IT Management blog

Il sito ITIL, Italia dedica un area (per il momento contenuta) ad ITIL v3 ed ai 5 libri relativi:

• Service Strategy
• Service Design
• Service Transition
• Service Operations 
• Continual Service Improvement

Per il post di oggi andiamo un po' fuori tema... non ci occuperemo di Certificazioni IT, ne' di IT Project management ne' di IT Service Management come da nostro impegno iniziale.

A volte e' utile allontanarsi un attimo dal quotidiano per poter capire i cambiamenti che avvengono attorno a noi e che non si riscontrano nelle attivita' giornaliere. Un' ottimo modo di fare cio' e di leggersi un libro. Un libro molto utile a tale proposito e' il volume seguente.

Wikinomics, La collaborazione di massa che sta cambiando il mondo 
di Don Tapscott, Anthony D. Williams

• Numero Pagine: 384
• Casa editrice: Etaslab
• Anno di pubblicazione: 2007
• Lingua: Italiano
• ISBN: 9788845313844
• Link ad Etaslab: http://etaslab.corriere.it/dynuni/dyn/Catalogo/13844_Tapscott-Williams_Wikinomics.jhtml

Il libro compie un eccitante viaggio nel nuovo paradigma della collaborazione di massa e del peer production. La parte interessante e' come si puo' migliorare il business comprendendo questo paradigma ed utilizzandolo opportunamente. 

Alcuni esempi di utilizzo citati sono:

• Come usare la peer production per risparmiare costi di R&D
• Come utilizzare le idee dei clienti
• Come aprire il proprio business ai fornitori ed ai clienti per migliorare i costi e le performance

Il libro non offre una soluzione buona per tutti, ma aiuta a riflettere ed a considerare gli elemtnei che possono essere utilizzati per essere parte del nuovo paradigma: apertura, peering, condivisione ed azione globale. Per sfruttarne i benefici occorre un ripensamento del business.

Con esempi vividi e coinvolgenti, basati su cinque anni di una ricerca senza precedenti, Wikinomics spiega i fondamentali cambiamenti avvenuti nella tecnologia, nella demografia e nel business che permetteranno alle persone di partecipare all’economia come mai prima d’ora.

Come vedete forse non siamo del tutto fouri tema...

Continuiamo con la serie di post sulle metriche relative ai processi ITIL (v2). Con il post di oggi concludiamo la panoramica sul Service support con le metriche di Release Management.

Nel ricavare le metriche e' sempre opportuno chiarire gli obiettivi (Fattori critici di successo) della misura. Per il processo in oggetto si possono considerare i seguenti:

• Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL)
• Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati
• Ottimizzare la gestione del processo di release

Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Release Management sono le seguenti (organizzate per Fattore Critico di Successo di cui offrono una misura):

Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati

• Numero di incidenti generati dalla release, queste metrica misura direttamente i "danni collaterali" generati da una release. Questi dati possono essere calcolati a partire dalla lista degli incidenti.
• % di Release urgenti, questa metrica permette di misurare la percentuale di release urgenti (potenzialmente pericolose) rispetto alle altre. Se queste risultano eccessive vuol dire che il processo e' bypassato con la scusa dell'urgenza. Questi dati sono norlmalmente disponibili nei log delle release.
• Numero (oppure %) di release non testate, normalmente a causa di urgenze, misura molto simile a quella precedente, che si puo' usare qualora i dati fossero disponibili in alternativa a quelli necessari per la metrica precedente.

Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL)

• Numero pacchetti Software installati in produzione e non presenti nella DSL, misura della bonta' del processo di release in generale e della DSL in particolare. I dati sono normalmente disponibili a seguito di audit sui software installati in produzione.
• Numero di licenze non in uso, misura della bonta' del processo di gestione della DSL. Questa metrica si puo' tradurre in un beneficio immediato al byusiness nella possibilita' di risparimare soldi o utilizzare piu' efficientemente le risorse.

Ottimizzare la gestione del processo di release

• % di accuratezza delle stime dei tempi (e/o costi) di release, misura della bonta' della pianificazione e dell'efficienza del processo di release. Semplice da calcolare se si ha l'abitudine di effettuare (e tracciare i relativi dati) un minimo di pianificazione della release.
• % di Release effettuate nei tempi previsti, fornisce informazioni sostanzialmente simile a quelle della metrica preecedente.

Nel processo di Release applicativo esistono due prospettive opposte che e' opportuno valutare e misurare con metriche (alcuni esempi sono elencati di seguito) che sono leggermente diverse a secondo del punto di vista:

• la prospettiva del gruppo di operations (Application Support) con le metriche relativa:
  • Numero di difetti identificati
  • Numero di fix rimandati indietro a sviluppo
• la prospettiva del gruppo di sviluppo
  • Numero di difetti riscontrati durante lo sviluppo
  • Numero di difetti risolti
  • Numero di fix rifiutati da Application Support

Con ITIL v3 il continuo di miglioramento dei processi assume una maggiore importanza. A questo proposito e' fondamentale l'identificazione di metriche per la reale misurazione dei processi e l'identificazione di opportunita' di miglioramento. Parecchi post fa abbiamo parlato di metriche, in questo post approfondiamo qualche metrica per la misurazione del processo di Configuration Management.

