How configuration lifecycle management complements PLM and MBSE

Configuration lifecycle management (CLM) is not new. As a practice, it has been around for decades in some shape or form as a key enabler to driving innovation and strategic portfolio definition towards configured product commercialization. CLM helps address needs such as:

• How to define the right product variant configuration and manage the associated complexity.
• How to track changes, variety and variability to align with the relevant market parameters.
• How to ensure that customers buy products that can be effectively and efficiently manufactured.
• How to ensure that manufactured products have been designed, validated and homologated per required compliance regulations.

Product modularity typically sits at the intersection of product lifecycle management (PLM), enterprise resource planning (ERP), manufacturing execution systems (MES) and customer relationship management (CRM). Simply put:

• PLM drives modular product development.
• ERP drives product pricing strategy, planning and supply chain operations.
• MES drives the associated process modularity through manufacturing execution.
• CRM drives pricing configurability for a given market, customer or consumer.

In this post—through an open dialogue with Henrik Hulgaard, CTO of Configit—I elaborate on the science of CLM and how it intersects with the wider PLM and MBSE disciplines.

Fundamentally, Hulgaard defines product configuration holistically across industries and product types.

“A product model is a [logical] representation of a product, containing multiple features (called parameters, options, characteristics or variables) and rules that define their relationships,” he said. “The product model is then used to guide [how] to configure a product correctly; that is, selecting values for the parameters that satisfy all the rules. A product model can be used to model very different things: a physical product such as a car, a legal contract such as insurance or even law texts.”

Through his experience at building product configuration software at Configit, Hulgaard highlights the example of “advanced effectivity concepts used in automotive to manage changes over time, [while] such concepts may be less relevant in other domains.”

If architected and managed effectively throughout the product lifecycle, modularity contributes to creating a competitive advantage. Having said that, Ethiraj and Levinthal (2004) debated that the implied complexity from product modularity might come in the way of speedy product deployment, as highlighted in their article “Modularity and Innovation in Complex Systems.”

“Excessive modularization may blind the designer to potentially important interactions between decision choices and result in dysfunctional perturbations in module- and system-level performance that constrain evolutions to inferior designs. The speed and efficiency gains from modularization will be offset by the increased time spent in the testing and integration phase, where the consequences of ignored dependencies will come to fore.”—Ethiraj and Levinthal (2004).

In a subsequent study entitled “Product Modularity, Process Modularity, and New Product Introduction Performance: Does Complexity Matter?”, Vickery et al. (2015) highlighted that high product complexity can hinder innovation, whereas high process modularity can facilitate product deployment. They cautioned about the risk of “over modularity” and promoted the need to find a “sweet spot” for product modularization in a high complexity environment.

Further questions to ponder include:

• Are tradeoffs between modular architecture definition and complexity reduction required?
• When should organizations look to make such decisions?
• How do these tradeoffs account for the wider product portfolio maturity, the maturity of the business itself, or possibly both?
• What data needs to be configured, how and at which stage of the product development?
• Do configurations concern both product data and manufacturing process data?
• How should the two be aligned and managed throughout the development and deployment cycles?
• Is this primarily a discrete manufacturing dilemma, or does it also affect formulated or other types of products?

From a product definition standpoint, bills of materials (BOM) and recipes are typically at the center of modularity, representing how products are defined, developed and delivered—from concept to engineering and manufacturing BOMs, up to using costed BOMs to simulate and track financial performance.

Hulgaard describes “the result of the configuration process [as] a set of values to the parameters in the product model; this is called a configuration or sometimes a feature string. A very typical use of the result is to combine it with a configurable BOM structure (also called a 150% BOM or super-BOM) to obtain an order-specific BOM that can be submitted to manufacturing (the route typically also needs to be configurable). But the configuration can also be used to generate the documentation, a CAD drawing or calculate the sales price.”

Moreover, per a whitepaper entitled “Accelerating Digital Transformation in Manufacturing with Configuration Lifecycle Management,” Configit claims that CLM brings configured data together in:

• Connecting enterprise platforms to a common configuration engine, removing data duplication and contributing to faster time-to-market.
• Aligning product portfolio and sales configurations to minimize inconsistencies.
• Ensuring consistent product configuration data from end-to-end.
• Creating a single source of truth for product configuration information through design, manufacturing, sales and services.
• Reducing mistakes and misinterpretations, lowering risk of costly misconfigured products.
• Contributing to delivering higher quality products.

CLM and change management are tightly interrelated, from concept, through development, to servicing discrete configured products. As Hulgaard put it, “CLM is used to track such changes through the lifecycle at the feature-level. At the early stages, this allows designers to quickly analyze the tradeoffs between product variability and cost, answering questions such as: What is the cost of introducing the laser-light feature in the base model in Europe? In this way, it provides an abstraction above the parts. This abstraction is also very useful when upgrading an existing machine or to replace worn-out parts by understanding what selections of features lead to the existing configuration.”

Therefore, the approach that CLM provides is not only one to control product modularity holistically, but also to govern how applicable changes are implemented above the product definition baseline, and up through supply chain operations and servicing.

It is essential to put product configuration in context of the entire product lifecycle deliverables of PLM and per the model-based system engineering (MBSE) framework, considering its effects upstream and downstream on the wider enterprise operations. Hulgaard confirms that “CLM is a key part of MBSE as the product model is one of the elements of a model of a (configurable) product along other models within the MBSE scope [when linking] requirements to features and rules.”

Nonetheless, Hulgaard argues that “CLM is not a new PLM” and expands on the fact that “modern PLM solutions all have the basic capabilities to define features and rules and link them to the parts in a configurable BOM. However, for PLM systems, [product configuration] is not the center focus and thus the capabilities are very rudimentary and lack the ability to handle key aspects such as the commercial perspective, analysis and optimization capabilities.”

CLM solutions have improved in the past decade. There are now specialized platforms such as the Configit Ace “constraint solver” engine, complemented by Virtual Tabulation technology which is to hold the compilation of all valid product configuration rules, and drive continuous BOM validation and optimization across the wider enterprise. It should be noted that a cloud-based version of Configit Ace was announced in January 2023.

A new dilemma has now emerged: should there be multiple or a single BOM configuration engine? If there was only one, where should the engine be mastered across PLM, ERP, CRM, etc. and how do you ensure seamless integration of such critical capability? Subsequently, how do you perform effective impact assessments across platforms and domains, validating product and market requirement alignment? And how do you manage product complexity without hindering subsequent changes?

Once again, Hulgaard presents a clear point of view towards a single configuration engine: “For CLM systems, the product models are the center and features, not parts, are the key communication between systems such as CRM / CPQ [configure, price and quote] systems in the sales area, and ERP systems in the manufacturing area. So CLM does introduce another system in the landscape, but reduces complexity as it removes the rule authoring from PLM as well as from other enterprise systems such as CPQ and ERP. By having a centralized view (the produce model) with all rules in one place, whether related to engineering, sales, manufacturing or servicing, enables dramatic reductions in time-to-market and number of errors in the ordering processes.”

Finally, Hulgaard shared interesting insights about enterprise integration, confirming that “good real-time integrations are key to obtain the benefits of introducing a CLM system.” The two main enterprise integration use cases being:

• To PLM: aligning the features with the configurable BOM defined in PLM.
• To CRM / CPQ: providing sales configurators ensuring a correct configuration of offered products.