Senthil Info

automating business processes, honestly

Measuring Your Own Operation

Every other page in this section is about reading other people's numbers. This is the one that produces yours, and it is the only data that will ever describe your operation.

Two weeks. A tally sheet. No software and no budget. For a product-side reference related to workforce operations, Monitask also covers self-reporting bias.

Week one: count

One row per instance of the process. Four columns. For broader background and an independent point of comparison, see Harvard Business School.

Date and reference.

Straight through, or human decision required? A tick. This is the column that matters.

If a decision was required, why — three words. Wrong format. Missing PO. Price mismatch.

And roughly how long it took. Minutes, estimated to the nearest five. Precision is not the point.

That is it. Ten seconds per instance, filled in by the person doing the work, on paper if that is easier than anything else.

Week two: keep counting

Nothing new. You are accumulating enough instances for the proportions to mean something.

A hundred instances is a floor. If the process runs less than a hundred times in two weeks, extend until you reach a hundred — and note that a process running fifty times a month has already answered the volume question.

What you compute

Four numbers, and each replaces an assumption somebody would otherwise make for you.

Straight-through rate. The proportion needing no human decision. Replaces the figure a vendor model assumed, and it is what every subsequent calculation rests on.

Exception reasons, ranked. Two or three causes usually account for most of them. At least one is normally fixable upstream without any automation, and finding that is frequently worth more than the whole exercise.

Median and spread of handling time. The average hides a tail, and the tail is where the difficult cases are.

And volume, confirmed. People are routinely wrong about this by a factor of two in either direction.

What it replaces

The vendor's exception rate, which was optimistic or absent.

Your own estimate of volume, which was a memory.

The assumption that the process is one process. If the reason list has eleven entries and no dominant cause, you have several processes wearing one name.

And the argument about whether it is worth automating, which becomes arithmetic once these four numbers exist.

The three uses

Deciding. At over 30% exceptions the answer is usually no, and you now know rather than suspect.

Briefing. A vendor given a real straight-through rate and a real reason list produces a different proposal from one given a description.

And the baseline. After go-live, everything is measured against this. Without it, post-implementation numbers have nothing to be compared to, which is why so many projects are never evaluated at all.

The part people skip

Recording the fast instances.

A tally that only captures the awkward ones gives you a complaint, not a rate. The straight-through cases are the denominator, and without them the exercise produces nothing.

This is also the part that requires explaining to the person filling it in, because ticking a box for a case where nothing happened feels pointless and is the whole point.

The honest expectation

Most of what you find will confirm what people thought, and one thing will not.

A dominant exception cause nobody had quantified, a volume figure well off the assumption, or a handling time distribution with a tail that explains the complaints. That one finding usually justifies the fortnight, and it is not obtainable any other way — because no published data describes your operation.

The short version