Produktstrukturen · Datenmodelle · Systemarchitekturen

Durchgängige Produkt- und Datenstrukturen.

Produktlogik und Systemrollen über den Lebenszyklus verbinden.

Wir verbinden Produktlogik, Produktmodelle, Strukturen, Objekte, Regeln und Stücklisten entlang PLM, CPQ und ERP – passend zu Produkt- und Prozessmustern wie MTS, PTO, ATO, MTO, CTO, CTO+ und ETO.

Architektur einordnen
Zur Expertise

WIRKUNG

Konsistenz

Produktmodelle, Strukturen, Regeln und Ergebnisobjekte fachlich zusammenführen.

Systemrollen

Datenhoheiten und Aufgaben von PLM, CPQ, ERP sowie CRM/PIM eindeutig klären.

Lifecycle

Versionen, Gültigkeiten, Änderungen und historische Stände reproduzierbar beherrschen.

Durchgängigkeit entsteht nicht durch Schnittstellen allein.

Digitalisierung entsteht nicht allein dadurch, dass PLM, CPQ und ERP eingeführt und technisch miteinander vernetzt werden. Entscheidend ist, wie Produktinformationen über den Lebenszyklus entstehen, wie Produktmodelle fachlich zusammenpassen, wie Strukturen und Objekte abgeleitet werden und welches System welche Sicht führt. Erst wenn Prozessmuster, Produktstrukturen und Systemarchitektur gemeinsam gedacht werden, entsteht wirkliche Durchgängigkeit. Typische Auslöser sind voneinander abweichende eBOM- und mBOM-Welten, doppelte Regelpflege, unklare Datenhoheiten oder Änderungen, die zwischen PLM, CPQ und ERP auseinanderlaufen.

Unsere Leitfrage lautet deshalb: Welche Produktinformationen und Produktmodelle entstehen wo, und wie entwickeln sie sich über den Lebenszyklus? Wie werden sie fachlich übersetzt, referenziert oder abgeleitet, und welches System trägt welche Sicht? So wird aus einer technischen Schnittstellenlandschaft eine belastbare Informations- und Prozessarchitektur für variantenreiche Produkte.

Vom Produkt zur durchgängigen Informationsarchitektur

Eine gute Produktarchitektur ist der Ausgangspunkt, aber noch kein durchgängiges Produktdatenmodell. Wir übersetzen die fachliche Produktlogik in zusammenpassende Modelle, Strukturen und Objekte und klären deren Entwicklung bis in Auftrag, Produktion und Service.

Durchgängige Informations- und Strukturkette von Produktlogik und Produktmodellen über eBOM, Maximalstruktur, Sales-BOM und mBOM bis zu BOP, Auftrag und 100%-Stückliste in PLM, CPQ und ERP.

Produktlogik → Produktmodelle → Strukturen & Objekte → Ableitungen & Ergebnisobjekte → Kernsysteme → Lifecycle

Dabei geht es nicht um die abstrakte Forderung nach einer einzigen Datenquelle für alles. Unterschiedliche Fachsichten sind notwendig. Entscheidend ist, dass ihre Bedeutung, Beziehungen, Gültigkeiten und Übergaben eindeutig sind und über den Lebenszyklus beherrscht werden.

Ein wichtiger Architekturpunkt ist das Risiko von Modell-, Methoden- und Vendor-Lock-in. Die größte Abhängigkeit entsteht häufig nicht durch die Benutzeroberfläche einer Software, sondern durch das Produktmodell, das mit Methode, Datenmodell, Plattformlogik und Betriebskonzept aufgebaut wird. Tiefe Modellintegration kann zugleich Durchgängigkeit und Effizienz schaffen; realistisch ist daher nicht, Lock-in vollständig zu vermeiden, sondern Abhängigkeiten bewusst zu wählen und den Exit-Pfad zu kennen. Deshalb bewerten wir früh Exportierbarkeit, Integrationsfähigkeit, Lizenz- und Betriebsmodell, Migrationsaufwand, Exit-Szenarien und Governance.

Architektur folgt Produkt- und Prozessmuster

