Service-KPIs im Maschinenbau: Was First-Time-Fix-Rate, MTTR und NPS wirklich aussagen

Serviceleiter im Maschinenbau messen heute fast immer die gleichen Kennzahlen — First-Time-Fix-Rate, Mean Time to Repair, Net Promoter Score. Aber die Zahlen wirken oft seltsam stabil: irgendwo zwischen „akzeptabel“ und „eigentlich zu niedrig“, ohne dass jemand erklären könnte, warum. Das Problem liegt selten an den KPIs selbst, sondern an der Datenbasis darunter.

Service-Kennzahlen sind nur so aussagekräftig wie die Daten, aus denen sie kommen. Werden FTFR und MTTR aus manuell zusammengetragenen Excel-Listen berechnet, mit unterschiedlichen Definitionen von „gelöst“ und ohne Drill-Down nach Anlagentyp oder Techniker, dann liefern sie ein Spiegelbild — aber keinen Hebel für Verbesserung. Wer KPIs wirklich nutzen will, braucht eine integrierte Datenbasis, in der jede Zahl auf eine konkrete Maschine, ein Ticket und eine Vertragsbeziehung zurückführbar ist.

• Problem: Fragmentierte Servicedaten — KPIs zeigen Symptome, aber liefern keine Drill-Down-Möglichkeit. Verbesserungs-Initiativen scheitern an fehlender Ursachenanalyse.
• Lösung: KPI-Architektur entlang des 4-Stufen-Modells — Daten digitalisieren, Systeme vernetzen, Entscheidungen mit Quellennachweis treffen.
• Ergebnis: FTFR und MTTR werden filterbar nach Anlagentyp, Region, Techniker. Wirtschaftliche KPIs wie Service-Marge und Aftermarket-Umsatz pro Maschine werden steuerbar.

Dieser Artikel beschreibt das vollständige KPI-Set für Service im Maschinenbau — operative Kern-KPIs (FTFR, MTTR, MTBF), kunden- und vertragsbezogene KPIs (NPS, SLA-Compliance), wirtschaftliche KPIs (Cost-per-Ticket, Marge, Aftermarket-Umsatz). Und vor allem: wie aus diesen Zahlen Steuerungsinstrumente werden, statt rückblickender Berichte.

Warum Service-KPIs ohne integrierte Datenbasis ihre Wirkung verlieren

In den meisten Service-Organisationen entstehen KPIs heute genau so: Ein Mitarbeiter sammelt am Quartalsende Ticketdaten aus dem Helpdesk, gleicht sie mit dem ERP-System für die Vertragsdaten ab, ergänzt Servicebericht-PDFs für die Einsatzzeiten, packt alles in Excel und berechnet daraus FTFR und MTTR. Das Ergebnis ist eine Zahl — aber keine Geschichte.

Drei strukturelle Probleme blockieren echte Steuerung:

Fehlende Bezugsobjekte. Eine FTFR von 65 % sagt wenig, solange unklar ist, ob die Wert für Anlagentyp A oder B gilt, ob er in Region Nord oder Süd auftritt, welcher Service-Techniker eingesetzt war oder welche Fehlerklasse vorlag. Ohne Maschinenakte als strukturierter Bezugspunkt bleibt jeder KPI eine isolierte Zahl ohne Handlungsableitung.

Unklare Definitionen. Was zählt als „erfolgreich beim ersten Einsatz gelöst“? Symptom-Behebung oder Ursachenanalyse? Reicht ein Neustart der Anlage, oder muss die Wurzel des Problems behoben sein? Solange diese Definition nicht systemseitig festgeschrieben ist, misst jede Service-Organisation etwas anderes — und Vergleiche zwischen Standorten oder Quartalen verlieren ihren Sinn.

Manuelle Zeitstempel. MTTR-Berechnungen scheitern an genau einem Punkt: Wann genau ist das Problem aufgetreten? Wann wurde es gemeldet? Wann konnte der Techniker beginnen? Wann war es behoben? Solange diese Zeitstempel manuell aus Berichten zusammengetragen werden, sind sie ungenau — und die KPI darauf entsprechend unzuverlässig.

Das 4-Stufen-Modell als KPI-Fundament

