Functional analysis
Analysis before automation
Most automation projects fail before the build even starts, because nobody scoped the problem properly first.There is a pattern to automation projects that go wrong. The tooling works, the demo is impressive, and then the thing meets the real process: the exceptions, the "oh, except when it's a Tuesday" rules, the handoff nobody documented. It quietly falls apart.
Automating a process you don't understand.
The failure starts long before the build stage, back at the point where nobody scoped the problem properly. By the time the automation runs live, it carries that gap in its logic, and unpicking it costs far more than the analysis would have.
The failure pattern
Speed and consistency turn against you.
Automation gives a process speed and consistency, and a half-understood process gets both applied to the wrong steps.Here is what half-understood looks like in practice. A team automates intake. The form routes cleanly, the confirmation goes out, the record lands in the system. Then the first awkward case arrives: a client who needs two services at once, a referral that skips a step, a field left blank on purpose. The automation has no branch for it, so it does the wrong thing confidently, and the staff quietly start handling those by hand. Now there are two processes, the automated one and the shadow one, and nobody fully trusts either.
The build followed its instructions exactly, so the tooling is not what failed here. The gap sat in the instructions, and it existed before anyone wrote a line of code.
Before the build
What good scoping looks like.
Before we build anything, we make the process visible and write it down: a map of the real workflow, a list of the rules and the exceptions, requirements you can test, and a clear line about what stays human.Map the real workflow
Chart the way the work actually happens today, including the steps nobody ever wrote down.
Talk to the person who does the work
Whoever handles the work every day is the one who knows which cases break the rule and what they do about them.
Find the edge cases early
They are where automation breaks and where risk lives, and usually a bigger share of the work than anyone expects.
Decide where humans stay in the loop
Name the steps where judgment carries real weight. Those stay with a person, whatever the volume around them.
Write requirements you can test
"Handles invoices" gives you nothing to check against. Write it so you can test it: extract these six fields, flag anything below 90% confidence for review.
Knowing when to stop
How you know the analysis is done.
The analysis is finished when a few plain things are true.Drawable end to end
You can draw the workflow from start to finish, and the people in the room agree it is right.
Named exceptions
You can name the handful of exceptions that matter and say what the workflow does with each one.
A number for success
You have a figure that defines success, and you can measure the finished workflow against it.
Clear human steps
You know which steps stay with a person, and why.
If any of those is missing, the scope still has a hole in it, and that hole is where the build will fail.
Why analysis matters more, not less
AI raises the stakes.
It is tempting to think AI makes analysis less important, on the assumption that a capable model can figure the process out on its own. It cannot. When a system acts with more autonomy, the cost of pointing it at a poorly understood process rises.
Faced with the case nobody scoped, a model makes a confident decision anyway, at the speed and scale of software, and the wrong call surfaces later. The analysis is what draws the boundary the model would otherwise cross.
Where to start