This post appeared in the CMII newsletter of April/May 2017

Do you struggle to meet a demand for broader product portfolio while reducing operating expenses? Many organizations do [1]. Over the past century, demand looped from high variety and low volume, to low variety and high volume, and back to high variety and low volume (illustrated in Figure 1 ❶). Following that trend, organizations adapted their business model to access more niches instead of driving for hit products (illustrated in Figure 1 ❷). The flipside of accessing more niches to increase sales is the reduction of scale economies. Multiple techniques were developed to compensate for the increase of resources consumed during product specification, verification and delivery. A proven technique to reduce those resources is Configuration Management (CM). CM limits waste by efficiently processing changes and controlling product quality (illustrated in Figure 1 ❸), thereby managing the impact of changes on operating expenses.

Figure 1 - Closing the Variant Management loop

Figure 1 – Closing the Variant Management loop

CM implementations, however, rarely reduce the cost of poor Variant Management (VM) within product configuration. Yet, VM is pivotal in achieving scale economies because it maximizes reuse by controlling optional items, configurable items, and the allowed combinations thereof (illustrated in Figure 1 ❹). CM alone without VM also rarely secures that variant sales price and delivery time stays within acceptable boundaries for customers. The control span of VM ranges from sales to in-service upgrade management. With the advent of the Industrial Internet of Things (IIoT) [6], a.k.a. Industry 4.0, this requirement extends to the product environments as they determine the elements it interacts with and how they alter its behavior. VM is therefore crucial to achieve scale economies and automate runtime configuration.

To achieve these goals, we claim that VM should become a dedicated core business process under the CM umbrella. In this post, we propose operating standards and tool requirements for VM.

VM is a recognized topic both in academic [2] and industrial [7] circles. The application of VM has resulted in many different ways of classifying variant types and constraints [3]. In Table 1, we illustrate a basic classification by Product (high-level commercial features), Software and Hardware with examples from a car Drive Mode variant.

Table 1 - Variant types and constraints for Product, Software and Hardware illustrated with car Drive Mode

Table 1 – Variant types and constraints for Product, Software and Hardware illustrated with car Drive Mode

The classification itself is not as important as the organization set up to manage variants. The organization shall be a team supporting engineering with the specification, modelling and maintenance of variants. It shall also support operations and maintenance with the management of runtime variant selection, either customer- or environment-driven. The VM organization shall complement the change specialists and apply the operating standards below:

1. Variant type identification and ownership
2. Variant type constraint identification and ownership
3. Variant type linkage to primary and secondary items
4. Variant type maintenance and growth
5. Variant type exposure to customers
6. Product commonality vs variability
7. Variant configuration identification and ownership
8. Customer variant configuration identification and ownership
9. Environment-driven variant (re-)configuration

Besides operating standards, VM also requires tools to manage the set of variants, their constraints and valid combinations thereof. These tools are not only required for complex products. A simple product composed of only 20 YES/NO options already results in more than a million possible combinations if not constrained. Constraints between those options restrict the solution space based on design and sales requirements. VM support tools shall go much further than traditional tables using columns for product identification and rows for options. Tables are very hard to maintain because they lack modularity and rational traceability. They also instill too much knowledge into the minds of key experts thus locking this critical knowledge away from the rest of the organization; only those experts can explain the knowledge implicitly built in those tables through time. Besides representing a sustainability threat for the business, these critical experts also prevent automation of configuration verification and repair during operations and maintenance. VM support tools shall satisfy the following requirements:

1. Variant modelling, revision and ownership
2. Constraint modelling, revision and ownership
3. Variant and constraint search, navigation and dependency reporting
4. Configuration checking for large models (10 000+ variables and constraints)
5. Configuration repair for large models (10 000+ variables and constraints)
6. Variant and constraint testing and debugging
7. Embedding in operations and maintenance support tooling
8. Embedding in running products
9. Interfacing with PLM (HW), ALM (SW) and ERP data, metadata, and workflows

In this post, we discussed why VM should complement the list of existing CM core business processes. Under that hypothesis, we listed some operating standards and tool requirements. Satisfying those requirements goes beyond product table management and most Configure Price Quote solutions [8]. To our knowledge, only few tool vendors actually provide solutions to the above requirements (e.g. Configit or SkalUP). We believe the advent of IIoT and the constant demand for customization will drive organizations towards more mature VM to reduce operating expenses while selling more product variants.

Acknowledgements
We would like to thank Maxime Gravel (Gulfstream), Mike McKinney (Sub-Zero & Wolf) and Paul Nelson (Orbital ATK) for their valuable feedback on the preliminary versions of this work.

References
[1] A. Flynn and E. Flynn Vencat (2012) “Custom Nation”, BenBella
[2] A. Hubaux, D. Jannach, C. Drescher, L. Murta, T. Mannisto, K. Czarnecki, P. Heymans, T. Nguyen and
M. Zanker (2012), “Unifying Software and Product Configuration: A Research Roadmap”, ConfWS’12, pp. 31-35
[3] A. Hubaux, T. T. Tun and P. Heymans (2013), “Separation of Concerns in Feature Diagram Languages: A Systematic Survey”, ACM Computing Surveys, 45, 4, Article 51, pp. 1-23
[4] C. Anderson (2008), “The Long Tail: Why the Future of Business Is Selling Less of More”, Hyperion
[5] C. R. Boër, S. Dulio and F. Jovane (2004) “Editorial: Shoe Design and Manufacturing”, International Journal of Computer Integrated Manufacturing, 17:7, 577-582
[6] K. R. Lakhani, M. Iansiti and K. Herman (2015), “GE and the Industrial Internet”, Harvard Business School, 9-614-032.
[7] M. Eigner, U. August and M. Schmich (2016), “Smart Products: Rethinking Product Structures and Processes”, Siemens Industry Software GmbH
[8] P. Sengar (2013), “MarketScope for Configure, Price and Quote Application Suites”, Garner, G0023260

About the author

Close