Root Cause Analysis (RCA)

Root Cause Analysis è il processo di identificare la causa profonda di un problema, non solo i sintomi. È la differenza tra mettere un cerotto e curare la malattia.

"Se non chiedi 'perché' abbastanza volte, finirai per trattare i sintomi e i sintomi torneranno."

Sintomo vs Causa

Il problema più comune nel problem solving è fermarsi al sintomo:

Curare il sintomo = il problema torna. Curare la causa radice = il problema non torna.

Quando fare un'RCA

• Dopo un incidente (downtime, perdita dati, security breach)
• Dopo un fallimento di progetto o slittamento grave
• Per problemi ricorrenti ("succede sempre")
• Quando in retrospective emerge un tema sistemico
• Prima di un change importante (pre-mortem: simulare il fallimento)

I 3 strumenti classici

1. 5 Whys (Toyota)

Sviluppato da Sakichi Toyoda (fondatore Toyota) e parte centrale del Toyota Production System.

Il principio: chiedi "perché?" 5 volte (o quante servono) per arrivare alla causa radice.

Esempio classico (Toyota)

Problema: La macchina si è fermata.

1. Perché? Il fusibile è saltato per sovraccarico.
2. Perché c'è stato sovraccarico? Il cuscinetto non era ben lubrificato.
3. Perché non era ben lubrificato? La pompa di lubrificazione non funzionava bene.
4. Perché non funzionava bene? L'asse della pompa era usurato e vibrava.
5. Perché era usurato? Non c'era un filtro, e si è infilata della limatura.

Causa radice: assenza di un filtro nel sistema di lubrificazione. Azione: aggiungere il filtro (sintomo) + processo di manutenzione preventiva (sistemico).

Esempio PM

Problema: Il go-live è slittato di 5 settimane.

1. Perché? L'integrazione SdI non era pronta.
2. Perché non era pronta? Le API non funzionavano come ci aspettavamo.
3. Perché ci aspettavamo cose diverse? Non avevamo fatto uno spike tecnico in fase di stima.
4. Perché non lo abbiamo fatto? Sales aveva già promesso la data al cliente.
5. Perché Sales promette date senza spike? Nessun processo formale lega offerte → validazione tecnica.

Causa radice: assenza di un processo "tech review prima delle offerte". Azione: istituire una review obbligatoria con il Tech Lead per le offerte > €X.

Regole d'oro

• 5 è indicativo: a volte bastano 3, a volte servono 7
• Una sola catena alla volta: se a un certo punto ci sono due cause, sdoppia (vedi Ishikawa)
• Vai oltre le persone: "perché Marco ha sbagliato?" → fermati. Sistema o processo, non colpa individuale
• Verifica ad ogni step: la causa è davvero collegata? Lo sai con certezza o stai indovinando?
• Fermati alla causa azionabile: se arrivi a "il libero mercato esiste", sei andato troppo lontano

Anti-pattern

• ✕ 5 Whys come caccia alle streghe: si arriva a una persona e si ferma → soluzione sbagliata
• ✕ Risposte basate su opinioni: ogni "perché?" deve avere una prova, non una congettura
• ✕ Saltare passaggi logici: il 3° "perché" deve seguire dal 2°, non essere un salto
• ✕ Singola catena per problemi multi-causa: spesso un evento ha 2-3 cause radice indipendenti → usa Ishikawa

2. Ishikawa / Fishbone Diagram

Sviluppato da Kaoru Ishikawa negli anni '60 in Giappone (Kawasaki Heavy Industries). Anche detto "fishbone" per la sua forma a lisca di pesce.

Il principio: visualizzare molteplici cause organizzate per categorie.

Struttura

                  Categoria A          Categoria B
                    │                    │
              ── ──┘── ──            ── ──┘── ──
              │ │ │ │ │ │            │ │ │ │ │ │
    ──────────────────────────────────────────────────→ PROBLEMA
              │ │ │ │ │ │            │ │ │ │ │ │
              ── ──┐── ──            ── ──┐── ──
                    │                    │
                  Categoria C          Categoria D

Le 6 M classiche (manufacturing)

Categorie tradizionali per processi industriali:

1. Man (persone)
2. Machine (macchine, hardware)
3. Material (materie prime, input)
4. Method (processo, procedure)
5. Measurement (misurazione, controlli)
6. Mother Nature / Milieu (ambiente)

Versione per IT/Software (5 P)

1. People (skill, headcount, turnover)
2. Process (workflow, governance)
3. Product (architettura, qualità)
4. Platform (infra, strumenti)
5. Provider (fornitori esterni, dipendenze)

Versione per servizi (5 S)

1. Surroundings (ambiente di lavoro)
2. Suppliers (fornitori)
3. Systems (sistemi tecnici)
4. Skills (competenze)
5. Safety (sicurezza)

Esempio: "Lo sprint è slittato"

       PROCESSO                       PERSONE
       │                              │
       ├─ DoR non rispettata          ├─ 2 dev in ferie
       ├─ Stime ottimistiche          ├─ Tech Lead in interview
       ├─ Spike non fatto             └─ Onboarding nuovo dev
       │
   ────┼─────────────────────────────────→ Sprint slittato 2 settimane
       │
       ├─ API esterna instabile       ├─ Pressione Sales
       ├─ Strumento monitoring KO     └─ Cambio scope mid-sprint
       │                              │
       PIATTAFORMA                    GOVERNANCE

Spesso il problema non ha una causa radice singola ma una combinazione di concause. Ishikawa lo rende visibile.

Come si fa (workshop)

