Capita di frequente, nelle PMI italiane, di vedere lo stesso problema ripresentarsi a distanza di settimane. Una consegna saltata, un cliente insoddisfatto, una procedura che non viene rispettata: si reagisce, si tampona, si torna a lavorare. Poi, qualche mese dopo, riaccade — magari con una sfumatura diversa. Il problema non era stato risolto: era stato spostato.
\nIl problem solving aziendale è il processo strutturato che separa la fase di analisi da quella di soluzione. Non è \"fare una riunione di brainstorming\"; è una sequenza di fasi — definire il problema, raccogliere dati, identificare le cause radice, decidere la soluzione, verificarne l'effetto — in cui l'imprenditore o il team si impedisce volontariamente di saltare alle conclusioni. I metodi più diffusi (PDCA, A3, 8D, 5 perché, diagramma di Ishikawa) nascono in contesti industriali grandi, ma i loro principi si possono adottare anche in studi professionali e PMI [1][2][3].
\nIn questo articolo si analizzano la differenza tra problem solving strutturato e reazione improvvisata, i criteri per riconoscere quali problemi meritano analisi, il processo a fasi (PDCA, A3, 8D), le tecniche di analisi delle cause (5 perché, fishbone), il passaggio dalla decisione all'implementazione e gli errori più comuni.
\nQuanti dei \"problemi risolti\" in azienda nell'ultimo anno si sono ripresentati in forma diversa? Se il numero è alto, il problema non era stato risolto: era stato spostato — e il costo si misura in tempo dell'imprenditore.
\nLa parola \"problem solving\" viene usata in modo così generico che spesso indica solo \"fermarsi a discutere di un problema\". Una definizione operativa serve proprio a separare la pratica strutturata — con fasi, strumenti, output verificabili — dalla riunione improvvisata che produce buoni propositi e nessuna soluzione duratura. La distinzione conta: in PMI italiane la produttività del lavoro per addetto è inferiore alla media UE [7], e una parte del divario è riconducibile a problemi che si ripresentano perché non vengono mai analizzati a fondo.
\nDefinizione operativa. Il problem solving aziendale strutturato è un processo a fasi che include: (1) definizione chiara e misurabile del problema, (2) raccolta dei dati sulla situazione reale, (3) analisi delle cause radice, (4) identificazione e selezione delle soluzioni, (5) implementazione su scala pilota, (6) verifica dell'effetto, (7) standardizzazione se la soluzione funziona. È la disciplina del \"non saltare alle conclusioni\" applicata ai problemi operativi [1][2].
\nDisambiguazione dei quattro termini confusi.
\nProblem solving vs decision making. Il problem solving analizza un problema fino a definirne le cause; il decision making sceglie tra alternative già definite. Il primo precede il secondo. Spesso si pensa che \"risolvere un problema\" coincida con \"prendere una decisione\". In realtà la decisione arriva alla fine del processo di problem solving — non all'inizio.
\nProblem solving vs root cause analysis (RCA). Il problem solving è l'intero processo (definizione → analisi → soluzione → verifica); la root cause analysis è una fase di quel processo (l'analisi delle cause). Spesso usate come sinonimi, ma RCA senza le fasi successive lascia il problema irrisolto: si sa la causa, non si sa cosa fare.
\nProblem solving vs brainstorming. Il problem solving è un processo strutturato con fasi e strumenti; il brainstorming è una tecnica creativa per generare idee in modo libero. Quando si dice \"facciamo problem solving\" si intende quasi sempre \"facciamo brainstorming\" — saltando l'analisi delle cause. Il brainstorming è uno strumento dentro il problem solving, non il problem solving stesso.
\nProblem solving vs troubleshooting. Il problem solving si applica a problemi organizzativi e di processo (come e perché lavoriamo); il troubleshooting si applica a problemi tecnici di malfunzionamento (perché questa macchina non funziona). Usano logiche di analisi simili (anche il troubleshooting usa i 5 perché), ma hanno ambiti diversi.
\nPer il quadro organizzativo più ampio in cui il problem solving si inserisce come competenza sistemica, il pillar sistematizzazione aziendale offre il riferimento complessivo.
\nQuanti problemi si presentano ogni settimana — e quanti meritano davvero un'analisi delle cause? Trattare ogni anomalia come problema da analizzare paralizza l'azienda; ignorarne troppe la condanna a ripeterli.
\nNon tutti i problemi che si presentano in azienda meritano un'analisi strutturata: alcuni sono sintomi di un problema più grande, altri sono eventi isolati che non si ripresenteranno. La differenza tra le aziende che usano bene il problem solving e quelle che lo usano male non sta nello strumento, ma nel filtro di ingresso: cosa entra nel processo e cosa no. Una ricerca su 317 stabilimenti produttivi in 9 paesi (Bortolotti et al., 2015 [6]) mostra che le implementazioni di metodi strutturati hanno successo soprattutto dove esiste una pratica diffusa di selezione dei problemi su cui concentrarsi. Rother [4] descrive questa selezione come parte del \"kata\" — l'abitudine ripetibile, non l'evento eccezionale.
\nI quattro criteri di selezione (triage del problema).
\nRicorrenza. Il problema si è presentato più di due volte negli ultimi tre mesi? La ricorrenza è il segnale più affidabile che esiste una causa strutturale, non un evento isolato. Un problema che si presenta una sola volta può essere gestito con una risposta diretta; uno che si ripresenta merita analisi.
\nImpatto economico o di qualità. Il problema ha un costo misurabile (in tempo, in resa, in qualità percepita dal cliente)? Se l'impatto non è quantificabile anche in modo approssimativo, la priorità dell'analisi è bassa.
\nRischio di propagazione. Il problema, se non risolto, tende ad espandersi ad altri processi o ad altri clienti? Un errore che rimane confinato e non si propaga ha priorità diversa da uno che può contaminare l'intera catena.
\nCosto del non intervenire. Il costo di tollerare il problema per un altro trimestre è superiore al costo dell'analisi? Questa domanda è spesso la più illuminante: in molti casi il problema viene tollerato perché \"costa meno\" risolverlo man mano — ma questo calcolo non include il costo del ripresentarsi.
\nLe tre domande operative da porsi davanti a un problema.
\nSe le risposte indicano ricorrenza + impatto + propagazione, il problema entra nel processo strutturato. Altrimenti si gestisce con una risposta diretta e si tiene in osservazione.
\nPDCA, A3 o 8D: qual è il metodo giusto per il problema che si ha sul tavolo oggi? La scelta sbagliata non è \"uno qualunque va bene\": usare l'8D per un piccolo difetto ricorrente è uno spreco; usare il PDCA per un richiamo prodotto è una negligenza.
\nTre metodi diversi, tre logiche diverse, tre situazioni in cui ciascuno funziona meglio: il PDCA (Plan-Do-Check-Act, codificato da W. E. Deming negli anni '50) per il miglioramento iterativo di processi che già esistono; il report A3 (Toyota, anni '60) per problemi che richiedono comunicazione condensata e condivisione visiva; le 8 discipline (8D) introdotte da Ford nel 1987 per problemi gravi che richiedono contenimento immediato prima dell'analisi delle cause [3][5][9]. La scelta del metodo non è ideologica: dipende dalla gravità del problema, dal tempo a disposizione e dal numero di persone coinvolte. Anche la norma ISO 9001:2015 [8] richiede, alla clausola 10.2, un processo formale di analisi delle cause e di azioni correttive — quindi per le PMI certificate la scelta di un metodo strutturato non è facoltativa.
\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| Metodo | Quando usarlo | Output tipico | Tempo medio di applicazione |
|---|---|---|---|
| PDCA | Miglioramento iterativo di un processo esistente; problemi ricorrenti di medio impatto | Piano di azione con ciclo di verifica mensile | 2-4 settimane per ciclo |
| Report A3 | Problemi che richiedono analisi condivisa e comunicazione trasversale tra funzioni | Un singolo foglio A3 con problema, analisi, soluzione, verifica | 1-3 settimane |
| 8D | Problemi gravi con impatto su cliente o sicurezza; richiedono contenimento immediato | Report 8D con azione di contenimento + analisi cause + azione correttiva | 2-8 settimane |
PDCA in pratica per una PMI. Applicato a un processo ricorrente (es. gestione dei reclami cliente), il PDCA parte dalla definizione di un obiettivo misurabile (Plan), lancia un cambiamento su scala ridotta (Do), verifica il risultato a una data stabilita (Check) e adotta o scarta il cambiamento (Act). Il ciclo dura 2-4 settimane per problemi semplici; può estendersi a 2-3 mesi per problemi di processo più complessi.
\nA3 in pratica per una PMI. Il report A3 è un foglio singolo strutturato in 8 sezioni: background, situazione attuale, obiettivo, analisi delle cause, contromisure, piano di implementazione, verifica dei risultati, standardizzazione [3][5]. La forza dell'A3 è la sintesi forzata: se non si riesce a descrivere il problema in una pagina, il problema non è ancora stato compreso abbastanza bene da risolverlo.
\n8D in pratica per una PMI. Le 8 discipline seguono una sequenza: definizione del team, descrizione del problema, contenimento immediato, analisi della causa radice, scelta delle azioni correttive, implementazione, verifica dell'efficacia, riconoscimento del team [9]. Il contenimento immediato (disciplina 3) è la fase critica che distingue l'8D dagli altri metodi: si interrompe il danno prima ancora di capire la causa. Per la mappatura dei processi aziendali, che costituisce la base su cui applicare questi metodi, il cluster dedicato è il punto di partenza.
\nQuante volte la \"soluzione ovvia\" si è rivelata risolvere il sintomo e non la causa? Chiedersi \"perché?\" cinque volte di fila non è un esercizio scolastico: è ciò che separa una correzione che dura da una che si presenta di nuovo tra sei mesi.
\nDavanti a un problema, il riflesso più diffuso è proporre subito una soluzione — di solito quella che ha funzionato l'ultima volta in una situazione apparentemente simile. I 5 perché (formalizzati da Taiichi Ohno in Toyota e descritti da Masaaki Imai [1]) e il diagramma di Ishikawa (sviluppato da Kaoru Ishikawa al Cantiere Navale di Kawasaki nel 1943, codificato in [2]) sono due tecniche pensate per impedire questo cortocircuito: forzano il team a fermarsi e a interrogare la causa fino a un livello in cui la soluzione diventa diversa da quella iniziale. Sono strumenti di analisi dentro le fasi PDCA o A3, non alternative al processo.
\nI 5 perché — esempio applicato a una PMI di servizi.
\nProblema: \"Il cliente ha ricevuto il preventivo in ritardo di 3 giorni rispetto al termine concordato\".
\nCausa radice identificata: assenza di una procedura per preventivi urgenti con aggiornamento rapido dei costi. La soluzione non è \"fare attenzione ai tempi\": è creare la procedura mancante.
\nIl diagramma di Ishikawa (fishbone).\nIl fishbone è uno strumento di brainstorming strutturato per raccogliere le possibili cause di un problema in categorie. Le 6 categorie classiche (6M) sono: Manodopera (persone), Metodi (processi), Materiali (input), Macchine (attrezzature), Misurazioni (dati), Milieu/Ambiente (contesto). In una riunione di analisi di 30-45 minuti, il team elenca le possibili cause per ciascuna categoria, poi le ordina per probabilità e impatto per selezionare quelle da approfondire con i 5 perché.
\nNell'uso pratico per una PMI di servizi, le 6M si adattano: \"Macchine\" diventa \"Strumenti/Software\", \"Materiali\" diventa \"Input/Dati\". La struttura resta valida perché forza il team a esplorare categorie diverse di causa invece di convergere subito sulla prima ipotesi plausibile.
\nUna soluzione decisa ma non implementata fa più danno di un problema riconosciuto e tollerato? È possibile — perché crea l'illusione che il problema sia stato gestito, mentre l'effetto continua a propagarsi.
\nL'analisi della causa, anche fatta bene, non risolve nulla se la soluzione non viene implementata e verificata. La ricerca su 317 stabilimenti in 9 paesi (Bortolotti et al., 2015 [6]) mostra che il fattore più discriminante tra problem solving che funziona e problem solving che fallisce non è la qualità dell'analisi, ma la presenza di soft practices — coinvolgimento delle persone che eseguiranno la soluzione, formazione, follow-up strutturato. Decidere e implementare sono due fasi distinte: la prima sceglie tra alternative, la seconda le mette in pratica e ne misura l'effetto.
\nI quattro elementi operativi dell'implementazione.
\nCriteri di scelta tra soluzioni alternative. Quando esistono più soluzioni plausibili, valutarle su tre dimensioni: impatto atteso (quanta parte del problema risolve?), costo di implementazione (tempo, risorse, formazione), reversibilità (si può tornare indietro se non funziona?). Preferire soluzioni reversibili in fase iniziale: permettono di sperimentare senza rischi.
\nPilota su scala ridotta prima del rollout. La soluzione viene testata su un processo, un cliente, un team — non introdotta contemporaneamente su tutta l'organizzazione. Il pilota dura 2-4 settimane e produce dati reali prima di estendere la soluzione.
\nMetrica di verifica definita prima dell'implementazione. Prima di lanciare la soluzione, si stabilisce: come si misura il successo? Quali indicatori osservare? In che arco di tempo? Senza una metrica predefinita, la verifica dell'efficacia diventa soggettiva. Liker [3] descrive questo principio come \"go and see\": verificare di persona che la soluzione produca l'effetto atteso, non fidarsi solo dei report.
\nFollow-up con date e responsabili. Ogni azione ha un responsabile nominato e una data di verifica in agenda. Il follow-up avviene nella riunione successiva: si verifica se la soluzione ha prodotto il risultato atteso. Se sì, si standardizza. Se no, si torna all'analisi. Per la gestione del cambiamento implicita nell'implementazione di una nuova soluzione, il cluster gestione del cambiamento aziendale tratta le dinamiche di adozione.
\nQuale di questi cinque errori è quello che si ripresenta più spesso nelle riunioni di analisi? La risposta più onesta è di solito: \"tutti e cinque, in proporzioni diverse a seconda della settimana\".
\nGli errori ricorrenti nel problem solving aziendale non riguardano gli strumenti, ma il modo in cui vengono usati. La ricerca [6] e l'osservazione di Rother sul Toyota Kata [4] convergono su un punto: il problem solving fallisce quando viene trattato come evento eccezionale anziché come abitudine ripetibile. I cinque errori più frequenti sono prevedibili — e per questo evitabili.
\nErrore 1 — Saltare alle soluzioni senza definire il problema.\nDescrizione: la riunione di \"problem solving\" inizia direttamente con la proposta di soluzioni, senza aver definito il problema in modo misurabile.\nCorrezione operativa: il primo output della riunione è una frase che definisce il problema in modo osservabile: \"Il tempo medio di risposta ai reclami è di 7 giorni contro i 3 promessi\" — non \"i reclami vengono gestiti male\".
\nErrore 2 — Confondere il sintomo con la causa.\nDescrizione: la soluzione viene applicata alla prima causa visibile, che è quasi sempre un sintomo della causa radice.\nCorrezione operativa: applicare i 5 perché prima di proporre qualsiasi soluzione. Se il processo dura meno di 20 minuti senza strumenti, probabilmente ci si è fermati troppo presto.
\nErrore 3 — Decidere senza coinvolgere chi esegue.\nDescrizione: la soluzione viene decisa dalla direzione e comunicata ai collaboratori come istruzione. Il tasso di adozione è basso [6].\nCorrezione operativa: includere almeno una persona che esegue il processo nella fase di analisi e nella selezione della soluzione. La soluzione che chi esegue ha contribuito a definire viene implementata con più cura.
\nErrore 4 — Implementare senza definire la metrica di verifica.\nDescrizione: la soluzione viene lanciata, ma non è chiaro come si misura il successo. Dopo 4-6 settimane, nessuno sa se ha funzionato.\nCorrezione operativa: prima di implementare, definire: quale indicatore si osserva, in quale arco di tempo, con quale soglia di successo.
\nErrore 5 — Trattare il problem solving come evento e non come abitudine.\nDescrizione: il team si riunisce per fare problem solving solo quando il problema è già grave. Non esiste un rituale ricorrente di analisi dei problemi [4].\nCorrezione operativa: inserire una slot mensile (30-45 minuti) dedicata alla revisione dei problemi ricorrenti, prima che diventino emergenze. Il kata [4] è la pratica che trasforma il problem solving da evento a competenza.
\nContesti di emergenza. I metodi strutturati richiedono tempo di analisi. In situazioni di emergenza acuta (problema che produce danni immediati a clienti o a sicurezza), il contenimento immediato precede l'analisi. L'8D prevede esplicitamente questa sequenza: prima si contiene il danno, poi si analizza la causa.
\nFonti [1], [2], [3], [4], [5], [9]. Sono libri di management e manuali industriali, non studi peer-reviewed. Le affermazioni metodologiche si appoggiano a [6] (peer-reviewed) per la parte empirica. Le descrizioni dei metodi (PDCA, A3, 8D, 5 perché, Ishikawa) derivano dalle fonti originali dei rispettivi metodi.
\nFonte [7] ISTAT. Il dato sulla produttività delle PMI italiane rispetto alla media UE è una correlazione statisticamente documentata, non una prova causale diretta tra gestione reattiva dei problemi e gap di produttività. Il nesso è plausibile e coerente con la letteratura, ma non dimostrato direttamente dalla fonte.
\nDimensione del team. I metodi come l'A3 e l'8D sono più efficaci in contesti con più persone coinvolte nel processo analizzato. Per il libero professionista, il ciclo PDCA e i 5 perché sono sufficienti nella maggior parte dei casi.
\nQual è il metodo più adatto per iniziare?\nPer una PMI che non ha mai formalizzato un processo di problem solving, il PDCA è il punto di partenza più accessibile: non richiede formazione specifica, si applica a qualsiasi scala e produce risultati osservabili in 2-4 settimane.
\nQuanto dura una sessione di analisi delle cause?\nPer un problema di media complessità, una sessione di 45-60 minuti con i 5 perché o il fishbone produce un'analisi sufficiente a identificare le cause radice principali. Sessioni più lunghe producono analisi più approfondite, ma il ritorno marginale diminuisce oltre le 90 minuti.
\nI metodi Lean si applicano solo alle imprese manifatturiere?\nNo. I principi di analisi delle cause sono indipendenti dal settore. Un'agenzia di comunicazione, uno studio professionale e un'impresa di logistica usano gli stessi strumenti su problemi diversi. L'adattamento riguarda gli esempi e il linguaggio, non la struttura del metodo.
\nIl problem solving aziendale strutturato è un processo a fasi che separa l'analisi dalla soluzione: definire il problema in modo misurabile, raccogliere dati, analizzare le cause radice (con i 5 perché o il fishbone), scegliere la soluzione, implementarla in modo pilota, verificarla con una metrica predefinita, standardizzarla se funziona. Il metodo si sceglie in base alla gravità (PDCA per problemi ricorrenti di medio impatto, A3 per problemi cross-funzionali, 8D per problemi gravi con impatto esterno).
\nIl fattore più discriminante tra problem solving che funziona e problem solving che fallisce non è la qualità degli strumenti, ma la presenza di tre elementi: abitudine ricorrente (non evento eccezionale), coinvolgimento di chi esegue il processo, metrica di verifica definita prima dell'implementazione.
\nIl problem solving aziendale non è una tecnica creativa né un evento di riunione: è un processo strutturato che separa la fase di analisi da quella di soluzione, e che si appoggia a metodi codificati — PDCA, A3, 8D, 5 perché, diagramma di Ishikawa — scelti in base alla gravità del problema, al tempo disponibile e alle persone coinvolte. La differenza tra un'azienda che risolve e una che ricicla gli stessi problemi non sta nello strumento usato, ma nell'abitudine a fermarsi prima di proporre soluzioni.
\nQuesta abitudine si inscrive in un quadro più ampio. Il problem solving è il processo che si applica a un problema specifico; il miglioramento continuo è la filosofia che rende quei processi un abito quotidiano dell'intera azienda; la gestione del cambiamento è il modo in cui un'organizzazione affronta una trasformazione episodica più estesa. I tre approcci si rinforzano: si può approfondire il legame tra analisi quotidiana dei problemi e cultura del piccolo passo nell'articolo dedicato al miglioramento continuo, il modo in cui i problemi emergono dai processi nella mappatura dei processi aziendali, e il legame tra problem solving strutturato e architettura organizzativa nella pillar sulla sistematizzazione dell'azienda.
\nUn'azienda che adotta davvero il problem solving strutturato si riconosce da segnali concreti: lo stesso problema tende a non ripresentarsi nella stessa forma, le riunioni di analisi hanno un format ripetibile invece di essere brainstorming a ruota libera, le decisioni vengono verificate con metriche definite prima dell'implementazione, e l'imprenditore non resta l'unica persona capace di analizzare un problema. Se le PMI italiane riducessero la frazione di problemi che si ripresentano, una parte del gap di produttività rispetto alla media UE [7] si chiuderebbe — non per effetto di una svolta improvvisa, ma per un metodo più sobrio: fermarsi a chiedere \"perché\" prima di rispondere \"come\".
\n[1] Imai, M., \"Kaizen: The Key to Japan's Competitive Success\", McGraw-Hill, 1986 (II ed. 2012).
\n[2] Ishikawa, K., \"What is Total Quality Control? The Japanese Way\", Prentice-Hall, 1985.
\n[3] Liker, J. K., \"The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer\", McGraw-Hill, 2004.
\n[4] Rother, M., \"Toyota Kata: Managing People for Improvement, Adaptability, and Superior Results\", McGraw-Hill, 2010.
\n[5] Sobek, D. K. e Smalley, A., \"Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System\", Productivity Press, 2008.
\n[6] Bortolotti, T., Boscari, S. e Danese, P., \"Successful lean implementation: Organizational culture and soft lean practices\", International Journal of Production Economics, 160, 182–201, 2015.
\n[7] ISTAT, \"Rapporto sulla competitività dei settori produttivi — edizione 2024\", ISTAT, 2024. Disponibile su: https://www.istat.it/
\n[8] ISO, \"ISO 9001:2015 Quality management systems — Requirements\", International Organization for Standardization, 2015. Disponibile su: https://www.iso.org/standard/62085.html
\n[9] Ford Motor Company, \"Team Oriented Problem Solving (TOPS-8D) Manual\", Ford Motor Company, 1987 (aggiornato 2018).