Capitolo 7: Ottenere fisico: transizione di servizio

Panoramica

In questo capitolo

Mantenere il controllo delle modifiche

Sapendo quali beni che hai e dove

Distribuzione di roba nuovo o modificato

Migliorare il processo decisionale

Pianificazione e sostenere le transizioni

Avete mai creato grandi progetti solo per scoprire che quando li metti in azione tutto va
terribilmente male? Ci che sembra grande su carta non necessariamente funziona come
volevi. Quando si tratta di progetti IT, potete permettersi di sbagliare? Per aggiungere al
danno la beffa, probabilmente ti aspetto un po ' di un idiota se tutto va a forma di pera.
Cos come si fa a evitare questo accada? Di avere processi di transizione di buon servizio,
naturalmente.
Service transition la fase in cui si costruire, testare e implementa il servizio nuovo o
modificati. In altre parole, questo dove si ottiene fisico. In tutto, ci sono sette processi di
transizione del servizio. Questo capitolo introduce cinque di loro: cambiare gestione;
gestione di asset e configurazione del servizio; gestione del rilascio e la distribuzione;
gestione della conoscenza; pianificazione della transizione e supporto. possibile trovare
i restanti due processi (convalida del servizio e di test e valutazione del cambiamento) in
capitolo 13 .

Comprendere lo scopo della fase di ciclo di vita di transizione servizio

Service transition la fase tra servizio di progettazione (vedere capitoli 5 e 6) e il
funzionamento del servizio (vedere capitolo 8). Questo pu sembrare una cosa strana o
piuttosto ovvia sottolineare; Tuttavia, vale la pena fermarsi e riflettere per un attimo che
cosa questo significa.
Uno degli ingressi principali in una transizione di servizio un pacchetto di progettazione
del servizio (SDP). SDP prodotto durante la fase di progettazione del servizio e contiene
tutte le informazioni necessarie al fine di decidere se andare avanti con la transizione del
servizio nuovo o modificato. importante notare che questo semplicemente
documentazione; la fase di progettazione non cominciare a costruire qualcosa. Il principale
di uscita di una transizione di servizio un servizio nuovo o modificato che viene
consegnato all'operazione del servizio e pu essere utilizzato come richiesto e destinato.
Cos servizio transizione fa il bit in mezzo: tutto il necessario per costruire, testare e
implementare il servizio nuovo o modificato.
1

ITIL Definizione la fase di transizione del servizio di ciclo di vita del servizio mira a
garantire che i servizi nuovi, modificati o pensionati soddisfino le aspettative del business
come documentato nella strategia di servizio e fasi di progettazione del servizio del ciclo di
vita.
Transizione di servizio possa includere le seguenti operazioni:

L'introduzione di nuovi servizi

Modifiche ai servizi esistenti

Lo smantellamento e la sospensione dei servizi

Il trasferimento dei servizi da un fornitore ad un altro, tra cui:

o Servizi

di un fornitore di outsourcing

o Portando

indietro in-House da un fornitore di servizi

o Trasferimento

di servizi da un fornitore ad un altro

Guardando una panoramica dei processi di transizione di servizio

possibile suddividere i processi di transizione del sette servizio come segue:

Processi che supportano tutte le fasi del ciclo di vita di servizio:

o Gestione

del cambiamento

o Gestione

di asset e configurazione del servizio

o Gestione

della conoscenza

Processi che si concentrano principalmente sulla transizione del servizio:

o Gestione

del rilascio e distribuzione

o Transizione

di pianificazione e supporto
2

o Test

e validazione del servizio

o Modificare

la valutazione

A processo un insieme di attivit che sono coordinati per conseguire un obiettivo

specifico. Cos, quello che segue sono le descrizioni di molte attivit che sono necessarie
per costruire, testare e implementare un servizio nuovo o modificato. Non si esegue ogni
processo nell'isolamento; coordinarle per raggiungere un obiettivo generale. La maggior
parte delle attivit per una transizione specifica sono coordinata come un progetto. Dopo
aver letto sui processi qui, guardate capitolo 13 per pi pratici consigli ed esempi di
progetti di servizio transizione.

Controllo del cambiamento: Gestione del cambiamento

Gestione del cambiamento assicura che modifiche IT sono registrate, valutate e
autorizzate e poi implementate in ambiente live in maniera controllata. Le modifiche
potrebbero essere a qualsiasi componente di qualsiasi servizio IT o infrastruttura.
Modifiche possono interessare hardware, software, documenti in realt tutto ci che
sotto controllo. ITIL si riferisce ad esso le modifiche, quindi modifiche al business non sono
normalmente nell'ambito di esso cambiare gestione.
Spesso si vedono cambiare direzione come uno spreco burocratico del tempo. Questo di
solito perch non capiscono i vantaggi della gestione del cambiamento. La naturale
conseguenza di un cambiamento male valutato e mal implementata un incidente che
crea i tempi di inattivit e influenza negativamente l'attivit. Che cosa stupida da fare! Per
non riuscire a valutare e controllare le modifiche correttamente intenzionalmente
rischiare inattivit ai vostri servizi. Sono sicuro che tutti abbiamo provato quelle occasioni
quando un collega rapidamente apporta una modifica a un'impostazione di un server
appena prima di andare in vacanza e si dimentica di dirlo a nessuno. La modifica interessa
qualcosa che crea un errore. La conseguenza un errore imprevisto e non identificato che
spreca una grande quantit di tempo e sforzo per risolvere. Molti ambienti IT sono enormi,
e nessuno persona pu sperare di capire l'effetto di un cambiamento pu avere
sull'enterprise IT. Il processo di gestione del cambiamento mira a garantire che tutte le
proposte di modifiche sono considerati in modo appropriato prima di qualsiasi
generazione, test e implementazione lavoro comincia.
ITIL Definizione Lo scopo del processo di gestione del cambiamento quello di
controllare il ciclo di vita di tutti i cambiamenti, permettendo cambiamenti utili deve essere
fatto con minimo disturbo ai servizi IT.
Chiunque dovrebbe essere in grado di richiedere che il reparto IT apporta una modifica a
uno dei servizi. Si tratta di business, nonch di personale IT. Le modifiche vengono
richiesti in risposta a molte cose, compreso i cambiamenti normativi o legali, cambiamenti
nel business, miglioramenti del software e miglioramenti tecnici e risoluzione degli errori di.
Ricordate Change management non deve essere burocratici. Un sacco di consigli nella
ITIL libri (alcuni di esso incluso qui) consente di creare un processo di gestione del
cambiamento flessibile e adattabile. Dopo aver deciso come gestione del cambiamento
3

funzioner nella vostra organizzazione, assicurarsi di documentare i criteri e il processo

e poi dire a tutti su di esso!

Definizione di alcuni termini di gestione del cambiamento

