Product Structures · Data Models · System Architectures
End-to-End Product and Data Structures.
Connecting Product Logic and System Roles Across the Lifecycle.
We integrate product logic, product models, structures, objects, rules, and bills of materials across PLM, CPQ, and ERP—aligned with product and process patterns such as MTS, PTO, ATO, MTO, CTO, CTO+, and ETO.
IMPACT
Consistency
Integrate product models, structures, rules and output objects into one consistent functional model.
System Roles
Clearly define data ownership and responsibilities for PLM, CPQ, ERP, and CRM/PIM.
Lifecycle
Manage versions, validity rules, changes and historical states reproducibly.
End-to-end consistency cannot be achieved through interfaces alone.
Digitalization does not result solely from the implementation of PLM, CPQ, and ERP and their technical interconnection. What matters is how product information is generated throughout the lifecycle, how product models fit together from a business perspective, how structures and objects are derived, and which system maintains which view. Only when process patterns, product structures, and system architecture are considered together does true end-to-end consistency emerge. Typical triggers include divergent eBOM and mBOM environments, duplicate rule maintenance, unclear data ownership, or changes that diverge between PLM, CPQ, and ERP.
Our guiding question is therefore: What product information and product models are created where, and how do they evolve over the product lifecycle? How are they translated, referenced, or derived at the functional level, and which system maintains which view? This transforms a landscape of technical interfaces into a robust information and process architecture for variant-rich products.
From Product to End-to-End Information Architecture
A good product architecture is the starting point, but it is not yet an end-to-end product data model. We translate the functional product logic into compatible models, structures, and objects and clarify their development all the way through order processing, production, and service.
Product Logic → Product Models → Structures & Objects → Derivatives & Output Objects → Core Systems → Lifecycle
This is not about the abstract demand for a single source of truth for everything. Different functional views are necessary. What is crucial is that their meanings, relationships, validities, and handoffs are unambiguous and managed throughout the lifecycle.
An important architectural consideration is the risk of model, method, and vendor lock-in. The greatest dependency often arises not from a software’s user interface, but from the product model, which is built using the methodology, data model, platform logic, and operational concept. Deep model integration can simultaneously create consistency and efficiency; it is therefore unrealistic to completely avoid lock-in; rather, dependencies should be chosen deliberately, and the exit path must be known. That is why we evaluate exportability, integrability, licensing and operating models, migration effort, exit scenarios, and governance early on.
Architecture follows product and process patterns
There is no single ideal PLM–CPQ–ERP architecture. Depending on the business and product model, we distinguish between MTS, PTO, ATO, MTO, CTO, CTO+, and ETO. These Process Classes do not form a linear maturity sequence but rather describe different proportions of stock production, selection, assembly, manufacturing, configuration, and engineering. Accordingly, product structures, rules, output objects, the timing of industrialization, and system roles change.
For product families and Process Classes, we clarify, among other things:
- where the variance lies in the product and in the bill of materials (BOM) structure, and to what extent the modular product system is industrialized;
- whether high-level configuration and BOM-level configuration must be separated or coupled;
- whether a single-stage or multi-stage configuration makes sense, and which planning and manufacturing stages must be retained;
- which components are derived subtractively from a maximum structure and which are assembled additively into a solution or order structure;
- where design automation, technical calculations, and engineering components are integrated into the CTO+/ETO process;
- whether industrialization occurs early in the modular product system or late in the customer order, and what impact this has on PLM, CPQ, and ERP.
PLM–ERP Scenarios: An Interface Is Not Yet an Architecture
For the interaction between PLM and ERP alone, more than a dozen fundamentally different architecture and integration scenarios can be distinguished in practice—depending on the leading system, structure and variant logic, timing of industrialization, change process, and plant view. A technical connection between, for example, Teamcenter and SAP therefore does not in itself constitute an information architecture.
Key decisions include:
- where CAD structures, eBOM and mBOM views, 150% or maximum structures, order-specific 100% breakdowns, and BOPs/routings are created and maintained;
- whether the mBOM is built and modified in PLM, in ERP, in a manufacturing system, or in a coupled model;
- where variant and configuration logic resides and how high-level and BOM-level configuration interact;
- whether industrialization takes place early in the modular product system or only late in the customer order;
- whether data transfers occur directly, via an integration layer, or via defined intermediate and output objects;
- how changes, approvals, validities, plant views, and feedback from production and service are handled consistently.
Consistent Structure and Derivation Chain
Product logic and characteristic models form the common foundation. Depending on the architecture, this gives rise to different, interconnected structural environments—not a fixed, linear chain. eBOM and mBOM serve different purposes; 150% or maximum structures can be maintained as eBOM and/or mBOM views. Sales-related structures, such as a Sales BOM, may exist in parallel, and the order-specific 100% breakdown can take place at the eBOM, mBOM, or order level.
- CAD structure and eBOM: a development-oriented view of functions, assemblies, components, and approved technical solutions.
- 150% or maximum structure: Contains the permissible variant space with options, validities, and rules; depending on the architecture, it can be an eBOM or mBOM view.
- Sales BOM and sales-oriented characteristic model: A parallel view of products, services, options, and scope of delivery—provided it is required as a separate business entity.
- 100% resolution or 100% bill of materials: A concrete, reproducible result of a valid configuration; at the eBOM, mBOM, or order level, depending on the architecture.
- mBOM and MRP view: A production-, assembly-, procurement-, and plant-specific structure for operational execution.
- BOP or routing: production sequences, resources, operations, and other executable process objects.
There is often no 1:1 mapping between the eBOM and mBOM; rather, a genuine transformation takes place: assembly sequences, production aids, phantom or logistics structures, plant views, and procurement logic are added, while purely development-oriented structures are not carried over unchanged. This transformation requires clear rules, responsibilities, and consistency in changes.
The key is not to introduce as many structures as possible. For each required view, the following must be clarified: What information is generated there? What is the leading source? What is supplemented, referenced, copied, or derived based on rules? Which semantics, version, and validity must be preserved during the transition? This allows engineering, sales, production, and service views to be connected without mixing their different purposes.
Objects, Semantics, and Output Objects
Many integration problems arise because objects that are different at the functional level are treated as technically equivalent. We therefore explicitly clarify the object logic—for example:
- Sales characteristic versus technical characteristic or class characteristic;
- Price item versus material item;
- Product variant versus material variant;
- Configurable material, material variant, and material master created automatically or based on rules;
- Configuration output versus 100% bill of materials;
- eBOM view versus mBOM/MRP view and BOP/work plan;
- Rule object versus BOM condition, derivation rule, or calculation logic;
- Quote and quote version versus order, order item, and technical output objects.
Only after this functional clarification can reliable transfer objects, data contracts, and system boundaries be derived.
System Roles and Data Ownership
Only after this functional clarification do we assign system roles. For each relevant object, we determine: Where is it created? Where is it managed and versioned? Where is it enriched? Who is authorized to modify it? Which systems require a reference, a copy, or a derived result? This applies to product structures, attributes, and rules as well as to configuration outputs, price components, documents, bills of materials, and order objects.
PLM, CPQ, and ERP form distinct yet interconnected system domains. CRM and PIM complement the architecture where customer, deal, product communication, or catalog data must be managed independently. The goal is not to maximize the functionality of individual systems, but rather to establish a clear division of labor with as little duplicate data maintenance as possible and deliberate synchronization mechanisms.
Configuration Architecture and Design Automation
High-level and BOM-level configuration, single- and multi-stage models, as well as additive and subtractive mechanisms have different implications for data models, rule sets, and system boundaries. In CTO+ and ETO scenarios, engineering components, technical calculations, and design automation must also interact with the logistical configuration.
We therefore consider not only where a configurator can technically run, but also what level of product logic it supports, how sub-variant spaces are synchronized, how CAD/ECAD results are generated, and how eBOM, mBOM, BOP/routings, and other executable output objects are derived from them. In particular, the transition from PTO or ETO to more industrialized CTO/CTO+ architectures becomes a planned process rather than a mere system migration.
Pricing as an Architectural Domain
Pricing also raises its own architectural questions: Price items are not automatically material items and sometimes follow different lifecycles. That is why we clarify where master prices and terms and conditions are located, where configuration-dependent price components are calculated, how costs and target margins are factored in, how markups, discounts, and approvals are controlled, and which commercial output objects are transferred with the quote and order.
In this way, pricing remains linked to product and configuration logic without creating a separate pricing domain alongside ERP, CPQ, and CRM. We delve deeper into business-specific pricing, margin views, approvals, and quote logic within the CPQ & Product Configuration competency area.
Versions, Validity Periods, and Lifecycle
Product models, structures, and rules do not emerge simultaneously and evolve at different rates. We therefore clarify not only version numbers and releases but also the evolution of the information itself: When does a particular view emerge? When is it ready? What is derived from a predecessor view, what is referenced, and what is deliberately frozen? Which combinations of product, rule, price, and BOM statuses must remain reproducible later on?
This makes product generations, plants, markets, and customer orders manageable. Phase-in, phase-out, replacement, retrofit, and service can access consistent historical statuses instead of having to be reconstructed retroactively from data that no longer aligns.
Pilot Models and Real Use Cases Instead of Boxes and Arrows
We do not develop target architectures using boxes and arrows alone. We test them early on using real product families and Process Classes—with actual product structures, characteristics, classes, rules, bills of materials, pricing objects, and output documents.
Depending on the task at hand, a pilot can range from the sales and characteristic model through high-level and BOM configuration to eBOM/mBOM derivation, BOP/work plan, pricing, quote, order, and 100% bill of materials. Edge cases such as CTO+ components, customer-specific engineering, multi-level configuration, or design automation are deliberately included in testing. This allows assumptions, system roles, and data transfers to be verified before a major transformation program or extensive implementation is launched.
Governance, Testing, and Release
Maintenance processes, responsibilities, approvals, regression tests, and release schedules determine whether the architecture remains stable after go-live. We therefore define owners and responsibilities for structures, characteristics, rules, pricing logic, and output objects in conjunction with the target architecture. Tests cover not only the happy path but also plants, variants, changes, edge cases, and historical reproducibility.
Value Creation and Logistics as a Reality Check
Architectural decisions must prove themselves in order processing, procurement, production, logistics, and service. That is why we verify plant views, material and warehouse logic, value-added models, procurement strategy, planning levels, BOPs/routings, and service requirements against the target architecture at an early stage. For products with many variants, this also includes master data logic: When do processes use a configurable material, when do they use predefined material variants, and when do they use automatically generated material master records? End-to-end consistency is only achieved when the information and structural chain supports the real-world process.
Results
- A technically robust information architecture comprising product logic, product models, structures, objects, and derivations.
- Clear data ownership, system roles, and transfer objects across PLM, CPQ, and ERP, as well as complementary CRM and PIM.
- Consistently linked eBOM and mBOM views, maximum structures, order-specific 100% breakdowns, and BOPs/routings.
- Reproducible versions, validities, releases, and historical statuses for products, rules, prices, and bills of materials.
- A target architecture validated against real product families and Process Classes, with reduced risk of duplicate maintenance and re-implementation.
Typical Project Pattern
Initial Situation
Product structures, attributes, rules, and bills of materials are distributed across multiple systems. Roles and semantics are unclear, changes diverge, and integration is limited to technical interfaces.
Approach
Organize product and process patterns, define models and structural chains, clarify objects and data ownership, assign system roles, and pilot the architecture using real-world use cases and edge cases.
Impact
Less duplicate maintenance, consistent product and output objects, stable releases, and a seamless information chain from development and sales through to orders, production, and service.
Frequently Asked Questions
Do we need a single central data source for everything?
No. Different domain-specific views are necessary. What matters is that meanings, relationships, validities, and handoffs are unambiguous, and that the leading role for each object is clarified.
Where should the eBOM and mBOM be managed?
There is no one-size-fits-all answer. The key factors are authorship, maturity level, change management process, plant views, and operational use. The eBOM can be managed in PLM, while the mBOM is created in PLM, ERP, or a linked manufacturing system; what matters is a controlled transformation rather than parallel, unsynchronized BOM environments.
Why are there so many different architectural scenarios between PLM and ERP?
Because the leading system, eBOM/mBOM responsibility, variant logic, timing of industrialization, plant view, change process, and integration principle can be combined in different ways. That’s why even the same system pairing can represent fundamentally different architectures from a business perspective.
How do we address architecture, model, and vendor lock-in?
Not by making the unrealistic demand for complete independence. Deep integration can create end-to-end consistency and efficiency. The key is to consciously choose dependencies, evaluate exportability, licensing, and operating models, as well as migration costs, and to have a realistic exit strategy in place.
Discuss Your Product Structure, BOM or End-to-End System Challenge
In an initial consultation, we clarify the product and Process Classes involved, current structural and system discontinuities, eBOM/mBOM logic, objectives and key risks. We then assess whether an architecture review, a functional target architecture, a pilot data model or an implementation roadmap is the right starting point.