Come estraggo le regole di business dal mio vecchio sistema con l'IA?

Le regole di business del vostro vecchio sistema si estraggono in 3 passi: l'IA legge il codice e scrive ogni regola come una frase chiara collegata alla riga da cui proviene; il responsabile del processo la rivede e la conferma o la corregge; e voi la confrontate con ciò che il sistema fa davvero su fatture reali. Uno strumento come AWS Transform per mainframe scrive le regole come requisiti verificabili, e nell'annuncio di Thought Machine con Amazon del 29 settembre 2026 l'estrazione passa per 4 fasi che si chiudono con un'approvazione umana. Non scrivete nuovo codice finché le regole non sono confermate.

Nella parte 3 avete ottenuto un inventario e una decisione provvisoria per ogni sistema. I sistemi che avete deciso di ricostruire o convertire sono quelli che hanno bisogno per primi di questo passo.

Perché le regole di business sono la cosa più preziosa del vostro vecchio sistema

Una regola di business è il modo in cui la vostra azienda calcola o decide qualcosa: come si calcola lo sconto di un cliente all'ingrosso, quando si aggiunge una penale di ritardo, chi approva un ordine d'acquisto sopra una certa soglia, come si arrotonda l'importo di una rata. Queste regole si sono accumulate in anni di modifiche, e molte non sono mai state scritte in alcun documento.

• Nel codice: condizioni e calcoli scritti anni fa da un programmatore su richiesta di un responsabile che ha poi lasciato l'azienda.
• Nel database: listini, tassi e soglie che qualcuno modifica a mano senza sapere cosa ne dipende.
• Nella testa delle persone: le eccezioni che il contabile gestisce a mano perché il sistema non lo fa.
• Nei fogli di calcolo: formule che colmano le lacune del sistema, come abbiamo spiegato in quale foglio è il sistema.

Se ricostruite il sistema senza queste regole, costruirete un sistema nuovo che calcola in modo diverso, e lo scoprirete solo quando un cliente contesterà una fattura. Sono le regole a dover migrare; il vecchio linguaggio di programmazione è solo il contenitore.

Come l'IA legge il codice e scrive le regole

Estrarre le regole era un lungo lavoro manuale: un programmatore leggeva il codice riga per riga e annotava ciò che capiva. Gli strumenti di oggi leggono tutto il codice, seguono da dove arriva ogni numero e dove va, e scrivono ciò che trovano in linguaggio chiaro. Un esempio: Amazon afferma nella pagina di AWS Transform per mainframe che il servizio estrae ogni regola di business dal codice sorgente e la collega alla sua origine, poi genera requisiti pronti per lo sviluppo che il vostro team può rivedere, ciascuno tracciabile fino al codice da cui proviene. È la descrizione che Amazon fa del proprio servizio, non un risultato garantito.

Il formato in cui si scrive una regola conta. Un formato noto è EARS, l'Easy Approach to Requirements Syntax, sviluppato da Alistair Mavin e dai suoi colleghi in Rolls-Royce e pubblicato per la prima volta nel 2009. L'idea è che ogni regola si scriva in un ordine fisso: lo stato, poi l'evento scatenante, poi ciò che il sistema deve fare. Ha 5 schemi di base; ecco alcuni esempi aziendali illustrativi:

Il valore di questo formato è che il responsabile del processo può leggerlo e giudicarlo senza saper programmare. Una frase per regola, e risponde sì, no o incompleta.

Un esempio dal settore bancario: l'intento di business, non la traduzione riga per riga

L'esempio recente più chiaro viene dalle banche, dove le regole su interessi, commissioni e rimborsi vivono da decenni in codice COBOL sui mainframe. Il COBOL è un vecchio linguaggio di programmazione che fa ancora funzionare molti sistemi di banche e assicurazioni. Nel suo annuncio del 29 settembre 2026, Thought Machine, un'azienda di tecnologia bancaria, ha dichiarato di lavorare con Amazon a un processo che non traduce il codice riga per riga, ma ne estrae il puro intento di business. Secondo l'annuncio, il processo prevede 4 fasi:

1. Estrazione: AWS Transform legge le applicazioni legacy ed estrae la logica di business in specifiche scritte in EARS.
2. Consolidamento: centinaia di varianti ridondanti dello stesso prodotto vengono unite in specifiche moderne e snelle.
3. Sintesi: agenti di IA generano i prodotti finanziari e i relativi test in Python.
4. Validazione: revisione umana in cui i team di ingegneria e di rischio della banca hanno un'esplicita autorità di approvazione.

