Governance in der Manufacturing-Landschaft

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Sizing: KMU — eine OT/IT-Übergabe und ein Qualitäts-KPI mit Werkleiter als Owner. Mid-Market — Quality Owner und Plant-Steward, Sensorprodukt mit Kalibrierstatus, zentrale Semantik für OEE und Ausschuss. Enterprise — föderierte Werke, Group-KPI-Owner neben lokalen Varianten, Supply-Chain-Share-Verträge mit Zweck und Weitergabeverbot; bei Connected Product nach SOP ein VIN-Produkt und Share neben den Werken.

Das Werk meldet Ausschuss nach lokalem Sensor-Kontext. Die Zentrale zeigt eine andere OEE, weil Aggregation, Zeitzone und Qualitätsregel anders gerechnet wurden. Manufacturing-Governance beginnt nicht mit einem Shopfloor-Dashboard. Sie beginnt mit Messkontext, Anlagengrenze, Kennzahlensemantik und dem, was den Hof verlassen darf.

Typische Fragen sind:

• Welcher Fluss darf die OT/IT-Grenze passieren?; Welche Einheit, Kalibrierung und welcher Anlagenzustand gehören zum Messwert?; Welche Anlagenkennzahl gilt im Werk, welche im Konzern?; Wer darf Ausschuss an Lieferanten oder Kunden weitergeben?; Welche Evidenz beweist, dass beide Zahlen dieselbe Schicht meinen?

Wenn Historian-Export, Qualitätsregel und Konzern-KPI denselben Identifier nicht teilen, steuert das Werk nach Ausschuss, Einkauf nach Konzern-OEE, und niemand kann die wirksame Formel vorlegen. Das Problem ist nicht das Dashboard. Es ist der fehlende Vertrag zwischen Sensor, Grenze, Kennzahl und Share.

Gute Manufacturing-Governance macht Schicht und Konzern vergleichbar — Messkontext, OT/IT-Übergabe und KPI-Mapping an denselben Identifier, nicht an die neueste Folie.

Die Serie Governance in der Manufacturing-Landschaft gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Ausgangslage

Das Werk berichtet Ausschuss aus dem lokalen Sensor. HQ aggregiert OEE über eine andere Zeitzone, andere Ausschlüsse und eine andere Qualitätsregel. Ohne OT/IT-Übergabe, Messkontext und KPI-Mapping stehen zwei Wahrheiten im Raum. Teams kaufen dann ein MES-Add-on oder taggen den Katalog — und Schichtleitung und Konzernsteuerung entscheiden weiter aneinander vorbei.

Was diese Serie klärt

• Orientierung: OT/IT-Grenze, Quality/Sensor-Produkt, Werk- versus Enterprise-KPI, Supply-Chain-Partnerfreigabe; bei OEM zusätzlich Fahrzeugdaten nach SOP
• Vertiefung: Die OT/IT-Grenze betreiben
• Vertiefung: Qualität von Sensordatenprodukten
• Vertiefung: Daten in der Supply Chain teilen
• Vertiefung: Werk- und Enterprise-KPIs versöhnen
• Abschluss (OEM): Fahrzeugdaten nach SOP

Begriffe und Kürzel vor dem Lesen

• OT/IT-Grenze — Vertrag über erlaubte Flüsse, Protokolle, Identitäten, Change-Fenster und Notfallwege zwischen Shopfloor und Enterprise-IT — kein offenes Gateway.
• OT (Operational Technology) — Anlagen- und Shopfloor-Systeme; Verfügbarkeit und Sicherheit gehen vor zentrale Skalierung.
• Quality/Sensor-Produkt — Messwert plus Einheit, Position, Sampling, Kalibrierstatus und Anlagenzustand mit Nutzer-SLO — kein Roh-Historian-Feed.
• Werk-KPI — lokale Kennzahl (Ausschuss, Anlagenkennzahl, Durchsatz) mit Schichtkalender, Ausschlüssen und Quality verantwortliche Person im Werk.
• Enterprise-KPI — Konzernkern mit Mapping, Abgleich und Group-KPI-verantwortliche Person; gleich benannt heißt nicht gleich gerechnet.
• Supply-Chain-Partnerfreigabe — Datensatz, Zweck, Empfänger, Weitergabe, Aufbewahrung und Incident-Kommunikation über die Unternehmensgrenze — kein CSV an den Lieferanten.
• Fahrzeugdaten nach SOP — VIN-fachliche Ebene und Feldtelemetrie mit Zweck (Garantie, Flotte, Produkt, Training), sobald ein Connected Product das Werk verlässt — kein Historian nach dem Tor.

