What Most Teams Get Wrong About Workflow Automation (And How BPMN Fixes It)

5 MINS

After over a decade working with BPM platforms — Newgen OmniFlow, Flowable, and others — I've seen the same mistake repeated across organizations of every size. They automate the process as it currently exists, rather than the process as it should work.

That distinction sounds obvious. In practice, it's where most BPM initiatives stall.

The real problem isn't the tool

When a workflow automation project fails, the post-mortem usually blames the technology. The platform was too complex. The integration was brittle. The vendor oversold the capabilities.

Sometimes that's true. But more often, the technology was fine. The problem was that nobody modeled the process correctly before the first line of configuration was written.

I've walked into organizations where "automation" meant taking a paper-based approval chain, digitizing each step, and connecting them with notifications. The process ran faster. But it was still the wrong process — four approval layers that existed because nobody had authority to remove them, not because the business needed them.

BPMN (Business Process Model and Notation) forces you to have this conversation before you build. When you draw a BPMN diagram, you can't hide ambiguity. Every gateway, every swimlane, every timer event is a decision you have to make explicit. That exposure is uncomfortable. It's also the most valuable part of the exercise.

The swimlane test

Here's a quick diagnostic I use: draw a BPMN swimlane diagram of your current process and show it to the people who actually do the work. Not the managers. The people in the trenches.

If they point to a swimlane and say "we never actually do it that way," you have a process gap that no automation tool will fix. You'll just execute the gap faster.

The swimlane test reveals three categories of problems:

Shadow processes : Steps that happen outside the official workflow because the official workflow doesn't actually work

Bottleneck handoffs : Transition points where work sits because ownership is unclear

Dead gates : Approval steps with no real decision criteria — the answer is always yes, so why does the step exist? Each of these is a business problem, not a technical one. BPMN surfaces them. The process redesign work has to happen before the automation work starts.

What good BPM implementation actually looks like

The best workflow automation projects I've been part of shared a few traits. First, there was a dedicated process analyst involved before any tooling decisions were made. Second, the BPMN diagrams were treated as living documents — reviewed with stakeholders, updated as the process changed, not handed off to developers and forgotten. Third, the KPIs were defined up front: what does success look like in cycle time, error rate, or handoff latency?

Without those inputs, you're building a machine to a spec nobody agreed on.

Automation is a force multiplier. If the underlying process is solid, automation delivers real efficiency gains. If it isn't, automation just makes the dysfunction happen at scale.

Fix the process first. Then automate it.

The uncomfortable truth about BPMN adoption

Most teams underinvest in process modeling because it's slower than jumping to implementation. There's no velocity metric for "modeled the process correctly." Stakeholders want to see something running.

I get it. But the cost of rework on a poorly-designed BPM implementation — re-mapping workflows, rewriting integration handlers, re-training users on a process that changed — is orders of magnitude higher than the cost of doing the modeling properly on day one.

BPMN isn't a formality. It's the specification. Treat it like one.

From Engineer to Engineering Manager: The Hard Parts Nobody Talks About

Harshath skipped presentations and built real AI products.

Harshath M. was part of the January 2026 cohort at Curious PM, alongside 13 other talented participants.