Portare l'AI su ERP e sistemi legacy senza sostituirli

Quando un'azienda comincia a pensare all'AI nelle proprie operazioni, la domanda sull'ERP arriva presto. Il nostro ERP è stato personalizzato anni fa; il sistema dei trasporti è ancora più vecchio. L'AI significa sostituirli?

Di solito no. L'ERP custodisce la contabilità, le anagrafiche e anni di regole su cui contano i revisori. Sostituirlo per aggiungere l'AI metterebbe a rischio tutto questo, per un vantaggio che non lo richiede. Conviene invece lasciare l'ERP al comando e costruirgli accanto uno strato dedicato. Lo stesso vale per CRM, sistemi di magazzino e sistemi di gestione dei trasporti.

L'ERP resta il sistema di riferimento

Il sistema di riferimento è il luogo in cui vive la versione ufficiale di un fatto aziendale: questa fattura è stata registrata, questo ordine esiste, questo fornitore ha queste condizioni di pagamento. L'AI non dovrebbe diventare un secondo sistema di riferimento, e non dovrebbe mai scrivere direttamente nel database dell'ERP, aggirando le regole che l'ERP applica.

In pratica, l'AI lavora su documenti e messaggi prima che entrino nell'ERP — li legge, li classifica, ne estrae i dati, li abbina — e consegna una proposta. Ciò che entra nell'ERP lo decidono le regole e, dove serve, una persona.

L'AI propone, le regole decidono

La divisione dei compiti è semplice da enunciare. Il modello fa ciò che le regole non sanno fare: leggere una fattura con un'impaginazione mai vista, capire un'email che mescola due ordini e una correzione, trovare la colonna giusta in un foglio di calcolo disegnato da un cliente. Le regole fanno ciò che il modello non dovrebbe fare: decidere se una partita IVA è valida, se un totale torna, se un fornitore esiste, se una registrazione è ammessa.

La separazione ha un vantaggio pratico. Quando qualcosa va storto, si vede se il modello ha letto male il documento o se mancava una regola. Entrambe le cose si possono correggere; mescolate, nessuna delle due.

Lo strato di integrazione

Tra l'AI e l'ERP c'è uno strato di integrazione. È ingegneria ordinaria, e decide se l'intero sistema merita fiducia.

API e middleware

Dove l'ERP offre servizi, lo strato di integrazione li chiama con gli stessi controlli che applicherebbe un'interfaccia utente. Dove non li offre, usa ciò che l'ERP già legge: tabelle di importazione, file, attività pianificate. In entrambi i casi, la validazione propria dell'ERP resta in gioco.

Code di messaggi

Una coda di messaggi come RabbitMQ o Azure Service Bus separa il passaggio di AI dall'ERP. Se l'ERP è fermo per manutenzione, il lavoro aspetta in coda invece di fallire. Se arrivano mille documenti insieme, vengono elaborati al ritmo che l'ERP riesce a sostenere. I nuovi tentativi partono dalla coda, con un limite; un messaggio che continua a fallire viene messo da parte per una persona, invece di bloccare tutto il resto.

Tabelle di appoggio

Molti ERP, e la maggior parte dei sistemi legacy, possono importare da tabelle di appoggio: un'area in cui i dati vengono scritti, verificati e poi prelevati dalla procedura di importazione del sistema stesso. Le tabelle di appoggio offrono un punto preciso in cui ispezionare un record prima che diventi ufficiale, e lasciano alle regole dell'ERP l'ultimo passaggio.

Importazioni idempotenti

Ogni importazione deve poter essere ripetuta senza rischi. Ogni documento riceve un identificativo stabile, e l'integrazione lo verifica prima di scrivere, così un nuovo tentativo dopo un'interruzione non registra due volte la stessa fattura. L'idempotenza rende possibili i tentativi automatici, e i tentativi automatici permettono a un flusso di lavorare di notte senza che nessuno lo sorvegli.

Osservabilità

Ogni messaggio dovrebbe essere tracciabile dall'email o dal file fino al record nell'ERP: quando è arrivato, cosa ha estratto il modello, quali regole sono state applicate, cosa è stato scritto e cosa ha risposto l'ERP. Con il tracciamento distribuito, per esempio OpenTelemetry, un caso fallito si trova direttamente, invece di doverlo ricostruire da log sparsi.