Nel Processo di Configuration Management esistono dei Fattori Critici di Successo che e' utile elencare, e da cui ricaveremo le metriche relative:

• Identificare e gestire le informazioni relative all'infrastruttura IT;
• Fornire informazioni utili ai processi di Incident Management, Problem Management, Change Management e Release Management;

Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Configuration Management sono le seguenti (organizzate per il Fattore Critico di Successo di cui offrono una misura):

Identificare e gestire le informazioni relative all'infrastruttura IT;

• Numero di licenze non in uso, questa metrica si traduce in un beneficio immediato al byusiness nella possibilita' di risparimare soldi o utilizzare piu' efficientemente le risorse 
• Numero di configurazioni non autorizzate, misura della bonta' del processo di mantenimento del CMDB, normalmente questi dati possono essere trovati durante gli audit previsti

Fornire informazioni utili ai processi di Incident Management, Problem Management, Change Management e Release Management;

• Numero di incidenti derivati da CI mal documentate, misura dei mancati benefici agli altri processi. Questa metriche identifica il costo vivo in termini di tempo perso dagli utenti (e dai tecnici) nel risolvere incidenti che potevano essere prevenuti da una migliore processo di Configuration Management
• % di CI inaccurate, anche questa misura della bonta' del processo di mantenimento del CMDB, normalmente questi dati possono essere trovati durante gli audit previsti
• Miglioramento dei risultati misurati in Customer Surveys annuali, misura della migliorata percezione del processo

