Without a Baseline, No Automation Can Prove It Saved Time

Someone asks in the management committee how much time the automation implemented six months ago actually saved. The answer is usually a feeling: "it feels faster," "the team says they no longer do that manual work." No one has a number to compare against another number. This scene repeats itself in companies that automated the technology well and the evidence poorly: the process may in fact have improved, but there's no way to prove it, and without proof there's no way to justify the investment or decide whether it's worth scaling it to other processes.

Measuring beforehand isn't the slow step, it's the one that makes comparison possible

The temptation when automating is to skip the prior measurement because it seems like bureaucracy: everyone wants to see the tool working, no one wants to spend weeks timing a manual process that's already known to be slow. But that prior measurement —the time each step takes, the associated cost, the error rate of the process as it stands today— is the only control variable that exists. Without it, any subsequent change has no reference point: there's nothing to compare it against.

Documentation from commercial process management systems formalizes this explicitly. The methods the industry records for evaluating automation describe a fixed order: first a baseline of the process is quantified —a key performance indicator and a measure of the underlying complexity—, then the improvement achieved by the tool is measured, and only then can the generated value be estimated. If the first step doesn't exist, the following two lose their footing: there's no improvement to measure if there's no starting point.

Without a baseline, any result can be explained by something else

Here's the real problem, not the methodological one but the operational one: when the automated process fails or improves, no one can attribute it with certainty to the automation. It could have been the automation, but it could also have been a seasonal change, the departure of a more experienced person, an adjustment in workload volume, or simply that the team started paying more attention to the process because it's now under review. Without a documented baseline, all of these explanations are equally valid, and the company is left without an argument to defend the investment or to discard it.

A process mining study applied to evaluating robotic automation of repetitive tasks illustrates this point with methodological precision: before deciding whether an activity was suitable for automation, its current failure rate was measured, identifying what proportion of cases required reprocessing and what proportion ended in elimination of the original item. The study's own conclusion is what supports this article's thesis: without being able to assess how the process behaves today, it's impossible to assess whether automating it makes sense. This isn't a technical nuance, it's the minimum condition for making the decision.

A hospital improvement case using DMAIC methodology shows the same principle from the results side. Hospital stay length was documented before the intervention —a mean value with its variability— and after applying the changes, exactly how much it was reduced could be quantified. That reduction is only demonstrable because the starting number was recorded. Had the hospital intervened without measuring beforehand, the final result would have been the same, but the possibility of proving it would not.

What a baseline must record to actually serve its purpose

Not just any number works as a baseline. The same documentation on KPI monitoring systems for automation warns that not all KPIs are equally useful for judging impact: only those that are quantifiable, are actually measured before intervening, are reliable, and are aligned with the decision to be made serve this purpose. An imprecise indicator, one estimated from memory or recorded inconsistently, does not function as a baseline, even if it exists on paper.

An academic protocol for auditable automation proposes a concrete order that any company can adapt without relying on sophisticated tools: extract baseline data from the current process, verify its quality —that the times are complete, that there are no missing events, that the recording method hasn't changed halfway through— and, if those checks reveal significant gaps, treat those gaps as the first problem to solve before automating anything. The same protocol requires setting, before intervening, what size of change will be considered a real improvement and how many observations are needed to trust the result. That agreement is closed with stakeholders before touching the process, not after seeing the first results.

A case involving clinical laboratories seeking to increase the proportion of automatically verified results follows the same order: the goal and the starting point were set in the measurement phase, before redesigning the process. That order is what later allows one to say precisely how much progress was made, not just that "it improved."

This week's review: what did you automate without knowing how much it cost before?

This week it's worth reviewing every active automation in your company and asking a simple question for each one: is there a record of how much time this process took, how much it cost, and what error rate it had before it was automated? If the answer is no, that automation may be working perfectly well and still be indefensible against any serious question about its value.

This isn't about undoing what's already been implemented. It's about deciding, from now on, that no new automation moves forward without first recording the state of the process it will replace. That record is cheap compared to the cost of not being able to answer, six months from now, the question someone on the committee will surely ask.