Delocalizzatori selvatici.

E’ avvenuto un disastro in una banca inglese, e un paio di amici mi hanno chiesto un parere “tecnico”. Premesso che la mia esperienza nel mondo bancario risale ad anni fa, credo che dopo una breve spiegazione sul meccanismo che si e’ inceppato (CA-7) , alcune considerazioni sulle condizioni di contorno di cio’ che si e’  inceppato e sul come, ovvero gli effetti nefasti della delocalizzazione dei servizi, siano il massimo che posso fare.

Un poco di background “pseudotecnico” su come lavorano alcuni sistemi bancari. In moltissime banche -anche se non in tutte, specialmente negli USA- non lavorate MAI sul conto corrente vero. Immaginate di avere un sistema fatto ad anelli concentrici.  Nell’anello interno si trova il vostro “vero” conto, mentre nell’anello esterno si trova una copia aggiornata da un sistema di code ad intervalli regolari.

Di fatto, nei lavori di ogni giorno, quello che fate e’ di lavorare sulla copia “esterna” del vostro conto, quella esposta alla rete della banca. Spesso ne esiste anche una copia ancora piu’ esterna, nel senso che alcune banche creano un nuovo snapshot per le operazioni tipo bancomat diversi da quelli della banca stessa , o operazioni da home banking. Ma e’ una cosa rara, per banche molto paranoiche.

Quando voi fate una qualsiasi operazione, quindi, agite sul conto “esterno”. Ma non e’ che alla sera il conto esterno venga copiato cosi’ com’e’ verso l’interno: sarebbe inutile. Quello che succede e’ che aggiornate il conto “esterno”, e producete la medesima operazione come copia dell’operazione eseguita (prelievo, deposito, assegno versato, etc). Periodicamente  la sera il sistema si trova in una condizione dove c’e’ il conto esterno, la coda di operazioni uguali a quelle eseguite durante il giorno sul conto “esterno”, infine i dati del  conto vero.

La coda viene prima “spazzolata” da un software antifrode, che essenzialmente riconosce alcune delle frodi in corso. Per esempio, se e’ in corso una frode con una serie di carte di credito rubate, e sta avvenendo che ci siano 30.000 prelievi da 21.76 euro , tutti uguali, provenienti da estero, potrebbe esservi bloccato un prelievo in coda (avvenuto materialmente o meno) , per essere messo in una coda “manuale”.

Si controlla lo stato del conto “esterno”, per verificare che non siate troppo giu’ col fido (perche’ e’ stato incassato un assegno) e non abbiate quindi sfondato un limite, per poi decidere se mettere i batch in questione in una coda che richieda l’intervento umano (cioe’ un tizio vi chiama per dirvi che siete fuori).

Fatto questo, finalmente (di solito la notte, ma alcuni hanno intervalli diversi) si processa questa coda ovvero un grosso mainframe esegue sul conto “vero” , e se il risultato e le checksum quagliano con quelle del conto “esterno” tutto procede, altrimenti si torna come prima e si segnala il problema.

Ovviamente si tratta di un modello macchinoso che e’ l’opposto del “tempo reale”, ma d’altro canto le banche hanno requisiti di sicurezza non indifferenti, e tutto questo sdoppiamento non fa altro che garantire sicurezza. Ovviamente produce qualche inconveniente, tipo il fatto che gli interessi si pagano calcolandoli dal conto “interno”, l’unico che puo’ produrre interessi, e quindi se versate oggi un assegno dovrete aspettare che il batch venga processato per iniziare a godere degli interessi.  Idem per le code che provengono da altre banche, per le quali e’ previsto un passaggio di controlli supplementari.

Per tenere queste code si usano diversi sistemi , preferiti quelli su  IBM che ha una vasta esperienza , come CICS, ma anche di altri produttori, come SAP , BULL, ed altri ancora, come CA tech.

