Analisi e riprogettazione del processo Software Change Management attraverso l'utilizzo del Framework ITIL Service Transition

(1)

Facoltà di Ingegneria

CORSO DI LAUREA IN INGEGNERIA INFORMATICA

PER LA GESTIONE D’AZIENDA

TESI DI LAUREA

ANALISI E RIPROGETTAZIONE DEL PROCESSO

DI SOFTWARE CHANGE MANAGEMENT

ATTRAVERSO L’UTILIZZO DEL FRAMEWORK

ITIL

Candidato:

Pierluigi Dell’Arciprete

Relatori

Prof. Gigliola Vaglini

Prof. Mario G.C.A. Cimino

Dott. Matteo Fossi

(2)

(3)

1

1. Riassunto

In questo elaborato viene descritta l’analisi e la riprogettazione di un processo di supporto al business di una realtà aziendale di respiro internazionale. Il processo preso in esame è quello del Change Management, ovvero, un sotto-processo dell’IT Service Management che ha il compito di gestire qualsiasi tipo di cambiamento a livello di infrastruttura IT. Anche se declassato a semplice processo di supporto, esso ha un ruolo fondamentale e delicato, poiché, inevitabilmente, va a toccare in modo trasversale tutti i processi di business incidendo in maniera tranchant sulla loro produttività.

L’intera analisi è stata svolta attraverso un contatto diretto, della durata di sei mesi, con le dinamiche interne all’azienda. Questa esperienza ha permesso di conoscere la struttura organizzativa e di analizzare in maniera approfondita le procedure aziendali, i workflow operativi e le metriche di processo utilizzate.

Nella fase di riprogettazione si è sfruttato il supporto del Framework ITIL. La nuova designazione ha comportato l’introduzione di nuove figure all’interno del processo, di nuove procedure, nuovi workflow operativi, quindi, nuove metriche di processo al fine di migliorare l’efficienza e l’efficacia del processo di “Change”.

(4)

2

2. Sommario

1. Riassunto ... 1

2. Sommario ... 2

3. Indice delle figure ... 7

4. Indice delle tabelle ... 8

5. Introduzione ... 9

6. La realtà Aziendale ... 12

6.1. Arval Service Lease Italia S.p.a... 12

6.2. I processi Arval ... 13 6.3. IT Service Organization ... 14 6.4. Servizi IT ... 15 Software Services ... 16 6.4.1. 6.4.1.1. Service Catalogue ... 16 7. Analisi di Processo ... 27

7.1. Oggetto e Campo di Applicazione ... 27

7.2. Glossario ... 27

7.3. Funzioni Coinvolte ... 28

7.4. Attori del processo ... 28

7.5. Descrizione generale del Processo ... 29

7.6. Descrizione Attività ... 30

7.7. Mappatura del processo ... 33

7.8. Workflow Operativo ... 34

7.9. Risorse impiegate nel processo ... 35

Risorse Umane ... 35

7.9.1. Area di lavoro ... 35 7.9.2.

(5)

3

Postazione di lavoro ... 36

7.9.3. 7.10. Dati di Processo... 37

Tempi delle attività di processo ... 38

7.10.1. Rapporto input/output di processo ... 40

7.10.2. Le dimensioni dei “Change” ... 42

7.10.3. 7.11. Problematiche evidenziate dagli attori del processo ... 44

Utenti ... 44

7.11.1. Assistenza di primo livello ... 44

7.11.2. Analista ... 44 7.11.3. Responsabile IT... 45 7.11.4. Tester ... 45 7.11.5. Coordinatore Produzione ... 45 7.11.6. 7.12. Conclusione Analisi ... 45 8. ITIL ... 47 8.1. Perché ITIL ... 47 CMMI ... 47 8.1.1. COBIT ... 49 8.1.2. La scelta ITIL ... 50 8.1.3. 8.2. Cos’è il framework ITIL ... 51

Storia di ITIL ... 51 8.2.1. 8.3. ITIL v3 ... 53 Service Strategy ... 54 8.3.1. Service Design ... 56 8.3.2. Service Transition ... 58 8.3.3. Service Operation ... 61 8.3.4. 8.4. Change Management ... 62

(6)

4

Obiettivi ... 62

8.4.1. Elementi Chiave e Attori ... 64

8.4.2. Il Processo nel dettaglio ... 66

8.4.3. Relazioni con gli altri processi ITIL ... 71

8.4.4. 8.5. ITIL e la ISO/IEC 20000 ... 73

9. Riprogettazione del processo ... 75

9.1. Obiettivi e Benefici ... 75

9.2. Glossario ... 76

9.3. Ruoli di governo del processo ... 77

Change Manager ... 77 9.3.1. Change Coordinator ... 77 9.3.2. Gruppo di Supporto ... 78 9.3.3. Change Initiator ... 78 9.3.4. 9.3.4.1. Responsanbilità del Change Initator ... 78

9.4. Definizione diverse categorie di Change ... 79

Major ... 79 9.4.1. Significant ... 79 9.4.2. Minor... 79 9.4.3. Standard ... 80 9.4.4. Emergency ... 80 9.4.5. Bug ... 80 9.4.6. Update ... 81 9.4.7. 9.5. Change Ownership ... 81

Ruolo dell’owner della richiesta ... 81

9.5.1. Categoria del Change come criterio di assegnazione della Ownership ... 81

9.5.2. 9.6. Change Advisory Board... 82

(7)

5 Ruolo del Change Advisory Board ... 82 9.6.1.

Composizione del Change Advisory Board ... 83 9.6.2.

Modalità e contenuti dei CAB meetings ... 83 9.6.3.

9.7. Change Approval Authority ... 84 Ruolo della Change Approval Authority ... 84 9.7.1.

Categorie del Change come Criterio di assegnazione del ruolo di Change 9.7.2.

Approval Authority (CAA) ... 85 Delega della Change Authority ... 85 9.7.3. 9.8. Assessment Team ... 86 Nomina e Composizione ... 86 9.8.1. Ruolo ... 86 9.8.2.

9.9. Development e Release Management Team ... 87 Nomina e Composizione ... 87 9.9.1.

Ruolo ... 87 9.9.2.

9.10. Overview ruoli e responsabilità di gestione del Change. ... 88 9.11. Classi di priorità del Change ... 89 La Priorità ... 89 9.11.1.

Le classi di Priorità ... 89 9.11.2.

9.12. Tabella delle Priorità del Change ... 90 9.13. Mappature del processo. ... 91 Overview del processo ... 91 9.13.1.

Creazione e Verfica RFC ... 94 9.13.2.

Normal Change Management ... 95 9.13.3.

Standard Change Management ... 98 9.13.4.

Emergency Change Management ... 99 9.13.5.

Revisione e Chiusura RFC ... 101 9.13.6.

(8)

6

9.14. Procedure operative ... 103

9.15. Definizione delle metriche ITSM ... 108

Key Process Indicator (KPI) ... 108

