Why Most Business Process Optimization Efforts Fail (And the Step Almost Everyone Skips)

Almost every company I work with is trying to optimize something.

A workflow that feels slower than it should be. A handoff that keeps dropping the ball. A piece of equipment they think they need to buy. A software implementation that promises to clean up the chaos. The language changes, but the instinct is the same: we have a problem, and the answer is to optimize our way out of it.

Here’s the pattern I’ve seen play out over and over again across nearly 30 years on the shop floor: most of those optimization efforts don’t fail because the tool was wrong, the vendor was bad, or the team resisted the change. They fail because the company tried to optimize something they had never actually captured.

You can’t optimize what you haven’t understood. And you can’t understand what you’ve never looked at.

This article is about the step almost everyone skips, what it actually looks like when you do it right, and how to diagnose whether you’re ready to optimize or whether you need to stop and capture current state first.

The Real Prerequisite Isn’t Documentation. It’s Clarity of Outcome.

Let me be direct about something, because I don’t want to be misunderstood.

When I say companies need to capture current state before they optimize, I’m not saying they haven’t done anything. Almost every company I work with is running the business every day. They’re producing parts, serving customers, hitting deadlines. They’re doing something. The issue is that what they’re doing has never been captured in a way that leadership can see clearly and make decisions on.

A lot of companies have done workflow mapping, process mapping, or even value stream mapping at some point. That’s a good starting point. It gives you the touchpoints, the handoffs, and the shape of how work flows through the operation. But the real diagnostic isn’t just “what’s happening today.” It’s the question that most mapping exercises skip entirely: what are we actually trying to do?

Where are we trying to go? What’s the outcome we’re optimizing toward? Is it throughput? Margin? Lead time? Quality? Customer retention? Some combination of those?

Until that’s defined, any optimization effort is pointing at a moving target. You can map every process in the building, document every SOP, and still make the wrong changes because you never agreed on what “better” looks like.

The Lens of Experience Problem

Here’s the thing most leaders don’t want to hear: we see our problems through the lens of our own experience. If you’ve spent your career solving capacity problems by buying equipment, your brain will default to “we need to buy equipment” every time capacity gets tight. If you’ve spent your career solving people problems by hiring, you’ll reach for headcount. If you’ve spent it solving data problems with software, you’ll reach for a new platform.

None of those instincts are wrong on their face. They’ve worked before, which is why they feel familiar. But they become a liability the moment the problem in front of you doesn’t match the shape of problems you’ve solved before.

I watched a company CEO recently talking about a capital investment they were considering. They were worried about capacity at a specific point in their operation, and the path forward, as they saw it, was to buy equipment. New asset, more throughput at that touchpoint, problem solved. I’ve seen companies achieve similar or better results in those scenarios for a fraction of the capital investment by doing the work differently. Not because the equipment wouldn’t have helped at all, but because the actual constraint in the system wasn’t at the touchpoint they were targeting.

That’s the lens of experience problem in action. They saw “capacity issue” and their experience said “buy equipment.” And the ecosystem around them reinforces that lens. Equipment dealers and OEMs will happily confirm that yes, the machine will fix your problem. It’s in their best interest to say so. Software vendors will do the same thing. Consultants too, for that matter. Anyone who sells a thing has an incentive to tell you that their thing is the answer.

The only way past that is to slow down long enough to ask: what’s the actual constraint in this system? Not the one that feels tight. The one that’s actually controlling the pace. Those are often not the same thing.

Optimization Without Technology Is a Real Thing

One of the clearest examples of why current state diagnosis matters is the work I’ve done around synchronous flow and throughput optimization. These are situations where a company has an unbalanced capacity state, they’ve been throwing resources at what they think is the bottleneck, and the overall system isn’t getting any faster.

Here’s what usually happens: leadership identifies a bottleneck, adds labor, buys equipment, or invests in software at that specific touchpoint. And the overall system still outputs at the pace of the real bottleneck, which was somewhere else entirely. So they spent the capital, hired the people, or implemented the platform, and the throughput barely moved.

When we solve for synchronous flow, we identify the most likely candidate for the real constraint in the system, and then we subordinate every other touchpoint to the pace of that constraint. There’s usually a lot of resource sharing and movement of people to feed the constraint, keep it fully utilized, and protect it from starvation. By monitoring a specific work-in-process profile and releasing work into the system based on the throughput of the constraint, we can typically increase the overall effectiveness of the entire system by a significant margin.

Here’s the part most people don’t expect: we can do this work without any technology at all. Technology can absolutely be an enabler in these situations for scheduling, monitoring throughput and capacity, and controlling work release. But the actual optimization is a function of understanding the system, defining the right work-in-process profile, and moving resources appropriately. That’s not a software problem. It’s a leadership and systems-thinking problem.

The irony is that companies in this situation often think they need technology because they’ve never seen the problem solved any other way. They’re looking at their operation through the lens of software vendors and equipment OEMs, all of whom are telling them that the answer is a purchase. And they never realize that the real answer might be a different way of thinking about the system they already have.

The Signals That You’re Trying to Optimize Too Early

If you’re reading this and wondering whether your own operation is ready to optimize or whether you need to step back and capture current state first, here are the signals I look for when I walk into a company.

