Il blog di un CIO in outsourcing

Mediante il processo di Financial Management (“gestione finanziaria”) si vogliono fondamentalmente monitorare due cose:

• i costi per la fornitura dei servizi ICT (es. elettrici, hardware, software, canoni linee, etc.);
• i costi di supporto tecnico.

Registrare correttamente i costi sostenuti per l’erogazione dei servizi ICT aziendali aiuta a:

• creare un bilancio dedicato;
• migliorare il processo di budgeting;
• identificare i costi non preventivati;
• individuare i costi che sono stati superiori alle previsioni;
• individuare la causa dei costi;
• identificare le aree di possibile riduzione dei costi;
• applicare un modello di controllo dei costi.

L’implementazione del processo segue il flusso in figura (dalla stessa è possibile banalmente desumere l’interazione di questo processo con quello di Service Level Management)

To do list

• Analizzare le metodologie per ridurre i costi ICT;
• Analizzare periodicamente l’offerta del mercato ICT;
• Standardizzare e razionalizzare l’infrastruttura ICT;
• Applicare economie di scala per gli acquisti;
• Formare gli utenti per un corretto utilizzo delle apparecchiature e dei servizi ICT;
• Migliorare il processo di incident management per ridurre il numero di interventi dei fornitori esterni;
• etc.

Con la presentazione del processo di “gestione finanziaria” di FITS, si conclude una veloce carrellata in merito ad un framework di gestione ICT, che non aveva alcuna pretesa di essere esaustiva.

Esaustiva è solo la pratica.

Spero di poter riuscire a trovare in futuro il tempo per mostrarvi come ho attuato FITS sui miei clienti (intendo step-by-step e con quali strumenti).

Service Continuity Management (“gestione della continuità del servizio”) è il processo mediante il quale si pianificano i piani di emergenza da attuare in casi di eventi catastrofici che dovessero compromettere seriamente, e/o mandare “down”, servizi ICT. Implica in primo luogo l’analisi dei rischi e l’implementazione di contromisure per ridurre al minimo la probabilità di tali eventi.

Il processo segue il workflow in figura

To do list

• Identificare i servizi
  I servizi sono “infrastrutture” ICT a disposizione degli utenti, a differenza delle apparecchiature hardware | software che lo assemblano / compongono, quali connessione internet, email, stampa, erp, etc.;
• Identificare gli asset
  Un asset sono i componenti che implementano il servizio. Es. hardware, software, linee dati, database, contratti con i fornitori, etc.;
• Identificare i rischi
  Pensate a tutto ciò che può danneggiare un servizio ICT. Es. attacco virus, allagamento, caduta linea dati, guasto, sabotaggio, mancanza di energia elettrica, etc.;
• Identificare le minacce
  Considerate quanto sia probabile che accada un evento, valutando ad es. i sistemi di sicurezza in essere;
• Implementare le contromisure
  Per quanto possibile riducete il numero di minacce ad es aumentando il livello di sicurezza, programmando le manutenzioni, monitorando i possibili colli di bottiglia e/o punti di failure, creando backup di sistemi, etc.;
• Realizzare i piani di emergenza
  Siate pronti ad affrontare gli eventi disastrosi, implementando opportuni piani di backup & recovery.

Quanto costa la business continuity?

E’ una domanda alla quale è difficile fornire una risposta, in quanto il costo può variare in funzione di diversi fattori, in particolare:

• Investimenti
  Necessari per l’acquisto di asset di backup, di consulenza per la definizione dei rischi e dei piani di emergenza, per l’acquisto di infrastrutture esterne, etc.;
• Persone
  Varie sono le figure che ruotano nell’ambito della definizione dei piani dei rischi / backup / recovery;
• Tempo 
  La quantità di tempo necessaria per l’implementazione di tale processo, sarà direttamente proporzionale al grado di maturità di altri processi visti in precedenza (la sequenza dei post di presentazione di FITS non è casuale).

In generale il costo della business continuity dei servizi dovrebbe essere controbilanciato dal valore aggiunto dello stesso e/o dal potenziale costo che si registrerebbe in caso di guasto.

Ho già parlato di questo argomento in un vecchio post ("Come si vende un progetto di infrastruttura ICT ?" ), e lo farò in futuro.

Il processo di Service Level Management (“gestione del livello di servizio”) ha come obiettivo quello di garantire che tutti i servizi ICT (connessione internet, fonia, email, software gestionale, etc.) siano mantenuti “up” per un “periodo accettabile”.

L’estensione di tale periodo definisce il “livello” del servizio.

E’ in pratica il processo che disegna il trade-off (compromesso) tra capacità e disponibilità.

Tale compromesso va sottoscritto in accordo con tutte le parti, tipicamente:

• Direzione;
• Responsabili di reparto;
• Una rappresentanza degli utenti finali;
• Fornitori esterni.

Esempio