9.15.1. Tabella KPI value range ... 110

9.15.2. 9.15.2.1. Change Major e Significant ... 110

9.15.2.2. Change Minor, Bug e Update ... 110

9.15.2.3. Standard Change ... 110

9.15.2.4. Emergency Change ... 111

Critical Success Factors (CSF) ... 111

9.15.3. 10. Risultati ... 112

11. Conclusioni ... 115

(9)

7

3. Indice delle figure

Figura 1 IT Service Management ... 10

Figura 2 I Processi Arval ... 13

Figura 3 Organizzazione Gerarchica IT Service ... 14

Figura 4 Servizi Informatici ... 15

Figura 5 Software Services ... 16

Figura 6 Mappatura Processo "As Is" ... 33

Figura 7 Workflow Operativo Processo "As Is" ... 34

Figura 8 Area di lavoro ... 36

Figura 9 Postazione di lavoro ... 37

Figura 10 Sorgente dei dati di processo ... 37

Figura 11 ciclo di vita del servizio ITIL ... 54

Figura 12 Service Transition ... 59

Figura 13 Change Management - Attività ... 67

Figura 14 Change Management – Proposta ... 68

Figura 15 Change Management – Approvazione ... 69

Figura 16 Change Management – Esecuzione... 70

Figura 17 Overview del processo ... 91

Figura 18 Creazione e Verifica RFC ... 94

Figura 19 Normal Change Management ... 96

Figura 20 Standard Change Management ... 98

Figura 21 Gestione Change Model Catalogue ... 99

Figura 22 Emergency Change Management ... 100

Figura 23 Revisione e Chiusura Change ... 101

Figura 24 Worflow Standard Change ... 103

Figura 25 Workflow Emergency Change ... 104

Figura 26 Workflow Major Change... 105

Figura 27 Workflow Minor Change ... 106

(10)

8

4. Indice delle tabelle

Tabella 1 Tempi medi delle singole attività di processo ... 39

Tabella 2 Gap Input/Output di processo ... 41

Tabella 3 Riclassificazione delle RDC ... 43

Tabella 4 Overview Ruoli e Responsabilità di gestione ... 88

Tabella 5 Tabella delle Priorità ... 90

Tabella 6 KPI range per Change Major e Significant... 110

Tabella 7 KPI range per Minor, Bug e Update ... 110

Tabella 8 KPI range per Standard Change ... 111

Tabella 9 KPI range Emergency Change ... 111

Tabella 10 Tempi attività nuovo processo ... 112

Tabella 11 Rapporto O/I di Processo ... 113

(11)

9

5. Introduzione

Come sappiamo oggigiorno l’IT svolge spesso un ruolo centrale nel supportare le organizzazioni a fornire prodotti ed erogare servizi ai propri clienti: molte organizzazioni dipendono dall’IT, la maggior parte non potrebbe operare efficacemente senza e molte altre non potrebbero nemmeno esistere. E’ per questo motivo che diventa importante la sua gestione.

L’IT Service Management è la disciplina che si occupa della gestione di sistemi di Information Technology su larga scala, filosoficamente concentrata sulla prospettiva del cliente e del contributo dell'IT al business. ITSM è incentrata sui processi ed in questo senso ha legami ed obiettivi comuni con altre discipline, framework e metodologie incentrate sul miglioramento dei processi (es. TQM, Six Sigma, Business Process Management, CMMI). 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, clienti e utilizzatori. Una delle classiche affermazioni che troviamo in letteratura quando si parla di ITSM asserisce che:

“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.”

(1) Il framework IT Infrastructure Library (ITIL) riassume l’intero ciclo di vita del servizio IT con lo schema circolare che vediamo in Figura 1, vediamo come tutto ruota attorno alla Service Strategy e come il servizio sia in continua evoluzione e miglioramento. Si alternano, infatti, tre fasi in maniera continuativa:

 Service Design: ovvero la fase di progettazione di servizi nuovi o di modifiche di

(12)

10

 Service Transition: ovvero la fase in cui vengono installati i nuovi servizi o gestiti i

cambiamenti di quelli esistenti;

 Service Operation: ovvero la fase di monitoraggio del servizio durante la sua

normale erogazione.

Figura 1 IT Service Management

A loro volta ognuna di queste macrofasi comprende un insieme di sotto processi che li caratterizzano. Il sotto processo che andremo ad analizzare in maniera più dettagliata in questo elaborato è quello del Change Management, un sotto-processo della Service Transition.

Il processo di Change Management si interessa di gestire i cambiamenti. Come da definizione ITIL:

(13)

11

“il cambiamento è l’aggiunta, la modifica o la rimozione di qualsiasi cosa che potrebbe avere un effetto sul servizio IT”

(2) Tali cambiamenti possono essere: la conseguenza di una reazione attuata in risposta ad un problema, imposti esternamente (ad es. cambiamenti legislativi), realizzati proattivamente per cercare di raggiungere livelli imposti di efficienza ed efficacia, per attuare iniziative a supporto del business, o ancora da programmi, progetti o iniziative per il miglioramento dei servizi.

Gli obiettivi che si prefigge il processo Change Management sono:

 Rispondere alle mutevoli esigenze di business del cliente, massimizzando il valore e riducendo gli incidenti, le interruzioni del servizio e le rilavorazioni;

 Rispondere alle richieste di cambiamento del business e dell’IT che allineano i servizi con le necessità del business;

 Assicurare che i cambiamenti siano registrati e valutati e che i cambiamenti autorizzati siano prioritizzati, pianificati, testati, implementati, documentati e riesaminati in modo controllato;

 Ottimizzare i rischi complessivi del business.

Sulla base di queste definizioni ci addentreremo nell’analisi di un caso aziendale, quello dell’Arval Lease Italia S.p.a., un’organizzazione che attualmente eroga dei servizi IT e che avrebbe l’ambizione di riorganizzare i suoi processi aderendo a quelle che sono le “Buone Pratiche” descritte da ITIL.

L’obiettivo di questo elaborato è quello di analizzare l’attuale processo di Gestione del cambiamento ed evidenziarne eventuali debolezze o criticità, quindi riprogettare il processo in conformità con le prescrizioni ITIL, garantendo allo stesso tempo un non abbassamento delle performance ed il superamento di eventuali criticità evidenziate in analisi.

(14)

12

6. La realtà Aziendale

6.1. Arval Service Lease Italia S.p.a

Arval, società del gruppo bancario BNP Paribas, è leader in Italia nel noleggio auto a lungo termine e nella gestione delle flotte aziendali. Arval è presente in 22 nazioni europee, in Marocco, Brasile, Messico, India e riesce comunque a toccare i 5 continenti grazie ad accordi di partenership.

L’Arval Service Lease Italia S.p.a nonostante sia tenuta a rispettare le linee guida imposte della casa madre francese mantiene una discreta autonomia nella sua gestione interna e quindi un buon grado di libertà nella definizione dei processi aziendali che la caratterizzano.

(15)

13

6.2. I processi Arval

Figura 2 I Processi Arval

La catena del valore, così come introdotta da Michael Porter, è il modello utilizzato per descrivere la struttura dell’organizzazione attraverso due tipologie di processo. I processi primari, o di business, sono quelli che contribuiscono direttamente alla creazione dell’output (prodotti o servizi); i processi secondari, o di supporto, sebbene non contribuiscano direttamente alla realizzazione del prodotto/servizio, sono necessari alla sua realizzazione.

Ovviamente, come già detto, il processo oggetto del mio elaborato di tesi è un sotto-processo del macro sotto-processo “- 15 - Gestione IT” che vediamo in Figura 1.

(16)

14

6.3. IT Service Organization

Il Reparto IT fornisce all'azienda consulenza e strumenti tecnologici per realizzare le attività di business e supportarne il continuo sviluppo. Esso è organizzato, come tutta l’azienda, secondo una struttura gerarchica funzionale che vediamo in Figura 3:

Figura 3 Organizzazione Gerarchica IT Service

Vi è un responsabile dell’intero reparto IT (IT Manager) che si rapporta in maniera diretta con i responsabili delle diverse funzioni:

 Sviluppo & Integrazione : si occupa dello sviluppo e dell’integrazione dei software

applicativi necessari ai processi di Business.

 Service desk, Quality & Method : si occupa di fornire il primo supporto

(tecnico/informatico) alle richieste provenienti dal lato business e di standardizzare le procedure operative.

(17)

15

 Infrastructure & Production: si occupa della gestione di tutte le infrastrutture

informatiche (database, pc, server, etc.) e della messa in produzione degli sviluppi generati dalla funzione corrispondente.

Vedremo più avanti come tutte queste divisioni funzionali verranno toccate in maniera trasversale dal processo di Change Management.

6.4. Servizi IT

L’ITSM nel suo complesso si occupa di gestire tutti i servizi riassunti in Figura 4. Per ognuno di essi vale il ciclo di Continual Process Improvement descritto

precedentemente.

(18)

16 Come si può vedere in Figura 4 questi servizi vengono raggruppati in due macro-categorie:

 User Services: sono quei servizi che si occupano dell’installazione e dell’operatività

delle strutture informatiche messe a disposizione a tutti gli utenti Arval.

 Software Services: sono quei servizi erogati dall’IT che supportano il processo

core dell’azienda in tutte le sue fasi. Sono 19 servizi, raggruppati in 5 macro-categorie, sui quali s’incentrano le attività di cambiamento e miglioramento continuo.

Software Services

6.4.1.

Questi descritti in Figura 5 sono nel dettaglio i Software Services:

Figura 5 Software Services

(19)

17 Di seguito una descrizione dettagliata del Service Catalogue, ovvero di tutti quei servizi erogati dall’azienda che sono oggetto di modifica ed evoluzione.

Reporting Interno

Descrizione Estrazione ed elaborazione dati per le varie unità aziendali

Campo di Applicazione

Fornire un'adeguata strumentazione a

supporto delle attività aziendali che consenta il raggiungimento degli obiettivi prefissati

Attività di modifica ed evoluzione del servizio

Gestione cambiamenti richiesti dal business attraverso il processo di change management, secondo tempistiche concordi con le esigenze di business.

Attività di manutenzione ordinaria

Supporto al business. Controllo delle performance. Monitoring trasferimento e manutenzione dati secondo la classificazione di sicurezza concordata.

Reporting Esterno

Descrizione Estrazione ed elaborazione dati per il cliente.

supporto delle attivta aziendali che consenta il raggiungimento degli obiettivi prefissati.

Supporto al business. Controllo delle performance. Monitoring trasferimento e manutenzione dati secondo la classificazione di

(20)

18 sicurezza concordata.

Query on Demand

Descrizione Servizio di richiesta estrazione dati per reportistica on demand.

Fornire reportistica on demand, per integrare i report già esistenti. Il servizio e attivo nei giorni mercoledì e venerdì.

Il servizio non comprende richieste di cambiamenti minor o progetti. Attività di manutenzione

ordinaria

Le query sono richieste spot senza impatto sulla produzione ma ad alto effort interno.

Front Office & Quotation

Descrizione Gestione del prospetto e del cliente nelle prime fasi del contratto con il cliente.

supporto delle attività aziendali che consenta il raggiungimento degli obiettivi prefissati.

(21)

19

Rischio

Descrizione Gestione del rischio sui prospetti.

Contabilità

Descrizione Amministrazione e gestione contabilità.

(22)

20

Recupero Crediti

Descrizione Gestione dei clienti insolventi.

Gestione Contratto

Descrizione Attività di gestione contratto dei clienti.

(23)

21

Processi di fatturazione

Descrizione Gestione della fatturazione e delle chiusure mensili.

Amministrazione HR

Descrizione Amministrazione personale d’azienda.

Supporto al business. Controllo delle performance. Monitoring trasferimento e manutenzione dati secondo la classificazione

(24)

22 di sicurezza concordata.

Acquisti Generali

Descrizione Strumenti per la gestione degli acquisti ad eccezione degli acquisti auto.

Rete Fornitori

Descrizione Amministrazione contratti con la rete di officine e carrozzerie convenzionate.

Fornire un'adeguata strumentazione a supporto delle attività aziendali che consenta il

raggiungimento degli obiettivi prefissati. Attività di modifica ed

evoluzione del servizio

Gestione cambiamenti richiesti dal business attraverso il processo di change management, secondo tempistiche concordi con le esigenze

(25)

23 di business.

Manutenzione e Carrozzeria

Descrizione Manutenzione.

Remarketing

Descrizione Gestione rientro usato e vendita dell’usato.

supporto delle attività aziendali che consenta il raggiungimento degli obiettivi prefissati. Attività di modifica ed Gestione cambiamenti richiesti dal business

(26)

24 evoluzione del servizio attraverso il processo di change management,

secondo tempistiche concordi con le esigenze di business.

Fatture Passive Servizi

Descrizione

Strumenti per l'inserimento, controllo delle fatture ricevute dai fornitori di servizi, e rifatturazione al cliente.

Supporto al business. Controllo delle performance. Monitornig trasferimento e manutenzione dati secondo la classificazione di sicurezza concordata.

Carburante

Descrizione Gestione delle carte carburante.

(27)

25 Attività di modifica ed

Assistenza e Preassegnazione

Descrizione Servizio di preassegnazione auto e assistenza al cliente.

Assicurazione

Descrizione Gestione completa dell’assicurazione auto.

(28)

26 Attività di modifica ed

Bolli e Multe

Descrizione Gestione del bollo auto e amministrazione multe.

Fornire un'adeguata strumentazione a supporto delle attività aziendali che consenta il

raggiungimento degli obiettivi prefissati.

Supporto al business. Controllo delle performance. Monitornig trasferimento e manutenzione dati secondo la classificazione di sicurezza concordata.

(29)

27

7. Analisi di Processo

7.1. Oggetto e Campo di Applicazione

Il processo di CM ha come scopo quello di avere una visione a 360 gradi dei cambiamenti che verranno introdotti nell’architettura dei sistemi informativi, di prevederne gli impatti e ridurre gli incidenti e sospensioni dei servizi informatici erogati.

7.2. Glossario

 Risorse dei sistemi informativi: ci riferiamo sia al personale interno appartenente

al reparto dei servizi informativi Arval, sia al personale delle società esterne che supportano il personale interno svolgendo specifiche attività (es.: sviluppo software, supporto applicativo, ecc.)

 Segnalazione: corrisponde ad una generica richiesta proveniente dall’Utente.  Richiesta di Cambiamento (RDC): è una richiesta effettuata dall’Assistenza di

primo livello o dalle Risorse dei sistemi informativi stessi. Viene generata in seguito ad una segnalazione Utente o ad un accorgimento migliorativo delle Risorse dei sistemi informativi.

 RDC Evolutiva: si tratta di un ampliamento delle funzionalità già esistenti.  RDC Correttiva: si tratta di una correzione di un attuale malfunzionamento.

 Business Expert: Utenti esperti degli applicativi di business che quotidianamente

utilizzano.

 Business: sono quelle persone che svolgono attività a valore per il cliente.

 Applicativi di Test: sono una copia esatta degli applicativi utilizzati dal business,

(30)

28

7.3. Funzioni Coinvolte

Il processo di Change Management coinvolge:

 Le Risorse dei sistemi informativi.

 L’Utente, che risulta essere il cliente finale del processo.

7.4. Attori del processo

 Utente: tutte le persone che hanno un codice di accesso (login) ai sistemi

informativi ma che non appartengono alle risorse dei sistemi informativi.

 Assistenza di primo livello (o 911): primo livello di accettazione delle

segnalazioni.

 Supporto Tecnico: corrisponde all’assistenza relativa a tutti gli aspetti tecnici

della postazione di lavoro dell’Utente (es.: Pc, stampanti, telefono, ecc.).

 Analista: persona che si occupa di effettuare un’analisi approfondita della

segnalazione.

 Sviluppatore: persona che si occupa dello sviluppo di un cambiamento software.

Sono da considerarsi attori del processo, però esterni all’organizzazione, poiché Arval esternalizza l’attività di Sviluppo ad altre organizzazioni.

 Tester: persona che si occupa di verificare che il cambiamento soddisfi i requisiti

definiti in analisi, solitamente effettua test di tipo tecnico.

 Coordinatore Produzione: persona che si occupa di rendere effettivo il

cambiamento.

 Responsabile IT: è il responsabile del reparto IT e dell’intero processo di Change

(31)

29

7.5. Descrizione generale del Processo

Il processo di Gestione del Cambiamento si articola in diverse fasi. L’ input al processo può essere generato da una segnalazione Utente o da un accorgimento migliorativo delle Risorse dei sistemi informativi. L’output del processo può consistere nel rilascio di una nuova versione di un applicativo o semplicemente nell’installazione di una stampante. In sostanza, il processo deve gestire qualsiasi cambiamento (HW o SW) sull’intera architettura dei sistemi informativi dell’organizzazione.

Tutti gli Utenti Arval possono usufruire di un applicativo interno per potersi mettere in contatto con l’assistenza di primo livello, in alternativa possono usufruire della linea telefonica interna digitando 911 sul proprio dispositivo telefonico. L’ assistenza di primo livello si occupa di gestire le segnalazioni e, qualora fosse possibile, dare un primo supporto. Se la segnalazione è di carattere prettamente tecnico/infrastrutturale contatta il supporto tecnico, il quale provvederà, nei limiti delle sue competenze.

Per le segnalazioni per cui non è possibile dare supporto, l’assistenza di primo livello deve generare una RDC con l’ausilio di un sistema informativo interno, accessibile dall’intero reparto IT. A questo punto la RDC viene esaminata dagli analisti che la classificano come RDC Correttiva o RDC Evolutiva. Nel caso venga categorizzata come correzione la richiesta viene passata direttamente in carico al sviluppatore. Qualora, invece, si richiede una evoluzione l’Analista definisce una dettagliata Analisi Funzionale e con la consulenza dello Sviluppatore determina un costo in termine di giorni lavorativi per portarla a termine. Successivamente l’Analisi funzionale deve essere portata all’attenzione del Responsabile IT, che a seconda del budget disponibile e dell’importanza dell’evoluzione decide se approvarla o meno. Se l’esito è positivo l’Analisi funzionale viene consegnata allo Sviluppatore corredata di priorità. In questo modo lo Sviluppatore organizza le sue attività coerentemente con il grado di priorità. Lo sviluppo viene effettuato sugli applicativi di test. Successivamente il Tester o lo stesso Utente che ha aperto la segnalazione può effettuare i test. Se il test

(32)

30 va a buon fine il Coordinatore Produzione stila la documentazione di rilascio necessaria a descrivere i cambiamenti apportati.

I cambiamenti vengono resi effettivi mensilmente (salvo casi di emergenza), poiché richiedono il temporaneo blocco delle attività del business.

7.6. Descrizione Attività

INVIO SEGNALAZIONE

Attori Principali Utente Attori Secondari -

Descrizione L’Utente può inviare una segnalazione per eventuali problemi avuti con l’applicativo o richiedere un cambiamento sul suo attuale funzionamento. Lo può fare attraverso la compilazione di un form, utilizzando un software interno, oppure attraverso una chiamata telefonica al 911.

GESTIONE SEGNALAZIONE

Attori Principali Assistenza primo livello (911) Attori Secondari Utente

Descrizione L’Assistenza può dare una risposta immediata all’utente quando: - il problema sia facilmente risolvibile;

- identifica un work-around per non bloccare la sua attività operativa;

- si tratta di un problema tecnico.

Altrimenti, crea una “Richiesta Di Cambiamento” sul Sistema Informativo interno all’IT il quale successivamente la prenderà in analisi. Eventualmente la segnalazione risulti poco chiara può chiedere delucidazioni all’Utente.

(33)

31

ANALISI RDC

Attori Principali Analista

Attori Secondari Utente, Sviluppatore

Descrizione L’Analista analizza la RDC. Eventualmente può contattare l’utente per ottenere ulteriori informazioni. Al termine

dell’analisi definisce: i componenti coinvolti, il grado di priorità e la categorizza come evoluzione o correzione. Nel caso venga categorizzata come correzione la richiesta viene passata direttamente in carico al sviluppatore. Qualora, invece, si richiede una evoluzione l’Analista definisce una dettagliata Analisi Funzionale, con la consulenza dello Sviluppatore

determina un costo in termine di giorni lavorativi per portare a termine l’evoluzione. Successivamente la segnalazione evolutiva analizzata viene inviata al Responsabile IT per l’approvazione.

APPROVAZIONE EVOLUZIONE

Attori Principali Responsabile IT

Attori Secondari Utente, Analista, Sviluppatore

Descrizione Il Responsabile IT deve approvare o rifiutare l’effettivo sviluppo dell’evoluzione. Nel caso si tratti di una grossa (e quindi costosa) evoluzione può richiedere un incontro con Utente, Analista e Sviluppatore per valutare gli effettivi benefit post-evoluzione.

(34)

32

LAVORAZIONE

Attori Principali Sviluppatore Attori Secondari -

Descrizione Lo Sviluppatore esegue la lavorazione della segnalazione tenendo conto della priorità con cui viene classificata

TEST

Attori Principali Utente Attori Secondari Tester

Descrizione Al termine dello sviluppo, viene testato il reale funzionamento della modifica realizzata. Nel caso il test richieda delle

competenze tecniche, unitamente all’utente che ha aperto la segnalazione che verificherà le funzioni dell’interfaccia, ci sarà un programmatore (diverso da quello che si occupato dello sviluppo) a testare la parte tecnica.

RILASCIO E MESSA IN PRODUZIONE

Attori Principali Coordinatore Produzione Attori Secondari -

Descrizione Successivamente all’esito positivo dell’attività di Test, il Coordinatore Produzione stila la documentazione di rilascio necessaria a descrivere i cambiamenti apportati. Una volta al mese effettua la Messa in Produzione, ovvero si rendono effettivi i cambiamenti collezionati nel periodo. Deve

comunicare il blocco delle attività temporaneo agli utenti che operano sugli applicativi ed i database coinvolti nel Change.

(35)

33

7.7. Mappatura del processo

(36)

34

7.8. Workflow Operativo

(37)

35

7.9. Risorse impiegate nel processo

Risorse Umane

7.9.1.

Sono 45 il numero di risorse umane impiegate nel processo di Change Management e sono così distribuite:

 5 impiegate nell’attività di assistenza.  12 impiegate nell’attività di analisi.  16 impiegate nell’attività di sviluppo.

 7 impiegate nell’attività di coordinazione della produzione.  4 impiegate nell’attività di supporto tecnico.

 1 responsabile IT.

Ognuno di questi raggruppamenti ha al suo interno una figura di riferimento che coordina la gestione del lavoro.

Area di lavoro

7.9.2.

L’area di lavoro è costituita da vasti uffici “open space” che permettono una facile comunicazione e collaborazione tra le risorse al suo interno. Le postazioni lavorative sono distribuite in maniera settoriale per attività lavorativa. Diverse le sale a disposizione per riunioni che coinvolgono tre o più risorse.

(38)

36

Figura 8 Area di lavoro

Postazione di lavoro

7.9.3.

La postazione di lavoro comprende tutta la strumentazione necessaria all’attività lavorativa: computer, telefono e cassettiera portadocumenti. I divisori sono di un’altezza adeguata da permettere la comunicazione tra i componenti dello stesso team-work e garantire allo stesso tempo l’operatività del singolo senza disturbi esterni.

(39)

37

Figura 9 Postazione di lavoro

7.10. Dati di Processo

Il sistema informativo utilizzato durante il processo permette di tracciare le fasi del ciclo di vita dell’intero processo per ogni segnalazione. In particolare registra nel database il nome della persona che si appresta a fare una determinata attività e l’istante in cui la inizia. Effettuando quindi una query sulla tabella in cui sono memorizzate queste informazioni, diventa semplice ottenere informazioni del tipo che vediamo in Figura 10.

Richiesta Status DataInizio Assegnatario Tipo …

00010245 Creata 02122012 14:58:36 456468 C … 00010245 Analisi 02132012 09:23:21 987987 C … 00010245 Approvazione 02232012 11:11:21 564654 C … 00010245 Lavorazione 02242012 14:22:19 954984 C … 00010245 Test 03062012 18:12:34 684856 C … 00010245 Lavorazione 03082012 10:12:34 954984 C … 00010245 Test 03102012 12:23:34 684856 C … 00010245 Rilascio 03122012 08:11:23 735684 C … 00010245 Chiusura 03152012 08:11:23 735684 C … … … … … …

(40)

38 Il numero memorizzato nella colonna “Richiesta” (Figura 10) è l’identificativo della segnalazione su cui vengono fatte le attività, la colonna “Status” indica lo stato in cui è la richiesta, la colonna “DataInizio” contiene un timestamp del momento in cui la richiesta è giunta allo status corrispondente, il numero della colonna “Assegnatario” invece corrisponde all’identificativo dell’utente che sta lavorando quella richiesta, infine la colonna “Tipo” indica se la RDC è di tipo Correttiva (C) o Evolutiva (E). Dalla stessa sorgente possiamo ricavare anche ulteriori informazioni relative alla richiesta che però non ho considerato utili ai fini delle analisi condotte.

Lavorando questi dati è stato possibile effettuare determinate analisi con discreta facilità anche su un volume di informazioni abbastanza grande.

Più oneroso è stato invece effettuare una riclassificazione delle richieste che rendesse possibile un’analisi più fedele sul tipo di input di processo. E’ stata eseguita, infatti, un esame puntuale della documentazione relativa ad ogni richiesta. Dalla documentazione è stato possibile capire il contenuto della richiesta di cambiamento e quindi riclassificarla in base al suo grado di onerosità ed al suo iter di lavorazione. Le classi definite le vedremo più avanti nel dettaglio.

Questa riclassificazione puntuale è stata fatta solo sulle richieste lavorate nell’arco dell’anno 2013, ovvero su 4770 RDC.

Tempi delle attività di processo

7.10.1.

Una prima analisi è stata condotta sulla durata media delle singole fasi che caratterizzano il processo. Sono oggetto di analisi i processi portati a termine nell’arco dell’anno 2013. Come vediamo in Tabella 1 e dal rispettivi grafici (Grafico 1 e Grafico 2), è stata fatta una distinzione sulle RDC di tipo correttivo e RDC di tipo evolutivo, poiché come abbiamo visto nella mappatura del processo si caratterizzano per un iter operativo lievemente differente.

(41)

39

Attività Tm (evolutiva) Tm (correttiva)

Gestione Segnalazione 12h 42m 22h 12m Analisi Richiesta 18d 16h 22m 4d 10h 34m Approvazione Evoluzione 7d 03h 31m - Lavorazione 28d 12h 13m 3d 21h 28m Test 20d 11h 43m 2d 23h 09m Rilascio 6d 06h 17m 6d 04h 45m

Tabella 1 Tempi medi delle singole attività di processo1

Grafico 1 Ripartizione del processo in base alle singole attività dedicate ad una RDC evolutiva

1_{I tempi medi di ogni attività sono stati calcolati sui processi portati a termine nel 2013 (4160 processi)}

1% 24% 1% 36% 26% 12%

Ripartizione del processo(evolutive)

Gestione Segnalazione Analisi Richiesta Approvazione Evoluzione Lavorazione Test Rilascio

(42)

40

Grafico 2 Ripartizione del processo in base alle singole attività dedicate ad una RDC correttiva

Rapporto input/output di processo

7.10.2.

L’aumento dei tempi di esecuzione del processo non può prescindere dalla crescente mole di richieste registrata negli ultimi anni. La Tabella 2 mostra come le Richieste Di Cambiamento siano aumentate annualmente dal 2009 ad oggi. Il motivo di questo progressivo aumento è la forte informatizzazione di tutte le attività dei processi di business. Il più grosso aumento rispetto all’anno precedente si è registrato nel 2010, ben il 116% delle richieste in più rispetto all’anno precedente. Nonostante anche la risoluzione delle richieste sia migliorata, non è stata comunque in grado di colmare il gap con le richieste in entrata, ciò ha causato un accumulo di richieste pendenti.

5% 22% 0% 22% 17% 34%

Ripartizione del processo (correttive)

Gestione Segnalazione Analisi Richiesta Approvazione Evoluzione Lavorazione Test Rilascio

(43)

41

Anno RDC Aperte RDC Risolte %Risolte RDC pendenti

2009 1480 1454 98,24 % 26 2010 3201 3011 94,06 % 216 2011 4182 3997 95,58 % 401 2012 4568 4412 96,58 % 557 2013 4770 4587 96,16 %

890

Tabella 2 Gap Input/Output di processo

Come vediamo, infatti, ad oggi le RDC pendenti arrivano a 890 ed è facile prevedere un ulteriore aumento per il 2014. E’ pertanto necessario invertire la tendenza diminuendo progressivamente i GAP. La crescita delle RDC pendenti viene evidenziata nel Grafico 3.

Grafico 3 Gap Input/Output di processo

0 1000 2000 3000 4000 5000 6000 2009 2010 2011 2012 2013 Nu m er o d i RD C Lavorate nell'anno

Input/Output di processo

RDC Risolte RDC Aperte RDC pendenti

(44)

42

Le dimensioni dei “Change”

7.10.3.

E’ stata effettuata un’analisi del processo dal punto di vista della onerosità dell’input. Appare chiaro, infatti, che non tutte le RDC necessitino delle stesse risorse per la loro risoluzione, in particolar modo le RDC evolutive possono avere una risoluzione più o meno onerosa a seconda del cambiamento richiesto. Pertanto è stata effettuata una riclassificazione delle RDC.

Le RDC sono state riclassificate in:

 RDC Correttiva: sono i cambiamenti richiesti in seguito a malfunzionamenti

degli applicativi o per modifiche di dati su cui l’utente non può intervenire.

 RDC Ricorrente: è una classe definita in analisi, intersezione di RDC Evolutive e

RDC Correttive. Racchiude tutti quei cambiamenti che ricorrono periodicamente (es. modifica dei diritti utente, installazione postazione lavoro , etc.)

 RDC Evolutiva Minore: è una classe definita in analisi, sottoclasse delle RDC

Evolutive. Comprende tutti quei cambiamenti che prevedono un tempo di risoluzione inferiore agli 80 giorni.

 RDC Evolutiva Maggiore: è una classe definita in analisi, sottoclasse delle RDC

Evolutive. Comprende tutti quei cambiamenti che prevedono un tempo di risoluzione superiore agli 80 giorni.

Tipologia RDC Numero Percentuale

RDC Correttiva 2239 49 %

RDC Corr. Ricorrenti 970 21 %

RDC Evol. Minore 1280 28 %

RDC Evol. Maggiore 98 2 %

(45)

43

Tabella 3 Riclassificazione delle RDC2

Grafico 4 Riclassificazione RDC

Interessante vedere (dalla Tabella 3 e dal Grafico 4) come RDC Correttive e RDC Ricorrenti siano circa il 70% di tutte le RDC ricevute in input, ovvero buona parte delle RDC risultano essere di bassa onerosità. Sarebbe opportuno, pertanto, prevedere un workflow differente per facilitare la loro risoluzione ed evitare di ostruire la risoluzione delle RDC di maggiore onerosità.

2_{Fanno parte dell’analisi solo le RDC lavorate nell’anno 2013}

49%

21% 28%

2%

Classificazione delle richieste

RDC Correttiva

RDC Ricorrenti

RDC Evol. Minore

RDC Evol. Maggiore

(46)

44

7.11. Problematiche evidenziate dagli attori del

processo

Successivamente all’analisi dei dati di processo si è proceduto all’intervista degli attori del processo che hanno evidenziato le loro problematiche. Queste sono state riassunte di seguito.

Utenti

7.11.1.

Sono stati intervistati dieci Business Expert che con maggiore frequenza hanno effettuato delle segnalazioni.

Queste le problematiche evidenziate:

 Mancanza di informazioni riguardo lo stato di avanzamento della loro segnalazione.

 Scarso coinvolgimento nella risoluzione che, a volte, risulta incompleta.

 Rallentamenti della loro attività troppo frequenti.

Assistenza di primo livello

7.11.2.

 Mancanza di un sistema informativo unico che eviti loro di reinserire le richieste a seguito di segnalazioni ricevute dagli utenti.

 Attività lavorativa troppo intensa per le risorse a disposizione.

Analista

7.11.3.

 Eccessiva pressione in termini di responsabilità sull’esito dell’intero processo. E’ l’analista che definisce il costo previsionale (in termini di

(47)

45 giorni) dello sviluppo, pertanto, è sua responsabilità se lo sviluppatore va oltre i termini previsti in fase di analisi sforando il budget predisposto.

Responsabile IT

7.11.4.

Nessuna problematica evidenziata.

Tester

7.11.5.

Nessuna problematica evidenziata.

Coordinatore Produzione

7.11.6.

 L’attività di messa in produzione del cambiamento avviene con una periodicità troppo bassa, questo causa dei carichi di lavoro troppo elevati in prossimità dell’attività stessa e molto bassi ad inizio periodo.

7.12. Conclusione Analisi

In seguito alla descrizione dettagliata del processo, alla definizione del suo workflow operativo, all’analisi dei dati di processo e delle problematiche evidenziate dagli attori del processo stesso si possono trarre delle conclusioni. Schematicamente si evidenziano i punti di forza e di debolezza del processo AS IS.

(48)

46 Punti di forza

- Elevata competenza delle risorse umane di cui il processo usufruisce. - Le persone hanno tutta la strumentazione di cui necessitano per lavorare

con efficienza.

- Buona dislocazione e conformazione delle postazioni di lavoro.

Punti di debolezza

- Tempi di processo troppo lunghi. - Assenza dei KPI.

- Assenza di documentazione per la standardizzazione delle procedure operative.

- Non sempre le attività svolte sono a valore per il cliente che dovrebbe poter seguire tutte le fasi del processo.

- Le informazioni sullo stato del processo non sono fruibili a tutti gli attori coinvolti, rendendo il processo disgregato.

- Necessità di un unico tool per la gestione di tutti i cambiamenti

- Unico e oneroso workflow anche per sottoprocessi che potrebbero essere eseguiti in maniera più snella.

(49)

47

8. ITIL

8.1. Perché ITIL

A supporto delle attività di gestione dei Sistemi Informativi sono nati e si sono diffusi molti sistemi di conoscenza strutturata e codificata, che di caso in caso hanno preso la forma di standard, raccolte di best practice, riferimenti per la certificazione, sistemi legislativi, check list e modelli di riferimento. Seppur la scelta del modello sia ricaduta su ITIL si è ritenuto utile richiamare alcune delle più importanti fonti di conoscenza strutturata, focalizzate nell’ambito dei Sistemi informativi. Ciò al fine di favorire una visione complessiva dello scenario delle fonti rilevanti per il Governo dei Sistemi Informativi. Nella parte seguente sono descritte e messe a confronto due tra le fonti di conoscenza più utilizzate e diffuse. Ogni fonte è descritta sinteticamente in termini di:

 descrizione e finalità;

 ente emittente;

 fonti e bibliografia.

Nella scelta delle fonti da inserire nel presente repertorio si è utilizzato il criterio della rilevanza e quello della rappresentazione della varietà dei temi della IS Governance. Le scelte non esprimono dunque un giudizio di merito, ma solo il tentativo di descrivere la ricchezza e la varietà delle fonti disponibili.

CMMI

8.1.1.

(50)

48 Il CMMI (Capability Maturity Model Integration) è una raccolta di best practice per il miglioramento dei processi focalizzato in particolare sui processi di sviluppo e manutenzione, supporto prodotti e servizi. Può essere usato per guidare il miglioramento dei processi in un singolo progetto, una divisione o una intera organizzazione. Il CMMI aiuta l’integrazione tra le funzioni di una organizzazione, fissa obiettivi di miglioramento, fornisce linee guida per l’adozione di processi per il miglioramento della qualità e aiuta a valutare i processi nello stato di partenza. Si basa su una specializzazione del più generico CMM (Capability Maturity Model). CMMI è utile per:

 verificare la maturità dei processi implementati;

 effettuare benchmarking tra processi;

 ridurre i rischi di progetto.

Ente Emittente

E’ pubblicato a cura del SEI (Software Engineering Institute ) della Carnegie Mellon University.

Fonti

 CMMI for Development (CMMI-DEV-v.1.3) che contiene le best practice da utilizzare per le orgnizzazioni che si occupano dello sviluppo di prodotti e applicazioni;

 CMMI for Acquisition (CMMI.AM v.1.2) che contiene le best practice per progetti in cui le soluzioni sono acquistate.

(51)

49

COBIT

8.1.2.

Descrizione finalità

Il Control Objectives for Information and related Technology (COBIT) è un modello (framework) per la gestione della Information and Communication Technology (ICT). Pubblicato inizialmente come supporto alle attività di revisione dell’IT, COBIT® nella sua veste attuale è strumento fruibile per molti ruoli aziendali. Anche come conseguenza dell’ampio insieme di potenziali ambiti di utilizzo del framework, l’applicazione di COBIT® non può essere immediata: è indispensabile una applicazione selettiva che tenga conto di elementi di discrimine, tra i quali ad esempio:

 le caratteristiche dell’azienda (tipo di business, dimensione, disponibilità/avversione al rischio, requisiti regolamentari, politiche interne, ecc.);

 gli obiettivi dell’area aziendale all’interno della quale si intende applicare la metodologia

COBIT 5 divide il controllo della funzione IT in quattro domini: Pianificazione e Organizzazione (Plan and Organise), Acquisizione e Implementazione (Acquire and Implement), Erogazione ed Assistenza (Deliver and Support), Monitoraggio e Valutazione (Monitor and Evaluate). Nei quattro domini sono collocati un totale di 34 processi, ai quali fanno capo, nella versione 5, un totale di 210 obiettivi di controllo; questi ultimi rivestono un'importanza centrale nel COBIT, al punto di dare il nome al modello stesso.

Ente Emittente

Creato nel 1992 dall'associazione americana degli auditor dei sistemi informativi (Information Systems Audit and Control Association - ISACA), e dal IT Governance Institute (ITGI).

(52)

50

Fonti

 COBIT 5 - Control Objectives, Management Guidelines, Maturity Models ITGI – IT Governance Institute - 2012

La scelta ITIL

8.1.3.

E’ chiaro che la numerosità dei framework disponibili sia ben più ampia di quelli appena descritti, nonostante ciò, la scelta sul modello da utilizzare per la riprogettazione del processo di Software Change Management è ricaduta su ITIL per una serie di vantaggi connessi.

ITIL è accettato come fonte di suggerimenti e indicazioni da parte di organizzazioni in tutto il mondo, si è affermato quale standard “de facto”, non proprietario, per la gestione dei servizi informatici, dando luogo alle specifiche della ISO 20000.

E’ un framework non prescrittivo: si può adattare ed implementare nel contesto particolare di una specifica organizzazione.

Adotta un linguaggio (terminologia) che consente ai professionisti dell’IT Service Management di comunicare chiaramente e senza ambiguità, non ha inventato nuovi nomi, ma ha attribuito significati specifici a parole e frasi già in uso.

ITIL dedica un intero modulo (Service Transition) a descrivere il valore di una gestione del cambiamento ben strutturata, attraverso l’adozione e l’attuazione di approcci standard, dando estrema rilevanza al processo di Software Change Management.

(53)

51

8.2. Cos’è il framework ITIL

L’IT Infrastructure Library, o ITIL come è normalmente chiamata, è una biblioteca di libri che descrivono il modo migliore (best practice) di organizzare l’attività di erogazione dei servizi IT, per produrre valore per i propri clienti. E’ stato originariamente sviluppato alla fine del 1980 dalla Central Computer and Telecommunications Agency (CCTA), un’agenzia del governo britannico. Da tempo la CCTA ora ha cessato di operare e le sue responsabilità sono state trasferite al Office of Governement Commerce (OGC) . Il CCTA non ha operato da solo nello sviluppo di ITIL, bensì ha coinvolto attivamente numerosi rappresentanti di molte altre organizzazioni con significativa esperienza pratica nella gestione dei servizi IT. Per questo motivo è ragionevole descrivere ITIL come una best practice.

Il valore e la rilevanza di ITIL può essere valutata da suo stato di accettazione in tutto il mondo come lo standard de facto per l’IT Service Management. E’ anche alla base di ISO/IEC 20000, uno standard internazionale per l’IT Service Management, pubblicato per la prima volta nel dicembre 2005 e aggiornato nel 2011. E’ stato adottato da molte tipologie di organizzazioni in tutto il mondo: commerciali e senza scopo di lucro, grandi e piccole, nazionali e multinazionali.