The first is whether leadership is focused on symptoms or root causes. If every conversation is about the symptom (“this process is slow,” “this handoff keeps breaking,” “we can’t hit our ship dates”), and no one can articulate what’s actually causing those symptoms, that’s a tell. Optimization efforts built on symptom-level understanding almost always miss. They fix what’s visible and leave what’s actually broken.

The second is whether everyone can answer the outcome question. If you go talk to five different people at three different levels of the organization and ask “what are we trying to accomplish?”, do you get the same answer? If you don’t, you have a clarity problem, not an optimization problem. No process improvement is going to hold if the people running the process don’t agree on what it’s supposed to produce.

The third is spaghetti-at-the-wall behavior. I listen for the pattern where leadership bounces from one objective to another, starts multiple initiatives at the same time, and can’t tell you which one is actually the priority. “We want to grow.” Okay, how? “We want to capture market share.” Okay, where? “We want to improve efficiency.” Which part of the operation, and to what end? When the answers keep shifting, the organization is already burning bandwidth on confusion. Layering optimization on top of that is like trying to tune an engine that’s still being rebuilt.

The fourth is the “we’re changing again” signal at the individual contributor level. When you talk to people on the floor or in the front line and they describe the last three initiatives that came through, and they can’t tell you which one is still active, you know the operation has burned trust on scattered change. Any new initiative is going to run into that exhaustion, and it’s not going to stick.

The fifth is a mismatch between growth intent and delivery capacity. I had a client wanted to grow. Legitimate goal. But when we started pulling it apart, their backlog was already stretching lead times past what customers would tolerate, and manufacturing was already operating at the edge. Even if sales and marketing were enormously successful and grew the top line 30 percent, the back end would never have been able to keep up. The path forward wasn’t a new sales initiative. It was fixing the delivery mechanism first, so that growth wouldn’t immediately create a worse version of the problem they already had.

If any of these signals feel familiar, the work in front of you isn’t optimization. It’s getting to clarity about what you’re actually trying to do, what the real constraint is, and what’s standing between you and the outcome you want.

What the Current State Work Actually Looks Like

I run what I call a current state sprint with almost every engagement. It’s not a textbook methodology, it’s a diagnostic process built on decades of having these conversations. But here are the threads I’m pulling on when I do it.

What’s the intended outcome? Where are we trying to go? Not in vision-statement language. In specific, measurable terms. More throughput? Shorter lead times? Higher margin? Lower turnover? And over what time frame?

What resources do we have? Human resources, capital, equipment, technology already in place. What can we work with before we talk about acquiring anything new?

What have you tried before? This one matters more than people realize. If a company has tried five different versions of the same fix and none of them worked, that tells me something about either their diagnosis or their execution. If they’ve never tried anything and the problem has been sitting for years, that tells me something about their leadership capacity or their clarity.

Where is the actual constraint? Not the one that feels tight. The one that’s controlling the pace of the system. This usually requires walking the operation, watching work flow through, and talking to the people actually doing the work. Sometimes it requires basic measurement, not sophisticated analytics, just observing where work piles up and where it moves through easily.

Where are the reinforcing confusion points? Are stakeholders aligned, or are there key people who haven’t been in the conversation? I had one client who had invested in a technology startup and was building custom software for their operation. The project had stalled for a long time because not all the right stakeholders had been brought into the conversation. The current state work there wasn’t mapping the process. It was getting the right people into the room and defining the major bottleneck they needed to solve. Once that happened, the project started moving again.

The output of a current state sprint isn’t a polished report. It’s clarity about what you’re actually trying to accomplish, what’s standing in the way, and where the leverage is. Once you have that, optimization decisions become dramatically easier. You can tell the difference between a shiny solution that solves the wrong problem and a simple change that actually moves the system.

Why I’ll Tell You That You Don’t Need to Buy This From Me

Here’s something I say to clients that other consultants might find uncomfortable: you don’t have to buy this work from me. You can learn this stuff on your own. You can experiment on your own. You can read everything Goldratt ever wrote, talk to other operations leaders, and build your own version of systems thinking through trial and error.

The reason people hire me is because it’s the shortcut. I’ve spent nearly 30 years getting direct, hands-on experience with these problems. I can walk into a company and ask the questions that matter because I’ve asked them hundreds of times. That compression of time is the real value. But the underlying work is something any leader can learn, and many leaders should learn, because understanding how to diagnose your own system is one of the highest-leverage skills in operations.

What I don’t sell is a predetermined answer. I don’t have a piece of equipment to move, a software license to sell, or a methodology I need to apply whether it fits or not. That independence from the outcome is what makes the diagnostic work clean. If the answer is technology, great. If the answer is process discipline without new tools, also great. If the answer is that the real problem is leadership alignment and has nothing to do with operations at all, we’re going to talk about that too.

The question is never “what should we buy?” The question is always “what’s actually in the way?”

Final Thoughts

Business process optimization is not the problem. It’s a legitimate, useful discipline when it’s applied to a process that’s ready for it. The problem is that most companies reach for optimization before they’ve captured what they’re actually doing, defined what they’re trying to achieve, or identified the real constraint in the system.

If you take one thing from this article, let it be this: before you buy anything, implement anything, or launch any new initiative, stop and ask whether you actually know what’s in the way. Not the symptom. The root cause. Not the touchpoint that feels slow. The constraint that’s controlling the pace.

That answer is almost always worth more than whatever you were about to spend on the thing you thought would fix it.

That’s it for today.

See you all again next week!

Dave