Process Mining vs Stakeholder Interviews: What Happens When the Data Disagrees With the People?
A manager tells you that purchase approvals normally take one day.
The process data says four.
Operations says Finance is causing the delay.
The event log shows most waiting time occurs before Finance even receives the case.
A team insists that every order is approved before it is raised.
The system contains hundreds of examples where the recorded purchase order appears before approval.
For a Business Analyst, this is where the interesting work begins.
The question is not simply:
Who is right? the stakeholder or the data?
A better question is:
What does each source know that the other cannot see?
Process mining and stakeholder interviews provide two very different views of a business process. One observes digitally recorded behaviour at scale. The other captures human knowledge, intention, context and experience. When the two disagree, the contradiction itself can become one of the most valuable pieces of evidence available to a Business Analyst.
What Process Mining Actually Sees
Traditional process discovery often starts by asking people how work gets done.. A Business Analyst might interview employees, run workshops, review procedures and create an AS-IS process map.
Process mining approaches the same problem differently.
Instead of beginning with what people say happens, process-mining tools analyse event data generated by systems such as ERP, CRM, ticketing and workflow platforms.
A typical event log might contain:
a case or transaction identifier
an activity
a timestamp
the system or user associated with the activity
With this information, the process-mining software can sequences of activities and identify patterns across millions of transactions.
It can reveal:
frequently occurring process paths
bottlenecks
waiting times
rework
repeated activities
process variations
skipped steps
unexpected sequences
deviations from the designed process
This creates a major advantage. Instead of interviewing five employees and trying to infer how the entire organisation operates, an analyst may be able to observe the recorded behaviour of 50,000 transactions.
But that does not mean process mining sees everything.
It sees what the systems recorded and that distinction matters.
What Stakeholder Interviews See That Data Does Not
Imagine a customer-service complaint follows this path:
Complaint received → employee calls supervisor → spreadsheet checked → supplier contacted → decision agreed verbally → CRM updated → ticket closed
The event log may contain only:
Ticket Opened → Ticket Closed
From the system's perspective, almost nothing happened between those two events.
From the employee's perspective, most of the work happened there.
Stakeholder interviews can uncover information that event logs often cannot capture:
why a particular decision was made
why employees use workarounds
why exceptions exist
what happened through telephone calls or meetings
which activities happen in Excel or offline
which policies influence behaviour
whether employees trust a system
whether a step exists only because of regulation or risk
what customers or staff experience during the process.
Process mining is therefore particularly strong at answering questions such as:
What happened?
When did it happen?
How frequently did it happen?
Where are cases slowing down?
Stakeholders are often better positioned to explain:
Why did it happen?
What was the intention?
Why was this exception necessary?
What happened outside the system?
For a Business Analyst, both perspectives are essential.
When the Data and the Stakeholder Disagree
Suppose you are analysing a procurement process.
The Procurement Manager tells you:
“A purchase order cannot be created before manager approval. The system doesn't allow it.”
Your process-mining analysis shows hundreds of cases where:
PO Created → Approval Recorded
At this point, a weak analysis would conclude:
The stakeholder is wrong.
A stronger Business Analyst treats the contradiction as a hypothesis to investigate.
Several explanations could exist.
Explanation 1: Approval happens outside the system: Managers may approve requests through email, Teams, telephone calls or meetings before the formal system approval is recorded.
Explanation 2: Emergency purchases use a different process: Urgent purchases may legitimately bypass standard sequencing.
Explanation 3: Different systems use different timestamps: The purchase-order timestamp may represent creation in one platform while approval is synchronised later from another.
Explanation 4: Employees discovered a workaround: Staff may have found a way around controls because the official process delays critical operations.
Explanation 5: The case definition is incorrect: Events may have been connected using the wrong identifier.
Explanation 6: The process changed: The dataset may contain historical cases from before a new approval rule was introduced.
Each explanation leads to a very different recommendation. That is why contradictions should not be viewed as analytical failures.
The Business Analyst's Role: Triangulation
So, the strongest approach is not:
Process Mining vs Stakeholder Interviews
It is:
Process Mining + Stakeholder Interviews + Supporting Evidence
This is triangulation.
A Business Analyst can combine:
process-mining results
stakeholder interviews
workshops
SOPs and policy documents
system configuration
observation
transaction samples
task-level analysis
data-quality checks
customer feedback
Each source answers a different part of the problem. A useful way to think about this is:
Process Mining tells us:
WHAT happened
WHEN it happened
HOW OFTEN it happened
WHERE deviations occur
Stakeholders help explain:
WHY it happened
WHAT CONTEXT influenced it
WHAT happened outside the system
Business Analysis determines:
SO WHAT?
WHAT SHOULD CHANGE?
That final step is where analytical insight becomes business value.
An Evidence–Context–Decision Framework
When process data and stakeholder testimony conflict, I would use the following framework.
1. Evidence
Start with the process data. Identify:
process variants
bottlenecks
waiting times
deviations
loops
rework
unusual sequences
Do not interpret the cause yet. Simply establish the observed pattern.
2. Context
Return to stakeholders with specific evidence.
Instead of saying:
“Your explanation was wrong.”
ask:
“We found that 14% of these transactions have the purchase order timestamp before recorded approval. What could explain those cases?”
This changes the discussion from confrontation to investigation.
Stakeholders may immediately recognise an emergency workflow, system issue or established workaround.
Validation
Before concluding that the business process is broken, validate the data by checking:
case identifiers
timestamp definitions
missing events
system scope
historical process changes
integration delays
whether manual activities exist
4. What is the root cause?
A deviation is not necessarily the root cause. Imagine process mining reveals frequent manual rework. The immediate temptation might be:
Automate the rework.
But further analysis reveals that customer information is frequently incomplete when cases enter the process. The real solution may be improving data capture at the beginning—not automating downstream corrections.
5. What should change?
Now translate findings into business recommendations.
Potential outcomes might include:
redesigning the process
changing business rules
automating an activity
removing an unnecessary approval
improving system integration
updating requirements
improving training
introducing new controls
redesigning data capture
The objective is not simply to create a more accurate process map.
It is to improve business outcomes.
6. Measuring Change
Process mining becomes particularly powerful when analysis does not stop after implementation.
The organisation can continue measuring:
cycle time
rework
process compliance
exception rates
automation rates
customer outcomes
The Business Analyst can therefore compare:
AS-IS performance → intervention → TO-BE performance
and determine whether the change created measurable value.
When Process Mining Can Produce the Wrong Story
Another important risk appears when analysts compare employee performance.
Imagine:
Employee A completes 35 cases per day.
Employee B completes 17.
A dashboard might make Employee B look less productive.
Stakeholder investigation reveals that:
Employee A handles standard cases.
Employee B handles highly complex enterprise accounts requiring regulatory checks and multiple approvals.
The process data captured transaction volume.
It did not adequately capture task complexity.
This demonstrates an important analytical principle:
A measurable difference is not automatically a meaningful difference.
Business Analysts must understand operational context before converting process metrics into conclusions.
Otherwise, process transparency can quickly become misleading performance surveillance.
Process Mining Is Also a Change-Management Problem
There is a human side to process mining that organisations cannot ignore.
Imagine telling employees:
“We are installing software that will show management exactly how every process is performed.”
Even if the actual objective is operational improvement, employees may interpret this as:
Management is monitoring me.
That perception can damage trust.
A Business Analyst involved in process-mining initiatives should therefore consider questions such as:
Why is the analysis being conducted?
How will employee-level information be used?
Who can access the data?
Will individuals be identified?
Are employees being evaluated or is the process being evaluated?
How will findings be communicated?
How will stakeholders participate in interpreting results?
Process improvement works better when employees are treated as sources of operational expertise rather than suspects being investigated.
The objective should be to understand why the system produces certain outcomes—not automatically to blame the people working inside it.
What Exactly Is a “Case”?
There is another problem increasingly relevant to modern process mining. Traditional process mining often assumes that a process can be represented as:
one case → sequence of activities
Real organisations are rarely that simple. Consider an order-to-cash environment. One customer creates:
3 orders
containing:
14 products
resulting in:
2 shipments
and:
4 invoices
What should the process-mining “case” be?
The customer?
The order?
The individual product?
The shipment?
The invoice?
Selecting the wrong case perspective can produce a process model that is technically consistent but operationally misleading. This is one reason object-centric process mining is becoming important.
Instead of forcing all activity into a single case sequence, object-centric approaches model relationships between multiple business objects such as:
Customer ↔ Order ↔ Item ↔ Shipment ↔ Invoice
This is particularly valuable for Business Analysts working with complex enterprise processes. It also provides another explanation for apparent stakeholder-data disagreements. Sometimes the stakeholder understands the business relationship correctly, while the process model has oversimplified it.
The Gap Is Often More Valuable Than Either Source
There is a tendency in modern analytics to assume that more data automatically creates better decisions. It does not.
Data without context can mislead. Context without evidence can also mislead. The Business Analyst's role sits between those two worlds. When stakeholder interviews and process-mining results agree, analysis is relatively straightforward.
When they disagree, something more interesting may be happening:
the process may have undocumented exceptions
the system may be missing manual work
stakeholders may misunderstand process frequency
employees may be relying on workarounds
timestamps may represent system activity rather than human activity
the official process may have diverged from operational reality
the analytical model itself may be wrong
That disagreement deserves investigation rather than immediate resolution.
Conclusion
Don't Choose Between Data and People. Investigate the Gap.
Process mining provides something traditional process analysis has often struggled to achieve: evidence of how large numbers of cases actually move through digital systems.Stakeholder interviews provide something event logs cannot: intent, explanation, business context and human experience.
One without the other creates blind spots. A process-mining dashboard may tell you that a transaction waited four days. A stakeholder may tell you that it was waiting for a customer document.
The analyst must determine whether that explanation is supported by evidence, whether the delay is avoidable and whether fixing it would create meaningful business value. The goal is therefore not to decide whether humans or systems are more trustworthy. It is to combine their evidence intelligently.
Stakeholders know the process they experience.
Systems know the process they record.
Business Analysts must determine the process the organisation actually operates.
And sometimes, the most valuable insight is found precisely where those three versions disagree.