INDICE PAG. 7 - SERVICE ASSET & CONFIGURATION MANAGEMENT CHAPTER 1 PAG. 1 - IMPLEMENTARE ITIL UTILIZZANDO OTRS

Transcript

1

2 INDICE CHAPTER 1 PAG. 1 - IMPLEMENTARE ITIL UTILIZZANDO OTRS CHAPTER 2 PAG. 3 - INCIDENT MANAGEMENT CHAPTER 3 PAG. 5 - PROBLEM MANAGEMENT PAG. 6 - REQUEST FULFILMENT CHAPTER 4 PAG. 7 - SERVICE ASSET & CONFIGURATION MANAGEMENT CHAPTER 5 PAG. 9 - CHANGE MANAGEMENT CHAPTER 6 PAG KNOWLEDGE MANAGEMENT CHAPTER 7 PAG SERVICE CATALOGUE MANAGEMENT PAG SERVICE LEVEL MANAGEMENT

3 CHAPTER 1 Implementare ITIL utilizzando OTRS Otrs non è solo un sistema di ticketing ma è una soluzione di IT Service Management strutturata su processi ITIL standardizzati, ITIL v3 compliant. L IT è ormai il dipartimento chiave di ogni azienda che va presidiato e regolato per arrivare alla creazione di processi automatizzati in grado di migliorare i tempi di risposta. Ed è proprio su l automatizzazione e la qualità dei processi che si gioca la partita. Non è un caso infatti che l ITIL, sia una disciplina incentrata sulla qualità del servizio percepita dai clienti, e OTRS ne supporta l intera infrastruttura, dai requisiti alle best practice. I core books di ITIL v3, rilasciati il 30 Maggio 2007, sono i seguenti: SERVICE STRATEGY comprende gli obiettivi organizzativi e le esigenze dei clienti e descrive i seguenti processi: Strategy Generation, Service Portfolio Management, Demand Management, Financial Management SERVICE DESIGN trasforma la strategia di un servizio in un piano per la realizzazione degli obiettivi aziendali e descrive i seguenti processi: Service Catalogue Management, Service Level Management, Capacity Management, Availability Management, IT Service Continuity Management, Information Security Management, Supplier Management SERVICE TRANSITION sviluppa e migliora le funzionalità per l introduzione di nuovi servizi negli ambienti supportati e descrive i seguenti processi: Transition Planning and Support, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation, Knowledge Management SERVICE OPERATION gestisce i servizi negli ambienti supportati e descrive i seguenti processi: Event Management, Incident Management, Request Fulfillment, Problem Management, Access Management. In questo libro vengono definite anche le seguenti funzioni: Service Desk, Technical Management, IT Operations Management, Applications Management CONTINUAL SERVICE IMPROVEMENT realizza servizi incrementali e miglioramenti su larga scala. Il processo di miglioramento descritto è unico e organizzato in sette passi. Copyright E-time Srl 1

4 In questo documento ci siamo concentrati solo sulla descrizione di alcuni processi, vedendo nel concreto come OTRS ne supporta l applicazione in base al framework ITIL. Innanzitutto OTRS è un sistema di Service Desk e quindi per definizione agisce come punto di contatto tra gli utenti e l I- TSM e gestisce incidenti e problemi degli utenti e fornisce un interfaccia per gli altri processi quali: Incident Management Problem management Request Fulfilment Service Asset e Configuration Management Change management Knowledge Management Service Catalogue e Service Level Management Copyright E-time Srl 2

5 CHAPTER 2 Incident management DI COSA PARLIAMO Incident: viene definito incidente qualsiasi evento che non rientra nell operatività ordinaria di un servizio e che causa o potrebbe causarne una riduzione. Workaround: correzione temporanea ad un incidente o una sequenza di azioni alternativa a quella che produce l incidente, utilizzabile dall utente. OBIETTIVO Ripristinare le operazioni normali di servizio il più velocemente possibile con la minima interruzione di servizio al business, assicurando che i migliori livelli di servizio e disponibilità siano mantenuti. ESEMPIO DELLA GESTIONE DI UN INCIDENT CON OTRS Ricostruiamo le fasi. 1. L utente attraverso una telefonata procede con una richiesta di assistenza 2. Service desk: apertura da parte dell operatore del ticket relativo alla richiesta con assegnazione alla relativa coda di riferimento. Nel frattempo l incident viene analizzato e si ricerca la soluzione. 3. Riattivazione del monitor e chiusura dell incident con successo. Copyright E-time Srl 3

