Il blog di un CIO in outsourcing

Riprendiamo la carrellata sui processi FITS. 

Il change management è il processo per la gestione dell’attuazione delle modifiche all’infrastruttura ICT, è può quindi riguardare hardware, software o servizi, e la relativa documentazione.

Il suo scopo è quello di minimizzare il danno ai servizi di ICT causati dai cambiamenti, e di assicurare che le informazioni relative all’hardware, al software, ai servizi e alla documentazione siano tenute aggiornate.

Cosa genera un cambiamento?

Può essere il risultato di un guasto tecnico o di un problema infrastrutturale. In alternativa se si tratta di implementare un nuovo software o installare un nuovo hardware per rispondere ad una nuova esigenza funzionale, è necessario gestire l’attività con il processo di release management, discusso in un precedente post.

Alcuni esempi di cambiamento

• Upgrade hardware / software PC;
• Assegnare una licenza software ad un altro operatore;
• Installare nuova memoria RAM in un server;
• Aggiornare / revisionare la documentazione di una procedura;
• etc.

Cosa fare in sintesi?

• Assegnare ruoli e responsabilità;
• Preparare tutti i materiali necessari per il processo (regolamenti, moduli di richiesta cambiamento, etc.);
• Preparare tutti i partecipanti (dettagliare le operazioni del processo step-by-step);
• Impostare una data di inizio per il processo che permetta il tempo di prepararsi;
• Comunicare il piano al team di implementazione e informare gli utenti;
• Effettuare, se possibile, un cambio pilota prima come prova

E’ dura la vita del CIO vero? Allora “aiutati che FITS ti aiuta” …

Nelle puntate precedenti ho elencato brevemente i processi di “Service Desk” e “Incident Management”.

Altrettanto brevemente, per consentire una lettura agevole di questi post introduttivi, è necessario fornire una definizione del processo di Release management.

Release Management è il processo di progettazione, costruzione, test e deployment di un nuovo hardware e/o software. Implementa il controllo di versione e aggiorna l’inventario hardware/software. L’obiettivo che si pone, è quello di fornire un metodo, coerente e ripetibile, per la distribuzione di un aggiornamento / novità all’interno della preesistente infrastruttura ICT.

Grossa enfasi viene data alle fasi di pianificazione e di preparazione dei nuovi servizi.

Le aziende che utilizzano tale processo, difficilmente impattano in ritardi di progetto, in quanto l’approccio strutturato consente di definire in anticipo le risorse necessarie per la realizzazione dell’obiettivo, e nel contempo riduce al minimo gli incidenti che interessano gli utenti ogniqualvolta viene introdotta una novità.

Di seguito una figura riepilogativa delle fasi del processo.

Definita la politica di rilascio (fondamentalmente bisogna rispondere alle domande “quando e come?”), pianficato / sviluppato / debbugato il servizio / applicazione, la fase di rollout consiste nella distribuzione / installazione dell’aggiornamento, e nel test in work dello stesso, che riguarda sia aspetti tecnici, che funzionali (rispetto dei requisiti “funzionali” forniti dal committente).

Il processo si interfaccia con quello di “Change Management” (attuazione del piano) e con quello di “Configuration Management” (aggiornamento della “situazione” parco macchine e/o del catalogo dei servizi).

Riprendiamo la nostra carrellata sui processi / servizi da implementare per governare il reparto ICT utilizzando il framework FITS (The BECTA Framework for ICT Technical Support) sviluppato dalla British Eductional Communications and Technology Agency (basato su ITIL).

La gestione degli incidenti (incident management) è un processo definito per la loro registrazione e risoluzione.

L’obiettivo è quello di ripristinare un servizio andato giù, nel più breve tempo possibile. Ciò si realizza molto spesso mediante una correzione temporanea e/o soluzione parziale, piuttosto che con una soluzione permanente.

La ricerca di una soluzione definitiva ad un problema è compito di una altro processo, ovvero appunto la gestione dei problemi (problem management).

Le cose da fare per implementare tale processo sono, in estrema sintesi:

• Assegnare ruoli e responsabilità;
• Elaborare la documentazione necessaria agli utenti ed al Service Desk per operare;
• Preparare gli utenti, il Service Desk, e il personale di supporto tecnico (interno e/o esterno);
• Decidere in che modo il Service Desk deve eventualmente “scalare” gli incidenti ai tecnici;
• Implementare e testare un sistema di Knowledge Management (gestione della conoscenza) per una tempestiva condivisione e gestione di incidenti ricorrenti (necessario per l’individuazione dei problemi);
• Decidere come il sistema di Knowledge Management deve essere alimentato (dal Service Desk e/o dai tecnici e/o da entrambi);
• Definire un piano di comunicazione dettagliato per tenere aggiornati gli utenti durante tutto il ciclo di vita dell’incidente;
• …

I puntini sospensivi sono d’obbligo … ci sarebbe tanto da scrivere … appunto …

Iniziamo la nostra carrellata sui processi / servizi da implementare per governare il reparto ICT utilizzando il framework FITS (The BECTA Framework for ICT Technical Support) sviluppato dalla British Eductional Communications and Technology Agency (basato su ITIL).

Un Service Desk è un sistema di persone, processi e prodotti che si pone come interfaccia unica tra gli utenti e tutti i servizi ICT aziendali, e gestisce tutte le fasi della richiesta di assistenza. Le richieste che esulano dalle competenze dei suoi membri, vengono passate al fornitore e/o gruppo di persone in grado di risolvere il problema. Differisce da un help desk tradizionale in quanto supporta tutti i servizi ICT (anziché uno solo), semplificando la vita agli utenti finali ed il controllo della gestione ICT.

A quali problemi risponde un Service Desk?

A livello aziendale l’aumento del numero e della complessità dei servizi presi in gestione dal reparto ICT, produce i seguenti problemi:

• Tempi di attesa più lunghi per la risoluzione dei problemi, anche gestiti da fornitori esterni;
• Mancanza di condivisione della conoscenza;
• Gradimento dei servizi ICT scarso, con conseguente cattiva informazione e gestione dei problemi ad esso legati ("non funziona niente …" è un’affermazione troppo ricorrente, ed allo stesso tempo generica, che non contribuisce in alcun modo alla risoluzione di un problema).

Cosa fa un Service Desk?

In estrema sintesi è possibile affermare che un Service Desk svolge le seguenti attività:

• Registrazione incidenti, problemi e richieste di cambiamento;
• Risoluzione incidenti e problemi;
• Gestione dei cambiamenti;

(Diamo delle definizioni)

L’approccio è volutamente sintetico e allo stesso tempo incomprensibile, se non fornendo alcune definizioni.

In particolare è opportuno specificare che:

• un incidente è un evento imprevisto che causa l’interruzione di un servizio;
• un problema dipende da ragioni infrastrutturali. Tipicamente è un problema la causa di un incidente;
• un cambiamento è una qualsiasi modifica alla situazione attuale (AS IS).

(Facciamo un esempio)

Es. Richiesta di assistenza

L’operatore lamenta il fatto che il suo PC non va più in rete. L’analisi dell’incidente da parte del Service Desk individua che in effetti la porta fisica alla quale il PC è collegato, è raccordata su una porta dello switch che risulta bruciata (non funzionante). L’incidente si risolve utilizzando una porta libera dello switch.

L’incidente è: “Si è “bruciata” una porta dello switch.”

Il problema è: “Lo switch è obsoleto ed usurato.”

Il cambiamento è (sarà?): “Lo switch è stato (sarà?) sostituito.”

Come si realizza un Service Desk? 

I passi principali da seguire per implementare un processo / servizio del genere non sono pochi. Ovviamente ogni punto di seguito riportato, apre un capitolo che è necessario approfondire per produrre un risultato concreto e tangibile. L’elenco è quindi da ritenersi esemplificativo ma non esaustivo.

