IT Management blog

Avevamo detto brevemente di ITILv3 in un post di un mesetto fa', diamo maggiori dettagli in questo post.

ITIL v3, rappresenta una evoluzione importante di ITIL, ma non una rivoluzione. L'interfaccia tra la versione corrente (ITIL v2) e la nuova non dovrebbe introdurre complicazioni ed essere facilmente usufruibile.

Il punto di maggior distacco dalla versione precedente e' l'introduzione del concetto di lifecycle dei servizi, che gia' si nota nel set di pubblicazioni che saranno disponibili su ITIL v3 (e che abbiamo gia' citato nel post citato):

• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvement

Altri cambiamenti sono i seguenti:

• Si chiarisce l'integrazione tra la strategia di business e la strategia di fornitura dei servizi IT, di fatto considerati parte dello stesso "ecosistema"
• Si introducono elementi di "agile development"  nel'IT service Design
• Si introduce il concetto di Return On Investment (ROI) nel framework e migliora la misurazione del valore prodotto
• Fornisce modelli di transizione per l'adozione di innovazioni nei servizi IT
• Viene introdotto il concetto di Service Management Knowledge Base che traduce i dati registrati in "organizational intelligence"
• Maggiore dettagli vengono dati per contesti di IT Service Management specifici a particolari settori

Certamente ne parleremo ancora...

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

I processi di Quality Management comprendono le attività necessarie per definire le politiche di qualità, gli obiettivi e le responsabilità della gestione della qualità, affinché il progetto soddisfi le esigenze per le quali è stato intrapreso.  Il Quality Management si concentra su due aree:

• la gestione della qualita' del progetto, le cui best practices sono normalmente applicabili alla maggior parte dei progetti la maggior parte delle volte, e
• la gestione della qualita' del prodotto del progetto, che di sua natura e' dipendente dal tipo di prodotto (la gestione della qualita' del software e' molto diversa dalla gestione della qualita' nella costruzione di strade...)

L'approccio al quality management, come descritto nel PMBOK, è stato pensato per essere compatibile con quello definito dall’ISO (International Organization for Standardization). Questo approccio generico e' ritenuto (da chi scrive il PMBOK) anche compatibile con altri approcci all quality management, quali quelli di Deming, Crosby ed altri, nonché con altri approcci non proprietari tra cui Total Quality Management (TQM), Six Sigma, Failure Mode and Effect Analysis, Design Reviews, Cost of Quality (COQ) e Continuous Improvement.

Una delle definizioni di qualità utilizzata nel PMBOK è "il grado di conformità ai requisiti di una serie di caratteristiche intrinseche". Elementi centrali di questa definizione sono i requisiti, che vanno specificati nei processi relativi al Project Scope Management.

Il PMBOK sottolinea le differenza tra la qualita' ed il "livello" di un prodotto: qualità e livello non sono sinonimi. Il livello è una categoria assegnata a prodotti o servizi che hanno funzionalità uguali, ma caratteristiche tecniche diverse. Un esempio puo' essere quello dei pneumatici: esistono pneumatici che vanno usati solo sotto i 120 km/h, essi non sono di qualita' inferiori a quelli che possono andare fino a 180km/h, ma di livello inferiore, la differenza e' tecnica e non qualitativa. La bassa qualità è sempre un problema; un basso livello può anche non esserlo.

Il PMBOK identifica nella knowledga area di Quality Management i tre i processi elencati di seguito:

• Quality Planning, che consiste nell’identificare gli standard di qualità importanti per il progetto e dei modi per soddisfarli. Il processo di quality planning e' parte del Planning Process Group. Input principali del processo sono lo Scope di progetto ed il piano di Project Management, mentre output sono il quality plan insieme alle liste di controllo di qualita' e relative metriche.
• Quality Assurance, che e' l'applicazione sistematica delle attivita' relative al quality management per assicurare che il progetto implementi tutte le misure necessarie per soddisfare i requirements. Il processo di Quality Assurance e' parte dell'Executing Process Group. Input principali del processo sono il Quality plan, lo stato di avanzamento dei lavori e le misurazioni del controllo qualita', mentre gli output sono la richiesta di modifiche ed eventuali azioni correttive suggerite.
• Quality Control, che prevede il controllo dei risultati di progetto per determinare l'aderenza agli standard stabiliti nel processo di Quality planning e per identificare i modi per migliorare il livello di qualita' qualora non fosse soddisfacente. Il processo di Quality Control e' parte del Monitoring & Controlling Process Group. Input principale del processo e' ancora una volta il Quality plan, mentre output sono i deliverables eventualmente convalidati ed eventuali modifiche richieste.

Sarebbe interessante vedere i vari processi nel dettaglio con particolare riferimento alle varie metodologie utilizzate, magari un giorno lo faremo...

Qualche mese fa', in un post, abbiamo accennato alle metodologie di Agile Project Management. Approfondiremo qualche aspetto di implementazione dell'Agile Project Management in questo post.

Normalmente il processo inizia quando qualcuno inizia a pensare che vi sono modi migliori di approcciare le problematiche di project management in generale, e di sviluppo software piu' in particolare. Quando ci si rende conto che le metodologie "agili" possono essere una scelta valida allora dovrebbe iniziare un processo piu' analitico: siamo pronti, come organizzazione, per questo tipo di metodologie?

In generale, vi sono tre aspetti che vanno valutati per capire se la transizione puo' avere successo o meno:

• Disponibilita' dell'organizzazione al cambiamento 
• Lo stato dell'arte nell'organizzazione rispetto alle metodologie di sviluppo utilizzate
• Le aspettative rispetto alle metodologie "agili"
• I tempi previsti di implementazione

Uno dei problemi ovvi e' la resistenza al cambiamento dell'organizzazione. Esistono delle metodologie ovvie e testate che possono aiutare in tal senso, quali le awareness campaings, cioe' fare in modo che tutti gli attori siano convinti della bonta' del cambiamento. Nonostante la resistenza al cambiamento possa essere mitigata, una data organizzazione puo' assorbire solo una data quantita' di cambiamenti in un dato tempo, e' questo e' un fatto dal quale non si puo' prescindere.

Un altro elemento da valutare e' la manutenzione del codice esistente. Puo' essere svolta con in nuovi metodi? In alcuni casi si puo' approfittare della necessita' di riscrivere sistemi datati per passare ai metodi "agili". In altri casi non si ha il lusso di poter riscrivere i sistemi e la necessita' di dover mantenere vecchi e nuovi sistemi insieme puo' rallentare l'adozione delle nuove metodologie.

Per ovviare ai problemi di cui sopra si puo' scegliere di implementare solo alcune parti delle metodologie "Agili", almeno in un primo momento. Le parti da scegliere dipendono molto dalle pratiche esistenti, alcune candidate possono essere le seguenti: pianificare le release utilizzando story cards; gestire il progetto utilizzando la velocity come metrica; ed automatizzando la user acceptance. Il resto puo' essere implementato successivamente.  E' chiaro che in questo modo i tempi si allungano, ma si evita di sorpassare la capacita' di assorbimento dei cambiamenti dell'organizzazione.

Uno degli aspetti da tenere sempre presente e' che l'implementazione dipende fortemente dalle condizioni preesistenti, e le aspettative devono essere spalmate nel tempo in modo opportuno in modo da evitare di classificare il cambiamento come non riuscito troppo presto.

itSMF Italia organizza per il 18 Aprile 2007 una manifestazione intitolata:

ITIL@GOV, IL governo delle tecnologie dell’informazione

L'evento verte sulla maturità ormai raggiunta anche in Italia dal modello ITIL, standard mondiale sulla qualità dei servizi informatici, definitivamente accettato con l’incorporazione in ISO20000. Con questo evento itSMF Italia si presenta al mercato di Roma e del Centro-Sud Italia. La partecipazione è gratuita.

Luogo:
Conference Center SGM
Via Portuense, 741 - Roma

Per maggiori informazioni andate sul sito di itSMF Italia.

Nel post precedente abbiamo parlato di IT Service Continuity Management, in questo post daremo qualche accenno all'implementazione dello stesso.

Il Piano di IT Service Continuity Management non va costituito in solitudine, ma deve tenere presente i requisiti del business espressi nel Business Continuity Management (BCM). In ITIL vi e' una pubblicazione espressamente dedicata al Business Continuity Process: "An introduction to the Business Continutity Management"

Normalmente il Life Cycle del BCM comprende le seguenti fasi:

• Iniziazione (Initiation) - In questa fase si stabiliscono le policy. Tutte le parti coinvolte devono essere a conoscenza del proprio ruolo nelle policy. In questa fase si definisce anche l'ambito del BCM (terms of reference and scope), cioe' cio che va' dentro al piano e cosa si puo' lasciare fuori (perche' irrilevante, non rischioso etc...). Le risorse vengono allocate in questa fase. e si definisce la struttura. Una corretta impostazione nella fase di iniziazione permette (ma non garantisce...) che il resto del processo proceda correttamente.
• Requirements e strategia - In questa fase si effettua la Business Impact Analysis (BIA), cioe' l'analisi dell'impatto sul business di discontinuita' sui processi aziendali. Alcuni degli aspetti identificati nella BIA includono i seguenti: il tempo in cui il servizio va ripreso, lo staff, le facilities ed i servizi necessari per permettere alle funzioni aziendali identificate come critiche di operare ad un livello minimo accettabile. Altra attivita' che si effettua in questa fase e' il Risk Assessment, cioe' l'identificazione dei rischi, la determinazione dei livelli di probabilita' del rischio e di impatto dello stesso (threat and vulneerability levels). Esistono diverse metodologie di Risk Assessment, ITIL suggerisce il metodo CRAMM. Dalle informazioni ricavate dalle attivita' precedenti e' possibile definire una strategia di BCM che includa misure di riduzione del rischio (Risk Reduction Measures), varie opzioni di recovery, (tipici esempi sono: non fare nulla, avere dei workaround manuali, avere accordi reciproci con altre aziende che usino tecnologie simili, etc...)
• Implementazione - In questa fase si pianifica sia la struttura organizzativa che sottende al BCM che i vari piani operativi (Emergency response plan, Damage Assessment plan, Vital Records Plan, etc...). In questa fase si implementano le misure di riduzione dei rischi (generatori, UPS, offsite storage, etc...). Parte essenziale di questa fase e' la preparazione di procedure ben documentate di recovery , che includano anche un testing periodico.
• Gestione Operativa - La gestione operativa assicura che il BCM sia manutenuto come parte dei processi di business. In questa fase ci si assicura che tutti gli attori del BCM siano a conoscenza del rolo ruolo e che i cambiamenti all'infrastruttura siano riflessi nei vari piani di BCM. Elemento della gestione operativa e' l'invocazione del Business Continuity Plan, che se tutto e stato pianificato per tempo non dovrebbe dare problemi.

Alcuni degli elementi chiave di una buona implementazione di ITSCM sono i seguenti:

• Assicurarsi il buy-in del management
• Fare campagne di awareness sull'ITSCM a tutto lo staff

Chiedo scusa ai lettori del Blog per l'assenza di questi giorni. Sono in Congo per lavoro e da qui e' un po' difficile aggiornare il blog...

Dalla fine della prossima settimana dovrei tornare in Italia e riuscire a aggiornare il blog in modo regolare.

Saluti...

L'IT Service Continuity Management (ITSCM) e' un processo che fa parte della parte Service Delivery di ITIL. Obiettivo del processo di IT Service Continuity Management e' di supportare il processo di Business Continuity Management assicurando che i servizi IT possano essere ripristinati in tempi e modi predeterminati.

L'IT Service Continuity Management va un po' visto come un'assicurazione nel caso che il business venga interrotto, e come tale va fatta un'analisi costi benefici su cosa esattamente deve essere compreso in questo processo.

Il Business Continuity Management (BCM) e' il processo che si occupa della gestione dei rischi al business e che una azienda possa continuare ad operare (anche in forma minimale) se i rischi dovessero materializzarsi. L'ITSCM forma una parte integrate del BCM, ed e' focalizzata alla parte IT del processo (sempre piu' centrale per le aziende).

I benefici dell'ITSCM sono abbastanza ovvi:

• Assicurare che il business passi indenne da disastri o avvenimenti simili
• Riducendo la vulnerabilita' dell'organizzazione ai rischi identificati
• Producendo piani di recovery a supporto del BCM

L' ITSCM interagisce con altri processi, ed in particolare con:

• Availability Management, implementando misure di riduzione del rischio in modo da aumentare l'availability dei servizi
• Service Level Management, definendo i livelli di ITSCM
• Change Management, assicurandosi che l'ITCSM sia sempre in linea con l'infrastruttura corrente
• Service Desk/Incident Management, nell'utilizzo di dati storici.

Responsabilita' del processo di ITSCM sono le seguenti:

• Comprendere e valutare le differenti opzioni di IT Service Continuity e selezionare quelle piu' opportune in base alle necessita' del business (e quindi del Business Continuity Plan)
• Creare il piano di IT recovery ed assicurarsi che siano allineati con i piani di Business Continuity
• Identificare ruoli e responsabilita' nell'ambito del piano di IT recovery in particolare e di ITSCM in generale.

In uno dei prossimi post accenneremo brevemente ad alcuni aspetti relativi all'implementazione dell'ITSCM.