Causal AI e Root Cause Analysis: risolvere i problemi nei processi industriali

In ogni stabilimento esiste un difetto che "torna sempre". Si regola un parametro, si sostituisce un componente, si richiama l'operatore alla procedura: per qualche settimana il problema sparisce, poi si ripresenta. Il motivo è quasi sempre lo stesso: si è corretto l'effetto, non la causa.

La root cause analysis è il metodo che serve proprio a questo: risalire dal sintomo osservato alla causa che lo genera, per eliminarlo in modo definitivo. In questo articolo vediamo come funziona, perché in reparto spesso si ferma a metà strada e come la Causal AI la rende più rapida, più affidabile e capace di gestire la complessità dei processi industriali di oggi.

Cos'è la root cause analysis e perché in fabbrica si ferma spesso ai sintomi

La root cause analysis (RCA), o analisi delle cause radice, è un insieme strutturato di metodi per individuare il fattore originario di un problema: quello che, se rimosso, impedisce al problema di ripresentarsi. La differenza rispetto a un intervento correttivo qualsiasi è l'obiettivo: non ripristinare la produzione, ma capire perché si è fermata o perché ha prodotto un pezzo non conforme.

Sulla carta è un processo lineare. Nella pratica di reparto incontra tre ostacoli ricorrenti:

• Pressione sui tempi. Quando una linea è ferma, la priorità è farla ripartire. L'analisi viene rimandata e spesso non viene mai completata, perché nel frattempo arriva l'emergenza successiva.
• Dati incompleti o dispersi. Parametri di processo, esiti dei controlli qualità, allarmi macchina e note di turno vivono in sistemi diversi, quando non su carta. Ricostruire cosa è successo nei minuti prima del difetto richiede ore.
• Cause multiple che interagiscono. Molti problemi non hanno una causa unica: nascono dalla combinazione di un lotto di materiale, una temperatura ambiente, un utensile usurato e un cambio formato. Un'analisi che cerca "la" causa rischia di fermarsi alla prima plausibile.

Il risultato è una RCA che individua un colpevole credibile, ma non necessariamente quello vero.

I metodi tradizionali e i loro limiti

I metodi classici di RCA restano strumenti validi: sono semplici, condivisi e coinvolgono chi conosce il processo. Il loro limite emerge quando le variabili diventano decine o centinaia e i dati arrivano in continuo dalle macchine.

5 perché

Il metodo dei 5 perché, nato nel Toyota Production System, consiste nel chiedersi "perché?" in sequenza, partendo dal problema, fino ad arrivare a una causa su cui si può agire. È rapido e non richiede strumenti.

Il limite è strutturale: segue un'unica catena causa-effetto. Se il problema ha più cause concorrenti, il metodo ne esplora una sola. Inoltre la qualità della risposta dipende dall'esperienza di chi conduce l'analisi: due team diversi possono arrivare a cause diverse partendo dallo stesso difetto.

Diagramma di Ishikawa

Il diagramma di Ishikawa, o diagramma a lisca di pesce, organizza le possibili cause in famiglie: tipicamente le 6M (Manodopera, Macchina, Metodo, Materiale, Misura, Mezzo/ambiente). Aiuta il team a non trascurare intere categorie di fattori.

Il suo limite è che elenca ipotesi, ma non le pesa. Non dice quale ramo conta di più, né come i fattori interagiscono tra loro. Per verificare le ipotesi servono comunque dati e analisi successive.

FMEA

La Failure Mode and Effects Analysis (FMEA) analizza in modo preventivo i possibili modi di guasto di un prodotto o processo, assegnando a ciascuno un indice di priorità basato su gravità, probabilità di accadimento e rilevabilità.

È uno strumento potente in fase di progettazione, ma è statico: fotografa ciò che gli esperti si aspettano possa andare storto in un determinato momento. Non si aggiorna da sola quando il processo cambia e fatica a intercettare modi di guasto non previsti, che sono spesso proprio quelli che generano i problemi ricorrenti.

Cosa cambia con la Causal AI nella root cause analysis

La Causal AI è l'insieme di tecniche di intelligenza artificiale che modellano le relazioni di causa-effetto tra le variabili di un processo, invece di limitarsi a rilevare quali variabili si muovono insieme. Abbiamo approfondito il concetto, e la differenza tra causalità e correlazione, nell'articolo sulla Causal AI applicata all'ottimizzazione della produzione. Qui ci concentriamo su cosa cambia, in concreto, nel processo di RCA.

