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 parzialmente nel 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, quindi alla 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 notifiche, 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
- Sistem 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 a una 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 sono vere, etc...

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

- Generazione dell'Evento, eventi succedono continuamente, ma non bisogna identificarli o registrarli tutti, solo quelli funzionali alla corretta gestione dei servizi IT.
- 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 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 (link), 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 deidati
• Passo 5: Analisi dei dati
• Passo 6: Presentazione ed utilizzo delle informazioni
• Passo 7: Implementazione di azioni correttive

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

L'International Standards Organization (ISO) ha iniziato lo sviluppo dello standard ISO 21500, nuovo standard internazionale per il project management.

Lo standard ISO 21500 si basera' su standard esistenti e su sviluppi gia' effettuati a livello nazionale. Tra di essi vi saranno senz'altro il PMBOK® del PMI (www.pmi.org), che servira' come base per la terminologia (a quanto pare). Per la suddivisione in processi si utilizzeranno input dal PMBOK®, dallo standard BSI 6079 ed IPMA (www.ipma.ch).
Lo standard dovrebbe, nelle intenzioni, essere applicabile ad organizzazioni di ogni dimensione e settore.

Lunedì, 31 Marzo 2008, il Southern Italy Chapter (http://www.pmi-sic.org) del Project Management Institute (http://www.pmi.org) organizza un seminario presso la Facoltà di Ingegneria dell' Università Federico II a Napoli (c/o Aula Scipione Bobbio, Piazzale V. Tecchio, 80 - Napoli).

Il titolo esteso del seminario e': "Program e Risk Management: Il caso A380 per Alena Aeronautica". Il relatore sara' l'Ing. Roberto Polidoro, Executive Vice President per i Programmi Airbus di Alenia Aeronautica ed esperto del settore.

L'iscrizione e' obbligatoria (scusate per il breve preavviso...). Per iscriversi cliccate sul link seguente: http://www.pmi-sic.org/iscrizione_eventi/modulo_iscrizione_free.htm

Il risk management e' senz'altro un argomento importante, ma senz'altro sara' interessante seguire da una fonte primaria il caso di studio che e' relativo all'arcinoto progetto Airbus A380.

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.