Spesso una percezione limitata riguardo il Service Catalog porta a considerarlo come una lista statica di servizi, la cui utilità non va oltre la mera elencazione. In realtà è uno strumento fondamentale per la gestione dei servizi digitali: approfondiamo insieme in che modo ci aiuta a garantire che l’offerta soddisfi sempre le esigenze dell’organizzazione e degli utenti finali.
Una comprensione superficiale del Service Catalog (Catalogo dei Servizi) e della sua funzione essenziale ne porta a sottovalutare l’utilità nella gestione dei servizi digitali, dove il Service Catalog invece riveste un ruolo fondamentale.
Questa percezione limitata spesso si traduce nel considerarlo come una lista statica di servizi, la cui utilità non va oltre la mera elencazione delle funzionalità offerte. In realtà è molto di più: si tratta di un registro strutturato e dettagliato che fornisce una visione chiara e comprensibile della gamma completa dei servizi e delle loro relazioni con i processi aziendali e le esigenze del business e dei suoi utenti.
Il fatto di trovare in un’unica fonte di verità costantemente aggiornata le informazioni essenziali sui servizi offerti, inclusi dettagli come descrizioni, condizioni di erogazione, requisiti, costi, tempi di consegna e altre informazioni pertinenti ha una duplice valenza:
Dal punto di vista delle pratiche ITIL (Information Technology Infrastructure Library), il Service Catalog fa riferimento principalmente alle pratiche di “Service Catalogue Management” (Gestione del Catalogo dei Servizi) e di “Service Portfolio Management” (Gestione del Portfolio dei Servizi). In quest’ultima, che riguarda la gestione dell’intero portfolio dei servizi IT (quindi tutti, da quelli in fase di definizione, sviluppo, erogazione fino a quelli in ritiro), il Service Catalog si concentra sulla definizione, gestione e pubblicazione del catalogo dei servizi che sono in fase di transizione o che sono già disponibili in ambiente live, con le relative informazioni a corredo.
Vediamo ora nel dettaglio quali sono le informazioni che ci servono per garantire che i servizi digitali soddisfino le esigenze dell’organizzazione e degli utenti finali.
Dato che, secondo ITIL, il ruolo principale della pratica di Service Catalogue Management è quello di aiutare il Service Provider a focalizzarsi sui «customer outcomes» (i risultati attesi dallo stakeholder finale) a partire da una correlazione tra le attività interne di servizio, gli asset a supporto (i CIs) e i processi di business, la prima importante distinzione da fare è sulla tipologia di servizio.
All’interno di un Service Catalog, i servizi possono essere suddivisi in due principali categorie:
Ad esempio gli utenti desiderano inviare e ricevere mail in modo rapido e affidabile. Questo è un esempio di Customer-Facing Service in quanto l’utente è direttamente coinvolto nell’utilizzo del servizio e si aspetta che sia efficiente e veloce. Il Service Provider (in questo caso il team IT) gestisce i Supporting Services per garantire che il servizio mail funzioni correttamente senza che l’utente debba preoccuparsi dei dettagli tecnici sottostanti.
Quindi se parliamo di gestione di router, switch, firewall e altri dispositivi di rete che consentono la comunicazione dati sono tutti elementi invisibili all’utente: che si usi un provider mail o un server rispetto a un altro, all’utente è indifferente a patto che le sue esigenze siano soddisfatte. A riguardo possiamo citare Philip Kotler, il guru del marketing moderno: «la gente non vuole un trapano, vuole un buco nel muro».
Nell’immagine di seguito, vediamo un esempio di come le due tipologie di servizio possono legarsi l’una con l’altra e in particolare ai processi e agli utenti di business che supportano. Un servizio può essere listato singolarmente, ma anche come “pacchetto”: in quel caso a comporlo può esserci un servizio principale (core service) e uno o più servizi aggiuntivi (enhancing service). Nel caso di un “pacchetto” può esserci un singolo SLA (Service Level Agreement) a coprirlo, con i servizi rimanenti che sono coperti dai propri SLA.
Il Service Catalog deve fornire una descrizione completa di ogni servizio offerto dall’organizzazione e includere i collegamenti a tutte le componenti di servizio interessate, al fine di offrire una visione chiara degli asset, dei processi e dei sistemi coinvolti nella fornitura di ciascun servizio.
Per definire, documentare e mantenere questi collegamenti in modo accurato e aggiornato, la pratica di Service Catalogue Management deve lavorare in stretta collaborazione con le pratiche di Asset Management e Configuration Management. Il Configuration Management Database (che chiamiamo CMDB per semplicità di comprensione, quando sarebbe più corretto usare il termine CMS) è il repository centrale in cui vengono archiviate le informazioni su asset, configurazioni e relazioni tra di essi. Il Service Catalog deve essere quindi integrato con il CMDB per garantire che le informazioni sui servizi siano allineate e aggiornate rispetto agli asset e alle configurazioni che li supportano.
Qual è il vantaggio di questa integrazione? Definendo ogni servizio come CI (Configuration Item) e, dove possibile, collegandoli tra loro per formare la catena di erogazione del servizio, l’organizzazione è in grado di risalire a monte dell’effetto domino che si verifica con incidenti o change e di conseguenza riesce anche a porre le basi per il service monitoring e reporting (ad es. può analizzare se la frequenza di incidenti che colpiscono un particolare servizio è legata a una causa specifica e intervenire di conseguenza).
Oltre al dettaglio sulle configurazioni e sulle dipendenze del servizio, è importante qualificare anche come stanno performando e come performeranno: qui entrano in gioco informazioni come i Service Reports che forniscono una panoramica delle prestazioni dei servizi (in stretta relazione con gli SLA e gli OLA definiti), ma anche le discussioni su eventuali richieste di miglioramento (Service Reviews) e il loro rating in termini di sicurezza (che può dare una stima indicativa della percentuale di rischio per cui potrebbero verificarsi interruzioni di servizio future).
Dato che il Service Catalog fornisce una visione consolidata dei servizi IT offerti e dei loro legami con i processi aziendali, diventa uno strumento fondamentale per l’attività di BIA (Business Impact Analysis): la valutazione delle dipendenze dei servizi IT aiuta, infatti, a determinare il rischio (definito come probabilità per impatto) e le conseguenze finanziarie, operative e di reputazione che un’interruzione dei servizi IT potrebbe avere sulle attività aziendali.
La qualità e la completezza delle informazioni nel Service Catalog influenzeranno l’efficacia della BIA: è per questo che nella costruzione del catalogo bisogna privilegiare un approccio “top-down” (ne abbiamo parlato anche in questo articolo sulla gestione dei servizi). Solo partendo dall’analisi degli obiettivi strategici si sarà in grado di individuare quali sono i processi aziendali chiave e di conseguenza quali sono i servizi critici che hanno un impatto significativo sul business e che richiedono una particolare attenzione in termini di continuità operativa e gestione del rischio.
Diversamente, con un approccio “bottom-up” dove il catalogo viene costruito a partire da quanto rilevato dai sistemi di discovery e gestione degli asset e delle configurazioni, rischiamo di non riuscire a collegare le informazioni fornite in una visione strategica sulla rilevanza e criticità del servizio. Ricordiamoci che un asset è riconosciuto come critico quando supporta un servizio critico.
Oltre alla valutazione dell’impatto, questo approccio ha ricadute positive su due aspetti:
Si consiglia di strutturare i dati del Service Catalog in un singolo repository: per iniziare è sufficiente anche un foglio Excel con i collegamenti alle risorse. Nella sua presentazione (dato che deve essere facilmente consultabile da tutti gli stakeholder), si tenga presente anche il target a cui è rivolto.
Per esempio, se il Service Catalog è ad uso dell’IT, per le informazioni dettagliate sui servizi tecnici/di supporto si può rimandare al CMS (o comunque agli strumenti che contengono i dati relativi agli asset, alle configurazioni e alle loro dipendenze). Se il Service Catalog è ad uso di utenti finali (o comunque di realtà che supportano la loro promozione e vendita), i dettagli sui Customer-Facing Services potrebbero essere resi disponibili tramite applicazioni browser-based.
Qui poi si apre un mondo: con un catalogo ben strutturato è più facile attivare una gestione self-service dei servizi.
Nella costruzione del file Excel (sotto un template di esempio preso dal libro ITIL Service Design), il Service Provider dovrebbe considerare quali servizi (righe di dati) e quali elementi o campi di dati (colonne di dati) dovrebbero essere inclusi in ogni vista. Per esempio, quali dettagli sui servizi di supporto sono importanti da includere in una vista per uno staff tecnico e quali non interessano agli utenti finali (e per questo sono da escludere dalla loro vista).
Nel nostro webinar “DORA: aumenta la resilienza operativa con Service Catalog e Dependency Mapping” (vai qui per guardare il replay) mostreremo un business case calato in un contesto bancario/finanziario.
Visto che entro gennaio 2025 le realtà del settore dovranno adeguarsi al regolamento europeo DORA (Digital Operational Resilience Act), approfondiremo con esempi concreti come un Service Catalog ben definito aiuta le istituzioni finanziarie a comprendere quali sono i servizi digitali critici e le loro interconnessioni, a beneficio di una migliore gestione dei rischi operativi e una maggiore resilienza in caso di interruzioni e malfunzionamenti.
Se vuoi sapere di più sull’argomento, guarda il replay sul nostro canale Youtube!
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2022 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda certificata ISO 9001:2015