Business Process Reengineering: How to Map the Current Process and Cut Its Steps

What is business process reengineering, and how does it differ from continuous improvement?

Business process reengineering means redesigning a process from the ground up instead of speeding up its old steps. Michael Hammer set out the idea in 1990 in his well-known Harvard Business Review article, observing that companies were using technology to run old ways of working faster, which left their basic performance problems unsolved. ^[3] He argued instead for breaking with inherited rules and redesigning for dramatic rather than incremental improvement. ^[3]

His best-known example is Ford’s accounts payable function, which employed more than 500 people in North America, while the equivalent department at Mazda had just 5. After Ford redesigned the process so that payment was triggered when goods were received and matched against the purchase order, without waiting for an invoice, it achieved a 75% reduction in headcount where the new process was implemented. ^[3]

The same idea is at work in Gulf government. The UAE’s Zero Government Bureaucracy programme set out to cancel at least 2,000 government procedures, halve the time procedures take, consolidate similar procedures and remove superfluous steps. ^[6]

Step one: define the process and its boundaries

Choose one process, not a whole department. The best candidate is a high-volume process that touches service recipients directly and attracts complaints or delays, such as issuing a permit, paying entitlements or handling a purchase request.

Then write its boundaries in three lines: what event starts the process? What outcome means it is finished? Who receives it? These boundaries stop the team drifting into neighbouring processes and make it possible to measure time from one clear point to another.

Appoint a process owner with the authority to change it across departments. Reengineering crosses departmental lines by its nature, and without an owner with that authority the project stalls at the first disagreement.

Step two: map the process as it really runs

Map what actually happens, not what the procedures manual says. Bring together the employees who carry out each step, follow a real transaction from start to finish, and record every handover from one person to the next.

Use a standard notation so that anyone reading the map understands it. BPMN is published by the Object Management Group (OMG) and adopted internationally as ISO/IEC 19510:2013; it is aimed at business analysts who design processes, technical developers who implement them and managers who monitor them. ^[1] At first you only need its core elements: ^[2]

Give each role or department its own lane. The number of times the transaction crosses between lanes then becomes obvious, and every crossing is a potential waiting point.

Step three: measure time before you judge

Lean thinking distinguishes cycle time, the time a worker takes to complete their work at one step, from lead time, the total time that elapses for a unit to move through the whole process from start to finish. ^[4] In administrative processes, the gap between the two is usually waiting time in inboxes and on approvers’ desks.

For each step, record the actual working time, the waiting time before it, how often the transaction is sent back for missing information or errors, and who approves it.

Hypothetical example: a request for office supplies passes through nine steps and three signatures and takes ten working days from submission to the purchase order. Measurement shows that the actual working time adds up to roughly three hours, and the rest of the ten days is waiting. Speeding up staff will not help here; removing the waiting points will.

Step four: classify every step

The Lean Enterprise Institute defines waste as any activity that consumes resources but creates no value for the customer, and distinguishes two kinds: waste that adds no value but is unavoidable with current technology and assets, and waste that can be removed immediately. ^[5]

Apply this classification to every step on the map. The decisive question for steps that seem necessary is: what requires them? If it is a law or regulation, the step is necessary waste for now, to be reduced or combined; if it is custom, or an old precaution nobody can explain, it is a candidate for removal.

Step five: redesign around the outcome

Hammer set out redesign principles that still hold for administrative work today: ^[3]

The most important rule at this stage is not to automate before you redesign. Hammer’s central observation was that automation alone makes old ways of working faster without fixing their problems. ^[3]

How do you design and implement the future process?

In value stream mapping, you first map the current state, then draw a future state as the target picture of how work and information should flow after improvement. ^[4] Draw the new process with the same BPMN elements so it can be compared with the current map step by step.

Then pilot it on a limited scale, such as one branch or one type of request, and measure lead time and the number of send-backs in the same way you measured the current state. Once the results hold, update the procedures manual, request forms and approval authorities, because a new process that is not documented gradually drifts back to its old shape.

Common mistakes

• Mapping the process from the written manual or the manager’s memory, so the map looks tidier than reality.
• Measuring working time alone and ignoring waiting time, so speed is targeted in the wrong place.
• Removing a step required by law or regulation without consulting the competent authority.
• Redesigning the process within one department, when most of the waiting happens at handovers between departments.

Conclusion

Start with one process, map it as it really runs, measure waiting time before working time, then classify each step and redesign around the outcome. Pilot the new process on a limited scale and document it before you automate or roll it out.