Showing results for 
Search instead for 
Did you mean: 

Managing Product Complexity

Community Manager Community Manager
Community Manager


Complexity is a byproduct of increased product variability. Over several decades product variability has grown exponentially due to market demands, technical complexity, corporate strategy, product/process variety, consumer demand, financial constraints and competition pressure. Product configurator software plays a vital role for managing product complexity within your company.


We’ve been digging into a variety of bill of materials management topics, lately focusing on configurator software for total variability management. I’ve asked my colleague, Sanjay Kulkarni, to continue that discussion with an exploration of how you can leverage a single configurator backbone for managing product complexity.


If we look at the journey of industry revolution from 1.0 to 4.0 we can see that our products are becoming more are more complex. I had used an example of garage door opener in PLM Connection 2016 and decided to stay with the same example for sake of continuity. In ancient times, during first industrial revolution large castle doors were operated using mechanical systems that were operated by humans and later water power was used. Then came the second industrial revolution where we got electrical power and motor operated systems were used.  During the third industrial revolution there was an invention of radio signals that enabled us to open the garage doors remotely without getting out of the car.  And now we are in the fourth industrial revolution with Internet of Things (IOT) where now one can operate the same garage door with a smart phone.


Consumers are satisfied (for the moment) but manufacturers are inundated with complexity. Also, government regulation, and competition has led to additional complexity such a safety sensors, a cooling fan, alert systems, power adapters,  and park assist, to name a few.


 Although all complexity drivers contribute towards overall corporate goal, these drivers are not necessarily in harmony with each other. As an example, on one side, corporate marketing strategy demands innovation and that leads to new products and features, on the other side there are financial constrains that demand reuse/commonality. Further complex products are usually developed across multiple domains and organizational boundaries lead to information exchange challenge. Technical complexity leads to process variety and that leads to challenges with government regulations, adherence to product requirements and deliver highest quality product. Many corporations have processes to introduce a new feature, modify a feature, replace engineering solutions for feature, and obsoleting a feature. Manual methods are not feasible and automation tools are necessary for managing product complexity, as there are multiple impacting drivers.


Let us take an example of a new feature introduction. Market demands a new feature for park assist and the manufacturer need to make a decision whether or not they should add this new feature to the portfolio.


Several complexity drivers needs to be evaluated before making a decision to go forward. For example the cost of developing a new feature versus anticipated profits, impact on market position, time to market, govt. regulations, technical requirements, core competency, manufacturing, supplier, service  requirements, etc.  


How many product variants to offer to the customer and the choice for alternate features leads to increased complexity. This is a critical decision for made-to-stock product manufacturers. For made-to-stock products, multiple product variants may mean increased inventories at distribution network and points-of-sale.


 Once a decision is made to develop the feature, then it is important to identify all applicable requirements associated with the feature and ensure that requirements are satisfied by providing several local solutions or a generic solution. 


 In order to manage complexity, you can start with key dimensions of product variety, change and multi-domain product development. Of course, there are other dimensions that you can consider once the foundation is built. Enterprise change management should account for cross domain impact of changes. Product variety can be managed using a Product Configurator. A common architecture with flexibility to carry out multi-domain product development with ability to identify specific features is the most essential foundation block. This helps reduce complexity by keeping focus on features that are relevant to a module. This sub-set of variability can then be used to check validity of constraints and completeness of solutions.


It must be possible to run validations across domain boundaries. Further, a comprehensive impact analysis across domains is essential to improve decision while making changes to the product. 

By leveraging product configuration capabilities in Teamcenter, customers can overcome many of these challenges. Teamcenter supports the notion of architecture, and serves as a single variant backbone across the product suite.




 With guided product configuration, you can validate domain configuration models and also analyze product variants by running simulation across multiple domains. Further, you can manage product lines, product models, and saved configurations for tracking vehicles/customer orders and apply the same while performing systems engineering work, design content development, etc.

We continue to strive to make managing product complexity easier for you. As our product configuration capabilities continue to evolve, we will keep you informed on the improvements we’re making to benefit you, while managing feature, configuration models, and applications in systems engineering, design, BOM, manufacturing and product planning.



SanjayPhoto.pngAbout the Author 

A product manager at Siemens PLM Software for Teamcenter, Sanjay Kulkarni has over 22 years of experience in Configuration Management, Six Sigma, Product development and management.





Valued Contributor

Hello Sanjay,


Yes, the management of configuration rules, variants and options, their context Information and multi-variant BOMs is one part of the challenge. No doubt, PLM, ERP, EDA and ALM solutions should be able to handle related information to reflect a complete image of the product, including all imaginable variants, to provide massive impact analysis for engineering change management tasks, etc.

But what's about the support of the other variant management tasks in front of the detailed configuration definition?

Sometimes on a structure or facelift rebuild tasks for an already existing product range, the analysis of legacy product structures and their overlaps is one important part too. Maybe this is not a target discipline for PLM and should be left at dedicated linked data business Intelligence analysis tools.

But nevertheless in every product development project, which will result in one or more variants, there exists a task upfront to decide which options should be offered and how the product structure should be organized to satisfy the demand for variety efficiently. You touched this task slightly with the statement "...Several complexity drivers needs to be evaluated before making a decision to go forward..". There exists various methods like the "Modulare Function Deployment", "Dependency Structure Matrix", "Variants Mode and Effects Analysis" to support this task to develope systematically a feasible and modular product architecture for variant products. But it seems that today the integration of such methods in PLM frameworks is not supported very well (Maybe with exception of METUS in Teamcenter?). As consequence EXCEL is taken more often as tool to run the matrix oriented methods like MFD and DSM, which leads still into a traceability break by the encapsulated file utilization. It would be helpfully if the PLM frameworks would provide such integrated tools for the early abstract product architecture design steps to realize their approach "from cradle to grave" for variant products as well. As example if a system is able to handle multiple bom structures in parallel and if it is able to handle connections and relations between the individual artifacts, it would be nice if it would provide also mechanismen to recommend feasible clustering scenarios to optimize the product architecture  (e.g. via a DSM algorithm).




Matthias Ahrens