Il CMDB come central data source
Dopo aver identificato l’importanza del CMDB per le aziende orientate ai servizi nel mio ultimo articolo su questo blog, ora desidero porre l’attenzione su un argomento più pratico.
Oggi rappresentare un intero processo utente all’interno di un’azienda può essere abbastanza complesso. Il principale motivo sussiste nell’iterazione di una varietà di aree business diverse e la considerazione di molte attività.
Per comprendere meglio questo aspetto è sufficiente considerare il processo (semplificato) nel caso in cui un dipendente decida di lasciare l’azienda.
Generalmente, l’ufficio che si occupa della gestione delle risorse umane (HR) è il punto di partenza di questo processo, ma esistono anche attività, che riguardano il reparto che il dipendente sta lasciando e ovviamente anche il reparto IT.
Quali potrebbero essere queste attività? (ne elencherò alcune solo per averne un’idea)
- Comunicazione della data di dimissione a tutti i reparti coinvolti da parte del reparto HR (alla fine del processo, il reparto HR deve comunicare tutte le attività che si sono concluse).
- Il reparto IT deve completare i seguenti compiti
- Disabilitare / cancellare l’account
- Bloccare l’indirizzo email
- Rimuovere il contatto dalle liste di mailing
- Disabilitare l’accesso alle unità di disco
- Modificare la rubrica telefonica aziendale
- Ritirare il computer
- Ritirare i dispositivi mobili
- Terminare i contratti
- Trasferire le licenze
- Disabilitare l’account e l’accesso VPN
- …
- Il reparto coinvolto deve svolgere i compiti interni e informare l’IT sulle decisioni intraprese.
Per coordinare in modo strutturato queste attività (e tante altre ancora) è necessario l’utilizzo di uno strumento di service management con un flusso di funzioni integrate e la conoscenza della struttura dei CI per il workflow stesso.
Se un CMDB con un processo di change management viene gestito correttamente, è davvero facile trovare tutti i dati inerenti l’utente. Le informazioni più rilevanti possono essere per esempio se l’utente possiede dispositivi mobili e che contratti ha assegnato. In base a queste informazioni si possono generare automaticamente delle liste molto accurate.
Un altro esempio può essere la rimozione di un contatto dalle liste di mailing o da un gruppo telefonico ecc. Queste procedure possono essere eseguite automaticamente utilizzando gli scripts. Questo può essere applicato anche per la rimozione degli accessi agli applicativi. Grazie ad un CMDB mantenuto in modo corretto, è sempre possibile conoscere a quali applicativi interni o esterni un collaboratore può accedere. Questi permessi possono anche essere rimossi attraverso l’esecuzione di scripts.
Oltre ai dispositivi assegnati, esistono molte altre decisioni che un reparto deve prendere durante le dimissioni di un collaboratore. Cosa si deve fare ad esempio con l’account di posta elettronica? Deve essere cancellato o assegnato ad un alto collaboratore (facendo attenzione alle leggi della privacy per la protezione dei dati) o le email devono essere inoltrate ad un altro collega (per esempio se l’indirizzo email era utilizzato in certe pubblicazioni)?
Come va gestito l’unità di rete personale? (Potrebbero essere state salvate informazioni particolarmente rilevanti per il business aziendale). Tutte queste domande non possono trovare risposta nel reparto IT, ma devono essere chiarificate dal reparto a cui il collaboratore appartiene.
Il reparto IT comunque deve fornire le informazioni rilevanti riguardo il collaboratore per supportare il processo decisionale. Spesso infatti il responsabile del dipendente non sa a quali dati il collaboratore stesso possa accedere.
Nei processi di service management, le informazioni riguardo il dipendente sono rappresentate graficamente attraverso le relazioni tra i diversi tipi di CI all’interno del CMDB (le tipologie dei CI possono essere per esempio hardware, software, documenti, servizi, persone ecc.). Quindi il CMDB serve come archivio di dati per diversi processi di service management (come change management, service request fulfillment, access management ecc.)
In conclusione
Riassumendo possiamo affermare che un un service management non può essere affidabile senza un mantenimento corretto e aggiornato del CMDB. I dati contenuti nel CMDB devono infatti sempre essere accurati e attuali per una visualizzazione e automatizzazione dei workflow.
In questo articolo la descrizione delle attività e delle loro interazioni è stata semplificata per poter avere una comprensione generale dell’argomento. In pratica ci sono molti altri aspetti che devono essere considerati (ma per una comprensione globale, questi dettagli non sono così rilevanti). Questo articolo è stato ideato per fornire una panoramica sull’utilizzo pratico di un CMDB.
Importante: In un CMDB le dipendenze/relazioni/connessioni tra i CI sono il punto fondamentale. Attraverso una mappa di relazioni (Configuration Management Relationship Map) si possono visualizzare tutte le connessioni tra i vari CI.
Il mio prossimo articolo si occuperà invece dell’integrazione del CMDB nella soluzione di IT service Management EriZone.
Martin Fischer
Author
