True Causes
IT

Analisi delle cause radice

L’analisi delle cause radice (root cause analysis) è la disciplina di chiedersi perché qualcosa è andato storto finché la risposta non smette di spostarsi. Risolvi la radice e i sintomi sopra di essa se ne vanno con lei; risolvi un sintomo e ritorna. La gestione della qualità, la risposta agli incidenti informatici, la sicurezza dei pazienti e l’aviazione la richiedono tutte dopo un guasto. I metodi differiscono soprattutto in chi fa il ragionamento.

I metodi

Cinque perché
Chiedi «perché» del guasto, poi della risposta, cinque volte. Una persona o un piccolo team. Veloce ed economico, e trova una catena di cause — quella che chi chiede sospetta già. Buono per un singolo incidente con un singolo meccanismo; debole dove le cause interagiscono.
Diagramma a lisca di pesce (Ishikawa)
Cause ordinate per categorie — persone, processo, attrezzature, materiali, ambiente — disegnate come lische che partono da una spina dorsale. Un facilitatore lo compila con i suggerimenti di un gruppo. Ampio più che profondo: elenca i candidati ma non dice nulla su quali cause influiscano su quali.
Analisi dell’albero dei guasti
Albero logico dall’alto verso il basso, dal guasto attraverso porte AND/OR fino agli eventi di base. Rigoroso per i sistemi ingegnerizzati in cui i componenti e i loro modi di guasto sono noti. Lo costruisce un analista; richiede dati che il mondo sociale raramente ha.
Analisi di Pareto
Conta gli incidenti per categoria e risolvi le categorie che ne spiegano la maggior parte. Dice dove fa male, non che cosa lo causa — uno strumento di smistamento, non un cercatore di cause.
Dialogo Democratico Strutturato
Le persone che vivono il problema scrivono le cause candidate, le chiariscono, e poi giudicano — una coppia alla volta, con una soglia del 75% — se ciascuna causa influisce in modo significativo su ciascun’altra. Un algoritmo riunisce le risposte in una mappa dell’influenza (modellazione strutturale interpretativa), e le cause in fondo alla mappa sono le radici. Cinquant’anni di pratica, diverse centinaia di dialoghi documentati. È ciò che svolge questo sito.

Quando il gruppo batte l’analista

Decide una sola domanda. La causa è nota a qualcuno nella stanza? Se si è guastata una macchina, un ingegnere con i log troverà il perché più in fretta di quindici persone che votano. Se le consegne sono in ritardo, i pazienti aspettano, una scuola perde insegnanti o una città perde fiducia, le cause sono distribuite tra le persone coinvolte — il turno di notte ne conosce una, il dispatcher un’altra, il cliente una terza — e nessun analista le possiede tutte. Allora il metodo deve raccogliere le cause da tutti e lasciare che tutti giudichino i collegamenti, altrimenti trova solo ciò che l’analista credeva già.

Due risultati della ricerca spiegano perché nemmeno una semplice discussione di gruppo ci riesce. Le persone a cui si chiede di classificare le cause per importanza prima che i collegamenti tra loro siano esaminati le classificano male — l’effetto delle priorità erronee — e un gruppo a cui si chiede il proprio parere lo disperde così tanto che nulla ha la maggioranza — lo spreadthink. Il dialogo strutturato è costruito attorno a entrambi: nessuna classifica finché i collegamenti non sono giudicati, e collegamenti giudicati uno alla volta a maggioranza qualificata.

Che cosa produce una buona analisi delle cause radice

Il modello in sette fasi · Un esempio svolto con numeri reali · Come questo sito lo svolge per qualsiasi numero di gruppi