SLA-/XLA-Katalog: Service-Level und Nutzererlebniskennzahlen

Die Ausschreibung verwendet einen zweistufigen Katalog. Auf der ersten Stufe werden Standardservicefamilien mit Default-Zielwerten festgelegt. Auf der zweiten Stufe werden diese Zielwerte nach Gewerk, Anlagenkritikalität, Kalender, Redundanzkonzept und Nutzerwirkung präzisiert. Das zugrunde liegende Systemdesign erlaubt mehrere SLA-Objekte je Vorgang; damit werden Reaktion, Wiederherstellung, OLA-Handover und Experience parallel messbar. Für die Detailausprägung je Gewerk werden dieselben Regeln auf Elektroversorgung, HKLS, GA/GLT, Brandschutztechnik, Fördertechnik, Sanitär, Sondertechnik und Dokumentationsleistungen angewendet.

Die Katalogwerte sind Ausschreibungszielwerte. Die verwendeten Metriken beruhen auf service-level goals, Kalendern und Start-/Pause-/Stop-Bedingungen, auf mehreren parallel messbaren Task-SLAs pro Vorgang, auf SLA-Breach-Logiken sowie auf Service-Desk- und Experience-Metriken wie MTTR, First Call/First Assignment Resolution, Incident-SLA-Breach-Rate, CSAT, CES, NPS, User Sentiment und normalisierten 0–100-Erfahrungsscores. Planon beschreibt hierfür eine offene Integrationsarchitektur bis in Service Desk, Workflows und Arbeitsaufträge; ServiceNow beschreibt die parallele Erfassung von Service Desk, User Sentiment und DEX-Werten; Jira Service Management bildet Goals, Kalender und Bedingungen für Time-to-resolve und Arbeitsarten unmittelbar ab.

Die OLA-/RACI-Zuordnung sichert die Hinterlegung der internen Lieferkette für jeden SLA-/XLA-relevanten Prozessschritt. Die Tabelle bildet Verantwortlich, Unterstützend und Informiert ab; konsultative Einbindungen werden im Prozessdesign je Schnittstelle mitgeführt.

Zeitbasierte SLAs werden ausschließlich innerhalb des vertraglich festgelegten Servicekalenders gemessen, sofern die jeweilige Metrik nicht ausdrücklich als 24/7-Metrik definiert ist. Start, Pause und Stop werden systemisch gesteuert. Pausen- oder Ausschlussgründe sind nur zulässig für genehmigte Wartungsfenster, freigegebene Abschaltungen, fehlende Zutrittsfreigaben, vom Auftraggeber veranlasste Betriebsunterbrechungen oder dokumentierte Fremdursachen. Die Plattformlogik für SLA-Kalender, Zeitziele und Start-/Pause-/Stop-Bedingungen ist in marktüblichen Service-Management-Systemen vorgesehen; zudem wird MTTR häufig in Geschäftszeiten gemessen, sofern kein 24/7-Kalender hinterlegt ist.

Für diesen Anhang gelten folgende Berechnungsdefinitionen. Reaktionszeit ist die Zeit vom Eingang eines Tickets oder Alarms bis zur qualifizierten Annahme durch den zuständigen Bearbeiter. Servicewiederherstellungszeit ist die Zeit vom Eingang bis zur Wiederherstellung der betroffenen Funktion, auch bei temporärem Workaround. Behebungszeit ist die Zeit bis zur nachhaltigen technischen Erledigung und dokumentierten Lösung. Verfügbarkeit wird als Verhältnis aus nutzbarer Servicezeit zu vereinbarter Servicezeit gemessen; ersatzweise kann sie, wo technisch sinnvoll, als Funktion aus MTBF und MTTR geführt werden. MTTR ist im Sinne dieses Anhangs einheitlich als Restore-/Resolve-Zeit definiert, um die von Plattformen bekannte Mehrdeutigkeit des Begriffs auszuschließen. MTBF misst die Betriebszeit zwischen ungeplanten, behebbaren Ausfällen derselben Servicefamilie oder desselben Assets. Atlassian beschreibt die Mehrdeutigkeit der MTTR, die MTBF-Definition sowie die Availability-Formeln explizit.

Für XLA-Metriken gilt folgende Messlogik. CSAT wird transaktional nach Ticketabschluss erhoben; auf einer 1–5-Skala gelten die Werte 4 und 5 als positiv. CES misst den vom Nutzer wahrgenommenen Aufwand auf einer 1–5- oder 1–7-Skala; niedrige Werte sind günstig. NPS wird quartalsweise als relationale Kennzahl mit einer 0–10-Frage erhoben, wobei 9–10 als Promoter, 7–8 als Indifferente und 0–6 als Detraktoren zählen. Zusätzlich wird ein monatlicher XLA-Index auf 0–100 normiert. Für die Ausschreibung wird der XLA-Index standardmäßig mit 50 % CSAT, 20 % invers-normalisiertem CES, 20 % Reopen-free-Rate und 10 % Kommunikationsqualität gewichtet; die relationale NPS-Messung wird ergänzend und nicht ersetzend geführt. Qualtrics beschreibt die Skalen und Berechnungen von CSAT, CES und NPS; ServiceNow beschreibt die Normalisierung von Experience- und User-Sentiment-Werten auf 0–100.

