CPQ, ERP and PLM? - How do you actually bring them together?

Post 1: CPQ, ERP and PLM? - How do you actually bring them together?

Post1

Now first of all: CPQ = Configure Price Quote!

So we are talking about configuration systems that are primarily designed to configure offers.

Quotations consist of price items!

This is often where the first problem of understanding begins.

Are price items also material items (in the sense of saleable materials)?

Sometimes yes, but often not! This results in two cases.

• Case 1: Equality of price items and material items is established, then CPQ can be linked to ERP and PLM via these items. Caution is required here. In contrast to price items, material items have a different life cycle. This is because price items are not or not always subject to the Form Fit Function principle! Accordingly, they have other requirements for interchangeability. Since price items usually have no hierarchy and in order to have room for "MBOM" assemblies in lower BOM levels, the items are often placed very high up in the product structure. This reduces the flexibility of the configuration and thus the overall solution.
• Case 2: If price items and material items cannot be unified, CPQ can only be linked to ERP via the variant space or the configuration string to be transferred. When consultants talk about high level (CPQ) and low level (BOM) configuration this is often the case. With a closed CTO and little change frequency on the construction kit, this often works without problems. With CTO+ this is a special challenge because
  • the variant spaces acting in the assemblies are subsets of the variant space in the CPQ and must therefore be aligned with it. This requires a distinctive configuration lifecycle management.
  • the question arises whether the EBOM/MBOM transition must happen before or after configuration.
  • a configuration anchored on the logistic bill of materials (keyword - KMAT) makes the storability of assemblies more difficult (works only with the specification of a storage variant).

That's as far as it goes in a nutshell.

Of course, the whole thing is very much dependent on the particular process pattern and the underlying product line.

What do you think about the topic?

What are your experiences?

If you have any questions, feel free to post them in the comments. I will try to answer them in my own posts as well.

We at RIM will be happy to help you work out the configuration strategy and the resulting interaction between CPQ, PLM and ERP.

Post 2: CPQ, ERP and PLM? - Which? Single-level or multi-level configuration?

Post2

Today for you the second post about CPQ, ERP and PLM.

It's about single-stage vs. multi-stage configuration.

Perhaps you have already heard the different arguments. Some argue that multi-level configuration would be too complex and swear by single-level configuration. Others have 5-7 level KMAT in their SAP systems. Mostly only specialists can handle this (I have experienced a company that had only 2 people for this and asked them never to fly in the same plane at the same time 😊) - but it works!

Today I would like to shed some light on the background:

• Single-stage configuration:
  • Single-level configuration follows the idea of generic product structure (GPS). The GPS is structuring in the superstructure until it comes to a level with positions and their variants. This is then the level of configuration. Below this level are assemblies. What is the background of such an approach? In most cases, an EBOM is made configurable, i.e. the structure is functionally systemic. Since an MRP-capable BOM is nevertheless necessary in the ERP (single structure concept), the configuration level is usually placed far up in the structure. Thus, starting from the assembly level, there is still a lot of room for the "MRP-capable" structure. The assemblies are then often an EBOM/MBOM compromise. If this succeeds, no explicit EBOM and MBOM separation is necessary. This case is used when companies evolve from ETO to CTO+. We like to refer to this as Late Industrial Engineering. The case also applies to line assembly. Here it is sufficient to create groups of material that are delivered to a specific takt. This enables a single-level configuration so that GPS is broken down to the level of the assemblies delivered to the line.
  • Multi-level configuration:
• ... and how is it now with multi-level configuration?
  • Here, an M(RP) BOM is made configurable with all its MRP levels. For the MRP run to work, the necessary MRP levels must be present in the BOM. Therefore, for highly variant products, a multi-level configuration is necessary. This is especially necessary if the variance sits in the depths of the structure, as it would then multiply out up the structure and all of these variants would then need to be marked out.
  • Why is this possible without defining the MRP levels as material numbers? The MRP run generates production orders. A production order is implicitly linked to a location in the assembly layout. If all variants that a structure or MRP level contains can be assembled at this location, then it is sufficient to create a KMAT (configurable material in SAP) for each of these locations. This configures the necessary variant on the respective MRP level, which is then assembled there.
  • Now here one could still write technical books, why in which situation which procedure is the correct one. Especially with the advent of multi-structure concepts, this topic has come into focus even more. The question is which case you need:
  • - 150% EBOM → 100% EBOM → 100% MBOM
  • - 150% EBOM → 150% MBOM → 100% MBOM
  • - 200% EBOM → 150% MBOM → 100% MBOM Etc.

If you need sparring or support for this, we at STZ-RIM can work out a solution concept tailored exactly to your case and your software development.

What do you think?

What approaches are you taking and what challenges are you encountering?

Have I forgotten something important that needs to be added?

Post 3: CPQ, ERP and PLM? - SAP KMAT or what does configuration mean in M(RP)-BOM?

Post3

Today for you another post about CPQ, ERP and PLM.

In future posts, I will go into further detail about future configuration requirements.

Today, however, first the classic par excellence explained.

