Le fabbriche dimenticano ciò che hanno già risolto
L'analisi causa radice con l'AI in produzione ripaga solo se il caso chiuso resta reperibile. Ecco cosa lo decide.
Cosa cambia davvero l’analisi causa radice con l’AI in produzione
L’analisi causa radice con l’AI in produzione è l’uso di un modello per aiutare un ingegnere a passare da un difetto alla sua causa, e per tenere l’intero caso in un unico fascicolo. Non sceglie la causa. Accorcia le due parti più lente del lavoro, la descrizione del problema e la ricerca di ciò che è già stato provato, e decide se il caso concluso potrà essere riusato.
Quest’ultima parte è quella su cui nessuno basa l’acquisto. È anche l’unica il cui valore si accumula.
Una flotta impara. Uno stabilimento archivia.
Due settimane fa la guida autonoma supervisionata è stata approvata sulle strade slovene. È stato il sesto mercato dell’Unione europea ad autorizzarla.
Quel sistema non ci è arrivato cambiando nome, né perché un modello fosse più intelligente del precedente. Ci è arrivato perché la flotta rimanda indietro i dati. Ogni chilometro percorso diventa qualcosa che la versione successiva può leggere.
Ora mettetevi in uno stabilimento e guardate lo stesso difetto risolto per la terza volta.
L’ingegneria non è peggiore. Le persone non sono peggiori. La differenza è ciò che ciascuna parte può conservare.
Un sistema di guida scrive la propria esperienza in una forma che la versione successiva può usare. La qualità scrive la propria esperienza in un report. Il report viene archiviato, firmato e conservato. Il prossimo ingegnere che sbatte contro lo stesso muro di solito non sa che esiste, o non riesce a trovarlo. L’apprendimento si ferma con la persona che ha fatto il lavoro.
Il report è stato fatto per essere firmato
Aprite un qualsiasi archivio 8D e lo schema è lo stesso. I report sono completi. Sono anche illeggibili come dati.
La descrizione del problema è in prosa. Le evidenze stanno in un allegato. L’azione è una frase. Il nome del file è un numero e una data. Niente di tutto questo risponde alla domanda che un nuovo ingegnere fa davvero, che non è mai “fammi vedere il report 2024-118” ma sempre “è già successo qualcosa di simile su questa macchina?”.
Non è una mancanza di disciplina. Il modulo 8D è stato pensato per dimostrare a un cliente che un problema è stato gestito. Non è mai stato pensato per essere letto dal caso successivo.
Ecco lo stesso lavoro visto due volte.
| Un report archiviato | Un caso riutilizzabile | |
|---|---|---|
| Scritto per | il cliente e la firma | il prossimo ingegnere |
| Descrizione del problema | prosa, spesso meno di tre righe | strutturata, con ciò che il problema è e ciò che non è |
| Evidenze | allegati accanto al file | collegate alla causa che confermano o escludono |
| Si trova tramite | numero di report e data | sintomo, pezzo, macchina, fase del processo |
| Verifica | un campo data, spesso vuoto | un ciclo chiuso, efficace o no |
| Valore dopo la chiusura | la prova che è stato gestito | un input per il caso successivo |
La tabella è tutto l’argomento. Entrambe le colonne descrivono le stesse ore di lavoro delle stesse persone. Una delle due si può riusare.
Cosa abbiamo misurato
Tra gennaio e marzo 2026 abbiamo gestito in questo modo dieci reclami cliente con aziende manifatturiere slovene, misurati presso otto di esse. In quel campione, tutto ciò che è stato prodotto durante la soluzione è rimasto collegato al caso e ricercabile in seguito: la definizione del problema, le cause escluse, le evidenze e la verifica.
Fonte: campione pilota, 10 reclami, aziende manifatturiere slovene, da gennaio a marzo 2026, misurato presso 8 aziende.
È un campione piccolo e lo diciamo. Basta a mostrare il meccanismo, non a promettere un numero a uno stabilimento che non abbiamo mai visto.
Il portatile
Prima di tutto questo mi sono seduto davanti a un portatile che conteneva più di 20 anni di lavoro di un ingegnere. Se ne sarebbe andato una settimana dopo.
Ogni problema risolto e ogni prova fallita stavano in file che solo lui sapeva leggere. Nomi di cartelle che avevano senso per lui. Fogli di calcolo senza riga di intestazione. Foto con i nomi file della fotocamera.
Nessun altro in quell’edificio avrebbe potuto aprirli e sapere cosa fare dopo. L’azienda non aveva ancora perso quella conoscenza. Non l’aveva mai avuta.
Uno strumento che porta uno stabilimento alla causa più in fretta e si lascia dietro lo stesso mucchio di file ha spostato il problema, non l’ha risolto.
Cosa verificare lunedì
Tirate fuori l’ultimo caso che avete chiuso. Poi fate tre verifiche, in quest’ordine.
Uno. Chiedete a qualcuno che non ci ha lavorato di trovarlo, partendo dal sintomo e da nient’altro. Dategli cinque minuti.
Due. Leggete la D2, la descrizione del problema. Se è più corta di tre righe, il caso è stato chiuso su una congettura che per caso ha funzionato.
Tre. Trovate la data di verifica. Se il campo è vuoto e il report è chiuso, il ciclo non è mai stato chiuso.
Se il caso non supera nessuna delle tre, la prossima volta che quel difetto si presenterà costerà quanto la prima. È tutto il costo di una traccia che non si può leggere.
Altro su galileon.si
Fonti
- Slovenia clears Tesla’s FSD driver assistance, pubblicato il 7 September 2026. AOL, che riprende Reuters
- Tesla FSD (Supervised) approved in Slovenia, its sixth EU market, 7 September 2026. We Talk Tesla