Contents5 sections
Track: The Baseline Is the Only Thing That Makes After Mean Anything
Without a before number signed by the operator, the after number is a claim. Track produces the one measurement the whole engagement is judged against.
The question every automation result should have to answer
Compared to what?
It is a boring question and almost nothing survives it. A workflow now runs in four hours. It used to run in - and here the sentence usually slows down, because nobody wrote the old number down, and the figure that arrives next was produced from memory by people who would prefer the project to have worked.
That is not dishonesty. It is what memory does. Ask anyone how long a task used to take and you get the version they remember most vividly, which is the worst one.
What Track measures
Four things per workflow, and no more, because a baseline with twenty metrics in it is one nobody will maintain or defend.
- Cycle time from the moment work enters the process to the moment it leaves.
- Throughput per week, including the runs that were abandoned.
- Error rate, defined as work that had to be redone rather than work someone disliked.
- Cost per run, at loaded hourly cost rather than headline salary.
Then the window: long enough to include a bad week, chosen before the data is seen rather than after.
The signature
The operator signs it. Not the vendor.
This is the only stage of the engagement with a signature on it, and the reason is narrow. A before number produced by the party who will be judged against it is a negotiating position. Signed by the client, it becomes the fixed point that makes the after number mean something, in both directions: the vendor cannot revise it down when the result disappoints, and the client cannot revise it up when a better story is wanted.
It also forces the definition of success into the open at the one moment when neither side knows whether they will like it.
What breaks without this stage
The engagement still works. That is the problem.
The build ships, the new cycle time is real, and the improvement is reported against a before figure assembled after the fact. Everyone is pleased for a quarter. Then somebody in finance asks how the payback was calculated, and the answer traces back to a number that was never measured, and at that point the entire result becomes unusable - not wrong, necessarily, but unusable, which for a capital decision is the same thing.
The arithmetic that justifies the build is only as good as its first term. Track is the first term.
Where it sits
Track is the third of six stages, and it only works if the process was stabilised first - the reason for that is in why the scope gets frozen. What happens to the measured process next is elimination before encoding, and the argument for putting an audit ahead of a build at all is in the audit before automation.
01Why does the operator sign the baseline rather than the vendor?+
Because the signature is the whole mechanism. A number produced by the party who will later be judged against it is not a measurement, it is a negotiating position, and everyone in the room knows it even when nobody says so. When the operator signs, two things become true at once: the vendor cannot quietly revise the before figure downwards when the after figure disappoints, and the client cannot revise it upwards when they want a better story for the board. It also forces the conversation that most engagements avoid, which is what counts as success, held at the one moment when neither side yet knows whether they will like the answer.
02What if the process is too irregular to measure in a fortnight?+
Then the window gets longer, or the workflow was not a good first candidate. Some processes genuinely need a full quarter to show their distribution, and month-end reconciliation is the obvious example: measured in the first fortnight of a month it looks trivial, and measured across the boundary it looks like a different job. The right response is to extend the window for that workflow rather than to pick a convenient fortnight and call it typical. If extending it puts the build too far out to be worth doing, that is a real finding about sequencing, not a reason to measure badly and proceed anyway.
03Why include a bad week on purpose?+
Because the exception load is the part automation has to survive, and a baseline taken from a clean week measures the version of the process that never causes trouble. The happy path is not where the money is. The money is in the run that arrived with a missing field, the client who replied in an unexpected format, the approval that sat for two days because the approver was traveling. A window that excludes all of that produces a flattering before number and, worse, a specification written against a process that does not exist, which is how a workflow gets built that works in the demo and fails in the second week of use.
04Is the baseline reusable if the project does not go ahead?+
Yes, and that is deliberate. The baseline belongs to the client, in writing, whether or not a build follows. It is the document that makes the next attempt cheaper regardless of who runs it, because the expensive part of any automation project is finding out how the work actually moves and what it currently costs, not writing the code that moves it differently. It also gives the operator something to hold the next vendor to. A consultancy that treats its measurements as internal working papers is telling you what it expects the measurements to be used for.
