Complexity Manager Release 2019

Complexity Manager Release 2019

Complexity Manager Release 2019

Variant Management in times of digital change - as much data as necessary and as few as possible!

"Data is the new oil of the world economy," as we often read. But how much oil is necessary and how well does it flow to get product variance and production going smoothly in the sense of industry 4.0? Can the comparably "old" data of product variance simply be transferred to the new data world that is currently developing on the production side? This should at least be checked. A good support for this: The Complexity Manager in its new release CM 2019.

Some of the key questions about product complexity:

How can Variant Management be made fit for digital change?

It has never been boring in Variant Management, so this is not to be expected in these times of digital change: In addition to the product variants themselves, the use of data as a topic is consequently gaining in importance. The quality and quantity of product diversity data will be decisive for a successful transition to the "Industry 4.0 age". Only both together provide transparency and indication of the necessary extent of the scope to be automated in the production process.

    How many variants are necessary, how many are possible?

    The answer to this question is still essential. Of course, everything that is needed on the market should also be offered. However, the internal company processes around the order processing process do not have to be disproportionately complex. Market-specific requirements are initially described independently of the technical implementation in order to identify the maximum possible degrees of flexibility for the later development of components and their tools. This leads to two views of the product: The rather "solution-neutral" view of the market and the "solution-specific" view of the manufacturing company.

      How do you get an early market picture of the product requirements?

      For the rather solution-neutral view, the market requirements are included independently of the technical solution. The product features and their options are defined from the market's point of view and combination restrictions are derived. The resulting overview (Feature Tree) is supplemented by quantity forecasts or real sales. The result is an overview with variants that can be sold well and less well, so that concrete indications for the definition of equipment packages can be derived at an early stage.

        How can the number of part variants be determined before the actual development?

        The second view of the product establishes the connection between market requirements and technical implementation. In a first approximation it is assumed that the variants of the technical components are to be justified exclusively by the market requirements. According to this understanding, a component is only changed or newly developed if there are concrete market requirements behind it. If these are known, the number and volume of each future component variant can be determined with the help of experience from development.

          Which costs can be avoided at an early stage?

          In case of in-house production, you can calculate the investment requirement for tool costs, for example, because of the overview of variance in components (Variant Tree), derived in this way. In connection with the required quantity of the component variant, which is derived from the quantity forecasts or real sales of the final product, it also becomes clear in each individual case, which investments are worthwhile and which are not, based on the sales figures. If necessary, a standardization of variants appears to be an opportunity in order to reduce the investment requirement. In the case of a supplier production of components one can give clearly more concrete data to the necessary number of variants and the respective requirement quantity.

            What are the effects of new market requirements?

            As the market requirements are regarded as the main reason for the creation of variants here, the effects of changes in these requirements can also be simulated: If, for example, an additional power for Europe is required on the market, it is possible to derive directly, which components have to be newly developed or revised if this requirement is to be fulfilled. All components, whose variance is determined by power, are affected by this change. This also makes it possible to estimate the costs caused by new development or tool procurement very early.

              Where is the optimal variety with the lowest possible processing effort?

              The consideration of the product variants from a market and engineering point of view enables early variant planning. If the market view provides forecasts or real sales figures for the variants, the technical view provides information on how many different and identical components can be used to realize the product program. Most sales with the smallest number of different components represent an optimum of variant diversity. In the last 40 variant analysis projects carried out, almost 80% of total sales were on average achieved with 24% of all variants and 44% of all part numbers.

                What amount of data should be provided for the configurator?

                As the overwhelming majority of the analyses lead to the result, that more than 80% of the sales volume is achieved with about one third of the product variants, it is certainly advisable not to store all feasible and possible variants in the configurator. The programming of all variants for the configurator would be very time-consuming and therefore also very expensive and it is not even guaranteed that every programmed variant is demanded by the market. Instead, it is advisable to divide the product range into a configurable ("CTO") and an order-related ("ETO") area. The order-related area is not stored in the configurator, but is only technically developed to completion when a concrete customer order has been received. This fulfils the guiding principle: "As much data as necessary and as little as possible".

                  How flexible must the product architecture be, how static may it be?

                  More than ever, market requirements are subject to continuous change. Some change more or never, others very often. Since market requirements are the main reason for the variance of components here, it is also possible to deduce at a very early stage which components need to be adapted or changed more frequently. This must be taken into account when implementing market requirements on both the development and production sides. The flexibility required by the market must be implemented flexibly in the product architecture and production with justifiable effort.

                    Which variant is to be planned when?

                    Not every variant of a product family is demanded on the market at the same time. This also means that you do not have to offer all variants on the market immediately, but that you usually have to plan for this one after the other at intervals of months, if not even years. The requirements of the market also play a major role here, as they are exactly what are required at different points in time. New Cabriolets, for example, are mainly launched in spring, a limousine perhaps only in autumn before a small truck variant is added next spring. This also has an effect on the component variance, as some of it will only be needed at a later point in time. The Complexity Manager uses the life cycles of the individual final products to recalculate the point in time for the necessary procurement of suitable components. Thus also here again very early a concrete plan exists, when which variant with which components is to be considered.

                      What potential can be realized?

                      When planning variants, investment costs can be avoided or optimized by standardizing components through early recognition of product variants that are in low demand on the market and therefore components that are not required. A streamlining of product variants leads to permanent "maintenance costs" being saved. The order of scale is different for each component and variant. Therefore, there can never be just one answer to the question "What does a variant cost?" If, in addition, investments in tools are avoided in variant planning, the potential is in any case in the millions.

                        Summary from the point of view of the market

                        From the point of view of the market, it is important to first find a clear definition of the requirements that are to be formulated as solution-neutral as possible from the technical implementation. The option of "seat heating" in a car is the right wording. "Electric seat heating", on the other hand, would be the wrong choice, since the market only considers the "seat heating" function to be important, but not the fact that the manufacturer implements this with electrical energy. In summary, the Complexity Manager offers the following options for analysing and planning product variants from the market's point of view (s. right slide).

                          Summary from the point of view of technical implementation

                          With the procedure described, it is possible to plan the diversity of components before they are actually developed. This also enables the early recognition of potential savings, especially in the development and / or procurement of tools, machines, etc. A subsequent adjustment of variants of the components always makes sense, but in this case the investments have already been made. As the Complexity Manager enables early planning of the variance right down to the parts list, it also makes a considerable contribution to cost avoidance, as it helps to plan these investments in concrete terms.

                            Get in Touch

                            Michael Friedrich

                            Jörg Starkmann