NOVO AI · PRAXISLEITFADEN 22 MIN. LESEZEIT
Die Entscheidung auf einen Blick
Stillstandsgründe erfassen funktioniert nur dann sauber, wenn Sie vor dem Pilot drei Dinge schriftlich festlegen: welche Zeit überhaupt zur OEE gehört, ab wann ein Stopp als Verfügbarkeitsverlust zählt und wie Ursachen dokumentiert werden. Ohne diese Regeln bekommen Sie zwar Ereignisse, aber keine belastbare Verfügbarkeits- oder OEE-Analyse.
Genau darin liegt die Lücke zwischen Stillstandserkennung, Verfügbarkeitskennzahlen in der Produktion und einem produktiven Shopfloor-Setup. Dieser Beitrag ist deshalb kein allgemeiner OEE-Überblick, sondern ein Umsetzungsleitfaden mit direkt nutzbarem Muster-Datenvertrag, Ereignisbaum, Grundkatalog und Abnahmeprotokoll.
Wichtig ist die Grenze dieses Leitfadens: Er übersetzt dokumentierte OEE-Methodik und öffentlich beschriebene Plattformfunktionen in eine lokale Werksregel. Er ersetzt keine Norm, keinen Praxistest und keine Produktsichtung. Öffentliche Dokumentation zeigt, was beschrieben ist; aus fehlenden Angaben folgt nicht, dass eine Funktion fehlt oder dass jede Maschine dieselben Daten bereits liefern kann.
01 / PRAXISWISSEN
Der Datenvertrag für Stillstandsgründe
Wenn Sie nur einen Teil dieses Beitrags übernehmen, dann diesen: Definieren Sie einen Datenvertrag für Stillstandsgründe. Gemeint ist kein IT-Vertrag im juristischen Sinn, sondern ein eingefrorenes Regelwerk, nach dem Maschine, Bedienung, Schichtbericht und OEE-Auswertung dieselben Ereignisse gleich behandeln. Erst dadurch werden Minuten, Ursachen und Verantwortlichkeiten über Schichten und Maschinen hinweg vergleichbar.
Die methodische Basis ist klar: OEE.com trennt ausdrücklich zwischen Schedule Loss und OEE. OEE beginnt erst mit der Planned Production Time. Zusätzlich ordnet die OEE-Methodik Stopps oberhalb einer festgelegten Schwelle der Availability zu und kürzere Unterbrechungen als Small Stops der Performance. Lean Production beschreibt dieselbe Grundlogik über Availability, Performance und Quality.
Das folgende Muster ist absichtlich konkret formuliert. Sie können es als Startpunkt übernehmen und nur die eckigen Klammern lokal ausfüllen. Es ist keine universelle Normvorgabe für jedes Werk, sondern eine empfohlene Freigabevorlage. Genau diese Trennung ist wichtig: Eine dokumentierte OEE-Methodik erklärt Begriffe, aber sie legt nicht automatisch Ihre lokale Stop-Schwelle, Pausenregel oder Rüstpolitik fest.
Muster-Datenvertrag zum direkten Übernehmen
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Musterformulierung
Dieser Datenvertrag gilt für [Maschine/Linie/Bereich] und für Auswertungen zu Zustandszeiten, Stillstandsgründen und Verfügbarkeit.Lokal auszufüllen
Maschinenliste, Schichtmodell, verantwortliche RolleMusterformulierung
Planned Production Time ist Schichtzeit abzüglich der als Schedule Loss freigegebenen Zeiten. Nicht freigegebene Ausschlusszeiten dürfen nicht stillschweigend abgezogen werden.Lokal auszufüllen
Pausen, Meetings, Werksstillstände, auftragsfreie ZeitenMusterformulierung
Ereignisse ab [X Minuten/Sekunden] werden als Stop Time erfasst und der Availability zugeordnet. Kürzere Ereignisse werden als Small Stops geführt und der Performance zugeordnet.Lokal auszufüllen
Schwellenwert, Begründung, StartdatumMusterformulierung
Rüstzeit wird ausschließlich nach [letzte Gutteil bis erste Gutteil / letzte Gutteil bis erste konsistent gute Teile / Vollgeschwindigkeit bis Vollgeschwindigkeit] gemessen.Lokal auszufüllen
Eine Variante auswählen, Beispiele dokumentierenMusterformulierung
Zustand, Grundgruppe, konkreter Grund, Verantwortungsbereich und Datenquelle werden getrennt geführt. Eine offene Ursache bleibt als offene Ursache sichtbar.Lokal auszufüllen
Code-Liste, Verantwortliche, zulässige Fallback-CodesMusterformulierung
Technische Erfassungsunsicherheit wird als eigene QA-Klasse markiert und bis zur Klärung weder automatisch als Produktion noch als sicherer Stillstand gewertet.Lokal auszufüllen
Kennzeichen, Sperrlogik, ReferenzquelleMusterformulierung
Nachträgliche Korrekturen an Ursachen sind zulässig bis [Zeitfenster]. Zeitklasse und Dauer dürfen nur durch freigegebene Rollen geändert werden.Lokal auszufüllen
Rollen, Änderungsfrist, ProtokollierungMusterformulierung
Der Pilot wird nicht pauschal freigegeben. Freigaben erfolgen getrennt für Zustandszeiten, Stop-Schwelle, Gründe, Mengenbezug und vollständige OEE.Lokal auszufüllen
Freigabestufen, Sperrgründe, Review-TerminDie praktische Wirkung dieses Musters ist einfach: Es zwingt alle Beteiligten, dieselbe Sprache zu verwenden. Wenn Schichtleitung, Instandhaltung und Controlling den gleichen Stopp später unterschiedlich nennen, liegt das Problem oft nicht in der Technik, sondern in fehlenden Regeln. Ein sauberer Datenvertrag macht diese Unterschiede vor dem Rollout sichtbar, nicht erst nach der ersten Eskalation im Shopfloor-Meeting.
Pflichtbausteine für den Datenvertrag
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Was Sie festlegen
Welche Zeiten als Planned Production Time gelten und welche als Schedule Loss ausgeschlossen sindWarum es ohne diese Regel kippt
Sonst schwankt der OEE-Nenner je Schicht, obwohl der Prozess gleich bleibtWas Sie festlegen
Ab welcher Dauer ein Ereignis als Stop Time zählt und darunter als Small Stop geführt wirdWarum es ohne diese Regel kippt
Sonst wandern Minuten unbemerkt zwischen Availability und PerformanceWas Sie festlegen
Wie Rüstvorgänge beginnen und enden, zum Beispiel letzte Gutteil-zu-erste Gutteil-RegelWarum es ohne diese Regel kippt
Sonst wird dieselbe Umrüstung mal als Rüsten, mal als Leerlauf gebuchtWas Sie festlegen
Welche Klassen es gibt: Schedule Loss, geplanter Stopp, ungeplanter Stopp, Small Stop, Slow Cycle, DatenlückeWarum es ohne diese Regel kippt
Sonst entstehen Doppelzählungen und Sammelkategorien ohne NutzenWas Sie festlegen
Welche Angaben pro Ereignis erfasst werden müssen, etwa Grundgruppe, Verantwortungsbereich und DatenquelleWarum es ohne diese Regel kippt
Sonst fehlen genau die Informationen für Pareto, Schichtvergleich und MaßnahmenWas Sie festlegen
Wie Stichproben, Grenzfälle und Freigabekriterien geprüft werdenWarum es ohne diese Regel kippt
Sonst wird ein technisch laufendes Setup als fachlich belastbar missverstandenBezugszeit zuerst einfrieren
Die erste Entscheidung ist unspektakulär und trotzdem entscheidend: Wogegen messen Sie überhaupt? Nach der OEE-Methodik von OEE.com gehört Schedule Loss nicht zur OEE. Dazu zählen Zeiten ohne Produktionsabsicht, etwa Werksstillstände, Pausen oder Phasen ohne Auftrag. OEE startet erst bei der Planned Production Time. Wer diese Trennung nicht sauber dokumentiert, verändert den Nenner der Kennzahl.
Für Ihren Datenvertrag empfehle ich deshalb eine schlichte Freigabetabelle mit Schichtbeginn, Schichtende, Pausen, geplanten Meetings, Wartungsfenstern und einer klaren Entscheidung pro Kategorie: zählt zur OEE oder nicht. Das ist keine Behauptung darüber, wie andere Werke es lösen. Wichtig ist nur, dass Dashboard, Export, Schichtbericht und Verbesserungsrunde dieselbe Regel verwenden.
Die Stop-Schwelle ist keine Nebeneinstellung
Die zweite Entscheidung betrifft die Schwelle zwischen Availability und Performance. OEE.com zur OEE-Einführung formuliert das klar: Stopps, die die festgelegte Schwelle erreichen, werden als Stop Time erfasst und zählen als Availability Loss. Kürzere Ereignisse gelten als Small Stops und werden der Performance zugerechnet. OEE.com nennt dafür dokumentierte Startwerte von fünf Minuten bei manueller und zwei Minuten bei automatisierter Erfassung.
Diese Zahlen sind kein Naturgesetz. Sie sind ein dokumentierter Ausgangspunkt, nicht Ihre Pflichtkonfiguration. Für eine Linie mit langen Zyklen kann eine andere Schwelle sinnvoll sein als für eine schnelle Verpackung oder eine CNC mit wechselnden Bearbeitungszeiten. Entscheidend ist, dass Sie die Schwelle bewusst wählen, an realen Fällen testen und im Datenvertrag unverändert festschreiben.
Rüstvorgänge brauchen eine eindeutige Start- und Endregel
OEE.com ordnet Changeover Time ausdrücklich der Availability zu, sofern sie innerhalb der Planned Production Time liegt. Zusätzlich nennt OEE.com zur Umsetzung drei saubere Messpolitiken: letzte Gutteil bis erste Gutteil, letzte Gutteil bis erste konsistent gute Teile oder letzte Gutteil bei voller Geschwindigkeit bis erste Gutteil bei voller Geschwindigkeit.
Für den Datenvertrag reicht eine Entscheidung. Ich empfehle, nur eine Regel pro Werk oder wenigstens pro vergleichbarer Linie zuzulassen. Sobald eine Schicht nach „erste Gutteil“ und die andere nach „stabile Vollgeschwindigkeit“ bucht, verlieren Sie Vergleichbarkeit. Nicht die Dauer des Rüstens ist dann unklar, sondern die Definition des Rüstens selbst.
Zustand, Ursache und Verantwortung getrennt führen
Ein erfasster Maschinenzustand erklärt noch nicht seine Ursache. Genau diese Grenze benennt auch die Novo-AI-Lösungsseite zur Maschinendatenerfassung für Bestandsmaschinen: Akustik- und Schwingungssignale helfen, Maschinenzustände zu unterscheiden, aber Stillstandsgründe werden je nach Setup durch Bedienerrückmeldungen, Maschinenmeldungen oder weitere Daten ergänzt. Zustandserkennung und Ursachenbuchung sind also unterschiedliche Aufgaben.
Im Datenvertrag sollten Sie deshalb mindestens fünf Pflichtfelder trennen: Ereignisklasse, Grundgruppe, konkreter Grund, Verantwortungsbereich und Herkunft der Ursache. Herkunft kann etwa Bedienereingabe, Maschinenmeldung, Regelwerk oder unbekannt sein. Damit verhindern Sie, dass eine unsichere Ursache wie ein harter Fakt aussieht. Für spätere Maßnahmen ist diese Trennung nützlicher als ein scheinbar vollständiger, aber fachlich unklarer Störgrundkatalog.
Empfohlene Pflichtfelder pro stoppbezogenem Ereignis
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Beispiel
Ungeplanter StoppEmpfehlung für die Nutzung
Technische Oberklasse, unverzichtbar für OEE-ZuordnungBeispiel
Material, Werkzeug, Technik, Qualität, PlanungEmpfehlung für die Nutzung
Für Pareto-Auswertungen klein und stabil haltenBeispiel
Material fehlt, Werkzeugbruch, Freigabe wartetEmpfehlung für die Nutzung
Nur dort detaillieren, wo Maßnahmen daraus folgenBeispiel
Produktion, Instandhaltung, Logistik, Qualität, PlanungEmpfehlung für die Nutzung
Für Maßnahmensteuerung getrennt von der Ursache führenBeispiel
Bediener, Maschinenmeldung, Regel, automatisch unbekanntEmpfehlung für die Nutzung
Erkennt Unsicherheit statt sie zu versteckenBeispiel
Freitext nur bei AbweichungEmpfehlung für die Nutzung
Nur als Ergänzung, nicht als Ersatz für strukturierte Codes02 / PRAXISWISSEN
Ereignisbaum: So klassifizieren Sie Stillstände ohne Doppelzählung
Ein brauchbarer Ereignisbaum beantwortet jede Unterbrechung in derselben Reihenfolge. Nicht zuerst „Warum steht die Maschine?“, sondern zuerst: War die Anlage überhaupt zur Produktion eingeplant? Danach: Liegt die Dauer über oder unter der Stop-Schwelle? Erst danach kommt die Ursachenlogik. Diese Reihenfolge verhindert, dass Teams mit Ursachecodes einen Fehler im Zeitmodell kaschieren.
Der Grund für diese Reihenfolge liegt in der OEE-Logik selbst. OEE.com beschreibt Stopps in der Availability und Lean Production ordnet Small Stops und Slow Cycles der Performance zu. Wer zuerst Gründe einsammelt und erst danach den OEE-Faktor klärt, bucht dasselbe Ereignis je nach Bedienung mal als Ausfall und mal als Leistungseinbruch.
Muster-Ereignisbaum in fünf Fragen
Für den Shopfloor muss der Ereignisbaum schneller nutzbar sein als jede Grundsatzdiskussion. Deshalb lohnt sich eine feste Fünf-Fragen-Reihenfolge, die in Schichtleitfaden, Bedienoberfläche und Review-Routine identisch bleibt. Die Fragen unten sind absichtlich knapp formuliert. Sie zwingen erst die Zeitklassifikation und erst danach die Ursachenklassifikation.
- War Produktionsabsicht vorhanden? Wenn nein, liegt Schedule Loss oder eine andere ausgeschlossene Zeit vor. Dann darf das Ereignis nicht in die OEE-Verfügbarkeit eingehen.
- Erreicht der Stopp die dokumentierte Schwelle? Wenn ja, Stop Time und Availability. Wenn nein, Small Stop und Performance.
- Greift eine dokumentierte Rüst-, Reinigungs- oder Freigaberegel? Dann folgt die Zuordnung der festgelegten Policy und nicht dem Bauchgefühl der Schicht.
- Ist die Ursache gesichert oder offen? Gesicherte Ursachen werden codiert. Offene Ursachen bleiben offen und werden nicht geraten.
- Ist die Datengrundlage technisch belastbar? Wenn eine Erfassungslücke, ein Kommunikationsproblem oder eine unklare Sequenz vorliegt, wird der Zeitraum als QA-Fall markiert.
Empfohlene Taxonomie für Zeit- und Stoppereignisse
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Zuordnung
Nicht Teil der OEEBuchungsregel
Zeit ohne Produktionsabsicht, zum Beispiel Pause oder geplanter WerksstillstandPflichtfelder
Kalenderkategorie, Schicht, FreigaberegelZuordnung
AvailabilityBuchungsregel
Geplanter, aber produktionsrelevanter Stopp wie Rüsten oder notwendige Reinigung innerhalb der geplanten ProduktionszeitPflichtfelder
Grundgruppe, Start-End-Regel, VerantwortungsbereichZuordnung
AvailabilityBuchungsregel
Produktionsunterbrechung mit Dauer über der dokumentierten Stop-SchwellePflichtfelder
Grundgruppe, Ursache, Datenquelle, VerantwortungsbereichZuordnung
PerformanceBuchungsregel
Kurzer Stopp unterhalb der Schwelle; nicht als Stop Time, sondern als Small Stop behandelnPflichtfelder
Zählregel, Dauer, optional MusterkennungZuordnung
PerformanceBuchungsregel
Maschine läuft, aber unter der definierten ReferenzleistungPflichtfelder
Referenztakt, Ist-Takt, KontextZuordnung
QA-SperreBuchungsregel
Technische Unsicherheit, die nicht als Produktion und nicht als sicherer Stillstand gebucht wirdPflichtfelder
Technischer Status, Ursache offen, FreigabeentscheidungBei der Benennung der Gründe gilt: klein anfangen. OEE.com empfiehlt für Stop Reasons einen einfachen Start, eine Auffangkategorie und eindeutige Bezeichnungen. Das ist kein Plädoyer für grobe Daten, sondern für beherrschbare Daten. Zehn klare Gründe, die konsequent verwendet werden, bringen im Pilot mehr als vierzig Codes, die jede Schicht anders auslegt.
Praktisch heißt das: Führen Sie eine kleine, stabile Grundgruppe mit wenigen Untergründen ein und ergänzen Sie erst dann, wenn die Daten wirklich genutzt werden. Wenn Ihre Kategorie „Sonstiges“ im Review ständig dominiert, fehlt keine Softwarefunktion, sondern ein besserer Grundkatalog. Wenn sie selten vorkommt, erfüllt sie ihren Zweck als kontrollierte Auffangkategorie.
03 / PRAXISWISSEN
Muster für Grundkatalog und Buchungsregeln
Viele Rollouts scheitern nicht an der Erkennung eines Stopps, sondern an einem zu groben oder zu detaillierten Katalog. Ein direkt nutzbarer Startkatalog sollte klein bleiben, aber schon die typischen Maßnahmenwege abbilden: Material, Werkzeug, Technik, Qualität, Planung und offene Ursache. Die folgende Vorlage ist eine Empfehlung für den Start, nicht die Behauptung, dass alle Werke genau diese Struktur brauchen.
Direkt nutzbarer Startkatalog für Stillstandsgründe
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Startcodes
Material fehlt, falsches Material, MaterialstauWann verwenden
Wenn die Unterbrechung durch Materialverfügbarkeit oder Materialfluss ausgelöst wirdWas nicht vermischt werden sollte
Nicht mit technischer Zuführstörung vermischen, wenn die Maschine selbst die Ursache istStartcodes
Werkzeugwechsel, Werkzeugbruch, WerkzeugsucheWann verwenden
Wenn das Werkzeug direkt Auslöser oder Gegenstand des Stopps istWas nicht vermischt werden sollte
Nicht mit Rüstpolicy verwechseln; geplanter Wechsel und ungeplanter Defekt getrennt haltenStartcodes
Maschinenstörung, Sensorfehler, Antrieb/ElektrikWann verwenden
Wenn der Auslöser an Maschine, Peripherie oder Steuerung vermutet oder bestätigt istWas nicht vermischt werden sollte
Nicht mit offener Ursache füllen, wenn der technische Grund noch nicht gesichert istStartcodes
Freigabe fehlt, Nachprüfung, QualitätsabweichungWann verwenden
Wenn Produktion wegen Prüf- oder Qualitätsentscheidung unterbrochen istWas nicht vermischt werden sollte
Nicht mit Ausschussquote oder Gutmenge verwechseln; hier geht es um den StoppgrundStartcodes
Kein Auftrag, Personal fehlt, Folgeauftrag wartetWann verwenden
Wenn der Produktionsfluss organisatorisch blockiert ist und nicht technischWas nicht vermischt werden sollte
Nicht als Schedule Loss buchen, wenn die Zeit innerhalb der Planned Production Time liegtStartcodes
Ursache offen, Klärung läuftWann verwenden
Wenn ein Stopp sicher vorliegt, die Ursache aber nicht belastbar feststehtWas nicht vermischt werden sollte
Nicht mit Freitext ersetzen; offene Ursache soll als eigener Auswertungsfall sichtbar bleibenZusätzlich zum Katalog brauchen Sie drei Codierregeln. Erstens bekommt jedes Ereignis genau eine Zeitklasse. Zweitens bekommt jedes Ereignis genau eine primäre Grundgruppe, auch wenn im Kommentar weitere Hinweise ergänzt werden. Drittens wird die Datenquelle separat geführt. Nur so können Sie später unterscheiden, ob ein Grund aus einer Bedienerrückmeldung, aus einer Maschinenmeldung oder aus einem nachträglichen Review stammt.
Wenn bei Ihrer Maschine nur Zustandswechsel vorliegen, prüfen Sie vor dem OEE-Rollout, ob der geplante Einsatz überhaupt Ursachenklassen verlangt oder zunächst nur belastbare Zustandszeiten. Genau diese Trennung beschreibt auch die Novo-Seite zur Maschinendatenerfassung für Bestandsmaschinen: Zustandserfassung allein ist nicht automatisch vollständige OEE und erklärt noch keinen sicheren Stillstandsgrund.
04 / PRAXISWISSEN
Die heiklen Grenzfälle, die Ihre Zahlen kippen
Die eigentliche Arbeit beginnt nicht bei offensichtlichen Ausfällen, sondern bei Grenzfällen. Dort entstehen spätere Diskussionen über „falsche“ OEE-Werte, obwohl in Wahrheit nur die Klassifikationsregeln unklar waren. Wenn Sie diese Fälle vor dem Rollout festlegen, sparen Sie sich Nachkalibrierung und Misstrauen in die Daten. Vier Fallgruppen sollten deshalb in jedem Pilot bewusst geprüft werden.
Grenzfall 1: Mikrostopps in Serienfolge
Mehrere kurze Unterbrechungen hintereinander sind ein klassischer Konfliktfall. Fachlich bleibt der Kern einfach: Liegt jedes einzelne Ereignis unter Ihrer Stop-Schwelle, gehört es als Small Stop zur Performance und nicht zur Availability, solange Sie keine andere dokumentierte Merge-Regel beschlossen haben. Diese Logik stützen OEE.com und Lean Production.
Wenn Sie aufeinanderfolgende Kurzunterbrechungen zusammenfassen wollen, schreiben Sie die Merge-Regel ausdrücklich auf. Legen Sie fest, innerhalb welchen Zeitabstands zusammengeführt wird und ob dafür derselbe Zustand oder dieselbe Ursache vorliegen muss. Ohne diese Dokumentation entstehen aus demselben Rohereignis zwei verschiedene Verlustbilder, je nachdem welcher Bericht oder welche Schicht den Stopp später betrachtet.
Grenzfall 2: Auftragswechsel ohne physischen Maschinenstopp
Ein Auftragswechsel beginnt fachlich nicht automatisch mit einer ERP-Buchung. Wenn die Maschine noch produktiv läuft, aber der neue Auftrag schon eröffnet wurde, darf dieselbe Zeit nicht zugleich dem alten und dem neuen Auftrag gehören. Für OEE und Verfügbarkeit reicht deshalb keine reine Auftragslogik. Sie brauchen eine zusätzliche Regel, wie der Auftragsbezug mit dem realen Maschinenzustand geschnitten wird.
Gerade bei Changeover lohnt sich eine einzige betriebsweite Definition. OEE.com zeigt, dass schon die Wahl zwischen „erste Gutteil“ und „stabil gute Teile“ die gemessene Dauer verändert. Für Ihre Praxis heißt das: Der Auftragswechsel braucht dieselbe Grenzdefinition wie der Rüstvorgang, sonst stimmen Auftragszeit, Rüstzeit und Verlustzeit nicht mehr zusammen.
Grenzfall 3: Erkannter Stopp, aber unsichere Ursache
Ein unsicherer Grund ist kein Sonderfall, sondern ein eigener Datenzustand. Die schlechteste Lösung ist, Bediener oder Teamleiter zu einer exakten Ursache zu zwingen, obwohl nur klar ist, dass ein Stopp vorlag. Besser ist ein sauberer Fallback-Code wie „Ursache offen“ oder „weitere Klärung nötig“. So bleibt die Zeit richtig erfasst, ohne eine Scheingenauigkeit in die Pareto-Analyse zu tragen.
Diese Empfehlung passt auch zu den öffentlich dokumentierten Arbeitsweisen anderer Anbieter. Auf der Seite zu Factbird Operator View wird beschrieben, dass Ereignisse umklassifiziert, geteilt, zusammengeführt, kommentiert und in der Dauer korrigiert werden können. Das ist kein Qualitätsurteil über die Gesamtplattform, aber ein nützlicher Hinweis: Ursachenklassifikation ist ein korrigierbarer Workflow und nicht bloß ein einmaliger Klick im Stoppmoment.
Grenzfall 4: Datenlücke oder echter Stillstand
Wenn Ihr Erfassungssystem kurz ausfällt, ist fachlich nicht automatisch klar, ob die Maschine lief oder stand. Genau deshalb empfehle ich eine eigene technische Klasse für Erfassungsunsicherheit. Diese Minuten gehören nicht stillschweigend in Produktion, aber auch nicht automatisch in ungeplante Stopps. Sie gehören zunächst in die QA-Prüfung, bis eine Referenzquelle oder Gegenprobe den Zustand plausibel macht.
Der Vorteil dieser Trennung ist operativ und nicht kosmetisch. Sobald technische Lücken als echte Prozessereignisse verbucht werden, verschieben Sie Verantwortlichkeiten. Aus einem Kommunikationsproblem wird dann scheinbar ein Fertigungsproblem. Für Verbesserungsmaßnahmen ist das riskant, weil Teams an der falschen Stelle reagieren und ihre Pareto-Liste auf einer unsicheren Datenbasis priorisieren.
05 / PRAXISWISSEN
Stillstandsgründe erfassen in fünf Schritten
Der sauberste Datenvertrag bleibt wirkungslos, wenn er nicht in einen Pilot, eine Buchungsroutine und eine Abnahme übersetzt wird. Deshalb folgt jetzt kein Strategieteil, sondern ein direkt anwendbarer Ablauf. Die Schritte sind plattformneutral formuliert. Wenn Sie mit externer Sensorik arbeiten möchten, kann die Novo-Seite zur Maschinendatenerfassung für Bestandsmaschinen als technischer Einstieg dienen; die Klassifikationslogik bleibt davon getrennt.
Schritt 1: Pilotgrenze und OEE-Zweck festlegen
Starten Sie mit einer Maschine, Zelle oder Linie und schreiben Sie einen Freigabesatz. Beispiel: „Für Maschine X werden Zustandszeiten, Stoppschwelle und Stillstandsgründe für Schichtvergleich und Verfügbarkeitsanalyse freigegeben; vollständige OEE bleibt gesperrt, bis Mengen- und Qualitätsquellen freigegeben sind.“ Dieser Satz verhindert, dass ein nützlicher Pilot vorschnell als vollständiges OEE-System verkauft wird.
Erwartetes Ergebnis ist ein klarer Scope statt eines diffusen Digitalisierungsprojekts. Verifizieren können Sie den Schritt, indem alle Beteiligten dieselbe Frage beantworten: Welche Entscheidung soll mit diesen Daten verbessert werden? Wenn Produktion, Instandhaltung und Controlling drei verschiedene Antworten geben, ist der Pilot noch nicht sauber definiert. Ein guter Pilot löst zuerst eine konkrete Entscheidungsfrage, nicht alle KPI-Probleme zugleich.
Schritt 2: Zeitmodell und Stop-Schwelle schriftlich freigeben
Im zweiten Schritt frieren Sie Kalender, Pausen, geplante Ausschlusszeiten, Stop-Schwelle und Changeover-Policy ein. Nutzen Sie reale Beispielereignisse aus Ihrer Linie und buchen Sie sie gemeinsam trocken durch. Dabei sollte jede Person zum selben Ergebnis kommen: Schedule Loss, Availability, Performance oder technische Datenlücke. Genau daran zeigt sich, ob Ihre Regeln verständlich genug sind.
Das erwartete Ergebnis ist nicht Perfektion, sondern Eindeutigkeit. Verifizieren können Sie mit einer Blindprobe von zehn Ereignissen, davon mindestens zwei knapp unter und zwei knapp über der Stop-Schwelle. Wenn dieselben zehn Fälle unterschiedlich klassifiziert werden, ist nicht das Team das Problem, sondern die Regelbeschreibung. Erst wenn diese Trockenübung stabil ist, lohnt sich die technische Instrumentierung.
Schritt 3: Ereignisbaum und Pflichtfelder im Shopfloor nutzbar machen
Jetzt übersetzen Sie die Regeln in die operative Oberfläche oder in den Buchungsprozess. Ob Sie mit Sensorik, Maschinenmeldungen oder Bedienereingaben arbeiten, ist zweitrangig. Entscheidend ist, dass ein Ereignis mit denselben Pflichtfeldern endet. Wenn eine Ursache offen bleibt, muss das zulässig sein. Wenn ein geplanter Stopp vorliegt, muss die Changeover-Policy automatisch oder prozessual greifen.
Das erwartete Ergebnis ist ein Prozess, der im Schichtalltag nicht mehr Begriffe verwendet als im Datenvertrag. Verifizieren können Sie diesen Schritt, indem Sie fünf reale Ereignisse vom Erkennen bis zur Auswertung verfolgen. Tauchen dabei neue, ungeplante Kategorien oder Freitextnotizen als Ersatz für Pflichtfelder auf, ist der Prozess noch nicht freigabefähig. Dann müssen nicht die Bediener strenger werden, sondern die Prozessdefinition klarer.
Schritt 4: Zwei Wochen Parallelbetrieb mit Referenzprotokoll
Führen Sie den Pilot zunächst im Parallelbetrieb. Das automatische oder halbautomatische System erfasst Zustände und Stopps; daneben läuft ein knappes Referenzprotokoll mit bewusst ausgewählten Grenzfällen. Ziel ist nicht Vollerhebung per Hand, sondern Gegenprüfung an den Stellen, an denen Fehlklassifikationen die Kennzahlen verschieben würden: um die Stop-Schwelle herum, bei Rüstvorgängen, an Schichtgrenzen und bei offenen Ursachen.
Erwartetes Ergebnis ist eine Liste echter Abweichungen statt allgemeiner Bauchgefühle. Verifizieren können Sie, indem Sie pro Abweichung genau benennen können, ob das Problem im Zeitmodell, in der Stop-Schwelle, in der Bedienlogik oder in der technischen Erfassung liegt. Nur dann lässt sich der Pilot fachlich verbessern, statt bloß das Dashboard umzubenennen oder die KPI nachträglich weichzuzeichnen.
Schritt 5: Abnahme mit Freigabegrenzen statt mit Ja/Nein
Am Ende des Piloten empfehle ich keine pauschale Freigabe „läuft“. Besser sind Freigabestufen. Beispiel: Zustände freigegeben, Stop-Schwelle freigegeben, Ursachecodes eingeschränkt freigegeben, vollständige OEE noch nicht freigegeben. Diese abgestufte Logik passt auch zur Novo-Dokumentation, die ausdrücklich zwischen Zustandserfassung und vollständiger OEE unterscheidet.
Das erwartete Ergebnis ist eine ehrliche Nutzungsfreigabe. Verifizieren können Sie den Schritt mit einem Abnahmeprotokoll, das jede Datenfrage einzeln freigibt oder sperrt. Genau das verhindert, dass aus einem belastbaren Stillstandsmonitoring voreilig eine scheinbar exakte Gesamtanlageneffektivität abgeleitet wird. Eine begrenzte Freigabe ist kein Makel, sondern eine fachlich saubere Aussage über den aktuellen Reifegrad.
06 / PRAXISWISSEN
Abnahmeprotokoll für die Datenqualität
Die Abnahme einer Stillstands-Taxonomie prüft nicht nur, ob Ereignisse irgendwo sichtbar sind. Sie prüft, ob dieselbe physische Realität in derselben Minute zur selben Klasse und zum selben Grund führt. Das klingt streng, ist aber der Punkt, an dem operative Daten verlässlich werden. Ohne diese Gegenprobe bleibt die Klassifikation ein gutes Konzeptpapier, aber noch kein belastbares Steuerungsinstrument.
Ich empfehle eine Stichprobe mit dokumentierten Testfällen aus mindestens sechs Situationen: geplanter Ausschluss, Rüstvorgang, langer ungeplanter Stopp, Small Stop unter Schwelle, offene Ursache und technische Datenlücke. Jede Situation sollte mindestens einmal gemeinsam durch Beobachtung und Datensatz geprüft werden. Ziel ist nicht statistische Repräsentativität, sondern fachliche Widerlegung der größten Fehlerquellen im Pilot.
Musterkopf für Ihr Abnahmeprotokoll
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Einzutragende Angabe
[Maschine/Linie/Bereich]Einzutragende Angabe
[z. B. Verfügbarkeitsanalyse, Schichtvergleich, Stillstandsgründe]Einzutragende Angabe
[z. B. vollständige OEE, Mengenbezug, Qualitätsbezug]Einzutragende Angabe
Beobachterprotokoll, Schichtkalender, Export der Zustandsdaten, BedienerkommentareEinzutragende Angabe
Dokumentierte Planned Production Time, Stop-Schwelle, Changeover-PolicyEinzutragende Angabe
Unklare Zeitbasis, widersprüchliche Schichtlogik, unmarkierte Datenlücken, abweichende Stop-SchwelleEinzutragende Angabe
Freigegeben / eingeschränkt freigegeben / gesperrtEmpfohlenes Abnahmeprotokoll für die Klassifikation
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
So testen Sie
Mehrere Ereignisse knapp unter und knapp über der Schwelle beobachtenFreigabekriterium
Dieselben Ereignisse landen reproduzierbar in Performance oder AvailabilityWenn nicht bestanden
Schwelle oder Entprelllogik prüfen und Blindprobe wiederholenSo testen Sie
Einen kompletten Rüstvorgang mit dokumentiertem Start- und Endpunkt begleitenFreigabekriterium
Start und Ende folgen exakt der festgelegten PolicyWenn nicht bestanden
Policy nachschärfen oder automatische/organisatorische Auslösung korrigierenSo testen Sie
Einen Stopp ohne sichere Diagnose prüfenFreigabekriterium
Die Zeit wird korrekt erfasst, ohne falschen ZwangscodeWenn nicht bestanden
Fallback-Code einführen oder Benutzerführung anpassenSo testen Sie
Erfassungsunterbrechung oder Kommunikationsproblem kontrolliert prüfenFreigabekriterium
Der Zeitraum wird als technische Unsicherheit erkennbar, nicht als Produktion kaschiertWenn nicht bestanden
QA-Sperrlogik definieren und Exportkennzeichnung ergänzenSo testen Sie
Ereignisse kurz vor und nach der Schichtgrenze vergleichenFreigabekriterium
Schicht- und Kalenderlogik bleibt konsistentWenn nicht bestanden
Kalender- oder Auftragszuordnung korrigierenSo testen Sie
Mehrere Bediener klassifizieren gleiche BeispielereignisseFreigabekriterium
Grundgruppe und Verantwortungsbereich werden einheitlich verwendetWenn nicht bestanden
Katalog vereinfachen, Schulung wiederholen, Beispiele ergänzenZur Freigabe gehört außerdem eine klare Regel für Änderungen nachträglich klassifizierter Ereignisse. Gerade wenn Gründe später ergänzt oder korrigiert werden, brauchen Sie Versionsdisziplin: Wer darf ändern, welche Felder sind änderbar und wie lange nach Schichtende? Ohne diese Regel leidet nicht nur die Datenqualität, sondern auch die Nachvollziehbarkeit in Maßnahmenrunden und Schichtvergleichen.
Wenn Ihr Schwerpunkt zunächst auf Zustands- und Stillstandstransparenz liegt, ist das kein Nachteil. In der dokumentierten Novo-Lösung für Bestandsmaschinen wird ausdrücklich empfohlen, im Pilot Erkennung und Datenqualität zu prüfen, bevor weitere Anlagen angebunden werden. Diese Reihenfolge ist vernünftig: erst fachlich belastbar, dann skalieren. Wer umgekehrt zuerst skaliert, verbreitet unklare Regeln nur schneller.
07 / PRAXISWISSEN
Dokumentationsvergleich: Novo AI und Factbird
Der folgende Vergleich ist ein Dokumentationsvergleich, kein eigener Praxistest. Quellen sind die öffentliche Novo-Seite zur Maschinendatenerfassung und die öffentliche Factbird-Seite zu Operator View. Novo AI veröffentlicht diesen Beitrag und ist selbst Anbieter. Deshalb vergleiche ich nur öffentlich dokumentierte Aussagen und markiere fehlende öffentliche Angaben als unbekannt, nicht als fehlende Funktion.
Öffentlich dokumentierte Aussagen zur Erfassung und Klassifikation von Stillstandsgründen
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Novo AI WatchMen
Dokumentiert: externe Sensorik; Akustik und Vibration helfen, Maschinenzustände zu unterscheidenFactbird Operator View
Öffentlich auf dieser Seite nicht dokumentiert; die Seite beschreibt primär die BedienoberflächeNovo AI WatchMen
Dokumentiert: Gründe werden je nach Setup durch Bedienerrückmeldungen, Maschinenmeldungen oder weitere Daten ergänztFactbird Operator View
Dokumentiert: Stopps werden im Arbeitsfluss erfasst, klassifiziert und mit Reason Codes geführtNovo AI WatchMen
Öffentlich auf dieser Seite nicht dokumentiertFactbird Operator View
Dokumentiert: umklassifizieren, teilen, zusammenführen, Notizen ergänzen und Dauer korrigierenNovo AI WatchMen
Öffentlich auf dieser Seite nicht dokumentiertFactbird Operator View
Dokumentiert: Best-Practice-Vorlage für Stillstandsursachen und beschriebene HierarchieNovo AI WatchMen
Dokumentiert: Zustandszeiten, Verfügbarkeit und Voraussetzungen für vollständige OEE werden beschriebenFactbird Operator View
Dokumentiert: Live-Produktionszeitachse und OEE in Echtzeit werden genanntAus diesem Quellenstand ergibt sich kein Gesamtsieger. Wenn Ihr vorrangiges Problem Brownfield-Transparenz an Bestandsmaschinen ohne direkten SPS-Zugriff ist, ist bei Novo öffentlich genau dieser Einstieg dokumentiert. Wenn Ihr vorrangiges Problem eine öffentlich beschriebene Operator-Oberfläche für Stoppgründe, Korrekturen und Reason Codes ist, ist das auf der Factbird-Seite deutlich konkreter beschrieben.
Wichtig ist die Grenze des Vergleichs: Aus einer öffentlichen Seite folgt nicht, wie gut ein Prozess in Ihrem Werk funktioniert. Ebenso folgt aus einer nicht dokumentierten Angabe nicht, dass eine Funktion fehlt. Für die Auswahl heißt das praktisch: erst den eigenen Datenvertrag definieren, dann prüfen, welche Plattform Ihre notwendige Klassifikationslogik öffentlich oder im Pilot nachvollziehbar abdeckt.
08 / PRAXISWISSEN
Beispielrechnung: wie die Stop-Schwelle Ihre Verfügbarkeit verändert
Die folgende Rechnung ist ausdrücklich ein Annahmebeispiel, kein Kundenergebnis. Sie soll nur zeigen, warum die Stop-Schwelle in den Datenvertrag gehört. Grundlage ist eine Acht-Stunden-Schicht mit 480 Minuten Anwesenheitszeit, davon 30 Minuten Pause als Schedule Loss. Damit bleiben 450 Minuten Planned Production Time. Innerhalb dieser 450 Minuten fallen 40 Minuten Changeover, 25 Minuten ungeplanter Stopp und 12 Minuten Small Stops an.
Annahmebeispiel zur Stop-Schwelle
Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.
Formel oder Regel
gegebenWert
480 minFormel oder Regel
Pausen, nicht Teil der OEEWert
30 minFormel oder Regel
480 - 30Wert
450 minFormel oder Regel
Changeover 40 + ungeplanter Stopp 25Wert
65 minFormel oder Regel
450 - 65Wert
385 minFormel oder Regel
unterhalb der Schwelle, daher PerformanceWert
12 minFormel oder Regel
385 - 12Wert
373 minFormel oder Regel
385 / 450Wert
85,56 %Formel oder Regel
373 / 450Wert
82,89 %Formel oder Regel
85,56 - 82,89Wert
2,67 ProzentpunkteDie Aussage ist nicht, dass kleine Stopps unwichtig wären. Im Gegenteil: Lean Production ordnet Small Stops und Slow Cycles ausdrücklich der Performance zu. Die Minuten verschwinden also nicht, wenn Sie sie nicht als Availability zählen. Sie werden nur dem richtigen Verlustmechanismus zugeordnet. Genau das macht spätere Maßnahmen präziser und verhindert Scheindiskussionen über eine künstlich gedrückte oder geschönte Verfügbarkeit.
Für Ihre Praxis ist die Folge einfach: Wenn Teams über Verfügbarkeitsverluste sprechen, müssen sie wissen, ob darin Small Stops enthalten sind oder nicht. Sonst vergleichen Sie Kennzahlen, die gleich heißen, aber fachlich unterschiedlich gebildet wurden. Eine gut dokumentierte Stop-Schwelle schützt deshalb nicht nur die OEE-Formel, sondern vor allem die Verständigung zwischen Shopfloor, Instandhaltung und Controlling.
09 / PRAXISWISSEN
Was Sie aus einer Fallstudie ableiten dürfen – und was nicht
Die Fallstudie zum CNC-Monitoring in der Industrieausrüstungsfertigung ist für dieses Thema hilfreich, weil sie den praktischen Nutzen sichtbarer Zeitverluste zeigt: Leerlauf, Mikrostopps, Rüstverluste und Stillstände werden dort als eigene Betrachtungsobjekte im Maschinenpark benannt. Genau diese Trennung ist auch für einen sauberen Datenvertrag wichtig.
Was Sie daraus nicht ableiten sollten, ist eine pauschale Leistungszusage für Ihr Werk. Die Fallstudie weist selbst darauf hin, dass detaillierte Zeit- und OEE-Werte Modellrechnungen auf Basis dokumentierter Annahmen sind. Für die Taxonomie bedeutet das: Eine Fallstudie kann zeigen, welche Verlustarten sichtbar gemacht werden sollen. Sie ersetzt aber nicht Ihre lokale Definition von Stop-Schwelle, Changeover und Ursachenklassen.
Der richtige Transfer lautet deshalb: Nutzen Sie Fallstudien, um die relevanten Verlustarten zu sehen, aber bauen Sie Ihre Klassifikationslogik aus Ihrem Schichtkalender, Ihren Auftragswechseln und Ihren QA-Regeln. Erst dann wird aus anschaulicher Transparenz eine belastbare Datengrundlage für Entscheidungen. Genau an dieser Stelle helfen der Muster-Datenvertrag und das Abnahmeprotokoll aus diesem Beitrag weiter.
10 / PRAXISWISSEN
Fazit
Stillstandsgründe erfassen heißt operativ nicht zuerst mehr Gründe sammeln, sondern zuerst bessere Regeln setzen. Wenn Bezugszeit, Stop-Schwelle, Changeover-Policy, Pflichtfelder und Abnahmeprüfung feststehen, werden MDE- und OEE-Daten belastbar. Wenn diese Regeln fehlen, liefern auch gute Sensorik und schöne Dashboards nur schwer vergleichbare Minuten.
Mein Rat für den Start ist schlicht: Übernehmen Sie das Muster aus diesem Beitrag, füllen Sie es für eine Pilotmaschine konkret aus und testen Sie es an realen Grenzfällen. Geben Sie dann nicht „die Plattform“, sondern konkrete Datenfragen frei. Genau so wird aus Stillstandserfassung ein Steuerungsinstrument statt ein weiterer Zahlenfriedhof.
11 / PRAXISWISSEN
Freigabecheck für Ihre Stillstands-Taxonomie
Haken Sie ab, was Sie bereits geklärt haben. Die Auswahl bleibt nur während dieses Seitenbesuchs bestehen.
12 / PRAXISWISSEN
Weiterführende Fragen
Nicht jede geplante Zeit gehört zur OEE. Laut OEE-Methodik wird Schedule Loss ausgeschlossen, OEE beginnt erst mit der Planned Production Time. Liegt ein Rüstvorgang innerhalb dieser geplanten Produktionszeit, wird er als Availability Loss behandelt. Entscheidend ist daher zuerst Ihre dokumentierte Zeitgrenze zwischen ausgeschlossener Zeit und geplanter Produktionszeit.
Die Zeit sollte trotzdem korrekt erfasst werden. Statt einen scheinbar exakten Grund zu erzwingen, ist ein eigener Status wie „Ursache offen“ sinnvoll. Zusätzlich sollte dokumentiert werden, aus welcher Quelle die Ursache stammt, etwa Bedienereingabe, Maschinenmeldung oder nachträgliche Klärung.
Nein, nicht automatisch. Öffentlich dokumentiert Novo AI, dass externe Signale Maschinenzustände unterscheiden helfen, Stillstandsgründe aber je nach Setup durch Bedienerrückmeldungen, Maschinenmeldungen oder weitere Daten ergänzt werden. Zustand und Ursache sollten deshalb im Datenvertrag getrennt behandelt werden.
Nur wenn Sie dafür eine dokumentierte Merge-Regel festgelegt haben. Ohne diese Regel sollten Ereignisse nach der definierten Stop-Schwelle klassifiziert werden. Sonst entstehen aus denselben Rohdaten je nach Bericht unterschiedliche Verlustbilder.
So sieht die Umsetzung in der Praxis aus
Vertiefen Sie den konkreten Anwendungsfall, die Messgrundlage und die Grenzen anhand einer veröffentlichten Novo-AI-Fallstudie.
