UNIVERSITÀ DEGLI STUDI DI GENOVA

Transcript

1 UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA Prova Finale GESTIONE DELLA TRANSIZIONE SECONDO LO STANDARD ITIL ITIL SERVICE TRANSITION RELATORI: Prof. Egidio Astesiano Ing. Stefano Bencetti CANDIDATO: Mario Zelaschi Anno Accademico 2008/2009

2 SOMMARIO Introduzione... pag. 4 Capitolo 1 ITIL v3 1.1 Storia di ITIL... pag Struttura di ITIL v3... pag ITIL e IT Service Management... pag Differenze fra ITIL v2 ed ITIL v3... pag. 9 Capitolo 2 Service Transition 2.1 Fondamenti del Service Transition... pag Criteri per il Service Transition... pag a Definire ed implementare un criterio formale per il Service Transition... pag b Implementare i cambiamenti ai servizi attraverso il Service Transition... pag c Adottare una piattaforma comune e degli standard... pag d Massimizzare il riutilizzo di processi e sistemi consolidati... pag e Allineare i piani del Service Transition con le necessità manageriali... pag f Stabilire e mantenere una connessione con gli stakeholder... pag g Stabilire controlli e discipline efficaci... pag h Fornire sistemi per il trasferimento di know-how e decision support... pag i Pianificare pacchetti di release e distribuzione... pag l Anticipare e gestire cambi di percorso... pag m Gestire le risorse attraverso il Service Transition... pag n Garantire un coinvolgimento anticipato nel ciclo di vita del servizio... pag o Assicurare la qualità del nuovo servizio... pag p Migliorare dinamicamente la qualità durante il Service Transition... pag. 24 2

3 Capitolo 3 Processi del Service Transition 3.1 Transition Planning and Support... pag Change Management... pag Service Asset and Configuration Management... pag Release and Deployment Management... pag Service Validation and Testing... pag Evaluation... pag Knowledge Management... pag. 102 Capitolo 4 Implementazione del Service Transition 4.1 Fasi dell introduzione del Service Transition..... pag Aspetti del cambio culturale..... pag Rischi e benefici.. pag Sfide. pag Fattori critici di successo.. pag. 112 Conclusioni... pag. 113 Bibliografia... pag. 114 Ringraziamenti... pag

4 INTRODUZIONE L argomento di questa Prova Finale sarà ITIL (IT Infrastructure Library), un insieme di template e best practice indirizzate a migliorare e rendere più efficace ed efficiente la gestione dei servizi erogati dalle organizzazioni IT. ITIL si colloca nell ambito dell IT Service Management, management interessato alla fornitura ed al supporto dei servizi IT preposti a sostenere il business di un organizzazione; fornisce un insieme completo, costante e coerente di pratiche per i processi di IT Service Management, promuovendo un modello di qualità che consente la creazione di valore per il business attraverso l utilizzo di sistemi informatici. La documentazione di questa Prova Finale sarà organizzata nel seguente modo: Cap I, ITIL v3: dopo una breve parentesi sulla storia di ITIL, conterrà informazioni sulle fasi di un Servizio IT nel ciclo di vita del servizio secondo ITIL v3, sui principali processi ITIL e sui ruoli coinvolti. Cap II, Service Transition: capitolo dedicato alla fase di Service Transition e ai criteri per una sua corretta implementazione. Cap III, Processi del Service Transition: analisi delle attività e dei macro processi che compongono il Service Transition. Cap IV, Implementazione del Service Transition: in questa sezione sarà analizzato il percorso da intraprendere per implementare correttamente il Service Transition, analizzando i vantaggi che ne derivano, i requisiti necessari, i rischi e le sfide da affrontare. 4

5 CAPITOLO 1 ITIL v3 1.1 Storia di ITIL Il concetto di ITIL è nato negli anni 80, quando il Governo britannico ha ritenuto che la qualità dei servizi IT non era sufficiente. Per ovviare al problema, la Central Computer and Telecommunications Agency (CCTA), adesso chiamata Office of Government Commerce (OGC), fu incaricata di occuparsi di sviluppare delle linee guida per un uso delle risorse IT efficiente e finanziariamente responsabile. Quella che noi chiamiamo ITIL v1 non fu altro che la prima versione di queste linee guida, intitolata Government Information Technology Infrastructure Method (GITM), che negli anni si è espansa fino a 31 volumi, concentrandosi sulle due aree di Service Support e Service Delivery. Molti dei principali concetti sulla gestione del servizio non erano stati creati all interno del progetto originale del CCTA che sviluppava ITIL: IBM rivendica infatti che i suoi Yellow Books ne siano stati un precursore. Durante gli anni 80 la diffusione di ITIL rimase limitata alla Gran Bretagna ed agli addetti ai lavori; il boom iniziò a metà degli anni 90, quando molte grandi aziende ne iniziarono l adozione. ITIL v2 uscì nel 2001 e le parti di Service Delivery e Service Support furono riassunte in due (più) concisi volumi. Microsoft nello stesso periodo rilasciò MOF, che si basa su ITIL. Il primo giugno 2007, sei anni dopo, l OGC ha rilasciato un ampio aggiornamento di ITIL, noto come ITIL v3. La pubblicazione iniziale di ITIL v3 è composta da cinque testi principali denominati: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement, consolidando così molte delle pratiche della versione v2 attraverso il ciclo di vita del servizio (Service lifecycle). 5

6 1.2 Struttura di ITIL v3 Il diagramma illustra lo schema del ciclo di vita di un servizio secondo lo schema ITIL v3. Il servizio nasce da una richiesta fatta dal business o da un cliente e può comportare lo sviluppo di un nuovo servizio oppure una modifica rilevante ad un servizio già esistente. Durante la fase di Service Strategy (SS), sono identificati e concordati i requisiti ed i risultati attesi e vengono documentati in un documento detto Service Level Package (SLP) che viene utilizzato dalla fase successiva. La fase di Service Strategy si trova al centro del ciclo di vita di ITIL v3 poiché stabilisce l orientamento di tutti gli IT Service Provider e dei loro clienti e li guida attraverso la costruzione di una chiara strategia di servizio tramite la precisa comprensione di: 6

7 Quali servizi devono venir offerti e a chi; Come devono essere sviluppati i mercati interni ed esterni per il servizio; Qual è l attuale e quale la potenziale concorrenza in questi mercati e in quali altri; Quali sono gli obiettivi posti per garantire una differenziazione; Come gli stakeholder percepiscono e misurano il valore e come questo valore può essere raggiunto; Come il cliente sceglierà il provider al quale commissionare la creazione di un servizio; Come il controllo sulla creazione del valore è raggiunto tramite verifica finanziaria; Come le risorse sono allocate in modo da garantire un effetto ottimale considerando il portfolio dei servizi; Come le performance dei servizi verranno misurate. Il Servizio passa quindi alla fase del Service Design, durante la quale viene prodotta e proposta una soluzione con un Service Design Package (SDP), che contiene tutto il necessario per portarlo lungo i rimanenti passi del suo ciclo di vita. Durante la fase di Service Transition (ST), ci si concentra sull implementazione del servizio definito nella precedente fase o, per usare i termini di ITIL v3, ci si concentra sul transitare il nuovo servizio IT in produzione. Gli obiettivi principali di questa fase sono: Capire tutti i servizi, le loro utilità e garanzie, poiché ciò è fondamentale per poter transitare il servizio IT in produzione; Stabilire una politica formale ed un framework comune per l implementazione di tutti i necessari cambiamenti assicurando nel contempo la continuità del servizio; Sostenere il trasferimento di know-how e la possibilità di riuso; Anticipare e gestire correzioni in corso d opera; Assicurare il coinvolgimento di questa fase in tutto il ciclo di vita del servizio. La successiva fase di Service Operation (SO) ha lo scopo di concordare un livello di servizio con i clienti e gli utenti e di gestire le applicazioni, le infrastrutture e le tecnologie per raggiungere tale livello. Solamente durante questa fase del ciclo di vita, il servizio fornisce valore al business perciò è fondamentale garantire che questo valore sia effettivamente fornito. Dopo la messa in funzione del servizio, la fase di Continual Service Improvement (CSI) dovrà correggere le mancanze (se presenti) e identificare eventuali opportunità di miglioramento in una qualunque delle precedenti fasi. 7

8 Questa fase è da considerarsi trasversale alle altre poiché è un ciclo continuo di cui deve essere tenuto conto durante ogni fase del Service lifecycle. 1.3 IT Service Management e ITIL IT Service Management (ITSM) è la disciplina che si occupa della gestione di sistemi di Information Technology (IT) su larga scala, filosoficamente concentrata sulla prospettiva del cliente e del contributo dell IT al business. La seguente è una delle classiche affermazioni che troviamo in letteratura quando si parla di ITSM: I fornitori di servizi IT non possono più permettersi di focalizzarsi solo sulla tecnologia, devono ora considerare la qualità dei servizi che forniscono e focalizzarsi nella relazione con il cliente. ITSM è incentrata sui processi ed in questo senso ha legami ed obiettivi comuni con altre discipline, framework e metodologie incentrate sul miglioramento dei processi. La disciplina non è interessata ad illustrare i dettagli di un determinato prodotto o i dettagli tecnici di un sistema informativo. È invece interessata a fornire un framework in grado di mettere in relazione le attività IT e le persone in esse coinvolte con business, clienti e utilizzatori. ITSM è generalmente legata al concetto di back office, o meglio al concetto di gestione dell IT, e non quindi allo sviluppo della tecnologia. Ad esempio, la realizzazione di un software per la scrittura di testi o la progettazione di un microprocessore non sono oggetto di interesse di questa disciplina, ma lo è piuttosto il sistema informativo utilizzato dal marketing. Molte società non appartenenti al settore della tecnologia, quali ad esempio società finanziarie e commerciali, hanno significativi sistemi informativi che non sono visibili ai loro clienti. Come già detto prima, ITIL è invece un insieme di linee guida ispirate dalla pratica nella gestione dell IT Service Management e consiste in una serie di pubblicazioni che forniscono indicazioni sull erogazione di servizi IT di qualità e sui processi e mezzi necessari a supportarli. L IT Service Management, quindi, in quanto concetto è relativo ma non equivalente a ITIL, che contiene una sezione specificatamente dedicata all IT Service Management, ovvero la combinazione dei volumi sul Service Support e Service Delivery i quali sono uno specifico esempio di un framework ITSM. 8

9 1.4 Differenze fra ITIL v2 ed ITIL v3 L introduzione dello standard ITIL v3, tesa a migliorare le practice ITIL in un ottica di Continuous Improvement, benché abbia portato significativi miglioramenti non può essere considerata una rivoluzione; infatti, una parte consistente di ITIL v2 continuerà ad essere presente in ITIL v3. Questo processo di perfezionamento è basato su consultazioni pubbliche e contributi dagli esperti del settore e dalla comunità ITSM internazionale. Come già accennato, il maggior punto di distacco fra ITIL v2 e ITIL v3 è l introduzione del concetto di lifecycle di servizi, che è un approccio strategico utilizzato in importanti aree ICT ed è legato alla loro industrializzazione e ingegnerizzazione. I Servizi IT dopo una lunga fase di sviluppo e maturazione si prestavano ad essere inquadrati nel loro ciclo di vita: quest ultimo ha una prospettiva più vasta di quella dei Processi o delle loro parziali aggregazioni (v2) ed ha l obiettivo di facilitare l integrazione Service Strategy con quella generale dell Azienda. La rappresentazione grafica delle cinque fasi del ciclo di vita è riportata nella figura seguente, ormai classica di ITIL v3: Da notare come il Continual Service Improvement eserciti la sua influenza lungo l intero ciclo di vita. Esso favorisce l inserimento dei Processi in un insieme integrato e facilita l integrazione dei Servizi con i Processi di business. La struttura costituisce un loop chiuso che produce feedback in tutte le fasi ciclo di vita. 9

10 Oltre ai 10 Processi fondamentali di v2, divisi in: Service Support (Incident Management, Problem Management, Configuration Management, Change Management, Release Management); Service Delivery (Service Level Management, Financial Management, Capacity Management, Service Continuity Management, Availability Management), i quali vengono ripresi da v3 e inseriti migliorati nel proprio framework, vengono introdotti 17 nuovi Processi, di cui: 3 in Service Strategy: Demand Management, Service Portfolio Management, Strategy Generation; 1 in Service Design: Service Catalog Management; 3 in Service Transition: Transition Planning and Support, Service Validation and Testing, Evaluation; 3 a cavallo tra SD e ST: Information Security Management, Supplier Management, Knowledge Management; 4 in Service Operation: Event Management, Request Fulfillment, Access Management, Operation Management; 3 in Continual Service Improvement: Service Reporting, Service Measurement, Service Improvement. I cambiamenti riflettono la maniera in cui la gestione dei servizi IT è maturata nei passati decenni. Il nuovo modello cambia il rapporto fra IT ed il business, per esempio: Dove ITIL v2 lavorava per allineare la gestione del servizio con la strategia di business, v3 li integra in un singolo ecosistema; Dove v2 parlava di allineamento fra Business e IT, v3 enfatizza l integrazione fra Business e IT; Dove v2 parlava di gestione della catena del valore (Value Chain Management), v3 enfatizza l integrazione della rete di valore (Value Network Integration); Dove v2 parlava di Catalogo lineare del servizio (Linear Service Catalog), v3 enfatizza il concetto di Portfolio dinamico del servizio (Dynamic Service Portfolios); Dove v2 parlava di collezione di processi integrata (Collection of integrated processes), v3 enfatizza il concetto di ciclo di vita olistico della gestione del servizio (Holistic Service Management lifecycle). I benefici apportati da ITIL v3 sono numerosi ma in particolare ITIL v3: 10

11 Stabilisce l integrazione della strategia di business con la strategia del servizio IT; Permette una progettazione più agile del servizio e di un modello di Return On Investment; Fornisce i modelli di transizione che sono stati adattati per rispondere ad una varietà di innovazioni; Sottopone a critica la gestione dei fornitori del servizio e i loro modelli di fornitura; Migliora la facilità di effettuare e di controllare i servizi in un ambiente dinamico, ad alto rischio di volatilità e soggetto ai rapidi cambiamenti delle necessità di business; Migliora la dimostrazione della misurazione del valore; Identifica gli inneschi per il miglioramento ed il cambiamento in ogni punto del ciclo di vita del servizio; Risolve le lacune e mancanze correnti in ITIL. 11

12 CAPITOLO 2 Service Transition Figura 2.2.1: Visione d insieme dei processi di ITIL v3 e dettaglio del Service Transition 12

13 2.1 Fondamenti del Service Transition Il Service Transition è supportato da alcuni principi fondamentali che evolvono dal Service Strategy e rafforzano e consolidano le pratiche e l approccio del Service Transition. Questi principi, oltre a capire cosa è un servizio e come apporta valore al business, sono alla base del Service Transition. La pubblicazione sul Service Strategy illustra la piattaforma per descrivere un servizio. Il valore di un servizio è definito nel contesto dei clienti e dei contratti, all interno di un ecosistema che è comunemente chiamato Business Enviromnent. I servizi sono un strumento tramite il quale una business unit fornisce dei valori a una o più altre business unit, o sotto-unità all interno di sé stessa. In questa pubblicazione, le business unit che forniscono servizi sono comunemente riferite come service provider o service unit, e chi usa questi servizi viene chiamato cliente o semplicemente business unit. L utilità di un servizio è definita nei termini dei risultati che i clienti si aspettano dal servizio e dai vincoli che esso è in grado di rimuovere. 2.2 Criteri per il Service Transition I seguenti punti costituiscono i criteri principali del Service Transition. La loro approvazione e applicazione da parte della dirigenza contribuisce all efficienza globale. Ognuno di questi criteri è esposto in maniera inequivocabile e la sua applicazione e approccio consigliati sono illustrati attraverso procedure consigliate che aiutano un organizzazione a rispettare tale criterio. 2.2.a Definire ed implementare un criterio formale per il Service Transition Policy Una policy formale per il Service Transition dovrebbe essere definita, documentata e approvata dal team di management, che deve assicurarsi che venga comunicata attraverso tutta l organizzazione e a tutti i fornitori e partner di rilievo. 13

14 Principi Best practice Le policy dovrebbero illustrare in maniera chiara ed evidente gli obiettivi e qualsiasi cosa estranea alla policy dovrebbe essere rimossa; Allineare le policy con le policy generali della piattaforma, organizzazione e Service Management; I finanziatori e il gruppo dirigenziale coinvolto nella stesura delle policy devono dimostrare il loro impegno nell adattare e implementare la policy. Questo include l impegno a fornire i risultati previsti per ogni cambiamento nei servizi; Usare processi che unifichino i vari team; fondere le competenze mantenendo tuttavia linee ben definite di responsabilità; Fornire i cambiamenti nelle release; Affrontare la distribuzione con sollecitudine nel piano delle release. Ottenere la chiusura formale da parte del team di management, dai finanziatori e dal gruppo di dirigenza coinvolti nello sviluppo della policy. 2.2.b Implementare i cambiamenti ai servizi attraverso il Service Transition Policy Principi Tutti i cambiamenti al Service Portfolio sono implementati attraverso il Change Management e i cambiamenti amministrati nella fase del Service Transition sono definiti e approvati. Un singolo nodo per i cambiamenti ai servizi di produzione minimizza le possibilità di cambiamenti conflittuali tra di loro e potenziali intoppi al sistema di produzione; Chi non ha i permessi di effettuare cambiamenti o introdurre novità all interno del sistema di produzione non deve avere la possibilità di farlo; Familiarità con l organizzazione del Service Operation aumenta l efficienza e permette cambiamenti organizzativi; Una buona conoscenza ed esperienza con i servizi e con l ambiente di produzione aumenta l efficienza; 14

15 Best practice Ogni versione verrà progettata e gestita da un Request for Change, generato dal processo del Change Management, per assicurare un efficace controllo e tracciabilità delle modifiche; Vengono usati metodi e procedure standard per una gestione pronta ed efficiente di tutti i cambiamenti, in modo da minimizzare disagi alla gestione del business derivati dai cambiamenti e impatti sulla qualità dei servizi; Tutti gli aggiornamenti dei cambiamenti e del rilascio di nuove versioni sono registrati nel Configuration Management System. La definizione di un cambiamento deve essere definita; I cambiamenti interni e esterni sono differenziati; I cambiamenti sono giustificati attraverso lo sviluppo di un Business Case ben definito; I cambiamenti ai servizi sono definiti in un Service Design Package che il Service Transition può usare per misurare le prestazioni attuali contro quelle predette dopo il cambiamento; L attuale processo di Change Management dovrebbe essere standardizzato e fatto rispettare con maggior fermezza; L impegno del management di far rispettare il processo è essenziale, e deve essere chiaramente visibile da tutti gli stakeholder; La verifica della configurazione aiuta ad identificare cambiamenti non autorizzati; Richieste tardive per cambiamenti che non possono essere adeguatamente amministrati non vanno accettate. 2.2.c Adottare una piattaforma comune e degli standard Policy Principi Basare il Service Transition su una piattaforma comune con processi e sistemi standard e riusabili, in modo da migliorare l integrazione con i reparti coinvolti nel Service Transition e ridurre i cambiamenti nei processi; Implementare le applicazioni consigliate come basi della standardizzazione, in modo da applicare l integrazione attraverso l intera catena di distribuzione; 15

16 Best practice Controllare la piattaforma e gli standard del Service Transition attraverso il Change Management e il Configuration Management; Assicurare che i processi siano adottati regolarmente, programmando verifiche regolari dei processi del Service Management. Pubblicare gli standard e le applicazione per il Service Transition; Fornire una piattaforma per istituire dei processi coerenti per garantire e valutare il profilo di rischio e le potenzialità di un profilo, prima e dopo che una sua versione sia rilasciata; Fornire sistemi di supporto per automatizzare i processi standard, in modo da ridurne la resistenza all adozione; Assicurarsi che vi sia la comprensione da parte del management della necessità di percorsi standard, sviluppando e rilasciando miglioramenti basati su un oculato Business Case; Stabilire il livello di coinvolgimento del management e degli stakeholder e impegnarsi a chiudere ogni divergenza. 2.2.d Massimizzare il riutilizzo di processi e sistemi consolidati Policy Principi Best practice I processi del Service Transition sono allineati con quelli dell organizzazione e con i suoi sistemi per migliorare efficienza e efficacia, e quando sono necessari nuovi processi, essi vengono sviluppati con questa sinergia in mente. Riutilizzare i processi e i sistemi già consolidati, ove possibile; Acquisire dati e informazioni dall origine per ridurre errori e migliorare l efficienza; Sviluppare modelli riusabili di Service Transition per acquisire esperienza e confidenza nelle procedure del Service Transition; Implementare le applicazioni e gli standard d industria come base per una standardizzazione, con l obiettivo di integrare le materie prime da diversi fornitori. Integrare i processi di Service Transition all interno del sistema di controllo della qualità; 16

