La tecnica di 5 Whys è uno strumento ingannevole per l'analisi delle cause della radice (RCA), originariamente popolare da Sakichi Toyoda all'interno del sistema di produzione Toyota. La sua premessa è semplice: chiedendo "Perché?" ripetutamente - di solito cinque volte - si esercita da un sintomo a una causa fondamentale.

Origini ed Evoluzione del metodo 5 Perché

Il 5 Perché è stato sviluppato negli anni '30 da Sakichi Toyoda e successivamente integrato nel sistema di produzione Toyota (ora Lean Manufacturing) da Taiichi Ohno. L'esempio classico di Ohno: un robot di saldatura si ferma. Perché? — Il circuito sovraccarico ha fatto saltare un fusibile. Perché? — La lubrificazione è insufficiente.

Perché lo standard 5 Perché fallisce in sistemi complessi

Prima di personalizzare il metodo, è fondamentale capire i modi di guasto dell'approccio standard quando si tratta di sistemi di ingegneria complessi.

  • Causa di interazione multifunzionale: Un singolo guasto può derivare da due o più fattori indipendenti che si verificano simultaneamente (ad esempio, un evento di carico di picco con la mancata pompa di raffreddamento).
  • Causal catene che si susseguivano: Chiedendo "Perché?" può produrre risposte multiple ad ogni livello, richiedendo un albero difetto piuttosto che un elenco lineare.
  • Condizioni latenti e deriva sistemica:[ La causa principale può essere una condizione gradualmente degradante (ad esempio, l'erosione degli standard di manutenzione) piuttosto che un evento discreto.
  • L'uomo, il processo e le interazioni tecnologiche:[ I sistemi di ingegneria sono sociotecnici; incolpare un guasto del sensore ignora il fatto che il programma di manutenzione è stato ritardato a causa di tagli di bilancio.
  • Comportamento emergente:[] Il fallimento può essere un comportamento inaspettato che nasce dalla combinazione di sottosistemi funzionanti correttamente, non da nessun singolo guasto dei componenti.

Una sessione di 5 Perché non è stata data, spesso si ferma al primo difetto tecnico (ad esempio, "il cuscinetto fallito") senza indagare sui fattori di progettazione, operativi o di gestione che hanno permesso che si verificasse tale difetto.

Strategie di sartoria per sistemi di ingegneria complessi

Per rendere i 5 Perché efficaci in ambienti complessi, è necessario strutturare l'indagine, coinvolgere la giusta esperienza e integrare i dati.

1. Coinvolgere team multidisciplinari

Un guasto elettronico può avere cause di radice nella dissipazione del calore (meccanica), tempistica del firmware (software), e formazione dell’operatore (fattori umani). Assemblare un team che include esperti di dominio da ogni sottosistema rilevante, così come i rappresentanti di operazioni, manutenzione e sicurezza. Un facilitatore dovrebbe garantire che le domande "Perché?" vengano poste da più prospettive.

2. Combina con l'analisi dei dati e i registri

I moderni sistemi di ingegneria producono enormi quantità di telemetria, registri di eventi e dati dei sensori. Prima o durante ogni passo "Perché?", verificano le risposte ai dati. Esempio: Il team ipotizza che una valvola non sia riuscita a causa della corrosione.

3. Mappa il sistema con diagrammi di dipendenza

I sistemi complessi sono la rete di componenti, processi e attori umani. Prima di iniziare i 5 Perché, creare un modello di sistema semplificato, come un diagramma di blocco funzionale, un diagramma di loop causale, o un frammento di albero difettoso, che evidenzia le dipendenze. Questa mappa aiuta il team a decidere i confini fisici o logici per l'analisi. Ad esempio, se viene esaminato un blackout di rete, una mappa che mostra le interconnessioni tra le linee di trasmissione, i fatti e i punti di controllo.

4. Limitare lo Scopo e Prioritize Subsystems

Invece, definire un limite chiaro: "Analizzeremo l'evento termico di fuga all'interno del modulo batteria numero 4." Quindi applicare il sarto 5 Perché all'interno di quel sistema limitato. Dopo aver identificato le cause di root, è possibile espandere la portata per vedere se esistono condizioni simili altrove.

5. Iterate e convalidate con le prove empiriche

Dopo che il team raggiunge una causa principale, testarlo contro le prove del mondo reale. Ciò potrebbe significare eseguire una simulazione, eseguire una parziale strappi, o rivedere i record di manutenzione per i modelli simili. Se la causa principale non riesce a convalidare, il team deve iterare: rivisitare il "Perché?" a livello in cui la catena ha rotto, riframe la domanda e seguire un percorso causale diverso.

Esempio pratico: Power Outage in una griglia complessa

Considera un blackout in una rete elettrica metropolitana che ha durato 90 minuti e ha interessato 300.000 clienti.

  • Perché outage? — Una linea 230 kV inciampato.
  • Perché la linea è triplicata? — Sovraccarico a causa di un'onda.
  • Perché sovraccarico? — Due unità di generazione maggiore si erano inaspettatamente chiuse.
  • Perché la generazione si è spenta? — Una valvola di controllo chiusa erroneamente nella pianta A.
  • Perché la valvola è chiusa? — Un guanto software nel sistema di controllo distribuito (DCS).

Questa catena lineare suggerisce "fissare il glitch DCS" come soluzione, ma l'approccio su misura espande notevolmente l'analisi.

Analisi estesa su misura

Il team include un ingegnere del sistema di alimentazione, uno specialista del software DCS, un operatore di rete e un ingegnere di protezione, che prima creano un diagramma di dipendenza della regione interessata: notano che le due unità di generazione che non sono state fornite dallo stesso apporto di acqua di raffreddamento, che erano state parzialmente bloccate da detriti.

Livello 1: Perché è andata in onda la linea 230 kV?

Answer (dopo il controllo dei dati): Il relè protettivo della linea ha rilevato un sovraccarico e ha aperto il rompicapo. La telemetria mostra che la linea trasportava il 120% della sua valutazione estiva per 15 minuti. Ma perché era sovraccaricata?]]

