IT Management blog

Lo scopo dell'ISO/IEC 20000 e' di "fornire un comune standard di riferimento per ogni impresa che offre servizi IT a clienti interni o esterni". Lo standard promuove l'utilizzo di un modello integrato a processi di gestione dei servizi IT. Questi processi sono sostanzialmenti quelli documentati in ITIL nella parte Service Support e Service Delivery. ISO/IEC 20000 pone dei requirement obbligatori per poter gestire i servizi IT in generale, ma non scende in dettagli specifici per diverse tipologie di fornitori. L'ISO 20000 rappresenta, quindi, uno strumento per poter dichiarare formalmente la conformita' alle best practice di ITSM in generale e di ITIL in particolare.

Lo standard ISO/IEC 20000, è sostanzialmente allineato con l’IT Infrastructure Library (ITIL), nonostante non ne includa formalmente l'approccio. E' stato sviluppato sulla base dello standard BSI 15000 (British Standard Institute), del quale ne mantiene la struttura.

L'applicazione delle best practices ITIL, aiuta il fornitore di servizi che desidera certificarsi su ISO/IEC 20000 in modo sostanziale. E' da sottolineare pero' che ISO/IEC 20000 copre anche aree solo parzialmente trattate in ITIL.

Lo standard ISO/IEC 20000 prevede i seguenti processi:

• Incident Management, immediatamente sovrapponibile all'omologo in ITIL.
• Problem Management, immediatamente sovrapponibile all'omologo in ITIL.
• Configuration Management, immediatamente sovrapponibile all'omologo in ITIL.
• Change Management, immediatamente sovrapponibile all'omologo in ITIL
• Release Management, immediatamente sovrapponibile all'omologo in ITIL.
• Service Level Management, immediatamente sovrapponibile all'omologo in ITIL.
• Budgeting and Accounting for IT Services, sovrapponibile con il processo ITIL Financial Management for IT Services.
• Capacity Management, immediatamente sovrapponibile all'omologo in ITIL.
• Service Continuity and Availability Management, sovrapponibile ai due processi ITIL IT Service Continuity Management ed Availability Management.
• Service Reporting, che non ha diretti equivalenti in ITIL.
• Information Security Reporting, che si relazione con ITIL nella pubblicazione "Security Management" (citata qui).
• Business Relationship Management, di cui si accenna nella pubblicazione ITIL "Business Perspective" (citata qui).
• Supplier Management, di cui si accenna nella pubblicazione ITIL "Business Perspective" (citata qui).

Le organizzazioni possono, naturalmente, essere certificate su ISO/IEC 20000 attraverso un processo di valutazione e certificazione. Gli enti di certificazione devono essere accreditati da una organizzazione di Accreditamento di un paese membro dell'ISO (processo "standard" per le certificazioni ISO).

Lo standard ISO/IEC 20000, si compone di due parti:

• Parte 1: Specification (lo Standard vero e proprio); pubblicato come ISO/IEC 20000-1:2005. Contiene una lista di controlli a cui una organizzazione “deve” essere aderente per fornire dei servizi ad una qualità accettabile per i suoi clienti, e potersi certificare.
• Parte 2: Code of practice; pubblicato come ISO/IEC 20000-2:2005. Descrive le best practice in maggior dettaglio, fornendo un riferimento e raccomandazioni per i processi di gestione del servizio che rientrano nell’ambito dello standard ufficiale. Contiene linee guida e suggerimenti che “dovrebbero” essere messi in pratica dalle organizzazioni, e risulta particolarmente utile a quelle organizzazioni che desiderano prepararsi per essere certificate ISO 20000 o pianificano semplici miglioramenti del servizio.

Lo standard consente alle organizzazioni che decidono di adottarlo, di poter effettuare dei benchmark sulla propria capacità nell’erogazione dei servizi, nel misurare i livelli di servizio e nella valutazione delle performance.

Cercheremo di approfondire i contenuti delle due parti in post successivi....

Parecchi post fa avevamo parlato di Cost Management (Gestione dei costi), come una delle 9 knowledge areas del PMBOK (vedi post relativo). Ne parliamo in questo post.

Il Cost Management essenzialmente comprende i processi coinvolti nella pianificazione, nella valutazione e stima, nella allocazione e nel controllo dei costi in modo che il progetto venga completato nei limiti del budget previsto. Questa knowledge area e' focalizzata sui costi delle risorse necessarie per completare le attività previste. E' chiaro che va fatta una valutazione nell'ambito del ciclo di vita sia del processo e del prodotto nella valutazione di tali costi. Spesso una riduzione dei costi in ambito di progetto si puo' tradurre in un aumento dei costi operativi del prodotto risultante.

E' importante sottolineare che e' importante che il Project Management Plan (vedi post su Project Management Integration) sia stato sviluppato, il quale normalmente include un piano di gestione dei costi, prima che i costi possano essere valutati e stimati.

I processi include nella Knowledge area sono i seguenti:

• Cost Estimating (Stima dei costi), che fa parte del planning process group. La stima dei costi comprende l’identificazione e la valutazione di varie alternative di costo. Le stime dei costi possono evolversi per affinamenti successivi nel corso del progetto, man mano che maggiori informazioni sono disponibili. Tipicamente, un progetto in fase iniziale può essere caratterizzato da una stima approssimativa che va dal -60% al +90%. Con l'avanzare del progetto, le stime potrebbero diventare più precise, restringendo l'intervallo tra il -10% e il +15%. Elementi da tenere presente nella stima dei costi possono essere i seguenti: policy esistenti nell'organizzazione per la stima dei costi, templates per la stima dei costi, dati storici di progetti simili, file di progetto. Output finale del processo e' la stima dei costi delle attività, cioe' la determinazione quantitativa dei costi previsti delle risorse necessarie per completare l'attività prevista.
• Cost Budgeting (Budgeting dei costi), che fa parte del planning process group. Il cost budgeting consiste nell’assegnazione dei costi stimati delle singole attività previste o Work Package, al fine di stabilire una baseline dei costi utilizzabile per misurare l’andamento del progetto in termini finanziari. Alcuni degli input del processo sono la stima dei costi effettuata precedentemente ed il WBS (vedi il post sul Project Scope Management). Uno degli output del processo e' la baseline dei costi, cioe' un budget suddiviso per fasi temporali, utilizzato come base per la misurazione ed il controllo dell'andamento dei costi del progetto.
• Cost Control (Controllo dei costi), che fa parte del Monitoring & Controlling process group. Il cost control ha la funzione di individuare le cause degli scostamenti in positivo ed in negativo dalla baseline prodotta nel Cost Budgeting. La tecnica dell'Earned Value puo' essere usata per valutare l'avanzamento del progetto rispetto alla baseline la dimensione degli scostamenti da essa. Output del processo possono essere modifiche delle stime di costo o delle baseline.

Sarebbe interessante vedere i vari processi nel dettaglio ed in particolare la tecnica dell'Earned Value (EV), magari un giorno lo faremo...

Nel sito ITIL, Italia, iniziativa associata all'IT Management blog, si e' aperto un blog associato a questo che ne riporta i post relativi alla gestione dei servizi IT (ITSM), il Blog ITIL, Italia.

Auguri alla nuova iniziativa.

Il processo di Availability Management (o Gestione della disponibilita') in ITIL fa parte del set di processi della parte Service Delivery. Scopo dell'Availability Management in ITIL e' di "ottimizzare la capacita' dell'infrastruttura IT al fine di offrire un livello di availability (disponibilita') adeguato e 'cost effective' affinche' l'organizzazione possa raggiungere i propri obiettivi".

Il processo di Availability Management normalmente si occupa delle seguenti cose:

• Determinazione dei requisiti di availability aziendali
• Produzione dell'availability plan
• Ottimizzazione dell'availability ed analisi degli elementi chiave relativi
• Raccolta ed analisi dei dati relativi all'availability
• Verifica del raggiungimento dei livelli minimi di availability specificati nei Service Level Agreement o Operating Level Agreement.

Vi sono dei principi guida che dovrebbero governare il processo di Availbility Management, questi sono i seguenti:

1. La Availability e' il fulcro su cui si appoggiano la soddisfazione del Business e degli utenti relativamente ai servizi IT
2. Anche quando le cose si mettono male (unavailability..) e' possibile mantenere una soddisfazione del business e degli utenti gestendo i problemi correttamente
3. Il processo di Availability management dei servizi IT puo' iniziare solo se si comprendono come i servizi stessi supportano il buisiness

Il processo di Availability management deve considerare il problema della disponibilita' sia dal punto di vista del componente dell'infrastruttura (il songolo server giu') che dal punto di vista del servizio (l'applicazione non disponibile) e quindi dell'utente finale. I concetti sono simili, ma l'impatto e la misurazione delle due cose e' diversa (un servizio potrebbe rimanere su anche se dei componenti sono giu'...).

Vi sono molti elementi che interagiscono con il processo di Availability Management e vanno considerati in relazione con esso, alcuni di essi sono:

• I requirements dell'organizzazione
• I costi necessari a mantenere un livello specifico di availability
• La ridondanza dei componenti chiave dell'infrastruttura IT
• L'affidabilita' dell'infrastruttura IT
• La complessita' dell'infrastruttura IT
• Qualita' delle procedure operative relative all'infrastruttura IT

In post successivi discuteremo piu' in dettaglio su alcuni aspetti prativi di availability management.

Nel blog abbiamo citato dei framework ITSM alternativi ad ITIL:

• Control Objectives for Information Technology (COBIT)
• Application Services Library (ASL)
• Business Information Services Library (BISL)
• Microsoft Operations Framework (MOF)
• L'Enterprise Computing Institute pubblica un set di libri che si occupano di IT management su larga scala.
• Butterworth-Heinemann (Computer Weekly Professional Series) ha prodotto un interessante set di pubblicazioni che si occupano di IT service management con particolare attenzione ad argomenti relativi all'IT portfolio.

Oltre a questi, 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).
• 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".

