The Pitfall of Standardization
“Standardizing operations will boost efficiency” – a belief many executives hold without question. But reality is not that simple.
Recently, a case study from SAP Japan was reported. As the company pushed forward with global operational reforms, it faced a situation where standardization actually “increased the workload.”
The word “standardization” often carries an irreversible image. Once rules are set, changing them comes at a high cost. That’s why people aim for perfect design from the start. But this very mindset is the trap of “irreversible standardization.”
Why Does Standardization Become “Irreversible”?
There are three main reasons why standardization becomes hard to reverse.
1. It locks people into fixed roles and expectations.
Standardized processes always assign specific people as responsible parties. Once someone is recognized as “the expert for this task,” changing the process affects personnel transfers and performance evaluations.
2. Contracts and systems blur accountability.
Standardization often goes hand-in-hand with system implementation or outsourcing. Contract periods and license fees become fixed costs, making mid-course changes financially difficult.
3. It proceeds without understanding the actual situation.
When you start with “standardization first,” you lose the bandwidth to observe what’s really happening on the ground. Even when problems arise, they’re postponed as “part of the standardization process,” and before you know it, the situation becomes irreversible.
In SAP’s case, it was reported that as standardization progressed, “rules that ignored individual on-site circumstances” increased, ultimately adding to the workload. This is a textbook example of standardization without understanding reality.
Three Key Points for Designing “Reversible Standardization”
So how can you make standardization a “reversible decision”? Here are three key points.
1. Set an Evaluation Period from the Start
Instead of introducing standardization as a permanent rule, first set a “trial period” of three or six months. At the end of that period, measure the effects and create a mechanism to decide whether to continue, adjust, or withdraw.
Specifically, define the following items in advance:
- A condition like “if this metric doesn’t improve, we will suspend standardization.”
- A boundary like “these specific tasks are exempt from standardization.”
- A rule like “during this period only, reverting to the original workflow is permitted.”
This transforms standardization into an “experiment you can reverse if it fails.”
2. Lock in the Points to Observe
Decide in advance the indicators for measuring the effects of standardization. However, what matters isn’t just numerical targets. Also lock in qualitative observation points, such as feedback from the field or the frequency of unexpected tasks.
In SAP’s case, it reportedly took time to realize that standardization had increased “tasks that shouldn’t have been necessary.” If observation points had been fixed in advance, the problem could have been spotted earlier.
3. Decide Exit Conditions in Advance
Make it possible to decide to “stop standardization” based on facts, not emotions. Set criteria like the following as exit conditions in advance:
- “If the processing time for standardized tasks increases by 20% or more compared to before.”
- “If complaints from the field exceed a certain number per month.”
- “If unexpected tasks exceed 30% of the total.”
By setting exit conditions, you can make calm decisions without being dominated by the psychological cost of “wasting what’s already been done.”
“Reversible Management” Leads to Successful Standardization
SAP’s case shows that standardization itself isn’t the problem. The issue lies in viewing standardization as an “irreversible decision.”
In management decisions, perfect design doesn’t exist. Start from the premise that “it might fail,” and build in mechanisms that allow you to revert at any time. That’s the essence of “reversible management.”
If your company is about to embark on standardization, try deciding “when to revert” before you begin. That single step is the best way to prevent irreversible failure.
Comments