Are We Automating the Process We Have, or Designing the One We Want?

Most organizations have a documented version of how their business operates. There are workflows, procedures, approval rules, and systems intended to keep everything moving.

Then you spend some time with the people doing the work and discover that things don't always happen quite that way.

Someone maintains a spreadsheet because the system doesn't handle a particular situation very well. An approval goes through an extra person because the team learned, probably the hard way, that certain requests need another look. Employees develop shortcuts to get around cumbersome steps, or add steps of their own to prevent problems they've encountered before.

Some of this is unnecessary complexity that's accumulated over time, and some of it is pretty sensible.

And as AI makes it easier to analyze and automate business processes, I think we need to get better at telling the difference.

Process Mining Shows the Path, and AI Now Acts on It

Process mining has been around for years. By analyzing activity recorded in enterprise systems, it can help organizations understand how work actually moves through a business, where things get stuck, and how frequently people deviate from the expected process. What's interesting now is how AI is changing what happens after that analysis.

We're seeing tools that connect process discovery with recommendations and workflow automation. They can identify opportunities for improvement, suggest changes, and help implement them. The distance between finding a problem and doing something about it is getting shorter.

There's a lot of value in that. Most businesses have processes that are far more complicated than they need to be, and plenty of employees spend their days compensating for systems that should be doing more of the work.

But there's a question I'd want answered before acting on some of those recommendations... why does the process work that way in the first place?

I think it's useful to know where people deviate from the documented process. But even if everyone followed that process perfectly, we'd still need to ask whether it was the right process.

A deviation might be an unnecessary step that everyone has simply gotten used to. Or it might exist because someone discovered a problem that never made it into the official workflow. Process data can tell us a great deal about how work happens, and sometimes why. But deciding whether a deviation is useful, unnecessary, or a sign that the process needs to change still requires understanding the business.

Some Workarounds Are Business Rules Nobody Wrote Down

Say a financial services company is reviewing its transaction approval process. The documented workflow is fairly simple: transactions meeting certain criteria are approved automatically, while others go to a team member for review.

When the company analyzes the process, it finds that one team regularly performs an additional verification before approving certain transactions. That step isn't required, and it adds time... so it looks like a good candidate for elimination.

But when someone asks the team about it, they learn that employees have noticed a particular combination of circumstances that sometimes raises an issue. The system doesn't recognize it, so the team added its own verification step.

Now the extra work looks a little different. Maybe that verification should become a formal business rule, and maybe the system needs better information to make the decision automatically. It's also possible that the team is being overly cautious and the step really isn't necessary.

But we don't know yet, and that's why it deserves a closer look.

If we remove the step because the data identifies it as inefficient, we might improve processing time while reintroducing problems the employees had learned to prevent. And if an AI system can recommend and implement that change in a fraction of the time it used to take, there's less time for anyone to challenge those assumptions.

Handling Time Is One Outcome Among Several

When organizations talk about process optimization, the conversation usually starts with efficiency. How long does the work take or how many steps are involved? Where are the delays and what can we automate?

Those are all reasonable questions, especially when a process is expensive or frustrating to users. But I'd also want to know what happens when the process doesn't go according to plan.

Take a customer service team. Some requests take longer because an employee has to investigate an unusual situation, coordinate with another department, or make an exception to a standard policy. An optimization tool might identify those cases as outliers and recommend better ways to reduce handling time.

That could be exactly what the business needs. Or those might be the situations where customers most appreciate having someone who can work through a problem rather than follow a script.

You have to understand the outcome before deciding whether the extra time is waste.

The same applies to approval workflows, claims processing, purchasing, and plenty of other typical business operations. A step that looks unnecessary in the process data may be protecting against a risk, accommodating a customer need, or compensating for a limitation somewhere.

Of course, employees also develop habits that stopped being useful years ago. I've seen plenty of workflows where people continue doing something because that's how they were trained, even though the original reason no longer exists. "We've always done it this way" is a common reason I've heard. I think we should challenge these kinds of behaviors too. The question is whether we understand what a step contributes before deciding what to do with it.

Someone Still Has to Decide What the Process Should Be

Process optimization often gets treated as an operational exercise. Find the bottleneck, make the change, and measure the result and outcomes.

But removing an approval means deciding which situations no longer need oversight. Automating an exception means deciding which circumstances qualify and how the system should respond. Replacing an employee's judgment with a rule means deciding which information counts, what happens when something is missing, and when the system should stop and ask for help.

And the people who understand those consequences aren't necessarily the people analyzing the process. Someone working with customers every day may recognize a problem that isn't visible in the data. A domain expert may know why a particular exception exists. Product and engineering teams can help determine whether the process needs a new business rule, a different experience, or a change to the underlying systems.

That's the kind of conversation I'd want to have before approving an optimization that changes how the business operates.

I've written before about agents making product decisions when they fill gaps in requirements. The same thing can happen with process optimization. Someone approves a recommendation without fully considering the business decisions behind it, and suddenly those decisions are part of how the organization operates.

I wouldn't expect every optimization to require a lengthy discovery effort. Sometimes the problem is obvious, and the solution is too. But when a recommendation changes how the business makes decisions or handles exceptions, someone needs to own that decision with a clear understanding of the consequences.

Discovery Keeps Going After Mapping

I like the idea of using process mining as a starting point for discovery. It gives teams evidence they might otherwise spend weeks trying to collect, and it can reveal patterns that nobody has noticed. But once we've identified a problem, there's still work to do.

We need to understand why people follow different paths through the process. That might mean reviewing unusual transactions, observing how employees handle exceptions, or talking with the people who have been maintaining the same workaround for five years.

Sometimes we'll find that the workaround should disappear. Other times we'll discover a missing business rule that needs to become part of the system. We might even find that the entire workflow needs to be reconsidered because the business has changed since it was designed.

Instead of automatically making the current process faster, we can ask whether there's a better way to accomplish what the business is trying to do.

Maybe several approvals can be replaced with a single decision based on better information. Maybe customers could provide something earlier in the process that eliminates a whole series of follow-up activities. Or perhaps the right solution is to automate the routine work while leaving unusual cases with someone who understands the context.

The data might point us toward those opportunities, but it won't necessarily tell us which approach makes the most sense for the business. That takes some investigation and a willingness to question the existing process.

Faster Implementation Raises the Cost of a Wrong Call

Agentic development is shortening the distance between spotting an opportunity and having working software. Agents can help analyze requirements, generate code, and test it, and for organizations sitting on years of process problems, that's a real advantage.

It also means we can act on an incomplete understanding much faster. The generated workflow can do exactly what it was specified to do and pass every test, and none of that tells us whether we made the right call about the process.

I wouldn't answer that with more approvals. Teams have spent years taking delay out of delivery. I'd put the attention earlier, before anyone builds. What outcome are we trying to improve? Which behaviors need to survive? What happens when the usual path doesn't apply? And who understands the consequences well enough to make that call?

Designing the Process We Actually Want

I'd use process discovery and agentic development together without much hesitation. What I'd be careful about is treating the process we observe as the process we should keep, or assuming every deviation from the documented workflow is a defect.

The current process reflects years of business decisions, system limitations, and employee workarounds. Some of that is worth keeping. Some should have disappeared years ago. We need to understand the difference before deciding what to automate.

So before we automate another workflow: are we automating the process we have, or designing the one we actually want?