--- Concetti base modello ITIL ---

Indice

1. Generalità su ITIL ................................................................................................................................................................. 2

1.1. Cos’è ITIL ......................................................................................................................................................................... 2

1.2. La struttura di ITIL come corpus teorico/pratico .......................................................................................... 3

2. Concetti chiave ....................................................................................................................................................................... 3

2.1. Definizioni Generali .................................................................................................................................................... 3

2.2. Servizio e Service Management ............................................................................................................................. 4

2.3. Valore................................................................................................................................................................................ 5

2.4. Assets tangibili e intangibili .................................................................................................................................... 6

2.5. Tipologie di IT Provider ............................................................................................................................................ 7

2.6. Il ciclo di vita della fornitura dei servizi IT ....................................................................................................... 7

2.7. Processi ............................................................................................................................................................................ 9

2.8. Ruoli .................................................................................................................................................................................. 9

2.9. Funzioni ........................................................................................................................................................................ 11

2.10. Automazione e gestione dei servizi IT ............................................................................................................. 12

2.11. Ciclo di Deming .......................................................................................................................................................... 12

2.12. Misure, Metriche, KPI e CSF .................................................................................................................................. 13

2.13. Le gestione del rischio ............................................................................................................................................ 15

2.14. Il concetto di governance ...................................................................................................................................... 15

3. Fasi e relativi processi e funzioni ................................................................................................................................ 15

3.1. La fase del Service Strategy .................................................................................................................................. 15

3.2. La fase del Service Design ..................................................................................................................................... 17

3.3. La fase del Service Transition .............................................................................................................................. 18

3.4. La fase del Service Operation .............................................................................................................................. 20

3.5. La fase del Continual Service Improvement .................................................................................................. 22

1. Generalità su ITIL

1.1. Cos’è ITIL

ITIL è definito come “una best practice di dominio pubblico”. Dal testo si ricava quanto segue:

Il termine BEST PRACTICE nasce nei primi del ‘900 ma diventa famoso negli anni ’80 col

lavoro di Tom Peters e si riferisce in generale al “miglior modo possibile per fare qualcosa”.

L’idea è che le best practices vengono create da qualcuno sulla base di ciò che è ritenuto come

il miglior approccio ad una certa situazione da parte di una comunità il più vasta (e

qualificata) possibile, così che il lavoro quotidiano possa essere paragonato alla best practice

riconsoscendone mancanze, limiti e punti di miglioramento.

ITIL identifica come generatori (SOURCES) di good (vedi di seguito) e best practices i

seguenti:

Academic Research

Strandards & Industry Practices

Internal Experience

Training & Education

Identifica poi in tutti gli attori del mondo aziendale (impiegati e consulenti, clienti e fornitori)

nonchè nelle tecnologie gli elementi abilitanti (ENABLERS) di good e best practices.

Non dovrebbero essere le imprese a cercare di inventarsi (IMPLEMENT) delle best practices,

quanto piuttosto dovrebbero focalizzarsi sulle esistenti cercando di adattarle al loro caso

specifico. Per farlo dovrebbero partire dalle cosiddette GOOD PRACTICES ovvero impianti

(FRAMEWORKS) e standard (STANDARDS) di uso pubblico e conoscenze (KNOWLEDGDE)

proprietarie di individui o altre imprese. I primi sono accessibili, ben documentati, disponibili,

a costo zero o basso ma riferiti a problematiche di tipo generale. Le conoscenze specifiche

invece sono sì collegate a quel contesto specifico che servirebbe all’azienda ma sono spesso

fornite solo con clausole commerciali abbastanza impegnative, con documentazione o assente

e via dicendo. L’applicazione da parte di un’impresa di good practices al suo caso specifico, se

riconosciuta come valida da una vasta comunità scientifico/professionale crea una best

practice o fornisce da input per la creazione di nuove good o best practices.

Riepilogando: la differenza fra best practices e good practices siano l’applicazione concreta e

la produzione di risultati positivi diffusamente riconosciuti. Le good practices sono forme di

conoscenza disponibili per le aziende (gratis o a pagamento, generali o particolari etc... etc...).

Queste acquisite e applicate al caso concreto se danno risultati pratici di validità riconosciuta

diventano (o finiscono dentro) best practices.

ITIL non è uno standard in senso proprio ma un framework, una good practice nella gestione

dei servizi IT. Infatti lo standard nell’IT SERVICE MANAGEMENT è la ISO/IEC 20000 a cui ITIL

è allineato ma da cui è allo stesso modo indipendente. ITIL non è uno standard perchè è

centrato più sul come raggiungere certi risultati che non sui requisiti che è necessario

possedere per poter essere definiti conformi a un certo standard (di qualità). ITIL è concepito

per essere una guida per ogni tipo di azienda che eroga servizi IT a prescindere da

dimensione, complessità, natura di provider commerciale o interno etc...

Soluzioni basate su ITIL sono state attivate da circa 20 anni in tutto il mondo.

Le imprese che hanno ottenuto più successo non sono quelle che hanno cercato

(pedissequamente) di applicare ITIL quanto piuttosto quelle che hanno attivato soluzioni al

problema della fornitura di servizi IT basate su ITIL.

ITIL è dunque una best practice e non solo una good practice perchè non è solo un framework

teorico ma è specifico di un contesto (la fornitura di servizi IT) ed è stato consolidato appunto

su 20 anni di applicazioni concrete. La sua generalità è il suo principale punto di forza ovvero

l’elemento che ne ha favorito il successo.

1.2. La struttura di ITIL come corpus teorico/pratico

ITIL è materialmente un insieme di pubblicazioni. La prima versione di appunto 20 anni fa,

prevedeva 40 libri. Ad oggi sono stati ridotti notevolmente e le pubblicazioni possono essere

suddivise in due gruppi.

Il primo è l’ITIL CORE che contiene le best practices di tipo più generico. Il secondo sono le

ITIL COMPLEMENTARY GUIDANCE, pubblicazioni relative a specifici settori industriali,

categorie aziendali, tecnologie etc... Queste ultime possono essere libri o articoli web e

possono essere nella forma di glossari, modelli di processi, studi di casi etc... e sono

tipicamente commissionati e pubblicati dal TSO (The Stationery Office, in pratica la ISO

Inglese: “a British publishing company... who is the official publisher and the distributor for

legislation, command and house papers, select committee reports”).

Da notare che se l’ITIL CORE è dinamico (l’ultima versione, la v3 è del 2011) la

documentazione della complementary guidance lo è ancora di più.

2. Concetti chiave

2.1. Definizioni Generali

Il framework ITIL è “famoso” per l’utilizzo di alcuni acronimi e termini propri, talvolta con

significato profondamente diverso rispetto alla terminologia corrente (PLAIN ENGLISH).

Alcune di queste definizioni saranno introdotte nel prosieguo. Riportiamo qui i termini più

trasversali e/o minimi per poter proseguire con la trattazione.

CUSTOMER: Qualcuno che ha acquistato merci o servizi.

USER: Qualcuno che utilizza quotidianamente i servizi IT. Gli utenti sono distinti dai

clienti perché alcuni clienti non utilizzano quotidianamente i servizi.

SUPPLIER: Una terza parte responsabile per fornire merci o servizi necessari per

l’erogazione dei servizi IT.

BUSINESS CASE: è uno strumento di supporto alle decisioni che illustra le conseguenze

desiderate di una scelta di business (es. un investimento, l’erogazione di un nuovo

servizio).

Termini definiti altrove:

Best Practice, Good Practice (vedi par. 1.1)

Service, Value, Utility, Warranty, Resources, Capabilities, Strategic Assets (vedi par. 2.2,

2.3, 2.4);

Lifecycle, Stage (vedi par. 2.6)

Process, Trigger, Function, Role (vedi par. 2.7, 2.8, 2.9);

Service Option, Service Package (vedi par. 3.1);

Service Design Package, Service Level Agreement (vedi par. 3.2)

Change, Release, Deployment (vedi par. 3.3)

Request, Incident, Problem, Events (vedi par. 0);

Measure, Metric, Baseline, KPI, CSF (vedi par. 2.12)

Risk (vedi par. 2.13)

Governance (vedi par. 2.14)

Configuration Item, Model, CMS, DML (vedi par. 3.3)

Entriamo quindi nel dettaglio della trattazione del framework ITIL.

2.2. Servizio e Service Management

In ITIL un servizio(SERVICE) è qualcosa di connesso alla produzione di valore (VALUE).

Riguardo ai servizi è utile prendere anche queste definizioni dall’ITIL glossary:

"An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is

used internally by the IT Service Provider and is not usually visible to the Business. The term Business

Service is also used to mean a Service that is delivered to Business Customers by Business Units. For

example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store.

Successful delivery of Business Services often depends on one or more IT Services."

“A Business Service is a Service that is delivered to Business Customers by Business Units. For example

delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful

delivery of Business Services often depends on one or more Supporting Services”.

“A Supporting Service is a service that is performed to support a Business Service but usually is not visible

to the Customers of the Business Service. A Supporting Service may be provided internally by the Service

Provider organisation (sometimes referred to as an Infrastructure Service) or it may be provided by a

third party Service Provider”.

C’è poi anche questa classificazione che, come la precedente non ho trovato nel libro:

Services can be discussed in terms of how they relate to one another and their customers, and can be classified as core, enabling or enhancing. Core services deliver the basic outcomes desired by one or more customers. They represent the value that the customer wants and for which they are willing to pay. Core services anchor the value proposition for the customer and provide the basis for their continued utilization and satisfaction. Enabling services are services that are needed in order for a core service to be delivered. Enabling services may or may not be visible to the customer, but the customer does not perceive them as services in their own right. They are ‘basic factors’ which enable the customer to receive the ‘real’ (core) service. Enhancing services are services that are added to a core service to make it more exciting or enticing to the customer. Enhancing services are not essential to the delivery of a core service, and are added to a core service as ‘excitement’ factors, which will encourage customers to use the core service more (or to choose the core service provided by one company over those of its competitors).

La gestione dei servizi IT (SERVICE MANAGEMENT) è dunque tutto ciò che ha a che vedere

con il trasferimento (DELIVERY) di valore a dei clienti (CUSTOMERS) indipendentemente dal

fatto che siano esterni o interni.

Il Service Management, secondo ITIL, “consiste in” (io direi “si esprime attraverso”)

SPECIALISED ORGANISATIONAL CAPABILITIES (capacità organizzative specializzate):

processi, attività, funzioni e ruoli. Il service management può essere a buon diritto visto come

una professione autonoma, richiedente opportune capacità (SKILLS), conoscenze

(KNOWLEDGE) e l’utilizzo di standard ed esperienza, misurabili tramite qualificazione

formale.

Definizione alternativa di service management dunque può essere questa: act of transforming

resources and capabilities into valuable service.

2.3. Valore

Ma che cos’è il valore? Può essere un elemento che faciliti il cliente nel raggiungimento dei

suoi risultati di business (OUTCOMES) che egli desidera e/o un rischio o un fattore produttivo

che egli preferisce non gestire in prima persona.

Il valore prodotto/trasferito può in particolare essere misurato economicamente in vari modi.

Eccone alcuni:

ROI, Return On Investiment: Beneficio Realizzato/Capitale Investito;

VOI, Value On Investiment: Beneficio Realizzato includendo benefici non monetari e

outcomes;

BENEFTIS, Benefici: Guadagni realizzabili (suddivisibili fra monetari e non monetari);

IMPROVEMENTS, Miglioramenti: OUTCOMES attuali vs OUTCOMES precedenti;

Tale valore ITIL può essere poi misurato in termini tecnici (o meglio, di qualità) attraverso

questi due attributi:

Utilità (UTILITY), intesa come le funzionalit{ che il cliente riceve, ovvero “ciò che il

servizio fa”, da confrontare con ciò che “dovrebbe fare”. (FIT FOR PURPOSE);

Garanzia (WARRANTY), intesa come “garanzia che il servizio sia presente” (FIT FOR

USE);

Riguardo alla warranty il modello prevede che sia associata a queste componenti:

disponibilità, capacità, continuità, sicurezza. Da notare che:

VALUE = UTILITY & WARRANTY

Nè l’utilit{ da sola nè l’affidabilit{ da sola generano valore. Da notare che il concetto dovrebbe

essere ulteriormente raffinato con un ragionamento di impostazione sales force (“mareting

mindset”, p. 30). E’ utile infatti lavorare non solo sul valore quantificabile come descritto in

precedenza ma anche, sulla percezione del valore da parte del cliente perchè è questa e non il

dato tecnico che alla fine decreta il successo di un business oppure no. ITIL pertanto

raccomanda di “catturare sempre la prospettiva del cliente”.

Nota: riguardo alla qualità del valore da erogare, vale il concetto tipico delle norme ISO di

qualit{ come conformit{: si tratta di erogare il “giusto” servizio alle “giuste” condizioni, dove

“giusto” si può intendere come sinonimo di “pattuito”.

2.4. Assets tangibili e intangibili

Il fornitore di servizi IT deve dunque trasferire valore. Ma come può farlo? Il valore viene

creato utilizzando dei beni (ASSETS) riconducibili a due categorie:

RESOURCES (tangible assets: infrastructure, peole, money)

CAPABILITIES (intangible assets: abilità di portare a termine attività)

Fra gli assets ovviamente un posto speciale ce l’hanno gli STRATEGIC ASSETS definiti come

“beni che forniscono le basi per le competenze aziendali distintive”.

Descrivere il modo in cui risorse e capacità (quali, in che modo etc...) producono un valore

vuol dire, secondo il framework ITIL, dare un modello al servizio che eroga quel valore

(SERVICE MODEL). Un service model ITIL è basato su due tipi di descrizioni:

Strutturale (elenco degli assets e delle loro configurazioni);

Dinamica (elenco delle interazioni fra gli assets del cliente e del fornitore)

Un modello di servizio include tipicamente, mappe di processo, diagrammi di flusso, di

attività, criteri di assegnazione delle priorità. Il possesso di modelli di sevizio accurati ed

efficienti può essere ritenuto un fattore critico di successo di un IT Provider (vedi più oltre,

processi DM e SACM).

2.5. Tipologie di IT Provider

E’ importante riconoscere (pag. 26) che ci sono differenti tipi di fornitori di servizi IT. Questi i

tre tipi fondamentali:

Internal Service Provider. E’ il caso tipico delle organizzazioni medio-piccole di

fornitore di servizi IT interno, ossia di CED. La focalizzazione è quella di trovare il

giusto bilanciamento fra gli interessi dell’intera organizzazione e quelli (spesso in

trade off) delle singole business units.

Shared Service Provider. E’ il caso in cui un insieme di funzioni di supporto (ovvero

non appartenenti al core business) vengono raggruppate in un’unit{ multi-servizio a

servizio dell’intera azienda (o di più aziende). Soluzione tipica: accorpamento di IT, HR

e Finance.

External Service Provider. E’ il caso in cui il provider di servizi IT è un’entit{

commerciale completamente distinta dall’azienda o dalle aziende che serve, operante

con proprio business sul mercato.

Va notato però che essi, se si parla di mera erogazione e gestione dei servizi IT hanno svariati

punti in comune, molto più di quanto avviene in termini di tipologia di relazione commerciale

col cliente, posizionamento sul mercato (che nel primo caso è assente o virtuale) e via

dicendo. Questo ha “autorizzato” ITIL a sviluppare un unico framework (centrato appunto

“solo” sul come gestire al meglio i propri servizi IT) anzichè una serie di framework per i

singoli casi.

2.6. Il ciclo di vita della fornitura dei servizi IT

L’erogazione di servizi ovvero il trasferimento di valore, ovvero l’attuazione di quanto

previsto nei service models è in pratica l’attivit{ ciclica e ordinaria di ogni IT Provider, la cui

“vita” corrisponde ad un esercizio continuo del service management e di tutto ciò che ne

consegue. Tale funzionamento ciclico poteva essere descritto anche in termini di attività di

reparti o unit{ organizzative ma ITIL, per enfatizzare l’importanza del coordinamento e

controllo trasversale a tali unit{, ha identificato come elementi costituenti tale “ciclo di vita”

(LIFECYCLE) dei processi (PROCESSES):

LIFECYCLE

o STAGES

PROCESSES

I processi (vedi di seguito) sono stati raggruppati in fasi o STAGES, ossia gruppi con

caratteristiche simili. Gli stages identificati da ITIL sono stati questi:

Code Stage Description

Cosa fa

SS Service Strategy

Spingere l’organizzazione a ampliare l’offerta e una gestione che sia vantaggio competitivo

SD Service Design

Progettare i nuovi servizi per soddisfare i requisiti ed essere ottimali da mettere in produzione ed essere gestiti quotidianamente.

ST Service Transition

Introdurre i nuovi servizi minimizzando tutti i potenziali impatti negativi connessi a tale introduzione

SO Service Operation

Far funzionare normalmente i servizi introdotti, misurarli, gestire il rapporto quotidiano con gli utenti

CSI Continual Service Improvement

Capire dove migliorare e spingere tutta l’azienda nel “mantenere lo slancio”.

Il modo in cui gli stages interagiscono può essere cosi rappresentato:

Lo schema è indicativo. Varie note: non rappresenta la retroazione (CSI verso tutte le altre

fasi), non illustra il contributo di interni e fornitori anche alle altre fasi diverse della SO etc...

D{ però un’idea di massima di un ciclo che parte dai bisogni dei clienti e dalla vision, si

traduce in requirements (di nuovi servizi) poi in risultati della progettazione (SDP) e infine in

servizi testati, consegnati e operanti a regime.

Lo schema di cui sopra nasconde (all’interno degli stages) i processi che sono l’unit{ che ITIL

sostanzialmente ha scelto, insieme ai ruoli e alle funzioni per fare la sua descrizione del

lifecycle (in pratica in ITIL abbiamo una descrizione di processi, funzioni e ruoli e loro

interazioni più di fasi e loro interazioni come nel diagramma di sopra, perchè questo

risulterebbe semplicistico e collegato ad una visione scorrettamente sequenziale).

2.7. Processi

Definizione: Un processo (PROCESS) è un insieme strutturato di attività concepite per

ottenere uno specifico obiettivo che trasforma un insieme di input in un insieme di output.

La definizione è per molti versi semplicistica dato che il termine “attivit{” si porta dietro

svariati altri concetti. Inoltre è da considerare che l’output sia (sempre) connesso alla

produzione di qualche valore (altrimenti si avvalorerebbero processi inutili...). Tenendo conto

di tutto ciò possiamo aggiungere che un processo:

ha i propri elementi abilitanti (nella produzione del valore): resources e capabilities;

è basato sulle persone quindi su insiemi di ruoli, procedure, istruzioni di lavoro

oltre che agli input (ciclici) può rispondere anche a determinati eventi esterni

denominati TRIGGERS;

ha propri meccanismi di controllo (metriche) e di miglioramento basati sull’approccio

closed lood (FEEDBACKS);

Mettendo tutto ciò in termini di definizione ITIL afferma che tutti i processi sono:

Misurabili;

Producono specifici risultati;

Hanno come risultato principale il trasferimento di valore a un cliente o stakeholder;

Rispondono ai propri triggers;

Sembrerebbe rimasto escluso il discorso delle persone. In realtà è solo perchè ITIL gli

dedicata un capitolo a parte, quello dei ruoli.

2.8. Ruoli

Un processo, come detto, vede sempre impegnate delle persone. Il tutto è espresso con

l’ausilio del concetto di ruolo (ROLE) definito come “insieme di responsabilit{ e autorit{

assegnate a una persona o a un gruppo”. Per come è definito il ruolo, una persona può avere

più di un “cappello” (ruolo) in azienda e un ruolo può corrispondere o no a titoli di lavoro,

livelli di inquadramento etc... ITIL associa all’insieme process + servizio erogato quattro

tipologie di ruoli:

PROCESS OWNER

PROCESS MANAGER

PROCESS PRACTITIONER

SERVICE OWNER

In particolare, compiti e responsabilità tipiche dei ruoli in oggetto sono descritti in questa

tabella:

Ruolo Descrizione Attività Valutabile PROCESS OWNER

Responsabile Generale (tipo project sponsor)

Definizione strategia di processo;

Definizione politiche e standard cui attenersi;

Definizione di KPI e verifiche

Input al design di un (nuovo) processo

Tutte le attività del processo

PROCESS MANAGER

Responsabile Operativo (tipo project manager)

Conduzione delle attività

gestione del personale e delle risorse

Monitoraggio e reporting

Tutte le attività operative

PROCESS PRACTITIONER

Operativo Lavoro connesso alle attività

Raccolta dati e/o misurazioni

Una a più attività a lui assegnate

SERVICE OWNER

Interfaccia Cliente Primo contatto del cliente

Negoziazione dei livelli di servizio

Monitoraggio del servizio

Espressione delle richieste di cambiamento (percezione customer needs).

Rapporto col il cliente per uno fra i vari servizi prodotti dal processo

Tutti i ruoli in questione sono considerati coinvolti attivamente (anche se non scritto in

tabella) nel fornire elementi utili per il miglioramento continuo del processo.

Il modo in cui processi e ruoli si combinano fra di loro è in genere illustrato con opportune

“matrici di autorit{” (AUTORITHY MATRIX) di cui l’esempio principale è la cosiddetta RACI.

Questa, dato un certo processo, per tutti i vari stakholder coinvolti mostra la loro condizione

di:

RESPONSIBLE, Responsabile operativo (Process Manager)

ACCOUNTABLE, Responsabile generale (Process Owner)

CONSULTED, Fornisce assistenza/conoscenza (simile a Process Practictioner)

INFORMED, Necessita Informazioni (Service Owner e/o Customer)

La matrice è normalmente dettagliata a livello di singole attività e i ruoli a cui si fa riferimento

sono generici, non solo non legati a persone fisiche ma anche non legati ad unità

organizzative, come ad esempio “sistemista hardware”. Questo consente:

di descrivere i processi a prescindere dai cambiamenti di organigramma;

di evidenziare la necessità dei processi di profili di tipo (e area organizzativa di

appartenenza) diverso;

Per ogni attività deve esserci obbligatoriamente uno e un solo ruolo ACCOUNTABLE e uno e

un solo ruolo RESPONSIBILE. Ecco un esempio (fatto da me) di matrice RACI per un processo

di Sviluppo Personalizzazione Software gestito da una piccola azienda IT:

Key Account

Capo Progetto

Sviluppatore Tester

Micro Analisi RA Sviluppo I C RA Test A C R Rilascio I A R

La RACI-VS è da considerarsi una versione estesa della più tradizionale matrice RACI,

particolarmente adattabile in caso di organizzazioni complesse. Essa prevede l'introduzione

di 2 ulteriori ruoli:

VERIFIER, colui che verifica che il deliverable rispetti i criteri di accettazione.

SIGNATORY, colui che approva la decisione del Verifier.

2.9. Funzioni

Le persone in azienda, pur partecipando ai vari processi (ovvero alle attività cicliche di varia

natura) secondo vari ruoli sono organizzate in unità organizzative (FUNCTIONS). Il

framework ITIL definisce per un IT Service Provider 4 funzioni fondamentali, ovvero:

Service Desk

Operation Management

Application Management

Technical Management

Da notare che queste sono associate nella trattazione alla sola fase di SO e la cosa è da

intendere così: un IT provider o un CED ha “sempre” 4 reparti (SD, OM, AM, TM) che si

occupano principalmente di attivit{ ordinarie legate ai sistemi informativi e/o all’erogazione

di servizi informatici (ovvero di IT service operations). Il personale di tali reparti è poi lo

stesso che, insieme ad altre funzioni aziendali se necessario (ragioneria, legale, contratti etc...),

si occupa occasionalmente o per una percentuale residuale del suo tempo (ecco la mancanza

di una associazione diretta ad esempio fra SS e una function) di attività relative a strategia,

progettazione, miglioramento continuo. Anche se è ovvio che partecipa anche a service

strategy, design, transition, continual service improvement.

Da notare inoltre che facendo riferimento ai soli ruoli principali, questi si possono vedere

come sottoinsiemi delle funzioni, con i processi che finiscono per tagliare trasversalmente il

diagramma. Così un grafico come il precedente, scritto per il processo “A” spiega bene il

rapporto fra i concetti di processo, funzione e ruolo:

2.10. Automazione e gestione dei servizi IT

L’automazione in generale nei processi di business consente di raggiungere migliore

performance: questo vale anche per l’erogazione di servizi IT che quindi con la giusta

automazione riescono a produrre maggiori utility e warranty e quindi generare più valore. Le

principali aree in cui l’automazione può migliorare notevolmente le cose sono identificate da

ITIL come le seguenti:

Monitoraggio e Misure

Generazione automatica di alert

Tool diagnostici e di analisi/aggiornamento delle configurazioni

Strumenti di modellazione e simulazione

Strumenti di Workflow

Artificial Intelligence (root cause analysis, scheduling, control systems...)

L’automazione è poi fondamentale per ottenere una elevata integrazione fra processi diversi,

migliorando efficienza, coerenza, comunicazione, riduzione di errori e duplicazioni etc...

2.11. Ciclo di Deming

Il ciclo di Deming fu introdotto a W. Edwards Deming come metodo per il miglioramento

qualitativo continuo. L’idea è che i processi (per definizione) possono essere misurati sia nel

loro stato attuale, sia dopo che sono stati modificati. Questo permette di misurare

oggettivamente non solo i processi ma anche il miglioramento e definire una sequenza

(ciclica, perché una volta raggiunto l’ultimo passo si riparte con nuovi obiettivi di

miglioramento e col primo passo) per ottenere miglioramento di validità universale. La

sequenza è celebre:

PLAN, Improvement Project Plan

DO, Improvement Project Execution

CHECK, Audit

ACT, New operational mode

A causa di questi passi il ciclo è detto anche PDCA. Note:

Differenza DO vs ACT. Il primo sarebbe propriamente riferito al fare le modifiche. Il

secondo al fare nel senso di operare nel nuovo modo.

Il modello prevede che dopo ogni “giro” (il libro dice fase, pag. 203, ma non sembra

aver troppo senso) ci sia un periodo di consolidamento per garantire che i

miglioramenti siano assimilati e per assicurarsi che siano nel medio termine

effettivamente i risultati voluti;

2.12. Misure, Metriche, KPI e CSF

La misura (o misurazione, cioè l’atto di misurare) è un prerequisito indispensabile al

miglioramento. Solo con la misurazione si può mostrare dove siamo (as is) e se i cambiamenti

voluti (to be) hanno prodotto i risultati voluti. In modo più preciso ITIL definisce in quattro

punti l’utilit{ della misurazione:

dimostrare che un’operazione o servizio si comporta (o non si comporta) come

dovrebbe e in particolare in accordo con i requisiti stabiliti;

provare ad uno stakeholder che ha effettivamente ricevuto (o non ha effettivamente

ricevuto) ciò che ha richiesto o per cui ha pagato;

confrontare la performance di un servizio con quella di un altro (benchmarking);

stabilire uno stato di riferimento che rappresenti la situazione corrente, rispetto alla

quale esprimere come variazioni i comportamenti futuri

L’oggetto dell’attivit{ di misurazione sono le cosiddette metriche (METRICS) che ITIL

definisce come cose che possono essere misurate e comunicate utili per gestire processi,

servizi o attività.

Abbiamo parlato anche di stati di riferimento (BASELINES). Una baseline è appunto una

fotografia di una situazione che (ITIL)

fornisce un punto di riferimento rispetto al quale dimostrare i futuri miglioramenti;

permette di misurare la salute di un processo, servizio, operazione per vedere se

necessita attenzioni;

Le baseline possono essere stabilite a livello strategico, tattico o operativo e all’inizio possono

essere difficili da misurare con accuratezza.

Tornando alle metriche ITIL le suddivide in tre tipologie:

Metriche di tipo tecnologico (TECHNOLOGY METRICS). Sono quelle utilizzate in genere

solo all’interno del provider per studiare ad esempio la capacità di un componente. Es.

MTBF;

Metriche di processo (PROCESS METRICS). Sono quelle utilizzate per capire se un

processo è conforme o no a procedure documentate. Sono anch’esse di utilizzo

prevalentemente interno e sono impiegate soprattutto per identificare opportunità di

miglioramento o esiti di processi di miglioramento. Es: Percentage of failed Changes.

Metriche di servizio (SERVICE METRICS). Sono utilizzate nei report di performance

diretti ai clienti finali. Es.: Percentuale di Disponibilità nella connessione internet

l’ultimo mese;

A prescindere dalla loro natura poi, ci sono metriche più importanti di altre: i cosiddetti KPI

(KEY PERFORMANCE INDICATORS). Essi sono metriche più importanti perché si riferiscono

non a (generiche) performance ma al raggiungimento di obiettivi (GOALS), ovvero in altri

termini al raggiungimento di fattori critici di successo.

Un CRITICAL SUCCESS FACTOR (CSF) è un’area di attivit{ critica per il successo di un’impresa.

I CSF sono in genere pochi in numero ed elevati in termini di importanza e sono assegnati e

manager di alto livello e/o senior.

Per concludere e tornare ai KPI, essi, appunto in quanto legati ai CSF sono pochi in numero e

pesanti in termini di importanza. Sono tipicamente espressi in termini di due o più metriche e

in termini significativi per il cliente o l’alta direzione. Esempio: Numero di incidenti risolti e

Numero di incidenti totali sono metriche. Percentuale di Risoluzione = Numero Incidenti

Risolti/Numero Incidenti Totali è un KPI.

Alcuni elementi di ausilio nella scelta delle metriche che:

Dovrebbero incoraggiare i corretti comportamenti;

Dovrebbero essere significative per chi le riceve in un performance report;

Non dovrebbero essere ambigue;

Attenzione inoltre a questi fatti:

Più è lungo il periodo, più è facile raggiungere un obiettivo (99% di disponibilità in 100

giorni è 1 giorno intero di fermo);

Nei report interni focalizzarsi sull’eccezione piuttosto che sulle conformità (le

eccezioni sono opportunità di miglioramento);

Quando c’è un’eccezione è fondamentale spiegarne le cause e includere possibili azioni

per evitare future eccezioni;

Quando si esegue un benchmarking occorre che i due termini di paragone siano

costruiti sulle solite basi (es. che senso ha confrontare il tasso di assenza di personale

con contratti diversi?)

I grafici (CHARTS) sono utili ma si prestano facilmente a distorsioni

visive/comunicative (es. scelta del range dell’asse Y);

Un report raggiunge il suo massimo potenziale esplicativo se contiene sia numeri che

grafici che spiegazioni testuali (e non ad esempio solo due fra questi tre elementi);

2.13. Le gestione del rischio

Viene definito rischio (RISK) un possibile evento che può causare danno o perdita o può

influire sull’abilit{ di raggiungere obiettivi. ITIL prevede un metodo di gestione dei rischi

denominato M_o_R (Management of Risk) pubblicato a parte come best practice, basato sui

seguenti step:

Analisi del Rischio. Identificare le possibili minacce a beni o servizi e stimare i relativi

valori di probabilità e impatto.

Gestione del Rischio. Fare qualcosa sul rischio analizzato. Il qualcosa rientra o è una

combinazione fra le seguenti opzioni:

o Accettazione del Rischio (es. prevedere fondi adeguati da usare al bisogno)

o Trasferimento del Rischio (es. uso di assicurazioni o outsourcing)

o Riduzione del Rischio (es. agendo su probabilità e/o impatto)

o Eliminazione del Rischio (quando possibile)

Che sia il M_o_R o un altro framework comunque ITIL consiglia fortemente di aver sviluppato

preventivamente un qualche modo strutturato di analizzare e gestire i rischi e di non provare

a risolvere il danno nel momento in cui si manifesta.

2.14. Il concetto di governance

Il termine GOVERNANCE tradotto in Italiano sarebbe “governo” o meglio “governo in senso

debole” basato, cioè, sul rapporto fra entit{ che almeno in parte agiscono in condizioni di

assenza di vera e propria subordinazione.

Riguardo alla IT governance ITIL afferma che “lo standard internazionale è la norma ISO/IEC

38500:2008”. Tale norma ha elencato sei principi base su cui fondare un “buon governo dei

servizi IT”: responsabilit{, acquisizione, performance, conformance e fattore umano,

rendendo dunque chiaro che “la governance IT è qualcosa di molto di più che il controllo dei

processi IT” di cui si occupa ITIL.

3. Fasi e relativi processi e funzioni

3.1. La fase del Service Strategy

E’ una fase caratterizzata da due componenti fondamentali.

La prima è quella di “offrire servizi migliori dei competitor”. Rientrano in questa tutto il ruolo

“attivo” di spingere l’organizzazione a fare nuovi investimenti, a introdurre nuovi servizi a

catalogo.

La seconda componente è legata al “trasformare la gestione dei servizi in bene strategico” (“to

develop service management as a strategic asset”). Il concetto è un pò più fumoso e merita

spiegazioni. Bene strategico (STRATEGIC ASSET) è definito come un bene che fornisce le basi

per le competenze aziendali distintive (CORE COMPETENCE), quelle cioè su cui si fonda il suo

vantaggio competitivo. Dunque la fase del service strategy non spinge solo l’organizzazione a

offrire nuovi servizi ma anche a indirizzarla ad una gestione sempre migliore, in modo che

anche per questa sua caratteristica il cliente la scelga, al di là della mera offerta. In tutto

questo rientra ovviamente anche la comprensione del mercato e dei clienti e la comprensione

che il vero valore è dato non solo dagli strategic assets propri ma, più precisamente, dalla

positiva interazione fra i propri e quelli del cliente:

Il tutto senza mai dimenticare la “marketing mindset” : l’idea che è forse più importante la

percezione del valore del valore quantificabile.

Notiamo che la fase del SS è relativa alla strategia. Ma cosa vuol dire “strategia”? Il suo

significato è in realt{ multiplo e ben spiegato dalla “regola delle 4P”:

PERSPECTIVE, Prospettiva. La strategia come Prospettiva è intesa come elaborazione

della vision, dell’idea di business a cui si vuole arrivare;

POSITION, Posizionamento. La strategia come Posizionamento è intesa come il modo

con cui si vuole caratterizzare la propria offerta di servizi (es. alto valore o basso costo,

enfasi sull’utilit{ o sull’affidabilit{ etc...);

PLAN, Piano. La strategia come Piano è intesa come insieme di scelte per trasformare

quello che c’è oggi in un qualcosa che ancora non esiste ma che è ben individuato;

PATTERN, Schema. La strategia come Schema, ossia come insieme coerente di regole

sulla base delle quali prendere decisioni;

La fase della SS è evidentemente (come tutto ITIL) centrata sui servizi (SERVICES). Concetti

utili sono però anche quello di insiemi di servizi (SERVICE PACKAGE) insiemi di possibili

configurazioni di livelli di servizio (SERVICE OPTIONS ovvero SERVICE LEVELS PACKAGE).

Ecco la tabella riepilogativa dei key processes:

Ph Code Description Cosa fa SS BRM Business

Relationship Management

mantenere una relazione produttiva con il cliente, focalizzandosi sugli aspetti di convergenza strategica

SS SPM Service Portfolio Management

mantenere e spingere per lo sviluppo di un portafoglio che dia un’immagine completa

dei vari servizi e del loro stato (pipeline, catalogue, retired)

SS FM Financial Management for IT Services

assicurare l’uso ottimale delle risorse finanziarie dell’organizzazione

SS DM Demand Management

capire la domanda di servizi da parte dei clienti e rendere attraverso ciò ottimale l’uso della capacità

SS SM Strategy Management

3.2. La fase del Service Design

E’ la fase in cui il servizio viene concretamente progettato: si prendono cioè tutti i passi per

assicurarsi che sia ben gestibile la sua introduzione (ST) e il suo funzionamento ordinario

(SO) nonchè la sua misura continua. Non solo, comunque: le esigenze di business cambiano

nel tempo, quindi è questa la fase che è responsabile di pensare ai cambiamenti necessari da

attuare nei servizi durante tutto il loro ciclo di vita, contribuendo all’identificazione dei

possibili rischi connessi ai cambiamenti e al miglioramento continuo.

Il service design conclude il suo lavoro passando alla fase del Service Transition il cosiddetto

SERVICE DESIGN PACKAGE (SDP), insieme di documenti che copre tutti gli aspetti del nuovo

servizio da attivare o re-ingegnerizzare.

Anche la fase del SD ha le sue 4P, ovvero i suoi quattro elementi cardine, ossia:

PEOPLE, Persone

PROCESSES, Processi

PRODUCTS, Prodotti

PARTNERS, Partners

A complicare un pò il quadro concettuale ITIL “formalmente riconosce cinque separati aspetti

che descrivono l’ambito del SD”. Si parla dei MAJOR ASPECTS of the SCOPE of SD ed essi sono:

Identificazione di requisiti di business e requisiti concordati col cliente;

Utilizzare strumenti di gestione dell’informazione che assicurino la consistenza dei

servizi introdotti con il portafoglio esistente;

Assicurare che l’infrastruttura tecnologica (nuova o modificata) sarà in grado di

sostenere i nuovi servizi;

Assicurare che l’infrastruttura organizzativa (processi) sia in grado di erogare

contemporaneamente sia i vecchi servizi che i nuovi;

Identificare le appropriate metriche e strumenti di misura necessari per l’analisi delle

performance e il miglioramento continuo dei servizi introdotti;

Ecco la tabella riepilogativa dei key processes:

Ph Code Description Cosa fa SD DC Design

Coordination assicurare che tutte le attività di progettazione (design) siano consistenti e coordinate. Produrre il SDP.

SD SCM Service Catalogue Management

sviluppare e mantenere un catalogo aggiornato dei servizi che rispettino le caratteristiche convenute

SD SLM Service Level Management

sviluppare e negoziare i gli accordi sui livelli di servizio (SLA) con i clienti. allineare l’offerta con la domanda

SD CM Capacity Management

assicurare che vi siano abbastanza risorse per soddisfare i bisogni presenti e futuri del business

SD AVM Availability Management

identificare ed eliminare le cause correnti o potenziali di indisponibilità dei servizi in modo coerente con gli obiettivi costi/benefici. Ipotesi di condizioni normali.

SD ITSCOM IT Service Continuity Management

assicurare che il ripristino di sistemi e servizi a seguito di incidenti (non ancora presentatisi ma che ragionevolmente potrebbero farlo) avvenga entro i tempi stabiliti

SD ISM Information Security Management

definire la politica di sicurezza relativa ai principali asset IT quali dispositivi e db interni, email, internet, accessi remoti etc...

SD SM Supplier Management

gestire i fornitori e i relativi contratti di subfornitura (Underpinning Contracts) in un’ottica di relazione di lungo termine

Da notare che nel libro (pag. 120) ISM e ACCM sono trattati insieme anche se viene

chiaramente detto che il primo processo si riferisce alla SD, il secondo alla SO.

3.3. La fase del Service Transition

E’ la fase con cui ci si (ri)assicura che tutto sia stato adeguatamente considerato e funzioni nel

modo corretto e in cui si porta il servizio fino all’ambiente di produzione (LIVE

ENVIRONMENT), regno della successiva fase di service operation. Da notare che le attività

preparatorie non sono solo interne ma hanno un grosso impatto sul cliente quello che da un

certo punto di vista più di ogni altro “subisce” la transizione dai vecchi sistemi ai nuovi.

Definizioni fondamentali legati alla fase di transizione:

CHANGE: è l’aggiunta, la modifica o la sostituzione di un qualunque elemento che può

impattare i servizi IT

RELEASE: è un insieme di più cambiamenti che sono assemblati (BUILT), testati e

consegnati (DEPLOYED) insieme. Può riguardare hardware, software, documentazione

etc....

DEPLOYMENT: è l’attivit{ responsabile dello spostamento di un processo o un

componente nell’ambiente di produzione (LIVE ENVIRONMENT)

In pratica la fase del Service Transition parte con la ricezione del SDP dalla Service Design o

dalle RFC dalla Service Operation, segue tutto ciò che va dall’assemblaggio al test, alla gestione

del transitorio (es. parallelo fra vecchi e nuovi servizi), all’introduzione nella gestione a

regime.

Tutto questo include la minimizzazione di tutti gli eventuali impatti non previsti, la gestione

delle comunicazioni, della formazione e il trasferimento di conoscenza oltre ovviamente alla

solita gestione complessiva che assicuri il rispetto del triplice vincolo (tempi, costi, qualità).

Una precisazione va fatta sui test, un’attivit{ che trova il suo contesto principale nella ST. Qui a

proposito della attivit{ di “service validation and testing” si dice che il suo scopo è “to ensure

that a new or changed service and its associated release process will meet the needs of the

business at the agreed costs”. Fra le altre fasi quella più interessata ai test è la SD ma questa li

pianifica soltanto per la ST (appunto).

Ecco la tabella riepilogativa dei key processes:

Ph Code Description Cosa fa ST SACM Service Asset and

Configuration Management

mantenere le informazioni sui vari Configuration Items (Asset Management) e sulle relazioni che li legano (Configuration Management).

ST KM Knowledge Management

assicurare che le persone giuste abbiano le conoscenze giuste al momento giusto combinando i dati del CMS con esperienze e skills

ST TPS Transition Planning and Support

pianificare e coordinare in termini di attività e risorse il passaggio alla normale attività dei servizi assicurando che i requisiti progettati siano ottenuti nel normale funzionamento. Ambiti applicativi principali: SPD e cambiamenti concorrenti.

ST CHM Change Management

assicurare che tutti i cambiamenti (RFC) siano gestiti attraverso metodi e procedure standard in modo efficace e secondo i tempi e i risultati prestabiliti

ST RDM Release and Deployment Management

assemblare (BUILD), testare e rilasciare i nuovi servizi nell’ambiente di produzione nei tempi previsti e con minime interruzioni dei servizi esistenti

ST SVT Service Validation and Testing

assicurare che un servizio nuovo o modificato sia conforme alle esigenze di business ai costi stabiliti

ST CE Change Evaluation

valutare se la performance ottenuta col il cambiamento è accettabile o no (effetti voluti vs inattesi, giudizio stakeholders)

Ci sono poi le seguenti attività:

Ph Code Description Cosa fa ST MOSC Management of

Organisation and Stakeholder Change

monitorare e gestire efficacemente i cambiamenti e portare le loro implicazioni all’attenzione degli stakeholders coinvolti e/o rilevanti

Alcune definizioni caratteristiche di questo stage (e in particolare di SACM):

Il concetto di partenza è il CONFIGURATION ITEM (CI) definito come un qualunque

componente che necessita di essere gestito per erogare (DELIVER) un IT Service. Un CI può

essere un servizio, un processo, un documento, uno SLA, un componente hardware, software,

un edificio, una persona etc... Compito dell’Asset Management è quello di mantenere le

informazioni sui vari CI (dato che i CI sono un sottinsieme degli Assets: quelli che hanno

impatto diretto nella produzione dei servizi).

Fra i vari CI un ruolo speciale ce l’hanno i software e le licenze che dovrebbero poter essere

utilizzati in produzione solo se la corrispondente versione è stata approvata (attività che

costituisce una fra le tipiche del SACM). ITIL prevede l’utilizzo di uno o più locazioni fisiche

dove contenere in modo sicuro tutti questi software approvati, denominati DEFINITIVE

MEDIA LIBRARY (DML). Un armadio con lucchetto con dentro CD, nastri e simili rende

abbastanza bene il concetto di DML.

Il processo di Configuration Management sfrutta i CI per esprimere in termini di questi e delle

loro relazioni i servizi prodotti ovvero “fornisce un modello di configurazione”

(CONFIGURATION MODEL) per i servizi in questione.

Normalmente il processo SACM è supportato da (e alimenta) un adeguato sistema informativo

detto CONFIGURATION MANAGEMENT SYSTEM (CMS). Questo include strumenti per

raccogliere, memorizzare, aggiornare, analizzare e presentare dati su tutti i CI e sulle loro

relazioni e viene tecnologicamente ottenuto attraverso uno o più CONFIGURATION

MANAGEMENT DATABASE(S) (CMDB).

3.4. La fase del Service Operation

E’ la fase cui è associata l’attivit{ aziendale corrente (BUSINESS AS USUAL) ed è quella in cui il

valore (VALUE), definito in SS e confermato in SD e ST viene concretamente e ciclicamente

erogato. Più formalmente si può dire che il suo proposito è di organizzare e condurre le

attività e i processi necessari per erogare i servizi ai clienti secondo i convenuti accordi sui

livelli di servizio (SLA).

E’ una fase caratterizzata dal bilanciamento fra vari elementi. Ecco una rassegna dei principali

trade off:

INTERNAL VIEW vs EXTERNAL BUSINESS VIEW. Internamente il service provider si

percepisce come un insieme di componenti mentre esternamente è visto come insieme

di servizi erogati.

STABILITY vs RESPONSIVENESS TO CHANGES. La stabilità tende a minimizzare

incidenti e problemi di disponibilità ma tende anche a scollegare sempre di più il

servizio erogato dai bisogni del business che variano in continuazione.

QUALITY vs COSTS. Troppa focalizzazione sulla qualità erogata porta i costi a crescere

a dismisura. Troppa focalizzazione sui costi rende non più appetibili i servizi erogati.

REACTIVITY vs PROACTIVITY. Una organizzazione troppo reattiva spende troppo

tempo nel combattere il fuoco, trascurando ciò che gli permetterebbe di ottenere lo

stesso risultato con molta meno fatica: cercare di prevenirlo. Viceversa un

orientamento eccessivo alla proattività crea organizzazioni inutilmente iper-

monitorate e soprattutto sequenze ininterrotte di cambiamenti inutili.

In poche parole si può dire che tutto quanto attiene alla fase di SO è “la faccia visibile dell’IT

Provider ed è la più vicina a utenti e clienti”.

Per questo motivo ha un ruolo decisivo in essa una buona gestione delle comunicazioni fra IT,

business e utenti. Essa deve avvenire su basi regolari, contenere la giusta quantità di

informazioni ed essere formulata in un linguaggio adattato alla comprensione del

destinatario.

La fase del SO è associata a una serie di key processes, questi:

Ph Code Description Cosa fa SO RF Request

Fulfilment è la gestione delle richieste (REQUESTS) da parte degli utenti ovvero di tutte le chiamate che non sono relative a INCIDENTS.

SO IM Incident Management

è la gestione degli INCIDENTS ed ha l’obiettivo di ripristinare il normale servizio più velocemente e con il minor impatto possibile.

SO PM Problem Management

è la gestione dei PROBLEMS che comprende tutte le attività che vanno dalla determinazione della ROOT CAUSE fino alla risoluzione e al rilascio del cambiamento

SO EM Event Management

è il monitoraggio di tutti i cambiamenti di stato importanti (EVENTS) relativi a servizi o CI, a segnalazione manuale o automatica

SO ACCM Access Management

gestione dei diritti delle persone di accedere alle informazioni, ovvero gestione materiale di confidenzialità, integrità e disponibilità delle informazioni

Qui è importante tenere presenti queste definizioni:

EVENT: E’ un cambiamento di stato significativo nella gestione di un servizio o di un

componente. L’evento corrispondente al raggiungimento di una soglia notificato in

modo automatico si chiama ALERT.

INCIDENT: E’ una interruzione non pianificata di un servizio IT o una riduzione

altrettanto non pianificata del suo livello di qualità o un generico guasto di un

componente (CI) anche se non impatta sul servizio erogato.

PROBLEM: E’ la causa (ROOT CAUSE) di uno o più INCIDENT. Fra i problemi alcuni

hanno cause ben documentate o WORKAROUND (modi di ripristino delle funzionalità

che non intervengono sulla root cause) noti: sono detti KNOWN ERROR.

REQUEST: E’ una richiesta (detta anche SERVICE REQUEST) da parte di un utente di

informazioni, consigli o di cambiamenti standard (STANDARD CHANGE) ovvero pre-

approvati comuni e a basso rischio collegati a procedure operative standard.

Vi sono associate poi anche delle functions:

Ph Code Description Cosa fa SO SD Service

Desk E’ una funzione che costituisce il SINGLE POINT OF CONTACT per gli utenti del provider di servizi IT per attività come: segnalazione di incidenti o eventi, inoltro di richieste di dati e introduzione/modifiche di servizi.

SO OM Operation Management

E’ la funzione che assicura la gestione ordinaria o quotidiana di tutta l’infrastruttura IT. Direi si possa assimilare a gestione hardware e sala macchine.

SO AM Application Management

E’ la funzione che assicura la gestione ordinaria di tutti i software applicativi e che è responsabile del relativo ciclo di vita (design, testing, miglioramento continuo).

SO TM Technical Management

E’ la funzione che provvede alla gestione ordinaria di tutto il personale tecnico collegato al provider di servizi IT. Include il garantirne l’adeguato aggiornamento e l’effettiva efficacia.

3.5. La fase del Continual Service Improvement

Una volta che un servizio o un insieme di servizi sono stati attivati è essenziale non sedersi e

pensare che il lavoro è stato già fatto. Tutto il contesto esterno e interno relativo al service

provider cambia continuamente e il fornitore di servizi deve monitorare ciò continuamente

alla ricerca di opportunità di miglioramento. La fase del CSI è dunque quella responsabile

dell’identificazione e dell’impulso strutturato alla realizzazione di queste opportunità man

mano che esse emergono dai continui mutamenti del contesto interno ed esterno.

Migliorare certo, ma cosa? Lo SCOPE del CSI individuato da ITIL copre fondamentalmente tre

ambiti:

Efficienza ed Efficacia (“Health”, pag. 46) della gestione manageriale (“service

management as a discipline”);

Riallineamento dell’offerta (Service Portfolio, SIP) con le presenti e future esigenze di

business;

Maturit{ nell’applicazione dei processi IT (come fonte di efficienza)

ITIL identifica per la fase di CSI sei passi, così descrivibili:

La cosa curiosa è che al netto di questi SEI passi alla fase corrisponde un unico processo a

SETTE passi, detto appunto “Seven Step Improvement Process” i cui sette passi corrispondono

più o meno ai passi 1-4 del precedente schema anche se con un livello maggiore di dettaglio.

Abbiamo quindi che la tabella dei key processes in questo caso si presenta così:

Ph Code Description Cosa fa CSI SSIP Seven Step

Improvement Process

elabora una metodologia ripetibile per l’ottenimento del miglioramento continuo in ogni fase del ciclo di vita e offre il supporto necessario per la sua applicazione e revisione