Page 1

Home - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

News ITIL, Italia Lunedi 7 Settmbre 2009 Utilizzo di best practices... Un nuovo post nel blog ITIL, Italia commenta i dati di utilizzo delle best practices ICT.

Mercoledi 12 Agosto 2009 COBIT 4.1 Un post nel blog ITIL, Italia descrive il framework COBIT 4.1 Mercoledi 11 Marzo 2009 Il Supplier Management in ITIL v3 Rese disponibili nel sito informazioni sul processo di Supplier Management in ITIL v3 .

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices¿ by itil-italia | 0 comments

COBIT 4.1

Domenica 08 Marzo 2009 L'esame ITIL V3 Manager Bridge Un interessante post nel blog ITIL, Italia descrive l'esame ITIL V3 Manager Bridge.

by itil-italia | 1 comments

Contenuti

by itil-italia | 0 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge

Il sito e' organizzato nelle seguenti parti: IT Infrastructure Library v3 (ITIL v3) Questa area del sito approfondisce il framework ITSM IT Infrastructure Library (ITIL) nella sua terza edultima versione. Il framework ITIL si evolve dal 1989, anno in cui le prime pubblicazioni furono rilasciate dal CCTA (Central Computer and Telecommunication Agency del governo inglese). Questo framework e' basato fondamentalmente sulle più recenti esperienze e best practices nel service management. IT Infrastructure Library v2 (ITIL v2) Questa area del sito approfondisce il framework ITSM IT Infrastructure Library (ITIL) nella sua seconda versione, versione tuttora in uso in molte organizzazioni. Questo framework e' basato fondamentalmente sulle best practices nel service management, non e' cioe' un modello teorico, ma una collezione di pratiche che hanno dato prova sul campo di essere "ben funzionanti". ISO/IEC 20000 Questa area del sito approfondisce lo standard ISO/IEC 20000, il cui scopo e' di "fornire un comune standard di riferimento per ogni impresa che offre servizi IT a clienti interni o esterni". Lo standard promuove l'utilizzo di un modello integrato a processi di gestione dei servizi IT PRINCE2 Questa area del sito approfondisce la metodologia PRINCE2 (PRojects IN Controlled Environments). Questa metodologia per il project management è basata su un approccio per processi. PRINCE2 permette un approccio scalabile in ragione dei requisiti richiesti, sia di complessità dei progetti sia di rischi relativi che di dimensioni. IT Service Management In questa area del sito si presentano i concetti dell'IT Service Management (ITSM) . L'ITSM e' una disciplina che si occupa della gestione di sistemi information technology (IT) su larga scala, filosoficamente concentrata sulla prospettiva del cliente e del contributo dell'IT al business. Control Objectives for Information and related Technology (COBIT) In questa area si presenta il framework Control Objectives for Information and related Technology (COBIT). Il COBIT e' un set (framework) di best practices per il management dell'IT creato dall'ISACA Information Systems Audit and Control Association ), e dall'ITGI (IT Governance Institute) nel 1992. E' stato successivamente aggiornato nel 1996, 1998, 2000 e Dicembre 2005 (COBIT 4.0).

http://www.itil-italia.com/[10/01/2011 11.30.09]

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


Home - ITIL, Italia

Microsoft Operations Framework (MOF) Qui si presenta l'ITSM secondo Microsoft. Il Microsoft Operations Framework (MOF) e’ una raccolta di best practice, principi e modelli studiata da Microsoft per gestire/supportare ambienti mission-critical al fine di raggiungere livelli adeguati di reliability, availability, supportability, e manageability per le soluzioni e i servizi basati sulla tecnologia Microsoft. Il MOF combina gli standard definiti da ITIL con guidelines spedifiche relative all’implementazione e alla gestione di sistemi basati su tecnologie Microsoft. Links Alcuni Link utili a risorse ITSM ed ITIL, sia in inglese che in italiano. Alcuni dei contenuti presenti in questo sito sono apparsi come post nell' IT Management Blog , ed utilizzati con il permesso dell'autore.

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/[10/01/2011 11.30.09]


ITIL v3 - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

ITIL, Italia Per navigare sugli argomenti relativi ad ITIL usate il navigator in basso. Per ritornare al navigator di ITIL da qualsiasi pagina di questa sezione, tornate alla voce ITIL v3 nel menu in alto nella pagina.

Indice di ITIL v3 Cos'e' il Framework ITIL? Storia di ITIL ITIL v3 Service Strategy Strategy Generation Service Portfolio Management Demand Management Financial Management ( vedi il processo equivalente in ITIL v2 ) Service Design Service Catalogue Management Service Level Management ( vedi il processo equivalente in ITIL v2 ) Capacity Management ( vedi il processo equivalente in ITIL v2 ) Availability Management ( vedi il processo equivalente in ITIL v2 ) IT Service Continuity Management ( vedi il processo equivalente in ITIL v2 ) Information Security Management Supplier Management Service Transition Transition Planning and Support Change Management ( vedi il processo equivalente in ITIL v2 ) Service Asset and Configuration Management ( vedi il processo equivalente in ITIL v2 ) Release and Deployment Management ( vedi il processo equivalente in ITIL v2 ) Service Validation and Testing Evaluation Knowledge Management Service Operation Processi Event Management Incident Management ( vedi il processo equivalente in ITIL v2 ) Request Fulfillment Problem Management ( vedi il processo equivalente in ITIL v2 ) Access Management Funzioni Service Desk ( vedi la funzione equivalente in ITIL v2 ) Technical Management IT Operations Management Applications Management Continual Service Improvement Certificazione Certificazione Foundations Level Certificazione Intermediate Level Certificazione Expert Level Certficazione Master Level Downloads Implementazione del Service Management Metriche ITSM Implementazione in piccole organizzazioni

http://www.itil-italia.com/itilv3.htm[10/01/2011 11.32.01]

Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices多 by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