Che cosa succede se un gestore di code si blocca? Succede essenzialmente che sparisce la possibilita’ di agire sul conto esterno perche’ non potete accodare operazioni -condizione perche’ si eseguano sul conto reale- e tenete conto che anche l’estratto conto E’ una operazione (a volte viene fatto pagare) (1)quindi se si blocca un sistema di code potrebbe succedere che non riusciate nemmeno a VEDERE il conto sul vostro home banking.

Una cosa simile, usando a volte sistemi analoghi, si fa nel mondo telco quando si sdoppano HLR e VLR, anche se l’intento e’ diverso. In ogni caso l’idea e’ quella di disaccoppiare mediante un meccanismo asincrono la realta’ da un frontend, sul quale lavorate effettivamente.

Ovviamente ci sarebbe ancora molto da scrivere, sul modo in cui questo risultato viene ottenuto dai vari sistemi, ma in pratica quanto successo in UK e’ sovuto all’ “incepparsi” del meccanismo che regola i batch, cioe’ che porta le operazioni in una coda ove vengono eseguite una ad una in separata sede. (2)

Come avrete capito, a  NatWest (la banca inglese inchiodata per giorni) e’ successo che si sia inceppato il meccanismo.PEr il resto, la varieta’ delle implementazioni di questi processi e’ tale che quanto ho scritto e’  una spiegazione concettuale, che vuole esprimere il disaccoppiamento, o l’asincronia, con la quale si opera negli ambienti con una  necessita’ di sicurezza molto alta.

Qualcuno potrebbe malignare sul confronto tra CICS e il CA-7, ma non e’ cosi’ sensato. E’ vero che IBM abbia un’esperienza consolidata a riguardo, ma il punto e’ un altro: il servizio fu delocalizzato.

Questo e’ un punto su cui ho scritto in passato, per una semplice ragione, ovvero il fatto che se nel mondo dell’industria si sono misurati alcuni vantaggi nel processo di delocalizzazione, e’ stato sinora IMPOSSIBILE misurare -e non esiste alcuna pubblicazione  a riguardo che si basi su “hard facts” – misurare la convenienza delle delocalizzazioni nel campo dei servizi.

Esistono grandi sostenitori della delocalizzazione dei servizi diversi dalla mera produzione, ma sebbene si leggano molte pubblicazioni a riguardo, quando si cercano delle prove o dei “fatti numerici” riguardanti la loro convenienza, tutto quello che emerge e’ “l‘autore la pensa cosi’, e’ un docente, e nessuno dei suoi studenti osera’ mai contraddirlo“.

Di base, l’idea di outsourcing si basa su un preciso design dei processi, che deve conservare lo know how dalla parte dell’azienda che delocalizza, inviando la “bieca produzione” in una nazione diversa. Questo implica una stretta osservanza di alcuni SLA, e una netta separazione tra i processi di gestione della conoscenza.

In pratica, se volete costruire un’auto e delocalizzate un intero processo, anziche’ una semplice funzione, tutto quello che farete sara’ di insegnare a qualcun altro a costruire auto. Una buona delocalizzazione manda le carrozzerie in una nazione, il motore in un’altra ancora, le componenti avanzate magari rimangono in casa, e l’assemblaggio finale preferibilmente in una terza nazione, magari limitrofa. Usando tutto nella stessa nazione, la cosa da fare e’ usare stabilimenti molto grandi. Altrimenti il risultato e’ una delocalizzazione/capestro, perche’ non appena chiuderete lo stabilimento -alla fine del progetto- , il governo locale interverra’, o qualcuno lo comprera’, e vi troverete un concorrente con le vostre tecnologie in mano.

Se l’industria ha imparato la lezione abbastanza in fretta -ormai solo gli sprovveduti delocalizzano la produzione “one-bulk” – la catastrofe arriva dal mondo dei servizi.

Innanzitutto, l’esigenza di mantenere in casa lo know-how rende molto difficile delocalizzare servizi. Si possono delocalizzare facilmente servizi a basso know-how, come per esempio gli helpdesk, ma delocalizzare completamente un’azienda del terziario e’, detto come va detto, cercarsi i guai.