Dalle ipotesi alle evidenze. Con i metodi tradizionali il team formula ipotesi e poi cerca di verificarle. La Causal AI parte dai dati storici e costruisce un grafo causale del processo: una mappa di quali variabili influenzano quali altre, e con che intensità. Le ipotesi degli esperti diventano verificabili in modo sistematico.

Più cause, pesate. Invece di una singola catena, l'analisi restituisce un insieme di cause candidate ordinate per contributo all'effetto osservato. Questo è decisivo quando il difetto nasce dalla combinazione di più fattori.

Domande "what-if". Un modello causale permette di stimare cosa succederebbe intervenendo su una variabile: abbassando una temperatura, cambiando un fornitore, anticipando una manutenzione. È la differenza tra sapere che due fenomeni sono legati e sapere quale leva muovere.

Tempi ridotti. La correlazione tra dati di processo, qualità ed eventi macchina, che a mano richiede giorni, viene eseguita in modo automatico. L'analisi può partire mentre il problema è ancora fresco, non settimane dopo.

Sistemi esperti e IA causale: differenze e complementarità

I sistemi esperti sono software che codificano la conoscenza di chi conosce il processo sotto forma di regole: "se la pressione supera X e la temperatura stampo è sotto Y, allora verifica la valvola Z". Sono stati tra le prime applicazioni dell'intelligenza artificiale in ambito industriale e funzionano bene per problemi noti e ben circoscritti.

L'IA causale segue la strada opposta: apprende le relazioni causa-effetto direttamente dai dati di produzione. Questo le consente di scoprire legami che nessuno aveva formalizzato, ma da sola rischia di proporre relazioni plausibili solo dal punto di vista statistico.

I due approcci non sono in competizione. I sistemi esperti portano nell'analisi il sapere di chi conosce il processo: vincoli fisici, sequenze impossibili, cause già note. L'IA causale usa questo sapere come punto di partenza, lo verifica sui dati e lo estende ai casi che le regole non coprono. Il risultato è una RCA più robusta di quella che ciascun approccio produrrebbe da solo.

Root cause analysis automatizzata: dati necessari e flusso di lavoro

Automatizzare la RCA non significa togliere l'esperto dal processo, ma dargli in pochi minuti il quadro che oggi richiede giorni di raccolta e incrocio dei dati. Il presupposto è disporre di dati affidabili, sincronizzati nel tempo e riferiti allo stesso contesto produttivo.

I dati necessari

• Dati di processo: parametri macchina e di linea (temperature, pressioni, velocità, assorbimenti, tempi ciclo), raccolti in continuo da una piattaforma di Industrial Internet of Things (IIoT) come Mirai4Machine.

• Dati di qualità: esiti dei controlli, misure, scarti e rilavorazioni, collegati al singolo lotto, ordine o pezzo.
• Eventi macchina: allarmi, fermi, microfermate, cambi formato e interventi di manutenzione, con il loro timestamp.
• Dati di contesto: ordine di produzione, articolo, lotto di materia prima, turno, operatore, condizioni ambientali. Una soluzione di schedulazione e raccolta avanzamenti come Mirai4Production fornisce buona parte di queste informazioni.

Quando i dati provengono da macchine e linee eterogenee, l'elaborazione on-edge, come quella orchestrata da Mirai4UniversalEdge, aiuta a normalizzarli e allinearli vicino alla sorgente, alla base della convergenza tra Operational Technology e Information Technology (OT/IT convergence).

Il flusso dall'anomalia alla causa

• Rilevazione dell'anomalia. Un indicatore esce dai limiti: cresce il tasso di scarto, aumentano le microfermate, una misura di qualità inizia a derivare.
• Contestualizzazione. Il sistema raccoglie automaticamente tutti i dati di processo, qualità, eventi e contesto relativi alla finestra temporale e alle risorse coinvolte.
• Analisi causale. Il modello confronta il periodo anomalo con il comportamento normale e individua le variabili che spiegano lo scostamento, ordinate per contributo.
• Validazione dell'esperto. Il tecnico di processo esamina le cause candidate, scarta quelle fisicamente implausibili e conferma le più probabili.
• Azione e verifica. Si interviene sulla causa confermata e si monitora l'indicatore per verificare che il problema non si ripresenti. L'esito alimenta il modello per le analisi successive.

Esempi: scarti, microfermate, derive di qualità

I tre scenari che seguono sono tipici di molti reparti produttivi e mostrano come cambia l'analisi quando le cause sono più d'una.

Scarti che aumentano senza un motivo apparente

