Blog

Prozessdaten sichtbar machen – ein Praxisbeispiel

Prozessdaten sichtbar machen – ein Praxisbeispiel, das Entscheidungen verbessert 📈

Use-Case: Eine Fertigungszelle ohne verlässliche Transparenz

In einer diskreten Fertigungszelle (Bearbeitung – Waschen – Prüfen) gibt es Lieferverzug und Ausschussspitzen, obwohl Maschinen und Personal unverändert sind. Die Ursache bleibt im Tagesgeschäft unsichtbar: kurze Stillstände, Geschwindigkeitsverluste, Qualitätsdrift und suboptimale Auftragsreihenfolge überlagern sich. Ziel: belastbare Transparenz zur Steuerung im Schichtbetrieb und zur systematischen Verbesserung.

Metriken und Methodik: Klar definiert, normkonform, wiederholbar

Die Auswahl weniger, sauber definierter Kennzahlen verhindert Mess- und Auswertungsfehler. Für die erste Ausbaustufe genügen:

  • Gesamtanlageneffektivität (OEE) nach ISO 22400-2:2014 – mit Komponenten Verfügbarkeit, Leistung und Qualität.
  • Erstausbeute ohne Nacharbeit (First Pass Yield, FPY) – Anteil an direkten Gutteilen.
  • Störungskennzahlen: mittlere störungsfreie Zeit (Mean Time Between Failures, MTBF) und mittlere Reparaturzeit (Mean Time To Repair, MTTR).
  • Rüstzeit und Nutzgeschwindigkeit im Auftragskontext.
  • Zwischenbestand im Prozess (Work in Process, WIP) sowie Durchlaufzeit pro Auftrag.

Mess- und Auswertemethoden:
– Zustands- und Ereignismodell: Maschinenzustände konsistent klassifizieren (Produktion, Rüsten, geplante Pause, ungeplante Störung, Leerlauf). Grundlage für OEE nach ISO 22400.
– Zeitreihen mit einheitlicher Zeitbasis: Uhrzeitsynchronisation über das Netzwerk (z.B. Network Time Protocol) für alle Quellen.
– Statistische Prozessregelung (Statistical Process Control, SPC): Regelkarten nach ISO 7870-2 zur Trennung von zufälliger Streuung und speziellen Ursachen.
– Kontextanreicherung: Verknüpfung von Maschinendaten mit Auftrags-, Artikel- und Schichtinformationen aus Fertigungsleitsystem (Manufacturing Execution System, MES) oder Unternehmenssystem (Enterprise Resource Planning, ERP).

Datenerfassung und Architektur: Schlank starten, skalierbar wachsen 🛠️

  • Schnittstellen: Steuerungs- und Sensordaten via OPC Unified Architecture (OPC UA) oder Message Queuing Telemetry Transport (MQTT); Prüfdaten (Messwerte, i.O./n. i.O.) aus Prüfständen.
  • Datenmodell: Eindeutige Signalnamen, definierter Einheitenkatalog, Versionierung von Definitionen (z.B. Geschwindigkeits-Referenz).
  • Speicherung: Zeitreihendatenbank für Rohdaten und Ereignisse; relationale Ablage für Stammdaten und Auftragskontext.
  • Qualitätssicherung: Plausibilitätsprüfungen (z.B. keine Überlappung inkompatibler Zustände), Ausreißerbehandlung dokumentiert und reproduzierbar.
  • Security by design: Trennung von Produktionsnetz und Auswertung, rollenbasierter Zugriff.

Praxisbeispiel: Von Rohsignalen zum Tagessteuerungs-Board

Vorgehen in fünf Schritten, in einer Zelle mit Bearbeitungsmaschine, Waschstation und Endprüfung umgesetzt:

1) Modellieren
– Zustandsmodell abgestimmt mit Instandhaltung und Produktion (was ist „Störung“, was „Leerlauf“?).
– OEE-Definition schriftlich fixiert (z.B. geplante Pause zählt nicht als Verlust).

2) Erheben
– Maschinenzustände, Zyklen, Taktgeber und Störungsbits via OPC UA angebunden.
– Prüfergebnisse (Merkmalswerte) und Freigabe i.O./n. i.O. integriert.
– Zeitbasis über das Netzwerk synchronisiert.

3) Validieren
– Daten mit einem Schichtprotokoll abgeglichen (Stichproben): stimmen Stillstandszeiten, Stückzahlen, Gut-/Ausschussmengen?

4) Visualisieren
– Laufzeitdiagramm pro Maschine (Run-Chart) mit Zustandsfarben.
– OEE-Übersicht je Schicht, zerlegt nach Verfügbarkeit, Leistung, Qualität.
– Pareto-Diagramm der Störgrundklassen.
– Regelkarte (z.B. X-R) für ein kritisches Längenmaß an der Endprüfung.

5) Handeln
– Daily-Board: 15 Minuten Schichtübergabe anhand der vier Sichten.
– Gegenmaßnahmen als Ticket mit Zeitstempel und Bezug zur Quelle (Störungscode, Auftrag).

Ergebnisbilder in der Interpretation (ohne vertrauliche Zahlen): Die Regelkarte zeigt ein wiederkehrendes Muster in der zweiten Schichthälfte; das Pareto weist kurze, häufige Stopps einer Zuführeinheit als Hauptverlust aus; die OEE-Aufschlüsselung macht die Leistungs-Komponente als dominanten Hebel sichtbar.

Interpretation: Was die Bilder wirklich sagen – und was nicht 🔍

  • Regelkarte nach ISO 7870-2: Ein Punkt außerhalb der Eingriffsgrenzen oder spezifische Muster deuten auf besondere Ursachen hin (z.B. Werkzeugverschleiß oder Temperaturdrift). Aktion: Ursache verifizieren, technische und organisatorische Abstellung planen.
  • Pareto der Störgründe: Wenige Ursachen dominieren. Aktion: jeweils eine Ursache mit klarer Maßnahme adressieren (Sensorhalterung, Zuführungsparameter, Wartungsintervall).
  • OEE-Komponenten getrennt betrachten: Eine niedrige Leistungs-Komponente verlangt andere Maßnahmen (Mikrostopp-Reduktion, Geschwindigkeitsabgleich) als ein Qualitätsverlust (Prozessstabilität, Prüfkonzept).
  • Laufzeitdiagramm: Häufige Zustandswechsel ohne nennenswerte Dauer sind Indiz für Mikrostopp-Kaskaden; Abhilfe selten durch „mehr Personal“, sondern durch Ursachenbeseitigung am Engpass.

Wichtig: Kennzahlen sind Entscheidungshilfen, keine Urteile über Personen. Falsche Definitionen oder unsaubere Datengrundlage führen zu Fehlentscheidungen. Deshalb Definitionen versionieren und Änderungen kommunizieren.

Handlungsempfehlungen für den Start

  • Klein anfangen: eine Linie, wenige Kennzahlen (OEE, Erstausbeute, Stör-Pareto, eine Regelkarte).
  • Definitionen fixieren: OEE-Formel, Zustandskatalog, Störungscodes schriftlich freigeben.
  • Zeit synchronisieren: gleiche Zeitquelle für Maschinen, Prüfstände und Auswertung.
  • Visualisierung funktional: klare Skalen, keine 3D-Grafiken, konsistente Farben für Zustände.
  • Tägliche Routinen: 15 Minuten Schicht-Review mit klaren Verantwortlichkeiten der Folgeaktionen.
  • Wartung und Instandhaltung einbinden: Mikrostopp-Ursachen und Verschleißmuster gemeinsam angehen.
  • Datenpflege regeln: Störungscodes pflegen, Freitext nur ergänzend, Pflichtfelder minimieren.
  • Datenschutz und Mitbestimmung beachten (siehe rechtlicher Rahmen).

Rechtlicher Rahmen (AT)

  • Personenbezug: Sobald personenbezogene Daten verarbeitet werden (z.B. Bedienername, Mitarbeiterausweis, Leistungsmessung), gilt die Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung). Erforderlich sind u.a. Rechtsgrundlage (Art. 6), Datenminimierung (Art. 5 Abs. 1 lit. c), Information der Betroffenen (Art. 13) und Verzeichnis von Verarbeitungstätigkeiten (Art. 30).
  • Mitbestimmung: Technische Einrichtungen, die die Mitarbeiter überwachen können, bedürfen in Betrieben mit Betriebsrat einer Betriebsvereinbarung; andernfalls individueller Zustimmung, sofern zulässig. Rechtsgrundlage: Arbeitsverfassungsgesetz (ArbVG) § 96 Abs. 1 Z 1.
  • Praxis: Wenn Transparenz ausschließlich prozess- und nicht personenbezogen benötigt wird, Identifikatoren nach Möglichkeit pseudonymisieren oder vermeiden. Sobald personenbezogene Auswertungen erforderlich sind, rechtliche Prüfung und Beteiligung des Betriebsrats vor Umsetzung.

Klare, messbare Transparenz ist erreichbar, wenn Definition, Datenerhebung, Statistik und rechtlicher Rahmen sauber zusammenspielen. Gerne unterstützen wir bei Auswahl, Implementierung und Review.

Quellen
– ISO 22400-2:2014 – Manufacturing operations management — Key performance indicators for manufacturing operations management — Part 2: Definitions and description (iso.org)
– ISO 7870-2:2023 – Control charts — Part 2: Shewhart control charts (iso.org)
– Verordnung (EU) 2016/679 – Datenschutz-Grundverordnung (Stand konsolidiert) (eur-lex.europa.eu)
– Arbeitsverfassungsgesetz (ArbVG) § 96 Abs. 1 Z 1 – Mitbestimmung bei Kontrollmaßnahmen (ris.bka.gv.at)

Konkrete Herausforderung oder Frage zu Ihrer Anlage? Sprechen Sie uns an – wir diskutieren gern Ihren Anwendungsfall und zeigen, wie sich mit wenig Aufwand aussagekräftige Visualisierungen aufbauen lassen.

#DatenMitDenken #LemconTech #IngenieurbueroLemmerer #Prozessdaten #OEE #SPC #OPCUA #MES