IT Management blog

Tanti auguri di un buon 2007 a tutti..... e a risentirci l'anno nuovo!

Una recente indagine della Ventana Research (http://www.ventanaresearch.com/) sulla gestione finanziaria dell'IT "unlocking the value of IT" (http://www.ventanaresearch.com/resources/resources.aspx?id=1814) basata su interviste a CIO (Chief IT Officer)( e manager IT ha mostrato come aziende che non applichino standard e metriche rigorose ai propri dipartimenti IT siano economicamente meno inefficienti di quelli che le applicano. La stima e' che in molti casi le aziende possano risparmiare dal 3 al 5 percento del loro budget IT attraverso pratiche di management migliori

Quasi tutte le grandi aziende hanno implementato pratiche di IT governance piu' strette nei 5 anni scorsi, ma l'attenzione si e' sopratutto focalizzata agli acquisti hardware e software, non sulle attivita' (operations). L'indagine mostra come l'uso di discipline quali l'IT portfolio management e la gestione finanziaria dell'IT siano critiche per un dipartimento IT cha voglia essere economicamente efficiente.

Le aziende che gestiscono le proprie attivita' IT in modo efficace hano una visibilita' dettagliata delle spese e utilizzano dati obiettivi per creare reports sull'utilizzo del budget IT: 

• Le aziende che hanno visibilita' immediata delle metriche di progetto e dei servizi IT hanno una percezione della efficienza economica dell'IT del 64% superiore a quelli che non hanno questa visibilita'
• Le aziende con processi formali di review risultano invece avere un efficienza economica del 22% superiore quelli che non hanno questi processi.

Le due pratiche (Financial Management of IT e Project/Service review) sembrano essere due gradini per migliorare l'efficienza economica dei propri servizi IT. Dall'indagine risulta anche che I manager dell'IT che utilizzano le risorse in modo piu' efficiente sono quelli che hanno piu' potere decisionale nel decidere il budget dell'IT.  

In un post precedente (http://marcoliuzzi.blog.com/1384335/) abbiamo parlato di Release Management. Di seguito diamo alcuni suggerimenti per l'implementazione del processo di Release Management.

Uno degli aspetti da documentare all'inizio dell'implementazione del processo e' la divisione dei compiti tra lo staff di sviluppo e quello  di supporto alle operazioni (operations). Il Release management coinvolge entrambe le parti:

• Lo staff di sviluppo e' normalmente responsabile per il design, sviluppo e costruzione (build) della soluzione, nonche' del testing. Il gruppo di sviluppo dovrebbe anche collaborare durante la messa in opera.
• Lo staff di operations e' normalmente responsabile per il processo, per la messa in opera e per il supporto.

Naturalmente le responsabilita' possono variare in base a necessita' specifiche, ma e' necessario che siano note e documentate.

Per poter implementare un processo di Release Management valido e' necessario avere la possibilita' di disporre di piu' ambienti (normalmente sviluppo, test e pre-produzione) in modo da poter fare il build e testing della soluzione in modo consistente a come verra' fatto in produzione. Non sempre questi ambienti sono disponibile, e questo puo' vanificare alcuni dei benefici del Release Management.

Un altro problema comune e' la manacanza di comprensione della Release. Quante volte vi e' capitato che il gruppo di sviluppo vi abbia dato il sistema, i sistemisti vi abbiano dato l'hardware: arrivederci e grazie. E adesso? Normalmente i vari gruppi dovrebbero essere tenuti sia a documentare tutta la release sia a fornire supporto durante la messa in opera. Se ricordate la definizione di Release Management c'era la parolina "holistic", che vuol dire che la release va vista nell'insieme e non solo nelle parti.

Un ulteriore comune ostacolo e' il seguente: il processo viene percepito come troppo burocratico e viene regolarmente bypassato. Com'era bello quando chiunque con una brillante idea era in grado di metterla in produzione senza fastidi (e la documentazione? e il supporto? e il testing ? sciocchezze, banalita' burocratiche...). A questo scopo e' fondamentale che tutti capiscono l'importanza ed i benefici del Release Management.

Un altro problema comune potrebbe essere lo scarso interesse del management all'implementazione del processo.  Questo puo' essere risolto facendo in modo che i manager vengano informati dei benefici nell'implementare il Release Management con "awareness campaigns" ed iniziative simili.

Avrete notato il nuovo look per l'IT Management Blog. Non che il precedente non mi piacesse, ma mi stava creando alcuni problemi di visualizzazione. Spero si risolvano con questo nuovo template....

Colgo l'occasione per augurare Buone Feste a tutti!!! Ci risentiremo sul Blog tra qualche giorno...

In un post di un paio di mesi fa' avevamo introdotto ITIL ed avevamo citato il processo di Release Management (vedi http://marcoliuzzi.blog.com/1183476/). Ne parliamo piu' in dettaglio in questo post.

La definizione "ufficiale" di Release Management in ITIL e' la seguente: 

• considerare in modo 'olistico' i cambiamenti ai servizi IT (to take an holistic view of a change to an IT service) ed assicurarsi che tutti gli aspetti di una release, tecnici e non, vengano considerati

Il release Management andrebbe utilizzato per:

• Implementazioni hardware massiccie o critiche
• Implementazioni software significative
• Implementazione contestuale di set di cambiamenti correlati

Le responsabilita' del processo di Release Management includono le seguenti:

• Pianificazione e coordinamento delle implementazioni di software nuovi (o di upgrade) con hardware e documentazione associati
• Coordinamento con il Change Management per validare l'esatto contenuto della release
• Assicurarsi che tutti gli item oggetto (o target) di implementazione siano tracciabili via CMDB
• Gestione delle aspettative dei clienti ed utenti nelle implementazioni

I seguenti concetti canno considerati con il Release Management:

• La Definitive Software Library (DSL), che contiene tutti le copie master di tutti i software in produzione, utilizzata e/o aggiornata con ogni release.
• Il Definitive Hardware Store (DHS), e' un area dove vengono mantenute i ricambi per l'hardware. Le parti nel DHS devono essere tracciate nel CMDB e mantenute allo stesso livello dell hardware in produzione
• Build Management, Il software e/o hardware che fa parte della release deve essere assemblato in modo controllato in modo che sia ripetibile e documentato
• Testing e Back-out, un piano di testing ed un piano di back-out (anch'esso va testato) fanno parte del corredo necessario ad ogni release prima che venga autorizzata

I benefici dell'implementare il Release Management includono i seguenti:

• Migliore qualita' dei servizi rilasciati come risultato di un maggiore percentuale di release finalizzate con successo
• Migliore utilizzazione delle risorse
• Certezza che l'hardware ed il software rilasciato in produzione siu di qualita' nota, riducendo in tal modo le possibilita' che software illegale, errato o non autorizzato sia in uso.

Una delle poche raccomandazioni di ITIL in termini di priorita' di implementazione dei processi e' quello di implementare i processi di configuration, change e release management insieme, e possibilimente di avere una funzione centralizzata per gestirli.

CA italia (http://www.ca.com/it/) ha commissionato un'indagine ad Ediformat (disponibile qui: http://www3.ca.com/it/Press/PressRelease.aspx?CID=94628) per "saggiare la percezione dei responsabili dei sistemi informativi sul livello dei servizi IT erogati all'azienda, sul rapporto con il management, sulla dinamica dei rapporti e dello scambio di informazioni con le altre aree dell'azienda e sui processi evolutivi pianificati o da attivare nel breve termine". L'indagine è stata presentata nel corso di un evento che si è tenuto il 26 ottobre a Milano. 

Il risultato dell'indagine indica che i Chief Information Officer (CIO) delle delle medie e grandi aziende in Italia sono in una posizione fluida, a cavallo tra una stretto controllo da parte del management e la voglia di "elaborare una strategia più direttamente orientata agli obiettivi di business" per poter "segnare un punto di svolta per il ruolo di chi oggi gestisce i sistemi informativi aziendali".

I dati raccolti dalle interviste hanno sembrano indicare "come la qualità delle richieste che arrivano dal business all'IT sia ancora viziata da una mancanza di conoscenza dell'azienda, che però l'IT fatica a migliorare. Nel lavoro ordinario prevale la gestione del contingente, perlopiù in assenza di un processo strutturato di flusso informativo fra i comparti aziendali". 

Questa situazione sembra, comunque in evoluzione: "La consapevolezza di dover allineare servizi IT e processi di business si sostanzia nello sviluppo delle best practice ITIL, nell'adozione di architetture SOA o nell'avvio, seppur graduale, di processi di governance". Il CIO si rende sempre piu' conto della necessita' di essere un manager organizzativo oltre che tecnologico, anche se il tempo riservato alla pianificazione sembra essere ancora abbastanza insufficiente (fra il 20 e il 30% del totale, con punte più basse fra il 10 e il 15%). 

In generale sembrano mancare ancora sistemi di misurazione obiettiva del valore prodotto dall’It, che viene spesso visto solo come un costo. Però qualcosa si muove: “Almeno i Kpi (Key Performance Indicator) sono usati per misurare meglio l’efficienza dei servizi It e gli Sla iniziano a prendere piede, quasi sempre su iniziativa diretta del Cio”.

Oggi e' stato rilasciato l' annual report dal Board of Directors di itSMF International (itSMFI) nel sito di itSMFI (il report e' disponibile su http://www.itsmf.org/node/197). Il report contiene il sommario delle attivita' del Board ed i progressi che sono stati fatti nel raggiungere gli obiettivi dell'organizzazione che sono, in sostanza di promuovere l'IT Service Management.

Alcuni punti salienti del report sono i seguenti:

• I seguenti Chapter dell'itSMF si sono costituiti: Irlanda, Spagna, Golfo Persico, Estonia, Grecia, Russia, Taiwan, Venezuela e Slovenia, portando il totale da 31 a 40
• Si pubblichera' un IT Service Management Journal
• Si e' lavorato sulle pubblicazioni di ITIL v3 (ne avevamo parlato qui: http://marcoliuzzi.blog.com/1319957/)
• Stanno lavorando su uno schema di certificazione su ISO 20000 (ne avevamo parlato qui: http://marcoliuzzi.blog.com/1322625/)

In un post precedente (http://marcoliuzzi.blog.com/1370810/) abbiamo parlato di Change Management. Di seguito diamo alcuni suggerimenti per l'implementazione del processo di Change Management.

Un aspetto importante da valutare nel pianificare l'implementazione del Change Management e' la dimensione dell'organizzazione su cui va implementato. Il processo specifico va disegnato sulle necessita' dell'azienda, un processo eccessivamente lungo potrebbe essere giusto per grandi organizzazioni, dove piu' entita' hanno necessita' di avere voce in capitolo, ma non potrebbe essere adatto a piccole organizzazioni, ove la complessita' non giustifica il beneficio.

Un altro elemento da tenere presente e' il tool che si usa per implementare il processo. Sistemi cartacei possono funzionare solo in piccolissime organizzazioni. Per organizzazioni anche di minima complessita' e' utile (fondamentale) considerare sistemi software di change management. E' utile che il tool si integri da un lato con il CMDB (http://marcoliuzzi.blog.com/1347546/) e dall'altro con i tool di incident e problem management (http://marcoliuzzi.blog.com/1240124/ e http://marcoliuzzi.blog.com/1273814/).

Naturalmente all'inizio il processo di Change Management verra' percepito come troppo burocratico e si cerchera' di bypassarlo (si citera' per giustificare l'urgenza, il "non lo sapevo" etc...). E' fondamentale che sia il management, sia tutto lo staff IT comprenda a fondo la necessita' ed i benefici del processo di Change Management e che lo utilizzi attivamente.

Naturalmente, se non esiste il Change Management anche il Configuration Management ne soffre (piu' che altro e' inutile fare Configuration Management se non vi e' il Change Management ad agire da getekeeper verso il CMDB). D'altra parte se non esiste un CMDB accurato (e quindi un processo di Configuration Management) anche il change management e' difficile se non impossibile.

Tra i benefici maggiori del Change Management vi sono i seguenti:

• Maggiore allineamento tra l'IT ed il business. Vi ricordate? questo e' uno degli scopi principali di ITIL (http://marcoliuzzi.blog.com/1183476/). Ogni nuovo cambiamento (quindi anche ogni nuovo servizio) deve passare un'approvazione di un CAB che includa anche la componente business (ove appropriato). Questo assicura che i maghi di IT non implementino servizi solo per provare l'ultima fantastica tecnologia.
• Migliore comunicazione. Nel processo di Change Management ci sono dei servizi gratuiti di (i partecipanti al CAB sanno dei cambiamenti, il tool di Change Management permette a tutti di vedere cosa bolle in pentola, etc...) che migliorano la comunicazione dei cambiamenti.
• Minore impatto dei cambiamenti. Quante volte avete scoperto il lunedi' mattina che non funziona nulla e non avete idea da dove iniziare per sistemare? Le attivita' di Change Management permettono una visibilita' di tutti i cambiamenti effettuati nell'infrastruttura ed aiutano nel processo di risoluzione degli incidenti/problemi
• Maggiore capacita' di implementare i cambiamenti. Standardizzando il processo non c'e' bisogno di reinventare l'acqua calda ogni volta che si deve implementare il cambiamento permettendo una maggiore efficienza nel processare i cambiamenti (bisogna pero' tenere presente che questo si ottiene dopo un certo periodo che si utilizza il processo).

E' nata un'iniziativa "gemella" a questo blog, il sito ITIL, Italia.

Il sito nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito verranno riutilizzati alcuni dei contenuti presentati in questo blog, organizzati in maniera migliore. Uno dei limiti della forma di comunicazione blog e' quella di dover presentare le informazioni in modo sequenziale. Questo problema viene risolto dal sito cui auguriamo una lunga e prospera vita.

Naturalmente l'IT Management Blog prosegue...

In questo post parleremo del processo di Change Management come definito in ITIL. Avevamo parlato dei processi in ITIL in un post precedente (http://marcoliuzzi.blog.com/1183476/).

Obiettivo del processo di Change Management e': l'utilizzo di metodi e procedure standardizzate per una efficiente e rapida gestione di tutti i cambiamenti all'infrastruttura, con lo scopo di minimizzare l'impatto di possibili incidenti correlati sui servizi IT.

Tipicamente, le attivita' nel Change Management includono le seguenti:

• Iniziare il processo di registrazione dei cambiamenti (o Request for Change, RFC)
• Valutare l'impatto, costi, benefici e rischi dei cambiamenti proposti
• Sviluppare giustificazioni (dal punto di vista del business) dei cambiamenti proposti ed ottenerne l'approvazione
• Gestire e coordinare l'implementazione delle RFC
• Monitorare e fornire report sulle RFC
• Fare la review e chiudere le RFC

I cambiamenti vanno autorizzati prima che inizi qualsiasi lavoro su di esse (e dopo che se ne e' fatta una valutazione di impatto, costi, benefici, etc...). Il processo di autorizzazione deve essere effettuato da un comitato che abbia il giusto livello di autorita', secondo il cambiamento previsto. Normalmente si stabiliscono del Change Advisory Boards (CAB) che possono includere:

• Change Manager (l'owner del processo di change management)
• IT staff dell'area relativa 
• Utenti o Clienti
• Esperti/Tecnici

Naturalmente non tutti i cambiamenti devono passare da un workflow complesso. Normalmente si distinguono degli standard changes, che prevedono un approvazione automatica che si adattano e cambiamenti molto comuni e ripetitivi (tipo creazione di account, etc...) e model changes che prevedono dei workflow specifici e/o semplificati che meglio si adattano al tipo di cambiamento (per esempio bug fixing, etc..).

Il change management dovrebbe occuparsi solo dei servizi IT in produzione. I singoli progetti dovrebbero avere un loro change management interno (ad esempio, nel PMBOK, vedi http://marcoliuzzi.blog.com/1203408/, esiste un processo di Project Scope control, nella knowledge area di Scope Management).

Il change management deve essere fortemente integrato con il project management perche' i cambiamenti (almento quelli piu' significativi) normalmente sono output di progetto.