MTBF richtig messen: Warum dein Wert wahrscheinlich falsch ist
Der MTBF-Wert auf dem Monatsreport der meisten Industriebetriebe hat keine gute Datengrundlage. Das zeigt sich so: Der Monatsreport für deine Instandhaltung ist fertig. Die MTBF-Kennzahl steht drauf, farblich markiert, mit Veränderung gegenüber dem Vormonat. Der Instandhaltungsleiter klickt die Zeile an und versucht zu rekonstruieren, wie der Wert zustande kommt.
Zeitstempel auf halbe Stunden. Drei Excel-Tabellen aus drei Schichten. Zwei Anlagen ohne Dokumentation, weil der Kollege letzte Woche krank war. Der Wert ist geschätzt, nicht gemessen.
So sieht es heute in den meisten Produktionsbetrieben aus. Nicht, weil die Leute nicht wollen, sondern weil die Grundlage fehlt. Belastbare MTBF-Werte entstehen nicht durch ein Dashboard, sondern durch drei Vorbedingungen.
Erstens, eine strukturierte Störungserfassung mit Pflicht-Schadensbild bei der Meldung. Das ist das Symptom, das der Bediener bei der Meldung auswählt. Die eigentliche Schadensursache trägt der Techniker erst nach der Reparatur nach. Beide gehören in unterschiedliche Felder, nicht in dasselbe.
Zweitens, eine belastbare Betriebszeit-Basis. Echte Maschinenlaufzeit aus einem MES ist die saubere Variante, im Mittelstand aber selten Standard. Praktikabler ist ein hinterlegter Schichtplan, der als Operating Hours die Basis bildet. Auch ein vorhandenes MES reicht allein übrigens nicht: Es zeigt, ob eine Maschine läuft oder steht, aber nicht, ob ein Stillstand geplant oder ungeplant war. Diese Unterscheidung lässt sich in den meisten Werken nur durch Bediener-Input sauber treffen.
Drittens, Zeitstempel direkt an der Anlage. In den meisten Werken läuft eine Störmeldung über mehrere Stationen: Der Bediener meldet dem Schichtleiter, der Schichtleiter ruft die Instandhaltung. Bis die Meldung im System landet, vergehen Minuten, manchmal Stunden. In dieser Lücke wird die Wahrheit geschätzt.
Kurz zur Terminologie, weil sie im Artikel mehrfach auftaucht: MTBF (Mean Time Between Failures) ist die mittlere Betriebszeit zwischen zwei Ausfällen einer Anlage. MTTR (Mean Time To Repair) ist die mittlere Reparaturzeit nach einem Ausfall. Beide Werte beeinflussen gemeinsam die technische Verfügbarkeit. Die exakte Formel hängt davon ab, welche Stillstände einbezogen werden. Die Abgrenzung im Detail kommt weiter unten. Dieser Artikel zeigt, wie die drei Vorbedingungen in der Praxis aussehen und warum keine Software das Problem allein löst.
Warum dein MTBF-Wert nicht stimmt
Drei Symptome verraten einen unzuverlässigen MTBF-Wert.
- Die Zeitstempel sind auf Stundenebene oder gröber. Eine Störung, die um 07:12 Uhr gemeldet und um 07:58 Uhr behoben wird, wird in der Excel-Liste als “vormittags, ca. 1 Stunde” festgehalten. Bei hundert Störungen im Quartal summiert sich der Fehler.
- Die Excel-Liste ist die einzige Quelle. Wenn die Meldung nicht in der Liste steht, zählt sie nicht. Wenn sie doppelt drinsteht, zählt sie doppelt. Kleinere Störungen, die der Techniker kurz selbst behebt, landen oft gar nicht in der Liste.
- Niemand im Team kann die Herleitung der Kennzahl beschreiben. Der Wert wird einmal im Monat exportiert, irgendjemand rechnet per Hand nach, und am Ende steht eine Zahl im Report. Die Rekonstruktion scheitert, wenn die Geschäftsführung nachfragt.
Ein Instandhaltungsleiter hat uns mal erzählt, dass in seiner Access-Datenbank drei verschiedene Zeitstempel-Formate nebeneinander existieren: Datum ohne Uhrzeit, Datum mit Uhrzeit auf Stundenebene, Datum mit Uhrzeit auf Minutenebene. Je nachdem, wer die Meldung eingetragen hat. Niemand im Haus traut der Kennzahl.
Das ist kein Einzelfall, sondern noch häufig die Regel. Forschungsinstitute wie das Fraunhofer IPT arbeiten seit Jahren an Methoden für datengetriebene Instandhaltung. Eine wiederkehrende Beobachtung aus unseren vielen Gesprächen mit Instandhaltern in Deutschland: die Verfügbarkeit belastbarer Kennzahlen scheitert in der Praxis selten an Software, sondern an der Datenqualität auf dem Shopfloor.
Was MTBF wirklich braucht
Drei Punkte sind relevant:
Strukturierte Störungserfassung mit Pflicht-Schadensbild
Freie Textfelder sind der häufigste Grund, warum Störungsdaten nicht auswertbar sind. “Motor läuft nicht” steht in der einen Meldung, “Antrieb defekt” in der nächsten, “keine Drehung” in der dritten. Drei Einträge, möglicherweise dieselbe Ursache, aber keine Software der Welt kann das automatisch gruppieren.
Die Lösung ist eine gepflegte Liste von Schadensbildern. Wie lang die Liste sein darf, ist eine alte Streitfrage. In der Theorie werden oft 15 bis 20 Einträge empfohlen, sonst ignoriere der Techniker die Liste. In der Praxis sieht das anders aus. Bei einem internationalen Markenartikelhersteller in unserem Datensatz umfasst der Schadensbild-Katalog über 800 Einträge, und er funktioniert.
Der Unterschied liegt nicht in der Anzahl, sondern in der Struktur. Eine flache Drop-Down-Liste mit 800 Einträgen ist tot. Ein hierarchischer Katalog (Anlagentyp → Komponente → Symptom), in dem der Techniker pro Anlage nur die für ihn relevanten 20 bis 30 Codes sieht, ist lebendig. Was im Frontend ankommt, ist immer eine kurze Liste. Was dahinter liegt, kann weitaus detaillierter sein.
Echte Betriebszeit als Basis, nicht Kalenderzeit
MTBF misst die Zeit zwischen zwei Ausfällen einer Anlage. Aber Zeit heißt hier Betriebszeit, nicht Kalenderzeit. Wenn die Anlage am Wochenende steht, weil Samstag und Sonntag nicht produziert wird, ist das kein Zuverlässigkeitsproblem. Trotzdem rechnen viele Excel-Tabellen diese Stunden mit, weil sie mit dem Datum arbeiten, nicht mit echten Betriebsdaten.
Die sauberen MTBF-Werte entstehen erst, wenn die Instandhaltungssoftware weiß, wann die Anlage wirklich gelaufen ist. Das heißt: Kopplung an MES oder BDE, oder zumindest an Schichtpläne, die als Basis dienen. Ohne diese Information bleibt die Kennzahl eine Schätzung mit besseren Zeitstempeln.
Was zählt als Ausfall? Ungeplante Stillstände, die die Anlage stoppen oder die Produktion unterbrechen. Geplante Stillstände wie Wartung, Umrüstung oder Schichtwechsel zählen nicht. Mikrostopps unter einer definierten Schwelle (oft 5 Minuten) werden meist separat erfasst, sonst verzerren sie die Kennzahl. Welche Schwelle in deinem Werk gilt, ist eine bewusste Setzung, kein Standard.
Zeitstempel auf jeder Störmeldung
Der dritte Punkt ist der am häufigsten unterschätzte. Der Zeitstempel auf der Störmeldung bestimmt, wann genau die Anlage ausgefallen ist. Wenn der Techniker die Meldung nachträglich erfasst, wenn er von der Anlage zurück ans Terminal läuft, entsteht eine Lücke. Zehn Minuten, dreißig Minuten, manchmal drei Stunden. In dieser Lücke wird die Wahrheit geschätzt.
Wie die Maschine ihren Status automatisch bekommt
Ein kurzes Beispiel aus einer Abfüllanlage zeigt, wie die drei Vorbedingungen in der Praxis zusammenspielen.
07:12 Uhr. Der Schichtführer steht an der Maschine, die gerade ausgefallen ist. Er nimmt das Tablet, scannt den QR-Code an der Anlage, wählt aus einer Liste das Schadensbild “Vorschub steht”, tippt einen Satz dazu und schickt die Meldung ab. Der Zeitstempel 07:12 ist automatisch gesetzt. Die Meldung landet bei der Instandhaltung.
07:15 Uhr. Ein Techniker übernimmt die Meldung vom Tablet im Werkstattbereich. Die Uhrzeit wird wieder automatisch festgehalten.
07:58 Uhr. Der Fehler ist behoben. Der Techniker tippt auf “erledigt”. Software rechnet im Hintergrund: Stillstand 46 Minuten. Reparaturzeit 43 Minuten. Laufzeit seit der letzten Störung an dieser Anlage: 82 Stunden.
Keine Excel-Liste. Keine manuelle Zeiterfassung am Ende der Schicht. Keine doppelte Datenpflege in Access-Datenbank und SAP-Auftrag.
Was in der Software passiert, ist simpel. Sobald die Störmeldung aufgemacht wird, legt die Software automatisch einen Status-Eintrag für die Anlage an. Dieser Eintrag hat einen Anfangs- und einen Endzeitpunkt. Wird die Störmeldung abgeschlossen, löst die Software den Status-Eintrag automatisch auf.
Die komplette Historie landet in einer Tabelle und einer Zeitleiste auf der Anlagenübersicht, mit Link zu jeder Störmeldung, jedem Auftrag, jedem Kommentar.
Das ist die Datenbasis, aus der sich MTBF rechnen lässt. Nicht weil irgendein Algorithmus clever ist, sondern weil jede Minute Stillstand mit einer echten, automatisch gesetzten Zeit versehen ist.
Was zeigt remberg heute auf dem Dashboard?
Die Kennzahlen, die sich aus einer sauberen Störungserfassung direkt ableiten lassen, sind in remberg live sichtbar: MTTR (Reparaturzeit), MTTA (mittlere Bestätigungszeit), Instandhaltungskosten und Anlagenfehler pro Anlage. Jede dieser Kennzahlen wird aus genau den Datenpunkten berechnet, die an der Maschine entstehen: Zeitstempel der Meldung, Zeitstempel der Übernahme, Zeitstempel des Abschlusses, Schadensbild.
MTBF folgt derselben Logik, braucht aber zwei Dinge zusätzlich: eine konfigurierte Laufzeitbasis (Schichtplan oder MES) und die Anzeige auf der Anlagendetailseite, an der wir mit remberg aktuell arbeiten. Die Datengrundlage im System ist die gleiche.
MTTR ist nicht MTBF, aber warum du beide brauchst
Wichtig zu Verstehen ist: MTBF misst Zuverlässigkeit, MTTR misst Reaktionsfähigkeit
MTBF ist die Mean Time Between Failures, also die mittlere Zeit zwischen zwei Ausfällen. Sie sagt, wie zuverlässig eine Anlage läuft. Formel: MTBF = Gesamtbetriebszeit geteilt durch Anzahl der Ausfälle.
MTTR ist die Mean Time To Repair, die mittlere Reparaturzeit. Sie sagt, wie schnell die Instandhaltung eine Anlage nach einem ungeplanten Ausfall wieder zum Laufen bringt.
Formel: MTTR = Durchschnitt aus (Abschlusszeit minus Übernahmezeit) über alle reaktiven Aufträge auf der Anlage. Start ist die Übernahme durch den Techniker, Ende ist die Bestätigung "technisch behoben". Wartezeit zwischen Meldung und Übernahme zählt nicht zur MTTR, sondern zur MTTA. Präventive Wartungsaufträge zählen nicht mit. Ohne saubere Trennung zwischen reaktiv und präventiv im Auftragsstamm ist die Kennzahl nicht belastbar.
Die beiden Werte messen unterschiedliche Dinge. Wer nur MTBF betrachtet, bekommt ein Gefühl für die Anlagenzuverlässigkeit, aber nicht für die Instandhaltungsorganisation. Wer nur MTTR betrachtet, optimiert die Reparatur und übersieht, dass die Anlage zu oft ausfällt.
Warum sie getrennt gemessen werden müssen
Zwei Beispiele machen es deutlich. Eine Anlage mit hoher MTBF und hoher MTTR fällt selten aus, aber wenn sie es tut, steht sie lange still. Die Verfügbarkeit leidet, obwohl die Technik zuverlässig ist. Die Reparaturorganisation ist das Problem.
Eine Anlage mit niedriger MTBF und niedriger MTTR fällt dagegen oft aus, ist aber schnell wieder da. Die Verfügbarkeit kann okay sein, aber die ständigen Unterbrechungen stören den Produktionsfluss. Hier lohnt sich eine Fehleranalyse an der Anlage selbst, nicht an der Instandhaltung.
Nur beide Werte zusammen liefern das vollständige Bild. Wie typische MTTR-Zielwerte für Fertigungsanlagen in verschiedenen Branchen aussehen und wie du Reparaturzeit sauber von Reaktionszeit trennst, haben wir im MTTR-Artikel mit Rechenbeispielen aufgeschlüsselt.
Warum ein Dashboard ohne Datenqualität nutzlos ist
Jede CMMS-Software behauptet heute, MTBF automatisch anzuzeigen. Das ist technisch richtig und inhaltlich nur dann wahr, wenn die Datenbasis stimmt. Ein Dashboard mit schönen Widgets ist wertlos, wenn es auf unscharfen Zeitstempeln, freitextlichen Schadensbildern und fehlenden Laufzeit-Infos aufsetzt.
Was ein Dashboard wirklich braucht: verlässliche Zeitstempel, die automatisch aus dem Scan oder der Schichtmeldung kommen. Einheitliche Schadensbilder aus einer gepflegten Liste. Eine Verknüpfung von Störmeldung, Anlage und Reparaturauftrag, damit sich Reparaturzeit und Stillstand sauber trennen lassen.
Wenn diese drei Punkte stimmen, liegt die Datenbasis für MTBF sauber im System. In remberg siehst du heute schon auf dem Dashboard, wie sich MTTR, mittlere Bestätigungszeit (MTTA), Instandhaltungskosten und Anlagenfehler pro Anlage über die Zeit entwickeln. Wie diese Auswertungen mit Filter nach Anlage, Werk und Zeitraum aussehen, siehst du bei den remberg Dashboards und Analysen.
Wie remberg die drei Vorbedingungen abbildet
Die drei Vorbedingungen (strukturierte Erfassung, Laufzeit-Kopplung, automatische Zeitstempel) sind Softwareunabhängig. Was sich unterscheidet, ist, wie ein Tool sie auf dem Shopfloor zugänglich macht. Drei Mechaniken in remberg machen den Unterschied.
Strukturierte Erfassung mit QR-Scan. Die Störmeldung entsteht direkt an der Maschine, per Scan auf dem Tablet oder Smartphone. Das Schadensbild ist Pflichtfeld aus einer hinterlegten Auswahlliste. Ein optionales Freitextfeld für Kontext bleibt, ersetzt aber nicht das strukturierte Feld. Die Schichtleitung muss nicht ans Terminal zurücklaufen, um die Meldung zu erfassen, und der Zeitstempel ist sekundengenau, weil er automatisch beim Scan gesetzt wird.
Laufzeit-Daten via Schnittstelle oder Schichtplan. Basis für die Betriebszeit ist der hinterlegte Arbeitszeit- und Schichtplan. Damit weiß die Software, ob ein Stillstand am Sonntag ein Verfügbarkeitsproblem ist oder schlicht das Wochenende. Eine direkte Schnittstelle zu MES- oder BDE-Systemen ist je nach Setup möglich, aber kein Standardumfang der Kennzahlenberechnung.
Anlagendetailseite mit vollständiger Historie. Jede Anlage hat eine Übersicht mit chronologischer Stör- und Wartungshistorie und Verknüpfung zu jedem einzelnen Auftrag.
Kein Excel-Reverse-Engineering mehr: Wenn die Geschäftsführung nach einem Stillstand fragt, klickt sich der Instandhaltungsleiter durch die Historie und zeigt jede einzelne Stillstandsminute mit Schadensbild, verantwortlichem Techniker und Reparaturzeit. Damit ist jede Kennzahl, die aus dieser Historie abgeleitet wird, bis auf die einzelne Störmeldung rekonstruierbar.
Heute laufen über 1 Million Anlagen in remberg, aus der mittelständischen Fertigung bis zum großen Industriekonzern. Was den Unterschied zu klassischen CMMS-Lösungen ausmacht: remberg ist mobile- und shopfloor-first gebaut, nicht ein in Tablet-Optik übersetztes Desktop-Tool, und läuft koexistent zu SAP PM statt als Ersatz.
Sieh dir an, wie MTBF in einer echten Anlagen-Historie aussieht
In einer 20-Minuten-Demo zeigen wir QR-Scan, Zeitleiste und Dashboard mit MTTR-, MTTA- und Kosten-Trend in einer Live-Umgebung, mit echten Daten aus einem Industrieunternehmen.
Demo buchen
Wer einen direkten Eindruck haben will, wie das in einer echten Anlagen-Historie aussieht: in einer 20-Minuten-Demo zeigen wir QR-Scan, Zeitleiste und Dashboard mit MTTR-, MTTA- und Kosten-Trend in einer Live-Umgebung, mit echten Daten aus einem Industrieunternehmen. Buche hier deine persönliche Demo.
Wer lieber erst schmökert: welche konkreten Module remberg für Instandhaltungs-Teams mitbringt, von Störungserfassung über Auftragsmanagement bis zu Ersatzteil-Workflows, zeigt unsere Lösungsseite zur Instandhaltungssoftware. Welche fünf Anbieter aktuell im deutschen Mittelstand am häufigsten in die engere Auswahl kommen, mit Stärken, Schwächen und typischen Einsatz-Szenarien, zeigt unser Anbieter-Vergleich.
Antworten auf häufige Fragen
Wie wird MTBF korrekt berechnet?
MTBF = Gesamtbetriebszeit geteilt durch Anzahl der Ausfälle. Die Betriebszeit muss echte Laufzeit sein, nicht Kalenderzeit. Wochenenden und geplante Stillstände werden nicht mitgerechnet.
Was unterscheidet MTBF von MTTR?
MTBF misst, wie zuverlässig eine Anlage läuft. MTTR misst, wie schnell die Instandhaltung nach einer Störung wieder funktionsfähig ist. Beide Werte beeinflussen gemeinsam die technische Verfügbarkeit. Wie sie genau zusammenwirken, hängt von der Definition der Stillstandsanteile ab.
Warum sind meine aktuellen MTBF-Werte nicht belastbar?
Wahrscheinlich fehlen drei Vorbedingungen: ein Pflicht-Schadensbild bei der Meldung, eine belastbare Betriebszeit-Basis (Schichtplan oder MES) und automatische Zeitstempel direkt an der Anlage.
Muss ich SAP PM für MTBF-Auswertung ablösen?
Nein. In vielen Industrieunternehmen bleibt SAP PM für Buchhaltung und Stammdaten führend, während eine dedizierte Instandhaltungs-Software die operative Schicht auf dem Shopfloor übernimmt. Beide Systeme werden per Schnittstelle verbunden.