Governance del catalogo dei servizi: come rendere SLAs, OLAs e KPIs vincolanti

Una governance del catalogo dei servizi funzionante determina in pratica se le promesse di servizio sono controllabili in modo affidabile oppure se nella gestione quotidiana sfociano in discussioni, escalation e rilievi d’audit. Molte organizzazioni hanno un catalogo dei servizi nello strumento o nel wiki, ma senza vincoli: gli SLA non sono definiti in modo misurabile, gli OLA sono solo „accordi di team“ senza potere d’imposizione, i KPI vengono riportati a sentimento o non possono essere dimostrati in sede di audit.

In questo articolo non si tratta di termini ITIL come fine a se stessi, ma di meccaniche di governance attuabili: quali contenuti un catalogo dei servizi deve necessariamente contenere, come SLA (Service Level Agreements, cioè impegni di servizio verso il cliente) e OLA (Operational Level Agreements, cioè impegni di consegna interni tra team) si incastrano tra loro, come definire i KPI (Key Performance Indicators, indicatori misurabili di controllo) in modo che monitoring, ticketing e reporting parlino la stessa lingua – e come rendere il tutto idoneo alla revisione.

Lo stato obiettivo è chiaro: una direzione IT può prioritizzare e budgettizzare i servizi, l’operatività può gestire le escalation in modo ordinato, Security e Compliance possono fornire evidenze, e la direzione aziendale ottiene report affidabili invece di semafori interpretati.

Perché „definito“ non equivale a „vincolante“

La vincolatività nasce solo quando una promessa di servizio è decidibile: deve essere univoca, misurabile, assegnata a un Owner, supportata da dipendenze realistiche e inserita in un regime di change e reporting. Altrimenti nella pratica accade tipicamente quanto segue:

• Inflazione degli SLA: I reparti richiedono „99,9% di disponibilità“ o „supporto 24/7“ come standard. Senza un modello di costi e rischi si promette ciò che poi non può essere rispettato.
• Lacune negli OLA: Il service owner „vende“ uno SLA, ma i team interni non hanno tempi di reazione e di consegna vincolanti, nessuna regola di reperibilità, nessuna promessa di capacità.
• Teatro dei KPI: Sono presenti KPI, ma fonte, logica di calcolo e ambito sono poco chiari. In sede di audit o durante escalation non è possibile ricostruire come sono stati ottenuti i numeri.
• Contraddizioni tra tool: Il monitoring misura qualcosa di diverso dal sistema di ticketing, e il reporting misura di nuovo qualcos’altro. Le discussioni riguardano allora i dati anziché le azioni.

La governance del catalogo dei servizi è quindi meno una „documentazione“ e più un quadro di controllo e di evidenza: chi decide cosa, sulla base di quali dati, con quali conseguenze in caso di scostamento.

Separare i termini con precisione: SLA, OLA e KPI nel contesto operativo

La causa più comune di ambiguità è una logica di livelli errata. Una separazione pratica appare così:

• SLA (Service Level Agreement): Accordo tra IT (o fornitore IT) e il „cliente“ (area di business, società controllata, clienti esterni). Contenuto: orari di servizio, disponibilità, canali di supporto, obiettivi di reazione e risoluzione, finestre di manutenzione, obblighi di comunicazione, responsabilità, eccezioni.
• OLA (Operational Level Agreement): Accordo interno tra team/unità che abilitano lo SLA (es. team piattaforma, rete, database, Security Operations). Contenuto: tempi di reazione interni, passaggi, attività operative, condizioni di accettazione, reperibilità, dipendenze, standard tecnici minimi.

Importante: uno SLA è un impegno. Un OLA è una capacità di erogazione. I KPI sono la misurazione. La governance collega i tre tramite ruoli, fonti dati, gestione delle versioni, escalation e azioni correttive.

Governance del catalogo dei servizi come sistema decisionale e di controllo

Se impostate il catalogo dei servizi come strumento di governance, non dovreste trattarlo come un elenco di „cose che fa l’IT“, ma come un inventario controllato di servizi con ciclo di vita definito. Le domande chiave sono:

