Service-Katalog-Governance: Wie man SLAs, OLAs und KPIs verbindlich macht

Eine funktionierende Service-Katalog-Governance entscheidet in der Praxis darüber, ob Serviceversprechen belastbar steuerbar sind oder ob sie im Tagesgeschäft zu Diskussionen, Eskalationen und Audit-Findings führen. Viele Organisationen haben zwar einen Servicekatalog im Tool oder im Wiki, aber keine Verbindlichkeit: SLAs sind nicht messbar definiert, OLAs sind nur „Team-Absprachen“ ohne Durchgriff, KPIs werden nach Bauchgefühl berichtet oder lassen sich im Audit nicht belegen.

In diesem Beitrag geht es nicht um ITIL-Begriffe als Selbstzweck, sondern um umsetzbare Governance-Mechanik: Welche Inhalte ein Servicekatalog zwingend braucht, wie SLAs (Service Level Agreements, also kundenseitige Servicezusagen) und OLAs (Operational Level Agreements, also interne Lieferzusagen zwischen Teams) zueinander passen, wie KPIs (Key Performance Indicators, messbare Steuerungskennzahlen) so definiert werden, dass Monitoring, Ticketing und Reporting dieselbe Sprache sprechen – und wie Sie das Ganze revisionstauglich machen.

Der Zielzustand ist klar: Eine IT-Leitung kann Services priorisieren und budgetieren, der Betrieb kann sauber eskalieren, Security und Compliance können Nachweise führen, und die Geschäftsführung bekommt belastbare Berichte statt interpretierter Ampeln.

Warum „definiert“ nicht gleich „verbindlich“ ist

Verbindlichkeit entsteht erst, wenn ein Serviceversprechen entscheidungsfähig ist: Es muss eindeutig sein, messbar, einem Owner zugeordnet, mit realistischen Abhängigkeiten hinterlegt und in ein Change- und Reporting-Regime eingebunden. Sonst passiert im Alltag typischerweise Folgendes:

• SLA-Inflation: Fachbereiche fordern „99,9% Verfügbarkeit“ oder „24/7 Support“ als Standard. Ohne Kosten- und Risikomodell wird zugesagt, was später nicht gehalten werden kann.
• OLA-Lücken: Der Service-Owner „verkauft“ ein SLA, aber die internen Teams haben keine verbindlichen Reaktions- und Lieferzeiten, keine Rufbereitschaftsregel, keine Kapazitätszusage.
• KPI-Theater: KPIs sind vorhanden, aber Quelle, Berechnungslogik und Scope sind unklar. Im Audit oder bei Eskalationen ist nicht nachvollziehbar, wie Zahlen zustande kommen.
• Tool-Widersprüche: Monitoring misst etwas anderes als das Ticket-System, und Reporting misst wieder etwas anderes. Diskussionen drehen sich dann um Daten statt um Maßnahmen.

Service-Katalog-Governance ist daher weniger „Dokumentation“, sondern ein Steuerungs- und Nachweisrahmen: Wer entscheidet was, auf Basis welcher Daten, mit welchen Konsequenzen bei Abweichung.

Begriffe sauber trennen: SLA, OLA und KPI im Betriebszusammenhang

Die häufigste Ursache für Unschärfe ist eine falsche Ebenenlogik. Eine praxistaugliche Trennung sieht so aus:

• SLA (Service Level Agreement): Vereinbarung zwischen IT (oder IT-Dienstleister) und „Kunde“ (Fachbereich, Tochtergesellschaft, externe Kunden). Inhalt: Servicezeiten, Verfügbarkeit, Supportkanäle, Reaktions- und Lösungsziele, Wartungsfenster, Kommunikationspflichten, Verantwortlichkeiten, Ausnahmen.
• OLA (Operational Level Agreement): Interne Vereinbarung zwischen Teams/Einheiten, die das SLA ermöglichen (z. B. Plattform-Team, Netzwerk, Datenbank, Security Operations). Inhalt: interne Reaktionszeiten, Übergaben, Betriebsaufgaben, Abnahmebedingungen, Bereitschaften, Abhängigkeiten, technische Mindeststandards.
• KPI: Kennzahl zur Steuerung und zum Nachweis. Ein KPI ist nicht automatisch ein SLA-Kriterium. Manche KPIs sind „frühwarnend“ (z. B. Change-Failure-Rate), andere sind „vertraglich“ (z. B. Verfügbarkeit im SLA-Messfenster).

