Standardize Processes Before Implementing a System —— The Three Costs of Skipping and Four Criteria for Evaluation

An equipment manufacturing company plans to implement MES and SRM in 2025, with a budget of 8 million yuan. In the first week, the consultant requested a process list, but the company could not provide it, so they proceeded with "standard system processes." Six months later, three factories adopted three different methods: Factory A strictly followed the system; Factory B printed work orders, signed them offline, and then entered them back into the system; Factory C maintained an Excel ledger and only entered summary data at the end of the month. The system login rate was 92%, which seemed successful, but the actual proportion of business processes that were closed within the system was only 51%.

First, let's draw a conclusion: Implementing a system will not standardize processes; it will only solidify the current status into code. Standardization is not a "homework" task before system implementation; it is a decision that determines whether the system is worth implementing. To evaluate whether a system can be implemented, do not look at whether the process diagrams are complete, but rather at four hard metrics that can be checked—fail to meet these and standardize first, do not "standardize while implementing."

1. The Three Costs of Skipping Standardization

These three costs are typically not mentioned in project proposals, but they will materialize after implementation.

The first cost is often underestimated. If the IT budget does not allocate more than 15% for process changes, the project will likely stall within three months after implementation—not because the system is bad, but because each business adjustment requires a development queue.

The third cost is the most hidden. The metric to judge is the proportion of cases completed within the system, not the login rate or the number of entries. A high login rate only indicates that people are using the software, not that the business processes are closed within the system. Below 70% is a failure, and below 60% is equivalent to not implementing the system at all.

2. Four Evaluation Criteria

All four criteria require "verifiable numbers" and do not accept responses like "we have already sorted it out."

Criterion One: Action Sequence Consistency Rate ≥ 85%. Sample 20～30 completed cases, cross-factory and cross-team, and compare the actual action sequences for the same type of business. If 85% or more are consistent, the system can be implemented, and the remaining differences can be handled with branch configurations; if 70%~85%, first converge the main paths to three or fewer, and configure each branch in the system; if below 70%, do not implement. Counterexample: A group used the "most standardized factory" as a blueprint, but after implementation, 40% of the orders in the other two factories could not be processed, ultimately requiring manual adjustments.

Criterion Two: Enumerated Exception Paths, and ≤ 20% Long-Tail Exceptions. Exceptions are not the problem; unenumerated exceptions are. The exception list should be complete, with each exception having a trigger condition, handler, and deadline. Long-tail exceptions (those with unclear trigger conditions) should not exceed 20% of the cases. Exceeding this ratio indicates that the process itself is not yet defined, and configuring it in the system will set up future rework.

Criterion Three: 100% Consistency in Key Field Definitions. Fields such as customers, materials, batches, delivery dates, and amounts should have a single definition across the company. A simple but effective method to check this is to sample 5 business indicators and ask 3 departments for their definitions, which must be consistent. If they are not, first unify the definitions—this is unrelated to the system, which will only turn three definitions into three sets of fields.

Criterion Four: Unique Decision-Maker at Each Decision Point. The process owner, approval authority, and dispute resolver must be clearly defined to specific positions, not "relevant departments." A practical test: disable an approver's account and see if the process gets stuck. If it does, it means the decision-making authority is still tied to the individual and has not been integrated into the process.

If any of the four criteria are not met, the correct action is to revert to standardization, not to add them to the "post-implementation optimization list." This list is rarely opened in 90% of projects.

3. Granularity: Standardize to L2, Not to SOP

The most common issue with standardization is granularity. Processes are divided into three layers: L1 value streams (5～7), L2 business processes (4～7 nodes each), and L3 operational steps (job-specific SOPs).

Implementing a system only requires L2 plus key fields plus decision rules. L3 is only necessary for safety, regulatory, or highly variable workstations. Configuring a 200-step SOP one-to-one into the system may seem rigorous, but in reality, it results in zero flexibility: any deviation encountered by frontline workers requires a change request, leading them to bypass the system to save time—each bypass results in a data break.

To determine if the granularity is excessive, check one number: the number of configuration nodes for a business path in the system should not exceed 1.2 times the actual number of nodes in the business process. If it does, it means "how people operate" has also been configured, which is not process standardization but a recording of operations.

4. Three Typical "Skipping" Postures

Counterexample One: Buy the System First and Let the Consultant Tidy Up the Processes. The consultant will always outline "processes that the system can support," not "processes that the business should have." Identification signal: the blueprint document cites "execute according to the system's standard process" as a design rationale rather than a compromise solution.

Counterexample Two: Solidify the Current Status, Including Known Redundant Nodes. "Supporting the current practices with the system" sounds practical, but it essentially welds three years of patches in one go. Evaluation standard: the number of process nodes after implementation should be 20%~30% fewer than before; if it is the same or even more, the implementation is just moving paper to the screen. How to identify redundant nodes can be found in the results change rate and expected interception value in Why Do Approval Flows Keep Getting Longer?.

Counterexample Three: Standardization as a Documentation Exercise. A complete set of process diagrams, SOPs, and responsibility tables is created, but the system configuration is another story. Check method: sample 10 processes and compare the document descriptions with the actual system configurations. If the consistency rate is below 85%, it indicates a disconnect. Inconsistent documentation and system configurations are worse than having no documentation at all—when issues arise, both sides can cite a version favorable to them.

5. Time Budget and What to Monitor After Implementation

Standardization should account for 1/3 to 1/2 of the total project duration to be reasonable. Projects that only allocate 10% are not efficient; they are pushing the overall risk to post-implementation, where the cost of each change is eight times that of the initial project.

Among the five indicators, "closure rate" and "number of nodes" are the most telling: the former proves that the business has truly moved into the system, and the latter proves that the system was streamlined before moving in.

6. Who Should Lead This Effort

The leader of process standardization must be the process owner responsible for the cycle, with IT handling configuration and integration, and business departments providing requirements and participating in acceptance. If IT leads the standardization, the output will inevitably be "processes that the system can support"; if a department leads, the output will be "the most convenient processes for my department." Neither is an end-to-end process.

The data collection work should be done first: the true state of processes cannot be determined through interviews alone; it must be reconstructed from system logs, as described in How Far Off Are Process Diagrams from Real Processes?. If, after finalizing the standardization, the number of nodes is still too high, then reduce the steps—do not configure the lengthy process directly into the system. The lesson in Why Do We Still Rely on Excel After Changing Three Scheduling Systems? is the same in the planning domain.

In a Nutshell

Standardize processes before implementing a system, not because they need to be "standard," but because the system will magnify your current status tenfold. Check the four criteria: action sequence consistency rate 85%, long-tail exceptions 20%, 100% consistency in key field definitions, and unique decision-makers at each decision point. Only proceed with the project if all four criteria are met; if any are not, first standardize the processes to ensure they are clean and consistent.

This article belongs to the "Digitalization and AI Zone · Process Digitalization" direction, targeting operations and process managers, and does not involve quality management system clauses.

Knowledge code: 16.1.2 Author: QTank Version: v20261029