17 Usare i canali di comunicazione preesistenti per le comunicazioni del Service Transition; Seguire i processi e le applicazioni per le risorse umane, il training, la gestione finanziaria e delle strutture; Progettare i modelli per il Service Transition in modo che permettano una facile personalizzazione per soddisfare determinate circostanze. 2.2.e Allineare i piani del Service Transition con le necessità manageriali Policy Principi Best practice Allineare i piani e i servizi del Service Transition con il cliente e le richieste del management, nell ottica di massimizzare il valore trasmesso dal cambiamento. Allineare durante la transizione le prospettive di clienti e utenti su come le prestazioni e il fine dei nuovi servizi possono essere usate per permettere un cambiamento nel business; Assicurarsi che il servizio possa essere usato in sintonia con le richieste e con i vincoli espressi nei requisiti del servizio, in modo da migliorare la soddisfazione di clienti e stakeholder; Comunicare e trasferire know-how ai clienti, utenti e stakeholder, per assicurare un loro uso efficiente del nuovo servizio; Monitorare e verificare l utilizzo dei servizi e delle applicazioni ad essi sottostanti durante lo sviluppo e nel primo periodo di vita del servizio prima di chiudere la transizione, in modo da assicurarsi che esso soddisfi le aspettative; Confrontare le prestazioni effettive dei servizi dopo una transizione con le prestazioni previste definite nel Service Design, con l obiettivo di ridurre le variazioni nelle potenzialità e prestazioni del servizio. Adottare le best practice consigliate per il programma e il Project Management per poter pianificare e organizzare le risorse necessarie, sviluppare, testare e rilasciare in produzione il prodotto, rispettando i costi, la qualità e le tempistiche previste; Fornire un piano chiaro ed esaustivo che permetta ai progetti di transizione di clienti e business di allineare le proprie attività con i progetti del Service Transition; Gestire impegni e comunicazioni degli stakeholder. 17

18 2.2.f Stabilire e mantenere una connessione con gli stakeholder Policy Stabilire e mantenere relazioni con i clienti, coloro che li rappresentano, utenti e fornitori attraverso il Service Transition in modo tale da trasfondere sul nuovo servizio o sui cambiamenti ad esso apportati le loro aspettative. Principi Guidare le attese degli stakeholder su come le prestazioni e gli usi dei nuovi servizi possono portare a un business change; Comunicare i cambiamenti a tutti gli stakeholder in modo da migliorare la loro conoscenza del nuovo servizio; Fornire informazioni valide in modo da permettere agli stakeholder di trovare informazioni sul Service Transition facilmente. Best practice Controllare con gli stakeholder che il nuovo servizio possa essere usato in accordo ai requisiti e alle limitazioni previste dai requisiti di sistema; Condividere con gli stakeholder Service Transition e piani di release; Lavorare col Business Relationship Management e il Service Level Management per relazionare clienti e stakeholder durante il Service Transition. 2.2.g Stabilire controlli e discipline efficaci Policy Stabilire adeguati controlli e discipline attraverso il ciclo di vita del servizio per rendere possibile una facile transizione dei cambiamenti al servizio. Principi Stabilire e mantenere l integrità dei service asset e delle configurazioni durante la loro evoluzione attraverso lo stadio di Service Transition; Automatizzare le attività di verifica in modo da aumentare il rilevamento di cambiamenti non autorizzati e discrepanze nelle configurazioni; Definire chiaramente chi fa cosa, quando e dove ; Definire e comunicare i ruoli e le responsabilità per ridurre errori risultanti da incomprensioni e mancanze di responsabilità. 18

19 Best practice Assicurarsi che ruoli e responsabilità siano ben definiti, mantenuti e compresi da tutti coloro coinvolti con qualsiasi processo rilevante per circostanze presenti e future; Assegnare persone a ciascun ruolo e mantenere l assegnazione nel Service Knowledge Management System (SKMS) o il Configuration Management System (CMS) per dare visibilità alla persona responsabile di particolari attività. Integrare i processi di Configuration Management con il Service Level Management per misurare la qualità degli elementi di configurazione attraverso il ciclo di vita del servizio; Assicurarsi che il servizio possa essere gestito, messo in atto e supportato in accordanza con i requisiti e le limitazioni specificate dall organizzazione del Service Provider all interno del Service Design; Eseguire verifiche sulle configurazioni e sui processi per identificare discrepanze non conformità nelle configurazioni che possano avere un impatto negativo sul Service Transition; Assicurarsi che solo personale competente possa implementare cambiamenti agli ambienti di testing e ai servizi in produzione. 2.2.h Fornire strumenti per il trasferimento di know-how e decision support Policy Il Service Transition sviluppa sistemi e processi per trasferire nozioni per l effettivo funzionamento del servizio e per permettere di prendere decisioni al momento giusto da parte delle persone di competenza. Principi Fornire dati di qualità, informazioni e nozioni nel giusto momento alle persone giuste in modo da ridurre il tempo speso e i conseguenti ritardi nell attesa di decisioni; Assicurarsi che vi sia un training e trasferimento di nozioni agli utenti adeguati in modo da ridurre il numero di chiamate verso il supporto tecnico; Migliorare la qualità delle informazioni per aumentare la soddisfazione di utenti e stakeholder, ottimizzando nello stesso tempo i costi di produzione e manutenzione; Migliorare la qualità della documentazione di release e distribuzione in modo da ridurre il numero di incidenti e problemi causato da una scarsa documentazione; Fornire un accesso facile a informazioni di qualità in modo da ridurre il tempo speso nella ricerca di materiale informativo, specialmente durante la gestione di attività critiche; Stabilire una fonte di informazioni definitiva e condividerle attraverso il ciclo di vita del servizio e con gli stakeholder, in modo da massimizzare la qualità delle informazioni e ridurre l overhead speso nel mantenimento delle stesse. 19

20 Best practice Riassumere e pubblicare gli effetti del cambiamento, prevedibili e non, deviazioni dall attuale contro prevista adeguatezza e performance, insieme al profilo del rischio. Assicurarsi che le informazioni sul Service Asset e Configuration Management siano accurate; Fornire know-how, informazioni e dati per le operazioni di sviluppo e supporto tecnico e fornire supporto ai team per risolvere problemi ed incidenti. 2.2.i Pianificare i pacchetti di release e distribuzione Policy I pacchetti di release vengono progettati per essere costruiti, testati, spediti, distribuiti ed esposti nel live environment, in modo tale da fornire i livelli di tracciabilità stabiliti, senza che cessi l efficacia nei costi di produzione. Principi Viene concordata con l amministrazione e le parti rilevanti una politica di release; Per ridurre i costi si ottimizza l utilizzazione delle risorse attraverso le attività del Service Transition; Le risorse vengono coordinate durante la release e la distribuzione; I meccanismi di release e distribuzione vengono pianificati in modo da assicurare che venga mantenuta l integrità dei componenti durante le fasi di installazione, gestione, imballaggio e spedizione; Tutte le release di emergenza vengono gestite secondo la procedura di Emergency Change; Vengono stimati e gestiti i rischi di interventi di sostegno o provvedimento ad una release fallita; Si usa come metro di giudizio il successo e fallimento dei pacchetti della release con l intento di migliorare l efficacia e l efficienza, pur tenendo presente l ottimizzazione dei costi. Best practice Tutti gli aggiornamenti delle release vengono registrati nel Configuration Management System; Le versioni definitive dei supporti elettronici, incluso il software, vengono archiviate in una Definitive Media Library prima della release nel test environment; Registrare le date in cui è prevista la distribuzione della release, facendo riferimento ai problemi ed alle relative richieste di cambiamenti; 20

21 I requisiti di una release vengono documentati e comunicati alle parti rilevanti. 2.2.l Anticipare e gestire cambi di percorso Cambiamenti di percorso Quando si progetta un itinerario lungo per una nave o aereo si fanno delle previsioni riguardanti venti, tempo ed altri fattori e, sulla base di questi, si progetta il viaggio. Lungo il percorso si compiranno controlli osservazioni basate sull esperienza vissuta al momento che richiederanno alterazioni anche minori per assicurarsi il raggiungimento delle destinazione. Anche una Transition di successo è un viaggio, a partire dal momento del come se, fino a giungere a quello del come richiesto. Nel dinamico universo in cui opera l IT Service Management succede spesso che si presentino fattori che differenzino il progetto iniziale del servizio, nuovo o cambiato che sia, dalla sua attuale transizione. Ciò implica la necessità di cambiamenti di percorso che vadano ad alterare l iter iniziale del Service Design, portando alla destinazione che il consumatore deve raggiungere. Policy Insegnare al personale come riconoscere la necessità di aggiustamenti del percorso e dare ad esso il potere di applicare le variazioni necessarie nei limiti prescritti. Principi Far sì che gli stakeholder considerino i cambiamenti necessari e da sostenere; Imparare dai cambiamenti di percorso precedenti per poter predire quelli futuri e riutilizzare gli approcci di successo; Analizzare e divulgare le informazioni tramite sessioni di debriefing riguardo al termine delle transizioni e trarre conclusioni, rendendole disponibili tramite il Service Knowledge Management System; Gestire le modifiche di percorso tramite un appropriato Change Management e procedure di riferimento. Best practice Usare le pratiche di Project Management ed il processo di Change Management per gestire i cambiamenti nel percorso; 21

22 Documentare e controllare i cambiamenti, senza però rendere il processo burocratico (deve essere più semplice farlo bene che subire le conseguenze di farlo in maniera errata); Fornire informazioni sui cambiamenti applicati successivamente alla costituzione della configurazione di base; Coinvolgere gli stakeholder nei cambiamenti quando appropriato, ma, allo stesso modo, gestire i problemi ed i rischi all interno del Service Transition. 2.2.m Gestire le risorse attraverso il Service Transition Policy Fornire e gestire risorse condivise e specialistiche attraverso attività di Service Transition, in modo da eliminare ritardi. Principi Riconoscere le risorse, abilità e conoscenze necessarie per dar vita al Service Transition all interno dell organizzazione; Formare una squadra (includendo al suo interno risorse esterne) in grado di implementare con successo la strategia del Service Transition, del pacchetto di Service Design e di quello di release; Destinare risorse dedicate per lo svolgimento delle attività critiche, così da ridurre i ritardi; Stabilire e gestire risorse condivise per migliorare l efficacia e l efficienza del Service Transition; Automatizzare i processi ripetitivi e con tendenza ad errori per migliorare efficacia ed efficienza dei processi chiave, come per esempio distribuzione, sviluppo ed installazione. Best practice Lavorare con le risorse umane (HR), i manager, ecc. per identificare, gestire ed utilizzare risorse competenti e disponibili; Riconoscere ed utilizzare risorse competenti e specialistiche, collocate al di fuori del gruppo principale ITSM, per implementare il Service Transition; Gestire attivamente le risorse condivise in modo da minimizzare l impatto che i ritardi di una transizione hanno su un altra; Misurare e mettere a confronto l effetto che l utilizzo di risorse dedicate o non ha sui ritardi. 22

23 2.2.n Garantire un coinvolgimento anticipato nel ciclo di vita del servizio Policy Pianificare controlli e discipline atti a verificare il prima possibile che un servizio nuovo o modificato sia in grado di espletare i compiti prefissati. Principi Usare un range di tecniche per massimizzare l individuazione di falle nel ciclo di vita del servizio il prima possibile per ridurre il costo di rettifica (più tardi si individua il problema, più alto sarà il costo di rettifica); Identificare i cambiamenti che non forniranno i benefici attesi e, prima di sprecare risorse, modificare i requisiti di sistema o arrestare il cambiamento. Best practice CoinvoIgere i clienti o i loro rappresentanti nei processi di testing, affinché concordino sull utilità che il servizio darà ai loro servizi di business; Coinvolgere gli utenti nei processi di testing ogni volta che è possibile. Basare tale processi sull effettivo modo di utilizzo del servizio e non solo su quello pensato dai progettisti; Utilizzare l esperienza precedente come metodo di identificazione degli errori nel Service Design; Incorporare il prima possibile la capacità di controllare e dimostrare che un nuovo o modificato servizio sarà in grado di espletare i compiti ad esso richiesti; Utilizzare una valutazione del Service Design indipendente e controlli interni per stabilire se i rischi dei progressi sono accettabili. 2.2.o Assicurare la qualità del nuovo servizio Policy Verificare e confermare che i cambiamenti proposti ai servizi operativi nelle definizioni di servizio e di release, Service Model e Service Design Package possano fornire i requisiti di servizio e i benefici al business richiesti. Principi Il Service Transition deve assicurare che i cambiamenti ai servizi operativi proposti vengano attuati in linea con accordi, specificazioni e piani; 23

24 Assicurarsi che i gruppi di Service Transition comprendano cosa i clienti e le aziende richiedono veramente da un servizio, per migliorare la soddisfazione di clienti ed utenti; L assicurazione di qualità e le pratiche di testing forniscono un metodo valido per garantire la qualità ed i rischi dei servizi; Gli ambienti di testing devono riflettere il Live Environment al più alto livello possibile, per ottimizzare l impegno impiegato nel testing; Il Test Design e la sua esecuzione dovrebbero essere gestiti e sviluppati indipendentemente dal designer e sviluppatore del servizio, per incrementare l efficacia del testing; Mettere in atto valutazioni indipendenti del Service Design e del servizio, per identificare i rischi da gestire ed attenuare durante lo sviluppo, il testing, la distribuzione e l utilizzo del servizio; Implementare i problemi ed i processi di Configuration Management attraverso il ciclo di vita del servizio per misurare e ridurre gli errori noti, causati nella produzione dalle release di implementazione. Best practice Comprendere i processi e le priorità dell azienda: ciò richiede spesso la comprensione della loro cultura, lingua, costumi e clienti; Il coinvolgimento degli stakeholder è importante sia per un efficace processo di testing che per guadagnare la fiducia dello stakeholder e dovrebbe quindi essere visibile nella comunità degli stakeholder; Comprendere la differenza tra la costruzione, il testing e i Production Environment, così da gestire le discrepanze e migliorare l abilità di predire il comportamento di un servizio; Gli ambienti di testing vengono mantenuti nel Change e Configuration Management e considerati rilevanti ai fini di qualunque tipo di cambiamento; Stabilire una linea di fondo del servizio e del Service Design prima di valutare il cambiamento; Valutare prima della release e distribuzione le potenzialità, qualità e costi previsti del Service Design, tenendo in considerazione il risultati delle esperienze precedenti; Considerare le circostanze che realmente si verificheranno quando il Service Transition sarà completo, e non solo quelle previste nel momento del design. 2.2.p Migliorare dinamicamente la qualità durante il Service Transition Policy Pianificare il miglioramento attivo della qualità del servizio durante la transizione. Principi 24

25 Identificare e risolvere gli incidenti ed i problemi durante la transizione, per ridurre la possibilità che si verifichino errori nel corso della fase operativa; Gestire e ridurre attivamente gli incidenti, i problemi e gli errori individuati durante il Service Transition, per ridurre i costi e l impatto sulle attività commerciali dei clienti; Allineare con i processi di produzione la gestione dei problemi sorti durante la transizione, così da stimare e gestire facilmente l impatto ed il costo degli errori sul ciclo vitale del servizio. Best practice Paragonare le potenzialità, le performance ed i costi reali del servizio con quelli previsti durante le prove, per identificare prima della chiusura del Service Transition i rischi eliminabili; Valutare in modo indipendente il servizio per identificare il profilo di rischio, dando priorità ai quei rischi che debbano essere mitigati prima della chiusura della transizione; Usare il profilo di rischio dalla valutazione del Service Transition per sviluppare test basati sul rischio; Fornire e testare con il supporto tecnico gli strumenti di aiuto per assicurare che, qualunque cosa vada storta nei processi di testing o nell utilizzo, si possano ottenere facilmente le informazioni chiave per identificare il problema, senza che questo abbia un eccessivo impatto sull utente; Incoraggiare il mutuo scambio di conoscenze tra gli stadi di transizione ed operazione, per migliorare le diagnosi ed i tempi di risoluzione; Stabilire procedure riguardanti incidenti nelle transizioni, problemi, errori, risoluzioni e provvedimenti che riflettano quelli utilizzati nel Live Environment; Risolvere gli errori noti e gli incidenti secondo la loro priorità di risoluzione; Documentare qualunque risoluzione, in modo tale che la documentazione possa poi essere analizzata; Analizzare in modo approfondito la causa scatenante degli incidenti più frequenti; Registrare, classificare e misurare il numero e l impatto degli incidenti e dei problemi di ogni release nelle fasi di testing, distribuzione e produzione, per identificare in anticipo la possibilità di risolvere gli errori; Mettere a confronto il numero e l impatto degli incidenti e dei problemi tra una distribuzione e l altra, così da identificare le migliorie ed aggiustare qualunque tipo di problema critico, in modo che migliori l esperienza dell utente nelle successive distribuzioni. 25

26 CAPITOLO 3 Processi del Service Transition 3.1 Transition Planning and Support 3.1.a Finalità, traguardi, obiettivi Finalità Pianificare le risorse adeguate per sviluppare, rilasciare, testare e mantenere una nuova versione del servizio in produzione; Fornire supporto al team del Service Transition; Assicurare che tutti i problemi, rischi e modifiche al Service Transition siano notificati agli stakeholder e decision maker di competenza. Traguardi Pianificare e coordinare le risorse in modo da assicurare che le richieste del Service Strategy codificate nel Service Design siano effettivamente realizzate nel Service Operation; Individuare, gestire e controllare i rischi di fallimento attraverso le attività di transizione. Obiettivi Pianificare e coordinare le risorse in modo da introdurre un servizio in produzione entro i costi, tempi e criteri di qualità previsti; Fornire piani chiari e compresivi che permettano al cliente di allineare le proprie attività con i piani del Service Transition. 3.1.b Prospettive Incorporare le esigenze di progettazione e operazionali all interno dei piani di transizione; Mantenere e integrare i piani di Service Transition attraverso il portfolio di clienti, servizi e contratti; Gestire i progressi, cambiamenti, problemi e rischi del Service Transition; Esaminare la qualità di tutto il processo di Service Transition; 26

27 Assicurare un efficiente comunicazione con clienti, utenti e stakeholder; Monitorare e migliorare costantemente le performance del Service Transition. 3.1.c Valore per il business Un Transition Planning and Support efficiente può migliorare significativamente le possibilità di un service provider di gestire alti volumi di cambiamenti e nuove versioni dei servizi attraverso tutto il suo parco clienti. Una pianificazione efficiente migliora l allineamento tra i progetti del Service Transition e i progetti di transizione di clienti, fornitori e business. 3.1.d Criteri, principi e concetti di base Il Service Design, in collaborazione con i clienti, i fornitori interni ed esterni all azienda e altri stakeholder di rilievo, sviluppa il Service Design e ne documenta le fasi in un Service Design Package (SDP). Il SDP include le seguenti informazioni, richieste dal team del Service Transition: I Service Package applicabili (Core Service Package, Service Level Package,..); Le specifiche del servizio; I modelli del servizio; I requisiti per poter implementare correttamente il nuovo servizio, inclusi gli ostacoli; Il progetto dettagliato di come le componenti del servizio si integreranno nel pacchetto di distribuzione; I progetti di sviluppo e rilascio della nuova versione; Il Service Acceptance Criteria. Criteri per il rilascio di una nuova versione di un servizio I criteri devono includere: Un identificativo univoco per ogni nuova versione di un servizio; I ruoli e le responsabilità ad ogni stadio dei processi di sviluppo e rilascio; La frequenza stimata del rilascio di una nuova versione; L approccio usato per l integrazione di nuovi cambiamenti in una nuova versione; Un meccanismo di automazione dei processi di installazione e distribuzione per migliorare il riutilizzo e l efficienza. 27

28 Una nuova versione di un servizio conta molte diverse tipologie di Service Asset e coinvolge numerose persone, spesso di diverse organizzazioni. Le responsabilità di ogni versione devono essere definite a priori, e poi eventualmente adattate alle esigenze della specifica transizione. I ruoli e le responsabilità principali devono essere definiti per ogni passaggio di consegne, in modo da assicurare che ognuna sia conscia del ruolo che gioca all interno del processo e del livello di autorità di ogni persona coinvolta in esso. Ogni nuova versione deve avere un identificativo univoco che ne permetta la veloce catalogazione in base all importanza della stessa (tipicamente: Major Releases, Minor Releases, Emergency Releases). 3.1.e Attività, metodi e tecniche per il processo Strategia di Service Transition L organizzazione deve stabilire l approccio migliore al Service Transition, basandosi sulla natura dei servizi principali e di supporto, sul numero e sulla frequenza di nuove versioni richieste e su qualsiasi necessità particolare degli utenti. La strategia di Service Transition stabilisce l approccio da parte dell organizzazione al Service Transition e all allocazione delle risorse necessarie ad esso. Gli aspetti da considerare sono: Scopi, traguardi e propositi del Service Transition; Contesto; Obiettivi; Standard, accordi e requisiti legali e contrattuali: o Standard interni e esterni, o Interpretazione delle linee guida industriali e legali e altri requisiti imposti, o Accordi e contratti inerenti al service transition; Organizzazioni e stakeholder coinvolti nella transizione: o Partner, fornitori e service provider, o Clienti e utenti, o Service Management, o Service Provider; Piattaforma per il Service Transition: o Ruoli e responsabilità, o Pianificazione e stima delle risorse necessarie alla transizione, o Requisiti per una corretta preparazione alla transizione, 28