La Di Mauro srl ha un’officina dislocata presso una sede distaccata. In virtù della complessità dei servizi ICT offerti dalla sede centrale, in ambito di disegno dell’architettura di rete, si è optato per una Virtual Private Network, implementata su firewall di proprietà aziendale, al fine di garantire il collegamento tra le due sedi.

I punti di failure, in un contesto del genere, sono:

• Connessioni internet;
• Hardware di rete (firewall, router, switch, etc.).

Vista l’assoluta necessità di mantenere il collegamento VPN sempre “up” durante le ore lavorative, si sono presi accordi con alcuni fornitori di hardware sul territorio, e si è deciso di dotarsi due linee XDSL per sede, una primaria e una di backup. Si sono poi presi SLA (Service Level Agreement – Accordi sui Livelli di Servizio) con il provider di connettività, del tipo:

• Caduta collegamento primario => “up” backup in 1 ora + Risoluzione guasto in 8 ore;
• Caduta collegamento primario + backup => Risoluzione guasto in 5 ore.

To do list

Di seguita una immagine riepilogativa della To do list da attuare per implementare il processo

I passi sono i seguenti:

• Documentare e concordare i servizi (catalogo dei servizi) con la Direzione / Responsabili di reparto;
• Far accettare e pubblicare i livelli di servizio in funzione delle capacità aziendali;
• Definire e attuare i contratti con i fornitori esterni;
• Monitorare e rivedere livello di servizio periodicamente.

La “gestione della disponibilità e delle capacità” viene implementata in ITIL mediante l’utilizzo di due processi distinti.

Obiettivo del processo di “gestione della disponibilità” è quello di garantire che i servizi ICT abbiano downtime (tempo di malfunzionamento) bassi, soprattutto nelle ore necessarie.

Anche questo processo risulta essere caratterizzato da una fase proattiva, ed una fase reattiva:

• proattiva – progetto del availability plan (piano di disponibilità);
• reattiva – attuazione del recovery plan (piano di recupero), il cui scopo è quello di essere di ausilio all’individuazione ed alla risoluzione dei problemi che si verificano;

Obiettivo del processo di “gestione delle capacità” è quello di aiutarvi a garantire che i componenti delle infrastrutture ICT siano in grado di supportare i servizi richiesti.

Esempi di capacità sono:

• spazio su disco per l’archiviazione di file;
• potenza di elaborazione;
• memoria;
• banda minima garantita;
• etc.

Questo processo risulta essere caratterizzato prevalentemente da una fase proattiva, che comporta la pianificazione della crescita necessaria di capacità, in funzione del cambiamento dei servizi / SLA, e l’individuazione di problemi di capacità potenziale (prima del loro verificarsi).

Tuttavia ci sono due temi comuni alla gestione delle disponibilità e a quella delle capacità: il rilevamento e la prevenzione. FITS razionalizza e semplifica l’approccio di ITIL, sulla base di questa comunanza, esemplificando due sotto-processi.

Monitoraggio di rete (Network monitoring)

Monitorare la rete vuol dire rilevare tutte le attività in essere, e l’impatto che le stesse hanno sull’infrastruttura. Monitorare le capacità, i picchi di richiesta / uso, ricercare punti di failure e/o colli di bottiglia, sono tutte azioni incluse in questo sotto-processo che può essere sintetizzato nella figura che segue.

Manutenzione programmata (Preventivate Manteinance)

La manutenzione programmata (o preventiva) è incentrata sull’utilizzo intelligente delle informazioni risultanti dal monitoraggio di rete.

In sintesi si cerca di individuare i miglioramenti che possono essere svolti per evitare problemi di disponibilità e di capacità prima che accadano.

To do list

• Progettare l’infrastruttura di rete / CED per ridurre al minimo le possibilità di failure;
• Attuare un piano di modifiche interfacciandosi con il processo di Change Management;
• Adottare tutti i sistemi di sicurezza disponibili per proteggere rete (firewall) e postazioni (software antivirus / antimalware);
• Dotarsi di un magazzino per le parti di ricambio dei software / hardware identificati come killer application (si pensi ad es. alla scheda di flusso primario di un centralino VoIP);
• Dismettere apparecchiature con capacità non adeguate alle nuovi richieste;
• Configurare gli elementi in modo standardizzato;
• Mantenere aggiornata una documentazione della rete e della sua architettura / dimensione;
• Creare un programma di manutenzione per l’ottimizzazione delle postazione ed il continuo tuning dei servizi di rete;
• etc.

Riprendiamo i lavori continuando la rapida carrellata su FITS, e affrontando nuovamente (lo abbiamo già fatto quì) il processo di Problem Management.

Nel post citato volli evidenziare, utilizzando un esempio banale, la differenza tra i due processi che, a prima vista, in virtù del nostro vocabolario ridotto (parlo di noi “tecnici”), possono apparire identici.