Secondo ITIL i tre obiettivi dell'IT Service Management (ITSM) sono i seguenti:

 allineare i servizi IT con i bisogni correnti e futuri del business e dei clienti

 migliorare la qualità dei servizi IT erogati

 ridurre i costi fissi di erogazione dei servizi

Storia di ITIL

(54)

52 Il concetto di ITIL ( ancora non si chiamava così ) è 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 comunemente chiamata come ITIL v1, fu la prima versione di queste "linee guida", che era stata intitolata "Government Information Technology Infrastructure Method" (GITM) e negli anni si è espansa fino a 31 volumi in un progetto inizialmente diretto da Peter Skinner e John Stewart presso il CCTA. Naturalmente, questa era abbastanza diversa dall'ITIL che conosciamo oggi, anche se concettualmente si avvicinava molto, e si concentrava su due aree: Service support e Service delivery.

Le pubblicazioni ITIL v1 furono reintitolate principalmente per desiderio di Roy Dibble del CCTA poiché queste dovevano essere delle linee guida e non un metodo formale ed anche per rispondere alla forte crescita di interesse ad di fuori della Pubblica Amministrazione Britannica.

Molti dei principali concetti sulla gestione del servizio non erano stati creati all’interno del progetto originale del CCTA che sviluppava ITIL, infatti IBM rivendica che i suoi "Yellow Books" ( A Management System for the Information Business ) ne siano stati un precursore. Secondo IBM, infatti, i quattro volumi chiamati A Management System for Information Systems avevano già documentato i concetti originali della gestione dei sistemi e funsero da input al set originale di libri ITIL. Altre pubblicazioni IBM e commenti degli stessi autori di ITIL hanno chiarito che i "yellow books" diedero un significativo contributo al Service Support di ITIL mentre il volume sul Service Delivery non ne era stato influenzato nella stessa misura.

(55)

53 Durante gli anni '80 la diffusione di ITIL rimase un po' 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 volumi. Microsoft nello stesso periodo rilascia 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).

8.3. ITIL v3

ITIL v3 è parte del processo teso a migliorare le best practices ITIL, ovvero parte del processo di “Continuos Improvement” che ITIL predica e applica anche a se stesso con aggiornamenti periodici dei suoi contenuti. Gli aggiornamenti sono anche frutto dei suggerimenti e delle segnalazioni effettuate dai membri della community, consultabili all’apposito indirizzo ( http://www.best-management-practice.com/ChangeLog ) una volta registrati.

Il punto di maggior distacco dalla versione precedente è l’introduzione del concetto di lifecycle dei servizi. Come si vede in Figura 11, ITIL è strutturato in base al concetto di ciclo di vita del servizio. Partendo dal cuore della struttura abbiamo queste tre grandi stratificazioni:

(56)

54

 Strategia del servizio (Service Strategy) è l’asse attorno al quale ruota il ciclo

di vita e rappresenta le politiche e gli obiettivi che guidano la gestione dei servizi.

 Progettazione del servizio (Service Design), transizione del servizio (Service Transition) e Service Operation sono le fasi con cui si realizza la strategia.  Miglioramento continuo del servizio (Continual Service Improvement – CSI)

è la ricerca continua del miglioramento in tutti gli aspetti della gestione dei servizi.

Figura 11 ciclo di vita del servizio ITIL

Service Strategy

8.3.1.

La Service Strategy racchiude le linee guida su come sviluppare ed implementare il Service Management come un asset strategico dell'organizzazione e non solo come una capacità operativa. In altre parole la Service Strategy invita i service providers a pensare ed agire in modo strategico, di modo che la strategia sia il collante durante tutto il lifecycle del servizio e si rimanga sempre focalizzati su quelle che sono le esigenze del business.

(57)

55 Definire una strategia corrisponde a stabilire una serie di punti fermi ai quali fare riferimento durante l’intero ciclo di vita del servizio:

 Identificare con chiarezza la il servizio e i clienti che lo utilizzano;

 Definire come il valore è creato ed erogato;

 Identificare le opportunità per offrire servizi e come realizzarle;

 Definire un modello chiaro per la fornitura del servizio che articoli come i servizi saranno finanziati, a chi saranno erogati e con quale proposito;

 Comprendere quali saranno le capacità organizzative necessarie alla realizzazione della strategia;

 Documentare e coordinare come gli asset dei servizi sono utilizzati per erogare i servizi e come ottimizzarne le performance;

 Definire il livello di investimento necessario ad un certo livello di domanda del servizio;

 Definire le strutture per garantire un buon rapporto di collaborazione e comunicazione tra il cliente ed il fornitore del servizio.

I processi di cui si caratterizza questa fase sono:

Strategy Generation ( Generazione della Strategia)

Con l’obiettivo sempre primario di servire il cliente, si definisce la strategia da intraprendere sulla base dell’offerta del fornitore del servizio, sulle capacità del servizio, sugli spazi attuali e potenziali di mercato, sulla presenza di eventuali competitors. Anche la garanzia di attuazione della strategia scelta è responsabilità del processo di Strategy Generation.

Service Portfolio Management ( Gestione del portafoglio dei servizi)

Il Service Portfolio Management assicura che il fornitore del servizio abbia a disposizione il giusto mix di servizi al fine di poter soddisfare le richieste del business con un adeguato livello di investimento.

(58)

56 Capire, anticipare e influenzare la richiesta dei clienti dei servizi, facendo in modo da garantire una “capacity” sufficiente a soddisfare la domanda.

Financial Management ( Gestione finanziaria )

Comprende quelle attività di previsione di spesa (Budgeting) e contabilizzazione delle spese (Accounting). Pertanto si occupa di : assistere nella riduzione dei costi a lungo termine; identificare i costi reali dei servizi; fornire informazioni finanziarie; calcolare il TCO (Total Cost of Ownership) e ROI (Return On Investment) del servizio.

Service Design

8.3.2.

Il Service Design si occupa della progettazione e sviluppo dei servizi e dei processi di Service Management, quindi di convertire obiettivi strategici (definiti nella Service Strategy) in un portfolio di servizi IT ed asset IT.

Le principali finalità della fase di progettazione del servizio sono la progettazione di nuovi servizi o di modifiche ai servizi esistenti da introdurre nell’ambiente di produzione. E’ importante in questa fase adottare un approccio olistico a tutti gli aspetti della progettazione e che quando si modifica un qualunque aspetto della progettazione anche tutti gli altri siano presi in considerazione, tenendo sempre in considerazione l’impatto sul servizio complessivo, sui sistemi e strumenti di gestione, sulle architetture, le tecnologie, i processi di gestione del servizio e le necessarie misurazioni metriche. Questo assicurerà non solo che la progettazione affronti subito gli elementi funzionali, ma anche che tutti i requisiti operativi e di gestione siano presi in considerazione come parte integrante della progettazione e non siano aggiunti in un secondo tempo.