La transizione dei servizi applicativi

Ho avuto modo di spiegare tante volte in che cosa consiste un progetto di transizione, producendo negli anni un numero considerevole di slide ed è giunto il momento di condividere questo argomento con un post sul mio blog.

L’ambito di riferimento è ovviamente quello di un outsourcing, più precisamente di selective  outsourcing applicativo, cioè l’ipotesi di delegare le attività di gestione, di manutenzione e di evoluzione di un sistema software ad una entità specializzata. Per il cliente non è mai una passeggiata: si tratta spesso di scelte inevitabili dettate dalle condizioni di mercato che portano al tentativo di ridurre il costo dell’IT, considerata una commodity, meno frequentemente da soluzioni indirizzate da una chiara strategia.

La transizione, nel contesto dei servizi ICT di application management, è un progetto di change management con una precisa durata temporale, che ha lo scopo di portare un servizio da uno stato iniziale , generalmente chiamato Present Mode of Operations o PMO, ad uno stato finale denominato Future Mode of Operations o FMO, seguendo rigorose procedure per minimizzare i rischi e soprattutto per rendere il più possibile indolore il cambiamento agli utilizzatori finali del sistema.

Nel ciclo di vita del sistema applicativo lo “stato iniziale” di un servizio di application management può coincidere con:

• il rilascio di un sistema applicativo, generalmente noto come go-live, a valle di un progetto di implementazione;
• il cambio di strategia di sourcing del cliente, quando ad un fornitore di servizi ne subentra uno nuovo, interno o esterno, rispetto al business del cliente;
• l’introduzione nel servizio a regime di nuovi elementi non pianificabili, che possono essere dettati da normative alle quali il sistema deve conformarsi, nuove opportunità di business, una variazione organizzativa sostanziale.

Naturalmente ci possono essere altre cause che giustificano il cambiamento, ma per semplificare ho citato i casi più comuni.
ITIL Versione 3 (link) dedica alla Service Transition uno dei suoi 5 libri; non ho l’ambizione di fare altrettanto qui, ma di fornire qualche “pillola” sull’approccio.

Si parte con l’assessment: una fase interessante poichè ci serve a capire in quale ambito ci stiamo muovendo, quali sono gli attori coinvolti nel servizio, quale è il ruolo dell’IT rispetto al business dell’azienda. E’ in questa fase che si prepara il piano di comunicazione, elemento indispensabile per avere il giusto “committment” ed un ragionevole supporto da parte dei rappresentanti della comunità utenti. L’assessment è anche il momento giusto per produrre il piano di dettaglio delle successive fasi della transizione.

La fase di preparation vede protagoniste da un lato le infrastrutture di supporto al servizio che devono essere predisposte se non presenti, dall’altro la predisposizione fine del progetto con il gantt complessivo, le procedure operative, le matrici di responsabilità e la definzione delle metriche di controllo del servizio a regime. Questa fase è  parecchio complessa, perciò è opportuno avvalersi del supporto metodologico  offerto dalle linee guida di ITIL e dal CobIT. Le check list, i cicli di intervista ed un buon tool per pianificare e controllare le attività sono gli attrezzi di lavoro ideali per condurre questa fase.

Discovery è la fase dove si scoprono, letteralmente, le funzionalità del sistema applicativo, si intervistano i responsabili di processo, gli utenti, si ascoltano punti di vista differenti, si studia la documentazione.
Non è solo knowledge transfer; si analizzano anche i punti deboli del servizio preesistente (se esiste), si adattano le procedure operative agli inevitabili vincoli che ogni organizzazione porta con sè, dai cicli di autorizzazione, alla disponibilità delle infrstrutture e delle risorse.

Finalmente si è pronti ad erogare il servizio con la fase di shadowing. Questa fase ha la particolarità di essere divisa in due parti, denominate direct e reverse. In sostanza, si tratta di erogare il servizio secondo il nuovo modello (FMO) ma lo si fa fare agli attori del “vecchio” modello e si osserva (direct shadowing), per poi scambiarsi di posto (reverse shadowing) ripetendo la lezione e verificando se c’è ancora qualcosa da imparare o da mettere a punto. Tutto ciò avviene senza il rispetto formale dei livelli di servizio (grace period). Tutta l’infrastruttura di supporto al servizio è già operativa, per cui gli utilizzatori del sistema applicativo contatteranno un Service Desk, che aprirà loro un ticket sul tool di troubleticketing adottato, registrerà la segnalazione degli utenti, contribuirà a popolare la knowledge base ed a seconda della tipologia della richiesta di intervento, fornità una soluzione, oppure un aiuto funzionale, oppure scalerà la richiesta alla struttura predisposta a risolvere la segnalazione.
Un elemento troppo spesso trascurato è l’importanza di una corretta gestione della configurazione; il configuration management database (CMDB), o la definitive service library, (DSL) collezionano, storicizzano le domande e le risposte date, le modifiche apportate al sistema applicativo, le versioni dei rilasci e delle librerie di supporto. Narrano la storia della applicazione, attraverso la quale si può “leggere” l’evoluzione applicativa e di processo dell’azienda e suggerire modifiche organizzative, di processo o operative.

Nella fase finale, quella che chiude ufficialmente la transizione detta tuning, il ruolo della gestione della configurazione è centrale, poichè serve a mettere a punto le regole del servizio a regime, soggetto al rispetto formale dei livelli di servizio, aiuta a confrontare i volumi delle chiamate attese con i volumi a consuntivo, a valutare se la finestra temporale nella quale il servizio è erogato è sufficiente a coprire le esigenze degli utenti ed infine a verificare se il costo del servizio è proporzionato al beneficio reso.

La transizione, per concludere, è una parte essenziale del ciclo di vita di un sistema applicativo: è ricorsiva, nel senso che si può riproporre lungo la durata di un servizio ad ogni fatto che comporti un significativo cambiamento; è reversibile, in quanto le procedure seguite per mettere in opera un servizio possono essere riutilizzate per dismetterlo.

Stay Tuned.
Giovanni