Friday, October 21, 2011

Service Transition in ITIL v3, alcune considerazioni generali

L’obiettivo del libro ITIL v3 sul “Service Transition” è di assistere le organizzazioni che pianificano e gestiscono cambiamenti ai propri servizi nell’ambiente di produzione (live). E’ interessante notare come un intero stadio del lifecycle dei servizi in ITIL v3 sia dedicato alla questa transizione, a prova del fatto che è, a buon diritto, considerato un passaggio chiave, da gestire opportunamente. E’, altresì, interessante notare la gamma di aspetti diversi che vengono considerati nella transizione: organizzativi, tecnologici, di processo e relativi alla conoscenza e competenza.
I concetti di “Service Transition” sono particolarmente importanti per i due gruppi che si situano alle due sponde opposte della transizione: chi crea e sviluppa i servizi e chi li supporta nell’ambiente di produzione. I benefici dell’adottare un approccio standard e riproducibile nella transizione dei servizi, sono evidenti: dalla capacità di stimare correttamente i tempi e costi della transizione alla abilità di ridurre costi e tempi e processare un numero maggiore di “transizioni”.
A grandi linee, i momenti che vengono considerati parte della transizione sono quattro:

  1. La catalogazione, in una lista o pacchetto (package) consistente, dei sistemi, processi e funzioni che compongono il servizio da transitare nell’ambiente di produzione.
  2. La “costruzione” (build) di questo pacchetto in un insieme coerente ed interoperante.
  3. Il test del servizio in condizioni pari o equiparabili all’ambiente di produzione, incluso il testing della transizione
  4. Il rilascio del servizio nell’ambiente di produzione
Posted by mliuzzi in 22:07:54 | Permalink | Comments Off

Friday, September 9, 2011

Finalmente uno schema di certificazione di compliance ad ITIL di tool Software.

Come vi davamo notizia un po di tempo fa, attraverso l’Office of Government Commerce (OGC), l’APM Group ha finalmente creato uno schema di certificazione, o sarebbe forse meglio dire di endorsement, che permette ai vendor di software gestionale di poter usare il logo che certifica il software come “ITIL Process Compliant”. I vendor devono proporre i propri tool a dei “Licensed Software Assessors” che verificano la compliance. Vi sono tre livelli di endorsement: Gold, Silver e Bronze.

Il livello Gold indica che il prodotto software ha almeno tre clienti che usano effettivamente il prodotto in un ambiente di produzione, e che certificano che usano il tool per automatizzare specifici process ITIL in accordo con il framework. La certificazione si basa su delle evidenze prodotte dagli utilizzatori del prodotto software.

Il livello Silver indica che il prodotto software ha almento tre clienti che usano effettivamente il prodotto in un ambiente di produzione. L’unica evidenza richiesta è che il prodotto sia effettivamente in uso.

Il livello Bronze richiede solo che il Prodotto, il processo e la documentazione utente passino l’assessment.

Posted by mliuzzi in 20:27:38 | Permalink | Comments Off

Saturday, August 13, 2011

Ancora su ITIL v3 2011…

Vi elenchiamo di seguito altri cambiamenti in ITIL v3 versione 2011 rispetto alla precedente:
- La consistenza tra i vari libri e’ stata significativamente migliorata, cosi’ come la leggibilita’.
- Il libro di Service Strategy e’ stato significativamente migliorato, e’ stato reso piu’ accessibile e si collega molto meglio agli altri libri ed a tutto il concetto di lifecycle.
- E’ stato introdotto il nuovo processo di Design Coordination nel libro di Service Design.
- Il libro di ITIL Service Operation e’ stato reso meno ambiguo ed in particolare, i ruoli (technical management, etc…) sono stati ulteriormente chiariti.
- La (re)introduzione del proactive problem management e metodologie di analisi sono state altre utili addizioni al libro di Service Operations.
- Il libro che tratta la service transition e’ stato rivisto ed integrato in maniera migliore con gli altri libri. I diagrammi ed il relativo testo sono stati resi piu’ chiari.
- Molti degli aspetti “esoterici” delle relazioni tra SKMS, CMS E CMDB sono stati resi piu’ chiari.

Posted by mliuzzi in 11:59:04 | Permalink | Comments Off

Wednesday, August 3, 2011

ITIL v3 Edizione 2011 è stato rilasciato

