Change management

((OTRS)) Community Edition & ITIL

La gestione dei cambiamenti


Implementare ITIL con ((OTRS)) Community Edition

La standardizzazione dei processi e il tempo di risposta dell’infrastruttura IT ai cambiamenti, rappresentano il terreno su cui si gioca la partita ed è per questo che presidiare questo processo diventa fondamentale Seguendo le best practices ITIL, il processo di Change management 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.” Una change request è definita come: “richiesta di modifica alla configurazione del software”. Può riguardare:
  • bug applicativi
  • nuovi requisiti da implementare
  • problemi di performance
  • problemi di usabilità/accessibilità
Qualunque sia l’oggetto della change request, il project manager si ritrova a dover valutare la richiesta imprevista e potenzialmente complessa effettuata dall’utente. Supponiamo di dover fare un nuovo rilascio software:
    1. Per ogni Change vengono definiti dei workorder che possono essere assegnati e presi in carico da operatori differenti. L’insieme dei workorder viene visualizzato graficamente così da evidenziare subito sia lo stato dei singoli workorder che il susseguirsi delle attività (possono essere eseguite in parallelo o in sequenza). La change, infine, può essere collegata:
      • al ticket
      • all’asset interessato (configItem)
      • ad entrambi
      tutti i collegamenti sono visualizzati all’interno della change stessa.
    2. Si prosegue con la creazione del change inserendo Titolo, Descrizione e Justification (motivazione).
Successivamente si andranno ad inserire i vari workorder. In questo esempio abbiamo inserito i workorder che riportiamo di seguito:
      • Block 1:
        • Compilazione form RFC
      • Block 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
      • Block 3:
        • Approvazione CAB
      • Block 4:
        • Ingaggio Supporto sistemistico
      • Block 5:
        • Aggiorna CI
Dopo l’esecuzione del primo workorder e in base al form compilato vengono ingaggiati gli uffici appartenenti alle diverse aree e in parallelo vengono eseguiti anche i work order appartenenti al secondo blocco. Una volta terminati i workorder appartenenti al blocco 2, partiranno quelli assegnati al blocco 3, dove avviene l’approvazione da parte del CAB che provvederà ad analizzare i documenti prodotti dai vari reparti, procedendo poi con l’autorizzazione o meno del passaggio in produzione. Se c’è l’approvazione, si passa al blocco 4 ingaggiando il supporto sistemistico per il rilascio software. Una volta completato anche quest’ultimo work order viene aggiornato il CI (Configuration Item) contenuto nel CMDB con le modifiche effettuate. ((OTRS)) Community Edition, inoltre, permette anche la creazione del CAB indicando le persone che ne faranno parte. Per le attività ripetitive, possono essere creati dei template modello. Riprendendo il nostro esempio, per ogni nuovo rilascio software che dovremo fare, possiamo utilizzare il modello creato.

((OTRS)) Community Edition: Ticket di processo

Con questa espressione identifichiamo un ticket che per passare da uno stato all’altro è obbligato a seguire diverse azioni. Un esempio di ticket di processo potrebbe essere la richiesta di un reso prodotto, oppure La gestione del servizio clienti o la richiesta di ferie da parte di un utente. ((OTRS)) Community Edition permette di gestire questi ticket definendo il processo e i relativi step che gli utenti dovranno effettuare, stabilendo anche quali sono le azioni necessarie per passare da uno step al successivo. Nell’immagine qui sotto riportiamo un’esempio di processo per la gestione del Service Desk di assistenza on-site, oggetto di un Centro di Assistenza Territoriale (CAT), realizzato con OTRS.

Altri approfondimenti…


Incident management

Ripristinare l’operatività garantendo la continuità del servizio.

Read more

Problem management

Gestire l’insorgere di un problem con ((OTRS)) Community Edition ed evitare che si ripetano.

Read more

Knowledge management

Qualità dei servizi offerti, conoscenza e condivisione delle informazioni.

Read more

Desideri maggiori informazioni? Contattaci.