29 o Autorizzazioni per la transizione, o Risorse e servizi comuni di supporto al Service Transition; Criteri: o Criteri di entrata e uscita per ogni step del rilascio della nuova versione, o Criteri per fermare e riprendere le attività di transizione, o Criteri di successo e fallimento; Identificazione dei requisiti e contenuti del nuovo servizio; Risorse umane: o Assegnare ruoli e responsabilità, o Assegnare e programmare formazione e trasferimento del know-how; Approccio: o Modello di transizione, inclusi gli stadi del lifecycle del Service Transition, o Piani per gestire cambiamenti, configurazioni diverse e know-how, o Stima dei costi e delle risorse necessari alla transizione, o Preparazione per il Service Transition, o Gestione, correzione e controllo degli errori, o Misurazione delle prestazione del servizio, o Indicatori chiave delle prestazioni e obiettivi di miglioramento; Piani di transizione, Change Management, Configuration Management, test, progettazione, valutazione e sviluppo, report di chiusura della transizione; Programmazione delle milestone; Requisiti finanziari, budget e finanziamenti. Preparazione al Service Transition Le attività di preparazione al Service Transition includono: Visionare e accettare gli input dagli altri stadi del lifecycle del servizio; Visionare e verificare gli input di SDP e Service Acceptance Criteria; Identificare sollevare e schedulare RFC; Verificare che le configurazioni di base siano registrate nel Configuration Management prima di dare inizio al processo di Service Transition; Verificare che la transizione sia effettivamente pronta ad avvenire. Le configurazioni di base aiutano a fissare un punto nella cronologia al quale le persone interessate possono fare. Ogni variazione agli obiettivi prefissati, ai requisiti del Service Strategy o alle regole base del Service Design deve essere richiesta e gestita attraverso il Change Management. 29

30 Pianificare e coordinare il Service Transition Pianificare un singolo Service Transition Lo sviluppo di un attività dovrebbe essere pianificato in stadi, poiché alcuni dettagli potrebbero non essere noti inizialmente. Ogni piano di Service Transition deve essere sviluppato a partire da un modello collaudato. Anche se il Service Design si occupa del progetto iniziale, all occorrenza di nuove circostanze il progettista, se necessario, deve allocare le risorse necessarie e modificare il piano. Un progetto di Service Transition descrive i compiti e le mansioni richieste per rilasciare una nuova versione di un servizio nell ambiente di testing e successivamente in produzione, tra cui: L ambiente e l infrastruttura di lavoro; La pianificazione di milestone e date di presa in carico e consegna del lavoro; Attività e compiti da svolgere; Approvvigionamenti, risorse, budget e tempistiche richieste per ogni stadio; I problemi e i rischi da affrontare e gestire; Tempistiche e imprevisti. Allocare le risorse necessarie permette ai pianificatori del Service Transition di stabilire se la transizione può avvenire nei tempi richiesti. Nel caso alcune risorse non siano disponibili, può essere necessario riconsiderare le priorità: queste eventualità devono essere discusse con il Change Management e il Release Management, poiché altri processi potrebbero risentire di questi cambiamenti. Pianificazione Una buona pianificazione è essenziale per mandare un nuovo servizio in produzione con successo su tutto l ambiente lavorativo e tutte le locazioni. Devono quindi essere creati e mantenuti dei piani di transizione che siano integrati con i piani per lo sviluppo della nuova versione del servizio e la sua conseguente distribuzione. Un piano di transizione ben strutturato dovrebbe infatti includere le attività chiave per acquisire le componenti necessarie allo sviluppo, preparare la release, generare, testare, distribuire e mantenere nel tempo il servizio. Adottare le procedure consigliate dal Project Management È consigliato gestire diverse versioni e sviluppi come un programma, con ogni sua branchia significativa gestita come un singolo progetto. 30

31 Gli step da tenere in considerazione durante la progettazione includono il range di elementi che compongono il servizio (risorse umane, hardware, software, documentazione,..): questo porta lo sviluppo a contemplare diversi sotto-progetti per ogni tipo di elemento che compone il nuovo servizio. Controllare la pianificazione Il settore che si occupa della pianificazione dovrebbe verificare tutti i piani di Service Transition, release e sviluppo. Dove possibile, le tempistiche di esecuzione dovrebbero includere elementi imprevisti e dovrebbero essere basate sull esperienza diretta piuttosto che su mere asserzioni. Questo si applica a maggior ragione verso i fornitori interni, non esistendo alcuna forma contrattuale. I tempi di esecuzione tipicamente variano di stagione in stagione e devono essere calcolati nella pianificazione, specialmente per transizioni proiettate sul lungo termine, dove i tempi di completamento possono variare notevolmente tra uno stadio e l altro del processo. Anticipare eventuali cambiamenti nelle circostanze commerciali In caso di cambiamenti commerciali, nel caso il piano di transizione esistente richieda ripensamenti ed eventuali modifiche, queste dovrebbero essere eseguite dal processo di Change Management, dal momento che eventuali soluzioni alternative devono essere vagliate e documentate propriamente. Tuttavia, nei casi in cui il piano di azione sia documentato come una reazione accettabile a nuove circostanze, l autorità per eseguire le modifiche potrebbe essere trasferita al Service Transition. 3.1.f Fornire supporto al processo di transizione Consigli I progetti dovrebbero sempre implementare i compiti del Service Transition in accordo con gli standard, le norme e le procedure applicabili. Tuttavia, i Project Manager non sempre sono a conoscenza del bisogno di adottare questi standard e quando nasce un nuovo progetto il ruolo del Service Transition è di inserire in maniera veloce ed efficiente all interno del progetto i processi propri del Service Transition, prima che vengano adottati metodi alternativi e non consoni. Amministrazione Il ruolo di Service Transition Planning and Support deve permettere l amministrazione di: 31

32 Gestire eventuali modifiche al Service Transition e all ordine dei lavori; Gestire problemi, rischi, modifiche e ritardi; Gestire il supporto ai processi del Service Transition; Gestire le comunicazioni verso gli stakeholder; Gestire il monitoraggio delle prestazioni del Service Transition. La pianificazione del processo e il suo progresso devono essere comunicati e resi disponibili per gli stakeholder di rilevo. La lista degli stakeholder è definita nel Service Package ricevuto in fase di design dell operazione. Monitoraggio dello stato di avanzamento e conseguente report Monitorare e controllare lo sviluppo permette di stabilire al termine dello stesso se la transizione è proceduta secondo i termini stabiliti e permette di identificare eventuali variazioni rispetto ai progetti originari. È inoltre essenziale mantenere una visione complessiva della transizione, confrontandola con i progetti del Service Transition, monitorando il progresso di ogni transizione periodicamente e nei punti chiave del processo. In molti casi i piani di transizione richiedono modifiche che li rendano allineati con una realtà che è cambiata rispetto al momento della progettazione del piano. Questo non è indice di una cattiva progettazione o di errori nella scelta del modello di transizione, quanto piuttosto il riflesso di un ambiente dinamico e in costante evoluzione. 3.1.g Punti di partenza, input e output, interfacciamento inter-processo Punto di partenza: Il punto di partenza è un RFC autorizzato per un Service Transition. Input RFC autorizzato; Pacchetto di Service Design; Definizione del Release Package e specifiche per la progettazione; Service Acceptance Criteria (SAC). 32

33 Output Strategia di transizione; Set di piani per il Service Transition. 3.1.g Key Performance Indicator (KPI) I KPI principali per il Transition Planning and Support includono: Il numero di versioni implementati che soddisfano le richieste dei clienti in termini di costi, qualità e obiettivi; Quanto più sottile è la differenza tra obiettivi, qualità, costi e tempi previsti e raggiunti; Riduzione del numero di problemi, rischi, e ritardi causati da una pianificazione inadeguata. 3.2 Change Management Un cambiamento può essere necessario per una serie di fattori: Proattivo, per ridurre i costi operativi, migliorare i servizi o aumentare l efficienza del supporto; Reattivo, per correggere errori o reagire a mutate circostanze operative. I cambiamenti dovrebbero essere gestiti in un ottica di: Diminuzione dell esposizione ai rischi; Minimizzazione dell impatto di imprevisti; Successo al primo tentativo. 33

34 3.2.a Finalità, traguardi, obiettivi Finalità Assicurare che siano usati metodi e procedure standard, per poter gestire tutti i cambiamenti in maniera efficiente e pronta; Tutti i cambiamenti ai servizi e alle configurazioni degli stessi devono essere registrati nel Configuration Management System; Il rischio per l amministrazione deve essere minimo. Traguardi Rispondere alle richieste dei clienti in continuo mutamento e massimizzare il risultato finale minimizzando incidenti e disservizi. Rispondere alle richieste di cambiamenti da parte dell amministrazione e del reparto IT, volte a un allineamento dei servizi con le richieste amministrative. Obiettivi Assicurarsi che i cambiamenti siano registrati e successivamente valutati, autorizzati, prioritizzati, pianificati, testati, implementati, documentati e valutati in maniera controllata. 3.2.b Prospettive Service Change L obiettivo ultimo del Change Management copre i cambiamenti ai servizi e alle configurazioni degli stessi attraverso tutto il ciclo vitale del servizio. Ogni organizzazione dovrebbe definire i cambiamenti che cadono all infuori degli obiettivi del processo di Service Change, come: Cambiamenti con impatto significativamente maggiore rispetto al Service Change, come cambiamenti organizzativi o delle politiche amministrative interne; Cambiamenti a livello operativo, come manutenzioni o riparazioni. 34

35 3.2.c Valore per il business Affidabilità e continuità di business sono parole chiave per il successo e la sopravvivenza di qualsiasi organizzazione. Cambiamenti nei servizi o nell infrastruttura possono avere un impatto negativo negli affari, ma il Change Management si occupa di dare valore al business: Stabilendo le priorità e rispondendo alle proposte di cambiamenti da parte di amministrazione e clienti; Implementando i cambiamenti che soddisfano le richieste dei clienti, mantenendo e ottimizzando i costi; Riducendo la malriuscita dei cambiamenti, e quindi malfunzionamenti nei servizi; Completando i cambiamenti in tempi brevi, in modo da rispettare le scadenze previste; Tenendo traccia dei cambiamenti avvenuti durante il ciclo di vita del servizio; Contribuendo per il calcolo di una stima precisa di tempi, costi e qualità prevista di un cambiamento; Stimando i rischi associati con la messa in funzione di nuovi servizi o la dismissione di vecchi; Minimizzando i disservizi causati da cambiamenti d emergenza o non pianificati; Riducendo il Mean Time to Restore Service (MTRS); Collaborando con il processo di Business Change per identificare opportunità di miglioramenti comuni. 3.2.d Criteri, principi e concetti di base Criteri I criteri che appoggiano il Service Transition includono: Creare una cultura di Change Management attraverso tutta l organizzazione che non veda tolleranza verso cambiamenti non autorizzati; Dare le corrette priorità ai cambiamenti; Stabilire le corrette responsabilità per i cambiamenti attraverso il ciclo di vita del servizio; Stabilire un singolo punto focale per i cambiamenti, in modo da minimizzare le probabilità di conflitti; Evitare che personale non autorizzato abbia accesso all ambiente di produzione; 35

36 Integrazione con altri processi di Service Managent, al fine di stabilire tracciabilità dei cambiamenti, rilevare cambiamenti non autorizzati e identificare incidenti causati dai cambiamenti; Valutazione di performance e rischi di tutte i cambiamenti che impattano gli ambiti di interesse del servizio; Misurazione di efficacia ed efficienza. Considerazioni su progettazione e pianificazione Il processo di Change Management deve essere pianificato in congiunzione con il Release and Configuration Management, per permettere al Service Provider di valutare al meglio l impatto del cambiamento sui servizi attuali e su quelli pianificati. I requisiti per i processi di Change Management includono: Eliminazione dei cambiamenti non autorizzati; Identificazione e classificazione: o Identificatori dei documenti per la transizione, o Tipologia, modelli e contenuto previsto dei documenti, o Impatto, urgenza, priorità; Organizzazione, ruoli, responsabilità: o Responsabilità di tutti gli stakeholder, o Approccio a un testing indipendente e valutazione della transizione, o Livelli di autorizzazioni e regole che governano le scelte prese; Stakeholder: o Pianificazione dei cambiamenti e dei rilasci di nuove versioni, in modo da permettere agli stakeholder una corretta pianificazione delle loro attività, o Comunicazione dei cambiamenti, della tabella di marcia e della pianificazione delle release; Procedure: o Norme di autorizzazione alla transizione, regole e procedure, o Come le richieste vengono registrate e gestite, o Come viene analizzato e valutato l impatto delle richieste, o Identificare le dipendenze e incompatibilità tra transizioni, o Valutare le possibili conseguenze date dall implementazione della transizione; Interfacce verso altri processi del Service Management; 36

37 Tipologia di Change Request Un Change Request è una richiesta formale di alterazione di uno o più parametri di configurazione. Tipologie diverse di cambiamenti posso portare a diverse tipologie di richieste: un organizzazione deve assicurarsi che tutte le procedure necessarie ad effettuare l operazione siano possibili. Modelli per il processo di transizione Un modello per un processo permette di predefinire i passaggi da intraprendere per gestire correttamente il processo. Il modello per il processo di transizione include: I passaggi che devono essere intrapresi per gestire correttamente il processo, compresi eventi inattesi e problemi di gestione; L ordine cronologico dei passaggi sopracitati, incluse dipendenze o coprocessi; Responsabilità; Tempi e limiti per il completamento del processo; Transizioni standard (pre-autorizzate) Una transizione standard è un cambiamento a un servizio o infrastruttura per il quale vi è un approccio pre-autorizzato dal Change Management, per il quale ha studiato e approvato una procedura apposita. Gli elementi chiave di una transizione standard sono: Un input ben definito che da inizio al RFC; Ruoli ben definiti, documentati e testati; Autorità garantite in anticipo; Rischio normalmente basso e ben compreso. Una volta approvato l approccio alla gestione delle transizioni standard, i processi di transizione devono essere sviluppati e comunicati. Normalmente viene associato al processo un modello di transizione, per assicurare una determinata consistenza di approccio. Le transizioni standard vanno identificare il prima possibile durante la progettazione del processo di Change Management, per assicurare una buona efficienza generale. 37

38 3.2.e Pianificazione dei rimedi ad errori Nessun cambiamento andrebbe approvato senza prima considerare l eventualità di un fallimento e pianificare soluzioni agli eventuali problemi che possano ripristinare lo status dell organizzazione alla situazione iniziale. Tuttavia, non tutti i cambiamenti sono reversibili, e in questi casi è necessario studiare una soluzione che riporti lo status-quo ad una situazione accettabile. Questo potrebbe coinvolgere una diversa progettazione del processo di transizione affinché permetta un recupero da eventuali problemi o fallimenti. 3.2.f Attività, metodi e tecniche per il processo Le attività di Change Management includono: Pianificazione e controllo dei cambiamenti; Programmazione dei cambiamenti e del rilascio delle nuove versioni dei servizi; Comunicazioni; Decision Making e autorizzazioni per le transizioni; Assicurare che vi siano piani di rimedio; Gestione dei report; Comprensione dell impatto delle transizioni; Miglioramenti continui. La figura illustra un esempio di transizione dei servizi, applicazioni e strutture di un Service Provider. Gli esempi degli stati del RFC sono indicati in corsivo. Le figure e illustrano la catena di processi equivalenti per alcuni esempi di transizioni standard. 38

39 Figura (sopra) Figura (sotto) 39

40 Creare e documentare una richiesta di transizione La transizione viene richiesta dall individuo o dal gruppo organizzativo che richiede determinati cambiamenti. In caso di una transizione di grossa entità, implicante significativi cambiamenti a livello organizzativo e/o finanziario, può essere necessaria una proposta di transizione, che contiene una descrizione dei cambiamenti da intraprendere, congiuntamente a giustificazioni amministrative e finanziarie. La documentazione contiene la completa cronologia della transizione, incorporando informazioni dal RFC e informazioni su autorizzazioni, implementazioni e controlli. A mano a mano che un RFC procede nel suo ciclo di vita, tutta la documentazione viene aggiornata nel CMS, in modo da dare visibilità allo stato di avanzamento del processo. Stime di risorse, costi e successo vengono anch essi documentati per permettere una corretta gestione del reporting dei dati. Change Logging Devono essere stabilite delle procedure per documentare e tenere traccia degli RFC, che possono essere sottoposti in forma cartacea, via o usando un apposita interfaccia web. Tutti gli RFC ricevuti dovrebbero essere registrati con un numero identificativo che rispetti l ordine cronologico. Nel caso una richiesta di transizione sia stata effettuata in seguito a un qualche problema, ne deve essere tenuta traccia, in modo da fornire tracciabilità. Apposite procedure stabiliranno poi i livelli di accesso e chi ha permessi nel sistema di logging. Sebbene infatti qualsiasi persona autorizzata possa creare un RFC, solo lo staff del Change Management può effettivamente chiudere un RFC. Verifica delle richieste di transizione Compito del Change Management è di considerare ogni richiesta di transizione e filtrare le richieste: Totalmente impraticabili; Ripetizioni di RFC precedenti, accettate, rifiutate o ancora in attesa di esito; Incomplete in qualche forma. Queste richieste vanno respinte, assieme a una breve descrizione della motivazione del rifiuto. 40

41 Valutare i cambiamenti Le sette domande del Change Management Le seguenti domande devono essere poste per ogni transizione. Senza queste informazioni, non può essere valutato l impatto della transizione e non può essere calcolato il bilancio tra rischi e benefici. Questo naturalmente può portare a un fallimento della transizione. Chi ha RICHIESTO la transizione? Quali sono le MOTIVAZIONE per la transizione? Quali sono i VANTAGGI previsti derivanti dalla transizione? Quali sono i RISCHI previste derivanti dalla transizione? Quali RISORSE sono necessarie per effettuare la transizione? Chi è RESPONSABILE per lo sviluppo, il testing e l implementazione della transizione? Quali sono le eventuali RELAZIONI tra questa transizione e altre transizioni? Vanno definite le responsabilità per la valutazione dei cambiamenti di maggiore impatto. Non esiste una soluzione universale per ogni azienda, in quanto possono essere molto diverse una dall altra in termini di dimensioni, struttura, complessità e organizzazione generale, tuttavia è consigliato discutere ogni progetto di transizione di una certa entità con tutti gli stakeholder, in modo da completare un quadro delle responsabilità generale ben definito. Nessun cambiamento è senza rischi Anche i cambiamenti più semplici portano con sé dei rischi spesso non proporzionali alla loro grandezza. È pratica consigliata usare una valutazione dei rischi durante il calcolo dell impatto di una transizione che identifichi fattori che possono danneggiare il business dell azienda o impedire la corretta funzionalità di uno o più suoi servizi. Categorizzazione del rischio Molte organizzazioni usano una matrice molto semplice, come quella della tabella 3.2.4, per la categorizzazione del rischio, e da questo livello ne deriva la valutazione della transizione e le autorizzazioni richieste. 41

42 Impatto della transizione Matrice impatto/rischio della transizione ALTO impatto BASSA probabilità Categoria di rischio: 2 BASSO impatto BASSA probabilità Categoria di rischio: 4 ALTO impatto ALTA probabilità Categoria di rischio: 1 BASSO impatto ALTA probabilità Categoria di rischio: 3 Probabilità Tabella Assegnazione delle priorità L assegnazione delle priorità stabilisce l ordine nel quale i cambiamenti andrebbero considerati; la priorità di un cambiamento deriva dall impatto stabilito e della sua urgenza. L impatto di un cambiamento è calcolato sul beneficio che ne trarrà il business da una implementazione riuscita della transizione. L urgenza di un cambiamento è basata su quanto l implementazione può essere ritardata. Pianificazione e programmazione della transizione Un attenta pianificazione dei cambiamenti assicura che non vi siano ambiguità tra quali compiti sono contemplati dal processo di Change Management, quali sono invece contemplati da altri processi e come i processi si interfacciano con fornitori i altri progetti che prevedono cambiamenti. Molti cambiamenti possono essere raggruppati in una sola nuova versione del servizio e quindi progettati, testati e rilasciati assieme. Se una nuova versione del servizio non comprende al suo interno un numero adeguato di cambiamenti, viene a mancare il bilanciamento tra consumo di risorse per portare a termine la transizione e benefici derivanti da essa. Il Change Management coordina la redazione e distribuzione di un Change Schedule (CS) e un Projected Service Outage (PSO): il SC contiene i dettagli di tutti i cambiamenti autorizzati, mentre il PSO contiene dettagli su come i cambiamenti influiscono sulla disponibilità dei servizi coinvolti dalla transizione e sul loro downtime pianificato. Questi documenti sono approvati 42

