ITIL, Italia

Il Qualification Board ha coinvolto la comunit� ITSM internazionale (attraverso i membri dell'itSMF) e gli Accredited Training Organisations (ATOs) sulle loro preferenze sui titoli delle certificazioni ITIL.

I risultati, avallati dal Board, sono i seguenti:

• I moduli Service Lifecycle, Service Capability e Managing Across the Lifecycle saranno ufficialmente noti come ITIL Intermediate Certificates.
• I candidati cha accumuleranno un minimo di 22 crediti di una selezione opportunamente bilanciata di moduli V2 e V3 saranno insigniti del ITIL Expert Certificate.
• I candidati che soddisferanno i requisiti della certificazione attualmente nota come "Advanced level" riceveranno l' ITIL Master Certificate.

Nello stesso comunicato si sono anche chiarite le date per la disponibilit� degli esami nei vari moduli ITIL V3:

Moduli Service Lifecycle

• 1 Ottobre 2008
• Service Transition
• Service Operation
• 1 Gennaio 2009
• Service Strategy
• Service Design
• Continual Service Improvement
• Managing Across the Lifecycle

Moduli Service Capability

• 1 Ottobre 2008
• Service Offerings & Agreements
• Operational Support & Analysis
• Release, Control & Validation
• 1 Gennaio 2009
• Planning, Protection & Optimization

Il processo Event Management nasce con ITIL v3. Si inserisce nella fase Service Operation del modello di lifecycle dei servizi IT in ITIL v3.  In ITIL v2, l'event management era trattato, ma solo parzialmente, nel contesto del processo di incident management, ove gli eventi erano considerati un input al processo. Se ne parlava un po' piu' diffusamente nel libro ICT Infrastructure Management.

In ITIL v3, l'event management finalmente assurge al ruolo di processo indipendente. In parte questo e' dovuto al fatto che si sono moltiplicati i tool che permettono di gestire gli eventi in modo appropriato.

Un evento, in ITIL v3, e' definito come un cambio di stato che ha rilevanza ai fini della gestione di un Configuration Item o di un servizio IT. Un evento potrebbe indicare un malfunzionamento di una parte dell'infrastruttura, e quindi esere un trigger per la generazione di un incidente. Gli eventi, comunque, possono anche indicare un andamento normale delle attivita' oppure la finalizzazione di un intervento di routine (es. il cambiamento di un tape).

Il processo di event management si basa ovviamente su dei sistemi di monitoraggio,  ma differisce dal normale monitoraggio in quanto l'event management genera ed  identifica eventi (cambi di stato), mentre i sistemi di monitoraggio controllano i componenti dell'infrastruttura anche in assenza di eventi. I sistemi di monitoraggio su cui si basa l'event management sono normalmente di due tipi:

• Sistemi di monitoraggio attivi, che attivamente vanno in poilling sui Configuration Items
• Sistemi di monitoraggio passivi che rilevano e mettono in correlazione notifiche operative e comunicazioni generate dai CI stessi

Dopo che l'evento e' stato identificato, esso si puo' trasformare in un incidente, un problema, un RFC, oppure semplicemente registrato per futura analisi.

In ultima analisi, il core business del processo di event management e' quello di identificare gli eventi, capirne il senso e determinare l'azione piu' appropriata (creazione di incident secondo i canali regolari, notifica immediata via SMS nel caso di major incidents, etc...)

In aggiunta a quanto detto sopra, l'event management puo' anche essere utile per automatizzare delle attivita' di routine, quali azionare in automatico l'avvio di script se determinate condizioni si verificano, etc...

Le attivita' tipiche dell'event management sono schematizzate nel workflow mostrato in basso. Le principali sono:

• Generazione dell'Evento, un cambio di stato nell'inftastruttura IT, trigger del workflow.
• Notifica dell'evento, la maggior parte dei CI possono essere configurati per generare eventi o su richiesta (interrogazione) o sulla base di determinate condizioni. Parte dell'event management e' determinare quali eventi devono generare notifiche.
• Identificazione dell'evento, non appena una notifica e' stata generata, va inoltrata al sistema di gestione degli eventi apposito
• Filtraggio degli eventi, come detto in precedenza solo gli eventi degni di nota vanno processati, gli altri possono essere scartati (magari scrivendolo in un log di sistema)
• Valutazione dell'evento (Importanza), gli eventi vanno valutati per poter poi decidere le azioni appropriate. Normalmente si usano almento tre livelli: Informativo, warning, eccezione.
• Correlazione degli eventi, se e' un evento e' significativo, bisognerebbe cercare di capire il contesto nel quale e' stato generato: e' la prima volta che si presenta? ci sono eventi correlati che ne arricchiscono l'informazione?. Questo normalmente avviene attraverso un "correlation engine" che permette di stabilire con maggiore precisione l'importanza dell'evento.
• Trigger, se a valle della correlazione ci si rende conto che l'evento e' significativo, fa definita una risposta, che potrebbe essere la creazione di un incidente, di una RFC o altro.
• Review delle azioni, non e' normalmente possibile fare la review di tutte le azioni effettuate come risposta agli eventi, avrebbe pero' senso assicurarsi che almento gli eventi significativi siano stati trattati opportunamente.
• Chiusura dell'evento, normalmente avviene non appena la risposta e' stata avviata.

Il 19 Giugno a Milano, al Circolo della Stampa - Corso Venezia 16 si terra' una conferenza dal tema molto interessante:

Service e Project Management: relazioni e sinergie

L'evento e' organizzato da iCONS - Innovative Consulting ed iSYS - Innovative Systems in collaborazione con itSMF Italia.

Questo evento si svolge nel contesto del ciclo di seminari ITIL� dalla TEORIA alla PRATICA, gia' pubblicizzato nel passato e si propone di indicare un metodo ed un percorso concreto per l�adozione dei processi del framework ITIL.

Questo tema risulta di particolare importanza nell'ambito di ITIL v3, ove il design e la transizione, che sono largamente project based, hanno assunto una dignita' pari ai processi di operations. Rimane molto interessante capire come interagiscono tali processi e come gestire in modo organico e produttivo queste interrelazione. Cosi' come sara' utile capire quali siano le possibili sinergie e come trarne vantaggio.

Dopo aver illustrato le potenziali interrelazioni in essere verranno presentate linee guida e raccomandazioni finalizzate al miglioramento dell'efficienza operativa e tali da consentire una visione completa ed integrata delle attivit� di progetti e servizi.

Per maggiori informazioni andate sul sito itSMF italia (www.itsmf.it)

In ITIL v2 siamo stati abituati ad avere i processi (e funzioni) schematizzati classicamente nelle due aree:

• Service Delivery
• Service Support

Questa chiarezza, si e' naturalmente ottenuta dopo aver sedimentato e digerito il framework per diverso tempo. Per ITIL v3, invece, probabilmente a causa della relativa giovinezza, non esiste una schematizzazione chiara dei processi e delle funzioni. Per la verita' esistono alcuni tentativi di schematizzazione, piu' o meno riusciti. Parte della confusione nasce dall'apparente inconsistenza tra le diverse pubblicazioni OGC sull'argomento. Per fare qualche esempio: la guida ufficiale all'ITIL Service Lifecycle (The Official Introduction to the ITIL Service Lifecycle) parla del processo "Transition Planning and Support" all'interno del Service Transition, cosi' come il volume dedicato al Service Transition, mentre la guida ufficiale all'esame ITIL v3 Foundations (Passing your ITIL Foundation Exam, the official study aid) non ne parla nel capitolo dedicato ai processi. Altro elemento di counfusione e' la mancanza di un diagramma chiaro e conciso nella documentazione ufficiale che schematizzi tutti i processi in ITIL v3. Se poi si considera anche il volumetto  "An Introductory Overview of ITIL V3" di itSMF, i dubbi crescono invece di diminuire.

Per provare ad offrire una schematizzazione di ITIL v3 ci riferiremo principalmente ai 5 libri principali:

• Service Strategy
• Service Design
• Service Transition
• Service Operations
• Continuous Service Improvement

L'assunzione di cui sopra vale per tutte la parti tranne che per la parte Service Strategy, per la quale seguiamo la guida ufficiale all'esame ITIL v3 Foundations.

I processi relativi al Service Strategy sono i seguenti:

• Strategy Generation
• Service Portfolio Management
• Demand Management
• Financial Management

I processi relativi al Service Design sono i seguenti:

• Service Catalogue Management
• Service Level Management
• Capacity Management
• Availability Management
• IT Service Continuity Management
• Information Security Management
• Supplier Management

I processi relativi al Service Transition sono i seguenti:

• Transition Planning and Support
• Change Management
• Service Asset and Configuration Management
• Release and Deployment Management
• Service Validation and Testing
• Evaluation
• Knowledge Management

I processi relativi al Service Operation sono i seguenti:

• Event Management
• Incident Management
• Request Fulfillment
• Problem Management
• Access Management

Vi sono anche delle funzioni definite nel Service Operation:

• Service Desk
• Technical Management
• IT Operations Management
• Applications Management

Nella parte Continual Service Improvement vi e' definito un processo di miglioramento continuo organizzato in sette passi:

• Passo 1: Definizione di cio' che bisogna misurare
• Passo 2: Definizione di cio' che si puo' misurare
• Passo 3: Raccolta dei Dati
• Passo 4: Formattazione dei dati
• Passo 5: Analisi dei dati
• Passo 6: Presentazione ed utilizzo delle informazioni
• Passo 7: Implementazione di azioni correttive

Scenderemo nel dettaglio dei vari processi nei prossimi post...

Una rappresentazione grafica della schematizzazione di cui sopra e' disponibile in basso.

Il primo problema che si incontra nei progetti di implementazione del processo di Configuration management e': da dove iniziare? Tutta la documentazione ITIL (sia versione 2 che versione 3) ci da' un visione quasi utopica del CMDB e del processo di configuration management, fino a dire che supporta tutti gli altri processi e che ne e' alla base.

Basti vedere una parziale lista dei benefici potenziali (o attesi?) per rendersi conto della sua utilita' e pervasivita':

• Disponibilita' di informazioni accurate sull'infrastruttura IT 
•  Maggiore controllo sugli asset IT
• Maggiore aderenza alle leggi (es. numero licenze software) 
• Miglior supporto al processo di Incident Management, soprattutto nella valutazione dell'impatto degli incidenti. 
• Miglior supporto al processo di Problem Management, in particolare nell'ausilio fornito nell'analisi della "root cause".  
• Miglior supporto al processo di Change Management, nell'identificazione delle  baseline iniziali prima del cambiamento
• Miglior supporto al processo di Release Management, nella definizione delle target CI
• etc...

Puo' fare talmente tante cose che... non sappiamo dove e come iniziare a fargliele fare. Iniziare a catalogare tutti i CI, etichettarli, aggiornarli, sperando che i benefici si materializzino come d' incanto, non e' generalmente una buona idea.

Un utile metodo per iniziare a implementare un CMDB e' porsi la domanda in termini specifici: cosa vogliamo fargli fare? Vogliamo un maggiore controllo sugli asset IT o vogliamo un tool di supporto all'Incident Management? Quali sono gli utilizzi piu' importanti del CMDB per la nostra organizzazione (e per il management dell'organizzazione)?