logicline arbeitet entlang eines vierstufigen Modells, das auch für KPI-Architektur gilt: Jede Stufe schafft die Voraussetzung für die nächste. Wer in Stufe 3 (Entscheiden) investieren will, ohne Stufe 1 (Digitalisieren) zu haben, baut auf instabiler Basis. Eine ausführliche Behandlung der vier Stufen als Strategie-Rahmen finden Sie im Pillar Service-Strategien im Maschinenbau.

Für die KPI-Frage heißt das konkret:

Die Reihenfolge ist nicht beliebig. Wer ein KPI-Dashboard ohne saubere Maschinenakte aufsetzt, bekommt schöne Charts mit fragwürdigem Inhalt. Wer eine SDI-Schicht über fragmentierte Daten legt, bekommt KI-Antworten ohne zuverlässige Grundlage. Die saubere Reihenfolge spart deutlich Zeit auf dem Weg.

Operative Kern-KPIs — FTFR, MTTR, MTBF

First-Time-Fix-Rate (FTFR) — wie oft das Problem beim ersten Einsatz gelöst wird

Formel: FTFR = Einsätze mit Erstlösung / Gesamtzahl der Einsätze × 100

Branchenüblich liegen FTFR-Werte im Maschinenbau-Service oft im Bereich von zwei Dritteln bis drei Viertel — der genaue Wert hängt stark von Maschinenkomplexität, Servicestruktur und Definition ab. Genau die Definition ist die erste kritische Frage: Bedeutet „erfolgreich“, dass das Symptom verschwunden ist, oder muss die Ursache behoben sein? Ein Techniker, der eine Anlage durch Neustart wieder anlaufen lässt, ohne die zugrunde liegende Fehlfunktion zu beseitigen, kann die FTFR statistisch verbessern — während sich das Problem in zwei Wochen erneut zeigt.

Ohne strukturierte Maschinenakte ist die FTFR eine Gesamt-Zahl, die nichts zur Handlung beiträgt. Mit Maschinenakte wird sie filterbar nach Anlagentyp, Region, Techniker, Fehlerklasse. Erst dann zeigt sich, ob ein bestimmter Maschinentyp systematisch schwer zu triagieren ist, ob ein Servicepartner deutlich schlechter abschneidet als der Durchschnitt, oder ob bestimmte Fehlerklassen wiederkehren.

Service Decision Intelligence (SDI) verbessert FTFR durch präzisere Triage vor dem Einsatz. Aus Servicehistorie und Telemetrie identifiziert die Intelligenzschicht typische Fehlermuster und liefert Empfehlungen zu Ersatzteilen, Technikerqualifikation und Diagnose-Schritten — mit Quellennachweis. Wie diese Schicht arbeitet und warum sie nicht halluziniert, beschreibt der Pillar Wenn Agentforce halluziniert: Warum KI im Service eine eigene Wissensbasis braucht.

Mean Time to Repair (MTTR) — wie lange die Lösung dauert

Formel: MTTR = Gesamte ungeplante Ausfallzeit / Anzahl der Störungen

Die MTTR misst die Zeit zwischen Ticket-Eröffnung und Schließung. Das größte Problem ist die Verzerrung durch Wartezeiten: Muss ein Techniker drei Stunden auf ein Ersatzteil warten, fließt diese Zeit in die MTTR ein, obwohl das eigentliche Problem in der Logistik liegt, nicht in der Reparatur. Eine saubere KPI-Architektur teilt MTTR daher in Sub-KPIs auf — aktive Reparaturzeit, Wartezeit auf Ersatzteil, Wartezeit auf Spezialist-Eskalation, Wartezeit auf Kundenrückmeldung.

Ein zweites typisches Problem sind unvollständige Zeitstempel. Wird der genaue Beginn einer Störung nicht erfasst — sei es durch manuelle Eingabe oder fehlende IoT-Signale —, kann das Ticket nicht zuverlässig in die MTTR-Berechnung einfließen. Die Norm DIN EN 15341 empfiehlt entsprechend, nur Störungen mit vollständig dokumentierten Start- und Endzeitpunkten in die Berechnung aufzunehmen. In der Praxis bedeutet das: automatisierte Zeitstempel über SPS- oder IoT-Signale, statt auf Servicebericht-Einträge zu vertrauen.

Wie SDI die MTTR durch vernetzte Diagnose-Empfehlungen reduziert — und wie Empolis Service Express dabei eine Rolle spielt — beschreibt der Pillar Wissensmanagement im Service.

Mean Time Between Failures (MTBF) — Anlagenseitig statt prozessseitig

Formel: MTBF = Summe der Betriebszeiten zwischen Ausfällen / Anzahl der Ausfälle

Die MTBF wandert vom Service- in den Engineering-Blick: Sie misst die Zuverlässigkeit der Anlage selbst. Die Hauptherausforderung ist die einheitliche Definition von „Ausfall“ — wird der über einen Fehlercode definiert, über einen Produktionsstillstand, über eine Sicherheitsabschaltung? Ohne klare, system-seitige Definition werden Vergleiche zwischen Anlagentypen oder Standorten wertlos.

Praktisch zählt: MTBF aus Telemetrie ableiten statt aus Serviceberichten. Telemetrie liefert objektive Zeitstempel; Serviceberichte sind manuell und reaktiv. Eine Digitale Maschinenakte, die IoT-Daten direkt in die Asset-Struktur einspielt, macht MTBF-Auswertungen pro Maschinentyp, Baujahr oder Betriebsumgebung möglich — und führt damit oft zu der Erkenntnis, dass nicht alle Anlagen gleich „zuverlässig“ sind, sondern Reifegrad-Cluster bestehen.

Kunden- und Vertrags-KPIs — NPS und SLA-Compliance

Net Promoter Score (NPS) — wann er aussagekräftig wird

Formel: NPS = % Promotoren − % Detraktoren, Skala −100 bis +100

Der NPS ist eine einfache Kennzahl mit komplexem Auswertungs-Problem. Die Standardfrage „Wie wahrscheinlich ist es, dass Sie unser Unternehmen weiterempfehlen?“ auf einer 0-bis-10-Skala. Aber: jährliche globale Umfragen liefern oft nur einen Stimmungs-Eindruck ohne Bezug zu konkreten Servicefällen. Wenn ein Kunde im Februar einen frustrierenden Servicefall hatte und im Juli pauschal antwortet — was misst der Wert dann eigentlich?

Aussagekräftig wird NPS erst, wenn er unmittelbar nach jedem Serviceeinsatz erhoben wird, ticketspezifisch und maschinenbezogen. Dann lässt sich die Bewertung mit FTFR, MTTR, Techniker, Anlagentyp und Vertragsklasse korrelieren. Es entsteht die Möglichkeit zu erkennen: An welchen Maschinentypen sind Kunden systematisch unzufrieden, obwohl die operative KPI im Schnitt liegt? Welche Servicepartner generieren NPS-Detraktoren?

SDI hebt die NPS-Analyse auf eine weitere Ebene, indem es Einsatzdaten mit NPS-Feedback verknüpft. Muster werden sichtbar, die ohne strukturierte Datenbasis im Rauschen verschwinden würden.

SLA-Compliance — Ticket-Ebene statt Vertrags-Durchschnitt

Die SLA-Compliance misst, ob vereinbarte Reaktions- und Lösungszeiten eingehalten werden. Zwei zentrale Herausforderungen:

Bezugsebene. Eine SLA-Compliance von 96 % auf Vertragsebene kann einzelne Kunden mit chronischen Verletzungen verbergen. Nur ein Drill-Down auf Ticket-, Anlagen- und Vertragsebene macht systematische Schwachstellen sichtbar. Strukturell heißt das: SLA-Compliance muss in mindestens zwei Sichten ausgewertet werden — pro Vertrag und pro Asset-Klasse.

Datenlage. Ohne automatisierte Zeiterfassung fehlt oft der genaue Zeitpunkt der Störungsmeldung. Manuelle Zeitstempel verzerren die Reaktionszeit-Messung. DIN EN 15341 empfiehlt daher, nur Tickets mit vollständigen Zeitstempeln in die SLA-Berechnung einzubeziehen — was in der Praxis bedeutet, dass die Erfassung über IoT- und Ticket-System-Integration laufen muss, nicht über manuelle Berichte.

Eine integrierte Datenbasis aus Maschinenakte (Bezugsobjekt), Tickets in Salesforce (Workflow) und Telemetrie (Zeitquelle) macht SLA-Compliance erst zu einer steuerbaren KPI. Chronische Untererfüllung — etwa bei einem bestimmten Vertragsmodell oder einer bestimmten Region — lässt sich erkennen und adressieren, bevor sie zur Vertragskündigung führt.

Wirtschaftliche KPIs — Cost-per-Ticket, Service-Marge, Aftermarket-Umsatz

Operative KPIs zeigen Servicequalität. Wirtschaftliche KPIs zeigen, ob der Service auch finanziell trägt.

Cost-per-Ticket — der vollständige Kostenblick

Formel: Cost-per-Ticket = Gesamtkosten aller Serviceeinsätze / Anzahl abgeschlossener Tickets

Der häufigste Fehler: nur Personalkosten in die Berechnung einbeziehen. Wer Cost-per-Ticket steuerungsrelevant berechnen will, muss ein vollständiges Kostenmodell hinterlegen — Personal, Material, Reisekosten, Gemeinkosten, ggf. Opportunitätskosten der gebundenen Techniker-Kapazität. Erst dann zeigen Vergleiche zwischen Vertragsklassen, Maschinentypen oder Regionen, wo Kostentreiber liegen.

Ein höherer FTFR senkt unmittelbar die Wiederholungseinsätze — und damit Cost-per-Ticket. Wer FTFR und Cost-per-Ticket gemeinsam betrachtet, sieht ob Erstlösungs-Verbesserungen tatsächlich wirtschaftlich durchschlagen oder ob andere Kostentreiber dominieren.

Service-Marge — Rentabilität des Servicegeschäfts

Die Service-Marge misst das Verhältnis von Service-Umsatz zu Service-Kosten. Erfolgreiche Maschinenbau-Service-Organisationen erreichen Margen, die deutlich über denen des Neumaschinen-Geschäfts liegen — Service-Geschäft ist strukturell margenstärker, weil weniger materialintensiv. Niedrige Margen sind in der Regel kein Marktthema, sondern haben interne Ursachen: ineffiziente Einsatzplanung, manuelle Ersatzteil-Disposition, eine reaktive Service-Organisation, die Notfalleinsätze statt geplanter Wartung fährt.

Strukturierter Service auf Basis vernetzter Daten verschiebt die Marge in zwei Richtungen: weniger Notfall-Einsätze (Kostenreduktion) und mehr Wartungsverträge mit planbarem Umsatz (Erlössteigerung). Wie strukturierte Service-Sales-Kampagnen aus der installierten Basis funktionieren, beschreibt der Pillar Service-Sales-Kampagnen aus der installierten Basis.

Aftermarket-Umsatz pro Maschine — der Lebenszyklus-Blick

Der Aftermarket-Umsatz pro Maschine zeigt den finanziellen Beitrag jeder Anlage über ihren gesamten Lebenszyklus — Ersatzteile, Wartungsverträge, Modernisierungen, digitale Services. Die KPI macht aus der installierten Basis ein steuerbares Geschäft: Welche Maschinen-Cluster tragen am meisten? Welche werden bald aus dem Servicefenster fallen? Wo lohnen Modernisierungs- oder Austauschangebote?

Ohne strukturierte Maschinenakte bleibt diese Sicht im Nebel. Mit Maschinenakte werden Aftermarket-Umsätze pro Anlage, pro Generation, pro Vertragsmodell auswertbar — und damit Trigger für gezielte Sales-Kampagnen. Wer das End-of-Life-Geschäft strategisch nutzen will, findet einen vertiefenden Blick im Pillar End-of-Life-Management im Maschinenbau.

Integrierte KPI-Architektur — von der Messung zur Steuerung

Einzelne KPIs reichen nicht. Die Wirkung entsteht aus der Verknüpfung: FTFR mit Cost-per-Ticket, MTTR mit NPS, MTBF mit Aftermarket-Umsatz pro Maschine. Erst diese Korrelationen zeigen, wo Verbesserungen tatsächlich auf den Geschäftserfolg durchschlagen.

Ein typisches Szenario aus dem Maschinenbau

Ein Hersteller mit etwa 4.500 installierten Anlagen weltweit verwaltet seine Stammdaten heute in Excel und einem ERP-System. Die FTFR wird quartalsweise manuell ermittelt und liegt „irgendwo zwischen 60 und 65 %“. Eine Drill-Down-Möglichkeit nach Anlagentyp, Region, Techniker oder Fehlerklasse fehlt. Warum die FTFR seit drei Jahren stagniert, kann niemand belegt erklären — und so bleiben Verbesserungsversuche Versuch und Irrtum.

Schritt 1: Strukturierte Maschinenakte auf Salesforce. Die installierten Anlagen werden mit Komponenten, Konfigurationen und Servicehistorie strukturiert erfasst — das Installed Base Assessment liefert in vier bis sechs Wochen den Bestand.

Schritt 2: Tickets, Telemetrie und Vertragsinformationen werden in dieselbe Plattform integriert. FTFR und MTTR werden in Echtzeit auswertbar — pro Anlagentyp, Region, Techniker. Es zeigt sich: Der Durchschnitt von 62 % verbirgt eine FTFR von 78 % bei der Hauptproduktlinie und 41 % bei einer kleineren Spezialanlage. Die Hebelaktion liegt nicht in „der FTFR insgesamt“, sondern in der Spezialanlage.

Schritt 3: SDI analysiert die vernetzten Daten und identifiziert das Muster — die Spezialanlage benötigt eine bestimmte Werkzeugkonfiguration und Technikerqualifikation, die in 60 % der Erst-Einsätze fehlt. Die Triage wird angepasst. Innerhalb von zwei Quartalen steigt die FTFR der Spezialanlage von 41 % auf 70 %.

Das ist die Differenz zwischen KPI als Bericht und KPI als Steuerungsinstrument.

SDI als Hebel — nicht nur Messung, sondern Verbesserung

Service Decision Intelligence ist mehr als ein Dashboard. Die Intelligenzschicht arbeitet auf den vernetzten Servicedaten und verbessert KPIs aktiv:

• FTFR steigt durch präzisere Triage vor dem Einsatz — auf Basis von Mustern aus der gesamten Servicehistorie
• MTTR sinkt durch kontextbezogene Diagnose-Empfehlungen mit Quellennachweis
• NPS wird steuerbar, weil Detraktoren-Muster über Anlagentypen und Regionen sichtbar werden
• SLA-Compliance kann proaktiv überwacht werden, weil Risiko-Tickets frühzeitig erkennbar sind

Drei Eigenschaften machen SDI für KPI-Anwendungen besonders relevant:

Datenhoheit. SDI läuft auf der Infrastruktur des Maschinenbauers — Azure oder AWS in EU-Region —, nicht in geteilten LLM-Umgebungen. Servicedaten fließen nicht in externe Trainingsmodelle ein, der AI Act ist erfüllt.

Quellennachweis. Jede Empfehlung kommt mit Audit-Trail. Wenn SDI sagt, „die wahrscheinliche Fehlerursache ist Sensor X, basierend auf Vergleichsfällen Y und Z“ — dann sind diese Quellen einsehbar. Das ist für regulatorisch sensible Servicefälle (Claims, Warranty) entscheidend.

GRAX als Lakehouse. Die vollständige Salesforce-Servicehistorie wird ohne API-Limits zugänglich. Servicehistorie, Telemetrie und Vertragsdaten landen im gleichen Kontext und stehen für KPI-Analysen zur Verfügung.

Wie die Service-Konsole vor Ort dadurch verändert wird — und wie der Techniker davon konkret profitiert — beschreibt der Pillar IoT-Daten beim Service-Einsatz.

Nächster Schritt

Service-KPIs im Maschinenbau sind kein Reporting-Problem, sondern ein Datenstruktur-Problem. Die Werkzeuge (Salesforce Service Cloud, Maschinenakte, IoT-Plattformen, SDI) sind ausgereift. Was den Unterschied macht, ist die Reihenfolge: Daten strukturieren, Systeme vernetzen, Entscheidungen mit Quellennachweis treffen.

Der erste Schritt ist deshalb nicht die nächste BI-Auswahl, sondern eine ehrliche Bestandsaufnahme: Wo stehen die Service-Daten heute? Welche KPIs sind wirklich filterbar? An welchen Stellen bricht die Drill-Down-Fähigkeit zusammen?

Zwei pragmatische Einstiege:

• Installed Base Assessment — wenn die Maschinendaten heute verstreut sind und KPI-Reports manuell aus Excel zusammengetragen werden. In vier bis sechs Wochen wird die Datenbasis strukturiert und ein konkreter KPI-Hebel-Report geliefert.
• Erstgespräch — wenn die Datenbasis bereits steht und Sie konkret bewerten wollen, welche Stufe als nächste den größten KPI-Hebel bringt — und ob SDI auf Ihrer Servicehistorie als Hebel auf FTFR und MTTR Sinn macht.