43 dall amministrazione con i clienti più importanti, con il Service Level Management e con le strutture portanti dell azienda, per poi essere comunicati al bacino di utenti. Valutazione dei rimedi È di vitale importanza stabilire dei percorsi per rimediare ad eventuali problemi durante la fase di transizione, in modo da individuare una strada da poter percorrere per tornare al punto di partenza in ogni momento del processo di transizione. Autorizzare la transizione Un autorizzazione formale per ogni transizione viene fornita da un autorità apposita. Il livello di autorizzazione necessario per un particolare tipo di cambiamento dovrebbe essere giudicato in base al tipo, dimensione e rischio della transizione. Coordinare l implementazione della transizione Il Change Management ha la responsabilità di assicurarsi che tutti i cambiamenti siano applicati come programmato. Le procedure di rimedio devono essere preparate e documentate in anticipo per ogni cambiamento autorizzato, in modo che eventuali problemi possano essere recuperati con un impatto minimo o nullo sulla qualità del servizio erogato. Il Change Management ha un ruolo di supervisore nell assicurarsi che i cambiamenti vengano testati esaustivamente; le procedure di testing possono continuare anche durante i primi periodi di adozione del nuovo servizio, prestando particolare attenzione a situazioni non previste o apparenti errori e malfunzionamenti. La transizione andrebbe applicata nel momento di possibile minor impatto sulla qualità di servizio. Verifica e chiusura della documentazione di transizione Completata la transizione, i risultati dovrebbero essere riportati per una verifica ai responsabili della gestione delle transizione, e infine presentati come transazione giunta a buon fine agli stakeholder. La verifica deve anche includere qualsiasi imprevisto ed incidente verificatosi durante il processo, come risultato della transizione. 43

44 Infine, deve essere prodotta una revisione della transizione che testimoni il raggiungimento degli obiettivi proposti, che gli stakeholder e chi ha richiesto i cambiamenti siano soddisfatti dei risultati e che non vi siano stati effetti secondari non desiderati. Compito del Change Management è anche revisionare i nuovi servizi dopo un certo periodo di tempo, con lo scopo di stabilire che: La transizione abbia avuto gli effetti desiderati e raggiunto gli obiettivi proposti; I clienti e gli stakeholder siano soddisfatti dei risultati; Non vi siano effetti secondari non desiderati; Le risorse pianificate per la transizione siano state rispettate; La transizione sia stata implementata nei tempi e costi previsti; Il piano di rimedio abbia funzionato correttamente, nel caso ve ne fosse stato bisogno. Nel caso una transizione non abbia raggiunto gli obiettivi preposti, il Change Management (o il CAB) deve decidere quale azioni intraprendere, cosa che potrebbe portare a un nuovo RFC. Nel caso la verifica dei risultati della transizione vada a buon fine, o nel caso che la transizione sia cancellata e si ritorni alla situazione iniziale, il RFC deve essere formalmente chiuso nel sistema di logging. Change Advisory Board Il Change Advisory Board (CAB) è un corpo nato per supportare l autorizzazione delle transizioni e per assistere il Change Management nella valutazione e prioritizzazione delle medesime. I membri del CAB devono essere scelti tra persone capaci di assicurare che tutti i cambiamenti alla portata del CAB siano adeguatamente valutati da un punto di vista sia amministrativo che tecnico. Nel caso sopraggiunga la necessità di una transizione di emergenza, potrebbe non esserci il tempo di convocare il CAB nel suo intero, ed è quindi necessario identificare una organizzazione più ristretta con l autorità per effettuare decisione di emergenza: questo corpo si chiama Emergency Change Advisory Board (ECAB). La composizione del CAB deve risultare piuttosto flessibile, in modo da rappresentare gli interessi economici in maniera adeguata quando sono proposte transizioni di primaria importanza. Questo assicura anche che la composizione dell ECAB abbia l abilità, sia da un punto di vista amministrativo che tecnico, di prendere decisioni appropriate in qualsiasi possibile eventualità. 44

45 Riunioni del CAB Molte organizzazioni gestiscono le riunioni del CAB via videoconferenza, senza frequenti riunioni faccia a faccia. Vi sono pregi e difetti di questa soluzione: la maggior parte delle decisioni e delle valutazioni possono essere prese senza problemi, ma generalmente decisioni per casi di alto rischio o alto impatto richiedono riunioni formali. Gestire le riunioni in maniera elettronica rende sicuramente più facile la pianificazione delle stesse, mentre una riunione faccia a faccia può comportare problemi organizzativi non indifferenti. L esperienza dimostra che la migliore soluzione è combinare entrambe le soluzioni, organizzando riunioni faccia a faccia in maniera regolare secondo un agenda predefinita, in modo da facilitare organizzazione e pianificazione delle stesse. In queste riunioni è consigliabile applicare un agenda standard, che comprenda: Le riunioni rappresentano un potenziale overhead nel tempo a disposizione dei membri, quindi tutti i documenti di RFC, assieme al SC e PSO, dovrebbero essere disponibili in anticipo e la flessibilità permessa ai membri del CAB dovrebbe permettere in caso di non disponibilità di inviare un sostituto. Il CAB deve essere informato e aggiornato su qualsiasi cambiamento di emergenza eventualmente resosi necessario. È da notare che il CAB è un corpo puramente consultivo. Se il CAB non può giungere ad un accordo su un punto, la decisione finale spetta a chiunque debba autorizzare la transizione. Transizioni di emergenza Le transizioni di emergenza sono talvolta necessarie e devono essere progettate e testate in maniera impeccabile, viceversa l impatto dei cambiamenti nell ambiente di produzione potrebbe essere maggiore rispetto al problema originario. Il numero di transizioni di emergenza va mantenuto il più basso possibile, poiché sono più inclini a fallimento rispetto alle transizioni pianificate. Le transizioni di emergenza sono riservate per cambiamenti intesi a riparare un errore nel servizio IT che impatti negativamente il business dell azienda ad alti livelli. 45

46 Progettare, testare e implementare una transizione di emergenza Quando le tempistiche lo richiedono, il Change Management assicura che sufficienti risorse e personale siano disponibile per questa procedura. È necessario portare avanti più test possibili sulla transizione d emergenza: cambiamenti totalmente non testati non dovrebbero essere implementati: è consigliato fare una proiezione dei costi stimati in caso di fallimento della procedura, e bilanciare quindi su questo il numero di test da effettuare prima di mandarla in produzione. In caso il numero di test da effettuare risulti particolarmente ridotto, essi dovrebbero vertere principalmente su: Aspetti del servizio che verranno utilizzati nell immediato; Elementi che causerebbero inconvenienti a breve termine. L amministrazione deve essere messa a conoscenza dei rischi e deve accettare o rifiutare tale transizione in base alle informazioni presentate. Il Change Management si deve occupare di dare un preavviso adeguato al servizio di supporto e altri stakeholder e di organizzare un adeguata presenza tecnica per supportare i Service Operation. Nel caso la transizione non vada a buon fine, il Change Management deve prendersi la responsabilità di porre le necessità amministrative in primo piano. In alcune circostanze potrebbe essere una soluzione migliore fornire un servizio di backup che fornisca i servizi base durante la fase di testing, o eventualmente sospendere il servizio temporaneamente per permettere le operazioni di aggiornamento. Documentazione della transizione di emergenza Sebbene potrebbe non essere possibile compilare tutta la documentazione del Change Management durante interventi di emergenza, è tuttavia essenziale tenere delle note temporanee da completare poi alla prima opportunità. 46

47 3.2.g Punti di partenza, input e output, interfacciamento inter-processo Cambi di strategie Le strategie dei servizi richiedono cambiamenti implementati per raggiungere specifici obiettivi, tenendo costi e rischi al minimo. Vi sono sempre rischi e costi da sostenere per cambi di strategie, come introdurre nuovi servizi, entrare in nuovi spazi di mercato o raggiungere nuove tipologie di clienti. Cambiamenti di uno o più servizi Cambiamenti ai servizi pianificati nel Service Portfolio e nel Service Catalogue sono un punto di partenza per il processo di Change Management. Cambiamenti operativi Gli utilizzatori dei servizi offerti dall organizzazione possono richiedere diversi cambiamenti operativi, come richieste di cambio password, o di accedere a aree ristrette; il personale del Service Operation, inoltre, si occupa di implementare cambiamenti correttivi e preventivi, attraverso la procedura standard di transizione, che sono poi gestiti attraverso il Change Management. Input Politiche e strategia per transizioni e release; Request for Change; Proposte di transizione; Programmazione attuale delle transizioni e PSO; Risultati dei test e dei report valutativi. Output RFC rifiutati; RFC approvati; Cambiamenti ai servizi; PSO riveduto e corretto; Piani di transizione autorizzati; Documentazione di transizione; Report del Change Management. 47

48 Interfacciamento inter-processo Integrazione con i processi di Business Change Quando appropriato, il Change Management deve sincronizzarsi con i team che si occupano dei processi di gestione amministrativa per assicurare che, dove possibile, questioni, obiettivi e sviluppi relativi alla transizione siano estesi a tutta l organizzazione. Questo porta i cambiamenti alle aree amministrative che non impattano i servizi o parti di essi a poter essere gestiti dal Business o Project Change Management piuttosto che dall IT Change Management. Programme Management e Project Management Il Programme Management e il Project Management devono lavorare in partnership, in modo da allineare tutti i processi e il personale coinvolti nei processi di transizione. Sourcing e Partnering Il Change Management deve assicurarsi che sourcing e partnering con fornitori di servizi interni ed esterni all azienda siano gestiti in maniera ottimale, in modo da assicurare una buona fruizione dei servizi da loro offerti. È altresì importante assicurarsi che i servizi offerti dai fornitori, sia interni che esterni, incontrino le necessità dei clienti e dell amministrazione. Interfacciamento all interno del Service Management Asset Management e Configuration Management Il Configuration Management System fornisce un veloce e facile accesso a informazioni di configurazione accurate, permettendo agli stakeholder e allo staff di valutare l impatto dei cambiamenti proposti e monitorare l andamento della transizione. Problem Management Il Problem Management è un altro processo chiave, visto che i cambiamenti spesso necessitano di metodi di risoluzione di problemi noti ed è uno delle maggiori fonti di RFC e uno dei principali argomenti di discussione nelle riunioni del CAB. 48

49 IT Service Continuity L IT Service Continuity ha molte procedure e gli aggiornamenti della pianificazione devono essere gestiti tramite il Change Management, in modo che le informazioni siano aggiornate e accurate e che gli stakeholder siano a conoscenza dei cambiamenti. Security Management La Security Management si interfaccia con il Change Management, in quanto i cambiamenti dettati dalla sicurezza vengono gestiti dal Change Management e la sicurezza stessa è argomento chiave di discussione nelle riunioni del CAB. Capacity Management e Demand Management Il Capacity Management e il Demand Management sono aspetti critici del Change Management. Un Demand Management non ottimale è causa di aumento dei costi e dei rischi per i Service Provider, poiché c è sempre un certo livello di incertezza associato con la richiesta di servizi. Il Capacity Management ha un ruolo importante nella valutazione dei cambiamenti proposti, non solo a livello di singolo cambiamento, ma anche di impatto totale della transizione sulla qualità del servizio. 3.2.h Key Performance Indicator (KPI) Il Change Management deve assicurarsi che ogni misurazione abbia un suo preciso significato. Anche se infatti è relativamente facile contare il numero di incidenti o imprevisti che eventualmente sono accaduti durante la transizione, è molto più utile osservare la causa scatenante e individuarne l andamento. È decisamente più conveniente misurare l impatto dei cambiamenti avvenuti e poter vantare ridotti effetti secondari grazie all apporto dato dal Change Management e misurare la velocità e l efficacia con il quale il Service Provider ha soddisfatto le necessità amministrative. I KPI principali per il Change Management includono: Il numero di cambiamenti effettuati ai servizi che incontrano i requisiti decisi dai clienti; I benefici della transizione, espressi come valore dei miglioramenti effettuati + impatti negativi preventivati, comparati con i costi del processo di transizione. 49

50 Riduzione del numero di disservizi, problemi e correzioni causate da specifiche inaccurate o inadeguate, o da una valutazione dell impatto sui servizi incompleta. Riduzione del numero di cambiamenti non autorizzati; Riduzione del numero di cambiamenti di emergenza o non pianificati; Percentuale di successo del processo di transizione; Riduzione del numero di cambiamenti non andati a buon fine; Tempo medio di implementazione, basato sul tipo/urgenza/priorità della transizione. 3.3 Service Asset and Configuration Management Questo capitolo analizza il processo di Service Asset and Configuration Management (SACM) all interno dell IT Service Management. Nessuna organizzazione può definirsi pienamente efficiente o funzionante fintantochè non gestisca adeguatamente le proprie risorse, specialmente quelle chiave per il proprio business. 3.3.a Finalità, traguardi, obiettivi Finalità Identificare, controllare, monitorare, verificare le risorse del servizio e gli elementi di configurazione; Gestire e proteggere l integrità delle risorse del servizio e degli elementi di configurazione attraverso il ciclo di vita del servizio. Traguardi Pianificare e coordinare le risorse in modo da assicurare che le richieste del Service Strategy codificate nel Service Design siano effettivamente realizzate nel Service Operation; Individuare, gestire e controllare i rischi di fallimento attraverso le attività di transizione. 50

51 Obiettivi Pianificare e coordinare le risorse in modo da introdurre un servizio in produzione entro i costi, tempi e criteri di qualità previsti; Fornire piani chiari e compresivi che permettano al cliente di allineare le proprie attività con i piani del Service Transition; Identificare, controllare, registrare, monitorare e verificare gli elementi del servizio e i parametri di configurazione, incluse versioni, linee di base, componenti, attributi e relazioni; Assicurare e proteggere l integrità degli elementi del servizio e dei parametri di configurazione attraverso il ciclo di vita del servizio, assicurandosi che siano usate solo componenti autorizzate e che siano effettuati solo cambiamenti autorizzati. 3.3.b Prospettive Assicurare l efficienza e l efficacia dei processi di Service Management fornendo accurate informazioni di configurazione e permettendo ai responsabili di prendere le giuste decisioni nel giusto momento; Minimizzare il numero di problemi di qualità e di conformità causati da una impropria configurazione dei servizi; Ottimizzare gli elementi del servizio, le configurazioni IT e le risorse. L obiettivo finale è definire e controllare le componenti dei servizi e dell infrastruttura e mantenere accurate informazioni di configurazione sullo stato storico, pianificato e attuale dei servizi e dell infrastruttura. 3.3.c Scopo L Asset Management copre gli elementi del servizio attraverso l intero ciclo di vita dello stesso e fornisce un insieme di elementi completo a chi è responsabile per il loro controllo. Il Configuration Management assicura che siano identificate e gestite componenti selezionate di un servizio completo, sistema o prodotto, e che i cambiamenti effettuati su di essi siano monitorati; assicura inoltre che le release all interno di un ambiente controllato e l uso operativo siano fatti sulla base di approvazioni formali. Fornisce un modello di configurazione dei servizi, elementi ed infrastruttura monitorando le relazioni tra gli elementi del servizio e gli elementi di configurazioni. 51

52 3.3.d Valore per il business Ottimizzare le prestazioni degli elementi del servizio e delle configurazioni migliora le prestazioni complessive del servizio e riduce costi e rischi derivanti da una cattiva gestione degli asset del servizio. Il SACM (Service Asset and Configuration Management) permette un accurata rappresentazione di un servizio, il che garantisce: Una migliore pianificazione dei cambiamenti; Cambiamenti e release pianificati e gestiti con successo; Imprevisti e problemi risolti entro gli obiettivi del servizio; Miglior aderenza agli standard, quindi minori inconformità; Più opportunità per il settore business; Possibilità di identificare con precisione i costi di un servizio. 3.3.e Criteri, principi e concetti di base In un ambiente distribuito con servizi condivisi, le singole componenti di un servizio coesistono con diversi servizi e configurazioni: un cambiamento sulla rete o sul sistema finanziario potrebbe avere un impatto sui singoli utenti del servizio. In servizi web-based, potrebbero esistere scambi di dati da e verso servizi gestiti da altre organizzazioni: cambiamenti in queste interfacce devono essere gestiti attraverso il Change Management. Service Asset e politiche del Configuration Management Il primo passo è sviluppare e mantenere le policy SACM che fissano gli obiettivi, i principi e i fattori critici di successo per quanto deve essere raggiunto dal processo. Vi sono significative implicazioni di costi e risorse nell implementazione del SACM e di conseguenza bisogna intraprendere decisioni strategiche in merito alle priorità da affrontare. Principi del Service Asset e del Configuration Management Assicurarsi che i costi e le risorse delle operazioni di Asset e Configuration Management siano commensurati con i potenziali rischi verso i servizi; Necessità di avere servizi disponibili, affidabili e cost-effective; 52

53 Necessità di avere criteri di economicità e prestazioni per interventi che riducano i costi o ottimizzino i servizi; Necessità di mantenere adeguate informazioni sugli asset e sulle configurazioni per gli stakeholder interni ed esterni; Integrazione di Asset e Configuration Management con gli altri processi; Un certo livello di automazione per ridurre errori e costi. Concetti base Il modello di configurazione Il Configuration Management rende disponibile un modello dei servizi, degli asset e dell infrastruttura registrando le relazioni tra gli elementi di configurazione. Figura 3.3.1: Esempio di un modello di configurazione Il principale vantaggio del modello logico dei servizi e dell infrastruttura del Configuration Management è di essere un unico modello, una singola rappresentazione usata da tutte le parti dell IT Service Management. Configuration Item Un Configuration Item (CI) è un asset, una componente di un servizio o un altro elemento che è o sarà sotto il controllo del Configuration Management. Un CI può variare molto in complessità, dimensioni e tipologia, spaziando da un intero servizio sino a un singolo modulo software o componente hardware minore. I CI possono essere raggruppati e gestiti assieme. Si possono individuare diversi CI: 53

54 Service Lifecycle CI, come Business Case, piani di Service Management, piani di service lifecycle, Service Design Package. Forniscono un immagine dei servizi del Service Provider, come questi servizi vengono forniti, quali benefici attendersi e a quale costo e quando verranno realizzati; Service CI, come: o Service Capability Assets, o Service Resource Assets, o Service Model, o Service Package, o Release Package, o Service Acceptance Criteria; Organization CI: una parte della documentazione definisce le caratteristiche di un CI, mentre un altra parte sarà un CI stesso e necessiterà di essere monitorato; CI Interni; CI Esterni, come richieste e accordi di clienti esterni, release da parte di fornitori e servizi esterni; Interface CI, richieste per garantire un servizio end-to-end attraverso un Service Provider Interface (SPI). Configuration Management System Il Service Asset e Configuration Management richiede l uso di un sistema di supporto conosciuto come Configuration Management System (CMS) per poter gestire servizi e infrastrutture IT di una certa grandezza e complessità. Il CMS viene usato per un grosso ventaglio di scopi, tra cui quello principale di mantenere tutte le informazioni necessarie ai CI e mantiene le relazioni tra tutti le componenti dei servizi e la documentazione su qualsiasi imprevisto, problema, errore noto, cambiamento e release, oltre a poter contenere dati su impiegati, fornitori, clienti e utenti. 54

55 Figura 3.3.2: Esempio di Configuration Management System Secure Library e Secure Store Una Secure Library è una raccolta di CI di tipo e stato noti, usata per controllare e rilasciare componenti durante il ciclo di vita di un servizio. L accesso ai contenuti di una Secure Library è ristretto. Un Secure Store è un posto che mantiene gli asset IT e che ha un ruolo chiave nella gestione della sicurezza, in quanto assicura un accesso affidabile a equipaggiamento di qualità nota. Definitive Media Library La Definitive Media Library (DML) mantiene e protegge le versioni definitive e autorizzate di tutti i CI che hanno passato i controlli di qualità. Può consistere in uno o più software library o aree di stoccaggio dati, separate dalle aree di sviluppo e testing. Contiene le copie master di tutto il software controllato in una organizzazione. 55

56 La DML dovrebbe includere le copie di tutto il software acquistato, oltre al software sviluppato internamente. Le copie master della documentazione dei sistemi sono anch esse memorizzate all interno della DML in formato elettronico. Può essere accettato all interno della DML solo materiale autorizzato, controllato strettamente dal SACM. Figura 3.3.3: Relazione tra Definitive Media Library e Configuration Management Database Definitive Spares Deve essere allestita un area apposita per lo stoccaggio sicuro dei ricambi hardware definitivi. Questi sono componenti di ricambio che vengono mantenuti allo stesso livello dei componenti in produzione. Dettagli su questi componenti, sulla loro locazione e contenuto sono specificati all interno del CMS. Possono essere usati in caso di necessità, e quando il loro uso temporaneo è terminato, devono essere ritornati all area di stoccaggio o deve essere ottenuto un rimpiazzo. Configuration Baseline Una Configuration Baseline è la configurazione di un servizio, prodotto o infrastruttura formalmente approvata, che serve da base per future attività e che può essere modificata solo attraverso delle procedure formali. Racchiude informazioni su struttura, contenuti e dettagli di 56

