Evaluating Product Complexity
My colleague, Sanjay Kulkarni, recently explored how you can leverage a single configurator backbone for managing product complexity. Now that you have an overview of complexity management, this article will provide additional details about types of complexity and how to measure them.
Complexity control is of utmost importance to every business, the negligence of which affects the bottom line. Industry trends demand tradeoffs to achieve a competitive advantage while maintaining an optimal level of product complexity. For example, to gain a competitive advantage and maintain market existence, one may have to shift focus from strictly high volume and adjust their portfolio to balance between high volume products and specialized products.
Diversification and product variety are necessary for increasing market share. Product complexity considerations are needed to determine a product mix that will yield revenue and competitive advantage. The organization must first learn to quantify the complexity and then they can take the necessary steps to manage it. 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. We have had a series of articles on leveraging configurator software for total variability management. I’d like to continue that discussion with an exploration of how you can leverage architecture and configurator backbone to measure and manage complexity.
With the fourth industrial revolution with the Internet of Things (IoT), consumers expect products to support certain capabilities and continue to expect more. Manufacturers have to support a level of complexity to be competitive. Organizations have to distinguish between good complexity and bad complexity. Good product complexity means efficiently meeting the customer needs by providing features that support market position and contribute to the bottom line. Portfolio planners must create a proper balance to ensure profitability. Adding features to a product that do not match the customer’s expectation, adds extra time and work to a process, and stifles creativity to develop better products is considered as bad complexity and should be eliminated if possible.
Complexity-related costs are generally hidden and cannot be tracked by typical accounting methods.
It is important to identify where complexity controls are required and where it is not necessary. Organizations put the rigorous process to manage complexity and that effort must be aligned to manage relevant complexity that impacts the bottom line. On the other hand, it may not be relevant to reduce complexity at levels that do not impact the bottom line. A software product, for example, can be designed to handle product complexity much beyond what it needs to support. Though it is paramount to validate the certified capabilities, it may not be necessary to reduce the features that are not exposed to the consumer. Further, it is a lot cheaper to have multiple software features compared to physical features. Only relevant complexity should be controlled that contributes towards the organization’s financial and quality goals.
Product complexity drivers can be defined as a phenomenon that prompts the system to increase its complexity. The complexity of a system can be internal or external. External complexity, also called exogenous, is injected as a result of demands from Sales, Customers, Competition, Global Markets, and Local Regulations, etc. Internal complexity, also called endogenous, is experienced within the company when translating customer requirements into physical products. This complexity impacts multiple domains with varying intensity. For instance, 30 variants of a Seat in manufacturing can mean 60 variants for purchasing due to a dual sourcing strategy but only 10 variants for development due to ten different functional product designs.
The first step in understanding the complexity is to list the Complexity Drivers. The traditional approach that is commonly used is to build the complexity tree based on these drivers and product variability. Following is an example of a product complexity tree for a Seat manufacturer.
These complexity trees tend to get really large and need to be synchronized with decisions taken by portfolio planning and balanced against technical constraints. A number of variants that get generated based on features and variation points for these complexity drivers can be used as a complexity measure for a given product variant.
Measurement of product complexity can be a very laborious process and it is not practical to compute this manually. Configurator capabilities in Teamcenter can help with the management of modules, complexity targets, and computation of complex numbers based on constraints applied to a given module. Teamcenter can also help with the management of complexity targets that are determined based on market analysis or benchmarking. By leveraging product configuration capabilities, you can dynamically quantify the complexity for a module and compare it against predefined targets.
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.
How to Solve Product Complexity:
Rethinking Variability Management with Product Configurator Software inside PLM video
Beyond Product Configurator Software: Total Variability Management blog series
Guided Product Configuration blog
Product Configuration in Teamcenter
About the Author: A product manager at Siemens PLM Software for Teamcenter, Sanjay Kulkarni has over 23 years of experience in Configuration Management, Six Sigma, Product development, and management.
