Punto e Virgola, periodicamente e con cadenza irregolare, offre ai lettori inserti di approfondimento in merito ad alcuni temi di particolare interesse.

Lo Speciale di questo numero di Settembre è stato elaborato dalla Segreteria di Coordinamento della Fisac Cgil San Paolo.

 

Sistema Informativo

San Paolo.

Seconda Puntata

 

A circa un anno di distanza eccoci nuovamente a parlare del sistema informativo del San Paolo. Nello speciale del marzo ‘96 spiegavamo perché questo strumento non funzionasse: oggi ripercorriamo le strade che hanno condotto agli ultimi eventi esprimendo le nostre valutazioni in merito a questo tema.

 

Prologo

Il collega sanpaolino che fosse particolarmente dotato di memoria, nei lunghi periodi di ozio che gli derivano da cadute di linea e tempi di risposta potrebbe forse ricordarsi di aver sentito vagamente parlare, un paio di anni fa, di un nuovo sistema informativo aziendale.

Se il collega fosse anche dotato di inusitate capacità speculative, oltre che di memoria, potrebbe forse domandarsi cosa ha prodotto questo nuovo sistema, eventualmente formandosi l'opinione di essere rimasto, lui, uno dei pochi sfigati che operano con carrette informatiche funzionali come una nave albanese.

Vorremmo anzitutto confutare l'interpretazione buonista di questo ipotetico collega: nelle sue condizioni ci sono rimasti pressochè tutti, in quanto le realizzazioni del nuovo piano che sono andate in produzione non erano di quelleno centrali, la cui ricaduta benefica può essere di massa e quindi visibile.

Noi non ne sappiamo molto di più del collega qualunque, però qualche notiziola ve la possiamo fornire, con una avvertenza: se fra i nostri lettori c'è qualcuno di quei colleghi super- tecnici del settore, passi ad un altro articolo; infatti, poichè noi non siamo tecnici, né super né poco, scriveremo di seguito un certo numero di imprecisioni, che speriamo verranno scusate.

Partiamo quindi con la nostra piccola storia.

 

Piccole storie

ACQUA PASSATA Il piano di sviluppo del sistema informativo aziendale, elaborato sul finire del 1994, era estremamente complesso e mirava ad ottimizzare il ritorno dei capitali da sempre investiti in informatica, creando un supporto informativo adeguato alle esigenze di sviluppo della banca.

In sintesi il piano prevedeva:

- rifacimento o aggiornamento delle procedure con contemporanea unificazione delle stesse; come sappiamo era stata fatta la scelta di "migrare per procedure" ovvero di unificare le tre ex-reti mano a mano che una nuova procedura unificata veniva rilasciata.

- ridistribuzione dei sistemi di elaborazione centrale su tre poli: Moncalieri - Grandate - Settimo, specializzati funzionalmente.

-ridisegno completo della tecnologia di filiale prevedendo la sostituzione del parco macchine e, soprattutto, l'adozione di una architettura innovativa consistente in posti di lavoro intelligenti, reti locali e stazioni serventi che potessero gestire archivi, l'integrazione con la rete geografica ed eventuali risorse tecnologiche condivise all'interno della filiale.

Sappiamo come alcune di queste previsioni siano state superate dai fatti e parlare di tripolarità dell'elaborazione centrale oppure di migrazione per procedure fa oggi una certa tenerezza.

In queste nostre note vorremmo occuparci in particolare di uno dei punti chiave di tutto il progetto, ovvero della nuova architettura di filiale che viene denominata "piattaforma di filiale".

LA GRANDE SCELTA Si tratta ovviamente di decidere cosa si vuole, vedere se esiste sul mercato e scegliere il fornitore. Per fare ciò erano state contattate nel 1995 le aziende leader del settore ricercando una soluzione globale, ovvero una azienda che fornisse tutto il pacchetto. L'analisi di mercato aveva coinvolto 16 aziende, di queste solo tre avevano presentato un progetto completo: IBM, Microsoft e Olivetti.

- IBM architettura tecnologica OS/2 completa, relativamente a server, client server e communication server. Ovviamente la scelta di IBM garantiva una grande integrazione con l'attuale sistema centrale (IBM), per contro la strada proposta prevedeva la conversione totale a OS/2 senza tappe intermedie e convertendo anche le filiali che attualmente utilizzano già diversi server di comunicazione; quindi si trattava certamente di una strada molto complessa.

- Microsoft architettura tecnologica Windows NT completa, con ipotesi di utilizzare poi eventualmente Windows 95. Questa scelta garantiva una maggior gradualità ed aveva alle spalle tutta la forza di Microsoft, forse non era del tutto chiara in tutti i suoi aspetti.