Livello 2: Perché la linea è stata sovraccaricata?

Answer: Poiché due unità di generazione (Unit A at Plant A and Unit B at Plant B) sono interrotte in 5 minuti l'una dall'altra, causando un deficit di 400 MW che ha spostato il flusso sulla linea Perché unità A trip?] L'acqua di controllo è chiusa a causa di un guasto (Perché il cuscinetto di log-FLT).

Livello 3: Perché il guanto DCS dell'unità A non è stato patchato?

Answer:] La patch era prevista per il prossimo outage di manutenzione, che era stato ritardato a causa di vincoli di bilancio. Perché l'interruzione di manutenzione ritardata? Un'iniziativa di taglio dei costi aveva ridotto la frequenza di manutenzione preventiva Perché il team non riconosceva questo rischio?[

Livello 4: Perché la pompa di raffreddamento dell'unità B ha fallito?

Answer:] La girante della pompa è stata erosa a causa della cavitazione. La cavitazione è avvenuta perché la pressione di immissione dell'acqua è caduta quando i detriti hanno parzialmente bloccato gli schermi di immissione. Perché gli schermi di immissione non sono stati bloccati l'aggiornamento Un progetto di costruzione vicino ha rilasciato sedimenti nella sorgente dell'acqua; la barriera di immissione debrid

Livello 5: Perché entrambe le unità falliscono in modo indipendente in pochi minuti?

Answer:[] La causa immediata è una coincidenza, ma la causa principale è un fallimento sistematico della governance del rischio: la fonte di acqua di assunzione condivisa, la patch ritardata, l'aggiornamento della barriera differita, e il coordinamento di protezione insufficiente tutto ripercorre una mancanza di analisi olistica del rischio di sistema e una cultura dell'ottimizzazione dei costi che sovrascrive il rischio operativo.

