Everyone Agrees. Almost Nobody Does It.

There’s a line making the rounds right now, and it’s the kind of line that sounds obvious until you sit with it: everyone agrees that re-engineering is the only real way to keep up with where AI is headed — not just where it is today.

And almost nobody actually does it, because it’s genuinely hard.

I believe that line. I’ve watched it play out from both sides of the table for almost three decades. Here’s what actually happens instead of re-engineering: someone wires an LLM into a process nobody’s touched in years. It works well enough to demo. Everyone calls it a win.

Then it hits real volume, or an auditor asks how a decision got made and there’s no good answer, or the underlying model gets updated and the prompt that was quietly holding the whole thing together stops working. Now someone’s rewriting that prompt at midnight, and that’s what’s passing for “AI transformation” at a lot of companies.

Reengineering isn’t a rebrand of automation

This matters because reengineering and automation are not the same exercise, and conflating them is exactly how organizations end up with midnight-prompt-rewrite syndrome. Automation executes an existing process faster. Reengineering asks whether the process should exist in its current form at all.

The classic example still holds up decades later: Ford didn’t automate its accounts payable approval steps — it eliminated invoices entirely by matching purchase orders directly against receiving data, and cut headcount by 75% in the process. That’s a different category of change than “we added a chatbot to the front end.”

The uncomfortable truth is that most organizations aren’t choosing between automation and reengineering with open eyes. They’re defaulting to automation because it’s faster to greenlight, easier to demo, and doesn’t require anyone to admit the underlying process was broken to begin with. Reengineering requires that admission first.

Why the architecture underneath has to be open

Here’s the part that doesn’t get said enough: even when a company commits to doing this right, the choice of platform quietly decides whether the work lasts five years or five months.

If your process logic lives inside a proprietary engine, every AI capability you bolt on inherits that vendor’s roadmap, release cycle, and pricing. When the vendor changes direction and vendors always eventually change direction you’re rebuilding, not upgrading.

Compare that to a process defined in an open standard like BPMN 2.0: it’s a portable file any compliant engine can read and execute, with business logic written in whatever language makes sense and connected through standard APIs. Moving that process from one BPMN-compliant engine to another takes real but reasonable effort. Moving a process built entirely inside a closed, proprietary platform to anything else usually doesn’t happen at all the switching cost is the point, whether or not the vendor says so out loud.

That’s not an argument against any specific platform. It’s an argument for knowing, going in, whether you’re building something composable or something you’ll be quietly stuck with in three years when the AI landscape has moved twice and your platform has moved once.

What this looks like in practice

The organizations doing this well share a few habits:

• They scope reengineering to processes that are actually broken, not everything that’s merely inefficient. Reengineering is expensive and disruptive; reserving it for high-impact processes is what makes the ROI math work.

• They map the current state honestly before redesigning — not to preserve it, but to understand what it’s actually accomplishing before deciding what should replace it.

• They pick architecture that lets the AI layer change without forcing a full rebuild of the process underneath it, because the AI layer will change, repeatedly, faster than most process redesigns can keep pace.

• They put people who are credible, empowered, and genuinely bought in on the team — not just technically competent. Reengineering fails on change management far more often than it fails on technology.

None of this is exotic.

It’s the same discipline that’s always separated a durable transformation from a demo that quietly decays.

AI just raised the stakes and shortened the runway, because now the thing you’re not reengineering is also the thing getting outpaced by a competitor’s model update every few months.

If you’re evaluating whether your organization is actually reengineering or just automating with better vocabulary, that’s usually a five-minute honest conversation. It’s just one most people would rather not have.