Quasi sempre in un progetto di mappatura dei processi si dispone di risorse limitate. Questo ci obbliga a portare l’attenzione sui processi più importanti. Per questi si dovranno definire le responsabilità e conseguentemente formare dei team di sviluppo. Essendo i processi interfunzionali anche i team di sviluppo dovranno esserlo: è necessario coinvolgere tutto il personale interessato dalle varie fasi di un processo.

Una delle difficoltà principali è l’individuazione di un “process owner” ovvero il responsabile del processo. L’individuazione dello stesso deve tener conto di diverse considerazioni: l’importanza della persona nel processo, la posizione in organigramma (senza voler entrare nel dettaglio, è utile ricordare che spesso gli organigrammi esistenti non sono veritieri e nascondono gravi problemi organizzativi. Nei progetti SGQ ci si limita a descrivere quanto comunicato dalla direzione ma la verifica dell’organigramma sarebbe importantissima e dovrebbe essere affidata a specialisti come ad es. esperti di Coaching o del Process Counceling), le attitudini e le caratteristiche personali.

Alle volte non ci si può basare solo su criteri gerarchici, anche perché magari gli attori appartengono a funzioni diverse. Non è necessario generare una organizzazione a matrice che, nella maggior parte dei casi sarebbe troppo complessa da gestire. Un buon criterio può essere quello di considerare la persona che effettua il maggior numero di attività entro i confini di un singolo processo.

L’individuazione dei teams di sviluppo può essere aiutata da una semplice matrice funzioni/processi. Si pone una X oppure una sigla nelle caselle “risultati” e si ottengono i teams di sviluppo (così facendo si coinvolgono i soli rappresentanti di funzione). Per un maggiore dettaglio si intervista la direzione relativamente al processo e si sottolineano nella relazione tutti i soggetti che compiono azioni (contestualmente si possono mettere in evidenza le fasi, input e output, clienti, fornitori e mezzi per una prima bozza del diagramma di flusso che rappresenti il processo), tra essi si sceglieranno i membri del team.

Al fischio di inizio è fondamentale che siano state definite regole, metodi, mezzi, che tutti debbano seguire per consentire efficienza e coerenza nel lavoro svolto da diversi team. Spesso soprattutto i più esperti tendono a dare per scontate delle conoscenze da parte degli altri membri del team. In realtà le persone hanno diverse esperienze e background formativi, talvolta culturali perché provenienti da paesi molto diversi tra loro ma devono poter comprendere e utilizzare il lavoro dei colleghi. In questo senso non va mai sottovalutata una buona formazione di tutto il personale coinvolto.

Possono tornare molto utili anche degli accorgimenti di carattere pratico ed organizzativo. Definire:

– Nome del progetto.

– Sale dedicate (per lasciare raccoglitori, cartelline, poster alle pareti).

– Date e orari facili da ricordare (es. il giovedì mattina è dedicato dal Team A allo sviluppo del progetto B).

– Modalità per conduzione riunioni (durata riunioni, fasi tipiche riunione, responsabile, avvisi).

– Fogli, schede, raccolta dati, cartelline, modelli, prestampati e raccoglitori di progetto, struttura di salvataggio dei file di progetto (se si utilizza il lavoro di un collega sarà molto più facile orientarsi in una struttura conosciuta).

L’elenco può essere completato o adattato a seconda delle situazioni.

In molti casi il punto di partenza sono delle interviste fatte al personale coinvolto, altre volte esiste già una procedura testuale da analizzare. In entrambi i casi i processi possono essere analizzati estrapolando dalla descrizione gli elementi fondamentali del modello di processo descritto nei precedenti articoli:

– descrizione delle attività (intervista a uno o più membri del team);

– analisi delle responsabilità (estrapolare responsabili dall’intervista);

– costruzione del diagramma di flusso (estrapolare azioni dall’intervista);

– definire criticità/controlli/piani di reazione (per es. FMEA di processo);

– identificazione e definizione indicatori di prestazione;

– identificazione delle relazioni (estrapolare Input e Output dall’intervista);

– identificare Strumenti/mezzi/risorse (estrapolare dall’intervista).

Dopo questa prima fase si può avere il dubbio di aver fatto un buon lavoro o meno, ci si può chiedere se il risultato è completo o mancano ancora dei pezzi.

È importante sottolineare che nella trasformazione da testuale a grafico c’è un’ottimizzazione intrinseca che fa emergere generalizzazioni od omissioni consentite invece nelle descrizioni testuali (es. forme impersonali come “viene emesso”, ha senso ma da chi? Nel grafico lo dobbiamo indicare).

Una possibile verifica passa attraverso l’analisi dei compiti. Per ogni attività individuata ci si può chiedere ad esempio:

– L’obiettivo è chiaro?

– Responsabilità e compiti sono coerenti con capacità e autorità?

– L’attività fornisce un valore aggiunto, ovvero, è utile per la realizzazione dell’obiettivo di processo?

– È possibile valutare le sue prestazioni?

– È stato definito un metodo efficace di valutazione?

– Sono disponibili risultati che indicano che le prestazioni del compito consentono di realizzare l’obiettivo?

– Il risultato è stato ottenuto nella fase appropriata del processo?

– Questo è il solo processo che genera questo risultato?

Un altro metodo per scoprire le caratteristiche che determinano l’efficacia di un compito è il Metodo delle Six Ws, detto anche Five Ws (and one H): What (Cosa)? Why (Perché)? Who (Chi)? When(Quando)? Where (Dove)? How (Come)? (per approfondimenti: David Hoyle, 2001).

Per verificare la correttezza del diagramma di flusso è utile infine verificare se:

– I punti del modello di riferimento sono chiaramente identificabili? (Vedi fig.1-2)

– Le norme, le leggi, i requisiti interni e quelli dei clienti sono rispettati? (si può utilizzare una matrice requisiti/processi per controllarlo)

– Il risultato è coerente con le linee guida per lo sviluppo del SGQ tracciate dalla direzione?

– Le relazioni precedenti sono state confermate?

Considerando ogni processo così descritto come una “black box” possiamo mettere in evidenza i reali input ed output del processo e confrontarli con quanto in approccio Top-Down  era stato definito. Tale verifica consente di evidenziare incongruenze, incomprensioni, e consente il completamento della mappa delle relazioni (e delle informazioni) tra i processi.

Questo punto è molto importante perché consente di comprendere in modo auto evidente quali siano le famose “relazioni tra i processi” che vengono citate dai principali standard internazionali  (ISO 9001, ISO 14001, ISO 45001) per i sistemi di gestione.

Le frecce in entrata o in uscita da un grafico, che sono destinate ad altri grafici, ovvero che non si chiudono su un’azione descritta all’interno del medesimo processo, rappresentano le relazioni tra i processi.

Infine da questa verifica si può anche comprendere un ultimo aspetto.

Se una qualsiasi attività, documento, processo non risulta avere alcun collegamento in entrata od uscita è possibile che:

1. Vada eliminato perché non ha valore aggiunto.

2. Vi siano delle relazioni non identificate da scoprire.

Vistra è in grado di supportare le aziende nel loro processo di internazionalizzazione, in ciascuno dei quattro passi.

Aiutiamo le aziende italiane in tutto il mondo per le problematiche di Qualità, Sicurezza sul Lavoro ed Ambiente.

Se vuoi saperne di più e approfondire l’argomento, guarda il video.