- Olivetti architettura mista con server Unix Olivetti, client Windows 95, comunication server Unix OLivetti attualmente in uso. Questa soluzione garantiva maggiore continuità con il passato consentendo anche di salvaguardare alcune architetture esistenti; per contro si trattava di una soluzione più "di attesa" nella quale alcune componenti , quali Windows 95, non ancora disponibili sul mercato a quella data.

La portata della scelta era veramente grande, tanto che furono necessari parecchi mesi per effettuarla. Infine l'Istituto decise di adottare IBM OS/2.

 

ENIGMI Tanto la struttura concettuale delle reti locali quanto la sua scelta concreta possono prestarsi ad alcune considerazioni critiche.

Reti locali Si tratta di un grosso passo avanti rispetto alla configurazione attuale che vede ogni terminale collegato al sistema centrale, infatti la rete consente di utilizzare le potenzialità dei Personal Computer condividendo risorse locali quali le stampanti laser, nonché di accedere ad applicazioni residenti su di un server locale.

Si tratta quindi di un concetto di forte decentramento sulla rete, che va ovviamente tarato; ovvero bisogna capire bene quanto si intende decentrare in termini di memorie e di elaborazioni periferiche.

E' un concetto sicuramente innovativo e vincente per quando è stato pensato, ma con i tempi di realizzazione del nostro sistema informativo diverrà operativo più o meno per fine secolo; vale quindi forse la pena di chiedersi se il concetto di potenziamento della rete continui ad essere strategicamente vincente, oppure non si dia il caso che già questa configurazione nasca superata.

Si tratta probabilmente di una domanda molto accademica, ma con la velocità di evoluzione del settore informatico, l'espandersi di strumenti nuovi ed in parte inesplorati quali Internet, l'interesse che questa detta per il suo utilizzo anche come office automation, ecc., forse si tratta di una domanda anche lecita, non fosse altro per la mole dell'investimento che l'Istituto vi produce.

Tutto ciò senza citare la propensione delle banche ad esplorare i canali di distribuzione telematici (banca telefonica, Internet ecc.) il cui sviluppo ed utilizzo una qualche connessione dovrà pur avere con la configurazione del sitema informativo che regge la rete di vendita tradizionale, ammesso che tutto ciò rientri in una strategia coerente presente al Sanpaolo.

Analisi di mercato Il sistema OS/2 è presente da anni sul mercato ed è considerato stabile e tecnologicamente avanzato ma è altresì definito un prodotto di nicchia, in quanto diffuso in modo ampio solo nel settore bancario ed assicurativo; la quota di mercato detenuta da OS/2 al momento della scelta (1995) era quantificata dagli osservatori del settore nel 5%, con una previsione per il 1999 calante al 0.8% in favore soprattutto di Windows che, in pari periodo, avrebbe avuto un trend dal 75 al 88%.

Con una situazione di questo genere si dava come abbastanza plausibile il fatto che IBM, gravata da considerevoli perdite economiche generate da OS/2, avrebbe rivisto la propria strategia commerciale, abbandonando a Microsoft il campo delle piattaforme e concentrando i propri sforzi nel settore delle infrastrutture Middleware (supporto indispensabile alla distribuzione di applicazioni nelle reti Client/Server) nel quale è in possesso di strumenti leader di mercato.

Questo voleva dire in pratica non certo l'abbandono della commercializzazione del prodotto, ma il ridimensionamento degli investimenti per il suo sviluppo; di conseguenza il mercato era favorevole al mantenimento da parte degli utenti degli investimenti in essere in OS/2, ma era molto cauto relativamente ad investimenti da effettuare ex-novo. Le stesse considerazioni di mercato, rovesciate, davano molto favorevole la posizione di Microsoft.

La scelta effettuata dal Sanpaolo è quindi andata controcorrente rispetto all'andamento del mercato. Va ribadito, ad onor del vero, che OS/2 è sì un prodotto di nicchia del mercato bancario ed assicurativo, ma che molte primarie banche Europee l'hanno adottato e che in Italia la medesima scelta è stata effettuata da grandi aziende italiane. Così come non si può certo mettere in dubbio la capacità di IBM nel supportare la clientela primaria.

Il vero nodo resta forse quanto i produttori indipendenti di software siano propensi a supportare un prodotto a limitata diffusione come OS/2, rispetto a prodotti di massa come Windows; si tratta del problema, squisitamente commerciale, con il quale è stata costretta a fare salati conti IBM, e con il quale sarebbe opportuno cercare di capire quali conti dovrà fare il Sanpaolo.

 

Piccole storie crescono

E' ARRIVATA LA BUFERA L'avvento dell'Ing. Barberis come responsabile delle tecnologie informatiche ha segnato un periodo breve ma denso di rivolgimenti.

Oltre ad essere il primo manager della nostra azienda preso dall'esterno, Barberis è stato anche il primo a farsi supportare da consulenti tecnici "personali" presi dal mondo universitario; precisamente dal Politecnico di Torino e dal M.I.T. di Boston.