Finalmente i libri di di ITIL v3 sono stati aggiornati. Sono stati resi disponibili da pochissimi giorni i cinque nuovi core book edizione 2011. Nel 2009 l’OGC, ovvero lo sponsor e “proprietario” di ITIL, aveva avviato un progetto di revisione dei cinque libri fondamentali che costituiscono il framework. La revisione arriva adesso, finalmente, a vedere la luce.

Qual’è l’impatto sul framework? In sostanza si tratta di un aggiornamento rispetto all’edizione precedente (che risale al 2007), non è quindi una vera nuova versione. Non porta cambiamenti rivoluzionari, come già aveva fatto ITIL v3 rispetto alla v2, ma incrementali. In pratica corregge errori e migliora la coerenza dei testi e tra i libri. L’aspetto interessante di questo aggiornamento è che accoglie le indicazioni che erano state segnalate dalla comunità mondiale nel Change Control Log andando a chiarire, aumentare la coerenza e correggere. La parte che è stata, probabilmente, più modificata è stata la pubblicazione sul Service Strategy per rendere i concetti in modo più chiaro, più conciso e più accessibile. Un altro aspetto dell’aggiornamento è stato lo sforzo a rendere il testo più adatto all’insegnamento, e non solo alla consultazione.

Posted by mliuzzi in 14:43:16 | Permalink | Comments Off

Thursday, July 14, 2011

Portfolio, Programme e Project Offices (P3O)

Come si evince dal titolo del post, P3O sarebbe la contrazione dell’acronimo di Portfolio, Programme e Project Offices.

Il modello P3O, della OGC, fornisce una struttura di supporto per tutti i tipi di cambiamento all’interno di un organizzazione. Il modello e’ abbastanza flessibile da permettere al suo interno diverse declinazioni di se stesso a secondo delle necessita’ e delle caratteristiche dell’organizzazione che lo implementa. In particolare le strutture di supporto possono avere diversi nomi, quali Portfolio Office, Centre of Excellence, Enterprise or Corporate Programme Office. Le strutture di supporto possono essere sia permanenti che temporanee, sia localizzate che centralizzate.

Sia PRINCE2, Managing Successful Programmes che Management of Risk menzionano la possibilita’ e l’opportunita’ di usufruire di strutture di supporto, ma non scendono nei particolari della loro implementazione e strutturazione.

P3O e’ il modello che fornisce le good pratice relative a queste strutture di supporto, in un insieme coerente di principi, processi e tecniche, rimanendo allineato a PRINCE2, MSP, e MoR.

Queste good pratice, che spaziano dall’ambito di progetto al programma, fino all’intero portfolio aziendale, coprono l’intero spettro organizzativo dai policy makers fino ai realizzatori.

Posted by mliuzzi in 21:32:36 | Permalink | Comments Off

Sunday, August 2, 2009

PRINCE2: Closing a Project (CP)

Dopo aver parlato qualche tempo fa’ di PRINCE2 e di due processi (Starting Up a Project ed Initiating a Project), ci occupiamo oggi del processo relativo alla chiusura del progetto: Closing a Project. Una delle definizioni stessa di Progetto in PRINCE2:

“Un organizzazione temporanea che ha lo scopo di produrre un risultato predefinito in un tempo predeterminato e con una quantita’ di risorse definita”,

implica che i progetti abbiano un “tempo predeterminato” e quindi una fine. Come tutte le cose, questa “fine” va gestita, ed il processo CP si occupa proprio di questo. I vantaggi di avere una chiara fine al progetto sono, tra gli altri, i seguenti:

  • si evita di impantanarsi in un ciclo di utilizzo e modifiche del prodotto;
  • si cede la gestione del “prodotto” generato dal progetto ai team “operativi” che si devono occupare del supporto del prodotto stesso;
  • si da’ l’opportunita’ di documentare tutti gli obiettivi eventualmente non raggiunti e le lessons learned.

Il processo CP puo’ iniziare in uno dei seguenti modi:

  • non appena l’ultimo stadio del progetto e’ stato approvato
  • se si comprende che il progetto non e’ piu’ utile per vari motivi

