Service‑Level‑Matrix erstellen
Facility Management: Methoden » Kaufmännisches FM » Vertragsmanagement & Vereinbarungen » Service‑Level‑Matrix erstellen
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
- Ziel der Methode
- Anwendungsbereich
- Ausgangssituation
- Voraussetzungen
- Daten
- Rollen
- Schritt-für-Schritt mit Zeit-
- Ergebnisse
- Vorteile
- Grenzen
- Einsatz
- Verweise
- Tools
- Beispielhafte SLA‑Matrix‑Struktur
- KPI‑Tabelle
- Praktische Aktionsschritte & Pilot‑Checkliste
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).
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.
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.
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).
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]
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
KPI/Reporting als Nachweisdokumentation und Steuerungskonzept im FM. (organisation.fm-connect.com)
Vertragsdokumente/Verträge (SLA‑Anhänge als Vertragsbestandteil, Standardisierung). (docs.fm-connect.com)
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 |
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