Es gibt nicht die eine ideale PLM–CPQ–ERP-Architektur. Je nach Geschäfts- und Produktmodell unterscheiden wir MTS, PTO, ATO, MTO, CTO, CTO+ und ETO. Diese Klassen bilden keine lineare Reifegradfolge, sondern beschreiben unterschiedliche Anteile aus Lagerfertigung, Auswahl, Montage, Fertigung, Konfiguration und Engineering. Entsprechend verändern sich Produktstrukturen, Regeln, Ergebnisobjekte, Industrialisierungszeitpunkt und Systemrollen.

Für Produktfamilien und Prozessklassen klären wir unter anderem:

  • wo die Varianz im Produkt und in der Stücklistenstruktur sitzt und wie weit der Baukasten industrialisiert ist;
  • ob High-Level-Konfiguration und BOM-nahe Konfiguration getrennt oder gekoppelt werden müssen;
  • ob eine ein- oder mehrstufige Konfiguration sinnvoll ist und welche Dispositions- und Fertigungsstufen erhalten bleiben müssen;
  • welche Anteile subtraktiv aus einer Maximalstruktur abgeleitet und welche additiv zu einer Lösung oder Auftragsstruktur zusammengesetzt werden;
  • wo Design Automation, technische Berechnungen und Engineering-Anteile im CTO+/ETO-Prozess verankert werden;
  • ob Industrialisierung früh im Baukasten oder spät im Kundenauftrag erfolgt und welche Auswirkungen dies auf PLM, CPQ und ERP hat.

PLM–ERP-Szenarien: Eine Schnittstelle ist noch keine Architektur

Allein für das Zusammenspiel von PLM und ERP lassen sich in der Praxis – abhängig von führendem System, Struktur- und Variantenlogik, Industrialisierungszeitpunkt, Änderungsprozess und Werkssicht – mehr als ein Dutzend grundsätzlich unterschiedliche Architektur- und Integrationsszenarien unterscheiden. Eine technische Verbindung zwischen beispielsweise Teamcenter und SAP ist deshalb noch keine Informationsarchitektur.

Zu den prägenden Entscheidungen gehören:

  • wo CAD-Struktur, eBOM- und mBOM-Sichten, 150%- beziehungsweise Maximalstrukturen, auftragsspezifische 100%-Auflösungen und BOP/Arbeitspläne entstehen und geführt werden;
  • ob die mBOM im PLM, im ERP, in einem Manufacturing-System oder in einem gekoppelten Modell aufgebaut und geändert wird;
  • wo Varianten- und Konfigurationslogik liegt und wie High-Level- und BOM-nahe Konfiguration zusammenspielen;
  • ob die Industrialisierung früh im Baukasten oder erst spät im Kundenauftrag erfolgt;
  • ob Übergaben direkt, über eine Integrationsschicht oder über definierte Zwischen- und Ergebnisobjekte erfolgen;
  • wie Änderungen, Freigaben, Gültigkeiten, Werkssichten und Rückmeldungen aus Produktion und Service durchgängig behandelt werden.

Durchgängige Struktur- und Ableitungskette

Produktlogik und Merkmalsmodelle bilden die gemeinsame Grundlage. Daraus entstehen je nach Architektur unterschiedliche, miteinander verbundene Strukturwelten – nicht eine fest vorgegebene lineare Kette. eBOM und mBOM erfüllen unterschiedliche Zwecke; 150%- beziehungsweise Maximalstrukturen können als eBOM- und/oder mBOM-Sicht geführt werden. Vertriebliche Strukturen wie eine Sales-BOM liegen gegebenenfalls parallel, und die auftragsspezifische 100%-Auflösung kann auf eBOM-, mBOM- oder Auftragsebene erfolgen.

  • CAD-Struktur und eBOM: entwicklungsorientierte Sicht auf Funktionen, Baugruppen, Komponenten und freigegebene technische Lösungen.
  • 150%- beziehungsweise Maximalstruktur: Träger des zulässigen Variantenraums mit Optionen, Gültigkeiten und Regeln; je nach Architektur als eBOM- und/oder mBOM-Sicht.
  • Sales-BOM und vertriebliches Merkmalsmodell: parallele Sicht auf Produkte, Leistungen, Optionen und Lieferumfang – sofern sie fachlich eigenständig benötigt wird.
  • 100%-Auflösung beziehungsweise 100%-Stückliste: konkretes, reproduzierbares Ergebnis einer gültigen Konfiguration; je nach Architektur auf eBOM-, mBOM- oder Auftragsebene.
  • mBOM und MRP-Sicht: fertigungs-, montage-, beschaffungs- und werksspezifische Struktur für die operative Ausführung.
  • BOP beziehungsweise Arbeitsplan: Fertigungsfolgen, Ressourcen, Vorgänge und weitere ausführbare Prozessobjekte.

