Problem Solving Aziendale: Metodi Strutturati per Analizzare e Risolvere Problemi

La risposta più frequente è la prima, e di rado è giusta.

Il problem solving aziendale è il processo strutturato che separa l'analisi di un problema dalla sua soluzione, con metodi codificati — PDCA, report A3, 8D, 5 perché, diagramma di Ishikawa — nati nell'industria e adattabili a qualunque scala [1][2][3].

Il metodo, però, è l'ultimo a entrare in gioco.

Un preventivo in ritardo nello studio di un professionista, un difetto che torna ogni mese nel reparto di un'azienda familiare, un reclamo che rimbalza fra tre uffici in un'impresa da cento persone: tre scale diverse, la stessa storia.

Sono stati risolti in fretta, senza che qualcuno li avesse davvero trovati.

In Italia, secondo l'ISTAT, quasi otto imprese su dieci con almeno tre addetti ne contano meno di dieci (78,9%, dati 2022) [10].

A quella taglia un ufficio qualità è l'eccezione: chi trova il problema è anche chi dovrà scegliere come affrontarlo.

Risolvere è l'ultimo di tre gesti: prima il problema va trovato e nominato, poi va scelta con criteri espliciti la strada per affrontarlo. Il metodo giusto è quello che serve al gesto in cui ci si trova.

Le sezioni che seguono percorrono i tre gesti nell'ordine in cui accadono: trovare il problema prima che costi, abbinare il metodo al problema, scegliere fra le alternative con criteri scritti, evitare gli errori che riportano all'inizio.

Capire cos'è il problem solving strutturato (e perché non è "fare una riunione")

Quanti 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.

La 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.

Definizione 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].

Disambiguazione dei quattro termini confusi.

Problem 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.

Problem 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.

Problem 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.

Problem 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.

Per il quadro organizzativo più ampio in cui il problem solving si inserisce come competenza sistemica, il pillar sistematizzazione aziendale offre il riferimento complessivo.

Trovare il problema prima che costi: problem finding, segnali deboli e gap analysis

Chi, in azienda, ha il compito di accorgersi che un problema esiste prima che lo dica un cliente?

La ISO 9001:2015 chiede di individuare i rischi prima che producano effetti indesiderati [8], ma in molte PMI la risposta reale è «il titolare, quando passa in reparto» — un metodo che funziona finché il titolare passa in reparto.

Senza un modo per trovare i problemi, una PMI li riceve: dal cliente che reclama, dal fornitore che sollecita, dal collaboratore che si dimette.

Il problem finding è il gesto che precede ogni metodo e che, nella pratica, raramente ha un responsabile.

Questa sezione distingue trovare, impostare e risolvere un problema, mostra come leggere i segnali deboli prima che diventino reclami, e introduce la gap analysis come misura della distanza fra come si lavora e come si dovrebbe.

Quei tre canali consegnano il problema quando è già costoso, dopo mesi di segnali rimasti senza destinatario.

Fino a quel momento il solo sensore è il giro di un titolare che alterna scrivania e reparto.

Il linguaggio corrente confonde tre gesti: il problem finding è accorgersi che un problema esiste prima che si manifesti come danno; il problem setting è dargli forma — perimetro, misura, chi ne soffre — prima di analizzarlo; il problem solving è il processo strutturato che segue.

La sequenza non si inverte: trovare, impostare, risolvere.

Il vocabolario Treccani fa risalire «problema» al greco próblēma, da un verbo che significa «mettere avanti, proporre» [11]: un problema esiste quando qualcuno lo mette davanti, e il problem finding è l'atto di metterlo davanti.

I segnali deboli sono anomalie piccole e ripetute sotto la soglia del reclamo: il livello a cui la clausola 6.1 della ISO 9001:2015 chiede di intervenire [8].

In un'azienda familiare da quindici persone hanno volti noti a chi sta in reparto, non a chi legge i report a fine mese: il collaboratore storico che rifà a mano un controllo «per sicurezza», la stessa scusa in due consegne di fila, un cliente che smette di chiedere preventivi senza lamentarsi.

