Wichtigste Erkenntnisse
Siehe die Arten von Arbeitsaufträgen, die diese Warnungen erzeugen sollten.
In einer typischen Anlage überwacht das OEE‑System die Linie und das CMMS das Asset. Beide sehen „Ausfallzeiten“, aber jede Seite sieht eine andere Version davon. Das OEE‑System erfasst jeden Stillstand über einer bestimmten Schwelle. Die Instandhaltung erfasst nur die, die zu Arbeitsaufträgen wurden.
Die Lücke zwischen diesen beiden Zahlen, in der Regel 20 % bis 40 % der gesamten Ausfallzeit, ist der Bereich, in dem kleine wiederkehrende Verluste liegen. Genau dort steckt auch der Großteil der erzielbaren Verbesserung.
Der Grund für diese Lücke ist nicht, dass ein Team die falsche Arbeit macht. Es ist, dass die beiden Systeme keine gemeinsame Definition dafür haben, „dieser Stillstand benötigt einen Arbeitsauftrag“. Der Bediener entscheidet, der Schichtleiter entscheidet, manchmal entscheidet niemand, und die Regeln driftieren Schicht für Schicht. Ein Instandhaltungs‑Betriebsmodell ist die Menge expliziter Regeln, die jedes OEE‑Ereignis in ein binäres Ergebnis verwandeln: ein Arbeitsauftrag wird eröffnet, oder nicht.
Ein OEE‑System ohne eine saubere Verlustklassen‑Taxonomie ist nur ein Summenzähler. Das Betriebsmodell beginnt damit, jeden Stillstand in eine stabile Menge von Klassen zu überführen, üblicherweise sieben bis zehn. Häufige Klassen: Rüsten/Formatwechsel, Mikrostillstand, kleinere mechanische Störung, elektrisch/Sensor, Materialmangel, Qualitätsausschuss, geplanter Überlauf, bedienerbedingt.
Die genaue Liste ist weniger wichtig als die Tatsache, dass überall, in jeder Schicht und an jeder Linie dieselbe Liste verwendet wird. Der Beitrag zu Manufacturing‑KPIs behandelt die zugrunde liegenden KPI‑Familien, in die diese Taxonomie eingebettet ist.
Jede Klasse braucht eine Regel: ab welcher Dauer oder Häufigkeit wird dieses Ereignis zu einem Arbeitsauftrag? Die Schwellenwerte sind am ersten Tag fast immer falsch und werden in den Wochen zwei bis sechs angepasst. Wichtig ist, dass die Regel existiert und sichtbar ist. Beispiele typischer Anfangsschwellen:
Cluster‑Schwellenregeln („3 Mal in 8 Stunden“) fangen tendenziell die kleinen wiederkehrenden Verluste auf, die Einzelereignis‑Schwellen übersehen. Sie sind die Regelart mit dem höchsten Ertrag, die man hinzufügen kann.
Jede Verlustklasse hat eine benannte verantwortliche Person, nicht eine Abteilung. Kleinere mechanische Störungen und elektrische Probleme gehen an den Instandhaltungsleiter. Rüsten und bedienerbedingte Ausfälle gehen an den Produktionsleiter. Materialmangel geht an den Planer. Qualitätsausschuss geht an den Qualitätsmanager. Der Verantwortliche führt nicht unbedingt die Reparatur aus, aber er verantwortet den Trend und die Schwelle. Wenn eine Klasse die Schwelle überschreitet, handelt der Verantwortliche zuerst.
Die wichtigste und am häufigsten übersprungene Regel. Wenn ein OEE‑Ereignis automatisch einen Arbeitsauftrag öffnet, müssen in derselben Minute zwei Dinge passieren: Der Instandhaltungstechniker sieht den Arbeitsauftrag auf einem mobilen Gerät, und der OEE‑Datensatz wird mit dem Arbeitsauftrag verknüpft, sodass der Abschluss zurückfließt.
Ohne diese Zwei‑Wege‑Verknüpfung degeneriert das Betriebsmodell innerhalb eines Quartals zu „OEE erzeugt Lärm, CMMS ignoriert ihn“. Ein feldtaugliches CMMS auf dem Telefon des Technikers ist das, was das möglich macht. Der Artikel zu Work‑Order‑Management‑Systemen geht tiefer auf die beteiligten Komponenten ein.
Da Cluster‑Schwellen denselben Fehler drei Mal auslösen, bevor ihn jemand bemerkt hätte, erscheinen die kleinen wiederkehrenden Verluste, die derzeit unsichtbar sind, im Instandhaltungs‑Backlog mit einem realen Behebungsweg. Die meisten Anlagen stellen fest, dass diese Kategorie allein nach ihrer Offenlegung oft einen großen Anteil, häufig 15, 25 %, der ungeplanten Ausfallzeit ausmacht. Eine tiefere Behandlung finden Sie in unserem Artikel zur Ursachenanalyse in der Fertigung.
Wenn jedes relevante OEE‑Ereignis zu einem Arbeitsauftrag wird, sieht das CMMS endlich die vollständige Population von Fehlern. MTBF und MTTR beginnen, die Realität zu widerspiegeln, statt nur die Teilmenge, die Bediener oder Vorgesetzte zur Eskalation ausgewählt haben. Die Folge ist, dass vorbeugende Wartungspläne gegen reale Ausfalldaten statt gegen Herstellerempfehlungen optimiert werden können.
Weil das OEE‑Ereignis und der Arbeitsauftrag eine gemeinsame ID teilen, sehen Produktionsleiter und Instandhaltungsleiter dieselbe Zeile. Das Morgenmeeting wird von „wessen Zahl ist richtig“ zu „welche Verlustklasse hat sich letzte Woche verschoben“. Diese einzelne Veränderung ist der operationale Schlüssel, den die meisten mittelständischen Anlagen suchen, wenn sie ein OEE‑System anschaffen, und sie kommt fast nie nur aus der OEE‑Software alleine.
Ein häufiger Fehler ist, beim Go‑Live 30 Auslöse‑Regeln auszurollen. Die Hälfte ist falsch, alle erzeugen Lärm, das Instandhaltungsteam deaktiviert die Integration in Woche drei. Beginnen Sie mit fünf oder sechs Regeln. Fügen Sie wöchentlich eine weitere hinzu, basierend darauf, was fehlt.
Wenn der Arbeitsauftrag geschlossen wird, der OEE‑Eintrag aber im Verlustregister „offen“ bleibt, driften OEE‑Zahlen und CMMS‑Zahlen wieder auseinander, manchmal innerhalb weniger Wochen. Der Abschluss muss in beide Richtungen fließen. Hier scheitern viele zusammengekoppelte OEE‑plus‑CMMS‑Stacks in der Praxis.
Wenn eine Klasse einen Arbeitsauftrag auslöst, aber kein benannter Verantwortlicher den Trend überwacht, wird der Arbeitsauftrag erledigt, der Verlust tritt erneut auf und nichts ändert sich. Der benannte Verantwortliche ist das, was Volumen in Verbesserung verwandelt.
Das oben beschriebene Betriebsmodell lässt sich in jedem gut instrumentierten Stack implementieren, aber der praktische Grund, warum mittelständische Anlagen damit kämpfen, ist, dass ein OEE‑Tool und ein separates CMMS nur selten eine saubere Ereignis/Arbeitsauftrag‑Verknüpfung teilen.
Fabrico wurde genau um diese Übergabe herum aufgebaut: Jedes OEE‑Ereignis lebt in derselben Datenbank wie die Arbeitsaufträge, die Asset‑Hierarchie und die Verlusttaxonomie, sodass die Auslöse‑Regeln und Schließungswege standardmäßig existieren statt als kundenspezifische Integration.
Wenn Sie sehen möchten, wie ein einheitliches Modell an Ihren eigenen Liniedaten aussieht, buchen Sie eine Demo und wir führen Sie durch die Daten.
Nein, aber das Schließungs‑Pfad‑Problem ist schwer sauber über zwei getrennte Systeme zu lösen. Anlagen mit geteilten Stacks brauchen in der Regel eine Middleware‑Schicht oder einen manuellen Abgleichsschritt, der sich innerhalb eines Quartals auflöst. Eine einheitliche Plattform eliminiert dieses Risiko.
Fünf oder sechs. Die Versuchung ist, am ersten Tag jede Regel zu definieren; die Realität ist, dass die meisten Regeln 4, 6 Wochen echte Daten brauchen, bevor die Schwelle stimmt. Eine kleine Anfangsmenge, die im ersten Quartal abgestimmt wird, ist besser als ein vollständiges Set, das kalt ausgerollt wird.
Betrieblich der Anlagenleiter. Der Instandhaltungsleiter und der Produktionsleiter sind jeweils für Klassen verantwortlich. Ohne einen einzelnen, anlagenweiten Eigentümer des Modells selbst driften die Schwellenwerte, die benannten Verantwortlichen rotieren ohne Übergabe und das Modell verfällt.
Anfangs sehr wenig. Der Bediener protokolliert Stillstände wie bisher. Was sich ändert, ist, dass das System jetzt entscheidet, ob jeder Stillstand zu einem Arbeitsauftrag wird, sodass der Bediener diese Entscheidungsschicht nicht Schicht für Schicht treffen muss. Im Laufe der Zeit sieht der Bediener weniger wiederkehrende kleine Verluste, weil die Auslöse‑Regeln sie früher abfangen.
Zwei Kennzahlen: der Anteil der ungeplanten Ausfallzeit, der einen verknüpften Arbeitsauftrag hat (Ziel: über 80 % innerhalb von 90 Tagen), und die rollierende Anzahl von Arbeitsaufträgen, die durch Cluster‑Schwellenregeln generiert werden (sollte nicht auf null fallen; wenn sie auf null geht, fangen die Regeln nichts Neues mehr ein).
Anmeldung
Blog