Ci hanno provato molte telco, e tutte hanno fallito. Apparentemente il fallimento e’ stato chiamato “transiction management”, ovvero “abbiamo mandato i servizi in India al preciso scopo di farli chiudere”. Si e’ detto, cioe’, che siccome spegnere un servizio telco (dismettere un contratto migrando gli utenti su altri contratti) e’ un lavoro oneroso che rende poco, l’ideale era di farlo in outsourcing in India.

Questo e’ assolutamente vero: in questo caso, l’ India e’ un posto prezioso per far morire il servizio. Avete inventato un contratto per il cellulare , che so io, “30 ore a tre euro, e gratis il venerdi’ all’Una”. Avete cosi’ racimolato due milioni di utenti che poi sono migrati sponeaneamente su altri servizi, tranne centomila che per pigrizia rimangono con quel contratto. Tenere in piedi una gestione per centomila contratti da tre euro e’ insensato, cosi’ volete migrarli. Dovete solo chiamarli uno ad uno per convincerli, oppure calcolare i loro consumi, simulare una tariffa piu’ conveniente e cambiar loro contratto con uno migliore -per evitare conseguenze legali-.

Siccome e’ un lavoro che alla telco non rende soldi, se non la possibilita’ di dismettere una serie di calcolatori dedicati alla tariffazione di quel contratto, (3) e’ sensato mandarlo in India. Il lavoro di “uccidere” servizi e contratti, detto anche “Transition Management”, e’ uno dei servizi che potete anche delocalizzare.

Ma si tratta, in pratica, dell’ UNICO tipo di servizi per i quali esiste una letteratura di “casi di successo”. Nel resto dei casi, si dovrebbe parlare di una letteratura di “casi di disastro“.

Esistono molti manager che, per motivi di carriera, sostengono di poter delocalizzare un servizio a valore aggiunto, quando non un servizio “core business”, senza avere la minima conoscenza dei processi di delocalizzazione, di gestione del know-how, di gestione della delocalizzazione. Essi si bulleranno di aver “ridotto i costi”, e agiscono PER MERI MOTIVI DI CARRIERA.

Sul terzo pianeta del sistema solare, la delocalizzazione di servizi core business  nel terziario ha prodotto SEMPRE disastri, con la sola eccezione del transiction management, ovvero dei servizi di cui si voleva curare la FASE TERMINALE in vista di nuovi servizi. Chiunque , specialmente manager, affermi il contrario e’ semplicemente UN VENDITORE DI FUMO a scopo di carriera o un accademico in cerca di visibilita’.

Il motivo per cui si producono disastri e’ semplicemente legato alla necessita’ dell’entita’ cui delocalizzate di ottimizzare il lavoro. Supponiamo per esempio di delocalizzare un servizio come il batching di una banca.

Inizialmente, chi prende la commessa e’ deciso a prenderla a tutti i costi, e non puo’ fallire durante la fase di migrazione. Siete strategici e quindi vi dedicheranno le migliori risorse, e avrete un sistema sovradimensionato a disposizione. (se va bene).

In seguito, voi imporrete uno SLA . Questo SLA , Service Level Agreement, (che diventa un OLA se l’azienda che avete aperto in India e’ vostra al 100%, o giu’ di li’) non fa altro che definire il livello minimo di servizio.

Si passa quindi ad una seconda fase: se nella prima si e’ fatto tutto il possibile, nella seconda si fa “solo” tutto l’indispensabile , ovvero quanto richiesto dal contratto.

Nella terza fase, quando ormai l’outsourcing e’ praticamente irreversibile, iniziano i problemini. Per il risk management, un problema non e’ solo un pericolo, ma un’opportunita’. Inoltre, siccome si fa pagare al committente un servizio di on call duty (persone reperibili che ricevono allarmi e intervengono), occorre mostrare che siano utili.

