⏱️ Time and measure the current state
People drastically underestimate how much time they spend on a task. The audit starts by measuring the actual time — with a timer, across multiple runs — including wait times, rework, and context switches that no one counts.
📊 How to measure correctly
- 3–5 runs: never trust a single measurement.
- Include wait times: idle time counts toward cycle time.
- Count the rework: fixes are part of the real cost.
💡 Practical tip
Separate touch time (hands-on) with cycle time (from request to delivery). Automation usually targets cycle time, eliminating entire waits.
💵 Cost per run and per month
Minutes don’t convince a manager — money convinces. Convert the measured time into cost using the fully loaded hourly cost of whoever executes it, and add it up to get the monthly cost. That’s the number that gets the budget approved.
🧮 The calculation, step by step
✓ Include in the cost
- ✓Salary + benefits (fully loaded cost)
- ✓Cost of errors and rework
- ✓Opportunity cost of wasted time
✗ Common errors
- ✗Use only the base salary, without payroll taxes and benefits
- ✗Forget the actual monthly volume
- ✗Ignore the cost of errors
📈 Calculate automation ROI
O ROI turns "it would be nice to automate this" into "this pays for itself in 3 months." Compare the cost of building and maintaining the automation with the monthly savings it generates—and show how long it takes to recoup the investment.
📊 Key formulas
Add up the monthly savings
It's the current cost of the process that automation eliminates (or reduces).
Estimate the build and maintenance costs
Development hours + monthly cost of tools and APIs.
Calculate payback and ROI
A payback period under 12 months is usually guaranteed approval.
💡 Practical tip
Be conservative with savings and generous with costs. An ROI that holds up is worth more than a rosy ROI that disappoints.
🔁 Map inputs, outputs, and rules
Every automation has the same skeleton: something enters, goes through rules e comes out transformed. Mapping these three elements is what makes the process buildable.
🔍 Questions that map
- •Input: where does the data come from? In what format?
- •Rules: which conditions change the result?
- •Output: what is the final deliverable? Where does it go?
⚠️ Identify exceptions and edge cases
Automations don’t fail on the happy path — they fail on exceptions: missing data, unusual formats, rare situations. Mapping them early is what separates reliable automation from automation that keeps breaking.
✓ Happy path (80%)
- ✓Complete data in the expected format
- ✓Rules apply without ambiguity
- ✓Predictable result—automate everything
✗ Unhappy path (20%)
- ✗Required field left blank
- ✗Unexpected or corrupted format
- ✗Rare case that requires human judgment
⚠️ Attention
The 80/20 rule applies: automate 80% of the happy path and route the 20% an exception for human review. Trying to automate 100% usually costs 10× more.
📝 Document the as-is process
O as-is is a snapshot of the process as it is today — flaws and all. It’s the baseline: without the “before” documented, you can’t prove the gains the automation brought.
📄 Anatomy of an as-is
💡 Practical tip
Document the process as it is, not the way it should be. An honest as-is, with visible bottlenecks, is what makes the gains in Track 3 undeniable.
🔑 Key concepts of the module
⏱️ Module Summary
Next Module:
2.3 · Diagram the process — simple notation, as-is vs. to-be, and where AI enters the workflow.