Quanti problemi arrivano giornalmente sul vostro tavolo? Per quanti di questi è già chiara la causa?
Spesso di un problema se ne intravede solo l’effetto, comprenderne il motivo scatenante non è sempre cosa facile.
Implica innanzitutto una conoscenza approfondita del contesto di riferimento, il possesso di un buon numero di informazioni inerenti al problema, ed essere in grado di esplorare e analizzare la situazione da diverse angolazioni attraverso tecniche e processi specifici di problem solving.
L’esperienza di Toyota nel Lean manufacturing, ha fortunatamente lasciato in eredità non solo strumenti, tecniche e processi dedicati, ma addirittura una filosofia cui far riferimento e che illustriamo in questo articolo.
PDCA Cycle
William Edwards Deming, docente, saggista e consulente statunitense, ottenne risultati eccezionali negli Stati Uniti lavorando al miglioramento della produzione industriale.
Dal 1947, trasferitosi in Giappone, insegnò ai vertici societari delle più importanti realtà economiche nazionali, come migliorare il progetto, la qualità di prodotto, fornendo in ultima analisi, un contributo significativo al paese nel renderlo famoso per prodotti innovativi e di alta qualità.
Uno dei punti cardine degli insegnamenti di Deming, sta nel concetto di miglioramento continuo attraverso un approccio iterativo delle fasi di pianificazione, esecuzione, ispezione dei risultati e ottimizzazione, cui ha dato il nome di ciclo PDCA.
La fase di pianificazione (Plan) dovrebbe prevedere lo studio e l’analisi delle attività da realizzare, al fine di raggiungere l’obiettivo prefissato.
Nella fase di esecuzione (Do) vengono operativamente attuate quelle attività.
La fase di monitoraggio e controllo (Check) è centrale rispetto a tutto il processo; è il momento in cui si raccolgono i feedback e i dei dati inerenti le attività svolte. Il suo fine ultimo è di analizzarne i risultati, verificarne eventuali varianze o scostamenti rispetto ad una baseline e identificarne possibili azioni correttive o di miglioramento.
Azioni poi svolte nell’ultima fase Act e che potrebbero portare ad una eventuale ri-pianificazione, la quale lancerebbe una nuova iterazione del ciclo PDCA.
La fase Check del ciclo è il momento in cui eventuali problemi emergeranno.
Toyota ha sviluppato nel corso degli anni un approccio al problem solving che, anch’esso, prende spunto dagli insegnamenti di Deming e che prende il nome di A3 Process.
A3 Process
Quando venne sviluppato il metodo A3, l’intenzione era di trovare un procedimento immediato, diretto e semplice per affrontare e risolvere i problemi. Si partì quindi con il decidere che tutte le informazioni necessarie alla risoluzione di un problema, dovessero essere rappresentate e raccolte in un foglio di dimensione A3. Da qui il nome.
Questo avrebbe permesso agli interlocutori di non perdersi in dettagli inutili, evitando entropia (spreco) e aumentando la focalizzazione (efficienza). Un ulteriore valore aggiunto arrivava dal fatto che le persone coinvolte utilizzavano quel foglio A3, scrivendoci sopra, spesso a matita, confrontandosi ad un tavolo, uno di fronte all’altro, cancellando e correggendo e aggiungendo informazioni man mano che queste emergevano. Insomma, uno strumento che favoriva il coinvolgimento, incoraggiando dialogo e collaborazione.
Un altro punto di forza del metodo risiede nel fatto che questo è supportato da un preciso processo operativo, suddiviso in passi, che guida sequenzialmente il suo utilizzatore verso il risultato finale.
E ancora, alcune fasi del processo sono supportate da ulteriori tecniche di problem solving come Value Stream Mapping utilizzata per tracciare la situazione corrente, Fishbone Diagram e Five-Whys per scoprire causa scatenante e determinarne le motivazioni.
Le 7 fasi dell’A3 Process
Le fasi del processo A3, sono sette e sul foglio vengono riportate come riquadri e devono essere svolte in sequenza:
- Background
- Condizione Corrente
- Goal / Condizione di Arrivo
- Root Cause Analysis
- Contromisure (Tentativi)
- Conferme (Risultati)
- Follow-up
Come già anticipato il metodo segue le indicazioni del ciclo di Deming.
Le prime quattro fasi corrispondono alla fase di pianificazione e servono a contestualizzare il problema nello scenario attuale, determinare una condizione di arrivo e, attraverso l’analisi delle cause, identificare delle azioni risolutive o di miglioramento, che verranno eseguite nella quinta fase Do.
Successivamente, raccolti e analizzati i risultati, si potranno identificare eventuali ulteriori azioni da adottare.
I riquadri del report A3
Riquadro | Spiegazione |
Background | · Perché è necessario trattare l’argomento · Contesto di riferimento |
Condizione Corrente | · Dove siamo oggi? Cosa accade? · Diagramma o value stream map del processo corrente · Informazioni inerenti il problema: dati, indici, KPI |
Goal / Condizione di Arrivo | · Dove dovremmo essere oggi? · Quale risultato dovremmo ottenere? · Quale specifico cambiamento dovremmo effettuare? · Diagramma o value stream map del processo desiderato · Informazioni inerenti il nuovo stato: dati, indici, KPI |
Root Cause Analysis | · Brainstorming · Fishbone Diagram · Lista delle possibile cause · Five-Whys · Quale è la motivazione principale del problema? |
Contromisure (Tentativi) | · Quali sono le contromisure da attuare? · E’ necessario effettuare prove o sperimenti? · Qual’è il piano delle attività da eseguire? · Chi fa Cosa, Quando e Dove? |
Conferme (Risultati) | · Quali i risultati raggiunti? · Quali le conferme o i fallimenti degli esperimenti? · Quali gli insegnamenti? |
Follow-up | · Quali ulteriori azioni risolutive/migliorative possono essere svolte? · Come misurare il loro impatto? · Quando verranno misurati i risultati e con quale frequenza? |
Fishbone Diagram
La fase più interessante del processo di problem solving è forse quella in cui si analizzano i possibili fattori scatenanti e le eventuali motivazioni ad essi collegate (quadrante Root Cause Analysis del report A3).
Il diagramma Fishbone supporta egregiamente quell’analisi.
Innanzitutto viene descritto brevemente l’effetto negativo, il problema o il difetto in analisi.
Si procede poi all’identificazione delle categorie in cui si ipotizza possano risiedere le principali cause. Queste vengono poi collegate attraverso linee oblique alla linea principale che collega il problema, come riportato in figura.
Le categorie riportate in figura sono quelle maggiormente utilizzate in ambito manifatturiero industriale.
Per ognuna di quelle categorie si passa quindi ad un’identificazione puntuale della cause sottostanti.
Nell’esempio sotto riportato, invece, si vogliono analizzare le ragioni del mancato successo di un ipotetico prodotto software. A seguito di un’analisi delle cause sottostanti, è stato redato il seguente diagramma.
Dal diagramma si evince facilmente che il fallimento del prodotto è innanzitutto da addebitarsi alla scarsa qualità che ha causato un incremento significativo dei costi, notevoli ritardi nella fase di sviluppo che hanno concorso al posticipo nel lancio del prodotto.
La scarsa qualità del prodotto sembrerebbe essere stata causata dai continui ricicli e dal ritardo dell’esecuzione della fase di test. Questo ritardo ha richiesto l’assunzione di un nuovo tester, con conseguente aumento dei costi e un ritardo della fase di sviluppo.
Se l’analisi si fermasse a questo punto saremmo tentati di addossare tutte le colpe al dipartimento di test.
Andando più a fondo, invece, ci si rende conto che tutte le incertezze nascono da un ritardo nell’accettazione dei requisiti di prodotto che hanno fatto slittare a cascata tutte le altri fasi realizzative.
Spostando quindi l’attenzione nell’area “Requisiti non chiari” tra le cause troviamo il mancato coinvolgimento degli esperti, la presenza di requisiti troppo generici e la mancata prioritizzazione degli stessi, che potrebbe aver anche causato un’errata focalizzazione della fase di sviluppo su funzionalità secondarie invece di quelle a maggior valore.
Fiduciosi di aver trovato la causa scatenante del problema, è il momento di analizzarne le motivazioni di fondo per poter lavorare sulla loro risoluzione.
E’ il momento di introdurre la tecnica Five-Whys.
Five-Whys
Questa tecnica, sebbene a prima vista possa sembrare banale, è uno strumento utilissimo per l’esplorazione delle cause che stanno alla base di un problema.
Si tratta di chiedersi perché qualcosa sia accaduto, reiterando su ogni risposta la domanda “Perché?”, esplorando incessantemente le relazioni tra causa-effetto.
Solitamente, al massimo dopo cinque perché si arriverà al punto terminale, la causa radice, dove reiterare la domanda perché, porterà sempre alla stessa risposta.
Un esempio pratico dell’uso di Five-Whys
Il veicolo non parte.
- Perché il veicolo non parte? La batteria è scarica?
- Perché la batteria si è scaricata? L’alternatore non funziona.
- Perché l’alternatore ha smesso di funzionare? La cinghia dell’alternatore è rotta.
- Perché la cinghia si è rotta? E’ vecchia e non è stata sostituita.
- Perché non è stata sostituita? Il veicolo non è stato sottoposto ai tagliandi programmati.
Se l’analisi si fosse fermata alla prima risposta, si sarebbe cambiata la batteria, per ritrovarsi da lì a poco ancora appiedati.
Gli approfondimenti successivi hanno permesso di arrivare non solo a capire il malfunzionamento primario (cinghia rotta) ma anche la causa scatenante (mancata attenzione ai tagliandi programmati).
Tornando all’esempio del fallimento del prodotto software sopracitato, la tecnica five-whys andrebbe applicata alle tre cause identificate dell’area “Requisiti non chiari”, chiedendosi ciclicamente perché gli esperti non siano stati coinvolti e perché i requisiti fossero troppo generici e non fosse stata assegnata loro una priorità.
Ottenuta la lista delle reali motivazioni e procedendo con il metodo A3, dovremmo elencare per ognuna una contromisura o azione correttiva che andrebbe poi pianificata e assegnata affinché possa essere svolta nei tempi e nei modi decisi.
Il processo terminerebbe quindi con la fase di monitoraggio e controllo dei risultati al fine di verificarne la definitiva risoluzione o la necessità di ulteriori azioni di miglioramento.
Conclusioni
Come anticipato all’inizio di questo articolo, l’esperienza di Toyota nel campo del Lean manufacturing ha lasciato in eredità una vera e propria filosofia, un filo rosso che lega qualsiasi iniziativa, strumento o tecnica che sono state sviluppate negli anni di attività di quella eccezionale realtà giapponese.
Una filosofia che fa del rispetto delle persone e del miglioramento continuo i due pilastri fondanti, su cui poggiano valori come collaborazione, condivisione della conoscenza, problem solving, sviluppo del capitale umano, coinvolgimento e lavoro di squadra.
*Agile Practice Leader & Coach – Inspearit Italy
http://it.linkedin.com/in/emilianosoldi/
http://www.inspearit.it/it/news/blog/
