Business Process Management: Find Delays and Redesign the Work - Yenra

Use a purchase-request example to map work, separate waiting from effort, improve handoffs, and understand when BPMN and automation help.

Ivory process lanes with navy work blocks at a teal junction, an amber decision prism, and a clear glass alternative route.
Conceptual illustration: process redesign examines queues, decisions, and the route work takes.

Business process management (BPM) is the work of understanding, improving, and running a repeatable process from its trigger to its outcome. The useful starting point is a real piece of work moving between people—not a software demonstration.

Consider a purchase request. The requester wants the right item ordered, the budget owner needs to authorize spending, and procurement needs enough information to place an accurate order. A process can meet every department’s local rule and still leave that request waiting for days.

Define the boundary, then observe actual cases

Choose a beginning and an ending that people can recognize. For this example, the boundary runs from a submitted purchase request to an order sent to the supplier. Delivery, invoice matching, and payment are related processes, but they are outside this first improvement effort. Without a boundary, the map expands until nobody can test it.

Follow several recent requests, including one returned for missing information, one urgent exception, and one rejected request. Record who performed each action, what information they used, and where the case waited. Ask the people doing the work to check the map. A written procedure often describes the intended route while email and spreadsheets reveal the route people actually use.

Separate a task from a decision and a queue. “Check budget” is work; “within delegated authority?” is a decision; “waiting for manager” is a state that needs an owner and an aging rule. Record the source of each approval rule so that a redesign does not silently remove a necessary control.

Worked example: 80 minutes of work inside a 20-hour process

Invented teaching example: one uncomplicated request follows four sequential stages. All times below use the same business-time clock, with no overlapping activities or rework. They illustrate a method, not an industry benchmark.

On a small screen, scroll the table sideways to read all columns.

Fictional purchase request: elapsed business minutes
StageActive workWaiting before stageTotal
Intake check15 min120 min135 min
Budget approval20 min480 min500 min
Supplier details check30 min240 min270 min
Create and send order15 min300 min315 min
Total80 min1,140 min1,220 min

The elapsed time is 1,220 minutes, or 20 hours 20 minutes. Only 80 ÷ 1,220 = 6.6% is active work, rounded to one decimal place. Making every task 25% faster would save 20 minutes and leave elapsed time at 1,200 minutes. Reducing the budget queue from 480 to 120 minutes would save 360 minutes and bring the total to 860 minutes, assuming everything else stays the same.

These are separate scenarios, not savings to add automatically. A shorter queue might require backup coverage or scheduled review times. That is a staffing and operating decision, not evidence that a new tool creates six hours of labor savings. Waiting time and paid effort are different quantities.

Fix the cause of delay before automating the route

Begin with changes that address observed failures. Put required information at intake, explain why it is needed, and offer a route for a requester who does not know a supplier code. Assign a backup approver. Send decisions to a monitored queue rather than a person’s private inbox. Make rejection reasons clear enough for the requester to act on.

Remove duplicate entry where a reliable record already exists. Combine checks only when the same person has the necessary authority and information. Independent budget and supplier checks may be candidates to run concurrently, but only if neither depends on the other and the order waits for all required approvals.

Write the exception routes alongside the normal route: missing information, unavailable approver, supplier rejected, urgent request, request withdrawn, and changes after approval. Decide when a change invalidates an earlier approval. An otherwise elegant process becomes unreliable if people must invent these rules during each exception.

Use BPMN when precise shared notation helps

A plain sequence or swimlane sketch is often enough for an initial conversation. OMG’s Business Process Model and Notation specification provides a standardized language for more formal models. BPM is the management practice; BPMN is a notation. A diagram does not, by itself, make a process executable.

Use a small set of symbols accurately: events for triggers and outcomes, tasks for work, lanes for responsibilities, and gateways for routing. An exclusive gateway selects a route according to conditions. A parallel gateway starts concurrent routes and can synchronize their completion. Confusing these can send work down the wrong branch or leave a model waiting for a branch that was never started.

If you plan to execute the model in a workflow engine, check that engine’s supported elements, data mappings, permissions, retries, and error handling. Keep business rules understandable to their owners even when developers implement the orchestration.

Pilot the redesigned process and keep an owner

Name one process owner responsible for the outcome across departments, while retaining individual task owners. Establish a baseline for elapsed time, queue age, returned requests, and errors that escape into orders. Define the denominator: a return rate measured per submitted request is different from a count of individual correction messages.

Run a limited pilot that includes normal work and deliberate exception tests. Compare similar cases over the same business calendar, and inspect slow cases rather than relying only on the average. Keep a fallback route and reconcile anything created in both the pilot and old process so that duplicate orders do not escape.

Once the process behaves sensibly, decide where business automation helps: routing a complete request, looking up a supplier, or flagging an overdue approval. AI may help summarize observed cases or propose a draft map. Verify its steps against real records; it can infer a handoff that never happened or omit a rare but necessary control. Review the process after policy, staffing, or system changes, not just after a software launch.

Related resources