Il Processo CP e’ composto dei seguenti sotto-processi:

  • CP1 – Terminazione del Progetto (Decommissioning a Project). Questo sottoprocesso si occupa di assicurarsi che tutti i prodotti siano stati approvati e consegnati al cliente finale, che siano aderenti alle specifiche iniziali ed eventualmente passati a chi si deve occupare del supporto operativo. In questo sottoprocesso si raccolgono tutte i documenti di progetto e vengono opportunamente archiviati. Durante questo processo si comunica ufficialmente la chiusura del progetto a tutte le entita’ coinvolte.
  • CP2 – Identificazione di azioni successive (Identifying follow-on actions). In questo sottoprocesso si identificano tutti gli obiettivi eventualmente non raggiunti e si definiscono le eventuali azioni successive in un documento formale (Follow on Actions Recommendations).
  • CP3 – Valutazione del Progetto (Evaluating a Project). In questo sottoprocesso si raccolgono tutte le informazioni valide per un “apprendimento organizzativo” cioe’ le informazioni necessarie a valutare il progetto e quelle utili affinche’ si impari sia dalle scelte giuste che da quelle sbagliate, nei progetti successivi. Il documenti formali prodotti in questa fase sono le lessons learned e l’End Project Report.
Posted by mliuzzi in 15:09:46 | Permalink | Comments (2)

Sunday, July 12, 2009

Implementazione di ISO/IEC 20000

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.

Posted by mliuzzi in 11:41:16 | Permalink | Comments (3)

Friday, June 12, 2009

COBIT e ITIL, due framework compatibili

Nelle solite scorribande su Internet per trovare materiale interessante, ho trovato disponibile in italiano un documento molto interessante sulla compatibilita’ tra COBIT ed ITIL (gia’ in precedenza disponible in inglese): “COBIT e ITIL, due framework compatibili” (pdf, 2.4 Mb, 103 pagine). Il documento, e’ stato realizzato a cura di AIEA, itSMF Italia e SDA Bocconi, ed è un’utile guida – soprattutto per chi non mastica l’inglese – per capire meglio come utilizzare congiuntamente  due  affermati framework per la gestione e la governance dell’IT.

Posted by mliuzzi in 09:55:47 | Permalink | Comments Off

Friday, May 1, 2009

Utilizzo di best practices…

Mi sono imbattuto casualmente su un articolo di un paio di anni fa (dicembre 2006), pubblicato nel sito ISACA (www.isacaroma.it), ma tradotto dall’originale inglese da Agatino Grillo su di una survey sull’utilizzo di COBIT nel mondo. Incidentalmente, l’articolo da anche utili informazioni sull’utilizzo di altri framework/best practices, ed e’ su questi che mi interessa focalizzare l’attenzione.

L’articolo in forma integrale e’ disponibile qui. Vi riporto i dati relativi all’utilizzo di framework/best practices per comodita’.

  • ITIL 54,3%
  • ISO/IEC 17799 53,4%
  • ISACA Audit Standards 47,3%
  • COSO Control 39,8%
  • IIA Audit Standards 27,5%
  • CMM/CMMI 23%
  • PMBOK (o PRINCE2) 22,8%
  • Accounting Audit Standards (AICPA, CICA, ICAEW, etc.) 20,8%
  • COBIT 20,2%
  • COSO ERM 17,4%
  • ISF 8,9%
  • None 3,4%
  • NIST 0,2%
  • ISO 27001 0,15%
  • ISO 9001 0,12%
  • Altri 8,4%

L’articolo non chiarisce l’ambito della survey, ma e’ interessante notare come ITIL risulti il maggiormente adottato nonostante non abbia incentivi “normativi” (mi si passi il termine) all’adozione, cioe’ non vi sono norme che ne obblighino l’adozione, ed a seguire vi siano tutta una serie di standard “normativi”, fino (vado a memoria) al CMM/CMMI e PMBOK (o PRINCE2) che “normativi” non sono, ma che pero’ vantano un’adozione nettamente inferiore ad ITIL (circa la meta’). Ci sarebbe anche da dire che PMBOK e PRINCE2 sono insiemi di best practices diverse, e che probabilmente non dovrebbero essere riportati nella stessa linea… Per la verita’ un po’ tutta la lista sembra un po’ troppo eterogenea. I dati rimangono comunque interessanti.



Posted by mliuzzi in 21:19:07 | Permalink | Comments Off

Tuesday, April 14, 2009

COBIT 4.1

Parecchi post fa, avevamo dato conto delle relazioni tra ITIL e COBIT, ma senza addentrarci in modo particolare su COBIT, proviamo a farlo in questo post.

