Finding an inefficient step is useful. Removing it takes a different kind of work: a decision about the new process, an owner, a trial in the real operation and a way to check whether the change held.
1. Name the outcome you want to improve
Choose one workflow and one specific result: time to complete a customer request, hours spent on rework, error rate or number of handoffs. Define where the process begins and ends. Include a service or quality measure so a faster process does not quietly create a worse outcome.
2. Observe the current work
Follow several real cases, including an ordinary case and an exception. Record who does each step, who waits, who decides and where information is entered again. Ask the people doing the work which rules are unclear and what workarounds they use. The Task Mapping guide can help estimate how often the work occurs and how much time it absorbs.
3. Locate the cause before choosing a fix
A delay can be caused by unclear authority, missing information, competing priorities, a system limitation or a genuine control that should stay. Test the cause with examples. Removing an approval is only sensible when the decision can safely sit elsewhere with a clear boundary.
| Finding | Possible change to test | What to check |
|---|---|---|
| Two teams re-enter the same details | Use one intake record and define who updates it. | Errors and time per case. |
| Routine work waits for senior approval | Define a decision limit for the local owner. | Turnaround and exception quality. |
| Requests bounce between teams | Name one owner and a clear handoff point. | Number of transfers and customer follow-up. |
| Peak work overwhelms one role | Move a task, adjust timing or simplify the step. | Capacity, service and rework. |
4. Design the smallest workable change
Write down the new sequence, the owner of each decision, the information required and the rule for exceptions. Compare it with the current process: which steps stop, which change and which must remain? Ask frontline people and the leaders who will support it to test the design before roll-out.
5. Pilot in the operation
Choose a bounded team, site or case type. Agree when the trial starts, who trains and answers questions, and how issues will be recorded. Run the new process long enough to see ordinary work and a few exceptions. Adjust the instructions when reality exposes a gap; do not make a new process depend on one person remembering an unwritten workaround.
6. Measure, decide and embed
Compare the same measures before and during the pilot. Check whether the time or rework moved to another team and whether quality held. Decide to adopt, revise or stop the change. If it works, update roles, instructions, reporting and leadership routines, then review the measure after the initial attention has passed.
Capture the baseline, proposed change, owner, pilot scope, result, quality check and next review date. A change is complete when the new way of working is understood, used and reviewed.
CLEAR can support the full sequence through Process and Transformation: diagnose the issue, engineer a practical model, activate the change with leaders and measure the result. See the worked rework example for what those steps look like together.