In molte aziende manifatturiere il configuratore c'è, ma la combinazione giusta per un cliente la sanno trovare due o tre tecnici.
Quando è così, portare l'AI su quel processo non vuol dire automatizzarlo. Vuol dire dare una forma interrogabile a quello che quei tecnici sanno, e farla correggere a loro finché ci si fida delle risposte.
Un caso raccontato con molti dettagli arriva da un produttore americano di componenti per robot industriali.
Sette milioni di combinazioni e una risposta giusta
ATI Industrial Automation, dal 2021 parte del gruppo americano Novanta, produce cambi utensile robotici: il giunto che permette a un robot di staccare una pinza e agganciarne un'altra. Per una sola linea di prodotto, secondo i conti fatti dall'azienda, le configurazioni possibili sono circa 7 milioni. Ognuna dipende dal robot, dal carico da spostare e da quello che deve passare attraverso il giunto.
In un episodio del podcast Manufacturing Matters uscito il 4 settembre 2026, Ajaiey Sharma, che guida la divisione robotica e automazione di Novanta, descrive com'era prima. Il cliente consulta cataloghi e note applicative, poi alla fine telefona. Comincia un avanti e indietro con gli ingegneri applicativi che, dal primo contatto alla configurazione finale, può durare giorni. Alla domanda su quanta di quella conoscenza stia nella testa delle persone, risponde: quasi tutta, distribuita fra ingegneri applicativi, progettisti e responsabili di prodotto.
Nello stesso podcast Juan Aparicio, amministratore delegato di ReshapeX, il fornitore che ha costruito il sistema, descrive il paradosso: l'ampiezza della gamma è il vantaggio di ATI ed è anche il problema. Trovare la configurazione giusta, dice, è come cercare un ago in una montagna di aghi.
Nel post su LinkedIn dell'11 settembre da cui siamo partiti, Sharma aggiunge un passaggio. Per anni ha pensato a quella complessità come a qualcosa da ridurre, con più documentazione e una gamma più snella. Oggi la considera il cuore del business, perché pochi concorrenti sanno sostenere milioni di combinazioni legittime. La domanda, a quel punto, diventa come rendere accessibile ai clienti quello che l'azienda sa, senza ridurre la gamma.
Automazione o conoscenza: la distinzione che decide il progetto
La frase che conta, nel post, è questa:
We knew this wasn't an automation project. Automation is for workflows you already understand. What we had was a data problem.
Sapevano che non era un progetto di automazione, perché l'automazione serve per i processi che si conoscono già. Il loro era un problema di dati: decenni di giudizio nella testa degli esperti, in una forma che nessuno poteva interrogare, cercare o consegnare a un nuovo assunto.
La distinzione ha conseguenze pratiche. Un problema di automazione parte da un processo che qualcuno sa descrivere per intero: chi lo avvia, che passaggi fa, dove si rompe. È il caso di cui abbiamo scritto parlando di come scegliere quale processo automatizzare: lì il lavoro è confrontare i processi e prendere lo strumento più semplice che basta.
Un problema di conoscenza parte da un processo che nessuno sa descrivere per intero, perché la regola non è scritta da nessuna parte. Per capire quale dei due hai davanti basta chiedere a chi fa quel lavoro come decide. Se la risposta è un elenco di passaggi, è automazione. Se la risposta è «dipende», seguita da un esempio che finisce con «questo lo sa Giorgio», è conoscenza.
Nel secondo caso non c'è ancora niente di scritto da automatizzare. Il lavoro è costruire quella struttura. Sharma, nel podcast, divide i compiti così: il codice l'ha scritto il fornitore, la parte dei dati l'ha fatta Novanta.
Perché cataloghi e manuali dati a un chatbot non bastano
La soluzione più immediata sarebbe raccogliere cataloghi, schede tecniche e manuali e metterli a disposizione di un modello linguistico. Aparicio spiega perché, su questo tipo di prodotto, non regge.
I codici articolo dei prodotti configurabili sono lunghi, spesso una ventina di caratteri, e ogni carattere significa qualcosa: cambiandone uno si ottiene un prodotto diverso. Per un modello linguistico due codici che differiscono di una lettera si somigliano moltissimo, ed è facile che li confonda. Un codice sbagliato è un pezzo sbagliato: parte, arriva dal cliente dopo settimane e non si monta sul suo robot.
Il sistema che hanno costruito, per come lo descrivono, divide il lavoro in due. Il modello linguistico capisce che cosa chiede il cliente. La scelta del codice la fa un motore costruito su un grafo della conoscenza (knowledge graph): una mappa di quali componenti sono compatibili con quali, e a quali condizioni, su cui il sistema ragiona per relazioni fra i pezzi e non per somiglianza fra le parole. Al modello, dice Aparicio, la soluzione non la lasciano scegliere.
Prima di arrivare al cliente, secondo il caso studio pubblicato da ReshapeX, ogni codice viene confrontato con l'elenco ufficiale dei codici Novanta. Le richieste che il sistema non riesce a validare passano a una persona, con tutta la conversazione.
Il grafo, però, qualcuno deve riempirlo e correggerlo.
Il lavoro vero: farlo correggere a chi lo sa
Secondo ReshapeX, ogni lunedì, per mesi, è uscita una nuova versione del sistema. I tecnici di Novanta la provavano in sessioni settimanali, il fornitore analizzava gli errori caso per caso e una riunione a settimana decideva le priorità.
Nel podcast, Aparicio e Sharma raccontano la regola delle prove: niente domande inventate. I tecnici inserivano le richieste arrivate davvero dai clienti, con le stesse parole, e giudicavano la risposta: buona o no, e perché. Ogni giudizio negativo portava a una di due correzioni: una risposta sbagliata da sistemare, o una conoscenza che il sistema non aveva e che andava aggiunta.
Tre passaggi del racconto valgono per qualunque azienda con un catalogo complesso.
Il catalogo ammette più di quello che funziona. Aparicio racconta che il grafo è partito dalle combinazioni possibili in teoria, e che le prove hanno tagliato interi rami: combinazioni valide sulla carta che nella pratica non funzionano. Nel caso studio c'è un esempio: un tecnico si accorge che la tabella di compatibilità sbaglia un abbinamento fra due componenti con un adattatore, e la correzione esce nella versione successiva.
Il tempo degli esperti l'ha dovuto trovare l'azienda. A un certo punto, racconta Sharma, il fornitore gli ha detto chiaramente che il sistema non poteva migliorare perché i suoi tecnici non lo provavano abbastanza. La risposta è stata chiedere al fornitore quante prove servivano e pretenderle dalla squadra. Il progetto era già negli obiettivi individuali, con un peso che toglieva spazio ad altro lavoro, e su proposta del fornitore le prove sono diventate una gara, con una classifica settimanale di chi provava di più.
La persona resta alla fine del giro. La configurazione proposta dal sistema passa ancora dall'ufficio applicazioni per un controllo finale. Cambia il lavoro di quell'ufficio: la configurazione non la costruisce più in giorni, la controlla. E dopo il lancio le prove continuano, in automatico ogni notte o ogni settimana, per accorgersi se il modello sottostante cambia comportamento.
Il primo prototipo, dice Sharma, era pronto due settimane dopo il primo incontro con il fornitore: non ancora preciso al 100%, ma bastava a far capire che la strada era quella. Fra quel prototipo e il lancio, nell'aprile 2026, ci sono i mesi di prove e correzioni descritti qui sopra.
Il fornitore ha portato la tecnologia; l'affidabilità l'hanno costruita gli esperti di Novanta, correggendo il sistema ogni settimana.
I numeri, e chi li racconta
Quello che si sa del progetto viene da quattro testi: il post di Sharma, il suo articolo sul sito di Novanta del 20 agosto 2026, il podcast, condotto da un dirigente di TECH B2B Marketing e registrato alla fiera Automate 2026, e il caso studio di ReshapeX, che vende la piattaforma su cui il sistema è costruito e chiude la pagina con l'invito a prenotare una dimostrazione. Sono tutte parti interessate. Una misura indipendente non l'abbiamo trovata.
Con questa premessa:
- Oltre 400 sessioni di clienti nelle prime due settimane dal lancio, il 14 aprile 2026, con il sistema attivo in sette lingue, secondo il caso studio.
- Il 100% di corrispondenza sui codici articolo. Per come la descrive ReshapeX, misura che ogni codice in uscita coincida con il riferimento ufficiale dei codici Novanta, contro cui viene controllato prima di arrivare al cliente. Dice che il codice esiste ed è scritto giusto. Non dice che sia la configurazione migliore per quell'applicazione: quel controllo, secondo Sharma, lo fa ancora l'ufficio applicazioni.
- Ricavi dalla prima settimana, scrive Sharma nel post. Il caso studio precisa: nella prima settimana una vendita chiusa tramite un distributore europeo e il primo ordine registrato attraverso il sistema; a fine seconda settimana decine di migliaia di dollari, sommando ricavi già prenotati e trattative qualificate, due cose diverse in un numero solo. La proiezione a sette cifre l'anno che segue vale, scrivono, se il ritmo si mantiene.
- I numeri di contorno cambiano da una fonte all'altra. Sharma parla di circa 7 milioni di configurazioni, il caso studio di 8,2 milioni. Per la precisione da raggiungere, nel podcast si parla soprattutto di 99,99%, nel caso studio di 99,9%. Per il ragionamento cambia poco; per capire con che grado di precisione leggere il resto, conta.
Il metodo è raccontato con abbastanza dettagli da poterlo riprendere. Sui risultati, per ora, c'è solo la parola di chi li ha ottenuti e di chi vende la piattaforma.
Alla scala di una PMI
Novanta è un gruppo quotato al Nasdaq, con un comitato interno che valuta i progetti di AI e un amministratore delegato che ha dato il mandato. Una PMI con un catalogo pieno di varianti non ha né l'uno né l'altro, ma ha lo stesso problema in scala più piccola quando il configuratore lo sanno usare in pochi e le telefonate difficili finiscono tutte agli stessi due tecnici.
Sharma, nel podcast, chiama rischio sistemico le persone con decenni di esperienza che escono dall'azienda. In una PMI quel rischio ha un nome e un cognome, e a volte una data di pensione vicina.
Dal caso Novanta si possono prendere quattro cose, ridotte alla nostra scala.
- Parti da un perimetro stretto. Una linea di prodotto, non il catalogo. Anche Novanta, racconta Sharma, ha ristretto il perimetro più volte pur di arrivare a qualcosa che funzionasse.
- Raccogli le domande vere prima di scrivere una riga di codice. Le email e le richieste dei clienti degli ultimi mesi, con le parole che hanno usato. Aparicio parla di cento o duecento casi reali, e di un paio d'ore di un esperto per giudicarli: sono il banco di prova, e diventano il modo per misurare se il sistema migliora.
- Metti in conto il tempo degli esperti, e toglilo da qualcos'altro. Finché le prove si facevano nei ritagli di tempo, anche a Novanta non se ne facevano abbastanza.
- Decidi prima che cosa torna a una persona. Le richieste che il sistema non sa validare, e il controllo finale prima dell'ordine. Un sistema che non ha un modo per dire «questo non lo so» finisce per inventare.
Prima di scegliere lo strumento
Il caso Novanta lo raccontano l'azienda e il suo fornitore, e i numeri vanno presi con quella misura. Tolti i numeri, resta una distinzione. Se il processo si sa descrivere, è un problema di automazione, e si sceglie lo strumento. Se la risposta sta nella testa di due persone, è un problema di conoscenza: prima si dà una struttura a quello che sanno, poi la si fa correggere a loro, settimana dopo settimana, finché ci si fida delle risposte quanto ci si fida di loro.
La tecnologia per farlo si compra. Il tempo dei tuoi esperti lo deve trovare l'azienda.
Nella tua azienda, quante richieste di configurazione passano ogni settimana dalla stessa persona?