CPQ, ERP, and PLM? - CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.

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

CPQ, PLM, ERP A topic that comes up again and again in consulting situations is how to bring CPQ together with ERP and PLM. It's a popular topic that can be discussed intensively. On Linked in, I have approached the topic in a series of posts that I would like to compile for you here.

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


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

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?


CPQ, ERP, and PLM? 🤔 - Which one is it? Single-stage or multi-stage configuration?**
CPQ, ERP, and PLM? 🤔 - Which one is it? Single-stage or multi-stage configuration?**


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?


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

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

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?


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

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

CPQ, ERP and PLM? - What is actually the difference between additive and subtractive configuration?
CPQ, ERP and PLM? - What is actually the difference between 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


CPQ, ERP and PLM? - Design Automation within Configuration
CPQ, ERP and PLM? - Design Automation within Configuration

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.


CPQ, ERP and PLM? - CPQ vs. ERP configuration 🤖 If you are reading this, you can save a significant amount of money for your company! 💰

Post 6

CPQ, ERP, and PLM? - CPQ vs. ERP Configuration 🤖 If you read this, you can save a significant amount for your company! 💰

Back with another post in the CPQ, ERP and PLM series.

I would like to look at the differences between configurations in CPQ (Configure Price Quote) and ERP systems.

Why can it save you money? CPQ vendor sales teams claim they can configure anything. They claim that, of course, but is that really the case? 🧐

👉 There are fundamental differences between configurations in CPQ and ERP systems. In essence, it is about the difference between high- and low-level configuration systems. From a methodological point of view, however, there is more to it than that.

👉 A CPQ system configures a quotation. A quotation essentially consists of quotation items that are assigned a price and textually describe what is to be purchased. These items are often equated with materials or purchasable items. This is sometimes true, as physical products are often sold.

❗️It it is important to understand that quotation items are not materials and do not behave like ERP materials.💡

👉 Why? Offer items encapsulate something that can be purchased. This can be a product, an abstract purchasable function, or something similar. In addition, while supply items have a life cycle, it is fundamentally different from that of materials. Materials adhere strictly to the form-fit-function (F3). However, a supply item can be easily replaced even if it does not conform to F3.
The variant space of ERP configuration is also different from that in CPQ. Typically, the options and option values in CPQ are much more extensive than in ERP.

CPQ systems are very well suited for high-level configuration (since they are designed for it) and often offer an attractive WEB front-end.

❗️With low-level configuration, especially with multi-level configuration approaches, it becomes difficult because many CPQ systems are not familiar with product structures and BOMs. Such scenarios quickly become highly complex and thus difficult to manage, and changes can become a real problem. One of the main reasons for this is that the diction of the product structure in CPQ often has to be modified via configuration rules and also hierarchies of configuration rules.

👉 I therefore recommend (depending on the case) high-level configuration in CPQ and low-level configuration, especially if it is multi-level, in ERP.
And in PLM? Configure there if you have a non-industrialized modular system (or kits) in a situation close to ETO or if you want to save designs. I will take up this topic in a next post.

I wanted to and could write much more, but that would make this post too lengthy.
So feel free to post your questions in the comments, and I'll be happy to answer them. ⬇️

I'm curious to hear your thoughts on this as well! 📢

If you want to tackle a #CPQ, #ERP or #PLM scenario, contact us at STZ-RIM Reshape Information Management. We are specialists, even for complex cases. 🌐

Get in touch with us today: https://stz-rim.com/kontakt/

CPQ, ERP and PLM? - Industrialized vs. Non-Industrialized Modular Kits 🧩.

Post 8

CPQ, ERP, and PLM? - Industrialized vs. Non-Industrialized Modular Kits 🧩.


Penetrating this topic is the central key to understanding the transition from ETO to CTO+ 🔍.

You may be familiar with the discussion 🗣️. Some say: configure and MBOM in PLM and then in ERP; others say configuration only in ERP. Which is correct?

With a few posts in the CPQ-ERP-PLM topic area, I would like to elaborate on this 🧐.

