IT Management blog

Vi ricordo per tempo che il PMI-SIC (www.pmi-sic.org) ha organizzato per il 13 Ottobre una seduta di esami PMP e CAPM, come vi avevamo dato notizia in un post precedente. La deadline per l'iscrizione scade il 7 settembre.

Le due sessioni si terranno presso l'Hotel Splendid - Via A. Manzoni 96 -Napoli.

Per maggiori informazioni andate al sito del Southern Italy Chapter del Project Management Institute (PMI-SIC). Le istruzioni per l'iscrizione sono pubblicata alla pagina relativa del sito del PMI-SIC.

Continuiamo la nostra analisi sui vari libri di ITIL v3; in quersto post diamo al volume sul Service Design.

Il volume si occupa del disegno e sviluppo (design e development) dei servizi e dei processi di Service Management, del convertire obiettivi strategici (volume Service Design, ne abbiamo discusso nel post precedente) in un portafoglio (portfolio) di servizi IT ed asset IT. Nel volume viene data una particolare enfasi al riutilizzo di elementi gia' disegnati o sviluppati in precedenza.

Alcuni degli obiettivi del Service Design sono i seguenti:

• Assicurare che i servizi nuovi (o migliorati) rimangano consistenti ed integrati con tutti i processi, le architetture, le tecnologie ed i sistemi di gestione utilizzati
• Gestire i rischi per rendere piu' "delicato" il "go live" del servizio
• Disegnare il servizio per assicurarsi che sia supportabile e cost-effective
• Produrre e manutenere processi, policies, architetture e framework per un disegno di qualita'

Alcune delle attivita' coperte nel Service Design sono le seguenti:

• Analisi dei requirements di business
• Identificazione di soluzioni alternative o di riutilizzo di componenti esistenti
• Disegno della soluzione
• Sviluppo del criterio di accettazione degli utenti/clienti rispetto al nuovo servizio
• Assicurarsi che la soluzione sia in linea con le stratevie, architetture e policies
• Assicurarsi che l'organizzazione IT sia pronta a gestire il nuovo servizio
• Allineare gli OLA ed SLA rispetto alla nuova soluzione

Alcuni concetti chiave introdotti sono i seguenti:

• Il portafoglio dei servizi (il Service Portfolio)
• I modelli di servizio (Service Models)
• Service Design Package (SDP)
• Opzioni ed approcci per l'insourcing o outsourcing dei servizi

I seguenti processi fanno parte del Service Design:

