La banca come Partner

Una Banca diversa in un mondo che cambia

In Europa l’orientamento verso strategie distributive di tipo multicanale sta diventando un modello di riferimento comune e condiviso tra le banche.

Tra gli addetti ai lavori circola ormai un’espressione molto efficace (click and mortar), per indicare questa compresenza di nuovi e vecchi canali commerciali nell’ambito della medesima struttura organizzativa. L’aspetto interessante è che sul versante click (ossia delle modalità che prevedono l’accesso alla banca tramite dispositivi che vanno da Internet alla televisione, dal telefono al computer palmare) il campo si stia allargando sempre più. Se fino a ieri per fruire di servizi bancari a distanza era necessario disporre di un personal computer collegato fisicamente alla rete Internet, oggi sono disponibili nuovi tipi di strumenti capaci di operare senza fili (wireless), per consentire al cliente la massima libertà di utilizzo, in qualsiasi condizione. Gli addetti ai lavori hanno salutato questi sviluppi come l’emergere di un nuovo modello di business, prontamente battezzato M-BANKING, dove M significa appunto Mobile.

In attesa dei prossimi sviluppi tecnologici, può forse valere la pena di svolgere qualche considerazione non solo sul concetto di multicanalità ma sul modo con cui i servizi finanziari vengono rilasciati. La tesi centrale di questo intervento, infatti, è che grazie alle tecnologie software oggi disponibili (e segnatamente allo standard XML ed ai WEB Services ) i tempi sono maturi per superare tale concetto, così come oggi viene inteso dalle banche di casa nostra, e non solo.

La multicanalità, in realtà, può essere considerata un caso particolare di una visione più ampia che, di fatto, distingue tra la fase di produzione e la fase di distribuzione dei servizi bancari. Per effetto di questa distinzione la banca si trova a gestire un insieme di relazioni multiple con una pluralità di attori, interni ed esterni, assumendo di volta in volta ruoli diversi: gestore dell’intero ciclo produttivo oppure distributore di servizi realizzati altrove oppure, ancora, outsourcer nei confronti di soggetti terzi, anche estranei al settore finanziario.

In Italia questa tendenza, che è stata prontamente battezzata contract banking, comincia a diffondersi nei principali gruppi bancari, con riferimento all’offerta di servizi che vanno dalla gestione di processi relativi all’infrastruttura tecnologica, al supporto amministrativo, al trattamento dei documenti contabili e così via.

La multicanalità comunemente intesa ricalca un modello simile a quello citato, nel senso che si presuppone che la banca si avvalga di canali distributivi più o meno sofisticati o innovativi, su cui essa esercita un controllo diretto. Se spingiamo lo sguardo oltre, emerge come tale modello di business sia limitativo: è invece la combinazione delle prestazioni d'opera di una molteplicità di “service factories” che permette di “costruire” offerte sempre più sofisticate e mirate a bisogni specifici. È l’idea della combinazione di servizi elementari in pacchetti complessi che può davvero “fare la differenza”. In altri termini, riuscire a creare composizioni variabili di servizi (e non esclusivamente finanziari) potrebbe voler dire vincere su un mercato sempre più competitivo.

Date queste premesse si evince come il “canale” non sia il solo elemento determinante per restare sul mercato, anzi il “canale” può essere considerato un caso particolare di un modello che prevede una catena di “business partners” intesi come “service integrators”, ciascuno specializzato e organizzato per operare in un particolare segmento.

I “service integrators” offrono essenzialmente prestazioni d'opera ad alto valore aggiunto pensate per classi di utenti accomunati da particolari interessi (tipicamente di business) che usufruiscono di un servizio organizzato a “package”. L’organizzazione che offre il “package” è, agli occhi delle varie “fabbriche di servizio” di cui si serve, un “business partner” (e non un canale) che rivende il prodotto di base in una veste del tutto nuova e con un target non specifico dei singoli fornitori.

Gli esempi di servizi complessi componibili come combinazione di servizi elementari sono innumerevoli e possono essere pensati per una serie molto vasta di realtà; si può spaziare da organizzazioni di tipo corporativo, a società in franchising, a gruppi chiusi di utenti, a realtà geografiche e così via.

