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.
Perché ogni mattina gli impiegati della banca possano collegarsi al sistema gestionale e trovarvi dentro le informazioni correttamente aggiornate è necessario che gli operatori del Centro Elaborazione Dati svolgano una lunga serie di operazioni.
La gestione giornaliera del gestionale
Le operazioni che vengono svolte quotidianamente sono tante. Tra quelle principali che venivano svolte al tempo in cui lavoravo presso il CED delle BCC di Ospedaletto prima e Malatestiana poi, c’erano la ricezione e l’invio del flussi sulla rete interbancaria, le elaborazioni batch, la gestione delle stampe (output delle elaborazioni, inventari, stampe di controllo), l’esecuzione delle copie di salvataggio e l’archiviazione dei supporti magnetici (operazione che a quel tempo era svolta “manualmente”) e l’elaborazione delle “chiusure serali di giornata” per preparare la base dati alla successiva giornata lavorativa.
Molte di queste attività avevano una cadenza giornaliera e venivano ripetute uguali tutti i giorni. Altre attività erano pianificate ad intervalli prefissati, come ad esempio la produzione di alcuni inventari settimanali.
Un momento particolare era rappresentato dai “fine mese” nei quali venivano svolte alcune elaborazioni particolari. In particolare i “fine mese” più importanti erano quelli di fine trimestre e, più di tutti quello di fine anno, momenti in cui venivano lanciate le elaborazioni di calcolo delle competenze e degli interessi.
Non è questa la sede per entrare nel dettaglio di queste attività ma un aspetto merita di essere approfondito. Ci si riferisce al fatto che queste elaborazioni non erano un semplice lancio di un programma e la relativa attesa della sua fine elaborazione. Pur essendo stati ben testati in ambienti di prova la situazione reale presenta una quantità di variabili tale che l’imprevisto è sempre dietro l’angolo. Abbiamo già citato il fatto che il funzionamento del sistema gestionale dipende dall’impostazione di un complesso impianto tabellare che ogni banca adatta alle proprie esigenze. Ne consegue che un programma testato in ambiente di prova e su un certo campione di banche pilota, possa andare in errore in un’altra banca, con un impianto tabellare diverso. Quando questo succede durante l’elaborazione di un “fine anno” visti i tempi stretti a disposizione per il lancio di tutte le elaborazioni, la ricerca dell’errore e la suo soluzione comportava non pochi problemi agli operatori.
Si tenga inoltre conto che i programmi gestionali bancari vengono continuamente modificati per recepire le continue variazioni della legislazione vigente, soprattutto in materia fiscale. Questa materia tra l’altro viene spesso modificata con l’annuale approvazione della legge finanziaria con evidenti riflessi sulla gestione bancaria.
Ogni fine mese viene quindi elaborato in circostanze diverse dal precedente, vuoi perché sono stati modificati i programmi, vuoi perché si è intervenuti sull’impianto tabellare o perché sono stati attivati nuovi servizi.
L’erogazione di un sistema gestionale bancario non può essere quindi affidata a persone che, pur essendo estremamente competenti delle tecnologie informatiche, non conoscono a fondo i processi bancari.
L’installazione delle nuove release e dei programmi per gestire i nuovi servizi
Periodicamente, a volte anche con cadenza mensile, si rendeva necessario aggiornare il programma gestionale con l’installazione di una nuova release, rilasciata per adeguarsi alle nuove normative di legge o per l’attivazione di un nuovo servizio.
I programmi ci venivano inviati direttamente dalla software house e prima di essere messi in produzione venivano provati su di un ambiente di test, rappresentato da una copia fuori linea del database “di produzione”. I programmi non potevano essere utilizzati così come ci erano pervenuti perché molti di essi dovevano essere personalizzati per la nostra banca. Uno dei vantaggi dati dal gestire il sistema informativo internamente rispetto alla gestione in outsourcing è quello che il sistema informativo può essere adattato per meglio rispondere alle esigenze commerciali dell’azienda; questo aspetto però nascondeva anche un lato negativo dato dal fatto che le attività di manutenzione del software diventavano sempre più pesanti al punto da non essere più sopportabili da una piccola struttura come la nostra, da cui derivò la scelta dell’outsourcing.
La gestione degli incidenti
Normalmente si considera la gestione degli incidenti una attività eccezionale. Con il SIBI ed i problemi che c’erano sulle linee di trasmissione dati questa attività era quotidiana. A causa della sua organizzazione, con il SIBI si verificavano di sovente situazioni di dead-lock in cui due operazioni eseguite più o meno contemporaneamente da due utenti potevano andare in conflitto e bloccare la coda delle transazioni, con conseguente caduta del sistema.
Il concetto di transazione prevede che un insieme di scritture sul database o vanno a buon fine tutte o viene innescato il meccanismo di roll-back e vengono cancellate anche quelle che erano state eseguite correttamente, ripristinando la situazione precedente alla transazione. Il SIBI non era in grado di gestire transazioni complesse in quanto le scritture sugli archivi dei rapporti e quelle sugli archivi della contabilità erano eseguite da processi server separati.
La conseguenza della caduta del sistema era che in alcuni casi veniva scritta la parte contabile della transazione ma non quella sul rapporto o viceversa. Quando si verificavano questi casi l’operatore del CED, in collaborazione con gli utenti ai quali non era andata a buon fine la transazione, doveva cercare di ricostruire l’operazione ed eventualmente completare manualmente le scritture mancanti sul DB, o cancellare quelle già fatte a metà, ripristinando i saldi iniziali.
Operazioni di questo tipo possono far rabbrividire un esperto della materia, ma quello era il sistema a disposizione per cui si faceva di necessità virtù
Il supporto agli utenti
Per concludere, ultima ma non meno impegnativa tra le attività e erogazione e supporto del sistema informativo bancario, c’era l’assistenza agli utenti.
Visto che tutti i processi bancari si svolgevano con l’ausilio del sistema informativo e che spessi gli stessi processi venivano modificati ed adattati in riferimento alle possibilità offerte dal programma gestionale, gli operatori del CED erano un vero e proprio riferimento per tutti i dipendenti della banca. A loro ci si rivolgeva per chiedere aiuto per quasi ogni aspetto dell’operatività.
Il supporto ai colleghi era quindi una della attività che assorbiva una grossa parte del tempo lavorativo giornaliero di noi addetti e responsabili del CED.