• Quali servizi sono ufficiali? (inseribili nel catalogo con proprietario, ciclo di vita, modello di costi, rischi)
• Quali livelli di servizio esistono realmente? (Standard, esteso, critico – con condizioni e prezzi/assegnazione CapEx/OpEx)
• Come si misura? (fonte di monitoraggio, logica di calcolo, ambito, qualità dei dati)
• Come si decide? (approvazione delle eccezioni SLA, priorità alle migliorie, decisioni di investimento)
• Come si fornisce la prova? (audit trail, versioni, evidenze, report, tracciamento delle azioni)

Questa logica alleggerisce l’operatività: le escalation diventano meno „personali“, perché si basano su criteri definiti. Allo stesso tempo la compliance diventa gestibile, perché le prove provengono da un sistema controllato anziché da screenshot raccolti ad hoc.

Contenuti minimi di una voce del catalogo dei servizi auditabile

Una voce di catalogo dei servizi deve essere così completa da permettere a un nuovo responsabile (o auditor) di inquadrare il servizio senza conoscenze implicite. Nella pratica si sono dimostrati utili campi obbligatori che possono essere rappresentati in tool (ITSM, CMDB) o in una struttura di documentazione centrale.

Campi obbligatori (compatti, ma completi)

• Nome e scopo del servizio: cosa supporta il servizio nell’azienda, per chi, con quale delimitazione?
• Service Owner: responsabile funzionale per i livelli di servizio, la priorità, le decisioni su budget/rischi (non solo „team leader operativo“).
• Owner tecnico / responsabilità operativa: chi gestisce, chi modifica, chi autorizza le misure di emergenza.
• Criticità del servizio: classe di impatto sul business (es. finanziario, regolatorio, critico per la sicurezza) con criteri chiari.
• Orari di servizio e canali di supporto: es. 8×5/12×5/24×7, canale incident, percorso per major incident.
• Componenti SLA: disponibilità (definizione!), obiettivi di reazione/risoluzione, finestre di manutenzione, obblighi di comunicazione.
• Dipendenze: piattaforme interne, Identity, rete, provider esterni; ciascuna con riferimento OLA.
• Concetto di misurazione: fonti dati, calcolo, punti di misura, esclusioni, conservazione dei dati (per audit).
• Requisiti di sicurezza e compliance: es. logging, conservazione, controlli di accesso, crittografia, cicli di patch, gestione delle vulnerabilità.
• Regole di change/release: modifiche standard vs. change rischiosi, CAB/Change Advisory Board (organo per le autorizzazioni ai change) o logica di approvazione alternativa.
• Ciclo di vita: introduzione, esercizio, sunset/disattivazione, percorso di migrazione.

Chi qui ritiene deliberatamente che sia «troppo»: esattamente queste informazioni vengono comunque richieste nelle escalation. Governance significa tenerle predisposte in modo strutturato.

Formulare gli SLA in modo che siano misurabili e negoziabili

Molti testi di SLA sono formulati giuridicamente o organizzativamente, ma non sono misurabili tecnicamente. Questo porta a controversie in due situazioni: in caso di inadempienza e in sede di audit. Un SLA solido necessita quindi di finestre di misurazione definite, confini di sistema chiari e un calcolo trasparente.

Componenti tipiche degli SLA e loro insidie

• Disponibilità: Definite „Service up“ come stato misurabile (z. B. erfolgreiche synthetische Transaktion, API-Health-Check, Login möglich) e chiarite se le finestre di manutenzione sono escluse. Evitate metriche di sola infrastruttura (z. B. „Server erreichbar“) come misura di disponibilità del servizio.
• Prestazioni: Se le prestazioni sono rilevanti per lo SLA, deve essere chiaro: punto di misurazione (Client, Edge, Backend), percentille (z. B. p95), periodo, esclusioni (z. B. Lastspitzen durch genehmigte Massenläufe).
• Reazione agli incidenti e risoluzione: Il tempo di reazione non è uguale al tempo di risoluzione. Definite i punti di inizio (Ticket-Eingang? Alarm?), i cambi di stato nell’ITSM e le regole in caso di informazioni mancanti.
• Finestre di manutenzione e Change: La governance richiede una policy chiara: chi approva, come viene annunciato, come si effettua il rollback, quali evidenze vengono generate.
• Comunicazione: Soprattutto per servizi critici, una SLA di comunicazione è spesso altrettanto importante dei valori tecnici: chi informa chi, tramite quale canale, con quale ritmo durante Major Incidents.

