A guide to business process reengineering

Business process reengineering means tearing down a core workflow and rebuilding it from scratch. Not tweaking. Not optimizing. Rebuilding.

If that sounds dramatic, it’s supposed to. BPR exists for situations where incremental improvement won’t cut it. The process itself is the problem, not just how people execute it.

The uncomfortable truth most people miss, though? AI follows whatever process you give it. Including the broken one. So if you’re thinking about throwing machine learning at a workflow that’s fundamentally broken, stop. Reengineer first. Automate second.

What business process reengineering actually means

Business process reengineering is the act of recreating a core business process with the goal of improving output quality, speed, or reducing costs. It’s not a minor tune-up. It’s a teardown.

Typically, you’re analyzing workflows, finding the ones that are broken or outright wasteful, and figuring out how to replace them entirely.

The concept blew up in the 1990s after Michael Hammer published Reengineering Work: Don’t Automate, Obliterate in the Harvard Business Review. His argument was blunt: companies were using technology to speed up fundamentally broken processes. That’s like giving a horse lighter horseshoes when you should be building a car.

In the decades since Hammer and James Champy popularized the concept, BPR has lived alongside business process management, which focuses on improving existing processes rather than replacing them. BPM became more popular because it’s less risky. But here’s where it gets interesting: with the pace of change we’re seeing now, especially around AI, the case for radical process redesign is stronger than it’s been in years.

Turns out, agents without workflows are powerful models running on empty process rails. That gap is exactly where BPR becomes relevant again.

Whether you’re rebuilding processes from scratch or improving existing ones, having the right software to document, track, and automate workflows makes a real difference. At Tallyfy, we’ve seen teams go from messy spreadsheet tracking to structured, repeatable workflows in days, not months.

Steps to get BPR right

Unlike business process management or improvement, which both work with what you’ve already got, BPR means changing processes at their foundation. This is expensive, time-consuming, and risky. Skip a step and the whole thing falls apart.

Identify and communicate the need for change

If you’re a small startup, this part’s easy. You spot the problem, text your co-founder, pivot.

For a larger organization? Much harder.

There’ll always be people who are comfortable with how things work right now. Some managers worry about sunk costs. Some employees worry about their jobs. Both worries are legitimate. So you need to build the case - which processes aren’t working? Where’s the competition beating you? What does the data say? Once you’ve got answers, leadership has to become salespeople. Not just announcing the change, but selling the vision. Showing every person in the organization how this helps them specifically. The biggest risk here? Not getting buy-in. BPR affects everyone, and sometimes the change genuinely looks negative from certain angles. Some employees might think, probably correctly in some cases, that reengineering could eliminate their role. I learned this the hard way at Tallyfy: usually, you can get employee buy-in through honest communication and motivation, but sometimes resistance runs deeper. A toxic workplace culture needs fixing before any BPR initiative has a shot.

Assemble the right team

Every BPR effort needs three types of people:

• A senior manager who can make decisions without running up the chain for approval on every minor detail. Without executive authority on the team, progress stalls.
• An operational manager who knows the process inside and out. They’ve lived with it. They know where it breaks and why.
• The right technical experts. Depending on the process, you might need IT specialists, manufacturing engineers, or workflow designers. This varies case by case.

The failure mode here is subtle. If your team thinks too similarly, they’ll miss blind spots. Too many people and decisions grind to a halt. Too few and you lack the expertise to design something better.

I think the one thing that helps every BPR team is genuine enthusiasm paired with intellectual honesty. People who are keen to make things better but aren’t married to any particular solution.

Define KPIs and map your processes

This is where impatience kills projects.

You don’t want to redesign a process and then discover you forgot to measure something critical. Define your KPIs upfront. Common ones include:

• Cycle time: how long from start to finish
• Defect rate: percentage of outputs with errors
• Mean time to repair: how fast you recover from failures
• Changeover time: switching between product lines or service types

Once KPIs are locked, map out your current processes step by step. The easiest approach is business process mapping. It’s hard to analyze a process as an abstract concept, but when you write every step down, the waste becomes visible.

Two practical ways to do this:

• Process flowcharts: pen and paper, whiteboard, whatever gets the steps visible
• Process management software: tools like Tallyfy let you digitize processes, set deadlines, and collaborate across teams. In our experience, simply documenting a process in software often reveals inefficiencies nobody noticed before

Honestly, the temptation to rush this phase is enormous. BPR usually happens when things aren’t going well, when there’s pressure to show results fast. But the analysis needs to be thorough. Problem areas need identifying. Goals need setting. Business objectives need defining. All of that takes time.

