Per gestire l’arrivo dell’anno 2000 e dell’EURO il SIBI sarebbe dovuto essere gran parte riscritto. Questa operazione avrebbe richiesto forti investimenti da parte delle banche che a quel tempo utilizzavano questo sistema. Dopo una attenta valutazione in cui si tenne conto di molti aspetti non solo tecnologici, venne deciso di abbandonare il SIBI per passare al sistema SIB2000 prodotto dall’allora Fondo Comune delle Casse Rurali Trentine, oggi Phoenix Informatica Bancaria.
Con il cambio di sistema informativo la banca operò anche la scelta di non continuare con una gestione interna dello stesso e di passare quindi ad una gestione in outsourcing presso il centro elaborazione dati regionale, il CEDECRA.
Il progetto fu affidato alla società Delta Dator di Trento che aveva già avuto diverse esperienze di porting da SIBI a SIB2000, con la collaborazione degli analisti e programmatori del SIBI e del SIB2000. Il mio ruolo fu quello di supporto bancario e sistemistico a questo team e, insieme ai miei colleghi, di intermediario tra il team e la banca. Un altro compito che dovetti svolgere fu quello di convertire i programmi sviluppati internamente e che colloquiavano in il SIBI per interfacciare il SIB2000.
Questo progetto fu molto complesso e ci vide impegnati per tre mesi giorno e notte. Quanto descritto in questa scheda è solo una breve sintesi di quello che è stato fatto.
Analisi dei due sistemi informativi
Una volta che si è deciso di intraprendere questa avventura, il primo passo da compiere in un progetto di questo tipo è l’analisi delle funzionalità messe a disposizione dei due sistemi informativi. In particolare è importante mettere in luce quelle che sono le funzioni presenti nel vecchio sistema e che invece non sono presenti nel nuovo.
Essendo stata la nostra trascodifica successiva ad altre dello stesso tipo, molte delle problematiche erano già state risolte.
Implementazione del sistema informativo di destinazione delle transazioni mancanti
Una volta determinate le funzionalità mancanti e necessarie, queste devono essere sviluppate per consentire alla banca di continuare l’operatività anche con il nuovo sistema informativo. Come già detto, nel nostro caso molti di questi problemi erano già stati risolti e sono state necessarie solo modifiche marginali.
A questo punto inizia il vero e proprio progetto di migrazione
Progettazione delle riconduzioni
Un sistema informativo gestionale, soprattutto se complesso come un gestionale bancario non è come un programma da PC, per il quale è sufficiente lanciare il setup e poi è pronto all’uso. Un programma gestionale necessita di lunghe e difficili attività di configurazione. In base a come viene costruito l’impianto tabellare, le transazioni di un programma gestionale bancario possono funzionare in modi molto diversi. Per questo motivo quindi ogni transcodifica è una storia a se e va analizzata e progettata con cura.
Tra le difficoltà principali da gestire la riconduzione della base dati di origine a quella di destinazione è una delle più complesse. Le basi dati di due software organizzano le informazioni in modo diverso.
Ad esempio nella base dati del SIBI i rapporti erano codificati in modo univoco con la composizione delle seguenti informazioni: Filiale, Tipo Rapporto, Categoria, Numero Conto, CIN. In SIB2000 invece la chiave era rappresentata da Servizio (riconducibile al Tipo Rapporto) e Numero Rapporto. I campi Filiale, e Categoria erano presenti, ma non facevano parte della chiave univoca. Se si fosse fatto un porting diretto dei campi Tipo Rapporto e Numero Rapporto, la gran parte dei record sarebbe stata scartata per la presenza di chiavi doppie. Bisogna poi tenere conto che la modifica delle chiavi primarie ha effetto su tutte le tabelle correlate per cui questa attività di riconduzione è di fondamentale importanza per la buona riuscita della migrazione.
Scrittura dei programmi di estrazione ed importazione
Dopo aver valutato come effettuare la riconduzione dei Database e deciso come risolvere i conflitti di chiave, sono stati scritti i programmi di esportazione dalla base dati di SIBI e quelli per l’importazione in SIB2000
Importazioni di test
I programmi di esportazione e di importazione realizzati sono stati lanciati per effettuare migrazioni di test. I test hanno messo in luce errori che potevano essere sia nei programmi che nella base dati. I programmi sono stati così messi a punto.
Analisi degli errori e normalizzazione della base dati di origine
I programmi di esportazione ed importazione sono stati scritti per trattare dati “corretti”, cioè che rispettano alcune regole formali. Come è facilmente comprensibile, nella base dati c’erano però molti dati non corretti, dovuti ad esempio ad errori durante il caricamento manuale. Si tenga conto che la base dati di SIBI non era relazionale ed il database non gestiva regole di integrità referenziale. I programmi di esportazione ed importazione hanno messo in luce questi errori scartando i dati che non rispettavano le regole formali. In questi casi i record scartati venivano corretti nella base dati di origine che è stata così pian piano normalizzata.
Simulazione dell’operatività sul nuovo sistema
Dopo aver ottenuto una nuova base dati sufficientemente attendibile sono state effettuate delle simulazioni dell’operatività sul nuovo sistema. Sono state provate le operazioni di TP di sportello e tutte le elaborazioni batch, come la ricezione ed elaborazione dei flussi, le chiusure di giornata, gli inventari settimanali, le chiusure mensili e le operazioni di chiusura trimestrali ed annuali.
Formazione sul nuovo sistema
Nel frattempo che si sviluppavano i programmi di esportazione e di importazione e venivano eseguite le migrazioni di test il personale della banca ed in particolare quello del CED è stato formato all’utilizzo del nuovo sistema.
Migrazione della base dati e attivazione del SIB2000
La base dati di SIBI è stata così preparata per l’elaborazione definitiva dei programmi di esportazione e di importazione. E così, un venerdì sera, dopo aver effettuato le operazioni di chiusura della giornata, è stata eseguita l’esportazione ed importazione definitiva. Questa operazione, ed i relativi controlli è durata tutto il weekend ed il lunedì successivo la banca ha aperto utilizzando il nuovo sistema informativo.
Supporto ai colleghi della banca per l’apprendimento e l’utilizzo del nuovo sistema
E’ stato già descritto nella scheda 9.2 “Erogazione e supporto del sistema informativo bancario” che una delle attività principale degli operatori del CED era quella di supporto ai colleghi nell’utilizzo del sistema informativo. Se questo è vero in condizioni di normalità, può essere facilmente comprensibile come lo possa essere a maggior ragione dopo l’attivazione di un nuovo sistema informativo. Per le prime due settimane, oltre al nostro supporto centrale, presso ogni filiale era presente un operatore della società che ha curato la migrazione, per dare assistenza diretta ai colleghi.
Adattamento dei programmi interni
La Banca di Ospedaletto, oltre ai moduli disponibili all’interno del SIBI, utilizzava anche molti programmi sviluppati internamente per automatizzare molte fasi di processo che non erano gestite dal sistema gestionale. Si trattava di moduli software non vitali, ma che avevano ormai assunto una notevole importanza. Tutte le attività descritte finora sono così state eseguite anche per i programmi interni. Questa attività è stata svolta direttamente da persone ora parte del team Evridigit
