Zašto automatizacija pokvarenog procesa pogoršava stvari

I keep seeing the same pattern in small businesses: something is painful, so someone suggests automating it.

The invoice process takes too long. The customer onboarding is a mess. The inventory tracking requires constant manual updates. The instinct is understandable — if it hurts, remove the human element. Let software handle it.

But automation doesn’t fix processes. It scales them.

The Multiplication Problem

When you automate a broken process, you don’t eliminate the brokenness. You accelerate it.

Consider a simple example: a business sends invoices manually. The process is slow because nobody knows which clients need purchase orders, which ones require specific payment terms, and which ones have special billing addresses. Every invoice requires someone to remember — or look up — these details.

The “solution” is to automate invoicing. Now invoices go out instantly. But they go out with the wrong information. Purchase orders are missing. Payment terms are incorrect. Billing addresses are outdated.

Before automation, errors happened at human speed. After automation, they happen at machine speed. Instead of fixing one invoice per week, someone is now fixing thirty per day.

The errors multiplied. The exceptions piled up. And someone still has to interpret the output — but now they’re doing it under pressure, at volume, without the context they had when they were sending invoices manually.

Why This Happens

The instinct to automate comes from a reasonable place. Manual processes are slow and tedious. They depend on individual memory. They break when people are sick or quit.

But these problems aren’t solved by automation. They’re solved by clarity.

The real issue with the invoice process wasn’t that it was manual. The issue was that nobody had documented which clients needed what. The information lived in one person’s head, or in scattered emails, or in tribal knowledge that evaporated every time someone left.

Automation doesn’t create clarity. It assumes clarity already exists. When it doesn’t, automation just moves faster in the wrong direction.

The Fix-First Principle

The sequence matters: fix the process first, automate second.

Fixing the process means making it work reliably with humans. It means documenting the rules. It means handling the exceptions explicitly instead of relying on judgment calls. It means making the process legible — something anyone could follow, not just the person who invented it.

This is boring work. It’s not as exciting as buying software or building integrations. But it’s where the actual improvement happens.

Most of the time, fixing the process removes the need for automation entirely. When the rules are clear and the exceptions are handled, the manual process becomes fast. Not as fast as software, but fast enough that the overhead of automation isn’t worth it.

And when automation does make sense — when volume genuinely exceeds what humans can handle — the automation works. Because it’s scaling something that already functions.

The Warning Signs

You’re about to automate a broken process if:

• Nobody can explain the current process in under two minutes
• The process has more exceptions than rules
• Different people do it differently
• The last person who understood it left six months ago
• You’re hoping the software will “figure it out”

These aren’t signs that you need automation. They’re signs that you need documentation, training, and probably some hard decisions about which exceptions you’re going to stop accommodating.

What Actually Works

Start by writing down the process as it should work. Not as it does work — as it should. Then identify every exception. For each exception, decide: is this a real variation that needs to be handled, or is this something that happened once and became permanent by accident?

Most exceptions are accidents. They’re accommodations that made sense in one moment and never got revisited. Eliminating them simplifies the process more than any automation could.

Once the process is clean, run it manually for a while. See if the pain is still there. Often it isn’t — the pain was coming from the complexity, not the manual work.

If pain remains, now you’re ready to automate. You have clear rules. You have documented exceptions. You know exactly what the software needs to do. The automation becomes a straightforward implementation of something that already works.

That’s the order: clarity, then speed. Never the reverse.

---

Related

This pattern is one of the core reasons digital transformation initiatives fail. For a deeper exploration, see: Why Digital Transformation Fails — examining how technology projects collapse when they’re applied to unclear foundations.