ITIL Seconda Parte

Sommario
Il Campo di applicazione e Politiche di Service Transition.............................................17

1.
Obiettivi formativi............................................................................................... 17
2.
Ambito di Service Transition................................................................................17

Grafico..................................................................................................................... 18
Domanda................................................................................................................. 19
Risposta................................................................................................................... 19
3.
Le politiche di transizione di servizio..................................................................20

1.
Definire e attuare la politica formale...................................................................20
2.
Implementare modifiche ai servizi......................................................................21
3.
Adottare un quadro e norme comuni..................................................................21
4.
Massimizzare il riutilizzo dei processi e dei sistemi istituiti..................................21
Domanda................................................................................................................. 21
Risposta................................................................................................................... 22
Domanda................................................................................................................. 24
Risposta................................................................................................................... 25
Domanda................................................................................................................. 26
Risposta................................................................................................................... 27
15.
Riepilogo.......................................................................................................... 27
16.
Sommario........................................................................................................ 27
Stampa e distribuzione gestione a Service Transition..................................................29

1.
Obiettivo di apprendimento................................................................................29
2.
Ambito di applicazione e finalit.........................................................................29

Grafico..................................................................................................................... 29
Grafico..................................................................................................................... 30
Domanda................................................................................................................. 30
Risposta................................................................................................................... 30
3.
Le quattro fasi..................................................................................................... 31
Grafico..................................................................................................................... 31
Drill Down Home...................................................................................................... 31
Pagina 1 di 3: uscita e la distribuzione di pianificazione.............................................31
1

Grafico..................................................................................................................... 32
Pagina 1 di 3: costruzione di uscita e il test...............................................................32
Pagina 1 di 2: Distribuzione...................................................................................... 33
Pagina 2 di 2: Distribuzione...................................................................................... 33
Pagina 1 di 2: Review e vicino.................................................................................. 33
Grafico..................................................................................................................... 33
Pagina 2 di 2: Review e vicino.................................................................................. 33
Domanda................................................................................................................. 33
Risposta................................................................................................................... 34
4.
Riepilogo............................................................................................................. 34
5.
Sommario............................................................................................................ 35
Knowledge Management nel Service Transition...........................................................36

1.
2.
Ambito di applicazione e finalit............................................................................36

Grafico..................................................................................................................... 36
Domanda................................................................................................................. 37
Risposta................................................................................................................... 37
3.
Struttura DIKW................................................................................................... 38
Grafico..................................................................................................................... 38
Grafico..................................................................................................................... 39
Grafico..................................................................................................................... 39
Domanda................................................................................................................. 39
Risposta................................................................................................................... 39
4.
Riepilogo............................................................................................................. 40
5.
Sommario............................................................................................................ 40
Asset Transition, Servizio di supporto, e test................................................................41

1.
obiettivi formativi.................................................................................................... 41
2.
Service Asset and Configuration Management...................................................41

2
Domanda................................................................................................................. 42
Risposta................................................................................................................... 43
3.
Pianificazione Transizione.................................................................................... 43
Domanda................................................................................................................. 45
Risposta................................................................................................................... 45
4.
Validazione e test................................................................................................ 47
Domanda................................................................................................................. 48
Risposta................................................................................................................... 48
5.
Riepilogo............................................................................................................. 49
6.
Sommario............................................................................................................ 49
Comprendere processi di transizione di servizio...........................................................50

1.
2.
Panoramica esercizio.......................................................................................... 50
3.
Riconoscendo politiche di transizione di servizio................................................50

Domanda................................................................................................................. 50
Risposta................................................................................................................... 50
Domanda................................................................................................................. 51
Risposta................................................................................................................... 51
Domanda................................................................................................................. 51
Risposta................................................................................................................... 52
Domanda................................................................................................................. 52
Risposta................................................................................................................... 53
4.
La gestione e la distribuzione di rilascio.............................................................53

Grafico..................................................................................................................... 53
Domanda................................................................................................................. 53
Risposta................................................................................................................... 53
Domanda................................................................................................................. 54
Risposta................................................................................................................... 54
Domanda................................................................................................................. 55
Risposta................................................................................................................... 55
Domanda................................................................................................................. 55
Risposta................................................................................................................... 56
3
5.
Riconoscendo la struttura DIKW..........................................................................56

Domanda................................................................................................................. 56
Risposta................................................................................................................... 56
6.
Identificare attivit.............................................................................................. 57
Domanda................................................................................................................. 57
Risposta................................................................................................................... 57
Domanda................................................................................................................. 58
Risposta................................................................................................................... 58
Domanda................................................................................................................. 59
Risposta................................................................................................................... 59
7.
Riepilogo............................................................................................................. 60
8.
Sommario............................................................................................................ 60
Cambio gestione........................................................................................................... 61
1.
obiettivi formativi................................................................................................ 61
2.
Finalit e campo di applicazione................................................................................61

Grafico..................................................................................................................... 61
Grafico..................................................................................................................... 62
Grafico..................................................................................................................... 62
3.
tipi di modifica di servizio................................................................................... 63

Domanda................................................................................................................. 65
Risposta................................................................................................................... 66
4.
interfacce Change Management.........................................................................66

Domanda................................................................................................................. 68
Risposta................................................................................................................... 68
5.
Riepilogo............................................................................................................. 69
6.
Sommario............................................................................................................ 69
Normali e di emergenza Variazioni Change Management............................................69

1.
2.
il cambiamento del ciclo di vita normale.............................................................69

Grafico..................................................................................................................... 70
Grafico..................................................................................................................... 70
Grafico..................................................................................................................... 70
4
Grafico..................................................................................................................... 71
Grafico..................................................................................................................... 71
Grafico..................................................................................................................... 72
Grafico..................................................................................................................... 72
Grafico..................................................................................................................... 72
Grafico..................................................................................................................... 73
Domanda................................................................................................................. 73
Risposta................................................................................................................... 73
3.
cambiamento del ciclo di vita di emergenza.......................................................74

Domanda................................................................................................................. 75
Risposta................................................................................................................... 76
4.
Riepilogo............................................................................................................. 76
5.
Sommario............................................................................................................ 76
La gestione dei servizi IT Modifiche.............................................................................. 78

1.
2.
panoramica esercizio.......................................................................................... 78
3.
Riconoscere tipi di cambiamento........................................................................78

Domanda................................................................................................................. 78
Risposta................................................................................................................... 78
4.
Riconoscendo le azioni del ciclo di vita del cambiamento...................................79

Domanda................................................................................................................. 79
Risposta................................................................................................................... 79
Domanda................................................................................................................. 80
Risposta................................................................................................................... 80
Domanda................................................................................................................. 81
Risposta................................................................................................................... 81
5.
Riepilogo............................................................................................................. 81
6.
Sommario............................................................................................................ 82
Cambio di valutazione.................................................................................................. 83
1.
2.
Obiettivi cambiamento di valutazione.................................................................83

Domanda................................................................................................................. 84
5
Risposta................................................................................................................... 84
3.
Benefici e sfide.................................................................................................... 85
Domanda................................................................................................................. 86
Risposta................................................................................................................... 86
4.
Riepilogo............................................................................................................. 87
5.
Sommario............................................................................................................ 87
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SERVICE OPERATION START.......................................................................................... 87

L'ambito e le responsabilit del Service Operation.......................................................88
1.
2.
Ambito di applicazione........................................................................................ 88
Grafico..................................................................................................................... 88
Domanda................................................................................................................. 89
Risposta................................................................................................................... 89
3.
Responsabilit..................................................................................................... 90
Domanda................................................................................................................. 91
Risposta................................................................................................................... 91
4.
Riepilgo............................................................................................................... 92
5.
Sommario............................................................................................................ 92
Il ruolo della comunicazione nel Service Operation......................................................93

1.
2.
Le pratiche di comunicazione efficace................................................................93

Domanda................................................................................................................. 95
Risposta................................................................................................................... 95
3.
Facilitare riunioni di successo..............................................................................96

Domanda................................................................................................................. 97
Risposta................................................................................................................... 97
4.
Le riunioni operative Servizio comune................................................................98

Domanda................................................................................................................. 99
Risposta................................................................................................................... 99
5.
Riepilogo............................................................................................................. 99
6.
Sommario.......................................................................................................... 100
6
Service Desk ruoli e obiettivi...................................................................................... 101

1.
Obiettivo di apprendimento..............................................................................101
2.
Funzioni Service Operation............................................................................... 101

Grafico................................................................................................................... 101
Domanda............................................................................................................... 102
Risposta................................................................................................................. 102
3.
I vantaggi di un service desk............................................................................ 102

Domanda............................................................................................................... 103
Risposta................................................................................................................. 103
4.
Fattori strutturali............................................................................................... 104

Domanda............................................................................................................... 106
Risposta................................................................................................................. 106
5.
strutture di service desk................................................................................... 106

domanda Set......................................................................................................... 107
Domanda 1 di 2...................................................................................................... 107
Domanda 2 di 2...................................................................................................... 108
5.
Riepilogo........................................................................................................... 109
6.
Sommario.......................................................................................................... 109
Altre funzioni Funzionamento di servizio....................................................................110

1.
obiettivi formativi.............................................................................................. 110
2.
Obiettivi Service Operation...............................................................................110

Grafico................................................................................................................... 110
Domanda............................................................................................................... 111
Risposta................................................................................................................. 111
3.
Gestione Tecnica............................................................................................... 111

Domanda............................................................................................................... 112
Risposta................................................................................................................. 112
4.
Le operazioni IT Management...........................................................................113
Domanda............................................................................................................... 115
Risposta................................................................................................................. 115
5.
Gestione Applicazione....................................................................................... 116

Supplemento.......................................................................................................... 116
7
Domanda............................................................................................................... 116
Risposta................................................................................................................. 117
6.
Riepilogo........................................................................................................... 117
Uso delle funzioni Service Operation..........................................................................119

1.
2.
panoramica esercizio........................................................................................ 119
3.
Riconoscendo le operazioni di servizio..............................................................119

Domanda............................................................................................................... 119
Risposta................................................................................................................. 119
Domanda............................................................................................................... 120
Risposta................................................................................................................. 120
Domanda............................................................................................................... 120
Risposta................................................................................................................. 121
4.
Impostazione di un service desk.......................................................................121

Domanda............................................................................................................... 121
Risposta................................................................................................................. 121
5.
Sommario.......................................................................................................... 122
Digitarel ' equazione qui . ........................................................................................... 123

L'area ei principi di gestione degli incidenti...............................................................123
1.
2.
Campo di applicazione 1. Incident Management...............................................123

Grafico................................................................................................................... 123
Domanda............................................................................................................... 124
Risposta................................................................................................................. 124
3.
Principi Incident Management...........................................................................125

Domanda............................................................................................................... 126
Risposta................................................................................................................. 126
Domanda............................................................................................................... 127
Risposta................................................................................................................. 128
4.
Riepilogo........................................................................................................... 128
5.
Sommario.......................................................................................................... 128
Il processo di gestione degli incidenti.........................................................................129

8
1.
2.
identificazione e la registrazione degli incidenti...............................................129

Grafico................................................................................................................... 129
Grafico................................................................................................................... 129
Grafico................................................................................................................... 130
3.
categorizzazione e prioritizzazione...................................................................131
Grafico................................................................................................................... 131
Grafico................................................................................................................... 131
Grafico................................................................................................................... 132
Grafico................................................................................................................... 132
Domanda............................................................................................................... 132
Risposta................................................................................................................. 133
4.
La diagnosi, escalation, e le indagini................................................................133

Grafico................................................................................................................... 133
Grafico................................................................................................................... 134
Grafico................................................................................................................... 134
Domanda............................................................................................................... 135
Risposta................................................................................................................. 135
5.
Risoluzione, chiusura e riapertura.....................................................................135

Grafico................................................................................................................... 135
Grafico................................................................................................................... 136
Domanda............................................................................................................... 137
Risposta................................................................................................................. 137
6.
Riepilogo........................................................................................................... 138
7.
Sommario.......................................................................................................... 138
Gestione Incidenti....................................................................................................... 139

1.
2.
3.
ambito Identificazione....................................................................................... 139

Domanda............................................................................................................... 139
Risposta................................................................................................................. 139
Domanda............................................................................................................... 140
9
Risposta................................................................................................................. 140
Domanda............................................................................................................... 141
Risposta................................................................................................................. 141
4.
Identificare i principi......................................................................................... 141

Domanda............................................................................................................... 142
Risposta................................................................................................................. 142
Domanda............................................................................................................... 142
Risposta................................................................................................................. 143
Domanda............................................................................................................... 143
Risposta................................................................................................................. 144
5.
Identificare attivit............................................................................................ 144

Domanda............................................................................................................... 144
Risposta................................................................................................................. 144
Domanda............................................................................................................... 145
Risposta................................................................................................................. 145
Domanda............................................................................................................... 145
Risposta................................................................................................................. 146
6.
Riepilogo........................................................................................................... 146
7.
Sommario.......................................................................................................... 146
Interfacce di gestione degli incidenti..........................................................................147

1.
2.
Incident Management e altri processi...............................................................147

Grafico................................................................................................................... 147
Domanda............................................................................................................... 147
Risposta................................................................................................................. 148
Domanda............................................................................................................... 149
Risposta................................................................................................................. 149
Domanda............................................................................................................... 150
Risposta................................................................................................................. 150
3.
Riepilogo........................................................................................................... 151
4.
Sommario.......................................................................................................... 151
L'area ei principi di Problem Management..................................................................152

10
1.
2.
Ambito di Problem Management.......................................................................152

Grafico................................................................................................................... 152
Domanda............................................................................................................... 152
Risposta................................................................................................................. 152
Domanda............................................................................................................... 153
Risposta................................................................................................................. 154
3.
Principi problema di gestione............................................................................154

Domanda............................................................................................................... 155
Risposta................................................................................................................. 156
Domanda............................................................................................................... 156
Risposta................................................................................................................. 156
4.
Riepilogo........................................................................................................... 157
5.
Sommario.......................................................................................................... 157
Il processo di Problem Management...........................................................................158

1.
2.
Il problema di gestione processo.........................................................................158

Grafico................................................................................................................... 158
Grafico................................................................................................................... 158
Grafico................................................................................................................... 158
Grafico................................................................................................................... 158
3.
individuare, registrare, classificare, dare priorit..............................................159

Grafico................................................................................................................... 159
Grafico................................................................................................................... 159
Grafico................................................................................................................... 160
Grafico................................................................................................................... 160
Grafico................................................................................................................... 160
Domanda............................................................................................................... 160
Risposta................................................................................................................. 161
4.
Indagare, aggirare, aumentare l'errore.............................................................161

Grafico................................................................................................................... 161
Grafico................................................................................................................... 163
11
Grafico................................................................................................................... 163
Domanda............................................................................................................... 163
Risposta................................................................................................................. 164
5.
Resolve, chiudere, recensione...........................................................................164

Grafico................................................................................................................... 164
Grafico................................................................................................................... 165
Grafico................................................................................................................... 165
Grafico................................................................................................................... 165
Domanda............................................................................................................... 166
Risposta................................................................................................................. 166
6.
Riepilogo........................................................................................................... 167
7.
Sommario.......................................................................................................... 167
Problemi di Gestione.................................................................................................. 167

1.
2.
3.
ambito Identificazione....................................................................................... 168

Domanda............................................................................................................... 168
Risposta................................................................................................................. 168
Domanda............................................................................................................... 169
Risposta................................................................................................................. 169
4.
riconoscendo principi........................................................................................ 169

Domanda............................................................................................................... 170
Risposta................................................................................................................. 170
5.
Identificare attivit............................................................................................ 170

Domanda............................................................................................................... 171
Risposta................................................................................................................. 171
Domanda............................................................................................................... 171
Risposta................................................................................................................. 171
Domanda............................................................................................................... 172
Risposta................................................................................................................. 172
6.
Riepilogo........................................................................................................... 172
7.
Sommario.......................................................................................................... 173
12
Interfacce di gestione dei problemi............................................................................ 173

1.
2.
Problem Management e altri processi...............................................................173

Grafico................................................................................................................... 173
Grafico................................................................................................................... 173
Domanda............................................................................................................... 175
Risposta................................................................................................................. 175
3.
Riepilogo........................................................................................................... 176
4.
Sommario.......................................................................................................... 176
Evento, richiesta e gestione degli accessi..................................................................176

1.
2.
Introduzione processi Service Operation...........................................................177

Grafico................................................................................................................... 177
3.
Event Management........................................................................................... 177
4.
Richiesta Fulfillment.......................................................................................... 178
5.
Gestione Accesso.............................................................................................. 180

Domanda............................................................................................................... 180
Risposta................................................................................................................. 180
6.
Riepilogo........................................................................................................... 181
7.
Sommario.......................................................................................................... 181
CSI Scope................................................................................................................... 182

1.
2.
Considerazioni di attuazione CSI.......................................................................182

Grafico................................................................................................................... 182
Grafico................................................................................................................... 183
Domanda............................................................................................................... 183
Risposta................................................................................................................. 183
3.
I vantaggi di CSI................................................................................................ 184

Domanda............................................................................................................... 185
Risposta................................................................................................................. 186
4.
Riepilogo........................................................................................................... 186
5.
Sommario.......................................................................................................... 186
13
Il Registro CSI............................................................................................................. 187

1.
2.
Scopo e vantaggi del registro CSI.....................................................................187

Grafico................................................................................................................... 187
Domanda............................................................................................................... 188
Risposta................................................................................................................. 188
Grafico................................................................................................................... 189
Domanda............................................................................................................... 190
Risposta................................................................................................................. 190
3.
Le informazioni contenute nel registro CSI........................................................190

Grafico................................................................................................................... 191
Grafico................................................................................................................... 191
Grafico................................................................................................................... 191
Domanda............................................................................................................... 192
Risposta................................................................................................................. 192
Domanda............................................................................................................... 193
Risposta................................................................................................................. 193
4.
Riepilogo........................................................................................................... 194
5.
Sommario.......................................................................................................... 194
Introduzione al processo di CSI................................................................................... 196

1.
2.
CSI e il ciclo di Deming...................................................................................... 196

Grafico................................................................................................................... 196
Domanda............................................................................................................... 197
Risposta................................................................................................................. 197
3.
Lo scopo del processo di CSI.............................................................................198

Grafico................................................................................................................... 199
Domanda............................................................................................................... 199
Risposta................................................................................................................. 200
4.
Riepilogo........................................................................................................... 200
5.
Sommario.......................................................................................................... 200
Trascrizione................................................................................................................. 201
14
Il processo di miglioramento CSI sette passi..............................................................201

1.
2.
Identificare le strategie e le 3. Misure...............................................................201

Grafico................................................................................................................... 201
Grafico................................................................................................................... 201
Grafico................................................................................................................... 202
Domanda............................................................................................................... 203
Risposta................................................................................................................. 203
4.Raccolta di dati..................................................................................................... 204

Grafico................................................................................................................... 204
Domanda............................................................................................................... 204
Risposta................................................................................................................. 205
5.Elaborazione dei dati e l'analisi............................................................................205
Grafico................................................................................................................... 205
Grafico................................................................................................................... 205
Domanda............................................................................................................... 206
Risposta................................................................................................................. 206
6.
Presentare e utilizzare le informazioni CSI........................................................207

Grafico................................................................................................................... 207
Domanda............................................................................................................... 208
Risposta................................................................................................................. 208
7.
Attuazione dei Miglioramenti............................................................................ 209

Grafico................................................................................................................... 209
Grafico................................................................................................................... 209
Grafico................................................................................................................... 210
Domanda............................................................................................................... 210
Risposta................................................................................................................. 211
8.
Riepilogo........................................................................................................... 211
Supplemento.......................................................................................................... 211
9.
Sommario.......................................................................................................... 212
Riconoscendo i sette passi per miglioramento...........................................................212

1.
15
2.
3.
Identificare i benefici e la portata.....................................................................212

Domanda............................................................................................................... 212
Risposta................................................................................................................. 213
Domanda............................................................................................................... 213
Risposta................................................................................................................. 213
4.
Utilizzando il registro CSI.................................................................................. 214

Domanda............................................................................................................... 214
Risposta................................................................................................................. 214
Domanda............................................................................................................... 215
Risposta................................................................................................................. 215
5.
Riconoscendo il processo di CSI........................................................................216

Grafico................................................................................................................... 216
Domanda............................................................................................................... 216
Risposta................................................................................................................. 216
Domanda............................................................................................................... 217
Risposta................................................................................................................. 217
Domanda............................................................................................................... 217
Risposta................................................................................................................. 218
Domanda............................................................................................................... 218
Risposta................................................................................................................. 218
Domanda............................................................................................................... 219
Risposta................................................................................................................. 219
Domanda............................................................................................................... 219
Risposta................................................................................................................. 220
6.
Riepilogo........................................................................................................... 220
7.
Sommario.......................................................................................................... 220
16
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
17
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 svista
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
rilascio e di prova, la distribuzione di rilascio, e la revisione e vicino, e colpisce Service
18
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.
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.
19
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

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
20
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
obiettivi:
21
1. Definire e attuare una politica formale per Service Transition

2. Attuare tutte le modifiche ai servizi attraverso Service Transition
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
22
il trasferimento delle conoscenze ai clienti e altre parti interessate per aumentare la loro
capacit di utilizzare il servizio nuovo o modificato
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.
8. Sistemi per il trasferimento di conoscenze e di supporto alle decisioni Fornire

23
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:
1. Allineare piani di transizione di servizio con le esigenze di business
2. Stabilire e mantenere relazioni con gli stakeholder
4. Fornire sistemi per il trasferimento di conoscenza e supporto alle decisioni
24
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 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
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
25
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
26
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):
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 |
|
Stampa e distribuzione gestione a Service

Transition
1. Obiettivo di apprendimento
27
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
beni virtuali, come un server virtuale o di storage virtuale
applicazioni e software
la formazione per gli utenti e il personale IT, e

28
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.
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.
29
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
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
30
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.
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.
31
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
verifica delle procedure di compilazione e le relative, e l'assegnazione delle risorse, i ruoli e le
responsabilit per l'esecuzione di attivit chiave.
32
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):
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 |
33
Knowledge Management nel Service Transition

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.
34
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
35
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.
36
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):
37
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 |
| 1. Ambito di applicazione e finalit |
| 2. Struttura DIKW |
| Sommario |
38
Asset Transition, Servizio di supporto, e test

1. obiettivi formativi
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. 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
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)
39
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
non le risorse IT, e
SACM pu coprire-IT non beni, 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
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
40
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
3. 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
41
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
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.
42
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
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
43
4. Validazione e test
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
44
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
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
45
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
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 |
| 1. Asset and Configuration Management |
| 2. Pianificazione di transizione |
| 3. Validazione e collaudo |
| Sommario |
46
Comprendere processi di transizione di servizio

1.
Obiettivi formativi
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
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.
47
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):
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:
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):
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
48
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:
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):
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
49
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):
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.
50
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):
51
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
52
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
53
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.
54
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.
55
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
56
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 |
| 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 |
57
Cambio gestione
1.
obiettivi formativi
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
58
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
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
59
potrebbero essere gestite attraverso un processo IT Change Management, avrebbero dovuto

essere tradotti in RFC associati ai cambiamenti di servizi IT necessari.
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.
60
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.
61
emergenza, e
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
62
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
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):
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.
63
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
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
64
Tutti i processi di gestione dei servizi possono richiedere Change Management, ad

esempio per realizzare miglioramenti di processo.
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
65
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
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 |
| 1. Scopo e campo |
| 2. Tipi di modifica Servizio |
| 3. Cambiare le interfacce di gestione |
| Sommario |
66
Normali e di emergenza Variazioni Change Management

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.
67
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
68
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.
69
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
70
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.
71
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.
72
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
73
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 |
| 1. Normale cambiamento del ciclo di vita |
| 2. Il cambiamento del ciclo di vita di emergenza |
| Sommario |
74
La gestione dei servizi IT Modifiche

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.
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):
75
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
76
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:
77
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 |
| 2. Riconoscere tipi di cambiamento |
| 3. Riconoscendo azioni cambiamento del ciclo di vita |
78
79
Cambio di valutazione
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.
80
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.
81
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
82
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
83
prospettive delle parti interessate, e la comunicazione dei rischi in modo efficace all'interno di una
organizzazione.
5. Sommario
| Inizio pagina |
| 1. Cambiare obiettivi della valutazione |
| 2. Vantaggi e sfide |
| Sommario |
84
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SERVICE OPERATION START

L'ambito e le responsabilit del Service Operation
1. Obiettivi formativi
descrivere l'oggetto di Service Operation
riconoscere le responsabilit del Service Operation

2. Ambito di applicazione
Il funzionamento del servizio la quarta tappa del ITIL Service Lifecycle.
Grafico
Lo schema ITIL Service Lifecycle rappresentato in un cerchio in cui lo stadio display
Service Strategy al suo centro. E 'circondato da Design, Servizio di transizione, e le fasi di
Service Operation. La fase di Continual Service Improvement costituisce il suo confine.
Lo scopo della fase di Service Operation quello di coordinare e svolgere le attivit ei processi
necessari per fornire e gestire servizi a livelli concordati per gli utenti business e ai clienti. Quindi la
fase di Service Operation assicura che i servizi vengono forniti come promesso.
La fase di Service Operation anche responsabile di assicurare che la tecnologia necessaria
gestito correttamente per sostenere questo servizio di consegna.
Service Operation una fase critica nel Service Lifecycle perch assicura che le operazioni
quotidiane funzionano senza intoppi. Gli obiettivi strategici dell'organizzazione sono in ultima
analisi ottenuti durante la fase di Service Operation.
operazioni quotidiane devono eseguire senza problemi e in modo efficace per garantire che gli
utenti aziendali possono raggiungere i loro obiettivi, e che i clienti ricevano i livelli di servizio che si
aspettano da parte dell'organizzazione.
Quando le operazioni senza intoppi, possibile raccogliere i dati di base necessari per pianificare
miglioramenti, o per trovare l'ispirazione per una migliore progettazione per i servizi.
Le persone che lavorano all'interno dei processi Service Operation devono affrontare il lavoro con
una visione ampia di tutto il meccanismo di funzionamento e di consegna. Se si avvicinano lavoro
con solo il loro processo o compiti specifici in mente che non pu essere in una buona posizione
per rilevare eventuali minacce o errori nella qualit complessiva del servizio.
Questa visione end-to-end pu includere fornitori, clienti e assistenza post-vendita. Cos, quando
necessario, i processi e gli strumenti utilizzati per gestire i flussi di lavoro cross-organizzative
dovrebbero essere distribuiti.
L'area di servizio Il funzionamento ampia - di portata comprende tutti i processi, le funzioni e gli
strumenti necessari per fornire e servizi di supporto. Questo ambito comprende
Servizi
I servizi includono qualsiasi attivit o l'attivit che fa parte di un servizio e che viene
effettuata dalla vostra organizzazione, un fornitore esterno, o l'utente o cliente del servizio.
processi di gestione dei servizi
85
Durante la fase di Service Operation, molti processi di gestione dei servizi sono
implementate e gestite su base continuativa. Anche se alcuni dei processi hanno origine in
altre fasi del ciclo di vita ITIL servizio, che culminano nella fase di Service Operation. Un
esempio di questo Change Management, che ha origine nella fase Service Transition, ma
le attivit principali di questo processo avvenga durante Service Operation. Alcuni processi
che non rientrano nell'ambito di applicazione del Service Operation comprendono il
processo di progettazione vera e propria e Gestione strategia per l'IT Servizi. Attivit di
processo a lungo termine, o attivit di pianificazione o di miglioramento per obiettivi a lungo
termine, tendono ad utilizzare le informazioni dalla fase Service Operation, ma non fanno
parte della sua portata.
tecnologia, e
Gestione della tecnologia utilizzata per fornire servizi IT parte integrante di Service
Operation. Cos una gran parte del lavoro svolto durante la fase di Service Operation
comprende la gestione dell'infrastruttura IT che garantisce l'erogazione dei servizi.
persone
Si tratta di persone che richiedono servizi e prodotti, ed la gente che gestiscono i
processi che li forniscono. Cos durante la fase di Service Operation, necessario essere a
conoscenza di tutte le persone coinvolte e lavorare verso la creazione di un servizio di
qualit accettabile a costi accettabili.
Per realizzare con successo la portata delle responsabilit Service Operation, necessario
considerare e tendere verso questi obiettivi:
fornire servizi IT e il supporto di questi servizi efficace ed efficiente
assicurarsi che i servizi sono forniti solo a quelli autorizzati a ricevere il servizio, e
ridurre l'impatto delle interruzioni di servizio nelle operazioni quotidiane
Domanda
Quali aree rientrano nell'ambito di applicazione del Service Operation?
Opzioni:
1. Garantire autorizzazioni di accesso sono in corso per l'accesso a un database di
vendita
2. Gestire requisiti hardware e software
3. La gestione di server e hardware della stampante
4. Attuazione della strategia di gestione per i servizi IT
5. Progettare il servizio per un nuovo ramo d'azienda
6. Considerando le persone che hanno intenzione, implementano e forniscono servizi
Risposta
Opzione 1: Corretto. Qualsiasi attivit che fa parte di un servizio incluso nelle operazioni
giorno per giorno. Quindi, garantire l'accesso a un database di vendita nell'ambito di
applicazione della fase di Service Operation.
Opzione 2: Corretto. La gestione e l'attuazione di molti processi di gestione dei servizi rientra
nell'ambito di applicazione del Service Operation.
86
Opzione 3: Corretto. Tecnologia che permette la fornitura di un servizio di gestione parte

integrante del Service Operation.
Opzione 4: non corretto. Alcuni processi che si concentrano su pi pianificazione a lungo
termine, come la strategia di gestione dei servizi IT, non sono inclusi nell'ambito di
applicazione del Service Operation. Tuttavia, la fase di Service Operation fa fornire un utile
contributo a tali processi.
Opzione 5: non corretto. Il processo di progettazione vera e propria per la gestione dei
servizi rientra nella fase di Service Design del ITIL Service Lifecycle, non la fase di Service
Operation.
Opzione 6: Corretto. Per gestire Service Operation, necessario essere a conoscenza di
tutte le persone coinvolte e lavorare verso la creazione di un servizio di qualit accettabile a
costi accettabili.
Risposte corrette):
1. Garantire autorizzazioni di accesso sono in corso per l'accesso a un database di
vendita
2. Gestire requisiti hardware e software
3. La gestione del server e la stampante hardware
6. Considerando le persone che hanno intenzione, implementano e forniscono servizi
3. Responsabilit
Perch Service Operation si occupa della attivit delle operazioni giorno per giorno, facile
impantanarsi nei dettagli e perdere di vista il quadro generale. Per combattere questa tendenza,
utile considerare Service Operation e le vostre responsabilit in un contesto pi ampio - quello del
ITIL Service Lifecycle, la tecnologia e il business globale.
Come parte del ITIL Service Lifecycle , la fase di Service Operation responsabile
dell'esecuzione e l'esecuzione di processi per ottimizzare il costo e la qualit dei servizi all'interno
del ciclo di vita.
Un'altra responsabilit quella di fornire il business con capacit di soddisfare i propri obiettivi.
Le responsabilit rimanenti all'interno della fase di Service Operation includono
la tecnologia utilizzata per fornire e supportare il servizio, e
Servizio responsabilit di funzionamento, in termini di tecnologia, assicurare anche che i
componenti che supportano i servizi IT funzionino in modo efficace.
Questa area di responsabilit comprende anche la realizzazione di attivit di controllo
dell'operazione che aiutano a gestire e fornire servizi IT.
il funzionamento complessivo del business stesso
Come parte del funzionamento generale del commercio , la fase di Service Operation
responsabile per la consegna di servizi IT in modo efficiente ed all'interno di parametri di
costo.
Questi servizi devono soddisfare le aspettative delineate nel Service Level Agreement
(SLA). Quindi vi una responsabilit per la consegna i livelli di servizio attesi per gli utenti e
clienti.
87
Service Operation anche la responsabilit di garantire la soddisfazione degli utenti con i

servizi IT.
Quando Service Operation funziona in modo efficace e raggiunge un equilibrio tra una particolare
attenzione per i dettagli e dal contesto pi ampio, le aziende sono in grado di trarre beneficio dai
loro investimenti IT. Cos Service Operation la fase in cui l'azienda riceve valore per un
investimento IT, il che rende questo fase del Service Lifecycle critica.
Domanda
Partita ogni responsabilit all'interno della fase di Service Operation per la categoria alla
quale essa appartiene. Pi di una responsabilit pu corrispondere a una categoria.
Opzioni:
A. Implementazione di processi che assicurano convenienti, servizi IT di alta qualit
B. componenti assicurando che supportano i servizi IT funzionino in modo efficace
C. Garantire costo di consegna efficace dei servizi IT
D. Fornire i servizi IT definiti negli SLA
E. Implementazione di attivit di controllo operazione per fornire servizi IT
F. Fornire il business con capacit di soddisfare i propri obiettivi
obiettivi:
1. Responsabilit come parte del Lifecycle Service
2. Responsabilit come parte della tecnologia
3. Responsabilit come parte del business globale
Risposta
Implementazione di processi per assicurare l'equilibrio ottimale tra costi e qualit, e
consentendo alle aziende di raggiungere i suoi obiettivi strategici, sono responsabilit Service
Operation come parte del Service Lifecycle.
Responsabilit connesse con la tecnologia assicurare anche che i componenti che
supportano la funzione di servizi in modo efficace le attivit di controllo e di funzionamento
aiutano a gestire e fornire servizi.
Servizio responsabilit operazione legata al business globale includono la fornitura di servizi
all'interno dei livelli di servizio concordati in modo efficiente e ad un costo accettabile.
Risposte corrette):
Obiettivo 1 = Opzione F, Opzione A
Obiettivo 2 = Opzione E, l'opzione B
Obiettivo 3 = Opzione D, Opzione C
4. Riepilgo
Il funzionamento del servizio la quarta tappa del ITIL Service Lifecycle. Lo scopo di questa fase
ampio in quanto comprende le operazioni giorno per giorno che aiutano a supervisionare e
implementare processi e le attivit per garantire che i servizi vengono forniti. Servizi, processi di
gestione dei servizi, la tecnologia e le persone rientrano tutti nell'ambito del Service Operation. Le
88
responsabilit sono sia con le operazioni quotidiane, nonch quelli nei contesti pi ampi della
Service Lifecycle, la tecnologia, e l'azienda stessa. Meeting delle responsabilit all'interno di
queste aree assicura benefici tangibili per gli investimenti IT.
5. Sommario
| Inizio pagina |
| 1. Ambito di applicazione |
| 2. responsabilit |
| Sommario |
89
Il ruolo della comunicazione nel Service Operation

individuare i principi di best practice per una comunicazione efficace in Service Operation
individuare le strategie per facilitare riunioni di successo

2. Le pratiche di comunicazione efficace
La comunicazione il processo attraverso il quale le persone o gruppi di persone si scambiano

informazioni, verbalmente o per iscritto.
In Service Operation, una buona comunicazione pu prevenire i problemi che si verificano o
attenuare i problemi che possono portare a problemi a valle della linea. Per esempio, se un
imprevisto impatto questione di business di un cliente, il fornitore del cliente e il servizio pu
consultare sulla questione e trovare il modo di regolare il servizio di conseguenza.
Bad comunicazione pu peggiorare le situazioni non avendo per evitare problemi di escalation. Ad
esempio, se un cliente non soddisfatto con alcuni aspetti di un servizio, errore di comunicazione
con il cliente sui modi per migliorare il servizio pu portare a un conflitto tra i partner di servizio.
Una buona comunicazione necessaria a tutti i livelli. squadre Service Operation, i team IT, utenti
e clienti sia interni che esterni devono comunicare regolarmente e in modo efficace.
. Non ci sono regole dure e veloci circa il ruolo e la pratica della comunicazione nel Service
Operation Tuttavia, queste sono alcune delle migliori pratiche che si dovrebbe tenere a mente:
individuare i soggetti interessati
essere consapevoli dei tipi di comunicazione tipiche Service Operation
esprimono la destinazione di ogni comunicazione in modo chiaro, e
concordare un modo appropriato di comunicazione
Prima di effettuare qualsiasi tipo di comunicazione, importante identificare i soggetti

interessati che hanno bisogno di essere coinvolti. Tutti i giocatori di ruolo devono essere
consapevoli di quando la comunicazione quello di prendere posto e dovrebbe essere coinvolto in
qualche modo.
Le parti interessate possono includere proprietari dei processi IT e personale coinvolto nel Service
Operation, responsabili di processo per i processi eseguiti da personale del Service Operation, i
team IT e reparti, clienti, utenti e personale fornitore coinvolto nel Service Operation.
Gli organizzatori devono essere consapevoli dei tipi di comunicazione tipico di Service
Operation e provare a selezionare il tipo pi efficace per lo scopo a portata di mano.
Alcuni esempi di diversi tipi di comunicazione che possono essere richiesti in Service Operation
includono
comunicazione operativa di routine
Attraverso la comunicazione operativa di routine , le parti interessate possono
riassumere gli eventi e presentare le nuove emissioni, ed evidenziare la necessit di un
follow-up sui problemi del passato.
90
la comunicazione tra un turno

La comunicazione tra i turni pu essere richiesto di aggiornare il personale in arrivo su
eventuali incidenti o problemi che si sono verificati durante il turno precedente.
reporting delle prestazioni
Tutti i membri del team possono svolgere un ruolo nel reporting delle prestazioni . Ad
esempio, i membri del team possono essere invitati a riferire sullo stato di salute di tutti i
sistemi principali e di informare altro personale di eventuali problemi che possono incidere
su di essa le operazioni di servizio nel prossimo futuro.
comunicazione in progetti, e
La comunicazione nei progetti necessaria per garantire che tutte le parti interessate
sono a conoscenza di eventuali problemi o incidenti che hanno bisogno di essere affrontati,
e che i piani di azione sono concepiti per la partecipazione alle questioni in sospeso.
formazione sui processi nuovi o modificati, disegni e modelli di servizio
E 'importante che le parti interessate a comunicare tutte le informazioni necessarie sulla
formazione sui processi nuovi o modificati, disegni e modelli di servizio.Questo assicura
che i membri del personale sono disponibili a partecipare a qualsiasi formazione adeguata,
e impedisce la formazione di interrompere le operazioni.
Ulteriori esempi di diversi tipi di comunicazione necessari a Service Operation includono
comunicazione relativa al
i cambiamenti
E 'importante comunicare le modifiche alle parti interessate. Le comunicazioni possono
essere programmati per discutere i cambiamenti che ci si aspetta e potenziali incidenti che
possono verificarsi a seguito, e di elaborare un piano d'azione per affrontare gli incidenti
rilevanti.
eccezioni
Se ci sono operative eccezioni , devono essere comunicati al personale, incluso qualsiasi
impatto atteso le eccezioni possono avere sulla gestione.
emergenze, e
In caso di funzionamento di emergenza , come un grande fallimento di rete, il personale
pu avere bisogno di incontrarsi per discutere il problema, trovare soluzioni, e stabilirsi su
un piano d'azione.
strategia, progettazione, e la transizione alle squadre operative di servizio
Informazioni generali sulla strategia IT, progettazione e servizi IT in fase di
transizione per le parti interessate in funzione del servizio deve essere comunicato anche.
Quando si prepara a comunicare le informazioni, importante mantenere la
destinazione scopo della comunicazione e tutti i risultati che ci si aspetta in mente. inoltre
necessario essere chiari su chi il pubblico destinatario . Inoltre, il pubblico deve essere in
accordo con l'organizzatore sullo scopo della comunicazione e qualsiasi azione che ci si aspetta di
conseguenza.
91
Oltre agli incontri, la comunicazione pu essere consegnato in molti modi, tra cui e-mail, servizi di
social media e di microblogging, instant messaging e web-based chat, cercapersone, Voice over
Internet Protocol (VoIP) utilities, teleconferenza e utilities riunioni virtuali e documenti utilit
-Condivisione.
Anche se ITIL non specifica un particolare mezzo di comunicazione o comunicazione di
frequenza, le organizzazioni dovrebbero determinare e documentare le proprie politiche di
comunicazione in base alle loro esigenze organizzative e preferenze.
E 'importante che tutte le parti interessate sanno come e quando la comunicazione quello di
prendere posto.
Ad esempio, se i membri di un'unit business lavoro off-site e devono mantenere il contatto con
l'altro, pu essere pi pratico usare messaggi di testo piuttosto che e-mail. Se questo il caso,
tutte le parti interessate devono sapere che hanno bisogno di mantenere i loro dispositivi cellulari
cariche e su di essi in ogni momento.
Il tipo di comunicazione favorito da un'organizzazione dipender sue esigenze. Ad esempio,
un'organizzazione con molti lavoratori fuori sede possono preferire l'uso di e-mail e teleconferenze
per la comunicazione. Le organizzazioni con i processi di gestione dei servizi pi complessi
favorir utilizzando strumenti di comunicazione e processi progettati per soddisfare le loro
particolari esigenze. Per esempio, pu essere protocollo per comunicare con i membri del team
che utilizzano uno strumento di gestione degli eventi che genera allarmi e li comunica ai membri
del team per l'azione automaticamente.
Domanda
Quali sono alcune delle migliori pratiche per la comunicazione efficace nel Service Operation?
Opzioni:
1. Identificare tutte le persone che dovrebbero essere coinvolti
2. Che tutti i soggetti interessati conoscono lo scopo di ogni comunicazione
3. Utilizzare la tecnologia pi avanzata per facilitare la comunicazione
4. Indipendentemente sviluppare un ordine del giorno per ogni riunione
5. Fare uso di tipi di comunicazione tipica di Service Operation
6. D'accordo con le parti interessate su una modalit appropriata di comunicazione
Risposta
Opzione 1: Corretto. Per evitare eventuali cali di comunicazione, necessario identificare
tutte le parti interessate e di garantire il loro coinvolgimento.
Opzione 2: Corretto. I soggetti interessati devono essere informati del motivo per ciascuna
comunicazione e le azioni che dovrebbero derivare.
Opzione 3: non corretto. Sebbene la tecnologia avanzata pu contribuire a facilitare la
comunicazione, pi importante che la tecnologia essere adatto allo scopo della
comunicazione stessa e il contesto in cui essa viene effettuata.
Opzione 4: non corretto. L'invito a una riunione e l'ordine del giorno dovrebbe essere
sviluppato in collaborazione con le parti interessate che hai identificato.
Opzione 5: Corretto. Avere la consapevolezza dei diversi tipi di comunicazione utilizzati in
Service Operation pu aiutare a concentrarsi gli obiettivi ei contenuti delle comunicazioni.
92
Opzione 6: Corretto. Procedure ottimali impongono che tutte le parti interessate concordano
sulla modalit pi appropriata di comunicazione, dato il contesto in cui deve avvenire.
Risposte corrette):
1. Identificare tutte le persone che dovrebbero essere coinvolti
2. Che tutti i soggetti interessati conoscono lo scopo di ogni comunicazione
5. Fare uso di tipi di comunicazione tipica di Service Operation
6. D'accordo con le parti interessate su una modalit appropriata di comunicazione
3. Facilitare riunioni di successo
Incontro, quando eseguito correttamente, sono un mezzo molto utile per la comunicazione. Lo
scopo di tenere una riunione lo scambio di informazioni su questioni e obiettivi comuni con un
gruppo. Le riunioni dovrebbero sempre rimanere concentrato su un programma comune con
l'obiettivo di guidare l'azione.
Questi sono alcuni dei fattori che possono contribuire a garantire un meeting di successo:
che istituisce un programma chiaro
problemi di registrazione che non sono all'ordine del giorno corrente
garantire che le regole per la partecipazione sono compresi
mantenendo minuti, e
incoraggianti livelli adeguati di partecipazione
E 'importante stabilire un ordine del giorno chiaro . Un ordine del giorno chiaro pu aiutare a
garantire che i partecipanti rimanere concentrati e che gli obiettivi di riunione sono
soddisfatte. Cambiamenti Suppongo che in normative di settore hanno un impatto sui processi
operativi di servizi IT dell'organizzazione. Un chiaro giorno di una riunione per discutere i
cambiamenti possono aiutare i partecipanti a concentrarsi sulla ricerca di soluzioni creative, invece
di entrare in discussioni dettagliate su ci che ha spinto le modifiche normative.
E 'importante registrare nuove questioni che non sono all'ordine del giorno corrente in modo
che i dettagli di questi problemi possono essere affrontati in un secondo momento. Inoltre,
rendendo note di questioni che non hanno subito rilevanti pu aiutare a convalidare le
preoccupazioni dei partecipanti che hanno sollevato i problemi, mantenendo l'ordine del giorno
corrente in pista.
La persona facilitando una riunione dovrebbe garantire che le regole per la partecipazione
sono compresi da tutti i partecipanti. La maggior parte delle organizzazioni hanno un insieme di
regole per quanto riguarda la partecipazione di incontro. Tali regole possono aiutare a garantire
che le riunioni senza intoppi. Per esempio, se tutti sanno che solo le questioni presentate all'ordine
del giorno saranno in discussione, possono assicurare che argomenti vogliono discutere sono
posti all'ordine del giorno. Se non riescono a farlo, loro sanno che i loro problemi possono essere
sollevate e noti per l'indirizzo futuro.
E 'importante mantenere minuti per diversi motivi:
per ricordare alla gente che sono state delegate a
per monitorare lo stato di avanzamento delle attivit che sono state delegate, e
93
per monitorare e seguire attraverso decisioni e azioni di cross-funzionali
Il facilitatore di una riunione dovrebbe incoraggiare gli adeguati livelli di partecipazione nel
corso della riunione. Questo pu aiutare a garantire che alcuni partecipanti non prendono la
riunione. I partecipanti possono anche accordarsi su quali argomenti per intrattenere o
interrompere durante la discussione. Per esempio, i partecipanti possono decidere di allontanare i
problemi specifici che non sono rilevanti per l'obiettivo della riunione. Questo pu contribuire ad
accelerare il ritmo della riunione.
Domanda
Identificare le strategie per facilitare riunioni di successo.
Opzioni:
1. Stabilire una chiara agenda
2. Incoraggiare la partecipazione massima su tutte le questioni
3. Mantenere minuti per gli incontri
4. Ignorando i problemi che non sono direttamente rilevanti
5. Garantire che tutti comprendano le regole di partecipazione
Risposta
Opzione 1: Corretto. A, un'agenda chiara e completa pu aiutare a garantire che i
partecipanti rimangono orientate al raggiungimento degli obiettivi fissati per una riunione.
Opzione 2: non corretto. Incoraggiare la partecipazione massima su tutte le questioni pu
essere controproducente. Le riunioni devono essere brevi e orientato agli obiettivi.
Opzione 3: Corretto. Verbalizzazione in grado di garantire che i partecipanti ricordano quali
problemi sono stati concordati e aiutare nel monitoraggio delle azioni e delle attivit di crossfunzionali che sono state delegate ad altri.
Opzione 4: non corretto. Anche se i problemi che non sono direttamente rilevanti non deve
essere discusso, importante prendere appunti di loro nel caso in cui le questioni sono di
nuovo pi tardi e in modo che le persone che hanno sollevato le questioni sanno che sono
stati ascoltati.
Opzione 5: Corretto. Per garantire che le riunioni senza intoppi, tutti i partecipanti dovrebbero
avere accesso alle regole dell'organizzazione di incontro di partecipazione.
Risposte corrette):
1. Stabilire un ordine del giorno chiaro
3. Mantenere minuti per le riunioni
5. Garantire che tutti comprendano le regole di partecipazione
94
4. Le riunioni operative Servizio comune

Incontri faccia a faccia tra le parti interessate a Service Operation possono essere tenuti
periodicamente, ma non sono sempre la soluzione migliore. E 'meglio se le informazioni utili
possono essere condivise in modo altrettanto efficace con altri mezzi, come ad esempio e-mail. E'
anche importante non di sviluppare una cultura in cui il lavoro si svolge o di gestione si consulta
con il personale solo durante le riunioni.
Le riunioni faccia a faccia possono essere costosi e potenzialmente dirompente. Essi richiedono
alle persone di impostare il tempo da parte dalle loro attivit abituali e di recarsi a un luogo di
incontro. Inoltre, sedi devono essere prenotati e ristoro potrebbero dover essere forniti. Cos gli
organizzatori dovrebbero sempre valutare i benefici di incontri faccia a faccia con i relativi costi.
I tre tipi di incontri luoghi comuni includono
incontri operativi
Incontri Operations si tengono all'inizio di ogni giorno o settimana. Essi sono di solito
partecipano i responsabili delle varie unit IT, presieduto dal responsabile delle operazioni
IT o responsabile delle operazioni di alto livello, e comprendono almeno un rappresentante
del service desk.
incontri di gruppo, e
Incontri di gruppo sono simili a riunioni operative tranne che includono solo i membri di un
particolare reparto IT, un gruppo o squadra.
incontri con i clienti
In aggiunta alle regolari riunioni di revisione dei livelli di servizio, riunioni con i clienti tra il
management e clienti sono occasionalmente tenuti a rivedere l'erogazione dei servizi e le
aspettative, e per risolvere eventuali problemi relativi al servizio.
Lo scopo di un incontro operazioni quello di evidenziare i problemi di funzionamento di servizi
IT rilevanti, come modifiche ai programmi, eventi imprevisti e manutenzione programmata.
I partecipanti possono sollevare nuove questioni e opportunit di nota per migliorare i servizi o
processi, che possono anche essere comunicati al CSI squadra.
incontri operazioni anche consentire la sincronizzazione tra le varie unit.
Durante incontri di gruppo , il personale IT pu essere informato su tutte le informazioni
pertinenti per la loro squadra. I membri del team discutono i loro progressi sulle assegnazioni
attuali, il lavoro incompleto, e potenziali problemi o preoccupazioni. Essi possono anche fornire
stime su tempi di completamento e richiedere risorse aggiuntive, se necessario. Questioni come
programmi di vacanza dei membri del team e disponibilit per i dazi roster sono trattate anche in
questi incontri.
95
Incontri con i clienti possono occasionalmente essere tenute dare un seguito a gravi incidenti o
per fornire un forum cliente.
incontri con i clienti che seguono su gravi incidenti possono essere utilizzate per riparare i rapporti
con i clienti, per raccogliere informazioni che i fornitori di servizi possono utilizzare per evitare che
il problema si ripresenti, e per concordare modi per prevenire l'incidente si ripeta in futuro.
Un forum cliente fornisce un ambiente in cui le aree di preoccupazione sia per il cliente e
l'organizzazione possono essere discussi. In questo tipo di incontro, nuove idee per il
miglioramento del servizio pu anche essere messo in avanti.
Domanda
Abbinare ogni tipo di riunione Service Operation alle sue caratteristiche.
Opzioni:
A. incontro Operations
B. riunione del gruppo
C. incontro clienti
obiettivi:
1. I gestori di vari reparti si incontrano per discutere di questioni operative
2. I manager si incontrano con il loro team di trasmettere le informazioni rilevanti da
incontri di livello superiore e per discutere dei progressi squadra
3. servizi IT rappresentanti delle organizzazioni si incontrano con i clienti per riparare le
relazioni danneggiate o migliorare le relazioni esistenti
Risposta
In una riunione operazioni, manager di diverse unit IT si incontrano per discutere di questioni
operative quali cambiamenti di programma, gli eventi non pianificati, e manutenzione
programmata.
In una riunione di gruppo, il manager o supervisore di un team IT o reparto passa le
informazioni pertinenti dalla riunione operazioni. Il personale in grado di fornire un feedback
sui problemi legati al lavoro in modo che il manager pu tenere traccia dei progressi
all'interno del gruppo.
In caso di problemi gravi, si tengono riunioni con i clienti per riparare relazioni con i clienti
danneggiati. incontri con i clienti possono anche essere utilizzati per contribuire a migliorare il
servizio e per prevenire le recidive di problemi.
Risposte corrette):
5. Riepilogo
Per una comunicazione efficace durante la fase di Service Operation, necessario coinvolgere
tutte le parti interessate, determinare e utilizzare il tipo pi appropriato di comunicazione, in modo
che tutti capiscano lo scopo della comunicazione, e concordare un mezzo attraverso il quale
comunicare con i partecipanti. Per garantire che le riunioni senza intoppi, possibile definire un
ordine del giorno chiaro, in modo che tutti capiscano le regole di partecipazione, prendere appunti
su questioni che non sono direttamente rilevanti per il problema a portata di mano, prendere
96
minuti, e incoraggiare livelli adeguati di partecipazione. i tipi di incontri comunemente tenuti in

Service Operation comprendono incontri operazioni, incontri di gruppo, e riunioni con i clienti.
6. Sommario
| Inizio pagina |
| 1. Pratiche di comunicazione efficace |
| 2. Facilitare riunioni di successo |
| 3. Incontri Service Operation comune |
| Sommario |
97
Service Desk ruoli e obiettivi

determinare quale strutture di service desk da utilizzare in determinate esempi

2. Funzioni Service Operation
Una funzione comprende le misure e le persone che svolgono un processo o un'attivit

definita. Questo pu essere rappresentato da una singola unit organizzativa o un gruppo
eterogeneo di gruppi e dipartimenti.
Ci sono quattro principali funzioni operative di servizio, che hanno lo scopo generale di gestione di
uno "stato stazionario" ambiente operativo.
Grafico
La prima funzione Service Operation il service desk. La seconda funzione la gestione
tecnica, che comprende server, desktop, reti e middleware. IT Operations Management
incorpora alcune delle gestione tecnica e Application Management, ma il suo obiettivo
principale operazioni di controllo IT e Facility Management.Application Management
incorpora finanza, risorse umane, e le applicazioni aziendali.
Servizio reception
Il service desk il principale punto di contatto per gli utenti quando vi una interruzione
del servizio, per le richieste di servizio, o anche per alcune categorie di richieste di modifica
(RFC).
Direzione tecnica
Technical Management fornisce le competenze tecniche dettagliate e le risorse
necessarie per supportare l'operazione in corso della IT Infrastructure - quali server, reti e
desktop. Direzione Tecnica svolge anche un ruolo importante nella progettazione, collaudo,
rilascio e il miglioramento dei servizi IT.
IT Operations Management
IT Operations Management la funzione responsabile delle attivit operative quotidiane
necessarie per gestire l'infrastruttura IT. Esso incorpora il controllo delle operazioni e
gestione degli impianti. Controllo operazioni IT assicura che i compiti operativi di routine
vengono effettuati. Facilities Management si riferisce alla gestione dell'ambiente IT fisico di solito data center o sale computer.
Application Management
Application Management responsabile della gestione di applicazioni in tutto il loro ciclo
di vita. La funzione di Application Management supporta e mantiene applicazioni operative
e svolge anche un ruolo importante nella progettazione, collaudo, e il miglioramento delle
applicazioni che fanno parte dei servizi IT.
Le quattro funzioni Service Operation garantire che i sistemi, software, servizi e operare in modo
efficiente e coerente.
Domanda
Abbinare ogni funzione Service Operation alla sua descrizione.
Opzioni:
98
A. Servizio reception
B. Direzione tecnica
C. IT Operations Management
D. Application Management
obiettivi:
1. Fornisce un punto centrale di contatto per gli utenti in caso di interruzione del servizio
2. Supporta il funzionamento di server, reti e infrastrutture IT in generale attraverso la
conoscenza tecnica
3. Assicura che i compiti operativi di routine sono svolte e gestisce l'ambiente IT fisico
4. Progettazione, manutenzione e controllo delle applicazioni software in tutto il ciclo di
vita
Risposta
Una scrivania servizio il principale punto di contatto per gli utenti quando vi una
interruzione del servizio, per le richieste di servizio, o anche per alcune categorie di RFC.
Direzione Tecnica supporta il funzionamento continuo della IT Infrastructure - quali server, reti
e desktop.
Le operazioni IT Management incorpora IT il controllo delle operazioni, che assicura che i
compiti operativi di routine vengono effettuati. Incorpora inoltre Facilities Management, che si
concentra sulla gestione dell'ambiente IT fisico.
Application Management responsabile della gestione applicazioni - tra cui Finanza, Risorse
Umane, e le applicazioni aziendali - in tutto il loro ciclo di vita.
Risposte corrette):
3. I vantaggi di un service desk
Un service desk una unit funzionale composta da un numero dedicato di personale incaricato di
trattare con una variet di eventi di servizio.
Questi eventi vengono segnalati attraverso chiamate telefoniche o un'interfaccia web, o vengono
segnalati automaticamente gli eventi di infrastruttura.
Il Service Desk una parte estremamente importante del reparto IT di un'organizzazione e
dovrebbe essere l'unico punto di contatto per gli utenti su base giorno per giorno.Service desk in
generale di gestire tutti gli incidenti e le richieste di servizio, e di solito fanno uso di software
specializzato strumenti per registrare e gestire tutti questi eventi.
Lo scopo primario della scrivania servizio di ripristinare il servizio normale per gli utenti pi
rapidamente possibile.
Ripristino servizio normale per gli utenti si intende in senso pi ampio possibile. Anche se questo
potrebbe comportare la fissazione di un guasto tecnico, si potrebbe ugualmente comportare
soddisfare una richiesta di servizio o rispondere a una domanda.
99
Cos il service desk si propone di fare tutto ci che necessario per ritornare servizi alla normalit
per gli utenti, per migliorare il servizio clienti, e per migliorare le operazioni IT .
I vantaggi di un efficace banco di servizio sono che
migliora il servizio al cliente, attraverso una migliore maneggevolezza e pi rapida

inversione di tendenza delle richieste del cliente o dell'utente
aumenta l'accessibilit attraverso un unico punto di contatto
migliora l'infrastruttura e controllo
migliora l'utilizzo delle risorse IT di supporto, attraverso una migliore lavoro di squadra e la
comunicazione
riduce l'impatto sul business negativo delle interruzioni del servizio, aumentando la
produttivit del personale aziendale, e
fornisce un'ottima base per i dipendenti che desiderano intraprendere una carriera nel
Service Management
I vantaggi della funzione di service desk rendono lo strumento pi importante per la gestione di
prima linea di supporto IT problemi. Esso fornisce una funzione di supporto altamente controllabile
che migliora la gestione delle risorse e dei clienti o per affari produttivit.
Domanda
Quali sono alcuni dei vantaggi di un efficace service desk?
Opzioni:
1. Migliora il servizio clienti
2. Migliora l'utilizzo delle risorse IT di supporto
3. Aumenta l'accessibilit
4. Si riduce l'impatto sul business negativo di interruzioni del servizio
5. Si riduce la necessit per la documentazione di interruzioni e richieste degli utenti
6. Essa garantisce 24 ore di accesso al personale di supporto IT
Risposta
Opzione 1: Corretto. Un banco di servizio efficace migliora il servizio al cliente, fornendo una
migliore maneggevolezza e pi rapida inversione di tendenza delle richieste del cliente o
dell'utente.
Opzione 2: Corretto. Un banco di servizio efficace aiuta ad ottimizzare l'uso delle risorse di
supporto attraverso una migliore il lavoro di squadra e la comunicazione.
Opzione 3: Corretto. Un service desk efficace migliora l'accessibilit, fornendo un unico
punto di contatto per gli utenti e clienti. Gli utenti possono chiamare un numero unico per tutti
i problemi di supporto IT e gli avvisi automatici sono impostati per andare a una singola
destinazione.
Opzione 4: Corretto. Ritorno veloce di richieste degli utenti da parte di un efficace service
desk consente agli utenti di tornare alla piena produttivit pi veloce, riducendo cos l'impatto
sul business negativo delle interruzioni del servizio.
100
Opzione 5: non corretto. Tutte le chiamate, le richieste e le interruzioni devono essere

registrati dal service desk per assistere con la determinazione parametri richiesti e con il
miglioramento della qualit del servizio.
Opzione 6: non corretto. La struttura e l'organizzazione di service desk variano - non tutti
sono progettati per supportare l'accesso 24 ore al giorno.
Risposte corrette):
1. Migliora il servizio clienti
2. Migliora l'utilizzo delle risorse di supporto IT
3. Aumenta l'accessibilit
4. Si riduce l'impatto sul business negativo di interruzioni del servizio
4. Fattori strutturali
Ci sono una serie di possibili strutture e la posizione opzioni per service desk. La soluzione
ottimale per una struttura di service desk e la posizione dipendente da esigenze
dell'organizzazione. Pu anche avere bisogno di essere personalizzato con servizi specialista
gruppi scrivania Alcuni service desk.
Le due strutture organizzative di base per service desk sono
locale,
Un locale di service desk si trova all'interno o vicino alla comunit di utenti che
serve. Questo aiuta spesso la comunicazione e fornisce il service desk una presenza
visibile. Tuttavia, un banco di servizio locale pu essere inefficiente e costoso a risorsa, in
particolare quando i volumi delle chiamate sono relativamente bassi. Potrebbe essere
necessario mantenere un banco di servizio locale anche se i volumi delle chiamate da sole
non giustificano. Ci pu essere dovuto a gruppi specializzati o utenti ad alto
status; linguistici, culturali, o il fuso orario differenze; o l'esistenza di servizi personalizzati o
specializzati che richiedono conoscenze specialistiche.
centralizzata
Un centralizzato service desk il personale si trova in uno o pi centralizzate strutture di
service desk. Questo pu essere pi efficiente e conveniente rispetto all'utilizzo di service
desk locali, perch un minor numero di personale sono necessari al fine di gestire un
elevato volume di chiamate. Tale struttura favorisce anche i livelli di competenza pi elevati
perch il personale tendono ad avere a che fare con un gran numero di eventi specifici. Il
mantenimento di una qualche forma di presenza sul territorio, pu essere ancora
necessaria per gestire le esigenze di supporto fisico, ma tale personale pu essere
controllato e distribuito da il service desk centrale.
Altre strutture organizzative per service desk fanno uso della tecnologia e la globalizzazione di
business.
service desk virtuale
Utilizzando la tecnologia come Internet e gli strumenti di supporto aziendali, possibile
dare l'impressione di un singolo, scrivania servizio centralizzato, quando in realt, il
personale si trovano attraverso qualsiasi numero o il tipo di localit geografiche o
strutturali. Questo il ruolo di un service desk virtuale . Service desk virtuali forniscono la
possibilit di lavorare a casa, gruppi di sostegno secondari, offshoring, o l'outsourcing - o
qualsiasi combinazione di queste opzioni. Tuttavia, ci deve essere coerenza e uniformit
101
nella qualit del servizio e termini culturali, che pu essere difficile da raggiungere con un
service desk virtuale.
Follow-the-sun service desk
Alcune organizzazioni globali o internazionali possono combinare due o pi dei loro service
desk geograficamente dispersi per fornire 24 ore di follow-the-SunService scrivania . Ci
fornisce una copertura di 24 ore a un costo relativamente basso, perch mancava la
scrivania deve lavorare pi di un singolo turno di lavoro. Ad esempio, un service desk nella
regione Asia-Pacifico pu gestire le chiamate durante gli orari di ufficio standard e, alla fine
di questo periodo , consegnare la responsabilit di eventuali incidenti aperti ad un service
desk-based europea.
Tutte le scrivanie di servizio devono condividere processi comuni, gli strumenti e le

informazioni del database. La questione della cultura e la lingua ha anche bisogno di
essere affrontato per questo approccio abbia successo.
Alcune organizzazioni trovano utile per creare gruppi di specialisti del service desk all'interno
della struttura complessiva del service desk. Incidenti relativi a particolari servizi IT vengono
indirizzati direttamente al gruppo pi attrezzata per gestirli. Ci consente una pi rapida risoluzione
di questi incidenti, attraverso una maggiore familiarit e formazione specialistica.
possibile impostare gli script telefoniche agli utenti percorso attraverso al relativo gruppo di
service desk specialistico. Ad esempio, "Se la chiamata di circa il servizio wireless, si prega di
premere 1 ora; altrimenti si prega di tenere premuto per un analista di Service Desk." O avvisi per
un particolare tipo di servizio possono essere indirizzate direttamente al gruppo servizio
associato. Le selezioni disponibili non devono essere troppo complicata, gruppi di servizio in modo
da specialisti dovrebbero essere considerati solo per un numero molto limitato di servizi chiave,
dove i volumi di chiamate per questi servizi sono elevati .
Indipendentemente dalla struttura banco di servizio che si sceglie per la propria organizzazione,
necessario assicurarsi che gli utenti sappiano che hanno bisogno di contattare e come contattare il
servizio di assistenza adeguata.
Un indirizzo numero di telefono unico, e-mail, e la pagina web - o uno per ciascun gruppo, se
vengono scelti service desk separati - dovrebbe essere fornito e ben pubblicizzato.
Punti di contatto possono essere pubblicizzati in vari modi per garantire che gli utenti sappiano
cosa numero da chiamare, quale sito web per andare a, o quale indirizzo e-mail da utilizzare.
possibile inserire le informazioni di contatto su hardware, telefoni, bacheche, o aziendale . regali
come penne o tazze possibile utilizzare uno sfondo personalizzato o desktop che contiene i dati
di contatto service desk, insieme a informazioni lette dal sistema che sar necessario al momento
della chiamata - come Internet Protocol (IP) e il sistema operativo (OS ) numero di build. anche
possibile inserire informazioni di contatto in vista sulla scrivania siti servizio Internet o intranet,
aggiungerli alla corrispondenza e-mail con gli utenti, o fornire agli utenti con carte telefoniche.
Domanda
102
Quali sono i fattori cosa necessario prendere in considerazione per determinare la struttura
e la posizione del service desk?
Opzioni:
1. struttura ottimale o miscela di strutture da utilizzare
2. Gruppi professionali richieste
3. I metodi utilizzati per pubblicizzare il service desk per gli utenti
4. i livelli di abilit del personale di supporto
Risposta
Opzione 1: Corretto. Le opzioni disponibili sono strutturali locali, centralizzate, virtuale, e il
follow-il-sole. Ognuna di queste strutture di service desk dotato di una propria serie di punti
di forza e di debolezza. La struttura scelta dovrebbe essere abbinato alle esigenze
Opzione 2: Corretto. Quando competenze specialistiche sono richieste o dove ci si aspetta
un gran numero di chiamate relativi ad un servizio specifico, i gruppi di service desk
specialistico possono essere creati per affrontare questi specifici servizi o critici.
Opzione 3: non corretto. I metodi utilizzati per pubblicizzare il service desk per gli utenti
dovrebbero essere progettati intorno alla struttura pi idonea e un percorso per il service
desk.
Opzione 4: non corretto. I livelli di abilit necessarie del personale di supporto una
considerazione importante. Tuttavia, non necessariamente una considerazione nella scelta
della struttura e la posizione del desk assistenza.
Risposte corrette):
1. struttura ottimale o miscela di strutture da utilizzare
2. Gruppi professionali richieste
5. strutture di service desk
Un rivenditore di moda ha cinque negozi in tutto tre stati. Database, server Intranet, e il server web
del rivenditore sono tutti situati in una sede centrale a Boston. Reparto IT del rivenditore gestisce
le questioni tecniche e software, e sta progettando un impianto di service desk.
Il rivenditore di moda decide di fondere due strutture organizzative di service desk:
centralizzata, e
Inizialmente, il team di servizio di gestione decide che un banco di servizio centralizzato
basato presso la sede di Boston sar la soluzione pi conveniente.Questa strategia
funziona perch costa meno di personale service desk locale e aiuta a consolidare i
processi e le risorse.
virtuale
Il team di Service Management decide che una sola persona contratto dovrebbe essere
disponibile per problemi tecnici presso i negozi nelle altre posizioni.Questo personale pu
essere controllato e distribuito dal service desk centrale. Una soluzione di team virtuale
stato deciso in quanto lavoratori a contratto su un piccolo fermo sono una soluzione
economicamente conveniente. Il negozio assicura che tutti i contraenti sono addestrati nei
processi associati ai loro ruoli.
103
Poich il software Voice over che il negozio utilizza Internet Protocol (VoIP) non si basa sulla
stessa piattaforma come le sue altre soluzioni di rete, il rivenditore decide di formare un gruppo
speciale di service desk a che fare con domande e richieste di VoIP.
La catena di abbigliamento si espande nel mercato australiano e per Parigi. Per soddisfare questa
espansione, le seguenti strutture di service desk supplementari sono incorporati:
locale,
A causa delle differenze linguistiche, il rivenditore di moda decide di utilizzare service desk
locale per la sua filiale di Parigi. Essa stabilisce inoltre un banco di servizio locale per le
filiali in Australia.
Segui il sole
Per ridurre i costi di gestione di due banchi di servizi locali e per migliorare la produttivit, la
squadra di servizio di gestione decide di utilizzare un approccio di follow-the-sun tra la sua
Uniti e service desk australiani. Il personale in entrambe le service desk usare
inglese. differenze di tempo tra il capo del servizio scrivania a Boston e il service desk
australiano permettono compiti da essere consegnati in modo che il servizio 24 ore al
giorno pu essere fornito senza richiedere diverse ore di lavoro per i lavoratori di service
desk.
Simile al rivenditore di moda, la soluzione service desk che la vostra organizzazione sceglie
dovrebbe dipendere budget, le esigenze di personale, esigenze di servizio, la lingua, e le questioni
geografiche.
domanda Set
Una grande societ di intermediazione finanziaria ha tre filiali a New York. L'azienda la
creazione di un service desk per fornire il primo porto di scalo per tutta la sua in-house
richiede. Si deciso di operare il service desk interno.
Domanda 1 di 2
Domanda
Le principali questioni che il service desk avr bisogno per affrontare sono problemi di rete,
problemi di amministrazione, e le questioni di desktop. Quale struttura di service desk meglio
si adatta a questa ditta?
Opzioni:
1. service desk locale
2. service desk centralizzato
3. service desk virtuale
4. Follow-the-sun service desk
Risposta
Opzione 1: non corretto. Una struttura di service desk locale non costo-efficace in questo
scenario. Non ci sono gruppi specializzati o utenti ad alto status; linguistici, culturali, o il fuso
orario differenze; o su misura o servizi che richiedono conoscenze specialistiche
specializzata.
104
Opzione 2: Corretto. Una struttura di service desk centralizzato probabile che sia la
soluzione pi efficace per questa societ. Personale in generale meno sar necessaria per
affrontare con alti volumi di chiamate, con conseguente risparmio sui costi. Una struttura
centralizzata incoraggia anche i livelli di competenza pi elevati a causa della maggiore
frequenza con cui il personale hanno a che fare con eventi specifici.
Opzione 3: non corretto. Anche se una struttura di service desk virtuale potrebbe funzionare,
l'azienda ha deciso di operare internamente il servizio di assistenza in modo che non avr
bisogno di soddisfare offshoring o esternalizzazione.
Opzione 4: non corretto. Tutti i rami sono nello stesso fuso orario, quindi una struttura di
service desk di follow-the-sun non possibile.
Risposte corrette):
Domanda 2 di 2
Domanda
Una macro in-house, utilizzato da 100 membri del personale di finanza che sono classificati
come critici per il business, genera una serie di problemi che spesso richiedono
aggiornamenti al codice Java. Il personale di servizio scrivania sono addestrati in
amministrazione e messa in rete, ma non hanno familiarit con Java e la funzionalit della
macro. Come deve l'accordo organizzazione con questo?
Opzioni:
1. Creare un gruppo speciale di service desk a che fare con domande relative al
servizio macro
2. Addestrare tutto il personale del service desk in modo che possano affrontare
domande circa il servizio macro
3. Noleggiare un singolo programmatore Java per gestire le query sul servizio macro
Risposta
Opzione 1: Corretto. Poich il servizio fondamentale, richiede una serie di abilit differenti,
e attira un elevato volume di chiamate e richieste, uno speciale gruppo di service desk
dovrebbe essere istituito per sostenere il servizio.
Opzione 2: non corretto. La formazione di tutto il personale del service desk per gestire le
query sul servizio macro sarebbe costoso e improbabile per generare competenze sufficienti
abbastanza rapidamente per gestire il problema.
Opzione 3: non corretto. Un singolo programmatore improbabile che sia in grado di gestire
il volume di chiamate e di lavoro che le questioni connesse con il servizio macro generer.
Risposte corrette):
1. Creare un gruppo speciale di service desk a che fare con domande relative al servizio
macro
5. Riepilogo
Funzioni Service Operation comprendono il service desk, la gestione tecnica, IT Operations
Management, e Application Management.
105
L'obiettivo principale del service desk quello di ripristinare il normale servizio per gli utenti il pi
rapidamente possibile. Questa funzione generalmente accettato come il mezzo pi efficace di
trattare le richieste di prima linea o richieste di informazioni. In aggiunta a questo, i benefici
includono il servizio clienti e un migliore utilizzo delle risorse IT migliorate.
Durante la progettazione di service desk, necessario considerare la struttura organizzativa del
service desk e se sono necessari gruppi di service desk speciale. Strutture potenziali per service
desk sono locali, centralizzata, virtuale e strutture di follow-il-sole.
6. Sommario
| Inizio pagina |
| 1. Funzioni Service Operation |
| 2. I vantaggi di un service desk |
| 3. Fattori strutturali |
| 4. Strutture service desk |
| Sommario |
106
Altre funzioni Funzionamento di servizio

riconoscere il duplice ruolo di Technical Management
riconoscere come l'IT Operations Management raggiunge l'equilibrio tra i suoi due ruoli
identificare i quattro ruoli di Application Management

2. Obiettivi Service Operation
Oltre al banco di servizio, Service Funzioni operative comprendono
Grafico
La prima funzione Service Operation il service desk. La seconda funzione la gestione
tecnica che incorpora server, desktop, reti e middleware. IT Operations Management
incorpora alcune delle gestione tecnica e Application Management, ma il suo obiettivo
principale IT Operations di controllo e gestione degli impianti.Application Management
incorpora finanza, risorse umane, e le applicazioni aziendali.
Direzione tecnica
Gli obiettivi della gestione tecnica sono di contribuire alla progettazione, realizzazione e
manutenzione di un'infrastruttura tecnica stabile. Una topologia tecnica ben progettato,
resistente, e conveniente dovrebbe essere in grado di favorire i processi di business
L'infrastruttura tecnica dovrebbe essere mantenuto attraverso l'uso adeguato e tempestivo
di competenze tecniche e tecniche per diagnosticare e risolvere eventuali guasti tecnici che
si verificano .
IT Operations Management, e
Gli obiettivi di IT Operations Management includono il mantenimento della stabilit dei
processi e delle attivit quotidiane dell'organizzazione, migliorando il servizio a costi ridotti
attraverso l'analisi regolari, e l'utilizzo di competenze operative per diagnosticare e risolvere
eventuali operazioni IT guasti che si verificano.
Application Management
Application Management si propone di supportare i processi di business di
un'organizzazione, identificando i requisiti funzionali e gestibilit per il software
applicativo. Essa mira inoltre a contribuire alla progettazione, implementazione, la
manutenzione e il miglioramento delle applicazioni. Si raggiunge questi obiettivi,
garantendo che le applicazioni sono ben progettati, resiliente, costo-efficacia, e soddisfare i
requisiti di funzionalit per il raggiungimento di risultati di business. Ci si aspetta anche per
diagnosticare e risolvere problemi tecnici.
Tutte le funzioni operative di servizio includono la pianificazione, la manutenzione e le attivit di
risoluzione dei problemi, e sono progettati per supportare gli obiettivi generali dell'organizzazione.
Domanda
107
Abbinare ogni funzione Service Operation al corrispondente obiettivo.

Opzioni:
A. Direzione tecnica
B. IT Operations Management
C. Application Management
obiettivi:
1. Garantire una topologia tecnica ben progettato, resistente, e conveniente
2. Il mantenimento della stabilit dei processi e delle attivit quotidiane
dell'organizzazione
3. Identificare i requisiti funzionali e gestibilit per il software applicativo
Risposta
Gli obiettivi della gestione tecnica includono l'implementazione e il mantenimento di
un'infrastruttura tecnica stabile in grado di supportare i processi di business.
Gli obiettivi di IT Operations Management includono il mantenimento della stabilit dei
processi e delle attivit quotidiane dell'organizzazione. Esse comprendono anche il
miglioramento del servizio a costi ridotti attraverso l'analisi regolare, e la diagnosi e la
risoluzione di eventuali operazioni IT guasti che si verificano.
Gli obiettivi della funzione di gestione delle applicazioni includono l'identificazione requisiti per
il software applicativo, e assistenza nella progettazione, implementazione, la manutenzione e
il miglioramento delle applicazioni.
Risposte corrette):
3. Gestione Tecnica
Direzione Tecnica si riferisce ai gruppi, dipartimenti o team che forniscono competenze tecniche e
di gestione complessiva dell'infrastruttura IT.
La funzione di gestione tecnico si concentra sulla gestione di hardware. In questo contesto, essa
svolge un duplice ruolo:
che detiene conoscenze tecniche e competenze, e
La funzione di gestione tecnico tiene e mantiene la conoscenza tecnica e le
competenze relative alla gestione dell'infrastruttura IT dell'organizzazione. E 'responsabile
di assicurare che ci sia conoscenze e competenze a disposizione per progettare sufficienti,
prova, gestire e migliorare i servizi IT.
fornisce risorse tecniche per supportare l'IT Service Management (ITSM) del ciclo di vita
La funzione di gestione tecnico responsabile di fornire le risorse tecniche per
supportare il ciclo di vita ITSM . Questo ruolo richiede che il personale sia
adeguatamente formato. Si richiede inoltre l'impiego appropriato delle risorse al fine di
garantire che la tecnologia usati per fornire e supportare i servizi IT di progettazione,
costruzione, gestito, e migliorato in modo efficace.
108
I requisiti per il doppio ruolo di Technical Management sono identificati all'interno del Service
Strategy, ampliato durante il processo di Service Design, convalidato durante la Service Transition,
e affinate attraverso Continual Service Improvement (CSI).
Per svolgere il suo duplice ruolo, la gestione tecnica assicura che un'organizzazione pu accedere
alle risorse umane adeguate per gestire la tecnologia necessaria per supportare gli obiettivi di
business.
Un aspetto importante di svolgere questo ruolo in modo efficace la capacit di bilanciare i livelli di
abilit a disposizione, l'utilizzo delle risorse, e il costo di queste risorse.
Ad esempio, se assumere un tecnico molto esperto e quindi utilizzare le abilit del tecnico solo per
un piccola percentuale del tempo, non hanno utilizzato le risorse salariali in modo ottimale. In
questo scenario, pu essere meglio assumere un imprenditore per l'attivit.
Le organizzazioni pi grandi possono sfruttare personale specializzato di piscine centrali per
mansioni tecniche specifiche. Ci contribuisce a garantire economie di scala e riduce la necessit
di assumere gli appaltatori per il lavoro tecnico. Questo tipo di utilizzo delle risorse
particolarmente efficace per i team di progetto e la risoluzione dei problemi.
La gestione tecnica si prevede di fornire una guida per le operazioni IT sul modo migliore di
procedere alla gestione operativa continua della tecnologia. Questo ruolo svolto nel processo di
Service Design, cos come durante le comunicazioni in corso con IT Operations Management.
Domanda
Quali dichiarazioni descrivere con precisione i ruoli di Technical Management?
Opzioni:
1. Essa garantisce che non vi la conoscenza e le competenze disponibili per
supportare servizi IT sufficienti
2. Assicura che adeguate risorse tecnologiche vengono distribuiti per supportare i
servizi IT
3. Esso fornisce la formazione tecnica a tutto il team Service Management
4. Essa garantisce che le attivit di backup e ripristino sono eseguiti in modo ottimale
per la funzione IT Operations Management
Risposta
Opzione 1: Corretto. Uno dei ruoli della gestione tecnica quello di tenere e mantenere le
conoscenze tecniche necessarie per progettare, testare, gestire e migliorare i servizi IT.
Opzione 2: Corretto. Un ruolo di Technical Management quello di gestire le risorse
tecniche, assicurando che essi sono addestrati e distribuiti per progettare, costruire, gestire e
migliorare i servizi IT in modo efficace.
Opzione 3: non corretto. La gestione tecnica si prevede di fornire una guida per le operazioni
IT sul modo migliore di procedere alla gestione operativa continuativa di tecnologia, ma non si
prevede di formare tutto il personale IT.
Opzione 4: non corretto. Le attivit di backup e ripristino sono parte di IT Operations
Management. La gestione tecnica si prevede di fornire una guida tecnica su questa
operazione, se necessario.
Risposte corrette):
109
1. Si assicura che non vi la conoscenza e le competenze disponibili per supportare

servizi IT sufficienti
2. Assicura che adeguate risorse tecnologiche vengono distribuiti per supportare i servizi
IT
4. Le operazioni IT Management
IT Operations Management la funzione responsabile per la manutenzione continua e la gestione
delle infrastrutture IT delle organizzazioni. Si definito dalle attivit quotidiane necessarie per
assicurare che l'infrastruttura funziona in modo ottimale. A loro volta, le operazioni di gestione IT
consente a un'organizzazione di soddisfare i propri obiettivi di business attraverso l'uso della
propria infrastruttura IT. IT Operations Management svolge due funzioni - controllare le operazioni
e di gestione degli impianti .
Operazioni di controllo supervisiona l'esecuzione e il monitoraggio delle attivit e degli eventi

nell'infrastruttura IT. Questo avviene tramite un ponte operazioni o centro operativo di rete - la
posizione fisica in cui monitorato e gestito rete informatica.
Oltre a eseguire attivit di routine in tutti i settori tecnici, le operazioni di controllo esegue le
seguenti attivit specifiche:
la gestione di console
Controllare le operazioni esegue Management Console , che definisce l'osservazione
centrale e capacit di monitoraggio. Questo viene poi utilizzato per monitorare e controllare
le attivit operative.
pianificazione dei processi
Job scheduling la gestione dei processi batch di routine o script, che esegue il controllo
delle operazioni.
l'esecuzione di backup e ripristini
Le operazioni di controllo responsabile per l'esecuzione di backup e ripristini a nome di
tutte le squadre tecniche e gestione delle applicazioni, cos come i reparti e singoli utenti.
gestione di stampa e uscita elettronica, e
Le operazioni di controllo responsabile per la raccolta e la distribuzione di tutti
centralizzati di stampa e l'output elettronico .
l'esecuzione di attivit di manutenzione
Le operazioni di controllo responsabile per l'esecuzione di attivit di manutenzione per
conto di squadre di tecnici o di un'applicazione per la gestione o dipartimenti.
L' Servizi Gestione sottofunzione di IT Operations Management prevede la gestione dell'ambiente
IT fisico. Questo include data center e sale computer, cos come le attrezzature di alimentazione e
raffreddamento necessario. Nei casi in cui in outsourcing la gestione di un data center, strutture
di gestione responsabile della gestione del contratto di outsourcing.
Facilities Management inoltre responsabile del coordinamento progetti di consolidamento su
larga scala, come i progetti di consolidamento dei server.
110
Come per molti processi di IT Service Management e le funzioni, le operazioni IT Management

svolge un duplice ruolo:
mantenere le attivit in corso e processi in esecuzione in modo ottimale, e
Mantenendo le attivit ed i processi in corso in esecuzione in modo ottimale , le
operazioni IT Management mantiene lo status quo richiesto come definito nel Service
Design e Service Transition.
IT Operations Management si occupa di mantenere la stabilit dell'infrastruttura IT e la
coerenza dei servizi IT. Miglioramenti operativi in questo contesto riguardano pi semplici e
migliori modi di fare le stesse cose.
adattarsi ai cambiamenti nei requisiti di business e della domanda
Oltre a mantenere le infrastrutture e il processo di status quo, IT Operations Management
deve anche essere in grado di adattarsi ai cambiamenti nei requisiti di business e la
domanda . Si deve garantire che le operazioni e gli eventi supportano un ambiente in
continua evoluzione.
Poich i due ruoli di IT Operations Management sono ad un certo livello di contraddittorio, IT
Operations Management ha bisogno di creare un equilibrio tra il mantenimento dello status quo e
cambiare lo status quo per affrontare nuove sfide.
Per raggiungere questo equilibrio, IT Operations Management ha bisogno di generare due set di
metriche - a riferire al business sul raggiungimento degli obiettivi di servizio, e di riferire al manager
IT sull'efficienza e l'efficacia delle operazioni IT.
. IT Operations Management deve sviluppare una strategia di costi volta a bilanciare le esigenze di
diverse unit di business con i risparmi sui costi disponibili attraverso l'ottimizzazione della
tecnologia o gli investimenti in nuove tecnologie esistenti Questa strategia deve essere fondata su
un valore a base - piuttosto che una in termini di costi basata - Return on Investment approccio
(ROI) per gli investimenti.
Per raggiungere l'equilibrio tra i suoi due ruoli, la funzione IT Operations Management richiede una
chiara comprensione di entrambe le esigenze tecnologiche e di servizio.
Per garantire questo, ha bisogno di delineare le procedure e manuali che delineano il ruolo delle
operazioni IT sia nella gestione della tecnologia e della fornitura di servizi IT.
Ha anche bisogno di costruire una comprensione di come la tecnologia viene utilizzata per fornire
servizi e l'importanza relativa e l'impatto di tali servizi sul business IT. Quindi tutte le operazioni IT
personale bisogno di capire come le prestazioni della tecnologia influenza la fornitura di servizi IT.
Domanda
Come ci si Operations Management raggiungere l'equilibrio tra i suoi due ruoli?
Opzioni:
1. Si crea metriche di business sul servizio risultati oggettivi e sulla efficienza delle
operazioni IT
2. Si sviluppa una strategia di costo in grado di bilanciare le esigenze di business nei
confronti di investimenti tecnologici
3. Si crea una strategia di ROI basato sul valore per gli investimenti
111
4. Esso fornisce le procedure che illustra il suo ruolo nella gestione della tecnologia e la
fornitura di servizi IT
5. Esso si basa la comprensione di come la tecnologia fornisce servizi IT e l'impatto di
questi servizi sul business
6. Essa si basa sulla gestione tecnica di fissare le sue priorit
Risposta
Opzione 1: Corretto. IT Operations Management ha bisogno di generare due set di metriche
- uno tracciare il raggiungimento degli obiettivi di servizio e l'altro tracciando l'efficienza e
l'efficacia delle operazioni IT.
Opzione 2: Corretto. IT Operations Management ha bisogno di sviluppare una strategia di
costo in grado di bilanciare esigenze diverse unit di business 'con i risparmi sui costi
disponibili attraverso l'ottimizzazione della tecnologia o gli investimenti in nuove tecnologie
esistenti.
Opzione 3: Corretto. Strategia di investimento IT Operations Management dovrebbe
identificare basato sul valore piuttosto che il ROI basato sui costi.
Opzione 4: Corretto. Tutte le attivit IT Operations Management, procedure e manuali
devono chiarire sia dei suoi ruoli - la fornitura di servizi IT e la gestione della tecnologia.
Opzione 5: Corretto. Con la tecnologia per i servizi che vengono consegnati collegamento e
privilegiando i servizi in base al loro impatto sul business, IT Operations Management
meglio in grado di assegnare il valore e le priorit.
Opzione 6: non corretto. Sebbene la gestione tecnica fornisce una guida per le operazioni IT
sul modo migliore di procedere alla gestione operativa continuativa di tecnologia, IT
Operations Management definisce le proprie priorit.
Risposte corrette):
1. Crea metriche di business sul servizio risultati oggettivi e sulla efficienza delle
operazioni IT
2. Si sviluppa una strategia di costo in grado di bilanciare le esigenze di business nei
confronti di investimenti tecnologici
3. Si crea una strategia di ROI basato sul valore degli investimenti
4. Esso fornisce le procedure che illustra il suo ruolo nella gestione della tecnologia e la
fornitura di servizi IT
5. Esso si basa la comprensione di come la tecnologia fornisce servizi IT e l'impatto di
questi servizi sul business
5. Gestione Applicazione
Application Management svolge un ruolo nella gestione di tutte le applicazioni, siano essi
acquistati o sviluppati in-house. E 'anche la responsabilit di informare le decisioni su se comprare
o costruire applicazioni necessarie.
Il doppio ruolo che svolge Application Management quello di fornire
conoscenze tecniche e competenze, e
Application Management responsabile per la detenzione e il controllo conoscenze
tecniche e le competenze relative alle applicazioni di gestione. In questo ruolo, collabora
112
con Direzione Tecnica per garantire che vi sia una sufficiente conoscenza per progettare,
testare, gestire e migliorare i servizi IT in modo ottimale.
risorse necessarie per supportare il ciclo di vita ITSM
Application Management responsabile di fornire le applicazione necessaria risorse per
sostenere il ciclo di vita ITSM . In questo ruolo, assicura che il personale di applicazione
sono addestrati e che le risorse sufficienti sono dispiegati in tutto il ciclo di vita ITSM.
di applicazione per la gestione di due ruoli contribuiscono a garantire un equilibrio tra i livelli di
abilit e il costo delle risorse di applicazioni, a sostegno degli obiettivi di business
Oltre alle sue due ruoli di alto livello, Application Management effettua le seguenti ruoli specifici:
fornire orientamenti per il funzionamento dei servizi IT, e
Application Management fornisce una guida per il funzionamento dei servizi IT su come
gestire in modo efficace applicazioni. Questo ruolo ha inizio durante il processo di Service
Design, ma continua in maniera costante come IT Operations Management tenta di
mantenere la stabilit e prestazioni ottimali.
integrando la Lifecycle Management Application con ogni fase del ITSM
Applicazioni coniugare tecnologia e funzionalit, e ogni fase del ciclo di vita di gestione
applicazione ha un insieme specifico di obiettivi, attivit, risultati finali, e le squadre. Cos un
focus specifico necessario per integrare l' Application Lifecycle Management con ogni
fase del ITSM in modo che le loro uscite corrispondenza agli obiettivi del servizio di
gestione del ciclo di vita.
Supplemento
Selezionando il titolo del link si apre la risorsa in una nuova finestra del browser.
aiuti di lavoro
In passato, la gestione delle applicazioni e sviluppo di applicazioni erano unit distinte. Con i
mercati in evoluzione e le esigenze dei consumatori, queste due funzioni devono essere pi
integrati. Accedi al lavoro di aiuto allo sviluppo Applicazione contro la gestione delle
applicazioni per ulteriori informazioni.
Domanda
Identificare i quattro ruoli di Application Management.
Opzioni:
1. Esso fornisce le conoscenze tecniche e le competenze relative alle applicazioni di
gestione
2. Fornisce le risorse delle applicazioni necessarie per tutto il ciclo di vita ITSM
3. Esso fornisce una guida per IT Operations Management sulla gestione delle
applicazioni
4. Integra l'Application Lifecycle Management nel ciclo di vita ITSM
5. Esso fornisce una guida alla gestione tecnica su come gestire strutture informatiche
6. Esso genera metriche l'erogazione dei servizi e l'efficacia operativa IT
Risposta
113
Opzione 1: Corretto. Application Management responsabile per la detenzione e il controllo

conoscenze tecniche e le competenze relative alle applicazioni di gestione.
Opzione 2: Corretto. Application Management responsabile di fornire risorse applicative
theneeded per supportare il ciclo di vita ITSM. In questo ruolo, assicura che il personale di
applicazione sono addestrati e che le risorse sufficienti sono dispiegati in tutto il ciclo di vita
ITSM.
Opzione 3: Corretto. Application Management fornisce una guida per IT Operationsabout
come gestire in modo efficace applicazioni. Questo ruolo ha inizio durante il processo di
Service Design, ma continua a titolo permanente.
Opzione 4: Corretto. Application Management ha bisogno di mappare e integrare ogni fase
del ciclo di vita di gestione applicazione con ogni fase del ciclo di vita ITSM in modo che le
loro uscite corrispondano agli obiettivi del servizio di gestione del ciclo di vita.
Opzione 5: non corretto. Infatti, la gestione tecnica fornisce una guida per IT Operations
Management per la gestione dei servizi IT.
Opzione 6: non corretto. IT Operations Management - piuttosto che Application Management
- rapporti sulla fornitura di servizi IT e l'efficacia operativa.
Risposte corrette):
1. Esso fornisce le conoscenze tecniche e le competenze relative alla gestione delle
applicazioni
2. Fornisce le risorse delle applicazioni necessarie per tutto il ciclo di vita ITSM
3. Esso fornisce una guida per IT Operations Management sulla gestione delle
applicazioni
4. Integra l'Application Lifecycle Management nel ciclo di vita ITSM
6. Riepilogo
Direzione Tecnica, IT Operations Management, e gli obiettivi di gestione delle applicazioni
comprendono la pianificazione, la manutenzione e le attivit di risoluzione dei problemi
all'interno di ogni rispettivo settore. La gestione tecnica svolge un duplice ruolo di custode di
informazioni tecniche e di know-how e come fornitore delle risorse tecniche necessarie. Esso
fornisce anche una guida per IT Operations Management per la manutenzione continua delle
infrastrutture IT. IT Operations di gestione svolge due funzioni - controllare le operazioni e
gestione degli impianti. Il suo doppio ruolo richiede che crea un equilibrio tra il mantenimento
dello status quo e cambiare lo status quo per affrontare nuove sfide. Ruoli principali di
applicazione di gestione sono come custode di informazioni sulle applicazioni tecniche e
competenze e come fornitore delle risorse applicative necessarie. I suoi due ruoli aggiuntivi
forniscono una guida per le operazioni IT sulla gestione delle applicazioni, e integrando
l'Application Lifecycle Management nel ciclo di vita IT Service Management (ITSM).
7. Sommario
| Inizio pagina |
| 1. Servizio obiettivi di funzionamento |
114
| 2. Direzione Tecnica |
| 3. IT Operations Management |
| 4. Application Management |
| Sommario |
115
Uso delle funzioni Service Operation

riconoscere le caratteristiche delle funzioni operative di servizio e come selezionare una

struttura di service desk e come al personale in modo appropriato in un dato esempio
In questo esercizio, ti viene richiesto di riconoscere i ruoli e gli obiettivi di funzioni Service
Operation.
individuando i ruoli e gli obiettivi di funzioni Service Operation, e
riconoscendo come selezionare una struttura di service desk e come al personale in modo
appropriato in un dato scenario
3. Riconoscendo le operazioni di servizio
Ci sono quattro principali funzioni di servizio operazione che interagiscono tra loro per garantire il
funzionamento ottimale del servizio.
Domanda
Abbinare ogni funzione Service Operation, con la sua descrizione.
Opzioni:
A. Servizio reception
B. Direzione tecnica
C. IT Operations Management
D. Application Management
obiettivi:
1. Fornendo un punto centrale di contatto per gli utenti in caso di interruzione del
servizio
2. Sostenere il funzionamento continuo delle infrastrutture tecniche attraverso la
conoscenza tecnica
3. Assicurare che le attivit di routine sono effettuate e la gestione dell'ambiente IT
fisico
4. Gestione della progettazione, la manutenzione e il controllo di applicazioni software
per tutto il ciclo di vita
Risposta
Una scrivania servizio il principale punto di contatto per gli utenti quando vi una
interruzione del servizio, per le richieste di servizio, e per alcune categorie di richieste di
modifica (RFC).
Direzione Tecnica supporta il funzionamento continuo dell'infrastruttura IT - compresi elementi
quali server, reti e desktop.
IT Operations Management si concentra sulla gestione dell'ambiente IT fisico e la garanzia
che tutti i compiti necessari per mantenere esso attuazione.
116
Application Management responsabile della progettazione e gestione delle applicazioni - tra

cui finanza, risorse umane, e le applicazioni di business - in tutto il loro ciclo di vita.
Risposte corrette):
Domanda
Una delle funzioni Service Operation il compito di sostenere i processi di business di
un'organizzazione identificando requisiti funzionali e gestibilit per il software.Funzione che
svolge questo ruolo?
Opzioni:
1. Servizio reception
2. Direzione tecnica
3. IT Operations Management
4. Application Management
Risposta
Opzione 1: non corretto. Il ruolo della scrivania servizio di ripristinare il normale servizio
agli utenti pi rapidamente possibile.
Opzione 2: non corretto. Il ruolo della gestione tecnica quello di assistere nella
pianificazione, implementazione e manutenzione di un'infrastruttura tecnica stabile.
Opzione 3: non corretto. Il ruolo di IT Operations Management il mantenimento della
stabilit dei processi e delle attivit quotidiane dell'organizzazione, cos come il miglioramento
dei servizi a costi ridotti attraverso l'analisi periodica.
Opzione 4: Corretto. Ruoli di gestione delle applicazioni includono l'identificazione dei
requisiti funzionali e gestibilit per il software, fornendo conoscenze tecniche ed esperienza,
fornendo risorse applicative, e integrando l'Application Management Lifecycle con quella di IT
Service Management (ITSM).
Risposte corrette):
Gestione 4. Applicazione
Domanda
Quali sono le funzioni parziali all'interno di IT Operations Management?
Opzioni:
1. IT Operations Control
2. Gestione delle strutture
3. Ciclo di vita Integrazione
4. Gestione della sicurezza
Risposta
Opzione 1: Corretto. IT Operations Control una funzione parziale di IT Operations
Management. Assicura che i compiti operativi di routine vengono effettuati.
117
Opzione 2: Corretto. Facilities Management una funzione parziale di IT Operations

Management. Essa implica la gestione di servizi informatici, come sale server e data center.
Opzione 3: non corretto. IT Operations Management lavora per assicurare che le attivit IT
quotidiane e le procedure siano effettuate in modo efficace - non tenta di integrare i vari cicli
di vita di gestione dei servizi.
Opzione 4: non corretto. Gestione delle attivit di sicurezza l'ampia responsabilit di IT
Operations Control, piuttosto che una delle sue sottofunzioni.
Risposte corrette):
1. IT Operations di controllo
2. Gestione delle strutture
4. Impostazione di un service desk
La funzione di service desk il punto principale degli utenti di contatto. Il suo scopo quello di
risolvere i problemi di assistenza pi rapidamente ed efficacemente possibile per garantire che gli
utenti o clienti sono in grado di continuare il loro lavoro nel soddisfare gli obiettivi di business.
Domanda
La vostra organizzazione IT ha due rami - uno a New York e l'altro in
Thailandia. L'organizzazione sta progettando una struttura di service desk per i suoi rami. Si
deve garantire che il personale di service desk disponibile durante l'orario di lavoro per
supportare i clienti che utilizzano i loro servizi IT. Sulla base di questo scenario, quale servizio
struttura scrivania dovrebbe utilizzare l'organizzazione?
Opzioni:
1. service desk locale
3. service desk virtuale
4. Follow-the-sun service desk
Risposta
Opzione 1: Corretto. Ci dovrebbe essere un banco di servizio locale in Thailandia e un altro a
New York per soddisfare i clienti con diverse lingue e culture, e in fusi orari diversi. Non
necessario a questo punto per mantenere il service desk operativo dopo ore di ufficio in ogni
posizione.
Opzione 2: non corretto. Una scrivania servizio centralizzato non appropriato in questa
situazione perch il personale ha bisogno per soddisfare i clienti con due culture e lingue
diverse e di lavorare in due fusi orari diversi.
Opzione 3: non corretto. Anche se due service desk virtuali - uno in Thailandia e l'altro a New
York - possono funzionare, ma non la soluzione migliore. Dato che necessario il supporto
di service desk solo durante le ore di ufficio, service desk locali incoraggiano il lavoro di
squadra e garantire che le risorse si trovano nelle vicinanze utenti interessati.
Opzione 4: non corretto. I banchi di servizio in entrambe le posizioni devono essere
disponibili solo in orario d'ufficio. Una struttura di follow-the-sun necessaria solo se il
supporto di service desk deve essere fornito di fuori del normale orario di lavoro in posizioni
particolari.
Risposte corrette):
118
1. scrivania Servizio locale

I ruoli e gli obiettivi delle funzioni di servizio di funzionamento e le modalit per selezionare una
struttura di service desk e personale in modo appropriato sono stati identificati.
5. Sommario
| Inizio pagina |
| 2. Riconoscendo le operazioni di servizio |
| 3. La creazione di un service desk |
119
L'area ei principi di gestione degli incidenti

individuare l'ambito di Incident Management
descrivere i principi di base della gestione degli incidenti

2. Campo di applicazione 1. Incident Management
Nel ITIL Service Lifecycle, la fase di Service Operation comprende cinque processi. Uno di questi
Incident Management.
Grafico
Il ITIL Service Lifecycle contiene la strategia di servizio, servizio, design, servizio di
transizione, il funzionamento del servizio, e Continual Service Improvement fasi. I cinque
processi della fase di Service Operation sono Availability Management, Capacity
Management, Financial Management, Problem Management e Incident Management.
Nella terminologia ITIL, un incidente definito come un'interruzione non pianificata o riduzione, la
qualit di un servizio IT.
Un incidente pu anche includere un guasto Elemento di configurazione (CI), se il servizio viene
interrotto.
Incident Management il processo per la gestione dei cicli di vita di tutti gli incidenti.
Si pu essere avvisati in caso di incidenti in modi diversi:
attraverso rapporti da personale tecnico
come conseguenza dell'uso di strumenti di monitoraggio evento
a seguito di comunicazione degli utenti con il personale del service desk, o
attraverso relazioni da parte di fornitori o partner commerciali
Efficiente Incident Management ha chiaro

scopo, e
Lo scopo della Incident Management quello di garantire che i servizi IT sono forniti ai
livelli concordati in un Service Level Agreement (SLA). Il focus di Incident Management il
mantenimento o il ripristino del servizio in caso di un incidente, e ridurre al minimo gli effetti
negativi di eventuali interruzioni sui clienti, utenti e le operazioni di business.
obiettivi
Gli obiettivi di Incident Management sono per assicurare la standardizzazione in risposta
agli incidenti, reporting, analisi e documentazione. Dovrebbe aumentare la visibilit e la
comunicazione degli incidenti per le imprese e personale di supporto IT. Si dovrebbe anche
concentrarsi su un ritratto positivo dei servizi IT in un contesto di business attraverso la
risposta agli incidenti efficace e di comunicazione, mantenendo la soddisfazione degli utenti
attraverso le buone qualit dei servizi IT e allineare tutte le attivit di gestione degli incidenti
con gli obiettivi organizzativi e delle priorit.
120
interruzioni di servizio sono spesso comunicati direttamente dagli utenti, sia attraverso il service
desk o Incident Management di reporting o di monitoraggio strumenti.
politica di gestione degli incidenti di un'organizzazione dovrebbe specificare come gli utenti
possono segnalare gli incidenti.
Si deve anche specificare come staff tecnico dovrebbe riferire, registrare e rispondere agli
incidenti.
E 'importante distinguere tra incidenti segnalati e le richieste di servizio regolare. Le richieste di
servizio vengono registrati come incidenti, ma raramente provocano alcun tipo di interruzione del
servizio.
Ad esempio, un utente pu rivolgersi a un service desk IT per una richiesta di reimpostazione della
password o con una richiesta di modifica account. Questi sono esempi di una richiesta di servizio
piuttosto che un incidente perch, anche se l'evento Inconvenienti l'utente, non provoca
l'interruzione del servizio n impatto altri utenti.
Un esempio di un incidente sarebbe un numero di utenti segnalazione impossibilit di connettersi
alla rete aziendale. servizi IT per quegli utenti viene interrotta, e il service desk deve attuare misure
per risolvere i problemi di connessione.
Domanda
Quali esempi rientrano nell'ambito di applicazione di Incident Management?
Opzioni:
1. Un utente di rete segnala un infezione da malware
2. Un gestore di ufficio richiede un livello superiore di accesso a una risorsa sulla rete
locale di un'azienda
3. Uno sbalzo di tensione danni di alimentazione di un server e interrompe l'accesso
alla rete
4. Un dipendente dimentica una password e chiama il service desk per ripristinarlo
5. Un router di rete mal configurato viene scoperto e registrato da un amministratore di
rete
Risposta
Opzione 1: Corretto. Una infezione da malware pu causare un'interruzione o
deterioramento del servizio IT, e quindi costituisce un incidente. Dovrebbe essere gestita
attraverso un processo di gestione degli incidenti stabilita.
Opzione 2: non corretto. Questo un esempio di una richiesta di servizio piuttosto che un
incidente. Anche se pu essere comunicata tramite un servizio IT o help desk, non si riferisce
ad una interruzione del servizio.
Opzione 3: Corretto. Qualsiasi evento che si traduce in un'interruzione di normali servizi
costituisce un incidente e deve essere affrontato attraverso una corretta gestione degli
incidenti.
Opzione 4: non corretto. Dimenticare una password potrebbe disagi un dipendente, ma
questo non si traduce in una pi ampia interruzione del servizio e quindi non costituisce un
incidente.
Opzione 5: Corretto. Un router di rete configurato male potrebbe causare un'interruzione di
servizio IT e cos costituisce un incidente. Si dovrebbe quindi essere gestito attraverso una
corretta gestione degli incidenti.
121
Risposte corrette):
1. Un utente della rete segnala un infezione da malware
3. Uno sbalzo di tensione danni di alimentazione di un server e interrompe l'accesso alla
rete
5. Un router di rete mal configurato viene scoperto e registrato da un amministratore di
rete
3. Principi Incident Management
processo di ciascuna organizzazione per la gestione di incidenti pu variare a seconda delle
esigenze e delle circostanze dell'organizzazione. Tuttavia, importante applicare alcuni principi
generali per Incident Management per essere efficace.
Questi principi includono
tempi di impostazione per la risposta agli incidenti
Incident Management dovrebbe impostare tempi e gli obiettivi ragionevoli per la gestione di
incidenti. Questi sono tipicamente specificati negli SLA, e dovrebbero riflettere gli obiettivi
fissati negli accordi sul livello operativo (OLA) e dei contratti sottostanti (UCS).
la creazione di modelli di incidenti
Molti tipi di incidenti tendono a ripresentarsi, quindi generalmente utile per definire modelli
di incidenti e applicarli agli incidenti rilevanti quando si verificano.
pianificazione di risposte speciale a incidenti gravi
Ci dovrebbe essere un modello o una serie di passaggi per affrontare i principali incidenti
specifici. Un'organizzazione pu definire ci che costituisce un grave incidente, anche se in
genere si tratta di un incidente che interrompe i servizi critici e richiede molto tempo per
riparare.
il monitoraggio dello stato incidente, e
il monitoraggio dello stato degli incidenti segue ogni incidente attraverso le fasi del ciclo di
vita utilizzando i codici di stato. Questo mantiene l'efficienza nei processi di gestione e di
segnalazione.
dividendo il ciclo di vita incidente in fasi di chiara
E 'utile per dividere il ciclo di vita di ogni incidente in diverse fasi, tra cui la rilevazione, la
diagnosi, la riparazione, il recupero, e il restauro. Ci pu risultare in una migliore
comprensione e gestione di un incidente.
Uno SLA pu stabilire un calendario per il completamento di ogni fase del processo di Incident
Management.
In alternativa, un processo automatizzato pu essere utilizzato per stabilire tempi appropriati per
risposta agli incidenti. Questo pu anche aiutare a determinare la gravit di un incidente, e se
aumentata di gravit in quanto prima di essere rilevato.
Tutto IT dipendenti e personale di supporto devono essere consapevoli dei tempi concordati e
rispondere di conseguenza quando si tratta di incidenti. Ad esempio, si dovrebbe sapere quali tipi
di incidenti di priorit.
Un modello incidente definisce le misure che dovrebbero essere adottate per affrontare qualsiasi
incidente che corrisponde al modello.
122
Questo aiuta a garantire che gli incidenti standard sono gestite in modo standardizzato, e in tempi
predefiniti.
Un modello incidente pu essere utile anche per la gestione di incidenti che richiedono una
gestione specializzata. Ad esempio, pu delineare passi per identificare la natura degli incidenti e
per riorientare quelli che richiedono un trattamento speciale per le persone o servizi competenti.
Ogni modello incidente dovrebbe includere informazioni specifiche:
i passaggi necessari per la gestione di un incidente del tipo in questione
l'ordine dei passaggi necessari, compresi eventuali compiti aggiuntivi
i dipendenti designati o le unit responsabili di ogni fase
tutte le precauzioni - come ad esempio realizzare backup o attuazione di altre misure di

sicurezza - che dovrebbero essere prese prima di applicare le misure previste sono implementati
tempi e le soglie per il completamento delle operazioni
a chi rivolgersi se un incidente richiede escalation, e
tutte le misure necessarie per raccogliere e fissare le prove per l'uso, se si interviene legale
Domanda
Quali sono le informazioni di un modello incidente dovrebbe includere?
Opzioni:
1. Un elenco di passaggi per incidenti di gestione
2. Un elenco di precauzioni da prendere prima che la squadra di Incident Management
inizia trattare con l'incidente
3. Informazioni sulle cause degli incidenti rilevanti
4. Un documento aggiornamento di stato inviato per l'utente o persona che inizialmente
ha comunicato l'incidente
5. I dati di contatto della persona o delle persone da notificare se l'incidente peggiora o
modifiche
Risposta
Opzione 1: Corretto. Un modello incidente voglia dettaglio i passi per trattare con un tipo
specificato di incidente, come pure l'ordine di questi passi.
Opzione 2: Corretto. Un modello incidente dovrebbe specificare tutte le precauzioni che
devono essere prese prima che le misure per far fronte a un incidente sono iniziati.
Opzione 3: non corretto. Un modello incidente potrebbe gruppi vari incidenti in base alle loro
sintomi, ma le cause di questi incidenti potrebbe essere diverso.
Opzione 4: non corretto. Un modello incidente definito prima di incidenti si verifichino in
realt per specificare come questi incidenti dovrebbero essere risolti. Un aggiornamento
sarebbe stata inviata ad un utente solo dopo che si verificato un incidente reale e ha
ricevuto una risposta.
Opzione 5: Corretto. Un modello incidente dovrebbe specificare a chi rivolgersi se un
incidente del tipo in questione si aggravi.
Risposte corrette):
123
1. Un elenco di misure per la gestione di incidenti

2. Un elenco di precauzioni da prendere prima che la squadra di Incident Management
inizia trattare con l'incidente
5. I dati di contatto della persona o delle persone da notificare se l'incidente peggiora o
modifiche
Un piano per rispondere a un incidente grave pu identificare un team dedicato in grado di fornire il
tempo e le risorse necessarie per attuare una rapida risoluzione.
Una distinzione deve essere fatta tra la persona che gestisce un grave incidente e il direttore
generale incidente.
Questo assicura che altri, meno gravi incidenti non sono trascurati, mentre i principali incidenti
ricevono sufficiente attenzione.
Monitoraggio incidente aiuta a garantire che gli incidenti non sono trascurati in qualsiasi punto del
loro ciclo di vita, e che i responsabili della gestione incidenti possono dare la priorit le risorse in
modo appropriato. Alcuni degli incidenti comuni codici di monitoraggio di stato includono
aperti, incidenti per scoperti di recente
in corso, per gli incidenti che sono stati assegnati e sono attualmente in corso di esame
ha deliberato, per gli incidenti che sono stati risolti, ma prima di regolare servizio viene
ripresa, o
chiusa, per una volta il servizio regolare ha ripreso
Domanda
Stai recensendo processo di Incident Management dell'organizzazione al fine di migliorarne
l'efficacia. Quali principi si dovrebbe applicare?
Opzioni:
1. Stabilire tempi appropriati per risolvere gli incidenti
2. Tenere traccia dello stato dell'incidente attraverso ogni fase del ciclo di vita del
incidente
3. Stabilire un team di gestione dedicato incidente a che fare con ogni incidente,
indipendentemente dalle dimensioni
4. Creare una collezione di modelli incidente con fasi di manipolazione incidente
predefinite per ciascuno di essi
5. Creare un modello analitico che prende in esame ogni incidente nel suo complesso
per capire meglio
Risposta
Opzione 1: Corretto. Si dovrebbe includere un lasso di tempo che denota il periodo
consigliato per affrontare ogni fase del ciclo di vita dell'incidente in ogni politica di Incident
Management. Questi periodi devono essere allineati con SLA.
Opzione 2: Corretto. Processi di Incident Management dovrebbero comprendere il
monitoraggio dello stato incidente per ottimizzare la gestione e reporting per ogni fase
efficiente. Questi possono include codici di stato per ogni fase del ciclo di vita incidente.
Opzione 3: non corretto. E 'buona norma creare un team dedicato di trattare solo con i
principali incidenti. Regolari i dipendenti di supporto IT possono fare con incidenti minori.
124
Opzione 4: Corretto. Efficace Incident Management si basa sull'utilizzo di modelli di incidenti,

che specificano modi standard di rispondere alle pi comuni tipi di incidenti.
Opzione 5: non corretto. Efficace Incident Management esamina gli incidenti in dettaglio
visualizzando il ciclo di vita incidente espanso. Questo rompe ogni incidente in sezioni da
analizzare al fine di massimizzare l'efficacia dell'azione risoluzione.
Risposte corrette):
1. Stabilire tempi adeguati per la risoluzione di incidenti
2. Tenere traccia dello stato dell'incidente attraverso ogni fase del ciclo di vita del
incidente
4. Creare una collezione di modelli incidente con fasi di manipolazione incidente
predefinite per ciascuno di essi
4. Riepilogo
Incident Management uno dei processi in fase di Service Operation. Il suo scopo quello di
prevenire o ridurre al minimo le interruzioni del servizio o il degrado della qualit del servizio che gli
incidenti causano. Per Incident Management per essere efficace, si dovrebbe definire tempi
accettabili per la risoluzione degli incidenti, utilizzare modelli incidente per definire i passi per
risolvere comuni tipi di incidenti, e il piano specializzata risposte per incidenti di rilievo. E 'anche
importante per monitorare lo stato degli incidenti in tutto il loro ciclo di vita e di dividere i cicli di vita
incidente in fasi appropriate.
5. Sommario
| Inizio pagina |
| 1. Incident Management portata |
| 2. Principi Incident Management |
| Sommario |
125
Il processo di gestione degli incidenti

individuare le attivit del processo di Incident Management

2. identificazione e la registrazione degli incidenti
Efficace Incident Management aiuta a garantire che un fornitore di servizi IT in grado di fornire
servizi ai livelli descritti in un Service Level Agreement (SLA).
Lo fa ripristinando il normale servizio il pi rapidamente possibile dopo il verificarsi incidenti e
ridurre al minimo gli eventuali impatti che provocano.
Il processo di Incident Management include una sequenza definita di passaggi:
1.
identificazione incidente
2.
registrazione incidente
3.
incidente categorizzazione
4.
incidente priorit
5.
diagnosi iniziale
6.
incidente escalation
7.
indagine e diagnosi
8.
risoluzione e recupero, e
9.
chiusura incidente e, se necessario, incidenti riapertura
Il primo passo identificare un incidente quando si verifica. Questo pu accadere solo quando un
utente contatti il service desk IT con un problema.
Grafico
Il primo passo del processo di gestione degli incidenti evidenziato: l'identificazione degli
incidenti.
Tuttavia, meglio se si pu individuare gli episodi prima di creare disturbo agli utenti, anzich solo
una volta i servizi sono stati notevolmente perturbato.
Per identificare la natura di un incidente, il personale di servizio scrivania o altro personale IT
possono mettere in discussione gli utenti interessati. Essi possono anche eseguire test diagnostici
a distanza.
Una volta identificato un incidente, importante iniziare la registrazione incidente - che poi
continua per tutto il ciclo di vita dell'incidente.
Grafico
La seconda fase del processo di gestione degli incidenti evidenziato: la registrazione degli
incidenti.
Si dovrebbe registrare le informazioni su ogni incidente di
Grafico
126
Alcune delle voci in un modulo di registrazione incidente sono il numero di riferimento,

incidente categorizzazione, incidente urgenza, impatto incidente, incidente priorit, data / ora
registrata, incidente la registrazione dei dipendenti, il metodo di comunicazione, riportando
reparto di utente, call-back metodo, descrizione dei sintomi , lo stato di incidente, legati CI,
gruppo di sostegno, legati problema noto errore /, le attivit di risoluzione, la data e l'ora
risoluzione, categoria di chiusura e la data di chiusura e l'ora.
categoria e l'impatto
In un registro, necessario assegnare ogni incidente un numero di riferimento unico per
scopi di monitoraggio. Si dovrebbe anche individuare sua categoria, l'urgenza di risolvere
l'incidente, il suo impatto sugli utenti, e il suo livello di priorit. Il modo in cui classificare un
incidente dipender dal sistema dell'organizzazione per fare questo. Categorie di alto livello
possono essere suddivisi in sotto-categorie.
La sezione di categoria e l'impatto contiene un numero di riferimento, incidente

categorizzazione, incidente urgenza, impatto incidente e incidente priorit.
la natura e la presenza, e
Nel registro, necessario includere informazioni quali la data e l'ora dell'incidente stato
registrato, il nome o l'ID della registrazione dell'incidente, come stato identificato
l'incidente dei dipendenti, e le informazioni di contatto per il reparto a cui l'utente che ha
riportato il incidente appartiene. Si dovrebbe anche includere una descrizione dei sintomi,
lo stato di incidente, relativi elementi di configurazione (CI), e il gruppo di supporto
responsabile della risoluzione l'incidente.
La sezione natura e la presenza contiene data / ora registrata, incidente la registrazione
dei dipendenti, il metodo di notifica, la segnalazione dipartimento di utente, call-back il
metodo, la descrizione dei sintomi, stato di incidente, in relazione CI, e gruppo di sostegno.
risoluzione
Una volta che un incidente stato risolto, necessario aggiornare il registro con gli
eventuali problemi connessi o errori noti associati con l'incidente, le attivit intraprese per
risolvere l'incidente, la data e il tempo di risoluzione, la categoria incidente aggiornato, e la
data e l'ora di chiusura.
la sezione di risoluzione registra qualsiasi problema correlato / errore noto, le attivit di
risoluzione, la data e tempi di risoluzione, categoria chiusura, e la data e l'ora di chiusura.
Se un service desk non funziona 24 ore al giorno, altri gruppi, come quelli coinvolti nei processi
operativi IT o il supporto di rete, pu accedere incidenti di fuori degli orari di service desk.
Come vengono prese ulteriori azioni per risolvere un incidente, il registro incidente deve essere
aggiornato in modo tale che una storia completa mantenuta.
Ad esempio, questo potrebbe includere cambiando la categorizzazione o la priorit di incidente
sulla base dei risultati di ulteriori attivit di diagnosi o di escalation.
3. categorizzazione e prioritizzazione
Durante la registrazione incidente iniziale, importante classificare gli incidenti in base al loro tipo.
Grafico
La terza fase del processo di gestione degli incidenti evidenziato: Incidente
categorizzazione.
127
Diverse organizzazioni definiscono le categorie di incidenti in modo diverso a seconda delle loro
esigenze. Tuttavia, importante per le organizzazioni di sviluppare e utilizzare un insieme
standard di codici a questo scopo.
Per sviluppare un insieme appropriato di categorie di incidenti, possibile
condurre una sessione di brainstorming
possibile includere membri di importanti gruppi di supporto IT in una sessione di
brainstorming, con l'obiettivo di generare adeguati categorie di livello superiore.E 'meglio
basare queste categorie su come incidenti possono influenzare i clienti e gli utenti. Il
gruppo pu quindi restringere i categorie proposte per identificare quelli che sono pi
appropriate.
utilizzare le categorie di prova, e
Dopo aver definito una prima serie di categorie di incidenti, necessario utilizzare questi
per un periodo di prova. Questo periodo dovrebbe essere abbastanza a lungo per un
numero sufficiente di incidenti si verifichi per testare l'utilizzabilit delle categorie. Il numero
di incidenti registrati in ciascuna delle categorie di livello superiore confermer se siano
necessarie le categorie. L'analisi degli incidenti che non rientrano in alcuna delle categorie
dovrebbe aiutare a identificare altre eventuali categorie di livello superiore da
aggiungere. Un'analisi ripartizione di ogni categoria pu aiutare a determinare le categorie
di livello inferiore richiesti.
rivedere e regolare le categorie
Si dovrebbe rivedere le categorie in uso e regolare, se necessario, dopo un ulteriore
periodo di uno a tre mesi. Essere consapevoli del fatto che ogni variazione significativa
categorie possono complicare il processo di identificazione delle tendenze degli incidenti e
di creare report di gestione. Cos, dopo le regolazioni iniziali, le categorie devono essere
mantenuti stabili a meno che non siano realmente necessarie modifiche.
E 'comune per classificare gli incidenti a pi livelli - di solito per tre o quattro livelli di granularit. Ad
esempio, un incidente pu essere classificato in base alla posizione, servizio, il sistema, e
l'applicazione colpisce.
Vale la pena notare che a volte i dettagli disponibili al momento un incidente viene registrato
possono essere incomplete, fuorvianti o inesatte.
Quindi importante che la qualificazione di un incidente viene controllato e aggiornato, se
necessario.
Grafico
A titolo di esempio, un incidente viene classificato come aver avuto un impatto cinque
terminali (posizione), la posta elettronica e Internet Service, la rete (di sistema), e il software
di gestione server di posta elettronica (applicazione).
Un altro aspetto importante di registrazione incidente quello di assegnare un codice di priorit
adeguata. Questo determiner come l'incidente ha la priorit.
Grafico
La quarta fase del processo di gestione degli incidenti evidenziato: Incidente priorit.
In qualit di fornitore di servizi IT, necessario determinare un sistema di codifica di priorit ed
essere sicuri tutto il personale sono chiare sui criteri associati.
Grafico
128
Come esempio di un sistema di codifica di priorit, un incidente viene assegnato un

punteggio urgenza e una valutazione di impatto di alta, media o bassa, rispettivamente. Un
incidente con un alto urgenza e l'impatto un 1. Un incidente con elevata urgenza e impatto
medio, o medio urgenza e ad alto impatto, un 2. Un incidente con bassa urgenza e ad alto
impatto, di media urgenza e l'impatto, o e alta urgenza e basso impatto un 3. un incidente
con urgenza e medio basso impatto, o bassa urgenza e impatto medio, un 4. un incidente
con low urgenza e basso impatto un 5.
si d anche un elenco di codici di priorit con corrispondenti descrizioni e tempi di risoluzione
di destinazione. 1 critico con un tempo di risoluzione di destinazione un'ora.2 alto con un
tempo di 8 ore risoluzione di destinazione. 3 media con un tempo di 24 ore risoluzione di
destinazione. 4 bassa con un tempo di 48 ore risoluzione di destinazione. 5
contrassegnato come la pianificazione, con un tempo di risoluzione di destinazione indicata
come "previsto".
Per determinare la priorit di un incidente, si prende la sua urgenza e il livello di impatto sul
business in considerazione. Un'indicazione di impatto spesso il numero di utenti essere colpiti,
anche se un singolo utente interessato la chiave per le imprese, le conseguenze possono essere
altrettanto disastrosa come un incidente che gli impatti molti utenti.
Altri fattori che contribuiscono a determinare l'impatto di un incidente includono rischio fisico, il
numero di servizi interessati, potenziali perdite finanziarie, potenziali danni alla reputazione di
business di un'organizzazione, e le implicazioni legali.
Ci sono anche casi in cui il sistema di priorit normale viene scavalcata, a causa di una richiesta
dell'utente o specifico impatto su un business.
Ad esempio, pu essere opportuno assegnare l'arresto di un'applicazione che impedisce agli utenti
interessati di eseguire tutte le funzioni di lavoro di un codice di priorit 2, in cui il codice indica
priorit elevata.
In questo caso, il codice di priorit associata a un tempo di risoluzione bersaglio di 8 ore. Quindi
questo il tempo entro il quale un team dovrebbe risolvere l'incidente.
Domanda
Come l'analista service desk a un provider di servizi IT, si riceve un report da un utente che la
sua e-mail non riesce a trasmettere.
Sequenziare il primi quattro fasi del processo di Incident Management.
Opzioni:
A. Porre le domande degli utenti di identificare correttamente il problema di posta
elettronica come un incidente
B. Iniziare i dettagli di registrazione dell'incidente e-mail sul modulo dipartimentale
Incident Management
C. Categorizzare l'incidente come interrompere il servizio per l'utente, e che colpisce
computer dell'utente
D. Assegnare l'incidente un punteggio di priorit di 3, dato il suo impatto moderato
Risposta
Risposte corrette):
Porre le domande degli utenti di identificare correttamente il problema di posta elettronica come un
incidente viene classificato
129
Quando il service desk riceve la notifica di un evento che colpisce un utente, identificato
come un incidente, e il processo di Incident Management pu iniziare.
Iniziare la registrazione dettagli dell'incidente e-mail sul modulo dipartimentale Incident
Management classificato
Una volta che l'evento identificato come un incidente, la registrazione di tutte le
informazioni pertinenti incidente pu iniziare come parte della seconda fase.
Categorizzare l'incidente come interrompere il servizio per l'utente, e che colpisce il computer
dell'utente classificato
Incidente categorizzazione il terzo passo. L'incidente verr classificato dal quale
posizione, il servizio, il sistema, o di applicazione ha un impatto.
Assegnare l'incidente un punteggio di priorit di 3, dato il suo impatto moderato classificato
Durante la quarta fase, l'incidente viene assegnato un codice di priorit in base alla gravit
dell'impatto. Il codice di priorit suggerisce un tempo consigliato risoluzione degli incidenti.
4. La diagnosi, escalation, e le indagini
Ogni incidente pu essere soggetto a due possibili diagnosi - una diagnosi iniziale quando in
primo luogo segnalato e una seconda diagnosi se l'incidente richiede ulteriori indagini.
Grafico
La quinta fase del processo di gestione degli incidenti evidenziato: la diagnosi iniziale.
Quando un utente segnala inizialmente un incidente a un service desk, un analista di Service Desk
tenta di diagnosticare l'incidente, chiedendo domande pertinenti. L'analista pu quindi utilizzare il
software e le informazioni attualmente disponibili per risolvere immediatamente l'incidente.
Se l'incidente non pu essere risolto immediatamente, l'analista dovrebbe informare l'utente. Pu
anche essere opportuno dare all'utente un numero di riferimento incidente, che tipicamente
generato da applicazioni di log incidente elettroniche.
Quando un utente segnala prima di un possibile crash dell'applicazione, per esempio, un analista
di Service Desk chiede alle domande degli utenti per cercare di determinare la causa e la natura
dell'incidente.
L'analista di Service Desk esegue test di diagnostica remota sul computer dell'utente e scopre
possibile instabilit del sistema operativo. L'analista non pu gestire l'incidente dalla scrivania di
servizio, in modo che il personale di supporto adeguato vengono notificati.
Alcuni tipi di incidenti si verificano regolarmente, in modo che le azioni di risoluzione appropriate
per questi incidenti sono in genere noti. Tuttavia, importante seguire una procedura per la
corrispondenza dei dati di un incidente alla classificazione appropriata.
abbinamento di successo far in modo che la risposta ad un incidente adeguato ed efficace. Si
riduce al minimo la necessit di escalation.
Quando diventa evidente che il service desk in grado di risolvere l'incidente, l'incidente deve
essere intensificato immediatamente per ulteriore supporto. Tipi di escalation includono
Grafico
La sesta fase del processo di gestione degli incidenti evidenziato: Incidente escalation.
escalation funzionale, e
130
escalation funzionale si verifica quando un incidente un'escalation di un livello alla

volta. Se il service desk non pu risolvere l'incidente, intensificato al successivo gruppo di
supporto del caso, come ad esempio un gruppo di supporto di livello 2. Se questo gruppo,
inoltre, non in grado di risolvere l'incidente, intensificato a monte della catena di
supporto. Alcuni incidenti pu essere aumentata a pi gruppi di supporto, o anche a terzi,
come ad esempio i fornitori di software o produttori di hardware.
escalation gerarchica
Nel caso di escalation gerarchica, un incidente viene trasferita direttamente a un livello
superiore all'interno dell'organizzazione, come il successivo livello di gestione, ad esempio,
in modo che riceva l'immediato intervento di una persona appropriata con autorit
necessaria. Escalation gerarchica usato anche se la procedura di indagine, diagnosi e
risoluzione e di recupero stanno prendendo troppo tempo. Escalation gerarchica dovrebbe
continuare la catena di gestione, se necessario in modo che il personale di gestione
appropriate possono approvare o azioni necessarie diretta, come ad esempio
assegnazione di risorse supplementari o che coinvolgono fornitori per risolvere l'incidente.
Se un incidente intensificato, si passer attraverso una seconda fase di indagine e di diagnosi.
Grafico
La settima fase del processo di gestione degli incidenti evidenziato: ricerca e diagnosi.
Le azioni intraprese a questo punto, con dettagli di eventuali azioni intraprese per cercare di
risolvere o ri-creare l'incidente, devono essere interamente documentate nel registro incidente per
assicurarsi che fornisce una storia completa incidente.
Ove possibile, ricerca e diagnosi devono essere eseguiti in parallelo per ridurre il tempo
complessivo necessario per risolvere un incidente. Strumenti di supporto devono essere progettati
o selezionati per permettere che questo il pi possibile. Indagare un incidente rischia di
coinvolgere
stabilire esattamente cosa andato storto o si intende ottenere da parte dell'utente
determinare l'ordine cronologico degli eventi che si sono verificati
confermando il pieno impatto dell'incidente, incluso il numero e la gamma di utenti colpiti
individuare eventuali eventi che potrebbero aver innescato l'incidente, e
ricerca record incidente o database errore noto per conoscenza acquisita a seguito di
incidenti simili
Il gruppo di sostegno, indagare il crash dell'applicazione, esegue test sui sistemi interessati e
determina un potenziale risoluzione che coinvolge il riavvio di un server.L'indagine del gruppo
rivela che l'incidente iniziale era il risultato di un riavvio automatico fallito.
Domanda
Come un analista IT Service Desk, hai gi identificato, l'accesso, classificati, e la priorit
l'incapacit di un utente per inviare e-mail. Sequenza successivi tre fasi del processo di
Opzioni:
131
A. Il tentativo di trovare la ragione del fallimento di e-mail al momento del rapporto

iniziale
B. Riferendosi alla questione e-mail ad un team di supporto IT dedicato, con
l'esperienza necessaria per diagnosticare e risolvere l'incidente
C. Cercando database errore noto per motivi per cui l'e-mail pu essere non riuscendo
a trasmettere
Risposta
Risposte corrette):
Il tentativo di trovare la ragione del fallimento di e-mail al momento del rapporto iniziale
classificato
La quinta fase del processo di Incident Management - una volta che l'incidente stato
identificato, il login, per categoria e priorit, quello di eseguire una diagnosi iniziale per
scoprire il motivo per l'incidente.
Riferendosi alla questione e-mail ad un team di supporto IT dedicato, con l'esperienza necessaria
per diagnosticare e risolvere l'incidente classificato
L'incidente intensificato nel sesto passaggio se si, come l'analista service desk, non pu
risolverlo.
Cercando database errore noto per motivi per cui l'e-mail pu non riuscire a trasmettere
classificato
La fase di indagine e la diagnosi del processo di Incident Management il settimo passo, e
si verifica dopo l'incidente stato intensificato.
5. Risoluzione, chiusura e riapertura
Una volta che un potenziale risoluzione ad un incidente stato identificato, deve essere applicato
e testato.
Grafico
L'ottava fase del processo di gestione degli incidenti evidenziato: Risoluzione e recupero.
Diverse persone possono essere coinvolte in misure per risolvere un incidente di
attuazione. Questi includono
utenti
Si pu chiedere agli utenti di eseguire determinate attivit sulle proprie stazioni di lavoro o
apparecchiature remote per aiutare a risolvere un incidente. Per esempio, si pu chiedere a
un utente di eseguire una scansione antivirus.
personale di servizio scrivania
Servizio personale della reception possono usare metodi centrali, come il riavvio di un
server, per contribuire a risolvere un incidente. Essi possono anche affrontare incidenti a
distanza, ad esempio utilizzando il software per prendere il controllo del desktop di un
utente e attuare una risoluzione.
membri di gruppi di sostegno, e
132
Si pu chiedere gruppi di sostegno specializzati per attuare azioni di recupero

specifiche. Per esempio, si potrebbe chiedere un lavoro di gruppo di terze parti per
riconfigurare un router per mantenere la stabilit della rete.
fornitori di terze parti
Pu essere opportuno chiedere a un prestatore di servizi di terze parti per risolvere un
incidente. Ad esempio, si potrebbe chiedere un fornitore di sostituire una configurazione
errata su un router che sta causando il fallimento della rete.
Se pi gruppi di sostegno sono coinvolti in applicazione di una risoluzione, importante coordinare
le loro attivit e mantenere i contatti con tutte le parti coinvolte.
Il gruppo di supporto IT dedicato, ad esempio, implementa la risoluzione proposta di utilizzare il
software per riparare il sistema operativo, Registro di sistema e software di posta elettronica sul
computer dell'utente.
Con un incidente come un sistema operativo danneggiato, il gruppo deve quindi testare
ripetutamente il computer per verificare che l'incidente stato risolto con successo e servizio
ripristinato.
Dopo l'incidente stato risolto, pu essere chiuso.
Grafico
La nona fase del processo di gestione degli incidenti evidenziato: Incidente chiusura /
riapertura.
Come parte della fase di chiusura, il servizio personale della reception dovrebbe confermare che
la categorizzazione incidente iniziale era corretta
Per garantire che un record incidente preciso mantenuta, si dovrebbe confermare che la
qualificazione iniziale del l'incidente stato corretto - e aggiornare, se necessario. Si pu
chiedere consiglio o guida da eventuali individui o gruppi direttamente coinvolti nella
risoluzione l'incidente, se necessario.
gli utenti sono soddisfatti con la risoluzione
possibile chiamare gli utenti, o utilizzare uno strumento come un sondaggio e-mail, per
verificare che gli utenti sono soddisfatti con la risoluzione che stata applicata.
la documentazione stata aggiornata, e
importante garantire che la documentazione incidente completa e completamente
aggiornato.
causa principale del incidente stato risolto
Se la causa principale di un incidente non stato affrontato, possibile l'incidente si
ripeta. Se la causa principale non stato identificato con successo o non pu essere
risolto, necessario determinare se un record problema relativo al l'incidente gi stato
sollevato. In caso contrario, sollevare un nuovo record di problema in concomitanza con il
processo di gestione dei problemi in modo che venga avviata un'azione preventiva.
Alcune organizzazioni scelgono di applicare un periodo di chiusura automatica per specifici
incidenti, o anche tutti,. Ad esempio, la politica di un'organizzazione pu specificare che ogni
incidente sar chiusa dopo due giorni, se non si sono verificati ulteriori contatti dell'utente.
133
Indipendentemente dalla durata, possibile chiudere formalmente un incidente una volta che sei
certo stato completamente affrontato e non deve ripetersi.
Anche con una gestione adeguata, ci saranno occasioni in cui gli incidenti si ripetono nonostante
sia chiuso. La decisione pu quindi essere fatto per riaprire l'incidente - la fase finale facoltativa del
processo di Incident Management.
E 'consigliabile avere regole predefinite su se e quando un incidente pu essere riaperto.
Si potrebbe avere un senso, per esempio, ad accettare che se un incidente si ripresenta entro un
giorno lavorativo di essere chiuso, pu essere riaperto - ma oltre questo punto, un nuovo incidente
deve essere connesso, ma legato al precedente incidente.
Domanda
esempi sequenza delle fasi finali del processo di gestione degli incidenti per l'esempio del
utente che non pu inviare e-mail.
Opzioni:
A. Esecuzione di test sul computer dell'utente per scoprire un problema con il sistema
operativo
B. In seguito ai risultati delle indagini e diagnosi il team di supporto esegue il software
per riparare un sistema operativo danneggiato
C. Si accede l'incidente come chiuso una volta che avete feedback da parte del team di
supporto e l'utente
Risposta
Risposte corrette):
Esecuzione di test sul computer dell'utente per scoprire un problema con il sistema operativo
classificato
La settima fase del processo di Incident Management quello di indagare e, allo stesso
tempo, diagnosticare l'incidente.
In seguito ai risultati delle indagini e la diagnosi del team di supporto esegue il software per
riparare un sistema operativo danneggiato classificato
La fase di risoluzione degli incidenti segue la fase di indagine e di diagnosi, l'ottavo passo.
Si accede l'incidente come chiuso una volta che avete feedback da parte del team di supporto e
l'utente classificato
Una volta che l'incidente risolto e testato, pu essere chiuso. Questo il nono passo del
processo di Incident Management. Se l'incidente si ripete in breve tempo di essere chiuso,
pu essere riaperto nel nono passaggio.
6. Riepilogo
Il processo di Incident Management una serie di passaggi per la risoluzione dei casi per
ripristinare e mantenere la normale servizio IT. Il processo inizia con l'identificazione incidente
iniziale e la registrazione di tutte le informazioni rilevanti incidenti. Un incidente viene classificato e
priorit, in base a chi o che cosa interessato e la gravit dell'impatto del incidente. Un incidente
inizialmente diagnosticata a livello di service desk. Essa pu essere aumentata, se necessario, ad
un gruppo di supporto IT dedicato, che poi si indaga e diagnostica l'incidente. Il gruppo di supporto
implementa risoluzione degli incidenti. Una volta che il servizio viene ripristinato, l'incidente
chiuso. Pu essere riaperta se ricorre subito dopo la chiusura.
134
7. Sommario
| Inizio pagina |
| 1. L'identificazione e la registrazione degli incidenti |
| 2. Categorizzazione e priorit |
| 3. Diagnosi, escalation, e di indagine |
| 4. Risoluzione, chiusura e riapertura |
| Sommario |
135
Gestione Incidenti
individuare l'ambito di Incident Management
individuare i principi di base della gestione degli incidenti
identificare le attivit del processo Incident Management, in uno scenario

In questo esercizio, ti viene richiesto di gestire gli incidenti.

identificare l'ambito di Incident Management
individuando i principi fondamentali di Incident Management, e
ordinare le attivit di gestione degli incidenti

3. ambito Identificazione
Domanda
Quali esempi di IT eventi rientrano nell'ambito di applicazione del processo di Incident
Management?
Opzioni:
1. Un riavvio del sistema fallito interrompe un sistema di prenotazione on-line biblioteca,
impedendo il pubblico dai libri riservando
2. Una rete di uffici in cui Internet si blocca periodicamente
3. Un utente biblioteca chiama il banco di servizio per accedere loro storia prestiti
4. Un gestore dimentica una password e quindi non pu accedere a un account di posta
elettronica
5. Un motore di ricerca fornisce risultati imprecisi a causa di un errato settaggio in un
server di database
Risposta
Opzione 1: Corretto. Qualsiasi evento che interrompe o potrebbe interrompere il normale
servizio classificato come un incidente. Quindi questo evento sarebbe gestito attraverso
Opzione 2: Corretto. L'incidente non diagnosticata sta influenzando negativamente l'accesso
a Internet, che un servizio IT. Cos dovrebbe essere gestita attraverso un processo di
gestione degli incidenti.
Opzione 3: non corretto. Anche se l'utente biblioteca in grado di accedere alle informazioni
necessarie senza l'aiuto del service desk, normali servizi di biblioteca rimangono senza
interruzioni. Quindi questo evento non rientra nell'ambito di Incident Management.
Opzione 4: non corretto. Anche se il gestore pu essere disturbato, si verificata alcuna
interruzione ai normali servizi IT. Quindi questo evento non si qualifica come un incidente.
Opzione 5: Corretto. In questo esempio, le normali servizi IT sono compromessi. Cos
l'evento si qualifica come un incidente e deve essere gestita attraverso il processo di Incident
Management.
136
Risposte corrette):
1. Un fallito riavvio del sistema interrompe un sistema di prenotazione on-line biblioteca,
impedendo il pubblico da riservare libri
2. Una rete di uffici in cui Internet si blocca periodicamente
5. Un motore di ricerca fornisce risultati imprecisi a causa di un errato settaggio in un
server di database
Domanda
Prendere in considerazione altri esempi di eventi. Quali esempi dovrebbero essere affrontati
attraverso Incident Management?
Opzioni:
1. Gli utenti che non riescono ad aggiornare i propri dati d'accesso sono bloccati da
utilizzare un sito
2. Un loop di rete causa un'intera rete di crash, impedendo agli utenti di accedere alle
risorse di rete
3. Un dipendente configura una connessione allo scanner ufficio in modo non corretto e
non in grado di acquisire documenti
4. Un cliente non pu accedere a Internet a causa di essere fornito con un modem
difettosa
5. Una infezione da virus provoca server di posta di un'organizzazione di crash,
impedendo ai dipendenti di accedere e-mail
Risposta
Opzione 1: non corretto. Anche se il servizio viene interrotto per gli utenti che non
aggiornano i propri dati d'accesso, non c' nessun incidente per risolvere in questo
caso. Quindi questo non coperta dal processo di Incident Management.
Opzione 2: Corretto. Quando una rete si blocca, normali servizi IT sono interrotti. Questo si
qualifica come un incidente e quindi rientra nell'ambito di applicazione di Incident
Management.
Opzione 3: non corretto. Il dipendente non pu eseguire la scansione di documenti, ma
questo dovuto alla configurazione viziata. Nessuna interruzione effettiva nelle normali
servizi IT si verificato, in modo che l'evento non rientra nell'ambito di applicazione di
Opzione 4: Corretto. Normale servizio al cliente interrotta a causa delle attrezzature
difettose, per cui questo evento si qualifica come un incidente e deve essere maneggiato con
Opzione 5: Corretto. Servizi IT normali sono interrotti dal crollo, per cui questo evento rientra
nel campo di applicazione Incident Management.
Risposte corrette):
2. Un loop di rete fa s che un'intera rete di crash, impedendo agli utenti di accedere alle
risorse di rete
4. Un cliente non pu accedere a Internet a causa di essere fornito con un modem
guasto
5. Una infezione da virus provoca server di posta di un'organizzazione di crash,
impedendo ai dipendenti di accedere e-mail
Domanda
137
Quali esempi rientrano nell'ambito di applicazione di Incident Management?

Opzioni:
1. Un gestore di contatti il service desk di richiedere l'accesso a un'unit di rete sicura
2. Una mancanza di corrente provoca un server dell'ufficio di crash, e il server deve
essere riavviato prima che l'accesso alla rete pu essere ripristinato
3. Un dipendente chiede che tutte le e-mail di lavoro trasmesso automaticamente un
indirizzo di casa e-mail
4. Un cavo di rete danneggiato impedisce un impiegato di accedere una stampante da
ufficio
5. Un analista di supporto IT scopre un virus su una workstation
Risposta
Opzione 1: non corretto. Anche se un Service Desk IT pu gestire la richiesta del gestore,
questo evento non comporta alcuna interruzione ai normali servizi IT. Cos non si qualifica
come un incidente.
Opzione 2: Corretto. La mancanza di corrente si qualifica come un incidente, perch
interrompe normali servizi di rete. Quindi rientra nell'ambito di applicazione di Incident
Management.
Opzione 3: non corretto. Nessuna interruzione ai normali servizi IT si verificato in questo
caso, in modo da non qualificarsi come un incidente.
Opzione 4: Corretto. Anche se interessato un solo dipendente, normali servizi IT di questo
utente sono state interrotte. Quindi questo si qualifica come un incidente e deve essere
maneggiato con Incident Management.
Opzione 5: Corretto. Anche se il virus stato identificato prima interrotto i servizi, che ha il
potenziale di interrompere le normali servizi IT. Cos si qualifica come un incidente e rientra
nell'ambito di applicazione di Incident Management.
Risposte corrette):
2. Una mancanza di corrente provoca un server dell'ufficio di crash, e il server deve
essere riavviato prima che l'accesso alla rete pu essere ripristinato
4. Un cavo di rete danneggiato impedisce un impiegato di accedere una stampante da
ufficio
5. Un analista di supporto IT scopre un virus su una workstation
4. Identificare i principi
esigenze e situazioni molto diverse delle organizzazioni, in modo che i loro processi per la
gestione di incidenti IT differiscono troppo. Tuttavia, aderendo ad alcuni principi generali pu
aiutare a garantire che il processo di Incident Management efficace.
Domanda
Quali sono alcuni dei principi per una efficace gestione degli incidenti?
Opzioni:
1. Si dovrebbe istituire un sistema che divide incidenti in entrambi una categoria di
attivo o inattivo
2. E 'importante per formare un nuovo team di supporto incidente per ogni incidente ha
riferito che il service desk non pu risolvere
3. Si dovrebbe stabilire tempi per ogni fase del processo di Incident Management
138
4. necessario creare modelli incidente comuni e una risoluzione step-by-step per

ciascuno di essi
5. Si dovrebbe dividere il ciclo di vita incidente in fasi di chiara
6. necessario pianificare risposte speciale a incidenti gravi
Risposta
Opzione 1: non corretto. Efficace Incident Management terr traccia ogni incidente in ogni
fase del ciclo di vita dell'incidente, non solo attiva e inattiva.
Opzione 2: non corretto. E 'meglio stabilire un team dedicato per affrontare incidenti
gravi. Regolari i dipendenti di supporto IT in grado di gestire gli incidenti pi piccoli.
Opzione 3: Corretto. Un importante principio di Incident Management quello di impostare
tempi per il completamento di ogni fase del processo. Questo aiuta a garantire che tutto il
personale di supporto sapere che cosa gli obiettivi concordati sono e possono dare la priorit
incidenti di conseguenza.
Opzione 4: Corretto. Utilizzo di modelli degli incidenti possono causare molto pi efficiente
risoluzione degli incidenti pi comuni. I modelli definiscono procedura appropriata per
rispondere a episodi di particolari tipi.
Opzione 5: Corretto. E 'utile per rompere il ciclo di vita incidente in varie fasi, tra cui la
rilevazione, la diagnosi, la riparazione, il recupero, e il restauro. Ci pu risultare in una
migliore comprensione e gestione di un incidente.
Opzione 6: Corretto. E 'utile avere un modello o serie di passi per affrontare incidenti
gravi. Un'organizzazione pu definire ci che costituisce un grave incidente, anche se in
genere si tratta di un incidente che interrompe i servizi critici e richiede molto tempo per
riparare.
Risposte corrette):
3. Si dovrebbe stabilire tempi per ogni fase del processo di Incident Management
4. necessario creare modelli incidente comuni e una risoluzione step-by-step per
ciascuno
5. Si dovrebbe dividere il ciclo di vita incidente in fasi di chiara
6. necessario pianificare risposte speciale a incidenti gravi
Domanda
Sei un analista di supporto IT e si riceve una chiamata dal service desk segnalazione di un
loop di rete. Come loop accaduto abbastanza spesso su reti, si decide di creare un modello di
incidente per trattare con loro. Quale dovrebbe essere il modello di incidente contenere?
Opzioni:
1. Un documento che elenca le cause alla base del loop di rete
2. Una guida su come risolvere un loop di rete e la ripresa dei servizi di rete
3. Un elenco di persone da contattare in caso di crash di rete, e l'ordine in cui farlo
4. Passi da fare prima di attuare una risoluzione per la protezione contro i rischi come
possibile perdita di dati
5. Un elenco di azioni di risoluzione per essere diviso tra il personale di supporto IT
disponibili
Risposta
139
Opzione 1: non corretto. Un gruppi di modelli incidente vari incidenti in base alle loro
sintomi. Tuttavia, le cause di incidenti effettivi saranno sconosciuto fino gli incidenti sono stati
correttamente diagnosticata.
Opzione 2: Corretto. Lo scopo di un modello incidente di servire come una guida passopasso per risolvere un particolare tipo di incidenti.
Opzione 3: Corretto. Un modello incidente dovrebbe includere i dettagli di contatto per il
personale di supporto che potrebbero aver bisogno di partecipare a risolvere seconda del tipo
di incidente. Essa dovrebbe inoltre definire i passi per l'escalation dell'incidente, se
necessario, compreso chi contattare in ogni punto.
Opzione 4: Corretto. Un modello dovrebbe dettaglio vengono applicate tutte le precauzioni
che dovrebbero essere prese prima che la procedura per la risoluzione di un incidente. Un
esempio il backup dei dati e dei file di configurazione.
Opzione 5: non corretto. Un modello incidente dovrebbe specificare esattamente quali
dipendenti sono responsabili per l'assunzione di quali azioni, piuttosto che suggerire un
elenco di attivit da dividere in modo casuale tra il personale.
Risposte corrette):
2. Una guida su come risolvere un loop di rete e la ripresa dei servizi di rete
3. Un elenco di persone da contattare se la rete si blocca, e l'ordine in cui farlo
4. Passi da fare prima di attuare una risoluzione per la protezione contro i rischi come
possibile perdita di dati
Domanda
Come analista IT, si trovano di fronte a una potenzialmente grave incidente - un alimentatore
malfunzionamento su un server, che potrebbe comportare la perdita di dati aziendali
importanti. Principi cosa Incident Management si applicano specificamente a gestire incidenti
di rilievo?
Opzioni:
1. Definire i tempi di risoluzione di destinazione per ogni fase del processo di
risoluzione
2. Stabilire un team dedicato per risolvere l'incidente
3. Nominare una persona dedicata per gestire la risoluzione del server malfunzionante
4. Stabilire un ambiente di lavoro di emergenza in cui il gestore incidente pu mettere in
pausa il lavoro sugli incidenti minori fino a che il grave incidente stato risolto
5. Priorit alle azioni per ridurre al minimo l'impatto dell'incidente
Risposta
Opzione 1: non corretto. E 'importante definire i tempi di risoluzione di destinazione per tutti
gli incidenti, non solo per i pi grandi. Tuttavia, un incidente grave richiede la risoluzione
rapida a causa del suo potenzialmente grave impatto negativo.
Opzione 2: Corretto. Un team di supporto dedicato dovrebbe essere istituito per risolvere
l'incidente il pi rapidamente ed efficacemente possibile. Questo tipo di squadra non sar
distratto da avere a che fare con gli altri, incidenti meno gravi.
Opzione 3: Corretto. E 'meglio di nominare un responsabile separato per occuparsi
esclusivamente di un grave incidente, piuttosto che avere il solito responsabile dell'incidente
140
fare questo. Questo aiuta ad assicurare che l'incidente grave riceve sufficiente attenzione, ma
anche che gli incidenti pi di routine continuano ad essere affrontato.
Opzione 4: non corretto. E 'meglio nominare un direttore indipendente incidente grave in
modo che il lavoro possa continuare senza sosta su altri incidenti. In questo modo, il grave
incidente ricever anche tutta l'attenzione del dirigente preposto.
Opzione 5: Corretto. Un grave incidente ha una potenzialmente grave impatto su
un'organizzazione e cos deve essere la priorit su tutti gli altri incidenti.
Risposte corrette):
2. Stabilire un team dedicato per risolvere l'incidente
3. Nominare una persona dedicata per gestire la risoluzione del server malfunzionante
5. Priorit alle azioni per ridurre al minimo l'impatto dell'incidente
5. Identificare attivit
Sei un analista di Service Desk che lavora per un provider di servizi Internet. Si riceve una
chiamata da un cliente che in grado di connettersi a Internet.
Domanda
Sequenza Le prime tre fasi del processo di gestione dell'incidente.
Opzioni:
A. Mentre al telefono con il cliente, verificare che il cliente utilizza i corretti password
B. Registrare tutti i dettagli dell'incidente, tra cui quali gruppo di supporto sar gestirlo
C. Assegnare un codice categoria dell'incidente, basata sul fatto che si traduce in
perdita completa di accesso a Internet
Risposta
Risposte corrette):
Mentre al telefono con il cliente, verificare che il cliente utilizza la corretta password classificato
Come primo passo nel processo di Incident Management, si identifica un incidente - che
comporta l'interruzione o la degradazione dei normali servizi IT.
Registrare tutti i dettagli dell'incidente, tra cui quali gruppo di supporto gestir classificato
Una volta che un evento viene identificato come un incidente, il secondo passo quello di
registrare tutte le informazioni rilevanti circa l'incidente.
Assegnare un codice di categoria per l'incidente, sulla base del fatto che esso si traduce in
completa perdita di accesso a Internet classificato
Incidente categorizzazione la terza fase del processo di Incident Management. Si tratta di
categorizzare un incidente in base a ci che posizione, il servizio, il sistema, o di
applicazione ha un impatto.
Domanda
Sequenza la prossima serie di Incident Management passi in ordine.
Opzioni:
A. Assegnare l'incidente una bassa priorit, sulla base del fatto che attualmente
colpisce un solo cliente
141
B. Porre le domande dei clienti su quando l'accesso stato perso e quello che stava
avvenendo al momento
C. Assegnare responsabilit di risolvere l'incidente a uno specifico agente di supporto
Risposta
Risposte corrette):
Assegnare l'incidente una bassa priorit, sulla base del fatto che attualmente colpisce un solo
cliente classificato
Dopo categorizzare l'incidente, e come parte della quarta fase, si dovrebbe assegnare un
codice di priorit o livello, in base alla gravit del suo impatto. livelli di priorit particolari
possono essere associati con tempi di risoluzione dei target corrispondente.
Porre le domande dei clienti su quando l'accesso stato perso e quello che stava accadendo al
momento classificato
Il quinto passo nel processo, che segue incidente priorit, sta conducendo una diagnosi
iniziale dell'incidente. Questo pu accadere al telefono quando viene segnalato un
incidente.
Assegnare responsabilit di risolvere l'incidente a uno specifico agente di supporto classificato
Se non possibile risolvere un incidente subito dopo una diagnosi iniziale, necessario
intensificare l'incidente al gruppo di sostegno adeguato nell'ambito del sesto passo.
Domanda
Posizionare le fasi finali del processo di Incident Management nell'ordine corretto.
Opzioni:
A. L'agente di supporto utilizza il software diagnostico per verificare conto del cliente per
rilevare eventuali problemi
B. Per implementare le azioni per ripristinare l'accesso Internet del cliente
C. Si chiama per verificare che il cliente pu accedere a Internet ed soddisfatto, e
quindi chiudere l'incidente
Risposta
Risposte corrette):
L'agente di supporto utilizza il software diagnostico per verificare conto del cliente per rilevare
eventuali problemi classificato
Nel passaggio sette, l'agente di supporto rilevante o squadra deve indagare ulteriormente e
diagnosticare l'incidente.
Per implementare le azioni per ripristinare l'accesso a Internet del cliente classificato
L'ottavo passo la risoluzione e di recupero, durante il quale vengono ripristinati i normali
servizi.
Si chiama per verificare che il cliente pu accedere a Internet ed soddisfatto, e quindi chiudere
l'incidente classificato
Una volta che l'incidente stato risolto, necessario verificare che il cliente soddisfatto e
garantire che le informazioni registrate circa l'incidente completa. quindi possibile
142
chiudere l'incidente. Se l'incidente ripetersi poco dopo, potrebbe essere necessario riaprire
l'incidente.
6. Riepilogo
La portata e principi del processo Incident Management, cos come l'ordine delle fasi che
comporta, sono stati identificati.
7. Sommario
| Inizio pagina |
| 2. Identificare portata |
| 3. Identificare i principi |
143
Interfacce di gestione degli incidenti

descrivere come Incident Management si interfaccia con altri processi di Service Lifecycle
2. Incident Management e altri processi
Incident Management si interfaccia con vari processi nella transizione, Servizio Progettazione e
Service Operation, le fasi del Service Lifecycle.
Grafico
Le altre tappe del ITIL Service Lifecycle Service Strategy sono e Continual Service
Improvement.
All'interno della fase di Service Operation, Incident Management si interfaccia con due processi Problem Management e gestione degli accessi.
A volte necessario coinvolgere Problem Management nelle indagini e risolvere le cause alla base
degli incidenti. Problem Management, in cambio, fornisce informazioni sui problemi esistenti e
problemi noti che potrebbero essere le cause di incidenti. Queste informazioni possono facilitare la
risoluzione degli incidenti pi veloce.
Ad esempio, un gruppo di dipendenti non pu accedere al loro e-mail. Durante il tentativo di
ripristinare il loro accesso e-mail, Incident Management si interfaccia con Problem Management
per aiutare a determinare il motivo per cui i dipendenti hanno perso l'accesso e-mail. Problem
Management identifica alcuni problemi noti che riguardano il servizio di posta elettronica, e
fornisce una correzione permanente che pu essere utilizzato per ripristinare l'accesso e-mail dei
dipendenti.
Incident Management si interfaccia con gestione degli accessi quando incidenti relativi a tentativi di
accesso non autorizzato o di altri tipi di violazioni della sicurezza. Access Management pu
utilizzare documenti storici degli incidenti da Incident Management di rivedere i controlli di
accesso. Allo stesso modo, Incident Management possono utilizzare le informazioni Access
Management per aiutare a risolvere gli incidenti che coinvolgere le violazioni di accesso.
Domanda
Come funziona l'interfaccia Incident Management con Service Operation?
Opzioni:
1. Pu comportare Problem Management per indagare e risolvere la causa di incidenti
2. Mantiene una storia di incidenti che pu essere utilizzato da Access Management a
supporto delle attivit di indagine forense
3. Si avvisa Capacity Management di incidenti relativi alle prestazioni
4. Si interfaccia con gestione degli accessi per risolvere gli incidenti di violazione della
sicurezza
Risposta
144
Opzione 1: Corretto. Attivit di Problem Management dovrebbero essere coinvolti nell'ambito

delle indagini incidenti per prevenire o ridurre il ripetersi degli incidenti.
Opzione 2: Corretto. Interfacce Incident Management con gestione degli accessi ad assistere
con attivit di indagine forense.
Opzione 3: non corretto. Capacity Management un processo in fase di Service Design,
piuttosto che la fase di Service Operation.
Opzione 4: Corretto. Incident Management si interfaccia con gestione degli accessi, quando i
tentativi di accesso non autorizzati di risolvere violazioni della sicurezza.
Risposte corrette):
1. Pu comportare Problem Management per indagare e risolvere la causa di incidenti
2. Mantiene una storia di incidenti che possono essere utilizzati da Access Management
per supportare le attivit di indagine forense
4. Si interfaccia con gestione degli accessi per risolvere gli incidenti di violazione della
sicurezza
Incident Management si interfaccia anche con quattro processi in fase di Service Design.
Service Level Management
Incident Management consente Service Level Management (SLM) per definire le risposte
misurabili a interruzioni del servizio. Si assiste anche a determinare dove i servizi sono al
loro pi deboli, in modo che SLM pu definire azioni come parte del piano di miglioramento
del servizio. SLM definisce i livelli accettabili di servizio all'interno del quale lavora Incident
Management. Esso definisce i tempi di risposta degli incidenti, le definizioni di impatto, i
tempi di risoluzione di destinazione, le definizioni dei servizi, le regole per i servizi che
richiedono, e le aspettative per fornire un feedback agli utenti. Ad esempio, una serie di
incidenti che coinvolgono un crash dell'applicazione sono segnalati. SLM definisce un
periodo di operativit della presente domanda di 99,5%, con un tempo di 60 minuti
risoluzione per la sospensione all'applicazione.
Information Security Management
Incident Management fornisce la gestione delle informazioni di sicurezza con informazioni
incidente come necessario per supportare le attivit di progettazione di servizi e consentire
una valutazione dell'efficacia delle misure generali di sicurezza. Ad esempio, il processo di
gestione degli incidenti potrebbe fornire Information Security Management, con un rapporto
di tutti gli incidenti accesso alla posta elettronica non autorizzata . Information Security
Management sarebbe quindi utilizzare queste informazioni per valutare le attuali misure di
sicurezza e-mail.
Gestione della capacit
Incident Management avvisa Capacity Management di incidenti relativi alle
prestazioni. Questi possono innescare il monitoraggio delle prestazioni e variazioni di
capacit. A sua volta, Capacity Management pu aiutare a risolvere i Incident Management
incidenti -. Per esempio aumentando la capacit che disponibile , ad esempio, i
dipendenti riportano continuamente che l'accesso alle e-mail insolitamente lenta nelle ore
di punta. Incident Management informa Capacity Management dell'incidente in modo che
possa essere monitorato e ulteriori passi se necessario aumentare la capacit della rete.
Availability Management
145
Availability Management utilizza i dati degli incidenti di gestione per determinare l'effettiva
disponibilit dei servizi IT. Questo pu essere paragonato ai livelli di disponibilit
richiesti. Disponibilit e Incident Management possono quindi lavorare insieme per
migliorare la disponibilit del servizio, se necessario. Per esempio, la disponibilit di
gestione potrebbe utilizzare record incidente creati durante il processo di Incident
Management per determinare la disponibilit di un servizio di posta elettronica. Potrebbe
anche interfacciarsi con Incident Management per sviluppare un piano per migliorare la
disponibilit del servizio.
Domanda
Come funziona l'interfaccia Incident Management con Service Design?
Opzioni:
1. Rileva incidenti che derivano da cambiamenti falliti che sono state attuate attraverso
la gestione del cambiamento
2. Si informa Capacity Management sugli incidenti relativi alle prestazioni
3. Esso consente SLM per determinare dove i servizi sono al loro pi deboli
4. Esso contiene le informazioni che Availability Management utilizza per determinare la
disponibilit dei servizi IT
5. Aiuta a indagare e risolvere cause degli incidenti
Risposta
Opzione 1: non corretto. Change Management un processo della fase di Service
Transition, non la fase di Service Design.
Opzione 2: Corretto. Incident Management consente di identificare gli incidenti relativi alle
prestazioni a cui Capacity Management risponde con cambiamenti di monitoraggio delle
prestazioni e capacit.
Opzione 3: Corretto. Incident Management aiuta a determinare dove i servizi sono al loro pi
deboli, in modo che SLM pu definire un piano di miglioramento del servizio.
Opzione 4: Corretto. Processi di gestione della disponibilit utilizzano i dati raccolti durante
Incident Management per determinare la disponibilit dei servizi IT, e dove il ciclo di vita
incidente pu essere migliorata.
Opzione 5: non corretto. Problem Management, un processo di Service Operation - non
Service Design - fase, fornisce i mezzi per analizzare e risolvere le cause sottostanti.
Risposte corrette):
2. Si informa Capacity Management sugli incidenti relativi alle prestazioni
3. Esso consente SLM per determinare dove i servizi sono a loro pi deboli
4. Esso contiene le informazioni che Availability Management utilizza per determinare la
disponibilit dei servizi IT
All'interno della fase di Service Transition, Incident Management si interfaccia con i processi di
servizio Asset e Configuration Management (SACM) e Change Management.
Uno degli usi del Configuration Management System (CSM) quello di individuare le attrezzature
difettose e per valutare l'impatto degli incidenti associati.
Incident Management in grado di fornire SACM con informazioni sugli elementi di configurazione
146
errati (CSI). Pu anche aiutare SACM valutare l'infrastruttura di servizi di supporto per aiutare a
identificare la causa di un incidente e risolverlo.
Ad esempio, SACM pu identificare un router difettoso e stabilire che potrebbe contribuire a
incidenti che coinvolgono la perdita di accesso alla posta elettronica. Incident Management
gestisce le informazioni sullo stato del router, che alimentato di nuovo al processo di
SACM. Esso utilizza anche le informazioni da SACM per contribuire a risolvere l'incidente correlato
per accedere alla posta elettronica.
Quando richiesta una modifica a implementare una soluzione o la risoluzione, questo dovr
essere registrato come una richiesta di cambiamento (RFC) e gestito attraverso il cambiamento di
gestione.
A sua volta, Incident Management rileva e risolve gli incidenti che derivano da cambiamenti falliti.
Ad esempio, un RFC pu comportare la sostituzione di un server di posta elettronica. Una volta
che il cambiamento stato approvato e implementato, Incident Management avrebbe bisogno per
monitorare il cambiamento attentamente per identificare e risolvere eventuali incidenti che
coinvolgono l'accesso e-mail che potrebbero derivare.
Domanda
Come funziona l'interfaccia Incident Management con Service Transition?
Opzioni:
1. Permette SLM elaborare risposte misurabili alla perdita di connessioni di rete
2. Esso fornisce la gestione delle informazioni di sicurezza con informazioni che
consentono la valutazione delle misure di sicurezza
3. Esso individua e risolve gli incidenti che derivano da modifiche apportate tramite
Change Management
4. Si interfaccia con SACM di identificare il router wireless difettosa
Risposta
Opzione 1: non corretto. SLM un processo in fase di Service Design, non la fase di Service
Transition.
Opzione 2: non corretto. Information Security Management un processo in fase di Service
Design, piuttosto che la fase di Service Transition.
Opzione 3: Corretto. All'interno della fase di Service Transition Service Lifecycle, Incident
Management si interfaccia con Service Asset and Configuration Management e Change
Management.
Opzione 4: Corretto. Durante la gestione degli incidenti, le informazioni relative CI difettosi
sono stati raccolti. Questa informazione viene utilizzata durante SACM per valutare
l'infrastruttura di servizi di supporto.
Risposte corrette):
3. Esso individua e risolve gli incidenti che derivano da modifiche apportate tramite
Change Management
4. Si interfaccia con SACM di identificare il router wireless difettosa
3. Riepilogo
Incident Management si interfaccia con il Problem Management e Access Management elabora in
fase di Service Operation del Service Lifecycle. Si interfaccia con il Service Level Management,
147
Information Security Management, Capacity Management e processi di Availability Management in

fase di Service Design. Si interfaccia anche con il SACM e Change Management elabora nella
fase Service Transition.
4. Sommario
| Inizio pagina |
| 1. Incident Management e altri processi |
| Sommario |
148
L'area ei principi di Problem Management

descrivere l'oggetto di Problem Management
descrivere i principi di base di Problem Management

2. Ambito di Problem Management
ITIL definisce un problema come una causa di fondo di uno o pi incidenti. Problem Management
il processo per la gestione dei problemi in tutto il loro ciclo di vita. Essa fa parte della fase di
Service Operation del ITIL Service Lifecycle.
Grafico
transizione, il funzionamento del servizio, e Continual Service Improvement fasi.
Lo scopo di Problem Management quello di identificare, documentare e risolvere i problemi.
Il processo di Problem Management comprende diversi obiettivi:
proattivo prevenire i problemi e gli incidenti associati si verifichi
eliminare gli incidenti ricorrenti, identificando e risolvendo le loro cause di fondo, e
minimizzare l'impatto di problemi che non possono essere prevenuta
Domanda
Quali sono gli obiettivi del Problem Management?
Opzioni:
1. Proattivo prevenire incidenti ricercando e risolvere le loro cause di fondo
2. Prevenire incidenti si ripetano
3. Ridurre al minimo l'impatto dei problemi
4. Rispondere agli incidenti di infrastrutture IT in cui si verificano
5. Traccia incidenti al fine di garantire che stanno completamente risolti
Risposta
Opzione 1: Corretto. Un obiettivo di Problem Management quello di identificare e risolvere i
problemi che sono alla radice le cause di incidenti IT-correlati.
Opzione 2: Corretto. Un obiettivo di Problem Management quello di identificare,
documentare e quindi risolvere i problemi, che sono definiti come le cause di incidenti.In
questo modo, si impedisce incidenti da ricorrenti.
Opzione 3: Corretto. Se il problema di gestione non pu risolvere un problema, si dovrebbe
mirare a ridurre al minimo l'impatto del problema per affari.
Opzione 4: non corretto. Problem Management si concentra sulla identificazione e
risoluzione dei problemi che sono le cause di incidenti. Incident Management, che un
processo di gestione separata, si concentra sulla risposta agli incidenti che si verificano.
149
Opzione 5: non corretto. Il focus del Problem Management il monitoraggio e la soluzione

dei problemi, o le cause di incidenti. Incident Management, che un processo separato,
coinvolge Controllo e gestione dei casi.
Risposte corrette):
1. prevenire proattivamente gli incidenti per la ricerca e la risoluzione dei loro radice le
cause
2. Prevenire incidenti si ripetano
3. Ridurre al minimo l'impatto dei problemi
L'ambito di Problem Management include la diagnosi delle cause di incidenti e risoluzioni
determinanti.
Implementazione risoluzioni attraverso le procedure di controllo adeguate, in particolare Change
Management e di uscita e Deployment Management, anche compreso nella dotazione di
Problem Management.
Un altro aspetto di portata di Problem Management mantenere e documentare informazioni sui
problemi e le soluzioni appropriate e risoluzioni.
Lo scopo di una soluzione di ridurre il numero o la gravit di incidenti associati finch il problema
sottostante pu essere risolto - o per fornire una soluzione alternativa quando non possibile
eliminare completamente il problema.
Diverse altre attivit rientrano nell'ambito di applicazione del Problem Management:
lo svolgimento di periodiche programmate recensioni di dischi incidenti per trovare modelli

e tendenze che possono indicare gli errori nelle infrastrutture
lo svolgimento di importanti recensioni incidente
lo svolgimento di periodiche programmate recensioni di tronchi operativi e registri di

manutenzione per identificare i modelli e le tendenze in attivit
lo svolgimento di periodiche programmate recensioni di registri di eventi per identificare

modelli e tendenze - per esempio, in eventi di avviso e di eccezione record
lo svolgimento di sessioni di brainstorming per identificare le tendenze, e
utilizzando fogli di controllo per raccogliere dati sul servizio o problemi di qualit operativa
Domanda
Quali attivit sono incluse nel campo di applicazione del Problem Management?
Opzioni:
1. Diagnosi di cause di incidenti e determinare come risolverli
2. Il mantenimento di informazioni sui problemi e le soluzioni appropriate e risoluzioni
3. Esecuzione di controlli periodici programmati dei log degli eventi per identificare
modelli e tendenze
4. Utilizzando liste di controllo per raccogliere i dati di carattere generale su problemi di
servizio o di qualit operativo dopo si verificano incidenti
5. Garantire che gli incidenti che coinvolgono interruzioni del servizio sono
adeguatamente monitorati e documentati
Risposta
150
Opzione 1: Corretto. Processi di Problem Management consentono di identificare e

diagnosticare i problemi che sono alla radice le cause di incidenti, e avviare azioni per
risolvere i problemi o ridurre al minimo il loro impatto.
Opzione 2: Corretto. Problem Management consente di documentare i problemi e le
risoluzioni collegate, o passi per lavorare intorno ai problemi se non possono essere
eliminati. Questo aiuta a prevenire o ridurre al minimo l'impatto dei problemi di servizi IT per
affari.
Opzione 3: Corretto. Problem Management aiuta in modo proattivo per identificare i problemi
IT-correlati, ad esempio, con revisioni periodiche degli eventi di avviso e di eccezione
registrati nei registri eventi. quindi possibile adottare misure per affrontare i problemi prima
che provocano incidenti.
Opzione 4: non corretto. Efficace Problem Management prevede la raccolta dei dati di
carattere generale su problemi di servizio o di qualit operativa in modo proattivo, per
identificare i problemi prima che si verifichino incidenti. Lo fa anche affrontare i problemi dopo
che si sono verificati incidenti, ma questo non comporterebbe la raccolta di informazioni di
carattere generale su servizio o la qualit operativa.
Opzione 5: non corretto. Incident Management, invece di Problem Management, assicura
che gli incidenti siano adeguatamente monitorati e registrati.
Risposte corrette):
1. Diagnosticare cause di incidenti e determinare come risolverli
2. Il mantenimento di informazioni sui problemi e le soluzioni appropriate e risoluzioni
3. Esecuzione di controlli periodici programmati dei log degli eventi per identificare
modelli e tendenze
3. Principi problema di gestione
Efficace Gestione dei problemi dipende da tre importanti principi. Esso dovrebbe includere
approcci sia reattiva e proattiva, si deve fare uso di modelli problematici, e non deve essere
confuso con Incident Management.
La differenza tra il Problem Management reattivo e proattivo sta nel modo in cui il processo di
Problem Management innescato.
Problem Management reattivo
attivit di Problem Management reattivi sono scatenate da incidenti che si sono gi
verificato. Queste attivit si integrano attivit di Incident Management, concentrandosi sulla
ricerca e risolvere le cause alla base degli incidenti, e di individuare soluzioni alternative in
caso di necessit.
Gestione proattiva dei problemi
L'obiettivo di migliorare le unit complessive di qualit del servizio o di consegna Proactive
Problem Management. Si tratta di ricerca di problemi e risolvendo loro prima che possano
causare incidenti, o prima che gli incidenti sono direttamente collegati a loro. Ad esempio,
l'analisi dei trend di documenti storici incidenti pu suggerire un problema di fondo, che
possono poi essere indagato. Proactive Problem Management integra Continual Service
Improvement attivit (CSI).Entrambi contribuiscono a continui miglioramenti in servizi IT - e
problemi individuati attraverso Gestione proattiva dei problemi pu essere inserito nel
registro CSI il come opportunit di miglioramento.
151
Proactive Problem Management reindirizza gli sforzi di un'organizzazione di reagire agli incidenti
per incidenti impediscono. In questo modo l'organizzazione per fornire un servizio migliore ai propri
clienti e fare un uso pi efficace delle risorse IT disponibili.
Un altro principio di efficace gestione problema quello di utilizzare modelli problematici. Problema
modelli sono in sequenza passi da seguire durante la risoluzione specifici tipi di problemi, che
aumenta l'efficienza nella gestione dei problemi quando in realt si verificano.
modelli di problemi e soluzioni alternative per gli errori noti devono essere registrati in un database
errore noto (KEDB) in modo che possano essere facilmente recuperati quando sono necessari.
Un principio finale per una efficace gestione problema quello di evitare di confondere con
Incident Management e Problem Management si concentrano su diverse aree.
incidenti
Un incidente un'interruzione non pianificata per un servizio IT o una riduzione della
qualit di un servizio IT. La causa pu essere un problema di fondo. Gli utenti che perdono
l'accesso alla loro e-mail un esempio di un incidente. Attivit di gestione degli incidenti si
concentrano sul ripristino dei servizi al loro stato normale il pi presto possibile dopo il
verificarsi interruzioni del servizio.
I problemi
Un problema una causa reale o potenziale di incidenti. Un server di posta elettronica
difettosa un esempio di un problema. Ci potrebbe portare a uno o pi incidenti in cui gli
utenti perdono l'accesso ai servizi di posta elettronica. Attivit di Problem Management si
concentrano sulla ricerca di modi per prevenire gli incidenti che si verificano.
Anche se i due processi si differenziano, sono ovviamente connessi - e le attivit di gestione degli
incidenti possono invocare le attivit problema di gestione. Ad esempio, uno o pi incidenti gestite
attraverso Incident Management possono indicare un problema di fondo, che viene poi registrato e
gestito attraverso Problem Management. Le regole per invocare Problem Management durante un
incidente pu variare tra le diverse organizzazioni.
Domanda
Qual la differenza principale tra il Problem Management e Incident Management?
Opzioni:
1. Incident Management si concentra sul ripristino dei servizi alla normalit nel pi
breve tempo possibile, considerando che il problema di gestione si concentra sulla
prevenzione di incidenti che si verificano o ricorrente
2. Incident Management proattiva considerando che il problema di gestione in gran
parte reattiva
3. Incident Management si concentra sugli errori meno gravi e problemi di Problem
Management
Risposta
Opzione 1: Corretto. Incident Management il processo per la gestione delle interruzioni di
servizi IT, mentre il Problem Management si concentra su come affrontare i problemi di fondo
queste interruzioni.
152
Opzione 2: non corretto. Incident Management consiste nel rispondere agli incidenti e cos
in gran parte reattiva. Problem Management, tuttavia, comprende sia gli elementi proattivi e
reattivi.
Opzione 3: non corretto. Incident Management comporta la gestione tutti gli incidenti, tra cui
quelli con conseguenze potenzialmente molto significativi. Allo stesso modo, Problem
Management comporta la gestione di tutti i problemi connessi con i servizi IT, tra cui i
principali problemi e quelli meno gravi.
Risposte corrette):
1. Incident Management si concentra sul ripristino dei servizi alla normalit nel pi breve
tempo possibile, considerando che il problema di gestione si concentra sulla
prevenzione di incidenti che si verificano o ricorrente
Pu essere opportuno invocare Problem Management durante un incidente in varie circostanze:
Problem Management possono avere informazioni sui problemi esistenti e errori noti che
potrebbero contribuire ad uno o pi incidenti
analisi delle tendenze di incidenti registrati suggerisce un problema di fondo
attivit di Problem Management possono aiutare a identificare la causa principale

dell'incidente
un gruppo di sostegno, un fornitore, o di altre funzioni IT di identificare l'esistenza di una

condizione di problema, o
il service desk ha risolto un incidente, ma non ha determinato una causa definitiva e

sospetta che sia il rischio di reiterazione
Domanda
Quali sono i principi per una efficace gestione problema?
Opzioni:
1. Identificare e risolvere i problemi prima che possano causare incidenti, cos come
rispondere ai problemi segnalati o potenziali problemi
2. Creazione e utilizzo di sequenze definite di passi per risolvere i problemi pi comuni
3. Concentrandosi sulle affrontare le cause degli incidenti, piuttosto che sugli incidenti
stessi
4. Implementazione di soluzioni alternative, piuttosto che piena risoluzione dei problemi,
quando possibile, per risparmiare sui costi
5. Dare priorit servizi ripristino dopo si verificano interruzioni
Risposta
Opzione 1: Corretto. Efficace Problem Management include sia gli elementi proattivi e
reattivi. Contribuisce al miglioramento di servizi in corso, identificando e risolvendo i problemi
prima che possano causare interruzioni del servizio.
Opzione 2: Corretto. Utilizzando modelli problema, che definiscono le sequenze di passi per
risolvere i problemi riscontrati pi di frequente o errori noti, pu portare a risoluzione pi
rapida problema.
Opzione 3: Corretto. Problem Management non deve essere confuso con Incident
Management. Si concentra sulle cause degli incidenti, piuttosto che sugli incidenti stessi.
153
Opzione 4: non corretto. Soluzioni alternative sono di solito solo correzioni temporanee - ed
spesso pi conveniente nel lungo periodo per risolvere completamente i problemi.
Opzione 5: non corretto. Incident Management, invece di Problem Management, si concentra
sul ripristino servizi IT al loro stato normale dopo si verificano interruzioni.
Risposte corrette):
1. Identificare e risolvere i problemi prima che possano causare incidenti, cos come
rispondere ai problemi segnalati o potenziali problemi
2. Creazione e utilizzo di sequenze definite di passi per risolvere i problemi pi comuni
3. Concentrandosi sulle affrontare le cause degli incidenti, piuttosto che sugli incidenti
stessi
4. Riepilogo
Il processo di Problem Management include la diagnosi delle cause di incidenti e determinare
come risolverli, l'attuazione delle risoluzioni, e il mantenimento di informazioni sui problemi. Esso
comprende sia gli aspetti reattiva e proattiva. Efficace Problem Management si basa su entrambe
le attivit problema di gestione reattiva e proattiva, e l'uso di modelli problematici. Non deve essere
confuso con Incident Management, che si concentra sul ripristino servizi IT alla normalit il pi
presto possibile dopo si verificano interruzioni.
5. Sommario
| Inizio pagina |
| 1. Ambito di Problem Management |
| 2. Principi Problem Management |
| Sommario |
154
Il processo di Problem Management

individuare le attivit del processo di gestione dei problemi
2.
Il problema di gestione processo
Il processo di Problem Management, come indicato dalla ITIL, si compone di dieci

passi. Innanzitutto viene rilevato un problema. Allora registrato, classificato e priorit.
Grafico
Un diagramma mostra le prime quattro fasi del processo di gestione dei problemi: rilevamento
dei problemi, di registrazione problema, problema di categorizzazione, e problemi di priorit.
Il problema indagato e diagnosticata, e, se possibile, una soluzione stato sviluppato per
risolvere temporaneamente il problema.
Grafico
I prossimi due passaggi sono aggiunti al diagramma: indagine del problema e la diagnosi e
soluzioni alternative.
Se del caso, una nota record di errore viene poi portata.
Grafico
Il passo successivo innalzamento errore noto se necessario viene aggiunto al diagramma.
Infine, per risolvere il problema, in genere si seguono questi tre passi:
implementare la soluzione al problema

di risoluzione problema viene aggiunto al diagramma di processo Problema Management.
chiudere il record di problema, e

la chiusura Problema viene aggiunto al diagramma.
se il problema stato classificato come importante, rivedere il problema e la sua

risoluzione
riesame principale problema viene aggiunto al diagramma.
Le fasi del processo di gestione dei problemi sono iterativo in quanto i risultati di una revisione
finale informano successive attivit di Problem Management, se del caso. Le organizzazioni
possono anche variare i gradini. Ad esempio, una soluzione pu essere applicata non appena
viene rilevato un problema importante, prima della sua causa principale identificata.
Grafico
Le fasi del processo, ancora una volta, sono il rilevamento problema, la registrazione
Problema, problema categorizzazione, Problema priorit, indagini problema e la diagnosi, le
soluzioni alternative, sollevando una nota record di errore, se necessario, la risoluzione dei
problemi, la chiusura problema, e la revisione dei principali problemi.
3. individuare, registrare, classificare, dare priorit
il personale problema di gestione in genere verifichi un problema in uno dei due modi:
155
Grafico
rilevamento problema viene evidenziato nel diagramma di processo di Problem Management.
reattivo, o
Il processo di Problem Management pu essere attivato in risposta ad un problema che
gi stato segnalato. Ad esempio, un problema pu essere segnalato da un banco di
servizio se sembra essere la causa di alcuni inconvenienti. Un problema pu anche essere
identificata da un gruppo di supporto tecnico che analizza un incidente, da un sistema
automatico, oppure da un fornitore o appaltatore.
in modo proattivo
Un problema pu essere rilevato come risultato di attivit proattive, intese a identificare i
problemi prima che essi hanno gravi effetti negativi sui clienti o utenti. Ad esempio, un
problema pu essere identificato attraverso la qualit regolare attivit di miglioramento del
servizio.
. Ad esempio, un banco di servizio riceve segnalazioni da diversi rappresentanti regionali, che non
possono accedere alla rete privata virtuale aziendale (VPN) per caricare i propri ordini di vendita
quotidiana Dopo l'accesso ciascuno dei segnalati incidenti, il service desk apre un report problema
- perch gli incidenti indicano un problema di fondo.
Una volta che stato rilevato un problema, devono essere registrati i suoi dettagli. Questo
assicura che il problema pu essere adeguatamente monitorati e gestiti, e che l'organizzazione
accumula un record storico di tutti i problemi. Il record problema iniziale deve essere aggiornato
per tutto il resto del ciclo di vita del problema.
Grafico
Problema di registrazione evidenziato nel diagramma di processo di Problem Management.
Alcuni dei dettagli che devono essere registrati in un record problema sono
i dettagli del singolo segnalazione del problema
la data e l'ora il problema stato inizialmente registrato
servizi e attrezzature particolari
priorit e categorizzazione dettagli
informazioni su eventuali incidenti pensato per essere associato con il problema, compresi i
numeri record di incidenti, e
dettagli di tutte le azioni di recupero di diagnosi o tentati presi
Avanti un problema dovrebbe essere classificato, utilizzando lo stesso sistema di codifica che
stato utilizzato per classificare eventuali incidenti associati. Ad esempio, incidenti e problemi
associati possono essere classificati come "servizio non disponibile" o "un rallentamento delle
prestazioni." Per garantire i problemi sono classificati correttamente, il supporto personale
richiedono definizioni chiare problema.
Grafico
156
Problema categorizzazione evidenziato nel diagramma di processo di Problem

Management. Un problema come gli utenti che sono in grado di connettersi a una rete VPN
pu essere classificato come "Servizio non disponibile".
Dopo categorizzare un problema, necessario dare la priorit che in base al suo potenziale
impatto e l'urgenza.
Grafico
Problema priorit evidenziato nel diagramma di processo di Problem Management.
Ogni problema deve essere assegnato un livello di codice di priorit adeguata, che pu essere
associato a un tempo di risoluzione di destinazione corrispondente.
Grafico
Come esempio di un sistema di codifica di priorit, un problema viene assegnata una
valutazione urgenza e una valutazione di impatto di alta, media o bassa, rispettivamente. Un
problema con un alto urgenza e l'impatto un 1. Un problema con elevata urgenza e impatto
medio, o medio urgenza e ad alto impatto, un 2. Un problema con bassa urgenza e ad alto
impatto, di media urgenza e l'impatto, o e alta urgenza e basso impatto un 3. un problema
con la media urgenza e basso impatto, o bassa urgenza e impatto medio, un 4. un
problema con low urgenza e basso impatto un 5.
si d anche un elenco di codici di priorit con corrispondenti descrizioni e tempi di risoluzione
di destinazione. 1 critico con un tempo di risoluzione di destinazione un'ora.2 alto con un
tempo di 8 ore risoluzione di destinazione. 3 media con un tempo di 24 ore risoluzione di
destinazione. 4 bassa con un tempo di 48 ore risoluzione di destinazione. 5
contrassegnato come la pianificazione, con un tempo di risoluzione di destinazione indicata
come "previsto".
Ad esempio, il problema di accesso VPN che impedisce ordini di vendita da caricato pu essere
assegnato un livello medio di impatto e un elevato livello di urgenza.Utilizzando un sistema di
codifica semplice, il problema pu essere assegnato il codice 2 - che associato con un tempo di
risoluzione bersaglio di 8 ore.
Domanda
Un fornitore di servizi IT recentemente aggiornato un database in call center di un cliente. Ora
il service desk riceve numerosi reclami da parte del cliente, spiegando che fino al 5% dei
tentativi da parte dei rappresentanti del servizio clienti (CSR) per salvare le informazioni sul
chiamante non riescono tutti i giorni. Quali sono le prime quattro fasi del processo di gestione
dei problemi in questo scenario?
Opzioni:
1. Il service desk intensifica i singoli episodi, perch sospetta un problema di fondo
2. L'help desk raccoglie precedentemente segnalato incidenti da record incidente, e li
include nel record problema
3. L'unit IT etichetta il problema come "le interruzioni di servizio"
4. L'impatto e l'urgenza delle interruzioni sono giudicati ad essere elevato
5. Il service desk dice utenti della rete sta vivendo un problema di larghezza di banda e
che il servizio sar in esecuzione ancora presto
6. L'unit IT invia un tecnico per risolvere il problema
Risposta
157
Opzione 1: Corretto. Il primo passo nel processo il rilevamento problema. Ci pu

verificarsi se, per esempio, uno o pi incidenti indicano un problema di fondo.
Opzione 2: Corretto. Una volta rilevato un problema, importante iniziare registrare i dettagli
del problema. Questo assicura che il problema pu essere monitorato e che
un'organizzazione avr un record storico di esso per riferirsi a pi tardi.
Opzione 3: Corretto. Come terzo passo, un problema dovrebbe essere classificato nello
stesso modo di qualsiasi incidente correlato, in base al tipo. Ad esempio, un problema pu
riguardare l'interruzione del servizio o per rallentare le prestazioni.
Opzione 4: Corretto. La quarta fase del processo privilegiare il problema, in base alla sua
urgenza e potenziale impatto.
Opzione 5: non corretto. Il service desk non deve scuse per gli incidenti. Inoltre, il problema
non ancora stato indagato, quindi non valido per fare ipotesi sulla sua natura o per
risoluzione.
Opzione 6: non corretto. Le prime quattro fasi del processo di Problem Management sono da
rilevare, registrare, catalogare, e quindi la priorit di un problema. Sarebbe troppo presto per
inviare un tecnico quando il problema di fondo non ancora stato somministrato.
Risposte corrette):
1. Il service desk intensifica i singoli episodi, perch sospetta un problema di fondo
2. L'help desk raccoglie precedentemente segnalato incidenti da record incidente, e li
include nel record problema
3. L'unit IT etichetta il problema come "le interruzioni di servizio"
4. L'impatto e l'urgenza delle interruzioni sono giudicati ad essere elevato
4. Indagare, aggirare, aumentare l'errore
Una volta che un problema stato priorit, dovrebbe essere studiata, diagnosi, allo scopo di
scoprire la causa principale.
Grafico
indagini problema e la diagnosi evidenziato nel diagramma di processo di Problem
Management.
La velocit e la natura di questa indagine varieranno a seconda della priorit assegnata al
problema e il tempo di risoluzione di destinazione associato.
Alcune delle tecniche di problem solving possibile utilizzare per investigare e diagnosticare un
problema includono
di brainstorming
Durante una sessione di brainstorming, un gruppo genera il maggior numero di idee
possibili circa le cause di un problema e risoluzioni. Il gruppo si restringe poi gi le sue
idee, d'accordo sulle azioni, e documenta i risultati.
la tecnica "5-Whys"
La tecnica a 5 Whys un metodo semplice ma efficace per ottenere la causa principale di
un problema. Si inizia con la descrizione del problema e poi chiedere: "Perch
successo?" Ogni risposta poi seguito da un altro "Perch?" domanda. Spesso ci vogliono
cinque domande per determinare la causa principale di un problema.
difetto di isolamento
158
Per isolare un guasto, di solito necessario replicare gli eventi che hanno portato al
problema. quindi indagare l'elemento di configurazione (CI) all'inizio della manifestazione,
seguita da ogni successiva CI, fino a trovare il guasto. Se il guasto non pu essere ricreato,
di indagare lo stato di salute di ogni CI coinvolto nell'evento.
mappatura affinit
mappatura Affinity comunemente fatto durante le sessioni di brainstorming con il
personale di supporto chiave. Le soluzioni possibili sono registrati su singole schede e poi
raggruppati in base alle caratteristiche simili. A "header" assegnato a ciascun gruppo per
l'identificazione futuro ed esaminato per una causa principale.
controllo di un'ipotesi
Quando si utilizza verifica di ipotesi, una squadra genera un elenco di possibili cause di
fondo sulla base di ipotesi plausibili. E 'quindi determina quali sono vere e quali sono false.
posto di osservazione tecnica
Il posto di osservazione tecnica permette al personale di supporto tecnico specialista
all'interno dell'organizzazione di supporto IT per monitorare gli eventi in tempo reale, al fine
di individuare i problemi che si verificano, e, potenzialmente, di individuare le possibili
cause del problema.
Diagramma di Ishikawa, e
Un diagramma di Ishikawa si sviluppa normalmente durante una sessione di brainstorming,
durante il quale un problema discusso in modo da aumentare la comprensione e
identificare l'origine di un problema. Il tronco principale delle classifiche diagramma il
problema. Le possibili cause sono rappresentate da rami del tronco, e fattori secondari
vengono aggiunti come steli.
analisi di Pareto
analisi di Pareto un metodo statistico utilizzato per determinare i pi importanti, o spesso
si verificano, potenziali guasti. Si basa sul principio di Pareto o la regola 80-20, in cui si
afferma che l'80% dei problemi sono causati da 20% delle cause.
possibile utilizzare il sistema di gestione della configurazione (CMS) per aiutare a diagnosticare il
punto esatto di un fallimento.
inoltre possibile utilizzare il database Conosciuto Error (KEDB) e tecniche di problem-matching,
come la ricerca di parole chiave, per stabilire se un problema si verificato prima e per verificare la
risoluzione predefinita.
Si consiglia di ricreare il fallimento in un ambiente di test che rispecchia l'ambiente dal vivo per
scoprire la causa del problema e quindi per trovare la risoluzione pi adeguata e conveniente. Un
ambiente di test consente di indagare e diagnosticare il problema senza causare ulteriori
interruzioni per gli utenti.
Quando il problema degli agenti fuori sede non essere in grado di caricare gli ordini di vendita
indagato, i registri rivelano che incidenti simili avvenuti in due diverse occasioni.In entrambi i casi,
gli incidenti sono stati riportati dopo la configurazione dello stesso router stato aggiornato.
E 'quindi stabilito che la causa principale una linea corrotta di codice che stato introdotto
durante l'aggiornamento di configurazione del router. Una soluzione praticabile al problema
quindi di riconfigurare il router per rimuovere la codifica difettosa.
159
Una soluzione un metodo temporaneo di superare le difficolt che un problema ha

introdotto. Anche se esiste una soluzione, importante continuare a lavorare verso una risoluzione
permanente. E 'anche importante documentare i dettagli di una soluzione e mantenere il record di
problema aperto.
Grafico
Soluzioni alternative evidenziato nel diagramma di processo di Problem Management.
A volte pi soluzioni alternative esistono, e ognuno aiuta a ridurre l'impatto e l'urgenza di un
problema - con il risultato che il suo livello di priorit pu essere ridotto.
Ad esempio, potrebbe essere possibile stabilire una connessione tra agenti di vendita fuori sede e
un server aziendale riconfigurando un router di backup. Pu anche essere possibile lasciare che
tutti gli agenti fax i loro ordini di vendita, piuttosto che inviare elettronicamente fino alla risoluzione
del problema.
Un errore di nota definita come un problema con una causa principale documentato e
soluzione. Una nota record di errore deve essere aperto, o sollevato, non appena un problema
stato diagnosticato e una soluzione stata trovata, se ne esiste uno. Il record dovrebbe quindi
essere inserito nella KEDB per riferimento futuro.
Grafico
Alzando errore noto se necessario evidenziato nel diagramma di processo di Problem
Management.
A volte necessario per sollevare un noto record di errore anche prima diagnosi dei problemi
completa e una soluzione stata trovata. Per esempio, questo potrebbe essere fatto per fini
informativi o per identificare una causa principale o una soluzione che appare per affrontare un
problema, ma che non stata confermata.
Una nota record di errore dovrebbe
identificare il record di problema cui si riferisce
Documento lo stato delle azioni intraprese per risolvere il problema
identificare la causa principale, e
documentare la soluzione
Domanda
Il problema di interruzione del servizio in un call center stato rilevato, registrati, classificati, e
priorit. Quali sono le tre fasi del processo di gestione dei problemi di solito si verificano
dopo?
Opzioni:
1. Utilizzare il KEDB di trovare la stessa configurazione in uso da un altro cliente che ha
avuto lo stesso problema
2. Implementare una soluzione temporanea, mentre la determinazione di una soluzione
definitiva al problema
3. Documentare la causa principale e le soluzioni al problema
4. Annotare l'ora e la data si verificato l'incidente
5. Chiedetevi "Quanto tempo ci vorr per risolvere il problema?"
160
Risposta
Opzione 1: Corretto. Il problema deve essere esaminato e diagnosticato per cause profonde
e le possibili soluzioni. Questo il quarto passo. Un modo per farlo quello di utilizzare
KEDB per trovare le occorrenze precedenti e il modo in cui questi sono stati risolti.
Opzione 2: Corretto. Prima di conoscere la causa principale o la soluzione appropriata per
un problema, una soluzione pu aiutare a ripristinare temporaneamente il servizio. Questo il
passo cinque.
Opzione 3: Corretto. Come parte del sesto passo, importante documentare un problema
sollevando una nota record di errore e inserirlo nella KEDB. In questo modo, problemi futuri
pu essere identificato e il servizio ripristinato rapidamente.
Opzione 4: non corretto. Il problema gi stato registrato come parte della seconda fase.
Opzione 5: non corretto. Questo un esempio del tipo di domanda che dovrebbe porsi
quando la priorit di un problema nel passaggio quattro - ma in questo caso, il problema gi
stato la priorit.
Risposte corrette):
1. Utilizzare i KEDB di trovare la stessa configurazione utilizzata da un altro cliente che
ha avuto lo stesso problema
2. Implementare una soluzione temporanea, mentre la determinazione di una soluzione
definitiva al problema
3. Documentare la causa principale e le soluzioni al problema
5. Resolve, chiudere, recensione
Una volta che la soluzione di un problema stato determinato, pu essere applicato. In questa
fase, vitale che salvaguardie vengono introdotti per garantire la risoluzione non crea ulteriori
difficolt. Se necessario alcun cambiamento in termini di funzionalit, una richiesta di
cambiamento (RFC) - una proposta formale per un cambiamento - dovrebbe essere sollevato e
autorizzato prima di applicare la risoluzione.
Grafico
la risoluzione dei problemi evidenziato nel diagramma di processo di Problem Management.
Se il problema grave e urgente una correzione necessaria per motivi di lavoro, un RFC
emergenza dovrebbe essere sollevata. La risoluzione deve essere applicato solo una volta che il
cambiamento stato autorizzato e prevista per il rilascio. Nel frattempo, il KEDB dovrebbe essere
usato per aiutare a risolvere eventuali ulteriori occorrenze dei problemi che possono verificarsi.
Se la risoluzione di un problema non pu essere giustificato - ad esempio, perch il suo costo
troppo alto -. Una decisione pu essere presa a lasciare il record di problema aperto e fare
affidamento su una soluzione La priorit del problema pu anche essere ridotto , basata sull'effetto
della soluzione.
Nel caso di agenti di vendita che non possono utilizzare una VPN per caricare i loro ordini di
vendita, di risoluzione potrebbe essere installare un router dedicato, per eliminare o ridurre
l'introduzione di errori negli aggiornamenti di configurazione. Ci richiederebbe un RFC perch si
tratta di una modifica alla infrastruttura di rete. Se l'organizzazione decide di non installare un
router dedicato, gli eventuali aggiornamenti di configurazione del router in futuro dovrebbero
essere modificate per includere testare la funzionalit del software di presentazione di vendite
prima che va in diretta.
161
Grafico
la risoluzione dei problemi evidenziato nel diagramma di processo di Problem Management.
Una volta che una risoluzione finale stata applicata, il record di problema viene controllata per
assicurarsi che sia completamente aggiornato. Il record problema e gli eventuali record correlati
incidenti che sono ancora aperte vengono poi chiusi. Inoltre, lo stato di qualsiasi relative nota
record di errore viene aggiornata per mostrare che la risoluzione stata applicata.
Grafico
Chiusura problema viene evidenziato nel diagramma di processo di Problem Management.
Come passo finale di Performance Management, i principali problemi - come definito sulla base di
sistema di priorit di un'organizzazione - dovrebbero essere riviste in modo l'organizzazione pu
imparare qualche lezione per il futuro. La revisione dovrebbe esaminare
Grafico
riesame principale problema evidenziato nel diagramma di processo di Problem
Management.
le cose che sono state fatte in modo corretto
le cose che sono state fatte male
cosa si potrebbe fare meglio in futuro
come evitare che problemi simili si ripetano, e
se ci fosse alcuna responsabilit di terze parti per i problemi e se sono necessarie azioni di
follow-up
I risultati di un'importante recensione problema dovrebbero essere utilizzati per
formare il personale e sensibilizzare
I risultati di una profonda revisione problema dovrebbe essere utilizzato come parte di
attivit di formazione e sensibilizzazione per il personale di supporto.Eventuali lezioni
apprese devono essere documentate in apposite procedure, istruzioni di lavoro, gli script di
diagnostica, o record di errore noti. Il manager problema dovrebbe facilitare la sessione e
documentare eventuali azioni concordate.
fornire un contributo al proattivo Problem Management, e
I risultati di una profonda revisione problema pu aiutare indicano potenziali cause di altri
problemi, o di problemi che possono verificarsi in futuro.
informare servizio di revisione incontri
I risultati dovrebbero essere incorporati in una riunione di revisione di servizio con i gruppi
di clienti o utenti. Questo viene fatto per garantire che il cliente consapevole delle azioni
intraprese e dei piani per prevenire futuri incidenti gravi che si verificano. Aiuta a migliorare
la soddisfazione dei clienti e assicurare la business che Service Operation sta gestendo i
principali incidenti con responsabilit e lavorare attivamente per prevenire il loro ripetersi in
futuro.
162
La lezione appresa l'aggiornamento di configurazione del router che ha portato le vendite agenti
non essere in grado di caricare i propri ordini di vendita quello di implementare pi approfondita
fase di beta testing degli aggiornamenti di configurazione del router, almeno per sistemi e software
che sono considerati critici.
Domanda
Quali sono esempi delle fasi finali del processo di gestione dei problemi?
Opzioni:
1. Riconfigurare agli utenti di connettersi al percorso di rete corretta quando firmano in
2. Controllare che il noto record di errore contiene una descrizione storica completa di
tutti gli eventi, e quindi chiudere il record di problema
3. Rendere personale di supporto rilevante IT consapevoli della nota record di errore
4. Accedere il problema con l'unit IT e fornire agli utenti con una stima approssimativa
di quando il servizio sar di nuovo funzionante
5. Applicare la soluzione fino a quando viene trovata una risoluzione
Risposta
Opzione 1: Corretto. Dopo aver identificato una risoluzione e sollevando un errore noto,
possibile applicare la risoluzione di un problema. Questo il passo otto del processo di
Problem Management.
Opzione 2: Corretto. Il secondo-ultimo passo del processo quello di confermare che tutte le
informazioni pertinenti su un problema stato registrato e poi chiudere il record di problema.
Opzione 3: Corretto. La fase finale del processo quello di rivedere i principali problemi. I
risultati possono essere utilizzati per aumentare la consapevolezza dei problemi e i passaggi
per risolverli tra il personale IT di supporto.
Opzione 4: non corretto. Logging il problema non una delle fasi finali del processo di
gestione dei problemi. Questo dovrebbe avvenire non appena viene rilevato il problema.
Opzione 5: non corretto. Una soluzione di solito una misura temporanea per finch non si
trova una risoluzione finale.
Risposte corrette):
1. Gli utenti riconfigurazione per connettersi al percorso di rete corretta quando firmano
in
2. Controllare che il noto record di errore contiene una descrizione storica completa di
tutti gli eventi, e quindi chiudere il record di problema
3. Rendere personale di supporto rilevante IT consapevoli della nota record di errore
6. Riepilogo
Il processo di Problem Management include dieci passi. I primi quattro passi sono da rilevare,
registrare, catalogare, e quindi la priorit un problema. Il problema poi indagato e diagnosticato
per una causa principale e le possibili soluzioni. Soluzioni alternative devono essere applicate se
questi esistono. Il problema e la sua risoluzione vengono documentati in un record di errore
noto. Mentre le ultime tre fasi, la risoluzione del problema implementato, il record di problema
chiuso, e grandi problemi sono recensione.
163
7. Sommario
| Inizio pagina |
| 1. Il processo di Problem Management |
| 2. Rileva, log, classificare, dare priorit |
| 3. Indagare, aggirare, aumentare errore |
| 4. Resolve, chiudere, recensione |
| Sommario |
Problemi di Gestione
individuare la portata e principi di Problem Management
identificare le attivit del processo problema di gestione, in uno scenario

In questo esercizio, siete tenuti a gestire i problemi.

identificare la portata del Problem Management
riconoscendo i principi di effettiva gestione dei problemi, e
individuare le attivit problema di gestione in un dato scenario

3. ambito Identificazione
Nel ITIL Service Lifecycle, Problem Management il processo per la gestione di tutti i problemi
che si presentano nelle varie fasi del ciclo di vita. Come risultato, si ha un ampio campo di
applicazione.
Domanda
Quali attivit sono incluse nel campo di applicazione del Problem Management?
Opzioni:
1. Diagnosi di cause di incidenti e le loro risoluzioni
2. delibere di attuazione attraverso adeguate procedure di controllo come la gestione
del cambiamento
3. Documentare le informazioni problema e soluzioni alternative e le risoluzioni
appropriate
4. Condurre periodiche programmate recensioni di tronchi operativi e registri di
manutenzione
5. Condurre periodiche recensioni in programma di record di problemi per indicare gli
errori nelle infrastrutture
6. Condurre sessioni di brainstorming per identificare gli errori di infrastruttura
Risposta
164
Opzione 1: Corretto. Processi di Problem Management consentono di identificare e

diagnosticare i problemi che sono alla radice le cause di incidenti, e avviare azioni per
risolvere i problemi o ridurre al minimo il loro impatto.
Opzione 2: Corretto. Problem Management responsabile per risolvere i problemi attraverso
le procedure corrette, quali la compilazione di richieste di modifica per informare la gestione
di ci che stato fatto.
Opzione 3: Corretto. Processi di Problem Management aiutano a mantenere le informazioni
sui problemi e le loro soluzioni e risoluzioni. Questo pu aiutare a ridurre gli incidenti correlati
accada.
Opzione 4: Corretto. Periodici recensioni in programma fanno parte della gestione proattiva
dei problemi. La realizzazione di tali recensioni aiuta a identificare eventuali modelli o
tendenze in attivit, ed evidenziare eventuali problemi che potrebbero sorgere in futuro.
Opzione 5: non corretto. Processi Problema di gestione assicurano che periodiche
programmate recensioni di dischi incidenti sono condotte. Questo aiuta a trovare modelli e
tendenze che possono indicare gli errori nelle infrastrutture.
Opzione 6: non corretto. Problem Management include sessioni di brainstorming con il
management per cercare di identificare eventuali tendenze al fine di provare a prevenire
eventuali problemi accada.
Risposte corrette):
1. Diagnosi cause profonde degli incidenti e delle loro risoluzioni
2. Implementazione risoluzioni attraverso appropriate procedure di controllo come la
gestione del cambiamento
3. Documentare le informazioni problema e soluzioni alternative adeguate e risoluzioni
4. Condurre periodiche programmate recensioni di tronchi operativi e registri di
manutenzione
Domanda
Quali attivit supplementari rientrano nell'ambito di applicazione del Problem Management?
Opzioni:
1. Identificare e affrontare i problemi in risposta a episodi che si verificano
2. Affrontare i problemi e gli errori noti prima che possano causare incidenti
3. Sostenere Continual Service Improvement (CSI) le attivit del ciclo di vita attraverso
l'individuazione e l'attuazione di miglioramento del servizio
4. Utilizzando liste di controllo per raccogliere dati sul servizio o problemi di qualit
operativa
5. Condurre recensioni casuali di log degli eventi per identificare modelli e tendenze
6. modifiche Approvazione necessarie per affrontare i problemi
Risposta
Opzione 1: Corretto. Questo fa parte degli aspetti reattivi di Problem Management, dove si
accinge a risolvere i problemi che si presentano.
Opzione 2: Corretto. Ambito di Problem Management include un processo proattivo in cui si
propone di fermare i problemi prima che si verifichino. Questo processo continuo e migliora
la soddisfazione dell'utente finale.
165
Opzione 3: Corretto. Proattive attivit Problema di gestione comportare l'esecuzione di

un'analisi di trend che aiuta a identificare e inserire miglioramento del servizio nel CSI e
gestire le opportunit di miglioramento.
Opzione 4: Corretto. Con l'aiuto di processi problema di gestione, i dati vengono raccolti su
questioni e vengono successivamente risolti prima che possano causare ulteriori interruzioni
nel business.
Opzione 5: non corretto. Le recensioni che si svolgono durante il Problem Management sono
periodiche e in programma, che aiuta a notare i modelli e le tendenze dei potenziali problemi.
Opzione 6: non corretto. Anche se Problem Management mira ad attuare risoluzioni di
problemi, deve garantire che tutte le modifiche proposte sono autorizzati attraverso adeguate
procedure di controllo, attraverso la gestione del cambiamento e di uscita e di gestione di
distribuzione dei processi.
Risposte corrette):
1. Identificare e affrontare i problemi in risposta a episodi che si verificano
2. Affrontare i problemi e gli errori noti prima che possano causare incidenti
3. Sostenere Continual Service Improvement (CSI) le attivit del ciclo di vita attraverso
l'individuazione e l'attuazione di miglioramenti del servizio
4. Utilizzando liste di controllo per raccogliere dati sul servizio o problemi di qualit
operativa
4. riconoscendo principi
Efficace Gestione dei problemi dipende da tre principi fondamentali.
Domanda
Quali sono i principi per una efficace gestione problema?
Opzioni:
1. La creazione di modelli problematiche che definire come affrontare problemi specifici
2. Problem Management rigorosamente distinguere dalla gestione degli incidenti
3. Distribuzione di processi Problema di gestione reattiva e proattiva
4. La combinazione di Problem Management con la gestione degli incidenti
5. Usando solo i processi di gestione reattiva problema
6. La creazione di modelli problematici che definiscono come diagnosticare problemi
Risposta
Opzione 1: Corretto. Problem Management aiuta a creare modelli problematici per problemi
specifici. Questi modelli di cui fasi in sequenza da seguire per risolvere i problemi. Questo
rende pi facile e veloce per risolvere i problemi quando si verificano.
Opzione 2: Corretto. Problem Management si concentra sulla prevenzione di incidenti
accada, mentre Incident Management si concentra sul ripristino dei servizi al loro stato
normale dopo il verificarsi interruzioni del servizio.
Opzione 3: Corretto. Problem Management utilizza entrambi i processi proattivi e
reattivi. Proattivi attivit sono scatenate da attivit che mirano a migliorare i servizi e prevenire
i problemi. Attivit reattivi sono scatenate da incidenti che si sono gi verificati e concentrarsi
sulla ricerca e risolvere le cause alla base degli incidenti.
166
Opzione 4: non corretto. Problem Management e Incident Management sono due processi
separati. Problem Management si concentra in particolare sulla prevenzione di incidenti
accada, mentre Incident Management si concentra sul ripristino dei servizi, dopo le
interruzioni, al loro stato normale.
Opzione 5: non corretto. Problem Management ha bisogno di processi reattivi e proattivi cos
si risolve non solo problemi, una volta che si verificano, ma evita anche i problemi che si
verificano.
Opzione 6: non corretto. Problem Management coinvolto nella diagnosi dei
problemi. Tuttavia, lo scopo principale di creare modelli di problema di avere passi
predeterminati a portata di mano per risolvere i problemi.
Risposte corrette):
1. La creazione di modelli problematici che definiscono come affrontare problemi
specifici
2. Problem Management Rigorosamente distintivo da Incident Management
3. Distribuzione di processi Problema di gestione reattiva e proattiva
5. Identificare attivit
Un fornitore di servizi IT recentemente aggiornato un database in call center di un cliente. Tuttavia,
il service desk sta ricevendo lamentele da parte del cliente, dicendo che fino al 10% dei tentativi
per salvare le informazioni sul chiamante da parte dei rappresentanti del servizio clienti (CSR)
stanno fallendo.
Domanda
Sequenziare i primi quattro fasi del processo di gestione dei problemi in ordine.
Opzioni:
A. Il service desk si intensifica l'incidente perch sospetta un problema di fondo
B. Il service desk raccoglie precedentemente segnalato incidenti da record incidente, e
li include nel record problema
C. Il problema etichettato come "le interruzioni di servizio" da parte del gruppo IT
D. Le interruzioni sono giudicati ad essere elevato in termini di impatto e urgenza
Risposta
Risposte corrette):
Il service desk si intensifica l'incidente perch sospetta un problema di fondo classificato
rilevamento problema il primo passo nel processo di Problem Management. Ci si verifica
se, per esempio, uno o pi incidenti indicano un problema di fondo.
Il service desk raccoglie precedentemente segnalato incidenti da record incidente, e li include nel
record problema classificato
Registrare i dettagli del problema la seconda fase del processo. Questo assicura che il
problema pu essere monitorato e che un'organizzazione avr un record storico di esso
per riferirsi a pi tardi.
Il problema etichettato come "le interruzioni di servizio" di l'unit classificato
167
Categorizzare un problema il terzo passo. Questo dovrebbe essere fatto allo stesso
modo di qualsiasi incidente correlato, in base al tipo. Ad esempio, un problema potrebbe
riguardare l'interruzione del servizio o per rallentare le prestazioni.
Le interruzioni sono giudicati ad essere elevato in termini di impatto e urgenza classificato
Dare priorit il problema il quarto passo nel processo e si basa sulla sua urgenza e
potenziale impatto sul business.
Domanda
Il problema di interruzione del servizio in un call center stato rilevato, registrati, classificati, e
priorit. Sequenza i prossimi tre fasi del processo di gestione dei problemi in ordine.
Opzioni:
A. Database degli Errori Noti (KEDB) viene utilizzato per trovare la configurazione che
anche utilizzato da un altro cliente con lo stesso problema
B. Riavviare il server di rete durante il tentativo di cercare le possibili cause alla radice
C. La causa principale e le soluzioni al problema documentato
Risposta
Risposte corrette):
Database degli Errori Noti (KEDB) viene utilizzato per trovare la configurazione che anche
utilizzato da un altro cliente con lo stesso problema viene classificato
indagini problema e la diagnosi la quinta fase del processo di Problem Management. Le
cause principali e le possibili soluzioni devono essere trovate, e utilizzando il KEDB per
trovare precedenti occorrenze del problema e come stato risolto un modo di fare
questo.
Riavviare il server di rete durante il tentativo di cercare le possibili cause di fondo classificato
L'implementazione di una soluzione problema, come il riavvio del server di rete, il sesto
passo nel processo. Questo pu aiutare a ristabilire il servizio su base temporanea, mentre
trovato la causa principale o una soluzione adeguata al problema.
La causa principale e le soluzioni al problema documentato classificato
Alzando un noto record di errore il settimo passo nel processo. Documentare un
problema e di inserirlo nella KEDB importante perch simili problemi futuri possono quindi
essere identificati e risolti pi rapidamente.
Domanda
In sequenza le fasi finali del processo di gestione dei problemi.
Opzioni:
A. Riconfigurare agli utenti di connettersi al percorso di rete corretta quando firmano in
B. Verificare che il noto record di errore per una descrizione storica ricca di eventi e
chiudere il record di problema
C. Rendere personale di supporto IT a conoscenza della nota record di errore
Risposta
Risposte corrette):
168
Riconfigurare agli utenti di connettersi al percorso di rete corretta quando firmano in classificato
risoluzione dei problemi l'ottavo passo. Questa fase pu essere effettuata solo dopo
l'identificazione di risoluzione e sollevando un errore noto.
Controllare che il noto record di errore per una descrizione storica ricca di eventi e chiudere il
record di problema classificato
La nona fase del processo quello di confermare che tutte le informazioni pertinenti su un
problema stato registrato e quindi chiudere il record di problema.
Rendere personale di supporto IT a conoscenza della nota record di errore viene classificato
Il passo decimo e finale del processo quello di rivedere i principali problemi. I risultati
raccolti possono essere utilizzati per aumentare la consapevolezza dei problemi e le fasi di
come risolverli tra il personale IT di supporto possono essere resi disponibili.
6. Riepilogo
La portata e principi di Problem Management sono stati riconosciuti, e sono state identificate le
attivit problema di gestione in un determinato scenario.
7. Sommario
| Inizio pagina |
| 2. Identificare portata |
| 3. Riconoscendo principi |
Interfacce di gestione dei problemi
1.
Obiettivo di apprendimento
descrivere come Problem Management si interfaccia con altri processi del ciclo di vita del
servizio
2.
Problem Management e altri processi
Il processo di Problem Management responsabile per affrontare tutti i problemi che possono
verificarsi nelle fasi ITIL Service Lifecycle. Per fare questo in modo efficace, deve interfacciarsi
con vari processi in ciascuna delle fasi del ciclo di vita.
Grafico
Nella fase Service Strategy, Problem Management si interfaccia con la gestione finanziaria per i
servizi IT di processo. Problem Management fornisce informazioni che supporta la gestione
finanziaria, perch aiuta a valutare l'impatto - compreso l'impatto finanziario - di soluzioni
alternative e le soluzioni proposte.
169
Cos Problem Management in grado di fornire la gestione finanziaria per i servizi IT con le
informazioni circa i costi di risoluzione e prevenzione dei problemi. Queste informazioni possono
poi essere utilizzati come input nei sistemi di contabilit e bilancio, e del costo totale di propriet
(TCO) calcoli.
A sua volta, la gestione finanziaria dei servizi IT pu fornire Problem Management con informazioni
utili, compresi i risultati delle analisi del valore del dolore. Questo tipo di analisi identifica le aree
dell'infrastruttura IT in cui i problemi e gli incidenti potrebbe avere il pi grave impatto sul business.
Grafico
grafico colonna Pain intitolato visualizza un'analisi del valore. L'asse X etichettato categoria
Infrastructure (categoria incidente). Le colonne che visualizzano sono etichettati hub, switch,
router, telefoni analogici, VOIPs, VPN e telefoni cellulari. L'asse Y etichettato valore valori e
visualizza dolore da 0 a 6.000 con incrementi di 1.000. La soglia fissata a appena sotto
3.000. Le colonne che superano la soglia sono quelli per i router, VOIPs e telefoni cellulari.
Problem Management interagisce con quattro processi Service Design:
Availability Management
Availability Management aiuta a determinare come massimizzare la disponibilit dei servizi
IT - o per garantire che i livelli di disponibilit definiti nel Service Level Agreement (SLA)
sono forniti. Problem Management supporta questo processo fornendo informazioni sui
problemi che possono ridurre la disponibilit, e per risolvere questi problemi o la
generazione di metodi appropriati per lavorare intorno a loro.
Gestione della capacit
Alcuni problemi, come quelli che coinvolgono i problemi di prestazioni, possono richiedere
un'indagine da squadre di gestione della capacit. Sia Capacity Management e Problem
Management possono cooperare per diagnosticare e risolvere questi problemi. Capacity
Management svolge anche un ruolo nel prendere misure proattive per prevenire i problemi
che si verificano. Durante la pianificazione della capacit, Problem Management pu fornire
informazioni che riguardano le decisioni di capacit legate. Ad esempio, pu identificare i
problemi che potrebbero essere risolti aumentando la capacit hardware o la larghezza di
banda di un'organizzazione.
IT Service Continuity Management, e
Problem Management funge da punto di ingresso in IT Service Continuity Management in
situazioni in cui un problema significativo non viene risolto prima che cominci ad avere un
grande impatto sul business. Per esempio, un router che supporta un processo di business
chiave difettoso, ma il fabbricante pu 't consegnare un sostituto per un paio di
giorni. Problem Management sarebbe interfacciarsi con l'IT Service Continuity Management
cos un processo di correzione temporanea o pu essere implementato, al fine di garantire
un servizio continua con un minimo di interruzione o la perdita possibile per utenti e clienti.
Service Level Management (SLM)
Problem Management contribuisce a miglioramenti nei livelli di servizio che vengono
concordati e monitorati attraverso il processo di SLM. Le informazioni che fornisce possono
anche determinare il Service Level Agreement (SLA) componenti revisione utilizzato da
SLM. A sua volta, SLM fornisce i parametri che Problem Management opera all'interno
definendo obiettivi dei livelli di servizio. SLM cliente anche i livelli di servizio, che possa
contribuire identificare i problemi che dovrebbero essere risolti attraverso il Problem
170
Management.
Problem Management si interfaccia con vari processi nella fase Service Transition. Uno dei pi
importanti di questi Change Management.
Problem Management responsabile di assicurare che qualsiasi modifica elementi di
configurazione (CI) che sono necessari per risolvere i problemi sono sottoposti alla gestione del
cambiamento per l'approvazione, sotto forma di richieste di modifica (RFC).
Change Management elabora aiuto per monitorare l'andamento di questi cambiamenti. I risultati
vengono poi filtrati in processi Problem Management che sono responsabili per la correzione di
tutte le modifiche non riuscite.
Problem Management si interfaccia anche con il processo di servizio Asset and Configuration
Management (SACM) nella fase di Service Transition. Problem Management utilizza il sistema di
gestione della configurazione (CMS) che impostato e mantenuto attraverso SACM per
identificare CI difettosi e per determinare gli impatti dei problemi e risoluzioni.
Problem Management interagisce anche con il Knowledge Management - un altro processo in fase
di Service Transition. Esso utilizza il Sistema di Knowledge Management Service (SKMS) come
base del Database degli Errori Noti (KEDB), che pu contenere o integrarsi con record
problematici.
Un processo di transizione servizio finale che interagisce con il Problem Management di rilascio
e distribuzione di gestione, che responsabile per la distribuzione correzioni di problemi
nell'ambiente live.
Questo processo aiuta anche a garantire che gli errori noti associati vengono trasferiti dal KEDB
sviluppo nel vivo KEDB.
A sua volta, Problem Management aiuta a risolvere i problemi che sono causati da errori durante il
processo di rilascio e Deployment Management.
Problem Management si interfaccia anche con la fase del ciclo di vita Continual Service
Improvement (CSI).
Il verificarsi di incidenti e problemi fornisce una base per identificare le opportunit di
miglioramento del servizio e aggiungendoli al registro CSI.
Proattive attivit Problema di gestione possono anche identificare i problemi sottostanti e problemi
di servizio che, se affrontate, possono contribuire ad un aumento della qualit del servizio e
l'utente finale o la soddisfazione del cliente.
Domanda
Come funziona l'interfaccia Problem Management con altri processi Service Lifecycle?
Opzioni:
1. Consente la gestione finanziaria dei servizi IT con le informazioni sui costi di risolvere
i problemi
2. Valuta misure proattive ai problemi che Capacity Management indaga
3. Utilizza il bene del servizio e CMS per identificare CI difettosi e determinare le
risoluzioni dei problemi
4. Identifica le opportunit di miglioramento dei servizi e li aggiunge al registro CSI
5. Consente la gestione finanziaria con i sistemi di contabilit e bilancio
171
6. Fornisce SLM con i parametri di lavorare all'interno
Risposta
Opzione 1: Corretto. Problem Management interagisce con la gestione finanziaria per i
servizi IT, fornendo con le informazioni circa i costi per risolvere e prevenire i
problemi. Queste informazioni possono poi essere incorporata nei sistemi di contabilit e
bilancio.
Opzione 2: Corretto. Problem Management in grado di fornire capacit di gestione con le
informazioni sulle modifiche di capacit necessarie per superare i problemi.Capacity
Management pu anche contribuire a risolvere problemi particolari.
Opzione 3: Corretto. Problem Management utilizza il CMS mantenuta attraverso il processo
di SACM per aiutare a identificare i problemi e l'impatto di eventuali risoluzioni.
Opzione 4: Corretto. Con l'identificazione dei problemi, Problem Management aiuta a
identificare le opportunit di CSI. Inoltre, migliora i livelli di servizio per risolvere i problemi.
Opzione 5: non corretto. Problem Management si concentra sulla identificazione, la diagnosi
e risoluzione dei problemi IT. Anche se interagisce con i processi di gestione finanziaria, non
fornisce sistemi finanziari.
Opzione 6: non corretto. SLM imposta i parametri per il Problem Management di lavorare
all'interno definendo obiettivi dei livelli di servizio.
Risposte corrette):
1. Fornisce gestione finanziaria dei servizi IT con le informazioni circa i costi di
risoluzione dei problemi
2. Valuta misure proattive ai problemi che Capacity Management indaga
3. Utilizza l'attivit di servizio e CMS per identificare CI difettosi e determinare problemi
risoluzioni
4. Identifica le opportunit di miglioramento dei servizi e li aggiunge al registro CSI
3.
Riepilogo
interfacce Problema di gestione con la gestione finanziaria per i servizi IT di processo nella fase di
Service Strategy e con quattro processi in fase di Service Design - Availability Management,
Capacity Management, IT Service Continuity Management e SLM. Si interfaccia con il Change
Management, SACM, Knowledge Management, e Release e Deployment Management in fase di
Service Transition. Si interfaccia anche con la fase di CSI.
4.
Sommario
| Inizio pagina |
| 1. Problem Management e altri processi |
| Sommario |
Evento, richiesta e gestione degli accessi
172
identificare gli ambiti di Event Management, Request Fulfillment, e gestione degli accessi
2. Introduzione processi Service Operation
Oltre a Incident Management e Problem Management, altri tre processi si verificano durante la
fase di Service Operation del ITIL Service Lifecycle.
Grafico
Questi processi sono
Gestione di eventi
Un evento alcun cambiamento di stato che ha significato per la gestione di un elemento
di configurazione (CI) o un servizio IT. Lo scopo di Event Management quello di gestire gli
eventi in tutto il loro ciclo di vita. Attivit associate comprendono la rilevazione di eventi,
dare un senso di loro, e determinare e coordinare le azioni di controllo appropriate.
Richiesta Fulfillment, e
Una richiesta di servizio qualsiasi richiesta o domanda che un utente fa di
un'organizzazione IT. Molte di queste richieste sono per le azioni comuni o minori che
coinvolgono basso rischio e bassi costi, o per semplici informazioni. Richiesta Fulfillment
il processo responsabile della gestione dei cicli di vita di tutte le richieste di servizio.
gestione degli accessi
Access Management il processo di concessione di specifici utenti autorizzati i diritti di
utilizzo dei servizi, ma anche impedendo agli utenti non autorizzati di accedere ad essi. Si
tratta di esecuzione delle politiche e delle azioni definite attraverso Information Security
Management.
3. Event Management
Event Management focalizzata sulla generazione e rilevazione notifiche significativi sullo stato
delle infrastrutture e dei servizi IT di un'organizzazione.
E 'anche la base per il monitoraggio e controllo operativo. Se gli eventi sono programmati per
comunicare informazioni operative, avvertimenti, e le eccezioni al reparto IT, possono essere
utilizzati come base per l'automazione di molti operazioni di routine e le attivit di gestione.
Esempi sono l'esecuzione di script su dispositivi remoti, la presentazione di posti di lavoro per
l'elaborazione, o il bilanciamento dinamico della domanda di un servizio su pi dispositivi per
migliorare le prestazioni.
Gli obiettivi del processo di Event Management sono a
rilevare tutti i cambiamenti di stato che hanno un significato per la gestione di un servizio o
CI IT
determinare l'azione di controllo adeguate per gli eventi e assicurarsi che gli stessi sono
comunicati alle funzioni appropriate
fornire il grilletto, o punto di ingresso, per l'esecuzione di molti processi Servizio di

funzionamento e le attivit di gestione operazioni
173
fornire i mezzi per confrontare le performance operative effettive e il comportamento contro

gli standard di progettazione e Service Level Agreement (SLA), e
fornire una base per la garanzia del servizio e il reporting, e miglioramento del servizio
Event Management pu essere applicato a qualsiasi aspetto della gestione dei servizi IT che deve
essere controllata e che possono essere automatizzati. Questo comprende eventi associati
CI
Alcuni elementi di configurazione possono essere inclusi nel perimetro di Event
Management perch hanno bisogno di rimanere in uno stato costante. Ad esempio, un
interruttore di una rete pu essere necessario per rimanere su. Strumenti possono
confermare che l'interruttore non rimanere sul monitorando risposte ai ping. Altri elementi di
configurazione possono essere inclusi perch il loro stato di bisogno di cambiare
frequentemente e Event Management pu essere utilizzato per automatizzare questo
processo - ad esempio, utilizzando uno script per eseguire aggiornamenti di routine ad un
file server.
condizioni ambientali
Condizioni ambientali che vanno da fluttuazioni di temperatura a disastri naturali come i
terremoti possono generare eventi, e questi rientrano nell'ambito di applicazione di Event
Management. Ad esempio, gestione degli eventi pu includere rispondere agli avvisi che
indicano che i controlli per la regolazione della temperatura in una sala server sono falliti.
licenze software
Software monitoraggio delle licenze - per garantire un uso ottimale e legale delle licenze
software - rientra nell'ambito di applicazione di Event Management. Ad esempio, un
sistema di monitoraggio evento pu sollevare allarmi quando le licenze sul software
specifico sta per scadere.
la sicurezza, e
eventi di sicurezza rientrano nel campo di applicazione del processo di Event
Management. Ad esempio, il software di gestione eventi installato su una LAN pu
sollevare un avviso se viene rilevato un tentativo non autorizzato al di accesso alla rete.
normale attivit IT
l'attivit normale spesso rientra nell'ambito di applicazione di Event Management. Ad
esempio, Gestione eventi pu prevedere l'utilizzo di software per monitorare l'uso di una
particolare applicazione o le prestazioni di un server.
4. Richiesta Fulfillment
Richiesta Fulfillment svolge un ruolo importante nel mantenere la soddisfazione dell'utente finale,
garantendo che le richieste degli utenti siano soddisfatte nel modo pi rapido ed efficiente
possibile.
Per garantire comuni tipi di richieste sono soddisfatte entro un ragionevole lasso di tempo,
importante avere processi documentati in atto per la gestione di queste richieste.
Questo impedisce le richieste di minori da congestionare i normali processi di Incident
Management e Change Management, e un impatto negativo erogazione dei servizi in generale.
174
Gli obiettivi del processo di richiesta Fulfillment devono
mantenere utente e la soddisfazione del cliente attraverso la gestione efficiente e

professionale di tutte le richieste di servizio
fornire un canale per gli utenti di richiedere e ricevere servizi standard per i quali esiste una
procedura di autorizzazione e qualificazione predefinito
fornire informazioni agli utenti e clienti circa la disponibilit dei servizi e la procedura per
ottenerli
fonte e fornire i componenti di servizi standard richiesti, e
assistere gli utenti, fornendo informazioni di carattere generale e la gestione dei reclami
Il processo necessario per soddisfare una richiesta varier a seconda della richiesta, ma di solito
pu essere suddiviso in una serie di attivit.
Per ogni tipo di richiesta, tali attivit devono essere documentate in un modello di richiesta.
Ad esempio, pensare ad un manager che richiede i ricordi di dettagli di login per un account di
posta elettronica di lavoro usato raramente e si avvicina al reparto IT con una richiesta.
Nella organizzazione del manager, un team IT dedicato segue il modello che elenca i passi
chiedere la sostituzione del caso. Queste comprendono l'identificazione della richiesta,
consultando l'esperto appropriato e, infine, soddisfare la richiesta.
Il team ha poi registra la richiesta e mantiene i contatti con il personale amministrativo di rete per
recuperare i dati di accesso dimenticati. Il team ha poi comunica le informazioni al gestore.
Il processo di richiesta di adempimento viene gestito in modo diverso in diverse organizzazioni. Ad
esempio, le richieste di assistenza possono essere trattate come
un flusso di lavoro separato
In un'organizzazione che si occupa di richieste varie che possono richiedere conoscenze
specialistiche, richieste di servizio possono essere trattate come un flusso di lavoro
separato. Ci essenziale se un richieste e gli incidenti sono gestite da diversi gruppi di
dipendenti. Nell'esempio del gestore richiesta password, il flusso di lavoro separata un
team IT dedicato che soddisfa la richiesta.
incidenti, o
Alcune organizzazioni gestiscono le richieste di assistenza attraverso il processo di Incident
Management. Le richieste di servizio vengono gestite come un particolare tipo di incidente
pianificato - a differenza di incidenti regolari, che sono non pianificata.
la responsabilit di un service desk esteso
In alcune organizzazioni, un service desk esteso gestisce le richieste di servizio di tutti i
dipendenti. Ad esempio, questo tipo di service desk pu gestire le richieste di servizio una
fotocopiatrice o addirittura richieste associate con problemi di gestione degli edifici, come
ad esempio la sostituzione di un apparecchio di illuminazione o la riparazione di una perdita
nelle tubature.
5. Gestione Accesso
175
Lo scopo di Access Management quello di concedere diritti specifici utenti di utilizzare i servizi
specifici. Alcune organizzazioni possono fare riferimento a questo processo come Rights
Management o gestione delle identit.
Gli obiettivi del processo di Access Management devono
gestire l'accesso ai servizi basati su politiche e le azioni definite in Information Security

Management
rispondere in modo efficiente e appropriato alle richieste di concessione di accesso ai

servizi, la modifica dei diritti di accesso, o limitare l'accesso, e
sorvegliare l'accesso ai servizi e garantire che i diritti assegnati vengono utilizzati

correttamente
Il processo di Access Management esegue le politiche definite attraverso Information Security
Management. Ad esempio, si pu attuare una politica che consente solo i manager in un
dipartimento risorse umane di accedere a un'applicazione del libro paga.
Con l'implementazione di misure di sicurezza delle informazioni, Access Management consente a
un'organizzazione di gestire la riservatezza, la disponibilit e l'integrit dei propri dati, compresa la
propriet intellettuale.
Anche se Access Management assicura che gli utenti hanno i diritti appropriati per utilizzare un
servizio, Gestione disponibilit che assicura che tale accesso disponibile a tutti gli orari
concordati.
Access Management solitamente incluso in tutte le funzioni tecniche e applicative di
gestione. Tuttavia, di solito coordinato attraverso un unico punto di controllo - come ad esempio
la gestione delle operazioni IT o un service desk.
Una richiesta di servizio pu avviare Access Management - per esempio, se un dipendente
richieste diritti di informazione o servizi specifici in una rete aziendale.
Domanda
Quali esempi rientrano nel ambiti di Event Management, Request Fulfillment, e gestione degli
accessi?
Opzioni:
1. Configurazione di un'applicazione per sollevare un avviso di protezione in risposta a
qualsiasi tentativo non autorizzato di accedere a una rete
2. Impostazione di una specifica unit di rete per memorizzare work-in-progress file
grafici
3. Riparazione di alimentazione danneggiata di un server che ha causato una rete
aziendale a crash
4. La creazione di un ufficio LAN per consentire solo senior manager l'accesso all'unit
di rete che contiene i record dei dipendenti
5. L'eliminazione di una e-mail sospette per prevenire possibili infezioni da virus
Risposta
Opzione 1: Corretto. Un evento un qualsiasi cambiamento che ha un significato per un
servizio IT, in modo da un avviso di protezione che viene prodotto ricadrebbe nell'ambito di
applicazione di Event Management.
176
Opzione 2: Corretto. Qualsiasi richiesta al service desk IT costituisce una richiesta di

servizio. Una richiesta di spazio su disco in pi su una rete potrebbe rientrare nell'ambito di
applicazione del Service Request Fulfillment.
Opzione 3: non corretto. Un aumento di potenza che interrompe i servizi sarebbe stato
classificato come un incidente e essere affrontata dal processo di Incident Management.
Opzione 4: Corretto. Una politica che concede solo determinati utenti l'accesso alle
informazioni o di un servizio rientra nell'ambito di applicazione di Access Management.
Opzione 5: non corretto. Qualcosa che ha il potenziale di causare il servizio IT interrotto
viene solitamente classificato come un incidente e rientra nell'ambito di applicazione di
Risposte corrette):
1. Configurare una richiesta di sollevare un avviso di sicurezza in risposta a qualsiasi
tentativo non autorizzato di accedere a una rete
2. Impostazione di una specifica unit di rete per memorizzare work-in-progress file
grafici
4. La creazione di un ufficio LAN per consentire solo senior manager l'accesso all'unit
di rete che contiene i record dei dipendenti
6. Riepilogo
Event Management, Request Fulfillment, e gestione degli accessi sono processi si trovano in fase
di Service Operation del ciclo di vita. ITIL Servizio
Event Management si propone di gestire gli eventi attraverso il loro ciclo di vita, tra cui CSI, le
condizioni ambientali, il monitoraggio delle licenze software, la sicurezza, e la normale attivit IT .
Richiesta Fulfillment copre tutte le richieste di servizio utente al dipartimento IT, e mira a
mantenere la soddisfazione degli utenti dei servizi che forniscono e informazioni.Access
Management fornisce diritti selettivi a informazioni e servizi a utenti specifici all'interno di un
contesto organizzativo.
7. Sommario
| Inizio pagina |
| 1. L'introduzione di processi di Service Operation |
| 2. Event Management |
| 3. Richiesta Fulfillment |
| 4. Access Management |
| Sommario |
|
CSI Scope
177
individuare i vantaggi a un business di adozione e l'attuazione di serie e gli approcci

coerenti per CSI
identificare le considerazioni chiave per l'attuazione di CSI

2. Considerazioni di attuazione CSI
Secondo ITIL, Continual Service Improvement (CSI) la fase del ciclo di vita di servizio che
coinvolge individuare e attuare miglioramenti ai servizi IT che supportano i processi di business. In
questo modo, si contribuisce a garantire che i servizi IT vengano allineate alle esigenze di
business in continua evoluzione.
Grafico
Un diagramma che rappresenta l'ITIL Service Lifecycle mostra il Service Design, Service
Operation, e le fasi di Service Transition Service Strategy circostanti. Continual Service
Improvement uno strato finale, che comprende tutte le altre fasi.
CSI si basa su principi, pratiche e metodi da processi come la gestione della qualit, Change
Management e Capacity Management, combinando questi per migliorare le prestazioni in tutte le
fasi del ciclo di vita di servizio.
Durante tutta la fase di CSI, la performance di un fornitore di servizi IT continuamente misurata e
miglioramenti sono fatti per i processi, servizi IT, e, ove necessario, l'infrastruttura IT. Questo pu
portare ad un miglioramento della qualit dei servizi IT, l'efficienza operativa e una migliore
efficienza dei costi.
CSI ha diversi obiettivi:
rivedere, analizzare, priorit, e formulare raccomandazioni per il miglioramento nelle fasi

del ciclo di vita
rivedere e analizzare i risultati dei livelli di servizio
individuare e attuare le attivit per migliorare la qualit del servizio IT
migliorare l'efficienza e l'efficacia dei processi che consentono la fornitura di servizi IT
migliorare l'efficacia dei costi dei servizi IT senza compromettere la soddisfazione del
cliente
garantire che i metodi di gestione appropriati di qualit sono utilizzati per sostenere le
attivit di miglioramento, e
garantire che i processi hanno obiettivi chiaramente definiti e che i progressi verso il
raggiungimento di questi possono essere misurati
La fase di CSI dovrebbe usare un sistema di feedback "circuito chiuso" che si basa sul ciclo di
Deming.
Grafico
Il cyle Deming rappresenta il piano, fare, controllare, e di agire ciclo. Essa mostra un continuo
controllo della qualit e di consolidamento. L'asse verticale etichettato livello di maturit, e
l'asse orizzontale etichettato scala temporale. C' una linea crescente del livello di maturit
e scala temporale che mostra Business e IT allineamento. Vi una freccia in prossimit della
partenza della linea che mostra il consolidamento di sopra di questo, si trova un ciclo che
178
inizia con il piano, in alto a destra, poi andare in senso orario, fare, controllare e
agire. Esempi di un "piano" sarebbe un piano di progetto, "do" sarebbe un progetto, "check"
sarebbe un audit, e "agire" sarebbe nuove azioni.
Attraverso questo sistema di feedback, l'uscita o il feedback da qualsiasi fase del Service Lifecycle
possono essere utilizzati per identificare le opportunit di miglioramento per ogni altra fase. Ad
esempio, le uscite dal processo di Problem Management - che fa parte della fase di Service
Operation - possono indicare la necessit di un miglioramento del servizio di disegno o fasi di
transizione di servizio.
Tutte le iniziative CSI dovrebbero avere finalit e gli obiettivi chiaramente definiti.
Si dovrebbe anche assicurare che il successo di ogni iniziativa di miglioramento del servizio pu
essere adeguatamente misurato in termini di successo o il fallimento nel raggiungimento degli
obiettivi specificati.
Questi passaggi aiutano a garantire che le risorse non sono sprecati in iniziative di miglioramento
che non sono realmente necessari. Questo approccio permette anche di quantificare i risultati di
eventuali sforzi di miglioramento.
Un'altra considerazione importante in sede di attuazione CSI che fondamentale per capire
cosa misurare e perch, cos come quello che il buon esito di una iniziativa di miglioramento
dovrebbe essere.
Senza questa comprensione, le conclusioni si raggiunge su ci che sono necessari miglioramenti,
e circa il successo o il fallimento di questi miglioramenti, una volta che sono stati attuati,
potrebbero non essere validi.
Domanda
Quali sono considerazioni chiave, nell'attuazione del CSI?
Opzioni:
1. miglioramento dei servizi dovrebbero avere obiettivi chiaramente definiti
2. Un sistema di retroazione ad anello chiuso deve essere usato
3. Uscita da qualsiasi fase dovrebbe essere in grado di identificare le opportunit di
miglioramento per ogni altra fase.
4. E 'fondamentale sapere che cosa misurare e perch
5. Si dovrebbe allineare i processi di business basati su servizi disponibili
6. Si dovrebbe garantire che i servizi IT siano consegnati in tempo per il cliente
Risposta
Opzione 1: Corretto. CSI assicura che i miglioramenti del servizio sono implementate, gestite
e supportate utilizzando obiettivi chiaramente definiti, gli obiettivi e le misure.
Opzione 2: Corretto. CSI dovrebbe utilizzare un sistema di retroazione ad anello chiuso
simile al ciclo Deming.
Opzione 3: Corretto. CSI dovrebbe assicurare che l'uscita da qualsiasi fase del Service
Lifecycle pu avvisare un'organizzazione per la necessit di un miglioramento in qualsiasi
altro stadio.
Opzione 4: Corretto. Efficace CSI dipende da sapere che cosa misurare per misurare il
successo delle iniziative di miglioramento, e perch. In caso contrario, le conclusioni circa gli
sforzi di miglioramento possono essere validi.
179
Opzione 5: non corretto. Un obiettivo del CSI quello di allineare i servizi IT con le esigenze
di business degli utenti del servizio, attraverso l'individuazione e l'attuazione di miglioramento
del servizio che supportano i processi di business.
Opzione 6: non corretto. CSI misura l'erogazione dei servizi e attua misure per
migliorarla. Tuttavia, non gestisce consegna effettiva.
Risposte corrette):
1. il miglioramento dei servizi dovrebbero avere obiettivi chiaramente definiti
2. Un sistema di retroazione ad anello chiuso deve essere utilizzato
3. Uscita da qualsiasi fase dovrebbe essere in grado di identificare le opportunit di
miglioramento per qualsiasi altra fase.
4. E 'fondamentale sapere che cosa misurare e perch
3. I vantaggi di CSI
CSI fornisce una guida di buone pratiche in quattro aree principali.
In primo luogo si fornisce indicazioni sulla salute generale di IT Service Management come
disciplina.
Fornisce inoltre un continuo allineamento del Service Portfolio IT alle esigenze di business attuali e
future degli utenti dei servizi.
CSI fornisce anche indicazioni per la maturit e la capacit del fornitore di servizi IT e la sua
gestione di supporto, processi e persone.
Ultimo ma fornisce una guida per il miglioramento continuo di tutti gli aspetti dei servizi IT e le
attivit di servizio che li supportano.
CSI dipende dieci attivit di supporto. I primi cinque attivit comprendono
rivedere le informazioni di gestione e le tendenze al fine di garantire che i servizi IT sono

riuniti i livelli di servizio concordati
rivedere informazioni di gestione e andamento per assicurare che l'uscita dei processi che
consentono stanno raggiungendo i risultati desiderati
condurre valutazioni di maturit per dimostrare aree di miglioramento, cos come aree di
interesse
condurre gli audit interni per verificare la conformit dei dipendenti e dei processi, e
la revisione deliverable esistenti per adeguatezza
I restanti cinque attivit di supporto includono
proponendo raccomandazioni per le opportunit di miglioramento
lo svolgimento di indagini di customer satisfaction
rivedere le tendenze di business e le priorit modificate per stare al passo con le proiezioni
di business
lo svolgimento di recensioni esterne ed interne di servizio per identificare le opportunit di
CSI, e
misurare e identificare il valore creato da miglioramenti CSI

180
Gli individui all'interno dell'organizzazione devono possedere tali attivit di sostegno. Questi
individui dovrebbe avere il potere e l'autorit per garantire che le attivit sono programmate,
pianificate e condotte quando sono ritenute necessarie.
deliverable CSI dovrebbero essere riviste su base continuativa. Questo viene fatto per verificare la
loro completezza, funzionalit, e la fattibilit, e per garantire che rimangano attuali e rilevanti, e non
diventano obsoleti e inutilizzabili.
Allo stesso modo, l'organizzazione ha bisogno di monitorare i propri indicatori di qualit e le misure
per garantire che in grado di identificare potenziali opportunit di miglioramento.
Perch ogni iniziativa miglioramento sar pi che probabile necessarie modifiche, miglioramenti
specifici dovranno seguire il processo di Change Management definito.
Per un'organizzazione, l'adozione e l'attuazione di standard ed approcci coerenti per CSI ha diversi
vantaggi:
porta a continui miglioramenti della qualit del servizio e la soddisfazione del cliente
assicura che i servizi IT vengano allineate alle esigenze di business
aumenta l'efficacia dei costi del servizio di provisioning riducendo i costi o l'attivazione di
un'organizzazione di gestire pi lavoro allo stesso costo
utilizza il monitoraggio e il reporting per identificare potenziali opportunit di miglioramento

in tutte le fasi del ciclo di vita, e
identifica le opportunit di migliorare la struttura di un'organizzazione, le capacit di risorse,

i partner, la tecnologia, le competenze del personale e la formazione, e le comunicazioni
Domanda
Quali sono i vantaggi di CSI?
Opzioni:
1. Esso consente il miglioramento della qualit del servizio continuo
2. Assicura che i servizi IT siano sempre allineati con i requisiti di business
3. Migliora l'efficacia dei costi
4. Essa aiuta a identificare le opportunit di miglioramento in tutte le fasi del ciclo di vita
5. Esso fornisce uno standard formale e universale per le capacit di controllo di
gestione di servizi
6. Esso individua le opportunit di miglioramento organizzativo
7. Esso fornisce informazioni sui costi e benefici dei servizi IT a un cliente
Risposta
Opzione 1: Corretto. CSI permette ad un'organizzazione di apportare continui miglioramenti
ai propri servizi, con conseguente aumento della soddisfazione dei clienti.
Opzione 2: Corretto. CSI aiuta a garantire che Portfolio servizio di un fornitore di servizi IT
in linea con le esigenze di business degli utenti del servizio e dei clienti.
Opzione 3: Corretto. CSI pu aumentare l'efficacia dei costi dei servizi, riducendo i costi e
permettendo un fornitore di servizi per gestire pi lavoro allo stesso costo.
181
Opzione 4: Corretto. CSI consente all'organizzazione di utilizzare il monitoraggio e il

reporting per identificare potenziali opportunit di miglioramento in tutte le fasi del ciclo di vita
di servizio.
Opzione 5: non corretto. Il focus di CSI sull'identificazione e l'attuazione di miglioramento
del servizio, non sui processi di controllo di gestione di servizio.
Opzione 6: Corretto. CSI permette ad un'organizzazione di identificare le opportunit di
migliorare la sua struttura, le capacit di risorse, i partner, la tecnologia, le competenze del
personale e la formazione, e le comunicazioni.
Opzione 7: non corretto. CSI non identifica i costi del servizio o benefici per i clienti. In
generale, un'analisi costi-benefici che far. Se adottato in modo coerente, CSI pu migliorare
continuamente i processi, servizi IT e infrastruttura IT e cos aumentare l'efficienza e
l'efficacia.
Risposte corrette):
1. Permette servizio continuo miglioramento della qualit
2. Assicura che i servizi IT siano sempre allineati con i requisiti di business
3. Migliora l'efficacia dei costi
4. Essa aiuta a identificare le opportunit di miglioramento in tutte le fasi del ciclo di vita
6. Esso individua le opportunit di miglioramento organizzativo
4. Riepilogo
La fase CSI del Service Lifecycle identifica e implementa continui miglioramenti ai servizi IT che
supportano i processi di business. In questo modo, si contribuisce a garantire che i servizi IT
rimangano allineati alle mutevoli esigenze di business. Considerazioni di attuazione CSI includono
l'utilizzo di un circuito chiuso di feedback basato sul ciclo di Deming, assicurando che tutte le
iniziative di miglioramento del servizio hanno chiaramente gli obiettivi definiti, e capire che cosa
misurare e perch per determinare il successo delle iniziative di miglioramento. Per le
organizzazioni, i benefici derivanti dall'adozione coerente , processi standardizzati CSI sono
continui miglioramenti della qualit del servizio, l'allineamento dei servizi IT con i requisiti di
business, una maggiore efficacia dei costi, e l'identificazione delle opportunit di miglioramento in
tutte le fasi ei processi del ciclo di vita. CSI pu anche aiutare le organizzazioni a identificare le
opportunit di migliorare la loro struttura, le capacit di risorse, i partner, la tecnologia, le
competenze del personale e la formazione, e le comunicazioni.
5. Sommario
| Inizio pagina |
| 1. Considerazioni di attuazione CSI |
| 2. Vantaggi della CSI |
| Sommario |
Il Registro CSI
182
riconoscere le informazioni tipico che dovrebbero essere incluse in un registro CSI
identificare le considerazioni chiave per l'utilizzo di registro CSI

2. Scopo e vantaggi del registro CSI
fornitori di servizi IT possono identificare i modi per migliorare la loro qualit del servizio e la
consegna in base alle loro proprie indagini, o in risposta a clienti e utenti lamentano problemi o
miglioramenti richiedono.
Un'attivit importante nella fase di Continual Service Improvement (CSI) del Service Lifecycle sta
registrando tutte le opportunit di miglioramento e le loro informazioni in un registro CSI. Un
registro CSI un database o un documento strutturato utilizzato per registrare e gestire le
opportunit di miglioramento in tutto il loro ciclo di vita.
Grafico
Il registro CSI serve quattro scopi principali:
uno strumento per registrare tutte le opportunit di miglioramento
Un registro CSI permette di tenere traccia di tutte le opportunit di miglioramento del
servizio e le iniziative collegate in tutto il loro ciclo di vita. Quindi fornisce CSI con un
approccio strutturato per la registrazione, il monitoraggio e la revisione sforzi di
miglioramento del servizio all'interno di un'organizzazione e le sue varie divisioni.
uno strumento per classificare le opportunit di miglioramento
Un registro CSI permette di categorizzazione di tutte le opportunit di miglioramento del
servizio in termini di scala, sulla base di quanto sforzo faranno richiedere l'attuazione. Si
classifica anche le opportunit di miglioramento in base al fatto che richiedono risposte nel
breve, medio o lungo termine. Questo aiuta a rendere pi chiaro il modo migliore per
priorit le iniziative di miglioramento e di allocare le risorse. Se necessario, la priorit di una
particolare opportunit di miglioramento pu essere cambiata - per esempio, se Problem
Management rende chiaro che un miglioramento necessario per risolvere un problema
che significativamente interessano erogazione del servizio.
si tratta di uno strumento per catalogare i benefici che si possono ottenere mediante
l'attuazione di iniziative di miglioramento, e
Parte di ci che un CSI record registro i benefici potenziali connessi con l'attuazione ogni
miglioramento del servizio proposto o iniziativa. Quindi rende chiaro quali siano gli obiettivi
delle iniziative di miglioramento sono. Il progresso di iniziative nel fornire i benefici previsti
pu quindi essere misurato e quantificato.
fornisce una coordinata, vista coerente di tutte le attivit di miglioramento
Nel corso di un dato periodo, un'organizzazione potrebbe essere necessario rispondere a
un numero potenzialmente elevato di opportunit di miglioramento - e questi pu riguardare
diversi servizi, reparti e aree di business. Utilizzando un registro CSI permette di monitorare
e valutare tutte le opportunit di miglioramento in modo che gli sforzi di miglioramento
possono essere coordinati e le risorse possono essere allocate in modo appropriato.
183
Idealmente un manager dedicato CSI dovrebbe essere responsabile per la produzione e la

manutenzione di un registro CSI. Questo aiuta a garantire che un approccio coerente stata
utilizzata e che la necessit di aggiornare il registro non trascurato.
Domanda
Qual lo scopo di un registro CSI?
Opzioni:
1. Per registrare tutte le opportunit di miglioramento
2. Per classificare le opportunit di miglioramento
3. Per catalogare i benefici che le iniziative di miglioramento dovrebbero fornire
4. Per fornire una visione coordinata e coerente delle attivit di miglioramento di
un'organizzazione
5. Per sollevare le priorit delle iniziative di miglioramento specifici automaticamente
6. Per garantire che tutto il personale di produzione e manutenzione partecipano
registrazione opportunit di miglioramento
Risposta
Opzione 1: Corretto. Il registro CSI viene utilizzato per registrare i dettagli di tutte le
opportunit di miglioramento del servizio individuate all'interno di un'organizzazione. Quindi
rende possibile monitorare, coordinare, valutare e quantificare gli sforzi di miglioramento
generale di un'organizzazione.
Opzione 2: Corretto. Il registro CSI viene utilizzato per classificare le opportunit di
miglioramento dei servizi in base alle loro dimensioni, o dimensione, cos come se si
applicano nel breve, medio o lungo termine. Questo rende pi facile dare la priorit iniziative
di miglioramento e di allocare le risorse.
Opzione 3: Corretto. Il registro CSI viene utilizzato per registrare i benefici che ogni iniziativa
miglioramento del servizio destinato a fornire. In questo modo possibile misurare e
quantificare il successo di ogni iniziativa.
Opzione 4: Corretto. Un registro CSI viene utilizzato per registrare i dettagli di iniziative di
miglioramento del servizio di un'organizzazione. In questo modo possibile coordinare gli
sforzi di miglioramento e valutare gli sforzi in diversi settori che utilizzano un approccio
coerente.
Opzione 5: non corretto. I singoli membri del personale sono costretti ad alzare le priorit
delle iniziative di miglioramento. Ci non avviene automaticamente.
Opzione 6: non corretto. Un manager CSI dedicato deve gestire la produzione e la
manutenzione del registro di CSI per garantire un approccio coerente.
Risposte corrette):
1. Per registrare tutte le opportunit di miglioramento
2. Per classificare le opportunit di miglioramento
3. Per catalogare i benefici che le iniziative di miglioramento dovrebbero fornire
4. Per fornire una visione coordinata e coerente delle attivit di miglioramento di
un'organizzazione
Il registro CSI contiene informazioni importanti per i fornitori di servizi e cos dovrebbe essere
considerato come parte del servizio generale di un'organizzazione Knowledge Management
System (SKMS).
184
Il SKMS l'insieme di strumenti e banche dati che un fornitore di servizi IT utilizza per gestire le
conoscenze, informazioni e dati necessari per gestire l'intero ciclo di vita di tutti i servizi informatici.
Come altri componenti dei SKMS, come il sistema di gestione della configurazione (CMS), il
registro CSI dovrebbe essere adeguatamente aggiornato e mantenuto.
Un'altra procedura quello di garantire che, per ogni iniziativa miglioramento registrato, adatti Key
Performance Indicator (KPI) sono identificati nel registro CSI. Si tratta di metriche per misurare se
l'iniziativa fornire i principali vantaggi desiderati.
Ad esempio, un KPI un'iniziativa che comporta un aumento della larghezza di banda totale
disponibile agli utenti della rete potrebbe essere la velocit media di trasmissione dei dati sulla
rete. Il KPI fornisce un modo concreto e oggettivo per valutare il successo o il fallimento
dell'iniziativa.
L'uso di KPI pu aiutare a migliorare e quantificare le prestazioni complessive del CSI.
Una best practice finale quello di definire l'interfaccia tra il registro CSI e altri processi nel Service
Lifecycle. Le informazioni registrate nel registro dovrebbe informare i processi in altre fasi del ciclo
di vita.
Grafico
Le interfacce registro CSI con Change Management, Problem Management e Capacity
Management.
Allo stesso modo, le uscite di processi come Change Management, Problem Management e
Capacity Management dovrebbe far scattare l'ingresso di nuove opportunit di miglioramento nel
registro quando ha senso.
I risultati delle valutazioni Servizio sono anche suscettibili di tradursi in richieste di miglioramento
che dovrebbero essere iscritti nel registro CSI.
ITIL non prevede regole severe su come il registro di CSI deve essere formattato o su
esattamente quali informazioni esso dovrebbe includere. Invece, ogni organizzazione deve
valutare le proprie esigenze e creare un registro di CSI che si adatta i propri scopi.
Domanda
Quali sono le migliori pratiche per l'utilizzo di un registro di CSI?
Opzioni:
1. Trattarlo come parte del SKMS
2. Usatelo per registrare KPI adatti per ogni occasione di miglioramento
3. Definire le interfacce tra il registro di CSI e altri processi
4. Assicurarsi che il registro CSI riflette e solo influenza le attivit CSI
5. Formattare il registro CSI utilizzando ITIL linee guida
Risposta
Opzione 1: Corretto. Il registro CSI contiene informazioni importanti per un fornitore di servizi
IT e cos deve essere trattata come parte del SKMS generali dell'organizzazione. E
'importante aggiornare e mantenere correttamente.
Opzione 2: Corretto. Il registro CSI dovrebbe identificare KPI appropriati per misurare il
successo di ogni iniziativa di miglioramento nel raggiungimento degli obiettivi
specifici. Questo cos che il progresso pu essere quantificata e monitorata.
185
Opzione 3: Corretto. importante garantire che le informazioni registrate nel registro informa
processi in altre fasi del ciclo di vita. Allo stesso modo, le uscite di processi come Problem
Management, Capacity Management e Change Management dovrebbero portare alla
identificazione di nuove opportunit di miglioramento.
Opzione 4: non corretto. Gli esiti di processi come Problem Management, Capacity
Management e Change Management dovrebbe far scattare l'ingresso di nuove opportunit di
miglioramento nel registro. Le iscrizioni nel registro dovrebbero anche influenzare altri
processi.
Opzione 5: non corretto. ITIL non specifica esattamente come formattare il registro
CSI. Invece, ogni organizzazione dovrebbe valutare le proprie esigenze e creare un registro
di CSI che si adatta alle sue finalit.
Risposte corrette):
1. Trattarlo come parte del SKMS
2. Usatelo per registrare KPI adatti per ogni occasione di miglioramento
3. Definire le interfacce tra il registro di CSI e altri processi
3. Le informazioni contenute nel registro CSI
Un registro CSI richiede in genere un formato elettronico. Ad esempio, pu essere un database o
un foglio. Tuttavia, le organizzazioni pi piccole possono tenere un registro di carta.
Anche se ogni organizzazione dovrebbe determinare il layout e il formato del CSI registrazione che
utilizza, alcuni tipi di informazioni devono essere inclusi.
numero opportunit
Il numero di opportunit un numero di riferimento che viene assegnato a una voce nel
registro CSI. Idealmente, esso dovrebbe identificare l'ordine dei record nel registro in base
a quando sono stati inseriti.
Ad esempio, le opportunit di miglioramento possono semplicemente essere numerati in
ordine cronologico, a partire da 1.
data sollevato
La data sollevata la data in cui l'opportunit di miglioramento o l'iniziativa stato immesso
prima nel registro CSI. In alternativa, pu indicare quando il problema che richiede
miglioramento stato identificato per la prima.
La data sollevata in questo esempio il gennaio 4.
Dimensione
Le dimensioni si riferisce alla scala di un miglioramento o iniziativa necessaria, basata su
quanto lavoro e lo sforzo richieder. In generale, una voce nel registro classificato come
piccole, medie o grandi dimensioni.
Le dimensioni in questo esempio piccolo.
Tempistica
In un campo lasso di tempo, si registra il tempo stimato che ci vorr per completare un
miglioramento o iniziativa, o per risolvere un problema specifico. Spesso un'iniziativa di
miglioramento classificato semplicemente come di breve, medio, o la durata a lungo
termine.
Il lasso di tempo in questo esempio breve.
186
Il registro CSI dovrebbe includere una descrizione di ogni possibilit di miglioramento o di

emissione e, quando possibile, dei suoi probabili cause.
Grafico
A titolo di esempio, la descrizione inserita per una particolare opportunit di miglioramento
"Un certo numero di fallimenti si sono verificati in sede di attuazione applicazioni nuove o
aggiornate. Ci stato causato dalla procedura di test in rilascio e distribuzione utilizzando
dati di test out-of-date. Il requisito quello di aggiornare i dati di prova in prova repository
4371. "
Informazioni derivate da Change Management, Problem Management, o Capacity Management
pu anche essere menzionata qui per indicare quali processi sono necessari o sono coinvolti nella
questione.
Un campo di priorit dovrebbe indicare come urgente necessario un miglioramento da
attuare. Ad esempio, utilizzando un codice da 1 a 4, con 1 indicante urgente e 4 indica la priorit
pi bassa. Questo aiuta a garantire che i problemi pi gravi sono riconosciuti e trattati in primo
luogo, dato limiti delle risorse disponibili.
Un campo metrica KPI dovrebbe elencare uno o pi opportuni KPI per misurare il successo di ogni
iniziativa di miglioramento.
Grafico
Come esempio, il KPI per il problema relativo fallimenti quando aggiornamento o sono
implementati nuove applicazioni la riduzione percentuale n in guasti.
E 'anche utile per fornire un campo Giustificazione per spiegare la scelta di un particolare metrica
KPI - o per giustificare la necessit di una particolare iniziativa di miglioramento sulla base dei
benefici che essa avr.
Grafico
Per il problema che coinvolge gli errori quando aggiornate o sono implementate nuove
applicazioni, la giustificazione per un miglioramento elencato come "Significativa riduzione
fallimenti dopo la transizione e la conseguente impatto sul business."
Tre ulteriori campi sono utile includere nel registro CSI.
sollevata da
utile registrare il nome della persona che per primo ha sollevato la iniziativa di
miglioramento. Per esempio, questo potrebbe essere un dipendente che ha scoperto un
modo un sistema potrebbe funzionare meglio.
In questo esempio, E. King sollevato l'iniziativa di miglioramento.
Per essere azionato da
E 'importante specificare chi responsabile di garantire che ogni miglioramento
implementato, per garantire che i miglioramenti necessari non siano trascurati o messo da
parte.
In questo esempio, R. Bergman sar responsabile per l'attuazione dell'iniziativa di
miglioramento.
Data richiesto dalla
Se del caso, un registro CSI dovrebbe registrare la data entro la quale il miglioramento
deve essere completato, ha implementato, o un problema completamente risolto.
La data richiesta dal, in questo esempio, il 14 gennaio.
187
Domanda
Abbinare i campi registro CSI a descrizioni di ci che sono abituati a registrare.
Opzioni:
A. KPI metrica
B. Priorit
C. sollevata da
D. Dimensione
E. Tempistica
F. numero opportunit
obiettivi:
1. La statistica o il valore utilizzati per misurare l'efficacia di una iniziativa di
miglioramento
2. Una parola o il codice di identificazione del grado di urgenza di ogni miglioramento o
iniziativa
3. La persona che per primo ha identificato l'iniziativa di miglioramento
4. L'entit del lavoro o sforzo richiesto per implementare un miglioramento
5. Il periodo di tempo che ci vorr per implementare ogni miglioramento
6. Un numero assegnato ad un problema a seconda di quando stata inserito nel
registro
Risposta
Il registro CSI dovrebbe registrare una o pi appropriate metriche KPI per ogni opportunit di
miglioramento elencato. Le metriche saranno poi utilizzati per misurare il successo dei
miglioramenti.
Il campo Priority indica quanto sia urgente ogni miglioramento registrato . Ad esempio, si
pu utilizzare un codice da 1 a 4 per fare questo, con 1 indicando un'alta priorit e 4 indica
bassa priorit.
Il Raised by campo dovrebbe identificare la persona che ha originariamente identificato il
problema che richiede un miglioramento. Questo pu o non pu essere la stessa come la
persona che per primo registra il problema nel registro.
Il campo Size indica la scala, o la portata, di un miglioramento richiesto, sulla base di quanto
lavoro sar necessario.
Il campo scala temporale pu indicare la durata probabile di un'iniziativa di miglioramento. Ad
esempio, un miglioramento pu avere a verificarsi nel breve, medio o lungo periodo.
Il campo numero di opportunit utilizzato per registrare ogni problema che viene inserito nel
registro. Il primo numero in un registro CSI viene assegnato il numero 1.
Risposte corrette):
188
Obiettivo 6 = Opzione F
Domanda
Abbinare i restanti campi registro CSI a descrizioni di ci che essi registrano.
Opzioni:
A. data sollevato
B. Descrizione
C. Giustificazione
D. Per essere azionato da
E. Data richiesto dalla
obiettivi:
1. Quando un'iniziativa di miglioramento stato notato e iscritto nel registro
2. Dettagli dell'iniziativa miglioramento
3. I benefici derivanti dall'applicazione di ogni miglioramento
4. La persona responsabile di ogni miglioramento
5. Il termine ultimo per l'attuazione del miglioramento
Risposta
E 'utile per registrare la data in cui l'opportunit di miglioramento sollevata prima in modo da
poter tenere traccia del tempo impiegato per affrontarlo.
Il registro CSI dovrebbe fornire una descrizione di ogni possibilit di miglioramento, compresa
la natura di eventuali questioni affrontate e, se necessario, le cause di eventuali problemi.
Per giustificare la necessit di miglioramenti, possibile registrare i benefici che porter una
volta attuate.
E 'importante assegnare a qualcuno per garantire che ogni miglioramento attuato e
adeguatamente monitorati. Si dovrebbe anche identificare questa persona nel registro CSI.
La data richiesta dal campo pu essere utilizzato per specificare la data entro la quale ogni
miglioramento dovrebbe essere attuato.
Risposte corrette):
4. Riepilogo
Un registro CSI uno strumento che pu essere utilizzato per registrare e catalogare tutte le
opportunit di miglioramento all'interno di un'organizzazione. Esso fornisce una visione coerente di
queste opportunit e ti permette di catalogare i benefici connessi con la loro attuazione. Il registro
CSI dovrebbe essere considerato come parte del SKMS generale di un'organizzazione. Si deve
identificare appropriate KPI per misurare il successo delle iniziative di miglioramento, e dovrebbe
fornire una interfaccia definita tra CSI e altri processi e iniziative strategiche. I campi normalmente
inclusi in un registro CSI includere il numero di opportunit, la data sollevato, dimensioni, tempi,
189
descrizione, priorit, KPI metrica, la giustificazione, sollevata da, per essere azionato da, e la data
richieste dalla.
5. Sommario
| Inizio pagina |
| 1. Scopo e vantaggi del registro CSI |
| 2. Le informazioni contenute nel registro CSI |
| Sommario |
190
191
Introduzione al processo di CSI
1.
obiettivi formativi
riconoscere come il ciclo di Deming si integra con il processo di miglioramento sette fasi
CSI
identificare lo scopo di utilizzare il processo di miglioramento sette fasi CSI
2.
CSI e il ciclo di Deming
Molte attivit devono essere completate per garantire un'efficace Continual Service Improvement
(CSI) attraverso il Service Lifecycle.
ITIL prescrive un processo di miglioramento sette fasi per l'integrazione di queste attivit. Il
processo prevede l'individuazione, la definizione, la raccolta, l'elaborazione, l'analisi, la
presentazione, e quindi l'attuazione dei miglioramenti del servizio.
Questo processo si integra con il ciclo di Deming di fornire affidabili e miglioramenti del servizio in
corso.
Il ciclo di Deming, noto anche come il ciclo PDCA comprende quattro fasi, ognuna delle quali
mappe per specifiche attivit di CSI nel processo di miglioramento sette fasi.
Grafico
Il diagramma ciclo di Deming costituito da una freccia circolare che va in senso orario. Il
Piano parola al top della freccia, Do si trova sulla destra, controllo nella parte inferiore, e
agire sulla sinistra.
Piano
Il passo Piano prevede l'identificazione della visione, esigenze aziendali, e gli obiettivi
operativi e strategici di guida la necessit di miglioramenti. Una volta che questi sono in
atto, possibile identificare le opportunit di miglioramento specifici ed i loro associati Key
Performance Indicators (KPI) per la misura.
I collegamenti passo piano per le prime due serie di attivit di CSI. In primo luogo
identificare la strategia di miglioramento, tra cui la visione, esigenza aziendale, la strategia,
gli obiettivi tattici, e gli obiettivi operativi. In secondo luogo, definire ci che si misura.
Fare
Il passo Do prevede la raccolta di dati grezzi dalle operazioni di servizio e quindi
l'elaborazione di questi dati, utilizzando fattori critici di successo (QCS) per garantire che
tutto questo viene valutata nello stesso contesto.
I collegamenti passo fare per la terza e quarta serie di attivit di CSI. In terzo luogo
raccogliere i dati chiedendo chi, come, e cosa, e sviluppare criteri per valutare l'integrit dei
dati, obiettivi operativi, e la misurazione del servizio. Quarto processo dei dati di scoprire la
frequenza, formato, strumenti e sistemi, e la precisione.
Dai un'occhiata
Il check fase prevede l'analisi dei dati preparati per rivelare le tendenze di business e il
successo o il fallimento della strategia determinata nel passo Piano. quindi possibile
comunicare i dati analizzati e le conclusioni circa l'efficacia degli sforzi di miglioramento dei
servizi per i soggetti interessati.
I collegamenti Controllare passo verso la quinta e la sesta serie di attivit di CSI. Quinto
192
analizzare le informazioni ed i dati rispondendo alle domande sulle tendenze, gli obiettivi, e
miglioramenti necessari. Sesto presente e utilizzare le informazioni, tra cui una sintesi e la
valutazione dei piani d'azione.
Atto
Il passo Act consiste nel prelievo di azione sulla base dei risultati delle analisi dei dati. Dopo
questo passo, un'organizzazione stabilisce una nuova linea di base e il ciclo di Deming pu
ricominciare.
Il passo Act comporta la settima dell'attivit CSI, che quello di realizzare miglioramenti.
Domanda
Abbinare ogni fase del ciclo di Deming alle appropriate attivit di CSI.
Opzioni:
A. Piano
B. Fare
C. Dai un'occhiata
D. Atto
obiettivi:
1. Identificare la strategia di miglioramento e definire ci che si misura
2. Raccogliere e dati di processo
3. Analizzare i dati e presenti e utilizzare le informazioni risultanti
4. implementare miglioramenti
Risposta
Il passo piano prevede l'individuazione di una strategia di miglioramento - riconoscendo la
visione, esigenza aziendale, la strategia, gli obiettivi tattici, e gli obiettivi operativi. Essa
comporta anche la definizione di che cosa misurare per monitorare l'efficacia delle iniziative di
miglioramento del servizio.
Il passo Do prevede la raccolta di dati da analizzare da operazioni di servizio, che stabilisce i
criteri per determinare l'integrit del dati e l'elaborazione dei dati in modo che possa essere
analizzato.
Il check fase implica l'analisi dei dati trattati in violazione di standard definiti nel piano per
illustrare i risultati di business. Dopo che i dati vengono analizzati, i risultati possono essere
presentati per le parti interessate.
Il passo Act implica l'implementazione di miglioramenti del servizio nelle aree
precedentemente individuati e analizzati. azioni di miglioramento sono comunicate al
personale interessato, che prendono le misure previste per l'attuazione dei miglioramenti.
Risposte corrette):
3.
Lo scopo del processo di CSI

193
Gli obiettivi del processo di CSI sono

identificare le opportunit di miglioramento dei servizi
Individuare opportunit di miglioramento dei servizi allineato con il passo Piano del ciclo
di Deming ed il punto di partenza per qualsiasi iniziativa di miglioramento del
servizio. Prendiamo l'esempio di un fornitore di servizi Internet wireless che intraprende
un'iniziativa per migliorare i servizi per i clienti. Il team di analisi IT individua diverse aree
per migliorare, tra cui una maggiore larghezza di banda, connettivit e vantaggi per il
cliente incluso con ogni account.
ridurre il costo della fornitura di servizi
E 'possibile ridurre il costo della fornitura di servizi e di garantire che servizi IT consentire
risultati di business che devono essere raggiunti. Nell'esempio del fornitore di servizi
Internet, riducendo il costo della fornitura di servizi ai clienti significher un aumento dei
profitti aziendali. Il team di analisti IT determina un modo per l'azienda a pagare meno per
la larghezza di banda venduta ai clienti senza servizio degradare.
identificare ci che deve essere misurato
Miglioramento del servizio aiuta a identificare ci che deve essere misurato, analizzato e
riportato per stabilire opportunit di miglioramento. Nell'esempio del fornitore di servizi
Internet, il team di analisi esamina le opportunit di miglioramento dei servizi, e determina
ci che pu essere misurato per determinare un servizio tasso di successo di
miglioramento. Questo include la misurazione della larghezza di banda fornita ai clienti
rispetto al prezzo pagato dal fornitore, e la stabilit di diversi tipi di tecnologia di
connessione del cliente.
rivedere continuamente successi di servizio, e
Si dovrebbe rivedere continuamente successi di servizio al fine di garantire che essi
rimangano allineati con le esigenze di business. possibile anche continuamente allineare
e ri-align servizio di provisioning con le esigenze di risultato. Nell'esempio del fornitore di
servizi Internet, il team di analisi possibile misurare l'efficacia di miglioramenti del servizio
mettendo a confronto dati finanziari attuali e passati, e durate attuali e passati per la
fornitura del stessi servizi IT.
capire che cosa misurare
E 'fondamentale per capire cosa misurare e perch, e di avere una chiara definizione di ci
che costituir un esito positivo di una iniziativa di miglioramento.Nell'esempio fornitore di
servizi Internet, il team di analisti determina gli aspetti tecnici di cosa misurare concernente
il miglioramento del servizio opportunit. Ci include la velocit di trasferimento di
larghezza di banda di diversa tecnologia, e il costo rispetto efficacia di diversi tipi di
tecnologie di trasmissione e strategie.
Ogni potenziale opportunit di miglioramento dovrebbe essere accompagnata da un caso
aziendale, o giustificazione, per mostrare come andr a beneficio di un business globale.
Sebbene la riduzione dei costi un obiettivo chiaro, dovrebbe essere raggiunto senza sacrificare
la qualit. Allo stesso modo, il miglioramento della qualit non dovrebbero essere attuate a meno
che i costi di fare i miglioramenti sono garantiti.
194
E 'importante notare che il processo di miglioramento sette fasi non indipendente. Sar ottenere i
risultati desiderati solo quando applicata alla tecnologia, servizi, processi, l'organizzazione, ed i
suoi partner.
Grafico
Il processo di miglioramento di sette passo quello di 1. Identificare la strategia di
miglioramento, 2. Definire ci che si misura, 3. raccogliere i dati, 4. elaborare i dati, 5.
analizzare le informazioni, 6. Presente e utilizzano le informazioni, 7. Implementare
miglioramento.
L'ambito del processo di miglioramento sette fasi CSI comprende
analisi del servizio
Analisi servizio comprende l'analisi delle prestazioni e le funzionalit dei servizi, processi
durante tutta la vita, partner organizzativo, e la tecnologia.
l'allineamento del servizio
CSI include l'allineamento continuo del Service Portfolio IT con le esigenze di business
attuali e future degli utenti del servizio. I miglioramenti dipendono anche dalla maturit del
consentendo processi IT per ogni servizio.
La tecnologia di servizio, e
CSI consiste nel fare il miglior uso possibile della tecnologia che un'organizzazione ha, cos
come la pianificazione di sfruttare le nuove tecnologie non appena disponibili, dove c' un
business case per farlo.
struttura organizzativa e del personale
Il processo pu essere utilizzato per valutare e migliorare la struttura organizzativa e le
capacit del personale. Ad esempio, possibile utilizzarlo per determinare se le persone
lavorano in funzioni e ruoli appropriati, e se hanno le competenze necessarie.
Monitorando e analizzando la fornitura di servizi IT, il processo di miglioramento sette fasi aiuta a
garantire che le esigenze aziendali attuali e future sono riconosciuti e rispettati.
Consente inoltre la valutazione continua della situazione attuale contro le esigenze aziendali e
identifica le opportunit per migliorare la fornitura di servizi per i clienti e gli utenti.
Domanda
In quali situazioni che pi appropriato utilizzare il processo di miglioramento sette fasi CSI?
Opzioni:
1. Si vuole cessare valutazioni periodiche per determinare opportunit di miglioramento
per il tuo business
2. Si vuole misurare quanto specifica attivit siano connesse a un servizio migliore
3. Si vuole ridurre al minimo il costo dei servizi IT che supportano il vostro business
4. Si desidera utilizzare il processo come strumento di free-standing per snellire il lato
IT della vostra azienda
5. Si vuole trovare nuovi modi per migliorare la vostra organizzazione ' dei servizi IT s
6. Si vuole determinare quale sia misurare, analizzare e comunicare, di stabilire le
opportunit di miglioramento
Risposta
195
Opzione 1: non corretto. Uno dei principali obiettivi del processo di miglioramento sette fasi
quello di incoraggiare le valutazioni continue per individuare e sviluppare nuovi modi per
migliorare il servizio.
Opzione 2: Corretto. Il processo di miglioramento in sette fasi si propone di spiegare come
attivit misurabile contribuire al miglioramento del servizio.
Opzione 3: Corretto. Il processo di miglioramento in sette fasi mira a ridurre il costo della
fornitura di servizi e di garantire che servizi IT abilitare i risultati di business che devono
essere raggiunti.
Opzione 4: non corretto. Il processo di miglioramento in sette fasi deve essere applicato ai
servizi, strumenti, partner organizzativo, e la tecnologia per supportare CSI.
Opzione 5: Corretto. Il processo di sette fasi consente di identificare le opportunit di
miglioramento dei servizi, processi e strumenti, al fine di migliorare i propri servizi IT.
Opzione 6: Corretto. Una volta che hai identificato le aree di miglioramento, il processo di
miglioramento sette fasi consente di identificare che cosa misurare per essere in grado di
valutare i vostri progressi miglioramento.
Risposte corrette):
2. Si vuole misurare come le attivit specifiche riguardano miglioramento del servizio
3. Si vuole ridurre al minimo il costo dei servizi IT che supportano il vostro business
5. Si vuole trovare nuovi modi per migliorare il servizio IT della propria organizzazione
6. Si vuole determinare quale sia misurare, analizzare e comunicare, di stabilire le
opportunit di miglioramento
4.
Riepilogo
Il processo di miglioramento in sette fasi CSI include l'identificazione, la definizione, la raccolta,

l'elaborazione, l'analisi, la presentazione, e l'attuazione di miglioramenti del servizio. Si integra a
stretto contatto con il ciclo di Deming. Il processo di CSI consente di identificare le opportunit per
migliorare il servizio, ridurre il costo della fornitura di servizi IT, a identificare ci che deve essere
misurato per stabilire opportunit di miglioramento, capire perch queste cose sono misurati, e
garantire un continuo ciclo di miglioramento. Questo permette di migliorare il servizio IT
conveniente che si allinea ai risultati di business desiderati.
5.
Sommario
| Inizio pagina |
| 1. CSI e il ciclo di Deming |
| 2. Lo scopo del processo di CSI |
| Sommario |
| Stampa | Sommario | Chiudi |
Trascrizione
Il processo di miglioramento CSI sette passi
196
identificare considerazioni per l'identificazione di strategie e definire le misurazioni

utilizzando il processo di miglioramento sette fasi CSI
descrivere le metriche un'organizzazione avr bisogno di raccogliere per sostenere CSI e

altre attivit di processo
descrivere le migliori pratiche per l'elaborazione e l'analisi dei dati utilizzando il processo di
miglioramento sette fasi CSI
identificare le situazioni e scenari in cui realizzazione miglioramento appropriata

2. Identificare le strategie e le 3. Misure
Il processo di Continual Service Improvement (CSI) comprende sette fasi.
Grafico
Le sette fasi del processo di CSI sono a 1. Identificare la strategia di miglioramento, 2.
definire ci che si misura, 3. raccogliere dati, 4. elaborare i dati, 5. analizzare le informazioni,
6. Presente e utilizzare le informazioni e 7. Implementare miglioramenti.
Lo scopo del processo quello di garantire il miglioramento continuo dei servizi IT in modo che tali
servizi soddisfino le esigenze di business e supportano i risultati di business desiderati.
Per avviare il processo di CSI, necessario porre domande pertinenti per aiutare a identificare una
strategia adeguata per il miglioramento. Ad esempio, quali sono le strategie di business e IT
dell'organizzazione e dei piani per i prossimi mesi e anni? E che cosa questi piani indicano che si
dovrebbe concentrarsi sul miglioramento?
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 1. Identificare la
strategia di miglioramento evidenziato.
La strategia si formulano dovrebbe essere progettato per consentire all'azienda di eseguire in
modo ottimale, con il minor numero possibile di vincoli posti dalla qualit o costi dei servizi IT.
Per identificare una strategia appropriata, a valutare l'organizzazione
obiettivi operativi tecnici e gli obiettivi strategici, e
Obiettivi strategici di un'organizzazione vi aiuteranno a determinare il proprio fabbisogno
globale di servizi IT, e cos contribuire a plasmare al centro degli sforzi di miglioramento del
servizio. Per esempio, se l'obiettivo strategico di un'organizzazione quello di fornire ai
clienti un servizio ad un costo inferiore rispetto ai suoi concorrenti, miglioramenti del
servizio possono concentrarsi sul miglioramento dell'efficienza e riduzione dei costi
operativi. Obiettivi operativi tecniche vi dar requisiti pi specifici per IT miglioramenti del
servizio. Ad esempio, un obiettivo di ridurre il tempo necessario per completare un
particolare processo pu dipendere specifici miglioramenti nelle prestazioni di un sistema
informatico o velocit di trasferimento dati.
imminenti piani di business e IT
Affari imminente e IT piani possono avere implicazioni per la strategia di miglioramento si
sceglie. Per esempio, i piani di espansione di business possono richiedere una particolare
attenzione per aumentare la capacit della rete. I piani per l'aggiornamento del sistema di
197
gestione delle informazioni di un'azienda pu creare un corrispondente necessit di

connessioni di rete pi elevata larghezza di banda.
Tra le domande che potete fare per aiutare a identificare una strategia di miglioramento sono
"Quali sono gli obiettivi di business dell'organizzazione?" "Quali effetti fanno scarsi servizi IT interni
hanno sui profitti?" e "Come pu miglioramenti nei servizi IT aiutare l'organizzazione a raggiungere
i propri obiettivi di business?"
gli obiettivi di business di un'organizzazione aiutano a rivelare la sua strategia.
E il miglioramento dei servizi IT possono contribuire a sostenere un punto obiettivo di business di
adeguati obiettivi tecnici operativi.
Una volta identificato la strategia di miglioramento, necessario decidere come verr misurato il
progresso. In questa fase, si
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 2. Definire ci che si
misura evidenziato.
definire che cosa si dovrebbe misurare
definire che cosa si pu effettivamente misurare
condurre un'analisi gap, e
finalizzare un piano di misura
Per definire ci che si misura per monitorare miglioramenti del servizio, necessario valutare
elementi di servizio
Si dovrebbe valutare gli elementi di un servizio IT, o le attivit coinvolte in un processo di
gestione dei servizi, che mirato per il miglioramento. Questo vi aiuter a rompere il
processo di servizio o di gestione verso il basso per le sue parti costituenti in modo da
poter determinare quali elementi possibile misurare.
indicatori di performance, e
Per ogni processo di servizio o di Service Management, necessario valutare gli indicatori
di performance disponibili. Per esempio, come sono le prestazioni, la disponibilit e la
qualit attualmente misurato - e come potrebbero essere misurati? Una volta stabilito
questo, possibile determinare quali prestazioni indicatori sono pi adatti dato gli obiettivi
di un'iniziativa di miglioramento.
gli obiettivi del target di riferimento
E 'fondamentale concentrarsi sui miglioramenti dei servizi che saranno di valore per il
servizio agli utenti, o si rischia di sprecare tempo e denaro sui miglioramenti che i clienti
interni o esterni considerano inutili. Di conseguenza, una volta che hai identificato una
strategia di miglioramento, si dovrebbe stabilire metriche progettato per misurare gli
elementi di servizio che i clienti e gli utenti considerano importante, o che sono
fondamentali per i clienti che hanno raggiunto i propri obiettivi di business.
Durante la fase di CSI, pu essere rilevante misurare
i livelli di clienti e utenti di soddisfazione con esistenti servizi IT

198
l'impatto sul business di IT interruzioni del servizio
le prestazioni dei fornitori di terze parti, e
performance di mercato, per stabilire se i servizi IT sono in linea o superiori a quelli offerti
da altri fornitori di servizi
Domanda
Abbina ogni attivit al passo corrispondente nel processo di CSI. Pi di una attivit pu
corrispondere ad un passo.
Opzioni:
A. Valutare obiettivi operativi tecnici e gli obiettivi strategici
B. Valutare imminente piani industriali e IT
C. Valutare gli elementi dei processi di servizio o di gestione di servizio mirati di
miglioramento
D. Valutare gli obiettivi del target di riferimento
E. Valutare indicatori di prestazioni per il servizio mirato o attivit Service Management
obiettivi:
1. Identificare la strategia di miglioramento
2. Definire ci che si misura
Risposta
Per identificare una strategia adeguata per il miglioramento, necessario valutare gli obiettivi
operativi e strategici tecnici dell'organizzazione, cos come imminente piani industriali e IT.
Per definire cosa misurare per migliorare, si dovrebbe valutare gli elementi di servizio e
indicatori di prestazioni disponibili, cos come gli obiettivi degli utenti del servizio.
Risposte corrette):
Obiettivo 1 = Opzione A, l'opzione B
Obiettivo 2 = Opzione C, Opzione D, Opzione E
4.Raccolta di dati
Una volta che sai che cosa misurare, la terza fase del processo di CSI quello di raccogliere i
dati. Ci comporta il monitoraggio dei relativi processi di servizio o di gestione dei servizi. Si pu
fare questo usando applicazioni, sistemi e strumenti di monitoraggio componente o, in alcuni casi,
un processo di monitoraggio manuale.
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 3. raccolta dei dati
viene evidenziato.
In genere ci si concentra sul monitoraggio della qualit, o l'efficacia e l'efficienza, di un servizio,
processo, strumento o un elemento di configurazione (CI).
L'enfasi non sulla assicurando prestazioni di servizi in tempo reale, ma sull'individuazione dove i
miglioramenti possono essere fatti. Quindi, il monitoraggio di CSI tende a concentrarsi sulla
rilevazione delle eccezioni e il monitoraggio risoluzioni.
Tuttavia, non si dovrebbe concentrarsi solo sul monitoraggio eccezioni o debolezze. Se un Service
Level Agreement (SLA) costantemente incontrato nel corso del tempo, si dovrebbe concentrarsi
199
su come determinare se tale livello di prestazioni pu essere sostenuta ad un costo inferiore - o se

il servizio mirato livelli ha bisogno di essere rettificato per le mutevoli esigenze di business.
Non avrete bisogno o essere in grado di far fronte alle grandi quantit di dati prodotti da tutte le
attivit di monitoraggio, in modo che la messa a fuoco nel processo di CSI sar in uno specifico
sottoinsieme di monitoraggio in un dato momento.
Quando un nuovo servizio IT stato progettato o uno esistente cambiato, questa una occasione
perfetta per garantire che i requisiti di servizio contengono ci CSI deve monitorare.
Per supportare CSI, in genere necessario raccogliere
metriche tecnologiche
metriche tecnologiche sono spesso associati a metriche dei componenti e delle applicazioni
basate su come le prestazioni e la disponibilit. Essi misurano le prestazioni dei
componenti che costituiscono un servizio IT.
metriche di processo, e
Metriche di processo vengono acquisite in forma di fattori critici di successo (CSF), Key
Performance Indicators (KPI) e metriche di attivit per i processi di gestione dei
servizi. Queste metriche possono aiutare a determinare la salute generale di un
processo. KPI possono aiutare a rispondere a domande chiave sulla qualit, le prestazioni,
il valore e il rispetto nel seguire il processo. CSI sarebbe utilizzare queste metriche come
input per identificare le opportunit di miglioramento per ogni processo. Responsabili dei
processi specifici sono generalmente responsabili per la definizione di metriche di
processo.
metriche di servizio
Domanda
Abbinare ogni tipo di metrica alla descrizione corrispondente.
Opzioni:
A. metrica Tecnologia
B. processo metrica
C. metrica Servizio
D. metriche di contenimento degli errori
obiettivi:
1. Un parametro che misura le prestazioni di un componente di un servizio
2. Una metrica che misura la salute e la qualit di un processo di Service Management
3. Un parametro che misura la prestazione di un servizio nel suo complesso
Risposta
metriche tecnologiche sono spesso associati a metriche dei componenti e delle applicazioni
basate su che danno risultati quantificabili sulle parti che compongono un intero servizio.
metriche di processo vengono acquisite in forma di CSF, KPI e metriche di attivit per i
processi di gestione dei servizi.
metriche di servizio sono utilizzati per misurare l'efficacia end-to-end del servizio, spesso
utilizzando metriche tecnologiche combinate.
Risposte corrette):
200
5.Elaborazione dei dati e l'analisi
Il passo successivo nel processo di CSI dopo aver raccolto i dati, quello di elaborare i
dati. Attraverso l'elaborazione, di convertire i dati che sono stati raccolti in un formato utilizzabile
che pu essere interpretato e analizzato.
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 4. elaborare i dati
evidenziato.
Il trattamento dei dati pu essere automatizzata o manuale. la raccolta dei dati e l'elaborazione
automatizzata meno vulnerabile agli errori di lavorazione manuale, quindi buona pratica per
automatizzare il pi possibile.
Quando richiesta l'elaborazione manuale, di vitale importanza per i dipendenti per
documentare le loro attivit di compliance, e per mantenere i log e record aggiornati. Per esempio,
potrebbe essere necessario alcuni dipendenti per registrare il tempo necessario per caricare
specifici tipi di file.
L'analisi dei dati il quinto passo nel processo di CSI. Questa fase prevede la trasformazione i dati
che hai trasformato in informazioni utili, comprese le informazioni sulle opportunit di
miglioramento. Pi abilit ed esperienza sono necessari per analizzare i dati rispetto a raccogliere
ed elaborare esso.
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 5. analizzare le
informazioni evidenziato.
Durante l'analisi, a valutare la misura in cui il processo di servizio o di Service Management
misurato si riunisce finalit e gli obiettivi specifici. documentare anche le vostre osservazioni e
conclusioni in modo chiaro.
Quando si analizzano i dati, importante chiedere domande come
Sono operazioni che funzionano secondo i piani?
Sono gli obiettivi definiti negli SLA o il catalogo Servizio stati raggiunti?
ci sono problemi strutturali di fondo che possono essere identificati?
Sono miglioramenti necessari?
Ci sono delle tendenze, e in caso affermativo, quali sono la proiezione tendenze e sono
essi positivi o negativi?
Quello che sta portando a causare o le tendenze?
E 'buona norma rivedere le tendenze per un periodo di tempo. Solo una visione istantanea di dati
su un processo di servizio o di Service Management improbabile che sia molto istruttiva. Invece,
utile chiedere: "Come abbiamo fatto questo mese rispetto al mese scorso, in questo trimestre
rispetto allo scorso trimestre, quest'anno rispetto allo scorso anno?"
201
Se si rileva un'anomalia, verificare che in realt non parte di una tendenza - e indagare sulle sue
possibili cause.
Allo stesso modo, indagare le tendenze - o cambiamenti nelle tendenze - per determinare le cause
sottostanti.
Domanda
Partita ogni migliori pratiche o attivit per il passaggio appropriato nel processo di CSI. Pi di
una delle migliori pratiche o attivit possono corrispondere a un passo.
Opzioni:
A. Automatizzare il pi possibile
B. attivit di compliance documento
C. i registri e aggiornare i record
D. tendenze revisione per un periodo di tempo
E. Esaminate quello che ha portato ai risultati delle analisi del periodo corrente
F. Accertare se un cattivo risultato un'anomalia
obiettivi:
1. Elaborare i dati
2. Analizzare le informazioni
Risposta
La fase di elaborazione dati deve essere automatizzato per quanto possibile per la
precisione. I dipendenti devono anche documentare le attivit di compliance e registri e
aggiornare i record, per garantire che la raccolta e l'elaborazione viene eseguita in modo
accurato e coerente.
Best practice per analizzare le informazioni sono di rivedere le tendenze per un periodo di
tempo e di stabilire se eventuali anomalie in realt parte di una tendenza. E 'anche
importante per determinare le cause alla base delle tendenze dei dati.
Risposte corrette):
Obiettivo 1 = Opzione A, l'opzione B, Opzione C
Obiettivo 2 = Opzione D, Opzione E, F Opzione
6.
Presentare e utilizzare le informazioni CSI
Il sesto passo nel processo di CSI quello di presentare i dati analizzati - in relazioni, piani di
azione, recensioni, valutazioni, e le opportunit di miglioramento individuate - per le parti
interessate.
Grafico
Nel CSI sette fasi diagramma processo di miglioramento, il presente punto 6. e utilizzare le
informazioni evidenziato.
necessario assicurarsi che i dati vengono presentati in modo che il pubblico di destinazione
troveranno facile da capire.
E 'importante includere solo le informazioni che di valore per il vostro particolare target di
riferimento. Si dovrebbe notare eccezioni e identificare i benefici che sono stati rivelati durante il
periodo monitorato.
Le informazioni si presenti dovrebbe differire a seconda che il pubblico costituito da
202
clienti
I clienti devono essere informati se i livelli di servizio mirati sono stati forniti e, nel caso di
carenze, quali miglioramenti sono attuate per migliorare la situazione. Ad esempio, un
provider di servizi Internet potrebbe spiegare le cause di interruzione del servizio ai clienti,
e notare come i miglioramenti previsti saranno effettuare i collegamenti dei clienti pi
veloce e affidabile.
alti dirigenti
I dirigenti sono propensi a concentrarsi sui tipi di informazioni fornite dal FCS e IPC. Ad
esempio, sono suscettibili di essere interessati a livelli di soddisfazione dei clienti, le
prestazioni effettive rispetto alle prestazioni previste, e costi e obiettivi di fatturato. Questi
tipi di informazioni aiutare a informare i miglioramenti strategici e tattici su scala pi
ampia. IT management senior pu richiedere questo tipo di informazioni sotto forma di un
balanced scorecard. Nel caso di un provider di servizi Internet, per esempio, possibile
consegnare scorecard per i dirigenti a dimostrare i vantaggi economici di investire in
tecnologia e come questo migliorer la soddisfazione dei clienti e aumentare i profitti.
personale IT interno, e
Il personale IT interno sono spesso interessati alle KPI di informazione e di metriche di
attivit forniscono perch questo pu aiutare a pianificare, coordinare, pianificare e
identificare le opportunit di miglioramento incrementale. Nel caso di un provider di servizi
Internet, possibile presentare al personale IT con un rapporto su come l'uso efficace delle
nuove tecnologie in grado di beneficiare della gestione dell'infrastruttura IT aziendale.
fornitori
I fornitori sono suscettibili di essere interessati a KPI e le metriche di attivit relative ai
propri servizi e le prestazioni. I fornitori possono essere destinati anche con iniziative di
miglioramento.
E 'di vitale importanza per i manager IT di investire tempo nella comprensione specifici obiettivi di
business e di tradurlo metriche per riflettere il loro impatto su questi obiettivi.
La sfida principale, e uno che pu essere soddisfatta, quello di comunicare in modo efficace i
benefici di business di una corsa-pozzo di supporto IT del gruppo. Il punto di partenza una nuova
prospettiva sugli obiettivi, le misure, reporting, e di come le azioni influenzano i risultati di business.
Anche se la maggior parte dei rapporti tendono a concentrarsi sulle aree negative, anche
importante segnalare una buona notizia. E 'di vitale importanza per indicare se CSI ha
effettivamente migliorato la fornitura di servizi in generale e, in caso contrario, le azioni intraprese
per rettificare la situazione.
Domanda
Abbinare ogni tipo di pubblico al metodo di comunicazione e le informazioni di formattazione
che meglio si adatta IT.
Opzioni:
A. Clienti
B. L'alta direzione
C. IT interno
D. fornitori
203
obiettivi:
1. Un messaggio che spiega il livello di servizio IT e miglioramenti di accompagnamento
2. Una balanced scorecard contenente rapporti sul modo in cui i miglioramenti possono
influenzare il servizio clienti e flussi di entrate
3. Un rapporto contenente metriche che illustrano il funzionamento interno del reparto
IT
4. Un messaggio che suggerisce miglioramenti procedurali per allineare i servizi con
iniziative di miglioramento continuo IT
Risposta
I clienti devono essere informati se il livello promesso di servizi IT viene fornito e, in caso
contrario, quali azioni sono state intraprese per migliorare la situazione.
L'alta direzione probabile che sia pi interessato a informazioni che possono aiutare a
determinare miglioramenti strategici e tattici su scala pi ampia, presentati in modo che
illustra il quadro generale.
Il personale IT interno sono generalmente interessati a KPI e le metriche di attivit, che
possono aiutare a identificare e pianificare iniziative di miglioramento procedurali.
I fornitori e terze parti saranno interessati a metriche e proposte di miglioramento relativi ai
propri servizi.
Risposte corrette):
7.
Attuazione dei Miglioramenti
La fase finale del processo di CSI sta implementando i miglioramenti che sono stati identificati.
Grafico
In sette fasi diagramma di processo di miglioramento del CSI, il passo 7. Implementare
miglioramento evidenziato.
Tuttavia, il processo CSI pu identificare molte opportunit di miglioramento, e pu non essere
possibile attuare tutte. Come risultato, le aziende devono dare priorit opportunit di
miglioramento.
Una volta che una decisione presa per migliorare un particolare processo di gestione dei servizi
IT e di assistenza, il Service Lifecycle continua.
I sette passaggi del processo CSI pu essere descritto come una "conoscenza spirale" piuttosto
che un ciclo semplice.
Grafico
Ogni volta che il processo completato, conoscenza organizzativa guadagnato. Questo pu
quindi essere utilizzato per informare i futuri miglioramenti del servizio.
204
Ogni passo nel processo di miglioramento sette fasi correlato alla sequenza di elementi nel Datainformazione-conoscenza-saggezza modello (DIKW).
dati
Dati rappresenta i fatti grezzi che vengono trattati in fasi due e tre del processo di CSI, che
coinvolgono determinare che cosa misurare e la raccolta dei dati.
I dati si riferiscono a questi passi nel processo di miglioramento sette fasi: 2. Definire ci
che si misura e 3. Raccogliere i dati.
Informazioni
Informazioni viene utilizzato nel passaggio quattro del processo di CSI, che prevede
l'elaborazione dei dati che sono stati raccolti. Quando i dati vengono elaborati, dato
significato contestuale e viene quindi convertito in informazioni.
Informazioni si riferisce al processo di miglioramento sette fasi passo 4. elaborare i dati.
Conoscenza
La conoscenza viene generato e utilizzato nei passaggi cinque e sei del processo di CSI,
che coinvolgono l'analisi e la presentazione e utilizzando le informazioni che stato
elaborato. La conoscenza informazione che collocato in un contesto e che equipaggia
la titolare di agire su e utilizzare tali informazioni.
La conoscenza relative alle fasi del processo di miglioramento sette fasi: 5. analizzare le
informazioni e 6. Presente e utilizzare le informazioni.
Saggezza
La saggezza utilizzato nella settima fase del processo CSI e alimenta nel ciclo CSI
corso. La saggezza l'accumulo di dati, informazioni e conoscenze che porta ad uno stato
consapevole di comprensione in cui il titolare conoscenza pu agire in modo efficace e
aggiungere valore ad una organizzazione.
Sapienza relative alle fasi del processo di miglioramento sette fasi: 7. Implementare
miglioramento e 1. Identificare la strategia di miglioramento.
Per CSI per avere successo veramente, deve essere completamente integrato con ogni fase del
ciclo di vita di servizio, e con i processi in ciascuna di queste fasi.
Grafico
Un approccio globale di servizio continuo da una organizzazione pu essere utilizzato per aiutare a
garantire che il miglioramento opportunit siano identificati durante l'intero ciclo di vita del
servizio. L'approccio comprende sei passi generali per l'esame.
vision affari, missione, obiettivi e gli obiettivi
Comprendere gli obiettivi di business di alto livello, al fine di abbracciare la visione
dell'organizzazione, che idealmente dovrebbe allineare le strategie di business e IT.
valutazioni Baseline
Ottenere un accurato, visione obiettiva di dove l'organizzazione in questo momento - tra
cui il business, organizzazione, persone, processi e tecnologia.
205
obiettivi misurabili
Sviluppare obiettivi specifici e un calendario gestibile attraverso la comprensione e
concordare le priorit di miglioramento.
miglioramento del servizio e di processo
Particolare il piano di CSI e di ottenere la fornitura di servizi di qualit superiore attraverso
l'attuazione o il miglioramento dei processi ITSM.
Misurazione e metriche
Verificare che esistono misure e metriche, che funzionano e sono accurate, stabilire se
sono stati raggiunti traguardi, la conformit processo alto, e gli obiettivi di business e le
priorit siano sufficienti a soddisfare il livello di servizio.
Sostenibilit
miglioramento della qualit a lungo termine richiede l'accettazione organizzativa. Garantire
l'accettazione e le modifiche sono incorporati nell'organizzazione.
Domanda
In quali situazioni l'uso del processo di CSI pi appropriata?
Opzioni:
1. Una catena di popolare rivenditore di elettronica che scopre sta perdendo affari sul
suo sito web a causa della base di dati Stock spesso essere fuori moda
2. Un provider di servizi Internet che sta perdendo clienti di un grande fornitore di servizi
che offre tassi migliori
3. Una societ di animazione che scopre il suo flusso di lavoro soffre di numerosi ritardi
tra i vari processi automatizzati e manuali
4. Uno sviluppatore di codice che soffre di un elevato turnover del personale e di
conseguenza ha difficolt nell'attuazione delle iniziative di miglioramento IT
Risposta
Opzione 1: Corretto. Aggiornamenti frequenti del sito web e database possono essere il
risultato di un servizio IT in ritardo di sviluppo e possono quindi essere diagnosticato e
alleviato utilizzando il processo di CSI.
Opzione 2: non corretto. Aumentare l'efficienza del servizio pu aiutare un business operare
in modo efficace pi conveniente, ma non fornir le risorse per inferiori radicalmente i prezzi
di un concorrente pi grande.
Opzione 3: Corretto. Un problema di flusso di lavoro con fattori sia automatici che manuali
che contribuiscono pu essere diagnosticata e migliorato dal processo di CSI.
Opzione 4: non corretto. Rotazione del personale un problema di gestione delle risorse
umane e deve essere risolto prima di un significativo miglioramento CSI iniziativa pu essere
attuata.
Risposte corrette):
1. Una catena di popolare rivenditore di elettronica che scopre sta perdendo affari sul
suo sito web a causa della base di dati Stock spesso essere fuori data
3. Una societ di animazione che scopre il suo flusso di lavoro soffre di numerosi ritardi
tra i vari processi automatizzati e manuali
206
8.
Riepilogo
Il processo di CSI comprende sette gradini. Il processo inizia con l'identificazione possibili strategie
di miglioramento e definire ci che deve essere misurato. Il passo successivo la raccolta dei dati
utilizzando la tecnologia, servizio, e metriche di processo. I dati vengono poi elaborati e analizzati,
dopo di che si preparato per la presentazione di soggetti interessati. Le informazioni viene
comunicata alle parti interessate in un formato appropriato, per informare e sollecita azione di
miglioramento. la fase finale del processo quello di attuare i miglioramenti individuati. Un
approccio costante miglioramento dei servizi contribuisce a garantire che il miglioramento
opportunit siano identificati durante l'intero ciclo di vita del servizio.
Supplemento
Selezionando il titolo del link si apre la risorsa in una nuova finestra del browser.
Follow-on Activity
Accedere a questi esami di pratica:

campione di carta Foundation esame una versione 4.2 , e
provate Fondazione Esame Carta B, Versione 4.0 .
9.
Sommario
| Inizio pagina |
| 1. Individuare strategie e misure |
| 2. Raccolta dei dati |
| 3. Elaborazione dei dati ed analisi |
| 4. Presentare e utilizzare le informazioni CSI |
| 5. Implementare miglioramenti |
| Sommario |
Riconoscendo i sette passi per miglioramento

riconoscere come utilizzare il processo di miglioramento sette fasi di CSI

In questo esercizio, ti viene richiesto di dimostrare la familiarit con la fase di Continual Service
Improvement (CSI) del ITIL Service Lifecycle.
identificare la portata e benefici di CSI
individuando come utilizzare il registro di CSI, e

207
riconoscendo le sette fasi del processo CSI

3. Identificare i benefici e la portata
Un'organizzazione IT fornisce un servizio di archiviazione dei dati off-site per i clienti che hanno
bisogno di memorizzare le informazioni sensibili. Come parte del ITIL Service Lifecycle, vuole
utilizzare il processo di CSI per migliorare i propri servizi IT su base continuativa.
Domanda
Quali considerazioni deve l'organizzazione tenere a mente in sede di attuazione CSI?
Opzioni:
1. Garantire che gli obiettivi miglioramenti del servizio sono chiaramente definiti
2. Utilizzare un sistema di feedback a circuito chiuso
3. Aderire al quadro rigoroso che CSI prevede miglioramenti di servizio
4. Determinare le misure appropriate per il miglioramento dei servizi, cos come i loro
risultati attesi
5. Assicurarsi che i miglioramenti di servizio siano allineati con le esigenze aziendali
6. Regolare i processi aziendali per produrre miglioramenti del servizio
Risposta
Opzione 1: Corretto. Efficace CSI assicura che i miglioramenti di servizio sono implementate
e gestite utilizzando obiettivi chiaramente definiti, gli obiettivi e le misure.
Opzione 2: Corretto. Il sistema di feedback CSI utilizza l'uscita da una fase del ciclo di vita
per identificare le opportunit di miglioramento per qualsiasi altra fase del ciclo di vita.
Opzione 3: non corretto. CSI fornisce linee guida best practice, piuttosto che una struttura
rigida, per l'attuazione di miglioramenti del servizio.
Opzione 4: Corretto. CSI contribuisce a determinare che cosa misurare, perch viene
misurato, e ci che il buon esito dovrebbe essere.
Opzione 5: Corretto. CSI assicura che Portfolio servizio di un fornitore di servizi IT rimane
allineato con le esigenze di business dei propri clienti interni o esterni.
Opzione 6: non corretto. Lo scopo della CSI quello di garantire che i servizi IT allinearsi alle
mutevoli esigenze di business, piuttosto che il contrario.
Risposte corrette):
1. Verificare che i miglioramenti del servizio sono obiettivi chiaramente definiti
2. Utilizzare un sistema di feedback a circuito chiuso
4. Determinare le misure appropriate per il miglioramento dei servizi, cos come i loro
risultati attesi
5. Assicurarsi che i miglioramenti di servizio siano allineati con le esigenze aziendali
Domanda
Come pu il beneficio dell'organizzazione di utilizzare CSI?
Opzioni:
1. Pu migliorare continuamente la qualit del servizio di archiviazione dati
2. Si pu garantire che il servizio di archiviazione dei dati sia in linea con le sue
esigenze di business
3. Pu migliorare il suo rapporto costo-efficacia
208
4. E 'in grado di identificare le opportunit di miglioramento nella fase finale del

ITIL Lifecycle Service
5. Si avr accesso a uno standard formale per funzionalit di controllo di gestione
6. L'organizzazione pu individuare altre possibili opportunit di miglioramento
organizzativo
Risposta
Opzione 1: Corretto. CSI permetter l'organizzazione di ottenere un continuo miglioramento
della qualit del servizio e soddisfazione del cliente.
Opzione 2: Corretto. CSI aiuta a garantire che tutti i servizi in portafoglio servizio
dell'organizzazione vengano allineate alle esigenze di business dei propri clienti.
Opzione 3: Corretto. CSI pu aumentare l'efficacia dei costi di un'organizzazione per la
riduzione dei costi, o consentendole di gestire pi lavoro allo stesso costo.
Opzione 4: non corretto. CSI consente all'organizzazione di utilizzare il monitoraggio e il
reporting per identificare potenziali opportunit di miglioramento in tutte le fasi del ciclo di vita.
Opzione 5: non corretto. CSI fornisce una guida best-practice per il miglioramento della
qualit del servizio IT. Essa non prevede norme formali per la gestione di revisione di servizio.
Opzione 6: Corretto. CSI consente all'organizzazione di identificare le opportunit di
migliorare la sua struttura, le capacit di risorse, i partner, la tecnologia, le competenze del
personale e la formazione, e le comunicazioni.
Risposte corrette):
1. Pu migliorare continuamente la qualit del servizio di memorizzazione dei dati
2. Si pu garantire che il servizio di archiviazione dei dati sia in linea con la sua attivit
ha bisogno di
3. Si pu migliorare la sua redditivit
6. L'organizzazione pu individuare altre possibili opportunit di miglioramento
organizzativo
4. Utilizzando il registro CSI
Come parte della fase di CSI, l'organizzazione implementa un registro CSI.
Domanda
Perch l'organizzazione deve utilizzare un registro di CSI?
Opzioni:
1. Esso consente l'organizzazione di registrare tutte le opportunit di miglioramento
individuate per il servizio di archiviazione dei dati
2. Esso permette all'organizzazione di classificare le opportunit di miglioramento
3. Esso consente l'organizzazione di catalogare i benefici che si possono ottenere
mediante l'attuazione di miglioramenti specifici per il servizio di archiviazione dei dati
4. Esso fornisce un coordinato, visione coerente delle numerose attivit di
miglioramento
5. Esso consente a tutti i membri del personale IT di prendere la responsabilit per
l'acquisizione e la registrazione di iniziative di miglioramento
6. Offre un one-size-fits-all di miglioramento del servizio che andr a beneficio di tutti i
tipi di organizzazioni
209
Risposta
Opzione 1: Corretto. Un registro CSI permette ad un'organizzazione di tenere traccia delle
opportunit di miglioramento e benefici associati.
Opzione 2: Corretto. Il registro CSI permette ad un'organizzazione di classificare le
opportunit di miglioramento in base alla loro dimensione, o la scala, e probabilmente la
durata.
Opzione 3: Corretto. Il registro CSI presenta la struttura e la visibilit per il miglioramento dei
servizi da loro associati con obiettivi chiaramente definiti e le metriche per il monitoraggio del
loro successo.
Opzione 4: Corretto. Il registro CSI permette di coordinare, vista consistente affermando ogni
possibile attivit che porta ad un miglioramento del servizio.
Opzione 5: non corretto. La produzione e la manutenzione di un registro CSI dovrebbero
essere gestite da un responsabile CSI dedicato.
Opzione 6: non corretto. Ogni organizzazione dovrebbe valutare le sue esigenze specifiche e
creare un registro CSI per soddisfare i propri scopi.
Risposte corrette):
1. Esso consente l'organizzazione di registrare tutte le opportunit di miglioramento
2. Esso permette all'organizzazione di classificare le opportunit di miglioramento
3. Esso consente l'organizzazione di catalogare i benefici che si possono ottenere
mediante l'attuazione di miglioramenti specifici per il servizio di archiviazione dei dati
4. Esso fornisce un coordinato, visione coerente delle numerose attivit di miglioramento
Domanda
Quali considerazioni deve l'organizzazione tenere a mente quando si compila il registro di
CSI?
Opzioni:
1. Esso dovrebbe associare miglioramenti proposti con opportuni indicatori di
prestazioni chiave (KPI)
2. Esso dovrebbe fornire un'interfaccia con altri processi
3. Dovrebbe riguardare solo le attivit CSI per evitare sovrapposizioni con la
documentazione prodotta durante altre fasi
4. Dovrebbe essere considerato parte del Sistema di Gestione della Knowledge Service
dell'organizzazione (SKMS)
5. Si dovrebbe utilizzare il formato rigorosamente definito delineato per tutte le
organizzazioni
Risposta
Opzione 1: Corretto. Ogni miglioramento proposto nel registro CSI dovrebbe essere
accompagnata da KPI rilevanti e altre metriche per misurare il successo o il fallimento dei
miglioramenti.
Opzione 2: Corretto. Il registro CSI dovrebbe fornire un'interfaccia con iniziative strategiche e
processi come Problem Management, Capacity Management e Change Management.
210
Opzione 3: non corretto. Processi come Problem Management, Capacity Management e

Change Management possono tutti fornire informazioni che riguarda le opportunit di
miglioramento e che dovrebbe essere inserito nel registro del CSI.
Opzione 4: Corretto. Il registro CSI contiene informazioni importanti e cos dovrebbe essere
considerato come parte di SKMS generale di un'organizzazione.
Opzione 5: non corretto. Ogni organizzazione dovrebbe progettare un registro CSI in base
alle sue esigenze specifiche.
Risposte corrette):
1. Si deve associare miglioramenti proposti con opportuni indicatori di prestazioni chiave
(KPI)
2. Esso dovrebbe fornire un'interfaccia con altri processi
4. Dovrebbe essere considerato parte del Sistema di Gestione della Knowledge Service
dell'organizzazione (SKMS)
5. Riconoscendo il processo di CSI
Avanti l'organizzazione implementa il processo di CSI, che comprende sette fasi.
Grafico
Domanda
Perch l'organizzazione dovrebbe utilizzare il processo di CSI?
Opzioni:
1. Per consentirle di cessare valutazioni periodiche per determinare le opportunit di
miglioramento
2. Per determinare il motivo per cui dovrebbe misurare attivit specifiche, e per capire
come si riferiscono ad un servizio di archiviazione dei dati migliorata
3. Per ridurre al minimo i costi di provisioning del servizio di archiviazione dei dati IT
4. Per trovare nuovi modi per migliorare il servizio di archiviazione dei dati
5. Per determinare che cosa misurare, analizzare e segnalare per monitorare gli sforzi
di miglioramento
6. Per semplificare il lato IT del business utilizzando il processo come strumento standalone
Risposta
Opzione 1: non corretto. Il processo di miglioramento in sette fasi incoraggia valutazioni
continue che aiutano a individuare e sviluppare nuovi modi per migliorare il servizio.
Opzione 2: Corretto. Il processo di miglioramento in sette fasi aiuta a determinare come le
attivit misurabile contribuire al miglioramento del servizio.
Opzione 3: Corretto. Il processo di miglioramento in sette fasi aiuta a ridurre il costo della
fornitura di servizi.
Opzione 4: Corretto. Il processo di miglioramento in sette fasi aiuta a identificare le
opportunit di miglioramento dei servizi, processi e strumenti, al fine di migliorare un servizio.
211
Opzione 5: Corretto. Il processo di miglioramento in sette fasi aiuta a identificare che cosa
misurare per essere in grado di valutare i progressi.
Opzione 6: non corretto. Il processo di miglioramento in sette fasi opere di miglioramento dei
servizi, gli strumenti, i partner organizzativi, e la tecnologia per la produzione di un
miglioramento continuo del servizio. Esso non pu fornire i miglioramenti di business senza il
contesto di business necessaria.
Risposte corrette):
2. Per determinare il motivo per cui dovrebbe misurare attivit specifiche, e per capire
come si riferiscono a un servizio di immagazzinamento dei dati
3. Per ridurre al minimo i costi di provisioning del servizio di archiviazione dei dati IT
4. Per trovare nuovi modi per migliorare il servizio di archiviazione dei dati
5. Per determinare che cosa misurare, analizzare e segnalare per monitorare gli sforzi di
miglioramento
Domanda
Quale dovrebbe essere la misura di organizzazione durante il processo di CSI
Opzioni:
1. Soddisfazione del cliente
2. dell'impatto sulle imprese
3. prestazioni dei fornitori
4. La soddisfazione del personale
5. Le prestazioni del mercato
6. livelli di servizio
7. prestazioni competitor
Risposta
Opzione 1: Corretto. L'organizzazione deve continuamente misurare come i clienti soddisfatti
sono con il servizio che viene fornito.
Opzione 2: Corretto. L'organizzazione dovrebbe misurare le azioni che vengono invocate da
interruzioni del servizio, e come influenzano i clienti.
Opzione 3: Corretto. L'organizzazione dovrebbe misurare i suoi rapporti con i fornitori e le
prestazioni di questi fornitori.
Opzione 4: non corretto. A meno che le condizioni di lavoro insoddisfacenti, per esempio, di
auto dipendenti di distanza, la soddisfazione dei dipendenti non deve influenzare il processo
di CSI.
Opzione 5: Corretto. L'organizzazione dovrebbe misurare la performance del mercato al fine
di garantire che i servizi rimane in linea con quelli di altri fornitori di servizi.
Opzione 6: Corretto. L'organizzazione dovrebbe misurare la disponibilit del servizio e la
qualit.
Opzione 7: non corretto. Prestazioni concorrente pu avere un impatto l'organizzazione, ma
questo non fornir i dati relativi al miglioramento propri servizi dell'organizzazione.
Risposte corrette):
1. La soddisfazione del cliente
2. Dell'impatto sulle imprese
212
3. Performance dei fornitori

5. Le prestazioni del mercato
6. livelli di servizio
Domanda
Dopo aver determinato cosa misurare, quali attivit dovrebbe condurre l'organizzazione?
Opzioni:
1. Misurare le prestazioni e la disponibilit di tecnologie che compongono i processi
2. Misurare Service Management KPI
3. Misurare l'efficacia di ogni servizio considerato di potenziale miglioramento
4. Misurare le potenziali profitti di grandi investimenti in nuove apparecchiature IT
5. Misurare l'efficacia dei programmi di formazione del personale in servizio al cliente
Risposta
Opzione 1: Corretto. CSI utilizza metriche tecnologiche che misurano l'efficacia delle
applicazioni, tecnologie e componenti che costituiscono processi IT.
Opzione 2: Corretto. CSI utilizza metriche di processo che possono aiutare a determinare la
salute generale di un processo. KPI pu aiutare a rispondere a domande chiave sulla qualit,
le prestazioni, il valore e il rispetto nel seguire il processo.
Opzione 3: Corretto. CSI richiede metriche di servizio che misurano l'efficacia di un intero
servizio. Spesso metriche tecnologiche vengono utilizzati per raccogliere dati per le metriche
di servizio.
Opzione 4: non corretto. Grandi investimenti sarebbero stati giudicati sui risultati di vari
parametri di budget e di investimento, piuttosto che utilizzare le metriche associate alla
gestione dei servizi.
Opzione 5: non corretto. La formazione dei dipendenti sarebbe stato valutato sui risultati di
risorse umane metriche invece di usare metriche relative alla gestione del servizio.
Risposte corrette):
1. Misurare le prestazioni e la disponibilit di tecnologie che compongono i processi
2. Misurare Service Management KPI
3. Misurare l'efficacia di ogni servizio considerato di potenziale miglioramento
Domanda
Cosa dovrebbe fare l'organizzazione fare quando si analizzano i dati relativi al servizio che ha
raccolto?
Opzioni:
1. tendenze rivedere i dati per un periodo di tempo
2. Esaminare le anomalie per determinare se puntano alle tendenze
3. Esaminare cause per i risultati attuali
4. Focus sui risultati negativi nel periodo in corso, come la pi urgente
5. Esaminare i risultati di servizio per un periodo di tre giorni
Risposta
213
Opzione 1: Corretto. L'organizzazione deve prendere in considerazione le tendenze dei dati

per un periodo di tempo sufficiente, altrimenti progressivo miglioramento o deterioramento del
servizio possono passare inosservati.
Opzione 2: Corretto. L'organizzazione dovrebbe esaminare le anomalie per determinare se
questi punto di tendenze di fondo o sono semplici eccezioni.
Opzione 3: Corretto. Quando i risultati attuali richiedono implementazione CSI, diventa
importante esaminare cause sottostanti. Se le cause sono sconosciute, quindi il focus del
processo di CSI potrebbe essere diretto ai processi e servizi sbagliati.
Opzione 4: non corretto. Anche se i risultati negativi si comportano spesso come un trigger
per l'attuazione del processo di CSI, importante rivedere le tendenze nel corso di un
periodo pi lungo per considerarli nel contesto pi ampio.
Opzione 5: non corretto. L'analisi dei risultati in un breve periodo pu portare a tendenze
perdere o male interpretato.
Risposte corrette):
1. tendenze rivedere i dati per un periodo di tempo
2. Esaminare le anomalie per determinare se puntano alle tendenze
3. Esaminare cause per i risultati attuali
Domanda
Si vuole presentare i risultati delle analisi dei dati CSI ai responsabili IT interne
dell'organizzazione e dirigenti.
Quali metodi di formattazione comunicazione e informazione sono adatti per questi
destinatari?
Opzioni:
1. Una balanced scorecard contenente rapporti sul modo in cui i miglioramenti possono
influenzare il servizio clienti e flussi di entrate
2. Un rapporto contenente metriche in grado di suggerire miglioramenti per il
funzionamento interno del Dipartimento IT
3. Un messaggio che spiega il livello di servizio IT e miglioramenti di accompagnamento
4. Un messaggio che suggerisce miglioramenti procedurali per allineare i servizi con
iniziative di miglioramento continuo IT
Risposta
Opzione 1: Corretto. Una scorecard pi rilevante per l'alta direzione. Questo pu aiutare a
determinare miglioramenti strategici e tattici su scala pi ampia, presentati in modo che
illustra il quadro generale.
Opzione 2: Corretto. Interno spesso interessato a KPI e le metriche di attivit che li aiutano
a identificare e pianificare iniziative di miglioramento procedurali per il reparto IT.
Opzione 3: non corretto. I clienti sarebbero pi interessati a sapere se il livello promesso di
servizi IT e dei miglioramenti previsti per l'erogazione dei servizi si sono verificati.
Opzione 4: non corretto. Fornitori e terzi sarebbero interessati a metriche e proposte di
miglioramento relativi ai propri servizi.
Risposte corrette):
214
1. Una balanced scorecard contenente segnalazioni su come miglioramenti pu

influenzare il servizio clienti e le entrate flussi
2. Un rapporto contenente metriche in grado di suggerire miglioramenti per il
funzionamento interno del Dipartimento IT
Domanda
L'organizzazione individua una serie di possibili azioni di miglioramento per il servizio IT.
Quali azioni allinearsi con il processo di CSI e offrir i maggiori benefici per l'organizzazione?
Opzioni:
1. Un investimento a basso costo in aggiornamento di tecnologia che consentir
l'organizzazione di offrire ai clienti aumentato lo spazio di archiviazione senza un
aumento dei prezzi
2. Un miglioramento in un processo che permette ai clienti di rinnovare i loro conti in
modo pi rapido ed efficiente
3. L'acquisto di diversi nuovi, costosi server che permetter servizi IT di lavorare molto
pi velocemente
4. L'assunzione di un nuovo manager IT da una societ concorrente di ottimizzare le
operazioni del reparto IT
Risposta
Opzione 1: Corretto. Il processo di CSI pu chiamare per gli investimenti in nuove tecnologie
se migliora i servizi IT, a condizione che il costo della fornitura di servizi non
massicciamente aumentato.
Opzione 2: Corretto. Il processo di CSI in grado di identificare e diagnosi possibili problemi
nei processi. Seguendo il processo, l'organizzazione in grado di determinare azioni di
miglioramento adeguate per migliorare il processo di malato.
Opzione 3: non corretto. Il processo di CSI pu cedere molte iniziative di miglioramento, ma
tali iniziative sarebbe sfavorevole se aumentano il costo del servizio IT.
Opzione 4: non corretto. Un nuovo manager assunto specificamente per semplificare il
reparto IT possono scegliere di implementare il processo di CSI, ma l'assunzione in s non
rientra nel campo di CSI.
Risposte corrette):
1. Un investimento a basso costo in aggiornamento di tecnologia che consentir
l'organizzazione di offrire ai clienti aumentato lo spazio di archiviazione senza un
prezzo aumenta
di 2. Un miglioramento in un processo che permette ai clienti di rinnovare i loro conti in
modo pi rapido ed efficiente
6. Riepilogo
La portata e benefici del processo di CSI sono stati identificati, e sono stati testati i passi del
processo.
7. Sommario
| Inizio pagina |
215
| 2. Identificare vantaggi e portata |

| 3. Utilizzando il registro CSI |
| 4. Riconoscendo il processo di CSI |
216

ITIL Seconda Parte

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ITIL Seconda Parte

Загружено:

Авторское право:

Доступные форматы

Sommario

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

Ambito di Service Transition................................................................................17

Le politiche di transizione di servizio..................................................................20

Definire e attuare la politica formale...................................................................20

Implementare modifiche ai servizi......................................................................21

Adottare un quadro e norme comuni..................................................................21

Massimizzare il riutilizzo dei processi e dei sistemi istituiti..................................21

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

Ambito di applicazione e finalit.........................................................................29

Pagina 2 di 3: uscita e la distribuzione di pianificazione.............................................31

Knowledge Management nel Service Transition...........................................................36

Ambito di applicazione e finalit............................................................................36

Asset Transition, Servizio di supporto, e test................................................................41

Service Asset and Configuration Management...................................................41

Comprendere processi di transizione di servizio...........................................................50

Riconoscendo politiche di transizione di servizio................................................50

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

Riconoscendo la struttura DIKW..........................................................................56

Finalit e campo di applicazione................................................................................61

tipi di modifica di servizio................................................................................... 63

interfacce Change Management.........................................................................66

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

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

cambiamento del ciclo di vita di emergenza.......................................................74

La gestione dei servizi IT Modifiche.............................................................................. 78

Riconoscere tipi di cambiamento........................................................................78

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

Obiettivi cambiamento di valutazione.................................................................83

Il ruolo della comunicazione nel Service Operation......................................................93

Le pratiche di comunicazione efficace................................................................93

Facilitare riunioni di successo..............................................................................96

Le riunioni operative Servizio comune................................................................98

Service Desk ruoli e obiettivi...................................................................................... 101

Funzioni Service Operation............................................................................... 101

I vantaggi di un service desk............................................................................ 102

Fattori strutturali............................................................................................... 104

strutture di service desk................................................................................... 106

Altre funzioni Funzionamento di servizio....................................................................110

obiettivi formativi.............................................................................................. 110

Obiettivi Service Operation...............................................................................110

Gestione Tecnica............................................................................................... 111

Gestione Applicazione....................................................................................... 116

Uso delle funzioni Service Operation..........................................................................119

panoramica esercizio........................................................................................ 119

Riconoscendo le operazioni di servizio..............................................................119

Impostazione di un service desk.......................................................................121

Digitarel ' equazione qui . ........................................................................................... 123

obiettivi formativi.............................................................................................. 123

Campo di applicazione 1. Incident Management...............................................123

Principi Incident Management...........................................................................125

Il processo di gestione degli incidenti.........................................................................129

identificazione e la registrazione degli incidenti...............................................129

La diagnosi, escalation, e le indagini................................................................133

Risoluzione, chiusura e riapertura.....................................................................135

Gestione Incidenti....................................................................................................... 139

obiettivi formativi.............................................................................................. 139

panoramica esercizio........................................................................................ 139

ambito Identificazione....................................................................................... 139

Identificare i principi......................................................................................... 141

Identificare attivit............................................................................................ 144

Interfacce di gestione degli incidenti..........................................................................147

Incident Management e altri processi...............................................................147

L'area ei principi di Problem Management..................................................................152