6 COME DEFINIRE LE PRIORITÀ CON OTRS La priorità di un incidente deve essere determinata in un modo il più obiettivo possibile. Ad esempio possono essere presi in considerazione due parametri come urgenza (entro quando va risolto; può essere stabilita anche dall utente che ha aperto l incident) e impatto (gli effetti dell incident sul business). Per la definizione della priorità di una richiesta di intervento, ci sono diverse vie: delegare all utente che apre il ticket l indicazione della priorità; definire la priorità dell intervento già come attributo dei servizi censiti in catalogo. Naturalmente questa opzione ha tanto più valore quanto più è dettagliato il catalogo servizi; stabilire un identificazione automatica della priorità della richiesta in base a parametri conosciuti, quali ad esempio: - lo stato dell asset coinvolto (attivo/disattivo; quanti servizi sono vincolati all asset e quale livello di importanza ricoprono per il business aziendale) - il ruolo aziendale dell Utente che ha aperto l incident - ogni altro dato disponibile a sistema In alternativa un altra via potrebbe essere quella di definire uno step nel processo di gestione dell incident, che richiede all operatore di analizzare la situazione ed indicare di sua iniziativa il livello di priorità. Per completezza riportiamo una semplice tabella che ben schematizza il rapporto tra impatto e urgenza per la definizione della priorità. Infine va precisato che per una valutazione completa dell impatto, è buona prassi dotarsi di un CMDB (Configuration Management DataBase) che raccoglie le informazioni relative ai CI (Configuration items) e le loro relazioni. Copyright E-time Srl 4

7 CHAPTER 3 Problem management DI COSA PARLIAMO il Problem management è strettamente correlato con l Incident management, anzi si può dire che la sua efficienza dipenda soprattutto da come viene gestito quest ultimo. Attraverso il problem management infatti si vanno ad identificare le best practice e le azioni correttive da applicare all infrastruttura aziendale in un ottica di lungo termine, un processo volto a prevenire il verificarsi di incidenti. Se anche l Incident management è gestito in modo accurato saranno subito evidenti: i dettagli sugli incidenti avvenuti i workaround identificati OBIETTIVO minimizzare l impatto sul business degli incidenti e dei problemi causati da errori nell infrastruttura IT, e prevenire la ricorrenza di tali incidenti, determinandone la root cause (causa ultima) degli incidenti. ESEMPIO DELLA GESTIONE DI UN PROBLEM CON OTRS Come detto sopra, Problem e Incident management sono strettamente correlati, va da se che anche la gestione con OTRS sia molto simile. L Incident è relativo ad un problema che ha un impatto diretto sull utente, mentre Problem è un azione sulla parte infrastrutturale che non parte da un problema utente, ma dall analisi degli incident. In questo caso in OTRS verrà aperto un ticket di tipo Problem. Copyright E-time Srl 5

8 Request fulfilment DI COSA PARLIAMO Come suggerisce la parola Request, questo processo definisce la gestione della Service Request ovvero la richiesta posta da un utente per ricevere un informazione, inserire un cambiamento o per ottenere l accesso ad un servizio IT. OBIETTIVO fornire agli utenti un canale per richiedere (e ricevere) servizi standard per i quali esiste uno schema predefinito di approvazione (es. richiesta di un computer); fornire agli utenti informazioni sui servizi disponibili e sulle procedure per ottenerli; fornire i servizi standard di cui sopra agli utenti finali; assistere gli utenti su richieste generiche, consigli e lamentele. LA GESTIONE DI UNA REQUEST CON OTRS OTRS da la possibilità di creare più code alle quali verranno assegnati i ticket in entrata e in uscita in base alla pertinenza (es. coda sales, supporto, ecc ). Con l assegnazione del ticket alla coda di riferimento si ha la certezza di indirizzare la domanda al dipartimento responsabile, riducendo notevolmente i tempi di risposta ed evitando inutili rimbalzi di responsabilità tra un dipartimento e l altro. Copyright E-time Srl 6

