Summary of Key Points
This article exposes a common “ERP dilemma” in corporate digital transformation: ERP systems, which require significant investment and time to implement, often transform from an “efficiency engine” into a “burden.” The root of the problem lies not in insufficient technological upgrades (such as moving from a monolithic architecture to microservices), but in a fundamental misconception about how these systems should be designed. Specifically, the idea that management rules, business processes, and system records are three completely different entities that must be tightly integrated is misplaced; moreover, the causal relationship between them is also reversed (it’s assumed that “systems determine operations,” when in reality, “operations create systems”).
The article proposes a “four-layer decoupling model” as a solution. By separating these four layers—operations, processes, management, and systems—the underlying issues of bloated and inflexible systems can be addressed at their core.
The “Boulder Dilemma” of Traditional ERPs: Why Do Systems That Cost Millions Become Stumbling Blocks?
The intention behind implementing ERP in companies is good: to improve efficiency, standardize management, and consolidate data. However, problems arise shortly after deployment:
- Front-line employees are frustrated: The system responds slowly, and forms are cumbersome (for example, purchasing orders require filling out more than a dozen fields, and a missing attachment can prevent submission).
- Management is overwhelmed: Necessary reports take a long time to generate, and strategic changes (such as streamlining approval processes) cannot be quickly implemented through the system.
- IT departments are constantly in a frenzy: They spend days patching bugs, adjusting interfaces, and performing custom development, trapped in a cycle of constant maintenance.
In the end, what should have empowered the company becomes the biggest obstacle to its flexible transformation—a “boulder” that is extremely difficult to move.
Why Don’t Technological Upgrades Solve the Problem? Microservices and Configuration Are Just a Band-Aid
The solutions offered by vendors may seem advanced: switching from a monolithic architecture to microservices, or using BPM (Business Process Management) and low-code tools for configuration (e.g., drag-and-drop process customization). But what’s the real effect?
- Configuration is an illusion: On the surface, no code needs to be changed; parameters can be adjusted in the interface (for example, changing the purchasing amount threshold from 1 million to 500,000). However, the underlying logic remains tightly linked. Changing one parameter may unexpectedly affect financial report calculations or trigger a process loop.
- Systems become configuration mazes: To accommodate various exceptions and special approvals, the number of configuration options increases, creating a complex, unreadable “web.” Even if the technical adjustments can be made in minutes, organizational reviews take months because no one dares to make random changes.
In essence, these technological upgrades merely replace “hard-coded code” with “hard-coded configurations,” without addressing the core issue of coupling between different system components.
The Ultimate Root Cause: A Misunderstood Causal Relationship
The biggest mistake with traditional ERPs is reversing the causal sequence:
- Traditional approach: First, establish rules (e.g., “purchases must be compared with at least three suppliers”), then design processes, and finally implement them in the system.
- Realistic sequence: Companies first start operating (for example, in their early stages, purchasers place orders directly by phone), encounter issues (such as bribery or supply disruptions), and only later do they develop corresponding rules.
Rules are based on past experiences, while actual operations are dynamic and real-time. Traditional ERPs tie management rules, processes, and records together, making it extremely costly to make any changes—this is the true reason why systems become increasingly cumbersome.
The Way Forward: The Four-Layer Decoupling Model
To solve this problem, the four different layers with distinct lifecycles must be completely separated:
1. Operations layer: The actual events that occur within the company (e.g., customers placing orders, suppliers delivering goods, inventory changes) form the foundation.
2. Process layer: Summaries of common operations (e.g., “place an order → deduct inventory → ship the product”), focusing on optimizing these paths without imposing constraints.
3. Management layer: Dynamic restrictions on operations (e.g., approvals required for amounts over 1 million), which can be adjusted at any time without affecting the processes.
4. System layer: This layer only records the traces of operations (e.g., who placed the order, how much inventory has changed) and does not participate in management or process logic.
For example, to lower the purchasing approval threshold from 1 million to 500,000, the management rules need to be adjusted—no changes are required at the process or system level. This makes the system more flexible and avoids creating a cumbersome obstacle.
Conclusion
The dilemma with traditional ERPs is not a technical issue; it’s a matter of outdated mentalities. Only by breaking the misconception that “systems determine operations” and adopting the four-layer decoupling model can digital systems truly become an agile aid to businesses, rather than a burden. This is a valuable lesson for all companies undergoing digital transformation.