Sei sulla pagina 1di 17

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 creare, testare e implementare il nuovo servizio o cambiato servizio.
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.
Definizione di ITIL 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
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 a modifiche IT, quindi modifiche al
business non sono normalmente entro l'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.
Definizione di ITIL 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 Gestione del cambiamento non deve essere burocratici. Un sacco di consigli nei libri ITIL
(alcune di esso incluso qui) consente di creare un processo di gestione del cambiamento flessibile e
adattabile. Dopo aver deciso come gestione del cambiamento 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: Parole di in ITIL, questo 'un cambiamento pre-autorizzato (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. (Modelli di richiesta sono descritti in
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 gli standard 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! Emergenza modifiche 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): Pubblicazioni di the ITIL 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: Nelle parole di ITIL si tratta di un documento che include una descrizione
ad alto livello di un potenziale introduzione di servizio o un 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 Ad esempio, l'implementazione di un servizio pack 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): Terminologia in ITIL, 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 criteri ITIL 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

necessario definire la 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 nella sistema di gestione della 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 le 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: Cosa la finanziaria o affari ritorno, o quali sono i benefici richiesti dal cambiamento?
Rischi: Quello che fanno i rischi coinvolti nel processo decisionale, o non, 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 ilmodificare 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. Il autorit di cambiare la persona che approva il cambiamento! pu essere chiunque
tu voglia che sia.
Stabilire una politica per come si desidera autorizzare modifiche e decidere su una serie di autorit di
cambiamento. 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 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. A piano di back-out assicura che se si verifica
un errore mentre il cambiamento in corso di attuazione, il servizio pu essere ripristinato a uno stato
precedente, noto, stabile. A piano di bonifica 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.
5

Distribuzione di cambiamento che autorizza


Una volta il cambiamento stato costruito e testato (vedere la 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 coordinando il cambiamento compilazione e test che ho descritto in un
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 allora 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 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 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 2spiega 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 del libro di transizione del servizio ITIL si
riferiscegestione della configurazione. Gestione della configurazione diverso da asset management in
due modi:
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 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): Definizione di the ITIL 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 sua definizione di ITIL, questo 'un insieme di strumenti, dati e informazioni che viene
utilizzati per supportare la gestione di asset e configurazione del servizio'. Figura 7-1 fornisce 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 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 gli standard 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 esso costituisce la base 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.
Visualizzazione ingrandita

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

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
tutti i processi ITIL, allora perche ' SACM speciale? Poich la gestione e pianificazione fondamentale
per ottenere il disegno del CMS corretto, 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
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 mostrato Figura 7-2. Per ogni CI si registra un
insieme di attributi.

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

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 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
Il Verifica e audit attivit 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 Verifiche possono essere eseguite 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.
Definizione di ITIL 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 nell'ambiente live
utilizzando le procedure e metodi sviluppati da Gestione stampa e distribuzione.

10

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-3 Mostra una descrizione pittorica di questo.

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

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.

11

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 gli standard ITIL, ' 'l'attivit responsabile del movimento di nuovo o modificato
hardware, software, documentazione, processo e cos verso 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: Definizione di the ITIL 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 come il amministrazione di rapporto del cliente sistema (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.
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: Stati di definizione di ITIL 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, un graduale approccio quando il rilascio viene
distribuito ad aree diverse in momenti diversi, possibilmente 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: Spingere 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, tirare
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.

12

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. A politica un insieme di decisioni se
volete norme 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 Convenzioni di denominazione e numerazione per le versioni
o Prevede la frequenza di ogni tipo di rilascio
o 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 riguarda 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. A distribuzione pilota
l'installazione della versione a un numero rappresentativo e il tipo di target o utenti per dimostrare che
entrambi il rilascio 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 amministrative come l'acquisto di
licenze software e trasferimento di diritti di propriet intellettuale.

13

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.
Definizione di ITIL 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

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?

14

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).

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

15

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.
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.
Definizione di ITIL ' 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 '.

16

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

17