9 CHAPTER 4 Service Asset & Configuration management DI COSA PARLIAMO Il Service Asset & configuration management è funzionale ad una serie di altri processi come Incident Management, Problem Management, Change e Release management e proprio per questo riveste un ruolo cruciale nell organizzazione dell intera infrastruttura IT. L identificazione e la gestione delle informazioni relative all infrastruttura IT passa da questo processo. Informazioni relative a: numero di licenze non utilizzate o configurazioni non autorizzate numero di incidenti causati da Configuration Item non documentate adeguatamente % di Configuration Items inaccurate sono misurabili attraverso il Service Asset & Configuration management OBIETTIVO fornire un modello logico dell infrastruttura attraverso l identificazione, il controllo, la gestione e la verifica di tutte le versioni di Configuration Items esistenti. Un configuration item (CI) è un unità di configurazione (elemento dell infrastruttura IT) che può essere gestita individualmente (es: computer, routers, servers, software, etc...). Ciascun Configuration item viene gestito attraverso un CMDB (Configuration Management Database) che tiene traccia di tutte le CI dell organizzazione e delle loro relazioni. LA GESTIONE DEL SERVICE ASSET E CONFIGURATION MANAGEMENT CON OTRS E GCMDB La visualizzazione di default del CMDB su OTRS è un elenco, come riportato nell immagine qui sotto: Come si può vedere dall immagine è subito visibile se ci sono configuration item in stato incident, indicati con il rettangolo rosso sulla prima colonna. Possiamo inoltre avere evidenza, tramite il rettangolo arancio sulla prima colonna, dei configuration item collegati a quello in stato incident. Questa visualizzazione ci permette di comprendere a colpo d occhio lo stato dei CI all interno del nostro CMDB. Copyright E-time Srl 7

10 E-time ha sviluppato un plugin per fornire un ulteriore visualizzazione grafica del CMDB chiamato GCMDB, che consente di accedere rapidamente alle informazioni in esso contenute. Attraverso GCMDB appare subito chiara la collocazione dei vari Configuration Items e le relazioni che intercorrono tra essi, una visione d insieme del CMDB. Vengono quindi indicati all interno dei cerchi i vari CI e le frecce indicano i collegamenti che ci sono tra essi. Cliccando su CI si apre la finestra relativa alla sua descrizione. Copyright E-time Srl 8

11 CHAPTER 5 Change management Copyright E-time Srl 9

12 CHAPTER 5 Change management DI COSA PARLIAMO Ribadiamolo ancora una volta: la standardizzazione dei processi e il tempo di risposta dell infrastruttura IT ai cambiamenti, sono il terreno su cui si gioca la partita ed è per questo che parliamo di Change management. Seguendo le best practices ITIL questo processo dovrebbe essere implementato contestualmente al processo di Configuration Management per arrivare ad una visione di insieme completa. Attuare un processo di Change management significa dare il via alla registrazione dei cambiamenti che avvengono (Request for Change, RFC), valutarne l impatto e fornire dei report periodici. Solitamente è buona prassi identificare un Change Advisory Boards (CAB) con compiti di analisi e rilascio di autorizzazioni sulle RFC proposte. Tra i membri del CAB troviamo:: Change Manager: il responsabile del processo di Change management Staff IT dell area coinvolta Utenti/clienti Esperti/tecnici OBIETTIVO 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. ESEMPIO CREAZIONE DI UNA CHANGE REQUEST CON OTRS Una change request è definita formalmente come: «una richiesta di modifica alla configurazione del software». Una change request può riguardare, bug applicativi, nuovi requisiti da implementare, problemi di performance ma anche problemi di usabilità/accessibilità. Quale che sia l oggetto della change request, il fatto principale rimane: il project manager si trova a dover valutare la richiesta imprevista e potenzialmente complessa effettuata dall utente.. Copyright E-time Srl 10

13 Supponiamo di dover fare un nuovo rilascio software. 1. Per ogni Change vengono definiti dei workorder che possono essere dati in carico ad operatori differenti. L insieme dei workorder può essere visualizzato graficamente in modo da evidenziare immediatamente sia lo stato dei singoli workorder sia il susseguirsi delle attività (che possono essere fatte in parallelo o in sequenza). La change può essere collegata sia al ticket che all asset interessato (configitem), i collegamenti sono visualizzati all interno della change stessa. 2. Procediamo con la creazione del change inserendo Titolo, Descrizione e Justification (motivazione). Copyright E-time Srl 11