At Tallyfy, we’ve seen teams spend weeks evaluating different process management approaches and trialing several before choosing one. That thorough analysis pays off when they achieve measurable improvements that a rushed decision would have missed entirely. Every single time.

Test small, compare KPIs, then scale

Once planning is done, start implementing on a small scale. Not a company-wide rollout. A controlled test.

Put your theories into practice. Watch how the KPIs move. If the new process works better, scale gradually, putting it into action across more and more of the organization.

If the KPIs don’t improve? Back to the drawing board. No shame in that. A mid-sized consulting firm that took this gradual approach reported 25% productivity improvements and 18% cost reduction. Those results came from careful scaling, not a rushed big-bang rollout.

The Ford case study everyone references

There’s a reason Ford’s accounts payable reengineering is the most cited BPR example. It’s dramatic and the numbers are hard to argue with.

In the 1980s, the American auto industry was struggling. Ford started examining departments for waste and found that their accounts payable division had 500 people. Their partner Mazda? Five. Even accounting for Mazda being smaller, Ford estimated they were overstaffed by a factor of five.

The old process worked like this:

1. Purchasing wrote a purchase order and sent a copy to accounts payable
2. Material control received goods and sent paperwork to accounts payable
3. The vendor sent a receipt to accounts payable

Then a clerk had to match all three documents manually. If they matched, payment went out. This took enormous manpower.

Ford didn’t tweak this. They rebuilt it:

1. Purchasing enters an order into an online database
2. Material control receives goods and cross-references the database
3. If it matches, material control accepts on the computer. Done.

The need for clerks to manually match three documents? Gone. That’s BPR at its most effective. Not speeding up a broken process, but eliminating the need for it entirely.

Why BPR matters more now than in the 1990s

Here’s my honest take on why this concept is having a quiet resurgence.

AI is forcing the conversation. Companies are rushing to bolt AI onto every workflow they’ve got, and most of the time it backfires. Why? Because the underlying process was never designed to handle that kind of automation. AI amplifies whatever process it follows. Can you just bolt AI onto a broken workflow? No. A broken process automated by AI just breaks faster. And at scale.

The smart organizations are doing something different. Well, the ones paying attention are. They’re reengineering first. They’re asking the fundamental question: “If we were building this process today, knowing what we know, would we build it this way?” Usually the answer is no.

This is where tools like Tallyfy come in. You can’t reengineer what you can’t see. And you can’t improve what you haven’t measured. Getting your processes documented, tracked, and visible is the prerequisite, not the end goal.

Common questions about BPR

What are the 3 R’s of reengineering?

Rethink, redesign, retool. Rethinking means nothing’s off-limits. Question every assumption about how work gets done. Redesigning means drawing up new blueprints for how things should flow. Retooling means equipping your team with the skills and technology to work in the new way.

They’re sequential and each one depends on the previous being done well.

What are the four principles?

Structure around outcomes, not tasks. Keep the end result in mind rather than getting attached to familiar methods.

Make the people who use the output responsible for the process. Let the chef taste the food, so to speak.

Treat distributed resources as if they’re local. Geography shouldn’t dictate workflow design.

Chain parallel processes instead of merging them. Think of it as harmonizing instruments rather than having each one play solo.

When should you use BPR instead of incremental improvement?

BPR isn’t for small fixes. It’s for gut renovations.

You need it when you’re falling behind competitors, when satisfaction scores are dropping, when your processes are so tangled they’re actively holding you back. It’s also the right call when new technology, particularly AI, opens up possibilities for radical improvement.

But a heads-up: it’s not a miracle cure. It demands commitment, resources, and willingness to upend how things work. It’s for situations where you’re ready to ask, “If we were starting today, how would we do this?”

How long does a typical BPR initiative take?

There’s no universal answer because it depends entirely on scope. A single department process might take 3-6 months from analysis to full implementation. A company-wide initiative can stretch past a year.

What I’ve noticed, though, is that the analysis phase almost always takes longer than people expect. The teams that accept that reality up front tend to get better results than the ones fighting the clock from day one.

---

Reengineer your purchase and accounts payable processes

Example Procedure

Internal Purchase Order Request

1Submit Purchase Order Request Form

2Finance Manager: Review Standard Purchase Order (Under $10k)

3Update Procurement System Status to Rejected

4Notify Employee: Purchase Order Rejected

5Generate Official Purchase Order Number (Standard PO)

+10 more steps

View template

Example Form

Accounts Payable Invoice Request Form

Use this form to submit a vendor invoice for payment. Provide complete vendor and invoice details to

6 fields

View template