OEE Dashboard: Datenmodell und Rollout im Brownfield

Zeitregeln, die vor Go-live festgelegt sein sollten

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.

Ein OEE-Wert allein ist als Managementsignal nützlich, aber als Rolloutziel zu klein. Im Brownfield brauchen Sie mindestens vier Ansichten: eine Zeitachse der Maschinenzustände, eine Schichtsicht, eine Auftragssicht und eine Verlustsicht mit Gründen oder offenen Ursachen. Erst zusammen beantworten sie die operative Frage, ob ein Tageswert wegen geplanter Zeit, ungeplantem Stopp, verlangsamtem Lauf oder Qualitätsverlust kippt.

Für einen schnellen Überblick über Zustände und Hallensicht kann ein Maschinenauslastung-Dashboard bereits viel Nutzen stiften. Ein OEE Dashboard muss darüber hinaus aber den Bezug zwischen Zeit, Auftrag und Menge absichern. Deshalb sollte Ihr Pilot nicht zuerst mit KPI-Kacheln starten, sondern mit der Frage, welche konkrete Entscheidung jede Ansicht im Tagesgeschäft ermöglicht.

Empfohlene Ansichten und ihr fachlicher Zweck

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.

Ein Brownfield-Rollout muss weder lang noch bürokratisch sein. Er wird aber dann belastbar, wenn jede Phase ein klar prüfbares Ergebnis hat. Die folgenden fünf Schritte sind plattformneutral formuliert. Sie setzen keine erfundenen Menüpunkte voraus und lassen sich sowohl mit vorhandenen Maschinenschnittstellen als auch mit einem Retrofit-Ansatz umsetzen.

1. Entscheidungsfrage und Pilotgrenze definieren.
   Formulieren Sie zuerst, welche betriebliche Frage das OEE Dashboard beantworten soll: Schichtvergleich, Auftragsverlustanalyse, OEE-Freigabe für eine Engpassmaschine oder Ursachenprozess für wiederkehrende Stopps. Wählen Sie dazu eine begrenzte Pilotgruppe mit ähnlicher Logik. Erwartetes Ergebnis ist ein klarer Freigabesatz. Prüfen Sie, ob jede beteiligte Rolle denselben Zweck in einem Satz wiedergeben kann.
2. Datenmodell und Zeitregeln einfrieren.
   Schreiben Sie Pflichtfelder, OEE-Nenner, Stoppschwelle, Rüstregel, Auftragsgrenze und Offline-Behandlung nieder. Erwartetes Ergebnis ist ein versionierter Datenvertrag. Prüfen Sie ihn an mindestens fünf realen Grenzfällen: Pause, Auftragswechsel, Rüsten, kurzer Stopp und Kommunikationslücke. Wenn zwei Verantwortliche denselben Fall unterschiedlich klassifizieren, ist die Regel noch nicht freigabefähig.
3. Quellen und IDs pro Feld zuordnen.
   Ordnen Sie für jedes Pflichtfeld eine führende Quelle zu: Maschine, Sensor, ERP, BDE, MES oder Qualitätssystem. Erwartetes Ergebnis ist eine Feldliste mit Quelle, Verantwortlichem und Fallback-Regel. Verifikation: Kein Feld darf zwei gleichrangige führende Quellen haben. Besonders kritisch sind Good Count, Ideal Cycle Time, Auftrags-ID und geplante Produktionszeit.
4. Pilotdaten gegen Realität und Grenzfälle prüfen.
   Führen Sie mindestens einen realen Testtag mit dokumentierten Schichtgrenzen, einem Auftragswechsel und gezielten Unterbrechungen durch. Erwartetes Ergebnis ist ein Abnahmeprotokoll mit Pass/Fail je Prüfpunkt. Verifikation: Zeitstempel, Zustandswechsel, Schichtschnitt, Auftragszuordnung und Datenlücken müssen im Export und im Dashboard dieselbe Logik zeigen.
5. Go-live nur zweckgebunden freigeben.
   Geben Sie das Dashboard nicht pauschal frei, sondern getrennt nach Zustandszeiten, Gründen, Mengen und vollständiger OEE. Erwartetes Ergebnis ist ein Go-live-Beschluss mit offener Restliste. Verifikation: Jeder gesperrte Teilbereich hat einen benannten Nachweis, der für spätere Freigabe noch fehlt. Genau diese Transparenz verhindert, dass halbfertige Daten später als harte Produktionssteuerung genutzt werden.

Wenn im Pilot bereits klar ist, dass Sie Bestandsmaschinen ohne nutzbare Schnittstelle einbinden müssen, kann ein Retrofit-Ansatz wie auf der Novo-Seite zur Maschinendatenerfassung für Bestandsmaschinen beschrieben sinnvoll sein. Dort ist zugleich die entscheidende Grenze sauber benannt: Zustände lassen sich von außen erfassen, Stillstandsgründe und vollständige OEE benötigen je nach Zielbild zusätzliche Quellen und Regeln.

Ein belastbares OEE Dashboard braucht Ehrlichkeit über Grenzen. Erstens sagen öffentliche Spezifikationen nichts darüber aus, welche Felder in einem konkreten Bestandspark tatsächlich aktiviert sind. Zweitens erklärt ein Maschinenzustand noch nicht automatisch seine Ursache. Drittens sind gleich klingende Zeitbegriffe aus unterschiedlichen Standards nicht automatisch identisch. Und viertens ersetzt kein Dashboard die lokale Werksentscheidung, welche Zeiten OEE-relevant sein sollen.

Wenn Sie diese Grenzen früh benennen, lassen sich spätere Diskussionen über falsche Erwartungen sauberer führen. Die Produktion erwartet keine theoretische Perfektion, sondern belastbare Regeln. Für den Pilot heißt das: lieber ein enger, sauber freigegebener Anwendungsfall als ein großes Versprechen mit lückenhaftem Datenmodell. Ein OEE Dashboard ist dann nützlich, wenn jeder Beteiligte weiß, welche Frage es zuverlässig beantwortet und welche bewusst noch nicht.

Die praktische Entscheidung lautet deshalb: Starten Sie mit einer kleinen Spezifikation, einer begrenzten Pilotgruppe und harten Pass/Fail-Kriterien. Wenn Zeitregeln, Auftragslogik, Mengenquelle und Datenlücken sauber freigegeben sind, wird die spätere Skalierung fachlich nachvollziehbarer als eine nachträgliche Bereinigung. Genau darin liegt der Unterschied zwischen einer Visualisierung, die nett aussieht, und einem OEE Dashboard, dem Schichtleitung und Produktionsleitung im Tagesgeschäft vertrauen können.