14 Successivamente andiamo ad inserire i vari workorder. Nell esempio in questione sono stati inseriti i seguenti workorder: Blocco 1: - Compilazione form RFC Blocco 2: - Ingaggio controllo qualità - Ingaggio Gestione procedure - Ingaggio Business continuity - Ingaggio Architetture sicurezza - Ingaggio Standard tecnologici - Ingaggio Identity management - Ingaggio Sistemi distribuiti - Ingaggio Sistemi centrali - Ingaggio Architetture web Blocco 3: - Approvazione CAB Blocco 4: - Ingaggio Supporto sistemistico Blocco 5: - Aggiorna CI Dopo aver eseguito il primo workorder e in base al form compilato vengono ingaggiati i vari uffici e quindi vengono eseguiti in parallelo i work order appartenenti al secondo blocco. Una volta che sono stati terminati i workorder appartenenti al blocco 2 parte quello del blocco 3 dove avviene l approvazione da parte del CAB che analizza i vari documenti prodotti dai vari reparti e procede con l autorizzazione o meno del passaggio in produzione. Se questa viene approvata si passa al blocco 4 ingaggiando il supporto sistemistico per il rilascio software. Una volta completato anche questo workorder viene aggiornato il CI contenuto nel CMDB con le modifiche effettuate (ad esempio cambio il link se il rilascio è una modifica del software dove viene cambiato l ufficio che ce l ha in carico). Copyright E-time Srl 12

15 OTRS permette anche la creazione del CAB indicando le persone che ne faranno parte. OTRS permette anche la creazione del CAB indicando le persone che ne faranno parte. Per le attività ripetitive, che quindi richiedono dei passaggi routinari, si possono creare dei template di Change. Ad esempio, una volta creato questa Change relativa al rilascio software possiamo farla diventare un modello e quindi ogni volta che abbiamo un nuovo rilascio software da fare possiamo utilizzare il modello già creato. Copyright E-time Srl 13

16 OTRS: TICKET DI PROCESSO Con ticket di processo identifichiamo un ticket che per passare da uno stato all altro è obbligato a seguire delle azioni (anche quest ultime da definire a loro volta). Un esempio di ticket di processo potrebbe essere la richiesta di reso di un prodotto, la gestione del servizio clienti o la richiesta di ferie da parte di un utente. OTRS permette di gestire questi ticket definendo il processo e i relativi step che gli utenti dovranno effettuare, definendo inoltre le azioni per passare da uno step all altro. Sotto un esempio di definizione di processo per la gestione del Service Desk per l assistenza on-site effettuata anche dai centri di assistenza territoriali (CAT) realizzato con OTRS. Copyright E-time Srl 14

17 CHAPTER 6 Knowledge management DI COSA PARLIAMO Con Knowledge Management o Gestione della conoscenza identifichiamo tutte quelle azioni rivolte ad assicurare la disponibilità e la correttezza delle informazioni per i decision makers. In sostanza attraverso la Gestione della conoscenza si è in grado di mostrare e aggiornare tutte le informazioni necessarie alla gestione dell infrastruttura IT, durante tutto il suo ciclo di vita. OBIETTIVO permettere al fornitore dei servizi (service provider) di essere maggiormente efficiente e di migliorare la qualità nella fornitura dei servizi. assicurare una conoscenza e una comprensione condivisa da parte dello staff di tutte le informazioni necessarie per una efficace ed efficiente fornitura dei servizi. LA GESTIONE DEL KNOWLEDGE MANAGEMENT CON OTRS Per la gestione del Knowledge Management occorre un Service Knowledge Management System - SKMS (o Sistema di Gestione della conoscenza del servizio), che deve essere integrato con tutti gli altri processi dell infrastruttura IT, ecco perchè la scelta di OTRS. Con OTRS posso visualizzare le FAQ già inserite e crearne di nuove, suddividendole nelle sottocategorie di appartenenza. Con la possibilità di restringere la visualizzazione del documento per ruoli dell operatore e customer e code di riferimento. Si possono creare anche dei processi di approvazione nei quali l articolo deve essere validato prima di poter essere pubblicato all interno delle FAQ. Questo può essere effettuato utilizzando code e ruoli predefiniti. Vediamo ora un esempio concreto: inserimento di articoli contenenti le soluzioni relative alle problematiche più generiche, nelle FAQ. Copyright E-time Srl 15

