Ausfallzeiten Tracking Software: Die 8 Stillstandsgründe, die OEE bewegen
Du kannst Software für Ausfallzeiten-Erfassung für 200 Euro im Monat kaufen oder für 20.000 Euro im Monat. Der Preis sagt Dir wenig darüber, wie nützlich sie am Montagmorgen ist, wenn die Linie steht und der Schichtleiter 30 Sekunden hat, etwas in ein Tablet zu tippen, bevor das nächste Teil das Band trifft.
Was zählt, ist ob die Software den Leuten auf dem Hallenboden hilft, den richtigen Grund zu benennen. Das ist die ganze Aufgabe. Sind die Stillstandsgründe zu vage, sagt Dir der OEE-Report am Monatsende, dass die Linie 14 Stunden stand, und niemand weiß warum. Sind sie zu granular, gibt der Bediener auf und tippt zu 80 Prozent „Sonstiges“. Du zahlst dann für ein System, das nichts erfasst.
Dieser Guide ist die praktische Variante. Er behandelt die acht Stillstandsgründe, die in einem kleinen oder mittelgroßen Werk wirklich OEE bewegen, die 30, die Du ruhig weglassen kannst, wie ein iPhone-basierter Ausfall-Feed live aussieht, und wie Du Software für Ausfallzeiten-Erfassung auswählst, ohne auf die Demo hereinzufallen.
Warum die meiste Ausfallzeiten-Erfassung am Punkt vorbei geht
Drei Muster tauchen immer wieder auf, wenn wir Ausfalldaten von neuen Kunden auditieren.
Das erste ist die „Sonstiges“-Inflation. Ein Werk fährt 24 Stillstandsgründe. Die drei häufigsten heißen „ungeplanter Stopp“, „kleines Problem“ und „Sonstiges“. Zusammen machen sie 62 Prozent der erfassten Ausfallzeit aus. Diese Daten sind für die Ursachenanalyse wertlos. Sie sagen Dir, dass die Linie stand, aber nichts darüber, was zu reparieren ist.
Das zweite ist Doppelerfassung. Bediener loggen einen Stopp im MES, einen separaten Stopp im Wartungssystem und einen dritten Eintrag im Papier-Logbuch für die Schichtübergabe. Die Zahlen passen nie zusammen. Der Werksleiter pickt sich die Quelle, die das Argument stützt, das er im Produktionsmeeting führen will.
Das dritte ist verzögerte Erfassung. Die Linie steht um 09:12. Der Bediener loggt den Stopp um 11:47, wenn er wieder am Tablet ist. Bis dahin erinnert er die Dauer als „etwa 20 Minuten“ statt der tatsächlichen 8 Minuten und 14 Sekunden. Echtzeit-Monitoring wird zu nachträglichem Geschichtenerzählen.
Die Lösung sind nicht mehr Stillstandsgründe. Es sind weniger Stillstandsgründe, erfasst im Moment, in dem die Linie steht, mit genug Kontext, dass der nächste danach handeln kann.
Die 8 Stillstandsgründe, die zählen (und die 30, die nicht zählen)
Über rund 40 Werke, mit denen wir in den letzten 18 Monaten gearbeitet haben, decken dieselben acht Stillstandsgründe 85 bis 92 Prozent aller Ausfallminuten ab. Die anderen 30 plus Codes, die Anbieter gern in ihre Default-Vorlage stecken, machen den Rest aus. Erfasse die acht. Mach den Rest zu Freitext oder fasse sie unter „Sonstiges“ zusammen.
Die acht Codes, die wirklich OEE bewegen, sind:
- Materialmangel. Keine Teile am Einlauf. Entweder ist der vorgelagerte Prozess langsamer als Deine Linie oder das Material wurde nicht rechtzeitig bereitgestellt.
- Materialstau oder Qualitätsausschuss aus dem Vorprozess. Ein Teil liegt am Einlauf, aber es ist falsch, beschädigt oder verklemmt. Andere Ursache als Materialmangel, andere Lösung.
- Werkzeug- oder Rezeptwechsel. Geplanter Rüstvorgang zwischen SKUs. Erfasse das separat, damit es nicht die ungeplante Ausfallzeit verfälscht.
- Mechanischer Fehler. Ein physisches Teil der Maschine ist ausgefallen. Lager, Riemen, Pneumatik, alles was einen Techniker braucht.
- Elektrik- oder Steuerungsfehler. Die Mechanik ist in Ordnung, aber SPS, Sensor oder Antrieb haben einen Fehler geworfen. Anderer Troubleshooting-Pfad.
- Bediener abwesend oder Pause. Die Linie ist bereit, aber niemand steht an der Station. Schließt Lücken bei der Schichtübergabe und ungeplante Pausen ein.
- Qualitätssperre. Die Linie steht, weil die letzten Teile durch die Prüfung gefallen sind und jemand entscheiden muss, was zu tun ist.
- Stau im Vor- oder Nachprozess. Deine Linie läuft, aber das Band ist voll, weil die Verpackung hinterher hängt oder das Lager keine Paletten mehr annimmt.
Das wars. Acht Codes decken den Großteil dessen ab, was die OEE-Zahl bewegt. Alles andere ist entweder eine Unterkategorie einer der acht oder ein seltenes Ereignis, das Du einmal im Monat als Freitext erfassen und im OEE-Review besprechen kannst.
Der Grund warum das funktioniert: Jeder der acht Codes mappt auf eine andere Handlung. Materialmangel ruft die Planung. Mechanischer Fehler ruft die Instandhaltung. Qualitätssperre ruft das Qualitätsteam. Wenn Dein Stillstandsgrund dem Bediener nicht sagt, wen er rufen soll, ist es der falsche Stillstandsgrund.
Wie ein iPhone-basierter Ausfall-Feed aussieht
Wenn Du unseren OEE-Berechnung Guide gelesen hast, weißt Du, dass Ausfalldaten in die Verfügbarkeit fließen, einen der drei OEE-Faktoren. Die Daten sind nur dann nützlich, wenn sie in dem Moment erfasst werden, in dem die Linie stoppt.
Der klassische Ansatz ist ein Tablet, das mit der SPS verdrahtet ist. Wenn die SPS ein Stopp-Event wirft, fragt ein Pop-up den Bediener nach einem Stillstandsgrund. Das funktioniert, kostet aber etwa 4.000 bis 8.000 Euro pro Linie für Hardware und Integration, und Du bindest Dich an den SPS-Hersteller, mit dem Du gestartet bist.
Die iPhone-Variante umgeht die SPS-Integration komplett. An jeder Station ist ein refurbished iPhone montiert, das eine einzige App fährt. Die Kamera beobachtet die Linie. Wenn der Teilefluss länger als ein konfigurierbarer Schwellwert steht (üblich 8 bis 15 Sekunden, je nach Taktzeit), flaggt die App den Stopp und der Bediener wählt einen der acht Stillstandsgründe auf dem Bildschirm. Die ganze Interaktion dauert unter 5 Sekunden.
Drei Dinge machen das möglich, die vor fünf Jahren noch nicht gingen. Erstens ist die iPhone-Kamera gut genug, um Zyklus-Stopps unter Hallenbeleuchtung zuverlässig zu erkennen, ohne einen separaten Sensor. Zweitens bedeutet On-Device-Verarbeitung, dass die Daten privat sind und keine Latenz durch Cloud-Roundtrips entsteht. Drittens kennt der Bediener das Interface schon. Es gibt keinen Trainingsaufwand über „Tippe auf den Grund“ hinaus.
Die Hardware, um eine Linie mit diesem Ansatz live zu nehmen, bleibt unter 1.000 Euro pro Station: refurbished iPhone, Halterung, Ringlicht, Ethernet-Adapter für den Daten-Backhaul. Du kannst innerhalb eines Nachmittags drei Linien mit einem Ausfall-Feed bespielen.
Vom Log zur Handlung: ein Workflow auf Schichtebene
Die Daten zu erfassen ist die halbe Arbeit. Die andere Hälfte ist sicherzustellen, dass die Daten etwas auslösen, bevor die Schicht endet.
Der Workflow, den wir in Werken mit echter OEE-Verbesserung konsistent sehen, sieht so aus. Jeder Stillstandsgrund, der in der letzten Stunde geloggt wurde, taucht auf einem geteilten Schicht-Dashboard auf. Der Schichtleiter wirft beim 15-Minuten-Rundgang einen Blick darauf. Wenn Materialmangel in zwei Stunden dreimal geloggt wurde, bekommt die Planung eine Slack-Nachricht vor dem Mittagessen, nicht erst im nächsten Planungsmeeting am Donnerstag. Wenn mechanische Fehler an einer Maschine clustern, wird die Instandhaltung gerufen, bevor das nächste geplante PM-Fenster kommt.
Das Dashboard muss nicht aufwendig sein. Eine einzige Seite mit den acht Codes, Anzahl und Minuten für die aktuelle Schicht, plus eine Sparkline mit dem Trend gegenüber letzter Woche reicht. Was zählt: dass der Schichtleiter tatsächlich draufschaut und dass das Hinschauen ein Gespräch auslöst.
Am Ende jeder Schicht schreibt der Leiter zwei Sätze in die Übergabe: was der größte Ausfalltreiber war und was er dagegen unternommen hat. Das werden die Daten, die das Produktionsmeeting am Freitag tatsächlich nutzt. Die OEE-Zahl an der Wand ist ein nachlaufender Indikator. Die Zwei-Satz-Übergabe ist der vorlaufende.
Für die kamerabasierte Variante dieses Workflows siehe unseren Beitrag zur kamerabasierten Produktionsüberwachung, der die Vision-Pipeline detaillierter behandelt.
Software für Ausfallzeiten-Erfassung auswählen
Wenn Du Dich hinsetzt, um Software für Ausfallzeiten-Erfassung zu evaluieren, blenden Dich die meisten Demos mit Dashboards, KI-Assistenten und Modulen für vorausschauende Wartung. Ignoriere die Demo. Stell fünf Fragen.
Erstens: Wie lange dauert es, einen Stopp ab dem Moment zu loggen, in dem die Linie steht? Liegt die Antwort über 10 Sekunden Bediener-Zeit pro Event, sind die Daten innerhalb eines Monats verspätet und unvollständig.
Zweitens: Wie viele Stillstandsgründe sind im Default konfiguriert und kannst Du sie auf acht reduzieren? Anbieter, die auf ihrer 40-Code-Taxonomie beharren, verstehen Maschinen-Ausfallerfassung auf einem realen Hallenboden nicht.
Drittens: Funktioniert das System ohne SPS-Anbindung? Wenn der einzige Pfad zur Ausfallerfassung über die Integration mit Deinem Steuerungssystem läuft, kaufst Du Dir ein dreimonatiges Implementierungsprojekt, bevor Du irgendwelche Daten siehst. Kamera- oder Tastenbasierte Erfassung sollte eine erstklassige Option sein, kein Upsell.
Viertens: Wie sehen die Daten roh aus? Bitte den Anbieter, eine CSV mit einer Woche Ausfall-Events von einem bestehenden Kunden zu exportieren (anonymisiert). Wenn der Anbieter das nicht in fünf Minuten kann, sind die Daten in seinem Dashboard eingesperrt und Du wirst kämpfen, sie rauszubekommen, wenn Du Deine eigene Auswertung machen willst.
Fünftens: Was sind die Gesamtkosten pro Linie für das erste Jahr, inklusive Hardware, Integration, Training und Subscription? Die meisten Teams budgetieren die Lizenz und vergessen den Rest. Eine 200-Euro-im-Monat-Subscription mit 12.000 Euro Integration ist keine 2.400-Euro-im-Jahr-Entscheidung.
Die richtige Software für Ausfallzeiten-Erfassung ist die, die Deine Schichtleiter ohne Aufforderung nutzen, von der Dein Instandhaltungsteam die Daten als verlässlich akzeptiert, und die Dein CFO im zweiten Jahr nicht als verlorene Investition abschreiben muss.
FAQ
Was ist der Unterschied zwischen Ausfallzeiten-Erfassung und OEE-Software?
OEE-Software berechnet die vollständige OEE-Zahl über Verfügbarkeit, Leistung und Qualität. Software für Ausfallzeiten-Erfassung konzentriert sich speziell auf den Verfügbarkeits-Faktor, indem sie erfasst, warum die Linie stand. Die meisten Teams brauchen beides, aber Du kannst Ausfallzeiten-Erfassung allein fahren und die Leistungs- und Qualitäts-Bausteine später ergänzen. Für die volle Berechnung siehe unseren OEE-Berechnung Guide.
Wie granular sollten Stillstandsgründe sein?
Acht bis zehn Codes ist der Sweet Spot. Unter sechs kannst Du Planungs-Themen nicht von Mechanik-Themen trennen. Über zwölf weichen Bediener innerhalb von zwei Wochen auf „Sonstiges“ aus. Widersteh dem Drang, jedes Mal einen Code hinzuzufügen, wenn jemand in einem Meeting einen vorschlägt.
Geht Ausfallzeiten-Erfassung ohne SPS?
Ja. Kamerabasierte Erfassung mit einem montierten iPhone ist die sauberste Option für Werke ohne moderne SPS oder für die Nachrüstung älterer Linien. Tastenbasierte Erfassung (ein physischer Knopf an der Station, den der Bediener bei Linienstillstand drückt) funktioniert auch, fügt aber etwa 2 Sekunden Bediener-Zeit pro Event hinzu.
Wie schnell ist Software für Ausfallzeiten-Erfassung live?
Für ein iPhone-basiertes Erfassungssystem hast Du eine Linie an einem Nachmittag live und ein komplettes Werk mit 8 bis 12 Linien innerhalb einer Woche. SPS-integrierte Systeme brauchen typischerweise 6 bis 12 Wochen pro Linie inklusive Test.
Ersetzt Ausfallzeiten-Erfassung Dein CMMS?
Nein. Ein CMMS verwaltet Arbeitsaufträge, Ersatzteilbestände und PM-Zyklen. Ausfallzeiten-Erfassung verwaltet Echtzeit-Event-Erfassung und Stillstandscodes. Die beiden sollten miteinander reden, sodass ein mechanischer Fehler, der an der Linie geloggt wird, automatisch einen Auftragsentwurf im CMMS anlegt. Aber sie lösen verschiedene Probleme.
Eine Rahmenfrage, die oft kommt: Wie hängt Software für Ausfallzeiten-Erfassung mit dem breiteren OEE-Reporting zusammen? Der Ausfall-Feed ist der Verfügbarkeits-Input, der in die OEE einfließt. Ohne saubere Quelle für ungeplante und geplante Ausfall-Events ist die Verfügbarkeits-Zahl in Deinem wöchentlichen OEE-Report eine Schätzung, und das Team streitet darüber, welche Linie am schlechtesten lief, statt sie zu reparieren. Mit einem sauberen Feed wird dieselbe Zahl zum Input, mit dem jedes Ursachenanalyse-Gespräch startet. Der wöchentliche Review verlagert sich von Schuld auf Lernen. Code-erfasste Events heben die Verfügbarkeit über ein Quartal, weil Schichtleiter endlich die Daten haben, um die größten Verlierer zuerst zu reparieren.
Die Reporting-Kadenz, die ihren Platz verdient, ist wöchentliches Ausfall-Reporting, gebunden an ein Pareto-Diagramm der Stillstandsgründe, mit MTTR und OEE-Werten neben den Produktionsverlusten pro Linie getrennt aufgetragen. Die Stillstandsgründe, die Du einrichtest, sollten Anlagenausfall, langsame Zyklen, Qualitätsprobleme und geplante Wartung getrennt abdecken, sodass der wöchentliche Review sehen kann, welche Kategorie am schnellsten wächst. Ein KVP, das diese Daten nutzt, hat eine Chance, sich auf die größten Verlierer zu konzentrieren statt auf die lautesten. Teams, die den Muskel des wöchentlichen Reviews auf einem sauberen Feed aufbauen, sehen den Unterschied innerhalb eines Quartals.
Jetzt starten
Wenn Du diese Woche einen Ausfall-Feed auf einer Linie live haben willst, ist der schnellste Weg ein refurbished iPhone, eine Halterung und ein kostenloser Enao-Account. Wähle die acht Stillstandsgründe, die zu Deinem Werk passen, richte die Kamera auf die Linie, und Du hast in unter einer Stunde Daten fließen. Keine SPS-Integration, kein 12-Wochen-Projekt, keine fünfstellige Rechnung. Kostenlos starten und die erste Linie noch heute live nehmen.
Der Community beitreten
Wir betreiben einen kostenlosen Slack für Shopfloor-Builder, KVP-Leads und Operations-Leute. Mitglieder tauschen Code-Templates, Kamera-Tricks und Deployment-Lektionen offen aus. Tritt der Community bei, um Vorlagen für Stillstandsgründe mit anderen Process Engineers zu vergleichen, die dasselbe tun.