I Control Objectives for Information and related Technology (COBIT)  - Obiettivi di controllo per le informazioni e tecnologie correlate – è un modello (framework), creato nel 1992 dall’associazione americana degli auditor dei sistemi informativi (Information Systems Audit and Control Association – ISACA), e dal IT Governance Institute (ITGI) per la gestione delle tecnologie informatiche –  Information and Communication Technology (ICT) . Questo marchio di fabbrica (cioe’ di essere un framework nato da una organizzazione di auditors) lo contraddistingue e lo caratterizza tra altri framework similari.
Uno degli aspetti importanti di COBIT e’ che ha raggiunto lo statuto di norma internazionalmente riconosciuta; l’Unione Europea ha indicato COBIT come uno dei tre standard utilizzabili per garantire la sicurezza dei sistemi d’informazioni (cfr. ad es. Gazzetta Ufficiale dell’Unione Europea L077 pag. 6, 23 marzo 2005).
COBIT fornisce ai manager, agli auditor e agli utenti dei sistemi IT una griglia di riferimento costituita da una struttura dei processi della funzione IT, rispetto alla quale si è venuto formando il consenso degli esperti del settore, una serie di strumenti teorici e pratici collegati ai processi con l’obiettivo di valutare se è in atto un efficace governo della funzione IT (IT governance) o di fornire una guida per instaurarlo.
COBIT è stato pubblicato per la prima volta nel 1996. La sua missione dichiarata è quella di “ricercare, sviluppare, pubblicizzare e promuovere un insieme internazionale di obiettivi di controllo di accettazione generale per l’utilizzo giornaliero da parte di manager e auditor”.
Le aziende devono soddisfare i requisiti di qualità, affidabilità e di sicurezza della loro organizzazione IT perseguendo obiettivi di efficacia, devono cioè:
  • controllare la funzione IT affinché fornisca le informazioni necessarie all’azienda
  • gestire i rischi che gravano sulle risorse IT
  • assicurarsi che la funzione IT raggiunga i propri obiettivi e che questi siano in sintonia con gli obiettivi aziendali
Devono inoltre perseguire obiettivi di efficienza, valutando la maturità dei processi e misurando le prestazioni della funzione IT.
Il modello COBIT si propone di rispondere a questi bisogni:
  • Fornendo un collegamento tra gli obiettivi della funzione IT e gli obiettivi aziendali
  • Organizzando le attività della funzione IT secondo un modello di processi generalmente accettato
  • Definendo gli obiettivi di controllo da utilizzare nella gestione
  • Fornendo un modello di maturità rispetto al quale valutare la maturità dei processi IT
  • Definendo obiettivi misurabili (goal) secondo metriche basate sui principi delle Balanced Scorecard
La versione corrente di COBIT (la 4.1 – rilasciata nel maggio 2007) divide il controllo della funzione IT in quattro domini:
  • Pianificazione e Organizzazione (Plan and Organise),
  • Acquisizione e Implementazione (Acquire and Implement),
  • Erogazione ed Assistenza (Deliver and Support),
  • Monitoraggio e Valutazione (Monitor and Evaluate).
Nei quattro domini sono collocati un totale di 34 processi, ai quali fanno capo, nella versione 4.1, un totale di 210 obiettivi di controllo; questi ultimi rivestono un’importanza centrale nel COBIT, al punto di dare il nome al modello stesso.
Il dominio Pianificazione e Organizzazione (Plan and Organise) copre gli aspetti strategici e tattici e si propone di individuare il modo migliore in cui la funzione IT può contribuire al raggiungimento degli obiettivi aziendali. Lo scopo è di comprendere se gli obiettivi della funzione IT sono noti a tutti all’interno dell’organizzazione, se la funzione IT è in linea con la strategia aziendale, se l’azienda sta utilizzando le proprie risorse in modo ottimale gestendo correttamente i rischi e fornendo la qualità richiesta.
I seguenti processi fanno parte di questo dominio:
  • PO1 Definire un piano strategico per l’IT
  • PO2 Definire l’architettura del Sistema Informativo
  • PO3 Definire gli indirizzi tecnologici
  • PO4 Definire i processi, l’organizzazione e le relazioni dell’IT
  • PO5 Gestire gli investimenti IT
  • PO6 Comunicare gli obiettivi e gli orientamenti della direzione
  • PO7 Gestire le risorse umane dell’IT
  • PO8 Gestire la qualità
  • PO9 Valutare e gestire i rischi informatici
  • PO10 Gestire i progetti
