Applicazioni web per Intranet

L’utilizzo delle tecnologie web ha rappresentato un altro passaggio generazionale nell’infrastruttura IT della Banca di Ospedaletto. Senza avere l’intenzione di spiegare in questa scheda quali sono le caratteristiche principali di questa tecnologia, per la quale si rimanda all’abbondante letteratura esistente, proviamo a mettere in evidenza quelli che sono stati per noi i fattori chiave che ci hanno spinto ad investire molto in questo settore.

Iniziamo descrivendo lo scenario IT in cui si era collocata l’azienda.

I sistemi informativi gestionali dell’azienda, il SIBI (di Secdata e poi di Digital) e successivamente il SIB2000 (di Phoenix Informatica Bancaria) erano/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.
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.
Tutta le fasi di processo che non vengono gestire dal sistema gestionale vengono svolte manualmente o tramite software verticali, specializzati, sviluppati o fatti sviluppare dalla banca.
Le Banche di Credito Cooperativo sono piccole aziende che non possono produrre internamente tutti i prodotti disponibili nell’offerta dei servizi bancari. Le BCC delegano questa attività di produzione a società specializzate del sistema del Credito Cooperativo, le società prodotto, o rivendono prodotti di altre compagnie (per esempio i fondi comuni o i prodotti assicurativi). Per vendere questi prodotti i dipendenti delle BCC devono utilizzare i software messi a disposizione da queste compagnie.

Il risultato prodotto da questo scenario è il seguente:

I dipendenti della banca sono costretti ad utilizzare molti sistemi IT diversi per lo svolgimento del proprio lavoro
La banca, se vuole cercare di ottimizzare i propri processi interni, automatizzando quanto è possibile, deve sviluppare altri software che si aggiungono ai molti già presenti
I dipendenti, di fronte a tanti strumenti diversi, si trovano in difficoltà e spesso rinunciano a vendere un prodotto perché è difficile accedere allo strumento software con il quale va gestita la transazione di vendita

Si instaura cioè una specie di circolo vizioso in cui la soluzione ad un problema, diventa essa stessa un problema.

Abbiamo provato a descrivere questo scenario con queste immagini


Una persona è felice per avere tanti oggetti. Vuole rappresentare il dipendente che ha tanti software a disposizione per svolgere il proprio lavoro	Per farlo ancora più felice gli diamo un altro regalo. (un altro programma che dovrebbe consentirgli di fare meno fatica nel suo lavoro)	Il nostro amico, invece di essere felice per il nuovo regalo è in difficoltà perché non sa come reggerlo.

Un altro aspetto problematico è che di tutti i sistemi che vengono messi a disposizione, ogni dipendente spesso ne utilizza solo una piccola parte, quella che serve per gestire la fase di processo in cui lui è coinvolto. In generale le interfacce utente dei vari software e programmi gestionali sono pensate in riferimento a se stessi. Se un programma gestisce 100 funzioni, la sua interfaccia utente verrà disegnata per rendere accessibili, secondo un ordine più o meno logico pensato dal produttore del software, tutte le 100 funzioni, indipendentemente da chi sarà l’utilizzatore.
Gli utilizzatori finali invece di quelle 100 funzioni ne useranno solo una piccola parte, e cioè quelle che servono allo svolgimento della propria parte del processo operativo.
Facciamo un esempio. Un software per la gestione dei prodotti assicurativi potrebbe prevedere:

Una transazione per l’autenticazione per riconoscere gli utenti
Un insieme di transazioni per gestire l’impianto tabellare di censimento delle anagrafiche e dei prodotti
Una transazione per l’inserimento di un nuovo ordine di acquisto da parte di un cliente
Un insieme di transazioni per gestire la vita del prodotto acquistato dal cliente
Un insieme di transazioni per la gestione contabile del servizio
Una transazione per gestire la chiusura del rapporto con il cliente

Le stesse transazioni potrebbero essere presenti in un programma per la gestione di un fondo comune.
Alla società di gestione dei prodotti assicurativi probabilmente servono quasi tutte queste transazioni e non ne servono altre. Idem si potrebbe dire per la società di gestione del fondo comune.
Al dipendente di una filale della banca invece svolge solo una piccola parte dell’intero processo della gestione dei prodotti assicurativi, perché il suo personale processo operativo comprende anche una parte del processo di gestione dei fondi comuni, così come una piccola parte di altri processi. A lui quindi servono solo tre transazioni fra le tante disponibili, per esempio quella per censire l’anagrafica del cliente, quella per l’inserimento di un ordine di acquisto e quella per la chiusura del rapporto. Le stesse transazioni gli servono all’interno del programma per la vendita del fondo comune.
Questo utente però sarà costretto a fare accesso a due sistemi diversi, con due modi diversi di fare l’autenticazione (e magari con due codici utente e due password diverse) ed a dover cercare le transazioni a lui utili in mezzo alla marea di transazioni disponibili sui vari sistemi.