Guida alla decisione: livelli SLA come prodotto, non come lista dei desideri

Invece di negoziare ogni volta per singolo servizio, è efficace un kit modulare con 2–4 livelli SLA (z. B. Standard, Erweitert, Kritisch). La regola di governance è: le eccezioni sono possibili, ma richiedono approvazione e devono rendere trasparenti costi/rischi. Questo evita „Schatten-SLAs“ per e-mail.

OLAs come catena di fornitura: impegni interni lungo le dipendenze

Spesso gli OLAs sono sottovalutati, ma sono la leva reale per la responsabilità. Un Service-Owner può assumersi la responsabilità di uno SLA solo se i team interni hanno promesso i loro contributi. In pratica significa: ogni servizio necessita di una mappa delle dipendenze con impegni interni di consegna chiari.

Cosa dovrebbe contenere un OLA (e cosa no)

• Obiettivi di reazione e di trattamento: z. B. „DBA reagiert innerhalb von 30 Minuten bei P1“ (mit definiertem P1-Kriterium).
• Regole di reperibilità: On-Call, Eskalationsstufen, Stellvertretung.
• Punti di consegna: quando un Ticket/Incident „übergeben“ gilt, quali informazioni sono obbligatorie (Runbook-Link, Logs, Metriken).
• Standard-Changes: cosa è consentito senza CAB, con quali precondizioni e quale evidenza viene generata (Change-Ticket, Peer-Review, Backout-Plan).
• Impegni su capacità e manutenzione: finestre di patch, lifecycle dei componenti di piattaforma, processi di End-of-Life.

Non appartengono a un OLA: obiettivi vaghi („tempestivamente“), liste di desideri tecnici senza percorso operativo o dipendenze senza un responsabile. I testi OLA sono contratti di lavoro tra team – devono funzionare in esercizio.

KPIs: Dall’indicatore alla gestione (e alla prova per l’audit)

I KPI hanno senso solo se influenzano decisioni. Nel contesto della governance del catalogo dei servizi si distinguono tre classi:

• SLA-KPIs (contrattuali): p.es. disponibilità nella finestra di misurazione, rispetto degli obiettivi di reazione/risoluzione per priorità.
• KPI operativi (di controllo): p.es. volume di incidenti per servizio, incidenti ricorrenti, Change-Failure-Rate, Mean Time to RESTore (MTTR).
• KPI di compliance/security (di controllo): p.es. patch-compliance, copertura del logging, revisioni delle autorizzazioni entro i termini, tempi di risoluzione delle vulnerabilità in base alla criticità.

Una regola importante di governance: ogni KPI necessita di una scheda dati. Senza una scheda dati per il KPI il reporting diventa questione di interpretazione. Una scheda dati per KPI comprende almeno definizione, calcolo, fonte dei dati, frequenza di misurazione, responsabili, valore target/soglie e gestione dei gap nei dati.

Concetto di misurazione: fonti dati, calcolo e dimostrabilità

La capacità di vincolare spesso non fallisce per volontà, ma per dati incoerenti. Un concetto di misurazione è quindi obbligatorio – soprattutto se gli SLA devono reggere in caso di contenzioso o in sede di audit.

Linee guida pratiche per un concetto di misurazione affidabile

