Le richieste di preventivo arrivavano via email, tutte diverse. Chi scriveva in tre righe, chi allegava un PDF con la distinta, chi elencava i codici articolo dentro il corpo del messaggio senza nemmeno andare a capo.
Qualcuno, ogni mattina, apriva quelle email una per una e ricopiava i dati nel gestionale.
Questo è il racconto di come un’azienda ha smesso di farlo, con i tempi e i passaggi reali. È un esempio costruito su un caso tipico del settore, non la cronaca di un cliente specifico.
Il contesto
PMI manifatturiera, una cinquantina di dipendenti, produzione su commessa. L’ufficio commerciale riceve fra le quindici e le trenta richieste di preventivo al giorno, quasi tutte via email.
Il lavoro di ricopiatura occupava circa due ore al giorno di una persona. Non due ore consecutive: quindici minuti qui, venti là, sempre in mezzo ad altro. Che è il motivo per cui nessuno le aveva mai contate.
Gli errori erano rari ma costosi. Un codice articolo trascritto male genera un preventivo sbagliato, che a volte si scopre in produzione.
Perché non bastava il gestionale
Il gestionale c’era, e funzionava. Il problema stava prima: fra l’email e il gestionale non esisteva nessun ponte, e il ponte era una persona.
Le soluzioni ovvie erano già state scartate. Un modulo web sul sito da far compilare ai clienti: proposto due volte, mai adottato, perché i clienti storici continuano a scrivere email e nessuno ha voglia di dire a un cliente da vent’anni come deve mandare le richieste. Un parser automatico delle email con regole fisse: provato, abbandonato, perché le email erano troppo diverse fra loro.
È esattamente il tipo di compito che sta in mezzo: troppo variabile per una regola, troppo ripetitivo per meritare una persona.
La soluzione, settimana per settimana
Settimana 1: guardare. Nessuna riga di codice. Si sono raccolte cento email di richiesta preventivo degli ultimi tre mesi e si è cercato cosa avessero in comune. Risultato: in tutte, senza eccezione, comparivano quattro informazioni, cioè cliente, articoli, quantità e data richiesta di consegna. Cambiava solo il modo in cui erano scritte.
Quel risultato è la specifica del progetto. Senza quella settimana, la specifica sarebbe stata “automatizzare i preventivi”, che non è una specifica.
Settimana 2: costruire il pezzo che interpreta. Una piccola applicazione con un campo dove incollare il testo dell’email e un pulsante. Dietro, un modello linguistico con l’istruzione di estrarre quelle quattro informazioni e restituirle in formato strutturato, dichiarando esplicitamente quando un dato non c’è invece di inventarlo.
Quest’ultima parte è quella che ha richiesto più tentativi. Un modello lasciato libero, davanti a un’email che non specifica la quantità, tende a metterci un numero plausibile. È il comportamento peggiore possibile, perché produce un dato sbagliato che sembra giusto. L’istruzione corretta è che un campo vuoto resta vuoto e viene segnalato.
Settimana 3: collegare e provare in parallelo. L’output è stato agganciato al gestionale, e per due settimane la persona ha continuato a fare il lavoro a mano confrontando il proprio risultato con quello dell’applicazione.
Non è tempo perso: è il modo in cui si scopre dove sbaglia prima di fidarsi. Nel confronto sono emersi due casi ricorrenti che l’applicazione gestiva male, entrambi legati ad allegati PDF con la distinta articoli, e si è deciso di lasciarli fuori dal perimetro e trattarli a mano.
Il risultato
Le due ore al giorno sono diventate una ventina di minuti, che servono a controllare quello che l’applicazione ha estratto e a gestire i casi con allegato.
Il dato che conta di più però non è il tempo. È che gli errori di trascrizione sono spariti, perché quando un dato manca l’applicazione lo dichiara invece di indovinarlo, e chi controlla lo vede subito.
Il perimetro è rimasto piccolo: l’applicazione non fa il preventivo, non calcola prezzi, non parla con il cliente. Legge un’email e riempie quattro campi.
Cosa ha funzionato, e perché
La settimana di osservazione prima di costruire. È la parte che tutti vorrebbero saltare ed è quella che ha reso il progetto fattibile in tre settimane invece che in tre mesi.
Il perimetro stretto. Ogni volta che qualcuno proponeva “già che ci siamo, potrebbe anche…”, la risposta era no. Le funzionalità aggiunte in corsa sono il modo standard in cui un progetto da tre settimane diventa un progetto da sei mesi.
Il parallelo prima del passaggio. Due settimane di doppio lavoro sembrano uno spreco. Sono l’unico modo per sapere se lo strumento regge, invece di sperarlo.
La regola sui dati mancanti. Un’applicazione che dice “non lo so” è utilizzabile. Un’applicazione che indovina è pericolosa, e il pericolo si scopre tardi.
Il criterio per capire se vale anche per te
Non guardare al settore. Guarda se esiste, nel tuo ufficio, un punto in cui una persona fa da traduttore fra due sistemi che non si parlano, leggendo qualcosa scritto in modo libero e riscrivendolo in modo strutturato.
Se esiste, misura quanto tempo occupa in una settimana vera, non a memoria. Quasi sempre è il doppio di quello che si stima.
Se vuoi capire prima se il processo è il tipo giusto, come capire se un processo aziendale è automatizzabile con l’AI mette in fila le domande da farsi. E se il dubbio è più a monte, cioè se convenga automatizzare o no, cos’è l’automazione aziendale e quando ha senso usarla in una piccola impresa parte da lì.
Hai un caso simile in azienda? La pagina Casi Excel raccoglie situazioni reali da raccontare, in forma anonima.