La corrispondenza con le anagrafiche

La parte meno appariscente del lavoro è spesso la più grande. Una fattura riporta “Acme Logistica S.p.A.”; l'ERP conosce quel fornitore con un codice. Un'email parla del “magazzino di Milano”; il sistema dei trasporti ha bisogno di un identificativo di località. La corrispondenza tra ciò che dicono i documenti e ciò che conoscono i sistemi è ciò che trasforma un testo estratto in qualcosa che l'ERP può registrare.

Anche qui l'AI aiuta, perché può suggerire l'abbinamento più probabile. Ma la corrispondenza va conservata, verificata e riutilizzata, non indovinata ogni volta da capo. Con il tempo, una tabella di corrispondenze ben tenuta diventa un patrimonio che sopravvive al progetto. Costruirla serve anche a mettere ordine nelle anagrafiche: ogni mancata corrispondenza che emerge è un dato che da qualche parte non era coerente.

Parlare la lingua del sistema legacy

I sistemi legacy hanno spesso una sola porta d'ingresso: un formato di importazione che accettano da anni. La mossa giusta è generare esattamente quel formato — ogni campo, ogni codice, ogni particolarità — e validarlo prima della consegna, invece di chiedere al vecchio sistema di cambiare.

In un pilota per un gruppo europeo di trasporti e logistica, l'AI trasforma le email dei clienti in ordini di trasporto. Gli ordini sono validati secondo il principio del tutto o niente e convertiti nell'XML che il sistema di gestione dei trasporti del gruppo importa. Il sistema dei trasporti riceve il formato che ha sempre ricevuto. Leggi il caso studio.

Due esempi dal nostro lavoro

Per una compagnia di crociere di lusso, i dati finanziari delle prenotazioni sono inviati automaticamente a Microsoft Dynamics NAV, e non si ribattono più a mano. NAV resta il sistema di riferimento; la piattaforma prepara, verifica e consegna. Quel flusso non usa l'AI, ma è lo schema di cui l'AI ha bisogno: una proposta preparata fuori dall'ERP, consegnata attraverso un'interfaccia che l'ERP controlla. Leggi il caso studio.

Per uno spedizioniere internazionale, un agente di AI legge le fatture passive in PDF. Le fatture vengono poi ricondotte alle anagrafiche, approvate e importate nel gestionale, e abbinate alle pratiche di spedizione attraverso le API del sistema con cui lo spedizioniere gestisce le spedizioni. Il modello propone; corrispondenze, approvazione e importazione seguono regole e persone. Leggi il caso studio.

Tre errori da evitare

• Scrivere direttamente nel database dell'ERP. Sembra più rapido, e aggira tutte le regole che l'ERP applica. Gli errori che lascia passare tendono a emergere più tardi, in contabilità.
• Lasciare al modello la decisione su cosa è valido. Un modello a cui si chiede se una fattura è corretta risponderà; questo non trasforma la risposta in un controllo. La validazione spetta a regole che danno sempre lo stesso risultato.
• Lasciare l'integrazione per ultima. Quando l'AI funziona prima che qualcosa sia collegato, il progetto sembra quasi finito. Non lo è: integrazione, corrispondenze ed eccezioni sono di solito la parte più grande del lavoro.

Una sequenza che funziona

1. Scegliere un flusso documentale con un responsabile chiaro e un costo chiaro.
2. Per ogni campo, individuare il sistema di riferimento e l'interfaccia che offre.
3. Costruire prima lo strato di integrazione, con importazioni idempotenti e tracciamento, e provarlo con dati inseriti a mano.
4. Aggiungere davanti il passaggio di AI, con regole di validazione e una schermata di revisione per le eccezioni.
5. Farlo lavorare accanto al processo attuale, confrontare i risultati, poi passare al nuovo sistema.

Costruire prima l'integrazione può sembrare un controsenso. È la parte che rende utile il passaggio di AI, ed è anche quella che resterà quando il modello cambierà.

È il lavoro che facciamo nell'integrazione dei sistemi e nell'AI per le imprese.