Wichtig: Ein SLA ist eine Zusage. Ein OLA ist eine Lieferfähigkeit. KPIs sind die Messung. Governance verbindet alle drei über Rollen, Datenquellen, Versionierung, Eskalation und Korrekturmaßnahmen.

Service-Katalog-Governance als Entscheidungs- und Kontrollsystem

Wenn Sie den Servicekatalog als Governance-Instrument aufsetzen, sollten Sie ihn nicht als Liste von „Dingen, die IT macht“ behandeln, sondern als kontrolliertes Inventar von Services mit definiertem Lebenszyklus. Die Kernfragen lauten:

• Welche Services sind offiziell? („Katalogfähig“ mit Owner, Lifecycle, Kostenmodell, Risiken)
• Welche Service-Level gibt es wirklich? (Standard, erweitert, kritisch – mit Bedingungen und Preisen/CapEx/OpEx-Zuordnung)
• Wie wird gemessen? (Monitoring-Quelle, Berechnungslogik, Scope, Datenqualität)
• Wie wird entschieden? (Genehmigung von SLA-Ausnahmen, Priorisierung von Verbesserungen, Investitionsentscheidungen)
• Wie wird nachgewiesen? (Audit-Trail, Versionen, Evidence, Reports, Maßnahmenverfolgung)

Diese Logik entlastet den Betrieb: Eskalationen werden weniger „persönlich“, weil sie gegen definierte Kriterien laufen. Gleichzeitig wird Compliance handhabbar, weil Nachweise aus einem kontrollierten System kommen statt aus ad-hoc zusammengesuchten Screenshots.

Die Mindestinhalte eines auditfähigen Servicekatalog-Eintrags

Ein Servicekatalog-Eintrag muss so vollständig sein, dass ein neuer Verantwortlicher (oder Auditor) den Service ohne implizites Wissen einordnen kann. In der Praxis haben sich Pflichtfelder bewährt, die sich in Tools (ITSM, CMDB) oder in einer zentralen Dokumentationsstruktur abbilden lassen.

Pflichtfelder (kompakt, aber vollständig)

• Service-Name und Zweck: Was unterstützt der Service im Unternehmen, für wen, mit welcher Abgrenzung?
• Service-Owner: fachlich verantwortlich für Service-Level, Priorisierung, Budget-/Risikoentscheidungen (nicht nur „Teamleiter Betrieb“).
• Technischer Owner / Betriebsverantwortung: wer betreibt, wer ändert, wer genehmigt Notfallmaßnahmen.
• Service-Kritikalität: Business-Impact-Klasse (z. B. finanziell, regulatorisch, sicherheitskritisch) mit klaren Kriterien.
• Servicezeiten und Supportkanäle: z. B. 8×5/12×5/24×7, Incident-Kanal, Major-Incident-Pfad.
• SLA-Bausteine: Verfügbarkeit (Definition!), Reaktions-/Lösungsziele, Wartungsfenster, Kommunikationspflichten.
• Abhängigkeiten: interne Plattformen, Identity, Netzwerk, externe Provider; jeweils mit OLA-Referenz.
• Messkonzept: Datenquellen, Berechnung, Messpunkte, Ausschlüsse, Datenaufbewahrung (für Audit).
• Security- und Compliance-Anforderungen: z. B. Logging, Aufbewahrung, Zugriffskontrollen, Verschlüsselung, Patch-Zyklen, Schwachstellenmanagement.
• Change-/Release-Regeln: Standardänderungen vs. riskante Changes, CAB/Change Advisory Board (Gremium für Change-Freigaben) oder alternative Freigabelogik.
• Lifecycle: Einführung, Betrieb, Sunset/Abkündigung, Migrationspfad.