Quello che bisognerebbe cercare di fare quindi, e che si è cercato di fare con l’introduzione delle tecnologie web oggetto di questa scheda, è quello di costruire una interfaccia utente pensata per l’utilizzatore finale, in considerazione del suo punto di vista di gestione di un processo.

Proviamo a dare una rappresentazione grafica

	Abbiamo 3 utenti (A, B e C), tre programmi (1, 2 e 3) ognuno dei quali ha delle transazioni (i simboli all’interno del programma)
	All’utente A servono per lo svolgimento del suo lavoro 4 transazioni, due del programma 1 ed una ciascuno dei programmi 2 e 3
	La stessa cosa si può dire degli utenti B e C che necessiteranno solo di alcune delle transazioni disponibili nei vari programmi ma che svolgendo un’atra mansione saranno diverse da quelle necessarie ad A. In questo esempio tutti gli utenti utilizzano tutti i programmi, tutte le transazioni dei programmi sono utilizzate da almeno un utente, ma in combinazioni diverse. Gli utenti devono quindi fare accesso a tutti i sistemi e ricercare al loro interno quanto serve loro per svolgere la propria mansione
	Utilizzando le tecnologie web si è cercato di costruire uno strato intermedio che funzionasse da punto di accesso unico, un portale da cui accedere a tutte le applicazioni sottostanti.
	Ogni utente si presenta al portale ed il portale mette a disposizione degli utenti le transazioni che a lui servono per svolgere la propria mansione.

Una applicazione pratica di questa idea è rappresentata dall’integrazione del sito intranet della Banca Malatestiana e della procedura GRACE descritta nella scheda 21.
Il portale del sito intranet svolgeva la funzione di punto di accesso unico con il quale venivano aggregati diversi contenitori di informazioni e applicazioni, selezionando le funzioni più utili agli utenti organizzando le stesso secondo una logica di processo invece che di strumento.
GRACE è uno strumento che permetteva di fare molte cose e tra queste veniva utilizzato in Banca Malatestiana per la gestione del work flow delle pratiche elettroniche, come ad esempio la funzione per richiedere il blocco di una carta di credito o di un Bancomat

Per eseguire il blocco di una carta utilizzando il menù di GRACE un operatore avrebbe dovuto:

Lanciare GRACE
Inserire userid e password
conoscere la logica con cui le funzioni erano organizzate in GRACE,
entrare nella sezione lavori

navigare nell’albero dei processi fino a trovare quello relativo alle carte di credito
aprire la sezione
cercare ed aprire la richiesta per il “Blocco carte”

Questo modo di organizzare le funzioni disponibili ha un senso per il fatto che GRACE gestisce molte transazioni ed informazioni che coprono l’intero arco dei processi bancari. Molte di queste funzioni ed informazioni non sono però rilevanti per un operatore di sportello che invece deve spesso inoltrare richieste per il blocco di una carta.

Grazie all’abilità dei colleghi di CSSB, il sistema di autenticazione di GRACE è stato integrato con il dominio di rete Microsoft Windows con il quale era gestito il controllo accessi alla rete aziendale. In questo modo è stato possibile accedere alle singole viste e transazioni di GRACE, senza dover per forza passare dal suo menù generale.

Le funzioni di GRACE più importanti per l’operatività di sportello furono così collegate direttamente all’home page del portale del sito intranet della banca, insieme alle altre funzioni utili prese dai vari contenitori e strumenti.

In questo modo un operatore di sportello poteva accedere alla richiesta di blocco carta con soli due clic del mouse, il primo per lanciare il browser Microsoft Internet Explorer (con apertura in automatico della home page del portare del sito intranet della Banca) ed il secondo per accedere alla richiesta.

Nessun codice utente e password erano più richiesti, ma la sicurezza era garantita in quanto l’utente si era già autenticato all’apertura del PC

Una copia del home page del portare del sito intranet è riportata nella figura seguente. Come si può vedere, nella sezione “Electronic Banking”, situata al centro della pagina, è posto il link alla richiesta di “Blocco carte”