Tre canali bastano a raccoglierli: una domanda fissa nel giro in reparto («che cosa è stato rifatto questa settimana?»), un registro a una riga (data, cosa, chi l'ha notato), una rilettura mensile per vedere cosa si ripete.

Quando un segnale si ripete, la gap analysis misura la distanza fra come si lavora (as-is) e come si dovrebbe (to-be): ordini evasi in cinque giorni contro i tre promessi sono un gap di due giorni, e il problema è impostato, non ancora analizzato.

Il confine, in una frase: il problem finding nota che il problema c'è, la gap analysis misura quanto è grande, la root cause analysis scava perché c'è.

Nell'uso italiano corrente l'assessment valuta persone (selezione, assessment center) o rischi (risk assessment); la diagnosi organizzativa esamina il modo in cui si lavora, e il problem finding ne è il primo passo.

Il punto di vista complementare, che parte dal disordine reale dei problemi, è nell'editoriale su come fare ordine nei problemi aziendali.

La risposta alla domanda di apertura è un nome e un canale: chi sta nel processo raccoglie i segnali, chi guida li rilegge.

Una volta trovato e nominato, un problema deve ancora guadagnarsi l'analisi: non tutti la meritano.

Riconoscere quali problemi meritano analisi (e quali sono solo sintomi)

Quanti 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.

Non 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 una decina di 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.

I quattro criteri di selezione (triage del problema).

Ricorrenza. 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.

Impatto 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.

Rischio 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.

Costo 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.

Le tre domande operative da porsi davanti a un problema.

1. Si è già presentato in questa forma (o in una simile) negli ultimi 90 giorni?
2. Chi ne soffre direttamente (interno, cliente, fornitore) e con che frequenza?
3. Se lo si ignora per un mese, cosa succede?

Se le risposte indicano ricorrenza + impatto + propagazione, il problema entra nel processo strutturato. Altrimenti si gestisce con una risposta diretta e si tiene in osservazione.

Il processo a fasi: PDCA, A3 Toyota, 8D — quando usarli

PDCA, 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.

Tre 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.

scorri la tabella →

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.

A3 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.

8D 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.

Tecniche per non saltare alle soluzioni: 5 perché e diagramma di Ishikawa

Quante 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.

Davanti 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.

I 5 perché — esempio applicato a una PMI di servizi.

Problema: "Il cliente ha ricevuto il preventivo in ritardo di 3 giorni rispetto al termine concordato".

1. Perché? Il responsabile commerciale non ha completato il preventivo in tempo.
2. Perché? Non aveva i dati di costo aggiornati per il servizio richiesto.
3. Perché? I costi vengono aggiornati una volta al trimestre, ma il preventivo richiedeva dati di costo correnti.
4. Perché? Non esiste una procedura per richiedere un aggiornamento rapido dei costi in caso di preventivi urgenti.
5. Perché? La procedura commerciale non prevede il caso del preventivo urgente come eccezione.

Causa 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.

Il diagramma di Ishikawa (fishbone). Il 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é.

Nell'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.

Quale metodo per quale problema: la tabella comparativa da PDCA alla root cause analysis

Quando l'ultimo problema è stato affrontato con un metodo scelto apposta, e non con quello usato la volta prima?

In molte PMI il metodo non si sceglie: si eredita.

Una ricerca su 317 stabilimenti manifatturieri [6] indica che a fare la differenza sono le pratiche con cui i metodi vengono usati, non gli strumenti in sé — e un metodo ereditato risponde a un problema che non c'è più.

PDCA, report A3 e 8D sono processi completi; 5 perché e diagramma di Ishikawa sono tecniche di analisi che vivono dentro quei processi; la root cause analysis è la famiglia che le raccoglie.

Metterli sulla stessa tabella non serve a eleggere il migliore, ma a leggere in tre colonne — quando usarlo, cosa produce, quanto dura — quale risponde al problema che si ha davanti.

La sezione chiude con il DMAIC, il parente più formale, e con la matrice di selezione che rende la scelta ripetibile.

Il metodo si sceglie per gesto e per problema, non per abitudine.

Rispetto alla tabella a tre righe vista sopra, questa aggiunge il diagramma di Ishikawa, i 5 perché e la root cause analysis.

scorri la tabella →

Il DMAIC (Define, Measure, Analyze, Improve, Control) è il ciclo del Six Sigma: un PDCA con una fase di misura formale in più, adatto a processi con molti dati e una variabilità da ridurre; per una PMI sotto i 50 addetti è di rado la prima scelta.

La tabella si legge in tre mosse: un impatto su cliente o sicurezza porta all'8D a prescindere.

In sua assenza decide il perimetro: più funzioni coinvolte portano al report A3, una sola al PDCA.

Dentro il processo scelto, Ishikawa quando le cause sono molte e disordinate, 5 perché quando la catena è lineare.

In un'azienda familiare da quindici persone la regola cambia le abitudini: un difetto che torna ogni mese in reparto è un caso da PDCA, il ciclo del miglioramento continuo, non da 8D; un reclamo che tocca la sicurezza del cliente è da 8D anche se l'azienda è piccola.

La versione compilabile della tabella è la Matrice di selezione del metodo di problem solving: stesse sei righe, e le tre variabili — gravità, tempo, persone coinvolte — su cui si marca la scelta.

Alla domanda di apertura la tabella dà una risposta verificabile — il metodo è scelto apposta quando si sa dire quale riga lo ha indicato — e lascia aperto il passaggio comune a ogni metodo: decidere che cosa fare, e farlo davvero.

Decidere e implementare la soluzione: il passaggio più delicato

Una 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.

L'analisi della causa, anche fatta bene, non risolve nulla se la soluzione non viene implementata e verificata. La ricerca su 317 stabilimenti in una decina di 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.

I quattro elementi operativi dell'implementazione.

Criteri 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.

Pilota 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.

Metrica 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.

Follow-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.

Scegliere fra più alternative con criteri espliciti: la matrice decisionale in 4 passi

Quando fra due proposte vince quella del titolare, è perché era la migliore o perché era del titolare?

Il principio 13 del Toyota Way chiede di decidere con calma, considerando a fondo le opzioni, e poi di attuare in fretta [3]: senza criteri scritti prima della discussione, la risposta non si può dare — e chi ha perso lo sa.

I tre criteri visti sopra — impatto, costo, reversibilità — bastano quando le alternative sono due.

Quando sono tre o più, e i criteri non pesano allo stesso modo, serve una matrice decisionale: le alternative in riga, i criteri in colonna, un peso per ciascun criterio, compilata prima di discutere.

Questa sezione mostra come costruirla in un quarto d'ora, come far entrare le proposte di chi esegue, e dove finisce il problem solving e comincia la decisione.

La matrice si costruisce in quattro passi.

1. Elencare le alternative, non più di quattro.
2. Scegliere da tre a cinque criteri: i tre già noti, più quelli che il caso richiede, come il tempo di attivazione o l'accettazione di chi esegue.
3. Dare a ogni criterio un peso da 1 a 3, prima di conoscere i punteggi.
4. Dare a ogni alternativa un punteggio da 1 a 5 per criterio, moltiplicare per il peso e sommare.

Un criterio ponderato è un criterio che conta più degli altri in modo dichiarato: il peso scritto in colonna rende esplicito ciò che in riunione resta implicito.

Un esempio ipotetico, in un'azienda familiare con i reclami evasi in ritardo: tre alternative — assumere una persona, cambiare gestionale, riscrivere la procedura — la seconda proposta dal titolare, la terza dal capo reparto storico che il processo lo esegue.

Con i pesi fissati prima somma di più la procedura riscritta: meno impatto del gestionale, ma reversibile, rapida da attivare e accettata da chi la userà.

La riga riservata alla proposta di chi opera nel processo non è una cortesia: la ricerca [6] indica che coinvolgimento e formazione di chi eseguirà distinguono le implementazioni riuscite da quelle fallite.

Perché quella riga non resti vuota serve un canale ordinario, come la Bacheca proposte di miglioramento.

Cinque concetti del glossario tengono insieme matrice e riunione.

• Autonomia decisionale: chi può chiudere la scelta senza risalire al titolare.
• Perimetro decisionale: entro quale ambito o importo la scelta spetta a chi esegue.
• Regola decisionale: il criterio scritto prima («vince la somma più alta, salvo veto di sicurezza»).
• Riunione decisionale: dove la matrice si compila e si chiude, distinta dalla riunione di analisi.
• Decision fatigue: perché la matrice si compila a inizio riunione, non a fine giornata.

Scelta l'alternativa, l'implementazione della soluzione passa da pilota, metrica e follow-up già visti, e il problem solving si ferma lì: ordinare le cose da fare è un'altra competenza, trattata nella gestione delle priorità.

Alla domanda di apertura si può ora rispondere: con la matrice compilata prima, la proposta del titolare vince quando somma di più, e chi ha perso lo legge nelle colonne.

Una scelta fatta così regge alla riunione successiva; ciò che la fa cadere sono errori ricorrenti, che conviene saper riconoscere in anticipo.

Errori comuni nel problem solving aziendale (e come evitarli)

Quale 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".

Gli 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.

Errore 1 — Saltare alle soluzioni senza definire il problema. Descrizione: la riunione di "problem solving" inizia direttamente con la proposta di soluzioni, senza aver definito il problema in modo misurabile. Correzione 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".

Errore 2 — Confondere il sintomo con la causa. Descrizione: la soluzione viene applicata alla prima causa visibile, che è quasi sempre un sintomo della causa radice. Correzione 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.

Errore 3 — Decidere senza coinvolgere chi esegue. Descrizione: la soluzione viene decisa dalla direzione e comunicata ai collaboratori come istruzione. Il tasso di adozione è basso [6]. Correzione 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.

Errore 4 — Implementare senza definire la metrica di verifica. Descrizione: la soluzione viene lanciata, ma non è chiaro come si misura il successo. Dopo 4-6 settimane, nessuno sa se ha funzionato. Correzione operativa: prima di implementare, definire: quale indicatore si osserva, in quale arco di tempo, con quale soglia di successo.

Errore 5 — Trattare il problem solving come evento e non come abitudine. Descrizione: il team si riunisce per fare problem solving solo quando il problema è già grave. Non esiste un rituale ricorrente di analisi dei problemi [4]. Correzione 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.

Limiti e condizioni di applicabilità

Contesti 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.

Fonti [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.

Fonte [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.

Dimensione 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.

Fonti [10] e [11]. Il dato ISTAT [10] descrive la struttura dimensionale delle imprese con almeno tre addetti (anno 2022) e non misura pratiche di gestione dei problemi: l'inferenza sull'assenza di una funzione qualità è della redazione. La voce Treccani [11] è un ancoraggio linguistico, non una prova empirica.

FAQ — Domande frequenti sul problem solving aziendale

Qual è il metodo più adatto per iniziare? Per 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.

Quanto dura una sessione di analisi delle cause? Per 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.

I metodi Lean si applicano solo alle imprese manifatturiere? No. 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.

Sintesi operativa

Il 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). Prima del metodo vengono due gesti: trovare il problema quando è ancora un segnale debole e scegliere fra le alternative con criteri scritti; risolvere è il terzo, e la tabella comparativa a sei righe abbina il metodo al tipo di problema.

Il 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.

Conclusione

Il problem solving aziendale non è un metodo da applicare: è una sequenza di tre gesti, e il metodo serve soltanto al terzo.

Trovare il problema mentre è ancora un segnale debole, scegliere con criteri dichiarati fra le strade possibili, risolvere con la tecnica adatta al tipo di problema: le aziende che riciclano gli stessi problemi di rado sbagliano il terzo gesto, saltano i primi due.

I metodi restano validi, a condizione di abbinarli al problema giusto e di non chiedere a uno solo di coprire ogni caso.

Da qui il filo prosegue in tre direzioni.

Chi vuole trasformare l'analisi dei problemi in un'abitudine dell'intera azienda trova nel miglioramento continuo il quadro in cui PDCA e Kaizen diventano cultura quotidiana.

Chi si accorge che il nodo non è il problema ma la decisione che lo segue può proseguire con la gestione delle priorità.

Chi preferisce partire dal disordine in cui i problemi si presentano davvero trova un punto di vista diverso nell'editoriale su come fare ordine nei problemi aziendali.

Chi vuole seguire gli approfondimenti sui singoli metodi e sulla matrice decisionale, man mano che escono, può iscriversi alla newsletter.

Un'azienda che ha imparato i tre gesti si riconosce da pochi segnali concreti.

Il titolare non è più la sola persona ad accorgersi che qualcosa non torna, perché i collaboratori hanno un posto dove scriverlo.

Le riunioni di analisi partono da un problema descritto in una frase misurabile, non da una soluzione già decisa.

Fra due proposte si sceglie con una tabella di criteri che chiunque può rileggere, e chi eseguirà la scelta l'ha vista prima che fosse approvata.

Se anche una parte delle micro e piccole imprese italiane riducesse la quota di problemi che tornano, il divario di produttività per addetto rispetto alla media europea [7] potrebbe accorciarsi di un tratto: senza svolte improvvise, con un metodo sobrio — trovare prima, scegliere con criteri, e solo allora risolvere.

Fonti e Riferimenti

[1] Imai, M., "Kaizen: The Key to Japan's Competitive Success", McGraw-Hill, 1986 (II ed. 2012).

[2] Ishikawa, K., "What is Total Quality Control? The Japanese Way", Prentice-Hall, 1985.

[3] Liker, J. K., "The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer", McGraw-Hill, 2004.

[4] Rother, M., "Toyota Kata: Managing People for Improvement, Adaptability, and Superior Results", McGraw-Hill, 2010.

[5] Sobek, D. K. e Smalley, A., "Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System", Productivity Press, 2008.

[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.

[7] ISTAT, "Rapporto sulla competitività dei settori produttivi — edizione 2024", ISTAT, 2024. Disponibile su: https://www.istat.it/

[8] ISO, "ISO 9001:2015 Quality management systems — Requirements", International Organization for Standardization, 2015. Disponibile su: https://www.iso.org/standard/62085.html

[9] Ford Motor Company, "Team Oriented Problem Solving (TOPS-8D) Manual", Ford Motor Company, 1987 (aggiornato 2018).

[10] ISTAT, "Censimento permanente delle imprese 2023: primi risultati", comunicato stampa, ISTAT, 14 novembre 2023 (dati riferiti al 2022; campione di circa 280.000 imprese con 3 o più addetti, universo di 1.021.618 unità). Disponibile su: https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/

[11] Treccani, "Problèma", Vocabolario on line, Istituto della Enciclopedia Italiana. Disponibile su: https://www.treccani.it/vocabolario/problema/