Wer hier bewusst „zu viel“ findet: Genau diese Informationen werden in Eskalationen ohnehin abgefragt. Governance heißt, sie vorher strukturiert vorzuhalten.

SLAs so formulieren, dass sie messbar und verhandelbar sind

Viele SLA-Texte sind juristisch oder organisatorisch formuliert, aber technisch nicht messbar. Das führt zu Streit in zwei Situationen: bei Nichterfüllung und im Audit. Ein belastbares SLA braucht daher definierte Messfenster, klare Systemgrenzen und eine transparente Berechnung.

Typische SLA-Komponenten und ihre Stolperfallen

• Verfügbarkeit: Definieren Sie „Service up“ als messbaren Zustand (z. B. erfolgreiche synthetische Transaktion, API-Health-Check, Login möglich) und klären Sie, ob Wartungsfenster ausgenommen sind. Vermeiden Sie reine Infrastrukturmetriken (z. B. „Server erreichbar“) als Serviceverfügbarkeit.
• Performance: Wenn Performance SLA-relevant ist, muss klar sein: Messpunkt (Client, Edge, Backend), Perzentil (z. B. p95), Zeitraum, Ausschlüsse (z. B. Lastspitzen durch genehmigte Massenläufe).
• Incident-Reaktion und -Lösung: Reaktionszeit ist nicht gleich Lösungszeit. Definieren Sie Startzeitpunkte (Ticket-Eingang? Alarm?), Statuswechsel im ITSM und Regeln bei fehlenden Informationen.
• Wartungsfenster und Changes: Governance braucht eine klare Policy: Wer genehmigt, wie wird angekündigt, wie wird zurückgerollt, welche Nachweise entstehen.
• Kommunikation: Gerade bei kritischen Services ist eine Kommunikations-SLA oft genauso wichtig wie technische Werte: Wer informiert wen, über welchen Kanal, mit welchem Takt bei Major Incidents.

Entscheidungshilfe: SLA-Level als Produkt, nicht als Wunschliste

Statt pro Service jedes Mal neu zu verhandeln, bewährt sich ein Baukasten aus 2–4 SLA-Leveln (z. B. Standard, Erweitert, Kritisch). Die Governance-Regel ist: Abweichungen sind möglich, aber genehmigungspflichtig und müssen Kosten/Risiko transparent machen. Das verhindert „Schatten-SLAs“ per E-Mail.

OLAs als Lieferkette: interne Zusagen entlang der Abhängigkeiten

OLAs werden oft unterschätzt, sind aber der eigentliche Hebel für Verbindlichkeit. Denn ein Service-Owner kann ein SLA nur dann verantworten, wenn die internen Teams ihre Beiträge zugesagt haben. Praktisch heißt das: Jeder Service braucht eine Abhängigkeitskarte mit klaren internen Lieferzusagen.

Was in ein OLA gehört (und was nicht)

• Reaktions- und Bearbeitungsziele: z. B. „DBA reagiert innerhalb von 30 Minuten bei P1“ (mit definiertem P1-Kriterium).
• Bereitschaftsregelung: On-Call, Eskalationsstufen, Stellvertretung.
• Übergabepunkte: wann ein Ticket/Incident „übergeben“ gilt, welche Informationen Pflicht sind (Runbook-Link, Logs, Metriken).
• Standard-Changes: was darf ohne CAB, mit welchen Vorbedingungen, und welche Evidence wird erzeugt (Change-Ticket, Peer-Review, Backout-Plan).
• Kapazitäts- und Wartungszusagen: Patch-Fenster, Lifecycle von Plattformkomponenten, End-of-Life-Prozesse.

