Preskoči na sadržaj
Natrag na pisanje
|
automation consulting systems boundaries

Zašto kažem ne većini zahtjeva za automatizaciju

Većina zahtjeva za automatizaciju su rješenja za probleme koji još ne postoje, ili flasteri za pokvarene procese. Kažem ne kada ROI ne opravdava složenost.

When someone asks me to automate something, my first instinct is to say no.

This probably sounds strange. I build systems for a living. Automation is a significant part of what I do. You’d think I’d be eager to take on automation projects.

But most automation requests shouldn’t be automated. At least not yet.

What I Actually Hear

When someone says “I want to automate X,” what I hear is one of several things:

“X is painful and I want the pain to stop.” Fair enough. But automation isn’t the only way to reduce pain. Sometimes the process is painful because it’s broken, and fixing the process eliminates the pain without adding automation complexity.

“I heard automation saves time.” It can. But the time saved needs to exceed the time spent building, testing, and maintaining the automation. For low-frequency tasks, this equation rarely works out.

“We should be more modern.” Modernity isn’t an operational goal. The question isn’t whether something is modern. The question is whether it works better than the alternative.

“I’m trying to solve a problem I imagine having in the future.” This is the most common one. Someone anticipates growth, volume, or complexity that doesn’t exist yet, and wants to prepare. But automating for problems you don’t have is expensive insurance.

The Three Conditions

I’ll take on an automation project when three conditions are met:

The process is stable. If the workflow changes frequently, automation becomes maintenance burden. Every process change requires automation change. You’re not saving time — you’re multiplying your update workload.

Stable means: the process has been running the same way for at least a few months. The rules are clear. The exceptions are documented and handled consistently. If someone asks “how does this work?” the answer doesn’t involve “well, it depends.”

The ownership is clear. Someone needs to own the automation. Not just build it — maintain it. When it breaks, who fixes it? When the business changes, who updates it? When edge cases appear, who handles them?

If the answer is “we’ll figure it out” or “whoever’s available,” the automation will decay. Clear ownership means a specific person who understands both the automation and the business process it supports.

The ROI justifies the complexity. Automation isn’t free. Building it takes time. Testing it takes time. Maintaining it takes time. The benefits need to outweigh these costs.

I do simple math: How much time does this task take manually? How often does it happen? What’s the annual time cost? What will the automation cost to build and maintain? Is the payback reasonable?

If the payback is over a year, I’m skeptical. Too much changes in a year. The automation might be obsolete before it pays for itself.

When I Say No

Here are the specific situations where I decline:

The process isn’t documented. If you can’t describe the process in clear steps, it can’t be automated. Automation requires explicit logic. “We just kind of handle it” isn’t automatable.

Different people do it differently. If five people would describe the process five different ways, there’s no single thing to automate. First standardize, then consider automation.

The exceptions outnumber the rules. If most cases require special handling, automation creates more work than it saves. You end up maintaining complex logic for edge cases while still handling exceptions manually.

The volume is too low. If the task happens once a week and takes ten minutes, automating it rarely makes sense. Even if automation saves 80% of the time, you’re saving eight minutes weekly. That’s seven hours per year. Is that worth building and maintaining automation?

Nobody will own it. If there’s no clear owner, the automation becomes orphaned. It will break and nobody will notice. It will drift from reality and nobody will update it. Orphaned automation is worse than no automation.

The real problem is something else. Sometimes automation is proposed to avoid addressing a harder issue. The process is painful because it’s poorly designed, or because people aren’t following it, or because there’s a skills gap. Automation doesn’t fix these problems — it encodes them.

The Conversation That Follows

When I say no to an automation request, I explain why. Usually this leads to a more useful conversation.

“The process isn’t stable enough” leads to: “What would need to be true for it to be stable?” This often surfaces process issues that need attention regardless of automation.

“The ROI doesn’t work” leads to: “What would make it worth automating?” Sometimes this reveals that a smaller, simpler automation would be worthwhile even if the grand vision isn’t.

“The ownership is unclear” leads to: “Who would own this if we built it?” Sometimes this reveals that nobody actually wants responsibility, which is a signal that the project shouldn’t happen.

These conversations are often more valuable than the automation would have been. They clarify what the business actually needs, rather than what someone imagined they wanted.