Per comprendere il processo di gestione del cambiamento, necessario comprendere
alcuni termini:
Cambiamento: ITIL afferma che un cambiamento ' l'aggiunta, la modifica o la
rimozione di tutto ci che pu avere un effetto sui servizi IT. Il campo di
applicazione dovrebbe includere le modifiche a tutte le architetture, processi,
strumenti, metriche e documentazione, nonch le modifiche ai servizi IT e degli altri
componenti. Qualsiasi cambia, tuttavia grande o piccolo, pu potenzialmente avere
un effetto su un servizio IT e quindi un impatto sul business in qualche modo. ITIL
definisce tre tipi di cambiamento: normale, normale e di emergenza. Tutte le
modifiche seguono il processo di gestione del cambiamento normale, ma modifiche
normale e di emergenza sono eccezioni:
o Modifiche standard: In ITIL Parole di , questo 'un cambiamento preautorizzato (chiamato anche un cambiamento di business-as-usual) che a
basso rischio, relativamente comune e segue un'istruzione di procedura o di
lavoro ad esempio, una reimpostazione della password o fornitura di
equipaggiamenti di serie di un nuovo dipendente'. Le modifiche pi standard
seguono una procedura di pre-definito o istruzioni di lavoro; Questo pu essere
un modello di cambiamento o di richiesta che descrive il percorso prestabilito
che dovrebbe essere seguito. (Richiedere modelli sono descritti nel capitolo 8)
Standard modifiche non devono essere avviati da una richiesta di modifica (Vedi
il punto successivo). Modifiche standard sono spesso avviate dal banco di
servizio come le richieste di servizio e affrontate utilizzando il processo di
richiesta di adempimento (vedere capitolo 8). Questo solleva alcuni del carico off
gestione del cambiamento e migliora la flessibilit del vostro processo di
gestione del cambiamento. Ma tenete a mente che non tutte le modifiche
standard sono trattate come le richieste di servizio, e non tutte le richieste di
servizio sono modifiche standard.
Cambiamento di emergenza: Secondo ITIL questo 'un cambiamento che
deve essere introdotto quanto prima ad esempio, per risolvere un grave
incidente o implementare una patch di protezione'. Le modifiche di emergenza
seguono una procedura di pre-definita essi adottano un modello di
cambiamento.
Avviso! Modifiche di emergenza non devono essere utilizzate semplicemente
per accelerare il processo di gestione del cambiamento. Sono necessarie
modifiche di emergenza per correggere una situazione dove c' un grande
impatto sul business e dovrebbe essere mantenuto al minimo.

Richiesta di modifica (RFC): Il ITIL pubblicazioni affermano che questo ' una
proposta formale per una modifica da apportare, inclusi i dettagli della modifica
proposta. Possono essere registrati su carta o elettronicamente '.

Proposta di cambiamento: In ITIL di parole si tratta di un documento che include

una descrizione ad alto livello di un potenziale introduzione di servizio o un
4

cambiamento significativo, insieme a un caso aziendale corrispondente e un

calendario di attuazione previsto.
Proposte di modifica vengono utilizzate le principali modifiche e le nuove
introduzioni di servizio proposti attraverso il processo di gestione del portfolio di
servizio (vedere capitolo 4 ).

Modello di cambiamento: ITIL afferma che un modello di cambiamento ' un

modo ripetibile di trattare con una particolare categoria di cambiamento. Per ogni
categoria di cambiamento, un modello di cambiamento definisce specifici passaggi
concordati che saranno seguite. Modelli di cambiamento possono essere molto
complessi, con molti passaggi che richiedono autorizzazione (ad esempio, una
versione di software pi importanti) o possono essere molto semplice senza
necessit di autorizzazione (ad esempio, la reimpostazione della password)'. Un
modello di cambiamento simile a una procedura di pre-definito modello per la
gestione di un particolare tipo di cambiamento.
Esempio Pack di ad esempio, l'implementazione di un servizio a un server un
cambiamento relativamente comune. Sono sicuro che nella vostra organizzazione
Sai che gestisce tale cambiamento, e ho il sospetto che le stesse persone
coinvolgere ogni volta. L'approccio di buon senso quello di documentare questa
come una procedura, o cambiare modello, per garantire che tutte le modifiche di
questo tipo sono sempre trattate nello stesso modo.

Cambiare advisory board (CAB): In ITIL terminologia di , questo ' un gruppo di

persone che sostengono la valutazione, definizione delle priorit, l'autorizzazione e
la pianificazione delle modifiche. Il gruppo si compone solitamente di rappresentanti
da tutte le aree all'interno dell'organizzazione di provider del servizio IT, business e
terzi quali fornitori. La cabina pu, ma non necessariamente, autorizzare modifiche.
Non tutte le modifiche andare alla cabina; le modifiche di alto rischio e di maggiore
impatto di solito richiedono coinvolgimento dalla cabina.

Emergenza cambia Comitato consultivo (ECAB): Secondo ITIL criteri di questo

' un sottogruppo della cabina che rende le decisioni riguardanti le modifiche di
emergenza. L'appartenenza pu essere decisa quando una riunione viene
chiamata e dipende dalla natura del cambiamento d'emergenza '. Dove possibili,
emergenza i cambiamenti dovrebbero essere autorizzati in modo normale; Tuttavia
in alcune situazioni necessario stabilire un corpo pi piccolo. Il ECAB probabile
che consistono del responsabile delle modifiche pi uno o due altri.
Esempio Imagine qualcosa va male durante la notte e il manager di turno le
operazioni IT apprezza la necessit di risolvere il problema prima che la mattina. In
una telefonata alle 3 del mattino, spiega il manager di turno il problema per il
responsabile delle modifiche, descrive la soluzione e ottiene l'autorizzazione per
apportare la modifica. Il responsabile delle modifiche, quindi, torna a dormire. In
molti casi, l'autorit di prendere tali decisioni in ore del crepuscolo pu essere
delegata per il manager di turno.

Decidere la portata del vostro processo di gestione del cambiamento

5

 necessario definire l' ambito del processo di gestione del cambiamento: che
cambiamenti passano attraverso la gestione del cambiamento e quali no. In particolare,
considerare:
Quando un cambiamento di lavoro, non un cambiamento IT; gli esempi includono
riorganizzazioni dipartimentali
Situazioni come ad esempio sostituendo una rete scheda in una workstation per
risolvere un incidente
Qual il rapporto tra il processo di gestione del cambiamento e il processo di
gestione del progetto
Qual il rapporto con i processi di gestione del cambiamento di qualsiasi fornitore
Non ho risposte definitive a queste situazioni: necessario decidere come essi saranno
trattati nella vostra organizzazione e documentare le decisioni nella vostra politica di
cambiamento e il processo.

Guardando le attivit di Change Management

