Modernizzare un gestionale AS/400 (IBM i) senza riscriverlo

Molte aziende italiane mandano avanti produzione, magazzino, ordini e fatturazione su un gestionale che gira da vent'anni o più su un sistema AS/400. Oggi quella piattaforma si chiama IBM i (è passata da AS/400 a iSeries, System i e infine IBM i), ma il nome che quasi tutti usano è ancora il primo. Davanti a un sistema così datato la reazione istintiva è pensare che vada buttato e rifatto. Quasi sempre è la conclusione sbagliata. Il problema raramente è la macchina, che resta affidabile e veloce. Il problema è che quel gestionale vive isolato dal resto del mondo, dipende da una competenza sempre più rara, e spesso non è mai stato pensato per essere esposto verso l'esterno in sicurezza. Sono tre problemi diversi, e nessuno dei tre si risolve riscrivendo tutto da capo.

Il gestionale AS/400 funziona: il problema è un altro

Un sistema AS/400 in produzione da anni ha un pregio che si sottovaluta: contiene la logica di business dell'azienda, affinata da decenni di casi reali, eccezioni e correzioni. Riscriverla da zero significa buttare via quel patrimonio e rischiare di reintrodurre errori già risolti. Ecco perché i rischi veri sono altri tre. Il primo è l'isolamento: il gestionale non parla con il sito, con l'app, con i portali di clienti e fornitori, con gli altri applicativi. Il secondo è la competenza: il linguaggio con cui è scritto, l'RPG, è padroneggiato da sempre meno persone, molte vicine alla pensione. Il terzo è la sicurezza: nato in un'epoca in cui il sistema stava chiuso in sala macchine, non è detto che sia pronto a essere raggiunto da una rete moderna.

Perché conviene modernizzare l'AS/400 invece di riscriverlo

La proposta più frequente è anche la più rischiosa: rifare tutto su una piattaforma nuova, in un colpo solo. Sulla carta è seducente, nella pratica è il tipo di progetto che più spesso sfora tempi e budget, o fallisce. Un gestionale che regge l'azienda non si può spegnere per mesi in attesa del sostituto, e ricostruire anni di regole in un'unica migrazione significa scoprire troppo tardi tutti i dettagli che nessuno ricordava più.

L'alternativa matura non è sostituire, è collegare: lasciare l'AS/400 a fare ciò che fa bene e costruirgli intorno, per gradi, lo strato moderno che gli manca. Ogni passo porta un valore concreto da subito e si può fermare o correggere senza aver messo a rischio il cuore del sistema.

La prova: da dove conviene cominciare, e quando invece non serve

Prima di parlare di tecnologie conviene capire quale dei tre problemi pesa davvero nella tua azienda, perché la risposta cambia completamente il primo intervento e il suo costo. Queste cinque domande si rispondono in cinque minuti, guardando l'ultimo anno e non le intenzioni.

• Quante volte al mese qualcuno riporta a mano dati che stanno già sull'AS/400 verso un altro strumento (un foglio di calcolo, il sito, un portale cliente, la contabilità)?
• Se la persona che conosce l'RPG si assentasse per due mesi, l'azienda si fermerebbe, rallenterebbe, o non se ne accorgerebbe?
• Il sistema è raggiungibile in qualche modo da fuori l'azienda (accesso remoto, collegamento con un fornitore, scambio dati automatico)? Chi ha le utenze con poteri ampi, e quando è stata l'ultima verifica?
• Ci sono richieste dei clienti che oggi si rifiutano perché il gestionale non le supporta (portale ordini, tracciabilità, scambio documenti automatico)?
• Le schermate a caratteri sono un problema reale per chi lavora (formazione lunga, errori, difficoltà a inserire persone nuove) o è solo una questione estetica?

L'ultima riga è quella che nessun fornitore scrive, ed è vera più spesso di quanto si creda. Un AS/400 che gira bene, chiuso e con la competenza in casa, è un sistema che sta facendo il suo mestiere: intervenire perché "è vecchio" non è una ragione.

Come integrare l'AS/400 con delle API su RPG e DB2

Il primo mattone è dare al gestionale una porta di comunicazione moderna. I programmi RPG e il database DB2 for i che vivono sull'AS/400 possono essere esposti, senza modificarli, dietro delle API: interfacce che parlano il linguaggio di oggi (richieste web, formato JSON) e che gli altri sistemi sanno già usare. Il database del sistema è pienamente interrogabile in SQL, e la piattaforma esegue Java come runtime di prima classe, pienamente supportato: questo permette di costruire uno strato di servizi che legge e scrive sul gestionale attraverso canali stabili, senza riscrivere la logica che c'è dentro. Sono gli stessi strumenti standard di qualsiasi applicazione moderna: ad esempio un framework Java come Spring Boot per lo strato di servizi, che dialoga con DB2 in modo naturale. Da fuori il sistema diventa un servizio come un altro; dentro, resta esattamente com'era.