• Service Level Management (gia' presente in ITIL v2)
• Availability Management (gia' presente in ITIL v2)
• Capacity Management (gia' presente in ITIL v2)
• IT Service Continuity Management (gia' presente in ITIL v2)
• Information Security Management (nuovo con ITIL v3)
• Service Catalogue Management (nuovo con ITIL v3)
• Supplier Management (nuovo con ITIL v3)

Entreremo piu' nel dettaglio in seguito...

Un po' di post fa abbiamo parlato della struttura di ITIL v3 (qui), e' tempo di andare a veder con maggiore dettaglio i vari libri che lo compongono. Il primo libro del set e' quello sulla Service Strategy.

Molti dei contenuti di ITIL v3, vengono direttamente dalla versione precedente ma, a detta degli stessi autori (Majid Iqbal e Michael Nieves), questo e' il libro che se ne distacca maggiormente tra i cinque volumi. Il libro si concentra sull'allineamento tra il business e l'IT, elemento presente anche in V2, anche se non sempre esplicitato. Questo volume non e' solo il primo di cinque volumi, ma anche un po' il collante tra di essi, in quanto i concetti descritti assicurano che durante tutto il lifecycle dei servizi, questi ultimi rimangano focalizzati sul business.

Nel libro vengono introdotti concetti che sono nuovi per ITIL. Per esempio viene introdotto un nuovo ruolo, il Service Product Manager, che rimane responsabile del lifecycle di ogni servizio. Questa innovazione riconosce che ogni servizio (oppure ogni classe di servizi) puo' avere le proprie specificita' e necessitare di una persona che possa vedere ogni particolare servizio dalla parte degli utenti. Questo e' uno degli esempi in cui l'allineamento con il business viene esplicitato maggiormente rispetto ad ITIL v2.

Un'altro elemento di novita' presente nel volume Service Strategy e' il concetto di Service Dynamics, che va ad arricchire il vecchio modello lineare causa-effetto, e che ha il potenziale per complicare un po' i diagramma ITIL... Alcuni autori ritengono che questa parte sia un po' troppo "accademica" ma che comunque rimanga un valido punto di vista.

Una delle critiche al libro e che e' un po' troppo avanzato e denso di teoria per il pubblico (le organizzazioni IT). Uno dei suggerimenti emersi nelle primissime letture e' quello di crearne una versione riassuntiva che possa essere letta e capita agevolmente da tutti. In realta' questa critica nasce dal fatto che la disciplina dell'IT Service Management e' diventata piu' avanzata di quello che era 10 anni fa con V2 e quindi gli argomenti si fanno via via piu' complessi, come e' normale con la crescita.

Questi primi assaggi fanno pensare che ITIL v2 rimarra' ancora in giro per qualche anno, non per demeriti di ITIL v3, ma per l'obiettiva maggiore complessita' del framework.

Il 28 settembre 2007 si terrà l'evento “APM - Agile Project Management” organizzato dal PMI-NIC a Milano, presso l’Hotel dei Cavalieri. La giornata sarà condotta da Mr. Sanjiv Augustine, autore del libro "Managing Agile Projects", e riferimento internazionale in materia di Agile Project Management, per la prima volta in Italia.

La formula scelta è quella del Workshop, con un coinvolgimento attivo dei partecipanti al fine di contribuire allo sviluppo di APM. L'evento e' organizzate in tre fasi: 

• Presentazione delle teorie di Agile Project Management, ove lo speaker riassume i concetti di pase dell'APM ed illustra il modello da lui sviluppato nel libro citato in precedenza.
• Sessione di Lavoro in sottogruppi: "APM Practice: dall'idea all'attuazione", ove si cerca di applicare e di trarre frutto dalle esperienze di ogni partecipante al framework di APM proposto
• Presentazione delle proposte di APM da parte di ogni sottogruppo e conclusione dell'evento

Maggiori dettagli disponibili qui. L'iscrizione può essere fatta esclusivamente online scaricando l'apposita scheda dalla homepage del sito www.pmi-nic.org.

Parecchi post fa avevamo parlato di Project Procurement Management (gestione dell'approvvigionamento di progetto), come una delle 9 knowledge area del PMBOK (vedi  post relativo). Ne parliamo in questo post, e cosi' concludiamo la panoramica delle 9 Knowledge area, elencate di seguito:

• Project Management Integration
• Project Scope Management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resources Management
• Project Communication Management
• Project Risk Management
• Project Procurement Management

Il Project Procurement Management include i processi di acquisto e/o acquisizione di prodotti o servizi da aziende esterne (o piu' in generale da entita' esterne) necessari per raggiungere i risultati del progetto.

I processi inclusi nel Project Procurement Management sono:

• Il Plan  purchases and Acquisitions (pianificazione degli acquisti), che fa parte del Planning process group, si occupa della determinazione degli elementi da acquistare o acquisire, quando e con quale modalità. gli output di questo processo includono il piano di acquisizione delle forniture (Acquisition plan), il capitolato contrattuale ed i criteri di scelta tra il produrre i beni o servizi necessari internamente o acquisirli esternamente (make or buy decision).
• Il Plan Contracting (pianificazione delle forniture), che fa parte del Planning process group, si occupa della gestione della documentazione dei requisiti di prodotti, servizi e risultati oggetto di approvvigionamento e individuazione dei potenziali fornitori. Gli output di questo processo includono le specifiche (tecniche e non) delle forniture richieste e i criteri di valutazione delle proposte dei fornitori.
• Il Request Seller Responses (richiesta delle risposte dai fornitori), che fa parte dell'executing process group, si occupa del reperimento di informazioni, preventivi, offerte o proposte in base alle necessità di progetto.
• Il Select Sellers, (selezione dei fornitori), che fa parte dell'executing process group, si occupa della valutazione delle offerte, scelte tra i potenziali venditori e/o fornitori e della stipula di contratti scritti con ciascun fornitore prescelto. Vi sono naturalmente molti elementi da valutare nella selezione tra cui (naturalmente) il costo, le caratteristiche tecnica della fornitura e gli eventuali rischi legati alla fornitura stessa (fornitore con una pessima storia etc...)
• Il Contract Administration (amministrazione del contratto), che naturalmente fa parte del controlling process group, si occupa della gestione dei contratti e delle relazioni tra acquirente e fornitore, nonche' della revisione e documentazione delle prestazioni presenti e passate del fornitore per definire, se necessario, eventuali azioni correttive e gettare le basi per una collaborazione futura con il fornitore. Oltre a cio' questo processo si occupa della gestione delle modifiche relative al contratto e, ove necessario, della gestione delle relazioni contrattuali con l’acquirente esterno del progetto, naturalmente nel caso il progetto non sia interno all'organizzazione ma eseguito su commissione contrattuale. Questo processo interagisce significativamente con altri processi di problem management nei seguenti task: autorizzare il lavoro del fornitore al momento giusto (Time Management); reporting delle prestazioni per monitorare il costo, la schedulazione e le prestazioni tecniche del fornitore (Communication Management); esecuzione del controllo di qualità per verificare l’adeguatezza del prodotto del fornitore (Quality Management), etc...
• Il Contract Closure (chiusura del contratto), fa naturalmente parte del Closing process group, e si occupa del completamento e conclusione dei vari contratti, compresa la risoluzione di eventuali questioni aperte e/o contenziosi. Il contract closure prevede anche le attività amministrative relative, quali l’aggiornamento degli archivi con i risultati finali allo scopo di poter riutilizzare le informazioni in futuro.

Anche in questo caso sarebbe interessante vedere i vari processi nel dettaglio, speriamo di avere il tempo di farlo nel prossimo futuro...

Uno dei libri parte del framework ITIL (v2) e' l'Application Management, il libro "giallo". Questo libro descrive come sviluppare le applicazioni partendo dalla gestione della domanda di business, attraverso tutte le fasi nel ciclo di vita di una applicazione, fino alla sua dismissione. Come e' naturale in ITIL, nel libro si pone enfasi sull’assicurare che i progetti e le strategie IT siano fortemente allineate. 

L'Application Management e' la disciplina (o se vogliamo il set di processi) che descrivono il management delle applicazioni software dall'inizio fino alla dismissione, in questo ciclo si trovano a monte il processo di sviluppo ed a valle l'IT Service Management. L'Application Management si occupa di creare un ponte tra le due discipline per assicurarsi che gli obiettivi di IT Service Management (e quindi del business...) siano gia' chiari nelle fasi iniziali di sviluppo.

L'Application Management offre una descrizione end-to-end dei processi di gestione che devono essere eseguiti nel corso del lifecycle di un'applicazione (dall'idea alla dismissione). Fornisce una descrizione ad alto livello delle responsabilita' e dei task da effettuare. Nel fare cio' fornisce una sorta di workflow (roadmap nel libro) che i professionisti dell'IT possono seguire nel rilascio di nuove applicazione software nell'infrastruttura ICT. Questa parte potrebbe sembrare molto vicina al processo di Release Management, ma in realta' va molto oltre fino a coprire il processo di sviluppo software quasi nella sua interezza.

Sebbene le disciplina di IT Service Management, Sviluppo Software ed Application Management siano distinte vi e' un forte grado di interazione, con l'Application Management a fungere da ponte tra le altre due. Il lifecycle dell'Application Management, come descritto in ITIL, e' in effetti la combinazione degli altri i due processi:

• Requirements
• Design
• Build
• Deploy
• Operate
• Optimize

Le prime tre sono normalmente parte dello sviluppo software, mentre le altre tre sono parte di IT Service Management (e' opinabile, ma realistico descriverlo cosi'). Naturalmente il cerchio si chiude quando la fase di Optimize suggerisce nuovi requirements.

Alcuni dei benefici dall'Application Management includono i seguenti: 

• La gestione delle applicazioni software come assets aziendali aiuta a focalizzarsi non solo all'output di progetto (il software), ma alla integrazione dello stesso all'infrastruttura esistente ed al business. Normalmente questo obiettivo si ottiene anche implementando sistem di gestione di application portfolio
• Collegare i irequisiti di business ai requisiti dell'applicazione permette alle aziende di effettuare i controllo di qualita' (testing) sulla base del valore aggunto al business piuttosto che alla mera funzionalita' del software. Sembra banale, ma vi e' un mondo qui dietro...

Sarebbe bello ed utile scendere nel dettaglio, speriamo e contiamo di poterlo fare...

Dopo tanto IT Service Management, ritorniamo al Project management: parecchi post fa avevamo parlato di Project Risk Management (Gestione dei Rischi di progetto), come una delle 9 knowledge areas del PMBOK (vedi post relativo). Ne parliamo in questo post.

Il Project Risk Management e' la knowledge area che raggruppa i processi relativi al Risk Management (gestione del rischio), e quindi alla identificazione degli stessi, alla analisi e definizione delle azioni di risposta ad essi ed al loro controllo nel corso del ciclo di vita del progetto. Contrariamente al senso comune, il Risk puo' essere sia positivo (opportunita') che negativo (rischio). Il Project Risk Management si pone come finalita' l’aumento delle probabilità e dell’impatto delle opportunita' e la diminuzione della probabilità e dell’impatto dei rischi (intesi come eventi negativi ai fini di progetto).

Il PMBOK identifica nella knowledge area di Project Risk Management i sei processi elencati di seguito:

• Il Risk Management Planning, che fa parte del Planning Process group, si occupa della parte di pianificazione e detreminazione delle metodologie che sottendono alla pianificazione ed esecuzione delle attività di gestione dei rischi nel progetto. Il Risk Management Planning assicura che le attivita' di risk management siano proporzionati al rischio e all’importanza data dall’organizzazione al progetto in modo da fornire sufficienti risorse e tempo per le attività di risk management e concordare le metodologie ed i criteri per la valutazione dei rischi. Questo processo, normalmente, dovrebbe essere avviato (e completato) nelle prime fasi di pianificazione del progetto, poiché è propedeutico  alla corretta esecuzione degli altri processi di questa knowledge area. L'output di questo processo e' il piano di risk management.
• Il Risk Identification, che fa parte del Planning Process group, si occupa di determinare i le opportunita' ed i rischi che possono avere un impatto sul progetto e di documentare le loro caratteristiche. Normalmente, questo è un processo iterativo: con il progressivo avanzare del del progetto potrebbero infatti venire rilevati rischi nuovi. Output di questo processo e' la lista dei rischi identificati.
• Il Qualitative Risk Analysis, che fa parte del Planning Process group, si occupa di assegnare le priorità alle carie opportunita' ed ai rischi ai fini di un’ulteriore analisi od operazione attraverso la valutazione e la combinazione della probabilità che i rischi si verifichino e al loro impatto. Questo processo rappresenta in genere uno strumento veloce (ed economico) per stabilire delle priorità relative per lil risk response planning, e per il quantitative risk analysis (che potrebbe non essere svolta, se i risultati del qualitative risk analysis siano ritenuti sufficienti allo scopo). Il Qualitative Risk Analysis dovrebbe essere di tipo iterativo, da ripetersi nel corso del ciclo di vita del progetto per essere aggiornare le informazione in base alle relative modifiche dei rischi del progetto. Output del processo e' l'aggiornamento della lista dei rischi identificati con le relative probabilita' ed impatti.
• Il Quantitative Risk Analysis, che fa parte del Planning Process group, si occupa di analizzare numericamente l’effetto dei rischi identificati e ritenuti probabili e/o ad alto impatto dal processo di Qualitative Risk Analysis sugli obiettivi complessivi del progetto. IL Quantitative risk analysis esamina l’effetto di questi eventi di rischio e assegna loro un ordine ed una classificazione numerica che e' molto utile nel caso si volesse utilizzare un processo decisionale di tipo quantitativo (o automatizzato). Output del processo e' l'aggiornamento della lista dei rischi identificati con i relativi valori numerici.
• Il Risk Response Planning, che fa parte del Planning Process group, si occupa di identificare e pianificare azioni in risposta ai rischi identificati, orientate ad aumentare le opportunità e ridurre i rischi agli obiettivi di progetto. Le azioni di risposta pianificate devono essere commisurate alla probabilita' ed all'impatto del rischio, essere adeguate agli obiettivi finanziare del progetto, realistiche nel contesto del progetto, e condivise da tutte le parti coinvolte. Output del processo e' l'aggiornamento della lista dei rischi identificati con le relativi azioni di risposta ed eventualmente i contratti (assicurativi e non) posti in essere per la mitigazione dei rischi.
• Il Risk Monitoring and Control, che fa parte del Monitoring and Controlling Process group, si occupa di rilevare i rischi noti, monitorare i rischi residui, identificare i rischi nuovi, attuare i piani di risposta ai rischi e valutare l’efficacia di queste operazioni nel corso del ciclo di vita del progetto. Questo processo applica tecniche, quali lo scostamento e l’analisi delle tendenze, che prevedono l'uso di misure relative ad aspetti di esecuzione del progetto. Output del processo e' l'aggiornamento della lista dei rischi e le eventuali azioni correttive.

Anche in questo caso sarebbe interessante vedere i vari processi nel dettaglio, speriamo di avere il tempo di farlo...

Come promesso lasciamo sedimentare ITIL v3 per un po' e torniamo al caro ITIL v2. Un libro parte del framework ITIL (v2) e' l'ICT Infrastructure Management. Questo libro descrive le best practices per la definizione dei requirements, la pianificazione, il design, il deployment, la gestione operativa ed il supporto tecnico di una infrastruttura ICT (Information and Communication Technology).

I processi descritti nel libro ICT Infrastructure Management sono i seguenti:

• ICT Design and Planning
• ICT Deployment
• ICT Operations
• ICT Technical Support

Si notera' che vi e' un concetto (parziale) di lifecycle in questa area ITIL.

Normalmente questa parte e' meno nota della parte di IT Service Management, e spesso questi processi sono considerati parte implicita dell'ITSM.

La parte di ICT Design and planning offre guidelines per il design e l'implementazione di processi di gestione dell'infrastruttura ICT che soddisfi i requirements del business. Tra gli aspetti esaminati vi sono il procurement attraverso la produzione di Statements of Requirement ("SOR") ed Invitations to Tender ("ITT"). Altro aspetto importante sono le guidelines su come supportare dal punto di vista dell'infrastruttura ICT cambiamenti di strategia del business.

Alcuni output del ICT Design and Planning sono:

• le strategie, policy e piani ICT,
• la descrizione dell'architettura ICT e della sua gestione,
• business cases, studi di fattibilita', ITT e SOR.

La parte di ICT Deployment Management offre guidelines sull'implementazione di processi di gestione dell'infrastruttura ICT cosi' come pianificati. Quest'area e' molto vicina alla disciplina di Project Management PRINCE2, ma si focalizza sull'integrazione con il Release Management ed il testing.

La parte di ICT Operations Management si occupa della gestione giornaliera dell'infrastruttura, che non e' da confondersi con la parte di Service Support di ITIL, in quanto e' orientata all'infrastruttura e non solo agli utenti. Esistono chiare relazioni con il Service support, e con l'incident management in particolare ma l'ICT operation management dovrebbe occuparsi in primo luogo di operare a partire da processi e procedure specifiche quali Output Management, Job Scheduling, Backup and Restore, Network Monitoring/Management, System Monitoring/Management, Database  Monitoring/Management Storage Monitoring/Management.

L'ICT Operation Management deve assicurare:

• Un'infrastruttura ICT stabile e sicura
• Una libreria di Documentazione operative aggiornata
• Un log di eventi operativi
• La gestione di sistemi di monitoring dell'infrastruttura

La parte di ICT Technical support e' la funzione specialistica all'interno dell'organizzazione IT. Essa si occupa, a supporto di altri processi sia di Service Management che di Infrastructure management, di aspetti specialistici quali:

• Valutazione delle tecnologie
• Market Intelligence (in particolare per ICT Design and Planning e per Capacity Management)
• Proof of Concept e Pilot engineering
• Specialist technical expertise (in particolare per ICT Operations e Problem Management)
• Creazione di documentazione

Ancora su ITIL v3, solo un altro post e poi vi prometto che ci occuperemo di altro per un po'... 

Il chapter italiano dell'IT Service Management forum (www.itSMF.it), in collaborazione con IBM, sta organizzando degli eventi su ITIL v3. In particolare vi sono due eventi di una giornata dal titolo: "ITIL v3: una nuova milestone nell'evoluzione del Service Management"

• 10 Luglio 2007 - Sede IBM - Via Sciangai, 53 Roma
• 12 Luglio 2007 - IBM Forum - Circonvallazione Idroscalo - Segrate - Mi-

Nell'evento si presentera' il nuovo approccio delle best practice ITIL, le più utilizzate in ambito IT, analizzate dai maggiori esperti del settore.

Gli argomenti includeranno i seguenti:

• I contenuti dell'ITIL v3
• Introduzione ad ITIL e le principali novità di ITIL v3
• La mappatura dei processi ITIL v2 nella nuova struttura della versione 3
• I nuovi schemi di certificazione
• Il ruolo dell'associazione itSMF Italia per la diffusione di ITIL
• Il ruolo IBM nell'evoluzione di ITIL e del Service Management
• Posizionamento dei servizi e tecnologie IBM in supporto al ciclo di vita dei Servizi IT

Maggiori informazioni sono disponibili sul sito itSMF: http://www.itsmf.it/index.php?method=zoom_conferenze&id=48

Le qualifiche ITIL v3 prevedono quattro livelli :

• Livello Foundations. Questo livello si focalizza sulla conoscenza della terminologia e dei concetti di base di ITIL v3. Di fatto si mantiene molto simile nell'impostazione alla certificazione Foundations di ITIL v2
• 2 livelli intermedi, organizzati in due orientamenti diversi: "lifecycle" e "capability".
  • L'orientamento "lifecycle" e' organizzato sui 5 libri OGC relativi ad ITIL v3: Service Strategy, Service Design, Service Transition, Service Operation e Continual Service Improvement.
  • L'orientamento "capability" e' organizzato su quattro elementi principali: service portfolio & relationship management; service design & optimisation; service monitoring & control e service operation & support.
• Livello Avanzato (ancora non totalmente definito)

La novita' e' il concetto dei crediti formativi per poter avere il diploma ITIL, per ottenere il quale occorrono 22 crediti. Per esempio, la certificazione Foundations (di cui e' da poco uscito il syllabus, disponibile qui) vale come 2 crediti formativi. Il Diploma di livello avanzato rimane ancora da definire, e ci vorra' un po' di tempo. In questo contesto, anche le certificazioni ITIL v2 possono valere come crediti. Come e quanto, rimane da verificare... itSMF suggerisce di contattare gli ATO (Accredited Training Organisations) per capire a quanti crediti si ha diritto.

In particolare, chi ha una certificazione ITIL v2 ha le seguenti opzioni:

• Chi possiede la certificazione ITIL v2 Manager, e desidera ottenere il diploma ITIL v3 puo' frequentare un corso apposito di tre giorni, che copre le novita' di ITIL v3, e sottoporsi all'esame relativo.
• Chi possiede la certificazione ITIL v2 foundations puo' frequentare un corso di una giornata per poi sottoporsi all'esame ITIL v3 Fundations
• Chi possiede la certificazione ITIL v2 Practitioner puo' utilizzare il titolo come credito per il diploma ITIL v3.

Molte cose rimangono da chiarire da parte di itSMF e saranno senz'altro chiarite nei prossimi mesi, noi rimaniamo in ascolto...