Quattro clienti OEM, ognuno con il proprio formato di specifica tecnica, i propri piani di controllo, le proprie revisioni che arrivano via email senza preavviso. In produzione, l'operatore che deve sapere qual è la tolleranza aggiornata per un determinato accoppiamento interrompe il capo turno, che interrompe il responsabile qualità, che interrompe il processo. Il cliente è sotto NDA. Abbiamo costruito un sistema RAG che indicizza tutta la documentazione tecnica attiva, risponde a domande in linguaggio naturale e cita la revisione corrente con il paragrafo preciso. Il tempo di ricerca specifiche in produzione si è ridotto del 74%.
Fare il subfornitore per l'industria automotive significa lavorare con specifiche tecniche che cambiano. Non ogni anno: ogni mese. Talvolta ogni settimana. Una revisione del disegno del cliente, un aggiornamento al piano di controllo, una modifica alle specifiche dimensionali dopo una valutazione di processo condivisa: la documentazione tecnica è viva, cambia nel tempo, e in produzione bisogna sempre avere la versione corretta.
Per un subfornitore che lavora con quattro clienti OEM o tier-1 diversi, il problema è moltiplicato per quattro: ogni cliente ha il proprio sistema di emissione delle specifiche (chi manda email, chi usa un portale fornitori, chi usa un sistema EDI, chi ancora manda fax scannerizzati), il proprio formato per i disegni, il proprio schema di numerazione revisioni, e il proprio vocabolario tecnico.
Il cliente di questo progetto, una PMI metalmeccanica specializzata in lavorazioni di precisione con 80 dipendenti e quattro linee di lavorazione, si trovava in questa situazione. La documentazione tecnica era distribuita su:
In questo contesto, una domanda semplice come "qual è la rugosità superficiale richiesta sul foro passante del codice 4872-B nella revisione corrente?" richiedeva un percorso di ricerca non banale e non sempre risolvibile in tempi compatibili con il ritmo della produzione.
Abbiamo tracciato il problema per quattro settimane con un log strutturato, raccolto dai capi turno e dal responsabile qualità. Ogni interruzione documentale veniva registrata: chi ha chiesto cosa, quanto tempo ha richiesto la ricerca, chi è stato coinvolto, e se alla fine la risposta trovata era certa o incerta.
I dati emersi:
Quest'ultimo dato era il più critico. Non perché le produzioni fatte su specifica incerta producessero sempre pezzi difettosi: nella maggior parte dei casi, la specifica incerta coincideva con quella corretta. Ma nel 6% degli episodi di incertezza documentata, la specifica usata in produzione era stata successivamente identificata come non corrente.
Nei 18 mesi precedenti all'analisi, tre non conformità ricevute dai clienti erano state ricondotte a produzioni eseguite su specifiche non aggiornate. Ognuna aveva richiesto analisi 8D, azioni correttive documentate, e in un caso la riproduzione parziale del lotto. Il costo diretto delle tre non conformità era significativo; il costo reputazionale era difficile da quantificare.
Il brief progettuale è stato sintetizzato dal responsabile qualità in una frase che è diventata il criterio di valutazione del progetto: "Voglio che l'operatore in produzione possa fare una domanda tecnica e ricevere una risposta certa, con la fonte, in meno di 30 secondi, senza dover chiamare nessuno."
Tre requisiti espliciti in questa formulazione:
Risposta certa. Non "probabilmente", non "mi sembra". Una risposta basata sulla versione corrente della specifica, con indicazione della revisione.
Fonte verificabile. L'operatore deve poter sapere da dove viene la risposta e andare a verificare il contesto completo se necessario. Non si può produrre su una risposta di un sistema che non si può verificare.
Meno di 30 secondi. La produzione non si ferma. Se la risposta richiede più di 30 secondi, l'operatore interrompe la macchina o decide da sé, e nessuna delle due opzioni è accettabile.
Questa fase ha richiesto sei settimane e ha coinvolto il responsabile qualità, un tecnico di produzione senior e un referente commerciale per cliente. Non era una fase tecnica: era una fase di conoscenza.
L'inventario ha prodotto un quadro completo della documentazione tecnica esistente: 4.200 documenti attivi (disegni, piani di controllo, specifiche materiale, istruzioni di processo, schede controllo), distribuiti nelle fonti descritte. Per ogni documento, sono stati censiti: cliente di riferimento, codice prodotto associato, data di emissione, numero di revisione, formato (PDF, DWG, Excel, Word), e stato (attivo, sostituito da revisione successiva, obsoleto per fine produzione).
La fase più critica è stata la ricostruzione delle catene di revisione: per ogni codice prodotto, identificare qual è la versione corrente della specifica e quali versioni precedenti esistono ancora negli archivi. In diversi casi, questa ricostruzione ha rivelato situazioni problematiche: documenti a bordo macchina con revisione precedente a quella in portale fornitore, email con aggiornamenti mai recepiti nella cartella di rete, due versioni contemporaneamente presenti in cartelle diverse con numerazione indistinguibile.
L'output di questa fase non è stato un sistema informatico: è stato un archivio documentale pulito, con un solo documento per revisione, con la revisione corrente marcata esplicitamente, e con le revisioni precedenti archiviate separatamente e marcate come non operative. Questo archivio pulito è la precondizione necessaria per qualsiasi sistema di ricerca: un RAG che indicizza anche documentazione obsoleta risponde con informazioni sbagliate, che è peggio di non rispondere.
La documentazione tecnica metalmeccanica ha caratteristiche specifiche che richiedono un approccio RAG non standard.
Il problema dei disegni. La parte più critica di un disegno tecnico è spesso la tabella delle tolleranze, le note a margine, la nomenclatura delle superfici. Un disegno CAD convertito in PDF perde la struttura geometrica e diventa una immagine: il testo è estraibile ma le quote associate alle feature geometriche perdono il contesto spaziale.
Abbiamo sviluppato un pre-processing specifico per i disegni tecnici che estrae il testo strutturato (tabella revisioni, note generali, specifiche materiale, trattamenti superficiali, tolleranze geometriche dalla tabella) e lo organizza in metadati strutturati associati al documento. Le quote dimensionali associate a feature specifiche non sono interrogabili via testo libero, ma le specifiche generali e le note sì.
Il problema della terminologia cliente-specifica. Ogni cliente OEM usa il proprio vocabolario per gli stessi concetti: quello che un cliente chiama "rugosità Ra" un altro chiama "finitura superficiale", un terzo usa la notazione ISO e un quarto usa la notazione ASME. Il sistema deve rispondere correttamente indipendentemente dal vocabolario usato nella domanda.
Abbiamo costruito un dizionario di sinonimi specifico per il dominio della lavorazione meccanica di precisione, validato con il team tecnico, che viene applicato sia all'indicizzazione dei documenti che all'elaborazione delle query. Una domanda sulla "rugosità del piano di appoggio" recupera correttamente anche i documenti che parlano di "finitura superficiale della superficie di contatto" con notazione diversa.
Il chunking per sezione tecnica. I piani di controllo hanno una struttura tabellare: caratteristica da controllare, metodo di misura, frequenza, valore di specifica, valore di allarme, valore di blocco. Il chunking standard per lunghezza di testo spezza questa struttura. Abbiamo sviluppato un chunking che mantiene integra ogni riga della tabella, con tutti i suoi campi, come unità atomica di retrieval.
Il problema più delicato dell'intera architettura è la gestione delle revisioni: garantire che il sistema risponda sempre sulla base della versione corrente, e che il cambio di versione sia riflesso immediatamente nel sistema.
Il flusso di aggiornamento è strutturato su tre livelli:
Aggiornamento automatico dai portali. Per i due clienti con portale fornitore, il sistema si connette via API e controlla settimanalmente la presenza di nuove revisioni. Quando trova una revisione nuova, avvia automaticamente il processo di aggiornamento: indicizza il nuovo documento, marca la revisione precedente come non corrente, e notifica il responsabile qualità.
Aggiornamento via email classificata. Per i due clienti che inviano aggiornamenti via email, un sistema di classificazione delle email identifica automaticamente gli allegati tecnici e li propone per l'indicizzazione. Il responsabile qualità riceve una notifica con l'allegato identificato e conferma l'aggiornamento con un clic. Non è automazione completa, ma riduce il processo da "cercare, aprire, copiare, archiviare" a "clicca per confermare".
Aggiornamento manuale con validazione. Per i documenti che richiedono elaborazione umana (disegni con modifiche significative, nuovi codici prodotto, specifiche che aggiornano procedure operative), il processo rimane manuale ma strutturato: un responsabile designato carica il nuovo documento, lo classifica nel sistema, marca il documento precedente come sostituito.
Il sistema non ha mai due revisioni attive per lo stesso codice prodotto. Se viene caricato un documento con stesso codice e numero di revisione superiore, la revisione precedente viene automaticamente marcata come non corrente e rimossa dall'indice operativo.
L'interfaccia in produzione è stata progettata con un vincolo esplicito: deve funzionare con i guanti. Questo ha implicazioni concrete su tutto: dimensione dei target touch, assenza di campo di testo libero principale (che richiede tastiera), presenza di suggerimenti predefiniti per le query più comuni.
Il touchscreen installato a bordo macchina mostra:
Ricerca per codice prodotto. L'operatore scansiona il codice a barre sul lotto in lavorazione. Il sistema carica automaticamente il profilo documentale del prodotto: disegno corrente, piano di controllo, specifiche materiale, note di processo.
Ricerca per domanda. Una serie di domande predefinite coprono le 15 richieste più frequenti emerse dal log delle interruzioni documentali: "Qual è la rugosità richiesta?", "Che tolleranza dimensionale ha il foro?", "Qual è il piano di controllo in linea?", "Qual è il materiale specificato?". L'operatore seleziona la domanda e ottiene la risposta con la fonte.
Ricerca libera. Per le domande non coperte dai predefined, un campo di testo libero con supporto vocale (il capannone è rumoroso, ma la voce funziona meglio dei guanti per il testo libero). La risposta include sempre il riferimento al documento, il numero di revisione, e la sezione specifica da cui è stata estratta.
Ogni risposta è accompagnata da un link che apre il documento originale a schermo intero, per chi vuole leggere il contesto completo. Questo è critico per il requisito di "fonte verificabile": l'operatore non deve fidarsi ciecamente del sistema, può sempre andare alla fonte.
I dati raccolti sugli otto mesi successivi al go-live, confrontati con il periodo baseline analizzato nella fase iniziale:
Tempo di ricerca specifiche in produzione: riduzione media del 74%. Le interruzioni documentali che richiedevano 18 minuti ne richiedono oggi in media 4,7. Il 68% delle query viene risolto in meno di 30 secondi (il target del brief).
Frequenza delle escalation al responsabile qualità per motivi documentali: ridotta dell'89%. Il responsabile qualità ha recuperato circa 2 ore al giorno precedentemente dedicate a rispondere a domande di ricerca documentale.
Non conformità da specifica sbagliata: zero negli otto mesi di operatività. Questo non è un dato statisticamente definitivo su un orizzonte così breve, ma nei 18 mesi precedenti erano state tre.
Utilizzo del sistema: 91% delle ricerche documentali in produzione passa dal sistema. Il 9% residuo riguarda principalmente i disegni CAD nativi (che il sistema non apre: rimanda al software CAD per le domande geometriche complesse).
Adozione da parte degli operatori: nella survey interna a tre mesi dal go-live, il 94% degli operatori ha giudicato il sistema "utile" o "molto utile". Il commento più frequente nei campi aperti: "finalmente non devo aspettare che arrivi il capo turno per una domanda stupida".
Un sistema di ricerca tecnica che non viene mantenuto degrada con precisione prevedibile: i documenti non aggiornati portano a risposte sbagliate, la fiducia nel sistema cala, gli operatori tornano alle vecchie abitudini.
Il ciclo di manutenzione definito con il cliente:
Questo ciclo richiede circa 3 ore settimanali di lavoro di manutenzione, assegnate a una figura specifica con responsabilità formale sul sistema.
Due sviluppi in pianificazione:
Integrazione con il sistema PPAP. Il cliente tier-1 principale richiede documentazione PPAP aggiornata ad ogni modifica di specifica. Attualmente questo processo è manuale e laborioso. Un sistema che rileva automaticamente le modifiche alle specifiche e avvia il flusso di aggiornamento PPAP ridurrebbe significativamente il lavoro burocratico associato alle revisioni.
Alert proattivo per scadenze documentali. Alcune specifiche hanno date di validità o prevedono revisioni pianificate a scadenze note. Un sistema di alert che notifica il responsabile qualità 30 giorni prima di una scadenza documentale permetterebbe di gestire la transizione in modo pianificato invece di scoprire la scadenza quando il portale cliente ha già aggiornato la versione.