Le seguenti sezioni affrontano le principali attivit del processo di gestione del
cambiamento.
Creare e registrare il RFC
Cambiamenti sono iniziati da un RFC. Chiunque nella vostra organizzazione dovrebbe
avere accesso alla richiesta di un cambiamento, tra cui uomini d'affari. La modifica
dovrebbe essere registrata dal reparto IT, normalmente nel sistema di gestione di
configurazione (CMS). Questo di solito comporta la creazione di un record di cambiamento
che fornisce un record storico del cambiamento.
In alcuni casi dove il cambiamento grande o complessa, ulteriori informazioni possono
essere richieste. In questo caso dovrebbe essere creata una proposta di cambiamento.
Proposte di modifica vengono spesso utilizzate per ottenere l'autorizzazione iniziale per
nuovi servizi o grandi cambiamenti ai servizi avviati dalla gestione del portafoglio di
servizio (per ulteriori informazioni sulle modifiche proposte e service portfolio management
dare un'occhiata capitolo 4 ).
Rivedere la RFC
Si tratta di un primo esame di RFC. Immaginate un manager di cambiamento entrando
suo ufficio una mattina e scoprire che un mucchio di nuove RFC ha atterrato nel vassoio di
in. Sono sicuro che non si tratta di una situazione sconosciuta per molti di voi. La prima
cosa che fa dare ogni richiesta una lettura veloce e cercare le seguenti operazioni:
Il modulo stato compilato correttamente.
I campi obbligatori sono completi.
Non si tratta di un duplicato di un'altra richiesta.
Non si tratta di una richiesta di ridicola che rientra nell'ambito del processo di
gestione del cambiamento.
Valutare e valutare il cambiamento
Esaminare e valutare il cambiamento. Ci pu essere delle principali attivit e influenzare
la decisione se autorizzare il cambiamento. Chi fa questo dipende il tipo e la portata del
cambiamento. Tutti gli aspetti del cambiamento devono essere considerati, tenuto conto
del business, tecnici e finanziari gli impatti del cambiamento.

Suggerimento Utilizzare il sette Rs di change management per ricordarvi le domande

chiave da porre:

Sollevato: Chi ha rilanciato la RFC?

Motivo: Qual il motivo per il cambiamento?

Ritorno: Che cosa la finanziaria o affari ritorno o quali sono i benefici richiesti dal
cambiamento?

Rischi: Che cosa sono i rischi coinvolti nel processo decisionale, o non fare, il
cambiamento?

Risorse: Quali risorse saranno necessarie per apportare la modifica?

Responsabile: Chi sar responsabile per apportare la modifica?

Relazione: Qual il rapporto con altre modifiche, o quali sono le dipendenze su

altri cambiamenti?

Questa fase include anche la pianificazione e programmazione del cambiamento. Pu

trattarsi di decidere di raggruppare una serie di modifiche in una nuova versione e
aggiungendo il cambiamento per il modificare pianificazione un elenco delle modifiche
che sono state autorizzate e hanno una data di implementazione pianificazione.
Che autorizza il cambiamento Build e Test
Basato sulla valutazione (vedere l'ultima sezione) si pu ora autorizza la costruzione e
collaudo del cambiamento. L' autorit di cambiare la persona che approva il
cambiamento! pu essere chiunque tu voglia che sia.
Stabilire un criterio per come si desidera autorizzare modifiche e decidere su un insieme di
cambiamento autorit. Tabella 7-1 fornisce un set di esempio di autorit.
Tabella 7-1: esempio cambiamento autorit
Apri tabella come foglio di calcolo

Autorit di cambiamento

Livello di rischio/impatto

Comitato esecutivo di affari

Modifica ad alto costo/rischio - richiede

decisione da dirigenti

Consiglio di gestione IT o gruppo

sterzo IT

Modifica che interessa di pi servizi o divisioni

organizzative

CABINA o ECAB

Modifica che interessa il gruppo locale o servizio

solo

Responsabile delle modifiche

Basso rischio cambio

Autorizzazione locale

Modifica standard

Crown copyright 2011. Riprodotti su licenza dall'ufficio di gabinetto.

Coordinare il cambiamento Build e Test
L'attivit successiva consiste nel coordinare la compilazione e il test del cambiamento. La
quantit di lavoro qui dipende dal tipo di cambiamento. Se il cambiamento
7

l'aggiornamento di un documento, si dispone di una quantit molto piccola di costruire e

testare il lavoro. Ma se il cambiamento , diciamo, l'installazione di un nuovo router di rete,
quindi il router dovr essere costruito o configurato e testato, e l'intero servizio pu avere
deve essere controllato per assicurarsi che non vi alcun impatto imprevisto.
Ricordate Il responsabile delle modifiche coordina il cambiamento compilazione e test
coordinando l'attivit dei singoli, team o fornitore che apporter la modifica. Non so cosa
vuol dire il tuo manager di cambiamento, ma nella mia esperienza improbabile per
essere il responsabile delle modifiche se stesso che rotola su suo maniche, preleva un
cacciavite e costruisce il cambiamento.
Il responsabile delle modifiche assicura che i responsabili del cambiamento hanno piani di
test in luogo e anche un piano di back-out o altri piani di risanamento. Un piano di backout garantisce che se si verifica un errore mentre il cambiamento in corso di attuazione,
il servizio pu essere ripristinato a uno stato precedente, noto, stabile. Un piano di
risanamento afferma ulteriore azione necessaria per ridurre al minimo il suo impatto
sull'azienda nel caso in cui il servizio IT non pu essere ripristinato a uno stato stabile.
Distribuzione di cambiamento che autorizza
Una volta il cambiamento stato costruito e testato (Vedi sezione precedente), autorit
data per la distribuzione. Questo fornisce un'opportunit per verificare i risultati del test,
rivedere i piani di risanamento e controllare la data di implementazione pianificata per il
cambiamento. Molti cambiamenti verranno distribuiti utilizzando il processo e le procedure
di rilascio e la distribuzione di gestione vedere la sezione successiva 'ottenere il
cambiamento Out There: rilascio e distribuzione gestione ').
Coordinare la distribuzione di cambiamento
Questa attivit simile a coordinare il cambiamento compilazione e test che ho descritto in
una sezione precedente. molto improbabile che il responsabile delle modifiche
distribuisce effettivamente il cambiamento. Se il cambiamento parte di un rilascio, il
processo di rilascio e distribuzione coordinare la distribuzione. Se si tratta di un semplice
cambiamento quindi verr distribuito sotto il controllo di gestione del cambiamento.
Revisione e il Record di cambiamento di chiusura
L'attivit finale nel processo di gestione del cambiamento quello di esaminare e chiudere
il cambiamento. Tutte le modifiche vengano riesaminate dopo l'attuazione, anche se dove
ci sono un volume elevato di modifiche, controlli in loco sono accettabili. La revisione non
solo per controllare che il cambiamento non ha mancato, ma per garantire che il
cambiamento raggiunto le finalit e i vantaggi che sono stati intesi. Questa recensione si
riferisce a spesso come un post revisione implementazione.
Esempio Pianificazione di cambiamento recensioni
A volte la revisione difficile pianificare poich non chiaro quanto tempo bisogna
aspettare per essere sicuri che il cambiamento ha avuto l'effetto voluto. Ricordo un caso
dove ho studiato un incidente che ha causato la routine di fine anno dell'applicazione
software finanziario a fallire. Io ero il monitoraggio il servizio tramite accesso remoto e per
fortuna sono stato in grado di riavviare la routine e le figure di fine anno sono state
prodotte in tempo. Successivamente, stato studiato il problema associato, la causa
identificata e una RFC generato per correggere un errore di programmazione. Il
cambiamento stato fatto e testato e poi implementato in ambiente live. Tuttavia, non era
possibile stabilire, per alcuni, che il cambiamento aveva risolto il problema fino a quando la
8

stessa routine stata eseguita l'anno successivo. Cos il record di cambiamento rimasto
aperto e la revisione non stata completata fino all'anno successivo.

Sapendo quello che hai ottenuto: servizio Asset e gestione della configurazione
Descritto semplicemente, gestione patrimoniale e di configurazione di servizio (SACM) il
processo che assicura di mantenere informazioni aggiornate su tutti i vostri beni e i componenti dei
servizi IT gestire. Esso mira a mantenere un repository di informazioni su questi componenti
uno o pi database di informazioni. Teoricamente, questo significa registrare ogni PC, applicazione
software, documento, componente di rete, server e cos via, che parte dell'ambiente IT.
Sono sicuro che, come me, avete sperimentato l'incasso di entusiasmo quando si decide
di registrare i dettagli di ogni PC, ogni server e ogni pezzo di software che possiedi,
memorizzarlo in un foglio di calcolo o database. Dopo aver completato questo lavoro,
orgogliosamente realizzare report di tutte le tue cose IT, affettata e tagliata in ogni modo
possibile. Il guaio che l'entusiasmo svanisce poche settimane pi tardi, quando cade
aggiornato il database. Poich si tratta di un processo, SACM costituito da attivit che non
solo vi assicureranno catturare e registrare queste informazioni, ma anche mantenere
aggiornato.
Comprendere gli aspetti di configurazione e di Asset

ITIL afferma che ' il processo SACM mira a garantire che le risorse necessarie per fornire
servizi siano adeguatamente controllate e che precisione e affidabili le informazioni su tali
risorse sono disponibile quando e dove necessario. Queste informazioni includono
dettagli di come sono stati configurati i beni e il rapporto tra il patrimonio. (Capitolo 2
spiega beni.)
Asset management, distinto da Gestione configurazione, generalmente descritto come il
processo responsabile di monitorare e segnalare il valore e la propriet di attivit
finanziarie in tutto il ciclo di vita. Questo tipo di asset management noto anche come
fisso gestione patrimoniale o finanziaria gestione patrimoniale. In alcune organizzazioni,
SACM verr utilizzato per fare alcuni o tutti i cespiti gestione per conto di altre parti del
business.
La maggior parte del Consiglio nella sezione SACM della ITIL libro di transizione del
servizio si riferisce gestione della configurazione. Gestione della configurazione diverso
da asset management in due modi principali:

Essa si occupa di tutte le attivit necessarie per fornire un IT quelli di servizio, non
solo finanziariamente preziosi.

Gestisce le informazioni relative alle relazioni tra attivit.

Questo secondo punto il pi importante perch consente di creare un modello di

configurazione logica dell'infrastruttura e i servizi. L'uso principale del modello logico
9

quello di essere in grado di controllare l'infrastruttura e fornire informazioni a tutti gli altri
processi di gestione del servizio. Ad esempio:

Per migliorare la valutazione dell'impatto dei cambiamenti

Per migliorare la diagnosi di problemi e incidenti

Di fornire processi quali la gestione della disponibilit e gestione della capacit con
una vista dei servizi e loro componenti al fine di identificare le debolezze e le aree
di miglioramento

Definizione di alcuni Asset di servizio e termini di gestione della configurazione

Ci sono alcune abbreviazioni e pezzetti di gergo in SACM, cos qui possibile definire
alcuni di loro:

Elemento di configurazione (CI): La ITIL definizione di questo termine 'qualsiasi

componente o altre attivit di servizio che deve essere gestito al fine di fornire un
servizio IT'. Si registrano informazioni su ogni CI (chiamato attributi cose come
identificatore univoco, nome, stato, proprietario e posizione, fare, specifica) in una
configurazione registrare entro il CMS e mantenere il record in tutto il ciclo di vita.
CIs sono sotto il controllo di gestione del cambiamento. In genere, CIs includerlo
servizi, hardware, software, edifici, persone e documentazione formale come
documentazione di processo e service level agreement (SLA).

CMS: Secondo la ITIL definizione, questo 'un insieme di strumenti, dati e

informazioni che viene utilizzati per supportare la gestione di asset e configurazione
del servizio'. Figura 7-1provides una visione pittorica di un CMS. ITIL continua a
spiegare che ' il CMS parte di un complessivo sistema di knowledge management
di servizio e include strumenti di raccolta, archiviazione, gestione, aggiornamento,
analisi e presentando dati relativi a tutti gli elementi di configurazione e le loro
relazioni. Il CMS pu anche includere informazioni su incidenti, problemi, errori noti,
le modifiche e uscite. Il CMS gestito da gestione di asset e configurazione del
servizio e viene utilizzato da tutti i servizio processi di gestione IT.
A CMS non un singolo database, ma come si pu vedere dalla figura, il CMS
prende i dati da molte fonti. Uno o molti database di gestione della
configurazione(CMDB)contengono informazioni su CIs. Ci pu essere uno per
ciascuno dei vostri siti: dire uno per l'ufficio di Londra e un altro per l'ufficio di New
York. Il CMS l'insieme di strumenti software o applicazioni che riguarda il CIs
registrata nel CMDB con gli incidenti rilevanti, problemi, modifiche e altri record
memorizzati in altri posti.

Previsione di configurazione: ITIL definisce questo come ' una linea di base di una
configurazione che stato formalmente concordata ed gestita attraverso il
processo di gestione del cambiamento. Una baseline di configurazione viene
10

utilizzata come base per il futuro si basa, versioni e modifiche. Una baseline di
configurazione serve come base per ulteriori attivit e pu essere modificata solo
attraverso procedure di cambiamento formale. Un buon esempio una build
standard di un PC, dove ha concordato che ogni PC dovrebbe essere costruito e
configurati nello stesso modo. In ogni caso, si consiglia di documentare questa
come un IC a se stante.

Snapshot: Secondo ITIL, questo ' lo stato corrente di un elemento di

configurazione, di processo o di qualsiasi altro set di dati, registrati in un punto
specifico nel tempo. Gli snapshot possono essere catturati dagli strumenti di
scoperta o di una tecnica manuale come una valutazione '. Uno snapshot registra la
configurazione di uno o pi componenti in un determinato punto nel tempo e non
necessariamente rifletta lo stato desiderato, autorizzato dei componenti. Una linea
di base si pu dire per indicare la 'destinazione' configurazione di uno o molti CIs,
considerando che un'istantanea la 'configurazione' effettiva prevista o in caso
contrario.
Come i nome suggerisce, uno snapshot l'equivalente di scattare una fotografia di
un componente IT un punto nel tempo. Sono sicuro che vi ricordate puzzle 'spot the
difference' dei bambini dove si sono tenuti a identificare le differenze tra due
immagini apparentemente identiche. solitamente cravatta dell'uomo che
macchiato invece a strisce! Allo stesso modo, possibile confrontare uno snapshot
con una previsione autorizzato e tenta di individuare la differenza. Eventuali
differenze che si scopre possono significare un cambiamento non autorizzato
avvenuto, ad esempio l'utente ha scaricato e installato un'applicazione software da
Internet senza autorizzazione.

Biblioteca multimediale definitivo (DML): ITIL afferma che questo ' una o pi
posizioni in cui sono memorizzate in modo sicuro le versioni definitive e autorizzate
di tutti gli elementi di configurazione del software. La DML pu contenere anche gli
elementi di configurazione associati quali licenze e documentazione. un'area di
archiviazione logica singola anche se ci sono pi posizioni. La DML controllato da
SACM, anche se forma il Fondazione di molta attivit di gestione di stampa e
distribuzione. Una 'lista' di ci che in DML sar nel CMS, e ci saranno definite le
procedure per l'aggiunta, la copia e la rimozione di CIs archiviati qui.
La DML dove memorizzare le copie master controllate e autorizzate di tutte le
versioni del software, insieme a tutti i documenti pertinenti. Pu essere fisica o
un'area di archiviazione dei file. Un DML fisico pu essere un armadio chiuso:
scaffali contenenti nastri, CD, DVD e altri supporti che contengono copie di software
master e documenti come i contratti di licenza e ordini che dimostrano la propriet
di acquisto. La DML deve essere attentamente controllato, gestito e backup e
separata dagli altri ambienti quali sviluppo, test o gli ambienti live.
11

Figura 7-1: Esempio visione pittorica di un CMS.

Guardando le attivit della SACM

Le sezioni seguenti vi portano attraverso le attivit del processo di gestione patrimoniale e
la configurazione di servizio.
Gestione e pianificazione
Se avete bisogno di pianificare tutti i processi di gestione del servizio, l'attivit non viene
visualizzato in ogni ITIL processo, allora perche ' SACM speciale? Poich la gestione e
pianificazione fondamentale per ottenere il disegno del CMS correggere, tale che
supporta tutte le attivit di gestione del servizio ed scalabile per le esigenze future.
necessario documentare un piano SACM. Il piano contiene cose come:
Ambito di applicazione e requisiti della SACM per la vostra organizzazione
Criteri applicabili, norme e organizzazione per SACM
Processi, procedure e strumenti per SACM.
La combinazione delle politiche SACM e un piano di gestione di configurazione unit il
resto delle attivit SACM.
Identificazione di configurazione
Identificazione di configurazione comprende tutte quelle attivit necessarie per decidere
come i beni di servizio saranno registrati nel CMS e come saranno identificati ed
etichettati. Questo include:
Definire e documentare come CIs saranno selezionati e raggruppati
Assegnazione di identificatori unici
Specificare gli altri attributi di ogni CI e le loro relazioni
12

Un problema comune consiste nel decidere quanti CIs si dovrebbe registrare nel tuo CMS
per rappresentare risorse dall'ambiente IT. Ad esempio, puoi registrare un PC desktop
come un singolo CI o CIs diversi? Si pu scegliere di avere un separato CI per uno
qualsiasi o tutti i componenti come ad esempio monitor, mouse, tastiera, unit base, disco
rigido, unit DVD/CD, scheda di rete e cos via. Si deve tenere a mente che per ciascuno
di questi che si decide un separato CI, si stanno commettendo di registrarlo dal suo
numero di serie o altro identificatore univoco in tutto il ciclo di vita. Ci pu essere
rappresentato tramite relazioni padre-figlio, come illustrato nella figura 7-2. Per ogni CI si
registra un insieme di attributi.

Figure 7-2: Example of CIs and their relationships for a desktop PC.
Figura 7-2: Esempio di CSI e le loro relazioni per un PC desktop.
L'esempio qui utilizzato quello di un PC; Tuttavia, il principio lo stesso se si stanno
prendendo in considerazione hardware, software o qualsiasi altro tipo di bene. Cos come
si fa a decidere quale CIs per registrare? Beh la risposta , dipende.
Suggerimento Qui ci sono alcune regole generale per decidere quali CIs di registrare nel
tuo CMS:
Andare gi per il livello di modifica unilaterale, cio decidere quale livello pi
appropriato per controllare i cambiamenti dell'asset.
Prendere in considerazione l'equilibrio tra il livello di dettaglio e lo sforzo e il costo di
mantenere aggiornate.
Non registrare l'asset nel vostro CMS, se non hai intenzione di mantenere il record
aggiornato.
Controllo di configurazione
Controllo di configurazione il termine per le attivit che consentono di decidono il livello
di controllo appropriato per ogni CI. La questione fondamentale chiedere qui : 'Come
controlliamo le modifiche a CIs?' La risposta pi semplice : 'con il processo di gestione
modifiche.' SACM e change management sono legati indissolubilmente. A un livello molto
13

basilare, gestione del cambiamento autorizza le modifiche a CIs mentre SACM aggiorna il
record di configurazione. In termini pratici, questo una semplificazione eccessiva. Il
modo migliore per iniziare quello di guardare ogni tipo di CI (ad esempio, applicazione di
software, PC) e decidere se le modifiche devono passare attraverso il processo di
gestione del cambiamento completo o un altro meccanismo con autorit delegata. Il punto
importante quello di assicurarsi che vi sia almeno un audit trail delle modifiche.
Lo stato e la rendicontazione contabili
Contabilit di stato rappresenta lo stato di ogni CI. Addentrarsi qualsiasi reparto e vedrete
un monitor sul pavimento con una nota di Sticky Notes che indica ' non funziona non
usare ' e un computer portatile con un'altra etichetta che indica 'attesa aggiornamento', o
un server con un'etichetta dicendo 'in prova'. Tutti questi pezzi di carta dirvi lo stato
corrente dell'attivit, o CI. Contabilit di stato equivale a mettere un pezzo di carta adesiva
su ogni CI per denotare lo stato si in, o la sua situazione. Tuttavia, in realt, lo stato
dell'IC viene registrato come un attributo nel CMS.
Il potere della contabilit di stato la capacit di query o report sullo stato del CIs registrati
nel CMS. Utilizzando stato contabilit si pu rispondere a domande quali:
Quanti pezzi devono essere sostituite?
Quanti sistemi bisogno il nuovo service pack?
Che attrezzatura oggetto di questo contratto?
Quali modifiche sono state apportate a questo server?
Quante licenze abbiamo?
Verifica e controllo
L'attivit di Verifica e controllo consente di verificare se il tuo CMS una rappresentazione
accurata dei vostri beni reali, infrastrutture e servizi. Sicuramente non devi farlo! Con
configurazione controllo e gestione del cambiamento in atto, tutti i record sono fino ad oggi
non vero? Beh, appena persone coinvolti, le cose non sempre vanno come previsto.
Cos il buonsenso per verificare che i processi e le procedure sono seguite da eseguire
controlli regolari o occasionali.
Ricordate Audit pu essere eseguito fisicamente utilizzando personale per controllare le
apparecchiature IT, annotando i dettagli e confronto con i dettagli e l'aggiornamento, il
CMS. Spesso strumenti di rilevamento di software possono essere utilizzati per
raccogliere elettronicamente i dettagli dei componenti. Tali strumenti sono enormemente
utile, ma non date per scontato che sono un sostituto per un processo SACM ben
progettato, documentato e comunicato. Pensate a quando si eseguono audit: forse prima
di apportare modifiche, prima release sono distribuiti e al previsto e intervalli casuali.

Ottenere il rilascio di l fuori: rilascio e gestione della distribuzione

Gestione del rilascio e la distribuzione molto pi appena le ultime fasi della gestione del
cambiamento: un ulteriore insieme di attivit che vengono attivati dopo aver deciso di
raggruppare una serie di modifiche insieme in un comunicato.
ITIL Definizione lo scopo del processo di gestione di rilascio e la distribuzione di
progettare, pianificare e controllare la build, test e distribuzione di comunicati e di offrire
nuove funzionalit richiesti dall'azienda, proteggendo l'integrit dei servizi esistenti.
Non tutte le modifiche vanno attraverso la gestione di rilascio e la distribuzione. Tuttavia,
probabile che, nel corso del tempo, una grande percentuale di modifiche sar introdotte
14

nell'ambiente live utilizzando le procedure e metodi sviluppati da Gestione stampa e

distribuzione.
Non solo rilasciare e gestione distribuzione implementare servizi nuovi e modificati, ma si
occupa anche di richieste per i componenti aggiuntivi. Una volta che le modifiche e uscite
sono state implementate, le richieste per le distribuzioni di ripetizione sono soddisfatte
facilmente utilizzando un modello di distribuzione. Il successo del processo di
adempimento della richiesta (vedere capitolo 8) basato sui modelli di distribuzione
buona.
Esempio Ad esempio, una richiesta per un nuovo PC ricevuto dal service desk
attraverso il processo di richiesta di adempimento. Il service desk segue il modello di
processo di modifica standard al fine di accedere e ottenere l'approvazione per la
richiesta. Passa quindi al team tecnico responsabile dell'esecuzione della richiesta, che
seguono il modello di distribuzione pre-concordato. proprio come la manovella su una
macchina, e un altro salta fuori alla fine.

Definizione di alcune Release e termini di gestione distribuzione

Il processo chiamato gestione rilascio e distribuzione, ma c' qualche differenza tra le
parole rilasciare e distribuzione? S: un rilasciare la cosa l'oggetto o il sostantivo. La
distribuzione quello che stai facendo la cosa il verbo. Cos, quando si esegue una
distribuzione, si sta distribuendo un rilascio nell'ambiente live. Figura 7-3shows una
visione pittorica di questo.

ased su ITIL materiale. Riprodotti su licenza da The Cabinet Office.

Figura 7-3: Panoramica degli elementi di gestione del rilascio e la distribuzione.
15

Un esempio di un rilascio
Si supponga che si prenda l'esempio di andare a lavorare, sul presupposto che si deve
andare in ufficio e non stai lavorando a casa. Si pu considerare se stessi di essere il
rilascio. Sono sicuro che si prepara te stesso, o il rilascio, prima di lasciare la casa.
Assicurarsi che si sono vestiti, avete la valigetta con voi e avete pianificato anche i mezzi
di viaggiare per lavoro. Pu anche controllare i problemi di traffico o di trasporto prima di
partire: controllare i mezzi di distribuzione. Tutto questo viene fatto prima di arrivare alla
tua porta e lasciare la vostra casa. Questo l'equivalente della progettazione, costruzione
e test di rilascio. Ora sei a due passi, possibile distribuire voi stessi nel vasto mondo,
utilizzando il metodo di viaggio e gli obiettivi che hai gi impostato. Quindi questo
equivalente alla distribuzione di un rilascio nell'ambiente live.
Per comprendere il processo di gestione del rilascio e la distribuzione, necessario
comprendere alcuni termini:
Release: ITIL dice che questo ' una o pi modifiche a un servizio IT che sono
costruite, testati e distribuiti insieme. Un singolo rilascio potrebbe includere
modifiche all'hardware, software, documentazione, processi e degli altri
componenti. Molte delle attivit di rilascio e la distribuzione gestione riguardano la
preparazione del rilascio. Ad esempio, decidere quali modifiche verranno
raggruppati in un comunicato, e come il rilascio sar costruito e testato.
Distribuzione: Secondo ITIL , ' 'l'attivit responsabile del movimento di nuovo o
modificato hardware, software, documentazione, elaborare e cos via per l'ambiente
live'. Le distribuzioni variano in dimensioni e complessit. Essi possono variare da
l'installazione di un singolo PC secondo un modello di distribuzione per dare piena
attuazione un nuovo servizio composto da pi componenti software e hardware in
molte workstation di destinazione, server o gli utenti. La distribuzione include anche
la consegna dell'operazione del servizio per servizio.
Unit di sblocco: Il ITIL definizione di questo termine ' i componenti di un
servizio IT che normalmente vengono rilasciati insieme. Un'unit di rilascio include
in genere componenti sufficienti per svolgere una funzione utile. Ad esempio,
un'unit di rilascio pu essere un desktop PC, incluso hardware, software, licenze,
documentazione e cos via. Un'unit di rilascio diverse pu essere l'applicazione
completa delle retribuzioni, incluse le procedure di operazioni IT e formazione degli
utenti '.
Esempio Imagine che il reparto vendite della vostra organizzazione utilizza un
servizio IT vendito composto da una suite di applicazioni quali il sistema di
amministrazione di rapporto del cliente (CRM), il sistema di ordine di vendita e il
sistema di post-vendita. C' una decisione politica per essere fatto qui. Se, diciamo,
un modulo del software del sistema di ordine di vendita una modifica apportata ad
esso, necessario distribuire solo il singolo modulo, tutto il sistema di ordine di
vendita o l'intero servizio di vendite? La risposta , inevitabilmente, 'dipende'. Ma
ora necessario considerare se migliorerebbe la qualit complessiva dei vostri
servizi IT per attuare una regola generale per guidare tutte le distribuzioni future del
servizio vendita. Cos se si decide che una modifica a un modulo del sistema di
ordine di vendita si tradurr nella distribuzione del sistema di ordine di vendita tutto,
avete scelto il sistema di ordine di vendita come l'unit di rilascio. Questa ora la
politica per la suite di software di vendita.

16

Unit di rilascio sono utili in consente di rompere il vostro ambiente live in pezzi di
dimensioni morso, soprattutto quando si tratta di distribuzione di ripetere
installazioni standard e cambiamenti come quelli lanciati attraverso il processo di
richiesta di adempimento.
Pacchetto di rilascio: ITILdefinizione afferma che questo ' un insieme di
elementi di configurazione che verranno costruiti, testati e distribuiti insieme come
un singolo estratto. Ogni pacchetto di rilascio di solito comprende una o pi unit di
rilascio. Al fine di minimizzare l'impatto delle distribuzioni sugli utenti, spesso
conveniente distribuire molte unit di rilascio in una sola volta. Quando si sposta in
una nuova casa, non ti muovi ogni possesso separatamente, pop cose in scatole,
solitamente organizzato dalla camera di destinazione come camera da letto o in
cucina. Un pacchetto di rilascio piuttosto come la scatola di cartone che mettete
vostri possessi poll.
Opzioni di distribuzione: Quando un servizio nuovo o modificato stato
progettato, il metodo di distribuzione dovrebbe essere considerato allo stesso
tempo. Questo accade in fase di progettazione del servizio del ciclo di vita del
servizio. Cos gran parte dell'approccio alla pubblicazione e distribuzione viene
deciso durante la progettazione. Qui ci sono alcune opzioni di distribuzione
possibili:
o Big bang contro approccio graduale: Big bang si riferisce alla
distribuzione il rilascio di tutte le aree di destinazione in una sola volta. Ad
esempio, un aggiornamento per l'applicazione di software ufficio vendite
potrebbe essere necessario essere distribuito a tutto il personale vendito in
una sola volta, perch contiene nuovi dati di prodotto. D'altra parte,
ungraduale approccio quando il rilascio viene distribuito ad aree diverse in
momenti diversi, forse che l'ufficio di Londra questa settimana seguita da
parte dell'ufficio di Parigi la settimana dopo. Questo un approccio meno
rischioso e permette alle risorse di essere gestiti in modo pi efficiente.
o Push vs pull: Push si riferisce a quando una versione distribuita da un
punto centrale. Questo comporta spesso l'utilizzo di strumenti di distribuzione
software automatico che scambiano una nuova release da un server centrale
e installare il software aggiornato su tutte le workstation di destinazione. Gli
utenti normalmente non ottenere una scelta su quando ricevere
l'aggiornamento. D'altra parte, tirando un rilascio consente all'utente di
ottenere il rilascio di nuovo facendo clic su un collegamento ipertestuale e
l'installazione del software in un momento conveniente.
o Manuale contro automatico: i metodi push e pull (Vedi punto precedente)
sono normalmente ottenuti utilizzando strumenti automatici per distribuire e
installare la versione. In alcuni casi, la distribuzione automatica potrebbe non
essere possibile e distribuzione manuale il metodo appropriato. A volte
l'invio di un ingegnere con una scatola piena di CD e un cacciavite in tasca
potrebbe essere l'unico modo.
Politica di rilascio: Molti degli elementi del rilascio e la distribuzione gestione
dovrebbe essere concordati in anticipo e documentati in un criterio di rilascio. Un
criterio un insieme di decisioni regole se volete che forniscono indicazioni di
alto livello su come deve essere eseguito il processo. Salva gente reinventare la
ruota ogni volta che fanno qualcosa. Il criterio di rilascio deve contenere:
o Definizione dei tipi consentiti di rilascio, ad esempio maggiore, minori ed
emergenza
o Denominazione e numerazione convenzioni per i rilasci
o Frequenza prevista di ciascun tipo di rilascio
17

Ruoli e responsabilit per il processo di gestione del rilascio e distribuzione

La politica di rilascio di solito creata e concordati con il responsabile delle

modifiche e comprende anche l'approccio prescelto a modifiche nelle versioni di
raggruppamento.

Guardando le attivit di rilascio e gestione della distribuzione

Le sezioni seguenti vi diamo il low-down sulle attivit che si impegnano in questo
processo.
Rilascio e pianificazione della distribuzione
Rilascio e pianificazione della distribuzione implica la pianificazione ad alto livello della
release, tra cui la pianificazione delle attivit successive, decidere o conferma delle
modifiche che devono essere incluse nel comunicato e la selezione di un modello di
rilascio e distribuzione pre-definito.
Build di rilascio e Test
Compilazione e test si intende la compilazione e il test del rilascio e il meccanismo di
distribuzione. Quindi questo non solo include test che assicurano che i nuovi o modificati
servizio soddisfer i suoi obiettivi, ma test dei mezzi di distribuzione del rilascio, come
l'uso di uno strumento di distribuzione software automatico per garantire che, una volta
distribuito, la nuova versione del software sar installarsi sulla workstation di destinazione
e sia disponibile per l'utente.
Edificio comprende prendendo i singoli componenti che sono stati soggetti a modifiche e
loro costruzione in una singola unit, o release. Nel caso di un PC desktop, possibile
l'assemblaggio di componenti hardware e l'installazione delle applicazioni software.
Questo, naturalmente, ora dovrebbe essere testato.
Test del servizio assicura che i componenti modificati ancora azionarlo correttamente
come parte dell'intero servizio. Se necessario, un pilota pu anche essere eseguito. Una
distribuzione pilota l'installazione della versione a un numero rappresentativo e il tipo di
target o utenti per dimostrare che sia la versione funziona come richiesto e i metodi di
distribuzione sono anche successo.
Distribuzione
Alcuni della pianificazione per la distribuzione viene eseguita come parte del rilascio
generale e pianificazione della distribuzione. Tuttavia, in questa fase necessario
aggiungere maggiori dettagli.
Distribuzione pu includere distribuzione, pensionamento o trasferimento; il termine si
riferisce a eseguire l'azione appropriata sul patrimonio. Potrebbe essere la distribuzione
dei componenti che compongono il rilascio nell'ambiente live. In alcuni casi, il progetto pu
essere ritirarsi o sostituire un servizio, pertanto i relativi beni come hardware e software
verranno rimosso dall'ambiente live e record aggiornati. Trasferimento si intende il caso in
cui la propriet dei beni viene modificata. Forse si outsourcing un servizio che hai
utilizzato per fornire voi stessi, e propriet di alcuni hardware, software o anche le persone
deve essere trasferito a un'organizzazione diversa.
L'attivit di distribuzione comprende non solo la distribuzione del servizio nuovo o
modificato, ma pu coinvolgere molti altri compiti, finanziarie e commerciali e alcuni
18

amministrative come l'acquisto di licenze software e trasferimento di diritti di propriet

intellettuale.
Early Life Support
Primi anni di vita di supporto l'insieme di attivit che assicurano che il servizio nuovo o
modificato non solo 'generato oltre il muro' nell'operazione del servizio. necessario
assicurarsi che il personale coinvolto nella transizione servizio mettersi in contatto con
personale di funzionamento di servizio per garantire che tutto ci che appropriato che
stato appreso durante la compilazione, test e distribuzione consegnato al personale
responsabile per la cura dopo il servizio quando vivo.
Ricordate Sostegno di vita precoce dovrebbe essere ritirata soltanto quando determinati
test di verifica sono stati met. Questi possono includere quanto segue:
Gli utenti possono utilizzare il servizio come previsto.
SLA sono ultimati e firmati off. (Ulteriori contratti di servizio in Capitolo 5 .)
Servizio obiettivi vengano raggiunti costantemente per un periodo concordato.
Variazioni repentine delle prestazioni sono segnalati e gestiti.
Service Release sono firmati dal business.
Revisione e Chiudi
Ho il sospetto che la maggior parte di distribuzioni o transizioni di servizio sono portata
fuori come progetti, pertanto quando si tratta di chiudere la distribuzione o la transizione di
servizio, molte delle attivit sono quelli che svolgono alla fine di qualsiasi progetto. Ci,
naturalmente, saranno alcuni che sono specifici per il servizio o il rilascio.
Per la chiusura di ogni distribuzione:
Acquisire feedback da utenti e personale IT.
Esaminare le modifiche apportate aperte, problemi ed errori noti.
Rivedere gli obiettivi di prestazione e le realizzazioni.
Documento lezioni apprese.
Per chiudere il passaggio di servizio:
Effettuare una revisione formale.
Verifica che tutte le attivit siano complete e aggiornati record.
Valutare il servizio.

Prendere migliori decisioni: Gestione della conoscenza

Gestione della conoscenza, naturalmente, riguarda la gestione della conoscenza ma
quale conoscenza? In breve, le conoscenze necessarie per gestire i servizi IT in tutto il
ciclo di vita di servizio. Sai dove tutti i dati, informazioni e conoscenza memorizzato nella
vostra organizzazione? scritto verso il basso, in un database o in testa a qualcuno?
Quando lo trovi, lo sai che accurate, aggiornate e non duplicato altrove? Dati,
informazioni e conoscenza includono cose come dati di misurazione del servizio e
obiettivi, SLA, operational level agreement e contratti, manuali tecnici, documenti di
esperienze passate, progetto documentazione e riferimenti a risorse Internet. La lista
infinita.
ITIL Definizione lo scopo del processo di gestione della conoscenza a:
Condividere informazioni, idee, esperienza e prospettive e garantire che questi siano
disponibili nel posto giusto al momento giusto per consentire decisioni informate
Migliorare l'efficienza riducendo la necessit di ritrovare la conoscenza
19

Cos, quali decisioni informate fai? Qui ci sono alcune possibilit:

Dovremmo investire in questo servizio?
Dobbiamo andare in pensione o sostituire questo servizio?
Quali sono i rischi per la fornitura del servizio in conformit con i requisiti del livello di
servizio?
Quali sono i problemi comuni con il servizio?
Chi ha le competenze per risolvere alcuni tipi di problema?
Chi sono i clienti e gli utenti di questo servizio?
Cosa fanno risorse abbiamo a disposizione?
Sono che nostri SLA si rivolge rispettati?

Definizione di alcuni termini di gestione della conoscenza

Ecco una spiegazione di alcuni termini chiave:

Dati: Una serie di fatti discreti.

Informazioni: Proviene da fornire contesto ai dati.

Knowledge: Composto da Tacito esperienze, idee, intuizioni, valori e giudizio degli

individui.

Saggezza: Fa uso della conoscenza per creare valore attraverso decisioni corrette e
ben informate. Saggezza implica che l'applicazione e la consapevolezza
contestuale a fornire un giudizio di senso comune forte.

Figura 7-4 viene illustrata la relazione tra dati, informazioni, conoscenza e saggezza
(questo il modello DIKW).

20

Figura 7-4: Il flusso di dati alla saggezza.

Esempio di dati di saggezza
Se vi dicessi che la mia scrivania servizio aveva registrato 1.000 chiamate luned, cosa ne
pensi? Sei colpita? Beh, che non dovresti essere. Tutto quello che vi ho dato un pezzo
unico di dati. Senza ulteriori dati non hai idea se questo buono o cattivo.
Se ora ti dicessi che oltre i 1.000 invita luned, abbiamo ricevuto 2.000 chiamate il marted.
Siamo qualsiasi ulteriormente in avanti? Anche nella sua forma pi semplice, ora avete un
pezzo di informazione. Sai che abbiamo registrato due volte altretante chiamate il marted
come abbiamo fatto il luned. Certo, questo non molto eccitante.
Successivamente, avrai vuotare il sacco. In realt, abbiamo registrato 3.000 chiamate su
mercoled, 4.000 gioved e 5.000 il venerd. Ulteriormente, ho misura questo per tre mesi e
posso dirvi che questa una tendenza e si ripete ogni settimana. Cosa c' di pi, sono
stato con queste tendenze per gestire la rota di spostamento per la mia scrivania di
servizio. Si spera, si concluder in questo momento che ho una conoscenza di con cui ho
fatto le decisioni forse sagge decisioni.

Service sistema di knowledge management (SKMS): ITIL definisce questo come

"un insieme di strumenti e database utilizzati per gestire dati, informazioni e
conoscenza. La SKMS include il CMS come pure altri database e sistemi
informativi. La SKMS include strumenti di raccolta, archiviazione, gestione,
aggiornamento, analisi e che presenta tutte le conoscenze, informazioni e dati che
un fornitore di servizi IT ha bisogno di gestire l'intero ciclo di vita dei servizi IT.
La SKMS contiene il CMS, e il CMS contiene uno o molti CMDB.

Ricordate DIKW il modello e il SKMS sono correlati. In primo luogo necessario decidere
cosa decisioni si vuole fare e quali servizi si desidera renderli circa. Poi si pu iniziare a
descrivere la conoscenza che verr memorizzata nella tua SKMS. Ma da dove proviene la
conoscenza? Proviene il modo di combinare e organizzare le informazioni. Infine,
necessario decidere quali dati necessario al fine di creare le informazioni.

Guardando le attivit
Le attivit di knowledge management sono:
Strategia di knowledge management: Le decisioni che vengono prese per quanto
riguarda i servizi sono solo buone come i dati, informazioni e conoscenze fornite al
decisore. Quindi, prima di progettare e impostare un SKMS, necessario decidere
su una strategia. Come con tutti i processi di gestione del servizio, la strategia
necessaria deve iniziare dalla comprensione delle esigenze degli stakeholder. Cos
si identifica che utilizzeranno la conoscenza e che tipo di decisioni che vogliono fare
sui servizi IT. Da questo possibile definire una strategia e politica per il knowledge
management.
Trasferimento di conoscenza: Come conoscenza trasferito o condivisi con, le
persone appropriate nell'organizzazione. Conoscenza pu essere trasferita in molti
modi. importante variare il metodo di trasferimento e, in particolare, per tener
conto di pubblico. Esempi di metodi di trasferimento di conoscenza esperienza
hands-on, formazione, partecipazione a seminari e webinar e distribuzione di riviste
e newsletter.
21

Gestione dati, informazioni e conoscenza: sono sicuro che avete sentito

l'espressione 'garbage in, garbage out'. Le conoscenze fornite dal SKMS sono solo
buona come i dati che vengono raccolti e archiviati. Cos ora che avete deciso
quale conoscenza necessaria per prendere decisioni, identificare i dati che sono
necessario fornirlo. La quantit di dati in questione potenzialmente enorme, cos
attenta considerazione deve essere dato per la raccolta, la manutenzione e la
manipolazione dei dati e delle informazioni memorizzate nella SKMS.
Utilizzando il SKMS: importante garantire che, una volta stabilito, il SKMS viene
utilizzato dalle persone appropriate e che si raggiunto l'obiettivo di migliorare la
qualit del processo decisionale. Considera:
o Controllo dell'accesso per la SKMS
o Fornire materiali di conoscenza nel formato appropriato, ad esempio come
report, manuali o siti Web
o Monitoraggio l'uso, la precisione e l'utilit della SKMS

Pianificazione della transizione e supporto

Avete un ufficio di programma o progetto nella vostra organizzazione? Se lo fai, pu
essere familiare con il suo ruolo nella pianificazione e coordinamento di progetti di alto
livello. Pianificazione della transizione e supporto esegue attivit analoghe per i vostri
progetti di transizione. Le attivit di transizione del servizio sono spesso svolte come
progetti, o fanno parte di altri progetti. Quando si considerano tutti i processi di transizione
del servizio, ci sono potenzialmente un gran numero di attivit che hanno bisogno di
coordinamento.
ITIL Definizione ' lo scopo del transizione pianificazione e sostenere il processo di di
fornire pianificazione generale per le transizioni di servizio e di coordinare le risorse
richiedono '.
L'input per la fase di transizione del servizio il SDP (vedere la sezione precedente
'comprendere lo scopo della fase di ciclo di vita di transizione servizio'). Questo dovrebbe
contenere tutte le informazioni necessarie per pianificare e gestire un progetto di
transizione, tra cui risorse e piani di alto livello le stime. Molte delle attivit del processo di
pianificazione e supporto di transizione prendere informazioni da SDP e utilizzarlo per
creare piani dettagliati.
Ecco un breve sguardo alle attivit di pianificazione della transizione e supporto:
Strategia di transizione: Si muta, l'approccio generale per la transizione del
servizio e mantenere un insieme di politiche di transizione servizio.
Prepararsi alla transizione di servizio: Si prende il SDP ed eseguire alcuni dei
seguenti:
o Esaminare il SDP e i criteri di accettazione del servizio.
o Identificare, raise e pianificazione RFCs.
o Verifica o stabilire linee di base.
Pianificazione e coordinamento servizio transizione: Si esegue il seguente:
o Creare i piani dettagliati e tempistiche.
o Allocare risorse.
o Gestione dei registri di problemi e rischi.
o Coordinare il progetto.
Forniscono il supporto del processo di transizione: In tutto il progetto di
transizione, svolgete attivit incluse le seguenti:
o Offrire consulenza e orientamento.
o Fornire supporto per l'amministrazione.
22

o Monitorare

e creare report sullo stato di avanzamento.

Identificare i ruoli di transizione del servizio

Ogni processo di gestione del servizio deve avere un proprietario di processo e un gestore
di processi. Spiegare questi due ruoli in capitolo 2. Per i processi di transizione del
servizio, i ruoli di gestione processo rilevanti sono:
Processi di gestione del cambiamento
Servizio asset e configurazione di processi di gestione
Processi di gestione rilascio e distribuzione
Processi di gestione di conoscenza
Ogni ruolo responsabile per le attivit descritte nell'apposita sezione di questo capitolo.
Utilizzando la tecnologia per Service Transition
Ecco alcuni strumenti che possibile utilizzare nel servizio di transizione di fase per
supportare i processi di transizione del servizio:
Il CMS per la memorizzazione di informazioni sugli elementi di configurazione e
record associati
Il SKMS
Strumenti di rilevamento che identificare automaticamente i componenti
collegati a una rete
Strumenti di distribuzione software per distribuire automaticamente versioni
software
Strumenti di test che consentono di automatizzare test pratiche

23