57 una configurazione e rappresenta un insieme di elementi di configurazione che sono in relazione gli uni con gli altri. Snapshot Uno Snapshot è un istantanea dello stato corrente di un elemento di configurazione o di un ambiente. Questa istantanea viene registrata nel CMS e rimane memorizzata come un record storico. 3.3.f Attività dei processi, metodi e tecniche Management e pianificazione Non esiste un modello standard per determinare il miglior approccio al SACM. Il Management Team e il Configuration Management devono decidere quale livello di Configuration Management è richiesto per il servizio o progetto selezionato e come questo livello viene raggiunto. Questo è poi documentato in un piano di Configuration Management. Configuration Identification Durante la pianificazione di una configurazione è importante: Definire come le classi, i tipi di asset e gli elementi di configurazione devono essere selezionati, raggruppati, classificati e definiti in base a determinate caratteristiche; Definire l approccio all identificazione univoca ed etichettatura di tutti gli asset o componenti del servizio e le relazioni tra essi attraverso il ciclo di vita del servizio; Definire i ruoli e le responsabilità degli addetti alla gestione degli elementi di configurazione per ogni stadio del loro ciclo di vita. Struttura e selezione dei Configuration Item Il modello di configurazione deve descrivere le relazioni e posizioni dei CI in ogni struttura. Sono previste strutture di configurazione che identificano tutte le componenti in un particolare servizio. Una parte importante del Configuration Management è decidere il livello al quale il controllo deve essere esercitato. I CI dovrebbero essere selezionati applicando un approccio top-down, considerando se è appropriato suddividere un CI in sotto-ci. Un CI può esistere come parte di un qualsiasi numero di differenti CI o gruppi di CI allo stesso istante. 57

58 Figura (a): Esempio di suddivisione di una configurazione per un servizio di computing end-user 58

59 Figura (b): Esempio di suddivisione di una configurazione per un Managed Virtual System Le figure (a) e (b) danno un esempio in forma schematica di come una struttura a CI per un servizio di computing end-user e un Managed Virtual System possano essere suddivisi. Scegliere l opportuno livello di CI concorre a raggiungere un bilanciamento tra disponibilità delle informazioni, il giusto livello di controllo e le risorse necessarie per supportarlo. Fattori che influenzano il livello di registrazione dei CI I fattori che influenzano la scelta del livello di CI più basso non sono solo finanziari: alcune organizzazioni non memorizzano dati su elementi di consumo perché sono normalmente rimpiazzati secondo una filosofia usa e getta. Altre organizzazioni, tuttavia, potrebbero trovare utile mantenere queste informazioni, come per esempio accade per le tastiere in molti uffici: conoscere il layout della tastiera da rimpiazzare è informazione di sicuro rilievo in realtà multi linguistiche, mentre diventa superfluo in un azienda che utilizza una sola lingua di input. L organizzazione dovrebbe pianificare un controllo dei livelli di CI regolarmente, confermando o meno se le informazioni ai bassi livelli siano ancora di utilità, e che la gestione dei cambiamenti e dei problemi e la gestione degli asset non siano negativamente influenzate dal fatto che il CMDB non vada sufficientemente a basso livello. Ogni asset e CI deve essere univocamente identificato, sia che sia generato all interno che all esterno dell organizzazione. L identificazione dovrebbe anche differenziare tra successive versioni e la descrizione delle configurazioni dovrebbe seguire, ove possibile, standard di servizio, prodotto o tecnologia. Convenzioni sul naming dei Configuration Item Le convenzioni sul naming dovrebbero coprire le necessità di: Relazioni gerarchiche tra CI all interno di una struttura di configurazione; Relazioni gerarchiche all interno di ogni CI; Relazioni tra CI e i documenti loro associati; Relazioni tra CI e cambiamenti; Relazioni tra CI, imprevisti, problemi e errori noti. Il Configuration Management dovrebbe garantire che sia stabilita una convenzione di naming per tutti i documenti. Pianificata la convenzione di naming, è molto importante tenere in considerazione le possibilità di futura crescita. Gli identificatori dovrebbero essere relativamente corti, ma esplicativi, e 59

60 devono seguire le convenzioni stabilite. Per quanto riguarda l hardware, se le convenzioni di naming non sono basate sul fornitore e sul modello del device, deve essere allestito un meccanismo che possa relazionare il Configuration Management e gli identificativi dei fornitori. Convenzioni sull etichettatura dei Configuration Item Ogni CI fisico dovrebbe essere etichettato con l identificatore di configurazione, in modo che possa essere facilmente identificato. Gli elementi devono essere distinti da un identificativo univoco e duraturo, come etichette che seguano determinati standard. Le componenti hardware dovrebbero essere identificate da etichette fisiche non rimovibili, i cavi etichettati ad ogni capo e ad ogni punto di ispezione. È raccomandabile usare un formato e un colore standard per queste etichette, in modo da facilitare l identificazione delle stesse anche ai non addetti ai lavori. Etichette fornite di codice a barre migliorano l efficienza. Attributi dei Configuration Item Gli attributi descrivono le caratteristiche salienti dei CI. Tipicamente gli attributi includono: Unique Identifier; Tipologia di CI; Nome e descrizione; Versione; Dettagli sulla licenza; Proprietario/custode; Stato. Questi attributi specificano caratteristiche funzionali e fisiche per ogni tipo di asset o CI. Definire la documentazione della configurazione Le caratteristiche di un CI sono spesso contenute in documenti. Molte organizzazioni specificano documenti addizionali che descrivono un CI ed usano template per assicurare che siano inserite informazioni coerenti. Memorizzare gli attributi dei CI può facilitare l uso e il riuso di documenti, file e fogli di calcolo già esistenti. 60

61 Relationship Le Relationship descrivono come i CI interagiscono tra di loro per fornire i servizi. Queste relazioni sono mantenute nel CMS. Anche se un CI figlio dovesse appartenere a un CI padre, può essere usato da un qualsiasi numero di altri CI. Questo può ridurre considerevolmente il numero di relazioni che sono necessarie rispetto ad avere CI individuali. Le relazioni sono anche meccanismi per associare RFC, record di incidenti, di problemi o errori con i servizi e i CI dell infrastruttura IT ai quali fanno riferimento. Tute queste informazioni dovrebbero essere incluse nel CMS. Le relazioni possono essere uno-a-uno, uno-a-molti o molti-a-uno. Identificazione degli archivi informatici Gli archivi informatici, fisici ed elettronici, dovrebbero essere identificati univocamente e registrati nel CMS con le seguenti informazioni: Contenuti, locazione e media di ogni archivio; Condizioni per inserire un oggetto; Come proteggere gli archivi da danni accidentali e dolosi e dall azione del tempo, assieme a procedure di recupero dati. Identificazione delle linee di base delle configurazioni Le linee di base delle configurazioni dovrebbero essere stabilite tramite un accordo formale su punti specifici e usate come punti di partenze per il controllo formale di una configurazione. Ogni linea di base concorre a formare una rete di referenze per l intero ciclo di vita del servizio. Le linee base sono aggiunte al CMS mentre sono sviluppate. Cambiamenti alle linee base e il rilascio di prodotti derivanti dal CMS sono sistematicamente controllati e monitorati tramite il Change Management. Identificazione delle Release Unit Le Release Unit descrivono la porzione del servizio o infrastruttura che sono normalmente rilasciate in accordanza con una policy interna di release. Le informazioni sulle Release sono registrate all interno del CMS, supportando il processo di sviluppo della Release. Le Release sono identificate univocamente tramite uno schema definito nelle policy di release. 61

62 Controllo di configurazione Il controllo di configurazione assicura che vi siano adeguati meccanismi di controllo sui CI, mantenendo un registro dei cambiamenti effettuati sugli stessi. Non deve essere aggiunto, modificato, sostituito o rimosso alcun CI senza un appropriata documentazione di controllo o senza seguire una determinata procedura. Le policy e le procedure devono gestire: Licence Control, per assicurare che le licenze siano usate dal numero corretto di persone e che non ci sia uso senza licenza; Change Management; Controllo di versione di Service Asset, versioni software e hardware; Controllo di accesso; Controllo di distribuzione; Installazione; Mantenimento dell integrità del DML. Spesso vi sono molte procedure che possono cambiare un CI. Queste, dove possibile, dovrebbero essere controllate e allineate con i tipi di CI, in quanto la standardizzazione previene gli errori. Durante la fase di pianificazione è importante progettare un modello di controllo della configurazione e implementarlo in un modo che lo staff possa facilmente localizzare ed usare le procedure e i prodotti di training associati. Descrizione e resoconto dello stato di un CI Ogni asset o CI avrà uno o più stadi attraverso i quali può progredire. L importanza di ogni stato dovrebbe essere definita nei termini di quale uso può essere fatto dell asset o CI in quello stadio. La modalità con la quale i CI si muovono tra uno stadio e l altro dovrebbe essere definita. Figura 3.3.5: Esempio del ciclo di vita di un CI 62

63 L organizzazione dovrebbe effettuare attività di controllo e reporting dello stato di configurazione durante il ciclo di vita del servizio, in modo da permette un processo efficiente di Configuration Management. Le procedure standard sono: Mantenere i record di configurazione attraverso il ciclo di vita del servizio e archiviarli secondo le linee guida; Gestire la memorizzazione dello stato di configurazione attuale e di quelli precedenti; Registrare i cambiamenti ai CI; Assicurarsi che i cambiamenti alle linee guida siano propriamente documentati; Record Durante le attività di identificazione e controllo delle configurazioni vengono creati record dello stato di configurazione. Questi record permettono tracciabilità e gestione dell evoluzione della configurazione. Verifica e audit Prima di una Major Release di una specifica configurazione, può essere richiesto di assicurarsi che l ambiente di esecuzione del cliente corrisponda al CMS. Prima di essere accettate nell ambiente di esecuzione, le nuove release, build, equipaggiamenti e standard devono essere verificate rispetto a determinati standard e deve essere rilasciato un certificato di test che provi che le funzionalità di un nuovo o aggiornato CI siano state verificate. Devono essere redatti piani di controllo per assicurare che il CMDB e relative configurazioni siano consistenti con lo stato fisico dei vari CI e viceversa. Queste procedure di controllo devono verificare che esistano solo versioni corrette ed autorizzate di CI: ogni oggetto non autorizzato dovrebbe essere rimosso e registrato tramite Configuration Management. La registrazione o rimozione di oggetti deve avvenire solo tramite i processi di Change Management e tutte le eccezioni e azioni non autorizzate devono essere registrate ed investigate. Controlli di configurazione devono essere fatti: Subito dopo cambiamenti al CMS; Prima e dopo cambiamenti ai servizi IT o all infrastruttura; Prima di una release o installazione per assicurarsi che l ambiente sia come previsto; In seguito al recovery da incidenti e dopo il ritorno alla normalità; Ad intervalli pianificati; A intervalli random; In risposta ad ogni CI non autorizzato. 63

64 In caso vi sia un alta incidenza di CI non autorizzati, la frequenza dei controlli deve essere aumentata per le parti dell infrastruttura affette dal problema. 3.3.g Information management Dovrebbero essere effettuate regolarmente copie di backup del CMS e tenute in luogo sicuro. È consigliabile tenere una copia in un luogo remoto per un eventuale uso in caso di disastro. Il CMS contiene informazioni sulle copie di backup dei CI. Contiene altresì traccia storica dei CI e delle versioni di CI che sono state archiviate, compresi eventualmente quelli cancellati. La quantità di cronologia da mantenere dipende dalla sua utilità all interno dell organizzazione. Le politiche di mantenimento della cronologia devono essere regolarmente riviste e modificate se necessario. Normalmente, il CMS dovrebbe mantenere informazioni solo per gli oggetti che sono fisicamente disponibili o che possono facilmente essere ottenuti con procedure note e sotto il controllo del Configuration Management. 3.3.h Key Performance Indicator (KPI) Così come accade con tutti i processi, le prestazioni del SACM devono essere monitorate e migliorate nel tempo con le seguenti misure: Diminuzione del tempo necessario all identificazione di CI non conformi; Utilizzo e redistribuzione di risorse sottoutilizzate; Miglioramento del rapporto tra licenze pagate ed effettivamente usate; Diminuzione del costo per licenza; Abbattimento dell impatto negativo dovuto a errori e incidenti causati da Asset e Configuration Management inadeguati; Diminuzione di errori causati da personale non sufficientemente qualificato; Riduzione nell uso di hardware e software non autorizzati. 3.3.i Sfide, fattori di successo e rischi Le sfide per il SACM sono: Convincere lo staff del supporto tecnico ad adottare una politica di check in/out; 64

65 Attirare e giustificare finanziamenti per il SACM; Evitare di raccogliere dati in eccesso portando a un sovraccarico sul SACM; Mancanza di supporto da parte del management che sottovaluta il ruolo del SACM nel supportare gli altri processi. I fattori critici di successo includono: Dimostrare un approccio top-down, incentrato sull identificazione dei CI e sulla dimostrazione dei potenziali punti di fallimento per ogni servizio dato; Usare la giusta tecnologia per automatizzare il CMS e rafforzare le politiche del SACM. I rischi per il SACM includono: La tendenza a considerarlo incentrato sulla tecnologia, piuttosto che sui servizi e sul business; Il calo nel tempo dell accuratezza delle informazioni di configurazione, il che può causare errori. 3.4 Release and Deployment Management Il Release e Deployment Management mira a progettare, testare e rilasciare la possibilità di fornire i servizi specificati dal Service Design che soddisfino i requisiti fissati dagli stakeholder e raggiungano gli obiettivi fissati. 3.4.a Finalità, traguardi, obiettivi Finalità Definire piani di sviluppo con clienti e stakeholder; Assicurarsi che ogni pacchetto di release consista in un set di asset e componenti di servizio che siano compatibili tra di loro; Assicurarsi che l integrità del pacchetto di release e delle sue parti costituenti siano mantenute attraverso le attività di transizione; Assicurarsi che tutti i pacchetti di sviluppo possano essere tracciati, installati, testati, verificati e rimossi; 65

66 Registrare e gestire rischi, cambi di percorso e problemi relativi ai nuovi servizi; Assicurarsi che vi sia un passaggio di know-how verso i clienti e gli utenti per permettere loro di ottimizzare l uso del servizio; Assicurarsi che il know-how sia trasferito allo staff operativo e di supporto per permettere il supporto al servizio secondo il livello di qualità richiesto. Traguardi Portare le release in produzione e stabilire direttive per un uso efficace del servizio in modo da fornire dei valori ai clienti e gestire le operazioni del servizio. Obiettivi Assicurare che: Vi siano piani di sviluppo chiari e comprensivi, che permettano ai clienti di allineare le loro attività con questi piani; Un pacchetto di release possa essere sviluppato, testato e messo in produzione efficacemente; I nuovi servizi soddisfino i requisiti accordati; Vi sia un impatto minimo sui servizi di produzione; Clienti, utenti e staff di Service Management siano soddisfatti delle pratiche di Service Transition. 3.4.b Prospettive Le prospettive del Release e Deployment Management sono di portare una release in produzione e stabilire i servizi specificati nel Service Design Package prima dell ingresso in produzione. 3.4.c Valore per il business Transizioni terminate più velocemente, al costo ottimale e rischio minimo; Clienti e utenti possono usare il nuovo servizio in modo da supportare gli obiettivi del management; Requirement accurati per una tracciabilità tramite il Service Transition. 66

67 Uno sviluppo e un processo di release ben pianificato e strutturato può fare una differenza significativa sui costi del servizio. Uno sviluppo mal progettato può costringere il personale IT a perdere una quantità di tempo considerevole per risolvere eventuali problemi. 3.4.d Criteri, principi e concetti di base Release unit Una release unit descrive la porzione di un servizio o infrastruttura IT, normalmente rilasciati assieme in accordanza con le policy di release dell organizzazione. Lo scopo è stabilire il livello di release più appropriato per ciascun asset di servizio o componente. Devono essere considerati i seguenti fattori nella decisione del livello appropriato per le unità di release: La facilità e la quantità di cambiamenti necessari per rilasciare un unità di release; La quantità di risorse e tempo necessaria a sviluppare, testare, distribuire ed implementare un unità di release; La complessità delle interfacce tra l unità di release e il resto dei servizi e infrastruttura IT. Progettazione delle release e considerazioni Il Service Design definisce l approccio alla transizione dal vecchio al nuovo servizio. Approccio Big Bang e approccio a fasi Esistono due metodi per mettere in produzione una release in locazioni multiple: Big Bang : il nuovo servizio viene implementato in tutte le aree in una singola operazione. Questo viene in genere attuato quando è considerata critica la consistenza del servizio all interno dell organizzazione. Approccio a fasi: il servizio viene implementato inizialmente su una base ristretta di utenti, per poi essere diffuso gradualmente tramite un piano di diffusione. Per poter scegliere l approccio a fasi, il servizio deve essere progettato affinché versioni più vecchie dello stesso possano coesistere; in caso contrario, l unica strada percorribile è quella dell implementazione Big Bang. 67

68 Approccio push e approccio pull L approccio push è usato quando il servizio è distribuito dal centro verso le locazioni target. In termini di distribuzione del servizio, fornire componenti aggiornate di un servizio a tutti gli utenti costituisce un approccio push, in quanto questo avviene secondo tempistiche non scelte dagli utenti. Un approccio pull è usato quando il software è disponibile in una locazione centrale e gli utenti sono liberi di prelevarlo verso la loro locazione secondo tempistiche di loro scelta, o quando la workstation effettua un riavvio. Quest ultimo approccio è usato per aggiornamenti non critici, mentre in caso di aggiornamenti importanti, come update per l antivirus, si adotta un approccio push. Dal momento che alcuni utenti potrebbero non effettuare mai l aggiornamento proposto tramite l approccio pull, generalmente dopo una certa quantità di tempo viene forzato tramite push. Approccio automatico e approccio manuale Un approccio automatico della distribuzione di una release assicura ripetibilità e consistenza. Tuttavia, non sempre è possibile fornire un meccanismo automatico efficiente e ben progettato: in caso di utilizzo di meccanismi manuali è importante monitorare e valutare l impatto di attività manuali, in quanto suscettibili di errori e inefficienze. Troppe attività manuali rallentano il team di release e creano problemi che impattano sull efficienza del servizio. Modelli di release e deployment Un servizio può essere distribuito nell ambiente di produzione in un certo numero di modi. Il Service Design si occupa di selezionare il modello di distribuzione più adeguato che includa i meccanismi, i processi, le procedure e le risorse necessarie per sviluppare e distribuire la release in tempo e entro il budget previsto. I metodi di release usati durante le prime build e le fasi di test possono variare di molto rispetto a quelli utilizzati in ambiente di produzione. I modelli di release e distribuzione definiscono: La struttura di release; I criteri di uscita ed entrata; 68

69 Gli ambienti necessaria alla compilazione della release e al suo testing per ogni livello di release; I ruoli e le responsabilità per ogni CI ad ogni livello di release; I sistemi, strumenti e procedure di supporto per la documentazione di tutte le attività di release. 3.4.e Attività, metodi e tecniche per i processi Pianificazione Piani di release e deployment I piani per la release e la distribuzione del servizio sono collegati con i piani del Service Transition e adottano il modello di release e distribuzione scelto. L intenzione è di avere un set di linee guida scalabili per portare in produzione la release e successivamente distribuirla. Anche se piccole organizzazioni hanno una struttura meno complessa, le discipline dettagliate sono di grande rilevanza: i piani di release e distribuzione devono essere scalabili anche in caso di una singola organizzazione. I piani di release e distribuzione devono essere autorizzati tramite il Change Management e devono definire: L obiettivo e il contenuto della release; Il profilo di rischio della release; Le organizzazione e gli stakeholder coinvolti dalla release; Il team responsabile per la release. Criteri di successo e insuccesso Il Service Transition è responsabile per la pianificazione delle situazioni di successo e insuccesso. È importante fornire questi criteri agli stakeholder di rilievo in anticipo affinché possano avere un idea corretta di cosa aspettarsi. Build e test prima dell entrata in produzione La pianificazione di build e testing stabilisce l approccio alla progettazione, testing e manutenzione di un ambiente controllato prima della produzione. 69

70 Figure 3.4.1: Modello a V La figura fornisce un esempio di un modello che può essere usato per rappresentare i diversi livelli di configurazione che possono essere sviluppati e testati per fornire le operazioni del servizio. La parte sinistra rappresenta le specifiche dei requisiti del servizio, mentre la parte destra focalizza sulla la validazione e attività di testing che sono eseguite per valutare le specifiche definite sulla parte sinistra: per ogni stadio sulla parte sinistra ne è associato uno su quella destra. Devono essere approntati diversi ambienti controllati per supportare diversi tipi e livelli di testing. Possono essere utilizzati processi di distribuzione e procedure preesistenti per approntare gli ambienti di testing, che devono essere sicuri e proibire l accesso non autorizzato. Progetti pilota I progetti pilota sono utili per testare il servizio con una piccola parte della base di utenti prima di renderlo disponibile a tutta la comunità del servizio. È importante stabilire la portata appropriata del progetto, ovvero che parte del servizio includere, ampiezza della base d utenti, ecc.; questo è un passo base nella creazione del progetto pilota: se infatti la portata è troppo esigua problemi e imprevisti potrebbero risultare solo dopo la messa in produzione, se troppo ampia vanifica i vantaggi del progetto pilota, risultando in una messa in produzione vera e propria. Un progetto pilota può stabilire la fattibilità di molti, se non tutti, aspetti di un servizio. 70

