Area of expertise 03
Product Structures, Data Models & System Architectures
One product logic. Clear views. Binding system roles.
We connect product logic, structures, objects, rules and bills of materials across PLM, CPQ, ERP, production and service. Distributed data becomes a robust information architecture for quotation, order, execution and operations.
03
Impact
Consistency
System clarity
Lifecycle integrity
End-to-end product data – from definition to the delivered and maintained instance.
Starting point
End-to-end consistency is not created by interfaces alone.
Many programs begin with systems, integrations and migration lists. The actual root cause often lies upstream: product and process logic have not been clarified, functionally distinct objects are treated as identical, and accountability remains unresolved across systems.
A robust architecture therefore begins by asking which information is created for what purpose, how it changes and who is accountable for it. System roles and technical handovers follow from that foundation.
01
Objects are treated as identical
A characteristic, line item, result or bill of materials is treated as the same object despite having a different meaning.
02
Views are copied
Sales, engineering and production require different views. Copies only create an illusion of consistency.
03
Systems are defined too early
Functions are distributed before data ownership, change authority and handover mechanisms have been decided.
End-to-end model
End-to-end consistency is a design task across five levels.
The levels do not form a rigid project sequence. They ensure that technical decisions are derived from product and process and that governance is not added only at the end of the project. Select an element in the visualization to see its meaning, architecture decision and typical risks.
Architecture principle · Five design levels
Objects & semantics
Before systems are connected, the objects must be distinguishable.
The same terms often mean different things in sales, engineering, production and service. These distinctions are not defects; they are functionally necessary. Explicit translation and derivation rules are essential.
Principle
Not every object is the same object
Most end-to-end consistency problems do not arise at interfaces, but upstream: two functionally distinct objects carry the same name and are therefore treated as identical. Five pairs appear in almost every project.
The common denominator: Each of these pairs describes a translation, not equivalence. Where the translation rule is missing, it is improvised — in free-text line items, auxiliary lists and tacit knowledge. End-to-end consistency emerges where these rules are named, versioned and owned.
Structure and derivation architecture
One product logic creates several legitimate views.
Sales, engineering, manufacturing and service answer different questions. There is therefore no universal structure that works equally well for every purpose. The architecture must define which view is independent and whether it is derived, transformed, enriched, maintained in parallel or frozen.
One product logic, multiple views
Product structures do not form a fixed sequence. Independent views with different purposes emerge from a shared product logic. For every object, the decisive questions are: What is created, how is it connected, who is authoritative for it and what happens when it changes?
Architecture decision: Where is the 150% structure that governs variants maintained?
The three views above describe the product type and its variant space. Service describes the delivered instance. Access is not to current type data, but to frozen states and references.
Handover mechanisms
- derived — created from a preceding view through rules
- transformed — restructured according to a different logic, not transferred
- enriched — an existing structure is supplemented by another level
- maintained in parallel — an independent view of the same product logic
- created — a new master object created according to a deliberate strategy
- frozen — a state is fixed for a specific instance
System roles · Data ownership · Lifecycle
Clear object ownership makes end-to-end consistency robust across the lifecycle.
Every relevant object requires a clear business meaning, a named owner, an authoritative system and defined rules for handover and change. Only then do robust system roles and an information architecture that lasts across product generations emerge.
Business ownership
Defines meaning, accountability and decision rights – independently of the system used. For every central object, the owner, approval authority and system of record are defined.
PLM & authoring systems
Govern product definition, CAD/eBOM, technical versions, approvals and engineering changes.
CPQ · CRM/PIM supporting
Use the sales view for need, configuration, price, quotation and customer communication.
ERP · MES supporting
Govern material, order, mBOM/BOP, plant views, planning and execution-related data.
Service & asset systems
Document the installed base, as-built/as-maintained state, field events, spare parts and retrofit.
Lifecycle & Governance
End-to-end consistency must hold across changes and product generations.
A data model is robust only if an earlier quotation, a delivered state and a subsequent change remain reproducible. Version, validity, effectivity and approval therefore belong in the architecture – as does the deliberate management of dependencies.
Version & effectivity
Product, rule, structure and document versions must align over time, by plant and by product generation.
Change & traceability
Impacts are controlled, approvals are tested, and as-built/as-maintained states remain traceable against their historical baseline.
Manage lock-in deliberately
Dependencies on models, methods, vendors and operating models are made visible – including realistic export and exit paths.
Reality check & pilot
The architecture must work in order fulfillment, production and service.
Boxes and arrows are not enough. We test the target model using a real product family and specific edge cases – with actual characteristics, rules, structures, bills of materials, documents and change states.
Test operations and logistics
- mBOM, BOP, plant views and procurement logic
- Material-master strategy: configurable, premaintained or created automatically
- 100% resolution and order-specific additions
- as-built, service, spare parts and retrofit
Pilot with real cases
- a representative product family instead of an idealized demo
- 10 to 20 deliberately selected standard and edge cases
- CTO+, ETO and limited engineering in the resolution
- Design automation where calculation or document generation genuinely adds value
Approach & outcomes
From distributed data to a validated target model.
We reduce complexity step by step without oversimplifying the business reality. The result is not an abstract architecture document, but a decision-ready model with robust piloting and implementation logic.
01
Current state & architecture decisions
Create transparency regarding product families, processes, objects, systems, discontinuities and unresolved decisions.
02
Target model & pilot
Model views, object contracts, derivation logic and system roles, and test them using real cases.
03
Roadmap & governance
Define migration paths, releases, accountability, testing and phased implementation.
Business outcomes
- aligned product, structure and object logic
- defined views and handover mechanisms
- reproducible configuration and BOM results
Implementation-ready outcomes
- clear system roles and data ownership
- validated pilot and prioritized roadmap
- governance for versioning, change, testing and release
FAQ
Frequently asked questions about product and system architectures.
Do we not need a single source of truth?
Every business object requires an unambiguous authoritative source. This does not mean that one structure must serve every purpose. Engineering, sales, production and service require independent views connected through clear identities, rules and accountability.
Where should the eBOM and mBOM be governed?
This depends on the product, industrialization and change pattern. PLM, ERP or a coupled model may be appropriate. What matters are transformation, plant view, change process, effectivity and business accountability – not a blanket system principle.
Why are there so many PLM–ERP scenarios?
Because products and operations are organized differently. Early industrialization within a modular product system requires different system roles from late order-specific elaboration. Architecture follows the product and process pattern.
How do we avoid lock-in?
Dependencies cannot be avoided completely, but they can be designed deliberately. The business model, proprietary rules, data formats, integrations and operating model are assessed separately. This includes exportable core objects, documented semantics and a realistic exit path.
How can a target model be validated robustly?
With real product families, actual objects and selected edge cases. The pilot must demonstrate not only the happy path, but also changes, validities, 100% resolution, manufacturing and subsequent service questions.
Assess a product-structure, BOM or end-to-end system consistency challenge on a sound basis.
Together, we clarify where the underlying business-logic break lies, which architecture decisions are pending and what a meaningful pilot could look like.