How to Start an Automation Project: From the Problem, Not the Tool

I start from the problem, not the tool. The first task is not writing code; it is measuring two things:

• Which task repeats, and how often?
• Where exactly is time lost in the current process?

These sound simple, but the answers are often surprising. A team says "modelling takes too long"; when you measure it, the real loss turns out to be in manually fixing drawing outputs, not in modelling. A project that automates the wrong place produces no felt gain, even if it works flawlessly.

The measurement does not need to be elaborate. A simple two-week log — which task, how many times, roughly how many minutes — is usually enough. Precision is not the point; finding the right line item is.

The return on automation is time saved multiplied by repetition count. Perfectly automating a rarely repeated task creates less value than roughly automating a frequently repeated one.

The second step is to look at the list from step one and make one distinction explicit: what goes to software, and what stays with a person.

Skip this step and the project breaks in one of two ways:

1. Scope grows without end. Every exception gets added to the software, the system turns into a pile of rules, and maintenance becomes impossible.
2. Nobody trusts it. When it is unclear where the automation starts and stops, users re-check its output every single time — which hands the saved time straight back.

A practical dividing line: work that can be turned into a rule goes to software; work that requires judgement stays with a person. Computing a profile's length from a parameter is a rule. Deciding whether a customer's special request fits the standard production flow is judgement.

Where the boundary sits matters — and so does having it written down. Every later exception request gets evaluated against that document.

In the third step you start writing code, but not all of it. You pick a small piece whose result can be measured.

The test of a well-chosen pilot: when it is finished, whether it worked should not be open to debate. "It feels better" is not a result. "Preparing the same frame went from 40 minutes to 6" is a result.

A pilot does one more thing: it breaks assumptions early. In automation projects, the most expensive mistakes are the ones you discover six months in, when the production data turns out not to be in the format you assumed. A small pilot surfaces that in week two.

When choosing pilot scope I look for one property: make it end to end but narrow. Cover the whole chain — from parameter input to production output — for a single product variant. A pilot that automates only the middle of the chain will not reveal the real bottlenecks.

The last step is growing the scope — on evidence, not on assumption.

As the pilot proves itself in the field, you add the next variant, the next product family, the next output type. Before each expansion, the same question is asked: which of the losses measured in step one does this addition actually address?

Without that discipline, automation projects bloat with features nobody uses. Every unused feature is not just wasted time; it becomes a permanent maintenance cost.

When describing a method, saying what it excludes matters as much as saying what it covers.

• Decisions that require judgement. I use AI tools for speed and iteration; architectural decisions, validation, and test coverage stay with me.
• Low-repetition work. Automating a task done once a month usually costs more than doing it by hand.
• Processes that have not settled. Automating a workflow that keeps changing is trying to pin down a moving target. The process settles first, then it gets automated.

An automation project's success is decided by the questions asked in the first week, not by the library chosen on day one:

Tool selection comes after these four answers — and by then it is usually obvious anyway.