If you don't know where to start, there is only one answer: Don't systematize. Question what can be eliminated first.
Previously, I wrote that system development failures are a structural problem, not a lack of executive knowledge. Building on that structure, this article discusses the actual first step clients should take. Choosing to "just systematize" when you're unsure is the most expensive move you can make. If you get the order wrong, you simply spend money automating inefficient processes.
■ The Misconception: "Systematization = Solution"
When consulting with clients, the initial request is almost always the same: "Our operations are inefficient, so we want to implement a system." However, upon closer inspection, most cases contain waste that could have been resolved before any system was introduced.
For example, consider a company's quotation process. They allowed sales staff to create quotes in a new system, but internal approval still required printing paper forms and circulating them physically. After approval, staff had to manually re-enter amounts from the digital quote into the paper form. Despite being "systematized," the overall workflow added a step: "Create in system, copy to paper." The root cause was that no one asked, "Can we eliminate the paper approval flow?" before building the system. Millions were invested, but by automating waste that should have been cut, most of that cost was effectively lost.
■ Cut Before You Add
There is a long-standing principle for business improvement called ECRS: Eliminate (can it be removed?), Combine (can it be merged?), Rearrange (can the order change?), Simplify (can it be made simpler?). Only after thoroughly considering these four should you consider Automate (systematization).
Many project managers skip this order and jump straight to "Automation." As a result, tasks that should have been eliminated, double entries that could have been combined, and approval flows that could have been simplified are baked directly into the software. The result is a system that performs useless tasks faster and more accurately. Ironically, because they feel like they've "systematized," no one notices the underlying waste.
This aligns with my previous point that system development failures are structural, not due to ignorance. Skipping the ECRS sequence is part of that flawed structure.
■ Four Questions for Decision Making
Before considering systematization, ask yourself these four questions in order:
- Can this task be eliminated entirely? (Eliminate)
- Can multiple tasks or departmental workflows be combined? (Combine)
- Can improvements be made just by changing the order or responsibility? (Rearrange)
- Can the method itself be simplified? (Simplify)
Only the tasks remaining after answering these questions are candidates for systematization. Conversely, if you enter requirements definition without considering these four, the seeds of failure are already sown.
■ Addressing the Desire for Speed
You might argue, "We don't have time to deliberate; we need to implement the system quickly." However, ECRS analysis typically takes only days or weeks. In contrast, if a rushed system requires redoing requirements definition later, you lose months. Trying to hurry often leads to detours.
Another objection is, "Our operations are too complex for external frameworks." But ECRS doesn't require deep operational knowledge. The people who know the details are the frontline staff; ECRS is simply a sequence of questions to prompt them to ask, "Can this be removed?" or "Can this be merged?" It can be used today without specialized expertise.
■ What You Can Do Tomorrow
No massive organizational overhaul is needed. Pick one task you currently want to "systematize" and answer the four questions above. Often, the first question (Eliminate) reveals options you hadn't considered.
The real reason for "not knowing where to start" isn't usually about whether to systematize, but not knowing what to analyze *before* systematizing. If you follow the correct order, decision-making isn't difficult.
Next time, I will address the most universal pain for executives: "People quitting." We'll discuss the organizational structures behind turnover rates.
If interested, please DM me via this link.
■ Related Past Articles
