There’s a version of this problem that shows up in a lot of growing businesses. The same complaint comes back every quarter. The same process keeps failing the same way. Someone proposes a fix, it gets implemented, and six months later the same issue is back on the table with a slightly different wrapper.
At some point, the problem isn’t the people executing the process. It’s the process itself.
This is where the distinction between process improvement and business process reengineering matters. They’re not interchangeable. One patches what exists. The other asks whether what exists should exist in its current form at all.
What the difference actually looks like
Process improvement works on the assumption that the core process is sound but has inefficiencies layered on top. An approval step that takes five days when it should take one. A handover between departments that drops information consistently. A manual step that could be automated. These are fixable without redesigning anything fundamental.
Business process reengineering — the idea was formalised by Hammer and Champy in a 1990 Harvard Business Review article that’s still worth reading — starts from a different question: if you were designing this process from scratch today, knowing what you know now, would it look anything like this? Usually the answer is no.
The challenge is that most organisations skip that question. They keep improving a process that was designed for a smaller, simpler business, and wonder why the improvements never quite hold.
Signs the process needs fixing, not rebuilding
• It works most of the time, but specific steps are consistently slow or error-prone
• Handovers between teams regularly lose information, but the teams themselves work fine
• There are manual tasks that everyone agrees should be automated but haven’t been yet
• Execution is inconsistent — some staff do it one way, others a different way
In these cases, process mapping and SOP development usually resolves it. Document the right way to do it. Train to it. Audit against it. The process itself is salvageable.
Signs it needs rebuilding
• The same problems happen regardless of which person or team handles the work
• The process was designed when the business was a fraction of its current size or complexity
• New technology has made a different approach possible, but the process hasn’t changed to reflect it
• Coordination across the process requires so many people that it slows to a crawl
• The cost or time required to run the process is making the business uncompetitive
If several of those apply, incremental improvement won’t fix it. The gains will be small and temporary. What’s needed is a genuine redesign — which is what business process reengineering services involve.
Where this comes up most in African businesses
Family businesses making the transition to professional management run into this regularly. The original processes were built around the founders’ personal oversight and judgment. They worked because the founder knew everything and everyone. When the business grows past what any single person can supervise, those informal processes break — and no amount of tweaking fixes a process that was never designed to run without the founder.
Fast-growth businesses hit a version of the same problem. A procurement process that managed ten suppliers reasonably well becomes unmanageable at fifty. A customer onboarding process that worked when the team could handle exceptions manually doesn’t survive when volume triples. These aren’t execution failures. They’re design failures.
Digital transformation creates a third category. Businesses that digitised their operations but essentially put digital wrappers around old manual processes often find they’ve inherited the inefficiencies of the original design. The software is running, but the process logic underneath it was never examined.
How ISO standards connect to this
ISO 9001 is often what forces organisations to look at their processes clearly for the first time. The gap assessment required before certification maps what you actually do against what a quality management system requires. For many businesses, it’s the first time anyone has sat down and traced how work actually flows, rather than how it’s supposed to flow.
What that assessment reveals shapes the project. Some organisations need SOP development and structured training to get consistent execution of processes that are already well-designed. Others find their processes need redesigning before you can build a certifiable system on top of them. ISL Global’s management systems consulting handles both — process redesign where needed, then ISO implementation on top of a solid foundation.
A framework for deciding
Three questions help narrow it down:
Does the process produce the right result most of the time, or only sometimes? If it works when followed correctly, the design is sound. If it regularly produces the wrong outcome even when followed correctly, the design has a problem that process improvement won’t fix.
Are the failures concentrated in specific steps, or spread across the whole process? Concentrated failures point to fixable inefficiencies. Failures spread across every stage suggest the architecture of the process is wrong.
Would a different technology or organisational structure change what’s possible here? If the honest answer is yes, and the process was designed before that option existed, it may be worth starting from a blank page rather than continuing to patch the old design.