Use ECRS with process time records to decide what to remove
Recalculate 12 fictional requests, separate staff effort from waiting, account for added effort, and plan a pilot that preserves required review.
On this page
Before automating a slow process, separate three questions: how long a customer waits, how much work the team does, and which work is still necessary. This exercise uses 12 request records to produce an ECRS change list and a pilot plan you can review with the next batch.
Copying takes 36 staff-minutes in this example. Removing it would reduce this batch's net effort by the full 36 only if the replacement adds no work and preserves the required review and records. It is not an achieved saving or a reduction in waiting. The exercise connects the calculation to change conditions and a decision for the next round.
Fictional teaching exercise: all requests, times, and process requirements were created for this article. They are separate from the weekly-report example in the framework guide. No results after a change are available.
Define one request and the time measures
A small service team handles routine configuration requests. It registers each request, copies the same fields into a status sheet, queues the request for review, checks access and configuration, resolves missing fields if needed, and sends a handoff notification. The status sheet is used only to view progress. Access review and a traceable review record are required controls in this example.
The dataset contains 12 fictional routine requests received and completed on October 1–4, 2026, in the Asia/Shanghai time zone. Each record runs from receipt to the handoff notification. There are no incomplete requests, complex requests, or overnight waits. This is a calculation exercise with complete records, not a representative assessment of the team's service.
- Active work: staff effort spent on entry, copying, review, rework, and handoff, measured in staff-minutes.
- Waiting: elapsed time in the review queue, from the end of copying to the start of review, measured in request-minutes. Staff can work on other requests during that interval.
- Request lead time: elapsed minutes from receipt to the handoff notification.
For this exercise, each request's work happens sequentially, with one person working at a time and no additional waits. Its lead time therefore equals active work plus waiting. In a real process with several people working concurrently, summed staff effort cannot simply be added to customer elapsed time. Reconstruct elapsed time from timestamps instead.
Recalculate the 12 records
Download the source process log and the definitions and calculated summary. Each CSV row represents one request. It includes receipt, queue entry, review start, and handoff timestamps, plus five categories of active effort. Rework covers completing missing fields and checking them again; it is already part of active work.
| Activity | Total staff-minutes | Mean per request | What to check in this example |
|---|---|---|---|
| Register the request | 60 | 5 | Which fields the reviewer needs |
| Copy into the status sheet | 36 | 3 | Whether one source can satisfy status users |
| Review access and configuration | 72 | 6 | Preserve review responsibility and records |
| Send the handoff notification | 24 | 2 | What the recipient needs to know |
| Resolve missing fields | 24 | 2 | Six of 12 requests needed rework |
| Total active work | 216 | 18 | Do not add rework a second time |
Waiting totals 504 request-minutes, or 42 minutes per request. Total request lead time is 720 minutes, with a mean of 60. For request 1, active work is 4 + 3 + 5 + 2 + 0 = 14 staff-minutes. Adding its 30-minute wait gives 44 elapsed minutes, matching receipt at 09:00 and handoff at 09:44.
Waiting accounts for 70% of mean lead time. That warrants investigating the queue; it does not represent 504 staff-minutes you can recover. The records do not explain the queue. Review schedules, batching, and request arrival patterns still need investigation. A long wait alone does not show that reviewers work slowly or that review can be removed.
Turn observations into conditional ECRS options
ECRS examines Eliminate, Combine, Rearrange, and Simplify. JICA's improvement course materials use these prompts to question the need for operations, their combination, their sequence, and how they are performed. The options below are our analysis of the fictional records, not recommendations from JICA.
| Prompt | Supporting record | Proposed change | Conditions and checks |
|---|---|---|---|
| Eliminate | Copying takes 36 staff-minutes | Stop maintaining a second copy of the fields | Status users confirm that a shared view meets their needs; check for any separate retention requirement |
| Combine | Registration and status fields match | Provide a status view from the request record | Fields, access permissions, and update timing suit both groups; preserve review records |
| Rearrange | Six requests had missing fields | Check required fields before entering the review queue | Reviewers still decide access; measure added checking effort as well as rework |
| Simplify | Handoff averages 2 staff-minutes | Use a notification template with request ID and review status | Recipients understand the next action; confirm approval before sending and check missed or incorrect notifications |
Eliminate and Combine describe two aspects of the same change here: remove copying and meet its purpose with a view of the original record. Do not add their benefits separately. Moving field checks earlier may only move effort, while a template may add maintenance and checking work.
If you have complaints about copying but no record of fields, output users, or required controls, start with a business process inventory. If those details are already available, work directly in the ECRS guide.
Treat 36 minutes as a scenario, not an achieved saving
If all 12 requests avoid copying, and the replacement view adds no maintenance or checking effort, active work could fall from 216 to 180 staff-minutes, or from 18 to 15 per request. The difference is 36 staff-minutes, equivalent to 0.6 staff-hours and about 16.7% of the original active effort. This is a conditional estimate for removing copying from this batch.
Subtract any new maintenance, checking, and exception handling from the avoided effort. Waiting may remain unchanged. Do not claim a 16.7% reduction in lead time, convert this scenario into annual savings, or infer that a role can be removed. Small fragments of time across people and shifts may not create a block of capacity that can be reassigned.
For the next batch, record actual copying effort avoided minus added maintenance, checking, and exception effort within the same scope. Show one-time setup separately. The 36 staff-minutes is this complete batch's scenario baseline, not a value to insert unchanged for requests with a different count or mix. No next-round records are available yet.
Plan a pilot you can review
For this example, try removing copying and providing the shared view first. Leave earlier field checks and notification changes for a later round so you can interpret this change. The plan below is a proposal; its owner, start date, and approval remain unconfirmed.
- Before starting: status users confirm fields and permissions. The review owner confirms that access checks and records remain intact. Agree on a pilot owner and a person to record results before beginning.
- Scope: follow the next 12 comparable routine requests through handoff. Record complex requests separately. If a request is still open at the review date, retain its status and elapsed wait; do not assign it zero time or silently omit it.
- Measurement: record the five original effort categories, queue time, timestamps, and added view setup, maintenance, and checking. Show one-time setup separately. Count each effort item once.
- Quality: every handoff must follow approval and have a traceable review record. Pause the pilot if a record is missing, a handoff bypasses review, or access is incorrect; handle affected requests under the original process. Zero errors in 12 requests would not establish long-term safety.
- Review: compare active effort, waiting, lead time, and rework counts separately. Check whether request mix and review staffing are comparable. A small before-and-after batch gives clues for the next decision; without a control design, do not attribute every change to the shared view.
The output is a documented decision to continue, adjust, or stop, with supporting records. Fewer steps describe a process change. Preserved quality and lower net effort require evidence from the next round.
Apply the exercise to your own process
Use the English worksheet to define the trigger, endpoint, time measures, and controls before choosing one ECRS option. Its worked example is one possible analysis, not the only correct answer.
The analysis script recalculates the CSV. The reproduction notes explain the command, fields, checksum, and simulation limits. The framework page provides an editable structure. Downloads are materials to read and calculate yourself; they do not promise automatic import or calculation.
For a resource or approval request, take the baseline, candidate, net-effort definition, and unconfirmed conditions into the clear work update guide. Produce a request to discuss; its customer service case is not new evidence about this process. If feasible options compete for resources, use the decision matrix checks to record tradeoffs and sensitivity without borrowing its procurement scores.
Start with a useful outline
Practice materials
- Recalculate the process records with PythonPY · 4 KB
- Fictional source process recordsCSV · 2 KB
- Process data and reproduction notesMD · 3 KB
- Time definitions, calculations, and source checksumJSON · 2 KB
- ECRS worksheet and worked exampleMD · 2 KB