Per la prima volta dalla nascita di ITIL l’OGC (Office of Government Commerce) ha ufficialmente avallato (pare) un framework di conformità ad ITIL per strumenti, documenti e processi di terze parti. Il framework sarà gestito dallo stesso gestore delle certificazioni ITIL (APMG) attraversi dei servizi di audit in joint venture tra Aspect Group Inc.e Service Management Consultancy Ltd. (SMCG). SMGC si occuperà di effettuare il servizio di audit in accordo con il framework di conformità.. L’OGC ha approvato l’utilizzo del marchio ITIL.

Vedi l’articolo originale su SearchCIO.

Nel Sito ITIL, Italia qualche giorno fa’ e’ uscito un interessante post sull’implementazione di ISO/IEC 20000, come descritta nello stesso standard. Lo standard ISO/IEC 20000 raccomanda l’utilizzo del ciclo PDCA (Plan - Do - Check - Act) per l’implementazione di tutti i processi, e definisce le varie fasi come segue:

• Pianificazione (Plan): identificazione degli obiettivi e dei processi necessari per fornire i servizi in accordo con le necessita’ dei clienti e le politiche aziendali
• Implementazione (Do): l’effettiva implementazione dello standard
• Controllo (Check): il monitoraggio e la misura dei risultati conseguiti rispetto agli obiettivi predeterminati
• Azione e Miglioramento (Act): L’attuazione delle azioni necessarie per rendere definitivo e/o migliorare il processo.

Il post poi prosegue a dettagliare le varie fase come descritte nello standard.

La CA organizza il seguente seminario gratuito: “Gestire al meglio le vostre attività di Change and Configuration Management (CMDB)”. 12 Febbraio Milano - 13 Febbraio Roma

L’occasione e’ valida per chi voglia dare un occhiata agli ultimi sviluppi in materia in declinazione CA. Un’implementazione efficiente delle modifiche è essenziale: le interruzioni hanno un impatto negativo che si riversa sull’intera organizzazione, e di conseguenza sulla produttività, sui clienti e sui flussi di ricavi. La crescita della complessità implica il fatto che le modifiche richiederanno ancor più risorse per l’individuazione e la risoluzione dei problemi, e quindi comporteranno costi accresciuti. Per questi motivi risulta ancor più difficile conseguire un reale cambiamento.

Gli amici di CA ci segnaneleranno processi (e senza dubbi anche eventuali tool a corredo) per aiutarci a districarci nei meandri del Change e Configuration Management.

Per maggiori informazioni: https://www.ca.com/it/events/list.aspx?c=10605&sp=&e=466