What I Say Yes To

I take on automation projects when:

  • The task is truly repetitive — happening daily or multiple times daily
  • The rules are clear and documented
  • The exceptions are few and well-defined
  • Someone specific will own the result
  • The math works out to clear time savings
  • The process has been stable for months

These projects tend to succeed. The automation gets built, maintained, and used. It actually saves time. It makes the work more reliable.

The pattern is clear: automation works best when it’s applied to mature, stable processes with clear ownership. It works poorly when it’s applied to chaotic, undefined processes that nobody fully understands.

The Meta-Point

Saying no to bad automation requests is part of doing good work.

A consultant who says yes to everything isn’t serving the client — they’re serving their own invoice. The value isn’t in building automation. The value is in building automation that works.

Sometimes the most valuable thing I can do is explain why the automation shouldn’t be built. That saves the client money. It saves everyone time. It prevents the creation of maintenance burden that would accumulate for years.

Knowing when not to automate is as important as knowing how to automate.

Hrvatski

Kada me netko zamoli da automatiziram nešto, moj prvi instinkt je reći ne.

Ovo vjerojatno zvuči čudno. Gradim sustave za život. Automatizacija je značajan dio onoga što radim. Pomislili biste da bih bio željni preuzeti projekte automatizacije.

Ali većina zahtjeva za automatizaciju ne bi trebala biti automatizirana. Barem ne još.

Što zapravo čujem

Kada netko kaže “želim automatizirati X,” ono što čujem je jedno od nekoliko stvari:

“X je bolan i želim da bol prestane.” Fer dovoljno. Ali automatizacija nije jedini način za smanjenje boli. Ponekad je proces bolan jer je pokvaren, i popravljanje procesa eliminira bol bez dodavanja složenosti automatizacije.

“Čuo sam da automatizacija štedi vrijeme.” Može. Ali ušteda vremena mora premašiti vrijeme utrošeno na izgradnju, testiranje i održavanje automatizacije. Za niskofrekventne zadatke, ova jednadžba rijetko funkcionira.

“Trebali bismo biti moderniji.” Modernost nije operativni cilj. Pitanje nije je li nešto moderno. Pitanje je radi li bolje od alternative.

“Pokušavam riješiti problem koji zamišljam da ću imati u budućnosti.” Ovo je najčešće. Netko predviđa rast, volumen ili složenost koja još ne postoji i želi se pripremiti. Ali automatizacija za probleme koje nemate je skupo osiguranje.

Tri uvjeta

Prihvatit ću projekt automatizacije kada su ispunjena tri uvjeta:

Proces je stabilan. Ako se tijek rada često mijenja, automatizacija postaje teret održavanja. Svaka promjena procesa zahtijeva promjenu automatizacije. Ne štedite vrijeme — množite svoje opterećenje ažuriranja.

Stabilno znači: proces se odvija na isti način najmanje nekoliko mjeseci. Pravila su jasna. Iznimke su dokumentirane i konzistentno obrađene. Ako netko pita “kako ovo funkcionira?” odgovor ne uključuje “pa, ovisi.”

Vlasništvo je jasno. Netko treba posjedovati automatizaciju. Ne samo je izgraditi — održavati je. Kada se pokvari, tko popravlja? Kada se posao promijeni, tko ažurira? Kada se pojave rubni slučajevi, tko ih obrađuje?

Ako je odgovor “smislit ćemo” ili “tko god je dostupan,” automatizacija će propadati. Jasno vlasništvo znači specifična osoba koja razumije i automatizaciju i poslovni proces koji podržava.

ROI opravdava složenost. Automatizacija nije besplatna. Izgradnja oduzima vrijeme. Testiranje oduzima vrijeme. Održavanje oduzima vrijeme. Koristi moraju nadmašiti ove troškove.

Radim jednostavnu matematiku: Koliko vremena ovaj zadatak traje ručno? Koliko često se događa? Koji je godišnji trošak vremena? Koliko će automatizacija koštati za izgradnju i održavanje? Je li povrat razuman?

Ako je povrat duži od godine dana, skeptičan sam. Previše se mijenja u godini dana. Automatizacija bi mogla postati zastarjela prije nego što se isplati.