• Identificare i servizi / le applicazioni da prendere in carico;
• Identificare gli utenti / le attrezzature;
• Identificare il personale interno / esterno che dovrà gestire le richieste di assistenza;
• Identificare il luogo fisico del Service Desk;
• Documentare le procedure di inoltro delle richieste di assistenza in outsourcing (per i servizi esternalizzati) – Formazione del personale
• Documentare le procedure di inoltro delle richieste di assistenza al Service Desk – Formazione degli utenti;
• Formare il personale di supporto tecnico e gli utenti del Service Desk;
• Documentare le soluzioni a tutti i problemi noti;
• Documentare le soluzioni a tutti gli incidenti ricorrenti;
• Definire delle metriche per valutare l’impatto degli incidenti (priorità);
• Definire delle metriche per monitorare il carico di lavoro;
• Predisporre uno strumento per la registrazione delle chiamate;
• Predisporre un piano di comunicazione per il lancio del Service Desk;
• … etc …

Tanti altri step sono necessari. Primo fra tutti, la creazione di un database delle configurazioni (CMDB – Configuration Management Data Base). Tuttavia è più opportuno, a mio avviso, riportare tale azione nella To Do list da mettere in atto per implementare altri processi con i quali, inevitabilmente, il Service Desk si interseca.

Auspico di riuscire a presentare in futuro, sulle pagine di questo blog, un caso reale di realizzazione. Nel frattempo … spero comunque di esservi stato utile a fare un po’ d’ordine.

Governare l’ICT è compito del Chief Information Officer.

Per non perdere la bussola (e ridursi ad avere un ufficio simile alla foto) è necessario innanzitutto stabilire i principi sui quali fondare la gestione di quella che, il più delle volte, è una azienda nell’azienda. Se siamo fortunati (o sfortunati … dipende dai casi), tali linee guida ci vengono imposte da uno standard al quale dobbiamo semplicemente adeguarci. Sto pensando a tutte quelle aziende che hanno una qualche certificazione di qualità che comprende la gestione dell’ICT nel loro manuale.

Se siamo sfortunati (o fortunati … dipende dai casi) e queste linee guida dobbiamo dettarle noi che facciamo?

Come spesso accade non dobbiamo inventarci la ruota ma solo scegliere. Esistono infatti differenti framework (insieme di processi) di best pratice (azioni pratiche da compiere) specifici per la gestione ICT.

Information Technology Infrastructure Library (ITIL) è un insieme di linee guida ispirate dalla pratica (Best Practice) nella gestione dei servizi IT (IT Service Management) e consiste in una serie di pubblicazioni che forniscono indicazioni sull’erogazione di servizi IT di qualità e sui processi e mezzi necessari a supportarli.

Sebbene sia stato sviluppato negli anni ottanta, ITIL non è stato largamente adottato fino alla metà degli anni novanta. Questa più larga adozione e conoscenza ha condotto all’emissione di standard a supporto, incluso ISO/IEC 20000 (precedentemente British Standards | BS 15000), il quale è uno standard internazionale che ricopre molti degli elementi di ITIL per la gestione dei servizi IT.

ITIL viene spesso considerato a fianco di altri framework di best practice quali Information Services Procurement Library (ISPL), Application Services Library (ASL), Dynamic Systems Development Method (DSDM), Capability Maturity Model (CMM/CMMI), e viene spesso collegato con l’IT governance attraverso Control Objectives for Information and related Technology (COBIT).

L’IT Service Management in quanto concetto è relativo ma non equivalente a ITIL. ITIL contiene una sezione specificatamente dedicata all’"IT Service Management" (la combinazione dei volumi sul Service Support e Service Delivery i quali sono uno specifico esempio di un framework ITSM), è comunque importante evidenziare che esistono altri framework.

Alternative

Oltre ITIL, esistono altri approcci all’IT Service Management, quali The BECTA Framework for ICT Technical Support (FITS) che è stato sviluppato dalla British Eductional Communications and Technology Agency ed è basato su ITIL ma è più snello per essere adottato nelle scuole secondarie e primarie britanniche (le quali hanno spesso dipartimenti IT molto piccoli). Similmente, The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps dichiara di essere basato su ITIL ma di essere specificatamente focalizzato sul più grande degli elementi di ITIL quello di "dare valore ai soldi".