• Single Source of Truth per KPI: stabilire quale sistema è la fonte (Monitoring, ITSM, Log-Analytics). Valori misti senza una regola chiara sono contestabili.
• Sincronizzazione temporale: base temporale unificata (NTP), fusi orari definiti, chiara attribuzione degli eventi (inizio/fine incidente).
• Disciplina dei punti di misurazione: la disponibilità del servizio misurata tramite service-checks (transazioni sintetiche) è più rappresentativa dei ping dell’host.
• Conservazione dei dati: per audit e analisi delle tendenze i dati grezzi devono rimanere disponibili per un periodo adeguato (log-retention, metriche, ticket).
• Documentare le eccezioni: finestre di manutenzione, Force Majeure, downtime approvati dal business: tutto deve essere versionato e dimostrabile.

Se volete standardizzare policy o passaggi di verifica, è utile un modello breve e copiabile. Esempio di struttura di policy interna (contenuto non specifico per tool, ma utilizzabile come checklist):

POLICY: Misurabilità di KPI e SLA (standard breve)

1) Ogni valore SLA deve avere:
   - Finestra di misurazione (orari, giorni)
   - Punto di misurazione (check sintetico / API / endpoint)
   - Definizione "soddisfatto/non soddisfatto"
   - Regola per le finestre di manutenzione e downtime approvato

2) Ogni KPI dispone di una scheda tecnica:
   - Nome KPI, scopo, Owner
   - Formula di calcolo
   - Fonte primaria dei dati (sistema + dataset)
   - Frequenza di misurazione e frequenza di reporting
   - Valore target/soglie + regola di escalation
   - Controllo qualità dati (valori mancanti, duplicati)

3) Tracciabilità:
   - Conservazione dei dati grezzi (almeno X mesi secondo disposizioni interne)
   - Versionamento dei report (non sovrascrivere retroattivamente il report mensile)
   - Audit trail per le eccezioni (approvazioni di change/maintenance)

Ruoli, responsabilità ed escalation: senza RACI non c’è governance

Nella pratica la governance assume concretezza quando le responsabilità non sono solo nominate, ma vincolanti per le decisioni. A questo scopo è utile una logica RACI: Responsible (esecutivo), Accountable (tenuto a rendere conto), Consulted (da consultare), Informed (da informare).

Set minimo di ruoli per la governance del catalogo di servizi

• Service-Owner (Accountable): responsabile delle promesse SLA, della prioritizzazione, delle tematiche di budget/rischio e delle autorizzazioni per eccezioni.
• Operations Owner / Betriebsverantwortlicher (Responsible): garantisce Runbooks, monitoring, processi di reperibilità e risposta agli incidenti.
• Resolver Groups (Responsible): team specialisti (rete, DB, piattaforma) che forniscono OLAs.
• Security/Compliance (Consulted/Control): definisce requisiti di evidenza e controllo, verifica la qualità di KPI e logging, supporta gli audit.
• Service Management / ITSM-Funktion (Responsible): gestisce il processo di catalogo, il versionamento, i cicli di revisione e gli standard di reporting.

Senza questi ruoli ogni escalation diventa un problema organizzativo. Con ruoli chiari diventa un problema di processo — e quindi risolvibile.

Meccanismi di governance: versionamento, cicli di revisione e processi per le eccezioni

Afinché SLAs/OLAs/KPIs rimangano vincolanti, servono meccanismi che controllino le modifiche e prevengano impegni obsoleti. Tre elementi sono particolarmente efficaci:

1) Versionamento con data di validità

Ogni versione di SLA/OLA deve avere una data di efficacia e una motivazione della modifica. Non è il „documento“ che conta, ma la tracciabilità: quali regole erano in vigore quando si è verificato un incidente?

2) Revisioni periodiche (non solo in caso di problemi)

La frequenza appropriata dipende dalla criticità del servizio: servizi critici più frequentemente, servizi standard meno. Una review comprende almeno: trend dei KPI, incidenti maggiori, interruzioni ricorrenti, qualità delle change, capacità/backlog, riscontri di sicurezza. L’output dovrebbe contenere sempre decisioni (risolvere, accettare, investire, de-scope).

3) Processo di eccezione con logica di rischio e costi

Le eccezioni sono normali: una unità di business richiede un livello di servizio più elevato, un sistema legacy non può raggiungere certi valori, un provider impone limiti. Diventano vincolanti quando sono formalmente registrate: a termine, motivate, approvate, con un piano di azione o con accettazione consapevole del rischio.

