Process mapping and choosing what to automate

An automation role is only half engineering. The other half is walking into Finance or Operations, working out what actually happens today, and deciding which parts deserve to exist at all. Candidates who skip straight to “I’d build an n8n workflow” fail this question; the expected answer starts earlier.

Map before you touch anything

The first deliverable is a picture of the current process that the people who do it agree with. Three notations are enough:

SIPOC — suppliers, inputs, process, outputs, customers — is one page that fixes the boundary before anyone argues about details. Do it first; most disagreements about a process turn out to be disagreements about where it starts.

Swimlanes put each step in the lane of whoever performs it. The value is visual: every line crossing a lane boundary is a handoff, and handoffs are where delay, rework and dropped items live. Counting the crossings is often the whole diagnosis.

Value-stream style timing annotates each step with two numbers that people routinely conflate:

step            touch   elapsed
─────────────────────────────────
submit invoice   2 min     2 min
wait for approval   0     3 days      <- the actual problem
post to ledger   5 min    15 min

Touch time is work; elapsed time is work plus waiting. Automating a two-minute step inside a three-day process saves two minutes. Getting people to see that distinction is most of the consulting value, and saying it in an interview lands hard because it is the mistake everyone has watched happen.

The sequence: eliminate, simplify, then automate

In that order, and the order is the point.

1. Eliminate. Does this step need to exist? Reports nobody reads, approvals nobody has ever rejected, fields nobody queries. The cheapest automation is deletion.
2. Simplify. Can the rule be made simpler before it is encoded? Automating a policy with eleven exceptions makes the exceptions permanent.
3. Standardise. Can the inputs be made consistent? Most integration pain is really data-quality pain arriving from upstream.
4. Automate. Only now.

Automating a bad process makes it faster and harder to change. A manual process has a human absorbing its inconsistency; encode it and the inconsistency becomes edge cases in your workflow, plus a rebuild whenever the policy shifts.

Deciding what is worth it

Score candidates rather than taking whoever asked loudest.

The arithmetic to say out loud: hours saved per month × months until the process changes, against build plus maintenance. A weekly 30-minute task is 26 hours a year — worth a day of work, not worth a fortnight. Interviewers listen for whether you volunteer maintenance cost, because low-code workflows are cheap to build and not cheap to keep alive.

Where variability is high, automate the 80% and route the rest to a human. Full automation of a messy process fails; partial automation with a clean exception queue ships. That framing — plus an explicit measure of what fraction lands in the queue — is the strongest thing you can bring to this question.

# The shape that survives: confident path automated, rest queued,
# and the routing rate is a metric you watch rather than a guess.
def route(doc: Invoice) -> Outcome:
    result = extract(doc)
    if result.confidence >= 0.9 and result.total == doc.stated_total:
        return post_to_ledger(result)          # ~80% of volume
    return review_queue.add(doc, reason=result.explain())

Measure before and after, with the same definition

Baseline the process before changing it, or you cannot show value and will be asked to. Four numbers cover most cases: volume per period, touch time per item, elapsed time per item, and rework or error rate.

Two traps worth naming:

• Work moves rather than disappears. Automating data entry can create a review queue that costs as much. Measure the whole path, not the step.
• The baseline gets remembered generously. People recall the process as slower than it was once it improves. Write the numbers down first.

Where automation projects actually fail

• No owner after handover. The engineer moves on, an OAuth token expires, and nobody notices for weeks.
• The undocumented exception. “Except for the German entity, we do it differently” surfaces in week three, after the design is fixed.
• Shadow process survives. People keep the spreadsheet because they do not trust the new thing. That is a signal about trust, not about training.
• Silent failure. The workflow stops and the data just stops moving. Alert on absence — a heartbeat — not only on errors.
• Automating around a system instead of fixing it. Sometimes the right answer is a config change in the ERP, not a workflow that scrapes it.

Related

• Zapier, Make and choosing an automation platform
  • choosing the tool once you know what to build.
• n8n and low-code automation
  • where the boundary between canvas and code belongs.
• Webhooks
  • the usual trigger for an automated process.
• Estimation and Planning - estimating the build once scope is known.
• Durable execution and human-in-the-loop
  • the human-in-the-loop queue, built properly.
• Leading technical direction on R&D work
  • running work whose outcome is uncertain.