24/02/2016

Root Cause e Processo MIN

Root Cause” è un’espressione che se non la si è già incontrata, di certo non mancherà molto prima che entri a far parte del nostro quotidiano lavorativo ed è per questo che è importante cercare di fare chiarezza su cosa significhi veramente.

Sta diventando ormai noto che, spesso, la parte più visibile di un problema non è il punto su cui agire per risolverlo.

È necessario analizzare la catena di cause, percorrendo a ritroso la loro sequenza logica, per raggiungere ed identificare le cause radice, le uniche cause da rimuovere, che raramente coincidono con il problema vero e proprio.

 

Nella RCA (Root Cause Analysis) sono due le metodologie più seguite: il diagramma di Ishikawa (a lisca di pesce, o fishbone) e il metodo dei “cinque perché”, sviluppato in Toyota dal sig. Sakichi Toyoda, che viene schematizzato come le radici di un albero che si diramano e si allungano sotto terra diventando invisibili dalla superficie e che, nel farlo, prendono talvolta direzioni inattese oppure assumono lunghezze inimmaginabili.

Per diversi aspetti i due metodi addirittura coincidono; in entrambi gli approcci la maggiore difficoltà sta nell’identificare le poche vere root causes celate nella totalità di cause che vengono di volta in volta individuate ed analizzate.

Questa difficoltà è il motivo per cui gli errori più frequenti vengono commessi nelle fasi di problem solving in cui si ricercano le cause radice. Sbagliare in questa fase è molto pericoloso; con tutta probabilità si passerebbe all’azione e ci si metterebbe a lavorare spendendo tempo e risorse per eliminare cause intermedie che non risolvono il problema in quanto non sono le vere cause radice.

Queste ultime rimarrebbero irrisolte e continuerebbero a generare il problema.

Nonostante ciò esiste una regola molto semplice, valida indipendentemente dal tipo di problema, che permette di identificare sempre e correttamente le root causes: la regola del “Processo MIN” (Ivan Fantin, Applicare il Problem Solving. Metodo, Applicazioni, Root Causes, Contromisure, Poka Yoke, A3, Createspace, 2013).

La regola è molto semplice e deve essere utilizzata in maniera complementare all’analisi delle cause, sia essa svolta con il metodo dei “cinque perché”, oppure mediante il diagramma fishbone di Ishikawa, o con altro; sia chiaro che la regola del Processo MIN non è da utilizzarsi in sostituzione ad essi.

La regola dice che siamo in presenza di una root cause ogni volta che individuiamo una causa che coincide con un “Processo MIN“, ovvero un processo (M)ancante, (I)ncompleto oppure (N)on seguito.

Ad ogni root cause analysys deve corrispondere ad un Processo MIN, indipendentemente dal contesto o dal problema che si va ad analizzare. Se una causa non coincide con un processo MIN è necessario continuare nell’investigazione, indagando e percorrendo ulteriormente la catena causale, perché non abbiamo ancora raggiunto una causa radice; invece, se la causa identificata di volta in volta coincide con un processo MIN allora possiamo fermarci perché abbiamo trovato una vera root cause.

Per riassumere, la fase di ricerca del Processo MIN:

• non è alternativa né al metodo di Ishikawa, né al metodo dei “cinque perché” (che invece sono alternativi tra loro), né ad altri metodi di investigazione a carico delle cause.

• è un aiuto in più, potremmo dire che “è un test” a cui sottoporre ogni causa che viene identificata per individuare quali di esse rispondono alla caratteristica di essere una root cause.

C’è un motivo per cui la root cause corrisponde sempre con un processo e mai con una colpa da dare a qualcuno: dare la colpa del problema a qualcuno impedisce di individuare un metodo efficace affinché il problema cessi di esistere.

Saremmo portati a credere che addestrare il colpevole oppure sostituirlo con un individuo più competente, più attento e più responsabile possa essere la soluzione al problema, ma chiunque è soggetto a commettere errori e a distrarsi, indipendentemente dalla formazione ricevuta e da quanta attenzione voglia dedicare a ciò che fa.

Ivan Fantin – Lean Manager e autore di “Applicare il Problem Solving”

Per una versione più approfondita e completa di questo articolo, potete richiedete una copia del magazine “Approvvigionare” cliccando qui