1. Scrivi il problema nella "testa" del pesce (lato destro)
2. Disegna le categorie principali come "spine" (4-6, scegli quelle adatte)
3. Brainstorming per ogni categoria — anche "perché?" cascading dentro ogni categoria
4. Voto / discussione sulle cause più probabili
5. Verifica con dati: quali cause possiamo confermare? quali sono solo intuizione?
6. Azioni sulle 2-3 cause radice prioritarie

3. Pareto Analysis (80/20)

Il principio di Pareto: circa l'80% degli effetti deriva dal 20% delle cause.

Come applicarlo

1. Lista di tutte le cause/problemi identificati
2. Misura la frequenza/impatto di ognuno
3. Ordina in modo decrescente
4. Trova il 20% che spiega l'80% dell'impatto totale
5. Concentra le azioni lì

Esempio

100 bug nell'ultimo trimestre. Distribuzione per categoria:

Insight: 3 aree spiegano l'82% dei bug. Investire qui ha ROI massimo.

Il processo completo di RCA

Un'RCA strutturata non è solo "fare i 5 Whys". È un processo:

Definizione del problema (step 1)

Pattern utile: descrivere il problema rispondendo a:

• What: cosa esattamente è successo?
• When: quando? (timeline precisa)
• Where: dove? (sistema, geografia, processo)
• Who: chi è stato coinvolto/impattato?
• Extent: quanto? (scala, severità, costo)
• NOT: cosa non è successo che avrebbe potuto (utile per restringere)

Esempio:

Il servizio di pagamento ha generato errori 500 per il 30% delle transazioni tra le 14:00 e le 15:30 del 12/03. Coinvolti ~2.800 utenti, ~€85k di transazioni mancate. Non si è verificato sul checkout guest (solo loggati)."

"Il sito si rompe a volte" → impossibile fare RCA.

RCA vs Pre-mortem

Come si fa un pre-mortem (15 min)

1. Imposta lo scenario: "È fra 6 mesi. Il progetto è fallito spettacolarmente. Cosa è andato storto?"
2. Brainstorming silenzioso (5 min): tutti scrivono le proprie ipotesi
3. Condivisione e clustering (5 min)
4. Azioni preventive (5 min): per le top 3-5 cause ipotetiche, cosa preveniamo già adesso?

→ Il pre-mortem aggira la pressione sociale al consenso: è più facile dire "potrebbe fallire perché X" prima che sostenere "stiamo sbagliando con X" durante l'esecuzione.

Bias cognitivi da evitare

L'RCA è inquinata da bias inconsci:

• Confirmation bias: cercare prove che confermano l'ipotesi preferita
• Hindsight bias ("lo sapevo!"): col senno di poi tutto sembra ovvio → giudizi ingiusti su chi era nel momento
• Fundamental attribution error: attribuire a persone (carattere) ciò che è del sistema (struttura)
• Survivorship bias: analizzare solo i fallimenti senza confrontare con i successi
• Recency bias: dare troppo peso all'ultimo evento

Antidoto: lavorare con i dati, non con le opinioni. Pretendere prove per ogni "perché".

Action item dell'RCA

Le azioni che emergono da un'RCA dovrebbero essere:

Regola: ogni RCA deve produrre almeno una azione strutturale, non solo "stiamo più attenti".

Anti-pattern

• ✕ Blame game: trasformare l'RCA in caccia al colpevole → distrugge sicurezza psicologica
• ✕ RCA superficiale: fermarsi al primo "perché" comodo
• ✕ Azioni vaghe: "miglioreremo la comunicazione" → nessuno saprà cosa fare
• ✕ Nessun owner: azione senza responsabile = azione mai fatta
• ✕ Nessuna verifica: si raccomanda ma non si controlla se l'azione ha funzionato
• ✕ Documento solo per compliance: scritto, archiviato, mai riletto
• ✕ RCA solo sui fallimenti: i near miss (problemi quasi accaduti) sono gratis da analizzare e preziosi

Buone pratiche

• Blameless: cultura no-blame, persone si fidano di essere oneste
• Cross-functional: invita gente che vede il problema da angolazioni diverse
• Documenta SubitoMnemo: timeline e fatti vanno raccolti quando sono freschi
• Time-box: meglio 2h di RCA strutturata che 2 settimane di analisi infinite
• Pubblica i risultati: la condivisione delle lessons fa imparare anche chi non c'era
• Verifica le azioni dopo 30/60/90 giorni: il problema è davvero risolto?
• Identifica i "near miss": cose che sono quasi andate male sono RCA gratuite

RCA fuori dal tech

I principi si applicano ovunque:

Quando NON serve un'RCA

• Problemi banali con causa ovvia ("il file non era salvato")
• Eventi una tantum non sistemici
• Quando mancano i dati (prima raccoglili)
• Quando la causa è chiaramente esterna e non controllabile

RCA leggera per problemi piccoli, RCA strutturata per incidenti gravi o pattern.

Collegamenti

• Retrospective — strumento periodico che spesso include mini-RCA
• Lessons Learned — output strutturato dell'RCA di fine progetto
• Risk Register — pre-mortem alimenta il register
• Monitoraggio e controllo — fase di rilevamento dei problemi
• Team Dynamics — la sicurezza psicologica abilita RCA oneste

Per approfondire

• The Toyota Way — Jeffrey Liker
• Quality Control Handbook — Juran (origini di Ishikawa)
• The Field Guide to Understanding Human Error — Sidney Dekker (RCA in safety-critical)
• Blameless Postmortems — pratica di Google SRE