FISCHER, Jörg W.: ERP, PLM, MES and CRM - Part 2 - a look into the future
In: ERP Management,
Berlin, (2023)3, pp. 16-21.
In Part 1 of this article, the change in the position of ERP in companies was explained. One reason for this change is the realization that the change dynamics of all master data have increased, so that their lifecycle management is coming into focus. ERP, as the previously dominant IT system in companies, is coming under pressure with regard to its supremacy.
In part 2 of the article, the future position of MES in the context of PLM and ERP will be explained on the basis of this argumentation, in order to then look at future IT system coverages of companies from a methodological perspective.
The MBOM as a gateway to the MES
A much-discussed topic in the industry is the position of Manufacturing Execution System (MES) to ERP and PLM.
Figure 1: Change in the automation pyramid
Up to now, it has been common practice to supply MES with the necessary information from ERP (Fig. 1, earlier view). Apart from the production orders from the ERP, a basic skeleton of master data is necessary to fulfill the tasks of the MES. The foundation is the MBOM. Assuming that in the future master data and thus also the MBOM will be created and further developed in a lifecycle management system (see part 1 of the article), the question arises why MES is not directly supplied with the necessary master data from there.
This discussion is currently being held intensively in many companies. It has been made possible because many PLM systems have now implemented the necessary functionality for modeling MBOMs.
Why PLM is preparing to displace ERP from the top of the automation pyramid?
If the MBOM is created in the PLM in the future, then it must be supplied to both the ERP and the MES. Without MBOM in ERP, no MRP run. Subsequently, it is often argued that regardless of the MBOM origin, it would be much easier to continue to transfer the MBOM from ERP to MES. This is a valid view.
At this point, the second blind spot of the classic ERP-centric view becomes apparent. It becomes clearly visible when ERP and MES are more precisely differentiated. In MES, as in ERP, processes are planned, initiated and their completion documented. MES differs from ERP in the following points, among others.
- MES maps processes and time horizons in a much more fine-grained way
- MES is more flexible, easy rescheduling of processes is well possible
- MES has a technological and not a commercial information model
Point 3 is essential for the chain of reasoning pursued. Instead of looking from a commercial perspective, like ERP, MES looks at information and processes in companies from a technology-oriented perspective. This is now clearly crystallizing in the context of increasing digitization. Since PLM, like MES, implements a technological information model, PLM is preparing to displace ERP from the top of the automation pyramid.
Second blind spot - commercial models in ERP are sufficient
The original assumption of the ERP centric view that a commercially designed information model is sufficient for technological aspects cannot be maintained in this way in the future.
Figure 2: Technological vs. commercial information models
The key to penetrating this aspect is semasiology, the study of word meaning. People assume that things mean the same thing when the same words are used. This assumption works in everyday life, but it fails when it comes to the task of merging information models from different IT system classes (ERP, PLM, MES).
Figure 2 shows an example of this. Fig. 1 (detail A) shows an assembly system consisting of three resources. Figure 2 detail (B) shows its illustration from a commercial point of view. Figure 2 (C) shows the technological view. Both models have an identically named object, the resource. Semasiologically, however, the objects have quite different meanings.
Technological information models are not a refinement of commercial models
Technological models are not a refinement of commercial models. This can be well illustrated by the example of a resource group. In the commercial view, resource groups are formed on the basis of a common cost rate, among other things. In the technological view, resources are grouped based on comparable technical capabilities. This can be seen in the current discussion about detailed planning and Advanced Planning and Scheduling (APS) systems. Traditionally, there are solutions for detailed planning in ERP systems. However, these have never really established themselves due to the contexts described above.
Low code is not the answer.
If the technological view is forced into a commercial information model, this can usually be seen in the large number of Excel spreadsheets in circulation. These then give the technological process the space it needs. The argumentation that low code systems could permanently replace Excel is not correct at this point. Where fundamental technological information models are lacking, these will not emerge by themselves through the use of low code.
The primacy of ERP in enterprises is coming under pressure.
Against the backdrop described above, the predominant position that ERP systems have held in companies up to now is coming under ever greater pressure. In some companies, there are already discussions about reducing ERP systems to their core functions, i.e., the tracking of quantities and value flows, and focusing on a completely separate development of the technological chain.
Are today's PLM systems suitable to carry the future technological and commercial master data models?
The argumentation outlined is now also often taken up by established PLM vendors in sales situations. PLM systems are then presented as if they could already map the lifecycle management of all master data, i.e. technological and commercial. It must be stated here that the information models, functional scope and flexibility of most PLM systems available today are far from sufficient to fulfill these tasks. Whether they are even suitable for this task due to the often very specific design of their information models remains to be seen.
xLM ≠ PLM - Digital Information Architecture - the undiscovered country
Accordingly, it is to be expected that a new layer will emerge above the processing systems (ERP, MES ...). The task of this layer is to handle the life cycle of all master data. In addition, it must be able to map and suitably unite commercial and technological information models. Master data is merely the result of complex creation processes. The new layer must therefore also be able to carry the necessary information models for this task. The trend toward smarter products that integrate into converging scenarios (Systems of Systems concept) creates a number of particularly challenging use cases (keyword: Model Based Systems Engineering MBSE).
A suitable name for this layer would be Digital Information Architecture or x-Lifecycle Management (xLM), where x is a variable representing a respective letter (e.g., P, A, C ....) depending on which facet of the layer is being considered.
Figure 3: The future position of the major system classes
Figure 3 shows the overall architecture of a possible future situation. In this architecture, the creation and lifecycle management (xLM) of the information is separated from its use in the settlement systems. The xLM layer provides the settlement systems with the necessary master data that is version and time correct.
Figure 3.5: xLM components
The xLM layer is still undiscovered land today. It is not yet implemented! Today's PLM, ALM and PIM systems are only the first explicitly visible facets of this emerging layer. As expected, the new xLM layer will not be a classic monolithic IT system. Rather, it can be assumed that different, distributed, microservices-based approaches to implementing this layer will emerge in the future.
Figure 4: Digital Information Architecture and IDSL layer
Digital Information Architecture ≠ Analytics, Data Mesh or Digital Core
The topic of xLM is already being addressed in some industry discussions. In this context, terms such as digital core, data mesh, data lake and knowledge graph, etc. are often used. Very different topics are often mixed up here. This is due to the fact that another layer is emerging at the same time as the xLM layer. This can be called the Industrial Data Science Layer (IDSL, Figure 4). Its task is to provide the platform or components and to generate entirely new contexts, insights and values from companies' data treasures. For the IDSL layer, different technologies (Knowledge Graph, Graph Databases) and architectural paradigms such as Data Mesh and Data Lake are discussed. Fashionable topics such as process, product and portfolio mining are only the first harbingers of the new IDLS layer. Consistently thought out further, a new intelligent control layer for companies is emerging.
Disruption makes no exceptions!
Following the argumentation, the coverage of ERP in companies will shrink significantly. Instead, completely new, fascinating spaces are opening up.
ERP vendors who retreat to their core competence of ERP in this situation and leave the field to others are taking an enormous risk.
Disruption will make no exceptions! Not even in front of big players.
ERP gained its outstanding importance in the past because leading vendors succeeded in setting the standard of today's valid business management view of companies with their ideas, methods and their technological implementation.
Accordingly, it is to be expected that in the future those vendors will have particular success who succeed in formulating a new, groundbreaking and holistic view of companies and establish this as the future standard. This and nothing less should be the claim of the large ERP vendors!
There is still time.