Quello descritto finora rappresenta un obiettivo a cui tendere e che non verrà mai raggiunto completamente, ma le tecnologie web oggetto di questa scheda hanno permesso di iniziare un percorso che va in questa direzione.
Parliamo infatti di un obiettivo a cui tendere perché man mano che si procede con l’attività di consolidamento, integrazione e semplificazione dell’infrastruttura esistente, nuovi strumenti e nuove tecnologie vengono attivati e messi a disposizione degli utenti; da una parte si cerca di semplificare dall’altra si mette nuova carne al fuoco. L’utilizzo delle tecnologie web ha però rappresentato una inversione di tendenza in quanto fino a questo momento avevamo solo una crescita del numero di strumenti e la situazione era diventata ormai ingestibile per gli utenti.

Naturalmente non tutte le applicazioni esistenti poterono essere integrate nel portale aziendale, ma lo stesso vi percepito come una buona semplificazione e soprattutto le nuove applicazioni sviluppate con interfaccia web non venivano più percepite come un’ulteriore complicazione.

Parlare di tecnologie web rischia di essere una definizione un po’ generica. I effetti quello che sta dietro la finestra di un browser è molto complesso, sicuramente molto più di quanto non lo fossero le architetture IT precedenti. Ma quello che importa nel nostro caso è l’aver trasferito questa complessità dagli utenti finali ai gestori dell’infrastruttura.

L’interfaccia HTML ha permesso di disegnare dei menù di funzioni pensati per gli utenti finali, aggregando contenuti provenienti da fonti diverse. All’utente finale, che dietro un link ci fosse un chiamata ad una applicazione ASP, ad un programma COBOL via CGI, una applicazione Lotus Notes, l’apertura di un documento in formato Microsoft Excel visto tramite una chiamata OLE, un programma Java o una semplice pagina HTML, locale o presa direttamente da internet poco importa. Qualunque sia la fonte dei dati l’utente ha la percezione di lavorare con l’applicazione “Intranet Aziendale”.
Come abbiamo già avuto modo di dire i processi operativi che possono essere svolti da un dipendente, soprattutto da un operatore di una piccola filiale, sono numerosi. Mentre ad un operatore di un ufficio interno è richiesta una forte specializzazione verticale sul processo di competenza del proprio ufficio, un operatore di sportello, specie di una piccola filiale, primo contatto con la clientela, deve poter operare su tutti i prodotti; all’occorrenza deve poter fare operazioni su un conto corrente, un libretto di deposito, pagare un effetto, richiedere una carta di credito, vendere un titolo, istruire una pratica di fido o sottoscrivere una assicurazione. Per ognuno di questi processi esistono precise regole operative, normative aziendali ed esterne da rispettare, strumenti appropriati, informatici e non, da utilizzare.
Uno dei grandi vantaggi della nuova interfaccia web è stato non solo quello di poter mettere a disposizione degli utenti una selezione dei collegamenti agli strumenti e alle transazioni necessarie, organizzati per mansione, ma anche i collegamenti alla normativa, alle documentazione di processo e alle istruzioni operative per svolgere correttamente il proprio lavoro.

Segue ora una breve descrizione di alcuni delle applicazioni sviluppate con le tecnologie web per automatizzare alcune delle fasi dei processi operativi della Banca di Ospedaletto e di Banca Malatestiana.

Tutte le applicazioni non necessitavano di autenticazione in quanto il sistema era integrato con il dominio di rete Microsoft Windows della banca per cui il riconoscimento dell’utente e l’assegnazione delle relative autorizzazioni di accesso erano automatici.

Interfaccia CGI per conversione web programmi COBOL
Il sistema informativo gestionale bancario utilizzato dalla banca, il SIBI, era scritto con il linguaggio di programmazione COBOL che di per se, con la versione del compilatore disponibile nel 1994, non disponeva di funzioni e comandi per gestire l’output in formato HTML ma grazie al sistema operativo OSF/1 – Digital Unix del sistema DEC Alpha 2100, che disponeva di un deamon http e grazie alle tecniche CGI fu possibile costruire pagine HTML che accettavano parametri in input, li passavano ai programmi COBOL il cui output veniva poi reindirizzato in uno stream ed incapsulato all’interno di codice HTML, generando così pagine web dinamiche.
In questo modo era possibile lanciare report ed estrarre informazioni dal sistema gestionale direttamente dalla intranet aziendale.

