Automation can make a bad process run faster.
That is useful only if the process itself should exist in its current form.
A team may ask to automate invoice approval because approvals take six days. The real problem may be that most invoices do not require approval, requests are repeatedly sent to the wrong manager, missing purchase-order numbers cause rework, or employees wait three days before opening a queue.
If those problems are not understood first, automation can preserve the waste.
Process mining is one way to discover how work actually moves through systems before deciding what to automate.
Actiknow’s custom application planning guidance recommends understanding the current workflow, people, approvals, information and systems before designing a new application. Process mining can provide evidence for that discovery when the workflow leaves reliable event data.
What Process Mining Does
Process mining reconstructs workflow behavior from event logs.
A useful event record typically identifies:
- case;
- activity;
- timestamp.
For example, a purchase request might have events:
- created;
- manager review;
- returned for correction;
- resubmitted;
- approved;
- purchase order issued.
Across thousands of cases, software can reconstruct common paths and variations.
This allows teams to see what actually happened rather than relying entirely on the documented process.
The Difference Between Process Map and Process Reality
A standard operating procedure may show:
Request → Review → Approval → Processing.
Real activity may look like:
Request → Review → Returned → Edited → Review → Escalated → Approval → Manual spreadsheet update → Processing.
Another group may skip the review.
Another may wait five days between steps.
Process mining exposes these variants.
That is valuable before automation because different problems need different solutions.
Bottlenecks
Measure waiting time between activities.
If processing itself takes ten minutes but requests wait two days for assignment, automating processing will barely change total cycle time.
Look for:
- long queues;
- specific teams;
- specific request types;
- specific days;
- approval thresholds;
- handoffs.
Automate where the delay is actually occurring.
Rework
Repeated steps are strong candidates for investigation.
Why are 30 percent of requests returned?
Possible causes:
- missing data;
- unclear form;
- incorrect routing;
- policy ambiguity;
- training;
- upstream system quality.
The best automation may be validation at submission rather than faster handling after the error.
Process Variants
Most organizations have more workflow variants than expected.
Some are legitimate.
A high-value purchase may require additional approval.
A customer complaint may follow a different path from a routine request.
Other variants are workarounds.
Process mining can quantify how often each path occurs.
Do not automatically force every case into one “happy path.” Understand why variants exist first.
Conformance
Compare observed behavior with the intended process.
Identify:
- skipped approvals;
- unexpected loops;
- activities in the wrong order;
- unauthorized paths;
- manual steps outside policy.
Conformance analysis is useful when the business has a clear expected workflow.
But deviation is not automatically bad. The documented process may be outdated.
Use deviations as investigation prompts.
Automation Candidate Scoring
Not every slow step should be automated.
Score candidates across:
- frequency;
- manual effort;
- rule clarity;
- error rate;
- business impact;
- technical feasibility;
- exception rate;
- change frequency.
High-frequency, rule-based, stable work is attractive.
Low-frequency work dominated by judgment may remain manual.
Actiknow’s article on AI in custom business applications makes a similar distinction between deterministic workflow and interpretive work. Use conventional automation for predictable rules and AI only where interpretation creates value.
Data Requirements
Process mining depends on event quality.
You need a stable case identifier.
You need meaningful activities.
You need timestamps.
Often you also need attributes such as department, amount, customer type or product to explain differences.
If the source systems do not capture these consistently, the mining result can be misleading.
Data Preparation
Raw application logs rarely arrive ready for analysis.
You may need to:
- join tables;
- map technical events to business activities;
- deduplicate;
- normalize timestamps;
- exclude test records;
- resolve case IDs;
- handle reopened cases.
Document these transformations.
Otherwise stakeholders may debate the process map because they do not trust how events were constructed.
Start With One Process
Do not attempt enterprise-wide process mining first.
Choose a workflow with:
- clear business owner;
- measurable pain;
- available event data;
- meaningful volume;
- real automation interest.
Examples:
- invoice processing;
- customer onboarding;
- service tickets;
- order fulfillment;
- claims;
- employee onboarding.
Prove the method and then expand.
Combine Data With Interviews
Event logs show what happened.
They do not always explain why.
Interview users after identifying patterns.
If requests repeatedly bounce between two teams, ask what information is missing.
If one region has much longer cycle time, understand policy or staffing differences.
Process mining should make discovery more evidence-based, not eliminate human context.
When Simpler Discovery Is Enough
Process mining is not necessary for every automation project.
If a five-person team follows a simple workflow and everyone agrees where the delay occurs, a workshop and time study may be enough.
Use simpler methods when:
- volume is low;
- systems do not contain useful events;
- workflow is short;
- problem is obvious;
- mining setup costs more than the likely benefit.
The objective is insight, not adoption of a tool category.
Actiknow’s guidance on whether a business needs custom software makes the same broader point: sometimes the answer is automation, integration, SaaS or process redesign rather than building a new application.
Measure Cycle Time Correctly
Separate processing time from waiting time.
A case may have 40 minutes of actual work across eight days.
Automation of the 40 minutes has a ceiling on total impact unless waiting is addressed.
Calculate:
- end-to-end cycle time;
- active processing time;
- queue time;
- rework time;
- handoff time.
This changes prioritization.
Segment the Process
Average cycle time can hide important patterns.
Segment by:
- business unit;
- region;
- request type;
- value;
- customer tier;
- channel;
- employee role;
- outcome.
A process may be healthy for 80 percent of cases and terrible for one high-value segment.
Automation should target the right population.
Find Manual Handoffs
Handoffs create delays and data-entry errors.
Look for places where information is:
- exported;
- emailed;
- copied;
- re-entered;
- uploaded;
- reconciled.
These are often good integration opportunities.
Actiknow’s custom solutions practice includes API integration and workflow automation. Process discovery helps determine which handoffs deserve that engineering effort.
Identify Shadow Systems
A formal workflow may move through ERP and CRM while employees maintain a spreadsheet between them.
The event log may show a mysterious two-day gap.
Interviews reveal the spreadsheet.
Process mining should therefore be combined with system inventory.
Automation architecture must include the actual process, not only official platforms.
Exceptions Matter
A process with 95 percent standard cases and 5 percent complex exceptions is ideal for selective automation.
Automate the standard path.
Route exceptions to people with context.
Do not force automation to handle every rare case before delivering value.
Design the exception queue explicitly.
What information will reviewers receive?
How does the case return to automation afterward?
Baseline Before Change
Capture baseline measures:
- volume;
- cycle time;
- rework rate;
- exception rate;
- manual touches;
- SLA breaches;
- error rate.
Without a baseline, the organization cannot prove the automation improved anything.
Avoid vanity measures such as “number of bots deployed.”
Measure business outcomes.
Prioritize Root Causes
For every bottleneck, ask why.
Slow approval could mean:
- approvers receive too many requests;
- threshold is too low;
- notifications are poor;
- requests lack information;
- approvers are on leave;
- system is difficult to use.
Each cause suggests a different intervention.
Automation is only one.
Redesign Before Automating
Remove unnecessary steps.
Combine duplicate reviews.
Clarify ownership.
Improve forms.
Standardize data.
Then automate the cleaner process.
This reduces implementation complexity and future maintenance.
Actiknow’s requirements guidance explicitly says a requested feature is not always the actual solution. A request for automated approval may be driven by delays, poor visibility or manual follow-up. That principle is central to process improvement.
Choose the Automation Mechanism
After discovery, choose technology according to the task.
Workflow engine for structured state transitions.
API integration for system-to-system exchange.
RPA when legacy interfaces have no practical API.
iPaaS for standard SaaS orchestration.
Custom application for unique workflows and user experience.
AI for interpretation of unstructured content.
Do not make process mining a funnel into one preferred automation technology.
Pilot the Highest-Value Path
Start with a bounded improvement.
For example:
- validate required fields before submission;
- auto-route standard requests;
- remove one duplicate approval;
- integrate two systems;
- automate reminders.
Measure the result.
Then expand.
This reduces risk and provides evidence for further investment.
Post-Automation Process Mining
Process mining is not only a pre-project tool.
After automation, compare the new process.
Did cycle time fall?
Did rework shift elsewhere?
Did users create a new workaround?
Did exceptions increase?
Did one team become the new bottleneck?
Continuous analysis can reveal unintended consequences.
Governance
Process data can expose employee behavior.
Use it responsibly.
The objective should be process improvement, not simplistic employee surveillance.
Limit access to appropriate users.
Interpret activity in business context.
A person appearing “slow” may be handling the hardest cases.
Communicate how the analysis will be used.
Build vs Buy for Process Mining
Large organizations may justify dedicated process-mining platforms.
Smaller organizations can often begin with event extraction, SQL, BI and targeted analysis.
The tool should match scale and recurring need.
Do not buy an enterprise platform before confirming the organization has useful event data and a process-improvement operating model.
A Practical 30-Day Discovery
- Week 1: Define process, owner, case ID and outcomes.
- Week 2: Extract and clean event data.
- Week 3: Analyze variants, bottlenecks, rework and segments.
- Week 4: Validate findings with users and prioritize interventions.
The output should be an improvement backlog, not merely a process diagram.
Questions to Ask Before Automation
- What outcome is slow or expensive?
- Where is time actually spent?
- How much is waiting?
- How much is rework?
- Which variants are legitimate?
- Which manual steps add no value?
- Which decisions are deterministic?
- Which require judgment?
- Which systems need integration?
- How will exceptions work?
- What baseline will prove improvement?
These questions are more important than “Which automation tool should we buy?”
Frequently Asked Questions
What is process mining?
It analyzes event data from business systems to reconstruct how cases actually move through a process.
Do we need process mining before every automation?
No. Simple workflows can often be understood through interviews and direct observation. Use process mining when volume, variants or uncertainty justify it.
What data is required?
At minimum, a case identifier, activity and timestamp. Additional attributes help explain differences.
Can process mining identify automation opportunities?
Yes, particularly repetitive steps, bottlenecks, rework and handoffs, but findings should be validated with business users.
Is a slow step always an automation candidate?
No. The root cause may be policy, missing information, workload or unnecessary approval.
Can process mining be used after automation?
Yes. Comparing before and after behavior can show whether cycle time, rework and exceptions actually improved.
Conclusion
Process mining is valuable when it helps the organization automate the right problem.
Use event data to identify bottlenecks, variants and rework. Add human context. Redesign unnecessary steps. Then choose the simplest technology that improves the measured outcome.
If you are evaluating a workflow for automation, Actiknow can help map the current process, identify integration and application gaps, and design a practical automation path. Discuss your process automation requirements with Actiknow.