71 Deve essere possibile effettuare un rollback del progetto pilota prima della messa in opera del nuovo servizio: l attività di testing infatti potrebbe usare materiale che deve poi essere riportato allo stato iniziale al termine del progetto pilota. Può risultare inoltre vantaggioso implementare un set di più progetti pilota, considerando prima alcuni fattori: Velocità e costi: un singolo progetto pilota sarà sicuramente più economico e più veloce rispetto a progetti multipli e potrebbe essere la soluzione ideale per un organizzazione omogenea, che con un singolo progetto coprirà pressapoco tutte le possibili eventualità; Organizzazioni disomogenee: in un organizzazione con un ampio range di possibili circostanze, potrebbe essere vantaggioso avere diversi progetti pilota che testino diverse aree allo stesso momento, consentendo quindi un certo parallelismo e un risparmio in termini di tempo. Un alternativa è eseguire questi progetti serialmente, usando per i successivi l esperienza maturata nei precedenti; Multiple strade: nel caso vi siano diverse opportunità da esplorare, potrebbe essere vantaggioso assegnare ognuna di essere a un progetto differente, e valutare poi in base ai risultati ottenuti quale seguire. Pianificazione dell implementazione della release Le attività di pianificazione dell implementazione della release includono piani e procedure per: Verificare i criteri di entrata e uscita; Formare professionalmente lo staff e trasferire il know-how; Stabilire i servizi e i loro asset; Convertire sistemi e utenti dalle applicazioni correnti al nuovo servizio; Verificare che i destinatari di un nuovo servizio siano pronti ad accogliere una release. Pianificazione della distribuzione Elenco di domande che bisogna porsi durante la pianificazione della distribuzione: Cosa deve essere distribuito? Chi sono gli utenti? Ci sono dipendenze dalla locazione? Dove sono gli utenti? Chi altro deve essere ben preparato in anticipo? Quando deve essere completata la distribuzione? Per quale motivo sta avendo atto una distribuzione? Quali sono i fattori critici di successo e i criteri di uscita? Quale è l attuale capacità del service provider? 71

72 Pianificazione della logistica e della distribuzione Gli aspetti da curare in questa pianificazione prevedono: Come e quando le release unit e le componenti del servizio verranno distribuite; Quali sono le tempistiche e cosa fare in caso di ritardi; Come tracciare i progressi e ottenere conferma di avvenuta consegna; Disponibilità di storage sicuro quando necessario. Una volta che i piani per la logistica e la distribuzione sono stati determinati, devono essere comunicati a tutti gli stakeholder. La consegna non è sufficiente: una logistica corretta richiede che le componenti arrivino a destinazione e si comportino come previsto. Di conseguenza i piani di distribuzione devono prevedere tracciabilità e documentazione alla consegna, come: Nota di consegna; Lista di cosa dovrebbe esserci; Come fare per assicurarsi che tutto funzioni. Pianificazione finanziaria/commerciale Gli aspetti finanziari e commerciali devono essere specificatamente controllati prima della distribuzione. Preparazione per implementazione, test e distribuzione Prima di autorizzare lo stadio di implementazione e testing, il Service Design e il release design devono essere autorizzati e validati. Questo dovrebbe risultare in un feedback costruttivo sul Service Design. Bisogna effettuare la registrazione, tracciatura e misurazione di qualsiasi rischio e problema legato ai servizi, service asset e CI; successivamente vanno prioritizzati i problemi e le azioni da intraprendere affinché siano risolti in tempo utile; infine bisogna produrre un report di validazione e i risultati associati, pronti per una valutazione del servizio. Questa valutazione controlla che i cambiamenti ai servizi forniranno i risultati previsti. Se vi sono problemi verrà prodotto un report di valutazione, che elencherà le deviazioni dal SDP, un profilo di rischio e le raccomandazioni per il Change Management. Una valutazione completa delle linee guida del Service Design assicura che la release del servizio verrà sviluppata partendo da un design stabile e approvato. Per alcune release il Service Transition Manager può stabilire un team di persone competenti per eseguire i piani. 72

73 Spesso, l introduzione di un servizio tecnologico richiede training per i vari team di distribuzione, implementazione e testing. Le necessità di training di questi gruppi saranno a diversi livelli: riconoscere le diverse capacità e competenze all interno dei vari gruppi è un utile prerequisito per l identificazione del training necessario. Implementazione e testing Durante gli stadi di implementazione e testing, i servizi comuni e le infrastrutture devono essere gestite attentamente, dal momento che possono influire significativamente su questi stadi dello sviluppo di un servizio tecnologico. Le linee guida degli ambienti controllati e i pacchetti di release sono registrati nel CMS per poter offrire un punto di ripristino. Inoltre, le informazioni di configurazione devono essere aggiornate per riflettere l implementazione di una release unit o di un pacchetto completo di release verso un gruppo di distribuzione o un ambiente target. La versione definitiva del pacchetto di release deve essere situata nel DML, anche se il pacchetto consiste solo in documentazione su aggiornamenti hardware. Documentazione di release e build La documentazione per acquistare, distribuire, installare, spostare e controllare asset e componenti rilevanti per acquisire, implementare, testare e rilasciare una release include: Contratti e accordi; Richieste di acquisto e ordini; Acquisto e consegna di beni; Linee guida per sicurezza e salute; Policy e procedure di sicurezza; Accordi di leasing; Proprietà intellettuali; Accordi di assistenza; Procedure per: o Gestire le configurazioni di servizi e infrastruttura, o Distribuire e installare software, o Distribuire, tradurre e convertire dati e informazioni, o Distribuire, installare e spostare equipaggiamenti, o Eliminare documentazione, media e equipaggiamento, o Pubblicare informazioni, dati e know-how, o Validare e testare, o Change Management; Service Asset e Configuration Management. 73

74 Acquisire e verificare le componenti e i CI Gli elementi e le componenti di configurazione sono acquisiti da progetti, fornitori, partner e gruppi di sviluppo. Per prevenire l acquisizione di componenti sconosciuti e potenzialmente rischiosi, è essenziale usare CI che abbiano raggiunto un certo livello di qualità o componenti da un catalogo standard precedentemente testato e autorizzato per l utilizzo in condizioni specifiche. Problemi, inconformità ed errori noti devono essere segnalati ai relativi stakeholder. Release packaging Devono essere implementate procedure di gestione, metodologie, tool e checklist per assicurarsi che il pacchetto di release sia costruito in un ambiente standard, controllato e riproducibile, in linea con il design definito nel Service Design Package. Le attività chiave per assemblare il pacchetto di release sono: Assemblare ed integrare le componenti della release in maniera controllata per assicurare un processo riproducibile; Creare la documentazione della release; Installare e verificare il pacchetto di release; Inviare una notifica per informare le parti rilevanti che il pacchetto di release è pronto per l installazione e l uso. Se il testing di un pacchetto di release è positivo, esso viene messo sotto il controllo del Configuration Management e verificato con le specifiche di design della release e di definizione del pacchetto di release. Da questo punto in poi tutte le variazione al pacchetto di release sono gestite attraverso il Change Management. Creazione e gestione dell ambiente di testing Una gestione efficace dell ambiente di testing è essenziale per assicurare che le build e i test siano eseguiti in maniera gestibile e ripetibile. Un controllo inadeguato di questi ambienti porta cambiamenti non pianificati a compromettere le attività di testing. Un servizio IT generalmente è costituito da un certo numero di risorse tecnologiche o asset di gestione. Nella fase di build questi blocchi differenti, spesso ottenuti da fornitori diversi, sono installati e configurati assieme per creare la soluzione progettata. La standardizzazione facilita l integrazione dei diversi blocchi per fornire una soluzione funzionante. Automatizzare l installazione dei sistemi e del software su server e workstation riduce le dipendenze verso l uomo e ottimizza le procedure. A seconda dei piani di release e distribuzione, l installazione può essere eseguite in anticipo o in situ. 74

75 L infrastruttura fisica deve essere testata appropriatamente, includendo prove di replicazione dell infrastruttura da un ambiente di esecuzione all altro. Gli ambienti di testing devono essere mantenuti attivamente e protetti usando le linee guida del Service Management. Testing del servizio e progetti pilota I criteri di testing riflettono le condizioni previste nelle quali il servizio dovrà operare. Tuttavia, queste circostanze possono cambiare, spesso in maniera repentina e non prevedibile: questi cambiamenti e il loro impatto sul testing del servizio devono essere tenuti sotto controllo, compresi e documentati. Le loro conseguenze devono essere espresse in termini di Acceptance Criteria cambiati e aggiornamenti al service package. Figura 3.4.2: Esempio di testing di un servizio attraverso il Service Transition 75

76 Un esempio dei test che possono essere eseguite durante la release e la distribuzione sono documentati nella figura Prove generali per il servizio Un metodo di testing consiste nel simulare quanto più possibile del servizio in una prova generale. È l ultimo stadio del testing interno, eseguito prima di qualsiasi esecuzione in ambiente live, e viene eseguito cercando di riprodurre quanto più possibile l ambiente di esecuzione finale. Può fornire preziosi elementi di valutazione stabilendo quali procedure non potranno funzionare in ambiente live o potrebbero produrre errori che impattino negativamente sul business. Tuttavia, sono procedure complesse, costose e che richiedono una considerevole quantità di tempo e risorse, e un accurato bilanciamento tra i costi previsti e il possibile danno che potrebbero prevenire è d obbligo. Una prova generale di operatività del servizio avviene poco prima della sua messa in produzione: avviarla troppo presto potrebbe portare ad avere cambiamenti nell ambiente di esecuzione rispetto a quello di testing, mentre un ritardo potrebbe far slittare la data di rilascio o tralasciare fattori di rischio importanti. Una tipica sessione di testing avviene in una giornata di prova generale secondo il ciclo Plan Do Check Act. Plan preparazione per il giorno Nominare un manager della prova; Identificare i processi chiave e quelli secondari; Identificare tutti gli stakeholder e le loro informazioni di contatto; Produrre una guida per la prova; Stabilire esempi di documenti per incidenti, richieste di assistenza, problemi di capacità e disponibilità e qualsiasi altro possibile evento che potrebbe verificarsi al momento dell esecuzione; Identificare tutti gli stakeholder, fornitori e provider di servizi che devono essere coinvolti nel processo; Invitare tutti gli stakeholder alla pianificazione di meeting e briefing. Do eseguire la prova Fissare meeting per: Introdurre gli obiettivi, documenti, ecc.; Effettuare la prova. 76

77 Check documentare la giornata Analizzare e valutare i risultati della prova e determinarne le conseguenze; Produrre un report scritto della prova; Memorizzare errori, problemi e rischi emersi durante la prova. Act agire in seguito alla prova Considerati i risultati della prova si profilano due soluzioni: Dichiarare che il servizio ha passato la prova senza particolari problemi, OPPURE considerare che il servizio non è idoneo a progredire in questo stadio e riferire al Service Design e/o al Service Transition per le modifiche. Pianificazione e preparazione per il deployment Le attività di pianificazione e preparazione del gruppo di distribuzione sono un opportunità per preparare l organizzazione alla transizione. Durante lo stadio di deployment viene sviluppato il piano d implementazione, il che comprende assegnare ogni singolo individuo a specifiche attività. 77

78 Figura 3.4.3: Esempio di un insieme di attività di deployment Stime Anche se le stime sul processo di distribuzione dovrebbero essere condotte con un certo anticipo, devono essere rivisitate periodicamente. Le valutazioni sullo stato di preparazione di un gruppo di distribuzione identificano: Problemi e rischi che potrebbero influire il deployment dei servizi, tra cui: o Mancanza di risorse interne ed esterne, 78

79 o Mancanza di training e know-how, o Cambiamenti nei requisiti non pianificati; Incidenze previste; Mancanze che devono essere corrette. Gli aspetti da valutare includono: Aspetti finanziari; Problemi e rischi nella consegna dei servizi; Regolamentazioni applicabili su salute, sicurezza e ambiente; Risorse e potenzialità dei servizi correnti; Risorse e potenzialità del Service Management corrente; Stato di prontezza dell organizzazione; Infrastrutture e attrezzature (locazione, capacità e potenzialità del reparto IT). Sviluppo dei piani e preparazione per il deployment La pianificazione per uno specifico deployment include l assegnamento di determinate risorse per poterlo effettivamente eseguire e per permettere le attività di supporto nei primi periodi di attività. La pianificazione include: Piani per la diminuzione del rischio; Piani di transizione, aggiornamento, conversione, abbandono; Piani di logistica e distribuzione; Trasferimento di know-how e training di stakeholder su come ottenere i massimi benefici dal nuovo servizio; Comunicazione alle persone coinvolte di quali saranno i cambiamenti e che benefici porteranno, oltre a come interesseranno l organizzazione e lo staff; Mobilitare gli utenti per renderli pronti all uso del nuovo servizio. Esecuzione di trasferimento, deployment e ritiro Trasferimento delle risorse finanziarie I trasferimenti di risorse finanziarie vanno completati come parte del deployment, il che include: Qualsiasi cambiamento negli accordi finanziari con i fornitori; Acquisto o trasferimento del supporto annuo e costi di manutenzione; Costi di acquisto di nuove licenze o rinnovi delle stesse; Contratti di disaster recovery; Trasferimento delle proprietà intellettuali. 79

80 Trasferimento/transizione di unità di business Il trasferimento di una business unit, di un servizio o di un unità di servizio, corrisponde ad un cambiamento nell organizzazione stessa. Sono richieste persone con le giuste capacità e competenze per poter effettuare le operazioni di deployment e per operare e gestire il nuovo servizio, e sarà quindi necessario: Assumere staff con le capacità appropriate piuttosto che formare i dipendenti attuali; Identificare le persone all interno dell organizzazione che già possiedono le capacità richieste e, se necessario, riallocarle ove richieste; Considerare risorse in outsourcing per ottenere staff dotato delle capacità necessarie; Fornire attività di training; Valutare le competenze dello staff. Deployment di processi e materiale Distribuire o pubblicare i processi e il materiale (processi, procedure, manuali, prodotti di training, ecc.) a coloro che sono coinvolti con la transizione. Deployment della capacità di Service Management Distribuire i nuovi processi, sistemi e strumenti ai team dei fornitori del servizio responsabili per le attività di Service Management, controllando che ciascuno sia competente per operare, mantenere e gestire il servizio in accordanza con i modelli e processi del servizio stesso. Trasferimento del servizio I problemi causati dal trasferimento di un servizio e le azioni da intraprendere in merito includono: Riesaminare le prestazioni, problemi e rischi del servizio eseguendo determinati test prima del trasferimento; Verifica della configurazione delle risorse del servizio; Comunicare il cambiamento agli stakeholder. Nel caso il cambiamento preveda un trasferimento di un fornitore di servizi, bisogna considerare anche: Gestione dei cambiamenti di contratto; Gestione dei cambiamenti agli accordi esistenti; Aggiornamento dei dettagli dei contratti; Trasferimento della proprietà delle risorse del servizio e degli elementi di configurazione. 80

81 Deployment del servizio Distribuire il servizio e le componenti del servizio nelle corrette locazioni e nel giusto momento; Impacchettare, installare e configurare i servizi e le componenti dei servizi con i nuovi dati e informazioni; Testare il sistema e i servizi; Registrare incidenti, eventi inaspettati e problemi; Correggere eventuali uscite di percorso. Decommissionamento e ritiro del servizio Rimuovere copie di software e dati dall hardware dismesso; Identificare licenze e altre risorse che possono essere riutilizzate; Eliminare l equipaggiamento obsoleto seguendo le procedure corrette; Spostare le risorse che possono essere riutilizzate in luogo sicuro. Rimozione di risorse ridondanti Una piena conoscenza delle risorse usate da un servizio permette, al momento della sua disattivazione, di gestire in maniera efficace le sue risorse, rimuovendo quelle non più necessarie e mantenendo quelle riutilizzabili, evitando quindi di: Sprecare spazio su disco e licenze; Pagare più del dovuto licenze e contratti di assistenza; Rimuovere risorse associate sia al servizio dismesso, sia tuttavia ad altri servizi in uso. Come parte della procedura di rimozione delle risorse non più utilizzate è importante cancellare o archiviare propriamente dati, informazioni e record ridondanti relativi al precedente processo. Verifica del processo di deployment Terminate le procedure di deployment, è fondamentale verificare che utenti, Service Operation, staff e stakeholder siano in grado di usare il nuovo servizio, verificando che: Il servizio e le sue risorse siano operativi; La documentazione sia stata aggiornata; Tutti i ruoli siano assegnati alle persone corrette; Lo staff sia pronto ad operare e usare il nuovo servizio; Lo staff abbia la possibilità di accedere alle informazioni necessarie per operare con il nuovo servizio. 81

82 Early Life Support L Early Life Support (ELS) fornisce la possibilità di migrare il nuovo servizio verso il Service Operation in maniera controllata e monitorata, permettendo di stabilire le capacità e risorse del nuovo servizio in maniera effettiva. Figura 3.4.4: Esempio di attività di ELS L ELS fornisce appropriate risorse per risolvere problemi operazionali e di supporto in maniera rapida, facendo sì che gli utenti possano usare il servizio senza interruzioni. Il team di distribuzione farà le dovute analisi qualora utenti o risorse incontrino problemi dovuti dal nuovo servizio, implementando le dovute correzioni per risolvere i problemi emersi. 82

83 Figura 3.4.5: Illustrazione dei benefici dell ELS La figura mostra il numero di incidenti avvenuti in un organizzazione in scenari perfettamente identici, il primo tuttavia con attività di ELS, il secondo senza. È importante risolvere problemi e fattori di rischio a intervalli regolari durante il periodo di ELS, specialmente quelli che impattano su costi e programmi della forza lavoro. Verifica e chiusura di un deployment Raccogliere feedback da clienti, utenti e fornitori dei servizi; Mettere in evidenza i criteri di qualità che non sono stati raggiunti; Verificare che qualsiasi correzione e azione necessaria sia stata effettuata; Verificare che gli obiettivi di prestazioni, incluso uso di risorse e capacità, siano stati raggiunti; Verificare che problemi, errori noti e soluzioni siano documentati; Verificare che le risorse ridondanti siano state gestite; Verificare che il servizio sia pronto per passare dallo stadio di ELS a quello operativo. Verifica e chiusura del Service Transition Per poter dichiarare che il Service Transition è effettivamente completato, deve essere redatta una verifica finale che stabilisca che sia appropriato alla scala della transizione; questa verifica deve includere: Verifica che tutte le attività di transizione siano state completate; Verifica che siano state raccolte metriche accurate. 83

84 3.4.f Punti di partenza, input e output, interfacciamento inter-processo Input RFC autorizzato; SLP; SDP; Piano di continuità del servizio IT e relativi piani di continuità business; Service Management; Risorse e componenti di servizi acquisite; Politiche di release fornite dal Service Design; Modelli di release e di distribuzione; Criteri di entrata e uscita per ogni stadio di release e deployment. Output Piani di release e di distribuzione; RFC complete per le attività di release e distribuzione; Catalogo dei servizi aggiornato con le informazioni rilevanti del nuovo servizio; Documentazione di Service Management aggiornata; Service Package, che definisce i requisiti da parte dei clienti e del business verso il servizio; SLP, che definisce i requisiti del servizio; SLA, OLA e contratti; Modello di servizio, che descrive la struttura e le dinamiche di come il servizio è operato e gestito; Report del nuovo servizio; Piani di continuità; Lista completa ed accurata dei CI; Report del Service Transition. 3.4.g Information management Mano a mano che i CI sono completati, il CMS viene aggiornato con informazioni come: Nuovi CI; Relazioni tra requisiti e test; Piani di installazione; Piani di logistica e consegna; Nuove locazioni e utenti; Aggiornamenti sullo stato; 84

85 Cambi di proprietà delle risorse. Il Service Knowledge Managament System raccoglie dati su: Informazioni sul deployment, cronologia del deployment stesso, persone coinvolte, ecc.; Regole e livelli di accesso; Errori noti. 3.5 Service Validation and Testing Lo scopo principale del Service Testing and Validation è assicurare la qualità finale del prodotto, ovvero stabilire che il Service Design e il Service Release forniscano un servizio in linea con le aspettative. La fase di testing assume quindi un ruolo fondamentale all interno del Service Management, in quanto se i servizi non sono accuratamente testati si può incorrere in: Incidenti; Chiamate di assistenza al Service Desk; Problemi ed errori difficili da individuare e risolvere nell ambiente live; Costi; Servizi inefficienti. 3.5.a Finalità, traguardi, obiettivi Finalità Pianificare ed implementare una validazione strutturata e processi di testing che forniscano un evidenza obiettiva che il nuovo servizio soddisfi i requisiti di clienti e stakeholder; Assicurare la qualità di una release, le sue componenti, il servizio risultante e la capacità del servizio; Identificare, verificare e risolvere problemi, errori e rischi attraverso il Service Transition. 85

