In breve
Ho passato quattordici anni nella qualità, di cui diversi a fare controllo dimensionale nel settore idroelettrico, prima di scrivere la mia prima riga di codice seria. Oggi, da solo, ho progettato una suite coerente di software verticali per le officine meccaniche. Non è un'impresa da programmatore. È merito del quadro di regole.
L'IA mi ha permesso di andare veloce. Ma l'IA lasciata a se stessa produce il plausibile, non l'affidabile, e nella qualità il plausibile non passa l'audit. Ciò che ha reso solido il risultato è la disciplina imposta attorno a lei: regole scritte, limiti rigidi, una verifica a ogni passo. Ecco come, e soprattutto cosa rivela di ciò che una PMI può ormai permettersi.
Vengo dall'officina, non dall'informatica
Bisogna chiarirlo subito, perché cambia tutto il resto. Non sono uno sviluppatore che ha scoperto il manifatturiero. Sono un professionista della qualità che ha finito per scriversi i propri strumenti.
Per quattordici anni la mia quotidianità è stata fatta di quote, primi campioni, non conformità da documentare, rapporti di collaudo da consegnare al committente. Ho controllato pezzi in cui l'errore non si recupera. Ho vissuto il riesame della direzione, l'audit interno, la tracciabilità spezzata che si scopre tre mesi troppo tardi. Conosco il peso reale di una taratura dimenticata.
Questa esperienza è la base di tutto. Un software qualità progettato da qualcuno che non ha mai compilato a mano un rapporto di primo campione sarà sempre un software che somiglia a ciò di cui si ha bisogno, senza mai aderirvi davvero. I dettagli che fanno la differenza (l'ordine esatto della catena qualità, ciò che un auditor vuole vedere, ciò che fa perdere un'ora all'operatore) non si inventano. Prima si vivono.
Non sono uno sviluppatore che ha scoperto il manifatturiero. Sono un professionista della qualità che ha finito per scriversi i propri strumenti.
L'IA da sola non fa niente di affidabile
Molti titolari immaginano che oggi si « chieda all'IA » di costruire un software e che ne esca un'applicazione pronta all'uso. Non funziona così, e bisogna essere onesti su questo.
L'IA generativa è notevole nel produrre in fretta qualcosa che sembra corretto. È anche esattamente il suo pericolo. Non conosce la differenza tra « giusto » e « credibile ». Lasciata senza regole né struttura, un giorno inventa una struttura di dati, il giorno dopo ne propone un'altra, mescola due nozioni che devono restare separate e vi lascia con un assemblaggio che compila, che fa bella figura in demo e che crolla al primo caso reale.
Nella qualità questo tipo di fragilità è eliminatorio. Prendiamo la catena che ogni responsabile qualità conosce: una non conformità (§8.7) si collega a un processo; un'azione correttiva (§10.2) si collega a una non conformità; un'azione preventiva deriva da un'analisi dei rischi (§6.1). Questi legami non sono decorativi. Sono la logica stessa del sistema. Un'IA a cui si chiede « fammi un modulo di non conformità » senza un quadro di regole rigoroso finirà, prima o poi, per collegare un'azione correttiva a un rischio invece che a una non conformità. Sul momento nessuno se ne accorge. All'audit vi costa la certificazione.
È il cuore di tutto ciò che ho imparato costruendo Asterion: l'IA è utile solo se è tenuta a freno. Il software verticale è il quadro di regole. L'IA lavora dentro, non al suo posto.
La disciplina prima della velocità
In concreto, governare l'IA significa imporle le stesse regole che si imporrebbero a un dipendente junior molto veloce ma senza giudizio di mestiere. Non gli si lascia decidere l'architettura. Gli si danno istruzioni scritte, non negoziabili, e si verifica il suo lavoro a ogni passo.
Ho quindi scritto regole prima di scrivere codice. Regole semplici, rispettate, rilette a ogni intervento. Qualche esempio di ciò che governa ogni riga del sistema:
| Regola imposta | Cosa impedisce |
|---|---|
| Dividere ogni parte del software in pezzi piccoli e brevi, mai blocchi giganti | Il groviglio ingestibile in cui nessuno capisce più cosa succede, né come correggerlo |
| Nominare e verificare ogni dato senza mai tollerare approssimazioni | Gli errori silenziosi che superano la demo e fanno danni nel lavoro reale |
| Controllo automatico prima e dopo ogni modifica | Il fatto di riparare una cosa rompendone di nascosto un'altra senza accorgersene |
| Un dato operativo registrato una sola volta, mai ricopiato da un'applicazione all'altra | La doppia registrazione e le incoerenze tra moduli |
| Documentazione aggiornata insieme al software | La deriva tra ciò che il software fa e ciò che si crede faccia |
Queste regole non rendono il lavoro più veloce, a breve termine. Lo rendono più lento, volutamente. È il punto che voglio far passare ai titolari: il valore non sta nella velocità dell'IA, sta nel rigore di ciò che la circonda. Un'IA veloce in un quadro di regole disciplinato produce un software solido. Un'IA veloce senza regole né struttura produce un debito che si paga più tardi, spesso nel momento peggiore.
A ogni intervento si ripete lo stesso meccanismo: leggere e capire l'esistente prima di toccarlo, fare una modifica minima e mirata, verificare che nient'altro si sia mosso, riassumere ciò che è stato fatto. Non ha niente di glamour. È esattamente la disciplina che ci si aspetta da un buon sistema qualità: tracciabile, verificabile, senza zone d'ombra.
C'è un'obiezione legittima che un titolare si pone davanti a uno strumento costruito da una sola persona: « e se questa persona sparisce, che fine fa il mio software? ». È proprio a questo che serve tutto questo rigore. Un software i cui pezzi sono brevi, chiamati con nomi chiari, documentati man mano e governati da procedure scritte non è un oggetto misterioso chiuso in una sola testa. È leggibile, navigabile, e altri possono riprenderlo in mano. La stessa esigenza di tracciabilità che si impone a un fascicolo qualità (che chiunque possa ritrovare cosa, perché e come) si applica al software stesso. È ciò che fa vivere uno strumento oltre chi l'ha scritto: una struttura documentata che permette ad altri di prendere il testimone. Per un acquirente è una garanzia di durata, non una scommessa su un individuo.
Un ecosistema coerente, non un mucchio di strumenti
Il risultato di questa disciplina è una cosa che non si costruisce per caso: una suite di applicazioni che si parlano davvero.
Ogni applicazione copre una funzione reale dell'officina: il controllo dimensionale, la gestione della qualità, la metrologia, la pianificazione. L'importante è che condividano una sola identità, una sola fonte di verità per i dati anagrafici, un solo modo di pensare. Un ordine di lavoro registrato una volta circola da una funzione all'altra senza essere ridigitato. Una non conformità rilevata al controllo alimenta il sistema qualità. Uno strumento seguito in metrologia viene proposto al posto giusto durante il collaudo.
Questa coerenza è possibile solo perché un unico quadro di regole regge l'insieme. Le stesse regole di struttura, la stessa esigenza di tracciabilità, la stessa conformità. Per noi questo significa dati ospitati ed elaborati in Canada: una scelta d'architettura assunta fin dalla prima riga, non una correzione aggiunta dopo. La sovranità dei dati, per me, non è un argomento di paura. È una questione di controllo e di proprietà: i disegni dei vostri clienti, lo storico delle vostre non conformità sono i vostri beni. Devono restare sotto il vostro controllo, e questo si decide nell'architettura, presto.
Un insieme di strumenti improvvisati ciascuno per conto suo non avrebbe mai mantenuto questa coerenza. È la disciplina imposta a ogni mattone che permette all'insieme di formare un sistema, e non una pila.
80 % alla macchina, 20 % all'essere umano, e mai il contrario
Dove l'IA governata dà il meglio è nel lavoro ripetitivo. Estrarre le quote da un disegno, confrontare documenti con requisiti, preparare un fascicolo, segnalare una scadenza che si avvicina: sono compiti in cui la macchina, ben guidata, si fa carico del grosso dello sforzo. Prepara.
Ma non firma. Il rilascio di un prodotto (§8.6), la chiusura di un'azione correttiva, la decisione che impegna la responsabilità dell'azienda: tutto questo resta, al 100 %, nelle mani di un essere umano qualificato. Un software ben progettato non cerca di automatizzare il giudizio. Lo potenzia. Presenta l'informazione chiara, mette in evidenza ciò che manca o che non torna, propone, e lascia decidere la persona competente.
Questo confine non è un limite tecnico che un giorno verrà tolto. È un principio. La responsabilità non si automatizza. Un sistema che pretende il contrario mente al suo utente, e lo lascia solo il giorno dell'audit. L'IA che prepara bene e l'essere umano che decide: è la divisione giusta, ed è quella che il quadro di regole deve proteggere.
Cosa rivela per una PMI
Ecco la parte che dovrebbe interessare ogni titolare, al di là del mio percorso.
Solo qualche anno fa, progettare una suite software coerente per un mestiere preciso richiedeva una squadra, un budget, mesi, spesso anni. Era riservato ai grandi. Una PMI manifatturiera aveva solo due opzioni: pagare carissima una suite generica che avrebbe usato a metà, o vivere con i suoi file Excel e i suoi raccoglitori.
Ciò che la mia esperienza dimostra è che ora esiste una terza via. Una persona che conosce davvero il proprio mestiere, se sa governare l'IA invece di fidarsene ciecamente, può progettare in pochi mesi strumenti tagliati esattamente su misura per la propria realtà. L'IA non fa il lavoro al suo posto, ma riduce enormemente la distanza tra « sapere di cosa si ha bisogno » e « costruirlo ».
La competenza che conta non è più saper programmare. È sapere cosa costruire, e avere la disciplina di tenere l'IA sui binari mentre aiuta a costruirlo. In altre parole: la competenza di mestiere torna al primo posto. Chi conosce la quota, la non conformità, la taratura e il riesame della direzione ha ora i mezzi per trasformare questo sapere in uno strumento, senza diventare informatico.
Per una PMI la lezione è diretta. La domanda non è più « abbiamo i mezzi per un software su misura? ». Diventa: « conosciamo abbastanza precisamente il nostro mestiere per dire di cosa abbiamo davvero bisogno? ». E per un fornitore la domanda è: viene dal vostro mondo, o lo guarda da lontano?
In conclusione: il quadro di regole, più dello strumento
Se dovessi riassumere questo dietro le quinte in una frase, sarebbe questa: non è l'IA ad aver costruito questi software, è la disciplina attorno a lei. L'IA è stata un acceleratore potente. Il quadro (le regole, la verifica, l'esigenza di tracciabilità, il rifiuto di automatizzare il giudizio) è ciò che ha reso il risultato degno di un ambiente in cui l'errore si paga.
Questo apre domande che trovo più interessanti delle risposte. Se la competenza di mestiere diventa la risorsa rara e lo strumento diventa accessibile, come sarà un buon software qualità progettato da chi vive il mestiere invece che da chi lo descrive? Quante officine portano, nella testa dei loro elementi migliori, strumenti che chiedono solo di esistere? E fino a che punto ci si fida di una macchina che prepara in modo ammirevole, finché un essere umano mantiene il controllo su ciò che lo impegna?
Non ho tutte le risposte. Ma so una cosa, per averlo costruito: l'IA governata da un software verticale strutturato non sostituisce il professionista della qualità. Gli restituisce finalmente il posto che gli spetta.
I principi descritti in questo articolo sono quelli che hanno guidato lo sviluppo di Asterion Solutions, una suite di software verticali pensati per le PMI manifatturiere che vogliono strutturare la loro qualità senza moltiplicare le attività amministrative.