Alcuni risultati di questo impegno sono sotto gli occhi di tutti: grazie a loro abbiamo capito che ipotizzare tre poli di elaborazione centrale era una costosa sfida all'ignoto (tutti hanno un polo più un secondo di back-up) e che i tempi della migrazione per procedure ci avrebbero portato nel 2000 con tre sistemi informativi distinti. L'impegno però non si è fermato qui e si è profuso anche nei riguardi dell'argomento che stiamo trattando, ovvero della nuova architettura informativa di filiale, ovvero del nocciolo teorico del problema: cosa vogliamo decentrare alla filiale in termini di memorie ed elaborazione, con quali rischi e con quali capacità da parte nostra di governare i processi.

Anche in questo caso i professori pare abbiano elargito consigli improntati al più solido buonsenso. Si dice abbiano fatto rilevare che ipotizzare soluzioni avveniristiche basate su elaborazioni locali oppure decentramenti spinti degli archivi, tendenti a sgravare l'Host di parte del carico (teoricamente con la configurazione a rete l'Host potrebbe addirittura scomparire), sarebbe stato un azzardo pericolosissimo.

Questo in considerazione della nostra totale inesperienza in fatto di gestione di configurazioni a rete, dopo trent'anni di gestione di un hardware centralizzato.

Quindi, piede premuto sul freno e avanti a passetti piccolissimi

Dato il dinamismo che caratterizza la nostra attività progettuale, ci mancava ancora questo consiglio!

 

TORNA IL SERENO Terminata la parentesi Barberis sono rimaste le scelte di prudenza ed è rimasto da mettere in pratica il nuovo piano informatico.

Dato che sono passati due anni dalla sua genesi, che le scadenze come 2000 ed Euro sono più vicine, che i problemi da soli non si risolvono, anzi in genere peggiorano,ecc., serpeggia in azienda un clima di certa tensione quando si parla di informatica. Va anche detto che quando si parla di informatica con gli utenti (colleghi) il clima che serpeggia è di un certo imbufalimento.

Forse entrambe queste sensazioni sarebbero un pò mitigate se, nel corso del 1997, fossero rilasciate in modo tangibile almeno alcune parti del piano, vuoi sotto il profilo architetturale, vuoi sotto il profilo procedurale.

Grande attivismo si è notato sul finire del 1996 per la predisposizione, il varo e la spiegazione al popolo del nuovo organigramma interno del S.S.I che si proponeva come la soluzione ad alcuni dei problemi organizzativi che frenavano il decollo delle iniziative. Organigramma sicuramente rivoluzionario in alcuni suoi aspetti ed in gran parte condivisibile. Terminato l'effetto annuncio, però, non abbiamo riscontrato un granchè di nuovo rispetto alla risoluzione dei problemi.

Forse di sereno ne è tornato un po' troppo.

 

ENTERPRISE CASE Non è la nave stellare del capitano Kirk, bensì la definizione tecnica degli strumenti di sviluppo che sono indispensabili in una architettura a tre livelli elaborativi (Client-Server-Host). La complessità di una tale architettura richiede degli strumenti molto più sofisticati di quelli solitamente in uso, che siano in grado di unire lo sviluppo alla esecuzione.

Detto in modo molto pedestre lo strumento consente a chi sviluppa l'analisi di scrivere contemporaneamente il programma, oltretutto con un risultato finale che diventa indipendente dall'architettura sulla quale viene calato.

Nel nostro caso quindi si è fatto bene a dotarsi di un tale strumento, in quanto l'indipendenza delle procedure dalla architettura è fondamentale, tanto più alla luce delle difficoltà che abbiamo incontrato nella scelta della piattaforma.

Lo strumento adottato è HPS della SEER Technologies, leader di mercato.

Peccato che ogni rosa abbia le sue spine. Questi tools di sviluppo richiedono un consistente sforzo finanziario ed organizzativo per arrivare ad un corretto utilizzo dello strumento. Tradotto vuol dire che, dato che c'è e costa tanto, bisogna usarlo; anche se non si è proprio tanto capaci, non ci piace, non riusciamo ad adattarlo agli altri protocolli in essere ed alla fine, dopo tanta fatica, cosa ne esce non va bene. Alla finfine sta succedendo che c'è e serve a poco, ovvero c'è e costa solo tanto.

Soprattutto sta succedendo un'altra cosa spiacevole: la SEER è ovviamente molto gelosa e non spiega niente a nessuno del proprio prodotto. Così quando c'è un problema, cioè tutti i momenti, devono intervenire i consulenti SEER costosamente presenti a Moncalieri in pianta stabile. Soprattutto non si sta facendo assolutamente nulla per creare un minimo di competenze diffuse all'interno del San Paolo, mentre la SEER, al contrario, può estendere altrove le esperienze fatte con noi.