Notate le due lezioni: il consolidamento mostra che un vecchio sistema porta con sé molte copie della stessa regola, e l'ultima fase è interamente umana. Sono affermazioni delle due aziende sul loro processo, e il loro esempio è una banca, ma il metodo vale per qualsiasi azienda: estrarre, unire i duplicati, poi costruire, senza approvare nulla prima della firma di chi decide.

Perché il responsabile del processo deve confermare ogni regola

L'IA legge ciò che il codice fa, non ciò che l'azienda vuole. È nello scarto tra le due cose che nascono gli errori di modernizzazione:

• Codice morto: può estrarre una regola da una parte inutilizzata da anni, facendola sembrare una regola viva.
• Un vecchio errore diventato abitudine: il sistema arrotonda un importo in modo sbagliato e il personale corregge a mano. La regola estratta si porterà dietro l'errore, a meno che qualcuno non dica che è un errore.
• Una regola fuori dal codice: l'eccezione che il contabile gestisce a mano non comparirà mai nell'estrazione.
• Regole in conflitto: due versioni del calcolo dello sconto in due punti diversi. Quale sia quella giusta è una decisione di business, non tecnica.

Assegnate quindi a ogni regola un responsabile di business che la firmi: il direttore commerciale per le regole sugli sconti, il direttore finanziario per penali e approvazioni. Le regole confermate diventano la base del capitolato dei requisiti del nuovo sistema, e abbiamo spiegato come scriverlo nella nostra guida ai requisiti software. Tenete presente che codice e database possono contenere dati di clienti o dipendenti, quindi qualsiasi strumento che li legga fuori dal Regno richiede la verifica vista nella parte 3, insieme alle indicazioni dell'Autorità saudita per i dati e l'intelligenza artificiale (SDAIA).

Il punto di vista di Origami

Quando modernizziamo un vecchio sistema, trattiamo le sue regole di business come la cosa più importante da trasferire, non il suo codice. Usiamo strumenti di IA per leggere il codice e scrivere le regole come frasi chiare a una velocità prima impossibile, ma nessuna regola è definitiva finché il responsabile del processo non l'ha letta e firmata.

Poi testiamo ogni regola confermata su dati reali del vecchio sistema prima di costruirci intorno quello nuovo, così che il nuovo sistema calcoli come l'azienda si aspetta e non come uno strumento ipotizza. Se volete vedere come lavoriamo, date un'occhiata ai nostri servizi.

L'esercizio della settimana: una regola, tre fatture

Non serve aspettare uno strumento per cominciare. Scegliete una regola che fa spesso discutere, come uno sconto o una penale di ritardo, e seguite questi passi:

1. Chiedete al responsabile del processo di scrivere la regola in una frase, nella forma: Quando..., il sistema deve...
2. Estraete dal sistema 3 fatture reali a cui è stata applicata la regola: una normale, una al limite e una con un'eccezione.
3. Calcolate a mano ogni fattura con la frase scritta e confrontate il risultato con ciò che ha prodotto il sistema.

Se tutte e tre coincidono, la regola è documentata. Se una differisce, avete trovato una regola nascosta o un vecchio errore, ed è esattamente ciò che dovete sapere prima di qualsiasi modernizzazione.

Nella prossima parte

Ora avete regole confermate per il vostro sistema. Arriva la grande decisione: spostare il sistema così com'è, convertirne il codice su una piattaforma moderna, ricostruirlo intorno alle regole estratte, oppure sostituirlo con un prodotto pronto e conservare solo i dati? Nella parte 5 confrontiamo queste strade in una tabella: quando si adatta ciascuna, cosa conserva, cosa rischia e chi deve essere coinvolto.

Fonti

• AWS Transform per mainframe: pagina ufficiale — estrazione delle regole di business collegate al codice originale, requisiti verificabili e test di equivalenza.
• Thought Machine e AWS: annuncio del 29 settembre 2026 — le quattro fasi: estrazione in EARS, consolidamento, sintesi e validazione umana.
• EARS: la guida ufficiale di Alistair Mavin — il formato, i suoi cinque schemi e la prima pubblicazione nel 2009.
• SDAIA: protezione dei dati personali.