BizThinkFrame
Practice with data · 9 min read简体中文

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.

Mean request lead time is 60 minutes: 18 minutes of sequential active work and 42 minutes of waiting; copying takes 3 minutes and required review takes 6 minutes per requestOpen diagram at full size

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

TRY IT WITH YOUR OWN MATERIAL

Start with a useful outline

Practice materials

Related methods

ECRS process improvement →Business process inventory →

Organize your own ideas

Workspace early access →

Continue exploring

Write a clear status update: results, risks, and next stepsCarry the baseline, net-effort definition, and open conditions into a resource or approval request.When a weighted decision matrix changes its winnerWhen feasible improvements compete for resources, record hard limits and sensitivity conditions.