Dopo trent'anni di affidamento dell'hardware centrale all'IBM le nostre scelte tecniche dipendono dalle scelte degli uffici commerciali IBM.

Fra quanti anni le nostre scelte tecniche sullo sviluppo dipenderanno dagli uffici commerciali SEER?

 

COSA FATTA CAPO HA Così dovette pensare Barberis quando gli spiegarono le nostre pensate in merito a piattaforma e tool di sviluppo.

Dato che abbiamo già deciso e soprattutto speso, cerchiamo di usare al meglio quello che abbiamo: quindi migriamo, affrontiamo 2000 ed Euro, usiamo HPS, riequilibriamo il rapporto fra addetti interni ed esterni, cerchiamo di non imbarcarci in avventure strane.

Cosa ne sia uscito dal punto di vista architetturale è difficile dire, visto che i lavori sono ancora molto lontani dalla conclusione. Forse qualche cosa si comincerà a vedere con la migrazione BPL, che dovrebbe avvenire con il nuovo communication server (ma con la vecchia architettura): almeno una prima chiavetta si girerà e staremo a vedere.

Certo non aspettiamoci balzi nel futuro, visto il taglio prudenziale che è stato dato al problema.

Questa nostra piccola trattazione si è incentrata sulle questioni architetturali, tralasciando il non meno importante aspetto del rifacimento delle procedure.

La nuova architettura di filiale è infatti elemento essenziale per poter distribuire il nuovo TP di sportello che, per la molteplicità degli aspetti che va ad investire, viene più correttamente denominato Nuovo Ambiente di Filiale.

Tutti gli aspetti procedurali sono di importanza fondamentale e sono forse di più appetibile trattazione, per la loro maggiore immediatezza; ci ripromettiamo pertanto di tornare in seguito sull'argomento, con considerazioni mirate a tale ordine di problemi. Poiché, però, una casa si costruisce dalle fondamenta, torniamo alla nostra piattaforma.

 

ENIGMA Riprendiamo i tarli che ci rodono da alcuni paragrafi.

Reti locali La più volte citata scelta di giustificata prudenza porterà ad una configurazione non troppo dissimile nei contenuti pratici da cosa avviene adesso; ci riferiamo sempre a chi e dove elabora, cosa elabora, come scorrono le informazioni, dove sono archiviate. Date le dimensioni del Sanpaolo la scelta è forse giusta, ma allora bisognerebbe non annettere un'importanza troppo fideistica alla nuova piattaforma come toccasana di tutti i mali.

Probabilmente se miglioramento ci sarà, sarà largamente dovuto alle procedure, di cui oggi sappiamo poco, piuttosto che all'architettura.

Si pone quindi la domanda se l'enorme investimento che si dovrebbe produrre nel nuovo sistema informativo sia stato mirato bene in ogni suo aspetto, cioè se alle risorse umane ed economiche dedicate all'architettura corrispondano benefici proporzionali, ed idem per le procedure.

Non sapendolo è lecito dubitare.

Analisi di mercato Si è verificato con millimetrica precisione quanto i maggiori analisti mondiali del mercato informatico avevano previsto nel 1995.

IBM ha perduto la guerra con Microsoft per il predominio nel settore delle piattaforme; le risibili quote di mercato possedute ormai non lasciano altra via a IBM che ricollocare i propri prodotti con destinazione la rete e non il client.

Nessuna dichiarazione ufficiale, per carità, ma una serie di iniziative commerciali non lasciano oggi più dubbi agli analisti, in quanto IBM sta spingendo i propri potenziali clienti ad adottare server OS/2 con clienti Windows, cioè OS/2 diventa un supporto per soluzioni di rete diverse.

Quindi OS/2 non è più strategico per IBM, quindi non verrà più sviluppato, quindi avrà sempre meno "appeal" sui produttori di software da cui dipendiamo per innumerevoli prodotti.

Niente di tragico, naturalmente, solo che la strada si fa sempre più in salita.

 

Enigma

Il finale resta rigorosamente aperto, poiché la nostra piccola storia è tutt'altro che conclusa.

Possiamo solo ipotizzare uno degli scenari possibili, quello che non vorremmo mai vedere.

Quello nel quale una grande azienda di punta in un settore che sta per subire una ristrutturazione epocale, una azienda che necessita con urgenza di una profonda ristrutturazione del sistema informativo che le consenta di mantenere la propria posizione sul mercato, sbaglia l'investimento più importante e resta al palo.

Questa azienda potrebbe essere il Sanpaolo e chi ne pagherebbe le conseguenze saremmo tutti noi.

Possiamo sperare nella capacità degli uomini e delle donne del Sanpaolo per scongiurare questo epilogo?

Questo lo ignoriamo, quindi dubitare è lecito.