fonte: http://it.wikipedia.org/wiki/ITIL

Per chi volesse approfondire il discorso, la migliore risorsa online per ITIL in italiano, a mio avviso, è presente nel mio CIOROLL di fianco.

L’approccio utilizzato dalle alternative si adatta meglio a situazioni nelle quali le risorse, umane e tecnologiche, sono limitate. Tale condizione è tipica delle nostre PMI (o almeno di quelle al Sud).

“The Visible OPS Handbook”, redatto da ITPI (Information Technology Process Initiative, organizzazione no profit impegnata in attività di ricerca e sviluppo in ambito manageriale ICT), consiglia di implementare l’IT Service Management in 4 mosse:

1. Stabilizzare il paziente. Oltre l’80% delle interruzioni derivano da problemi organizzativi. Bisogna individuare, documentare ed analizzare i rischi dovuti ai cambiamenti e i processi per la gestione dei problemi, al fine di ridurre i tempi di ripristino di un servizio.
2. Prendere e lasciare. Spesso l’infrastruttura esistente non consente un miglioramento. Per esserne certi e capire cosa salvare, dobbiamo inventariare gli asset (hardware, software e contratti), le configurazioni e i servizi e decidere tempestivamente cosa salvare e dove investire.
3. Definire e documentare processi ripetibili. Creiamo processi ripetibili di gestione dei cambiamenti e dei guasti, per il maggior numero di asset e servizi.
4. Abilitare un continuo miglioramento. In questa fase costruiamo gli indici / metriche necessarie per consentire un continuo miglioramento e capire se stiamo raggiungendo gli obiettivi definiti con la Direzione (Controllo di gestione).

FITS (The BECTA Frameworkfor ICT Technical Support) implementa un sottoinsieme dei processi ITIL.

Di seguito un elenco:

1. Service Desk
2. Incident Management
3. Release Management
4. Change Management
5. Configuration Management
6. Problem Management
7. Availability & Capacity Management
8. Service Level Management
9. Service Continuity Management
10. Financial Management

Riuscire a implementare tali processi (che cercherò di descrivere in post futuri) / seguire queste best practice, che altro non sono che “buon senso schematizzato e applicato”, è quanto di più difficile si possa fare ma, al tempo stesso, è l’obiettivo che ogni responsabile ICT deve perseguire con forza e volontà.

E’ chiaro che la scelta del framework da adottare dipende dalla tipologia di cliente che si segue. Nel mio caso utilizzo spesso FITS … e voi?

Nelle famose riunioni di cui parlavo al seguente post, i nuovi progetti software si promuovono quasi da soli, in quanto derivano da esigenze manifestate dalla Direzione e/o dall’esperto direzionale. I progetti infrastrutturali, viceversa, sono quelli per i quali diventa difficile, se i rapporti non sono ottimali e/o se qualcosa è andato storto l’anno prima, stabilire l’importanza e l’urgenza.

Come agiamo allora?

Partiamo dall’analisi delle cause. Un progetto infrastrutturale è difficile da vendere internamente perché il management non vede l’infrastruttura, ma meravigliosi report (torte, pile, istogrammi, etc) che gli occorrono per concentrarsi sul proprio business, dimenticando, o non sapendo, tutto il lavoro che c’è dietro. E poi perché l’infrastruttura ICT, nonostante la progressiva riduzione dei costi dell’hardware e l’adozione di sistemi operativi con licenze open, soprattutto lato server, ha comunque un costo elevato in termini di ore/uomo necessarie per l’implementazione di architetture solide.

Pertanto non si tratta di essere più o meno entropici, perché per quanto possiate sforzarvi avrete di fronte persone che percepiscono solo i costi e non i benefici di ciò che state proponendo, e la maggior parte di esse non potrà mai capire veramente le infrastrutture (voi avete studiato tanto per farlo).

Se voi foste imprenditori, investireste in qualcosa che non capite e/o controllate? Credo di no … quindi spostiamo il focus della discussione … parliamo di soldi!!!