Questi approcci alternativi (ma come abbiamo visto ispirati da ITIL) possono essere utili soprattutto a chi intende implementare l'ITSM in piccole organizzazione (in particolare il primo).

Parecchi post fa avevamo parlato di Time Management, come una delle 9 knowledge areas del PMBOK (vedi post relativo). Ne parliamo in questo post.

La gestione dei tempi in un progetto e' forse la parte piu' dolorosa. Per il PMI questa knowledge area include i processi necessari ad assicurare la finalizzazione del progetto nei tempi programmati, che sono elencati di seguito:

• Definizione delle attività (Activity definition), che fa parte del planning process group. La definizione delle attività comporta l'identificazione e la documentazione necessaria per l'esecuzione del lavoro programmato. Il processo permette di identificare i deliverable al livello più basso della struttura di scomposizione del lavoro (WBS), detto Work Package e di associare una o piu' attivita ad ognuno di essi. I Work Package costituiscono la base della stima, della programmazione, dell'esecuzione, del monitoraggio e del controllo del lavoro. L'output principale del processo e' un elenco di attivita'.
• Programmazione delle attività (Activity sequencing), che fa parte del planning process group. La programmazione delle attività comporta l'identificazione delle relazioni esistenti tra le varie attività identificate nel processo precedente. E' fondamentale identificare i constraints tra le varie attivita' (alcune potrebbero non poter iniziare finche' altre non sono completate, etc..), che in progetti medi e grandi generano notevole complessita' nella programmazione. Output del processo e' un programma delle attivita'.
• Stima delle risorse necessarie alle attività (Activity Resource Estimation), che fa parte del planning process group. La stima delle risorse necessarie alla varie attività comporta la stima di quali risorse utilizzare (persone, tools o materiali), della percentuale di ciascuna risorsa da impiegare e di quando ogni risorsa sarà disponibile per l'esecuzione delle attività di progetto.
• Stima della durata delle attività (Activity Duration Estimation), che fa parte del planning process group. Il processo di stima della durata delle attività si occupa 1) di stimare la quantità dell'impegno di lavoro richiesto per completare l'attività programmata, e 2) di valutare la quantità supposta di risorse da dedicare al completamento dell'attività programmata e 3) di determinare il numero di giorni/uomo (o settimane/uomo, etc..) necessari al completamento dell'attività programmata.
• Sviluppo della programmazione (Schedule development), che fa parte del planning process group. Lo sviluppo della programmazione di progetto, sostanzialmente mette insieme i dati derivanti dai processi precedenti per determinare la data d'inizio e di fine pianificata per le attività di progetto. Questo processo e' iterativo, lo sviluppo della programmazione prosegue per l'intero progetto mano a mano che il lavoro avanza e che il Project Management Plan cambia (perche' di solito cambia...).
• Controllo della programmazione (Schedule Control), che fa parte del monitoring and controlling process group. Il controllo della programmazione sostanzialmente si occupa di contrallare l'andamento dei tempi di progetto e di influire sui fattore che determinano modifiche di programmazione (e gestire le modifiche...).

Come si notera' su sei processi cinque sono di pianificazione ed uno di controllo, il che chiarisce come questa knowledge area sia fortemente orientata supporto alla pianificazione del progetto. Spesso, ai fini pratici, tutti e cinque i processi di Time Management appartenenti al process group di pianificazione sono così strettamente collegati da essere considerati come un unico processo che, in casi di progetti relativamente piccoli, può essere svolto da una sola persona. Il PMBOK pur ammettendo tale pratica li tratta in modo separato, ognuno con le sue tecniche, input e output.

Ecco una parola amata ed odiata dai manager: le metriche. Cerchiamo di capire cosa sono e a cosa ci possono servire in ambito ITSM.

Esistono diverse categorie di metriche (o di utilizzo delle metriche), tra le quali vi sono le seguenti:

• Metriche dette Operative, cioe' osservazione di eventi "operativi" nei processi ITSM. Esempi di tali metriche sono: il numbero di incidenti, il totale dei costi, etc...
• KPI (Key Performance Indicators), cioe' metriche che misurano le performance dei vari processi. Queste sono quelle piu' importanti e che ci devono guidare nella gestione dei processi. Esempi di KPI sono: %incidenti riaperti nel mese, % cambiamenti falliti (backed out). Tipicamente queste metriche sono calcolate a partire da metriche operative.
• Tolleranze, questo tipo di metriche misurano l'intervallo di tolleranza delle KPI, distinguendo i valori accettabili da quelli che non lo sono.
• Fattori Critici di Successo (FCS o CSF in inglese), cioe' KPI che sono fondamentali dal punto di vista del business o del cliente. Esempi di CSF sono: %Risoluzione di incidenti al primo contatto (importantissimo per il cliente).
• Dashboard (un tempo chiamati cruscotti ...), cioe' CSF utili da tenere sott'occhio per identificare in tempo possibili variazioni o trend che mettano a rishio il business.

Le relazioni tra le varie categorie e' esemplificata nel diagramma in basso.

In post successivi parleremo di metriche specifiche per i vari processi ITIL...