Esame ITIL Foundations - Basi

--- 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;

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).
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à:
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:
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:
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ì:
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

Esame ITIL Foundations - Basi

Recommended

Recommended

More Related Content

Similar to Esame ITIL Foundations - Basi

Similar to Esame ITIL Foundations - Basi (20)

Esame ITIL Foundations - Basi