ZeroUno: Il progetto di Slm che ha visto protagonista Axa è assimilabile più a un servizio rivolto a utenti interni o a quello offerto da un fornitore a clienti esterni
Matteo Marzotto: Ritengo che questo caso esemplifichi bene le problematiche che si devono affrontare in termini di servizio sia per quanto riguarda la gestione di un certo livello di conflittualità sia il livello di complessità dei sistemi. Chi si trova ad affrontare l’impostazione di un sistema di misurazione e di successiva gestione dei livelli di servizio deve inevitabilmente, come Axa, fare i conti con alcune resistenze e affrontare la necessità di cambiamento culturale e di processo, che sono una costante nella maggior parte dei progetti, insieme alla complessità architetturale, diventata ormai abbastanza fisiologica. L’aspetto preliminare, a prescindere dal settore in cui si opera, è gestire il cambiamento dal punto di vista culturale e il cambiamento dei processi produttivi interni della funzione It che vengono inevitabilmente toccati.
In realtà la differenza fra cliente interno ed esterno non è così marcata: in entrambi i casi è necessario definire bene a chi ci si rivolge e quali siano le sue necessità. Il primo passo è dunque identificare il cliente che si deve servire e quali siano i servizi da erogare. Tuttavia questa impostazione, abbastanza ‘normale’ per un fornitore di outsourcing tecnologico verso i propri clienti, difficilmente viene adottata in relazione a utenti interni. Normalmente infatti una funzione interna eroga agli utenti i servizi (applicativi, di consulenza, studi di fattibilità…) in modo destrutturato e non formalizzato.
Sarebbe invece necessario non solo definire i livelli di servizio, ma anche effettuare una mappatura puntuale del portafoglio applicativo, che in una realtà complessa (come quella di Axa) può richiedere molto tempo e comporta anche un cambiamento culturale nell’approccio della funzione sistemi informativi ai servizi.
Il successivo passaggio fondamentale è ricostruire la filiera produttiva del servizio erogato. Se si vuole realizzare un sistema che oltre a misurare il livello di servizio aiuti a anche a effettuare diagnosi efficienti sui malfunzionamenti, è inevitabile ricostruire preliminarmente i segmenti di filiera che servono per produrlo. Agire in modo proattivo significa infatti ridurre il più possibile i tempi di diagnosi dei malfunzionamenti del sistema e aver strutturato una serie di procedure operative di risposta che consentono di correggere l’anomalia nei tempi concordati all’interno degli Sla.
Fatto questo lavoro preliminare e concordati con i clienti i livelli attesi, si deve infine verificare cosa comporti il garantirli. Si deve, per esempio, comprendere cosa significhi portare dal 98% al 99% la disponibilità di un’applicazione; quali siano gli impatti a livello di skill e di investimenti economici; cosa comporti a livello di fabbrica produrre questo incremento delle prestazioni.
ZeroUno: Un aspetto particolarmente qualificante del caso Axa è rappresentato dall’inclusione della user experience
Marzotto: È una tendenza in atto. Storicamente i sistemi di service level management erano legati alle componenti tecnologiche che producevano i servizi: esistevano strumenti per il monitoraggio della rete, dei servizi sui server e per il management della postazioni di lavoro. Tuttavia difficilmente i vari sistemi di monitoraggio venivano integrati per verificare il livello di servizio percepito dall’utente finale. L’evoluzione del Slm comporta invece la garanzia del rispetto dei livelli di servizio fino al livello dell’utente finale. Ma per fare ciò è indispensabile la presenza della componente tecnologica, senza la quale una serie di attività non sarebbero perseguibili.
Esistono a questo proposito due problematiche. La prima è legata al configuration management: non può esistere un sistema integrato di monitoraggio dei livelli di servizio laddove non sia gestita in modo strutturato la gestione delle configurazioni (a partire dall’asset management). Il secondo aspetto è l’integrabilità di questi strumenti con gli altri sistemi di monitoraggio. Il sistema così come l’abbiamo descritto (end-to-end, proattivo…), per consentire un livello di intervento diretto presuppone che tutti i sistemi di monitoraggio siano integrati e si parlino tra loro.
Integrare tutti questi sistemi per misurare la user experience non sempre è facile. In alcuni casi è necessario sviluppare internamente dei middleware per rendere omogenee le informazioni che arrivano dai diversi sistemi di rilevazione e renderli disponibili in modo integrato in cruscotti di gestione. Questo ultimo aspetto di integrazione, insieme all’analisi sui processi di produzione dei servizi, è l’aspetto più critico sia a livello di risorse impegnate sia di fattibilità del progetto.
ZeroUno: Una volta messo a punto un sistema di monitoraggio con le caratteristiche descritte chi dovrebbe essere a suo parere il protagonista del monitoraggio: chi fornisce il servizio o chi lo utilizza?
Marzotto: La scelta dipende dai principi di governance interni; ma è chiaro che, laddove la funzione sistemi informativi interna si esponga nel definire livelli di servizio con le funzioni utenti, è inevitabile andare nella direzione di assegnare a chi utilizza il servizio anche il controllo. In ogni caso andrebbero definiti nell’accordo (più o meno formalizzato) gli strumenti di misurazione. Questo passo non è affatto scontato: infatti, spesso contratti di servizio dettagliatissimi non indicano poi gli strumenti di misurazione né assegnano la responsabilità del controllo.
È comunque necessario rendere trasparente l’esito della misurazione mettendo a disposizione direttamente gli strumenti o andando a produrre una reportistica periodica. Questi progetti vengono poi generalmente accompagnati da rilevazioni sulla customer satisfaction o da survey sul livello di servizio percepito per andare a individuare, accanto alla misurazione, i processi di miglioramento continuo della prestazione. È ovvio che se i livelli di servizio stabiliti non vengono raggiunti l’evidenza crea conflittualità, ma aiuta anche a raggiungere razionalità nella valutazione delle azioni della funzione It.
TRE REGOLE IMPORTANTI
I messaggi che Matteo Marzotto vuole lanciare a un’azienda che intenda implementare un sistema di gestione degli Sla sono 3.
1. Questi progetti non possono nascere da un’implementazione tecnologica, ma devono essere trainati da un cambiamento che riguarda innanzi tutto il livello culturale e poi i processi interni. Lo sponsor dovrebbe dunque essere cercato a un livello piuttosto alto visto che devono cambiare le relazioni fra chi produce il servizio e chi ne fruisce.
2. Quando si parte con un progetto di Slm e si vanno a definire i livelli di servizio, l’unico responsabile deve essere la funzione It interna, che deve diventare l’unico centro di responsabilità rispetto al livello di attuazione del livello di servizio, mentre non è accettabile ribaltare la responsabilità del mancato raggiungimento dello Sla su eventuali fornitori esterni. Ciò comporta che l’analisi sui processi di produzione venga estesa a tutta filiera di fornitura del servizio.
3. la tecnologia è indispensabile per attuare progetti Slm in un ambiente complesso. Alla base del progetto c’è un’evoluzione culturale, innanzi tutto, e poi dei processi e delle procedure interni, ma se non esiste l’automazione, resa disponibile dagli strumenti tecnologici, questo tipo di procedure in sistemi complessi non sono attuabili.
