Un cliente riceve la merce sbagliata. Si rimedia con una spedizione urgente, ci si scusa, si promette più attenzione. Il mese dopo succede di nuovo, con un altro cliente e un altro codice. Il problema era stato risolto, eppure è tornato.
\nA quel punto molti imprenditori arrivano alla stessa conclusione: serve un metodo di problem solving. Si comincia a cercare e si trova di tutto: PDCA, DMAIC, 8D, A3, 5 perché, diagramma di Ishikawa, Kaizen, Design Thinking. Ognuno con i suoi passi, i suoi moduli, i suoi corsi.
\nMettendo in fila i principali, ne abbiamo contati 50, tra metodi, framework e strumenti, ciascuno con i testi da cui nasce. Davanti a una lista così la domanda viene da sé: quale scegliere?
\nIn questo articolo proviamo a rispondere. Ma partiamo da una domanda che viene prima: che cosa serve a qualsiasi metodo per funzionare?
\nLa prima distinzione è tra metodi e strumenti.
\nAlcune voci sono metodi completi: guidano tutto il percorso, dal problema alla soluzione, fino alla verifica del risultato. PDCA, DMAIC, 8D, Toyota Business Practices e Kepner-Tregoe sono di questo tipo.
\nAltre sono strumenti, che si usano dentro un metodo per fare un passo preciso. I 5 perché e il diagramma di Ishikawa servono a cercare le cause. L'analisi di Pareto serve a decidere da dove cominciare. La FMEA serve a prevedere dove un processo può cedere.
\nL'A3 sta nel mezzo: è un modo di ragionare e insieme un foglio che mette quel ragionamento su una sola pagina.
\nConfondere le due cose porta a un errore frequente: adottare uno strumento credendo di aver adottato un metodo. Si disegna un diagramma di Ishikawa a ogni riunione, ma nessuno controlla poi se la soluzione ha funzionato.
\nPer orientarsi conviene raggrupparli in base alla domanda a cui rispondono.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| La domanda | Metodi e strumenti |
|---|---|
| Come risolvo un problema che c'è già? | PDCA, DMAIC, 8D, A3, Toyota Business Practices, QC Story, Kepner-Tregoe |
| Qual è la vera causa? | 5 perché, diagramma di Ishikawa, Root Cause Analysis, Fault Tree Analysis, analisi «è / non è», Change Analysis, Barrier Analysis, Apollo, TapRooT, Shainin Red X |
| Da dove comincio? | Analisi di Pareto, Theory of Constraints e i suoi Thinking Processes |
| Come evito che succeda? | FMEA, Pre mortem, Bow Tie Analysis |
| Come miglioro il processo ogni giorno? | Lean Problem Solving, Kaizen, Kaizen Event, Six Sigma, controllo statistico di processo (SPC), 7 strumenti base della qualità |
| Come trovo una soluzione nuova? | Design Thinking, Double Diamond, Creative Problem Solving, modello Osborn-Parnes, TRIZ, Synectics, SCAMPER, Brainstorming, pensiero laterale, Sei cappelli per pensare |
| Quale alternativa scelgo? | Cynefin, OODA Loop, albero delle decisioni, analisi costi-benefici, analisi multicriterio, matrice decisionale pesata, analisi SWOT, Gap Analysis |
| Che cosa abbiamo imparato? | After Action Review, Lessons Learned, Post mortem |
Guardando come lavorano, però, quasi tutti rientrano in 2 grandi categorie:
\nLe prime cercano strade nuove. Le seconde risalgono all'origine di quello che non va.
\nQual è il migliore, allora? E perché ce ne sono così tanti, invece di uno solo?
\nSe un metodo funzionasse sempre, con qualsiasi problema e nelle mani di chiunque, tutti userebbero quello e gli altri sarebbero spariti. Quando in una disciplina convivono decine di modi diversi di fare la stessa cosa, di solito vuol dire che nessuno funziona sempre e per tutti. Un metodo universale di problem solving, insomma, non esiste.
\nSuccede lo stesso con le diete: quella che funziona per una persona non è detto che funzioni per un'altra. Allo stesso modo, ogni metodo di problem solving può rivelarsi efficace o inefficace a seconda di chi lo applica e del problema su cui lo si applica.
\nOgnuno dà il meglio in un contesto preciso. L'8D è nato nell'industria automobilistica, con Ford, ed è ancora molto usato nelle fabbriche. Barrier Analysis e TapRooT si usano soprattutto nella sicurezza e nell'analisi degli incidenti. Design Thinking e Double Diamond vengono dalla progettazione di prodotti e servizi.
\nPer una piccola o media impresa non serve conoscerli tutti. Serve capire che cosa hanno in comune.
\nSe si mettono uno accanto all'altro i metodi completi, si nota che il primo passo è quasi sempre lo stesso:
\nHanno in comune anche l'obiettivo. L'8D punta a prevenire che il problema si ripresenti. La Root Cause Analysis cerca le cause profonde invece di intervenire sui sintomi.
\nRisolvere un problema, per tutti questi metodi, vuol dire fare in modo che non capiti più. Una toppa non lo risolve: lo rimanda.
\nTaiichi Ohno, l'ingegnere che ha costruito il sistema di produzione Toyota, spiegava i 5 perché con un esempio diventato famoso. Una macchina si ferma.
\nFermandosi alla prima risposta si cambia il fusibile, e la macchina riparte. Fermandosi alla quarta si cambia l'albero della pompa. In entrambi i casi, scriveva Ohno, il guasto si sarebbe ripresentato dopo qualche mese. Solo il quinto perché porta a una soluzione che chiude il problema: montare il filtro.
\nDi solito questo esempio si racconta per mostrare la forza della domanda «perché?». Ma c'è un dettaglio che passa inosservato: il metodo parte da una macchina ferma. Cioè da un problema che qualcuno ha visto, ha considerato un problema e ha deciso di analizzare.
\nUna macchina ferma si vede. Molti problemi in azienda invece non fanno rumore: un preventivo rifatto due volte, un cliente che non riordina, un collaboratore che aspetta istruzioni invece di segnalare che qualcosa non va.
\nTutti questi metodi danno per scontata una cosa: che il problema sia già lì, davanti a chi lo deve risolvere. Visto, scritto, scelto come il più importante.
\nNella realtà delle aziende è proprio questo il passo che spesso manca. E manca in 3 modi.
\n1. Il problema non si vede. Chi lo vive ogni giorno lo considera normale, o non lo segnala per non creare tensioni. Il titolare diventa l'unico a vedere i problemi, e vede solo quelli che arrivano fino a lui.
\n2. Il problema si vede, ma si scrive male. «Il muletto si guida male» e «Mancano regole per l'uso del muletto» descrivono lo stesso incidente, ma portano a soluzioni diverse. Un metodo lavora su quello che riceve: se la definizione è sbagliata, trova con grande precisione la soluzione al problema sbagliato.
\n3. Si sceglie il problema sbagliato. Si interviene sul problema più urgente o più fastidioso, non su quello che genera più conseguenze. L'analisi di Pareto aiuta a scegliere, ma lavora sulla frequenza dei problemi: se nessuno li annota, non c'è nessuna frequenza da contare.
\nQuesti 3 errori li analizziamo più a fondo nell'articolo Fare ordine nei problemi aziendali.
\nVedere, scrivere e ordinare i problemi è una competenza a sé, che viene prima del problem solving. La chiamiamo Problem Noting.
\nLa miglior tecnica di problem solving, quindi, non è una tecnica di problem solving.
\nIl Problem Noting non sostituisce i metodi: è quello che permette loro di funzionare. Un'azienda che annota con metodo i propri problemi può usare il PDCA, l'8D o un semplice 5 perché e ottenere risultati. Un'azienda che non lo fa può adottare il metodo più sofisticato e continuare a risolvere gli stessi problemi.
\nNon dipende dalla bravura delle persone, ma da come l'azienda tratta i problemi. Quando segnalarli è un'abitudine di tutti, e non un compito del solo titolare, i problemi arrivano al metodo per tempo e scritti in modo utile.
\nSe nessun metodo di problem solving è universale, esiste un modo di gestire i problemi che lo sia?
\nSì: è quello che poggia su principi naturali. Anzi, i metodi universali di gestione dei problemi sono 2, e ogni elemento naturale li usa da miliardi di anni, comprese le cellule del nostro corpo.
\nTra le discipline che si usano in azienda, quella che si avvicina di più a questo metodo si chiama Problem Management, ed è conosciuta soprattutto in ambito informatico.
\nIl Problem Management tiene separate due cose che in molte aziende si confondono: l'incidente e il problema. L'incidente è il cliente che riceve la merce sbagliata: va sistemato subito, con la spedizione urgente e le scuse. Il problema è la causa che fa ripetere l'incidente il mese dopo, con un altro cliente e un altro codice.
\nPer questo, prima di cercare una soluzione, il Problem Management chiede di individuare i problemi, anche quelli nascosti dietro incidenti che si ripetono, di registrarli e descriverli, e di ordinarli in base al rischio che comportano. Vedere, scrivere e ordinare: sono gli stessi passi del Problem Noting.
\nFatto questo passo, la scelta del metodo diventa più semplice, perché dipende dal tipo di problema che si ha davanti:
\nPer cominciare basta un ciclo semplice come il PDCA, e la domanda «perché?» ripetuta finché si arriva a una causa su cui si può agire.
\nRicapitolando per punti:
\n