Rimessa contante
Per ridurre il rischio rapina, presso le filiali non poteva essere trattenuto denaro contante oltre un certo importo. Quando questo importo veniva superato il contante doveva essere trasferito tramite i corrieri addetti al trasporto valori presso il caveau centrale o presso una filiale che invece aveva ridotto le scorte di denaro liquido.
Il denaro non poteva essere trasferito liberamente ma era necessario prenotare il passaggio del corriere. Il corriere stesso non poteva trasportare contante oltre un certo importo a causa di limiti imposti dalla copertura assicurativa.
Per organizzare questo trasporto venivano effettuate una serie di telefonate tra le filiali, il caveau della sede banca, l’ufficio contabilità ed il corriere, e spediti fax verso l’ufficio del corriere e verso il centro di raccolta della valuta per riscontro delle somme trasmesse,
Compito dell’addetto al caveau era quello di verificare che i vari massimali non venissero superati, in particolar modo quello del corriere che, raccogliendo fondi nel suo percorso tra le filiali, anche se ogni rimessa effettuata era di piccola entità, poteva trovarsi ad un certo punto a dover trasportare un importo superiore al suo massimale.
L’applicazione “Rimessa contate” gestiva tutti questi aspetti. Quando una filiale doveva effettuare una rimessa di contante inseriva la richiesta nella procedura. Nella richiesta doveva essere indicato il viaggio del corriere e la destinazione della rimessa. La procedura verificava eventuali importi già impegnati durante lo stesso viaggio e, nel caso ci fosse la disponibilità, prenotava gli importi richiesti e, grazie all’interfaccia con il sistema Lotus Domino/Extrafax, inviava un avviso per posta elettronica al caveau e spediva per fax una distinta compilata automaticamente in tutte le sue parti al corriere ed al centro di raccolta valuta. L’addetto al caveau e l’addetto del servizio di contabilità generale della banca potevano tenere sotto controllo tutti i movimenti di valuta con apposite funzioni di interrogazione presenti nella procedura.

Deleghe
Il processo di lavorazione delle deleghe F23 ed F24 coinvolgeva diverse unità organizzative della banca, in particolar modo le filiali, l’ufficio incassi e pagamenti e la contabilità generale. Tra questi uffici venivano scambiate molte telefonate e contabili cartacee i cui dati dovevano essere reinseriti all’interno del sistema informativo gestionale. L’ufficio incassi e pagamenti doveva poi produrre i flussi da inviare verso la rete interbancaria e raccogliere ed elaborare i flussi di ritorno dalla stessa e confrontare gli esiti con quanto inserito dalle filiali.
Tutta la parte di scambio di comunicazioni tra le filiali e gli ufficio centrali fu trasferita su di una applicazione web scritta con linguaggio Microsoft Active Server Pages (ASP) eliminando così le telefonate e le contabili cartacee e la parte di elaborazione in uscita ed in entrata dei flussi verso la rete interbancaria e l’incrocio dei dati con quanto inserito dalle filiali fu gestita da un E.I. (Emulatore di Impiegato – vedi scheda 14.6)

SGR – Situazione Generale Rapporti
SGR era il nome di un report del sistema gestionale SIBI che riepilogava la situazione giornaliera della raccolta e degli impieghi della banca. Non tutti i rapporti venivano gestiti tramite il SIBI e lo stesso problema, addirittura accentuato esisteva anche con il sistema successivo, il SIB2000 in quanto le procedure estero e titoli erano esterne. Per poter presentare alla Direzione Generale e ai direttori delle filiali un riepilogo completo della situazione della raccolta e degli impieghi era necessario estrarre le informazioni da tutti i sistemi per ricomporre in un unico report. Questa operazione di raccolta delle informazioni venne automatizzata grazie ad un Emulatore d’Impiegato ed i dati raccolti, venivano riclassificati da una applicazione chiamata anch’essa SGR che presentava la situazione raccolta diretta ed indiretta, degli impieghi e della tesoreria, l’indice impieghi/raccolta e dei grafici che mostravano l’andamento mensile, lo scostamento da inizio anno e lo scostamento rispetto allo stesso giorno dell’anno precedente. I dati erano visualizzati per totale banca e per singola filiale.

Protocollo posta
Si tratta di una semplice applicazione per gestire il protocollo della posta in partenza ed in arrivo. In precedenza protocollo della posta era gestito centralmente dalla segreteria generale con un registro cartaceo e le richieste di un nuovo numero di protocollo, o di ricerca sul registro di una lettera ricevuta o spedita in precedenza, doveva fare richiesta in segreteria tramite una telefonata.
Con questa applicazione chiunque poteva richiedere autonomamente un nuovo protocollo o consultare il registro direttamente dal proprio posto lavoro.

