Priorità, SLA ed escalation

Priorità, Severity e impatto sul business

Gravità (Severity)

La Severity riflette la gravità tecnica della condizione attuale.

Priorità (Priority)

La Priority riflette l’ordine di esecuzione dei lavori.

Severity e Priority non coincidono.

Ad esempio, un Issue può avere Severity = High insieme a Priority = P3.

Un caso simile è possibile quando il problema è tecnicamente serio ma riguarda un asset di riserva, senza impatto attuale sull’esercizio.

Punteggio integrale (Impact Score)

Per l’ordinamento può essere applicato un punteggio integrale:

dove:

• $S$ — severity;
• $B$ — impatto sul business;
• $A$ — numero o criticità degli asset interessati;
• $R$ — rischio per la sicurezza o rischio normativo;
• $D$ — durata.

Impatto sul business (Business Impact)

OHM supporta campi di impatto strutturati:

• numero di dispositivi interessati;
• numero di consumatori o di siti;
• volume di gas a rischio;
• durata del degrado;
• potenziale perdita di dati;
• rischio di misura commerciale errata;
• rischio di un intervento in campo;
• rischio di violazione dell’SLA;
• rischio per la sicurezza delle informazioni;
• costo del fermo;
• livello di impatto reputazionale.

Gestione del livello di servizio (SLA)

OHM realizza un modello completo di gestione degli SLA.

Il controllo si estende non solo alla risoluzione del problema, ma all’intero ciclo della sua gestione.

flowchart TD
  A["Issue creato"] --> B["Response SLA"]
  B --> C["Acknowledgement SLA"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]

Ogni fase ha le proprie regole di calcolo.

Politica SLA

La politica SLA definisce:

• il tempo di risposta consentito;
• il termine di presa in carico;
• il termine di risoluzione;
• il termine di verifica;
• le regole di escalation;
• il calendario lavorativo;
• le eccezioni.

L’SLA viene assegnato automaticamente in base al Canon, alla criticità e alla categoria dell’oggetto.

Calendari lavorativi

Il sistema supporta:

• 24×7;
• 12×7;
• giorni lavorativi;
• calendari regionali;
• giorni festivi;
• orari specifici dei singoli reparti.

Il tempo al di fuori del calendario lavorativo non viene conteggiato, salvo che la politica SLA richieda una risposta 24 ore su 24.

Timer SLA

Per ogni Issue il sistema calcola contemporaneamente più timer indipendenti.

Ad esempio:

• Time To Response;
• Time To Acknowledge;
• Time To Resolve;
• Time To Verify;
• Time To Close.

Ogni timer può avere le proprie regole di arresto.

Condizioni di sospensione

Il conteggio dell’SLA può essere sospeso.

Ad esempio:

• attesa del fornitore;
• attesa dell’accesso;
• attesa di un’autorizzazione;
• restrizioni stagionali;
• forza maggiore.

Il motivo della sospensione deve essere registrato.

Violazione dell’SLA

In caso di violazione dell’SLA il sistema automaticamente:

• cambia lo stato;
• aumenta il livello di rischio;
• attiva l’Escalation Engine;
• crea una registrazione di audit;
• riflette la violazione nei KPI.

Motore di escalation (Escalation Engine)

L’Escalation Engine trasferisce automaticamente il problema a un livello di responsabilità superiore quando le condizioni stabilite vengono violate.

L’escalation non dipende dalle azioni dell’utente e viene eseguita automaticamente.

Livelli di escalation

Uno scenario tipico:

flowchart TD
  P1["P1"] -->|"15 minuti"| L1["Capoturno"]
  L1 -->|"1 ora"| L2["Responsabile regionale"]
  L2 -->|"4 ore"| L3["Direttore operativo"]

Gli intervalli specifici sono definiti dalla politica dell’organizzazione.

Trigger di escalation

L’escalation può essere innescata da:

• una violazione del Response SLA;
• una violazione del Resolution SLA;
• l’assenza di un assegnatario;
• l’assenza della presa in carico;
• una riapertura;
• il carattere massivo;
• un Business Impact elevato.

Azioni di escalation

Al verificarsi della condizione il sistema può:

• notificare il responsabile;
• cambiare il proprietario;
• aumentare la Priority;
• creare un Massive Incident;
• creare un ticket esterno;
• informare l’alta direzione;
• avviare un’analisi aggiuntiva.

Tutte le azioni vengono registrate integralmente.

Cronologia delle escalation

La scheda dell’Issue contiene un registro completo:

La cronologia non viene mai eliminata ed è utilizzata nel calcolo dei KPI operativi.