ITIL v3 - ITIL, Italia Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilv3.htm[10/01/2011 11.32.01]


ITIL_Overview - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Cos'e' il framework ITIL v2 (IT Infrastructure Library versione 2)? Il framework ITIL (IT Infrastructure Library) si evolve dal 1989, anno in cui le prime pubblicazioni furono rilasciate dal CCTA (Central Computer and Telecommunication Agency del governo inglese). Questo framework e' basato fondamentalmente su best practices nel service management, non e' cioe' un modello teorico, ma una collezione di pratiche che hanno dato prova sul campo di essere funzionali ad una solida implementazione di IT Service Management di alto livello.

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

La versione di ITIL cui si fa riferimento in questo articolo è la versione 2 (ITIL v2). Secondo ITIL i tre obiettivi dell'IT Service Management (ITSM) sono i seguenti: allineare i servizi IT con i bisogni correnti e futuri del business e dei clienti migliorare la qualita' dei servizi IT erogati ridurre i costi fissi di erogazione dei servizi

Blog ITIL, Italia - post recenti Utilizzo di best practicesÂż by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

La filosofia ITIL adotta un approcio process-driven che si puo' utilizzare in organizzazioni sia grandi che piccole. L'IT service management e' scomposto in una serie di processi integrati e correlati tra loro. I processi di ITSM in ITIL sono divisi in due aree principali: Service Support Service Delivery Nell'area di Service Support vi sono i seguenti processi: Service Desk (in realta' e' una funzione e non un processo) Incident management Problem Management Configuration Management Change Management Release Management Nell'area di Service Delivery vi sono i seguenti processi: Service Level Management Financial Management for IT services Capacity Management IT Service Continuity Management Availability Management Il Service Support ed Il Service Delivery sono il cuore del Service Management e di ITIL, pero' esistono delle porzioni (in realta' sono libri) spesso considerate "minori", ma abbastanza importanti, elencate di seguito: La Prospettiva di Business (The Business Perspective), questa porzione e' orientata ai business managers per comprendere i fondamenti dell' IT necessari a supportare il business e le best practices di ITSM ICT Infrastructure Management , questa porzione copre tutti gli aspetti della gestione dell'infrastruttura IT, Gestione delle Applicazioni , questa porzione esamina le problematiche relative al ciclo di vita delle applicazioni, dai requirements al disposal. Security Management, questa porzione si focalizza sulla gestione della sicurezza integrata agli altri processi Implementazione del Service Management, questa porzione esamina le problematiche relative all a gestione dell'implementazione del Service Management e, naturalmente, offre delle best practices in merito. Il diagramma tipico che mostra l'interazione tra tutti i componenti di ITIL e' il seguente:

http://www.freewebs.com/itil-italia/itiloverview.htm[10/01/2011 11.32.14]

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


ITIL_Overview - ITIL, Italia

ITIL suggerisce sia implementato il proprio framework di service management (e che hanno valore anche oltre l'ITIL) secondo una successione ben definita di passi (process improvement model) che portano ad uno stato in cui il miglioramento del processo e' costruito all'interno del processo stesso. I passi sono: Definizione della Visione e degli obiettivi di business (chiedersi dove si vuole arrivare) Assesment della situazione corrente (chiedersi dove si e' adesso) Definizione del percorso di implementazione (chiedersi come arrivare fino alla realizzazione della visione e degli obiettivi di business) Definizione dei criteri di misura e di metriche (chiedersi come definire i punti di arrivo in termini quantitativi) Esistono in commercio tool di assessment e planning per l'implementazione di ITIL nella propria organizzazione (alcuni sono gratuiti --> ITIL Service Management Self Assessment ) .

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.freewebs.com/itil-italia/itiloverview.htm[10/01/2011 11.32.14]


ITIL_History - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

ITIL, Italia

Storia di ITIL... Il concetto di ITIL (ancora non si chiamava cosi') e' nato negli anni '80, quando il governo britannico ha ritenuto che la qualita' dei servizi IT non era sufficiente. Per ovviare al problema, la Central Computer and Telecommunications Agency (CCTA), adesso chiamata Office of Government Commerce (OGC), fu incaricata di occuparsi di sviluppare delle linee guida per un uso delle risorse IT efficiente e finanziariamente "responsabile". Quella che noi chiamiamo ITIL v1, non fu altro che la prima versione di queste "linee guida", che era stata intitolata "Government Information Technology Infrastructure Method" (GITM) e negli anni si è espansa fino a 31 volumi in un progetto inizialmente diretto da Peter Skinner e John Stewart presso il CCTA. NAturalmente, questa era abbastanza diversa dall'ITIL che conosciamo oggi, anche se concettualmente si avvicinava molto, e si concentrava sulle due aree di service support e service delivery, un po' come l'ITIL v2. Le pubblicazioni ITIL v1 furono reintitolate principalmente per desiderio di Roy Dibble del CCTA poiché queste dovevano essere delle linee guida e non un metodo formale ed anche per rispondere alla forte crescita di interesse ad di fuori della Pubblica Amministrazione Britannica. Molti dei principali concetti sulla gestione del servizio non erano stati creati all’interno del progetto originale del CCTA che sviluppava ITIL, infatti IBM rivendica che i suoi "Yellow Books" (A Management System for the Information Business)ne siano stati un precursore. Secondo IBM: "Nei primi anni ottanta, IBM aveva già documentato i concetti originali della gestione dei sistemi in una serie di quattro volumi chiamati A Management System for Information Systems. Questi largamente accettati “yellow books,” ... furono gli input principali al set originale di libri ITIL." . Altre pubblicazioni IBM e commenti degli stessi autori di ITIL hanno chiarito che i "yellow books" diedero un significativo contributo al Service Support di ITIL mentre il volume sul Service Delivery non ne era stato influenzato nella stessa misura. Durante gli anni '80 la diffusione di ITIL rimase un po' limitata alla Gran Bretagna ed agli addetti ai lavori, il boom inizio' a meta' degli anni '90, quando molte grandi aziende ne iniziarono l'adozione.

Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices¿ by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

ITIL v2 usci' nel 2001, e le parti di Service Delivery e Service Support furono riassunte in due (piu') concisi volumi. Microsoft nello stesso periodo rilascia MOF, che si basa su ITIL. Il primo giugno 2007, sei abbi dopo, l’OGC ha rilasciato un ampio aggiornamento di ITIL, noto come ITIL v3. La pubblicazione iniziale di ITIL v3 è composta da cinque testi principali denominati: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement consolidando così molte delle pratiche della versione v2 attraverso il ciclo di vita del servizio (service lifecycle).

© ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilhistory.htm[10/01/2011 11.32.39]

qualsiasi


ITIL_ServiceSupport - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

ITIL, Italia

ITIL Service Support La parte di Service Support di ITIL v2 si occupa della porzione della gestione giornaliera delle attivita' di IT Service Management. Mentre l'altra parte, Service Delivery , si occupa della pianificazione di lungo termine della fornitura di servizi IT e del miglioramento degli stessi. I processi inclusi nella parte Service Support sono i seguenti: Incident Management Problem Management Configuration Management Change Management Release Management

Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practicesÂż by itil-italia | 0 comments

COBIT 4.1

Vi e' anche inclusa una funzione chiave dell'IT nella parte Service Support: il Service Desk .

by itil-italia | 1 comments

Le interazioni tra le varie parti sono esemplificate nella figura in basso.

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilservicesupport.htm[10/01/2011 11.35.23]

qualsiasi


ITIL_IncidentManagement - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Incident Management Secondo quanto riportato nella documentazione ufficiale su ITIL v2 , l'obiettivo del processo di incident management e' di ripristinare le operazioni normali di servizio il piu' velocemente possibile con la minima interruzione di servizio al business, assicurando che i migliore livelli di servizio e disponibilita' siano mantenuti . Le seguenti definizioni sono usate nel processo di Incident Management: Un incidente e’ qualsiasi evento che non fa parte dell’operativita’ standard di un servizio e che causa, o puo’ causare, un’interruzione e una riduzione della qualita’ di tale servizio Un workaround e’ una correzione temporanea ad un incidente o una sequenza di azioni alternativa a quella che produce l’incidente, utilizzabile dall’utente. Le responsabilita' nel processo di incident management sono le seguenti: 1. 2. 3. 4. 5. 6.

La registrazione degli incidente La classificazione degli incidenti ed il supporto iniziale L'analisi e diagnosi dell'incidente La soluzione ed il ripristino La chiusura dell'incidente La "ownership" dell'incidente, il monitoraggio e le relative comunicazioni

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices¿ by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

I punti dall'1 al 5 sono sequenziali, mentre il punto 6 va svolto durante tutto il ciclo di vita dell'incidente.

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

Figura 1 - Input, attivita' ed output del processo di Incident Management Il ruolo chiave nell'incident management e' quello del Service Desk.Alcuni dei benefici dell'incident management sono i seguenti: Minore impatto degli incidenti sul business a cause di una piu' veloce risoluzione Identificazione proattiva di possibili miglioramenti all'infrastruttura

http://www.itil-italia.com/itilincidentmanagement.htm[10/01/2011 11.36.01]

qualsiasi


ITIL_IncidentManagement - ITIL, Italia Disponibilita' di informazione significativa per poter redigere e valutare i livelli di servizio Migliore utilizzazione dello staff Eliminazione di incidenti "persi" Aumento della customer satisfaction Meno interruzioni sul lavoro sia allo staff IT che agli utenti

Implementazione dell'Incident Management Se volessi implementare l'Incident Management nella mia organizzazione, cosa dovrei fare? Alcuni punti dal quale iniziare, senza pretesa di completezza, sono i seguenti: Assicurarsi della volonta' dell'organizzazione di farlo (cio' che gli anglosassoni chiamano "management commitment"). E se la volonta' non c'e', puo' essere utile vendere i vantaggi dell'incident management al management in modo da convincerli Implementare il Service Desk nella propria organizzazione Assicurarsi che ci siano risorse umane dedicate all'incident management. Eventualmente le risorse umane possono anche ruotare tra incident management ed altre attivita', tenendo pero' presente che gli skill potrebbero diluirsi eccedendo con la rotazione. Formare le risorse umane a comprendere il processo di incident management e le relazioni con altri processi ("process awareness") Mettere l'utente al centro del servizio. Questo e' un'atteggiamento mentale che deve essere comune a tutte le risorse umane impiegate nei processi di Incident management. Da non sottovalutare. Creare una knowledge base condivisa per la risoluzione degli incidenti. Per evitare che la knowledge base rimanga un corpo estraneo al processo e' necessario che 1. la consultazione della knowledge base faccia parte del processo (il tecnico dovrebbe consultarla come prima azione per vedere se incidenti simili sono gia' successi e come sono stati risolti) e che 2. la knowledge base venga aggiornata come risultato del processo (ogni volta che un incidente non capitato prima viene risolto, la soluzione andrebbe registrata sulla knowledge base) Avere un tool software di assegnamento/tracciamento degli incidenti che implementi il processo. Il tool deve essere parte della knowledge base (i tecnici devono avere accesso a tutti gli incidenti per poter vedere le soluzioni gia' implementate). Formalizzare le procedure di incident management e formare il personale su quelle procedure (ne parliamo piu' in basso). Tipici aspetti da formalizzare sono i seguenti: Definire i livelli di servizio da rispettare (andrebbero negoziati con gli utenti/clienti) per ogni tipo di incidente. Definire le priorita' degli incidenti in base a criteri obiettivi (matrice urgenza/impatto) Monitorare i livelli di servizio in maniera periodica (giornaliera o almeno settimanale) Formalizzare accordi con gruppi esterni qualora gli incidenti vadano scalati (OLA o Operating Level Agreement) Definire il ciclo di vita degli incidenti per evitare che vi siano "zone morte" in cui non si sa chi e' responsabile. I fattori critici di successo nell’implementazione dell’Incident Management includono i seguenti: Un CMDB aggiornato. Se il CMDB non è aggiornato la determinazione dell’impatto e dell’urgenza della soluzione diventa molto lenta e difficile. Strumenti software adeguati per la gestione degli incidenti. I processi manuali/cartacei sono ragionevoli solo per implementazioni molto ridotte, ed impossibili per implementazioni che includono più gruppi di lavoro. Una ‘knowledge base’, che comprenda al minimo: Il Known Error Database La lista dei problemi nell’infrastruttura Uno storico degli incidenti risolti nel passato Documentazione tecnica Una stretta connessione con il processo di Service Level Management per determinare le deadline per la risoluzione per ogni tipo di incidente. E' da tenere presente che il processo di incident management ha forti relazioni con altri processi (Problem Management e Configuration management tra gli altri).

Metriche Alcune metriche che possono essere utili per misurare le performance del processi di Incident Management sono le seguenti: % di incidenti risolti al primo livello di supporto (non sono stati scalate) al mese, per misurare la bontà

http://www.itil-italia.com/itilincidentmanagement.htm[10/01/2011 11.36.01]


ITIL_IncidentManagement - ITIL, Italia della knowledge base; % di incidenti risolti al momento del contatto, per misurare l’aderenza dell’incident management alla situazione ideale, cioè di poter risolvere tutte le chiamate “al volo”; % di incidenti assegnati in modo non corretto al mese, per misurare la bontà dei processi di assegnamento; % di incidenti risolti nei livelli di servizio stipulati (SLAs) al mese, per misurare la capacita’ di risolvere gli incidenti secondo i livelli di servizio stipulati; tempo medio di risoluzione degli incidenti al mese, per misurare la bontà e l’efficienza del processo di incident management in generale; % di incidenti con categorizzazione non corretta al mese, per misurare l’accuratezza e l’utilizzabilità dei dati prodotti dall’incident anagement. % di richieste di servizio rispetto agli incidenti al mese, per misurare la maturità del servizio. Col tempo, gli incidenti dovrebbero diminuire e le richieste di servizio aumentare. % di incidenti risolti correttamente al primo tentativo, al mese, per misurare l’efficienza del processo. Non tutte le metriche possono andare bene per tutti, naturalmente dobbiamo calarle nella nostra realta' e usare quelle che possono essere usate nel nostro contesto, oppure svilupparne di nuove che meglio si adattino alle specificita' del nostro processo.

© ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilincidentmanagement.htm[10/01/2011 11.36.01]


ITIL_ProblemManagement - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Problem Management L'obiettivo del Problem Management, come definito in ITIL v2 e' di minimizzare l'impatto sul business degli incidenti (vedi qui per la definizione) e dei problemi causati da errori nell'infrastruttura IT, e di prevenire la ricorrenza di tali incidenti. Per poter raggiungere questo obiettivo, il Problem Management cerca di determinare la "root cause" (causa ultima) degli incidenti, e focalizza la propria attenzione a migliorare o correggere queste situazioni. La differenza con l'incident management e' evidente. Mentre l'incident management e' focalizzato all'utente, qui e adesso, il problem management e' focalizzato all'infrastruttura nel lungo termine. Il problem management ha degli elementi di reattivita' ed altri di proattivita'. E' reattivo nel senso che i problemi possono rendersi evidenti dal moltiplicarsi degli incidenti. E' proattivo nel senso che e' possibile (consigliata) l'identificazione dei problemi prima che generino incidenti. Il processo di Problem Management ha bisogno di un processo di Incident Management ben implementato che fornisca gli input di cui ha bisogno (incidenti) in forma strutturata ed analizzabile. Le attivita' di Problem management includono: Controllo dei Problemi (problema e' la causa di uno o piu' incidenti) Control degli Errori (un problema diventa errore se la causa ultima e' nota o se esiste un workaround) Prevenzione dei Problemi (Problem Management proattivo) Creazione di Workarounds Le informazioni relative ai problemi ed errori (Known Error Database) vengono gestite dal processo di Problem Management. Queste informazioni sono utilissime al processo di Incident Management.

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices多 by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

I benefici del Problem management sono i seguenti: Miglioramento della qualita' del servizio IT Riduzione del volume degli incidenti Risoluzione permanente dei problemi Possibilita' di ottimizzare il processo di organizational learning

Implementazione del Problem Management Da dove partire per implementare il Problem Management? Innazitutto e' fondamentale che il processo di Incident Management sia implementato in quanto fornisce gli input al processo: Dettagli sugli incidenti occorsi, categorizzati opportunamente per poter essere analizzati Eventuali workarounds gia' identificati nella risoluzione degli incidenti (i workaround possono essere sviluppati dal problem management, ma spesso vengono anche sviluppati nell'incident management) Altri punti da tenere presente sono i seguenti: I tecnici addetti all'incident management devono avere accesso alla lista aggiornata dei Known Errors (Known Errors Database), che include anche i workaround, in modo da poter risolvere tutti gli incidenti correlati in modo rapido. In questo modo, l'implementazione del Problem Management aiuta ad ottimizzare il processo di Incident Management Le informazioni su ogni incidente vanno collegate al problema corrispondente. Questo aiuta a dare visibilita' dell'impatto di ogni problema (quanti incidenti sono generati dal singolo problema) e quindi a definirne la priorita' E' utile che questo meccanismo di prioritizzazione sia in qualche modo automatizzato, in modo che i problemi a piu' alta priorita' (che causano la maggior parte degli incidenti) siano affrontati prima. Idealmente le persone che si occupano dei problemi devono essere diverse da quelle che si occupano di incidenti, perche' diverso e' il target (utente finale vs. infrastruttura). La stessa persona puo' occuparsi di

http://www.itil-italia.com/itilproblemmanagement.htm[10/01/2011 11.36.37]

Newest Members

qualsiasi


ITIL_ProblemManagement - ITIL, Italia entrambi solo se ha molto chiara la differenza tra i due. Non sempre e' facile capire la "root cause" degli incidenti, spesso questa e' la fase piu' delicata del processo di Problem Management a monte della determinazione che il problem e' un Known Error. Questa parte si puo' dividere nelle seguenti fasi: Definizione del Problema. Gli incidenti, essendo visti dal punto di vista dell'utente possono avere una definizione completamente diversa dal problema. Per esempio, una connessione di rete configurata male potrebbe generare incidenti di tipo "errore nella stampa" se quella connessione serve un print server. In questo senso una corretta definizione puo' gia' essere fondamentale nel trovare la soluzione. Stabilirne le Cause. In questa parte possono essere utili delle metodologie formali per la "root cause analysis" quali quelle di Kepner and Tregoe oppure di Ishikawa (i famigerati diagramma a lisca di pesce). Un ultimo aspetto da tenere presente e' che per un processo di Problem Management efficiente e' necessario avere una fotografia dell'infrastruttura IT che si presti ad una analisi strutturata. Questa "fotografia" viene generata nel processo di Configuration Management.

Metriche Alcune metriche che possono essere utili per misurare le performance del processi di Problem Management sono le seguenti: Numero di problemi chiusi al mese, per misurare il volume e l’efficienza del lavoro Numero di incidenti risolti con l’uso del Known Error Database al mese, per misurare l’utilità del processo % di incidenti causati da problemi al mese, per misurare il potenziale beneficio del processo di problem management Numero di RFC create per risolvere errori al mese, per misurare il numero di soluzioni proposte Tempo medio dalla creazione alla chiusura di un problema (per problemi chiusi in un determinato periodo), per misurare il throughput Le 5 tipologie di incidenti con maggiore numero di istanze, al mese, per identificare aree di miglioramento nell’infrastruttura (non un KPI, ma un dato operativo) Non tutte le metriche di Problem Management proposte possono andare bene per tutte le organizzazione, naturalmente dobbiamo calarle nella nostra realta' e usare quelle che possono essere usate nel nostro contesto, oppure svilupparne di nuove che meglio si adattino alle specificita' del nostro processo.

© ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilproblemmanagement.htm[10/01/2011 11.36.37]


ITIL_ConfigManagement - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Configuration Management Il processo di configuration management, come definito in ITIL v2 , e' forse il meno immediato da comprendere, ma senz'altro uno dei piu' importanti, in quanto fornisce la base a tutti gli altri processi. L'obiettivo del Configuration Management e' di fornire un modello logico dell'infrastruttura attraverso l'identificazione, il controllo, la gestione e la verifica di tutte le versioni di "Configuration Items" esistenti.A questo punto, e' opportuno definire i Configuration Item (per maggiori dettagli andate su wikipedia: http://en.wikipedia.org/wiki/Configuration_item ).

Il configuration item, o CI, e' un unita' di configurazione (elemento dell'insfrastuttura IT) che puo' essere gestita individualmente (tipo: computer, routers, servers, software, etc...).

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices多

Un elemento chiave del processo e' il Configuration Management Database (CMDB), che viene utilizzato per tracciare tutte le CI e le relazioni tra di loro (tipo: il server A ospita il Servizio B, etc...).

by itil-italia | 0 comments

Alcuni benefici dell'implementare il processo di configuration management sono i seguenti:

by itil-italia | 1 comments

Disponibilita' di informazioni accurate sull'infrastruttura IT Maggiore controllo sulle CI (potenzialmente costose) Maggiore aderenza alle leggi (es. numero licenze software) Miglior supporto al processo di Incident Management, soprattutto nella valutazione dell'impatto degli incidenti. Miglior supporto al processo di Problem Management, in particolare nell'ausilio fornito nell'analisi della "root cause". Le attivita' relative al processo Configuration Management sono le seguenti: Pianificazione, include le strategie, policy, obiettivi, ruoli e responsabilita' nel processo di Configuration Management. Altro elemento da tenere presente nella pianficazione e' la struttura del CMDB. Identificazione, include la selezione, identificazione e "labeling" delle CI. Controllo, include il processo di assicurare che solo le CI autorizzate siano presenti nel CMDB. Tutto le CI possono essere modificate solo attraverso il processo di Change Management (di cui diremo in seguito). Status Accounting, la gestione del ciclo di vita delle CI (da quando sono in test a quando sono rilasciate e poi "disposed") Verifica, include gli audit effettuati con lo scopo di verificare l'accuratezza del CMDB. Una delle poche raccomandazioni di ITIL in termini di priorita' di implementazione dei processi e' quello di implementare i processi di configuration, change e release management insieme, e possibilimente di avere una funzione centralizzata per gestirli.

Implementazione del Configuration Management Riportiamo di seguito alcuni suggerimenti su come approcciare alcuni problemi comuni nell'implementare il processo di Configuration Management. Uno dei problemi principali e' il cercare di implementare il processo senza implementare altri processi che sono funzionali ad esso. Come detto sopra: una delle poche raccomandazioni di ITIL in termini di priorita' di implementazione dei processi e' quello di implementare i processi di configuration, change e release management insieme, e possibilimente di avere una funzione centralizzata per gestirli. In particolare, il processo di change management assicura che tutti i cambiamenti avvengano secondo un workflow prestabilito ed agisce da gatekeeper per il CMDB. Un altro problema e' la confusione tra il processo di configuration management ed il CMDB. Non basta implementare il CMDB per avere il processo in piedi. Bisogna prima avere tutte le procedure (Pianificazione, Identificazione, Controllo, Status Accounting e Verifica) per la gestione ed il mantenimento del CMDB e poi si puo' popolare il CMDB, senno' si rischia che esso risulti obsoleto prima di essere disponibile.

http://www.itil-italia.com/itilconfigmanagement.htm[10/01/2011 11.37.05]

COBIT 4.1 Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


ITIL_ConfigManagement - ITIL, Italia Un altro problema comune e' quello di non avere un adeguato livello di dettaglio delle CI nel CMDB. Se' e' eccessivo (troppo dettaglio) si rischia di dover tracciare tutto (quante tastiere e mouse ci sono) con un dispendio eccessivo di risorse. Se e' troppo alto si rischia di non avere informazioni significative dal CMDB. Come in tutte le cose, il CMDB va' analizzato e pianificato in modo che sia uno strumento che sia di aiuto e non un peso. Un problema comune e' lo scarso interesse del management (nessuno e' interessato ad implementarlo). Questo purtroppo e' conseguenza del fatto che i benefici sono in la' nel tempo e non immediatamente tangibili. E' fondamentale che i manager vengano informati dei benefici nell'implementare il Configuration Management. Alzi la mano chi non ne ha avuto esperienza: il processo viene percepito come troppo burocratico e viene regolarmente bypassato. A questo scopo e' fondamentale che tutti capiscono l'importanza ed i benefici del Configuration Management. Il tool che implementa il CMDB e' inadeguato. Personalmente, i pochi tool che ho visto (Siebel, HP OpenView Service Desk) non sono certo il massimo, ma il loro punto di forza e' l'intergrazione con gli altri processi ITIL.

Metriche Nel Processo di Configuration Management esistono dei Fattori Critici di Successo che e' utile elencare, e da cui ricaveremo le metriche relative: Identificare e gestire le informazioni relative all'infrastruttura IT; Fornire informazioni utili ai processi di Incident Management, Problem Management, Change Management e Release Management; Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Configuration Management sono le seguenti (organizzate per il Fattore Critico di Successo di cui offrono una misura): Identificare e gestire le informazioni relative all'infrastruttura IT; Numero di licenze non in uso, questa metrica si traduce in un beneficio immediato al byusiness nella possibilita' di risparimare soldi o utilizzare piu' efficientemente le risorse Numero di configurazioni non autorizzate, misura della bonta' del processo di mantenimento del CMDB, normalmente questi dati possono essere trovati durante gli audit previsti Fornire informazioni utili ai processi di Incident Management, Problem Management, Change Management e Release Management; Numero di incidenti derivati da CI mal documentate, misura dei mancati benefici agli altri processi. Questa metriche identifica il costo vivo in termini di tempo perso dagli utenti (e dai tecnici) nel risolvere incidenti che potevano essere prevenuti da una migliore processo di Configuration Management % di CI inaccurate, anche questa misura della bonta' del processo di mantenimento del CMDB, normalmente questi dati possono essere trovati durante gli audit previsti Miglioramento dei risultati misurati in Customer Surveys annuali, misura della migliorata percezione del processo

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilconfigmanagement.htm[10/01/2011 11.37.05]


ITIL_ChangeManagement - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Change Management Obiettivo del processo di Change Management, come definito in ITIL v2 , e': l'utilizzo di metodi e procedure standardizzate per una efficiente e rapida gestione di tutti i cambiamenti all'infrastruttura, con lo scopo di minimizzare l'impatto di possibili incidenti correlati sui servizi IT . Tipicamente, le attivita' nel Change Management includono le seguenti: Iniziare il processo di registrazione dei cambiamenti (o Request for Change, RFC) Valutare l'impatto, costi, benefici e rischi dei cambiamenti proposti Sviluppare giustificazioni (dal punto di vista del business) dei cambiamenti proposti ed ottenerne l'approvazione Gestire e coordinare l'implementazione delle RFC Monitorare e fornire report sulle RFC Fare la review e chiudere le RFC I cambiamenti vanno autorizzati prima che inizi qualsiasi lavoro su di esse (e dopo che se ne e' fatta una valutazione di impatto, costi, benefici, etc...). Il processo di autorizzazione deve essere effettuato da un comitato che abbia il giusto livello di autorita', secondo il cambiamento previsto. Normalmente si stabiliscono del Change Advisory Boards (CAB) che possono includere: Change Manager (l'owner del processo di change management) IT staff dell'area relativa Utenti o Clienti Esperti/Tecnici Naturalmente non tutti i cambiamenti devono passare da un workflow complesso. Normalmente si distinguono degli standard changes, che prevedono un approvazione automatica che si adattano e cambiamenti molto comuni e ripetitivi (tipo creazione di account, etc...) e model changes che prevedono dei workflow specifici e/o semplificati che meglio si adattano al tipo di cambiamento (per esempio bug fixing, etc..). Il change management dovrebbe occuparsi solo dei servizi IT in produzione. I singoli progetti dovrebbero avere un loro change management interno (ad esempio, nel PMBOK ), esiste un processo di Project Scope control, nella knowledge area di Scope Management). Il change management deve essere fortemente integrato con il project management perche' i cambiamenti (almento quelli piu' significativi) normalmente sono output di progetto.

Implementazione del Change Management Un aspetto importante da valutare nel pianificare l'implementazione del Change Management e' la dimensione dell'organizzazione su cui va implementato. Il processo specifico va disegnato sulle necessita' dell'azienda, un processo eccessivamente lungo potrebbe essere giusto per grandi organizzazioni, dove piu' entita' hanno necessita' di avere voce in capitolo, ma non potrebbe essere adatto a piccole organizzazioni, ove la complessita' non giustifica il beneficio. Un altro elemento da tenere presente e' il tool che si usa per implementare il processo. Sistemi cartacei possono funzionare solo in piccolissime organizzazioni. Per organizzazioni anche di minima complessita' e' utile (fondamentale) considerare sistemi software di change management. E' utile che il tool si integri da un lato con il CMDB e dall'altro con i tool di incident e problem management. Naturalmente all'inizio il processo di Change Management verra' percepito come troppo burocratico e si cerchera' di bypassarlo (si citera' per giustificare l'urgenza, il "non lo sapevo" etc...). E' fondamentale che sia il management, sia tutto lo staff IT comprenda a fondo la necessita' ed i benefici del processo di Change Management e che lo utilizzi attivamente. Naturalmente, se non esiste il Change Management anche il Configuration Management ne soffre (piu' che

http://www.itil-italia.com/itilchangemanagement.htm[10/01/2011 11.37.33]

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices多 by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


ITIL_ChangeManagement - ITIL, Italia altro e' inutile fare Configuration Management se non vi e' il Change Management ad agire da getekeeper verso il CMDB). D'altra parte se non esiste un CMDB accurato (e quindi un processo di Configuration Management) anche il change management e' difficile se non impossibile. Tra i benefici maggiori del Change Management vi sono i seguenti: Maggiore allineamento tra l'IT ed il business. Vi ricordate? questo e' uno degli scopi principali di ITIL. Ogni nuovo cambiamento (quindi anche ogni nuovo servizio) deve passare un'approvazione di un CAB che includa anche la componente business (ove appropriato). Questo assicura che i maghi di IT non implementino servizi solo per provare l'ultima fantastica tecnologia. Migliore comunicazione. Nel processo di Change Management ci sono dei servizi gratuiti di (i partecipanti al CAB sanno dei cambiamenti, il tool di Change Management permette a tutti di vedere cosa bolle in pentola, etc...) che migliorano la comunicazione dei cambiamenti. Minore impatto dei cambiamenti. Quante volte avete scoperto il lunedi' mattina che non funziona nulla e non avete idea da dove iniziare per sistemare? Le attivita' di Change Management permettono una visibilita' di tutti i cambiamenti effettuati nell'infrastruttura ed aiutano nel processo di risoluzione degli incidenti/problemi Maggiore capacita' di implementare i cambiamenti. Standardizzando il processo non c'e' bisogno di reinventare l'acqua calda ogni volta che si deve implementare il cambiamento permettendo una maggiore efficienza nel processare i cambiamenti (bisogna pero' tenere presente che questo si ottiene dopo un certo periodo che si utilizza il processo).

Metriche Nel Processo di Change Management esistono dei Fattori Critici di Successo che e' utile elencare, e da cui ricaveremo le metriche relative: Accuratezza e rapidita' nell'implementazione dei cambiamenti; Protezione dei servizi IT in produzione durante l'implementazione dei cambiamenti; Aumento dell'efficienza del processo di change management; Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Incident Management sono le seguenti (organizzate per il Fattore Critico di Successo di cui offrono una misura): Accuratezza e rapidita' nell'implementazione dei cambiamenti; % di riduzione dell'utilizzo di procedure "urgenti" nell'implementare i cambiamenti (trimestrale o annuale), misura del fatto che ci si rende conto che il processo e' sufficientemente rapido % riduzione dei cambiamenti "backed out" (trimestrale), misura dell'accuratezza dell'implementazione Protezione dei servizi IT in produzione durante l'implementazione dei cambiamenti % riduzione degli eventi di indisponibilita' di servizi IT in seguito a cambiamenti (trimestrale o annuale), misura della bonta' della pianificazione e del testing % riduzione degli eventi di di incidenti generati in seguito a cambiamenti (trimestrale o annuale), misura della bonta' del testing Miglioramento dei risultati misurati in Customer Surveys annuali, misura della migliorata percesione del processo Aumento dell'efficienza del processo di change management % di aumento di RFC processate (mensile) misura del throughput del processo % di RFC implementate nei tempi previsti (trimestrale), misura della bonta' della pianificazione % di RFC implementate nei costi previsti (trimestrale), misura della bonta' della pianificazione

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilchangemanagement.htm[10/01/2011 11.37.33]


ITIL_ReleaseManagement - ITIL, Italia

ITIL, Italia

Home

ITIL v3

ITIL v2

ISO 20000

PRINCE2

ITSM

COBIT

MOF

Links

Blog

Release Management La definizione "ufficiale" di Release Management in ITIL v2 e' la seguente:

considerare in modo 'olistico' i cambiamenti ai servizi IT (to take an holistic view of a change to an IT service) ed assicurarsi che tutti gli aspetti di una release, tecnici e non, vengano considerati Il release Management andrebbe utilizzato per: Implementazioni hardware massiccie o critiche Implementazioni software significative Implementazione contestuale di set di cambiamenti correlati Le responsabilita' del processo di Release Management includono le seguenti: Pianificazione e coordinamento delle implementazioni di software nuovi (o di upgrade) con hardware e documentazione associati Coordinamento con il Change Management per validare l'esatto contenuto della release Assicurarsi che tutti gli item oggetto (o target) di implementazione siano tracciabili via CMDB Gestione delle aspettative dei clienti ed utenti nelle implementazioni I seguenti concetti canno considerati con il Release Management: La Definitive Software Library (DSL), che contiene tutti le copie master di tutti i software in produzione, utilizzata e/o aggiornata con ogni release. Il Definitive Hardware Store (DHS), e' un area dove vengono mantenute i ricambi per l'hardware. Le parti nel DHS devono essere tracciate nel CMDB e mantenute allo stesso livello dell hardware in produzione Build Management, Il software e/o hardware che fa parte della release deve essere assemblato in modo controllato in modo che sia ripetibile e documentato Testing e Back-out, un piano di testing ed un piano di back-out (anch'esso va testato) fanno parte del corredo necessario ad ogni release prima che venga autorizzata I benefici dell'implementare il Release Management includono i seguenti: Migliore qualita' dei servizi rilasciati come risultato di un maggiore percentuale di release finalizzate con successo Migliore utilizzazione delle risorse Certezza che l'hardware ed il software rilasciato in produzione siu di qualita' nota, riducendo in tal modo le possibilita' che software illegale, errato o non autorizzato sia in uso. Una delle poche raccomandazioni di ITIL in termini di priorita' di implementazione dei processi e' quello di implementare i processi di configuration, change e release management insieme, e possibilimente di avere una funzione centralizzata per gestirli.

Implementazione del Release Management Uno degli aspetti da documentare all'inizio dell'implementazione del processo e' la divisione dei compiti tra lo staff di sviluppo e quello di supporto alle operazioni (operations). Il Release management coinvolge entrambe le parti: Lo staff di sviluppo e' normalmente responsabile per il design, sviluppo e costruzione (build) della soluzione, nonche' del testing. Il gruppo di sviluppo dovrebbe anche collaborare durante la messa in opera. Lo staff di operations e' normalmente responsabile per il processo, per la messa in opera e per il supporto. Naturalmente le responsabilita' possono variare in base a necessita' specifiche, ma e' necessario che siano note e documentate.

http://www.itil-italia.com/itilreleasemanagement.htm[10/01/2011 11.38.17]

ITIL, Italia Il sito ITIL, Italia nasce dalla consapevolezza della mancanza di risorse ITIL in italiano. In questo sito ci si occupa di IT Service Management in generale, e si approfondisce il framework ITIL in particolare, pur citando anche altri framework quali COBIT e MOF .

Blog ITIL, Italia - post recenti Utilizzo di best practices多 by itil-italia | 0 comments

COBIT 4.1 by itil-italia | 1 comments

Tool conformi ad ITIL? by itil-italia | 10 comments

L'esame ITIL v3 Manager's bridge by itil-italia | 0 comments

Commenti Visitate l'area commenti per feedback vogliate dare sul sito.

Newest Members

qualsiasi


ITIL_ReleaseManagement - ITIL, Italia Per poter implementare un processo di Release Management valido e' necessario avere la possibilita' di disporre di piu' ambienti (normalmente sviluppo, test e pre-produzione) in modo da poter fare il build e testing della soluzione in modo consistente a come verra' fatto in produzione. Non sempre questi ambienti sono disponibile, e questo puo' vanificare alcuni dei benefici del Release Management. Un altro problema comune e' la manacanza di comprensione della Release. Quante volte vi e' capitato che il gruppo di sviluppo vi abbia dato il sistema, i sistemisti vi abbiano dato l'hardware: arrivederci e grazie. E adesso? Normalmente i vari gruppi dovrebbero essere tenuti sia a documentare tutta la release sia a fornire supporto durante la messa in opera. Se ricordate la definizione di Release Management c'era la parolina "holistic", che vuol dire che la release va vista nell'insieme e non solo nelle parti. Un ulteriore comune ostacolo e' il seguente: il processo viene percepito come troppo burocratico e viene regolarmente bypassato. Com'era bello quando chiunque con una brillante idea era in grado di metterla in produzione senza fastidi (e la documentazione? e il supporto? e il testing ? sciocchezze, banalita' burocratiche...). A questo scopo e' fondamentale che tutti capiscono l'importanza ed i benefici del Release Management. Un altro problema comune potrebbe essere lo scarso interesse del management all'implementazione del processo. Questo puo' essere risolto facendo in modo che i manager vengano informati dei benefici nell'implementare il Release Management con "awareness campaigns" ed iniziative simili.

Metriche Nel ricavare le metriche e' sempre opportuno chiarire gli obiettivi (Fattori critici di successo) della misura. Per il processo in oggetto si possono considerare i seguenti: Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL) Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati Ottimizzare la gestione del processo di release Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Release Management sono le seguenti (organizzate per Fattore Critico di Successo di cui offrono una misura): Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati Numero di incidenti generati dalla release, queste metrica misura direttamente i "danni collaterali" generati da una release. Questi dati possono essere calcolati a partire dalla lista degli incidenti. % di Release urgenti, questa metrica permette di misurare la percentuale di release urgenti (potenzialmente pericolose) rispetto alle altre. Se queste risultano eccessive vuol dire che il processo e' bypassato con la scusa dell'urgenza. Questi dati sono norlmalmente disponibili nei log delle release. Numero (oppure %) di release non testate, normalmente a causa di urgenze, misura molto simile a quella precedente, che si puo' usare qualora i dati fossero disponibili in alternativa a quelli necessari per la metrica precedente. Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL) Numero pacchetti Software installati in produzione e non presenti nella DSL, misura della bonta' del processo di release in generale e della DSL in particolare. I dati sono normalmente disponibili a seguito di audit sui software installati in produzione. Numero di licenze non in uso, misura della bonta' del processo di gestione della DSL. Questa metrica si puo' tradurre in un beneficio immediato al byusiness nella possibilita' di risparimare soldi o utilizzare piu' efficientemente le risorse. Ottimizzare la gestione del processo di release % di accuratezza delle stime dei tempi (e/o costi) di release, misura della bonta' della pianificazione e dell'efficienza del processo di release. Semplice da calcolare se si ha l'abitudine di effettuare (e tracciare i relativi dati) un minimo di pianificazione della release. % di Release effettuate nei tempi previsti, fornisce informazioni sostanzialmente simile a quelle della metrica preecedente. Nel processo di Release applicativo esistono due prospettive opposte che e' opportuno valutare e misurare con metriche (alcuni esempi sono elencati di seguito) che sono leggermente diverse a secondo del punto di vista: la prospettiva del gruppo di operations (Application Support) con le metriche relativa: Numero di difetti identificati Numero di fix rimandati indietro a sviluppo la prospettiva del gruppo di sviluppo Numero di difetti riscontrati durante lo sviluppo

http://www.itil-italia.com/itilreleasemanagement.htm[10/01/2011 11.38.17]


ITIL_ReleaseManagement - ITIL, Italia Numero di difetti risolti Numero di fix rifiutati da Application Support

Š ITIL, Italia - 2006, tutti i diritti riservati Webdesign, sviluppo e CMS by Web.Communications

http://www.itil-italia.com/itilreleasemanagement.htm[10/01/2011 11.38.17]

Corso ITIL  
Corso ITIL  

Corso ITIL

Advertisement