Zwischen eBOM und mBOM liegt häufig keine 1:1-Übertragung, sondern eine echte Transformation: Montagefolgen, Fertigungshilfsmittel, Phantom- oder Logistikstrukturen, Werkssichten und Beschaffungslogiken werden ergänzt, während rein entwicklungsorientierte Gliederungen nicht unverändert übernommen werden. Diese Transformation braucht klare Regeln, Verantwortlichkeiten und Änderungsdurchgängigkeit.

Entscheidend ist nicht, möglichst viele Strukturen einzuführen. Für jede benötigte Sicht muss geklärt sein: Welche Information entsteht dort? Was ist führend? Was wird ergänzt, referenziert, kopiert oder regelbasiert abgeleitet? Welche Semantik, Version und Gültigkeit muss über den Übergang erhalten bleiben? So lassen sich Engineering-, Vertriebs-, Produktions- und Service-Sicht verbinden, ohne ihre unterschiedlichen Zwecke zu vermischen.

Objekte, Semantik und Ergebnisobjekte

Viele Integrationsprobleme entstehen, weil fachlich unterschiedliche Objekte technisch gleichgesetzt werden. Wir klären deshalb die Objektlogik ausdrücklich – zum Beispiel:

  • Vertriebsmerkmal versus technisches Merkmal beziehungsweise Klassenmerkmal;
  • Preisposition versus Materialposition;
  • Produktvariante versus Materialvariante;
  • konfigurierbares Material, Materialvariante und automatisiert oder regelbasiert angelegter Materialstamm;
  • Konfigurationsergebnis versus 100%-Stückliste;
  • eBOM-Sicht versus mBOM-/MRP-Sicht und BOP/Arbeitsplan;
  • Regelobjekt versus Stücklistenbedingung, Ableitungsregel oder Berechnungslogik;
  • Angebot und Angebotsversion versus Auftrag, Auftragsposition und technische Ergebnisobjekte.

Erst aus dieser fachlichen Klärung lassen sich belastbare Übergabeobjekte, Datenverträge und Systemgrenzen ableiten.

Systemrollen und Datenhoheiten

Erst nach der fachlichen Klärung ordnen wir die Systemrollen zu. Für jedes relevante Objekt wird festgelegt: Wo entsteht es? Wo wird es geführt und versioniert? Wo wird es angereichert? Wer darf es ändern? Welche Systeme benötigen eine Referenz, eine Kopie oder ein abgeleitetes Ergebnis? Das gilt für Produktstrukturen, Merkmale und Regeln ebenso wie für Konfigurationsergebnisse, Preisbestandteile, Dokumente, Stücklisten und Auftragsobjekte.

PLM, CPQ und ERP bilden dabei unterschiedliche, aber verbundene Systemräume. CRM und PIM ergänzen die Architektur dort, wo Kunden-, Deal-, Produktkommunikations- oder Katalogdaten eigenständig geführt werden müssen. Ziel ist keine Funktionsmaximierung einzelner Systeme, sondern eine klare Arbeitsteilung mit möglichst wenig Doppelpflege und bewussten Synchronisationsmechanismen.

Systemrollen und Ergebnisobjekte zwischen PLM, CPQ und ERP mit Produktmodellen, Merkmalen, Regeln, Konfigurationsergebnis, Pricing, Angebot, Auftrag und 100%-Stückliste.

Konfigurationsarchitektur und Design Automation

High-Level- und BOM-nahe Konfiguration, ein- und mehrstufige Modelle sowie additive und subtraktive Mechanismen haben unterschiedliche Konsequenzen für Datenmodelle, Regelwerke und Systemgrenzen. Bei CTO+ und ETO kommt hinzu, dass Engineering-Anteile, technische Berechnungen und Design Automation mit der logistischen Konfiguration zusammenspielen müssen.

