Automate a broken process and you just made it faster.

The most expensive mistake in a technology rollout is usually made before a single piece of technology is installed. It is the decision to automate the process you already have, instead of the process you should have.

It feels efficient. The current way is documented, everyone knows it, and encoding it into the new system is the fast path to go-live. It is also how you spend a fortune making a bad process permanent.

There is an old line that fits perfectly here: applied to a flawed process, technology will only amplify the flaw. That is not a warning most rollouts heed.

Speed is not the same as improvement

Take a flawed workflow and build it into a new system, and you have not fixed anything. You have made the flaws faster, more rigid, and far more expensive to change later.

Worse, you have now baked the dysfunction into software, where it carries the authority of the system. The workaround people used to rely on is now blocked, the new path is no better, and everyone has one more reason to resent the change and quietly revert.

Faster is only good if the direction is right. Automating a process that was sending work in circles just sends it in circles more efficiently.

Why this happens to smart teams

Nobody sets out to automate a broken process. It happens because redesign is hard and the clock is loud.

Mapping how the work should flow, renegotiating who owns what, settling decision rights, challenging a sequence that has existed for a decade, all of that is slow and political. Configuring the system to match what already exists is fast and uncontroversial. So the path of least resistance wins.

There is also a comfort in keeping the process familiar. Changing the tool feels like progress without the discomfort of changing how people actually work. But the tool was never the point.

Configuration is not redesign

A lot of programs believe they have redesigned the process when what they really did was configure the new system. Those are not the same thing.

Configuration asks how do we set up this tool. Redesign asks how should this work actually flow, regardless of the tool. If you only ever ask the first question, the system inherits every assumption baked into the old way, including the broken ones.

The redesign has to happen at the level of the work itself, in plain language, before anyone opens the configuration screen. Otherwise the tool quietly dictates the process, and the tool does not know your business.

Redesign is the precondition, not the bonus

The discipline that prevents this is simple to say and hard to do. You redesign the operating model before you automate it.

Define how the work should flow. Settle the roles and the decision rights. Decide what to stop doing entirely. Only then do you let the technology serve the redesigned process. The system should encode the future state, not enshrine the past one.

This is the Architect work, and it is where the real value of a transformation is created or lost. The technology then becomes what it should always have been: an instrument for a process you actually chose.

The hardest part is deciding what to stop

Redesign is not only about adding better steps. It is mostly about removing ones that no longer earn their place. Every organization accumulates process barnacles, steps that exist because of a problem that was solved years ago, an approval that protected against a risk that no longer exists.

Automating those steps preserves them forever and gives them the authority of the system. Redesign is the rare chance to question them and cut the ones that do not survive scrutiny.

Deciding what to stop doing is harder than deciding what to add, because every step has a defender. But it is where most of the gain hides.

Order the changes by return

Redesigning everything at once is its own failure mode. The way through is to sequence by return. Highest-impact changes first, so the early wins fund the patience that the harder changes require.

That sequencing is not a project-management nicety. It is how you keep the organization believing while you do the slow work of changing how it actually operates.

It also lets you learn. The first redesigned process teaches you things that make the second one better, as long as you go deliberately instead of all at once.

The question to ask before configuration

Before anyone configures anything, there is one question worth forcing into the room. If we did not have this system, would we still do the work this way?

If the answer is no, you are about to automate something you would not choose on purpose. That is the moment to stop and redesign, while it is still cheap.

Asking it after go-live is far more expensive, because by then the flawed process is encoded, trained, and defended.

Technology is very good at doing whatever you tell it, faster. That is exactly why the process has to be right before you hand it over.

Automate a broken process and you have not solved the problem. You have just made sure it happens at scale, with a system's authority behind it, and a much larger bill to change it later.