Queste nuove opportunità dovrebbero apparire particolarmente appetibili per il mondo bancario in quanto, qualunque sia il progetto di servizio complesso ipotizzato, appare ovvio che una delle componenti di base è, nella maggioranza dei casi, il servizio di supporto finanziario.

Naturalmente questa transizione nel modello di business non è esente da problemi che in questa sede non verranno affrontati, come ad esempio: “di chi è il Cliente ?”, perché ci porterebbero troppo lontano. Pertanto ci limiteremo a prendere in esame le implicazioni di questi nuovi modelli sulle architetture informatiche.

Dalle esperienze in corso in tema di “multicanalità” e dalle esperienze relative alle modalità si osserva come una delle componenti chiave per il successo dei relativi progetti risieda nell’utilizzo di soluzioni software infrastrutturali che realizzano un disaccoppiamento tra i mondi delle “fabbriche di servizio” (tipicamente i sistemi legacy) e i nuovi gestori dei canali.

Tale disaccoppiamento può essere attuato mediante l’utilizzo di appositi “middleware” capaci di far colloquiare opportunamente i vari mondi, oppure mediante l’adozione di un modello standard che pubblichi e presenti i servizi attraverso una infrastruttura di tipo “business to business”.

Mentre nel primo caso il risultato che si ottiene è di tipo tattico il secondo approccio mette a disposizione un’infrastruttura che – proprio grazie alla evoluzione del concetto di interoperabilità - può rivelarsi molto interessante per mettere in pratica una visione più vasta del concetto stesso di multicanalità; la soluzione tradizionale prevede l’utilizzo di componenti software (più o meno sofisticate) che garantiscono l’interoperabilità dei vari mondi ma la sola interoperabilità non garantisce che i servizi esposti possano essere compresi, analizzati e riutilizzati facilmente anche da partners, a priori, ignoti.

Il concetto di multicanalità viene quindi esteso verso un più sofisticato e interessante concetto di “multiservizio in ambiente multicanale”.

I Web Services sono una risposta alle esigenze emerse da questi nuovi modelli di business e dalle richieste di migliori performances applicative nate dalla prime esperienze relative ad applicazioni di e-commerce o, in termini più ampi, di “web based applications” . Essi sono la naturale evoluzione delle prime esperienze relative alla integrazione di servizi eterogenei offerti su piattaforme web.

Questa architettura tecnologica vuole essere una risposta alle maggiori sfide che la generazione precedente di tecnologie non sono state in grado di soddisfare. Nonostante il loro nome, l’architettura Web services, non riguarda il problema di connettere persone tramite i siti Web. L’attenzione viene focalizzata sulla interconnessione diretta di applicazioni e strutture dati sulla base di standard consolidati e su tecnologie ben note; l’obbiettivo è quello di garantire che applicazioni e dati siano fruibili in maniera diretta e senza “logica intermedia” da parte di altri applicativi in maniera indipendente dalla distribuzione dei medesimi e della sottostante infrastruttura tecnologica che li supporta.

L’idea base è quella di riproporre in ambito inter-applicativo la stessa facilità d’uso, la medesima ubiquità e la facile disponibilità che il paradigma del Web ha proposto e brillantemente risolto in ambito interpersonale o tra applicativi ed utente finale. Il punto chiave di questa nuova architettura è quello di creare un forte disaccoppiamento tra le diverse risorse applicative così che esse possono essere rese disponibili in una vasta serie di contesti, possano essere accedute in modo estremamente dinamico e non pre codificato su diverse piattaforme e su diverse risorse distribuite geograficamente.

“Disaccoppiare” vuol dire che la connettività non è specifica alle funzionalità offerte dalle risorse applicative che vengono accedute ma ciascuna risorsa applicativa è intrinsecamente disponibile ad essere utilizzata (e riutilizzata) nei contesti più ampi, non precodificati e sulla base dei servizi di base insiti in qualunque infrastruttura tecnologia che sia in grado di ospitarla.

In risposta a queste sfide possiamo dire che quattro principi fondamentali hanno modellato la definizione della architettura dei Web services:
 

• Semplicità: ridurre al massimo la complessità agli estremi delle connessioni per rendere più facile e meno costoso per ciascuna componente applicativa offrire i propri servizi alle altre componenti e allo stesso tempo per ciascuna componente facilitare l’accesso alle altre componenti in modo da arricchire e completare la propria offerta sulla base di quelle già disponibili e testate.
   