Wir betrachten deshalb nicht nur, wo ein Konfigurator technisch laufen kann, sondern welche Ebene der Produktlogik er beherrscht, wie Teilvariantenräume synchronisiert werden, wie CAD-/ECAD-Ergebnisse entstehen und wie daraus eBOM, mBOM, BOP/Arbeitsplan und weitere ausführbare Ergebnisobjekte hervorgehen. Gerade der Übergang von PTO oder ETO zu stärker industrialisierten CTO/CTO+-Architekturen wird so planbar statt zu einer reinen Systemmigration.

Pricing als Architekturdomäne

Auch Pricing erzeugt eigene Architekturfragen: Preispositionen sind nicht automatisch Materialpositionen und folgen teilweise anderen Lebenszyklen. Deshalb klären wir, wo Stammpreise und Konditionen liegen, wo konfigurationsabhängige Preisbestandteile berechnet werden, wie Kosten und Zielmargen einfließen, wie Mark-up, Discounting und Freigaben gesteuert werden und welche kaufmännischen Ergebnisobjekte mit Angebot und Auftrag übergeben werden.

So bleibt Pricing mit Produkt- und Konfigurationslogik verbunden, ohne eine zweite Preiswelt neben ERP, CPQ und CRM zu erzeugen. Die fachliche Preisbildung, Margensicht, Freigabe und Quote-Logik vertiefen wir im Kompetenzfeld CPQ & Produktkonfiguration.

Versionen, Gültigkeiten und Lifecycle

Produktmodelle, Strukturen und Regeln entstehen nicht gleichzeitig und verändern sich mit unterschiedlichen Geschwindigkeiten. Wir klären deshalb nicht nur Versionsnummern und Releases, sondern die Informationsentwicklung selbst: Wann entsteht welche Sicht? Wann ist sie reif? Was wird aus einer Vorgängersicht abgeleitet, was referenziert und was bewusst eingefroren? Welche Kombinationen aus Produkt-, Regel-, Preis- und Stücklistenstand müssen später reproduzierbar bleiben?

Damit werden Produktgenerationen, Werke, Märkte und Kundenaufträge beherrschbar. Phase-in, Phase-out, Ersatz, Retrofit und Service können auf konsistente historische Stände zugreifen, statt nachträglich aus nicht mehr zusammenpassenden Daten rekonstruiert zu werden.

Pilotmodelle und reale Use Cases statt Boxen und Pfeile

Wir entwickeln Zielarchitekturen nicht nur in Boxen und Pfeilen. Wir prüfen sie früh an realen Produktfamilien und Prozessklassen – mit echten Produktstrukturen, Merkmalen, Klassen, Regeln, Stücklisten, Pricing-Objekten und Ergebnisdokumenten.

Je nach Aufgabenstellung reicht ein Pilot vom Vertriebs- und Merkmalsmodell über High-Level- und BOM-Konfiguration bis zu eBOM/mBOM-Ableitung, BOP/Arbeitsplan, Pricing, Angebot, Auftrag und 100%-Stückliste. Grenzfälle wie CTO+-Anteile, kundenspezifisches Engineering, mehrstufige Konfiguration oder Design Automation werden bewusst mitgetestet. So werden Annahmen, Systemrollen und Übergaben überprüfbar, bevor ein großes Transformationsprogramm oder eine umfangreiche Implementierung gestartet wird.

Governance, Test und Release

Pflegeprozesse, Verantwortlichkeiten, Freigaben, Regressionstests und Releasekalender entscheiden darüber, ob die Architektur nach dem Go-live stabil bleibt. Wir definieren deshalb Owner und Verantwortlichkeiten für Strukturen, Merkmale, Regeln, Pricing-Logik und Ergebnisobjekte zusammen mit dem Zielbild. Tests decken nicht nur den Happy Path ab, sondern auch Werke, Varianten, Änderungen, Grenzfälle und historische Reproduzierbarkeit.

Wertschöpfung und Logistik als Realitätscheck