È il pattern che in letteratura si chiama "strangler fig": invece di sostituire il sistema in un colpo, gli si costruisce intorno un guscio moderno che intercetta le richieste e ne assorbe una funzione alla volta. Il vecchio e il nuovo convivono, e il passaggio avviene per gradi, quando ogni singolo pezzo è pronto e verificato.

Dal green-screen 5250 a un'interfaccia web moderna

Con quelle API in piedi, il passo successivo è l'interfaccia. Le classiche schermate a caratteri verdi (il terminale 5250) funzionano, ma allontanano gli utenti più giovani, rendono lenta la formazione e non esistono su un telefono. Sopra lo strato di servizi si può costruire un'interfaccia web, e all'occorrenza un'app, con librerie a componenti diffuse (ad esempio React) che consumano il JSON prodotto dalle API, e con l'esperienza d'uso che le persone si aspettano oggi. L'operatore lavora su una schermata moderna; dietro, ogni azione arriva al gestionale di sempre. Una precisazione onesta: rifare l'interfaccia non vuol dire fotografare le vecchie schermate e incollarle su una pagina web, una scorciatoia fragile che si rompe al primo cambiamento. Vuol dire ricostruire l'interazione sopra le API, dove dati e regole passano da canali stabili.

Integrare i dati dell'AS/400 con gli altri sistemi

Un gestionale isolato tiene i dati chiusi dentro di sé. Spesso servono altrove: per alimentare un altro applicativo, per scambiarli con un portale di fornitori o clienti, per estrarne stampe aggiornate. Poiché il database DB2 for i è interrogabile in SQL, quei dati possono essere resi disponibili ad altri sistemi in modo controllato, oppure copiati con continuità verso un'altra base dati quando serve tenerli allineati. Il punto delicato non è tecnico, è di metodo: si espone solo ciò che serve, con letture dedicate, senza consegnare a chi sta fuori le chiavi dell'intero sistema.

Mettere in sicurezza l'IBM i durante la modernizzazione

Qui sta il punto che troppi progetti di modernizzazione trascurano, e che invece è decisivo. Aprire verso una rete moderna un sistema nato per stare chiuso in sala macchine ne moltiplica la superficie d'attacco. Non è un rischio teorico: anche su IBM i vengono scoperte vulnerabilità reali, e una configurazione degli accessi ereditata da vent'anni fa spesso concede più poteri del necessario. Modernizzare senza mettere in sicurezza vuol dire costruire una casa nuova su una serratura vecchia.

La modernizzazione fatta bene tratta la sicurezza come parte del progetto, non come un ritocco finale. Lo strato di API non è solo una comodità tecnica, è anche il punto di controllo: è lì che si decide chi può fare cosa, si validano le richieste, si tiene traccia degli accessi e si evita di esporre il sistema in modo diretto.