• Disaccoppiamento: costruire una infrastruttura modulare ove ciascuna componente possa utilizzare ed essere a sua volta riutilizzata da altre componenti senza richiedere però che tutte le possibili connessioni tra le varie componenti siano preventivamente stabilite prima che qualunque servizio applicativo sia reso disponibile. Le connessioni vengono stabilite ed utilizzate su una base di un concetto di “per necessità” quando richiesto dal contesto applicativo e vengono liberate appena non sono più necessarie. Questa logica garantisce la opportuna gestibilità e scalabilità del sistema.
   
• Eterogeneità: supportare il numero più ampio possibile di piattaforme tecnologiche su cui le varie componenti applicative possono risiedere.
   
• Apertura: garantire un solido e ben noto framework su cui sviluppare il nuovo standard come semplice evoluzione di standards già largamente usati nella architettura più ampiamente disponibile (internet) .
   

Oggi sono disponibili piattaforme che supportano l’ infrastruttura Web Services in modo nativo, perfettamente integrata con le infrastrutture tecnologiche preesistenti, e pronta per ospitare una innumerevole serie di servizi applicativi.

“Software come servizio” è il paradigma su cui si stanno impostando le nuove realizzazioni presso una infinità di utenti finali ed il medesimo paradigma viene utilizzato dagli ISV per rendere più appetibili i propri prodotti. Ripensare in ottica di Web Service un package tradizionale vuol dire che le logiche applicative del package stesso vengono rese fruibili per altre componenti software così che esso stesso può concorrere a creare una catena a valore aggiunto.

Pensare al “Software come servizio” vuol dire ripensare profondamente ai modelli di progettazione del medesimo, al modello di “vendita” interna e sul mercato, alla allocazione dei “budgets”, alla gestione dei progetti, al modo di sviluppare al modo di mantenere il patrimonio informatico aziendale.

Gli standards ed i protocolli sono elementi critici di successo nella fruibilità di applicativi sviluppati sulla base della architettura Web Services. Questi standards di base vengono, o è prevedibile che verranno, corredati, sulle varie piattaforme, da un insieme di altri servizi “abilitanti” che concorrono a comporre una “service grid” di supporto il cui scopo è quello di rendere gli applicativi basati su questo standard ancor più appetibili sia per i consumatori che per i fornitori.

Proprio la disponibilità a tempi brevi ed a costi bassi di tutto un insieme di servizi di supporto ai Web Services sarà, in definitiva, un buon modo per monitorare il “successo” di questo nuovo modo di pensare il “software” in tutti i suoi aspetti.

E’ prevedibile che quattro categorie di servizi “abilitanti” emergeranno sulle varie piattaforme che supportano i Web Services.
 

• Service management: Questi servizi supportano la gestione e la configurazione di “application services” garantendo che essi soddisfano predefiniti livelli di servizio.
   
• Resource management: Questi servizi di supporto garantiscono che i vari servizi applicativi possano interagire a livello di meta definizione con altri e che eventuali discrepanze possano essere risolte a livello di processi di trasformazione intermedi.
   
• Transport management: Questi servizi abilitanti di supporto hanno lo scopo di offrire del valore aggiunto nel processo di interazione tra le varie componenti applicative gestendo complessi meccanismi di routing applicativo, di orchestrazione e di filtro.
   
• Shared utilities: Questi servizi abilitanti di supporto nascono con lo scopo di supportare al meglio un modello di business organizzato a componenti riusabili, gestendo i processi di accounting basati su un concetto di “service fee”, sulla offerta di controllo della sicurezza di accesso ed altro.
   

Come si evince i Web Services, sebbene siano un modello di sviluppo e di “delivery” dei servizi software ancora giovane, sono perfettamente maturi per essere considerati come una ottima piattaforma su cui focalizzare la propria attenzione nello sviluppo di nuovi servizi, e cosa ancor più interessante nel contesto di progetti reali, sono estremamente validi in un ottica di riingegnerizzazione di processi già noti.

Appare evidente il concetto che il rilascio di servizi applicativi sotto forma di Web Services ben si sposa con un ambiente di lavoro (consumatore di tali servizi ) organizzato secondo una logica operazionale che tende a responsabilizzare l’utente finale nella definizione di un servizio complesso a priori non codificato come composizione dinamica di servizi elementari ben noti.