Messdatenquellen sind hierarchisch festgelegt. Führend für Reaktions-, Restore- und Behebungszeiten sind die im Service Desk beziehungsweise CAFM erzeugten und auditierbaren Zeitstempel. Führend für Alarmbeginn und technische Ursache sind GLT-/BMS- beziehungsweise Quellsystemdaten, sofern eine automatische Ticketerzeugung oder Referenzierung erfolgt. Führend für Service- und Assetzuordnung sind Anlagenkataster, CI-/CMDB-Zuordnung und Servicefamilien. Führend für Vor-Ort-Erledigung und First-Time-Fix sind mobile Einsatz- oder Dispositionsdaten. Führend für XLA sind die über das Ticketsystem versendeten Umfragen. Planon beschreibt die offene Architektur bis in Service Desk, Arbeitsaufträge und die Anbindung von Smart-Building-Diagnosen; ServiceNow beschreibt auditierbare Tabellen, Incident-/Change-/Problem-Audits sowie CMDB-Health- und Relationship-Health-Mechaniken.

Datenqualität ist Freigabebedingung für die Wirksamkeit von SLA/XLA. Monatlich zu prüfen sind Pflichtfeldvollständigkeit, korrekte Priorität, korrekte Service- und CI-Zuordnung, konsistente Zeitstempel, Ausschlusscodes, Duplikatfreiheit und geschlossene Auditkette. Für CAFM-/CMDB-nahe Daten gilt ein Qualitätsgate aus Vollständigkeit, Richtigkeit und Compliance; Beziehungsdaten dürfen keine ungeklärten orphan-, stale- oder duplicate-Objekte oberhalb der festgelegten Grenzrate enthalten. ServiceNow führt CMDB-Health genau entlang Completeness, Correctness und Compliance sowie Relationship Health entlang orphan, stale und duplicate relationships.

Die operative Berichterstattung erfolgt in vier Takten. Erstens in Echtzeit als Leitstands- und Service-Desk-Dashboard mit offenen, gefährdeten und überfälligen Vorgängen. Zweitens täglich mit at-risk- und breach-orientierten Übersichten. Drittens wöchentlich mit Aging-, Backlog- und Maßnahmenlisten. Viertens monatlich mit verbindlichem SLA-/XLA-Report je Leistungsbereich, Gewerk und Priorität. Quartalsweise erfolgt zusätzlich ein Management-Review für Trends, Zielwertkalibrierung, strukturelle Schwachstellen und XLA-Entwicklung. ServiceNow beschreibt die automatische Generierung und Verteilung von Metrikreports, tägliche Schlüsselmetriken in SLA-Dashboards sowie auf tägliche, wöchentliche und monatliche Intervalle aggregierte Experience-Werte.

Ein SLA-Breach liegt vor, wenn der jeweilige Vorgang den zulässigen Zeitkorridor überschreitet. Für SLA-gebundene Incident- und OLA-Aufgaben wird dies systemisch über den Breach-Status beziehungsweise über elapsed percentage > 100 % nachvollzogen. Die Auswertung erfolgt mindestens nach Priorität, Kategorie, Assignment Group, Task-SLA und Breach-Status.

Die Eskalationsstufen wirken dual. Zeitlich lösen sie bei Nichteinhaltung der Schwellenwerte automatisch die nächste Stufe aus. Inhaltlich erzwingen sie jeweils einen zusätzlichen Steuerungsbeitrag: E1 steuert Aufnahme und Routing, E2 fachliche Diagnose und OLA-Aktivierung, E3 Ressourcen- und Prioritätsentscheidungen, E4 Auftraggeberabstimmung und Zielkonfliktlösung, E5 Sonderentscheidungen mit Betriebs-, Sicherheits- oder Managementrelevanz. Für P1-Ereignisse ist zusätzlich eine Parallelkommunikation an Betreiber-, Sicherheits- und Notfallrollen vorzusehen.

Der Audit- und Review-Prozess ist dreistufig. Im Monatsreview werden alle SLA-/XLA-Abweichungen, wiederkehrenden Incidents, Reopen-Fälle, Data-Quality-Defekte und offenen Maßnahmen bewertet. Im Quartalsreview werden Zielwerte, Schwellen, Survey-Fragen, Gewichtungen und Servicefamilien überprüft. Im Anlassfall-Audit werden Vorgänge stichprobenartig bis auf Ticket-, Audit-, GLT- und Arbeitsauftragsdatensatzebene nachvollzogen. Grundlage der Nachweisführung ist die Auditfunktion des Systems, die Änderungen auf auditing-enabled tables mitsamt Erstellung, Aktualisierung und Löschung nachvollziehbar hält.

Bonus- und Malusmechanik werden über eine monatliche Scorecard je Leistungsbereich wirksam. Die Scorecard gewichtet standardmäßig 70 % SLA-Erfüllung, 20 % XLA-Erfüllung und 10 % Datenqualität/Nachweisqualität. Kritische Pflichtverletzungen – insbesondere Fristversäumnisse bei gesetzlich gebundenen Leistungen, unbegründete P1-SLA-Verletzungen, manipulative Datenkorrekturen oder systematische Auditlücken – übersteuern jede positive Scorecard und schließen einen Bonus im betroffenen Zeitraum aus. Monetäre Ausgestaltung, Kappung und kumulative Anwendung werden im Vertragsteil separat festgelegt; dieser Anhang definiert ausschließlich die Logik, die Auslösebedingungen und die Zuordnung zum Leistungsbereich.

Ein Malus wird nur für zurechenbare Abweichungen ausgelöst. Nicht zurechenbar sind dokumentierte und freigegebene Wartungsfenster, fehlende Zutritte, nicht durch den Auftragnehmer verursachte Versorgungsunterbrechungen, Ereignisse aus höherer Gewalt, vom Auftraggeber angeordnete Prioritätsverschiebungen sowie Fälle, in denen die für die Metrik erforderliche Datenqualität im betreffenden Monat nicht erreicht wurde. Für jede abrechnungswirksame Abweichung ist die belastbare Nachweisführung aus Ticket, Auditlog, CI-/Asset-Zuordnung und Eskalationshistorie erforderlich.

Für die Start-up-Phase gilt eine abgestufte Wirksamkeit. Im ersten Betriebsmonat werden alle SLAs und XLAs im Shadow-Mode gemessen; abrechnungswirksam sind ausschließlich P1/P2-Notfall-, Sicherheits- und gesetzlich bindende Leistungen. Im zweiten und dritten Betriebsmonat gelten die zeitkritischen Betriebs-SLAs voll, Experience-Metriken und MTBF verbleiben noch in der Stabilisierung. Ab dem vierten Betriebsmonat gilt die volle Wirksamkeit für alle freigegebenen Leistungsbereiche. MTBF-basierte Zielwerte setzen zusätzlich eine belastbare Betriebsbaseline voraus; bis zu deren Freigabe werden nur Ist-Werte und Trends berichtet. Survey-basierte XLAs gelten erst, wenn je Leistungsbereich eine belastbare Mindeststichprobe erreicht ist; bis dahin wird ein rollierender Mehrmonatswert verwendet. Die TTS-Mobilisierung und Start-up-Logik sind im Konzept bereits als eigener Einführungs- und Übergabebaustein angelegt.

• die endgültige Servicefamilienstruktur je Gewerk, Bereich und Sonderanlage einschließlich CI-/Asset-Mapping

• die verbindliche Kritikalitätsmatrix P1 bis P4 je Service und je Anlagenklasse

• die Servicekalender, Bereitschaftszeiten, Feiertagslogiken und 24/7-Ausnahmen je Leistungsbereich

• die endgültigen Verfügbarkeitsziele je kritischer Medienversorgung, Redundanzgruppe und Komfortfunktion

• die Rückfallfenster und Ausschlussregeln für First-Time-Fix, Reopen und Wiederholstörungen

• die Mindeststichprobe, Versandlogik und Sprachfassungen der XLA-Umfragen sowie der finale Fragenkatalog für CSAT, CES und NPS

• die finale Gewichtung des XLA-Index je Leistungsbereich und die Entscheidung, ob NPS ausschließlich quartalsweise oder zusätzlich halbjährlich erhoben wird

• die Datenfeldliste für Pflichtfelder, Ausschlusscodes, Verantwortungskennzeichen und revisionssichere Freigabevermerke

• die finalen Schnittstellen, Feldmappings und Autoritäten zwischen CAFM, Service Desk, GLT/BMS, SAP/ERP, Telemetrie, Mobile Workforce und Herstellerportalen

• die Hersteller- und Drittleistungs-OLAs einschließlich Eskalationsrecht, Ersatzteilverfügbarkeit und Bereitschaftsmodellen

• die finale Scorecard-Gewichtung, Bonus-/Malus-Korridore, monetären Kappungen, Heilungsfristen und Regeln zur Saldierung mehrerer Teilbereiche

• die Dauer der abrechnungsfreien Phase sowie die Abnahmebedingungen für den Übergang in den Vollbetrieb

• die Rollenbezeichnungen und zeichnungsberechtigten Freigaben gemäß finalem Organigramm und Governance-Modell