Prioritäten, SLA und Eskalation

Priorität, Severity und Geschäftsauswirkung

Schweregrad (Severity)

Severity spiegelt die technische Schwere des aktuellen Zustands wider.

Priorität (Priority)

Priority spiegelt die Reihenfolge wider, in der die Arbeiten ausgeführt werden.

Severity und Priority sind nicht dasselbe.

Beispielsweise kann ein Issue Severity = High und gleichzeitig Priority = P3 aufweisen.

Ein solcher Fall ist möglich, wenn das Problem technisch schwerwiegend ist, aber ein Reserve-Asset betrifft und den Betrieb derzeit nicht beeinträchtigt.

Gesamtbewertung (Impact Score)

Für die Rangfolge kann eine Gesamtbewertung herangezogen werden:

wobei:

• $S$ — Schweregrad;
• $B$ — Geschäftsauswirkung;
• $A$ — Anzahl oder Kritikalität der betroffenen Assets;
• $R$ — Sicherheits- oder Regulierungsrisiko;
• $D$ — Dauer.

Geschäftsauswirkung (Business Impact)

OHM unterstützt strukturierte Felder zur Erfassung der Auswirkung:

• Anzahl der betroffenen Geräte;
• Anzahl der Verbraucher oder Standorte;
• gefährdetes Gasvolumen;
• Dauer der Degradation;
• möglicher Datenverlust;
• Risiko einer fehlerhaften Abrechnungsmessung;
• Risiko eines Vor-Ort-Einsatzes;
• Risiko einer SLA-Verletzung;
• Risiko für die Informationssicherheit;
• Ausfallkosten;
• Ausmaß des Reputationsschadens.

Steuerung des Servicelevels (SLA)

OHM setzt ein vollwertiges Modell zur SLA-Steuerung um.

Die Kontrolle erstreckt sich nicht nur auf die Behebung eines Problems, sondern auf dessen gesamten Bearbeitungszyklus.

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

Jede Phase hat eigene Berechnungsregeln.

SLA-Richtlinie (SLA Policy)

Die SLA-Richtlinie legt fest:

• die zulässige Reaktionszeit;
• die Bestätigungsfrist;
• die Behebungsfrist;
• die Verifizierungsfrist;
• die Eskalationsregeln;
• den Arbeitskalender;
• die Ausnahmen.

Das SLA wird automatisch anhand von Canon, Kritikalität und Objektkategorie zugewiesen.

Arbeitskalender

Das System unterstützt:

• 24×7;
• 12×7;
• Werktage;
• regionale Kalender;
• gesetzliche Feiertage;
• individuelle Zeitpläne einzelner Abteilungen.

Zeit außerhalb des Arbeitskalenders wird nicht angerechnet, sofern die SLA-Richtlinie keine Rund-um-die-Uhr-Reaktion verlangt.

SLA-Timer

Für jedes Issue berechnet das System mehrere unabhängige Timer gleichzeitig.

Zum Beispiel:

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

Jeder Timer kann eigene Stoppregeln haben.

Pausenbedingungen

Die SLA-Uhr kann angehalten werden.

Zum Beispiel:

• Warten auf einen Lieferanten;
• Warten auf Zutritt;
• Warten auf eine Freigabe;
• saisonale Einschränkungen;
• höhere Gewalt.

Der Grund für die Pause muss festgehalten werden.

SLA-Verletzung

Bei einer SLA-Verletzung führt das System automatisch folgende Schritte aus:

• Änderung des Zustands;
• Erhöhung der Risikostufe;
• Auslösung der Escalation Engine;
• Erstellung eines Audit-Eintrags;
• Abbildung der Verletzung in den KPI.

Eskalationsmechanismus (Escalation Engine)

Die Escalation Engine übergibt ein Problem automatisch an eine höhere Verantwortungsebene, sobald festgelegte Bedingungen verletzt werden.

Die Eskalation ist unabhängig von Benutzeraktionen und läuft automatisch ab.

Eskalationsstufen

Ein typisches Szenario:

flowchart TD
  P1["P1"] -->|"15 Minuten"| L1["Schichtleiter"]
  L1 -->|"1 Stunde"| L2["Regionalleiter"]
  L2 -->|"4 Stunden"| L3["Betriebsdirektor"]

Die konkreten Intervalle legt die Richtlinie der Organisation fest.

Eskalationsauslöser

Eine Eskalation kann ausgelöst werden durch:

• eine Verletzung des Response SLA;
• eine Verletzung des Resolution SLA;
• das Fehlen eines Bearbeiters;
• das Fehlen einer Bestätigung;
• eine Wiedereröffnung;
• eine massive Ausprägung;
• einen hohen Business Impact.

Eskalationsmaßnahmen

Ist eine Bedingung erfüllt, kann das System:

• den Vorgesetzten benachrichtigen;
• den Verantwortlichen wechseln;
• die Priority anheben;
• ein Massive Incident anlegen;
• ein externes Ticket anlegen;
• die Geschäftsleitung benachrichtigen;
• eine zusätzliche Analyse anstoßen.

Alle Aktionen werden vollständig protokolliert.

Eskalationshistorie

Die Issue-Karte enthält ein vollständiges Protokoll:

Die Historie wird niemals gelöscht und fließt in die Berechnung der betrieblichen KPI ein.