Sul gestionale stesso vale il principio del privilegio minimo: ogni utenza tecnica riceve solo i poteri che le servono, e le autorità più ampie (quelle equivalenti all'amministratore assoluto del sistema, storicamente il profilo QSECOFR) restano riservate e sorvegliate. Le versioni recenti di IBM i aggiungono strumenti moderni, come l'autenticazione a più fattori, che vanno sfruttati. La regola è semplice: ogni porta che si apre verso l'esterno va progettata per reggere chi la userà male, non solo chi la userà bene.

Ridurre la dipendenza dagli sviluppatori RPG

Il terzo problema, la competenza, si affronta senza drammi ma senza rimandarlo. Trovare e trattenere chi conosce l'RPG è sempre più difficile e costoso, e legare la sopravvivenza dell'azienda a poche persone è un rischio in sé. Lo stesso approccio graduale offre una via d'uscita: man mano che si costruisce lo strato di servizi, si può spostare, un pezzo alla volta, la logica che cambia più spesso verso tecnologie diffuse, per cui è facile trovare competenze. Non è una corsa a smantellare il gestionale, è una riduzione controllata della dipendenza: il cuore stabile resta dov'è, le parti che evolvono migrano dove il mercato del lavoro è più ampio.

Non sostituire una dipendenza con un altra

Chi ha un AS/400 conosce bene il problema di dipendere da poche persone: è esattamente la situazione da cui vuole uscire. Il rischio, in un progetto di modernizzazione, è uscirne per entrare in una dipendenza nuova, questa volta dal fornitore che ha costruito lo strato moderno. Sarebbe lo stesso problema con un vestito diverso, e va evitato per iscritto, non a parole.

Le condizioni sotto si possono mettere in contratto e verificare. Vale la pena pretenderle da chiunque, non solo qui.

• Il codice dello strato nuovo è tuo dal primo giorno, in un archivio intestato alla tua azienda. Non a saldo lavori: dal primo giorno.
• Tecnologie ordinarie e diffuse, per cui le competenze si trovano sul mercato. Il senso del progetto è ridurre la dipendenza da una competenza rara: introdurne una nuova e altrettanto rara lo vanificherebbe.
• Nessun componente proprietario con licenza intestata al fornitore. Se il nuovo strato gira solo grazie a una licenza che non è tua, il codice tuo non ti serve.
• Documentazione scritta per un altro sviluppatore: come si installa, come si configura, come si ripristina, quali chiamate esistono e cosa fanno.
• Accessi intestati alla tua azienda, sia sull'AS/400 sia sui sistemi nuovi. Il fornitore lavora con utenze proprie, che tu puoi revocare in qualsiasi momento.

La verifica pratica è una sola, e si può fissare come condizione di fine fase: un altro sviluppatore deve poter installare e avviare lo strato nuovo seguendo solo la documentazione consegnata. Se ci riesce, la continuità esiste. Se non ci riesce, non esiste, per quanto rassicurante sia stata la risposta a voce.

Il fornitore RPG che avete già non si tocca

Un'altra preoccupazione ricorrente, di solito non detta: chi mantiene il gestionale da anni teme di essere scavalcato, e chi decide teme di perderlo. Un progetto di modernizzazione fatto bene non sostituisce quella figura, ci lavora accanto: le API si costruiscono sopra i programmi esistenti senza modificarli, e chi conosce l'RPG resta il punto di riferimento per il cuore del sistema. Averlo dalla propria parte è anche la condizione pratica perché il lavoro proceda: è lui che sa dove sono le eccezioni che nessuno ha mai documentato.

Modernizzare l'AS/400 un passo alla volta, con rischio controllato

Il filo che lega tutto è il metodo: nessuna migrazione totale, ma una sequenza di passi delimitati, ognuno con uno scopo chiaro e un risultato verificabile. Si parte quasi sempre da un'analisi iniziale: capire com'è fatto il sistema, quali dati e programmi contano davvero, dove sono i rischi di sicurezza e da quale integrazione conviene cominciare. Da lì si sceglie il primo blocco che porta valore subito (spesso una singola integrazione, o una schermata critica rifatta), lo si realizza a scopo e prezzo definiti, e solo dopo si decide il passo seguente. Così l'investimento resta sotto controllo, il gestionale non si ferma mai, e a ogni tappa c'è qualcosa che funziona, non una promessa.

Quanto costa, con le cifre

Gli ordini di grandezza qui sotto sono riferiti al mercato italiano delle piccole e medie imprese, IVA esclusa. Non sono preventivi: servono a capire se il discorso regge prima di scrivere a qualcuno. Il preventivo puntuale nasce dopo l'analisi, con lo scope scritto.

Il numero che manca in tabella è il più importante: quanto costa oggi non fare nulla. Vale la pena stimarlo, anche a spanne. Un'ora al giorno di ricopiature manuali vale intorno ai 5.000 euro l'anno di tempo di una persona. Un ordine perso perché un cliente voleva un portale che non potete dargli è un ricavo che va altrove. Un fermo di due mesi della persona che conosce l'RPG, se nessuno può sostituirla, è un rischio che non si misura in euro finché non capita.

Chiedi l'analisi di fattibilità: 900 euro, due settimane, scalati dal progetto

Come si svolge il lavoro, fase per fase

Ogni fase ha uno scopo, una durata e un prezzo definiti prima di cominciare. Alla fine di ciascuna si può proseguire, fermarsi o cambiare direzione, e ciò che è stato fatto resta in funzione.

Il gestionale non si ferma mai, in nessuna fase. Il lavoro si svolge da remoto con credenziali dedicate; gli interventi che richiedono presenza si concordano.

In sintesi

• Il sistema AS/400 (IBM i) di solito non è il problema: è affidabile e custodisce la logica di business dell'azienda.
• I rischi veri sono tre: isolamento dagli altri sistemi, competenze RPG sempre più rare, sicurezza pensata per un mondo chiuso.
• Riscrivere tutto in un colpo solo è la strada più costosa e più esposta al fallimento.
• La via matura è collegare, non sostituire: API sopra programmi e database, senza toccarne il cuore.
• Sopra le API: interfaccia web moderna al posto del green-screen, e dati integrati con gli altri sistemi.
• La sicurezza si progetta insieme al resto, non si aggiunge alla fine: privilegio minimo, un punto di controllo unico, autenticazione forte.
• Un passo alla volta, ognuno con valore concreto e rischio delimitato, a partire da un'analisi iniziale.

Domande frequenti sulla modernizzazione dell'AS/400

Quanto costa modernizzare un gestionale AS/400?

Si parte da un'analisi di fattibilità di 900 euro per due settimane, che si scala dal progetto se si procede. La prima integrazione in esercizio sta indicativamente tra 4.000 e 8.000 euro; lo strato di servizi con la prima interfaccia web tra 12.000 e 25.000, distribuiti sulle fasi. La manutenzione dello strato nuovo va dai 150 ai 400 euro al mese. Tutti gli importi sono IVA esclusa, e il preventivo puntuale nasce dopo l'analisi, con lo scope scritto.

In quanto tempo si vede il primo risultato?

Due settimane per l'analisi, poi dalle quattro alle sei settimane per la prima integrazione in esercizio. Non è un progetto annuale: il senso delle fasi è che qualcosa di utile entri in azienda presto, mentre il resto si costruisce.

Di chi è il codice dello strato nuovo?

Tuo, dal primo giorno, in un archivio intestato alla tua azienda, insieme agli accessi. Le tecnologie usate sono ordinarie e diffuse, proprio perché il senso del progetto è ridurre la dipendenza da competenze rare, non spostarla altrove.

Il nostro fornitore storico RPG viene sostituito?

No, ci si lavora accanto. Le API si costruiscono sopra i programmi esistenti senza modificarli, e chi conosce il gestionale resta il riferimento per il suo cuore: è la persona che sa dove sono le eccezioni che nessuno ha mai scritto da nessuna parte.

Bisogna spegnere l'AS400 durante la migrazione?

No. La logica è costruire lo strato moderno accanto al sistema, che resta in produzione. Il vecchio e il nuovo convivono e le funzioni passano una alla volta, quando ognuna è pronta e verificata. Non c'è un fermo dell'azienda in attesa del sostituto.

Si può integrare l'AS/400 con e-commerce e fatturazione elettronica?

Sì. Una volta esposto il gestionale dietro delle API, i suoi dati e le sue funzioni diventano disponibili verso altri sistemi: un negozio online, un portale di fornitori o clienti, lo scambio di documenti (EDI) o l'invio della fatturazione elettronica. Si espone solo ciò che serve, in modo controllato.

Come si affronta la carenza di sviluppatori RPG?

Con la stessa modernizzazione graduale: man mano che si costruisce lo strato di servizi, la logica che cambia più spesso può migrare verso tecnologie diffuse, per cui è facile trovare competenze. Il cuore stabile resta sull'AS/400, e la dipendenza da una competenza rara si riduce nel tempo.

Conviene modernizzare o riscrivere tutto da capo?

Nella grande maggioranza dei casi conviene modernizzare. Riscrivere tutto in un colpo solo significa buttare via decenni di logica di business e affrontare il progetto più a rischio di fallimento. Collegare e sostituire per gradi porta valore da subito e tiene il rischio sotto controllo.

Collegare il passato al presente, in sicurezza

Modernizzare un gestionale AS/400 non vuol dire rinnegare ciò che funziona da vent'anni. Vuol dire collegarlo al presente, in sicurezza, senza fermare l'azienda e senza scommettere tutto su una riscrittura. Il primo passo non è un grande progetto, è una domanda: da dove conviene cominciare, e con quale rischio.

Il modo più semplice per rispondere è partire dall'analisi di fattibilità: due settimane, 900 euro IVA esclusa, che si scalano dalla prima fase se si procede. Comprende l'esame del sistema con chi lo conosce, la verifica dei rischi di sicurezza e degli accessi, e la scelta del primo blocco. Si consegnano lo scope scritto, i rischi in ordine di gravità e il preventivo a fasi con i prezzi di ciascuna. Se non si procede, quei documenti restano tuoi e puoi usarli con qualunque altro fornitore.

Chiedi l'analisi di fattibilità per il tuo sistema

E se dopo la prova delle cinque domande la conclusione è che il sistema sta facendo il suo lavoro e non serve intervenire adesso, scrivilo lo stesso: dirtelo è una risposta utile, e non costa nulla.

Per il servizio dedicato, con il perimetro, i costi e come si parte:

Modernizzazione di un gestionale AS/400: come funziona e come iniziare