In realtà l’obiettivo del processo di “gestione dei problemi” è quello di ridurre al minimo sia il numero che la gravità degli incidenti.

Risulta pertanto essere un processo caratterizzato da una fase proattiva, ed una fase reattiva:

• proattiva – individuare e risolvere i problemi e gli errori noti prima che gli incidenti si verifichino;
• reattiva – individuare la soluzione dei problemi quando uno o più incidenti si verificano.

Se esiste un dipartimento ICT con risorse di personale e finanziarie adeguate, la fase “reattiva” del processo differisce dall’obiettivo della “gestione degli incidenti”, in quanto tenta dal principio di ripristinare il servizio al cliente, seppur il più rapidamente possibile, ma cercando di attuare da subito una soluzione permanente.

Incidenti Vs problemi. L’ultima “battaglia”

Un incidente si verifica quando qualcosa non funziona nel modo previsto.

Le espressioni maggiormente utilizzate sono:

• “si è verificato un guasto”;
• “si è verificato un errore”;
• “il sistema non funziona”;
• “si è verificato un problema”.

Tuttavia il termine usato con FITS è “incidente“.

Un problema può essere:

• il verificarsi più volte dello stesso incidente;
• un incidente che colpisce molti utenti.

Quindi un problema può esistere senza avere un impatto immediato per l’utente, mentre gli incidenti sono di solito più visibili e l’impatto sull’utente è più immediato.

To do list

• Assegnare ruoli e responsabilità;
• Preparare gli utenti, Service Desk e personale di supporto tecnico (fornitori esterni);
• Decidere come il service desk passerà i problemi tecnici (strumenti, dipartimenti, priorità, etc.);
• Predisporre una documentazione di tutte le fasi del progetto;
• Decidere chi sarà ad analizzare le tendenze degli incidenti per individuare i problemi di fondo;
• Decidere come verranno registrate le risoluzioni dei problemi e valutare l’utilizzo di un sistema di Knowledge Management.

Continuiamo la rapida carrellata sui processi FITS.

La gestione della configurazione è il processo di creazione e mantenimento delle informazioni rilevanti di ogni oggetto/elemento che costituisce l’infrastruttura ICT.

In altri termini è l’insieme di azioni che è necessario svolgere per mantenere costantemente aggiornato l’inventario hardware / software / servizi ICT.

Per mettere in atto il processo è indispensabile dotarsi di un CMDB, ovvero di un database estendibile, in grado di memorizzare tutte le informazioni di interesse degli oggetti di configurazione, denominati Configuration Item (CI).

Dal sito di Tecnoteca, che ha sviluppato e promuove CMDBuild, ovvero un CMDB Open Source tutto italiano, vi riporto alcuni passaggi chiave che meglio fanno comprendere di cosa stiamo parlando.

Chi utilizza il CMDB
Le organizzazioni per le quali è strategico avere sempre sotto completo controllo la situazione degli elementi informatici utilizzati(Gestione della Configurazione), conoscendone in ogni momento la composizione, la dislocazione e le relazioni funzionali.
Informazioni mancanti o non aggiornate significano costi inutili, operazioni ridondanti, ritardo nella risoluzione dei problemi, intralcio alle attività aziendali.
Le parole chiave di un CMDB sono: velocità di risposta < – > controllo del sistema
Quali elementi informatici gestisce il CMDB

• hardware: computer, periferiche, sistemi di rete, apparati di telefonia
• software: di base, di ambiente, applicativo
• documenti: progetti, contratti, manualistica
• altre risorse, interne ed esterne

A quali domande risponde il CMDB

• dove si trova un CI (configuration item) ?
• chi lo usa ?
• di cosa fa parte ?
• da cosa è composto ?quali sono e dove si trovano altri CI analoghi ?
• ho licenze sufficienti per l’utilizzo del software ?
• cosa è successo nella vita del CI ?
• su quali altri CI impatta una eventuale modifica ?

Un CMDB consente di:

• ridurre i problemi al proprio sistema informatico
• risolvere più velocemente i problemi residui
• disturbare meno frequentemente il personale più esperto

In altre parole diminuzione dei costi e miglioramento della qualità dei servizi.
Per contro gestire il sistema IT in modo controllato vuol dire anche:

• disporre nel posto giusto delle informazioni necessarie
• dotarsi di un sistema informatico di gestione
• utilizzare risorse che mantengano il sistema sempre aggiornato

Cosa fare in sintesi?

• Assegnare ruoli e responsabilità;
• Definire gli elementi / oggetti di configurazione (CI) ed il livello di dettaglio adeguato all’organizzazione;
• Definire gli attributi dei CI;
• Alimentare il CMDB;
• Definire un metodo per l’aggiornamento del CMDB;
• 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;
• Implementare, se possibile, il processo solo su un reparto che faccia da pilota per le procedure di manutenzione del CMDB.

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.