18 1. Creiamo una nuova FAQ inserendo il titolo, assegnando categoria e periodo di validità. Nello stato possiamo anche definire se la FAQ può essere visualizzata dall operatore, dal customer (entrando nella sua interfaccia) o da entrambi. 2. Definiamo il problema per il quale stiamo creando una nuova FAQ e forniamo la soluzione di risposta. Copyright E-time Srl 16

19 3. Visualizzazione della FAQ da parte di un operatore. Queste possono anche essere valutate mettendo le stelle corrispondenti nella parte bassa. Copyright E-time Srl 17

20 CHAPTER 7 Service Catalogue management DI COSA PARLIAMO Per la compilazione strutturata del catalogo servizi, proponiamo di rifarci alla definizione ITIL del catalogo Servizi: Un database o documento strutturato contenente le informazioni su tutti i servizi IT in produzione, inclusi quelli pronti per il deployment. OBIETTIVO Fornire una sorgente univoca di informazioni consistenti su tutti i servizi forniti Rendere le informazioni nel catalogo ampiamente disponibili Assicurarsi che le informazioni nel catalogo siano aggiornate ed opportunamente manutenute LA GESTIONE DEL SERVICE CATALOGUE CON OTRS Per creare il Service Catalogue, ITIL suggerisce i seguenti dati da individuare, per ogni servizio identificato: Nome e descrizione del servizio Tipologia del servizio Eventuali servizi a supporto Business Owner Gestore del servizio Impatto sul Business SLA in essere Orario di disponibilità del servizio Contatti per eventuale escalation di incidenti ecc... Il catalogo dei servizi è parte del portafoglio dei servizi, e contiene informazioni riguardo a due tipologie di servizi IT: Business Service Catalogue: che raccoglie i servizi visibili al cliente; Technical Service Catalogue: elenco dei servizi di supporto richiesti dal service provider, indispensabili anche per erogare i servizi visibili al cliente. Un esempio, può essere quindi la suddivisione dei servizi in due macroaree: Front-End e Back- End al cui interno censire e classificare i servizi di dettaglio per i quali si prevede di fornire assistenza. Copyright E-time Srl 18

21 Nell immagine qui sotto un esempio della vista globale del Catalogo Servizi nell interfaccia di OTRS. Copyright E-time Srl 19

22 Service Level Management DI COSA PARLIAMO Questa la definizione di ITIL per questo processo: mantenere e gradualmente migliorare l allineamento e la qualità dei servizi IT, attraverso un ciclo costante di accordi, monitoraggio, reporting, e revisione degli achievements dei servizi IT e attraverso l implementazione di azioni per eliminare livelli di servizio inaccettabili. OBIETTIVO allineare i servizi IT con i bisogni correnti e futuri del business e dei clienti migliorare la qualità dei servizi IT erogati ridurre i costi fissi di erogazione dei servizi Si evince quindi facilmente l impatto diretto del Service Level Management sull allineamento e il miglioramento della qualità dei servizi, rispettando i limiti di costo prefissati. Si tratta di un processo che coinvolge attivamente sia il cliente che il fornitore. Il primo è spinto a definire le proprie necessità, mentre il secondo a fornire risposte coerenti. Da questo nasce la definizione degli SLA (Service Level Agreement) tra clienti e provider. SERVICE LEVEL MANAGEMENT CON OTRS Per ciascun servizio del Service catalogue si possono definire i relativi SLA, cioè accordi presi tra fornitori e clienti che dovranno essere monitorati ad intervalli di tempo stabiliti. Riportiamo un esempio di creazione di uno SLA relativo ad uno o più servizi. 1. Iniziamo l inserimento dello SLA definendo la tipologia, i servizi a cui andrà collegato, il calendario e le tempistiche di escalation. Copyright E-time Srl 20

23 Per quanto riguarda il tipo di SLA da creare, OTRS permette di sceglierlo tra un set già predefinito: 2. Una volta creato, il nuovo SLA potrà essere visualizzato all interno della finestra di riepilogo. Una volta definiti gli SLA si possono creare report condivisibili sia per monitorare i servizi, sia come garanzia del raggiungimento degli obiettivi pattuiti tra clienti e fornitori. Copyright E-time Srl 21

24 E-time S.r.l. Viale del Lavoro, San Martino Buon Albergo (VR) P.iva