Gestione magazzino
In quasi tutti gli uffici si tenevano dei registri per la gestione del magazzino di diversi articoli. Questi registri erano tenuti su semplici quaderni sui cui venivano annotati i carichi, gli scarichi e i saldi delle quantità e dei valori.
Fu scritta allora una semplice applicazione che permetteva di creare liberamente i registri di magazzino necessari. I registri potevano essere movimentati con operazioni di carico e scarico. L’applicazione registrava automaticamente la matricola dell’operatore che aveva eseguito il movimento e permetteva di consultare e stampare sia l’elenco dei movimenti che i saldi di ogni articolo.
Tra i vantaggi ottenuti con l’utilizzo di questa applicazione abbiamo la standardizzazione della tenuta dei registri e la possibilità di utilizzarli da ogni utente e posto lavoro abilitato

Registro autorizzazioni
Applicazione per la tenuta dei registri delle autorizzazioni di sconfinamento concesse dal Consiglio di Amministrazione della Banca e dal Presidente. In precedenza i due registri erano tenuti su dei libri cartacei che furono mantenuti in rispetto alla normativa vigente ma invece di essere scritti utilizzando la macchina da scrivere i fogli del registro venivano scritti dal programma. Il vantaggio dato da questa applicazione fu anche la possibilità di essere utilizzati da ogni utente e posto lavoro autorizzato, di produrre una adeguata reportistica e di consentire delle ricerche testuali sulle registrazioni inserite.

Processo del credito: CRBCC, Monitoraggio Monitoraggio con incrocio delle nuove iscrizioni in conservatoria con le anagrafiche della banca, Esito del CdA

CRBCC – Centrale Rischi della Banca di Credito Cooperativo – era un archivio in cui venivano registrate tutte le visure catastali richieste per i clienti della banca, le nuove iscrizioni al catasto, sia volontarie che pregiudizievoli, e le richieste di accertamento della Guardia di Finanza.
Questa applicazione era integrata con un mail-in Database di Lotus Notes utilizzato per automatizzare lo scambio di comunicazioni con il visurista e con un Emulatore d’Impiegato che automatizzava le ricerche delle persone segnalate nell’anagrafica rapporti della banca.
Quando un nuovo cliente si presentava allo sportello per l’apertura di un nuovo rapporto gli addetti di sportello consultavano questo registro per verificare l’esistenza di segnalazioni a carico del cliente

Esito del consiglio
Questa applicazione, ridenominata “Esito del coniglio”, come simpaticamente veniva chiamata la riunione del Consiglio di Amministrazione della banca, permetteva agli addetti fidi delle varie filiali di venire a conoscenza del risultato della fase molto importante del processo del credito, quella di delibera, con qualche giorno di anticipo rispetto a quando le stesse informazioni venivano pubblicate sul sistema informativo gestionale bancario. Generalmente l’esito delle decisioni sulle concessioni di credito prese durante la riunione del CdA della banca, sono attese con molta fretta, spesso con ansia, da parte dei clienti che ne hanno fatto richiesta e ciò mette molta pressione sui dipendenti delle filiali che si occupano della relazione con questi clienti. D’altra parte, la pubblicazione delle informazioni sulla fase di delibera, potevano avvenire sul sistema informativo solo dopo che gli addetti dell’ufficio crediti avevano sbrigato alcune sottofasi di tale processo, attività che richiedevano abbastanza tempo, anche in ragione della grande quantità di pratiche da lavorare. Ne consegue che il giorno dopo la riunione del CdA, i colleghi dell’ufficio fidi venivano subissati di telefonate per richieste di informazioni sull’esito delle pratiche da loro proposte, il che a sua volta comportava un ulteriore ritardo nel completamento delle fasi necessarie alla pubblicazione dell’esito sul sistema informativo.
Con questa applicazione fu possibile aggirare il problema e consentire agli addetti dell’ufficio fidi di rendere disponibili le informazioni richieste prima di aver completato tutte le fasi richieste dal processo e dal sistema informativo gestionale bancario.

Esito del Coniglio del: 10/02/2002

