ECRS process improvement
Examine a process through Eliminate, Combine, Rearrange, and Simplify, starting with whether the work is necessary.
Use ECRS when repeated work or awkward handoffs suggest that a process needs redesign. First question its purpose, then consider shared work, the order of steps, and a simpler way to carry out what remains. The four prompts help organize options that still need practical checks.
The current process, its trigger and required output, observed workload or errors, the people using it, and the controls that must remain.
An editable current-process description and four groups of proposed changes, with conditions and checks recorded in the relevant fields.
How to use it
- Describe the current process from trigger to output. Record the workload and the purpose of each output with the people who use it.
- Eliminate: ask whether a step or output is still needed. Confirm its users and required controls before proposing removal.
- Combine: identify compatible steps or duplicated information that could share work or one data source.
- Rearrange: change the sequence or timing where it would reduce handoffs or rework while preserving dependencies.
- Simplify: make the remaining steps easier to perform. Record the conditions, affected users, and how you will check quality and effort.
- Test a limited change and compare actual effort and errors on the same basis. Resolve unmet requirements before expanding or adding automation.
Keep its limits in mind
ECRS generates improvement options; it does not prove savings or authorize removing a control. Preserve required quality, access, safety, and handoff checks. Combining steps is useful only when they are compatible. A simpler diagram can still conceal extra work or risk for another team.
Review weekly reports before automating copying
Fictional example: Xinggang spends 10 hours a week preparing three reports with similar data. Two reports duplicate fields, and one has had no readers for two months. The team initially wanted to automate copying without checking whether every report was still needed.
On a small screen, scroll across the diagram to read it.
Redesign: The case consolidates three reports into one data source and two views. Lack of readership prompts a check with users; it is not sufficient permission to remove a required report.
Outcome still to check: Ten hours is the original weekly workload. No post-change time or error figures are supplied, so the redesign cannot be presented as a measured saving.
The 10 hours describe the baseline. The proposed changes have not been measured as savings; overlapping measures must not be added twice.
Next step: Check both views against user requirements for one cycle, then record next month's actual effort and errors. Put any request for implementation resources or approval into a business improvement proposal.
Three reasons to stop before removing a step
Use ECRS when repeated work needs a redesign before automation. Begin with the output and the person who uses it, then question necessity, compatibility, sequence and execution. The letters organize possible changes; they do not authorize removal or certify an improvement.
Pause if an apparently unused output may serve a required control. No readership for two months is a reason to ask its users and owner, not permission to delete it. Pause if combining tasks would conflict with access or quality responsibilities. Pause if the saving simply moves work to another team. Expand the measurement boundary until the extra effort is visible.
Distinguish effort, waiting and calendar duration. Two people working for 30 minutes contribute 60 person-minutes; that does not establish a 60-minute elapsed process. A shared source may remove repeated entry while adding validation. Give each work item one ledger row so the same removed activity is not credited once under Eliminate and again under Combine.
Choose mapping, redesign or evaluation
The original Xinggang example supplies ten weekly hours for three reports and no post-change measurement. Keep it separate from the hypothetical planning ledger below. Neither an easier diagram nor a new template supplies the missing outcome.
| Method | Input | Output |
|---|---|---|
| Process flowchart | Actual trigger, steps, handoffs and exceptions | A current path to inspect |
| ECRS | The current path, output requirements and constraints | Redesign candidates and checks |
| PDCA | A bounded candidate and agreed observation plan | Execution and evidence for adjustment |
| Business improvement proposal | Evidence, alternatives, resources and approval needs | A specific request, not automatic authorization |
Worked case: a smaller recurring total can cost more initially
This separate fictional ledger compares preparation of the same two report views for one normalized batch. Every number is a planning estimate in person-minutes, not a measured result from the ten-hour case. Each recurring activity is counted once. The proposed shared source reduces re-entry and formatting, retains extraction and exception handling, and adds validation effort.
The recurring totals are 120+150+90+120+60 = 540 before and 120+30+110+70+60 = 390 proposed: 150 fewer person-minutes per comparable batch. There is also a one-time estimate of 240: 180 for setup and 60 for the first-cycle parallel check. That parallel check is outside the recurring rows and is counted only within the 240, not added again.
For four identical batches, baseline effort would be 4×540 = 2,160. The proposal would require 4×390+240 = 1,800, a conditional net reduction of 360 person-minutes, or six person-hours. The first batch alone is 630 against 540, an extra 90. None of these estimates establishes actual saving, shorter waiting or available staff time.
| Activity | Before | Proposed | Condition |
|---|---|---|---|
| Extract source data | 120 | 120 | Same source scope |
| Re-enter shared data | 150 | 30 | One approved shared source |
| Validate | 90 | 110 | Required checks retained |
| Format two views | 120 | 70 | Both views meet user requirements |
| Handle exceptions | 60 | 60 | No hidden transfer of exceptions |
| Recurring total | 540 | 390 | One count per activity |
Review requirements and net effort before claiming success
The conclusion is that the candidate could reduce recurring effort but needs setup and a parallel check. Ask the output users to confirm required fields and controls, the responsible people to confirm capacity, and the decision owner to approve the trial scope. The ledger is a planning comparison, not an accepted implementation schedule.
If a trial is approved, record actual person-time by unique work item, one-time work, errors, unfinished exceptions and any work transferred elsewhere. Record waiting and elapsed duration separately. Keep the original output and quality requirements constant, or explain what changed. Do not subtract a proposed saving twice or hide setup because it falls outside the reporting week.
At review, compare the actual complete totals and required outputs with the baseline. A faster formatting step alone cannot demonstrate a better overall process. If the shared source introduces errors or access conflicts, adjust or stop before scaling. Preserve the first estimates and append actual observations, approvals and remaining unknowns rather than replacing the proposal with a success claim.
Check your work
- Have you questioned the purpose before optimizing the mechanics?
- Has the user of an output confirmed whether it is needed?
- Are essential controls and dependencies still represented?
- Does each option describe a concrete change and its conditions?
- Are baseline, redesign, and measured outcome kept separate?
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.
Read a practical guide →Practice with an example
Choose a preparation route for progress, a resource or decision request, or a period review. Use one service case to inspect openings, review checks and focused guides, and keep a preparation note.
Prepare a work update: start with the purpose →