Configurator-to-Commissioning Pipeline
Carry the sold machine configuration into engineering, the digital twin, and variant-specific commissioning without re-entering the order
Our role
We defined the canonical configuration contract, mapped rule-engine output to engineering and simulation inputs, and designed change and test-generation workflows across the delivery chain.
Competencies involved
Case images
See the concrete visuals, test environments, and outputs that make the story easier to assess.
The Problem
Many companies face similar challenges when trying to create value from their technical data and processes.
A configured machine often becomes a PDF, spreadsheet, or order note that engineering must interpret again. Module choices, options, I/O, and layout are re-entered across tools, so changes arrive as messages rather than a controlled difference from the approved sold configuration.
These challenges often result in concrete problems:
- Sales configuration, engineering structures, automation data, and simulation inputs use disconnected representations
- Manual re-entry creates ambiguity about modules, options, interfaces, I/O, and spatial layout
- Configuration changes do not automatically identify affected engineering outputs or required commissioning scenarios
Why It Matters
Why does this matter? Look at the broader impact:
A digital sales process creates limited operational value if delivery starts by translating the order again. The sold configuration should become a governed engineering input that drives variant-specific design and test preparation.
Key metrics we focus on:
Completeness and consistency of the structured handover from sales to engineering
Traceability of configuration changes across generated engineering and twin packages
Readiness of variant-specific commissioning scenarios before physical integration
Our Solution
Here's how we approach the solution:
Canonical sold-configuration model produced by the rules engine with stable module, option, interface, and revision identities
Transformation pipeline that generates the applicable module, option, I/O, parameter, and layout package for engineering and the digital twin
Change-diff workflow showing what changed between approved configurations and which downstream artifacts require regeneration or review
Variant-specific commissioning test plan assembled from module and option scenario templates with traceability to the sold configuration
Results
The comparison between the starting point and the result shows the concrete value the solution can create.
Approved sales configuration reinterpreted and re-entered separately by engineering, automation, simulation, and commissioning teams
One structured sold configuration drives governed engineering outputs, twin setup, change review, and the applicable test plan
The concrete results include:
- Delivery teams receive machine structure and configuration intent in a form their systems can process
- Configuration changes become explicit diffs with visible downstream impact instead of informal updates
- Digital twin and commissioning preparation reflect the machine variant the customer actually ordered
Project context
A machine builder had a digital configuration process but still recreated the sold machine in engineering and commissioning tools. neexo aligned product rules, module identities, I/O, layout, twin parameters, and scenario templates so an approved configuration could generate controlled downstream packages and meaningful change diffs.
Deliverables
- Canonical sold-configuration schema and integration contract for rules, modules, options, I/O, parameters, and layout
- Generation and change-diff pipeline for engineering packages and digital twin configuration
- Variant-specific commissioning test-plan generator linked to module and option scenario templates
Want the approved configuration to become the starting point for engineering and commissioning?
We can help analyze your situation and identify opportunities for similar solutions.