86 Traguardo Il traguardo del Service Validation and Testing è di assicurare che un servizio fornirà determinati vantaggi ai clienti e al loro business. Obiettivi Far sì che una release creerà un nuovo servizio che offrirà le operazioni e vantaggi previsti ai clienti e al costo, capacità e limitazioni previsti; Assicurarsi che i requisiti di clienti e stakeholder per il nuovo servizio siano correttamente definiti e correggere errori e variazioni all inizio del ciclo di vita del servizio. 3.5.b Prospettive Il Service Validation and Testing può essere applicato lungo tutto il ciclo di vita del servizio per assicurare la qualità di ogni aspetto dello stesso. Il testing supporta direttamente il processo di release e deployment, assicurando che venga applicato l appropriato livello di testing durante le attività di release, build e deployment e valutando dettagliatamente i modelli del servizio per assicurare che siano su misura per lo scopo designato e pronti all uso prima di essere autorizzati ad entrare in funzione. 3.5.c Valore per il business Errori nel servizio possono causare danni al business del service provider e alle risorse dei clienti, e portano di conseguenza a perdita di reputazione, di soldi, di tempo. Il valore chiave fornito dal Service Testing and Validation al business e ai clienti è un certo grado di confidenza che il nuovo servizio eseguirà le operazioni richieste senza errori. 3.5.d Criteri, principi e concetti di base Input dal Service Design Un servizio è definito da un pacchetto di servizio che comprende uno o più SLP (Service Level Package) e delle componenti riusabili, alcune delle quali sono servizi. Il pacchetto di servizio 86

87 definisce le operazioni e garanzie che sono fornite dal servizio in condizioni di corretto funzionamento. Il Service Design Package definisce i requisiti del servizio, che forniscono gli elementi chiave per la pianificazione e progettazione della sessione di testing. Qualità e garanzie del servizio Le garanzie sul servizio sono ottenute tramite verifica e validazione, che sono ottenute a loro volte tramite sessioni di testing e verifica dei risultati rispetto alle specifiche. La validazione conferma che sono stati rispettati i requisiti per un uso specifico o un applicazione specifica. La validazione in un contesto di ciclo di vita assicura che il servizio o il sistema è in grado di fornire i risultati aspettati. All inizio del ciclo di vita del servizio, la validazione conferma che i bisogni dei clienti specificati nel pacchetto di servizio sono effettivamente tradotti correttamente nel Service Design come requisiti del servizio. Più avanti nel ciclo di vita, sono eseguiti test per verificare che il servizio effettivamente soddisfi i requisiti di cui sopra. Le garanzie specificano che un prodotto o servizio rispetterà determinate specifiche. Politiche Politiche di Service quality Il dirigente definisce il significato della qualità del servizio; il Service Strategy discute le prospettive di qualità che un fornitore di servizi deve considerare. Politiche di rischio Diverse tipologie di utenti, organizzazioni, business unit e service unit hanno diverse predisposizioni ai rischi: un organizzazione con alto fattore di rischio sicuramente avrà meno confidenza sul funzionamento di un servizio piuttosto che un organizzazione ad alta sicurezza. Le politiche di rischio influenzano i controlli richiesti attraverso il Service Transition, incluso il grado di testing di superamento dei requisiti. Politiche di Service Transition Vedi Capitolo 2. 87

88 Politiche di Release Il tipo e la frequenze delle release influenzano l approccio al testing: release frequenti per esempio possono implicare procedure di testing ad alta automazione. Politiche di Change Management L uso del Change Management può influenzare la fase di testing: se per esempio la release di un pacchetto viene slittata nel tempo può essere richiesto testing addizionale. Strategia di test La strategia di testing definisce l approccio all organizzazione della fase di test e all allocazione delle risorse necessarie; può essere applicata all intera organizzazione, a un set di servizi o a un servizio singolo e deve essere sviluppata assieme agli stakeholder appropriati. Le attività per definire i piani per il testing comprendono: Tradurre il Service Design nei requisiti e modelli per i test; Stabilire il miglior approccio per ottimizzare la copertura dei test, dati il profilo di rischio e la valutazione delle risorse; Tradurre il Service Acceptance Criteria nei criteri di entrata ed uscita per ciascun livello di testing, in modo da definire un margine di errore accettabile; Modelli di test Un modello di test include un piano dei test, cosa deve essere testato e gli script che definiscono come ogni elemento sarà testato. Un modello assicura che la fase di test sia eseguita in maniera consistente in una modalità ripetibile efficace ed efficiente. Gli script definiscono le condizioni di test, i risultati attesi e i cicli di test. Prospettive di validazione e testing Prospettive di utenti business e clienti Il coinvolgimento del business nell approvazione dei test è fondamentale affinché la procedura vada a buon fine ed è incluso nel Service Design, permettendo un adeguata pianificazione delle risorse. Dal punto di vista del business questo è importante per: 88

89 Avere un metro di misura per l accettabilità del servizio, incluse le interfacce con il fornitore dei servizi; Comprendere e rendere disponibile il giusto livello e la corretta capacità di risorse. Dal punto di vista del fornitore del servizio è importante il coinvolgimento del business per: Mantenere il business coinvolto durante la fase di testing per evitare sorprese al termine; Assicurarsi che la qualità finale del servizio sia buona, in quanto è uno dei primi parametri di valutazione della qualità del sistema; Capire dove i test di accettabilità possano essere inseriti all interno di un servizio business o attività di testing di un prodotto. User testing application, system, service Le procedure di testing comprendono simulazioni, eseguite in un ambiente il più vicino possibile a quello di produzione, atte a determinare che il servizio soddisfi i requisiti funzionali e di qualità previsti. È dunque fondamentale comunicare in maniera efficace agli utenti che partecipano al test che, essendo una prova, non tutto potrebbe andare come previsto e errori e problemi possono accadere in qualsiasi momento del test. Prospettive di miglioramenti per operazioni e servizi Devono essere presi provvedimenti per assicurare che tutti i requisiti dello staff IT siano stati soddisfatti prima del deployment del servizio, verificando che: Le risorse tecnologiche siano pronte ad offrire il nuovo servizio; Le capacità dello staff, know-how e risorse siano disponibili per assistenza dopo che il servizio sia operativo; Sia stata considerata la continuità del business e del reparto IT; Via sia accesso alla documentazione e al SKMS. Il Continual Service Improvement erediterà il nuovo servizio all interno del programma di miglioramento continuo. Approcci e tecniche di testing Vi sono numerose metodologie di testing che possono essere combinate tra di loro per raggiungere pattern di testing efficaci ed efficienti, in grado di verificare che requisiti di differenti tipologie di servizi, modelli di servizio, profili di rischio, ecc. siano correttamente soddisfatti, come: 89

90 Verifica delle documentazioni; Approccio risk-based, che si focalizza sulle aree a maggior rischio; Approccio experience-based, che si avvale dell aiuto di esperti per focalizzarsi sulle aree più critiche; Approccio standard, che si basa su standard industriali; Simulazioni; Prototipazione; Test di laboratorio; Test di regressione; Progetti pilota. Le attività di testing devono essere allocate seguendo l ordine di importanza dei servizi, anticipando l impatto sul business e i rischi, in modo da ottimizzare le risorse dedicate al testing. Le analisi di impatto sul business condotte durante la fase di design e di Service Continuity Management sono spesso utili per stabilire le priorità di testing. Considerazioni di progettazione La progettazione del testing del servizio punta a sviluppare modelli e casistiche di testing che possano determinare se il servizio soddisfi i requisiti o meno, portando particolare attenzione a non focalizzarsi troppo sulle componenti a basso livello (più facili da testare), ma adottando un approccio strutturato che preveda un modello che interessi le componenti a tutti i livelli. Le considerazioni da fare al momento della progettazione del testing di un servizio includono: Business/Organization: o Allineamento con i servizi, processi e procedure del reparto business, o Cicli e variazioni stagionali del business, o Il numero e tipologia di utenti e le previsioni di crescita, o I possibili requisiti in seguito a nuove strutture e funzionalità; Service architecture and performance: o Service Portfolio, o Opzioni per testare differenti tipologie di risorse dei servizi, o Service Level Requirement e Service Level Target, o Service Transition Level; Requisiti per l ambiente di testing; Service Management: o Modelli di Service Management, o Modelli di Service Operation, o Modelli di Service Support, o Cambiamenti nei requisiti per il Service Management, o Cambiamenti nel volume degli utenti del servizio e delle transazioni; Application information and data: o Verificare che l applicazione funzioni correttamente con l infrastruttura tecnica, 90

91 o Verificare la funzionalità dell infrastruttura; Technical infrastructure: o Risorse fisiche, o Capacità delle risorse tecniche, o Pezzi di ricambio. Aspetti da considerare nella progettazione dei test per un servizio: Finanza (Budget adeguato? Spese oltre il budget? Costi cambiati?); Documentazione (La documentazione necessaria è disponibile? È comprensibile?); Fornitori del servizio, delle sue risorse e componenti (Quali sono le interfacce esterne?); Build (Possono il servizio, le sue risorse e componenti essere trasformati in un pacchetto di release e ambiente di testing?); Verificabile (È verificabile con le risorse, tempo e infrastrutture disponibili?); Tracciabilità; Dove e quando il testing può essere fatto? Vi sono condizioni particolari sotto le quali il servizio potrebbe essere eseguito? La consapevolezza dal punto di vista tecnologico dell ambiente di esecuzione è essenziale per ottenere un ambiente di testing valido: la progettazione dell ambiente di testing deve tenere conto dell attuale e del previsto ambiente di esecuzione live ove il servizio opererà. Per molte organizzazioni è impossibile andare oltre a un periodo di 6 9 mesi, per altre si possono fare stime su basi annuali e oltre. Tipologie di testing I test funzionali dipendono dal tipo di servizio e dal canale di distribuzione; questi test sono descritti in molteplici standard e linee guida. Il testing di un servizio include anche diversi test non funzionali, come test di: Usabilità; Accessibilità; Processi e procedure; Trasferimento di know-how; Verifica di prestazioni e capacità; Verifica sotto carico e verifica della scalabilità; Verifica della disponibilità; Verifiche di coerenza; Verifiche di compatibilità; Verifica della documentazione; Verifica della sicurezza; Verifica di coesistenze e compatibilità; Verifiche di operabilità e mantenibilità. 91

92 Service requirements and structure testing service provider, users and customers I test sul servizio sono sviluppati per poter verificare i requisiti del servizio in termini di utilità, capacità, uso delle risorse, parte finanziaria e rischi. Service level testing service level managers, operations managers and customers Verifica la possibilità da parte del fornitore del servizio di soddisfare i requisiti del servizio: le performance di una risorsa di un servizio devono permettere di eseguire le operazioni per il quale il servizio è stato progettato. Warranty and assurance tests fit for use testing Come già anticipato, i clienti vedono il servizio in termini di garanzie verso alcune utilità che aggiungono valore alle loro risorse in modo da fornire il supporto a livello business richiesto. Per ciascun servizio le garanzie sono espresse in termini misurabili che permettono ai test di essere sviluppati in modo da stabilire che la garanzia può essere fornita. I seguenti test sono usati per fornire la confidenza che le garanzie possano essere fornite: Disponibilità: è il più elementare aspetto per assicurare dei valori ai clienti, fornendo la garanzia che il servizio sarà disponibile per l uso secondo i termini e le condizioni concordati; Capacità: è un aspetto del Service Reporting che assicura ai clienti che un servizio supporterà uno specifico livello di attività business. I clienti potranno apportare cambiamenti ai loro pattern di utilizzo dei servizi, avendo la certezza che i loro processi e sistemi business saranno adeguatamente supportati; Continuità: assicura ai clienti che il servizio continuerà a supportare le attività business nel tempo anche in caso di fallimenti. In caso di interruzione dei servizi vi è la garanzia, secondo gli accordi stipulati, che il servizio ritornerà operativo entro un certo lasso di tempo predeterminato; Sicurezza: assicura che l utilizzo dei servizi da parte dei clienti è sicuro, garantendo che le loro risorse non sono esposte a certi tipi di rischi. Usability users and maintainers I test di usabilità sono di importanza sempre crescente mano a mano che sempre più servizi vengono regolarmente usati come parte della vita quotidiana e della ordinaria amministrazione. Focalizzarsi sull immediatezza di uso di un servizio può aumentare significativamente l efficienza dello stesso e ridurre i costi complessivi. I test di usabilità analizzano le possibili abilità di attuali o futuri utilizzatori del nuovo servizio e verificano che sia usabile specialmente da: 92

93 Utenti disabili; Utenti con disturbi sensoriali (daltonici, miopi,..); Utenti non madrelingua. Contract and regulation testing Verifiche e test sono effettuati per assicurare che i criteri nei contratti siano stati accettati prima dell approvazione da un capo all altro del servizio. Compliance testing Vengono effettuate verifiche per assicurare il rispetto di regolamenti interni e impegni dell organizzazione preesistenti. Service Management testing Operational tests systems, services Carico e sforzo: questi test stabiliscono se il nuovo servizio funzionerà secondo gli standard previsti anche in situazioni di carico limite. Sicurezza: deve essere considerato l impatto che ogni servizio potrebbe avere sul sistema in termini di sicurezza, e verificata di conseguenza la gestione della sicurezza del nuovo servizio secondo questi criteri. Ripristino delle funzioni: per ogni nuovo servizio deve essere verificata la sua capacità di ripristinare le proprie funzioni in seguito a un problema, secondo i piani di Disaster Recovery. Regression testing La pratica di regression testing prevede una seconda esecuzione di un test andato a buon fine e la comparazione tra i risultati del primo e del secondo test. Questa procedura assicura che il nuovo servizio non introduca errori in seguito ad una prima esecuzione. 93

94 3.5.e Attività, metodi e tecniche dei processi Figura 3.5.1: Esempio di un processo di validazione e testing Il processo di testing è riassunto schematicamente nella figura Alcune attività di testing possono essere eseguite in parallelo. 1. Gestione di validazione e testing La gestione del testing include problemi di gestione, riduzione dei rischi e implementazione dei cambiamenti identificati durante le attività di testing, in quanto questi possono introdurre ritardi e creare dipendenze che devono essere gestite attivamente. Vengono usate metriche di testing per misurare il processo di test e gestire e controllare le attività di testing. 2. Pianificazione e progettazione dei test La pianificazione e progettazione dei test avviene ai primi stadi del ciclo di vita del servizio e include: Raccolta delle risorse; Dati e capabilità di hardware, networking e staff; Risorse di clienti e business richieste; Servizi di supporto; Requisiti finanziari. 3. Verifica della pianificazione e progettazione dei test Verificare i piani di testing e la progettazione dei test per assicurare che: 94

95 Il modello di testing fornisca una copertura di test adeguata e appropriata; Il modello ti testing copra gli aspetti chiave di integrazione; Gli script dei test siano accurati e completi. 4. Preparazione dell ambiente di test 5. Esecuzione dei test Effettuare i test, usando tecniche e procedure automatiche o manuali. I tester dovranno registrare le loro considerazioni durante questa fase e in caso un test dovesse fallire, ne devono essere documentati i motivi. La procedura di testing deve continuare come pianificato e in caso di fallimento di un test devono essere ricondotti i test in questione dallo stesso esaminatore. Figura 3.5.2: Esempio di esecuzione delle attività di testing 95

96 6. Valutazione dei criteri di uscita e report 7. Chiusura dei test e pulizia Al fine di prevenire errori e problemi, è importante che l ambiente di test venga reinizializzato al termine della fase di testing. 3.5.f Punti di partenza, input e output, interfacciamento inter-processo Il punto di partenza per la fase di testing è un piano di release, un piano di test o un piano di quality assurance schedulato. Input Il service package; Uno o più SLP; Definizioni di Service Provider Interface; Il Service Design Package; Piani di release e deployment; Criteri di accettabilità; RFC. Output L input principale della fase di testing è il report di valutazione del servizio, comprendente: Configurazione dell ambiente di testing; Test eseguiti; Risultati di questi test; Analisi dei risultati. Una volta che il servizio sia stato in produzione per un tempo adeguato, è possibile stilare delle valutazioni sulle prestazioni pianificate contro quelle effettive: se questa valutazione è positiva verrà inviato un report di valutazione al Change Management con raccomandazione di promozione del servizio. 3.5.g Key Performance Indicator (KPI) L efficacia della procedura di testing nei confronti del business è calcolata grazie a: 96

97 Riduzione dell impatto che hanno incidenti ed errori nell ambiente di produzione causati da nuovi servizi; Uso più efficiente di risorse; Riduzione dei ritardi nella fase di testing che possano avere un impatto sul business; Chiara comprensione di ruoli e responsabilità tra clienti, utenti e fornitori di servizi. 3.5.h Sfide, fattori critici di successo e rischi Attualmente, i maggiori ostacoli per un testing efficiente sono la mancanza di rispetto e comprensione per il ruolo fondamentale che ha il testing, spesso oggetto di scarsi finanziamenti. 3.6 Evaluation Il processo di Evaluation è un processo generico che valuta se le prestazioni di un qualcosa siano accettabili, convenienti, ecc., e, in seguito, se sia stato portato in produzione, ecc a Finalità, traguardi, obiettivi Finalità La finalità è fornire parametri consistenti e standardizzati per determinate le prestazioni di un cambiamento di servizio in un contesto di servizi e infrastruttura IT preesistenti. Le prestazioni effettive vengono confrontate con quelle previste e qualsiasi discrepanza viene valutata e gestita. Traguardo Il traguardo di questo processo è di dimensionare correttamente le aspettative degli stakeholder e fornire informazioni efficaci e accurate al Change Management per far sì che cambiamenti che potrebbero compromettere le capacità del servizio o introdurre rischi non vengano eseguiti senza controlli. 97

98 Obiettivi Valutare gli effetti voluti di una transizione e quantificare quanti non voluti sono effettivamente accettabili; Fornire output dalla valutazione dei processi in modo da permettere al Change Management di stabilire se una transizione è praticabile o meno. 3.6.b Prospettive In questa sezione consideriamo la valutazione dei nuovi servizi definiti dal Service Design durante lo sviluppo e prima della transizione finale nell ambiente operativo. L importanza di questo processo è di assicurare che le aspettative poste siano realistiche e identificare quali eventuali motivi hanno portato le prestazioni fuori dai target fissati. 3.6.c Valore per il business Una valutazione efficace permette di stabilire che uso viene fatto delle risorse in termini di benefici ottenuti da un servizio: questi dati permettono a loro volta di ottenere informazioni utili a future transizioni e al Change Management. 3.6.d Criteri, principi e concetti di base Criteri Il Service Design o i cambiamenti ai servizi verranno valutati prima di essere eseguiti; Qualsiasi discostamento tra le prestazioni previste e quelle effettive verrà gestito dal cliente accettando la transizione anche se le prestazioni sono discordanti. Principi Gli effetti previsti e non previsti di una transizione devono essere identificati e le loro conseguenze considerate; Una transizione di un servizio deve essere valutata in maniera consistente, aperta e obiettiva. 98

99 3.6.e Attività, metodi e tecniche per i processi Processo di valutazione Figura 3.6.1: Processo di valutazione 99

100 Piano di valutazione La valutazione di una transizione dovrebbe essere effettuata da diverse prospettive per far sì che qualsiasi effetto non previsto sia compreso completamente. Naturalmente quello che ci si vorrebbe aspettare da una transizione sono solo effetti benefici, mentre quelli non voluti sono spesso difficili da predire e spesso non visti anche quando il servizio è in produzione e quindi ignorati. Inoltre, spesso possono danneggiare altri servizi o gli utenti del servizio. Comprendere gli effetti previsti di una transizione La documentazione della transizione deve stabilire chiaramente quali sono gli effetti previsti, in modo che sia possibile determinarne l efficacia. Comprendere gli effetti non previsti di una transizione In aggiunta agli effetti previsti possono essercene di non previsti: il modo più efficace di identificarli è discuterne con i clienti, con gli utenti del servizio e con coloro che lo mantengono. Valutazione delle prestazioni previste Grazie ai dati raccolti dai requisiti dei clienti, dalle prestazioni previste e dal modello di prestazioni, viene generata una valutazione dei rischi, che se suggerisce che le prestazioni previste possono creare rischi non accettabili o non soddisfano gli Acceptance Criteria, viene inviato al Change Management un report della valutazione. Valutazione delle prestazioni effettive Una volta che la transizione è stata implementata, viene generato un report sulle prestazioni effettive. Usando i requisiti degli utenti, le prestazioni attuali e il modello di prestazioni, viene generata una valutazione dei rischi, che se suggerisce che le prestazioni attuali possono creare rischi non accettabili o non soddisfano gli Acceptance Criteria, viene inviato al Change Management un report della valutazione. Risk Management Vi sono due step previsti dal Risk Management: valutazione del rischio e mitigazione. Un rischio occorre quando una minaccia può sfruttare una debolezza: la possibilità che una minaccia sfrutti una falla di sistema, e l impatto che questo può avere, sono fattori fondamentali nella determinazione del fattore di rischio. 100