Lesepfad

1. Governance in Manufacturing
2. Die OT/IT-Grenze betreiben
3. Qualität von Sensordatenprodukten
4. Daten in der Supply Chain teilen
5. Werk- und Enterprise-KPIs versöhnen
6. Fahrzeugdaten nach SOP — nur wenn ein Connected Product das Werk verlässt

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Linien-, Sensor-, Werk- und Toolnamen durch eure MES-, Catalog-, Ticket- und Prozessquellen.

Konzept halten — Last-Säulen: Quality und Verantwortung tragen diese Kette; KPI ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierung — OT/IT-Grenze ohne den Shopfloor zu übernehmen

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

Manufacturing braucht nicht „eine Fabrik-Datenbank“, sondern geschnittene Produkte.

OT- versus IT-Grenze

Die Grenze ist kein Kabel. Sie ist ein Übergabevertrag.

Dieses Produkt beschreibt:

• Erlaubte Flüsse; Protokolle; menschliche und technische Identitäten; Change-Fenster; Notfallweg; verantwortliche Person auf jeder Seite; technischer Betreiber (OT-Ingenieur, IT-Plattform).

Entscheidungen:

• Welcher Historian-Export darf in die Enterprise-IT?; Wer genehmigt ein neues Gateway?; Welche Änderung am Wochenende ist Notfall, welche ist ungeplanter Bypass?

Quality- und Sensor-Produkt

Ein Messwert ohne Kontext ist kein Produkt.

Es benötigt:

• Sensor-ID und Position; Einheit; Sampling; Kalibrierstatus; Anlagenzustand; Freshness; Plausibilität; Nutzer-SLO; Quality verantwortliche Person.

Entscheidungen:

• Wann ist ein Wert „gültig“ gegenüber nur vorhanden?; Wer darf Kalibrierung schließen?; Welcher Nutzer (Linie, Qualität, Konzern) hat welches SLO?

Werk-KPI versus Enterprise-KPI

Gleich benannte OEE ist oft zwei Formeln.

Das Produkt benötigt:

• Lokale Definition (Schichtkalender, Ausschlüsse, Qualitätsregel); Konzernkern; Mapping; Abgleich; Werkleiter oder Quality verantwortliche Person lokal; Group-KPI-verantwortliche Person zentral.

Entscheidungen:

• Welche Ausschlüsse gelten im Werk, welche im Konzern?; Wer darf eine lokale Variante führen?; Wann ist Abgleich „erfüllt“ gegenüber einer nur erklärten Differenz?

Supply-Chain-Share

Der Export an den Lieferanten ist kein „gleicher Datensatz wie intern“.

Entscheidungen:

• Welcher Datensatz und welcher Zweck?; Wer ist Empfänger, wer darf weitergeben?; Welche Aufbewahrung, Löschung und Incident-Kommunikation gelten jenseits des Tors?

Fahrzeugdaten nach SOP

Nur relevant, wenn ein Connected Product das Werk verlässt. VIN ist nicht der Werksensor und nicht der Fahrer.

Entscheidungen:

• Welches fachliche Ebene gilt nach SOP (VIN an Plant-Serial)?; Welcher Zweck (Garantie, Flotte, Produkt, Training)?; Wer ist Vehicle-Data-verantwortliche Person, wer technischer Betreiber der Telematik?

Wo Governance hängt

Zwischen Sensor und Historian-Export

Ohne Einheit, Kalibrierung und Anlagenzustand bleibt der Job grün und der Wert unbrauchbar. Pipeline-Verfügbarkeit ist kein Qualitätsnachweis.

Zwischen OT-Ingenieur und IT-Plattform

Der OT-Ingenieur betreibt die Grenze. Er ist Custodian, nicht Owner der Konzern-OEE. Ein offenes Gateway ohne Change-Fenster ist kein Vertrag.

Zwischen Werk-Ausschuss und Konzern-OEE

Schichtkalender, Zeitzone und Qualitätsregel verschieben die Zahl. Ohne Mapping und Reconciliation steuern Werkleitung und HQ auf parallelen Wahrheiten.

Zwischen Quality Owner und Group-KPI-Owner

Lokal entscheidet Qualität über Ausschuss. Den Konzernkern ändert nur der Group-KPI-Owner. Beide beraten; genau einer ist je Entscheidung accountable.

Zwischen Hofgrenze und Lieferanten-Share

Ein interner Sensorfeed ist kein Partnerprodukt. Ohne Zweck, Empfänger und Weitergabeverbot wandert Ausschuss in fremde Systeme.

Zwischen MES-Admin und fachlicher Freigabe

Wer das OEE-Flag setzen kann, ist nicht berechtigt zu entscheiden, welche Ausschlüsse der Konzernbericht verwendet.

Rollen-Mapping

Data Owner (Manufacturing)

Werkleiter ist accountable für lokale Zwecke, Ausschussregel und akzeptables Betriebsrisiko im Werk. Quality Owner entscheidet Gültigkeit des Messwerts. Group-KPI-Owner entscheidet den Konzernkern. Der OT-Ingenieur und der MES-Admin sind nicht Owner dieser Kennzahlen.

Data Steward

Quality Operations oder Plant Analytics triagiert Sensorlücken, pflegt KPI-Varianten und Mapping, überwacht Kalibrierfristen und eskaliert widersprüchliche OEE-Zahlen.

Data Product Owner

Priorisiert Sensorprodukt, Grenzvertrag, KPI-Familie und Share-Index. Nutzen und Lieferbarkeit — nicht die Qualitätsauslegung an der Linie.

Data Architect

Schützt Grain (Linie ≠ Werk ≠ Konzern, Sensor ≠ KPI, Schicht ≠ Kalendertag), Lineage vom Historian zum Konzernreport und Breaking Changes an Gateway und Share.

Data Custodian

OT-Ingenieur, MES-Admin und IT-Plattform setzen Flüsse, Identitäten, Locks und Historian-Exports um. Konfigurationsmacht ist keine Auslegungshoheit.

Data Consumer

Schichtleitung, Qualität, Instandhaltung, Konzernsteuerung, Einkauf, Lieferant (nur mit Share-Vertrag). Abweichungen laufen über denselben Intake — keine stillen Spreadsheet-OEE.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

Mini-Fall

Symptom: Ein Werk meldet Ausschuss anhand lokaler Sensordaten. Die Zentrale zeigt eine andere Anlagenkennzahl, weil sie Schichten, Zeitzonen und Qualitätsregeln anders zusammenfasst. Einkauf bewertet den Lieferanten nach der Konzernzahl, obwohl das Werk eine andere Ursache sieht.

Typischer Fehlstart: Ein MES-Add-on kaufen und Katalogfelder füllen, ohne Mapping, ohne Abgleich und ohne Messkontext am Export.

Vereinbarung: Quality/Sensor-Produkt mit Einheit, Kalibrierung und Anlagenzustand. Plant-versus-Enterprise-Vertrag mit Schichtkalender, Ausschlüssen und Mapping. Abgleich der beiden Zahlen durch Quality Owner und Group-KPI-verantwortliche Person. OT-Ingenieur bleibt technischer Betreiber der Historian-Übergabe.

Kritische Übergaben

Anti-Patterns

• Historian-Export ohne Einheit, Kalibrierung und Anlagenzustand
• OT-Ingenieur als heimlichen verantwortliche Person der Konzern-Anlagenkennzahl setzen
• Werk-Ausschuss und Enterprise-Anlagenkennzahl unter einem Label vermischen
• Lieferanten-Partnerfreigabe als Kopie des internen Feeds ohne Zweck und Weitergabeverbot
• Gateway ohne Change-Fenster und ohne Notfallweg
• MES-Admin entscheidet Ausschlüsse, weil die UI es hergibt

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape
• Functions Hub — Manufacturing

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Wochen bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Den letzten Konflikt Werk-Ausschuss gegen Konzern-OEE wählen. Sensor, Schichtkalender, Ausschlüsse und den Historian-Export aufnehmen. OT/IT-Grenze und ein Sensorprodukt für eine Linie schneiden.

Schritt 2: Control und Nachweis umsetzen

Messkontext am Export verpflichten. Mapping und Reconciliation zwischen Werk- und Enterprise-KPI produktiv schalten. Negativtest: Konzernreport darf nicht schließen, wenn die Reconciliation offen ist.

Schritt 3: Testen und Ausnahmen sichtbar machen

Einen Supply-Chain-Share mit Zweck, Empfänger und Weitergabeverbot dokumentieren. Ein Change-Fenster und einen Notfallweg an der OT/IT-Grenze durchspielen.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Sensorprodukt, Mapping, Grenzvertrag, Share) auf eine zweite Linie oder ein zweites Werk übertragen. Optional bei OEM: einen VIN-/Telemetrie-Slice nach SOP schneiden — nicht Pflicht für jedes Werk.

Exit-Kriterien

• OT/IT-Grenze nennt Flüsse, Identitäten und Change-Fenster.
• Sensorprodukt trägt Messkontext und Kalibrierstatus, nicht nur den Rohwert.
• Werk- und Enterprise-KPI haben Mapping, Abgleich und getrennte verantwortliche Person.
• Supply-Chain-Partnerfreigabe hat Zweck, Empfänger und Weitergaberegel.
• technischer Betreiber liefert Konfigurationsnachweis ohne mündliche Brücke.

Weiterlesen

• Functions Hub — Manufacturing
• Governance in Operations
• Governance in Software- und Produktentwicklung
• KPI-Definition, Verantwortung und Versionierung

Ein offenes Gateway ist noch kein Vertrag. Manufacturing-Governance scheitert, wenn der OT-Historian ungefiltert in den IT-Lake schreibt und niemand sagt, welcher Fluss, welche Identität und welches Change-Fenster gelten. Spätere Qualitäts- und Konzern-KPI-Fragen haben dann keinen durchsetzbaren Hof.

Dieser Teil definiert den Übergabevertrag zwischen Historian und Lake — bevor Sensorkontext oder Konzern-OEE darauf aufsetzen.

Vorher: Governance in Manufacturing. Weiter: Qualität von Sensordatenprodukten.

Ansatz

Jeder materielle Fluss über die OT/IT-Grenze erhält, bevor er den IT-Lake erreicht:

1. einen erlaubten Zweck und ausgeschlossene Zwecke (Steuerung, Qualität, Konzernreport — nicht „alles, was der Historian hat“);
2. eine Allow-List für Tags, Protokolle und Zielzonen plus menschliche und technische Identitäten;
3. ein Change-Fenster und einen benannten Notfallweg mit Ablaufdatum;
4. den Werkleiter oder Quality Owner als Owner des Zwecks und den OT-Ingenieur als Custodian der Grenze;
5. einen Konfigurationsnachweis der wirksamen Gateway-Regel, den ein Prüfer ohne mündliche Brücke lesen kann.

Kein Historian-Export ohne diesen Vertrag. Der Group-KPI-Owner besitzt die Konzern-OEE, nicht das Gateway.

Grenz-Workflow

1. Fluss und Zweck schneiden

Der Owner benennt genau einen produktiven Export: welche Linie, welcher Historian-Tag, welcher Lake-Pfad. „Wir spiegeln den Historian“ ist kein Zweck.

2. Scope je Seite festlegen

OT-in: Sicherheit, Verfügbarkeit, Anlagenidentität. IT-in: Landing-Zone, Retention, Consumer. Was auf einer Seite Notfall ist, ist auf der anderen oft ungeplanter Bypass.

3. Identitäten und Allow-List binden

Jedes technische Konto und jeder menschliche Zugang trägt eine Rolle. Neue Protokolle und neue Tags brauchen Freigabe, bevor sie den Hof passieren.

4. Change-Fenster und Notfallweg

Geplante Änderungen laufen im Fenster. Der Notfallweg nennt Auslöser, Freigeber, Ablauf und Rückweg. Ein Wochenend-Job ohne Fenster ist ein Bypass, kein Betrieb.

5. Custodian umsetzen, Owner entscheiden

Der OT-Ingenieur setzt Gateway, Locks und Export um. Er entscheidet nicht, welche Ausschüsse der Konzernbericht verwendet. Konflikte zwischen Verfügbarkeit und Zentralsteuerung eskaliert der Werkleiter oder Quality Owner.

6. Nachweis sichern

Wirksame Konfiguration, Allow-List und letzter Test hängen am Fluss. Ohne Export der Regel bleibt die Grenze Folie.

Handoffs

Anti-Patterns

• Historian ungefiltert in den IT-Lake schreiben
• OT-Ingenieur als heimlichen verantwortliche Person der Konzern-Anlagenkennzahl setzen
• Wochenend-Änderungen ohne Change-Fenster als Betrieb verbuchen
• Gateway-Jobs als Qualitätsnachweis behandeln
• Notfallweg ohne Ablaufdatum und ohne Rückweg offen lassen

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Einen produktiven Historian-Export wählen und Zweck, Zielzone und Identitäten schriftlich festlegen.
2. Die wirksame Gateway-Allow-List exportieren und gegen den genannten Zweck prüfen.
3. Ein Change-Fenster und einen Notfallweg mit Freigeber und Ablauf durchspielen.
4. Einen Negativtest fahren: unautorisiertes Tag oder Protokoll darf den Lake nicht erreichen.

Ein grüner Ingest-Job ist noch kein Messwert. Quality-Governance scheitert, wenn der Historian-Export Einheit, Kalibrierstatus und Anlagenzustand verliert und die Pipeline trotzdem „gültig“ meldet. Schichtleitung steuert dann Ausschuss, den niemand später derselben Probe zuordnen kann.

Dieser Teil macht aus dem Sensorlesewert ein Produkt — nach der OT/IT-Grenze, bevor Shares oder Konzern-OEE den Wert weiterreichen.

Vorher: Die OT/IT-Grenze betreiben. Weiter: Daten in der Supply Chain teilen.

Ansatz

Jeder materielle Sensormesswert erhält, bevor Linie, Qualität oder Konzern ihn steuern:

1. eine Sensor-ID mit Position und Sampling sowie die Einheit am Wert, nicht nur im Wiki;
2. einen Kalibrierstatus mit Frist und einen Anlagenzustand (Produktion, Wartung, Rüsten, Stillstand);
3. eine Gültigkeitsregel: vorhanden ist nicht gültig; Out-of-Context-Werte werden abgelehnt, nicht still gemittelt;
4. den Quality Owner als Accountable für Fitness und den OT-Ingenieur als Custodian des Exports;
5. ein Consumer-SLO je Nutzung (Linie, Qualität, Konzern) mit Freshness und Plausibilität.

Kein Ausschuss- oder OEE-Input ohne diesen Kontext. Der Group-KPI-Owner aggregiert nur freigegebene Werte.

Sensorprodukt-Workflow

1. Grain und Position festlegen

Der Quality Owner bestimmt, was ein Messpunkt ist: Sensor an einer Stelle der Linie, nicht „die Halle“. Splits, redundante Sensoren und Ersatzgeräte bekommen eigene IDs.

2. Einheit und Kalibrierung binden

Einheit und Kalibrierstatus reisen mit dem Wert. Abgelaufene Kalibrierung macht den Punkt ungültig, auch wenn der Job grün bleibt. Schließen der Kalibrierung ist eine Owner-Entscheidung, kein Admin-Klick.

3. Anlagenzustand mitschreiben

Ein Wert aus Wartung oder Rüsten ist ein anderer Datensatz als ein Wert aus Produktion. Ohne Zustand vermischt die Aggregation Ausschuss mit Setup-Ausschuss.

4. Gültigkeit gegen Vorhandensein

Der Contract nennt, wann ein Wert „gültig“ ist. Plausibilität, Freshness und Kontextflags sitzen dort, wo das Produkt publiziert wird — nicht erst im Dashboard.

5. Consumer-SLO trennen

Die Linie braucht Sekunden. Qualität braucht Kalibrierkontext. Der Konzern braucht reproduzierbare Schichten. Ein SLO für alle drei lügt mindestens zwei von ihnen an.

6. Export und Nachweis

Der OT-Ingenieur hängt Kontext an den Historian-Export. Der Quality Owner gibt das Produkt frei. Ohne Kalibrier- und Zustandsnachweis bleibt der Feed Rohsignal.

Handoffs

Anti-Patterns

• Roh-Historian-Feed als Qualitätsprodukt behandeln
• Kalibrierung im Wiki führen und am Wert weglassen
• Werte aus Wartung in die Produktionsaggregation mischen
• Pipeline-Grün als Fitness-Nachweis verbuchen
• OT-Ingenieur Gültigkeit schließen lassen, weil er den Export bedient

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Einen Sensor wählen, der eine Ausschuss- oder OEE-Entscheidung speist, und Einheit plus Kalibrierstatus am Export prüfen.
2. Anlagenzustand als Pflichtattribut aufnehmen; einen Wartungswert bewusst ablehnen.
3. Quality Owner und OT-Ingenieur schriftlich trennen: Fitness versus Export.
4. Ein Consumer-SLO für Linie und eines für Qualität nebeneinanderlegen und die Differenz dokumentieren.

Ein CSV an den Lieferanten ist noch kein Share. Manufacturing-Governance scheitert, wenn Ausschuss oder Sensorwerte den Hof als Kopie des internen Feeds verlassen und der Empfänger sie an Unterlieferanten weiterreicht. Später kann niemand Zweck, Empfänger und Löschung vorlegen.

Dieser Teil begrenzt, was die Unternehmensgrenze passiert — nach dem Sensorprodukt, bevor Konzern-OEE denselben Datensatz intern anders rechnet.

Vorher: Qualität von Sensordatenprodukten. Weiter: Werk- und Enterprise-KPIs versöhnen.

Ansatz

Jeder materielle Share über die Hofgrenze erhält, bevor der erste Export startet:

1. einen Datensatz-Schnitt (welche Felder, welches Grain, welcher Zeitraum) — nicht den ganzen internen Sensor- oder Ausschussfeed;
2. einen Zweck und ein Weitergabeverbot (kein Onward an Unterlieferanten, Broker oder Kunden ohne neue Freigabe);
3. benannte Empfänger plus Aufbewahrung, Löschung und Incident-Kommunikation;
4. den Werkleiter oder Quality Owner für die fachliche Bedeutung und einen Supply-Chain-Owner für Zweck und Empfänger;
5. einen technischen Slice am Exchange, den der OT-Ingenieur oder die IT-Plattform als Custodian schaltet und widerrufen kann.

Kein Partnerzugriff auf denselben Lake-Pfad wie die Linie. Der Group-KPI-Owner gibt keine Lieferanten-CSV frei.

Share-Workflow

1. Schnitt und Zweck festlegen

Owner und Quality Owner wählen genau einen Datensatz: Ausschuss einer Linie für Reklamation, nicht „alles, was Qualität hat“. Zweck ist ein Satz, den Legal und Einkauf gleich lesen.

2. Empfänger und Weitergabe binden

Der Vertrag nennt die juristische Person, nicht „den Lieferanten“. Weitergabe an Sub-Tier, Konzernschwester oder Portal ist verboten, bis ein neuer Share existiert.

3. Aufbewahrung und Löschung

Partner behalten den Slice nur so lange, wie der Zweck trägt. Löschfrist und Nachweis gehören in denselben Vertrag wie der erste Export.

4. Slice statt Kopie des internen Feeds

Masking, Feldliste und Credential sitzen am Exchange-Punkt. Ein intern gültiges Sensorprodukt bleibt intern, bis der Share es ausdrücklich freigibt.

5. Incident und Widerruf

Zweckbruch, Verlust oder Onward ohne Freigabe lösen denselben Incident-Weg aus. Revoke muss technisch wirken, nicht nur in der E-Mail stehen.

6. Nachweis sichern

Wirksame Policy, Empfängerliste und letzter Revoke-Test hängen am Share. Ohne das bleibt der Export eine Höflichkeit.

Handoffs

Anti-Patterns

• Internen Sensor- oder Ausschussfeed als CSV an den Lieferanten kopieren
• Zweck weglassen und „Transparenz“ als Freigabe behandeln
• Weitergabe an Unterlieferanten still dulden
• Partnerfreigabe-Zugang über dasselbe Gateway-Konto wie die Linie
• OT-Ingenieur oder MES-Admin den Partnervertrag entscheiden lassen

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Einen bestehenden Lieferanten-Export aufnehmen: Datensatz, Empfänger, ob ein Zweck schriftlich existiert.
2. Weitergabeverbot und Löschfrist nachziehen; Onward ohne neue Freigabe schriftlich verbieten.
3. Den technischen Slice vom internen Feed trennen und einen Revoke-Test fahren.
4. Quality Owner und Supply-Chain-Owner für Bedeutung versus Zweck benennen.

Gleich benannte OEE ist noch keine gemeinsame Zahl. Manufacturing-Governance scheitert, wenn das Werk Ausschuss nach lokalem Sensor und Schichtkalender steuert und die Zentrale eine andere OEE zeigt, weil Aggregation, Zeitzone und Qualitätsregel anders rechnen. Einkauf und Schichtleitung entscheiden dann aneinander vorbei.

Dieser Teil mappt Werk-OEE auf Konzern-OEE — nachdem Grenze, Sensorprodukt und Share stehen.

Vorher: Daten in der Supply Chain teilen. Serie startet bei Governance in Manufacturing.

Ansatz

Jede materielle Kennzahl, die Werk und Konzern unter demselben Namen führen, erhält vor Steuerungsnutzung:

1. eine lokale Definition (Schichtkalender, Ausschlüsse, Qualitätsregel) mit Werkleiter oder Quality Owner als Accountable;
2. einen Konzernkern mit Group-KPI-Owner — gleich benannt heißt nicht gleich gerechnet;
3. ein Mapping lokaler Variante auf den Kern (Zeitzone, Grain, Ausschlüsse) plus eine Reconciliation, die als erfüllt oder offen gilt;
4. denselben Identifier für Schicht, Linie und Periode, den Historian-Export und Konzernreport teilen;
5. den OT-Ingenieur als Custodian der Quelle, nicht als Owner der Semantik.

Kein Konzernreport schließt, solange die Reconciliation offen ist. Der MES-Admin setzt keine Ausschlüsse, nur weil die UI es hergibt.

KPI-Mapping-Workflow

1. Beide Formeln nebeneinanderlegen

Plant-Steward schreibt Werk-OEE: Kalender, geplante Stillstände, Qualitätsregel. Group-KPI-Owner schreibt den Kern. Differenzen sind der Vertrag, nicht ein Fehler, den man wegglättet.

2. Identifier und Zeitfenster binden

Schicht, Zeitzone und Periode müssen joinbar sein. Ein Werktag in lokaler Zeit ist kein Kalendertag in UTC. Ohne gemeinsamen Schlüssel bleibt jede Erklärung mündlich.

3. Mapping festlegen

Welche lokalen Ausschlüsse überlebt der Kern, welche werden zurückgerechnet? Mapping ist eine Tabelle mit Owner, kein Kommentar im Report.

4. Reconciliation schließen

Erfüllt heißt: Differenz erklärt, Betrag und Ursache festgehalten, beide Owner einverstanden. Nur erklärt ohne Zahl ist nicht erfüllt. Der Konzernreport darf nicht schließen, solange der Status offen ist.

5. Varianten erlauben, Label trennen

Lokale Varianten bleiben erlaubt. Sie heißen nicht heimlich wie der Kern. Consumer sehen Werk-OEE oder Konzern-OEE, nicht „OEE“ ohne Kontext.

6. Quelle und Semantik trennen

Der OT-Ingenieur liefert den Historian-Kontext für dieselbe Schicht. Er ändert den Konzernkern nicht. Semantik-Konflikte gehen an Quality Owner und Group-KPI-Owner.

Handoffs

Anti-Patterns

• Werk-Anlagenkennzahl und Konzern-Anlagenkennzahl unter einem Label addieren
• Zeitzone und Schichtkalender still unterschiedlich lassen
• Abgleich als Kommentar ohne Betrag führen
• OT-Ingenieur oder MES-Admin Ausschlüsse entscheiden lassen
• Konzernreport schließen, obwohl das Mapping offen ist

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Den letzten Konflikt Werk-Ausschuss gegen Konzern-OEE wählen und beide Formeln, Kalender und Ausschlüsse dokumentieren.
2. Identifier für Schicht und Periode festlegen, den Sensorprodukt und Konzernreport teilen.
3. Mapping schreiben und eine Reconciliation mit Betrag und Ursache durchspielen; Status offen oder erfüllt setzen.
4. Ein Consumer-Label trennen: Werk-OEE und Konzern-OEE dürfen nicht mehr dasselbe Feld sein.

Ein grüner Telematik-Ingest ist noch kein Fahrzeugprodukt. Manufacturing-Governance scheitert bei Autobauern, wenn ECU-Traces nach SOP denselben Lake füllen wie der Historian und niemand VIN, Zweck und Fahrer trennt. Aftersales steuert dann Garantie an einem Rohfeed, den Qualität an der Linie nie freigegeben hat.

Dieser Teil schneidet Fahrzeugdaten nach Start of Production — nach Werk- und Enterprise-KPIs. Werksensor bleibt Teil 3; Connected Product ist ein anderes Grain.

Vorher: Werk- und Enterprise-KPIs versöhnen. Serie startet bei Governance in Manufacturing.

TISAX, UNECE WP.29 und Batterieverordnung bleiben eigene Programme — hier gilt nur der Datenvertrag nach SOP.

Ansatz

Jeder materielle Fahrzeugdatensatz erhält, bevor Aftersales, Flotte oder Lake ihn nutzen:

1. ein VIN-Grain, an der Linie an die Plant-Serial gebunden — Traceability, kein Fahrer, kein Kundenkonto;
2. ein Telemetrieprodukt mit Einheit, ECU-Kontext und Gültigkeit — der Historian-Vertrag aus Teil 3 wird nicht kopiert;
3. einen Zweck je Nutzung: Werkqualität, Garantie/Aftersales, Flotte, Training; Training braucht Freigabe;
4. einen Händler- oder Garantie-Share wie Teil 4, aber am VIN, nicht am internen Qualitätsfeed;
5. Data-Act-Zugang (Nutzer oder Dritte) als Share-Vertrag, nicht als Cloud-Dump;
6. den Vehicle-Data-Owner als Accountable und die Telematik-/OT-Plattform als Custodian.

Kein Lake-Pfad „alles aus dem Fahrzeug“. Der Quality Owner bleibt Owner der Linie; er ist nicht Owner der Feldtelemetrie, nur weil dieselbe ECU in der Halle stand.

Fahrzeugdaten-Workflow

1. VIN an der Linie binden

Der Vehicle-Data-Owner legt fest, was ein Fahrzeugdatensatz ist: VIN plus Plant-Serial an der Linie. Splits, Nacharbeit und Ersatz-ECUs bekommen eigene Bindung. VIN ist Traceability, nicht Personen-Identifier — Finden, nicht durchleuchten.

2. Feldtelemetrie als eigenes Produkt schneiden

Einheit, ECU-Kontext und Gültigkeit reisen mit dem Wert. Der Historian-Export der Linie ist ein anderes Produkt. Wer beide unter einem Lake-Pfad führt, vermischt Schichtausschuss mit Fahrverhalten.

3. Zweck trennen

Werkqualität endet an der SOP. Garantie, Flotte und Produktanalytik sind eigene Zwecke. Training auf Garantie- oder Flottentraces braucht Freigabe — Erhebung ist nicht Training.

4. Händler- und Garantie-Share am VIN

Der interne Qualitätsfeed ist kein Partnerprodukt. Slice, Zweck, Empfänger und Weitergabeverbot sitzen am VIN, bevor der erste Export den Hof als Connected-Product-Dump verlässt.

5. Data-Act-Zugang als Share, nicht als Dump

Nutzer- oder Drittzugang zu Gerätedaten ist ein Share-Vertrag mit Zweck und Widerruf — Überblick in EU-Regulierung: AI Act, Data Act, NIS2 und DORA. Ein offener Cloud-Pfad ist kein Zugang.

6. Owner und Custodian trennen

Der Vehicle-Data-Owner schließt Zweck und Gültigkeit. Die Telematik- oder OT-Plattform setzt Ingest, Rechte und Retention um. Konfigurationsmacht ist keine Auslegungshoheit.

Handoffs

Anti-Patterns

• Historian-Pfad nach SOP als Fahrzeugcloud weiterführen
• VIN als Kunden- oder Fahrer-ID verwenden
• Garantie-Traces ohne Freigabe ins Training kippen
• Händler-CSV des vollen Telemetriefeeds
• MES-Admin oder Telematik-Admin Zweck und Gültigkeit schließen lassen
• Data-Act-Zugang als unbegrenzten Lake-Lesezugriff bauen

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt. Nur relevant, wenn ein Connected Product das Werk verlässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Manufacturing Landscape
• Lernpfad — Manufacturing Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Eine ECU- oder Telemetriekette wählen, die nach SOP Aftersales oder Flotte speist, und VIN gegen Plant-Serial prüfen.
2. Den Lake-Pfad splitten: Werksensor bleibt Linie; Feldtelemetrie bekommt eigenen Zweck.
3. Vehicle-Data-Owner und Telematik-Custodian schriftlich trennen; einen Händler- oder Data-Act-Share am VIN schneiden, nicht am internen Feed.
4. Einen Negativtest fahren: VIN darf keine Kunden-ID sein; Training ohne Freigabe darf den Feed nicht lesen.

Weiterlesen

• Finden, nicht durchleuchten
• Quality Foundations
• EU-Regulierung: KI Act, Data Act, NIS2 und DORA