Kada kažem ne

Evo specifičnih situacija gdje odbijem:

Proces nije dokumentiran. Ako ne možete opisati proces u jasnim koracima, ne može se automatizirati. Automatizacija zahtijeva eksplicitnu logiku. “Mi to nekako riješimo” nije automatizabilno.

Različiti ljudi to rade različito. Ako bi pet ljudi opisalo proces na pet različitih načina, ne postoji jedna stvar za automatizaciju. Prvo standardizirajte, zatim razmotrite automatizaciju.

Iznimke nadmašuju pravila. Ako većina slučajeva zahtijeva posebno rukovanje, automatizacija stvara više posla nego što štedi. Na kraju održavate složenu logiku za rubne slučajeve dok još uvijek ručno obrađujete iznimke.

Volumen je prenizak. Ako se zadatak događa jednom tjedno i traje deset minuta, automatizacija rijetko ima smisla. Čak i ako automatizacija štedi 80% vremena, štedite osam minuta tjedno. To je sedam sati godišnje. Je li to vrijedno izgradnje i održavanja automatizacije?

Nitko to neće posjedovati. Ako nema jasnog vlasnika, automatizacija postaje napuštena. Pokvarit će se i nitko neće primijetiti. Odmaknuti će se od stvarnosti i nitko je neće ažurirati. Napuštena automatizacija je gora od nikakve automatizacije.

Pravi problem je nešto drugo. Ponekad se automatizacija predlaže da se izbjegne rješavanje težeg problema. Proces je bolan jer je loše dizajniran, ili zato što ga ljudi ne slijede, ili zato što postoji jaz u vještinama. Automatizacija ne popravlja ove probleme — kodira ih.

Razgovor koji slijedi

Kada kažem ne zahtjevu za automatizaciju, objašnjavam zašto. Obično to vodi do korisnijeg razgovora.

“Proces nije dovoljno stabilan” vodi do: “Što bi trebalo biti istinito da bude stabilan?” Ovo često otkriva probleme procesa koji trebaju pažnju neovisno o automatizaciji.

“ROI ne funkcionira” vodi do: “Što bi učinilo da vrijedi automatizirati?” Ponekad ovo otkriva da bi manja, jednostavnija automatizacija bila vrijedna čak i ako velika vizija nije.

“Vlasništvo je nejasno” vodi do: “Tko bi ovo posjedovao ako bismo izgradili?” Ponekad ovo otkriva da nitko zapravo ne želi odgovornost, što je signal da se projekt ne bi trebao dogoditi.

Ovi razgovori su često vrjedniji od automatizacije koja bi bila. Razjašnjavaju što tvrtka zapravo treba, umjesto onoga što je netko zamislio da želi.

Čemu kažem da

Prihvaćam projekte automatizacije kada:

  • Zadatak je stvarno repetitivan — događa se dnevno ili više puta dnevno
  • Pravila su jasna i dokumentirana
  • Iznimke su malobrojne i dobro definirane
  • Netko specifičan će posjedovati rezultat
  • Matematika pokazuje jasne uštede vremena
  • Proces je stabilan mjesecima

Ovi projekti obično uspijevaju. Automatizacija se izgradi, održava i koristi. Zapravo štedi vrijeme. Čini posao pouzdanijim.

Obrazac je jasan: automatizacija najbolje funkcionira kada se primjenjuje na zrele, stabilne procese s jasnim vlasništvom. Loše funkcionira kada se primjenjuje na kaotične, nedefinirane procese koje nitko potpuno ne razumije.

Meta-poanta

Reći ne lošim zahtjevima za automatizaciju je dio dobrog posla.

Konzultant koji kaže da svemu ne služi klijentu — služi vlastitom računu. Vrijednost nije u izgradnji automatizacije. Vrijednost je u izgradnji automatizacije koja funkcionira.

Ponekad je najvrjednije što mogu učiniti objasniti zašto automatizacija ne bi trebala biti izgrađena. To štedi klijentu novac. Štedi svima vrijeme. Sprječava stvaranje tereta održavanja koji bi se akumulirao godinama.

Znati kada ne automatizirati je jednako važno kao znati kako automatizirati.

Povezano

Press M to toggle | Click nodes to navigate