Su una linea di stampaggio il tasso di scarto sale in alcuni turni e non in altri. L'ipotesi iniziale è l'operatore. L'analisi causale, incrociando parametri di processo, lotti di materiale e condizioni ambientali, mostra invece che lo scarto cresce quando un certo lotto di materia prima viene lavorato con temperature ambiente più basse, condizione frequente nel turno notturno. La causa non è il turno, ma la combinazione di due fattori che nessuna regola singola avrebbe isolato.

Microfermate ricorrenti

Le microfermate sono brevi, spesso non registrate e difficili da analizzare a mano, ma pesano in modo rilevante sull'Overall Equipment Effectiveness (OEE). Su una linea di confezionamento si ripetono più volte all'ora. Collegando gli eventi macchina ai cambi formato e alla velocità dei nastri a monte, il modello individua una relazione tra l'accumulo dei prodotti in ingresso e il blocco di una stazione specifica. Per misurare l'impatto prima e dopo l'intervento è utile partire da un corretto calcolo dell'OEE.

Derive di qualità

Una quota dimensionale si sposta lentamente verso il limite di tolleranza nel corso di alcune settimane, senza ancora generare scarti. L'analisi causale collega la deriva all'usura progressiva di un utensile combinata con un aumento della velocità di lavorazione introdotto per recuperare produttività. Intervenire su entrambi i fattori permette di evitare lo scarto prima che si manifesti: è il principio della predictive quality.

Robin e Robin Whispers: dall'analisi alla raccomandazione

Una RCA ha valore solo se si traduce in un'azione eseguita sullo shopfloor. È qui che entrano in gioco Robin e Robin Whispers, le soluzioni Miraitek che portano l'analisi fino all'operatore.

Robin è l'assistente virtuale di fabbrica che supporta l'operatore nelle attività quotidiane. Unisce la conoscenza contenuta nei manuali e nella documentazione delle macchine con i dati raccolti in tempo reale dalla piattaforma IIoT. L'operatore può chiedere a Robin, in linguaggio naturale, perché una macchina si è fermata o come risolvere un allarme, e ricevere indicazioni contestualizzate sulla macchina e sulla situazione specifica.

Robin Whispers porta questo supporto un passo avanti: invece di attendere una domanda, suggerisce in modo proattivo l'azione più indicata quando l'analisi individua una causa probabile. Il risultato della RCA diventa così una raccomandazione concreta, ad esempio verificare un componente, correggere un parametro o pianificare un intervento, consegnata a chi può metterla in pratica.

Insieme, i due strumenti rappresentano il layer agentico che chiude il ciclo tra dato, analisi causale e decisione operativa, mantenendo sempre la persona al centro della scelta.

Dalla causa all'azione

I problemi ricorrenti, gli scarti e i fermi non sono una fatalità: sono il segnale di cause che non sono ancora state individuate. La root cause analysis resta il metodo per trovarle, ma in processi con decine di variabili e dati in continuo i soli strumenti tradizionali non bastano più.

La Causal AI aggiunge ciò che mancava: la capacità di pesare più cause insieme, di verificare le ipotesi degli esperti sui dati e di stimare l'effetto di un intervento prima di farlo. Con Robin e Robin Whispers, il risultato dell'analisi arriva fino all'operatore sotto forma di indicazione concreta.

FAQ

Che differenza c'è tra root cause analysis e troubleshooting?

Il troubleshooting mira a ripristinare rapidamente il funzionamento di una macchina o di un processo: risolve il problema contingente. La root cause analysis interviene dopo, o in parallelo, per capire perché il problema si è verificato ed evitare che si ripresenti. Un buon troubleshooting rimette in marcia la linea; una buona RCA impedisce che si fermi di nuovo per lo stesso motivo.

Quali dati servono per una RCA con l'IA?

Servono quattro famiglie di dati, sincronizzate nel tempo: dati di processo (parametri macchina e di linea), dati di qualità (misure, scarti, rilavorazioni), eventi macchina (allarmi, fermi, manutenzioni) e dati di contesto (ordine, lotto, turno, condizioni ambientali). Non serve partire con dati perfetti: è più importante che siano collegati tra loro e riferiti alle stesse risorse e finestre temporali.

La Causal AI sostituisce l'esperto di processo?

No. La Causal AI accelera e rende più oggettiva l'analisi, ma la conoscenza dell'esperto resta indispensabile per impostare il modello, escludere relazioni fisicamente impossibili e validare le cause individuate. Il ruolo dell'esperto si sposta dalla raccolta e dall'incrocio manuale dei dati alla verifica e alla decisione.