E.I. – Emulatore d’Impiegato

Analizzando l’operatività di un impiegato di banca, soprattutto quella di un addetto agli uffici interni, ci si rende conto che costoro trattano informazioni che sono quasi completamente residenti su sistemi informatici e che le transazioni che eseguono per trattare queste informazioni sono spesso ripetitive o comunque variabili all’interno di un numero limitato di opzioni conosciute in anticipo

Le difficoltà dell’automazione di certi processi sono soprattutto tre.
In primo luogo dal fatto che queste informazioni sono residenti su sistemi diversi che non colloquiano fra di loro.
Il secondo e che i sistemi sono sviluppati da software house esterne alla azienda che rivendono il loro prodotto ad aziende diverse con esigenze diverse. Di conseguenza un prodotto software industriale non può essere personalizzato per ogni singolo cliente ma deve necessariamente gestire un processo standard.
Il terzo elemento di ostacolo è dato dal fatto che questi sistemi gestionali sono sempre più spesso gestiti da outsourcer che, nell’ottica di offrire un servizio industriale e per tutelare i livelli di servizio forniti, non concedono l’accesso diretto in scrittura alla base dati, se non attraverso le transazioni del software da loro distribuito.
I programmi sono di proprietà della software house e non sono modificabili dal personale della banca o dell’outsourcer.

Fino all’anno 1998, la Banca di Ospedaletto gestiva internamente, nel proprio CED, il sistema gestionale bancario SIBI ed i sistemi da cui lo stesso veniva erogato. Il SIBI era stato distribuito dalla software house insieme ai sorgenti per cui il personale della banca era in grado di personalizzarlo per adattarlo all’organizzazione della banca ed ai processi operativi da essa svolti. Nel 1998 l’azienda scelse di cambiare il sistema informativo gestionale bancario e di esternalizzare la sua gestione. Da quel momento non fu più possibile personalizzare i programmi o scrivere altri programmi che facessero accesso diretto alla base dati.

Per aggirare questi problemi fu ideato e realizzato E.I., l’Emulatore di Impiegato.
E.I. è una metodologia di sviluppo del software in grado di simulare la pressione dei tasti sulla tastiera del PC e di leggere l’output a video dei programmi con il quale è possibile automatizzare sequenze ripetitive di transazioni, soprattutto quelle che prevedevano l’interazione fra due sistemi diversi, simulando le azioni di un impiegato.

Lo scopo di E.I. è appunto quello di sostituire un impiegato in tutte quelle attività che si limitano all’esecuzioni di transazioni su sistemi informatici, attività che però sono una parte consistente del lavoro di un impiegato, soprattutto di quelli che lavorano negli uffici interni di una azienda e che non sono in contatto con i clienti.

Dal punto di vista concettuale, tenendo conto anche delle moderne tecnologie di riconoscimento ottico dei caratteri che della voce. E.I. potrebbe accettare qualsiasi tipo di input, e potrebbe automatizzare quasi ogni processo. Il concetto alla base di E.I. era però quello di occuparsi di quelle fasi di processo ripetitive e con poche variabili, la cui “business logic” era facilmente incapsulabile all’interno di un codice software, per cui gli emulatori di impiegato sono stati sviluppati per automatizzare quelle fasi di processo il cui input dipendeva da informazioni residenti su sistemi informatici facilmente trattabili. Tra questi avevamo i dati presenti su database e su spool di stampa. Quello che però permise ad E.I. di fare un grosso salto in avanti fu la possibilità di leggere ed interpretare gli output a video dei programmi.

Essendo E.I. dipendente dalle interfacce utente di software di terze parti, le cui modifiche dovute alla distribuzione di nuove release non sono controllabili, nello sviluppo degli Emulatori d’Impiegato ci si è sempre concentrati su quelle fasi di processo che hanno poche variabili ma molte ripetizioni perché è importante ottenere un veloce ritorno dell’investimento. I costi in termini di tempo legati al loro sviluppo devono essere velocemente recuperati in termini di lavoro risparmiato nell’esecuzione della fase di processo automatizzata. Tenendo a mente questo principio i risparmi ottenuti grazie ad E.I. sono stati considerevoli.

