Table of contents
Variant management is an exciting topic within the domain of PLM. Many of our customers start their PLM journey with ENOVIA Change Management Central, often with the intention of expanding the solution to supporting other processes and organizations. However, expansion of the solution tends to stop with the initial scope or at least stay stalled for a long time. Over the last couple of years, I have been fortunate enough to be working with expanding the scope of some of our customers into the area of Variant Management. It is a highly challenging area as many processes are involved resulting in many functions and organizations to discuss, explain and convince about the excellence of coming to terms with a product definition.
Naturally, any producing company whether it is products or services work with scenarios like;
All of these scenarios require a change of and to the Product Definition although the impact of the change needed vary in size.
Both a technical aspect and a marketing aspect could be part of the Product Definition, where a technical aspect partly would be, the modularized breakdown of the product’s building blocks and partly the rules defining how modules are allowed to interface and where the marketing aspect would be reflecting the sales strategy in terms of which options of the product are available or allowed or even how options could be combined on a market.
There are several reasons why a company should consider a generic Product Definition as opposed to working with variant-specific BOM´s. At a high level, it has to do with the company´s business model. A company that offers customizable products to its customers and in addition mass-produces these products is a typical example of what is called a mass-customization offering company. When and if a company decides on a business model where their offering is a customizable product. They need to consider the impact it has on the current processes and IT systems. It is usually a major shift going from a company managing variant specific BOM´s to a generic Product Definition. Many companies grow into this business model starting out with managing variant specific BOM´s and somewhere along the road find out that it becomes too cumbersome to manage single BOM´s for all the scenarios mentioned above.
Modularization is a way of taking control of the complexity by packaging it into well-defined modules, which means properties like function, production, service etc. is known early in development projects. A company is most likely suffering from a huge administrative workload keeping the variant-specific BOM´s aligned with latest product definition, there is a high probability that the data quality in these “copy and paste” variant specific BOM´s is poor and that these errors work their way from design too manufacturing, none having the capacity to detect the faults. Resulting in, among other things, sub-optimized processes, claims from customers buying faulty products and costly product returns.
Surveys like the one done by [Guess 2002] shows that the relationship between the data quality level and the amount of resources needed in a company can be quantified. An example; if data is 100% correct then resource level has e.g. index 100. If data correctness falls to 97% then resource index raise to 125. And if data correctness falls to 92% then resource index raise to 200. Result! Half the company’s staff is working with non-value adding activities.
A generic Product Definition could be seen upon as a logical or functional breakdown of the product, where it is broken down into appropriate building blocks. The building blocks represent the product on an abstract level. Each building block or module holds one too many variants where the variants are realized by the physical part or assembly. An example; modules in a product car would likely to be dashboard, engine, seats and more. Each module realized by assemblies varying on e.g. audio package, type of engine, power of engine, fabric of seat upholstery etc.
The generic Product Definition provides an overview of the product in terms of what it is built up by and to some extent how it is built up and it will give a picture of the product variance. In addition to that it gives a possibility to precisely define modules, their interfaces, their usage and their re-use. Information that is important to make product cost calculations and finding ways to reduce the cost of a company’s product or product range in respect to design, production and purchase.
Example of a generic product structure
Introducing a generic Product Definition might not reduce complexity at first but will give control over complexity. A generic Product Definition is of great value for product management when planning new product development, for R&D as input on what is needed to be new design and which design can be re-used, for production planning and not the least purchasing organization for procurement planning. All these disciplines produces information to a common structure and consume information from the same along the products lifecycle. Core processes of a company meet in this common structure and together with a plan on how to reduce product complexity fundamental benefits are revealed:
One way of picturing reduction of product complexity is to remove unnecessary design weighted with cost of design, production and procurement however still keep the configurability and variability. For example instead of having 20 gear boxes realizing the variance of a product, reduce them to 3 and make sure that these 3 cover all variants to a totally lower cost than the 20 did.
Example illustrating difference between variant specific BOMs and Generic Product Structure
ENOVIA has a solution for the whole process of Variant Management called Variant Management Central (VCC). Ask me, or any of my colleagues about how we can help your company choose the best alternative for you.
Stay ahead of the curve by following our blog