Un modello di eccezione pratico come blocco copiabile:

MODULO: Eccezione SLA/OLA (Modulo breve)

- Servizio interessato:
- Valore interessato (SLA/OLA/KPI):
- Scostamento (Reale vs. Obiettivo):
- Motivazione (tecnica/organizzativa):
- Impatto sul business in caso di mantenimento:
- Valutazione del rischio (es. disponibilità, Security, Compliance):
- Misure di compensazione (monitoraggio, fallback, comunicazione):
- Durata (fino a data) e termine per la revisione:
- Autorizzatore (Service-Owner + eventualmente Compliance/Security):

Prospettiva di audit: Welche Nachweise typischerweise fehlen

Gli audit (interni o esterni) raramente verificano solo l’esistenza di un documento. Verificano se l’organizzazione esercita controllo e può fornire evidenze. Le lacune tipiche nella governance di SLA/OLA/KPI sono:

• Nessun Audit-Trail coerente: i report vengono modificati a posteriori, le eccezioni non sono versionate, le finestre di manutenzione non sono tracciabili.
• Origine dei dati non chiara: i valori KPI sono „dal dashboard“, ma mancano dati grezzi, query o regole di calcolo.
• Mancanza di responsabilità: il Service-Owner non è nominato o non dispone di diritti decisionali (budget, priorità, autorizzazione per eccezioni).
• Controlli senza follow-up: i rilievi vengono documentati, ma le azioni non sono seguite (nessun responsabile, nessuna scadenza, nessuna prova di efficacia).
• Confusione di scope: componenti infrastrutturali sono vendute come servizio senza una vista end-to-end (Identity, percorsi di rete, dipendenze esterne).

Se volete diventare auditabili, pensate in termini di artefatti: documenti SLA/OLA versionati, schede dati KPI, collegamenti a ticket, approvazioni di change, Major-Incident-Reports, evidenze di review e liste delle azioni.

Costi e capacità: perché i livelli di servizio richiedono sempre un modello operativo

I livelli di servizio non sono solo „obiettivi“, ma assorbono capacità: reperibilità on-call, ridondanza, monitoring, sforzo di testing, costi di ricambi e licenze, contratti con provider, controlli di Security. La governance deve rendere visibile questa relazione, altrimenti gli SLA diventano un’approvazione implicita di budget.

Driver di costo concreti da includere nelle decisioni sugli SLA

• On-Call e capacità 24/7: copertura del personale, catene di escalation, runbooks, formazione.
• Ridondanza e failover: infrastruttura aggiuntiva, complessità operativa, test regolari (prove di failover).
• Monitoring e Observability: controlli sintetici, retention dei log, alerting, reporting SLO/SLA.
• Sicurezza delle modifiche: ambienti di staging, meccanismi di rollback, processi di approvazione, automazione.
• Security/Compliance: controlli più stringenti (es. obblighi più severi di logging e review) aumentano il carico, ma riducono il rischio.

La direzione IT ha bisogno di chiarezza decisionale: quali servizi sono così critici da giustificare un livello di servizio superiore? Quali rischi vengono accettati? Quali debiti tecnici (Technical Debt) impediscono il raggiungimento di un valore obiettivo e quanto costa la loro eliminazione?

Logica di implementazione: in 6 passaggi fino a SLA, OLA e KPI vincolanti

Un errore tipico è il „Big Bang“: prima definire tutto, poi distribuire. In pratica un approccio iterativo è più stabile, se dalla prima fase integra anche la governance.

1. Selezionare il portfolio di servizi: Iniziate con 10–20 servizi realmente rilevanti (processi aziendali critici, incidenti frequenti, rilevanza normativa).
2. Assegnare l’ownership: Per ogni servizio nominate un Service-Owner con mandato decisionale, oltre ai responsabili di esercizio e ai gruppi di risoluzione.
3. Assicurare la misurabilità: Per servizio definite 3–5 KPI, stabilite le fonti dati, create schede dati KPI e definite la retention.
4. Definire il kit SLA: 2–4 livelli di servizio con chiare finestre di misurazione, orari di servizio, obiettivi di reazione/risoluzione e obblighi di comunicazione.
5. Stipulare OLA lungo le dipendenze: Per ogni valore rilevante per l’SLA devono esistere impegni interni adeguati (inclusi on-call e passaggi di consegne).
6. Stabilire il ritmo di governance: Cicli di revisione, processo di eccezione, reporting, monitoraggio delle azioni. Solo allora scalate su ulteriori servizi.

