Measuring the baseline before you automate anything at all

3 days ago
3 min read

Updated: 18 hours ago

Introduction

There is one step that separates automation projects that can be evaluated from those that cannot, and it takes about an hour. Before anything changes, write down how long the process currently takes, how often it goes wrong, and what it costs. Once the change is made, that information is gone permanently, and every subsequent argument about whether it worked becomes a matter of opinion.

The reason it is skipped is that it feels like delay. The tool is bought, everyone is keen, and spending a fortnight measuring the old way seems like an obstacle. It is the cheapest insurance available, and its absence is why so many businesses hold subscriptions they cannot justify and cannot cancel with confidence.

1. Measuring the baseline before you automate is a one-hour task

Not a project.

Three or four numbers, recorded honestly, over two or three weeks of normal operation. This is not a time-and-motion study and it does not need to be precise; it needs to exist.

2. Measure time, quality and cost together

One dimension is not enough.

How long it takes, how often it is wrong, and what it costs. Automation that halves the time and doubles the error rate is not an improvement, and a single-dimension baseline cannot show that.

3. Time the whole process, not the working part

Elapsed, not effort.

From request to completed, including the waiting. Most processes are mostly queue, and improving the working part of a process that is ninety per cent waiting produces almost nothing.

4. Count the exceptions and the rework

The part that predicts the outcome.

How often does the process go wrong, need correcting, or fall outside the normal path? This is the number that determines whether automation will help or simply move the problem into an exception queue.

5. Capture it during a normal period

Not the quietest week.

A baseline taken during a holiday period or a quiet month will make any subsequent comparison look bad or good for reasons unrelated to the change. Pick a representative period and note anything unusual about it.

6. Ask the people who do the work

They know things the numbers do not.

What the frustrating parts are, where the time goes, what they work around. This qualitative baseline is frequently more useful than the quantitative one, and it is equally impossible to reconstruct later.

7. Write it down where it will be found

Sounds trivial, matters enormously.

A dated note in a shared location with the method described. Baselines recorded in someone's notebook are unavailable at exactly the moment they are needed, which is twelve months later at renewal.

8. Use the same method for the after measurement

Comparability is the whole point.

Same definition, same period length, same source. A great deal of apparent improvement is a change in how the measurement was taken, and using the identical method removes that argument.

9. Expect the baseline itself to be useful

The unexpected benefit.

Measuring a process properly frequently reveals that the problem is not what everyone assumed, and that a change in sequence or a removed approval solves it without any tool. This happens often enough to be worth the hour on its own.

Be careful about baselining in a way that feels like surveillance. If people believe the measurement will be used to judge them, the numbers become fiction, so the purpose has to be stated and honoured.

Conclusion

Spend the hour before you change anything, because the information cannot be recovered afterwards.

Measure time, error rate and cost together rather than one alone, time the whole elapsed process including the waiting, count exceptions and rework because they predict whether automation will help, take the measurement during a representative period, record what the people doing the work say about it, write it down somewhere it will be found in a year, use the identical method for the after measurement, and expect the exercise itself to reveal a fix you had not considered.