Questo significa che l’equilibrio perfetto tra outsourcee ed oursourcer e’ cosi’:

  • Il servizio si svolge da remoto, pur avendo un continuo monitoraggio ed un continuo reporting riguardo all’ SLA.
  • Il servizio e’ aderente allo SLA, tranne un certo numero di incidenti, risolti comunque nei termini dello SLA, e tali da giustificare il contratto di supporto reperibile.

Da tale equilibrio non si esce: non appena il sistema rispetta molto bene lo SLA, piu’ del richiesto,  sul sistema si caricano servizi piu’ complessi: si dice che “c’e’ ancora spazio”. Ci si ferma solo quando si nota che la qualita’ inizia ad arrancare. D’altro canto, se gli SLA vengono rispettati molto piu’ del necessario, l’ outsourcer opera dei tagli per risparmiare, sino a scendere al mero SLA.

In definitiva, quindi , l’outsourcing di servizi si trova in una condizione per la quale se anche il committente non carica ulteriormente il sistema quando SLA e KPI sono “overperformed”, ci pensa l’outsourcer a fare saving dal suo lato, peggiorando la performance sino al minimo richiesto dal contratto SLA.

Se dite questo ad un economista, lo trovera’  deliziato: una “mano invisibile” sembra “tendere all’efficienza”.

Se lo dite ad un architetto di sistema, mi si arricciano i capelli: overfitting sullo SLA!

Che cos’e’ l’overfitting sullo SLA? E’ un problema delle infrastrutture in outsourcing, che consiste in un processo di adattamento dell’infrastruttura alla mera condizione contrattuale,  per il quale NESSUNA condizione straordinaria o imprevista potra’ mai essere coperta dall’infrastruttura.

In questa condizione, si verifica che:

  • Non esiste MAI un piano B nel caso di fallimento. In tal caso, ogni migrazione va alla perfezione O NON VA.
  • Non esiste altro spazio nell’infrastruttura nel caso una condizione imprevista si verifichi. Non avete piu’ personale (gia’ sfruttato al 100%. Il tecnico fa gia’ straordinari, non puoi chiedere altro tempo) , non avete piu’ rete, niente di niente.

Voi direte: ma non puoi scrivere nel contratto che ci sia il piano B ed il tecnico a disposizione? Nel caso di migrazione, siamo in fase progetto, e non BAU.(Business As Usual). Quindi, difficilmente potrete chiedere qualcosa se non dal budget del progetto. Nel secondo caso, potete anche chiedere il sovradimensionamento di ogni cosa, ma difficilmente l’outsourcer lasciera’ le migliori risorse inutilizzate o sottoutilizzate: il contratto conterra’ sempre e comunque un qualche imbroglio sulla qualita’ delle risorse.

Ovviamente non sono sul posto, e non posso sapere cosa di preciso stia avvenendo alla banca inglese. Dire che sia successo questo e’ difficile, senza esserci dentro. Ma questo e’ esattamente tutto quel che mi viene in mente se mi dite “outsourcing nel terziario”.

Posso dire una cosa: la notizia dell’outsourcing  NON mi ha riempito di stupore.

Uriel Fanelli, 26 giugno 2012

(1) Inoltre e’ un’informazione che ha valore, dunque va protetta e l’accesso va tracciato.

(2) la sede puo’ davvero essere separata, nel senso che puo’ capitare in alcune situazioni di estrema sicurezza che il calcolatore che processa le code venga sconnesso dall’esterno mentre le esegue, e poi rimesso in rete l’indomani, o altre misure simili, tipo il trasporto delle code su un calcolatore molto distante, o su piu’ di uno per confrontare i risultati.

(3) Si, l’architettura delle reti telefoniche e’ cosi’ complessa che il contratto commerciale fa parte del protocollo di trasporto. Questo perche’ c’e’ un apparato dadicato che controlla che voi abbiate ancora i soldi per fare la telefonata che state facendo. Il che significa: la telco inventa un nuovo contratto, ergo mette giu’ qualche calcolatore in piu’.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *