Sei sulla pagina 1di 71

Sommario

Il Campo di applicazione e Politiche di Service Transition...............................................6


1.

Obiettivi formativi..............................................................................................................................6

2.

Ambito di Service Transition.............................................................................................................6

3.

Le politiche di transizione di servizio................................................................................................9

15. Riepilogo............................................................................................................................................16
16. Sommario..........................................................................................................................................16
Asset Transition, Servizio di supporto, e test................................................................16
1.

obiettivi formativi...........................................................................................................................17

2.

Pianificazione Transizione................................................................................................................17

3.

Service Asset and Configuration Management...............................................................................19

4.

Validazione e test...............................................................................................................................22

5.

Riepilogo............................................................................................................................................24

6.

Sommario..........................................................................................................................................24

Stampa e distribuzione gestione a Service Transition..................................................25


1.

Obiettivo di apprendimento.............................................................................................................25

2.

Ambito di applicazione e finalit.....................................................................................................25

3.

Le quattro fasi...................................................................................................................................27
Uscita e la distribuzione di pianificazione.................................................................27
Costruzione di uscita e il test................................................................................... 28
Distribuzione........................................................................................................... 28
Review e vicino....................................................................................................... 29

4.

Riepilogo............................................................................................................................................30

5.

Sommario..........................................................................................................................................30

Cambio gestione........................................................................................................... 31
1.

obiettivi formativi.............................................................................................................................31

2.

Finalit e campo di applicazione......................................................................................................31

3.

tipi di modifica di servizio................................................................................................................33

4.

interfacce Change Management......................................................................................................36

5.

Riepilogo............................................................................................................................................39

6.

Sommario..........................................................................................................................................39
1

Normali e di emergenza Variazioni Change Management............................................40


1.

obiettivi formativi.............................................................................................................................40

2.

il cambiamento del ciclo di vita normale.........................................................................................40

3.

cambiamento del ciclo di vita di emergenza...................................................................................44

4.

Riepilogo............................................................................................................................................47

5.

Sommario..........................................................................................................................................47

La gestione dei servizi IT Modifiche.............................................................................. 48


1.

obiettivi formativi.............................................................................................................................48

2.

panoramica esercizio........................................................................................................................48

3.

Riconoscere tipi di cambiamento.....................................................................................................48

4.

Riconoscendo le azioni del ciclo di vita del cambiamento..............................................................49

5.

Riepilogo............................................................................................................................................51

6.

Sommario.........................................................................................................................................52

Cambio di valutazione.................................................................................................. 53
1.

Obiettivo di apprendimento.............................................................................................................53

2.

Obiettivi cambiamento di valutazione.............................................................................................53

3.

Benefici e sfide...................................................................................................................................55

4.

Riepilogo............................................................................................................................................57

5.

Sommario..........................................................................................................................................57

Knowledge Management nel Service Transition...........................................................58


1.

Obiettivo di apprendimento.............................................................................................................58

2.

Ambito di applicazione e finalit................................................................................................58

3.

Struttura DIKW..............................................................................................................................60

4.

Riepilogo............................................................................................................................................62

5.

Sommario..........................................................................................................................................62

Comprendere processi di transizione di servizio...........................................................63


1.

Obiettivi formativi............................................................................................................................63

2.

Panoramica esercizio........................................................................................................................63

3.

Riconoscendo politiche di transizione di servizio...........................................................................63

4.

La gestione e la distribuzione di rilascio.........................................................................................66

5.

Riconoscendo la struttura DIKW....................................................................................................69

6.

Identificare attivit...........................................................................................................................70
2

7.

Riepilogo............................................................................................................................................73

8.

Sommario..........................................................................................................................................73

Il Campo di applicazione e Politiche di Service


Transition
1. Obiettivi formativi
Dopo aver completato questo argomento, si dovrebbe essere in grado di

riconoscere la portata del servizio Transition

descrivere esempi di politiche di transizione di servizio


2. Ambito di Service Transition

Service Transition una fase del ciclo di vita del servizio illustrato nel Information Technology
Infrastructure Library (ITIL). E 'progettato per garantire che i servizi nuovi o modificati soddisfino
le aspettative di business documentati nelle fasi Service Strategy e Service Design del ciclo di vita.
I processi inclusi nella fase di Service Transition sono:

La pianificazione della transizione e il supporto


Change Management
Servizio Asset and Configuration Management (SACM)
Release e Deployment Management
La validazione del servizio e test
Valutazione del cambiamento
Service Knowledge Management.

Gli obiettivi del Service Transition sono

pianificare e gestire le modifiche di servizio efficiente ed efficace

gestire i rischi relativi a nuovi, modificati o servizi in pensione

distribuire con successo release di servizio in ambienti supportati

set appropriate aspettative circa le prestazioni e l'utilizzo di nuove o modificate servizi IT

assicurare che le modifiche di servizio creano il valore di business atteso, e

fornire informazioni accurate su servizi e attivit di servizio

Per raggiungere questi obiettivi, la fase di Service Transition deve includere


capacit e la pianificazione delle risorse
Durante Service Transition, a pianificare e gestire la capacit e le risorse necessarie per
gestire servizio transizioni, per garantire che i servizi possono essere messi in funzione in
modo efficace ed efficiente.
valutazione dei rischi
Durante la fase di Service Transition, si implementa un quadro di gestione del rischio per la
valutazione delle capacit di servizio e profili di rischio prima di nuovi o modificati servizi IT
vengono distribuiti.
servizio di gestione patrimoniale, e
Durante Service Transition, stabilire e mantenere l'integrit del patrimonio di servizio.
Service Lifecycle Supervisione
Per garantire che la transizione dei servizi va nel modo migliore possibile, si assicura che
non ci sono meccanismi efficienti in atto per la costruzione, il collaudo, e la distribuzione dei
servizi. inoltre necessario garantire che i servizi possono essere gestiti, gestiti e
supportati in conformit con vincoli specificati durante la fase di Service Design del Service
Lifecycle.
La fase di Service Transition include la pianificazione di rilascio, la costruzione, il collaudo, la
valutazione e l'implementazione di nuovi e cambiati i servizi IT. Esso comprende anche il
passaggio delle variazioni di capacit di gestione dei servizi del fornitore di servizi IT.
Il campo di applicazione comprende Service Transition

gestire la complessit associata con le modifiche ai servizi e processi di; gestione dei

servizi;

l'introduzione di nuovi servizi o di apportare modifiche ai servizi esistenti;

disattivazione e l'interruzione dei servizi, applicazioni o componenti di servizio se del caso;

trasferimento dei servizi da e verso altri fornitori di servizi IT - per esempio, a causa di
cambiamenti in outsourcing, l'uso di co-sourcing, o fusioni aziendali.
L'unit per il miglioramento continuo del servizio richiede il processo di Change Management, che
prevede l'autorizzazione per l'introduzione di nuovi servizi o per modificare quelli esistenti. Questo
processo seguito da SACM, durante il quale le linee di base vengono catturati e registrati.

Grafico
Un diagramma illustra il contesto in cui si verifica la fase di Service Transition. A partire con
Continual Service Improvement, Change Management fornisce l'autorizzazione per le
modifiche, e quindi SACM fornisce un punto di catturare linee di base. Questi alimentano in
Service Transition, che si concentra su quattro tipi principali di attivit - pianificazione
transizione e supporto, gestione delle persone attraverso Servizio transizioni, la valutazione
cambiamento, e la convalida del servizio e collaudo. Cambio di valutazione porta anche a
rilasciare e Deployment Management, che comprende pianificazione delle release, build di
5

rilascio e di prova, la distribuzione di rilascio, e la revisione e vicino, e colpisce Service


Design, Service Strategy e Service Operation. Knowledge Management diventa rilevante
anche durante Continual Service Improvement.
La fase di Service Transition si concentra sulla fornitura di pianificazione di transizione e il supporto
per questi servizi, e gestire le risorse necessarie per i processi coinvolti nella transizione questi
servizi in ambienti live. Essa coinvolge anche valutare le modifiche, che porta in uscita e
Deployment Management, e infine convalidare e testare i servizi che sono stati introdotti o
modificati.
Una volta che i servizi sono stati convalidati e testati, il processo finale - Knowledge Management rilevante. Questo processo viene utilizzato a sostegno di tutto il ciclo di vita di servizio.
L'adozione e l'attuazione di approcci coerenti durante la fase di Service Transition pu aiutare le
organizzazioni a

Progetto di stima di costi in modo pi accurato

adottare modifiche pi facilmente

accrescere la fiducia che i nuovi o modificati IT servizi possono essere forniti alle specifiche

migliorare il controllo delle attivit di servizi e configurazioni

ridurre i ritardi, e

consentire la condivisione delle risorse pi efficiente

Domanda
Quali attivit rientra nell'ambito di applicazione del Service Transition?
Opzioni:
1. Gestire le complessit associate alla modifiche ai servizi e processi di gestione dei
servizi
2. L'introduzione di nuovi servizi o di apportare modifiche ai servizi esistenti
3. servizi di disattivazione
4. Trasferimento di servizi da e verso altri fornitori di servizi IT a causa di cambiamenti
in outsourcing
5. La revisione e la valutazione delle prestazioni di servizio esistente
6. Gestire la complessit associata con pi applicazioni e utenti

Risposta
Opzione 1: Corretto. La fase di Service Transition comporta cambiamenti riuscendo a servizi
e dei processi di gestione dei servizi, e la loro transizione verso ambienti live.
Opzione 2: Corretto. La fase di Service Transition si riferisce a muoversi servizi nuovi o
modificati in funzione.
Opzione 3: Corretto. Poich i servizi nuovi o aggiornati vengono distribuiti, Service Transition
deve gestire la disattivazione e l'interruzione dei servizi ridondanti, o servizi non sono pi
considerati di valore sufficiente per l'organizzazione.
6

Opzione 4: Corretto. Durante la fase di Service Transition, potrebbe essere necessario


trasferire i servizi verso o da altri fornitori di servizi, per esempio a causa di cambiamenti in
outsourcing oppure a causa di operazioni di fusione societaria.
Opzione 5: non corretto. La fase di Service Transition prevede il monitoraggio e la
valutazione dei servizi nuovi o modificati al fine di garantire che stanno soddisfare le
aspettative aziendali.
Opzione 6: non corretto. La fase di Service Transition consiste nel gestire le transizioni di
nuovo o modificato servizi IT in ambienti live. Non comporta gestire la complessit associata
con pi applicazioni e utenti.
Risposte corrette):
1. Gestire le complessit associate alla modifiche ai servizi e processi di gestione dei
servizi
2. L'introduzione di nuovi servizi o di apportare modifiche ai servizi esistenti
3. Servizi di disattivazione
4. Trasferimento di servizi da e per altri fornitori di servizi IT a causa di cambiamenti in
outsourcing
3. Le politiche di transizione di servizio
Ogni organizzazione sviluppa e realizza politiche basate sulle sue circostanze individuali. Ad
esempio, le esigenze delle organizzazioni variano in base alla loro dimensione, la distribuzione, la
cultura e le risorse. Tuttavia, ITIL fornisce 14 esempi di politica che possono guidare le
organizzazioni ad adottare le migliori pratiche per la transizione di successo dei servizi IT.
Le prime quattro politiche delineate da ITIL per Service Transition sono

definire e attuare una politica formale per Service Transition

attuare tutte le modifiche ai servizi attraverso Service Transition

adottare un quadro e norme comuni, e

massimizzare il riutilizzo dei processi e dei sistemi istituiti

Ogni politica ha associato i principi e le migliori pratiche.

1. Definire e attuare la politica formale


Il team di gestione appropriata deve definire, documentare, e approvare una politica formale per la
Service Transition. Dovrebbe anche essere comunicati a tutte le parti interessate. Distribuzione
dovrebbe essere affrontato nelle prime fasi di progettazione e pianificazione di rilascio.
La politica deve indicare chiaramente gli obiettivi e dovrebbe essere in linea con il quadro
complessivo della governance. La politica dovrebbe anche dimostrare l'impegno degli sponsor e
dei dirigenti per fornire i risultati previsti da eventuali cambiamenti dei servizi IT.
La politica dovrebbe delineare i processi che integrano le squadre pur mantenendo chiare linee di
responsabilit e di responsabilit. Essi dovrebbero anche specificare come vengono consegnati i
cambiamenti - come uscite, per esempio.
2. Implementare modifiche ai servizi
7

Tutte le modifiche di servizio devono essere gestiti attraverso la fase di Service Transition, con
l'eccezione di modifiche standard che seguono le procedure definite durante la fase. Modifiche di
servizio devono essere gestiti da un unico punto focale e la loro portata devono essere
documentati.
L'accesso e le autorizzazioni per le modifiche dovrebbero essere limitati, e tutti gli aggiornamenti ai
cambiamenti e rilasci devono essere registrate a fronte di attivit di servizio o elementi di
configurazione nel sistema di gestione della configurazione (CMS).
Metodi e procedure standardizzate dovrebbero essere utilizzati per garantire una gestione
efficiente e tempestiva di tutte le modifiche. Le richieste tardive di modifiche che non possono
essere gestiti correttamente non devono essere accettati.
3. Adottare un quadro e norme comuni
Servizio di transizione dovrebbe essere basata su un quadro comune di processi e sistemi
riutilizzabili standard. Ci permetter di migliorare l'integrazione delle parti coinvolte nella Service
Transition e ridurre le variazioni nei processi.
Best practice per questa politica sono per ottenere buy-in per la standardizzazione, e per
sostenere l'elaborazione coerente attraverso l'utilizzo di automazione e un quadro chiaro entro il
quale si svolge il lavoro. Il quadro dovrebbe essere controllata anche con processi di Change
Management e SACM.
4. Massimizzare il riutilizzo dei processi e dei sistemi istituiti
Processi di transizione dei servizi sono in linea con i processi dell'organizzazione e dei relativi
sistemi per migliorare l'efficienza e l'efficacia. Quando necessario nuovi processi, si sono
sviluppati con riutilizzo in mente.
I principi sono di ri-utilizzare i protocolli stabiliti per quanto possibile, lo sviluppo di modelli standard
di servizio Transition riutilizzabili per costruire esperienza e fiducia, implementare best practice di
settore per la standardizzazione e l'integrazione, e dei dati di cattura e le informazioni dalla fonte
originale per ridurre gli errori e gli aiuti efficienza.
Le migliori pratiche da seguire includere l'integrazione di Service Transition in Management
Service generale utilizzando pratiche di gestione dei progetti dell'organizzazione ed esistenti canali
e processi di comunicazione. Modelli di transizione dei servizi dovrebbero essere progettati per
consentire una facile personalizzazione in base alle circostanze specifiche.

Domanda
Principi match per le politiche di servizio di transizione a cui si applicano.
Opzioni:
A. Definire l'impegno degli sponsor e dei processi di contorno che si integrano squadre
B. L'accesso e le autorizzazioni dovrebbero essere limitate e tutti gli aggiornamenti
devono essere documentati
C. Guadagno buy-in per la standardizzazione e l'uso di automazione e un quadro
chiaro, ove possibile,
D. Integrare Service Transition in Management Service generale utilizzando i canali di
comunicazione esistenti
8

obiettivi:
1. Definire e attuare una politica formale per Service Transition
2. Attuare tutte le modifiche ai servizi attraverso Service Transition
3. Adottare un quadro e norme comuni
4. Massimizzare il riutilizzo dei processi e dei sistemi istituiti

Risposta
Una politica formale per Service Transition dovrebbe definire l'impegno di sponsor e dirigenti
ai processi e il cambiamento e dovrebbe mostrare come integrare le squadre pur
mantenendo chiare linee di responsabilit e di responsabilit.
La politica di attuare tutte le modifiche ai servizi attraverso Service Transition richiede che
l'accesso e le autorizzazioni per le modifiche essere limitato e tutti gli aggiornamenti ai
cambiamenti e release dovrebbe essere registrato a fronte di attivit di servizio o di
configurazione Elementi nella CMS.
Per garantire che tutte le parti adottino un quadro e norme comuni, importante per ottenere
buy-in - in particolare dei massimi dirigenti dell'organizzazione. E 'anche importante per
automatizzare i processi, ove possibile.
Per massimizzare il riutilizzo di processi e sistemi consolidati, si dovrebbe integrare Service
Transition in gestione complessiva Service utilizzando pratiche esistenti di gestione del
progetto, i canali di comunicazione e processi.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D
5. Allineare i piani di transizione
Un'altra politica suggerita da ITIL quello di allineare i piani di transizione di servizio con le
imprese ha bisogno di massimizzare il valore del cambiamento. Si dovrebbe adottare il programma
e la gestione dei progetti migliori pratiche per pianificare e gestire le risorse necessarie per
confezionare, costruire, testare e distribuire un comunicato con successo. inoltre necessario
fornire piani chiari e completi che consentono al cliente e di business per allineare le proprie attivit
di cambiamento con i piani di transizione di servizio. Alcuni principi sono associati con la politica di
allineare piani di transizione di servizio con le esigenze di business:

set clienti e utenti aspettative su come un servizio pu essere utilizzato efficacemente per
permettere il cambiamento di business

fornire informazioni e stabilire processi per consentire l'integrazione di un rilascio nei


processi aziendali e dei servizi

assicurarsi che il servizio di transizione pu essere usato in conformit con i requisiti e


vincoli per migliorare la soddisfazione specificati

il trasferimento delle conoscenze ai clienti e altre parti interessate per aumentare la loro
capacit di utilizzare il servizio nuovo o modificato
9

monitorare e misurare l'utilizzo del servizio e la tecnologia di base, durante la distribuzione


e il supporto primi anni di vita, e

confrontare effettivo prestazioni previste del servizio per ridurre le variazioni di capacit di
servizio e le prestazioni
6. Stabilire e mantenere relazioni con gli stakeholder
La sesta proposta politica quello di stabilire e mantenere relazioni con gli stakeholder in tutta
Service Transition per impostare le aspettative circa il nuovo o cambiato il servizio.
necessario impostare le aspettative sulle prestazioni di servizio e di come il servizio consentir
cambiamento aziendale. Si dovrebbe anche comunicare le modifiche alle parti interessate e di
garantire informazioni di buona qualit sulla transizione prontamente disponibile.
Una delle migliori pratiche associata validazione dalle parti interessate che il nuovo servizio pu
essere utilizzato a seconda delle esigenze e dei vincoli. Si dovrebbe anche condividere i piani con
le parti interessate, costruire relazioni con loro, e di ottenere l'impegno da parte dei fornitori chiave
durante e dopo la transizione.
7. Stabilire controlli e discipline efficaci
La settima proposta politica quello di stabilire i controlli e discipline efficaci in tutto il Service
Lifecycle. Principi associati e le migliori pratiche riguardano
Direzione generale per tutto il ciclo di vita
L'integrit di tutte le attivit e le configurazioni di servizio individuati deve essere mantenuta
per tutto il ciclo di vita di servizio.
Tale gestione deve essere in accordo con le risorse disponibili e le esigenze ei vincoli
definiti nel Service Level Agreement (SLA).
Definizione dei ruoli e delle responsabilit, e
Si dovrebbe definire chiaramente e comunicare ruoli e responsabilit - assicurando che
siano chiaramente compresi e mappa ad ogni fase del ciclo di vita Service Transition.
I ruoli assegnati devono essere conservate all'interno del Servizio Knowledge Management
System (SKMS) e CMS. Si dovrebbe anche garantire che solo personale adeguatamente
qualificato in grado di implementare modifiche al ambienti di test controllati ei servizi
supportati.
Requisiti di audit
Controlli di configurazione e regolare processo dovrebbero monitorare il cambiamento del
ciclo di vita. Per identificare meglio le discrepanze o modifiche non autorizzate, pu essere
utile per automatizzare le attivit di audit. I processi di configurazione, Modifica, e Problem
Management dovrebbe essere basato sulle transazioni per fornire una pista di controllo
chiara e di migliorare l'efficacia dei controlli.

10

8. Sistemi per il trasferimento di conoscenze e di supporto alle decisioni


Fornire
Un'altra politica Service Transition proposto quello di fornire sistemi per il trasferimento di
conoscenza e supporto alle decisioni. Garantire processi di trasferimento di conoscenze efficaci
aiuta a informare il processo decisionale e migliora Service Operation.
Come best practice, necessario fornire un facile accesso, la presentazione e strumenti di
reporting per la SKMS e CMS. Questi dovrebbero essere presentati utilizzando interfacce di
qualit progettato con ruoli e responsabilit di persone diverse in mente.
Dopo ogni Service Transition completa, utile per documentare una sintesi degli effetti previsti e
imprevisti del cambiamento in termini di capacit, prestazioni, e il rischio.
Principi associati ai sistemi che prevedono il trasferimento delle conoscenze comprendono
fornendo dati di qualit, informazioni e conoscenze al momento giusto alle persone giuste per
ridurre lo sforzo trascorso in attesa per le decisioni e conseguenti ritardi.
necessario assicurarsi che non vi una formazione adeguata e che la qualit dei dati e della
documentazione accettabile.
Stabilire anche una fonte definitiva di conoscenza e di condividere queste informazioni con i
soggetti interessati in tutto il ciclo di vita di servizio. E 'utile per fornire informazioni consolidate per
permettere il cambiamento e decisioni efficaci.
9. Rilascio Piano e pacchetti di distribuzione
Un'altra politica importante quello di pianificare i pacchetti di rilascio in modo che forniscono i
livelli concordati di tracciabilit in un modo economicamente efficace ed efficiente. Quindi
necessario per garantire i soggetti interessati approvano la politica di rilascio e che la politica
prevista con largo anticipo.
Meccanismi di rilascio e previsto insediamento dovrebbero garantire l'integrit dei componenti
durante l'installazione, la gestione, l'imballaggio e la consegna. Uso delle risorse dovrebbe essere
coordinato durante il rilascio e ottimizzato per ridurre i costi.
I rischi di un rilascio fallito devono essere incluse nei piani, e valutati e gestiti. Inoltre, uscite di
emergenza dovrebbero essere pianificati e gestiti in linea con le procedure di modifica di
emergenza.

Domanda
Abbinare le politiche di transizione esempio di servizio ai principi corrispondenti.
Opzioni:
A. Misurare uso di servizio durante la distribuzione
B. Comunicare piani a clienti, utenti e fornitori
C. Orari regolari verifiche configurazione e del processo e automatizzare le attivit di
audit, ove necessario,
D. Fornire una formazione adeguata e garantire che la qualit dei dati buona
E. Gestire uscite di emergenza in linea con le procedure di modifica di emergenza
dell'organizzazione
obiettivi:
11

1. Allineare piani di transizione di servizio con le esigenze di business


2. Stabilire e mantenere relazioni con gli stakeholder
3. Stabilire controlli e discipline efficaci
4. Fornire sistemi per il trasferimento di conoscenza e supporto alle decisioni
5. Pacchetti di rilascio Piano

Risposta
Allineamento Service Transition con le esigenze aziendali include misurazione uso di servizio
durante la distribuzione e il supporto primi anni di vita.
Si dovrebbe comunicare i cambiamenti e piani per le parti interessate, e di garantire che
informazioni di buona qualit sulla transizione prontamente disponibile.
Controlli efficaci includono verifiche periodiche, le attivit di audit automatizzati, e la fornitura
di una chiara pista di audit per i processi di gestione della configurazione, cambiare, e
problema.
Sistemi per il trasferimento di conoscenze e di supporto alle decisioni fornendo pu
coinvolgere fornire formazione e informazione di qualit. Questo pu migliorare la
soddisfazione delle parti interessate, ridurre i costi e ridurre gli errori.
Quando si pianifica pacchetti di rilascio, necessario assicurarsi che rilasci di emergenza
sono previsti in conformit con le procedure di modifica di emergenza.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D
Obiettivo 5 = Opzione E
I restanti politiche di transizione servizio proposto da ITIL devono
10.
Anticipare e gestire correzioni di rotta
Per anticipare e gestire correzioni di rotta, necessario formare i dipendenti per
identificare, fare e gestire correzioni di rotta, e di applicare le variazioni necessarie per i
piani di servizio di transizione originali entro i limiti prescritti e compreso. Questi
cambiamenti devono essere gestiti utilizzando procedure esistenti, e dovrebbero essere
informati dai precedenti correzioni di rotta. Si dovrebbe incoraggiare le parti interessate ad
aspettarsi cambiamenti e capire che queste sono necessarie e utili. Si dovrebbe anche
prevedere i futuri cambiamenti e utilizzare le sessioni di debriefing di fine transizione per
informare gli altri.
11.
Gestire in modo proattivo le risorse in tutta Service Transition
Per gestire le risorse in modo proattivo, necessario un team in grado di attuare il
cambiamento attraverso tutte le fasi del ciclo di vita. Si dovrebbe stabilire condiviso,
dedicato e risorse specialistiche attraverso attivit di Service Transition per eliminare i
ritardi e ottimizzare l'uso delle risorse. Ove possibile, automatizzare i processi ripetitivi e
soggetti a errori per migliorare l'efficacia e l'efficienza delle attivit chiave.
12.
Assicurare il coinvolgimento nelle prime fasi del ciclo di vita di
servizio, e
12

Garantendo il coinvolgimento nelle prime fasi del ciclo di vita di servizio, possibile
massimizzare la diagnosi precoce di eventuali difetti o debolezze, e di cambiamenti che
non fornire i benefici attesi. Ci comporta in genere costi molto pi bassi rispetto se si
identificano i problemi solo in seguito.
13.
Fornire la garanzia della qualit del servizio nuovo o modificato
Per fornire la garanzia della qualit, le risorse Service Transition dovrebbero verificare che
le modifiche proposte in grado di soddisfare i requisiti aziendali specifici e fornire i benefici
di business previsti. Attraverso valutazioni formali di Service Design, il team dovrebbe
anche identificare i rischi e misurare e ridurre gli errori noti. Progettazione di test e
l'esecuzione devono essere gestiti e consegnati in modo indipendente dal progettista del
servizio o l'architetto e gli sviluppatori. Inoltre, gli ambienti di test devono riflettere gli
ambienti dal vivo al massimo grado possibile per consentire risultati rilevanti.
14.

Migliorare la qualit in modo proattivo

La politica finale proposto da ITIL quello di migliorare la qualit in modo proattivo durante la
fase di Service Transition. Tre principi sono associati con attuazione di tale politica:

il rilevamento e la risoluzione dei problemi durante la fase di transizione per ridurre la


probabilit di errori che si verificano durante la fase di Service Operation

gestire e ridurre i problemi e gli errori durante la Service Transition per ridurre i costi e la
necessit di ri-lavoro, e

allineando Incident e Problem Management con i processi Service Operation per aiutare a
misurare e gestire il loro impatto

Domanda
Abbinare le politiche di transizione esempio servizio ai loro principi.
Opzioni:
A. Prevedere i cambiamenti futuri e utilizzare le sessioni di debriefing di fine transizione
B. Automatizzare i processi ripetitivi e soggetto a errori
C. Stabilire controlli efficaci per la rilevazione di problemi, in via preliminare
D. Garantire risorse Service Transition capire le esigenze di servizi IT dei clienti e
valutare formalmente il design
E. Allineare gestione degli errori con i processi di intervento di manutenzione al aiutare
misura e gestire il loro impatto
obiettivi:
1. Anticipare e gestire correzioni di rotta
2. Gestire in modo proattivo le risorse attraverso attivit di Service Transition
3. Assicurarsi che il rilevamento degli errori nelle prime fasi del ciclo di vita di servizio
4. Fornire garanzia della qualit del servizio nuovo o modificato
5. Proattivo migliorare la qualit durante la Service Transition

Risposta

13

Per anticipare e gestire correzioni di rotta, necessario utilizzare procedure esistenti informato da precedenti correzioni ove possibile, anticipare i problemi futuri, e costruire nuove
conoscenze attraverso sessioni di debriefing di fine transizione.
Per gestire le risorse in modo proattivo, si dovrebbe stabilire una squadra capace, stabilire
una serie di risorse, e automatizzare i processi soggetti a errori, ove possibile, per migliorare
l'efficienza.
L'istituzione di controlli e discipline idonee nelle prime fasi garantisce l'individuazione precoce
dei problemi, riducendo generalmente i costi associati a affrontare questi problemi.
Per fornire la garanzia della qualit, la squadra ha bisogno di verificare che le modifiche
proposte in grado di fornire i benefici di business richiesti. E 'utile a condurre valutazioni
formali di Service Design per identificare i rischi connessi, e per misurare e ridurre gli errori
noti.
Per migliorare la qualit durante la fase di Service Transition, importante allineare incidenti
e gestione dei problemi con i processi Service Operation per aiutare misura e gestire il loro
impatto sulla fornitura di servizi.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D
Obiettivo 5 = Opzione E
15.Riepilogo
Il campo di applicazione Service Transition include l'implementazione nuovi e modificati servizi IT
nell'ambiente dal vivo, lo smantellamento vecchi servizi fuori dell'ambiente dal vivo, e il
trasferimento dei servizi da e verso altri fornitori di servizi IT.
Le organizzazioni dovrebbero creare le proprie politiche in base alle loro esigenze. Tuttavia,
possono utilizzare una qualsiasi delle 14 politiche suggerite dal ITIL per guidare la loro
attuazione della fase Service Transition.
16.Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Ambito di Service Transition |
| 2. Politiche di servizio di transizione |
| Sommario |

14

Asset Transition, Servizio di supporto, e test


1. obiettivi formativi
Dopo aver completato questo argomento, si dovrebbe essere in grado di

descrivere la portata della Asset servizio e processo di Configuration Management

descrive la portata della pianificazione transizione e processo di sostegno

descrive la portata della convalida servizio e processo di testing


2. Pianificazione Transizione

Lo scopo del processo di pianificazione di transizione e il supporto quello di fornire la


pianificazione generale per processi di transizione di servizio e di coordinare le risorse di cui hanno
bisogno.
Gli obiettivi di pianificazione di transizione e supporto sono per monitorare e migliorare le
prestazioni della fase Service Transition e
coordinare le risorse
Durante la pianificazione della transizione e il supporto, a pianificare e coordinare le risorse
necessarie per garantire che la strategia di servizio di un'organizzazione pu essere
realizzato in modo efficace, date le specifiche di progettazione fornite.
coordinare le attivit
Per garantire percorsi di pianificazione di transizione senza intoppi, necessario
coordinare le attivit tra i progetti, fornitori e team di assistenza dove richiesto.
stabilire nuovi o modificati servizi IT
Il risultato finale di pianificazione di transizione e di sostegno un nuovo o modificato
servizi IT entrare in un ambiente supportato all'interno delle stime dei costi, qualit e tempo
previsto.
stabilire nuovi sistemi e strumenti
Per pianificare un Service Transition, potrebbe essere necessario modificare o creare nuovi
sistemi di gestione delle informazioni, strumenti, tecnologie e architetture di
gestione. Potrebbe anche essere necessario per stabilire nuovi processi di gestione dei
servizi, cos come i metodi per misurare se i requisiti stabiliti durante la fase di Service
Design del ciclo di vita sono stati raggiunti.
garantire l'adozione di un quadro comune
Per migliorare l'efficacia e l'efficienza delle attivit di pianificazione e di coordinamento,
necessario assicurarsi che tutte le parti adottino un quadro comune di processi riutilizzabili
standard e sistemi di supporto.

fornire piani chiari, e


15

Per consentire ai clienti e responsabili della gestione dei progetti di cambiamento di


business per allineare le loro attivit con piani di transizione di servizio, necessario fornire
loro i piani - che dovrebbe essere chiaro e completo.
gestire i rischi
Per ridurre al minimo il rischio di fallimento e la rottura attraverso le attivit di transizione,
necessario identificare, gestire e controllare i rischi. Si dovrebbe anche assicurare che le
questioni di servizio di transizione, i rischi, e le deviazioni sono segnalati per i soggetti
interessati e responsabili delle decisioni.
L'ambito di pianificazione transizione e supporto include
il mantenimento di politiche
pianificazione di transizione e il supporto richiede politiche mantenendo, standard e modelli
per le attivit di transizione di servizi e processi. Ad esempio, le politiche possono
richiedere l'uso di una matrice Responsabile, Accountable, Consultato e informato (RACI)
per gestire i ruoli e le responsabilit per l'attuazione di un progetto di cambiamento.
modifiche guida
necessario guidare ogni cambiamento o nuovo servizio attraverso tutti i processi di
transizione di servizio e dare priorit contrapposte esigenze di risorse di transizione di
servizi. Per esempio, gli ambienti di test per il nuovo software di supporto possono essere a
scarseggiare. Per guidare i cambiamenti, necessario dare la priorit che il software per
testare prima.
coordinamento delle attivit
Durante la pianificazione e sostenere le transizioni, necessario coordinare le attivit in
modo pi transizioni possono essere gestiti contemporaneamente. Tale coordinamento
deve adattarsi perfettamente con il programma e la gestione dei progetti, Service Design, e
le attivit di sviluppo dei servizi.
la pianificazione dei requisiti delle risorse, e
necessario assicurarsi che il bilancio per un Service Transition ben programmato e che
non ci sono risorse sufficienti per soddisfare i requisiti futuri.
rivedere le attivit di pianificazione e di supporto
Si dovrebbe rivedere e migliorare le prestazioni di pianificazione della transizione e di
attivit di supporto alla chiusura di ogni progetto.
L'ambito di pianificazione della transizione e il supporto non include la pianificazione della
costruzione, test e implementazione di modifiche di servizio individuali o uscite.
Queste attivit si verificano come parte di entrambi gestione del cambiamento e di uscita e
distribuzione di gestione.

Domanda
Quali attivit rientrano nel campo di applicazione della pianificazione della transizione e del
processo di sostegno?
Opzioni:
1. Aggiornare il documento politico Change Management per includere i nuovi standard
richiesti
16

2. Supervisionare la modifica a un processo di helpdesk online attraverso tutti i requisiti


di servizio di transizione
3. Lista e il prezzo di tutti i componenti di cui ha bisogno di formare i dipendenti attuali
nella realizzazione del nuovo servizio IT
4. Creare una panoramica dell'impatto di un servizio cambiato il livello di
soddisfazione del cliente
5. materiali Review formazione sviluppati per favorire il servizio riprogettazione

Risposta
Opzione 1: Corretto. L'ambito di pianificazione transizione e supporto include il
mantenimento di politiche, norme e modelli per le attivit di Service Transition e processi.
Opzione 2: Corretto. L'ambito di pianificazione della transizione e di sostegno comprende
guidare ogni cambiamento o nuovo servizio attraverso tutti i processi di transizione di
servizio.
Opzione 3: Corretto. L'ambito di pianificazione della transizione e di sostegno comprende la
pianificazione del bilancio e le risorse necessarie per soddisfare i requisiti futuri per Service
Transition.
Opzione 4: non corretto. L'ambito di pianificazione transizione e supporto include la revisione
e il miglioramento delle prestazioni delle attivit di pianificazione di transizione e di supporto,
piuttosto che rivedere le conseguenze di rilascio di un servizio nuovo o modificato.
Opzione 5: non corretto. L'ambito di pianificazione transizione e supporto include la revisione
e il miglioramento delle prestazioni delle attivit di pianificazione di transizione e di supporto,
piuttosto che la revisione di un servizio stesso.
Risposte corrette):
1. Aggiornare il documento politico Change Management per includere nuovi standard
richiesti
2. Supervisionare la modifica a un processo di helpdesk online attraverso tutti i requisiti
di Service Transition
3. Lista e il prezzo di tutti i componenti di cui ha bisogno di formare i dipendenti attuali
nella realizzazione del nuovo servizio IT
3. Service Asset and Configuration Management
Nessuna organizzazione pu essere pienamente efficiente o efficace a meno che non gestisce
bene il suo patrimonio. Ci vale in particolare per le attivit che sono vitali per l'esecuzione di
business dell'organizzazione o le imprese dei suoi clienti.
Il processo di Servizio Asset and Configuration Management (SACM) garantisce che le risorse
necessarie per fornire servizi IT siano adeguatamente controllati e che le informazioni accurate e
affidabili su tali attivit disponibile quando e dove necessario. Queste informazioni includono
dettagli di come le attivit sono state configurati e le relazioni tra le attivit.
Per meglio comprendere la portata e lo scopo di Asset e Configuration Management, utile
distinguere tra
un bene di servizio, e
17

Un'attivit servizio qualsiasi risorsa o capacit che potrebbe contribuire alla fornitura di un
servizio IT. Esempi di attivit di servizio sono un server virtuale, un server fisico, una
licenza software, le informazioni memorizzate in un sistema di gestione dei servizi, o la
conoscenza detenuta da un anziano manager.
un elemento di configurazione (CI)
Un CI un bene di servizio che deve essere gestito per fornire un servizio IT. Tutti gli IC
sono le attivit di servizio, anche se le attivit di servizio non sono tutti gli EC. Esempi di CI
sono i server e le licenze software. Ogni CI deve essere sotto il controllo di Change
Management. Le informazioni che ha memorizzato, ma che non sotto il controllo del
Change Management pu essere un bene molto prezioso, ma non un CI.
E 'importante notare che molti beni virtuali, come i server o le reti virtuali, pu essere IC e
richiedono lo stesso controllo di gestione tra le attivit fisiche.
SACM ha diversi obiettivi:

al fine di garantire che le attivit siano identificati, controllati, e adeguatamente accuditi in


tutto il loro ciclo di vita

per garantire l'integrit dei CI stabilire e mantenere un accurato e completo Configuration


Management System (CMS)

di individuare, di controllo, registrazione, relazione, controllo e verifica dei servizi e di altri


elementi di configurazione, comprese le versioni, linee di base, elementi costitutivi, e gli attributi di
servizio e relazioni

per mantenere le informazioni di configurazione precise sullo stato storico, pianificato, e la


corrente di servizi e altri CI, e

a supporto dei processi di gestione dei servizi efficienti ed efficaci, fornendo informazioni
che consente un processo decisionale efficace
SACM assicura che CI sono identificati, baselined, e mantenuto, e che i cambiamenti a loro sono
controllati. Cos il suo campo di applicazione comprende la gestione del ciclo di vita completo di
ogni CI. Ad esempio, un server virtuale verr utilizzato nel fornire accesso inhouse alle politiche
aziendali. L'attivit viene identificato, le sue prestazioni di base misurata, il sistema viene
mantenuto attraverso il passaggio, e le prestazioni sono recensione volta che il servizio viene
testato.
SACM responsabile di assicurare rilasci in ambienti controllati e l'utilizzo operativo sono
formalmente autorizzati. Esso fornisce anche un modello di configurazione dei servizi e delle
attivit di servizio registrando le relazioni tra CI.
Cos come le risorse IT come server, i tipi di attivit coperte da SACM includono
le risorse non IT
SACM pu coprire beni non-IT, prodotti di lavoro utilizzati per sviluppare i servizi e IC
necessari per supportare il servizio che non sarebbe classificato come attivit da parte di
altre parti del business. Il campo di applicazione comprende interfacce per i fornitori di
servizi interni ed esterni dove ci sono risorse e CI che hanno bisogno di essere controllati per esempio, quando le attivit sono in comune.
immobilizzazioni
18

La maggior parte delle organizzazioni utilizzano un processo di Asset Management fissa


per monitorare e segnalare il valore e la propriet delle immobilizzazioni in tutto il loro ciclo
di vita. Fixed Asset Management consiste nel mantenere un registro risorsa che registra
le informazioni finanziarie su capitale fisso di un'organizzazione. Di solito non sotto il
controllo della stessa unit di business che gestisce servizi IT. Tuttavia, il processo di
SACM dovrebbe essere applicato per le immobilizzazioni sotto il controllo di esso, e ci
dovrebbe essere interfacce tra SACM ben definito e fissato Asset Management. I dati dal
registro del bene pu anche essere integrato con il CMS per fornire una visione pi
completa
di
CSI.

Domanda
Quali attivit rientrano nell'ambito di applicazione del processo SACM?
Opzioni:
1. Gestione interfacce utilizzate per condividere patrimonio di conoscenze su una rete
tra un fornitore e l'azienda
2. Garantire che un CI viene rilasciato solo in uso operativo dopo l'autorizzazione
formale
3. L'integrazione dei dati dal registro di asset fisso con il CMS
4. Documentare cliente e il feedback interno degli utenti dei servizi
5. La gestione e la documentazione di costruire attivit come il controllo di versione

Risposta
Opzione 1: Corretto. L'ambito di SACM comprende attivit non IT, prodotti di lavoro utilizzati
per sviluppare i servizi, e CI necessario per supportare il servizio come le interfacce a fornitori
di servizi interni ed esterni dove ci sono attivit che devono essere controllati condivisa.
Opzione 2: Corretto. Il campo di applicazione SACM comprende la gestione del ciclo di vita
completo di ogni CI, compresa la garanzia che rilasci ambienti controllati e l'utilizzo operativo
sono fatte sulla base di un'autorizzazione formale.
Opzione 3: Corretto. Il processo di SACM dovrebbe essere applicato alle immobilizzazioni
sotto il controllo di esso, e ci dovrebbe essere interfacce ben definite tra SACM e fisso Asset
Management. Inoltre, i dati del registro del bene possono essere integrati con il CMS per
fornire una visione pi completa della CSI.
Opzione 4: non corretto. Si tratta di un'attivit associata con la revisione e vicino le fasi del
processo di rilascio e Deployment Management.
Opzione 5: non corretto. Si tratta di un'attivit associata con la build di rilascio e la fase di
test del processo di rilascio e Deployment Management.
Risposte corrette):
1. interfacce Gestione utilizzati per condividere patrimonio di conoscenze su una rete tra
un fornitore e la societ
2. Garantire che un CI viene rilasciato solo in utilizzazione dopo autorizzazione formale
3. L'integrazione dei dati dal registro di asset fisso con il CMS
4. Validazione e test
19

Il processo di convalida del servizio e collaudo fornisce la garanzia della qualit all'interno del
dominio Service Transition. Si verifica che un nuovo o cambiato servizio adatto allo scopo e in
forma per l'uso.
Validation Service e la sperimentazione l'ultimo processo di Service Transition. Una volta che
questo processo viene completato, il servizio viene spostato in un ambiente reale.
Lo scopo della convalida servizio e processo di test quello di garantire che un nuovo o modificato
un servizio che corrisponda a delle specifiche di progettazione e dovr soddisfare le esigenze
aziendali. Diversi obiettivi sono legati alla validazione del servizio e test:

la garanzia della qualit per un rilascio, i suoi componenti di servizio costituenti, il servizio
risultante, e la capacit di servizio consegnato da una release

convalida che un servizio "adatto allo scopo" - o consegner l'utilit richiesta

garanzia che un servizio "adatto per l'uso" - o consegner la garanzia concordata

conferma che i requisiti dei clienti per il servizio nuovo o modificato siano definite
correttamente

progettazione e realizzazione di una validazione strutturata e processo di testing, e

revisione in corso che identifica, valuta e affronta i problemi, gli errori e rischi durante tutta
la fase Service Transition
Testare direttamente sostiene il processo di rilascio e distribuzione di gestione, garantendo che i
livelli adeguati di test vengono eseguiti durante il rilascio e la gestione della distribuzione delle
attivit.
Essa valuta i modelli di servizio dettagliati per garantire che essi siano adatti allo scopo e in forma
per l'uso, prima di essere autorizzato ad entrare Service Operation, attraverso il catalogo dei
servizi.
L'uscita dal test viene utilizzato dal processo di valutazione cambiamento di fornire informazioni su
se il servizio formalmente giudicato da fornire le prestazioni del servizio, con un profilo di rischio
accettabile.
I test possono essere classificati in base all'utente finale di un prodotto di servizio.
Test Servizio clienti
Con il test del servizio clienti, un Service Level Agreement (SLA) guida di prova e mira a
garantire che il fornitore di servizi si assume la responsabilit per la consegna, il
funzionamento e la salvaguardia del patrimonio del cliente o di servizio ai livelli
concordati. Validation Service e test possono essere applicate in tutto il servizio Ciclo di vita
di qualit assicurare ogni aspetto di un servizio e la capacit dei fornitori di servizi, le
risorse e la capacit di fornire un service release o un servizio con successo. Durante la
convalida e la sperimentazione di un servizio end-to-end, le interfacce con fornitori, clienti e
partner sono importanti.
Prove di servizi in camera
Il test importante per i servizi in camera, come per i servizi forniti ai clienti esterni. Esso
comprende la sperimentazione di nuovi o modificati IT servizi o componenti di servizio, e
prende in esame il comportamento di questi nella business unit bersaglio, unit di servizio,
gruppo distribuzione o l'ambiente. Questo ambiente potrebbe includere aspetti di fuori del
20

controllo del fornitore di servizi - per esempio, le reti pubbliche, livelli di abilit degli utenti, o
asset del cliente.

Domanda
Quali attivit rientrano nell'ambito di applicazione del processo di convalida del servizio e il
test?
Opzioni:
1. Fornire la garanzia della qualit sulla progettazione di un servizio in termini di
capacit delle organizzazioni risorse
2. Esaminando il comportamento dei componenti di servizio, come l'accesso a Internet,
in unit di business di destinazione
3. Garantire che i livelli adeguati di test vengono eseguiti durante la Stampa e
distribuzione di attivit di gestione
4. Test e assicurare che un servizio consegner l'utilit necessaria
5. Garantire che CI sono identificati, baselined, e mantenuto
6. Gestire le questioni ambientali come il raffreddamento, protezioni antincendio, e
controllo di accesso fisico

Risposta
Opzione 1: Corretto. Validation Service e test possono essere applicate in tutto il ciclo di vita
del servizio di qualit assicurare ogni aspetto di un servizio e la capacit dei fornitori di servizi
di offrire un service release o un servizio con successo.
Opzione 2: Corretto. La sperimentazione di nuovi o modificati in camera IT servizi o
componenti di servizio richiede l'esame del comportamento di questi nella business unit di
destinazione. nell'ambito della convalida servizio e processo di test.
Opzione 3: Corretto. Validation Service e test supporta direttamente il processo di rilascio e
distribuzione di gestione, garantendo che i livelli adeguati di test vengono eseguiti durante il
rilascio e la gestione della distribuzione delle attivit.
Opzione 4: Corretto. Convalida e di prova di garantire che i modelli di servizio siano adatti
allo scopo e si adattano all'impiego prima di essere autorizzato ad entrare Service Operation.
Opzione 5: non corretto. Questa attivit parte del processo di SACM. Un CI un asset
servizio che deve essere gestito per fornire un servizio IT.
Opzione 6: non corretto. Questa attivit fa parte della fase di build di rilascio e la prova di
uscita e Deployment Management.
Risposte corrette):
1. Fornire la garanzia della qualit sulla progettazione di un servizio in termini di capacit
delle organizzazioni risorse
2. Esaminando il comportamento dei componenti di servizio, come l'accesso a Internet,
in unit di business di destinazione
3. Garantire che i livelli adeguati di test vengono eseguiti durante il rilascio e la gestione
della distribuzione delle attivit
4. Test e assicurare che un servizio consegner l'utilit necessaria
5. Riepilogo
21

Il processo SACM garantisce che le risorse necessarie per fornire servizi IT siano adeguatamente
controllati e che le informazioni accurate e affidabili su tali attivit disponibile quando e dove
necessario. La portata del SACM comprende la gestione del ciclo di vita completo di ogni CI. Il
processo di pianificazione di transizione e il supporto fornisce pianificazione generale e coordina le
risorse necessarie. Questo non include la creazione di piani dettagliati, ma piuttosto guida
cambiamenti, mantenendo politiche, e coordinare le attivit. La validazione servizio e processo di
test fornisce una garanzia della qualit sperimentare e convalidare Service Design, stampa e
distribuzione. Il suo ruolo quello di garantire che un nuovo o modificato il servizio IT adatto allo
scopo
e
in
forma
per
l'uso.

6. Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Asset and Configuration Management |
| 2. Pianificazione di transizione |
| 3. Validazione e collaudo |
| Sommario |

22

Stampa e distribuzione gestione a Service


Transition
1. Obiettivo di apprendimento
Dopo aver completato questo argomento, si dovrebbe essere in grado di

descrivere le fasi del processo di rilascio e distribuzione di gestione


2. Ambito di applicazione e finalit

Come parte della fase di Service Transition, il processo di rilascio e distribuzione di gestione guida
la pianificazione, programmazione, costruzione, collaudo, e la distribuzione di comunicati. Essa
aiuta a garantire che queste attivit offrono la funzionalit di nuova richiesta senza mettere in
pericolo la qualit e l'integrit dei servizi esistenti.

Grafico
Il processo di rilascio e distribuzione di Gestione composto da pianificazione delle release,
build di rilascio e di prova, la distribuzione di rilascio, e la revisione e vicino.
Due gli obiettivi principali del processo di rilascio e distribuzione di gestione sono da definire e
firmare uscita e Deployment Management piani con le parti interessate, e per creare e pacchetti di
test che sono compatibili con elementi di configurazione (CI).
Ci sono diversi altri obiettivi chiave del processo di rilascio e distribuzione di gestione:

mantenere l'integrit di un rilascio e tutti i suoi componenti associati

distribuire i pacchetti di rilascio dalla libreria multimediale definitivo (DML) per l'ambiente
vivo, in linea con i piani e programmi concordati

garantire che tutti i pacchetti di rilascio possono essere monitorati, installati, testati,
verificati, e annullati se del caso

garantire che il cambiamento sia correttamente gestita durante il rilascio e la distribuzione


di servizi

garantire che qualsiasi servizio nuovo o modificato in grado di fornire l'utilit e la garanzia
concordato

registrare e gestire le deviazioni e rischi, e prendere misure correttive necessarie, e

garantire il trasferimento delle conoscenze per le principali parti interessate per ottimizzare
l'uso di nuova o modificata servizi IT
L'ambito di uscita e Deployment Management comprende i processi, i sistemi e le funzioni
necessarie per il confezionamento, costruire, testare e distribuire rilasci ambienti live. Esso
comprende anche quei processi necessari per stabilire servizi IT e formalmente consegnarli alle
funzioni di Service Operation.
Il campo di applicazione del processo di rilascio e distribuzione Management comprende anche
tutti gli EC. Gli esempi includono

beni fisici, come ad esempio un server o di rete


23

beni virtuali, come un server virtuale o di storage virtuale

applicazioni e software

la formazione per gli utenti e il personale IT, e

servizi, compresi tutti i contratti e gli accordi relativi

Anche se di rilascio e distribuzione di gestione responsabile di assicurare che i test del caso ha
luogo, la prova vera e propria viene condotto come parte della convalida servizio e processo di
testing.

Grafico
Un diagramma illustra il contesto in cui si verifica la fase di Service Transition. A partire con
Continual Service Improvement, Change Management fornisce l'autorizzazione per le
modifiche, e quindi SACM fornisce un punto di catturare linee di base. Questi alimentano in
Service Transition, che si concentra su quattro tipi principali di attivit - pianificazione
transizione e supporto, gestione delle persone attraverso Servizio transizioni, la valutazione
cambiamento, e la convalida del servizio e collaudo. Cambio di valutazione porta anche a
rilasciare e Deployment Management, che comprende pianificazione delle release, build di
rilascio e di prova, la distribuzione di rilascio, e la revisione e vicino, e colpisce Service
Design, Service Strategy e Service Operation. Knowledge Management diventa rilevante
anche durante Continual Service Improvement.
Inoltre, Release e Deployment Management non responsabile per l'autorizzazione modifiche. Si
richiede l'autorizzazione di Change Management in diverse fasi del ciclo di vita di un rilascio.

Domanda
Quali sono alcuni degli obiettivi del processo di rilascio e gestione di distribuzione?
Opzioni:
1. Definire e concordare piani per il rilascio di servizio e la distribuzione con i clienti
2. Distribuire pacchetti disperdere nell'ambiente vivere in accordo con un piano e il
calendario concordato
3. Registrare e gestire deviazioni e rischi connessi a nuovi servizi
4. Assicurarsi che tutti i pacchetti di rilascio possono essere monitorati
5. Assicurarsi che affidabile e sicuro conoscenze, informazioni e dati sono disponibili in
tutto il ciclo di vita di servizio
6. Mantenere le informazioni accurate di configurazione sulla storica, pianificato, e lo
stato attuale dei servizi

Risposta
Opzione 1: Corretto. Attraverso il rilascio e la gestione della distribuzione, i piani per il rilascio
e la distribuzione di servizi dovrebbero essere comunicati a tutte le principali parti interessate,
compresi i clienti, ed essere debitamente firmate off.
Opzione 2: Corretto. Un obiettivo chiave di questa fase quello di implementare nuovi o
modificati servizi IT per un ambiente vivo, nei tempi previsti e in linea con i piani di rilascio
concordati.
24

Opzione 3: Corretto. Un obiettivo di rilascio e distribuzione di gestione quello di garantire


che i rischi connessi con il rilascio e la distribuzione di nuovi o modificati servizi IT siano
correttamente identificati, e che le azioni appropriate per mitigare tali rischi.
Opzione 4: Corretto. Un obiettivo di rilascio e distribuzione di gestione quello di garantire
che tutti i servizi rilasciati possono essere monitorati, installati, testati, certificati e supportati
se necessario.
Opzione 5: non corretto. Si tratta di un obiettivo di Knowledge Management, piuttosto che di
uscita e Deployment Management.
Opzione 6: non corretto. Si tratta di un obiettivo di Asset e Configuration Management,
piuttosto che di uscita e Deployment Management.
Risposte corrette):
1. Definire e concordare piani per il rilascio di servizio e la distribuzione con i clienti
2. Gli imballaggi di rilascio distribuire nell'ambiente vivere in accordo con un piano e il
calendario concordato
3. Registrare e gestire deviazioni e rischi connessi a nuovi servizi
4. Assicurarsi che tutti i pacchetti di rilascio possono essere monitorati
3. Le quattro fasi
Il processo di rilascio e distribuzione di Gestione ha quattro fasi - di rilascio e di pianificazione della
distribuzione, build di rilascio e di test, implementazione e revisione e stretti.

Grafico
Un diagramma mostra che Change Management fornisce l'autorizzazione per la
pianificazione di rilascio, per la fase di build di rilascio e di test, e per il controllo di un servizio
di DML. Esso prevede inoltre l'autorizzazione per la distribuzione, il trasferimento, e ritiro di
servizi. La revisione e vicino fasi di rilascio e gestione di distribuzione restituisce una
revisione post-implementazione per la gestione del cambiamento.
Ogni fase ha le sue sfide ed esigenze.

Uscita e la distribuzione di pianificazione


I piani per la creazione e la distribuzione di un rilascio sono generati in fase di pianificazione di
rilascio e la distribuzione. Questa fase inizia con l'autorizzazione Change Management per
pianificare un rilascio, e si conclude con l'autorizzazione Change Management per creare il
rilascio. Il piano di rilascio e distribuzione per un rilascio dovrebbe specificare

la portata e il contenuto del rilascio

rischi associati

soggetti interessati dal rilascio

il team responsabile del rilascio

il programma di distribuzione degli aggiornamenti

la strategia di consegna e distribuzione degli aggiornamenti

le risorse necessarie per la fase successiva, e


25

i criteri di accettazione o di rifiuto per il rilascio

Costruire e pianificazione dei test deve lavorare con la convalida del servizio e la prova assicurare
che i piani di test possono essere effettuati.

Grafico
Un diagramma mostra che il rilascio costruire e testare nei collegamenti processo di rilascio e
gestione di distribuzione al servizio di validazione e testing. Altri processi del processo di
rilascio e distribuzione di gestione sono la pianificazione di rilascio, distribuzione di rilascio, e
la revisione e vicino.
Le attivit che si svolgono durante il rilascio e la pianificazione della distribuzione includono lo
sviluppo di costruire piani, le specifiche di progettazione e requisiti di configurazione dell'ambiente.
Durante questa fase, il team stabilisce anche la logistica di rilascio e gli orari, definisce una linea di
base di configurazione per l'ambiente di sviluppo, verifica la compilazione e relative procedure, e
assegna le risorse, i ruoli e le responsabilit per l'esecuzione di attivit chiave.

Costruzione di uscita e il test


Durante la fase di build di rilascio e di prova, un pacchetto di rilascio costruito, testato e
controllato in DML. La fase inizia con l'autorizzazione Change Management per costruire un
rilascio e termina con l'autorizzazione Change Management per il pacchetto di rilascio baselined
aggiunto nella DML dal servizio Asset and Configuration Management (SACM).
La build di rilascio e la fase di test si verifica solo una volta per ogni release.
Durante la build di rilascio e la fase di test, necessario gestire gli ambienti di costruire e
testare. Questo include il controllo dei diritti di accesso ai componenti fisici e tecnologici e la
gestione dei problemi ambientali - come il raffreddamento, misure antincendio, l'accessibilit e le
misure di sicurezza. inoltre necessario per gestire e documentare costruire e testare attivit,
come ad esempio quelli relativi al controllo di versione, la gestione della linea di base, la
generazione di report di prova, e il controllo delle uscite.
Altre attivit connesse con questa fase includono

attivit di verifica - per esempio, la verifica che i prerequisiti siano soddisfatti prima di un
assemblaggio o il collaudo inizia

attivit di preparazione - preparare e controllare il rilascio del servizio pronto per la


distribuzione per l'ambiente dal vivo, e

attivit di promozione - promuovere o consegna il rilascio del servizio alla fase successiva o
squadra

Distribuzione
Inizia la fase di implementazione con l'autorizzazione Change Management per distribuire un
pacchetto di rilascio di uno o pi ambienti di destinazione. Si conclude con la consegna alle
funzioni operative di assistenza e supporto prime fasi di vita.
Durante la fase di distribuzione, si sviluppa un piano dettagliato di attuazione, compresi i dettagli
su chi responsabile per ogni aspetto della realizzazione. Questa fase anche l'occasione per
preparare l'organizzazione e la sua gente per il cambiamento organizzativo.
Ci possono essere molte fasi di implementazione separati per ogni uscita, a seconda delle opzioni
di distribuzione previsti.
26

Parti interessate di distribuzione devono essere sufficientemente sicuri in un service release per
ricorrere ad esso, proprio loro gli aspetti della distribuzione e impegnarsi per la distribuzione.
gestione senior, i clienti, il business e service provider squadre devono accettare i costi di
implementazione, gestione, organizzazione e persone implicazioni del rilascio, nonch ogni
corrispondente organizzazione, la funzione e cambiamenti di processo.

Review e vicino
Nel rivedere una distribuzione, necessario acquisire esperienze e commenti su clienti, utenti, e la
soddisfazione del fornitore di servizi.

Grafico
Un semplice esempio di un sondaggio tra i clienti che mira a valutare un servizio richiede ai
destinatari di fornire una delle tre risposte - S, neutro, o No - "era il servizio veloce" alle
domande " stato il servizio gentile?" e "il servizio era efficiente?"
necessario verificare che eventuali problemi, errori noti, e le soluzioni sono documentati e
accettati dai soggetti interessati. Si dovrebbe anche mettere in evidenza i criteri di qualit che non
sono state soddisfatte e assicurare che le azioni necessarie, correzioni necessarie, e le modifiche
sono completi.Prima di chiudere il processo di rilascio e distribuzione di gestione, necessario
assicurarsi che non ci sono capacit, risorse, capacit, o problemi di prestazioni rimanenti per
affrontare. Per fare questo, utile rivedere gli obiettivi di prestazione, i risultati, e registro dei rischi.
inoltre necessario garantire che qualsiasi attivit ridondanti sono stati rimossi, e fare controlli
finali per assicurare il servizio pronto per la transizione dal sostegno prime fasi di vita in
funzione. Quindi, in questa fase, l'esperienza e il feedback vengono catturati, obiettivi di
performance e risultati sono rivisti , e le lezioni vengono apprese.

Domanda
processi di gestione di distribuzione corrispondono alle fasi del processo di rilascio e
distribuzione di gestione a cui appartengono.
Opzioni:
A. Sviluppare piani costruire e testare che includono i dettagli sulle risorse, i ruoli e le
responsabilit per l'esecuzione di attivit chiave
B. misurazioni di base di documenti e di limitare l'accesso alla directory dei processi
C. Assegnare un agente di helpdesk per formare la squadra e far s che lo sponsor ha
firmato di sconto su tutti i costi di implementazione
D. Nota che i criteri di qualit non sono stati rispettati e soluzioni alternative di
documenti
obiettivi:
1. Rilascio e la distribuzione di pianificazione
2. build di rilascio e di prova
3. distribuzione
4. Review e vicino

Risposta
Durante il rilascio e la distribuzione di pianificazione, necessario sviluppare piani di costruire
e testare. Costruire e attivit di pianificazione di test includono stabilisce logistica di rilascio e
gli orari, la definizione di una linea di base di configurazione per l'ambiente di sviluppo, la
27

verifica delle procedure di compilazione e le relative, e l'assegnazione delle risorse, i ruoli e le


responsabilit per l'esecuzione di attivit chiave.
Nella build di rilascio e la fase di test, necessario controllare i diritti di accesso e le attivit
documento costruire e testare, come ad esempio quelli connessi con la gestione della linea di
base e il controllo di versione.
Nella fase di distribuzione, necessario assicurarsi che le principali parti interessate accettino
i costi di implementazione e di assegnare gli individui ad attivit specifiche, come la
formazione.
Durante la revisione e vicino fase, necessario valutare la qualit di un servizio di rilascio e di
garantire che eventuali problemi, errori noti, e le soluzioni sono documentati.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D
4. Riepilogo
Il processo di rilascio e distribuzione di gestione guida la pianificazione, programmazione,
costruzione, collaudo, e la distribuzione di comunicati. Il suo campo di applicazione comprende i
processi, i sistemi e le funzioni necessarie per il confezionamento, costruire, testare e distribuire un
rilascio nell'ambiente live. Esso comprende anche processi necessari per stabilire il servizio e
formalmente consegnarla a funzioni Service Operation. Il processo di rilascio e il Deployment
Management comprende quattro fasi - di rilascio e di pianificazione della distribuzione, build di
rilascio e di test, implementazione e revisione e stretti.

5. Sommario
| Inizio pagina |
| Obiettivo di apprendimento |
| 1. Ambito di applicazione e finalit |
| 2. Le quattro fasi |
| Sommario |

28

Cambio gestione

1.

obiettivi formativi

Dopo aver completato questo argomento, si dovrebbe essere in grado di

distinguere tra i tipi di cambiamento del servizio nel processo di Change Management

individuare le interfacce del processo di Change Management

2.

Finalit e campo di applicazione

Variazione in relazione alla funzione IT si riferisce alla Inoltre, la modifica o la rimozione di tutto ci
che potrebbe avere un effetto sui servizi IT. Ci include modifiche alle architetture, processi,
strumenti, metriche e documentazione, nonch modifiche ai servizi IT e elementi di configurazione
(CI).
Le modifiche possono essere effettuate in modo proattivo - per esempio, quando le organizzazioni
sono attivamente alla ricerca di vantaggi commerciali, quali riduzione dei costi, miglioramento dei
servizi, o una maggiore facilit ed efficacia del sostegno.
In alternativa, le modifiche possono essere effettuate in modo reattivo, al fine di rispondere agli
errori che si verificano o si adattano al mutare delle circostanze.
Change Management il processo in fase di Service Transition che responsabile per il controllo
del ciclo di vita di tutte le modifiche ai servizi IT. Il suo scopo principale quello di garantire che
solo i cambiamenti positivi sono fatte e che ci comporta il minimo disturbo.

Grafico
Il ITIL Service Lifecycle costituito dalle fasi Service Strategy, Service Design, Service
Transition, Operation servizio, e Continual Service Improvement.
Lo scopo del processo di Change Management quello di controllare il ciclo di vita di tutte le
modifiche, consentendo cambiamenti positivi da effettuare con il minimo disturbo ai servizi IT. Per
fare questo, Change Management si propone di
massimizzare il valore
Un obiettivo di Change Management quello di rispondere alle mutevoli esigenze di
business dei clienti, massimizzando il valore e riducendo gli incidenti, interruzioni, e la
necessit di ri-lavoro all'interno dell'organizzazione.
allineare i servizi
Change Management mira ad allineare business e IT richieste di modifica (RFC), a sua
volta aiutare allineare i servizi IT con le esigenze aziendali.
di controllo e di documentare i cambiamenti, e
Un obiettivo di Change Management quello di garantire che cambia sono registrati e
valutati, e sono prioritarie che i cambiamenti autorizzati, progettato, testato, implementato,
documentato, e rivisto in modo controllato. Si tratta di garantire che tutte le modifiche ai CI
sono registrati nel Sistema di Gestione della configurazione (CMS).
ottimizzare rischio
A volte opportuno accettare consapevolmente un rischio perch i potenziali benefici
possono superare il rischio. Altre volte, meglio per ridurre al minimo il rischio. Efficace
29

Change Management bilancia i rischi connessi con le modifiche ai servizi IT, assicurando
che cambia solo con profili di rischio accettabili sono implementati.
Il processo di Change Management per un servizio IT che fornisce l'organizzazione si interfaccia
con i processi utilizzati da imprese e fornitori a livello strategico, tattico e operativo. Si interfaccia
anche con i processi utilizzati dai fornitori di servizi IT interni ed esterni, in cui devono essere gestiti
modifiche alle risorse condivise e IC.

Grafico
Un diagramma mostra che un fornitore di servizi che gestisce le modifiche a servizi IT a livello
di cambiamento strategico, le modifiche a un portafoglio di servizio a livello di cambi tattici, e
le modifiche alle operazioni di servizio a livello cambiamento operativo.
Un business gestisce le modifiche al business al livello di cambiamento strategico, cambia ai
processi di business ad un livello cambiamento tattico, e modifiche alle operazioni di business
a livello cambiamento operativo.
un fornitore gestisce le modifiche alle attivit del fornitore a livello di cambiamento strategico,
modifiche ai servizi esterni a livello di cambiamento tattico, e modifiche alle operazioni
esterne a livello di cambiamento operativo.
cambiamenti strategici di business, fornitore di servizi e fornitori sono legati, come sono quelli
sul cambiamento argine tattica e il livello di cambiamento operativo.
Change Management deve interfacciarsi con Change Management aziendale e con Change
Management del fornitore. Questo pu essere un fornitore esterno all'interno di un sistema formale
di gestione delle modifiche, o dei meccanismi di modifica del progetto all'interno di un progetto di
sviluppo interno.
Del portafoglio di servizi risiede a livello tattico all'interno dell'offerta fornitore di servizi. Questo
portafoglio fornisce una chiara definizione di tutti i servizi attuali, pianificati, e in pensione. Capire il
portafoglio servizio aiuta tutte le parti coinvolte nella fase di Service Transition per capire il
potenziale impatto di un cambiamento di servizio IT sui servizi attuali e sui servizi in cantiere.

Grafico
Il portafoglio di servizio al centro del processo di cambiamento tattico e dispone di un
collegamento a due vie per la gestione di servizi IT (fornitore di servizi), la gestione del
processo di business (business), e la gestione dei servizi esterni (fornitore). Il portafoglio di
servizio ha anche un collegamento bidirezionale per le operazioni di servizio - che
responsabilit del fornitore di servizi a livello operativo cambiamento.
Change Management non responsabile del coordinamento di tutti i processi di gestione dei
servizi al fine di garantire la corretta attuazione dei progetti. Al contrario, questo si ottiene
attraverso la pianificazione di transizione e di sostegno.
Un'organizzazione dovrebbe definire i tipi di modifiche che si trovano al di fuori della portata del
suo processo di Change Management.
Tipicamente questi includono i cambiamenti che hanno un impatto significativamente pi largo che
i cambiamenti di servizio o cambiamenti a livello operativo. Ad esempio, out-of-scope modifiche
potrebbe includere ampia cambia alle politiche o alle operazioni di business. Prima di questi
potrebbero essere gestite attraverso un processo IT Change Management, avrebbero dovuto
essere tradotti in RFC associati ai cambiamenti di servizi IT necessari.
30

3.

tipi di modifica di servizio

In genere tutte le modifiche vengono avviate tramite una richiesta documentata di qualche tipo. . Il
livello di dettaglio e il tipo di autorizzazione richiesta generalmente dipende dalla natura del
cambiamento
variazioni sono spesso classificati come maggiore, significativa, o minore - a seconda del livello di
costi e rischi connessi, e sulla portata di un cambiamento e la sua relazione ad altri cambiamenti. Il
modo in cui un cambiamento classificato pu essere utilizzato per identificare un'autorit
modifica appropriata.
Una pratica migliore per un'organizzazione di predefinire modelli di cambiamento e di applicarle
ad appropriarsi modifiche quando si verificano, in base al proprio ambiente e necessit.
Un modello di cambiamento definisce una sequenza di passi concordata e strumenti di supporto
per la gestione di un particolare tipo di cambiamento. Essa aiuta a garantire che le modifiche sono
gestite in modo coerente e in linea con tempi predefiniti.
Cos come contempla passi per la movimentazione di un particolare tipo di modifica, un modello
cambiamento dovrebbe definire le dipendenze tra i passaggi o richieste co-elaborazione. Esso
dovrebbe includere anche un elenco delle responsabilit, le persone a cui questi vengono
assegnati, e tempi e soglie per il completamento delle fasi definite. Infine, un modello di
cambiamento dovrebbero definire una procedura di escalation del caso, identificare chi deve
essere contattato e quando.
I tre principali documenti informativi connessi con l'avvio e il controllo Change Management sono
proposte di modifica
Il processo Service Portfolio Management, o di un programma o di gestione del progetto,
garantisce le proposte di modifica sono sottoposti alla gestione del cambiamento prima di
noleggio di nuovi o modificati servizi IT. Questi documenti sono utilizzati per garantire che le
potenziali conflitti per le risorse o altri problemi vengono identificati. Una proposta di
cambiamento comunica una descrizione di alto livello della proposta di modifica, tra cui i
risultati di business da sostenere, e l'utilit e la garanzia da fornire. Esso dovrebbe
includere anche una pianificazione e un business case completo, compreso i rischi, le
alternative e il budget e le aspettative finanziarie. Autorizzazione della proposta
cambiamento non autorizza l'attuazione del cambiamento, ma semplicemente permette al
servizio di essere noleggiata in modo che Service Design pu cominciare.

RFC, e
Un RFC un formale e documentata - sia scritta o elettronica - proposta di modifica da
apportare. Esso comprende i dettagli del cambiamento proposto. Il termine RFC spesso
abusato per indicare un record di modifica, oppure il cambiamento stesso. RFC vengono
utilizzati solo per presentare le richieste. Essi non sono utilizzati per comunicare le
decisioni del Change Management o per documentare i dettagli del cambiamento.

31

RFC potrebbero includere una chiamata di servizio scrivania, un documento di avvio del
progetto, o un modello RFC specifica.
record di modifica
Un record cambiamento un disco che documenta il ciclo di vita di una singola modifica, e
viene utilizzato per gestire il ciclo di vita di quel cambiamento.
Un record cambiamento viene creato per ogni RFC, compresi quelli che vengono
successivamente respinto.
Un record cambiamento dovrebbe fare riferimento ai IC colpite per la modifica proposta, e
tutte le informazioni necessarie a un cambiamento, comprese le informazioni dal RFC.
cambiare le registrazioni possono essere memorizzate nel CMS o altrove nel servizio
Knowledge Management System (SKMS).
I vari processi possono generare proposte di modifica, che vengono poi sottoposti alla gestione del
cambiamento. Ad esempio, le proposte di modifica possono derivare da attivit nel Service
Portfolio Management, Continual Service Improvement, Service Level Management e processi di
catalogo Service Management.
Inoltre, errori o problemi identificati durante la fase di Service Operation possono portare alla
generazione di un RFC formale.
Il processo di Change Management implica una revisione ogni proposta di cambiamento e il
programma di cambiamento in corso, identificando eventuali conflitti o problemi, e sia che
autorizza la modifica proposta o documentare i problemi che devono essere risolti.
Una volta che la proposta di modifica autorizzata, il programma di cambiamento deve essere
aggiornato per includere il quadro delle date di attuazione per il cambiamento.
Dopo il servizio nuovo o modificato noleggiata, RFC vengono utilizzati per chiedere
l'autorizzazione per le modifiche specifiche. Questi RFC dovrebbero essere associato con la
proposta cambiamento in modo che Change Management ha una vista l'intento strategico globale
e pu dare la priorit e rivedere le RFC in modo appropriato.
Diversi tipi di cambiamento possono richiedono diversi tipi di richieste di modifica. I tre tipi
fondamentali di modifiche al servizio sono
Standard
Un cambio di serie un qualsiasi cambiamento che pu essere visto come un
cambiamento pre-approvato, con l'autorizzazione efficacemente dato in
anticipo.Approvazione bilancio sar tipicamente preordinata o sotto il controllo della parte
che richiede il cambiamento. Un trigger definito avvia un cambiamento standard.Un
esempio potrebbe essere una richiesta da un utente per reimpostare una password o per
aumentare la dimensione della cassetta postale dell'utente in un'applicazione di posta
elettronica. Una procedura standardizzata dovrebbe esistere per l'attuazione del
cambiamento, che si verifica comunemente o previsto.Modifiche standard tipicamente
comportano rischi e bassi costi, e bassi livelli di sforzo da implementare.

emergenza, e
32

Un cambiamento di emergenza deve essere attuata quanto prima - per esempio, per
risolvere un incidente grave o implementare una patch di protezione quando viene rilevata
una minaccia ad alto rischio. Modifiche emergenza deve essere accuratamente studiato e
testato per quanto possibile prima che siano attuato, o l'impatto dei cambiamenti stessi pu
essere peggiore di quella dell'incidente originale. Tuttavia, ci pu essere un tempo minimo
disponibile per l'attuazione di questi tipi di modifiche. Dettagli di modifiche di emergenza
possono essere documentati in modo retrospettivo.
normale
Un cambiamento normale un qualsiasi cambiamento di servizio che non un
cambiamento standard o di emergenza. Quindi questo tipo di modifica non associato con
un processo di pre-approvati, standardizzato, ma anche non classificato come
emergenza.
Ad esempio, un'organizzazione sa che uno dei suoi sistemi di monitoraggio software di rete
dovr essere aggiornato se a continuer a sostenere il traffico di rete a livelli ottimali in
futuro. Come misura proattiva, l'organizzazione decide di eseguire l'aggiornamento prima
che si verifichino problemi di prestazioni. Questo un cambiamento normale nel senso che
dovrebbe passare attraverso il processo formale e completo Change Management.
Nessun cambiamento dovrebbe essere autorizzata a meno che la questione di cosa fare se il
cambiamento non successo stato affrontato in modo esplicito. Questo tipo di piano
conosciuto come un piano di bonifica. Essa delinea le azioni necessarie per recuperare dopo un
fallito IT modificare o rilascio.
E 'importante considerare quali opzioni sono disponibili bonifica come parte della valutazione del
rischio di una modifica proposta in modo che l'azione correttiva pu essere presa, se necessario,
dopo un cambiamento autorizzato viene implementata.
Bonifica pu includere piani di back-out, l'invocazione dei piani di continuit del servizio, o altre
azioni dirette a rendere i processi di business per continuare.
Un piano di back-out in genere la risposta ideale bonifica. Essa specifica come ripristinare
l'organizzazione al suo stato iniziale, spesso attraverso la ricarica di una serie di baselined CI - in
particolare per software e dati.
Tuttavia, non tutti i cambiamenti sono reversibili, per cui pu essere richiesto un approccio
alternativo alla bonifica. Ci potrebbe includere la revisione della stessa variazione in caso di
fallimento, o - se l'impatto di un fallimento grave, anche invocando piano di continuit operativa
dell'organizzazione.
Cambiare i piani di attuazione dovrebbero includere anche le tappe e altri trigger per l'attuazione
degli interventi di bonifica, al fine di garantire non c' tempo sufficiente per il back-out o altre
bonifica in caso di necessit.

Domanda
Abbinare ogni esempio i tipi di cambio servizio nel processo Change Management a cui
appartiene.
Opzioni:
A. Fornitura di attrezzature e servizi definiti di un nuovo dipendente
B. Un piccolo cambiamento nella domanda di libro paga di un'azienda sta causando
una lieve diminuzione dei livelli di capacit su un server di rete in modo che si
desidera aumentare la capacit della rete globale per supportare i requisiti futuri
33

C. Un server chiave fallisce e una sostituzione temporanea deve essere installato fino a
quando il server fisso
obiettivi:
1. cambiamento standard
2. cambiamento normale
3. cambiamento di emergenza

Risposta
modifiche standard sono quelli che sono pre-approvato, comuni, e associata a processi
standardizzati. Esempi stanno fornendo attrezzature e servizi standard per i nuovi dipendenti,
e la rimozione degli account utente quando i dipendenti lasciano l'organizzazione.
Normali modifiche avvengono solo saltuariamente, e non sono molto urgente. Non sono preapprovato e hanno bisogno di passare attraverso l'intero processo di Change
Management. Aggiunta di capacit di una rete o un server per migliorare le prestazioni future
rete un esempio di un cambiamento normale.
Un cambiamento di emergenza quello che ha da attuare rapidamente per risolvere un grave
incidente o di impedire che si verifichi uno. Un esempio la configurazione una sostituzione
se un server chiave fallisce.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
4. interfacce Change Management
For Change Management per essere efficace, ci sono molti altri processi che si interfaccia
con. Change Management lavora con la pianificazione di transizione e il sostegno per assicurare
che ci sia un approccio coordinato alla gestione di servizi transizioni.
Change Management e di uscita e di gestione di distribuzione sono integrati - processi di
condivisione utilizzati per i programmi organizzativi o progetti per definire confini chiari, le
dipendenze e le regole.
Change Management si interfaccia anche con la gestione del fornitore, in cui i cambiamenti
influiscono o possono essere influenzati dai fornitori.
Per garantire che le informazioni sulle modifiche vengono scambiate e cascata in tutta
l'organizzazione, gestione del cambiamento in genere si integra con i processi di cambiamento
aziendale.
Se del caso, Change Management deve essere coinvolto con programma di attivit e di gestione
del progetto di business team. Primo allineamento tra Change Management e programmi e
progetti di gestione essenziale per garantire che il programma di cambiamento efficace e che
tutte le modifiche sono ben gestito.
Modifiche a qualsiasi deliverable attivit o progetto che non impattano servizi o componenti di
servizio possono essere soggetti a procedure di lavoro o progetto di cambiamento di gestione,
piuttosto che in EN Cambia procedure di gestione. In questi casi, tuttavia, la gestione del
cambiamento ancora coinvolto in
34

la gestione di linee di base di configurazione


Si deve prestare attenzione al fine di garantire che le modifiche alla configurazione del
servizio linee di base e rilascia seguono il processo di Change Management.
collegamento con i team di progetto
Il team di Change Management sar chiamato a mantenere i contatti a stretto contatto con i
team di progetto per garantire la corretta attuazione e coerenza all'interno degli ambienti
che cambiano.
movimentazione proposte di modifica
Il processo Service Portfolio Management presenter proposte di modifica alla gestione del
cambiamento prima di noleggio di nuovo o modificato servizi IT, al fine di assicurare che i
potenziali conflitti per le risorse o altri problemi vengono identificati.
Il processo di Change Management si interfaccia anche con la valutazione del cambiamento. Ci
dovrebbe essere chiaro accordo su quali tipi di cambiamento saranno oggetto di valutazione
formale cambiamento, e il tempo necessario per questa valutazione deve essere incluso nella
programmazione globale per il cambiamento. Change Management fornisce il grilletto per la
valutazione cambiamento, e la relazione di valutazione deve essere consegnato alla gestione del
cambiamento in tempo per l'autorit di cambiamento di usarlo per aiutare nel processo
decisionale.
Le tre interfacce chiave rimanere con Change Management sono
Change Management Stakeholder
Alcune organizzazioni hanno una funzione separata per gestire le modifiche organizzative noto come Stakeholder Change Management. In altre organizzazioni questa funzione
svolta dalla funzione IT.
Se queste funzioni sono separati o no, hanno bisogno gli aspetti organizzativi di Change
Management per essere adeguatamente considerato e il processo di Change Management
ha bisogno di interfacce appropriate con le persone che svolgono questo lavoro.
sourcing e partnering, e
Sourcing e le relazioni di partenariato coprono venditori e fornitori che stanno fornendo un
nuovo o esistente IT servizio per l'organizzazione interna ed esterna.
Pratiche efficaci Change Management sono necessari per gestire queste relazioni in modo
efficace e per garantire la regolare erogazione dei servizi. Si dovrebbe anche sapere come
partner di gestire il cambiamento all'interno della propria organizzazione. Sourcing e
accordi di partnership dovrebbe definire il livello di autonomia di un partner pu avere nel
realizzare il cambiamento. Alcune organizzazioni in situazioni di outsourcing si riferiscono
RFC ai loro fornitori per le stime prima di autorizzare le modifiche.
Gestione del servizio
Tutti i processi di gestione dei servizi possono richiedere Change Management, ad
esempio per realizzare miglioramenti di processo.

35

Molti processi di gestione dei servizi saranno coinvolti nella valutazione di impatto e
l'attuazione delle modifiche di servizio.

Domanda
Quali sono le interfacce chiave del processo di Change Management?
Opzioni:
1. L'integrazione con i processi di cambiamento aziendale
2. L'allineamento con il programma e la gestione dei progetti
3. Un focus sulla organizzativo e Stakeholder Change Management
4. L'allineamento con sourcing e partnership
5. L'integrazione con le funzioni di controllo e di protezione
6. L'allineamento con la ridondanza e la gestione dello storage

Risposta
Opzione 1: Corretto. L'integrazione con i processi di cambiamento di business
importante. Se del caso, Change Management deve essere coinvolto con programma di
attivit e di gestione del progetto di business team per garantire che le questioni del
cambiamento, gli scopi, gli impatti e gli sviluppi sono scambiati e cascata in tutta
l'organizzazione.
Opzione 2: Corretto. Programma e la gestione del progetto un'interfaccia chiave. Stretto
allineamento tra il Change Management e programmi e progetti di gestione essenziale per
garantire che il programma di cambiamento efficace e che tutte le modifiche sono ben
gestito.
Opzione 3: Corretto. Gestione organizzativa e delle parti interessate Il cambiamento
un'interfaccia essenziale. Aspetti organizzativi di Change Management devono essere
adeguatamente considerato e il processo di Change Management dovrebbero avere
interfacce appropriate con le persone che svolgono questo lavoro.
Opzione 4: Corretto. Pratiche di Change Management efficace sono necessari per gestire
l'approvvigionamento e le relazioni al fine di garantire la consegna regolare del servizio e che
i partner utilizzano processi di Change Management che si pu facilmente allinearsi con.
Opzione 5: non corretto. Anche se Change Management ha molte interfacce, non richiede
l'integrazione con le funzioni di controllo e di protezione. Essa, tuttavia, condividono una forte
interfaccia con la valutazione del cambiamento.
Opzione 6: non corretto. Anche se Change Management ha molte interfacce, non richiede
l'allineamento con le funzioni di ridondanza e di gestione dello storage.
Risposte corrette):
1. L'integrazione con il cambiamento dei processi aziendali
2. L'allineamento con il programma e progetto di gestione
3. Un focus sulla organizzativo e Stakeholder Change Management
4. L'allineamento con sourcing e partnership
5. Riepilogo
L'ambito di Change Management include modifiche a tutte le architetture, processi, strumenti,
metriche, e la documentazione, nonch modifiche ai servizi IT e altri CI. Change Management si
propone di massimizzare il valore, allineare i servizi, ottimizzare rischio e di controllo e di
36

documentare i cambiamenti. Documentazione associata al processo di cambiamento comprendere


proposte di modifica, RFC e modificare i record. I cambiamenti possono rientrare in tre categorie di
base che influenzano come il cambiamento viene gestito. Queste categorie sono il cambiamento di
serie, cambio normale, e il cambiamento di emergenza. Change Management si interfaccia a
stretto contatto con molti altri processi. Questi includono la pianificazione di transizione e di
sostegno, di uscita e Deployment Management, Gestione dei fornitori, processi di cambiamento
aziendale, il programma e la gestione dei progetti, la gestione di linee di base di configurazione, in
collegamento con i team di progetto, la gestione delle proposte di modifica, la valutazione
cambiamento, gestione del cambiamento delle parti interessate, l'approvvigionamento e la
partnership e di servizio Gestione.

6. Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Scopo e campo |
| 2. Tipi di modifica Servizio |
| 3. Cambiare le interfacce di gestione |
| Sommario |

37

Normali e di emergenza Variazioni Change Management


1. obiettivi formativi
Dopo aver completato questo argomento, si dovrebbe essere in grado di

identificare le fasi del ciclo di vita normale modifica

identificare gli aspetti della procedura di cambiamento che potrebbe differire da una
normale procedura di cambio di modifiche di emergenza
2. il cambiamento del ciclo di vita normale
ITIL definisce il normale ciclo di vita del cambiamento come comprendente otto passi. A seguito
di questi passaggi pu aiutare a garantire efficaci Change Management.

Grafico
Le fasi del ciclo di vita normale cambio sono a 1. creare RFC, 2. recensione RFC, 3. valutare
il cambiamento, 4. autorizzare il cambiamento di costruzione e di prova, 5. coordinare la
costruzione cambiamento e di prova, 6. distribuzione di autorizzare, 7. coordinate
distribuzione e 8. revisione e vicino.
I primi quattro passi nella normale messa a fuoco il cambiamento del ciclo di vita sulla valutazione
e l'autorizzazione per la costruzione e collaudo modifiche.
1. Creare RFC
L'individuo o il gruppo che propone un cambiamento crea la richiesta di modifica
(RFC). Tutte le RFC ricevuti devono essere registrati e assegnati numeri di identificazione
in sequenza cronologica. Se una richiesta di modifica presentata in risposta a un trigger,
quale una risoluzione ad un record di problema, dovrebbe essere registrato il numero di
riferimento di un documento sull'evento scatenante.
2. Review RFC
Change Management dovrebbe garantire che le RFC includono tutte le informazioni
richieste. RFC incompleti o impraticabili devono essere restituiti, insieme con brevi dettagli
del perch che sono stati respinti - e lo stato delle RFC devono essere registrati. Se un
RFC accettato, si passa alla fase successiva.
3. Valutare il cambiamento
I cambiamenti ritenuti significativi - sulla base di criteri ben definiti - dovrebbero essere
sottoposti al processo di valutazione cambiamento formale. Una richiesta formale di
valutazione dovrebbe essere presentata per innescare questo processo. Quando la
valutazione cambiamento formale non richiesta, una modifica proposta pu essere
valutata in modo pi informale.
4. Autorizzare costruire il cambiamento e il test
Autorizzazione formale per qualsiasi cambiamento deve essere ottenuto da un'autorit di
cambiamento adatto, che pu essere un individuo o un gruppo di persone. I livelli di
autorizzazione necessaria per un particolare tipo di cambiamento dovrebbero essere
basate sul tipo, le dimensioni, il rischio e il potenziale impatto sul business del
cambiamento. Le controversie su autorizzazione cambiamento o il rifiuto, ci dovrebbe
essere un diritto di ricorso ad un'autorit a un livello superiore. Le modifiche che sono state
respinte devono essere formalmente recensione, documentate, e chiusi.
38

Si consideri un esempio. In primo luogo il reparto IT di un'organizzazione riceve un RFC dal


reparto vendite, chiedendo che un server sicuro essere impostato per scopi di ecommerce. Questa passato al team IT Change Management.

Grafico
1. Creare RFC evidenziato nel diagramma del ciclo di vita.
Il team esamina poi il RFC, controllando che contiene tutte le informazioni necessarie.

Grafico
2. recensione RFC evidenziato nel diagramma del ciclo di vita.
Mentre il terzo passo, il team di Change Management valuta e valuta la modifica proposta,
utilizzando una serie di sette domande "R":

Grafico
3. Valutare il cambiamento evidenziato nel diagramma del ciclo di vita.

Chi ha r aised il cambiamento?

Qual il r Eason per il cambiamento?

Che r eturn richiesto dal cambiamento?

Quali r ischi sono coinvolti nel cambiamento?

Quali r isorse sono tenuti a consegnare il cambiamento?

Chi r esponsible per la costruzione, prova e l'attuazione del cambiamento?

Qual la R APPORTI tra questo cambiamento e altri cambiamenti?

Come la quarta fase del ciclo di vita normale cambiamento, la modifica proposta - che ritenuta
essere di valore - formalmente autorizzata dai membri di un Change Advisory Board (CAB).

Grafico
4. Autorizzare costruire il cambiamento e il test viene evidenziato nel diagramma del ciclo di
vita.
I passi da 5 a 8 sono gli ultimi quattro passaggi della normale cambiamento del ciclo di vita.
5. Coordinare costruire il cambiamento e il test
Se un cambiamento autorizzato parte di un rilascio, quindi il confezionamento del
cambiamento in un rilascio e la costruzione e la sperimentazione si coordinato con il
processo di rilascio e Deployment Management. Per semplici modifiche che non fanno
parte di un rilascio, il processo di Change Management coordina costruzione e
collaudo. Change Management inoltre responsabile di assicurare che i cambiamenti sono
accuratamente testati. Dove i cambiamenti di emergenza non sono stati completamente
testati, particolare attenzione deve essere presa durante l'implementazione. Testing pu
continuare in parallelo con la distribuzione iniziale di un servizio nell'ambiente dal vivo in
modo che ulteriori azioni correttive pu essere presa se necessario.

6. distribuzione Autorizza
39

La progettazione, la costruzione e la sperimentazione di un cambiamento dovrebbero


essere valutati per garantire che i rischi sono stati gestiti e che le prestazioni effettive
soddisfa le esigenze di business. Il processo di valutazione cambiamento genera una
relazione di valutazione intermedia per eventuali variazioni significative. Per piccoli
cambiamenti, il processo di Change Management effettua controlli adeguati. Il risultato di
questa valutazione dovrebbe essere trasmessa all'autorit modifiche necessarie per
l'autorizzazione formale per implementare il cambiamento. Se l'autorizzazione non dato,
in questa fase, l'autorit cambiamento pu richiedere modifiche al design o alla
pianificazione della distribuzione.

7. coordinate distribuzione
Il processo di Change Management coordina distribuzione per semplici modifiche che non
fanno parte di un rilascio. Change Management responsabile di assicurare che i
cambiamenti vengono distribuiti e programmati quando il minimo impatto sulle operazioni in
tempo reale probabile. Il personale di supporto dovrebbero essere a disposizione per
affrontare rapidamente eventuali incidenti che potrebbero sorgere.
Ogni distribuzione deve essere autorizzata. Ci pu richiedere che pi RFC essere
presentate. In alternativa, alcune organizzazioni utilizzano un singolo RFC con pi fasi di
autorizzazione. Inoltre, le procedure di bonifica devono essere preparati e documentati in
anticipo gli errori si verificano casi. Autorit e la responsabilit per invocare la bonifica
dovrebbero essere definite in maniera specifica documentazione di cambiamento.
8. Review e vicino
Prima di chiudere un cambiamento, deve essere valutata in termini di prestazioni e di
garantire che il cambiamento non ha introdotto eventuali rischi inaccettabili.La valutazione
dovrebbe anche valutare eventuali incidenti associati. Se un provider esterno gestisce il
cambiamento, saranno necessari i dettagli di tutti gli obiettivi di servizi contrattuali. Per
cambiamenti significativi, il processo di valutazione cambiamento genera una relazione di
valutazione. Per piccoli cambiamenti, opportuni controlli sono condotti come parte del
processo di Change Management. Se la valutazione di un cambiamento favorevole, il
cambiamento si presenta come completato per accordo sul cambiamento delle parti
interessate. Le lezioni apprese devono essere registrati in modo da informare i
cambiamenti futuri.

Nel caso della richiesta di un nuovo server di e-commerce, gli ordini di lavoro per le modifiche
autorizzate vengono inviate a hardware, la sicurezza e le applicazioni squadre durante la quinta
fase del normale cambiamento del ciclo di vita. Questi ordini di lavoro sono monitorati e collegati
alle RFC originali. Durante il Change Management supervisionato il processo per assicurare che
il server sia accuratamente testato.

Grafico
5. Coordinare costruire il cambiamento e il test viene evidenziato nel diagramma del ciclo di
vita.

40

Una volta completato il test, un'autorit cambiamento del cliente la relazione intermedia di
valutazione al fine di garantire che il server pu eseguire, come richiesto. E poi autorizza
formalmente l'implementazione del server richiesto.

Grafico
6. distribuzione autorizzata evidenziato nel diagramma del ciclo di vita.
Il team di Change Management coordina le scadenze per l'introduzione e monitor per garantire
che tutto va come previsto.

Grafico
7. coordinate distribuzione evidenziato nel diagramma del ciclo di vita.
Infine, il team valuta se il nuovo server soddisfare le esigenze del reparto vendite e
l'organizzazione complessiva.

Grafico
8. Review e vicino evidenziato nel diagramma del ciclo di vita.

Domanda
Nel corso di una riunione strategica, si scopre che la vostra organizzazione intende
aumentare il numero dei suoi dipendenti del 7% nel prossimo trimestre. La rete attualmente
gestendo le richieste bene, ma si sospetta che avrete bisogno di un server aggiuntivo per
bilanciare i carichi di rete. Cos si crea un RFC e inviarlo al team di Change Management. Il
team ti chiede ulteriori informazioni costo, che si presenta. E poi autorizza la
modifica. Sequenza i restanti esempi dei passaggi della normale cambiamento del ciclo di
vita.
Opzioni:
A. Un dirigente valuta la RFC e approva formalmente la richiesta.
B. Impostare, costruire, e server di prova in scenari ad alto traffico
C. La performance del server viene valutata contro le previsioni, ed i risultati mostrano
che la pianificazione della distribuzione non uscita e ha autorizzato
D. Il server configurato nel corso di un periodo di basso traffico secondo il calendario
E. L'andamento complessivo del server viene valutata e il record cambiamento
archiviato

Risposta
Risposte corrette):
Un dirigente valuta la RFC e approva formalmente la richiesta. classificato
Questo parte di un gradino cambiamento autorizzare costruire e testare, e quindi la
quarta fase del processo.
Impostare, costruire, e server di prova in scenari ad alto traffico classificato
Questo fa parte di coordinare build cambiamento e di prova, ed la quinta fase del
processo di cambiamento.
La performance del server viene valutata contro le previsioni, ed i risultati mostrano che la
pianificazione della distribuzione non uscita e ha autorizzato classificato

41

Questo un esempio di una azione intrapresa durante la fase di dispiegamento


cambiamento autorizzare, ed la sesta fase nel processo di cambiamento.
Il server configurato nel corso di un periodo di basso traffico secondo i piani classificato
Questo un esempio di come Change Management prevede di coordinare distribuzione
cambiamento, e cos il settimo passo nel processo.
L'andamento complessivo del server viene valutata e il record cambiamento archiviato
classificato
Questa attivit si verifica durante la revisione finale e la chiusura del record cambiamento,
che il passo finale nel normale cambiamento del ciclo di vita.
3. cambiamento del ciclo di vita di emergenza
Il numero di modifiche di emergenza proposte dovrebbe essere ridotto al minimo perch questi tipi
di cambiamenti tendono ad essere dirompente e incline al fallimento. Quindi, per quanto possibile,
tutte le modifiche che possono essere richiesto devono essere previste e pianificate, tenendo
conto della disponibilit di risorse per costruire e testare le modifiche.
Inoltre, quando necessario un cambiamento urgente - a causa di scarsa pianificazione o di
improvvisi cambiamenti di requisiti di business - preferibile se pu essere trattato come un
cambiamento normale, ma data la massima priorit.
Tuttavia, possono talvolta essere necessarie modifiche di emergenza. E 'importante avere
procedure in atto per la gestione di questi in fretta, ma senza sacrificare importanti controlli di
gestione.
Una procedura di cambio di emergenza dovrebbe essere generalmente riservato per le modifiche
volte a correggere gli errori nel settore dei servizi IT che stanno avendo un significativo impatto
negativo sugli utenti di un'azienda o clienti.
Modifiche finalizzato a introdurre miglioramenti aziendali urgentemente necessarie dovrebbero
essere trattati come normali cambiamenti, ma assegnato il massima urgenza.
Il cambiamento di emergenza del ciclo di vita fondamentalmente la stessa della normale
cambiamento del ciclo di vita. Tuttavia, a causa dei vincoli di tempo in una situazione di
emergenza, alcuni dei passi possono essere gestiti in modo leggermente diverso.
le procedure di modifica normali e di emergenza possono essere diverse in quattro aree
fondamentali.
Autorizzazione
Spesso in caso di emergenza, un incontro pieno CAB non pu essere ritenuta. Nei casi in
cui richiesta l'autorizzazione CAB, pu quindi essere istituito un CAB emergenza (ECAB)
secondo procedure dell'organizzazione per questo. Prevedibili modifiche di emergenza come guasti del server - improbabile che hanno bisogno di un ECAB. Al contrario,
l'autorit per autorizzare questi cambiamenti pu essere delegata alle funzioni di servizio
funzionamento, la gestione tecnica, o di Application Management. Tale delega deve essere
limitata ad azioni che non cambiano la specificazione delle attivit di servizio e di non
tentare di correggere gli errori del software. Con incidenti software, meglio tornare allo
stato precedente o di fiducia versione, piuttosto che tentare una modifica non pianificata e
potenzialmente pericoloso.

42

analisi
Modifiche emergenza deve essere accuratamente studiato e testato per quanto possibile
prima dell'uso, o l'impatto della variazione di emergenza pu essere maggiore del incidente
originale. Cambia completamente testati non dovrebbero essere attuati se questo del
tutto evitabile. Il meno un cambiamento si ritiene probabile che fallire, il pi ragionevole pu
essere di ridurre il periodo di prova in caso di emergenza.

Quando solo limitato di test possibile, allora il test deve essere focalizzata su aspetti del
servizio che saranno utilizzati immediatamente, oppure elementi che potrebbero far s che
la maggior disagio a breve termine o gli errori una volta vivono nell'ambiente.
Cambio recensione
Se una modifica non riesce a correggere l'errore eccezionale urgenza, possono essere
necessari tentativi iterative a correzioni. Change Management dovrebbe assicurare che le
esigenze di business rimangono la preoccupazione principale e che ogni iterazione
controllato. Change Management deve garantire che i cambiamenti inefficace, sono
rapidamente fatto da parte. Se troppi tentativi di un cambio di emergenza sono inefficaci,
necessario considerare se l'errore stato correttamente diagnosticato, la risoluzione
stato adeguatamente testato, e la soluzione stata implementata in modo corretto. In tali
circostanze, pu essere meglio per fornire un servizio parziale consentire la modifica da
accuratamente testato, o forse per sospendere temporaneamente il servizio e quindi
implementare il cambiamento.

Documentazione
Potrebbe non essere possibile aggiornare tutti i record di modifica al momento che le azioni
urgenti sono in fase di completamento. Ad esempio, questi cambiamenti possono verificarsi
durante la notte o durante il fine settimana.
E ', tuttavia, essenziale che i record temporanei sono realizzati durante tali periodi, e che
tutti i record sono stati completati retrospettivamente, alla prima occasione possibile. Un
accordo per il completamento di questi aggiornamenti dovrebbero essere documentata
quando il cambiamento autorizzato.
Supponiamo che un'organizzazione ha pi rapporti in arrivo dei clienti non in grado di accedere al
loro sistemi libro paga. Attraverso procedure problema di gestione, si scoperto che un server non
riuscito.
Questo richiede un cambiamento di emergenza. L'hardware del server deve essere riparato o
sostituito, e un piccolo cambiamento nella configurazione del server pu essere richiesto. Il
cambiamento in questo caso pu essere autorizzato da personale operativo, anzich richiedere
l'autorizzazione da parte di un ECAB.
A causa di vincoli di tempo, solo le funzioni di ingresso giornalieri per il libro paga sono testati. Di
fine mese routine non sono testati a questo punto.

43

Il team di attuazione dei documenti di cambiamento che ha dato l'autorit per esso e mantiene le
note dettagliate su come viene attuato il cambiamento. Le note affermano che i rapporti completi
saranno completati entro tre giorni lavorativi.

Domanda
Un nuovo virus infetta rete di un'organizzazione a causa di una vulnerabilit del sistema
operativo. Una patch di sicurezza immediato necessario per salvaguardare la rete da
ulteriori attacchi. Quali sono esempi di misure adeguate la squadra dovrebbe prendere in
questo caso, ma che non sarebbe appropriato in una normale procedura di cambiamento?
Opzioni:
1. Ottenere l'autorizzazione da un ECAB per il cambiamento
2. Eseguire solo i test di base sulla patch di protezione, la programmazione pi
numerosi test una volta che la patch in diretta
3. Mantenere brevi note del cambiamento e di fissare un termine per la
documentazione completa del cambiamento
4. Coordinare l'impiego del cambio in modo che il personale di supporto sono a
disposizione per affrontare eventuali incidenti che potrebbero sorgere
5. Documentare un RFC, log, e garantire assegnato un numero di identificazione

Risposta
Opzione 1: Corretto. Non ci pu essere il momento per un incontro pieno CAB. Perch la
modifica avr effetto su tutta la rete, tuttavia, opportuno garantire che il cambiamento
autorizzato da un ECAB.
Opzione 2: Corretto. C' poco tempo per prova piena, tuttavia, pu essere meglio per fornire
un servizio parziale consentire la modifica da accuratamente testato.
Opzione 3: Corretto. Anche se la documentazione completa sempre necessario, questa
documentazione pu essere differito fino dopo il cambiamento implementato in scenari di
cambiamento di emergenza.
Opzione 4: non corretto. Questo fa parte delle normali fasi di cambiamento e le
responsabilit del Change Management.
Opzione 5: non corretto. Documentare un RFC, la registrazione, e assegnazione di un
numero di identificazione un passo compiuto durante il normale ciclo di vita del
cambiamento Change Management.
Risposte corrette):
1. l'autorizzazione guadagnare da un ECAB per il cambio
2. Eseguire solo i test di base sulla patch di protezione, la programmazione pi numerosi
test una volta che la patch in diretta
3. Mantenere brevi note del cambiamento e di fissare un termine per la documentazione
completa del cambiamento
4. Riepilogo
ITIL definisce un processo di otto step per il normale cambiamento del ciclo di vita. Si inizia con
la creazione di un RFC, che viene poi recensione. La modifica proposta valutata e valutata, e
quindi la costruzione e la prova autorizzato e coordinato. Successivo distribuzione della modifica
autorizzata e poi coordinato. Infine, la modifica viene rivisto e il record di modifica in questione
chiusa. Se le modifiche di emergenza devono essere attuate, processi di autenticazione, il
44

controllo, revisione e processi di documentazione possono differire da quelli di un normale


cambiamento del ciclo di vita. Ci dovuto alla necessit di risposte rapide in situazioni di
emergenza.
5. Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Normale cambiamento del ciclo di vita |
| 2. Il cambiamento del ciclo di vita di emergenza |
| Sommario |

45

La gestione dei servizi IT Modifiche


1. obiettivi formativi
Dopo aver completato questo argomento, si dovrebbe essere in grado di

distinguere tra i tipi di cambiamento del servizio nel processo di Change Management

identificare il normale processo di cambiamento del ciclo di vita, dato uno scenario

individuare le procedure di modifica di emergenza, dato uno scenario


2. panoramica esercizio

In questo esercizio, ti viene richiesto di praticare il riconoscimento come gestire i cambiamenti di


servizi IT.
Ci comporta le seguenti operazioni:

riconoscere i tipi di cambiamento, e

individuare le fasi del processo di ciclo di vita del cambiamento


3. Riconoscere tipi di cambiamento

I cambiamenti modo in cui vengono gestite dovrebbe dipendere da come vengono classificate come i cambiamenti di serie, normali, o di emergenza.

Domanda
Abbinare ogni esempio alla corrispondente categoria di cambiamento.
Opzioni:
A. Un amministratore viene chiesto di eliminare una serie di account utente di
dipendenti in pensione
B. Un responsabile della sicurezza richiede sistemi di rilevamento delle intrusioni hostbased per un server che stato programmato per essere istituito nel prossimo
trimestre
C. Una vulnerabilit nella sicurezza di rete deve essere affrontata al pi presto possibile
per proteggere le risorse di un'organizzazione
obiettivi:
1. cambiamento standard
2. cambiamento normale
3. cambiamento di emergenza

Risposta
modifiche di routine come l'eliminazione degli account utente obsoleti sono conosciuti come i
cambiamenti standard e sono in genere pre-approvati.
Un cambiamento normale un cambiamento di linea che richiede l'approvazione prima di
essere implementato. Ci include aggiornamenti pianificati di sicurezza, come l'uso di sistemi
antintrusione supplementari.
Un cambiamento di emergenza una rapida risposta ad un errore o di sicurezza problema
non pianificata e immediato che potrebbe avere gravi implicazioni per le imprese se non
affrontato immediatamente. Un esempio il cambiamento richiesto in risposta a una
vulnerabilit significativa nella sicurezza di rete.
Risposte corrette):
46

Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
4. Riconoscendo le azioni del ciclo di vita del cambiamento

Domanda
Il dipartimento IT di un'organizzazione intende aggiornare tutta la sicurezza workstation
tirando fuori una nuova applicazione anti-malware. Ha creato e ha presentato una richiesta
per il cambiamento (RFC). La RFC stato rivisto e trasmessa, e il potenziale impatto del
cambiamento stato valutato. Inserite i passaggi rimanenti nel normale ciclo di vita del
cambiamento nell'ordine corretto.
Opzioni:
A. Ottenere l'approvazione del Change Advisory Board (CAB) per creare la build
B. Il monitoraggio delle prestazioni della nuova applicazione e assicurarsi che il test a
calendario
C. Invia risultati delle prove di autorizzazione distribuzione
D. Inviare RFC per stendere l'applicazione in ogni reparto
E. Commenta prestazioni effettive contro le stime e le risultanze documentali

Risposta
Risposte corrette):
Ottenere l'approvazione del Change Advisory Board (CAB) per creare la build classificato
La quarta fase del ciclo di vita normale cambio di autorizzare la costruzione cambiamento
e di prova. Questo in genere autorizzato da un taxi.
Il monitoraggio delle prestazioni della nuova applicazione e assicurarsi che il test a calendario
classificato
La quinta fase del ciclo di vita normale cambiamento sta coordinando l'accumulo
cambiamento e di prova. Questo include garantire che vi sia sufficiente il test del rilascio e
che questa fase si svolge all'interno del programma definito.
Invia risultati dei test per l'autorizzazione di distribuzione viene classificato
Il sesto passo nel normale ciclo di vita del cambiamento quello di autorizzare la
distribuzione cambiamento. Prima che questo pu essere fatto, i risultati della fase di
costruzione e collaudo devono essere valutati.
Inviare RFC per stendere l'applicazione in ogni reparto classificato
La settima fase del ciclo di vita normale cambiamento quello di coordinare la
distribuzione. Ci pu comportare l'invio di pi RFC per i diversi aspetti della distribuzione.
Recensione prestazioni effettive contro le stime e le risultanze documentali classificato
La fase finale del ciclo di vita normale cambiamento quello di rivedere la modifica e per
chiudere il record di cambiamento. In genere questa recensione valuta le performance
effettive rispetto delle prestazioni previste e affronta eventuali cambiamenti inaspettati.

Domanda
47

Nel corso regolari attivit di revisione organizzativa, si scoperto che c' una vulnerabilit
nella sicurezza di rete, con gli utenti viene permesso di installare software non autorizzato su
singole workstation. Questo viola i requisiti di sicurezza di rete dell'organizzazione e pone la
rete a rischio sostanziale. Un cambiamento di programmazione immediato necessario per
modificare i livelli di accesso di tutti gli utenti le opportune impostazioni. Cosa si deve fare in
sede di attuazione questo cambiamento che diverso da quello che si farebbe con una
normale procedura di cambiamento?
Opzioni:
1. Convocare un cambiamento Advisory Board di emergenza (ECAB) di autorizzare il
cambiamento
2. Eseguire il test per le attivit giorno per giorno in cui il cambiamento di
programmazione pu interessare, ma rinviare piena test
3. Fissare un termine per tutti i record di modifica da completare in modo retrospettivo
4. Rivedere la RFC per assicurarsi che copre tutte le aree necessarie
5. Rivedere il cambiamento in termini di prestazioni e chiudere il record di cambiamento

Risposta
Opzione 1: Corretto. Dopo la modifica stata esaminata e valutata, l'autorizzazione deve
essere ottenuta per costruire e testare il cambiamento. In una situazione di emergenza come
quello descritto, questo pu essere fatto tramite una ECAB. Per le modifiche di emergenza
minori, le autorit operative o altre possono autorizzare le modifiche.
Opzione 2: Corretto. Anche se pieno di test preferibile, test solo delle attivit quotidiane
che possono essere interessate dalla modifica pu essere opportuno in una situazione di
emergenza come quella descritta. Altri test possono svolgersi solo dopo che la modifica
stata implementata.
Opzione 3: Corretto. Tutte le modifiche devono essere pienamente documentati, ma nel caso
di modifiche di emergenza, questo pu essere fatto con effetto retroattivo.
Opzione 4: non corretto. Rivedere il RFC la stessa in entrambi i normali e di emergenza
cicli di vita del cambiamento.
Opzione 5: non corretto. Rivedere le prestazioni cambiamento e la chiusura del record lo
stesso in entrambi i normali e di emergenza cicli di vita del cambiamento.
Risposte corrette):
1. convocare una Change Advisory Board di emergenza (ECAB) di autorizzare il
cambiamento
2. Eseguire il test per le attivit giorno per giorno in cui il cambiamento di
programmazione pu incidere, ma rinviare piena test
3. Fissare un termine per tutti i record di modifica da completare in modo retrospettivo

Domanda
Un errore nelle formule matematiche sistema payroll di un'organizzazione stato scoperto,
con conseguente sistema non calcolando deduzioni correttamente. Una modifica immediata
alle formule necessario. Quali normale cambiamento passi del ciclo di vita pu essere
modificato per accogliere questa emergenza?
Opzioni:
48

1. Provare un altro iterazione se il cambiamento non risolve il problema, assicurando


che le modifiche inefficaci sono rapidamente sostenuti fuori
2. Convocare un taxi per valutare la RFC e di autorizzare test e implementazione
3. Creare record temporanei del cambiamento e completare questi record
retrospettivamente
4. Testare gli aspetti pi cruciali del cambiamento solo prima di distribuirlo in diretta
5. Invia una valutazione formale RFC

Risposta
Opzione 1: Corretto. Questo cambiamento nel processo di revisione pu verificarsi in alcune
situazioni di emergenza, quando importante per risolvere le situazioni in fretta.
Opzione 2: non corretto. Questo passaggio la stessa di quella in un normale ciclo di vita
cambiamento. In questo scenario, una cabina di emergenza (ECAB) - o di un altro processo
di autorizzazione - possono essere utilizzate per garantire che la modifica proposta
autorizzato il pi rapidamente possibile.
Opzione 3: Corretto. Potrebbe non essere possibile aggiornare tutti i record di modifica nel
momento in cui le azioni urgenti sono in fase di completamento. Un tempo concordato per il
completamento di aggiornamenti della documentazione deve essere determinato quando il
cambiamento in primo luogo autorizzato.
Opzione 4: Corretto. Quando solo limitato di test possibile, le prove devono essere
concentrate su aspetti del servizio che verr utilizzato immediatamente e sugli elementi del
cambiamento che pu provocare la pi disagio a breve termine.
Opzione 5: non corretto. L'invio di una valutazione formale RFC lo stesso per entrambe le
normali e di emergenza modifiche.
Risposte corrette):
1. Prova un'altra iterazione se il cambiamento non risolve il problema, assicurando che
le modifiche inefficaci sono rapidamente sostenuti fuori
3. Creare record temporanei del cambiamento e completare questi record
retrospettivamente
4. Testare gli aspetti pi cruciali del cambiamento solo prima di distribuirlo in diretta
5. Riepilogo
I cambiamenti sono stati classificati in base al loro tipo, stata identificata la sequenza di passi nel
normale cambiamento del ciclo di vita, e le differenze tra normale e di emergenza Change
Management sono stati riconosciuti.

6. Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Panoramica Esercizio |
| 2. Riconoscere tipi di cambiamento |
| 3. Riconoscendo azioni cambiamento del ciclo di vita |

49

50

Cambio di valutazione
1. Obiettivo di apprendimento
Dopo aver completato questo argomento, si dovrebbe essere in grado di

individuare le principali sfide di valutazione cambiamento


2. Obiettivi cambiamento di valutazione

Lo scopo del processo di valutazione cambiamento quello di fornire un mezzo coerente e


standardizzato per determinare le prestazioni - o il valore - di un progetto di cambiamento dei
servizi IT, per facilitare una decisione sull'opportunit di autorizzare il cambiamento.
Si tratta di identificare e valutare i probabili impatti di una proposta di modifica sui risultati di
business e sui servizi e infrastrutture IT esistenti e proposte.
Essa coinvolge anche l'identificazione dei rischi e problemi associati.
Gli obiettivi della valutazione cambiamento sono a
definire le aspettative delle parti interessate
Uno degli obiettivi di valutazione cambiamento quello di garantire che i soggetti
interessati abbiano aspettative realistiche di cambiamenti di servizi IT. Lo fa fornendo
informazioni su tutti i probabili effetti dei cambiamenti e dei rischi associati.
valutare gli effetti di un cambiamento proposto, e
Un obiettivo della valutazione cambiamento quello di individuare e valutare gli effetti
potenziali di un cambiamento di servizio proposto, inclusi sia i suoi effetti previsti e non
voluti, per lavoro, clienti e utenti dell'organizzazione. La misura in cui i potenziali effetti
indesiderati sono valutati dipender da ci che ragionevolmente possibile capacit di
data, risorse e vincoli organizzativi.
fornire uscite di alta qualit
Cambiare valutazione mira a fornire informazioni affidabili, accurate e complete sul valore
delle modifiche proposte e le loro rischi associati. Questa informazione informa quindi le
decisioni circa se o non autorizzare le modifiche.
Ogni cambiamento deve essere autorizzato da un opportuno un'autorit cambiamento in vari punti
nel suo ciclo di vita - e cambiare la valutazione supporta le decisioni a ciascuno di questi punti. Per
esempio, i risultati della valutazione possono guidare le decisioni sull'opportunit di autorizzare la
costruzione e la sperimentazione di un cambiamento di servizio IT e sul fatto di autorizzare la
distribuzione del servizio nuovi o modificati per l'ambiente dal vivo.
Ogni organizzazione ha bisogno di decidere quali modifiche dovrebbero essere oggetto di
valutazione cambiamento formale e che pu essere valutata pi semplicemente come parte del
processo di Change Management.
Questa decisione normalmente documentato nel modello modifica utilizzato per gestire ogni tipo
di modifica.
Per il processo di valutazione cambiamento per essere efficace, deve coinvolgere valutare una
proposta di modifica oggettivamente. Esso dovrebbe includere anche i metodi di reporting coerenti.
Il gruppo di valutazione deve fornire una relazione di valutazione, o relazione di valutazione
intermedia, alla gestione del cambiamento per facilitare il processo decisionale in ogni punto in cui
richiesta l'autorizzazione.
51

Domanda
Quali sono gli obiettivi di valutazione cambiamento?
Opzioni:
1. Assicurarsi che le parti interessate hanno aspettative realistiche delle modifiche
proposte
2. Valutare sia gli effetti voluti e non intenzionale di una proposta di modifica dei servizi
IT
3. Fornire uscite di alta qualit a sostegno delle decisioni circa autorizza modifiche di
servizio
4. Ridurre al minimo la gravit degli impatti e interruzioni causate da cambiamenti di
servizio
5. Stabilire e mantenere un accurato sistema di gestione della configurazione (CMS)

Risposta
Opzione 1: Corretto. Cambiare la valutazione mira ad assicurare che le parti interessate
abbiano aspettative realistiche di cambiamenti servizio proposto, sulla base di informazioni
oggettive sui probabili effetti dei cambiamenti.
Opzione 2: Corretto. Cambio di valutazione coinvolge valutare gli effetti previsti di un
cambiamento di servizio, cos come gli effetti indesiderati che pu avere ei rischi associati. In
questo modo, aiuta a determinare il valore di procedere nel cambio proposto.
Opzione 3: Corretto. Lo scopo della valutazione cambiamento quello di garantire che una
decisione appropriata pu essere fatta circa se o non autorizzare una proposta di modifica del
servizio. Per fare ci, deve fornire informazioni di buona qualit sotto forma di rapporti di
valutazione.
Opzione 4: non corretto. Anche se questo un obiettivo generale di Change Management,
non specifico per cambiare la valutazione. Cambio di valutazione prevede la raccolta e la
valutazione di dati oggettivi per quanto riguarda un cambiamento proposto, per consentire ai
decisori di determinare se la modifica deve essere autorizzata.
Opzione 5: non corretto. Questo un obiettivo dei processi di gestione patrimoniale e di
configurazione in fase di Service Transition. Cambio di valutazione non comporta utilizzando
un CMS. Si tratta di raccogliere e valutare le informazioni sulle modifiche proposte, per
facilitare le decisioni sul fatto di autorizzare tali modifiche o meno.
Risposte corrette):
1. Assicurarsi che i soggetti interessati abbiano aspettative realistiche di proposte
modifiche
2. Valutare sia gli effetti voluti e non voluti di un progetto IT cambiamento di servizio
3. Fornire uscite di alta qualit a sostegno delle decisioni circa autorizza modifiche di
servizio
3. Benefici e sfide
Cambiamento di valutazione , per sua natura, che riguarda il valore. valutazione effettivo
cambiamento stabilisce come e se una proposta di modifica del servizio sar di valore per
l'organizzazione, date le risorse necessarie, i probabili effetti del cambiamento, e gli eventuali rischi
potenziali o reali associati.
A sua volta, contribuisce a garantire un focus sul valore nel Change Management - con le decisioni
di autorizzare modifiche sulla base di quale valore faranno contribuiscono.
52

Inoltre, i risultati della valutazione cambiamento possono alimentare e sostenere in Continual


Service Improvement (CSI). Ad esempio, le debolezze associati ai cambiamenti di servizio proposti
possono essere affrontati e risolti, informare i futuri miglioramenti in offerte di servizi e la consegna.
Tuttavia, il processo di valutazione cambiamento soggetto a numerose sfide. Questi includono
lo sviluppo e l'utilizzo di appropriate misure di valutazione
Per le misure di valutazione per essere veramente significativa, si dovrebbe sviluppare
misure di performance standard e metodi di misurazione attraverso progetti e fornitori. Lo
sviluppo e il controllo di tali misure e metodi pu essere difficile.
Inoltre, pu essere difficile da misurare in modo che dimostrano meno variazioni nelle
previsioni durante e dopo la transizione.
comprendere le prospettive degli stakeholder
Quando valutazioni cambiano, pu essere difficile da comprendere le diverse prospettive
delle parti interessate che sono alla base efficace gestione del rischio.Questa
comprensione tuttavia, fondamentale per le attivit di valutazione cambiamento.
bilanciamento dei rischi, e
L'equilibrio tra evitando e prendendo rischi colpisce la strategia complessiva di
un'organizzazione e il successo della sua erogazione dei servizi IT. Tuttavia, la
comprensione, e di essere in grado di valutare, l'equilibrio tra la gestione del rischio e
prendere rischi una sfida.
Cambiare valutatori hanno bisogno di adottare un approccio pragmatico e misurato al
rischio con la costruzione di una conoscenza approfondita dei rischi che hanno avuto un
impatto, o possono avere un impatto, il transizione di successo dei servizi e delle uscite.
comunicazione dei rischi
Cambiare il personale di valutazione sono tenuti a comunicare l'atteggiamento
dell'organizzazione al rischio e l'approccio alla gestione del rischio in modo efficace durante
la valutazione del rischio. Sono inoltre tenuti a favorire una cultura di gestione del rischio in
cui le persone condividono le informazioni.
I fattori che possono impedire la valutazione cambiamento dall'essere efficaci comprendono

la mancanza di criteri chiari per quando deve essere utilizzato valutazione cambiamento

aspettative non realistiche del tempo richiesto per la valutazione cambiamento

cambiare il personale di valutazione con l'esperienza insufficiente o autorit organizzativa


per influenzare le autorit di cambiamento, e

progetti e fornitori di stima date di consegna in modo impreciso e causando ritardi nelle
attivit di valutazione cambiamento

Domanda
Quali sono le sfide sono associati con il processo di valutazione cambiamento?
Opzioni:
1. Identificare idonee misure di valutazione
53

2. Notando e capire come le diverse parti interessate visualizzare i rischi associati ad


una modifica proposta
3. Costruire una conoscenza approfondita dei rischi che hanno avuto un impatto
successo Service Transition
4. Incoraggiare una cultura di gestione del rischio in cui le persone condividono le
informazioni sui rischi
5. Trovare modi che cambiano contribuisce al miglioramento del servizio complessivo
6. Riducendo al minimo i comportamenti a rischio e prescrivere un approccio evitante
rischio di gestione del cambiamento

Risposta
Opzione 1: Corretto. Una sfida chiave nella valutazione cambiamento sta sviluppando misure
di performance standard e metodi di misurazione attraverso progetti e fornitori. Inoltre, la
misurazione e dimostrando meno variazioni nelle previsioni durante e dopo la transizione
difficile.
Opzione 2: Corretto. Una sfida chiave nella valutazione cambiamento la comprensione
delle diverse prospettive delle parti interessate che sono alla base efficace gestione del
rischio per le attivit di valutazione cambiamento.
Opzione 3: Corretto. Costruire una conoscenza approfondita dei rischi che hanno influenzato
o possono avere un impatto successo Service Transition e rilascia una sfida fondamentale
della valutazione cambiamento. Le squadre hanno bisogno di bilanciare la copertura dei rischi
e l'assunzione di rischi, ed essere il pi pragmatico possibile.
Opzione 4: Corretto. Incoraggiare una cultura di gestione del rischio in cui le persone
condividono le informazioni una sfida della valutazione cambiamento. Le squadre hanno
bisogno di comunicare l'atteggiamento dell'organizzazione al rischio e incoraggiare gli altri a
condividere le informazioni per ottenere un quadro il pi possibile completo delle modifiche
proposte.
Opzione 5: non corretto. Si tratta di un obiettivo generale di Change Management e non un
problema specifico di cambiare la valutazione.
Opzione 6: non corretto. Ci deve essere un equilibrio tra l'assunzione di rischi e la
prevenzione dei rischi nella valutazione del cambiamento.
Risposte corrette):
1. Identificare idonee misure di valutazione
2. Notando e capire come le diverse parti interessate vedono rischi associati a una
proposta di modifica
3. Costruire una conoscenza approfondita dei rischi che hanno avuto un impatto
successo Service Transition
4. Incoraggiare una cultura di gestione del rischio in cui le persone condividono le
informazioni sui rischi
4. Riepilogo
Il processo di valutazione cambiamento mira a fornire un metodo standardizzato coerente per
valutare il valore di un cambiamento di servizio proposto e rischi associati. Si tratta di raccogliere e
valutare i dati oggettivi di una modifica proposta. Cambiare valutazione aiuta a garantire che le
decisioni sul fatto di autorizzare le modifiche proposte si basano sul valore reale di tali modifiche
alla organizzazione, i suoi utenti, ed i suoi clienti. Sfide connesse con questo processo includono
misure di valutazione per la standardizzazione e metodi, bilanciamento dei rischi, la comprensione
54

prospettive delle parti interessate, e la comunicazione dei rischi in modo efficace all'interno di una
organizzazione.
5. Sommario
| Inizio pagina |
| Obiettivo di apprendimento |
| 1. Cambiare obiettivi della valutazione |
| 2. Vantaggi e sfide |
| Sommario |

55

Knowledge Management nel Service Transition


1. Obiettivo di apprendimento
Dopo aver completato questo argomento, si dovrebbe essere in grado di

identificare la struttura Knowledge Management

2. Ambito di applicazione e finalit


Nel ITIL Service Lifecycle, il processo di Knowledge Management si verifica come parte della
fase di Service Transition.

Grafico
Il ITIL Service Lifecycle costituito dalle fasi Service Strategy, Service Design, Service
Transition, Operation servizio, e Continual Service Improvement.
Il processo di Knowledge Management coinvolge la condivisione di punti di vista, i dati, idee,
esperienze e informazioni, e garantire che questi sono disponibili nel posto giusto e al momento
giusto. Ci consente decisioni informate, e migliora l'efficienza, riducendo la necessit di riscoprire
la conoscenza.
Knowledge Management ha diversi obiettivi:

per migliorare la gestione del processo decisionale, garantendo affidabili e sicure


conoscenze, informazioni e dati disponibile in tutto il ciclo di vita di servizio

per ridurre la necessit di ritrovare conoscenze, migliorando cos l'efficienza, la qualit del
servizio, e soddisfazione del cliente, e riducendo il costo del servizio

al fine di garantire che i dipendenti hanno una comprensione chiara e comune del valore
che servizi IT di fornire a clienti e utenti, e il modo in cui si rende conto che il valore

per mantenere un Sistema di Knowledge Management Service (SKMS) che fornisce


l'accesso controllato alla conoscenza del caso, informazioni e dati per i destinatari, e

per raccogliere, analizzare, archiviare, condividere, utilizzare e mantenere la conoscenza,


le informazioni ei dati in tutta l'organizzazione fornitore di servizi
Un SKMS un insieme di strumenti e banche dati utilizzati per la gestione della conoscenza, le
informazioni ed i dati, con l'obiettivo di migliorare l'efficienza complessiva e l'efficacia di tutte le fasi
del ciclo di vita di servizio.
Un SKMS permette alle persone di beneficiare delle conoscenze e l'esperienza degli altri, sostiene
un processo decisionale informato, e migliora la gestione dei servizi IT.
La conoscenza che particolarmente importante durante la fase di Service Transition include le
identit dei soggetti interessati dalle nuove o modificate servizi IT, livelli accettabili di rischio,
aspettative di performance del servizio, e le risorse disponibili e tempi.
La capacit di fornire un servizio di qualit o un processo si basa fortemente sulla capacit delle
persone coinvolte per rispondere in modo appropriato in circostanze diverse. A sua volta, questa
capacit dipende dalla comprensione della gente di ogni situazione, e del relativo servizio o
processo in quel contesto.
La qualit e la pertinenza delle conoscenze delle parti interessate dipende dalla accessibilit, la
qualit, e la costante pertinenza delle informazioni che sono rese disponibili attraverso una SKMS.
56

La gestione della conoscenza rilevante per tutte le fasi del ciclo di vita e cos viene fatto
riferimento nel corso ITIL. In relazione al Service Transition, Knowledge Management comprende
la gestione dei dati, informazioni e conoscenze su nuovi o modificati servizi IT. Tuttavia, non si
concentra su attivit come l'acquisizione, il mantenimento, o utilizzando i dati di configurazione.

Domanda
Quali sono gli obiettivi del processo di Knowledge Management?
Opzioni:
1. Migliorare la gestione del processo decisionale
2. Garantire che i dipendenti hanno una chiara e condivisa comprensione del valore dei
loro servizi IT forniscono al cliente
3. Mantenere un adeguato SKMS
4. Raccogliere, analizzare, archiviare, condividere, utilizzare e mantenere le
informazioni in tutta l'organizzazione
5. Assicurarsi che le informazioni di configurazione sia correttamente raccolto
6. Assicurarsi che le informazioni di configurazione sia correttamente mantenuto ed
utilizzato

Risposta
Opzione 1: Corretto. Il processo di Knowledge Management si propone di migliorare la
gestione del processo decisionale, garantendo una conoscenza affidabile e sicuro, le
informazioni, i dati ed disponibile in tutto il Service Lifecycle.
Opzione 2: Corretto. Il processo di Knowledge Management mira a garantire che i dipendenti
hanno una chiara, comprensione condivisa del valore che i servizi offrono ai clienti, e di come
questo valore viene realizzato dalla fruizione dei servizi.
Opzione 3: Corretto. Il processo di Knowledge Management mira a mantenere una SKMS
che fornisce l'accesso alla conoscenza del caso, informazioni e dati controllati per il pubblico
destinatario.
Opzione 4: Corretto. Il processo di Knowledge Management si propone di raccogliere,
analizzare, archiviare, condividere, utilizzare e mantenere la conoscenza, le informazioni e
dati in tutta un'organizzazione di fornitore di servizi.
Opzione 5: non corretto. Knowledge Management non si concentra su processi come la
raccolta o la cattura dei dati di configurazione. Essa si concentra sulla necessit di garantire
che la conoscenza memorizzato e condiviso in modo appropriato.
Opzione 6: non corretto. Knowledge Management non riguarda l'acquisizione, il
mantenimento, o utilizzando i dati di configurazione. Si riferisce alla gestione della
conoscenza che un fornitore di servizi si accumula.
Risposte corrette):
1. Migliorare la gestione decisionale
2. Garantire che i dipendenti hanno una chiara e condivisa comprensione del valore dei
loro servizi IT forniscono ai clienti
3. Mantenere un adeguato SKMS
57

4. Raccogliere, analizzare, archiviare, condividere, utilizzare e mantenere le informazioni


in tutta l'organizzazione
3. Struttura DIKW
Data-to-Information-to-Conoscenza-to-Saggezza (DIKW) una struttura che pu aiutare a capire e
implementare efficaci processi di Knowledge Management.

Grafico
La struttura DIKW raffigurato come un grafico con "intesa" come l'asse X e "Context" come
l'asse Y. Dati impostato sullo zero, dove gli assi X e Y. incontrano. Il punto successivo
"Informazione", che aumenta in modo esponenziale ed associata a domande come
"Chi?" "Che cosa?" "Quando?" e dove?" La prossima "conoscenza", che associato con la
domanda "Come?" Infine, il punto di Saggezza associato con la domanda "Perch?"
La struttura DIKW comprende quattro elementi.
dati
I dati si riferiscono a fatti discreti. La maggior parte delle organizzazioni a catturare grandi
quantit di dati nei database altamente strutturati. Questi possono includere Management
Service, servizio di asset e di gestione della configurazione dei database. Le attivit di
Knowledge Management chiave associati con i dati sono dati identificativi rilevanti,
catturando i dati con precisione, analizzare e sintetizzare i dati, mantenendo l'integrit dei
dati e l'archiviazione dei dati per garantire un equilibrio ottimale tra la sua disponibilit e
l'utilizzo delle risorse.
Informazioni
Le informazioni sono dati a cui stato aggiunto contesto per migliorare la
comprensione. Le informazioni sono in genere memorizzati in supporti semi-strutturati
come documenti o e-mail. La chiave di attivit di Knowledge Management associati con le
informazioni garantire che le informazioni siano facili da catturare, interrogare, trovare,
riutilizzo, e imparare da. Questo aiuta a garantire che gli errori non si ripetano e che il
lavoro non duplicato.
Conoscenza
La conoscenza dinamica e al contesto base, e serve a facilitare il processo decisionale. E
'composto da i taciti esperienze, idee, intuizioni, i valori e giudizi di individui. La gente
acquisire conoscenze da loro esperienze dei loro coetanei proprio e, e attraverso l'analisi
dei dati e delle informazioni. Attraverso la sintesi di questi elementi, si crea nuova
conoscenza.
In Service Transition, questa conoscenza non si basa unicamente sulla transizione in
corso. Invece, anche basata su esperienze di transizioni precedenti, e la consapevolezza
delle recenti e attesi cambiamenti - che hanno registrato i dipendenti accumulano
inconsciamente nel corso del tempo.
Saggezza
La saggezza si riferisce all'applicazione di conoscenze e di forte senso comune in
determinati contesti per creare valore. E 'illustrato nelle decisioni ben informate.
Come esempio, il processo pu iniziare con DIKW raccolta dati quali la data e l'ora in cui stato
registrato un incidente.
58

Grafico
Ad esempio, un incidente stato registrato il 27 marzo alle 16:40.
Questi dati possono essere trasformati in informazioni combinando l'ora di inizio, ora di fine, e la
priorit di molti incidenti di trovare il tempo medio necessario per chiudere incidenti della stessa
priorit.

Grafico
Continuando con l'esempio, il tempo medio di chiudere 2:30 minuti.
Utilizzando queste informazioni medio periodo, possibile sviluppare conoscenze. Ad esempio,
possibile analizzare le informazioni e scoprire che il tempo medio di chiudere gli incidenti con la
data priorit aumentata di circa il 10% dal stata rilasciata una nuova versione di un servizio.
Da questo, saggezza pu essere raggiunto. Ad esempio, saggezza pu comportare riconoscendo
che l'aumento del tempo necessario per chiudere gli incidenti dovuta alla documentazione
scarsa qualit per la nuova versione del servizio. quindi possibile decidere il modo migliore per
migliorare la documentazione.

Domanda
Abbinare ogni esempio di conoscenza con l'elemento DIKW cui appartiene.
Opzioni:
A. Data e ora ad alta velocit, l'utilizzo dei servizi Internet
B. Un grafico a torta a confronto Internet log-ons il luned mattina con settimanali logons
C. numero medio documentata di connessioni realizzato su un Lunedi mattina
D. Un riconoscimento che gli utenti richiedono dati provenienti da altri centri per
orientare il lavoro della settimana, si traduce in pi connessioni il luned
obiettivi:
1. dati
2. Informazioni
3. Conoscenza
4. Saggezza

Risposta
La data e l'ora di connessioni Internet ad alta velocit un fatto discreta e cos definita
come dati, che la prima parte della struttura DIKW.
Il numero di connessioni che si hanno ogni Lunedi il vostro dati grezzi. Determinando il
numero medio di connessioni ogni Lunedi si sta fornendo il contesto per questi dati. Questo
rappresenta informazioni.
Confrontando gli accessi settimanali con luned accessi vi far consapevoli della quantit
degli accessi settimanali verificarsi il Lunedi. Ad esempio, il grafico a torta pu mostrare che il
25% delle connessioni per una settimana si verificano il Lunedi. Questo rappresenta la
conoscenza e pu aiutare a prendere decisioni circa il processo.
Il motivo dietro il maggiore impiego di connessioni Internet rappresenta la saggezza, perch
incorpora una comprensione del contesto e un modello di erogazione dei servizi, cos come
forte giudizio del senso comune.
Risposte corrette):
59

Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione C
Obiettivo 3 = Opzione B
Obiettivo 4 = Opzione D
4. Riepilogo
Nella fase di Service Transition, lo scopo del processo di Knowledge Management quello di
migliorare il processo decisionale, aumentare l'efficienza e garantire che la conoscenza raccolto,
conservato e condiviso tramite un SKMS ben gestita. La struttura DIKW definisce e distingue tra i
dati, le informazioni, la conoscenza e la saggezza, sulla base dei livelli associati di contesto e di
comprensione.
5. Sommario
| Inizio pagina |
| Obiettivo di apprendimento |
| 1. Ambito di applicazione e finalit |
| 2. Struttura DIKW |
| Sommario |

60

Comprendere processi di transizione di servizio


1.

Obiettivi formativi

Dopo aver completato questo argomento, si dovrebbe essere in grado di

descrivere esempi di politiche di transizione di servizio

identificare le attivit delle fasi del processo di rilascio e distribuzione di gestione

identificare la struttura Knowledge Management

descrivono gli scopi della transizione del risparmio, servizio di supporto, e processi di test

2.

Panoramica esercizio

In questo esercizio, siete tenuti a riconoscere le politiche ei processi di transizione di servizio.


Ci comporta le seguenti operazioni:

corrispondenti principi di esempi di politiche di transizione di servizio

individuare le attivit in ogni fase del processo di rilascio e distribuzione di gestione

riconoscendo la struttura Knowledge Management, e

individuare le attivit nel passaggio degli asset, servizio di supporto, e la sperimentazione


dei processi

3.

Riconoscendo politiche di transizione di servizio

ITIL delinea 14 esempi di politiche di transizione di servizio che le organizzazioni possono


utilizzare per l'elaborazione delle politiche personalizzate per la gestione del processo di Service
Transition.

Domanda
principi match per le politiche di servizio di transizione a cui si applicano.
Opzioni:
A. Comunicare le linee guida formalmente approvati e standardizzate per Service
Transition
B. Creare un unico punto focale da cui sono gestite e supervisionate modifiche
C. Usa l'industria ha accettato le migliori pratiche
obiettivi:
1. Definire e attuare una politica formale per Service Transition
2. Attuare tutte le modifiche ai servizi attraverso Service Transition
3. Adottare un quadro e norme comuni

Risposta
Una politica formale per Servizio di transizione dovrebbe essere definito, documentato, e
formalmente approvato dal team di gestione. Dovrebbe anche essere comunicati a tutte le
parti interessate.
Per implementare tutte le modifiche ai servizi attraverso Service Transition, modifiche di
servizio devono essere gestiti da un unico punto focale e la loro portata devono essere
documentati.
61

Utilizzando industria accettato le migliori pratiche, a migliorare l'integrazione attraverso la


catena di approvvigionamento e promuovere l'adozione di un quadro e di standard comuni.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C

Domanda
principi match per altri esempi di politiche di transizione di servizio.
Opzioni:
A. modelli di transizione servizio di progettazione che consentono una facile
personalizzazione in base alle circostanze specifiche
B. Confrontare le prestazioni effettive di un servizio di transizione con il rendimento
previsto
C. Impostare le aspettative sulle prestazioni e di ottenere l'impegno da parte dei fornitori
chiave
obiettivi:
1. Massimizzare il riutilizzo dei processi e dei sistemi istituiti
2. Allineare piani di transizione di servizio con le esigenze di business
3. Stabilire e mantenere relazioni con gli stakeholder

Risposta
Per massimizzare il riutilizzo di processi e sistemi consolidati, necessario progettare modelli
di servizio di transizione che consentono una facile personalizzazione in base alle circostanze
specifiche.
Per allineare piani di transizione di servizio con le esigenze aziendali, possibile confrontare
le prestazioni effettive dei servizi dopo una transizione con la performance prevista definito in
Service Design con l'obiettivo di ridurre le variazioni di capacit di servizio e le performance.
Per stabilire e mantenere relazioni con gli stakeholder, necessario comunicare
regolarmente e definire le aspettative sui piani di performance e azioni e altri cambiamenti
potenziali.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C

Domanda
principi match per ulteriori esempi di politiche di transizione di servizio.
Opzioni:
A. ruoli assegnati devono essere conservati all'interno del sistema di gestione della
configurazione
B. Creare una banca dati consolidata di informazioni da condividere

62

C. Utilizzare meccanismi di distribuzione per garantire l'integrit dei componenti durante


l'installazione
D. Gestire e ridurre i problemi e gli errori durante la Service Transition per ridurre i costi
e di ri-lavoro
obiettivi:
1. Stabilire controlli e discipline efficaci
2. Fornire sistemi per il trasferimento di conoscenza e supporto alle decisioni
3. pacchetto di rilascio Piano
4. Proattivo migliorare la qualit durante la Service Transition

Risposta
Per stabilire controlli e discipline efficaci, necessario specificare ruoli e responsabilit. I ruoli
assegnati devono essere conservate all'interno del Sistema di Gestione servizio della
conoscenza e del Sistema di Gestione della configurazione.
Per il trasferimento di conoscenze e di supporto alle decisioni utile utilizzare fonte definitiva
di conoscenza e di condividere queste informazioni attraverso il Service Lifecycle e con le
parti interessate. E 'anche utile per fornire informazioni consolidate per permettere il
cambiamento e per accelerare decisioni efficaci.
Quando si pianifica un pacchetto di rilascio, possibile utilizzare meccanismi di rilascio e di
distribuzione per assicurare l'integrit dei componenti durante l'installazione, la
manipolazione, il confezionamento e la consegna.
Per migliorare la qualit durante la Service Transition, utile per gestire in modo proattivo e
ridurre gli incidenti e gli errori durante la Service Transition.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D

Domanda
principi match per i restanti esempi di politiche di transizione di servizio.
Opzioni:
A. Incoraggiare le parti interessate ad aspettarsi cambiamenti e capire che queste sono
necessarie e utili
B. Stabilire la capacit condiviso e dedicato in tutte le attivit di transizione
C. Stabilire rilevamento degli errori adatto all'inizio di un progetto Service Transition per
ridurre i costi di rettifica
D. Assicurarsi che le modifiche possono essere consegnati entro le specifiche di test e
ambienti riflettono l'ambiente vivo
obiettivi:
1. Anticipare e gestire correzioni di rotta
2. gestire in modo proattivo le risorse tra servizio Transizioni
3. Assicurare il coinvolgimento nelle prime fasi del ciclo di vita di servizio
63

4. Fornire la garanzia della qualit del nuovo o modificato servizi IT

Risposta
Per anticipare e gestire correzioni di rotta, necessario incoraggiare le parti interessate ad
aspettarsi cambiamenti e individuare, se necessario. I dipendenti devono essere addestrati a
gestire correzioni di rotta.
Per gestire in modo proattivo le risorse, necessario un team in grado di attuare il
cambiamento attraverso tutte le fasi del ciclo di vita. Si dovrebbe stabilire condiviso, dedicato
e risorse specialistiche attraverso attivit di Service Transition per eliminare i ritardi e
ottimizzare l'utilizzo delle risorse.
L'istituzione di controlli e discipline idonee nelle prime fasi garantisce la diagnosi precoce o gli
errori e riduce il costo di fissazione di tali.
Service Transition responsabile di assicurare che i cambiamenti possono essere consegnati
in base alle specifiche attraverso l'uso di garanzia della qualit, valutazioni e test.
Risposte corrette):
Obiettivo 1 = Opzione A
Obiettivo 2 = Opzione B
Obiettivo 3 = Opzione C
Obiettivo 4 = Opzione D

4.

La gestione e la distribuzione di rilascio

Il processo di rilascio e il Deployment Management comprende quattro fasi - stampa e


pianificazione della distribuzione, build di rilascio e di test, implementazione e revisione e vicino.

Grafico
La grafica di uscita e la distribuzione di gestione si compone di pianificazione delle release,
build di rilascio e di prova, la distribuzione di rilascio, e la revisione e vicino.

Domanda
Quali attivit deve essere eseguita durante la fase di rilascio e di pianificazione della
distribuzione?
Opzioni:
1. Impostare una pianificazione per la distribuzione e il rilascio
2. Impostare passaggio o fallire criteri per il servizio ha cambiato o nuova
3. Definire una linea di base di configurazione per l'ambiente di compilazione
4. Assicurare che le azioni necessarie, correzioni necessarie e le modifiche sono
completi
5. obiettivi di performance e risultati recensione

Risposta
Opzione 1: Corretto. Il piano per il rilascio dovrebbe contenere i dati circa la portata di
rilascio, i rischi, la squadra, il programma, la consegna, le risorse e le principali parti
interessate.
Opzione 2: Corretto. Quando si pianifica il rilascio, necessario identificare il passaggio o
non riescono criteri per il servizio, in modo che possa essere adeguatamente testati, valutati,
e rivisto.
64

Opzione 3: Corretto. Durante questa fase, si stabilisce la logistica e gli orari, definire una
linea di base di configurazione per l'ambiente costruire, testare le procedure di compilazione
e le relative, e assegnare le risorse, i ruoli e le responsabilit di svolgere attivit chiave.
Opzione 4: non corretto. Queste attivit si verificano in una fase successiva del processo di
rilascio e Deployment Management.
Opzione 5: non corretto. La revisione degli obiettivi e dei risultati avviene in una fase
successiva del processo di rilascio e Deployment Management.
Risposte corrette):
1. Impostare una pianificazione per la distribuzione e rilasciare
2. Impostare passaggio o fallire criteri per il servizio ha cambiato o nuova
3. Definire una linea di base di configurazione per l'ambiente di compilazione

Domanda
Quali attivit dovrebbe avvenire durante la build di rilascio e la fase di test?
Opzioni:
1. Gestire le questioni ambientali - ad esempio mediante l'attuazione di sistemi di
raffreddamento
2. Documentare la gestione dei servizi di base
3. Ottenere il sostegno della squadra per la funzione e di processo le variazioni
generate dal rilascio
4. Fornire pianificazione generale per il servizio transizioni e coordinare le risorse
necessarie
5. la qualit della revisione di Service Design contro le esigenze dei clienti

Risposta
Opzione 1: Corretto. Attivit nei build di rilascio e la fase di test comprendono i diritti di
accesso di controllo ai componenti fisici e tecnologici e la gestione di problematiche
ambientali - ad esempio, per il raffreddamento di attuazione, misure antincendio, e le misure
di sicurezza.
Opzione 2: Corretto. La fase di build di rilascio e di test comprende le attivit di gestione e
documentazione costruire e testare, come ad esempio quelli connessi con il controllo di
versione, la gestione della linea di base, la generazione di rapporti di prova, e il controllo delle
uscite.
Opzione 3: non corretto. Durante questa fase il rilascio del servizio promosso o consegnata
alla fase successiva o squadra. Non comporta guadagnando il supporto per la funzione e di
processo le variazioni generate dal rilascio.
Opzione 4: non corretto. Questa fase inizia con l'autorizzazione Change Management per
costruire il rilascio e si conclude con l'autorizzazione Change Management per il pacchetto di
rilascio baselined essere controllato nella libreria multimediale definitivo, o DML, dal Servizio
Asset and Configuration Management, o SACM. Non comporta la pianificazione Service
Transition generale o il coordinamento delle risorse necessarie.
Opzione 5: non corretto. Questa fase si concentra in particolare sulla costruzione e la
sperimentazione di un rilascio. Non comporta la valutazione della qualit di Service Design.
Risposte corrette):
65

1. Gestire le questioni ambientali - ad esempio mediante l'attuazione di sistemi di


raffreddamento
2. Documentare la gestione dei servizi di base

Domanda
Quali attivit deve essere eseguita durante la fase di spiegamento?
Opzioni:
1. Assegnare un tecnico per il test del software della nuova applicazione rapporto
generazione
2. Preparare operatori ad attuare il passaggio alle funzioni di Service Operation
3. Distribuire il pacchetto di rilascio di uno o pi ambienti di destinazione
4. Set di base per il servizio durante i test
5. Documento di controllo della versione del Build Service

Risposta
Opzione 1: Corretto. Assegnazione di individui di attivit specifiche un'attivit in fase di
distribuzione. Un esempio l'assegnazione di un tecnico specifico per completare il test
iniziale del software.
Opzione 2: Corretto. Questa fase si conclude con la consegna di un rilascio per le funzioni
operative di assistenza e supporto prime fasi di vita. Quindi include preparare i soggetti
interessati per la consegna delle funzioni di Service Operation.
Opzione 3: Corretto. Questa fase inizia con l'autorizzazione Change Management per
distribuire il pacchetto di rilascio di uno o pi ambienti di destinazione.
Opzione 4: non corretto. Linee di base impostazione dovrebbe essere eseguiti durante la
build di rilascio e la fase di test.
Opzione 5: non corretto. Il controllo delle versioni dei documenti deve avvenire durante la
build di rilascio e la fase di test.
Risposte corrette):
1. Assegnare un tecnico per il test del software della nuova applicazione rapporto
generazione
2. Preparare operatori ad attuare il passaggio alle funzioni di Service Operation
3. Distribuire il pacchetto di rilascio di uno o pi ambienti di destinazione

Domanda
Quali attivit appartengono nella revisione e vicino fase?
Opzioni:
1. Cattura esperienze e feedback sui clienti, utenti, e la soddisfazione del fornitore di
servizi
2. Verificare che le parti interessate sono consapevoli degli errori noti e accettare le
soluzioni alternative
3. obiettivi di performance Review, successi, e il registro dei rischi
4. Assicurarsi dirigenza accetta i costi di implementazione associati
5. Assegnare le risorse, ruoli e le responsabilit per le attivit di transizione chiave di
servizio

Risposta
66

Opzione 1: Corretto. Nel rivedere una distribuzione durante questa fase, si dovrebbe
acquisire esperienze e feedback sui clienti, utenti, e la soddisfazione del fornitore di servizi.
Opzione 2: Corretto. Durante questa fase, necessario verificare che eventuali problemi,
errori noti e soluzioni alternative sono documentati e che queste sono accettate da soggetti
interessati, quali clienti o fornitori.
Opzione 3: Corretto. Prima di chiudere la fase, necessario assicurarsi che non vi siano
questioni ancora capacit, risorse, capacit o prestazioni che devono essere affrontate. Per
fare questo, utile rivedere gli obiettivi di prestazione, i risultati, e registro dei rischi.
Opzione 4: non corretto. Garantire dirigenza accetta i costi di implementazione parte della
fase di distribuzione.
Opzione 5: non corretto. Risorse Assegnazione, i ruoli e le responsabilit associato con la
fase di progettazione di rilascio e la distribuzione.
Risposte corrette):
1. esperienze catturare e feedback su clienti, utenti, e fornitore di servizi di
soddisfazione
2. Verificare che le parti interessate sono consapevoli degli errori noti e accettare le
soluzioni alternative
3. Obiettivi di performance Review, successi, e il registro dei rischi

5.

Riconoscendo la struttura DIKW

Data-to-Information-to-Conoscenza-to-Saggezza (DIKW) una struttura che consente di


identificare i processi di Knowledge Management.

Domanda
esempi sequenza delle informazioni in base all'ordine in cui gli elementi appaiono nella
struttura DIKW.
Opzioni:
A. Un errore rilevato durante il test documentata e numerata
B. Un file documenta il numero totale di errori rilevati utilizzando specifiche categorie di
errore
C. Il team di design osserva che la maggior parte degli errori di codifica sono associati
con la selezione e l'utilizzo di formule
D. Programmatori sono date una panoramica di come funziona un programma in un
ambiente reale, con conseguente minor numero di errori

Risposta
Risposte corrette):
Un errore rilevato durante il test documentata e numerata classificato
Questo un fatto discreta quindi un esempio di dati. Come tale il primo elemento della
struttura DIKW Knowledge Management.
Un file di documenti il numero totale di errori rilevati utilizzando specifiche categorie di errore
classificato

67

Questo un esempio di informazioni - dati di base, o un contesto per esso, stato


sviluppato in forma di specifiche categorie di errore. Quindi questo il secondo elemento
della struttura DIKW Knowledge Management.
Il team di design osserva che la maggior parte degli errori di codifica sono associati con la
selezione e l'utilizzo di formule classificato
Questo un esempio di conoscenza perch rappresenta comprensione della transizione in
corso, l'esperienza di transizioni precedenti, e la consapevolezza dei cambiamenti
previsti. Quindi questo il terzo elemento nella struttura DIKW Knowledge Management.
Programmatori sono date una panoramica di come funziona un programma in un ambiente reale,
con conseguente minor numero di errori classificato
Questo un esempio di saggezza in quanto fornisce la pi contesto e la comprensione di
un modello di erogazione del servizio e trova forte giudizio di buon senso.Quindi questo
l'elemento finale nella struttura DIKW Knowledge Management.

6.

Identificare attivit

Come parte del Service Transition Management, necessario affrontare Servizio Asset and
Configuration Management (SACM), la pianificazione di transizione e di supporto, e la convalida
del servizio e collaudo.

Domanda
Quali attivit sono associati con SACM?
Opzioni:
1. Assicurarsi che i server gestiti nella transizione sono identificati, baselined, e
mantenuti
2. Testare un server virtuale per ottenere dati sulle prestazioni di base per un nuovo
servizio inhouse
3. Mantenere un accurato e completo sistema di gestione della configurazione
4. Registrare il rapporto tra il virtuale e il server fisico, che sono entrambi utilizzati per
supportare consegna o il nuovo servizio
5. Controllare che errori noti e soluzioni alternative sono accettate da utenti e clienti
6. dipendenti treno in modo per documentare i cambiamenti inattesi nelle prestazioni di
servizio

Risposta
Opzione 1: Corretto. necessario identificare tutti gli elementi di configurazione (CI),
prestazioni di base del documento, mantenere gli IC, e assicurare che le modifiche a loro
sono controllati.
Opzione 2: Corretto. necessario determinare la linea di base per Elementi di
configurazione utilizzati in Service Transition.
Opzione 3: Corretto. Un obiettivo di questa fase quello di garantire l'integrit degli elementi
di configurazione per stabilire e mantenere un CMS accurata e completa.
Opzione 4: Corretto. L'attivit in questa fase fornisce un modello di configurazione dei servizi
e delle attivit di servizio registrando le relazioni tra elementi di configurazione.

68

Opzione 5: non corretto. Si tratta di un'attivit associata con la recensione e vicino fasi di
rilascio e Deployment Management.
Opzione 6: non corretto. Questo non un aspetto di Asset e Configuration Management, ma
un principio della politica di anticipare e gestire correzioni di rotta.
Risposte corrette):
1. Assicurarsi che i server gestiti nella transizione sono identificati, baselined, e
mantenuti
2. Testare un server virtuale per ottenere dati sulle prestazioni di base per un nuovo
servizio inhouse
3. Mantenere una accurata e completa gestione della configurazione del sistema
4. Registrare il rapporto tra il virtuale e il server fisico, che sono entrambi utilizzati per
supportare consegna o il nuovo servizio

Domanda
Quali sono le opzioni descrivono il processo di pianificazione di transizione e di sostegno?
Opzioni:
1. Esso fornisce pianificazione generale per il servizio transizioni e coordina le risorse di
cui hanno bisogno
2. Ha lo scopo di modificare o creare nuovi sistemi di gestione delle informazioni, gli
strumenti e la tecnologia
3. Si lavora per assicurare che tutte le parti adottano processi standard e sistemi di
supporto
4. Controllare la pianificazione del bilancio per assicurare le risorse necessarie per
soddisfare i requisiti futuri sono sufficienti
5. Creare piani dettagliati per lo sviluppo di singole modifiche
6. modifiche di controllo di elementi di configurazione come i server virtuali

Risposta
Opzione 1: Corretto. Il campo di applicazione del processo di pianificazione di transizione e il
supporto include fornire pianificazione generale per il servizio transizioni e coordinare le
risorse di cui hanno bisogno.
Opzione 2: Corretto. Per pianificare un supporto una transizione, potrebbe essere necessario
stabilire nuovi sistemi informativi di gestione, strumenti, tecnologie e gestione delle
architetture. Potrebbe anche essere necessario per stabilire nuovi processi di gestione dei
servizi, metodi di misurazione e metriche per soddisfare i requisiti stabiliti durante la fase di
Service Design del ciclo di vita.
Opzione 3: Corretto. Per migliorare l'efficacia e l'efficienza delle attivit di pianificazione e di
coordinamento integrato, necessario assicurarsi che tutte le parti adottino il quadro comune
di processi riutilizzabili standard e sistemi di supporto.
Opzione 4: Corretto. Parte dei requisiti di pianificazione delle risorse per sostenere il servizio
di transizione quello di garantire che il bilancio per la transizione ben programmato e che
non ci sono risorse sufficienti necessarie per soddisfare i requisiti futuri per Service Transition.
Opzione 5: non corretto. L'ambito di pianificazione e gestione di transizione supporto non
include la piena responsabilit della pianificazione dettagliata del costruire, testare, e la
distribuzione di singole modifiche o release.
69

Opzione 6: non corretto. Questa attivit rientra nell'ambito di applicazione di Asset e


Configuration Management.
Risposte corrette):
1. Esso fornisce pianificazione generale per il servizio transizioni e coordina le risorse di
cui hanno bisogno
2. Ha lo scopo di modificare o creare nuovi sistemi di gestione delle informazioni,
strumenti e la tecnologia
3. Si lavora per assicurare che tutte le parti adottano processi standard e sistemi di
supporto
4. Controllare la pianificazione del bilancio per assicurare le risorse necessarie per
soddisfare i requisiti futuri sono sufficienti

Domanda
Quali sono esempi di attivit nel processo di validazione e testing del servizio?
Opzioni:
1. Valutare la capacit di qualit e il servizio fornito da un rilascio
2. Determinare se il servizio offrir la garanzia concordata
3. Verificare che il cliente requisiti sono definite correttamente
4. Fare riferimento al Service Level Agreement (SLA) per impostare i parametri per il
test
5. capacit di progettazione intorno condiviso e risorse specificamente designati
6. diritti di controllare l'accesso ai componenti fisici e tecnologici

Risposta
Opzione 1: Corretto. Validation Service e di prova di fornire la garanzia della qualit per un
rilascio, i suoi componenti di servizio costituenti, il servizio risultante, e la capacit di servizio
consegnato da un comunicato.
Opzione 2: Corretto. L'ambito di convalida del servizio e di prova di garanzia che un servizio
adatto per l'uso - esso pu offrire la garanzia concordata. Essa stabilisce che la
progettazione di servizio e il rilascio consegner un nuovo o modificato il servizio o l'offerta di
servizio che adatto allo scopo IT e in forma per l'uso.
Opzione 3: Corretto. Validation Service e test richiede la conferma che i requisiti dei clienti
per il servizio nuovo o modificato siano definite correttamente.
Opzione 4: Corretto. Questa fase deve garantire che vi sia la pianificazione e la realizzazione
di processi di validazione e test strutturato. Per fare questo, la SLA guida di prova e mira a
garantire il fornitore di servizi si assume la responsabilit per la consegna, il funzionamento e
la salvaguardia del patrimonio del cliente o di servizio.
Opzione 5: non corretto. Questo fa parte della gestione delle risorse e non direttamente
nell'ambito di applicazione di validazione e testing.
Opzione 6: non corretto. Durante la build di rilascio e la fase di test, necessario gestire gli
ambienti di costruire e testare controllando i diritti di accesso e la gestione delle
problematiche ambientali.
Risposte corrette):
1. Valutare la capacit di qualit e il servizio fornito da un rilascio
2. Determinare se il servizio offrir la garanzia concordato
70

3. Verificare che il cliente requisiti sono definite correttamente


4. Fare riferimento al Service Level Agreement (SLA) per impostare i parametri per il test
7. Riepilogo
politiche di transizione Esempio di servizio sono stati abbinati a principi corrispondenti, sono state
individuate le attivit in ogni fase del processo di rilascio e distribuzione di gestione, e le
componenti della struttura DIKW sono stati riconosciuti. Attivit nei SACM, pianificazione della
transizione e di sostegno, e la validazione di servizi e processi di test sono stati identificati.
8. Sommario
| Inizio pagina |
| Obiettivi di apprendimento |
| 1. Panoramica Esercizio |
| 2. Riconoscendo le politiche di transizione di servizio |
| 3. La gestione e la distribuzione di rilascio |
| 4. Riconoscendo la struttura DIKW |
| 5. Identificare attivit |

71