Was die Fertigungsdatenerfassung abgleichen muss
Die OEE sieht aus wie ein einziger Prozentsatz. Sie setzt sich aus Messwerten zusammen, die von verschiedenen Systemen unabhängig voneinander definiert werden.
- Geplante Produktionszeit: der Schichtkalender, der im ERP hinterlegt ist und von der Maschine nicht erkannt wird
- Stillstand und dessen Grund: die Maschine registriert, dass sie gestoppt hat, und nur ein Bediener oder das Manufacturing Execution System (MES) weiß, ob es sich um eine Störung, einen Rüstvorgang oder eine Pause handelte
- Ideale Taktzeit: die Geschwindigkeit, mit der das Teil produziert werden sollte, die normalerweise im Arbeitsplan im ERP und nicht an der Maschine hinterlegt ist
- Gutmenge im Vergleich zur Gesamtmenge: die Maschine zählt Zyklen, und die Qualitätsprüfung entscheidet, welche davon verkaufsfähig waren
- Der Auftrag, zu dem der Output gehört: welcher Fertigungsauftrag zu diesem Zeitpunkt lief, was die Maschine nicht wissen muss
Nur einer dieser fünf Werte stammt direkt von der Maschine. Der Rest kommt aus den Geschäftssystemen. Deshalb liefert ein Erfassungsprojekt, das an der Maschine endet, Zahlen, die niemand verteidigen kann.
Warum liefert die Fertigungsdatenerfassung zwei OEE-Werte?
Definitionen gehen auseinander, bevor alles andere geschieht. Wenn die geplante Produktionszeit in einem System die geplante Wartung ausschließt und im anderen einschließt, unterscheidet sich die Verfügbarkeit um mehrere Prozentpunkte, ohne dass eines der Systeme falsch liegt. Dasselbe gilt für die Frage, ob ein fünfminütiger Stopp als Stillstand zählt oder als Mikro-Stopp, der in der Leistung aufgeht.
Das Timing vergrößert die Lücke zusätzlich. Maschinendaten treffen kontinuierlich ein, während ERP-Buchungen erst erfolgen, wenn jemand einen Fertigungsauftrag bestätigt – oft erst am Ende einer Schicht. Der Vergleich eines Live-Werts mit einem bestätigten Wert misst daher ebenso sehr die Verzögerung in der Berichterstattung wie die tatsächliche Leistung. Genau diese Verzögerung ist das Problem. Echtzeit-Produktionsüberwachung setzt genau hier an, um das Problem auf Architekturebene zu lösen.
Die Zuordnung ist der unauffälligste der drei Faktoren, aber auch der kostspieligste. Wenn Output dem falschen Arbeitsauftrag zugeordnet wird, stimmt die Summe auf Werksebene zwar immer noch, doch die Kosten für jeden betroffenen Auftrag sind falsch. Genau das führt dazu, dass die Zahlen auf Werksebene plausibel aussehen, während die Auftragskalkulation unzuverlässig bleibt.
Keines dieser drei Probleme ist auf Sensoren zurückzuführen, weshalb die Anschaffung weiterer Sensoren hier nicht weiterhilft.
Wo eine falsch eingeschätzte OEE-Kennzahl Geld kostet
Das Dashboard fällt nicht durch offensichtliche Fehler auf. Es wird stillschweigend ignoriert, während sich die Kosten im Hintergrund anhäufen.
- Meetings, in denen über die Zahlen gestritten wird: Zeit, die damit verschwendet wird, darüber zu debattieren, welche Zahl korrekt ist, anstatt zu entscheiden, was dagegen unternommen werden soll.
- Verbesserungsmaßnahmen, die am falschen Problem ansetzen: Wenn Rüstvorgänge fälschlicherweise als Ausfälle kategorisiert werden, fließt das Instandhaltungsbudget in Bereiche, in denen eigentlich der Rüstprozess das Problem war.
- Auftragskalkulationen, denen man nicht trauen kann: Output, der dem falschen Auftrag zugeordnet wird, verzerrt die Margen beider Aufträge.
- Kapazitätsplanung auf Basis überhöhter Raten: Wer auf Basis theoretischer Taktzeiten plant, die in der Praxis nie erreicht wurden, gibt Versprechen ab, die das Werk nicht einhalten kann.
- Investitionsvorhaben, die ins Stocken geraten: Eine Maschinenersatzbeschaffung, die mit OEE-Daten begründet wurde, kommt nicht voran, wenn die Finanzabteilung die Ausgangsbasis nicht verifizieren kann.
Wenn eine Zahl falsch aussieht, ist der erste Instinkt meist, noch mehr Daten zu sammeln.
Warum die Erfassung von Fertigungsdaten in beide Richtungen funktionieren muss
Mehr Daten aus der Fertigung zu erfassen bedeutet mehr Sensoren, feinere Granularität und kürzere Intervalle. Das verbessert zwar die Auflösung der bereits funktionierenden Hälfte, lässt die Diskrepanz jedoch genau dort, wo sie war.
Die andere Hälfte ist der Kontext. Ein Stopp-Ereignis wird erst dann zu einer Ausfallzeit mit Grund, wenn jemand oder etwas es klassifiziert. Eine Stückzahl wird erst dann zu einer Gutmenge, wenn die Qualitätssicherung sie freigegeben hat. Eine Produktionsmenge wird erst dann aussagekräftig, wenn sie mit dem zugehörigen Arbeitsauftrag verknüpft ist.
Die eigentliche Anforderung verläuft also in beide Richtungen. Arbeitsaufträge, Arbeitspläne und Schichtkalender müssen in die Fertigung gelangen, damit Maschinendaten direkt bei ihrer Entstehung markiert werden können. Das markierte Ergebnis muss dann als Bestätigung an das ERP-System zurückfließen. Ein Projekt, das Daten nur nach oben transportiert, wird immer Zahlen liefern, über die man sich streiten muss.
Es gibt drei Ansätze, diesen Kreislauf zu schließen, doch jeder hat seine Schwächen. Eine Maschinenüberwachungsplattform visualisiert die OEE zwar gut, verwendet aber meist eigene Definitionen statt derer des ERP. Ein MES ist zwar das richtige Bindeglied zwischen Fertigung und Unternehmenssystemen, stellt jedoch eine umfangreiche Implementierung dar, weshalb viele Werke es aufschieben. Die manuelle Eingabe in das ERP am Schichtende ist in den meisten Werken noch immer Standard – und genau das erzeugt die Verzögerung, die einen Abgleich unmöglich macht.
Wie sorgt eine Integrationsplattform für den Abgleich von Fertigungsdaten?
Eine Integration Platform-as-a-Service (iPaaS) verbindet die Maschinenebene mit den Systemen, die die Definitionen enthalten – also das ERP für Kalender und Arbeitspläne sowie die Qualitätssicherung für die Gutmengen. Beide Richtungen verlaufen über dieselbe Ebene, sodass Kontext in die Fertigung gelangt und Bestätigungen zurückfließen.
Die bidirektionale Kommunikation macht den Unterschied zwischen einem reinen Datenstrom und echter Integration. Wenn der aktive Arbeitsauftrag an die Maschine gesendet wird, wird der Output in dem Moment markiert, in dem er entsteht, anstatt ihn am Schichtende mühsam zu rekonstruieren. Die Abbildung von Maschinenzuständen auf die Ausfallkategorien des ERP stellt sicher, dass die Verfügbarkeit auf beiden Seiten identisch definiert ist. Daten nur in eine Richtung zu übertragen, führt zwangsläufig zu zwei verschiedenen Zahlenwerten.
Alumio ist eine Integrationsplattform, die für den bidirektionalen Datenaustausch entwickelt wurde – sie liefert Kontext in die Fertigung und sendet Bestätigungen zurück. Die Alumio-Integrationsplattform erreicht dies auf vier Wegen.
- Kontextübermittlung in die Fertigung: eine ereignisgesteuerte Daten-Route innerhalb von Alumio überträgt den aktiven Arbeitsauftrag, den Arbeitsplan und den Schichtkalender an die Maschinenebene, sodass der Output direkt bei der Entstehung markiert und nicht nachträglich rekonstruiert wird
- Einheitliche Definition für beide Seiten: ein Daten-Transformer bildet Maschinenzustände auf dieselben Ausfallkategorien ab, die auch das ERP verwendet, sodass Verfügbarkeit in beiden Systemen dasselbe bedeutet
- Kontinuierliche Rückmeldung von Bestätigungen: eine Daten-Route übermittelt produzierte Mengen und Ausschuss in Echtzeit an das ERP und ordnet sie dem korrekten Auftrag zu, wodurch die Verzögerung am Schichtende entfällt
- Jeder Wert ist auf seine Quelle zurückführbar: detaillierte Protokolle zeichnen auf, welcher Messwert zu welcher Zahl geführt hat, sodass bei Unstimmigkeiten ein einfacher Blick in die Logs genügt, anstatt ein Meeting einzuberufen
Die Konfiguration übernimmt das Mapping der Zustände und die Rückflüsse, wobei der Alumio Code Transformer es Entwicklern ermöglicht, dort zu programmieren, wo sie es der Konfiguration vorziehen. Eine zweite Linie geht für bereits bestehende Mappings in Betrieb, was genau das ist, was Maschinendaten, die Unternehmenssysteme erreichen, in eine verlässliche Kennzahl statt in einen bloßen Datenstrom verwandelt.
Was sich durch eine abgestimmte Betriebsdatenerfassung ändert
Der Erfolg eines Erfassungsprogramms misst sich nicht daran, wie viele Maschinen Daten liefern. Er misst sich daran, ob der Werksleiter und der Finanzdirektor dieselbe Zahl sehen und keiner von beiden sie infrage stellt.
Drei Rollen decken jeweils unterschiedliche Aspekte ab. Der Werksleiter verantwortet die OEE-Kennzahl und den darauf basierenden Verbesserungsplan. Der Produktionsplaner plant auf Basis von Zykluszeiten, die in der Arbeitsplanung hinterlegt sind, anstatt auf Basis der tatsächlich in der Fertigung erreichten Werte. Der Finanzcontroller muss jeden Auftrag auf Grundlage von Ausbringungsmengen kalkulieren, die möglicherweise dem falschen Auftrag zugeordnet wurden.
Wenn man sich auf eine gemeinsame Kennzahl einigt, ändert sich der Zweck der Daten. Die OEE ist dann nicht mehr nur eine Kennzahl für Werksbesprechungen, sondern wird zur Grundlage für Kalkulation, Kapazitätsplanung und Investitionsentscheidungen. Eine Integrationsplattform, die in beide Richtungen arbeitet, liefert diese einheitliche Kennzahl, da beide Seiten sie auf Basis derselben Definitionen berechnen. Das ist etwas völlig anderes als ein besseres Dashboard.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