Il Project Management Institute o PMI (http://www.pmi.org), ha annunciato che ha raggiunto la certificazione ISO/IEC 17024 per la certificazione Project Management Professional (PMP®) dall'International Organization for Standardization (ISO).

Cosa cambia? Praticamente nulla. Semplicemente la certificazione PMP e' la sola certificazione di Project Management che sia certificata ISO 17024. Nella pratica, comunque, era gia' una delle principali certificazioni per Project Managers disponibili, per la serieta' nella selezione ed i numeri: ci sono oltre 218,000 professionisti certificati PMP in oltre 160 paesi. L'accreditamento ISO 17024 semplicemente fornisce ulteriore prova dello stato della certificazione PMP come una delle piu' valide certificazione di Project Management.

Continuiamo la nostra analisi sui vari libri di ITIL v3; in questo post proviamo ad illustrare i contenuti del volume Continual Service Improvement.

Il volume in esame è stato compilato da Gary Case e George Spalding e copre gli aspetti relativi al continuo miglioramento dei servizi offerti. Gli obiettivi del Continual Service Improvement (CSI) includono i seguenti:

Review, analyze and make recommendations on improvement opportunities in each lifecycle phase: Service Strategies, Service Design, Service Transition, and Service Operations:

• Rivedere ed analizzare i Service Level Achievement
• Identificare ed implemetare attivita' di miglioramento della qualita' dei Servizi IT e migliorare l'efficienza e l'efficacia dei processi ITSM
• Migliorare l'efficienza nei costi (cost effectiveness) della fornitura dei servizi IT

In realta' questo concetto non e' nuovo con ITIL v3, ma era ben presente anche nella versione precedente ove venivano presentate le tematiche inerenti all'implementazione di ITIL. I passi sono sempre gli stessi, e sono i seguenti:

• Qual'e' la visione? --> Business vision, missione aziendale, Obiettivi
• Dove siamo adesso? --> Valutazione della Baseline
• Dove vogliamo arrivare? --> Definizione di target misurabili
• Come ci arriviamo? --> Definizione di piani di miglioramento dei processi
• Ci siamo arrivati? --> Misurazione delle metriche per verificare il raggiungimento dei target

Con la possibile aggiunta del passo che riportava al punto primo, come facciamo in modo che il ciclo continui con lo stesso entusiasmo? (how do we keep the momentum going?).

Cio' che si aggiunge in questo volume e' la concretizzazione di questa idea, cioe' la formalizzazione della pratica del CSI. A tale proposito vengono definiti ruoli chiave quali il CSI manager, il service owner ed il service level manager il cui compito principale e' l'implementazione delle pratiche di CSI.

L'implementazione del CSI prevede sette passi principali, a partire dall' identificazione della visione di dove si vuole arrivare:

• Definizione di cio' che si deve misurare (metriche ideali)
• Definizione di cio' che e' possibile misurare (metriche reali)
• Accumulo dei dati
• Processamento dei dati in termini di frequenza di raccolta, etc..
• Analisi dei dati in termini di accuratezza, integrita', etc..
• Presentare ed usare l'informazione per definire piani di azioni e reports
• Implementazione di piani di azione correttivi

Il volume sul CSI documenta che le misure ed il tipo di metriche da accumulare. Uno degli aspetti piu' interessanti e' l'identificazione dei tre tipi di metriche principali: tecnologiche, service-related e process-related. Molte organizzazione accumulano metriche (magari in modo non pianificato), ma non le mettono nel contesto del servizio IT inteso come servizio end-to-end.

Ci torneremo ancora e con maggiori dettagli...

Da uno studio della Computing Technology Industry Association (http://www.comptia.org/), promotori, tra molte altre iniziative, della certificazione IT Project+, risulterebbe che le cause piu' frequenti di fallimento per progetti siano le seguenti:

1. Scarsa  comunicazione  (insufficiente, di scarsa qualita'), per il 28%
2. Pianificazione delle risorse insufficiente, per il 18%
3. Pianificazione dei tempi non realistica, per il 13.2%
4. Requirements di progetto scarsamente dettagliati o imprecisi, per il 9.8%
5. Mancanza di supporto degli stakeholders, per il 6.7%
6. Mancanza di criteri di successo del progetto, per il 5.2%
7. Budget non realistico, per il 4.8%
8. Mancanza o insuffizienza di pianificazione dei rischi, per il 4.4%
9. Mancanza di processi di controllo dei cambiamenti, per il4.3%

Come altre volte anche questa volta le comunicazioni di progetto sembrano essere il singolo elemento che maggiormente puo' determinare l'insuccesso di un progetto (abbiamo gia' parlato qui e qui). A tale proposito una maggiore attenzione ai processi di Communication Management puo' risultare determinante.

Continuiamo la nostra analisi sui vari libri di ITIL v3; in questo post vi daremo conto dei contenuti del volume Service Operation.

Il volume in esame è stato compilato da David Cannon e David Wheeldon e copre vari aspetti delle attivita' giornaliere necessari a fornire e supportare i servizi IT. In particolare vi sono cinque processi che rappresentano il cuore di questo volume:

• Event management, che si occupa di gestire le eccezioni (generalmente eventi generati dall'infrastruttura). Questa parte era considerata parte di Incident Management in precedenza, assume (giustamente) connotati propri in ITIL v3.
• Incident management, gia' presente in ITIL v2
• Request fulfilment, che si occupa di gestire le Service Requests, anche questa area era considerata parte di Incident Management in precedenza, e come tale liquidata con poche parole (tipo: e' utile utilizzare per le service request lo stesso workflow dell'incident management...).
• Problem management, gia' presente in ITIL v2
• Access management, nuovo con ITIL v3, che si occupa di gestire gli accessi ai servizi IT.

Nella parte di Service Operations sono anche previste quattro funzioni (o gruppi): 

• Service desk, esistente gia' in ITIL v2
• Technical management
• Application management
• IT operations management

Il volume fa riferimento anche alle attivita' operative che vengono svolte quotidianamente nei dipartimenti IT. A tale proposito fa riferimento a principi gestionali generici quali il monitoraggio dei control loops, gia' presenti in alcune parti di ITIL v2. Il libro fa anche riferimento (ad alto livello) ad attivita' specifiche correlate alla tecnologie, quali:

• Mainframe Management
• Server Management
• Network Management
• Storage and Archive
• Database Administration
• Directory Services Management
• Desktop Management
• Internet / Web Management

Uno dei punti chiave del libro e' che la gestione dei servizi IT e della tecnologia correlata vanno integrati e non separati (come viene spesso fatto). Questo sembra essere l'elemento maggiore di novita'.

Continuiamo la nostra analisi sui vari libri di ITIL v3; in questo vi daremo conto dei contenuti del volume Service Transition.

Il volume in esame è stato compilato da Shirley Lacy ed Ivor Macfarlane e si concentra sull'implementazione del servizio, (definito nel volume precedente: Service Design), o meglio, per utilizzare i termini di ITIL v3, transitare il nuovo servizio IT in produzione ("transitioning the Service into operations"). i processi, i concetti e le attività presentate in questo volume hanno i seguenti obiettivi:

• Rendere più semplice l'adozione e la gestione del cambiamento
• Standardizzare le attività di transizione
• Mantenere l'integrità delle configurazioni nel corso della loro evoluzione
• Velocizzare il processo decisionale
• Assicurare che i nuovi servizi IT siano implementabili, gestibili, manutenibili e cost-effective

Non tutto è nuovo in questo volume, i seguenti processi sono sostanzialmente uguali ad ITIL v2 (anche se con diversi miglioramenti):

• Change management
• Configuration management
• Release (and deployment) Management

Il fatto di lasciare alcune parti invariate permetterà a quanti hanno esperienza ITIL v2 di riutilizzarla con profitto anche su ITIL v3. Alcune parti di Service Transition nascono però con ITIL v3. Queste sono:

• Asset Management, aggiunto al (ma distinto dal) configuration management
• Knowledge Management, in precedenza limitato solo ad essere una costola dei vari processi ITIL v2 (Incident Management, Problem Management, etc...), adesso un processo a sè stante.

Nella parte Service Transition si concretizza quello che è stato un pò il mantra di ITIL v3, il concetto di lifecycle dei servizi. Nel Service Transition si introducono quindi le seguenti attività:

• Service Transition Planning and Support
• Service Validation, Testing and Evaluation

Ci torneremo ancora e con maggiori dettagli...