Architekturentscheidungen müssen sich in Auftrag, Einkauf, Produktion, Logistik und Service bewähren. Deshalb prüfen wir Werkssichten, Material- und Lagerlogik, Wertschöpfungsmodelle, Beschaffungsstrategie, Dispositionsstufen, BOP/Arbeitspläne und Serviceanforderungen früh gegen das Zielbild. Bei variantenreichen Produkten gehört dazu auch die Stammdatenlogik: Wann arbeiten Prozesse mit einem konfigurierbaren Material, wann mit vorab angelegten Materialvarianten und wann mit automatisiert erzeugten Materialstämmen? Durchgängigkeit ist erst erreicht, wenn die Informations- und Strukturkette im realen Prozess trägt.

Ergebnisse

  • Eine fachlich belastbare Informationsarchitektur aus Produktlogik, Produktmodellen, Strukturen, Objekten und Ableitungen.
  • Klare Datenhoheiten, Systemrollen und Übergabeobjekte entlang PLM, CPQ, ERP sowie ergänzend CRM und PIM.
  • Durchgängig verbundene eBOM- und mBOM-Sichten, Maximalstrukturen, auftragsspezifische 100%-Auflösungen sowie BOP/Arbeitspläne.
  • Reproduzierbare Versionen, Gültigkeiten, Releases und historische Produkt-, Regel-, Preis- und Stücklistenstände.
  • Eine an realen Produktfamilien und Prozessklassen geprüfte Zielarchitektur mit geringerem Doppelpflege- und Re-Implementierungsrisiko.

Typisches Projektmuster

Ausgangslage

Produktstrukturen, Merkmale, Regeln und Stücklisten sind über mehrere Systeme verteilt. Rollen und Semantik sind unklar, Änderungen laufen auseinander und Integration bleibt auf technische Schnittstellen reduziert.

Vorgehen

Produkt- und Prozessmuster ordnen, Modelle und Strukturketten definieren, Objekte und Datenhoheiten klären, Systemrollen zuweisen und die Architektur mit realen Use Cases und Grenzfällen pilotieren.

Wirkung

Weniger Doppelpflege, konsistente Produkt- und Ergebnisobjekte, stabile Releases und eine durchgängige Informationskette von Entwicklung und Vertrieb bis zu Auftrag, Produktion und Service.

Häufige Fragen

Brauchen wir eine einzige zentrale Datenquelle für alles?

Nein. Unterschiedliche Fachsichten sind notwendig. Entscheidend ist, dass Bedeutung, Beziehungen, Gültigkeiten und Übergaben eindeutig sind und die führende Rolle je Objekt geklärt ist.

Wo sollten eBOM und mBOM geführt werden?

Das lässt sich nicht pauschal beantworten. Entscheidend sind Autorenschaft, Reifegrad, Änderungsprozess, Werkssichten und die operative Nutzung. Die eBOM kann im PLM geführt werden, während die mBOM im PLM, ERP oder einem gekoppelten Manufacturing-System entsteht; entscheidend ist eine beherrschte Transformation statt paralleler, nicht synchroner Stücklistenwelten.

Warum gibt es zwischen PLM und ERP so viele unterschiedliche Architekturszenarien?

Weil führendes System, eBOM-/mBOM-Verantwortung, Variantenlogik, Industrialisierungszeitpunkt, Werkssicht, Änderungsprozess und Integrationsprinzip unterschiedlich kombiniert werden können. Deshalb kann selbst dieselbe Systempaarung fachlich grundverschiedene Architekturen abbilden.

Wie gehen wir mit Architektur-, Modell- und Vendor-Lock-in um?

Nicht durch die unrealistische Forderung nach völliger Unabhängigkeit. Tiefe Integration kann Durchgängigkeit und Effizienz schaffen. Entscheidend ist, Abhängigkeiten bewusst zu wählen, Exportierbarkeit, Lizenz- und Betriebsmodell sowie Migrationskosten zu bewerten und einen realistischen Exit-Pfad zu kennen.

Produktstruktur-, Stücklisten- oder Systemdurchgängigkeitsthema einordnen

In einem ersten Gespräch klären wir Produkt- und Prozessmuster, heutige Struktur- und Systembrüche, eBOM-/mBOM-Logik, Zielsetzung und wesentliche Risiken. Danach bewerten wir, ob ein Architektur-Review, ein fachliches Zielbild, ein Pilotdatenmodell oder eine Umsetzungsroadmap der richtige Einstieg ist.

Architekturgespräch vereinbaren