Il punto di forza principale di E.I. era nella possibilità di far interagire sistemi non collegati fra loro. Al tempo in cui è stato sviluppato, presso la Banca di Ospedaletto si utilizzavano diversi sistemi la cui integrazione era limitata allo scambio di alcuni flussi dati per gestire gli aspetti principali. Molte attività di integrazione erano svolte manualmente dagli impiegati che effettuavano transazioni su di un sistema, stampavano il risultato, si collegavano all’altro sistema e riportavano quanto precedentemente stampato; essendo i due sistemi prodotti da software house diverse ed erogati da società diverse (per es. il programma gestionale bancario, il SIB2000, prodotto da Phoenix Informatica Bancaria e ICCREATP, il gestionale di ICCREA, la nostra banca centrale) le possibilità di automazione utilizzando i metodi di integrazione classici erano legati alla volontà delle due aziende di collaborare e la banca non aveva quasi nessuna possibilità di influire su questa integrazione. Grazie ad E.I. era la banca che realizzava l’integrazione all’insaputa delle due software house, lavorando sul piano dell’interfaccia utente. Tra l’altro, lavorando su questo piano, quello dell’interfaccia utente si aveva la garanzia di mantenere l’integrità dei dati e la consistenza dei database che venivano scritti da transazioni ufficiali gestite dai produttori del software.

Riportiamo qui alcuni esempi di E.I. ripresi da un documento di descrizione del progetto dell’anno 2000
“…

La maggior parte delle funzioni svolte da un impiegato della nostra banca, viene espletata attraverso l’interazione con il sistema SIB2000 per mezzo dell’emulazione terminale “IBM Personal Comunication” fornita con il pacchetto IBM Client Access.
Inoltre, l’input di molte di queste operazioni non deriva né dalla lettura di un foglio di carta, né da un comando vocale, bensì dall’output di altre transazioni o da stampe che possono essere lette a video o stampate su file.
L’emulazione terminale di Client Access offre una interfaccia ad oggetti che permette di simulare la pressione di tasti e di leggere il contenuto del video (Presentation Space, come lo chiama lui)

Abbiamo quindi iniziato a codificare, in alcuni programmi scritti con Visual Basic, la logica che sovraintende alle operazioni svolte quotidianamente dall’impiegato durante l’operatività SIB2000 e, sfruttando l’interfaccia ad oggetti dell’emulazione terminale di Client Access, siamo stati in grado di sostituirlo (l’impiegato) in diverse parti del suo lavoro.

I punti di forza di EI:

mantiene un log dettagliatissimo di ogni tasto che invia e di ogni stringa che legge, in modo da poter risalire esattamente a tutto quello che ha fatto in caso di un errore imprevisto
passando attraverso le transazioni ufficiali del SIB2000 permette di scrivere programmi che vanno in update sul database senza correre il rischio di lasciare il database stesso in uno stato inconsistente
permette di far colloquiare il SIB2000 con ICCREATP senza dover mettere in piedi complicate procedure di estrazione e carico flussi e dei relativi file transfer (e di saltare a piè pari eventuali problemi burocratici)
permette di far colloquiare il SIB2000, in modo bidirezionale con tutte le altre fonti dati immaginabili (carta a parte)
una volta tarato fa molti meno errori dell’impiegato vero
aiuta molto ad abbassare il problema della sostituzione di uno in ferie

Ad oggi sono stati individuati molti punti in cui EI può fare la sua parte con profitto, ed è quindi in corso la stesura di altri programmi. Tra quelli già scritti abbiamo:

– Segnalazione pagamento Certificati di Conformità auto su ICCREATP – procedura Incassi On Line:

EI effettua il login ad ICCREATP ed entra nella procedura Incassi On Line;
legge su SQL Server quali certificati di conformità sono da pagare guardando quelli segnalati dalla filiale;
cerca i certificati nella procedura Incassi On Line e li segnala come pagati;
spunta il pagamento del certificato sul SQL Server;
controlla che l’importo totale da pagare segnalato dalla filiale sia uguale alla somma di quello che legge nei singoli certificati trovati su ICCREATP;
torna in SIB2000 ed esegue una KG11 (prima nota di contabilità) per l’importo dei certificati pagati.

– Segnalazione ricezione Certificati di Conformità auto su ICCREATP – procedura Incassi On Line:

Come sopra a parte il diverso tipo di segnalazione e la produzione di una Hard Copy della schermata ICCREATP contenente i dati del Certificato

– Centro Utenze

APERTURA

Esecuzione transazioni apertura per generare stampe statistiche sui valori nominali PO da SIB2000 e sulla raccolta diretta/indiretta da Pegasus;
smistamento stampe presenti nella coda SERALI;
smistamento stampe presenti nella propria coda di stampa generate dall’apertura.

Ogni Lunedì:

esecuzione stampe relative agli avvisi di scadenza titoli e agli assegni protestati (CA54);
quadratura saldo del conto di contabilità 244/86/116 (POS), mediante spunta tra gli addebiti, suddivisi per ABI e per data, precedentemente memorizzati giorno per giorno su un database su SQL server, e i messaggi 034 registrati a partire dall’ultima data spunta, estratti con la transazione VO04. Gli addebiti non spuntati danno il saldo del 244/86/116.

