Poka-yoke per la conoscenza: perché la vostra FMEA resta vuota

Anni fa un ingegnere si rifiutò di scrivere nella FMEA quello che sapeva.

Disse il perché ad alta voce, in riunione. Metterlo per iscritto avrebbe ridotto il suo valore in azienda.

La sua risposta era più onesta del modulo che avevo in mano.

L’incentivo che nessuno progetta

In quasi ogni stabilimento c’è una persona che viene chiamata quando una certa macchina si ferma. La sua conoscenza non sta in nessun documento. Tutti lo sanno e nessuno ci rimedia.

L’azienda lo premia perché sa ciò che gli altri non sanno. Poi gli chiede di scriverlo. Gli sta chiedendo di ridurre il motivo per cui viene chiamato.

Eliyahu Goldratt ha riassunto il meccanismo in una frase: ditemi come mi misurate e vi dirò come mi comporterò. Quell’ingegnere viene misurato su ciò che solo lui sa risolvere. Si comporta esattamente come viene misurato.

La risposta abituale è un promemoria, un format o una formazione. Tutte e tre presuppongono che il problema sia l’attenzione. Non lo è.

Cosa ha detto davvero Shingo

Shigeo Shingo tracciò una linea che la maggior parte degli uffici qualità confonde ancora. Separò l’errore dal difetto. Le persone commettono errori. Un errore diventa un difetto solo quando niente lo ferma nel mezzo.

La sua conclusione non fu chiedere alle persone di stare più attente. L’attenzione non è un controllo. Progettò il passo in modo che l’azione sbagliata non potesse essere completata: un’attrezzatura che accetta il pezzo in un solo verso, una maschera che non si chiude se manca una rondella.

Il senso del poka-yoke è eliminare la dipendenza dall’attenzione umana proprio nel momento in cui è più probabile che venga meno.

Leggete la stessa idea alla luce della vostra FMEA. Se il documento si riempie solo quando qualcuno se ne ricorda, si sente generoso e ha un’ora libera, il sistema dipende dall’attenzione. Non c’è alcun controllo.

Perché la FMEA in Excel muore due volte

Una FMEA in un foglio di calcolo fallisce in due punti distinti, e il secondo è il motivo per cui così tante sembrano piene di lavoro e non aiutano nessuno.

Fallisce nella raccolta. Scriverci è un atto a parte, dopo che il lavoro vero è finito. È in concorrenza con il reclamo successivo. Non ha una scadenza che qualcuno faccia rispettare. Così si riempie in modo disomogeneo, soprattutto da parte di chi ha meno da perdere.

Fallisce nel recupero. Anche le righe scritte sono difficili da raggiungere in seguito. L’ingegnere che ne ha bisogno sei mesi dopo non sa che il file esiste, non può cercare nelle sue dodici versioni su SharePoint e non sa quale fosse quella valida. Così la conoscenza è scritta in teoria e persa in pratica.

Questo secondo fallimento spiega perché “documentiamo già tutto” e “risolviamo lo stesso problema due volte l’anno” sono entrambi veri nello stesso stabilimento.

Cosa deve fare una salvaguardia per la conoscenza

Se il controllo non è l’attenzione, devono valere quattro condizioni. Nessuna riguarda il software.

La raccolta deve essere un sottoprodotto del lavoro. La conoscenza viene registrata perché il caso è stato chiuso, non perché qualcuno l’ha chiesta dopo. Se c’è un passo a parte, ci saranno eccezioni, e le eccezioni diventano la regola.

La registrazione deve portare con sé la sua fonte. Una causa senza il documento, il lotto o la misura che la sostengono è un’opinione ben impaginata. Il prossimo ingegnere deve poterla verificare, non doversi fidare.

Il recupero deve avvenire nel momento del bisogno. Non su richiesta, non dopo una ricerca. Quando viene descritto un problema simile, ciò che si è già imparato deve arrivare insieme.

Chi scrive non deve pagare per scrivere. È questa la condizione che decide se le altre tre funzioneranno mai. Se contribuire con la propria conoscenza costa status, il sistema verrà aggirato, per quanto buono sia.

Cosa produce

È quello che costruiamo in Galileon. Non un posto dove archiviare documenti, e non l’ennesimo modulo. Un sistema in cui ogni caso chiuso alimenta il successivo.

Cosa produce per l’ingegnere, misurato sul nostro campione pilota di 10 reclami cliente con aziende manifatturiere slovene, da gennaio a marzo 2026:

• Il passo delle azioni correttive passa da tre giorni di riunioni a circa trenta secondi per una prima proposta, perché le proposte vengono da azioni che hanno già funzionato su cause confermate.
• Il passo di descrizione del problema produce circa tre volte più suggerimenti utilizzabili di un format vuoto, perché parte da casi simili invece che da una pagina bianca.
• Tracciabilità completa dal reclamo cliente all’azione preventiva, così la domanda di audit “mostratemi come ci siete arrivati” ha una risposta che esiste già.

Cosa l’ingegnere non fa: riempire una base di conoscenza. La registrazione viene scritta perché il caso è stato chiuso.

Cosa resta all’ingegnere

Gli agenti raccoglieranno i dati come oggi li raccolgono le persone, e ce ne saranno molti più di adesso. L’ultimo passo appartiene ancora a una persona.

Il giudizio che non si sposta è il pensiero analitico e critico, e si vede in quattro decisioni:

• cosa non appartiene a questo problema
• cosa è rumore e cosa è segnale
• dove l’interpretazione è sbagliata
• quali dati vanno raccolti di nuovo, su un campione più ampio

Più dati ci sono, più vale saper decidere quali parlano davvero del problema.

La linea da tracciare

C’è una versione di tutto questo in cui ogni azienda si costruisce il proprio strumento. Oggi il codice costa poco, quindi si costruiscono comunque cose che andrebbero rifiutate, e il risultato è un prodotto con molte funzioni e nessuna cura dietro a nessuna di esse.

La domanda da porsi prima che cominci è quale parte sia davvero il vostro dominio e quale sia meglio lasciare a chi ci lavora ogni giorno, ha molti più dati e consegnerà qualcosa di meglio di un MVP interno.

La risposta spetta a voi. Vale la pena darla in modo deliberato, non per inerzia.

Altro su galileon.si

• Due anni per descrivere un solo difetto: cosa insegna il richiamo Toyota sulla definizione del problema - cosa succede a monte, quando il problema non viene mai descritto abbastanza bene perché l’analisi regga.
• Come funziona SolveR
• Sicurezza dei dati

Fonti

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Pagina dell’editore
• Eliyahu M. Goldratt, su misurazione e comportamento. Goldratt Consulting