Short answer: use process evidence to locate delay, rework and variation, then investigate the cause before proposing automation. Automating a broken path can make defects faster and less visible.
Image disclosure: this AI-generated editorial illustration depicts automated process-data collection; it is not a process-mining product interface.
Frame the business outcome
Define the process boundary, customer or operational outcome, start and end events, population and decision owner. “Automate finance” is too broad; “reduce invoice receipt-to-posting time without increasing duplicate payments” is testable.
Choose an observation period that captures seasonality, exceptions and different teams. A quiet week can make a fragile process look consistent.
Build a trustworthy event log
Microsoft documents case ID, activity name and timestamps as core process-mining fields. Add resource, channel, amount, product, location and outcome when lawful and useful. Normalize activities without erasing meaningful differences.
Check missing events, timestamp zones, duplicate cases, changed activity names and system migrations. Event logs show recorded system behavior, not every phone call, spreadsheet or workaround. Combine them with interviews and direct observation.
Read variation before ranking candidates
Examine dominant paths, long waits, loops, handoffs, rework, abandoned cases and outcome differences. A slow step may be necessary review; a fast step may create later defects. Separate processing time from waiting time.
Classify causes: missing data, unclear policy, capacity, system latency, approval design, interface friction or genuine repetitive execution. Automation addresses only some causes.
Score suitability and consequence
| Dimension | Useful question |
|---|---|
| Frequency | Does the work occur often enough to matter? |
| Stability | Are inputs and rules sufficiently consistent? |
| Data readiness | Are required fields reliable and accessible? |
| Consequence | What happens when the automation is wrong? |
| Recoverability | Can actions be reversed or compensated? |
| Ownership | Who maintains rules and handles exceptions? |
Estimate build, integration, monitoring, exception handling and change costs. Do not equate hours avoided with layoffs or guaranteed cash savings. Capacity may be redeployed rather than removed.
Pilot with a control group
Select a bounded population and define baseline metrics. Compare cycle time, error, rework, exception age, customer impact and staff effort. Include failure injection and a manual fallback. Stop or narrow the pilot if downstream quality worsens.
Revisit the process map after implementation. Automation changes behavior and may move the bottleneck elsewhere.
Use the Software ROI Calculator for assumptions and the Automation Tool Selector only after the process and control requirements are clear.
Decision rule
Prioritize a candidate when the outcome matters, evidence shows a repeatable constraint, data is adequate and failures can be contained. Fix policy and data problems before automating their symptoms.
References
- Microsoft Learn: Prepare processes and event data, accessed August 30, 2026.
- Microsoft Learn: Prepare processes and recordings, accessed August 30, 2026.
- Microsoft Learn: Process mining tutorial, accessed August 30, 2026.