Zum Inhalt springen
FM-Connect Chat

Hallo! Ich bin Ihr FM-Connect Chat-Assistent. Wie kann ich Ihnen helfen?

FM-Solutionmaker: Gemeinsam Facility Management neu denken

Service‑Level‑Matrix erstellen

Facility Management: Methoden » Kaufmännisches FM » Vertragsmanagement & Vereinbarungen » Service‑Level‑Matrix erstellen

Service Level Matrix im Facility Management strukturiert erstellen und anwenden

Service‑Level‑Matrix im Facility Management erstellen

Eine Service‑Level‑Matrix (SLM) übersetzt FM‑Leistungen in messbare, steuerbare Service Levels: Leistungsfamilien → Services → SLA‑Metriken → Zielwerte → Messmethodik → Eskalationsstufen → Reporting. Sie ist das Bindeglied zwischen Servicekatalog/Warengruppen, operativer Leistungserbringung (CAFM/Service Desk/IoT) und vertraglicher Steuerung (SLA‑Anhänge, Rahmenverträge) sowie Budget-/Leistungscontrolling (ERP).

FM‑Connect verankert KPI‑/Reporting‑ und Steuerungskonzepte als zentrale Nachweisdokumentation im FM und betont die Bedeutung klarer Definitionen, Datenquellen und Verantwortlichkeiten.

Ohne Datenqualität und Prozessdisziplin werden SLAs schnell zu „Papier‑KPIs“.

Leistungsstandards systematisch definieren

Einführung in die Methode

Eine Service‑Level‑Matrix ist eine standardisierte Tabelle bzw. ein Regelwerk, das für definierte FM‑Services die Service Levels festlegt: Welche Leistung wird wann, wo, in welcher Qualität, mit welcher Reaktions‑/Wiederherstellzeit und mit welcher Nachweislogik erbracht. Sie verbindet Servicekatalog (Leistungsbeschreibung) und KPI‑/Reporting‑System (Messung, Steuerung, kontinuierliche Verbesserung).

Im Gegensatz zu Einzel‑SLAs in Verträgen schafft eine SLM einen einheitlichen Standard über Standorte, Gewerke und Dienstleister hinweg. Sie ist damit ein zentraler Baustein von Operating‑Standards und Vertragsmanagement im FM (SLA‑Anhänge, Eskalationsroutinen, Service Credits/Bonus‑Malus – falls genutzt).

    • Eine Service-Level-Matrix, die Services mit KPIs, Zielwerten, Messmethoden, Datenquellen und Eskalationspfaden in Spalten übersichtlich darstellt und visuell unterscheidet.

Ziel ist eine umsetzbare, auditfähige und in Systeme übersetzbare Service‑Level‑Matrix, die:

  • Services eindeutig katalogisiert (Leistungsfamilien/Warengruppen/Servicekatalog)

  • für jeden Service SLA‑Metriken (KPIs), Zielwerte, Messmethoden, Datenquellen, Prüfintervalle und Eskalationen definiert

  • zwischen Vertrags‑SLA (geschuldete Leistung) und Operational‑SLA (interne Steuerung im Tagesgeschäft) differenziert

  • die Datenquellen und „System of Record“ (SoR) pro Kennzahl festlegt (CAFM/Service Desk/IoT/ERP/DMS)

  • als Grundlage für Reporting/Dashboards und kontinuierliche Verbesserung dient.

Strategisch passt das zu ISO‑Logik:

ISO 41014 betont Performance‑Indikatoren und Reviews als Bestandteil strategischer Steuerung; ISO 41001 verankert Managementsystem‑Denken und Nachweisfähigkeit.

Die Methode ist anwendbar für:

  • Betreiber/CREM: Standardisierung von Service Levels über Portfolio/Standorte

  • FM‑Dienstleister: SLA‑konforme Leistungserbringung, Reporting, Eskalationsmanagement

  • Öffentliche Auftraggeber: transparente, vergleichbare Leistungssteuerung und Nachweisführung

  • IT‑nahe FM‑Services: Service Desk, CAFM‑gestützte Prozesse, IoT‑basierte Performancewerte (z. B. Verfügbarkeit, Störungen, Energie-/Zustandssignale).

Typische Ausgangslagen:

  • SLAs existieren nur als Text in Verträgen, ohne messbare Definition/Datengrundlage

  • KPIs sind uneinheitlich (verschiedene Definitionen, unterschiedliche Messpunkte), Vergleichbarkeit fehlt

  • fehlende Zuordnung: welcher Service gehört zu welcher Warengruppe/Leistungsfamilie?

  • Datenquellen sind unklar oder unzuverlässig (Ticketzeiten, Asset‑Bezug, IoT‑Events, ERP‑Abrechnung)

  • Eskalationen erfolgen ad hoc statt standardisiert.

Datenqualität, Datenstruktur und Datenmanagement sind entscheidend; ohne diese Basis sind SLA‑Messungen nicht belastbar.

Voraussetzungen

  • Servicekatalog/Leistungsstruktur (Leistungsfamilien, Services, Warengruppen) – konkret unbestimmt, muss organisationsspezifisch festgelegt werden.

  • Prozessgrundlagen (z. B. Störung → Ticket → Dispatch → Rückmeldung → Abnahme) und klare Rollen.

  • Datenbasis und Datenpflege: Pflichtfelder, Objekt-/Asset‑IDs, Serviceklassifikation; Rollen.

  • Schnittstellenfähigkeit zwischen CAFM/Service Desk/IoT/ERP/DMS.

  • Governance‑Rahmen: SLA‑Owner und Review‑Rhythmus (monatlich/quartalsweise) definiert.

  • Rechtlicher Rahmen: wenn SLAs arbeits-/mitbestimmungsrelevant (z. B. Nutzertracking, mobile Apps), frühzeitig Mitbestimmung/Datenschutz klären (unbestimmt je Organisation).

    • Diagramm der fünf Voraussetzungen für ein Service-Management-System: Servicekatalog, Prozesse & Rollen, Datenbasis, Schnittstellen und Governance.

Benötigte Daten

  • Servicekatalogdaten: Service‑IDs, Leistungsfamilie, Geltungsbereich, Prioritäten

  • Ticket-/Service‑Desk‑Daten: Erfassungszeitpunkt, Priorität, Reaktionszeit, Lösungszeit, First Time Fix, Wiederholstörungen

  • CAFM/IWMS‑Daten: Objekt-/Raum-/Asset‑Bezug, Wartungs-/Auftragsstatus, Störhistorie

  • IoT/GLT‑Daten: Verfügbarkeit, Alarme, Zustände; Mapping Sensor→Asset (oft Engpass; unbestimmt in Qualität)

  • ERP/Controlling‑Daten: Abrechnungsregeln, Budgets, Kostenstellen, Rechnungen (für SLA‑Kosten-/Maluslogik, falls genutzt)

  • Vertrags-/DMS‑Daten: SLA‑Anhänge, Nachweise, Audit‑Trail‑Dokumente, Versionen

  • Data‑Quality‑Daten: Pflichtfeldverletzungen, Dubletten, Aktualität.

Organisatorische Rollen

  • SLA‑Owner (A): inhaltlich verantwortlich für KPI‑Set, Zielwerte, Eskalationslogik

  • Service Manager (R): operative Umsetzung, Messung, Review, Maßnahmensteuerung

  • Contract Owner / Contract Manager (R/C): Vertrags‑SLA, Service Credits/Bonus‑Malus (falls vorhanden), Nachweispflichten, Change Requests (teilweise unbestimmt)

  • FM‑Operator/Objektleitung (R): Leistungserbringung, Abnahmen, Mängelmanagement

  • Controlling (C): Kosten-/Budgetbezug, Rechnungs- und Abgrenzungslogik

  • IT/Integration Owner (R): Datenflüsse, APIs/ETL, Monitoring/Logging

  • Data Owner / Data Steward / Custodian (RACI nach GEFMA 430): Datenhoheit, Pflege, DQ‑Regeln Vorgehensstruktur

Schritt-für-Schritt mit Zeit- und Deliverable-Vorschlägen

Richtwerte; abhängig von Portfolio, Toollandschaft und Datenlage unbestimmt.

Phase 1 – Scope und Servicekatalog (1–2 Wochen) Deliverables:

  • Servicekatalog‑Liste (Leistungsfamilie → Service) inkl. Warengruppenbezug

  • Zielbild: Welche Services sollen vertraglich gesteuert werden vs intern (Operational).

Phase 2 – KPI-/SLA‑Definition (2–4 Wochen) Deliverables:

  • KPI Definitionen (Formel, Start-/Stop Zeitpunkte, Exceptions)

  • Zielwerte/Serviceprioritäten (z. B. Kritikalität, Nutzerimpact) unbestimmt

  • Messmethodik Dokument (Sampling, Prüfintervalle).

Phase 3 – SoR/Datenquellen & Integrationsmapping (2–6 Wochen) Deliverables:

  • SoR Matrix pro KPI (Ticketzeiten → Service Desk; Assetbezug → CAFM; Kosten → ERP; Verfügbarkeit → IoT)

  • DQ Regeln (Pflichtfelder, Validierung)

  • Schnittstellen-/Datenflusskonzept]

Phase 4 – Operationalisierung & Reporting (2–4 Wochen) Deliverables:

  • Reporting‑Template und Dashboard‑Layout

  • Eskalationsstufen (Ampellogik, Eskalationsketten, Service Reviews).

Phase 5 – Pilot & Rollout (4–12 Wochen) Deliverables:

  • Pilotbericht (validierte KPI‑Messbarkeit, DQ‑Issues, Anpassungen)

  • Rollout‑Wellenplan, Schulung (Service Desk, Operatoren, Contract Manager).

Erwartete Ergebnisse

  • Eine Service‑Level‑Matrix als verbindlicher Standard (vertraglich/operativ)

  • KPI‑Katalog mit Messmethoden, SoR‑Zuordnung, Eskalationslogik

  • Dashboards/Reports für Management und operative Teams

  • Stabiler Prozess zur SLA‑Steuerung (Review‑Meetings, Maßnahmenboard)

  • Höhere Vergleichbarkeit und höhere Auditfähigkeit durch standardisierte Definitionen und Nachweise

Vorteile der Methode

  • Vergleichbarkeit über Standorte/Dienstleister hinweg

  • Klare Priorisierung von Services (kritisch vs standard)

  • Weniger Konflikte über „Ist das SLA erfüllt?“ durch definierte Messregeln

  • Frühzeitige Eskalation statt ad‑hoc firefighting

  • Bessere Vertragssteuerung (SLA‑Anhänge, Abrechnungsregeln)

Grenzen der Methode

  • Datenqualität/Prozessdisziplin sind Voraussetzung; ohne saubere Ticket-/Asset‑Zuordnung sind KPIs unbrauchbar.

  • Integrationsaufwand kann hoch sein (CAFM↔SD↔IoT↔ERP); Schnittstellenbetrieb muss dauerhaft organisiert werden.

  • Zielwerte sind organisationsspezifisch und teils unbestimmt; Überambitionierte SLAs erhöhen Kosten und Rüge/Claim‑Risiko.

  • Bei öffentlichen Auftraggebern müssen SLA‑Kriterien vergabe- und nachweissicher in Leistungsbeschreibung und Wertung übersetzt werden.

Typische Einsatzbereiche

  • Störungsmanagement (Reaktionszeit/Wiederherstellzeit/First Time Fix)

  • Instandhaltung/Wartung (Planerfüllung, Überfälligkeiten, Anlagenverfügbarkeit)

  • Cleaning/IFM (Qualitätsscores, Mängelquote, Reaktionszeiten)

  • Service Desk (Erreichbarkeit, SLA‑Einhaltung, Ticketdurchlaufzeiten)

  • Kritische Infrastrukturen (hohe Priorität/strenge Eskalation)

  • IT‑nahe Services (SaaS/Managed) mit Verfügbarkeits‑SLAs und Audit‑Rights

Verweise

Vorlagenhinweise (Templates)

  • SLA‑Matrix‑Template

  • KPI‑Definition‑Template: KPI‑Name, Formel, Start/Stop, Ausnahmen, Datenquelle/SoR, Frequenz, Owner

  • RACI‑Template: SLA‑Owner, Service Manager, Contract Owner, Data Steward, IT, Operator

  • Reporting‑Template: Ampel, Trend, Root Cause, Maßnahme, Owner, Termin

  • Pilot‑Plan‑Template: Umfang, Testdaten, Abnahme, Lessons Learned

Beispielhafte SLA‑Matrix‑Struktur

Inhalte und Zielwerte sind unbestimmt und müssen je Organisation/Servicefamilie festgelegt werden.

Leistungsfamilie

Service

SLA Metrik

Zielwert

Messpunkt/Definition

Datenquelle (SoR)

Prüfintervall

Eskalation

TFM

Störungsbehebung

Reaktionszeit

unbestimmt

Ticket erstellt → Rückmeldung Einsatz

Service Desk

täglich/wöchentlich

Stufe 1–3

TFM

Anlagenverfügbarkeit

Verfügbarkeit

unbestimmt

uptime/(uptime+downtime)

IoT/GLT

monatlich

Stufe 1–3

IFM

Reinigung

Qualitätsquote

unbestimmt

Stichproben/Scorecard

CAFM/QM

monatlich

Stufe 1–2

Service Desk

Erreichbarkeit

Availability

unbestimmt

Telefon/Portal uptime

SD/Telephony

monatlich

Stufe 1–3

KFM

Rechnungsprüfung

Durchlaufzeit

unbestimmt

Eingang → Freigabe

ERP

monatlich

Stufe 1

KPI‑Tabelle (KPI, Definition, Data source, Frequency, Target)

KPI

Definition

Datenquelle

Frequenz

Ziel

Verfügbarkeit

uptime/(uptime+downtime)

IoT/GLT

monatlich

unbestimmt

Reaktionszeit

Ticketstart → Erstreaktion

Service Desk

wöchentlich

unbestimmt

Wiederherstellzeit

Ticketstart → Lösung

Service Desk/CAFM

wöchentlich

unbestimmt

First Time Fix

gelöst beim ersten Einsatz

CAFM/SD

monatlich

unbestimmt

Durchlaufzeit Auftrag

Auftrag start → Abschluss

CAFM

monatlich

unbestimmt

Qualitätsmängelquote

Mängel/Prüfungen

CAFM/QM

monatlich

unbestimmt

    • Eine visuelle Roadmap, die ein Pilotprojekt in zwei Phasen darstellt: Die Setup-Phase und die Pilotphase mit Datenanbindung und Dashboard-Go-live.

Sofortmaßnahmen (30 Tage)

  • Servicekatalog/Warengruppenliste finalisieren (unbestimmt)

  • Top 10 Services auswählen und KPI Definitionen festlegen

  • SoR Matrix je KPI definieren (SD/CAFM/IoT/ERP)

  • Eskalationslogik und Review Rhythmus festlegen

Pilot‑Checkliste

  • [ ] 1 Leistungsfamilie + 3–5 Services ausgewählt

  • [ ] KPI Definitionen und Messpunkte abgenommen

  • [ ] Datenquellen angeschlossen (SD/CAFM/IoT/ERP)

  • [ ] Pflichtfelder/DQ Regeln aktiv (Asset Bezug, Priorität, Zeitstempel)

  • [ ] Dashboard v1 live + wöchentlicher Review

  • [ ] Eskalationsstufen getestet (mind. ein Testfall)

  • [ ] Anpassungen dokumentiert, Rollout Wellenplan erstellt