101 Naturalmente, l introduzione di nuove minacce o falle di sistema aumenta il fattore di rischio: aumentare le dipendenze verso altri servizi o componenti aumenta l impatto che può avere un exploit sul sistema. È un chiaro requisito che una proposta di transizione deve valutare i rischi esistenti e quelli previsti dopo la sua implementazione. Se il fattore di rischio è aumentato, allora il secondo stadio del Risk Management viene usato per mitigare questo rischio. Dopo questa operazione il fattore di rischio viene ricalcolato e viene valutato il rischio residuo ciclicamente sinché esso non viene portato a livelli ritenuti accettabili. Il concetto è quindi ottenere un fattore di rischio minore rispetto a quello originario. Variazione tra le prestazioni previste e quelle effettive Una volta che il servizio ha passato la valutazione delle prestazioni previste e quelle effettive, viene effettuata una comparativa tra i due dati e l output di questa attività è un Deviation Report. 3.6.f Punti di partenza, input e output, interfacciamento inter-processo Punti di partenza: Input: Richiesta di Evaluation da parte del responsabile del Service Transition o dal Change Management; Piano di Activity o Project. Service package; SDP e SAC; Risultati e report dei test. Output: Report di valutazione per il Change Management. 101

102 3.7 Knowledge Management La possibilità di fornire un servizio o processo di qualità dipende per larga parte dall abilità delle persone in esso coinvolte di rispondere alle circostanze, che a sua volta dipende per larga parte dalla loro consapevolezza della situazione: la gestione delle conoscenze assume dunque un ruolo chiave nei processi di transizione. 3.7.a Finalità, traguardi, obiettivi Finalità La Finalità del Knowledge Management è di assicurare che le giuste informazioni siano recapitate al posto o alla persona competente corretta al momento giusto. Traguardo Il traguardo del Knowledge Management è di permettere alle organizzazioni di migliorare la qualità della gestione assicurando che le informazioni appropriate siano disponibili durante il ciclo di vita del servizio. Obiettivi Permettere al fornitore del servizio di essere più efficiente, migliorare la qualità del servizio, aumentare la soddisfazione dei clienti e ridurre il costo del servizio; Assicurare che lo staff abbia chiara comprensione del valore che i propri servizi forniscono ai clienti; Assicurare che lo staff del fornitore del servizio abbia le informazioni necessarie al giusto momento. 3.7.b Prospettive Il Knowledge Management è un processo presente in tutto il ciclo di vita e relativo ad ogni settore, e dunque vi sono riferimenti ad esso in tutta la documentazione ITIL; in questo capitolo verrà analizzato da un punto di vista del Service Transition. 102

103 3.7.c Valore per il business Il Knowledge Management assume particolare importanza all interno del Service Transition, dal momento che il know-how è uno degli elementi chiave di un servizio. Il Knowledge Management è una risorsa fondamentale per le persone coinvolte in qualsiasi ruolo all interno di tutti gli stadi del ciclo di vita di un servizio. È un ottimo metodo per singoli individui e gruppi di condividere dati, informazioni e conoscenze circa tutte le sfaccettature di un servizio IT. 3.7.d Criteri, principi e concetti di base La struttura Data-to-Information-to-Knowledge-to-Wisdom Il Knowledge Management è tipicamente visualizzato all interno della struttura Data-toun insieme di fatti circa alcuni eventi. La maggior parte delle organizzazioni memorizza grosse moli di dati in database altamente strutturati. Information-to-Knowledge-to-Wisdom (DIKW): Data: è Information: consiste nel fornire un contesto ai dati di cui sopra. È normalmente memorizzata come contenuti semi strutturati, documenti, e file multimediali. Knowledge: è composta da esperienze, idee, visioni, valori e pensieri di singoli individui. Le persone acquisiscono esperienza sia per proprio conto, sia grazie alle esperienze di altre persone. Dalla sintesi di questi elementi si crea nuova conoscenza. Wisdom: fornisce il discernimento finale del materiale. Figura 3.7.1: Il percorso da Data a Wisdom 103

104 Service Knowledge Management System All interno dell IT Service Management, il Service Knowledge Management System (SKMS) gestisce il considerevole quantitativo di dati del Knowledge Management. 3.7.e Attività, metodi e tecniche per il processo Strategia di Knowledge Management Una strategia generale per il Knowledge Management è necessaria: ovunque vi sia un approccio al Knowledge Management, le iniziative all interno del Service Transition o IT Service Management dovrebbero essere sviluppate per rientrare all interno dell approccio organizzativo generale. In assenza di un approccio organizzativo al Knowledge Management, sono richiesti appropriati step per stabilire il Knowledge Management all interno del Service Transition o IT Service Management, ma anche in questo caso lo sviluppo dovrebbe essere sempre stabilito con una visione il più ampia possibile su di esso. Trasferimento delle conoscenze Durante il ciclo di vita di un servizio le necessità di un organizzazione devono focalizzarsi sulla raccolta, condivisione e uso delle proprie conoscenze; per poter raggiungere questo risultato, il know-how deve poter essere trasferito da un punto ad un altro dell organizzazione in specifici punti del ciclo di vita del servizio. La sfida è spesso il problema pratico di trasportare un pacchetto di Knowledge da una parte all altra dell organizzazione. Naturalmente non è semplice come l invio di una , ma si può in effetti definire come l attività attraverso la quale un unità è condizionata dall esperienza di un altra. Normalmente il trasferimento di conoscenze è basato sul modello di lezioni tenute in aula; in molti casi il training iniziale è fornito a un rappresentante del gruppo di lavoro, che dovrà a sua volta trasferire le nozioni apprese ai colleghi. Gestione di dati e informazioni Una gestione efficiente dei dati e delle informazioni permette di ottenere: Conformità con i requisiti legali, le politiche aziendali, i codici di condotta professionale, ecc.; 104

105 Forme di visualizzazione di dati ed informazioni in uno stile facilmente usabile dall organizzazione; Dati ed informazioni correnti, completi e validi; Dati ed informazioni eliminabili su richiesta; Dati ed informazioni ottenibili da chi e quando ne ha bisogno. Stabilire i requisiti per i dati e le informazioni Spesso dati ed informazioni sono raccolti senza una chiara comprensione di come verranno utilizzati e dei costi che comporteranno. Efficienza ed efficacia sono ottenibili solo stabilendo dei chiari requisiti per le informazioni, tra cui: Stabilire le tipologie di dati da raccogliere, il loro contenuto e la loro forma, assieme al motivo per la loro raccolta; Incoraggiare l utilizzo di contenuti comuni ed uniformi e formati standard, in modo da garantire una più facile consultazione e comprensione del contenuto; Stabilire i requisiti per la protezione dei dati, la privacy, la sicurezza, le restrizioni e i permessi di accesso, le proprietà intellettuali e i brevetti con gli stakeholder di rilievo; Definire chi necessita l accesso a quali dati ed informazioni, oltre a quando questi dati possono essere acceduti. Considerare qualsiasi cambiamento al processo di Knowledge Management attraverso il Change Management. Definire l architettura delle informazioni Al fine di poter usufruire in maniera efficace delle informazioni raccolte, in termini di diffusione dei concetti memorizzati, l architettura deve ricalcare la situazione e i requisiti delle informazioni: Creando e aggiornando regolarmente il modello di informazioni del Service Management; Definendo sistemi che ottimizzino l uso delle informazioni, mantenendo l integrità delle informazioni; Adottando schemi di classificazione dei dati che siano in uso in tutta l organizzazione. 105

106 Figura 3.7.2: Service Knowledge Management System Stabilire le procedure di gestione dei dati e delle informazioni Una volta che i requisiti e l architettura sono fissati, può essere stabilita la gestione dei dati e informazioni per supportare il Knowledge Management. I passi chiave sono: Identificare il ciclo di vita del servizio e i dati e le informazioni da raccogliere; Definire la procedura richiesta per mantenere i dati e le informazioni e renderli disponibili a chi li richiede; Stabilire autorità e responsabilità per tutti gli elementi di informazione ne richiesti; Stabilire procedure di backup e recovery dei dati e delle informazioni memorizzate. Una volta che le procedure sono designate, promulgate ed accettate, l organizzazione può: Implementare meccanismi di cattura, memorizzazione e lettura dei dati dalle sorgenti; Gestire la memorizzazione dei dati e delle informazioni in linea con la legislatura in vigore; Archiviare le informazioni designate, in accordanza con i piani di gestione di dati e informazioni. 106

107 Valutazione e miglioramenti Così come con tutti i processi, anche la cattura e gestione delle informazioni per supportare il Knowledge Management può essere oggetto di miglioramenti da parte del Service Improvement Plan. 3.7.f Punti di partenza, input e output, interfacciamento inter-processo Uno dei punti critici del Knowledge Management è assicurare che i benefici derivanti da un suo corretto utilizzo siano chiaramente compresi e abbracciati all interno dell intera organizzazione. Nello specifico, l efficacia del Knowledge Management è in parte dovuta al supporto di tutti colore che operano all interno dell IT Service Management. 3.7.g Key Performance Indicator (KPI) Ridotto numero di errori relativi al processo di Knowledge Management; Migliore risposta ai cambi di necessità del business; Migliore accessibilità e gestione di standard e policy; Diffusione di conoscenze; Minor tempo necessario per supportare e mantenere i servizi; Minor tempo necessario per trovare informazioni utili alla risoluzione di errori; Minor dipendenza verso il personale per il know-how. 107

108 CAPITOLO 4 Implementazione del Service Transition Implementare il Service Transition da zero può essere conveniente solo in caso sia stabilito un nuovo service provider; conseguenza di ciò è che il compito per la maggior parte delle organizzazioni sarà di miglioramento del servizio, ovvero adattare l attuale approccio ai processi di Service Transition e stabilire i miglioramenti da intraprendere, dando priorità alle necessità del business. Figura 4.1: Passi per migliorare i processi di Service Transition 108

109 Introdurre nuovi processi di Service Transition, o modificarne di esistenti, comporta significativi cambiamenti organizzativi e l introduzione di servizi più evoluti. Proprio per questi motivi, la maggior parte dei suggerimenti di questa pubblicazione è direttamente applicabile all introduzione del Service Transition stesso. 4.1 Fasi dell introduzione del Service Transition 4.1.a Giustificare il Service Transition Il Service Transition gioca un ruolo chiave nella capacità del service provider di fornire servizi di qualità al business. Tuttavia, i processi di Service Transition non sempre sono visibili ai clienti e questo può rendere difficile giustificare le spese. Quando viene pianificato il Service Transition bisogna quindi porre particolare attenzione a quantificare e misurare i benefici, normalmente una giusta via di mezzo tra l impatto sul business (sia negativo che positivo) e i costi. 4.1.b Progettare il Service Transition I fattori da considerare durante la progettazione del Service Transition comprendono: Standard e criteri applicabili Relazioni Altri servizi di supporto interni In molte occasioni il Service Transition deve collaborare con altre aree che effettuano transizioni di altri elementi del business change: i processi devono essere progettati in modo da facilitare queste relazioni. Gestione del programma e del progetto Per assicurare che il processo di transizione vada a buon fine, lo staff del Service Transition deve assegnare timeline e milestone dei programmi e progetti chiave. Affinché sia efficace e permetta l uso ottimale delle risorse, il Service Transition deve avere una vista dall alto di progetti, combinazioni di transizioni e release. 109

110 Gruppi di sviluppo interni e fornitori esterni Clienti e utenti La comunicazione con clienti e utenti è di vitale importanza per assicurare che il nuovo servizio rimanga incentrato sui requisiti del business corrente. I requisiti identificati durante la fase di design posso evolversi durante il processo di transizione e i canali di comunicazione con i clienti sono il metodo migliore per identificare questi cambiamenti. Altri stakeholder Altri stakeholder possono avere la necessità di interfacciarsi con il Service Transition e devono essere identificati per ogni eventuale futura circostanza. Budget e risorse Le azioni richieste per poter attuare il Service Transition porteranno a un tangibile beneficio per l organizzazione, ma tuttavia richiedono degli investimenti, ed è compito del Service Transition gestire la sorgente di queste risorse finanziarie. Approccio ai finanziamenti È necessario approntare un meccanismo per controllare i fondi per l infrastruttura necessaria alla transizione, includendo: Ambienti di testing: in molte organizzazione i gruppi di testing non sono sotto il controllo diretto della transizione; le relazioni e l autorità per allocare le risorse necessarie devono essere stabilite, comprese, mantenute e gestite; SCM e Service Knowledge Management System: queste entità richiedono specificatamente risorse finanziarie essenziali per la loro efficacia. Il costo della transizione deve essere parte integrante della progettazione: questo si applica qualsiasi sia il meccanismo di gestione dei fondi. Risorse Similarmente ai problemi incontrati durante le considerazioni sui fondi, l approvvigionamento e il controllo delle risorse deve essere gestito all interno della strategia di Service Transition La gestione dell ambiente di testing è oggetto di grandi investimenti e un elemento significante all interno di molte organizzazioni: una carenza di fondi o risorse destinati all ambiente di testing può causare errori e problemi, fonti di perdite economiche ed effetti disastrosi sulle capacità di business dell organizzazione. 110

111 4.2 Aspetti del cambio culturale Persino la formalizzazione di procedure per la maggior parte già esistenti porta ad un cambio culturale; se l implementazione del Service Transition all interno di un organizzazione porta ad installare processi che non erano presenti prima, il cambio culturale sarà significativo. L esperienza mostra come lo staff che lavora nel Change Management è potenzialmente resistente a cambiamenti nelle sue stesse aree come nessun altro. Anche se è di primaria importanza che lo staff che lavora direttamente nel Service Transition lo supporti, è ugualmente importante che chi supporta o è supportato dal Service Transition comprenda perchè i cambiamenti abbiano luogo e i benefici che ne derivano da questi. Il programma di cambio culturale deve far comprendere agli stakeholder, prima e durante la transizione, i vantaggi della procedura, evitando che venga vista come un accessorio inutile da dimenticare dopo i primi momenti. 4.3 Rischi e benefici Così come con tutte le transizioni, le decisioni su come effettuare la transizione non devono essere prese senza un adeguata comprensione dei rischi e dei benefici previsti. In questa specifica situazione i rischi possono comprendere: Alienazione dello staff di supporto; Costi per il business eccessivi; Ritardi inaccettabili per i benefici al business. I rischi e i benefici richiedono una linea guida della situazione corrente. I valori da considerare possono includere: Grado di soddisfazione di clienti e utenti; Ridotto tasso di incidenti e fallimenti; Ridotto costo di transizione. 4.4 Sfide La complessità dei servizi lungo la catena di distribuzione è in continuo aumento e questo porta a sfide sempre più ardue per i fornitori di servizi che implementino nuovi servizi o ne modifichino di esistenti. 111

112 Alcune di queste sfide per ottenere un Service Transition di successo sono: Gestire molti contatti, interfacce e relazioni attraverso il Service Transition; Raggiungere un bilanciamento tra mantenere un ambiente di produzione stabile ed essere veloci ad implementare i cambiamenti richiesti dal business; Raggiungere un bilanciamento tra praticità e burocrazia; Creare un ambiente che favorisca standardizzazione, semplificazione e scambio di conoscenze; Sviluppare una cultura che incoraggi le persone a collaborare e lavorare efficacemente assieme; Stabilire chi fa cosa, quando e dove e chi dovrebbe fare cosa, quando e dove ; Sviluppare metodologie standard per la misurazione delle prestazioni; Assicurarsi che la qualità del servizio e del supporto sia dimensionato all uso da parte del business della nuova tecnologia; Capire ed essere in grado di valutare il bilanciamento tra quali rischi affrontare e quali invece gestire e prevenire. 4.5 Fattori critici di successo Gestire i contatti e mantenere le relazioni durante il Service Transition; Integrarsi con gli altri stadi del loro ciclo di vita del servizio che possono avere un impatto sul Service Transition; Automatizzare i processi per ridurre i tempi e diminuire gli errori; Creare e mantenere nuove conoscenze in un format comprensibile e gestibile da altre persone; Sviluppare sistemi, strumenti, processi e procedure di buona qualità; Essere in grado di comprendere le configurazioni del servizio e le loro dipendenze; Comprendere i processi e le procedure, le competenze e le capacità per gestire una pratica di Service Transition; Comprendere i rischi che hanno condizionato un Service Transition di successo; Essere in grado di comunicare la disponibilità dell organizzazione a correre dei rischi e l approccio alla loro gestione in maniera più efficace durante le attività di Service Transition; Ottenere una maggior soddisfazione i clienti e utenti durante il Service Transition; Dimostrare che i benefici di un Service Transition migliorato superano i costi e le difficoltà per ottenerlo. 112

113 CONCLUSIONI Molte organizzazioni vedono ancora l IT Service Management come un problema prevalentemente tecnico: ITIL promuove un approccio più vicino al business e agli utenti e clienti dei servizi, scalzandolo dalla classica visione di contenitore di tecnologia, oscuro ed isolato. Il focus dell IT Management è in continuo mutamento e nel futuro sarà sempre meno incentrato sulla tecnologia e sempre più volto ai bisogni del business: il framework ITIL crea delle solide basi per adottare pratiche e metodologie che siano focalizzate sulle necessità del business e dei processi. Questa pubblicazione è parte della documentazione ITIL, volta a fissare le linee guida per le organizzazioni che riconoscano l importanza del Service Management per il loro successo. Queste linee guida, tuttavia, da sole non sono sufficienti, ma vanno interpretate all interno del contesto dell organizzazione che le intenda seguire. I manager del servizio IT devono gestire i servizi secondo la propria concezione di priorità: per alcuni sarà la sicurezza, per altri la velocità, per altri ancora l usabilità. Implementare un Service Transition efficace è una sfida per tutti e prevede una piena comprensione dei suoi principi, del business supportato e dei servizi introdotti, cambiati o dismessi. Questa pubblicazione è stata scritta per fornire delle fondamenta ai professionisti ITSM per implementare servizi solidi ed efficaci che possano supportare a lungo termine i propri clienti nel loro business. La completa adozione di queste pratiche all interno delle organizzazioni non potrà far altro che creare una maggiore sinergia tra business e IT, attualmente separati da un muro di incomprensione e incomunicabilità, fonte di perdite in termini economici, funzionali e di tempo. Attraverso lo sviluppo ed il successivo mantenimento dei processi di ITIL v3, un organizzazione sarà in grado di ottenere un chiaro vantaggio competitivo rispetto alle concorrenti, fonte di ingenti benefici di natura economica e strategica. 113

114 BIBLIOGRAFIA Office of Government Commerce IT Service Management (ITSM) ITIL V3 ITIL V3 Service Transition URL: ITIL, Italia ITIL v3 ITIL v2 ISO URL: itsmf International An Introductory Overview of ITIL v3 URL: itsmf Italia IT Service Management Forum ITIL URL: Wikipedia Information Technology Infrastructure Library ITIL URL: Information_Technology_Infrastructure_Library Wikipedia Italia Information Technology Infrastructure Library ITIL URL: Matteo Mazzotti ITILv3 ITIL Service Design URL: Images Courtesy of ITIL, Office of Government Commerce 114

115 RINGRAZIAMENTI I miei ringraziamenti vanno a tutti coloro che mi sono stati vicino in questo lungo e faticoso percorso, e in particolar modo: Al Prof. Egidio Astesiano e all Ing. Stefano Bencetti, per avermi seguito nella redazione di questa Prova Finale con disponibilità, pazienza, cortesia e professionalità; Alla mia famiglia, che mi ha supportato e spronato con amore costantemente in questi anni, che ha sopportato le delusioni e festeggiato con me gli avvenimenti piacevoli, che ha creduto in me e alla quale devo tutto; A lei, che ha saputo cogliere anche quella parte di me nascosta dallo stress dello studio, che mi ha supportato e sopportato in tante occasioni, che mi ha sempre circondato di amore e felicità e che mi sta regalando tra i momenti più felici della mia vita; Ai miei amici, preziosi e insostituibili compagni che, chi dandomi un esempio da seguire, chi standomi vicino durante le immancabili delusioni, chi offrendomi aiuto e chi piacevoli distrazioni, mi hanno accompagnato in questi anni e spero nei futuri. Vorrei tuttavia dedicare in particolare questo risultato alla mia defunta nonna, che ricordo quotidianamente con estremo affetto e nostalgia, e che tanto ha desiderato di vedere questo momento e con mio estremo rimpianto non sono stato in grado di regalargli in tempo. Grazie a tutti, Mario Zelaschi 115