6. La realtà Aziendale
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.
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.
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 … … … … … …
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.
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
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
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 pendenti42
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 %
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
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.
Queste le problematiche evidenziate:
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.
Queste le problematiche evidenziate:
Eccessiva pressione in termini di responsabilità sull’esito dell’intero processo. E’ l’analista che definisce il costo previsionale (in termini di
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.
Queste le problematiche evidenziate:
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.
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.
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.
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.
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).
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.
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
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.
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:
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.
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