As a foundation, it is most important to understand the difference between - Industrialized vs. Non-Industrialized Modular Kits and thus also the difference between Early and Late Industrial Engineering 🤔.

At this point, many thanks to Ulrich Schmidt from BDF-Experts for opening our eyes 🙏 and Frederik Breckwolt and Dominik Mayer for the sparring🤼.

In the picture you can see a scenario 📸. Imagine that the modular system is being newly developed. This typically involves running through the V model 🔄.

At this point, there are two principal possibilities:

🅰️Fall A: The kit can be developed without industrialization, i.e. the final development for production has not yet been completed, as this only happens later, i.e. when the order is placed. Hence the name Late Industrial Engineering This is usually recognizable by the fact that only a CAD-BOM or EBOM kit (150%) is available.

🅱️Fall B: The modular system is already completely industrialized during development. The material is fully developed, so that the logistical handling and supplier selection is already complete. We also call this case Early Industrial Engineering. This is recognizable by the fact that an MBOM, or more correctly an M(RP)-BOM 150%, is already available for the SOP.

In the case of an order with a customer-specific share, the industrialized modular system (Fig. Detail C) can be reacted to very quickly, as industrialization is only carried out for the customer-specific share. In the case of a non-industrialized modular system (Fig. Detail D), it is necessary to carry out the complete industrialization 🔄. This gives the industrialized modular system a time advantage, whereas the non-industrialized modular system has a flexibility advantage.

To classify. Case A is a typical sub-case of ETO (we say ETO out of the box) whereas case B is an extended CTO case. We call it CTO+

What this means in the context of PLM and ERP-related PLM and how a hybrid approach between both cases can be implemented, you will learn in the following posts 📘.

#CPQ #ERP #PLM #Configuration #BusinessSolutions

CPQ, ERP and PLM? - CPQ- and E-BOM-based non-industrial modular kits in ETO-related cases🧩.

Post 9

CPQ, ERP, and PLM? - CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.
CPQ, ERP, and PLM? - CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.

In my opinion, the future lies in hybrid modular kits with a significant industrial content (>60-95%📊). These kits must be designed in such a way that they can be manufactured flexibly in the factory network🏭 according to the assemble-to-order principle. IT systems🖥 that support this must combine various configuration scenarios, i.e. additive➕, subtractive➖ and design automation🔄 in any form and must also be M(RP)-BOM-capable📋.

This is the ultimate requirement for resilience in a modern digital supply chain🌍⛓.

Most current approaches primarily pursue EBOM-based strategies for non-industrialized kits. These are diametrically opposed to the approach mentioned above. Setting them up is a good start for modularization, but only the first step🚶.

So it is time to investigate how CPQ works with EBOMs in PLM in non-industrialized cases🔍.

The principle is simple and illustrated in the following figure🖼. In CPQ, there are quotation items that customers can configure🛠. These are mapped in PLM as structure levels of an E-BOM. Since quotation items typically represent functional units, they result in functional assemblies. These functional assemblies cannot be assembled and also play no role in MRP🚫.
It is important to understand that these function modules, as anchors of the offer position in CPQ, do not have to follow the F3 principle. They only have different versions🔄.

Since the non-industrialized kits are usually very mechanical and CAD-oriented📐, many implementations still have the classic CAD-BOM/EBOM mix. It is even possible that these mixed structures have slight MBOM parts.
The automated transfer of this structure to the ERP usually fails. The reason is not the interface❌!
Why actually? Converting such a unified structure into an ERP-capable M(RP)-BOM structure requires tedious ERP-related Industrial Engineering🔧, which most of the PLM systems available today hardly offer.

What do you think? I'm curious to hear your insights on this topic! 📢

Please ask your questions in the comments, and I will be more than happy to answer⬇️.
If you are exploring a hybrid scenario, get in touch with us🤝. We are experts in designing such situations🌐.
Contact us today: https://rim-crm.odoo.com/r/Uid



Leave a Reply

Your email address will not be published. Required fields are marked *

More articles

The conference brings together experts, users and industry leaders to discuss the latest developments in Product Lifecycle Management (PLM) software and solutions....