Presentiamo un caso aziendale comprensibile al Titolare e/o al Direttore esecutivo, evidenziando quali sono i benefici apportati al business in termine di riduzione dei costi e ottimizzazione delle prestazioni (e quindi di aumento della produttività).

Cerchiamo, ad esempio, di dimostrare che attuando il piano descritto nel progetto infrastrutturale che intendiamo far approvare, riusciremo a:

• Assicurare la business continuity e/o tempi di down dei servizi accettabili;
• Ottenere un risparmio sui costi;
• Migliorare la produttività;
• Mitigare e/o evitare rischi;
• Essere conformi a standard qualitativi;
• Etc.

In sintesi spieghiamo PERCHE’ bisogna procedere con l’investimento, e non COME.

Un buon punto di partenza può essere fornito dall’elencare i costi da sostenere in caso di un incidente implicante il dowtime di un servizio importante.

Solitamente vi sono:

• Costi fissi per la manutenzione e supporto nella gestione dell’attività;
• Costi NON fissi per la risoluzione del guasto (software / sistemistici);
• Costi NON fissi per la sostituzione di parti guaste (hardware);
• Costi indiretti legati alla riduzione della produttività;
• Costi incalcolabili, legati al morale del personale che utilizza i servizi per lavorare e/o PEGGIO, a quello dei clienti finali dell’azienda;
• Etc.

Ora dimostrate che il Vs progetto porta dei benefici che vanno in direzione opposta a questi costi e giustificano l’investimento. Se ci riuscite, allora avrete qualche possibilità di venderlo … in bocca al lupo!

Come ogni anno (a proposito buon anno), puntuali come un orologio svizzero, arrivano le riunioni di programmazione strategica.

L’aver condotto progetti di successo nell’anno che si è chiuso, aumenta la propria credibilità nei confronti del management. E’ sempre difficile raccogliere ed evidenziare correttamente i risultati ottenuti dai progetti svolti nell’anno precedente, il più delle volte per mancanza di tempo e di strumenti, tuttavia è necessario presentarsi a questi appuntamenti con una minima cognizione di causa (fosse anche solo una stima da confermare) di cosa si è fatto e sta funzionando, in quanto tempo, quanto è costato, e cosa bisogna ancora fare per “finalizzare il progetto”.

All’ordine del giorno di questo tipo di riunioni c’è sempre la definizione dell’AS IS, del TO BE e a volte anche del TO DO. Scorrono copiose, anno dopo anno, le dichiarazioni di buoni propositi, le innovazioni da implementare e le iniziative da intraprendere per controllare correttamente i costi e ottimizzare le risorse esistenti. Belle parole. Nei fatti bisogna gestire un portfolio progetti.

Come gestiamo il portfolio progetti?

Io utilizzo una combinazione di mappe mentali, in fase progettuale, e un foglio elettronico (Calc), in fase di rendicontazione. Raramente, purtroppo per mancanza di tempo e soprattutto di budget, WBS e GANTT.

Il template della mappa di base è all’incirca il seguente:

Il foglio elettronico che utilizzo per tenere traccia delle fasi, e monitorare l’andamento dei task, anche se cambia di volta in volta, raccoglie i seguenti dati:

• descrizione progetto;
• fasi;
• task;
• risorse utilizzate (personale interno, fornitore esterno, ruolo);
• periodo (il e/o da – a);
• note (mi annoto tutto, comportamento degli attori, problemi e successi);
• lista acquisti;
• gg lavoro stimati;
• gg lavorati;
• costo totale progetto;
• costo attuale.

Quando ho il tempo di utilizzare WBS e GANTT, da vero amante dell’open source quale sono, utilizzo GANTT PROJECT … ma questo è un altro post.

A progetto terminato, e servizio rilasciato, solitamente effettuo due azioni:

• un’indagine sulla soddisfazione degli utenti;
• una comunicazione con taglio dimostrativo (in realtà sono due, una rivolta al management, l’altra all’utente finale).

Ma anche questo è un altro post.

Alla prossima!