Cinque perché, diagramma di Ishikawa, PDCA, DMAIC. Sono nomi che si sentono in ogni corso di formazione aziendale, spesso senza che nessuno spieghi quando usarli. Qui li mettiamo in fila, con i criteri per scegliere quello giusto davanti a un problema vero, non a un esercizio da manuale.
Perché il problem solving sul lavoro ha bisogno di strumenti, non solo di teoria
Un problema aziendale raramente si risolve con la buona volontà. Serve un percorso, e serve uno strumento adatto a quel tipo specifico di problema. Il rischio più comune è l’opposto: applicare lo stesso strumento a tutto, indipendentemente dal contesto, perché è quello che si conosce meglio.
Nel nostro lavoro con team aziendali abbiamo visto lo stesso schema ripetersi: un gruppo che padroneggia il brainstorming lo usa anche quando il problema richiederebbe un’analisi delle cause. Un reparto qualità abituato al Six Sigma prova a incasellare in DMAIC un problema relazionale tra due collaboratori. Il risultato è tempo perso e frustrazione. Non perché lo strumento sia sbagliato in sé. Ma perché è nel posto sbagliato.
Questo articolo raccoglie gli strumenti più usati nel problem solving aziendale — cinque perché, diagramma di Ishikawa, diagramma di Pareto, PDCA, DMAIC — e indica per ciascuno quando serve davvero e quando invece complica solo le cose.
Le 4, le 5 o le 7 fasi del problem solving: cosa cambia davvero tra i modelli
Chi cerca “fasi del problem solving” trova modelli a 4, a 5 e a 7 passaggi. Non sono in contraddizione tra loro: sono la stessa sequenza logica descritta a grana diversa.
Il modello a 4 fasi è il più sintetico: definire il problema, generare alternative, scegliere, agire. Quello a 5 fasi separa la raccolta di informazioni dalla generazione di alternative, e aggiunge quasi sempre una fase di verifica finale. Il modello a 7 fasi scompone ulteriormente ogni passaggio — ad esempio distingue l’identificazione del problema dalla sua definizione formale, e la valutazione delle opzioni dalla decisione vera e propria. Le domande che corrispondono a ciascuna fase sono in una guida alle domande per risolvere un problema.
La domanda giusta non è “quale modello è corretto”, ma “quanto è complesso il problema che ho davanti”. Un problema tecnico semplice si muove bene su 4 fasi. Un problema che coinvolge più reparti, con interessi diversi in gioco, ha bisogno della granularità del modello a 7 fasi, altrimenti si salta un passaggio senza accorgersene — di solito la definizione precisa del problema, che è anche il passaggio che quasi tutti bruciano per fretta.
La tecnica dei 5 Whys per arrivare alla causa reale in cinque domande
I 5 Whys sono lo strumento più rapido del problem solving aziendale: si chiede “perché” cinque volte di fila, partendo dal sintomo, fino ad arrivare alla causa che, se rimossa, fa sparire anche le sue conseguenze.
Un esempio da un contesto di produzione: una linea si ferma. Perché? Un sensore ha dato un falso allarme. Perché? Il sensore è sporco. Perché? Non è mai stato incluso nel piano di pulizia. Perché? Il piano di pulizia non è stato aggiornato quando è stato installato. Perché? Non esiste una procedura per aggiornare i piani di manutenzione quando arriva un macchinario nuovo. La causa reale non è il sensore. È un buco nella procedura. Sempre così.
Il limite dei 5 Whys è che funzionano bene quando la catena causale è una sola. Davanti a un problema con cause multiple e intrecciate, forzare una sequenza lineare di “perché” produce una risposta parziale, che sembra completa solo perché si è fermata al quinto passaggio invece che al primo utile.
Diagramma di Ishikawa e diagramma di Pareto per visualizzare le cause di un problema
Quando le cause possibili sono tante e confuse, il diagramma di Ishikawa — detto anche diagramma a lisca di pesce — le ordina per famiglie: persone, metodi, materiali, macchine, e spesso anche misurazioni e ambiente. Non dice quale causa sia quella giusta. Aiuta solo a non dimenticarne nessuna. Niente di più.
Il diagramma di Pareto arriva dopo, non prima. Una volta raccolte le cause possibili, mostra quali poche di esse producono la maggior parte degli effetti — la classica proporzione per cui una minoranza di cause spiega la maggioranza dei problemi. Serve a decidere dove concentrare le risorse, non a scoprire le cause: quello lo ha già fatto l’Ishikawa, o la raccolta di dati che lo precede.
Un errore frequente è usare il Pareto senza dati veri, per intuito. A quel punto non è più analisi. È un’opinione vestita da grafico. Niente di più affidabile di prima.
PDCA e ciclo di Deming: il miglioramento continuo applicato al problem solving aziendale
Il ciclo PDCA — pianifica, esegui, verifica, agisci — è anche noto come ruota di Deming. È pensato per problemi che si ripetono, in contesti dove i dati abbondano: una linea di produzione, un processo di assistenza clienti, un flusso amministrativo.
Funziona perché gira: non si esaurisce dopo un ciclo. Si pianifica un cambiamento, lo si esegue su scala piccola, si verificano i risultati, e solo allora lo si estende — oppure lo si corregge e si riparte. È lo strumento giusto quando il problema è noto e ricorrente, molto meno quando il problema è nuovo e non si è ancora capito bene cosa si sta osservando: lì il PDCA rischia di far correre verso un’azione prima che la diagnosi sia solida.
DMAIC e approccio Lean Six Sigma quando il problema è un processo e non un evento isolato
DMAIC — definire, misurare, analizzare, migliorare, controllare — è la versione più strutturata di questa logica, ed è il cuore del Six Sigma. Cinque fasi, ognuna con strumenti propri, tutte costruite attorno alla misura: la fase di analisi non parte finché non ci sono numeri affidabili su cui lavorare.
Questo è anche il suo limite più concreto: se i dati non ci sono, il metodo si blocca. Non è pensato per un problema isolato o per una decisione una tantum, ma per un processo che si ripete abbastanza spesso da generare una base di dati su cui costruire un miglioramento misurabile e duraturo nel tempo, con un controllo finale che ne mantenga i risultati.
Abbiamo visto reparti tentare di applicare DMAIC a un problema capitato una volta sola, con due settimane di dati raccolti in fretta. Il risultato tecnicamente rispetta le cinque fasi, ma la fase di analisi lavora su un campione troppo piccolo per dire qualcosa di affidabile.
Come scegliere lo strumento giusto in base al tipo di problema da risolvere
Nella nostra esperienza con team aziendali, la scelta dello strumento dipende da tre domande, più che dal problema in sé.
La prima: il problema è tecnico, con una causa individuabile? Allora i 5 Whys, l’Ishikawa e il Pareto lavorano bene, in questo ordine: raccogliere le cause possibili, individuare quelle prevalenti, scavare nella catena causale di quella prioritaria.
La seconda: il problema si ripete, e ci sono dati sufficienti? Allora PDCA o DMAIC, a seconda di quanto il contesto richiede rigore statistico. Un piccolo team può bastare col PDCA. Un processo industriale critico ha bisogno del DMAIC.
La terza, la più trascurata: il problema coinvolge persone, abitudini, interessi che confliggono? Nessuno di questi strumenti analitici lo scioglie da solo. Serve prima scomporre il problema, capire cosa ciascuna parte coinvolta rischia di perdere, e far emergere la soluzione dalle persone stesse invece di calarla dall’alto — un lavoro che assomiglia più alla mediazione che all’analisi statistica.
Riconoscere in quale delle tre categorie si trova il problema è già, da solo, più della metà del lavoro. Zero strumenti risolvono qualcosa se sono applicati alla categoria sbagliata. Zero, senza eccezioni.
Problem solving nella didattica: la stessa logica applicata in classe
La metodologia didattica del problem solving non è un argomento a parte: usa la stessa struttura logica — definizione del problema, raccolta, generazione di alternative, scelta, verifica — applicata a un contesto di apprendimento invece che a un processo aziendale. In classe, la risoluzione dei problemi viene proposta come esercizio guidato: l’insegnante presenta una situazione senza soluzione ovvia, e lo studente costruisce un piano di attuazione per affrontarla, spesso lavorando in piccoli gruppi.
Il punto di contatto con il problem solving aziendale è più stretto di quanto sembri. Il design thinking, per esempio, nasce come metodo per l’innovazione di prodotto ma viene insegnato anche in ambito scolastico proprio perché allena lo stesso tipo di pensiero: partire dal bisogno reale, non dalla soluzione già in mente. Chi si forma su questi strumenti a scuola arriva in azienda con un vantaggio concreto: ha già interiorizzato che la definizione del problema viene prima della sua soluzione, il principio su cui si basa ogni metodologia strutturata di problem solving, dai 5 Whys al DMAIC.
Domande frequenti sul problem solving sul lavoro
Quante fasi ha il problem solving: 4, 5 o 7?
Tutte e tre le versioni descrivono lo stesso percorso a livelli di dettaglio diversi. Un problema semplice si gestisce bene con 4 fasi; un problema complesso, con più soggetti coinvolti, ha bisogno della granularità del modello a 7 fasi per non saltare la definizione precisa del problema.
Qual è la differenza tra i 5 Whys e il diagramma di Ishikawa?
I 5 Whys seguono una sola catena causale in profondità. L’Ishikawa mappa più cause possibili in parallelo, per famiglie. Si usano insieme: prima l’Ishikawa per non dimenticare cause, poi i 5 Whys sulla causa più probabile per arrivare fino in fondo.
Quando conviene usare DMAIC invece di PDCA?
DMAIC quando servono rigore statistico e una base di dati solida, tipicamente in contesti Six Sigma o produzione ad alto volume. PDCA quando il ciclo di miglioramento deve essere più snello e veloce, con verifiche frequenti su scala ridotta.
Il problem solving è una competenza che si allena o è innata?
Si allena, come qualsiasi altra competenza trasversale. Migliora molto di più con una pratica ripetuta su problemi reali che con la sola lettura della teoria: ne abbiamo trovato conferma ogni volta che un team ha applicato uno di questi strumenti a un caso concreto invece che a un esercizio in aula.
Chi vuole vedere questi principi applicati dentro un metodo strutturato in sei fasi, con un caso aziendale reale raccontato passo per passo, può leggere la guida al metodo di problem solving in sei fasi e il caso della produzione in Romania su playsolving.com.