Where should business process improvement start?

“Improve our efficiency” does not define the work to undertake. Describe the problem through an outcome: a request is waiting for approval, a file comes back incomplete or a team cannot tell whether work can begin. Explain who experiences the difficulty and what they actually encounter.

Set a start and an end. For example, follow a purchase request from receipt to the decision communicated to its requester. Keep neighbouring activities visible without automatically including all of them in this first improvement project.

Bring together someone who initiates the request, someone who processes it and someone who receives the result. Walk through recent cases, removing information unnecessary for the exercise. Draw the steps and decisions in their actual order. Simple arrows are enough when the immediate goal is shared understanding.

Separate observations from assumptions and unanswered questions. NIST describes self-assessment as a way to identify missing or conflicting information that can inform action planning. The practical workflow exercise in this article is our editorial adaptation for a limited process, rather than a Baldrige assessment.

Baldrige Improvement Tools

Separate time spent actively working from time spent waiting. Record returns for corrections as well. A request handled quickly by each participant may still spend long periods between them. Faster data entry would address only part of that situation.

Choose one main indicator and one quality check. For incomplete files, these might be the proportion returned and a check that accepted files contain the necessary information. Keep the number and types of requests observed. Without that context, a later comparison would be difficult to interpret. Agree on what counts as a return so different teams do not record different events under the same label.

In this entirely fictional situation, administration returns requests because the requested date and budget owner are missing. Requesters assume administration will find those details; administration expects requesters to provide them. No software failure is involved in this example.

The team proposes a request form containing both details and assigns someone to check submissions at entry. It trials this arrangement within an agreed scope, then examines returns and exceptions. No numerical benefit is assumed. The team must see whether the form reduces repeated work without simply transferring an unreasonable burden to requesters.

Complete this worksheet with the team before changing the process. Where an answer is missing, record a question to investigate rather than leaving an assumption hidden.

• Workflow: what event starts the work, and what outcome ends it?
• Obstacle: what difficulty can be observed in the cases examined?
• Hypothesis: why do we think this obstacle occurs?
• Change: which rule, information requirement or responsibility will we adjust?
• Verification: which indicator and quality check will we follow?
• Owner: who supports the trial, and who decides what happens next?

At the end of the trial, compare genuinely comparable cases and discuss any that contradict the original hypothesis. Record effects on neighbouring teams too. A local improvement needs to remain compatible with the intended outcome of the whole workflow.

You may keep the change, revise it or stop it. If a repetitive transfer between systems remains a problem, automation scoping may become useful. The process map and observations will provide a concrete starting point for that discussion. Preserve the trial notes so a later team can understand both the decision and its limits.