Nel dominio Acquisizione e Implementazione (Acquire and Implement) si provvede a controllare la gestione dei cambiamenti e la manutenzione di sistemi, servizi e applicazioni, sempre compatibilmente con gli obiettivi aziendali. Lo scopo è di comprendere se i progetti forniranno soluzioni in linea con le attese e con i tempi e costi stimati, se opereranno correttamente una volta rilasciati e se la modalità di gestione dei cambiamenti è in grado di assicurare che questi vengano posti in essere senza effetti negativi sull’operatività dell’azienda.
I seguenti processi fanno parte di questo dominio:
  • AI1 Identificare le soluzioni informatiche
  • AI2 Acquisire e manutenere il software applicativo
  • AI3 Acquisire e manutenere l’infrastruttura tecnologica
  • AI4 Consentire il funzionamento e l’uso dei sistemi IT
  • AI5 Approvvigionamento delle risorse IT
  • AI6 Gestire le modifiche
  • AI7 Installare e certificare le soluzioni e le modifiche
I processi nel dominio Erogazione ed Assistenza (Deliver and Support) si occupano dell’erogazione effettiva dei servizi, il che comprende anche il controllo della disponibilità, del rispetto dei livelli di servizio e della sicurezza del servizio stesso, così come il supporto agli utenti e la gestione dei dati e dell’ambiente fisico.
I processi del dominio si assicurano che i servizi IT vengano erogati in linea con le priorità aziendali, che venga effettuata una gestione ottimale dei costi, che il personale sia in grado di utilizzare i sistemi con cognizione di causa e in sicurezza e che le informazioni siano protette negli aspetti di riservatezza, integrità, confidenzialità che sono loro propri.
I seguenti processi fanno parte di questo dominio:
  • DS1 Definire e gestire i livelli di servizio
  • DS2 Gestire i servizi di terze parti
  • DS3 Gestire le prestazioni e la capacità produttiva
  • DS4 Assicurare la continuità di servizio
  • DS5 Garantire la sicurezza dei sistemiy
  • DS6 Identificare e attribuire i costi
  • DS7 Formare e addestrare gli utenti
  • DS8 Gestione del service desk e degli incidenti
  • DS9 Gestire la configurazione
  • DS10 Gestire i problemi
  • DS11 Gestire i dati
  • DS12 Gestire l’ambiente fisico
  • DS13 Gestire le operazioni
I processi nel dominio di Monitoraggio e Valutazione (Monitor and Evaluate) si occupano di verificare se le prestazioni della funzione IT sono in linea con le aspettative del vertice aziendale, se il sistema di controlli interni è ben congegnato, se sono saldi i legami tra le prestazioni della funzione IT e gli obiettivi aziendali e se è garantita la conformità a leggi e regolamenti.
I seguenti processi fanno parte di questo dominio:
  • ME1 Monitorare e valutare le prestazioni dell’IT
  • ME2 Monitorare e valutare i controlli interni
  • ME3 Garantire la conformità ai regolamenti
  • ME4 Istituzione dell’IT governance
Per ogni processo sono definiti degli obiettivi di controllo specifici. Inoltre vi sono due insiemi di obiettivi di controllo “generali” applicabili a ciascun processo:
  • il primo insieme riguarda i processi medesimi (si tratta controlli identificati con la sigla PCn – Process control n)
  • il secondo insieme riguarda i dati in ingresso e uscita ai processi (si tratta controlli identificati con la sigla ACn – Application Control n)
Secondo il modello, il raggiungimento degli obiettivi di controllo garantisce un ragionevole livello di confidenza riguardo al raggiungimento degli obiettivi aziendali connessi al processo e alla prevenzione dei rischi associati al processo stesso.
Il modello non impone necessariamente il raggiungimento di ogni obiettivo di controllo. Il management aziendale può decidere quali sono i controlli applicabili ad ogni singolo processo all’interno dell’azienda, quali andranno implementati e con quali modalità, o viceversa può accollarsi il rischio di non implementarli.
La norma COBIT (nella versione inglese) è pubblica e scaricabile gratuitamente (nel sito dell’ISACA). Per chi fosse interessato ad approfondirne il contenuto e’ consigliabile iniziare dal documento COBIT 4.1 Executive Summary and Framework, scaricabile anch’esso dal sito dell’ISACA.
Posted by mliuzzi in 21:33:55 | Permalink | Comments Off