Senthil Info

automating business processes, honestly

Mapping It First

The cheapest thing that improves an automation's odds is a week spent finding out what the process actually does. It requires no software, no vendor and no budget line, and it is skipped in most projects because it produces no artefact anyone wants to look at.

Documented against actual

Every process of any age has two versions. For a product-side reference related to workforce operations, Monitask also covers mouse jiggler detection software.

The documented one is what somebody wrote when the process was designed, or during an audit. It describes the intended path. For broader background and an independent point of comparison, see Deloitte Consulting.

The actual one contains the workarounds, the informal exceptions, the step added after an incident in 2019, the spreadsheet that lives on one person's desktop, and the thing everyone does when the system is slow.

Automation built from the documented version fails on contact with the actual one, and the failure looks technical. It is not — it is the same misplaced blame as everywhere else in this subject.

What to record

Six things. A page per process, not a diagram tool.

The trigger. What starts it, and in what form the input arrives.

Each step, with who does it and roughly how long. Rough is fine — the ratio between steps matters more than the absolute numbers.

Every decision point, and the rule applied. Where the rule cannot be written, mark it. Those marks are your judgement steps and they are what separates a real candidate from a false one.

Every exception people can name, with roughly how often. This is the list that matters most.

Every system touched, and whether it has an interface or is used through a screen.

And what happens when something goes wrong — who notices, how, and how long it takes.

Who to ask

The people doing the work, not their manager. The manager knows the documented version, which is the one they designed or inherited. The person doing it knows the exceptions.

Ask what breaks, not how it works. "How does this work" gets you the documented answer; "what goes wrong, and what do you do then" gets you the actual one.

Ask the newest person too. They still remember which parts were confusing, which is information everyone else has lost.

And ask before the design is fixed. After that the same conversation is an announcement, and the knowledge arrives as objections rather than as input. That is most of what change management means.

What you will find

Consistently, across processes.

The step nobody could explain. A check, a copy, an approval whose original reason has been forgotten. Sometimes it is load-bearing and sometimes it is residue from a system that no longer exists.

The exception nobody documented that turns out to be 20% of volume.

The spreadsheet. There is almost always a spreadsheet, it is not in any system diagram, and it is frequently where the actual logic lives.

And the process that should not exist. Reconciliations that exist because two systems do not talk, re-keying, checks added after a forgotten incident. Eliminating one of these beats automating it and is cheaper.

The output

Not a diagram. Four things:

A one-page step list with times.

The exception list, ranked by frequency, with a note on which are fixable upstream.

The judgement steps, marked.

And the measured straight-through rate — the tally sheet result, which replaces the assumption in every business case that follows.

That is enough to select a process, brief a vendor, and check any proposal that comes back. It also frequently ends the project early, which is the best possible return on a week.

Why it gets skipped

It has no deliverable anyone celebrates. A platform selection produces a decision document; mapping produces a page of awkward findings.

It delays the visible work. A week of asking questions looks like a week of not starting.

And nobody is selling it. Vendors quote builds. The mapping week appears in no proposal because it is not billable to anyone, which is exactly why it is the cheapest week in the project.

The short version