Importante: ogni fase fornisce un valore operativo. Già dopo il passo 3 potete prendere decisioni migliori, perché misurazione e responsabilità sono stabilite.

Checklist: domande di governance che dovete rispondere per ogni servizio

Questa checklist è volutamente formulata in modo vicino ad audit e operatività. Se qui potete rispondere „sì“, siete molto più vicini alla vincolatività rispetto a molte organizzazioni con documenti estesi ma inefficaci.

• Esiste un Service-Owner nominato con mandato decisionale (budget, priorità, eccezioni)?
• I valori SLA sono definiti in modo da essere tecnicamente misurabili (punto di misurazione, finestra di misurazione, esclusioni)?
• Per ogni valore SLA esiste una fonte dati e un calcolo documentato?
• Esistono OLA per tutte le dipendenze rilevanti (inclusa la reperibilità, i passaggi di consegna, le modifiche standard)?
• La prioritizzazione degli incidenti è chiara e implementata in modo coerente in ITSM/Monitoring?
• Esistono finestre di manutenzione definite e un processo di change tracciabile?
• I report KPI sono archiviati con versioning e i dati grezzi sono disponibili per un periodo sufficientemente lungo?
• Esiste un processo di eccezione con scadenza, accettazione del rischio e piano d’azione?
• Esiste un ritmo di review fisso con decisioni e compiti documentati?
• I requisiti di sicurezza e compliance sono ancorati nel catalogo servizi (logging, accesso, patch, evidenze)?

Conflitti tipici e come la governance li risolve

La governance del catalogo servizi è anche gestione dei conflitti con regole chiare. Tre conflitti ricorrenti possono essere attenuati con meccanismi netti:

Conflitto 1: „Wir brauchen 24/7“ vs. capacità reale di erogazione

Soluzione: kit SLA con logica costi/capacità e meccanismo di eccezione formalizzato. Se si richiede il 24/7 deve essere chiaro quale catena on-call, quale ridondanza e quali test vengono finanziati. Senza questa catena il 24/7 è solo un’etichetta.

Conflitto 2: „KPI sieht gut aus“ vs. Nutzer klagen

Soluzione: verificare il punto di misura (End-to-End invece che infrastruttura), percentili invece della media, transazioni sintetiche. La governance impone di definire cosa significhi „il servizio funziona“.

Conflitto 3: „Questo è un problema di piattaforma“ vs. „questo è un problema di servizio“

Soluzione: catena OLA e gruppi di Resolver con passaggi chiari. Le escalation non passano tramite persone, ma attraverso confini di responsabilità e scadenze definiti.

Conclusione: il carattere vincolante nasce da misurabilità, responsabilità decisionale e dimostrazione

SLA, OLA e KPI non diventano vincolanti solo perché compaiono in un documento. Diventano vincolanti quando la governance del catalogo dei servizi collega coerentemente tre elementi: definizioni misurabili (incluse le fonti dati e il calcolo), responsabilità con potere decisionale (Service-Owner con mandato e catena di fornitura OLA) e controllo dimostrabile (versionamento, revisioni, processo di eccezione, audit trail).

Se iniziate in modo pragmatico, con un portafoglio di servizi ben delimitato e un chiaro modello di misurazione e ruoli, si genera rapidamente un effetto: meno discussioni sui numeri, maggiore focus sulle azioni. Ed è proprio questa la differenza tra un „catalogo dei servizi“ e un catalogo dei servizi che sostiene realmente l’esercizio, la conformità e la gestione.

Per questo tema sono importanti anche IT-Service-Management e i percorsi di escalation. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.