From Product Configuration towards Flexible Solution Architectures (FSA)

Article 6 in our series Executives’ Perspectives on Digital Transformation
by Thomas Gessner, Business Development Manager MBSE Solutions, Zuken.

Customer centricity through customer-specific products drives value and is a key competitive differentiator. At the same time, this approach to developing products presents many manufacturers with a structural dilemma: while engineer-to-order business models enable maximum flexibility, they also make it more difficult to reuse existing solutions and increase dependence on expert knowledge.

Learning from MBSE-Driven Configuration Approaches

A recent MBSE case study from Japan describes an interesting approach to structuring this area of conflict. The project attempted to support the quotation and configuration phase by combining model-based systems engineering with a structured product architecture. Decision logics are explicitly modeled so that suitable machine configurations can be systematically derived from customer requirements.

The approach is based on a highly standardized platform structure (150% baseline), from which project-specific solutions are created by selectively removing unnecessary functions. For many European machine manufacturers, however, such a model is only transferable to a limited extent. In practice, product portfolios have often grown organically over decades and contain numerous variants without a clearly defined system architecture. At the same time, significant innovations continue to emerge in the project context.

This is precisely why the real key lies less in a fully preconfigured platform and more in a product architecture that specifically defines space for project-specific solutions.

Creating Space for Customer-Specific Innovation

At certain points in the architecture, ‘engineering zones’ can be deliberately provided in which different strategies for dealing with customer-specific requirements are applied – such as over-specification, targeted delta engineering or the integration of project-specific modules via defined interfaces.

What is particularly noteworthy about the Japanese approach is the integration of engineer-to-order and configure-to-order logic within a common data model. Instead of separating the two worlds, organizationally or system-technically, requirements, system decisions and product structures are linked in a consistent model. This perspective also offers valuable impetus for European mechanical engineering – provided it is combined with the reality of mature product portfolios and project-driven innovation.

Good product architectures define not only components but also controlled spaces for project-specific engineering.

Why Collaborative MBSE Matters in Industrial Machinery

In many industrial machinery companies, product creation still happens in fragments. Market requirements are defined upstream, engineering solutions emerge downstream, and product management tries to keep everything aligned somewhere in between.

The symptoms are familiar:

• Sales commits to solutions that are difficult to engineer
• Engineering optimizes locally instead of systemically
• Customer-specific solutions disappear once the project is delivered

The issue is rarely a lack of expertise. It is the absence of a shared understanding of the product.

When Product Decisions Are Made Without a Product View

Engineer-to-Order and Configure-to-Order business models create structural tension. Every customer request is different, yet the product portfolio must remain manageable and scalable.

In practice, this tension becomes visible in the quotation and order clarification process. Many of the most critical product decisions are made at this stage — long before detailed engineering begins.

Optimizing the quotation process might be the biggest lever for MBSE. Yet the people making these decisions typically do not work with system models. Instead, they rely on experience, documents, and fragmented product knowledge.

To cope with this complexity, many organizations operate three parallel worlds:

1. Sales and quotation
2. Application engineering
3. Product development

All three make product-relevant decisions — but based on different data, different tools, and different assumptions. What is missing is a common product reference that connects market intent, functional behavior, and technical realization.

From Product Platforms towards and Architecture of controlled flexibility

Platform thinking often assumes that the product can be fully predefined. A pragmatic approach is the so-called “150% product structure”, where all possible options are modeled in advance, and project solutions are created by removing unnecessary elements. While effective in highly standardized industries, this approach often reaches its limits in industrial machinery: Many innovations emerge directly in customer projects, and not all future variants can be anticipated.

What organizations actually need is not a rigid platform, but a structured solution space. In such an architecture:

• stable system functions form the backbone of the product
• alternative solution principles are organized as reusable building blocks
• clearly defined engineering zones allow controlled project-specific extensions

This concept introduces structural flexibility. Instead of trying to predefine every possible configuration, the product architecture explicitly defines where variability is allowed and how it can be handled.

Customer-specific solutions can then follow different strategies, for example:

• Over-specification, selecting a larger or more capable standard component
• Delta engineering, implementing small, targeted adaptations
• Implementing validated technology conecpts
• Project modules, integrated through defined interfaces

In this way, flexibility becomes part of the architecture rather than an uncontrolled side effect of project work.

Stable system functions define the architecture, reusable solution families enable configuration, and engineering zones allow controlled innovation.

This turns Engineer-to-Order projects from exceptions into an integral part of the product system.

Collaborative MBSE: Less Modeling, More Shared Thinking

Model-Based Systems Engineering is often perceived purely as an engineering discipline. That perception is too narrow.

Collaborative MBSE describes a different role for models: models become a shared workspace for product decisions, not a technical artifact owned by engineering. This is particularly important in the quotation phase, where many key product decisions are made by people who are not MBSE specialists.

Instead of forcing these stakeholders to become modelers, collaborative approaches make system knowledge accessible through visual and contextualized views. Within such a model:

• market and customer requirements
• product functions and system behavior variants, options, and customer-specific deviations are explicitly connected.

Product decisions are made in context, not in isolation.

Why Product Management Benefits the Most

Product management often carries responsibility for the product without having sufficient visibility into technical decision spaces. Collaborative MBSE changes that.

Requirements are no longer static documents but structured elements of a living product model. Variants and custom solutions become visible, comparable, and discussable. Portfolio and roadmap decisions can be grounded in real dependencies rather than assumptions.

The model becomes a negotiation space between market needs, technical feasibility, and economic constraints — not a control instrument owned by engineering.

Turning Customer Projects into Product Knowledge

One of the most overlooked strengths of model-based approaches is their ability to contextualize customer-specific solutions. Instead of treating Engineer-to-Order projects as isolated exceptions, they become part of the product knowledge base.

Questions that were previously answered informally suddenly become visible:

• Where does true differentiation occur?
• Where does unwanted variety creep in?
• Which solutions deserve to become part of the reusable solution space?

This transforms operational project work into strategic product insight — something document-based processes almost never achieve.

MBSE as a Social System

The success of Collaborative MBSE is not driven by tools alone. It is driven by mindset and works only if:

• models are visualized in a way non-modelers can understand
• different stakeholder perspectives are explicitly acknowledged
• decision quality matters more than model completeness

Technologies such as GENESYS and SIDEKICK support this approach by combining formal consistency with accessible views — without turning MBSE into an exclusive expert domain.

Product Development Is a Team Sport

Organizations that continue to treat product creation as a sequence of disconnected disciplines will struggle to control complexity — regardless of how sophisticated their tools are. Collaborative MBSE offers a pragmatic alternative.

Not by introducing more methodology, but by establishing shared product models that connect market, product, and engineering.

In short: Not more modeling — better, shared product decisions.