Digitalization and the need for companies to react agilely and quickly to customer requirements are changing the role of ERP systems in companies. In this article, starting from the classic role of ERP in companies, the transformation to its future role is highlighted, also showing the interaction of the major system classes ERP, PLM, CRM, MES and CPQ. The article is split into two parts. The first part deals with the current transformation of the position of ERP systems in companies, while the second part discusses the future of IT systems in companies.
The initial release can be found here:
FISCHER, Jörg W.: ERP, PLM, MES and CRM - a new perspective - a new universe - part 1
In: ERP Management,
Berlin, (2023)2, pp. 16-21.
Change in the position of ERP in companies
Many companies are aware that digitization will fundamentally change their business and the industry. Recent technology leaps and global crises have created a potential for multidimensional disruption that has probably never existed in this form before.
This creates the need for companies to question themselves in all areas, to embed agility in their processes, to be able to react quickly and effectively to changing customer requirements, and also to deal with data-based business models.
This has implications for information architecture and IT system design, and also fundamentally changes the role of ERP.
The original position of ERP in companies
The emergence of ERP systems at the end of the 1980s was tantamount to a revolution. For the first time, it was possible to track a company's quantity and value flows, control production and the supply chain, calculate manufacturing costs and prepare balance sheets in an IT system.
Covering so many fields of application in one central IT system has led to an ERP-centric view in many places, which assumes that all corporate functions can be united in one large IT system, the ERP, and that nothing else is necessary in the company apart from this one large IT system.
This view includes two major blind spots that still have an impact today. One of the blind spots first became visible with the emergence of Customer Relationship Management (CRM) and the accompanying success of Salesforce. The large ERP manufacturers, first and foremost SAP, were never really able to establish themselves in this area. The reasons for this are complex. One hardly noticed, but essential reason is the fundamental difference in the thinking and modeling approach of ERP and CRM. An ERP system is designed by data model and functionality for the formal processing of procedures, in the sense of transactions. This basic logic also shapes the thinking and actions of the vendors of such systems. A CRM system, on the other hand, follows a different interpretation. The essential business object in the CRM system is the opportunity, i.e. the sales opportunity. An opportunity is not very formal. It has a life cycle and is developed piece by piece as it matures. A strictly formal and transactional process logic, as necessary in ERP, is unsuitable for a CRM system.
Types of data and what they can tell us
The described situation already points to one of the blind spots of the ERP-centric view. It becomes even more obvious when the data types of the ERP are broken down (see Figure 1). SAP S/4HANA terminology is used to explain this. Figure 1, Detail A shows a company with an ERP as the leading IT system. The data in the ERP system can be categorized as organizational objects, master data (with and without organizational reference), and transaction data. Organizational data has the tasks of representing real (e.g., plant), real-abstract (e.g., MRP area, sales organization), and legal entities (controlling area, company code, etc.) in the enterprise. Master data is defined as basic data that is not changed over a certain period of time. Transaction data in ERP documents which transactions are pending, are to be executed or have already been executed.
Figure 1: ERP and the necessary data types in companies
ERP system vs. master data
To summarize: "The main task of an ERP system is to initiate processes and document their completion. The processes in focus concern quantity and value flows. The focus is not on the description of how a process is to be carried out, but rather on the formal documentation, its completion and the associated quantity and value movements. The master data provides the necessary framework or skeleton for this task (see Fig. 1 Detail B).
Figure 1, Detail C shows the people in the organization who use office applications, etc. generate information, essentially master data. From a classic ERP-centric perspective, this appears normal. Assuming that master data does not change over a period of time, this view is also understandable. "
First blind spot - today master data are in constant change
Today, this assumption is no longer true! This has crystallized in particular through the change in process patterns in the discrete industry. The driver for change is the need for companies to be able to react quickly, effectively and cost-neutrally to changing customer requirements. The market demands to be offered highly individualized products, if possible in delivery times and at the price of standard products. The process patterns Select to Order (STO) and Engineering to Order (ETO), which were still common in many companies in the noughties, are now almost universally evolving towards Configure to Order (CTO/CTO+). The knowledge of the existence of different process patterns and their formulation is one of the essential findings of the past years. In classical ERP-focused literature, stockpiling strategy, including Make to Stock (MTS), Assemble to Order (ATO), or Make to Order (MTS) (Figure 2, Detail A) are mentioned in a series with the Engineering to Order (ETO) process pattern (Figure 2, Detail B). Today, it is necessary to clearly separate process patterns of information creation from material stockpiling strategies. The strategic choice of the stockpiling strategy determines the respective location of the customer decoupling point and thus how the lead-to-cash process is linked to the plan-to-produce process (directly coupled or decoupled via stockpiling).
Figure 2: Process patterns vs. stockpiling strategies
Process patterns (see Figure 2, Detail B) determine how the creation, maturity development and change processes of the product-relevant master data (hereinafter referred to as information creation) must interact with the execution processes, i.e. lead to cash and plan to produce (hereinafter referred to as information utilization). Their exact determination (see Fig. 2, Detail C) is the central design criterion for the implementation of Product Lifecycle Management (PLM).
The interlinked processes
Figure 3 shows the main process patterns and the interactions between the processes for information creation and information utilization in a highly condensed form. In strict STO, information creation and information utilization are decoupled. The product is developed and produced after the start of production (SOP). The classic view that master data does not change over a period of time is largely true with STO. With strict ETO, the creation of information is included in the use of information. Here, too, the classic view of largely stable master data applies. With ETO, a large part of the product components are developed for an individual order. Since the resulting information is only used in this order, the master data remains largely stable.
Figure 3: Interaction of information creation and use in different process patterns
Everything different at CTO+
In the CTO+ process pattern, however, this situation changes fundamentally. In CTO+ (see Fig. 3, detail D), standard product components are supplemented ad hoc by individual development in the case of an order. This must be done in a highly automated manner and in the shortest possible time. Information creation and information utilization must interact in a highly dynamic manner. Order-specific components are often added to the modular system and then used across orders and product lines. This results in an increase in complexity with a significantly higher frequency of changes to product-related master data. Increasing verification requirements further exacerbate this problem.
In the case of the CTO/CTO+ process pattern, master data is therefore subject to frequent changes that have to be made at very short notice. As a result, the creation and lifecycle management of these pushes into the focus of consideration. This has been clearly demonstrated in recent years by the increasing popularity of product lifecycle management (PLM) in industry.
EBOM & MBOM - The need for a multi-structure approach
Appropriately handling the maturity development and lifecycle of product-related master data is very challenging for companies. The CTO+ process pattern requires the construction of product lines consisting of reusable modules. The product structure that represents such a product line (usually referred to as Engineering Bill of Material (EBOM) 150 %) must be functionally structured to represent these modules. When implementing the CTO+ process pattern, assembly is usually changed from place assembly to line assembly concepts. For this, a Manufacturing Bill of Material (MBOM), which contains stockable assembly modules, is mandatory as input for the MRP run (MRP for Material Requirements Planning) in the ERP. The structure of the MBOM is based on the production layout. This approach is subsumed under the term multi-structure concept and replaces the previously common way of thinking that product structure and bill of material were the same thing.
The importance of product lifecycle management in the order-to-cash process
In the course of the order-to-cash process, the EBOM 100 % required for the order is created from an EBOM 150 % and then supplemented ad hoc on an order-specific basis (Fig. 3, detail E). This EBOM 100 % is subsequently transformed into an order-specific MBOM 100 %. In the CTO+ process pattern, the maintenance of the EBOM and MBOM as well as the transformation of EBOM into MBOM are thus located in the Product Lifecycle Management (PLM) task area and thus in the PLM system. From there, the MBOM is fed into the ERP. The earlier idea that the bill of materials would be created in the ERP is therefore no longer up-to-date with CTO+.
In summary, it can be stated: The position of ERP in companies is changing. The CTO/CTO+ process pattern is changing the view of ERP and the master data. Whereas these were once regarded as stable in the longer term, they are now subject to highly complex dynamics. Their emergence and lifecycle management is moving into focus and thus directing the view to PLM. ERP as the hitherto dominant system in companies is coming under pressure as a result of the increasing importance of PLM and CRM in its claim to cover all essential corporate functions. This can be seen publicly in particular in the partnership between Siemens and SAP and in the accompanying intensive discussions about how ERP and PLM systems should interact.
A very current topic and one that directly follows the previous argumentation is the position of Manufacturing Execution System (MES) to ERP and PLM.
Figure 4: Change in the automation pyramid
Read in the next part how PLM is preparing to displace ERP from the top of the automation pyramid and why the MBOM in PLM is the gateway to MES.
The 5 most important facts
- ERP systems, which emerged in the 1980s, revolutionized the way companies managed their production, supply chains and finances.
- It is wrong to think that everything in companies could be consolidated in a single ERP system.
- ERP systems focus on initiating and documenting processes related to quantity and value flows.
- Master data provides the necessary structure for implementation.
- Today, master data is no longer stable, but subject to constant change due to the demand for highly individualized products.