Change management

La gestione dei cambiamenti

“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.”
IT experts build the processes
Di cosa parliamo

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

Esempio creazione di una Change request con Rexpondo

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
Blocco 3:
  • Approvazione CAB
Blocco 4:
  • Ingaggio Supporto sistemistico
Blocco 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.

Attachment details window

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.

change request with otrs ce

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

process management with otrs ce
Altri approfondimenti

Incident management

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

Problem management

Gestire l’insorgere di un problem con Rexpondo ed evitare che si ripetano.

Knowledge management

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

Scopri come Rexpondo può aiutarti a implementare ITIL nella tua azienda.