Nicht in ein OLA gehören: unkonkrete Ziele („zeitnah“), technische Wunschlisten ohne Betriebspfad oder Abhängigkeiten ohne Verantwortlichen. OLA-Texte sind Arbeitsverträge zwischen Teams – sie müssen im Betrieb funktionieren.

KPIs: Von der Kennzahl zur Steuerung (und zum Audit-Nachweis)

KPIs machen nur dann Sinn, wenn sie Entscheidungen beeinflussen. Im Kontext Service-Katalog-Governance unterscheiden sich drei Klassen:

• SLA-KPIs (vertraglich): z. B. Verfügbarkeit im Messfenster, Einhaltung Reaktions-/Lösungsziele je Priorität.
• Betriebs-KPIs (steuernd): z. B. Incident-Volumen pro Service, Wiederholer-Incidents, Change-Failure-Rate, Mean Time to Restore (MTTR).
• Compliance-/Security-KPIs (kontrollierend): z. B. Patch-Compliance, Logging-Abdeckung, Berechtigungsreviews termingerecht, Schwachstellenbehebungsfristen je Kritikalität.

Eine wichtige Governance-Regel: Jeder KPI braucht ein Datenblatt. Ohne KPI-Datenblatt wird Reporting zur Interpretationsfrage. Ein KPI-Datenblatt umfasst mindestens Definition, Berechnung, Datenquelle, Messfrequenz, Verantwortliche, Zielwert/Schwellwerte, und Umgang mit Datenlücken.

Messkonzept: Datenquellen, Berechnung und Beweisfähigkeit

Verbindlichkeit scheitert häufig nicht am Willen, sondern an inkonsistenten Daten. Ein Messkonzept ist daher Pflicht – besonders, wenn SLAs im Streitfall oder im Audit belastbar sein müssen.

Praktische Leitplanken für ein belastbares Messkonzept

• Single Source of Truth pro KPI: Legen Sie fest, welches System die Quelle ist (Monitoring, ITSM, Log-Analytics). Mischwerte ohne klare Regel sind angreifbar.
• Zeitsynchronisation: Einheitliche Zeitbasis (NTP), definierte Zeitzonen, klare Zuordnung von Ereignissen (Incident Start/Ende).
• Messpunkt-Disziplin: Serviceverfügbarkeit über Service-Checks (synthetische Transaktionen) ist aussagekräftiger als Host-Pings.
• Datenaufbewahrung: Für Audit und Trendanalysen müssen Rohdaten ausreichend lange verfügbar sein (Log-Retention, Metriken, Tickets).
• Ausnahmen dokumentieren: Wartungsfenster, Force Majeure, vom Business genehmigte Downtimes: alles muss versioniert und nachweisbar sein.

Wenn Sie Policies oder Prüfschritte standardisieren wollen, hilft eine kurze, kopierbare Vorlage. Beispiel für eine interne Policy-Struktur (kein Tool-spezifischer Inhalt, aber als Kontrollliste nutzbar):

POLICY: KPI- und SLA-Messbarkeit (Kurzstandard)

1) Jeder SLA-Wert hat:
   - Messfenster (Zeiten, Tage)
   - Messpunkt (synthetischer Check / API / Endpunkt)
   - Definition „erfüllt/nicht erfüllt“
   - Regel für Wartungsfenster und genehmigte Downtime

2) Jeder KPI hat ein Datenblatt:
   - KPI-Name, Zweck, Owner
   - Berechnungsformel
   - Primärdatenquelle (System + Datensatz)
   - Messfrequenz und Reportfrequenz
   - Zielwert/Schwellwerte + Eskalationsregel
   - Datenqualitätscheck (fehlende Werte, Duplikate)

3) Nachweisbarkeit:
   - Rohdaten-Retention (mindestens X Monate nach interner Vorgabe)
   - Report-Versionierung (Monatsreport nicht nachträglich überschreiben)
   - Audit-Trail für Ausnahmen (Change-/Maintenance-Freigaben)

Rollen, Verantwortlichkeiten und Eskalation: ohne RACI keine Governance

In der Praxis wird Governance greifbar, wenn Verantwortlichkeiten nicht nur benannt, sondern entscheidungswirksam sind. Dafür eignet sich eine RACI-Logik: Responsible (ausführend), Accountable (rechenschaftspflichtig), Consulted (einzubinden), Informed (zu informieren).

Minimaler Rollensatz für Service-Katalog-Governance

• Service-Owner (Accountable): verantwortet SLA-Zusagen, Priorisierung, Budget-/Risikothemen, Ausnahmegenehmigungen.
• Operations Owner / Betriebsverantwortlicher (Responsible): stellt Runbooks, Monitoring, On-Call-Prozesse und Incident-Response sicher.
• Resolver Groups (Responsible): Fachteams (Netzwerk, DB, Plattform), die OLAs liefern.
• Security/Compliance (Consulted/Control): definiert Nachweis- und Kontrollanforderungen, prüft KPI- und Logging-Qualität, begleitet Audits.
• Service Management / ITSM-Funktion (Responsible): betreibt Katalogprozess, Versionierung, Review-Zyklen, Reporting-Standards.

Ohne diese Rollen wird jede Eskalation zu einem Organisationsproblem. Mit klaren Rollen wird sie zu einem Prozessproblem – und damit lösbar.

Governance-Mechaniken: Versionierung, Review-Zyklen und Ausnahmeprozesse

Damit SLAs/OLAs/KPIs verbindlich bleiben, brauchen Sie Mechaniken, die Änderungen kontrollieren und veraltene Zusagen verhindern. Drei Elemente sind besonders wirksam:

1) Versionierung mit Gültigkeitsdatum

Jede SLA-/OLA-Version muss ein Gültigkeitsdatum und einen Änderungsgrund haben. Wichtig ist nicht „Papier“, sondern Nachvollziehbarkeit: Welche Regeln galten, als ein Incident passierte?

2) Regelmäßige Reviews (nicht nur bei Problemen)

Ein sinnvoller Takt ist abhängig von Service-Kritikalität: kritische Services häufiger, Standardservices seltener. Ein Review umfasst mindestens: KPI-Trends, Major Incidents, wiederkehrende Störungen, Change-Qualität, Capacity/Backlog, Security Findings. Der Output sollte immer Entscheidungen enthalten (beheben, akzeptieren, investieren, de-scope).

3) Ausnahmeprozess mit Risiko- und Kostenlogik

Ausnahmen sind normal: ein Fachbereich will höheres Service-Level, ein Legacy-System kann bestimmte Werte nicht erreichen, ein Provider limitiert. Verbindlich wird es, wenn Ausnahmen formal erfasst sind: befristet, begründet, genehmigt, mit Maßnahmenplan oder bewusster Risikoakzeptanz.

Eine praxistaugliche Ausnahmevorlage als kopierbarer Block:

VORLAGE: SLA/OLA-Ausnahme (Kurzformular)

- Betroffener Service:
- Betroffener Wert (SLA/OLA/KPI):
- Abweichung (Ist vs. Soll):
- Begründung (technisch/organisatorisch):
- Business-Auswirkung bei Beibehaltung:
- Risiko-Einschätzung (z. B. Verfügbarkeit, Security, Compliance):
- Kompensationsmaßnahmen (Monitoring, Fallback, Kommunikation):
- Befristung (bis Datum) und Review-Termin:
- Genehmiger (Service-Owner + ggf. Compliance/Security):

Audit-Perspektive: Welche Nachweise typischerweise fehlen

Audits (intern oder extern) prüfen selten nur, ob ein Dokument existiert. Sie prüfen, ob die Organisation steuert und nachweisen kann. Typische Lücken in SLA/OLA/KPI-Governance sind:

• Kein konsistenter Audit-Trail: Reports werden nachträglich geändert, Ausnahmen sind nicht versioniert, Wartungsfenster sind nicht nachvollziehbar.
• Unklare Datenherkunft: KPI-Werte sind „aus dem Dashboard“, aber Rohdaten, Abfragen oder Berechnungsregeln fehlen.
• Fehlende Verantwortlichkeit: Service-Owner ist nicht benannt oder hat keine Entscheidungsrechte (Budget, Priorisierung, Ausnahmegenehmigung).
• Kontrollen ohne Follow-up: Findings werden dokumentiert, aber Maßnahmen nicht verfolgt (kein Ownership, keine Fristen, kein Wirksamkeitsnachweis).
• Scope-Verwechslungen: Infrastrukturkomponenten werden als Service verkauft, ohne End-to-End-Sicht (Identity, Netzwerkpfade, externe Abhängigkeiten).

Wenn Sie auditfähig werden wollen, denken Sie in Artefakten: versionierte SLA/OLA-Dokumente, KPI-Datenblätter, Ticketverknüpfungen, Change-Freigaben, Major-Incident-Reports, Nachweise zu Reviews und Maßnahmenlisten.

Kosten und Kapazität: Warum Service-Level immer ein Betriebsmodell braucht

Service-Level sind nicht nur „Ziele“, sondern binden Kapazität: Rufbereitschaft, Redundanz, Monitoring, Testaufwand, Ersatzteil- und Lizenzkosten, Provider-Verträge, Security-Kontrollen. Governance muss diese Verbindung sichtbar machen, sonst werden SLAs zur impliziten Budgetzusage.

Konkrete Kostentreiber, die in SLA-Entscheidungen gehören

• On-Call und 24/7-Fähigkeit: personelle Abdeckung, Eskalationsketten, Runbooks, Training.
• Redundanz und Failover: zusätzliche Infrastruktur, Betriebskomplexität, regelmäßige Tests (Failover-Proben).
• Monitoring und Observability: synthetische Checks, Log-Retention, Alarmierung, SLO-/SLA-Reporting.
• Change-Sicherheit: Staging-Umgebungen, Rollback-Mechanismen, Freigabeprozesse, Automatisierung.
• Security/Compliance: härtere Kontrollen (z. B. strengere Logging- und Reviewpflichten) erhöhen Aufwand, senken aber Risiko.

Eine IT-Leitung braucht hier Entscheidungsklarheit: Welche Services sind so kritisch, dass sich ein höheres Service-Level lohnt? Welche Risiken werden akzeptiert? Welche technischen Schulden (Technical Debt) verhindern das Erreichen eines Zielwerts, und was kostet die Beseitigung?

Implementierungslogik: In 6 Schritten zu verbindlichen SLAs, OLAs und KPIs

Ein typischer Fehler ist der „Big Bang“: erst alles definieren, dann ausrollen. In der Praxis ist ein iteratives Vorgehen stabiler, wenn es Governance von Anfang an mitliefert.

1. Service-Portfolio schneiden: Starten Sie mit 10–20 Services, die wirklich relevant sind (kritische Geschäftsprozesse, häufige Incidents, regulatorische Relevanz).
2. Ownership festlegen: Pro Service einen Service-Owner mit Entscheidungsmandat benennen, plus Betriebsverantwortliche und Resolver Groups.
3. Messbarkeit herstellen: Pro Service 3–5 KPIs definieren, Datenquellen festlegen, KPI-Datenblätter erstellen, Retention klären.
4. SLA-Baukasten definieren: 2–4 Service-Level mit klaren Messfenstern, Servicezeiten, Reaktions-/Lösungszielen und Kommunikationspflichten.
5. OLAs entlang der Abhängigkeiten schließen: Für jeden SLA-relevanten Wert muss es passende interne Zusagen geben (inkl. On-Call und Übergaben).
6. Governance-Takt etablieren: Review-Zyklen, Ausnahmeprozess, Reporting, Maßnahmenverfolgung. Erst dann skalieren Sie auf weitere Services.

Wichtig: Jede Stufe liefert einen operativen Nutzen. Schon nach Schritt 3 können Sie bessere Entscheidungen treffen, weil Messung und Verantwortlichkeit stehen.

Checkliste: Governance-Fragen, die Sie pro Service beantworten sollten

Diese Checkliste ist bewusst audit- und betriebsnah formuliert. Wenn Sie hier „ja“ sagen können, sind Sie deutlich näher an Verbindlichkeit als viele Organisationen mit umfangreichen, aber wirkungslosen Dokumenten.

• Gibt es einen benannten Service-Owner mit Entscheidungsmandat (Budget, Prioritäten, Ausnahmen)?
• Sind SLA-Werte so definiert, dass sie technisch messbar sind (Messpunkt, Messfenster, Ausschlüsse)?
• Gibt es pro SLA-Wert eine Datenquelle und eine dokumentierte Berechnung?
• Sind OLAs für alle wesentlichen Abhängigkeiten vorhanden (inkl. Bereitschaft, Übergaben, Standard-Changes)?
• Ist die Incident-Priorisierung klar und in ITSM/Monitoring konsistent umgesetzt?
• Gibt es definierte Wartungsfenster und einen nachvollziehbaren Change-Prozess?
• Werden KPI-Reports versioniert abgelegt und sind Rohdaten ausreichend lange verfügbar?
• Existiert ein Ausnahmeprozess mit Befristung, Risikoakzeptanz und Maßnahmenplan?
• Gibt es einen festen Review-Takt mit dokumentierten Entscheidungen und Aufgaben?
• Sind Security- und Compliance-Anforderungen im Servicekatalog verankert (Logging, Zugriff, Patch, Nachweise)?

Typische Konflikte und wie Governance sie auflöst

Service-Katalog-Governance ist auch Konfliktmanagement mit klaren Regeln. Drei wiederkehrende Konflikte lassen sich mit sauberer Mechanik entschärfen:

Konflikt 1: „Wir brauchen 24/7“ vs. reale Lieferfähigkeit

Lösung: SLA-Baukasten mit Kosten-/Kapazitätslogik und formalisierter Ausnahme. Wenn 24/7 gefordert wird, muss klar sein, welche On-Call-Kette, welche Redundanz und welche Tests finanziert werden. Ohne diese Kette ist 24/7 nur ein Etikett.

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

Lösung: Messpunkt prüfen (End-to-End statt Infrastruktur), Perzentile statt Durchschnitt, synthetische Transaktionen. Governance zwingt zur Definition, was „Service funktioniert“ bedeutet.

Konflikt 3: „Das ist ein Plattformproblem“ vs. „das ist ein Serviceproblem“

Lösung: OLA-Kette und Resolver Groups mit klaren Übergaben. Eskalationen laufen nicht über Personen, sondern über definierte Verantwortungsgrenzen und Fristen.

Fazit: Verbindlichkeit entsteht durch Messbarkeit, Ownership und Nachweis

SLAs, OLAs und KPIs werden nicht dadurch verbindlich, dass sie in einem Dokument stehen. Sie werden verbindlich, wenn Ihre Service-Katalog-Governance drei Dinge konsequent verbindet: messbare Definitionen (inklusive Datenquellen und Berechnung), entscheidungsfähige Verantwortung (Service-Owner mit Mandat und OLA-Lieferkette) und nachweisbare Steuerung (Versionierung, Reviews, Ausnahmeprozess, Audit-Trail).

Wenn Sie pragmatisch starten, mit einem geschnittenen Service-Portfolio und einem klaren Mess- und Rollenmodell, entsteht schnell ein Effekt: weniger Diskussionen über Zahlen, mehr Fokus auf Maßnahmen. Und genau das ist der Unterschied zwischen einem „Servicekatalog“ und einem Servicekatalog, der Betrieb, Compliance und Management wirklich trägt.

Für dieses Thema sind auch It-Service-Management und Eskalationswege wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.