Questa analisi su misura non rivela una, ma sei cause di radice interdipendente che spaziano dal design, dalla manutenzione, dalla gestione ambientale e dalla cultura organizzativa. Le azioni correttive devono affrontare tutte: patch il glitch DCS, installi una barriera di detriti secondari, crei un bordo di revisione del rischio per deferrali di manutenzione e aggiorni le impostazioni di coordinamento protettivo per gestire eventi di bassa probabilità .

Strumenti e Integrazione Complementari

Per i sistemi complessi, combinarli con i più robusti framework analitici. Il National Transportation Safety Board (NTSB)[] utilizza un metodo di indagine strutturato per incidenti che include alberi da evento, alberi da difetti e analisi della timeline. Analogamente, l’Agenzia Internazionale per l’Energia riporta l’affidabilità analiticazione della griglia[FFFFF]

Diagramma di pesce (Ishikawa) — Cause di categorizzazione

Prima di iniziare i 5 Perché, utilizzare uno schema a spina di pesce per brainstorming potenziali cause in sei categorie standard: Persone, Processo, Attrezzature, Materiali, Ambiente, Gestione. Questo impedisce al team di fissare presto su una singola categoria (come attrezzature) e assicura che le domande "Perché?" esplorano tutti i rami. L'osso di pesce può essere convertito in un multi-branch 5 Perché, approfondindo ogni osso.

Analisi dell'albero di default (FTA) — Decomposizione logica

FTA utilizza la logica booleana (AND/OR gates) per modellare come le combinazioni di guasti portano ad un evento top. I 5 Perché possono essere visti come un FTA semplificato con un'assunzione lineare e lineare (tutte le condizioni devono essere vere). In sistemi complessi, la logica reale spesso coinvolge O gate (qualsiasi delle varie cause può innescare il livello successivo).

Analisi dei fattori causali e degli eventi (ECFA)

Per ogni evento significativo, il team identifica la causa immediata (spesso una risposta "Perché?") e poi ripercorre le precondizioni e i fattori sottostanti. ECFA lavora bene per gli incidenti che si dispiegano nel tempo, come un attacco informatico su un sistema di controllo o una fuoriuscita ambientale.

Analisi dei barili

Nei sistemi critici per la sicurezza, una causa principale è spesso una barriera mancante o fallita. Una barriera è qualcosa che impedisce il danno fisico (ad esempio, firewall), operativo (ad esempio, checklist), o culturale (ad esempio, la cultura di report). Dopo aver applicato i 5 Perché su misura, rivedere ogni causa principale per determinare se una barriera specifica avrebbe dovuto interrompere la propagazione del fallimento.

Migliori Pratiche per l'attuazione

Per garantire il vostro sartoriale 5 Perchés offre risultati attuabili, seguire queste migliori pratiche:

  • Document the chain:[] Scrivi ogni domanda, la risposta e le prove di supporto.
  • Stop quando si trova un punto di controllo:[] L'obiettivo non è infinito perché.Smettere quando si arriva a una causa che può essere modificata con un cambiamento fattibile (design, procedura, politica).Se si arriva a "errore umano", continuare: chiedere che cosa nel sistema ha reso più probabile tale errore.
  • Avoid biasimo:[]] Concentrati sui fattori di sistema, non sugli individui. La colpa di un tecnico smette di analizzare. I 5 Perché dovrebbero sempre chiedere circa le condizioni, le pressioni e le risorse che influenzano il comportamento.
  • Utilizza un facilitatore:[] Le analisi del sistema complesso beneficiano di un facilitatore esterno che può sfidare le ipotesi e impedire al team di saltare alle conclusioni.
  • Validare con test sul campo:[ Quando possibile, testare fisicamente la causa radice ipoteizzata. Per il software, eseguire una simulazione mimicking le condizioni esatte. Per l'hardware, controllare il componente o impostare un esperimento di laboratorio.
  • Effetti di secondo ordine del documento:[] Una volta identificate le cause della radice, considerate come le azioni correttive potrebbero introdurre nuove modalità di fallimento.

Conclusioni

Per ulteriori informazioni, rivolgersi a: