Kompetenzfeld 03
Produktstrukturen, Datenmodelle & Systemarchitekturen
Eine Produktlogik. Klare Sichten. Verbindliche Systemrollen.
Wir verbinden Produktlogik, Strukturen, Objekte, Regeln und Stücklisten über PLM, CPQ, ERP, Produktion und Service. So wird aus verteilten Daten eine belastbare Informationsarchitektur für Angebot, Auftrag, Ausführung und Betrieb.
03
Wirkung
Konsistenz
Systemklarheit
Lifecycle-Sicherheit
Durchgängige Produktdaten – von der Definition bis zur ausgelieferten und gewarteten Instanz.
Ausgangspunkt
Durchgängigkeit entsteht nicht durch Schnittstellen allein.
Viele Programme beginnen mit Systemen, Integrationen und Migrationslisten. Die eigentliche Ursache liegt jedoch häufig davor: Produkt- und Prozesslogik sind nicht geklärt, fachlich unterschiedliche Objekte werden gleichgesetzt und Zuständigkeiten bleiben zwischen den Systemen offen.
Eine belastbare Architektur beginnt deshalb mit der Frage, welche Information für welchen Zweck entsteht, wie sie sich verändert und wer sie verantwortet. Erst daraus folgen Systemrollen und technische Übergaben.
01
Objekte werden gleichgesetzt
Merkmal, Position, Ergebnis oder Stückliste werden trotz unterschiedlicher Bedeutung wie dasselbe Objekt behandelt.
02
Sichten werden kopiert
Vertrieb, Entwicklung und Produktion benötigen verschiedene Sichten. Kopien schaffen nur scheinbar Durchgängigkeit.
03
Systeme werden zu früh festgelegt
Funktionen werden verteilt, bevor Datenhoheit, Änderungsrecht und Übergabemechanismen entschieden sind.
Gesamtmodell
Durchgängigkeit ist eine Gestaltungsaufgabe auf fünf Ebenen.
Die Ebenen bilden keine starre Projektfolge. Sie sorgen dafür, dass technische Entscheidungen aus Produkt und Prozess abgeleitet werden und Governance nicht erst am Projektende ergänzt wird. Wählen Sie in der Visualisierung ein Element, um Bedeutung, Architekturentscheidung und typische Risiken zu sehen.
Architekturprinzip · Fünf Gestaltungsebenen
Objekte & Semantik
Bevor Systeme verbunden werden, müssen die Objekte unterscheidbar sein.
Gleiche Begriffe bedeuten in Vertrieb, Entwicklung, Produktion und Service häufig nicht dasselbe. Diese Unterschiede sind keine Störung, sondern fachlich notwendig. Entscheidend sind explizite Übersetzungs- und Ableitungsregeln.
Grundsatz
Nicht jedes Objekt ist dasselbe Objekt
Die meisten Durchgängigkeitsprobleme entstehen nicht an Schnittstellen, sondern davor: Zwei fachlich verschiedene Objekte tragen denselben Namen und werden deshalb gleichgesetzt. Fünf Paare, die in nahezu jedem Projekt auftauchen.
Der gemeinsame Nenner: Jedes dieser Paare beschreibt eine Übersetzung, keine Gleichheit. Wo die Übersetzungsregel fehlt, wird sie improvisiert — in Freitextpositionen, Nebenlisten und Kopfwissen. Durchgängigkeit entsteht dort, wo diese Regeln benannt, versioniert und verantwortet sind.
Struktur- und Ableitungsarchitektur
Eine Produktlogik erzeugt mehrere berechtigte Sichten.
Vertrieb, Entwicklung, Fertigung und Service beantworten unterschiedliche Fragen. Darum gibt es keine universelle Struktur, die für jeden Zweck gleichermaßen funktioniert. Die Architektur muss festlegen, welche Sicht eigenständig ist und ob sie abgeleitet, transformiert, angereichert, parallel geführt oder eingefroren wird.
Eine Produktlogik, mehrere Sichten
Produktstrukturen bilden keine feste Reihenfolge. Aus einer gemeinsamen Produktlogik entstehen eigenständige Sichten mit unterschiedlichem Zweck. Entscheidend ist je Objekt: Was entsteht, wie wird es verbunden, wer führt es und was geschieht bei einer Änderung?
Architekturentscheidung: Wo wird die variantenführende 150-%-Struktur geführt?
Die drei Sichten oben beschreiben den Produkttyp und seinen Variantenraum. Service beschreibt die ausgelieferte Instanz. Der Zugriff erfolgt nicht auf aktuelle Typdaten, sondern auf eingefrorene Stände und Referenzen.
Mechanismen der Übergabe
- abgeleitet — entsteht regelbasiert aus einer Vorgängersicht
- transformiert — umstrukturiert nach anderer Logik, keine Übertragung
- angereichert — bestehende Struktur wird um eine Ebene ergänzt
- parallel geführt — eigenständige Sicht auf dieselbe Produktlogik
- angelegt — neues Stammobjekt nach bewusst gewählter Strategie
- eingefroren — Stand wird instanzbezogen festgeschrieben
Systemrollen & Datenhoheit
Systemrollen folgen den fachlichen Objekten.
Nicht die maximale Funktionsbreite eines Werkzeugs entscheidet, sondern die klare Arbeitsteilung. Jedes relevante Objekt braucht einen führenden Ort, ein benanntes Änderungsrecht und einen definierten Mechanismus für die Nutzung in anderen Systemen.
Fachliche Rolle
Definiert Bedeutung, Verantwortung und Entscheidungsrecht – unabhängig vom eingesetzten System.
PLM & Autorensysteme
Führen Produktdefinition, CAD/eBOM, technische Stände, Freigaben und Engineering-Änderungen.
CPQ · CRM/PIM ergänzend
Nutzen die Vertriebssicht für Bedarf, Konfiguration, Preis, Angebot und Kundenkommunikation.
ERP · MES ergänzend
Führen Material, Auftrag, mBOM/BOP, Werkssichten, Disposition und ausführungsnahe Daten.
Service- & Asset-Systeme
Dokumentieren installierte Basis, as-built/as-maintained, Feldereignisse, Ersatzteile und Retrofit.
Lifecycle & Governance
Durchgängigkeit muss über Änderungen und Produktgenerationen tragen.
Ein Datenmodell ist erst belastbar, wenn ein früheres Angebot, ein ausgelieferter Stand und eine spätere Änderung reproduzierbar bleiben. Version, Gültigkeit, Effectivity und Freigabe gehören deshalb zur Architektur – ebenso wie das bewusste Management von Abhängigkeiten.
Version & Wirksamkeit
Produkt-, Regel-, Struktur- und Dokumentstände müssen zeitlich, nach Werk und nach Produktgeneration zusammenpassen.
Änderung & Nachweis
Auswirkungen werden kontrolliert, Freigaben getestet und as-built/as-maintained bleiben gegen ihren damaligen Stand nachvollziehbar.
Lock-in bewusst beherrschen
Modell-, Methoden-, Hersteller- und Betriebsabhängigkeiten werden sichtbar gemacht – einschließlich realistischer Export- und Exit-Pfade.
Realitätscheck & Pilot
Die Architektur muss in Auftrag, Produktion und Service funktionieren.
Boxen und Pfeile reichen nicht. Wir prüfen das Zielmodell an einer realen Produktfamilie und an konkreten Grenzfällen – mit echten Merkmalen, Regeln, Strukturen, Stücklisten, Dokumenten und Änderungsständen.
Wertschöpfung und Logistik prüfen
- mBOM, BOP, Werkssichten und Beschaffungslogik
- Materialstammstrategie: konfigurierbar, vorgepflegt oder automatisiert angelegt
- 100-%-Auflösung und auftragsspezifische Ergänzungen
- as-built, Service, Ersatzteil und Retrofit
Mit realen Fällen pilotieren
- eine repräsentative Produktfamilie statt eines idealisierten Demos
- 10 bis 20 bewusst gewählte Standard- und Grenzfälle
- CTO+, ETO und begrenzte Konstruktion in der Auflösung
- Design Automation dort, wo Berechnung oder Dokumenterzeugung tatsächlich trägt
Vorgehen & Ergebnisse
Vom verteilten Datenbestand zum geprüften Zielmodell.
Wir reduzieren die Komplexität schrittweise, ohne die fachliche Realität zu vereinfachen. Das Ergebnis ist kein abstraktes Architekturpapier, sondern ein entscheidungsfähiges Modell mit belastbarer Pilotierung und Umsetzungslogik.
01
Istbild & Architekturentscheidungen
Produktfamilien, Prozesse, Objekte, Systeme, Brüche und offene Entscheidungen transparent machen.
02
Zielmodell & Pilot
Sichten, Objektverträge, Ableitungslogik und Systemrollen modellieren und an realen Fällen testen.
03
Roadmap & Governance
Migrationspfade, Releases, Verantwortungen, Tests und die schrittweise Umsetzung festlegen.
Fachliche Ergebnisse
- abgestimmte Produkt-, Struktur- und Objektlogik
- definierte Sichten und Übergabemechanismen
- reproduzierbare Konfigurations- und Stücklistenergebnisse
Umsetzungsfähige Ergebnisse
- klare Systemrollen und Datenhoheiten
- validierter Pilot und priorisierte Roadmap
- Governance für Version, Änderung, Test und Release
FAQ
Häufige Fragen zu Produkt- und Systemarchitekturen.
Brauchen wir nicht eine einzige „Source of Truth“?
Für jedes fachliche Objekt braucht es eine eindeutige Führung. Das bedeutet aber nicht, dass eine einzige Struktur alle Zwecke erfüllen muss. Entwicklung, Vertrieb, Produktion und Service benötigen eigenständige Sichten, die über klare Identitäten, Regeln und Verantwortungen verbunden sind.
Wo sollten eBOM und mBOM geführt werden?
Das hängt von Produkt-, Industrialisierungs- und Änderungsmuster ab. PLM, ERP oder ein gekoppeltes Modell können sinnvoll sein. Entscheidend sind Transformation, Werkssicht, Änderungsprozess, Effectivity und die fachliche Verantwortung – nicht ein pauschaler Systemgrundsatz.
Warum gibt es so viele PLM–ERP-Szenarien?
Weil Produkte und Wertschöpfung unterschiedlich organisiert sind. Eine frühe Industrialisierung im Baukasten benötigt andere Systemrollen als eine späte auftragsspezifische Ausarbeitung. Architektur folgt dem Produkt- und Prozessmuster.
Wie vermeiden wir einen Lock-in?
Abhängigkeiten lassen sich nicht vollständig vermeiden, aber bewusst gestalten. Fachliches Modell, proprietäre Regeln, Datenformate, Integrationen und Betrieb werden getrennt bewertet. Dazu gehören exportierbare Kernobjekte, dokumentierte Semantik und ein realistischer Exit-Pfad.
Wie lässt sich ein Zielbild belastbar validieren?
Mit realen Produktfamilien, echten Objekten und ausgewählten Grenzfällen. Der Pilot muss nicht nur den Happy Path, sondern auch Änderungen, Gültigkeiten, 100-%-Auflösung, Fertigung und spätere Servicefragen nachweisen.
Produktstruktur-, Stücklisten- oder Systemdurchgängigkeitsthema fundiert einordnen.
Wir klären gemeinsam, wo die fachliche Bruchstelle liegt, welche Architekturentscheidungen anstehen und wie ein sinnvoller Pilot aussehen kann.