Lo strumento visivo per capire perché un piano non funziona
- Obiettivo identificare le cause di un problema, non soltanto descriverne gli effetti.
- Metodo 5M o 6M organizzare l’analisi per persone, processi, strumenti, materiali, misurazioni e ambiente.
- Uso pratico applicare il modello a ritardi, costi fuori controllo, turnover e inefficienze operative.
- Regola decisiva verificare le cause con dati e osservazioni prima di introdurre contromisure.
- Limite il diagramma genera ipotesi, ma non dimostra da solo quale causa sia quella principale.
Perché il diagramma di Ishikawa è utile nella pianificazione aziendale
Un obiettivo mancato può dipendere da molte variabili contemporaneamente. Un progetto digitale può accumulare ritardi per requisiti poco chiari, competenze insufficienti, dati incompleti o approvazioni troppo lente. Ridurre tutto a “il team non ha lavorato abbastanza” significa spesso scegliere una spiegazione comoda, ma poco utile.
La struttura a lisca di pesce parte da un effetto ben definito, collocato alla destra del diagramma. Le grandi linee che arrivano alla spina dorsale rappresentano le categorie di possibile causa, mentre i rami più piccoli dettagliano i fattori che possono aver prodotto il problema.
Io lo considero soprattutto uno strumento di confronto. In una riunione ben condotta obbliga le persone a distinguere tra opinioni, segnali e cause verificabili. Questo riduce il rischio di investire budget in soluzioni che affrontano soltanto la parte più visibile del problema.
Come leggere le categorie 5M e 6M
La versione più conosciuta utilizza il metodo delle 5M. In molte organizzazioni viene estesa a 6M aggiungendo l’ambiente, cioè il contesto fisico, organizzativo e normativo in cui il processo avviene.
| Categoria | Domanda utile | Esempio nella pianificazione |
|---|---|---|
| Manodopera | Le persone hanno competenze, tempo e responsabilità chiare? | Ruoli sovrapposti o formazione insufficiente |
| Metodo | Il processo è definito e applicato nello stesso modo? | Approvazioni senza sequenza condivisa |
| Macchine | Software, hardware e strumenti supportano davvero il lavoro? | Gestionale lento o sistemi non integrati |
| Materiali | Le risorse necessarie sono disponibili e adeguate? | Dati, documenti o forniture incompleti |
| Misurazioni | Gli indicatori sono affidabili e aggiornati? | KPI calcolati con dati parziali |
| Ambiente | Il contesto esterno o interno condiziona il risultato? | Normative, stagionalità o lavoro frammentato |
Non serve applicare le categorie in modo rigido. Per un’analisi HR, per esempio, posso sostituire “materiali” con informazioni e risorse; per un piano commerciale posso separare mercato, clienti e canali. La forma resta la stessa, ma le categorie devono parlare il linguaggio del processo analizzato.
Come costruirlo passo dopo passo
Il lavoro funziona meglio con un gruppo ristretto, in genere 4-8 persone che conoscano direttamente il processo. Un gruppo troppo numeroso tende a produrre molte idee, ma poca responsabilità sulle verifiche.
- Definire l’effetto con una frase precisa e misurabile, come “il 22% dei nuovi assunti completa l’onboarding oltre i 30 giorni”.
- Stabilire il perimetro indicando periodo, sede, reparto, prodotto o segmento coinvolto.
- Disegnare le categorie 5M, 6M oppure categorie personalizzate in base al processo.
- Raccogliere le cause senza cercare subito un colpevole. Ogni ipotesi deve descrivere un possibile meccanismo, non un giudizio sulla persona.
- Scendere di livello chiedendo più volte “perché può accadere?”. Qui il metodo dei 5 Perché aiuta a passare dalla causa apparente alla causa più profonda.
- Verificare le ipotesi con dati, osservazioni, interviste o test limitati.
- Definire le azioni assegnando un responsabile, una scadenza e un indicatore per controllare l’effetto.
La qualità del risultato dipende molto dalla formulazione iniziale. “Vendite basse” è troppo generico; “tasso di conversione dei lead qualificati sceso dal 18% al 10% in tre mesi” permette invece di cercare cause pertinenti e di confrontare il prima con il dopo.
Per evitare che il diagramma diventi una raccolta infinita di post-it, io assegno a ogni causa un livello di priorità e una modalità di verifica. Una causa importante ma non verificabile subito può restare nel piano di analisi, senza essere trasformata prematuramente in una decisione costosa.
Un esempio concreto per HR e digitalizzazione
Immaginiamo che un’azienda voglia ridurre i ritardi nell’onboarding digitale. L’effetto da scrivere alla destra del diagramma potrebbe essere “il nuovo dipendente completa il percorso iniziale in oltre 30 giorni”. Da qui il gruppo può sviluppare le seguenti ipotesi.
| Area | Possibili cause | Verifica consigliata |
|---|---|---|
| Persone | Il responsabile non sa chi deve approvare gli accessi | Interviste e controllo delle responsabilità assegnate |
| Metodo | Non esiste una checklist unica per il primo giorno | Confronto tra le procedure usate dai reparti |
| Tecnologia | Gli account vengono creati manualmente in sistemi diversi | Analisi dei tempi e dei passaggi del flusso |
| Informazioni | I dati del contratto arrivano incompleti all’IT | Controllo dei ticket e dei campi mancanti |
| Misurazioni | Il KPI parte dalla firma del contratto invece che dal primo giorno | Revisione della definizione dell’indicatore |
Questo esempio mostra perché la causa non è necessariamente “l’ufficio HR è lento”. Il ritardo potrebbe nascere da un modulo incompleto, da un passaggio duplicato o da un indicatore costruito male. La contromisura più efficace potrebbe quindi essere una checklist integrata tra HR e IT, non un semplice aumento del personale.
Lo stesso approccio si adatta al turnover, all’assenteismo, ai ritardi di progetto, alle richieste ripetute al servizio clienti e agli scostamenti di budget. Nel benessere organizzativo, però, bisogna proteggere la riservatezza: i dati aggregati aiutano a capire il processo, mentre attribuire pubblicamente il problema a singoli dipendenti distrugge la collaborazione necessaria per risolverlo.
Come trasformare le cause in decisioni di piano
Il diagramma non è il piano d’azione. È il passaggio che collega un problema a una serie di decisioni motivate. Per ogni causa prioritaria consiglio di definire almeno quattro elementi concreti:
- l’azione da realizzare;
- il responsabile operativo;
- la scadenza o la durata del test;
- il KPI che mostrerà se la situazione è migliorata.
Se la causa ipotizzata è la duplicazione degli inserimenti dati, l’azione può essere automatizzare il trasferimento tra due sistemi. Il test dovrebbe avere un perimetro chiaro, per esempio un reparto e quattro settimane, e misurare tempo medio, errori e richieste di assistenza prima di estendere la soluzione.
Qui il collegamento con la pianificazione aziendale diventa evidente. Le cause confermate aiutano a ordinare gli investimenti in base a impatto, urgenza e fattibilità, mentre le cause non verificate restano ipotesi da approfondire. È un modo semplice per rendere più trasparente il budget e spiegare perché una priorità è stata scelta rispetto a un’altra.
Quando il metodo non basta da solo
Il diagramma è qualitativo e dipende dalla conoscenza delle persone coinvolte. Se il gruppo include soltanto manager o soltanto specialisti, alcune cause operative possono non emergere. Per questo preferisco coinvolgere chi pianifica, chi esegue il processo e chi riceve il risultato.
Un altro rischio è confondere la presenza di una causa con la sua importanza. Il fatto che una variabile sembri plausibile non significa che produca davvero l’effetto. Servono dati storici, confronto tra gruppi, osservazione diretta o un piccolo esperimento controllato.
Per problemi complessi conviene affiancare il modello ad altri strumenti:
- 5 Perché per approfondire una singola catena causale;
- analisi Pareto per capire quali cause incidono maggiormente;
- mappa di processo per individuare passaggi, attese e responsabilità;
- matrice impatto-sforzo per scegliere le prime azioni;
- ciclo PDCA per testare, misurare e standardizzare il miglioramento.
Se l’effetto dipende da vincoli legali, rischi per la sicurezza o decisioni finanziarie rilevanti, l’analisi dovrebbe essere integrata da competenze specialistiche. La lisca di pesce organizza il ragionamento, ma non sostituisce una valutazione tecnica né dimostra da sola la causa radice.
Dal diagramma a un miglioramento che resta nel tempo
Il valore di questo strumento non sta nel disegno più bello, ma nella qualità delle domande che il team riesce a porsi. Un diagramma utile termina con poche cause prioritarie, verifiche realistiche e azioni collegate a indicatori leggibili.
La mia regola pratica è semplice: se dopo la riunione nessuno sa che cosa misurare, chi deve agire e entro quando, l’analisi è ancora incompleta. Quando invece le cause diventano decisioni tracciabili, il modello entra davvero nella pianificazione e aiuta l’azienda a usare meglio tempo, persone e risorse.