ELABORAZIONI

Lettura dati contabili dai reports giornalieri scaricati dal DSP2 in automatico durante la notte da Dispatch-PC, in particolare:
GIORNALE DI FONDO ATM: dati necessari per la chiusura contabile cassa bancomat;
RIEPILOGO ACCREDITI/ADDEBITI POS: dati necessari per contabilizzare i versamenti Cofiro da esercenti tramite POS e totale per data degli addebiti POS MULTITEL suddivisi per ABI esercente (memorizzazione per successiva quadratura);
OMNIEL: dati necessari per la registrazione del totale degli accrediti prelevamenti eurocheque e per lo storno mediante un messaggio 034 (GB) degli addebiti AMEX (causale setif 43010).
carico file transfer relativi agli addebiti/accrediti carte con VM20;
cancellazione dei movimenti in stato VISUAL con VM21;
elaborazione dei file transfer caricati precedentemente con VM22;
registrazione del totale degli accrediti prelevamenti eurocheque mediante BB01 su ICCREA causale 205;
registrazione di eventuali commissioni sui prelievi cash advance (storno commissioni dal 129/86/138);
storno degli eventuali addebiti AMERICAN EXPRESS (causale setif 43010) mediante BB01 su ICCREA con messaggio rete di tipo 034 diretto alla Deutsche Bank S.p.A.;
chiusura contabile delle casse bancomat;
registrazione versamenti Cofiro effettuati dagli esercenti tramite POS;
carico distinte RID mediante PG32, utilizzando in sequenza le transazioni 0, 1 e 7;
carico distinte RIA mediante PG32, utilizzando in sequenza le transazioni 0, 1 e 7;
se vi sono distinte RIA in accredito, carico distinte con VU10 (transazioni 0,1,7) e successiva elaborazione dei movimenti con VU21;
carico distinte utenze (ACCREDITI GENERICI) mediante UC02 e successiva elaborazione movimenti mediante UD03;
autorizzazione messaggi 011 (DA), 034 (GB), W66 (W6) del POS nell’emulazione 3270, transazione JKTP del CICS;
stampa schermo della KG55 del terminale;
stampa riepilogo flussi elaborati, distinte RID/RIA caricate e messaggi autorizzati.

BONIFICI PERIODICI

Estrazione bonifici periodici con OH12;
Sistemazione valute bonifici sospesi con OH13;
Elaborazione bonifici estratti con OH14;
Autorizzazione bonifici su banche con ON02 (solo se indicato utente autorizzato), dopo aver verificato l’assenza di eventuali bonifici anomali con OA21.

– Spunta Rimesse assegni/effetti tra SIB2000 e DP01 su ICCREATP

Apertura database BCC su SQL server – tabella Si_SpuntaRimesse;
lettura dei movimenti da spuntare da SIB2000 tramite BB01 funzione 5 su ICCREA e loro inserimento nella tabella sopraindicata;
accesso tramite emulazione 3270, ad ICCREATP, transazione DP01;
spunta e successiva verifica delle distinte presenti in DP01 secondo i seguenti criteri:
06 A (distinte assegni spedite a ICCREA) <—> movimenti causale 067, 065, 062 del giorno precedente;
07 A (distinte assegni ricevute da ICCREA) <—> movimenti causale 054 del giorno stesso;
06 E (distinte effetti spedite a ICCREA) <—> movimenti causale 812 del giorno stesso;
07 E (distinte effetti ricevute da ICCREA) <—> movimenti causale 930 del giorno stesso.
Contemporaneamente vengono spuntati i movimenti presenti nella tabella Si_SpuntaRimesse;
stampa riepilogo movimenti spuntati;
stampa riepilogo movimenti non spuntati in SIB2000 e movimenti non spuntati in DP01.

– Divisione stampe fine mese

– Ricerca differenze contabili mediante query con accesso ODBC ai files SIB2000

Mediante l’accesso ai dati via ODBC siamo stati in grado di scrivere alcune query (non realizzabili con il QUERY AS400) che estraendo i movimenti contabili e filtrandoli e raggruppandoli secondo opportuni criteri ci permettono di trovare differenze sui conti di contabilità in pochi secondi, senza dover disturbare gli addetti dell’assistenza del sistema informativo dell’outsourcer.

Prima di adottare questo sistema la ricerca di alcune differenze portava via anche molti giorni di lavoro (quando venivano trovate). In particolare ci si riferisce alle differenze generate a partire da movimenti della Procedura Titoli PEGASUS di Eurosys. A tal proposito gli stessi responsabili di Eurosys si sono complimentati per il metodo da noi escogitato.

…”