Your ERP data and your workflow reality are not the same thing
ERP systems are the canonical record of what happened in a business. When a purchase order is created, approved, fulfilled, and invoiced, the ERP records the transaction states and timestamps. When a project is opened, staffed, billed, and closed, those milestones appear in the ERP. The data is accurate, auditable, and detailed.
It is also significantly incomplete for the purpose of understanding how work actually moved through your organisation. That incompleteness is not a failure of ERP design; it is a consequence of what ERPs are built to do. Understanding the distinction matters if you are trying to make automation decisions from your existing data.
What ERP data captures
An ERP records state transitions that occur within the ERP system. When you approve a purchase order in the system, that approval is timestamped. When you receive goods and mark them received, that is timestamped. When the invoice is matched and posted, timestamped. This is structured, reliable event data and it is the foundation of most process mining analyses.
What the ERP does not capture is what happened between those system events. Between "purchase order submitted" and "purchase order approved," there may have been two emails asking for additional information, one phone call to clarify a cost centre, and a three-day delay while a manager was travelling. The ERP records the start and end timestamps of the approval step. It does not record what happened in between, because all of that activity happened outside the system.
This is the ERP visibility gap. It is the gap between what the system recorded and what actually occurred. For most operations processes in mid-size organisations, a substantial portion of the work happens outside the ERP: in email, in Slack, in spreadsheets, in meetings, in other specialised tools. The ERP captures the formal handoffs but not the informal coordination, the rework, the parallel check that someone runs in a separate system, or the informal escalation that moved a stuck item forward.
How this gap affects automation decisions
Automation decisions based purely on ERP data will consistently underestimate process complexity and mislabel the source of cycle time.
Consider a procure-to-pay process. The ERP shows: purchase order created, approved two days later, goods received five days after that, invoice matched and paid four days later. Total recorded cycle time: eleven days. An automation analysis based on this data would focus on the gaps between ERP events: why does approval take two days, why does matching take four days?
But if you also pull the email and collaboration data, you might see that approval took two calendar days because the approver received the request at 4pm Friday and responded Monday morning, making the actual decision time about twenty minutes. And matching took four days not because of a process problem but because the vendor sent the invoice to an incorrect email address and the accounts payable team did not know to look for it until a colleague forwarded it after three days. The process, as measured by the ERP, took eleven days. The actual delays were caused by calendar timing and a misdirected email, neither of which appears in the ERP data.
An automation built to reduce the two-day approval time would address the wrong problem. The right fix is an automated invoice receipt confirmation that alerts the AP team immediately if a matched invoice does not arrive within 24 hours of goods receipt. That solution comes from workflow data, not ERP data.
What workflow event data adds
Workflow event data, drawn from across the full stack of systems a process touches, captures what happens between ERP events. This includes collaboration tool activity (Slack messages related to a specific transaction, email threads about a specific invoice), task management activity (tickets opened, assigned, reassigned, and closed in relation to a process step), and activity in specialised tools that feed into or depend on the ERP (a contract management system, a vendor portal, a project delivery tool).
When you layer this data over the ERP event log, you can reconstruct much more of the actual process. You can see not just that an approval took two days but that the approver was messaged at 4pm Friday, did not respond until Monday, and the first response was a request for clarification that the requestor answered in two hours. You can see not just that invoice matching took four days but that it involved three email threads, one of which included a correction to the invoice amount that required re-submission.
This reconstruction is what process mining tools built on top of ERP data attempt to do with ERP events alone. The limitation is that ERP events are the terminal points of activities, not the activities themselves. Workflow event data from collaboration and task management tools fills in the activity between those terminal points.
A practical example: accounts payable
A growing infrastructure services company was analysing its accounts payable process in 2025 as part of an automation planning exercise. The ERP showed an average invoice-to-payment cycle of 22 days against a target of 15. The team assumed the problem was in the three-step approval process, which the ERP data showed averaging 8 days of the total 22.
When workflow data from the email system and a shared vendor inbox was added to the analysis, the picture changed. The 8-day approval step broke down as follows: 1.5 days from invoice receipt to first-level review, 3 days waiting for a coding decision from the project manager responsible for the relevant cost centre, and 3.5 days for second-level approval. The 3-day wait for the project manager was the primary driver, and it was caused by a single structural issue: project managers received invoice routing notifications by email alongside 80 to 120 other emails per day and had no specific workflow to handle them.
The fix was targeted: a dedicated AP approval workflow that separated invoice routing from general email, with a 24-hour escalation trigger. The ERP-only analysis would have led to a broader and more expensive automation effort targeting the approval process overall. The multi-system workflow analysis pointed to a specific, low-cost fix with a directly measurable impact.
This is not a criticism of ERP data
ERP data is essential. It is the most reliable, structured, auditable source of process information in most organisations. The point is not that ERP data is insufficient; it is that ERP data answers specific questions well (what was the formal status of this transaction at each milestone?) and does not answer other questions (what was happening between milestones, and why?). Automation decisions require both types of answers.
The organisations that get the most accurate picture of their processes, and therefore the most defensible automation business cases, are the ones that combine ERP event data with workflow data from the broader tool stack. That combination is now more accessible than it has ever been, which is part of why the gap between ERP-based process analysis and workflow reality-based process analysis is becoming a decision-quality differentiator rather than just a theoretical distinction.