E' utile a questo proposito organizzare dei workshop con gli utenti attesi del CMDB (a livello decisionale) che possano definire quali sono i loro problemi in modo da poter capire come puo' il CMDB aiutarli a risolverli. La soluzioni attese dal CMDB si formalizzano in Use Cases. Questi possono andare dal rendere disponibile agli operatori di Help Desk una vista dell'infrastruttura di rete in modo da poter rispondere alla (frequente) domanda: "i server sono raggiungibili?" fino al permettere ai manager di effettuare analisi di costo sull'infrastruttura per poter allocare i costi ai diversi clienti.

Questi Use Cases saranno il nostro punto di partenza nel definire il nostro CMDB attraverso un approccio Top-Down. Partendo dal risultato finale definiamo i dati ed il livello di dettaglio che devono essere presenti nel CMDB. Questo approccio ci permette anche di definire un approccio in fasi. Prima si approcciano e si implementano gli Use Cases che risolvono i problemi piu' dolorosi e via via con iterazioni successive si puo' procedere ad espandere il CMDB fino a risolvere anche altri problemi.

Il Configuration Management e' forse l'unico processo ITIL della parte Service Support (ragionando in termini di ITIL v2) i cui benefici non sono (quasi) gratuiti leggendo le ricette ITIL

La Cogitek (http://www.cogitek.it) , in collaborazione con itSMF Italia (http://www.itsmf.it) organizza per il mese prossimo, e precisamente il 18/04/2008,  un evento particolarmente stimolante sul tema dell'ambiente Open Source a supporto delle "best practices" di ITIL.

L'evento, che si svolgera' nella mattinata, e' particolarmente stimolante in quanto si svilupper� lungo un filo conduttore che partendo dalla definizione dei Processi e del CMDB in ottica ITIL percorre la strada dell'Open Source per trovare la risposta integrale alle esigenze dell'Azienda utente.

Il tema trattato senz'altro non prescindera' dall'interessante progetto CMDBuild (http://www.cmdbuild.org/), software in ambito Open Source, in cui un paio di oratori dell'evento hanno ricoperto ruoli significativi.

L'evento rientra nel ciclo di incontri "ITIL at Work", un'iniziativa che nasce dalle considerazioni fatte dal Gruppo di Consulenti di Cogitek, che operano nell'Area dell'IT Governance, che ritengono ormai sufficientemente diffusa la conoscenza delle best practices ITIL e che si propone con una cadenza bimestrale.

La partecipazione e' gratuita previa prenotazione. Per maggiori informazioni: http://www.itsmf.it/index.php?method=zoom_conferenze&id=88

Qualche post fa' abbiamo analizzato il processo Starting up a project (SU) di PRINCE2, proseguiamo su quello traccia ed occupiamoci del secondo processo: Initiating a Project (IP).

Il processo IP inizia non appena il Project Board (l'autorita' che dirige il processo in PRINCE2) approva il Mandato di progetto (Project Brief), preparato durante il processo precedente (SU).

Di fatto il processo SU e' il primo vero e proprio processo del modello PRINCE2, in quanto, per essere precisi, il processo SU non fa parte del progetto in senso stretto, ma della fase di pre-progetto. Nel processo SU in effetti si stabilisce il Project Board, che e' l'autorita' massima del progetto che poi da' il via ufficiale al progetto sulla base del Mandato di progetto.

Alcuni degli obiettivi di questo processo sono i seguenti:

• Finalizzare il Project Initiation Document (PID)
• Preparare lo Stage Plan per la prima fase di progetto
• Documentare e confermare il Business Case per il progetto
• Ottenere l'impegno delle varie parti
• Assicurarsi che il Project Board assuma la "proprieta'" (ownership) del progetto

Il Processo IP e' composto dei sotto processi:

IP1 - Pianificazione della Qualita' (Planning Quality). Questo sottoprocesso si occupa di determinare i requisiti di qualita' del progetto, nonche' l'approccio da tenere durante il progetto rispetto alla qualita'. Sia i requisiti che l'approccio vanno documentati nel piano di qualita' di progetto (Project Quality Plan)

IP2 - Pianificazione di progetto (Planning a Project). Questo sottoprocesso di occupa di creare il Piano di progetto (Project Plan). Il piano include le attivita' principali, i deliverables, i costi , il ciclo di vita nonche' le risorse necessarie allo svolgimento del progetto stesso.

IP3 - Affinamento del Business Case e dei rischi di progetto (Refining Business Case and Risks). Questo sottoprocesso si occupa di ampliare e verificare il Business Case descritto nel Mandato di Progetto (Project Brief) alla luce del piano di progetto. Lo stesso lavoro di ampliamento e verifica viene effettuato con riferimento ai rischi di progetto.

IP4 - Impostazione dei controlli di progetto (Setting up Project Controls). In questo sottoprocesso vengono definiti dei meccanismi di controllo per assicurarsi che ad ogni livello di progetto possano essere verificati il progresso (con riferimento al piano di progetto) e definite le misure correttive eventuali. In questo sottoprocesso viene anche definito un Communication Plan che chiarisca come, quando e a chi le informazioni vadano distribuite.

IP5 - Impostazione dell'archivio di Progetto (Setting Up Project Files). In questo sottoprocesso si sviluppa il sistema informativo di progetto, tra le altre cose di creano l' Issue Log, il Lessons Learned Log ed il Daily Log.

IP6 - Creazione del Project Initiation Document (Assembling a PID). Nell'ultimo sotto processo del processo IP ci si occupa di creare il Project Initiation Document, che e' il documento (fisico o logico) che abbia tutte le informazioni necessarie ad effettuare deciusioni sul progetto. Il PID sara' riutilizzato durante tutta la durata del progetto.