Configuration in a 150% M(RP)-BOM that takes place during the MRP run and what logic is behind it (especially interesting for PLM experts who often don't know ERP logics or not very well :). Configuration in a 150% M(RP)-BOM is especially common for CTO+ process patterns with stable modular building blocks. The solution approach is also particularly popular with component manufacturers, for example.

The picture shows the basic logic. You can see the M(RP)-BOM 150% (4711-KMAT) for the fruit gums. You can see an empty glass bowl on the left side of the picture. This is a Production Location in the production. At this the fruit gum bags are mounted. There are 2x variants. The gold bear bag and the cola bottle bag.

At SAP ERP would be mapped as KMAT and a 150% #M(RP)-BOM from it. It would look like in the picture (4711 KMAT).

The MRP run is performed via . The instantiation context of the KMAT is the Production Location. Since both variants are assembled at the same location, they can be combined in the M(RP)-BOM 150% (4711-KMAT). The context defined from the #MRP -run generated Production Order rich a reference to the Production Location. The #Vvariantwhich is formed is then part of the Production Order (to be seen at the small black box on the Production Order). Is it now the desire to put the finished products on Bearing to lay a Material variants (4712 and 4713 on the right in the picture) are necessary.

Material variants must be single-variety! This is due, among other things, to the fact that everything that is grouped together in a storage bin should be subject to the 100% interchangeability principle (form-fit-function principle).

The KMAT therefore has a production location reference, whereas a material variant has a storage location reference. If you use KMATs without a material variant, all intermediate assemblies are not storable.

Often this approach was still implemented under the idea of the single structure concept. Thus, in practice, the KMAT BOMs are often subject to an EBOM/MBOM mixture. They then often contain structural levels that express functional module assemblies and not production locations. For companies, this is often reflected in the fact that certain logistics processes, such as advance planning for assemble-to-order or intercompany processes, are not so easy to implement.

What do you think. What is your experience with the classic use of the configuration with M(RP)-BOM 150% in MRP run?

And as always, if you want to implement a modern multi-structure concept with MBOM, CPQ and configuration fully stockable and highly automated then we at RIM will be happy to help you.

Post 4: CPQ, ERP and PLM? - What is actually the difference between additive and subtractive configuration?

(Post4)

Today for you another post about CPQ, ERP and PLM.

I would like to address the issue of additive and subtractive configuration.

• Subtractive configuration
  • • If one thinks about configuration, one has mostly substractive configuration in the sense. From a maximum BOM or a maximum scope those elements are subtracted by configuration rules, which are not relevant for the respective configuration.
    • Once the structure to be configured (often a BOM or a quotation) has a rule for each of the possible elements. Thus a variant condition (object dependencies). If one wants to start the configuration now, then characteristics are selected for this entire structure (typically the product line). The rule mechanism now compares the selected characteristics with the variant conditions and subtracts everything that is not needed.
    • Before that, there is the feed-in (i.e. the feed-in of dependent characteristics that must follow the input) and the buildability check (checking whether the characteristics are valid in the combination). What is exciting is the wording that is used. You can hear which software is used in companies by the words they use. (SAP: KMAT, characteristics, characteristic values, object dependencies; Teamcenter: (Named)VariantConditions, Stored Option Sets, Option Families)....

   

  • • Additive configuration
      • • In contrast to the subtractive configuration, the elements are not subtracted but collected in the additive configuration. Some surely think now of the established expression Solution Configuration. But this is only a small part, because there are several configurations that are additive. Let me list what comes to mind. Feel free to add to it:
        • ETO - from the construction kit - from construction kit elements the respective are collected, copied and adapted if necessary. We like to call the structure for collecting Technical Order Structure or TOS.
        • Geometric configuration via connector points.
        • From a set of elements, the respective ones are selected and positioned appropriately (2D or 3D). The positioning is done via connector points, which also know which elements can be docked to them or which pairings are permitted. The corresponding configurators then often have very fancy 3D interfaces.
        • Pick up for a matching shopping cart.
        • Often additive configuration is also used to pick up components that fit together. Here, product discovery is associated with configuration. It is important that the user gets matching components in the shopping cart via additive configuration.

      Caution. - In most cases, you won't find the pure forms of additive or subtractive, but mixtures, and it is certainly possible to wrest additive functionality from subtractive mechanisms. This may sound strange, but I have already seen it in industry.

      So at the point you could certainly find many more examples of additive configuration. I look forward to additions and comments.

      If possible, no comments from sales whose bottom line is that the configurator they offer can do everything 😊. I know you have to say that, and in the end, unfortunately, it is often not true.

   

Post 5: CPQ, ERP and PLM? - Design Automation within Configuration

Post5

Today for you another post in the context of the topic CPQ, ERP and PLM.

I would like to address the topic Design Automation dedicate.

At Design Automation is about generating design documents e.g. 3D models and ECAD models automatically. I will focus on MCAD models and on a single part. Imagine you create a template of a CAD 3D model. The template then describes the topology of the later part. If the template is now provided with appropriate parameter values (e.g. dimensions, length, width, height, etc.), the template can be instantiated to a complete 3D model including drawing. For the computation of the parameter values rules and/or computation (often also complete design computations) are necessary. These rules are executed in a rule engine (configuration engine). This is the core of the Design Automation.

Now, however, you have to hollow out further. Often, the rules were stored in the CAD system. Designers have then made a mockery of such rules. If this is done, however, a proprietary island is created and the rules cannot be used outside the specific CAD system and are also difficult to maintain. Therefore it is important that the rule engine runs on the server side and is independent of a proprietary application.

If the structure of the assembly or product can now also be put together in the rule engine on the basis of rules, ideally all the necessary documents and models for this assembly will be obtained.

So far so good. So the CAD-BOM is available at this point. This must now be transferred to an EBOM and, if necessary, an MBOM. If you have the production capability internally or always work with the same suppliers, the document for the part/(global) material can be realized as 1:1 in the EBOM. For the MBOM, the material now needs the attributes necessary for the logistical and commercial evaluation as well as the routing. In the case described, these can also be defined in advance as templates and generated by the rule engine.

In the transformation from CAD-BOM to EBOM and MBOM lies the key to the full automation of the Desing Automation Process.

Often we see great automations from the RIM that then slide into tedious manual work after the CAD document is created. Sometimes also parallel non-synchronized processes so that Desing Automation run in parallel to a non-synchronized logistic configuration.

We at RIM have developed groundbreaking methods for methodically working through, planning and implementing the topic in such a way that a holistic configuration with Desing Automation becomes possible. If you want to know more, please contact us here.

And what is your experience with the topic?

Have you solved it yet and if so what was your approach?

I look forward to comments and feedback.