Filiale	Codice Fido	Pr. rich	Intestazione	Imp. rich.	Imp. deliber.	Differenza
Stato rich.	Data scad.	Tipo Rich.	Proponente	L. di credito	Tipo scad.
———	———	———	——————————-	————	————	————
10	12345678	25	Impresa F.lli Bandiera	100.000,00	80.000,00	– 20.000,00
APPROVATO	15/05/2002	xxxx	Paolo Rossi	Fidejussione	A revoca
———	———	———	——————————-	————	————	————
10	87654321	26	Carlo Bianchi	5.000,00	0,00	– 5.000,00
RESPINTO	20/08/2003	xxxx	Giuseppe Verdi	Fido in conto corrente	A revoca

Saldi contabili servizi
Procedura per il controllo di gestione e l’analisi della redditività di alcuni servizi della banca. L’applicazione era composta da tre parti:

Interfaccia per la gestione dell’impianto tabellare per la riclassificazione del piano dei conti (Web – Microsoft ASP + Microsoft SQL Server)
Estrattore dei saldi di contabilità (E.I. – Emulatore d’Impiegato – Microsoft Visual Basic + IBM Client Access)
Report (Web – Microsoft ASP + Microsoft SQL Server)

Dopo aver individuato gli elementi che contribuivano a formare il risultato economico di un servizio ed averli censiti all’interno delle tabelle del programma, si procedeva all’estrazione dei dati dal conto economico tramite transazioni di interrogazione dei mastri sul sistema gestionale SIB2000; le transazioni di interrogazione erano automatizzate tramite un Emulatore d’Impiegato (cfr. scheda 14.6)
I dati estratti e riclassificati venivano presentati tramite report presenti all’interno dell’applicazione.

Report da procedura di gestione del personale
Il processo di amministrazione del personale era supportato dall’utilizzo di una applicazione client-server residente su un PC che utilizzava una base dati su Microsoft SQL Server.
Alcuni dati gestiti dalla procedura erano utili, oltre che al responsabile dell’ufficio personale, ad altre funzioni aziendali, per cui venne realizzata una interfaccia web che consentiva alle persone autorizzate di accedere alla base dati del programma di amministrazione del personale tramite il sito intranet aziendale.
Tra le informazioni più utilizzate c’era il report contente i dati anagrafici dei dipendenti. Il report poteva essere configurato dinamicamente scegliendo i campi che si desiderava ottenere in output.
Un altro insieme di informazioni molto richieste erano i contatori di ferie e permessi dei dipendenti. Ogni dipendente poteva interrogare la propria posizione personale direttamente dalla intranet aziendale ed in questo modo si evitarono molte telefonate fatte dai dipendenti all’ufficio personale.

Profilo investitori fondi comuni
Programma di supporto agli addetti alla consulenza titoli delle filiali. Tramite un questionario a risposte bloccate si determinava il profilo del cliente per individuare quali potessero essere i prodotti finanziari più adatti da proporgli. Dopo aver compilato e confermato il questionario, l’applicazione calcolava un punteggio in base al quale veniva proposta una composizione ideale del paniere titoli adatto al profilo del cliente.

I risultati del questionario venivano archiviati e potevano essere confrontati in futuro per valutare se nel tempo era cambiata la propensione al rischio del cliente e per analisi statistiche di segmentazione della clientela per future azioni di marketing.

Paniere Titoli
Procedura per la gestione del listino di titoli trattati fuori mercato. Prima dell’automazione tramite questa procedura, la creazione del listino era una operazione complessa e costosa in termini di tempo. Il listino era distribuito alle filiale tramite dei file in formato Microsoft Excel compilati a mano dopo aver letto i dati dalle varie fonti disponibili. I file di Excel erano distribuiti per posta elettronica e quindi avevano solo valore indicativo e le operazioni di vendita dovevano essere confermate tramite telefonate per evitare di basarsi su informazioni obsolete.
L’applicazione Paniere Titoli automatizzò molti dei passaggi di compilazione del listino. Il processo di alimentazione partiva da alcune macro scritte sul terminale Reuters per estrarre i dati dei titoli e parcheggiarli su files di Excel. Questa operazione, quando era svolta manualmente era molto lunga motivo per cui ci si limitava ad estrarre solo pochi titoli. I dati estratti venivano dati in pasto ad una applicazione scritta con Microsoft Access per importare i file di Excel estratti da Reuters e caricarli su un Database Microsoft SQL Server. Dopo l’importazione l’operatore dell’ufficio titoli poteva intervenire sulla base dati per apportare le modifiche necessarie ed i dati erano immediatamente disponibili agli operatori di filiale tramite la intranet aziendale.
Essendo diventata molto veloce, fu possibile ripetere più volte al giorno l’operazione di aggiornamento del paniere, aumentando il numero di titoli inclusi.