Con il 2009 riprendono le attività del Chapter del Sud Italia del Project Management Institute (http://www.pmi-sic.org) con un nuovo Seminario dal titolo “Il Project Management e il mercato del lavoro” il prossimo 28 Gennaio 2009, presso la splendida cornice del Palazzo PICO a Fuorigrotta, via Terracina.

Il tema scelto è caldo ed interessante: la relazione tra il mondo del lavoro e il project management. L’esperienza decennale della Dott.ssa Elisabetta Vernoni nel campo della formazione manageriale sarà preziosa per accompagnare gli ospiti nella scoperta e soluzione di questo interrogativo.

Maggiori informazioni sono disponibili nell’area apposita del sito del PMI-SIC, peraltro rinnovato di recente: http://www.pmi-sic.org/index.php?option=com_content&task=view&id=80&Itemid=1

Uno dei processi piu’ affascinanti introdotti in ITIL v3 e’ senza dubbio il processo di Knowledge management (o Gestione della Conoscenza). In qualche modo rimette il fattore umano all’interno del meccanismo perfetto (?) dell’IT service management. Il sito ITIL, Italia ci da’ alcuni spunti sul Knowledge Management che vi riassumo in breve di seguito.

Lo scopo principale di questo processo e’ di assicurare che le giuste informazioni siano disponibili a chi deve prendere delle decisioni, sia a livello di top management sia a livello di service desk staff.

Il processo di Gestione della Conoscenza e’ parte del Service Transition in quanto e’ uno degli elementi che e’ fondamentale “transitare” nell’ambiente di produzione. Gli utenti finali, lo staff del service desk ed altro staff di supporto devono avere le informazioni necessarie prima che il sistema nuovo venga “transitato” in produzione in modo da facilitarne l’adozione e da assicurare il corretto svolgimento dei rispettivi ruoli.

Un concetto importante nell’ambito della Gestione della Conoscenza e’ la struttura Dati-Informazioni-Conoscenza-Saggezza (Data-to-Information-to-Knowledge-to-Wisdom o DIKW), che non e’ altro che un metodo per capire le relazioni che intercorrono tra i dati, le informazioni, la conoscenza e la saggezza e spiega come ciascuno di questi elementi si basa sugli altri.

Naturalmente, occorre un sistema per aiutare nella gestione della conoscenza, che, secondo il glossario ufficiale italiano di ITIL v3, si chiama Sistema di gestione della conoscenza del servizio (Service Knowledge Management System o SKMS), ed e’ un insieme di strumenti e database che vengono utilizzati per gestire la conoscenza e le informazioni. Il SKMS, tra tanti altri elementi, include anche il Configuration Management System, così come altri strumenti e database. Il SKMS archivia, gestisce, aggiorna e mostra tutte le informazioni di cui un fornitore di Servizi IT necessita per gestire i servizi IT, durante tutto il ciclo di vita. Ovviamente tutte queste informazioni, come dicevamo prima, non sono tutte “informatizzabili” e spesso comprendono anche elementi quali:

• L’esperienza dello staff
• L’esperienza e conosenza degli utenti
• Informazioni esterne quali, dati aziendali, finanziarie, politiche etc.. che possono essere rilevanti per il supporto del servizio

Il SKMS e’ un po’ il cuore del processo di gestione della conoscenza, e, come tutte le cose va pianificato e gestito opportunamente.

Le informazioni da me riassunte sopra sono disponibili sul sito ITIL, Italia oppure direttamente sulla parte relativa al Knowledge Management.

Accanto alle classiche misure di performance dei progetti (Costi, tempi, earned value, etc…) si fa sempre piu’ strada il concetto di stabilita’ di progetto.

Si definisce stabilita’ di progetto (relative stability of a project) la resistenza (o viceversa, la sensibilita’) delle attivita’ e risorse di progetto ad eventi non pianificati. In altre parole, un progetto e’ stabile se riesce ad assorbire eventi non pianificati senza particolari ripercussioni sul piano originale. Un progetto si dice, invece, instabile quando, a fronte di eventi non pianificati, devia in modo significativo dal piano originale.

Si definiscono tre tipi di stabilita’:

• Stabilita’ positiva - quando un progetto, a fronte di eventi non pianificati, riesce a manternere invariato il piano originale (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto rimane invariata)
• Stabilita’ neutrale - quando un progetto, a fronte di eventi non pianificati, mantiene la variazione determinata dall’evento immodificata fino alla fine (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto viene ritardata degli stessi tre giorni)
• Stabilita’ Negativa - quando un progetto, a fronte di eventi non pianificati, subisce variazioni in misura maggiore a quelle determinate direttamente dall’evento (per esempio, a fronte di un ritardo di tre giorni su una consegna, la data di fine del progetto viene ritardata di un mese)

Ovviamente la stabilita’ di progetto, in molti casi, ha un costo, ed ovviamente anche un valore. Per avere un progetto a stabilita’ positiva (rispetto ai tempi) e’ spesso sufficiente costruire il piano con opportuni buffer di tempo tra un attivita’ e l’altra, in modo da poter assorbire ritardi. Questo sara’ tanto piu’ importante quanto l’ambiente di progetto e’ instabile (per esempio: si utilizzano nuove tecnologie, nuove risorse umane, possibilita’ di cambiamenti in corsa, etc…), mentre sara’ meno importante per progetti in ambienti relativamente stabili.

Certo e’ che i project manager di vecchio pelo queste cose le sanno gia’, pero’ adesso possono usare la nuova buzzword - Project stability - per giustificare i buffer al proprio management.

Fortunatamente il sito ITIL, Italia ci da ancora alcuni spunti per scrivere e ci fornisce ancora una volta nuovi contenuti in italiano su  ITIL v3.

Oggi tocca al processo di Access Management, nuovo con ITIL v3. Questo processo e’ parte del Service Operation nell’ambito del lifecycle di ITIL v3.Gli obiettivi di questo processo sono di fornire agli utenti i diritti per usare uno o piu’ servizi ed eseguire le politiche definite nei processi di Availability e Security Management 

Da quanto sopra si evince che questo processo e’ l’attuazione in pratica, appunto nel Service Operations - nell’operare quotidiano, di alcuni aspetti del Security Management relativi alla fornitura dei diritti di accesso (ed alcuni aspetti di Availability Management, in particolare quelli relativi al rendere disponibili le informazioni solo a chi e’ autorizzato).

Nel processo di Access Management si definiscono i concetti di accesso, identita’ e diritti (o privilegi). Tipicamente, il processo di Access Management viene svolto dal Service Desk, se necessario, il Service Desk passa la richiesta ad altri gruppi, anche se e’ utile che queste richieste possano essere tutte delegate al Service Desk, almeno per i tipi di accesso piu’ comuni.

Il processo si svolge, tipicamente, nelle fasi di richiesta di accesso,verifica, fornitura dell’accesso, monitoraggio dei cambi di stato, logging degli accessi, revoca o riduzione dell’accesso.

Maggiori dettagli nella parte del sito ITIL, Italia dedicata all’Access Management.

Il sito ITIL, Italia ci fornisce ancora una volta nuovi contenuti su  ITIL v3. Oggi tocca al processo di Request Fulfilment.

Il processo di Request Fulfilment e’ nuovo con ITIL v3. Questo processo e’ parte del Service Operation nell’ambito del lifecycle in ITIL v3. Gli obiettivi di questo processo sono sostanzialmente di fornire agli utenti un canale per richiedere (e ricevere) servizi standard per i quali esiste uno schema predefinito di approvazione (i.e. richiesta di un computer). Nell’ambito del processo di Request Fulfilment si definisce la Service Request come: una richiesta da un utente per un informazione, consiglio, un cambiamento standard (standard change) o per un accesso ad un servizio IT.

Le attivita’ del processo di Request Fulfilment in ITIL v2 erano incluse nel processo di Incident Management, ove si suggeriva di utilizzare per le Service request lo stesso workflow degli incidenti. Uno dei motivi per cui si e’ deciso di separare le due cose e’ che gli incidenti sono non-schedulabili o non-pianificabili, mentre le service request possono e devono essere pianificate.

Una trattazione piu’ approfondita e’ disponibile sulla pagine relativa (qui) del sito ITIL, Italia.