Most automation backlogs are built on opinion. A department head nominates the process that annoys them most, a workshop produces sticky notes describing how work is supposed to flow, and a team automates that version. Months later the automation runs, but the exceptions it was never designed for pile up in a queue, and nobody can say with confidence how much value was delivered. With AI agents now entering automation programs, the cost of this guesswork rises: agents are more expensive to run than bots, and an agent acting on a misunderstood process makes mistakes faster.
Process intelligence, the combination of process mining, continuous monitoring and decision support, offers a better starting point: reconstruct how work actually flows from the event data your systems already record, and choose what to automate based on evidence. In 2025 and 2026 the field has shifted toward object-centric process mining (OCPM), which reflects how real business processes interconnect, and toward tighter links between mining, orchestration and agents. This playbook explains how to use these techniques to build an automation backlog you can defend.
Why Process Intelligence Comes Before Agents
Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. One of its central recommendations was to redesign workflows rather than layer agents onto existing ones. Analyst Kai Waehner makes the same point in his 2026 process intelligence landscape: embedding AI into a process designed around human limitations risks automating inefficiencies at machine speed, and process redesign should use mining evidence first.
Process mining answers questions that workshops cannot:
- How many variants of the process actually occur, and which ones account for most volume?
- Where does work wait, loop back or get reworked, and for how long?
- Which steps bypass controls, and how often?
- Which exceptions are frequent enough to justify automation, and which are rare enough to leave to people?
- After an automation goes live, did cycle time, rework and cost actually improve?
Expectations of the discipline are also shifting toward measurable economics. The Deloitte Global Process Mining Survey 2025, as reported by PEX Network, found that 59% of respondents expect cost savings from process mining, up from 46% in 2021, while 38% cite identifying automation opportunities as a goal.
What Object-Centric Process Mining Changes
Classic process mining assumes every event belongs to exactly one case, such as one purchase order. Real processes do not work that way. A single sales order may produce several deliveries; one delivery may combine items from several orders; one invoice may cover multiple deliveries; and a payment may settle several invoices. Forcing this into a single case notion leads to two well-known distortions: events duplicated across cases, which inflate counts, and relationships lost between cases, which hide the real causes of delay.
Object-centric process mining instead models processes as events that touch multiple related objects. The OCEL 2.0 standard (Object-Centric Event Log) formalizes this. According to the standard’s documentation, every event is an execution of an activity with a timestamp and links to at least one object; objects belong to types and can have attributes that change over time; objects can be related directly to each other; and both event-to-object and object-to-object relationships can carry qualifiers describing roles. That lets a single log capture an order-to-cash or procure-to-pay process across all its interacting entities.
Practitioners quoted by PEX Network describe OCPM as moving from “the future” into actual adoption. Waehner’s landscape adds a buyer’s caution: many vendors deliver OCPM on proprietary internal models, so the ability to export OCEL 2.0 is the practical test of portability and lock-in.
Automate the process you have measured, not the process you have described. Object-centric event data shows where work truly waits, loops and breaks, and that is where automation and agents earn their keep.
The Playbook: From Event Data to Automation Backlog
Step 1: Frame the Business Question
Start with a value question, not a tool. Examples: Why does order-to-cash take longer for our largest customers? Why are a large share of supplier invoices blocked? Why do customer service cases reopen? Agree on the outcome metrics, such as cycle time, touchless rate, days sales outstanding or rework rate, and on the process scope.
Step 2: Identify Objects and Sources
List the business objects involved (for example, sales orders, order items, deliveries, invoices, payments, customers) and the systems where their events are recorded: ERP, CRM, warehouse management, ticketing, email and collaboration tools. Map how objects relate. This object model is the backbone of the analysis and is reusable across many future questions.
Step 3: Extract and Build the Event Log
Extract change and transaction tables from source systems and transform them into an object-centric event log, ideally in or exportable to OCEL 2.0. Typical work includes resolving timestamps and time zones, mapping technical status changes to meaningful activities, linking objects through document flow tables and handling deleted or archived records. Build this as a governed, repeatable data pipeline in your data platform rather than a one-off extract, so the log can be refreshed continuously.
Step 4: Discover and Validate
Generate process maps per object type and across types. Validate with people who do the work: the goal is not to prove them wrong but to confirm the data reflects reality and to understand why variants exist. Many apparent inefficiencies have legitimate reasons, such as regulatory checks; others reveal workarounds nobody documented.
Step 5: Diagnose Root Causes
Quantify waiting time between activities, rework loops, control bypasses and variant frequency. Use object relationships to trace causes across process boundaries: a late payment may originate in a partial delivery several steps earlier. Break down results by attributes such as customer segment, plant, supplier or product line to find where problems concentrate.
Step 6: Classify Opportunities by Remedy
Not every problem calls for automation. Classify each finding by the remedy it needs:
- Policy or process redesign: remove unnecessary approvals, change thresholds, fix master data.
- System configuration or integration: replace manual re-keying with an API or fix a broken interface.
- Rules-based automation: deterministic, high-volume steps suited to workflow rules or RPA.
- AI agent: exceptions that require reading unstructured information, gathering context from several systems and choosing among options under policy.
- Human focus: rare, high-impact or sensitive cases where better information and prioritization help more than automation.
Step 7: Size Value and Rank
For each opportunity, estimate affected volume from the event log, time or cost per case, expected improvement and implementation effort. For agent candidates, include model and platform run costs per case and the cost of human review for escalated cases. Rank by net value and risk. Because every estimate is grounded in measured volumes, the backlog becomes defensible to finance.
Step 8: Monitor Continuously
Once changes go live, keep the event log refreshing and track the same metrics. Process intelligence becomes the feedback loop: it shows whether an automation reduced cycle time, whether an agent’s escalation rate is falling, and whether new variants are emerging that the automation does not handle. Waehner’s framework adds a decision gate, which checks automated actions and AI recommendations against business rules and confidence thresholds, so mining insight, orchestration and control work together rather than in silos.
Choosing Agent Candidates With Evidence
Event data makes it possible to apply clear criteria to proposed agent use cases. Good candidates usually show:
- High exception volume concentrated in a few exception types, rather than a long tail of unique cases.
- Long waiting time caused by information gathering rather than by decisions requiring authority.
- Unstructured inputs such as emails, PDFs or free-text notes that rules and bots cannot handle.
- Clear policies for resolution that can be written as boundaries and thresholds.
- Contained, reversible risk, so that agent errors can be caught and corrected.
Poor candidates show the opposite: low volume, unclear policy, decisions that hinge on authority or relationships, or irreversible consequences such as large payments or regulatory filings.
A Worked Example: Order-to-Cash Delays
Consider a generic industrial distributor whose finance team believes payment delays come from slow customers. An object-centric analysis tells a different story.
- The team builds an event log with sales orders, order items, deliveries, invoices and payments, linked through the ERP’s document flow, plus customer service tickets from the CRM.
- Discovery shows that a significant share of orders are split into multiple deliveries because of stock shortages at the primary warehouse. Each partial delivery triggers a separate invoice.
- Object relationships reveal that customers frequently dispute invoices for partial deliveries because they do not match their purchase orders. Disputed invoices wait for a credit or rebill, and the related tickets show customer service gathering delivery proofs manually from the warehouse system.
- The remedies are classified: a policy change to consolidate invoicing for partial deliveries for key customers; an integration fix to share delivery confirmations automatically; and an AI agent to handle remaining disputes by reading the customer’s email, assembling delivery proofs and order history, and proposing a resolution within credit limits.
- Value is sized from measured volumes. The policy change and integration fix address most of the delay at low cost; the agent handles the residual disputes, with resolutions above a threshold routed to a credit controller.
- Continuous monitoring tracks dispute rate, days sales outstanding and agent escalation rate, and flags when a new pattern, such as a new customer segment, appears.
Without object-centric analysis, the company might have deployed a collections agent to chase customers harder, automating the wrong problem. With it, the largest gains came from policy and integration, and the agent was targeted where it genuinely added value.
Tooling and Architecture Choices
The process intelligence market is consolidating and converging with orchestration. Waehner cites examples such as Celonis acquiring Ikigai Labs and Salesforce folding Apromore into Agentforce. When choosing tools, consider:
- Openness: support for standards such as OCEL 2.0, XES, BPMN and DMN, and the ability to export models and data.
- Data location: whether analysis runs on data in place in your lakehouse or warehouse, or requires copying data into a vendor cloud.
- Connectivity: extractors for your ERP, CRM and ticketing systems, and support for event streaming for near-real-time monitoring.
- Integration with orchestration and agents: whether insights can trigger actions and whether agents can query process context, increasingly through open protocols such as MCP.
- Commercial independence: exposure to price changes or forced migrations after acquisitions.
Many enterprises will pair an agnostic mining capability built on their data platform with the orchestration engine of their main automation vendor, or the reverse. Building the object-centric event log in your own data platform keeps that choice open.
Pitfalls to Avoid
- Starting with the tool instead of the question. Dashboards without a value question rarely lead to action.
- Underestimating data preparation. Extraction and event modeling are usually the largest effort. Plan for it and build it as a reusable pipeline.
- Using the analysis to blame people. Present findings as process issues, or the teams you need will stop cooperating.
- Forcing single-case views on multi-object processes. This distorts counts and hides causes; use object-centric modeling where entities interact.
- Stopping after discovery. The value comes from remedies and continuous monitoring, not from a one-time process map.
- Ignoring privacy. Event logs can contain personal data about employees and customers. Apply minimization, pseudonymization and access controls, and involve works councils or privacy officers where required.
Outlook and Conclusion
Process intelligence is becoming the evidence and control layer for automation. Expect object-centric modeling to become the default, event logs to refresh continuously from streaming data, and agents to consult process context before acting and to report their actions back into the same event data. As vendors consolidate, open standards and data kept in your own platform will be the main protection against lock-in.
The organizations that get the most from agents and bots in the coming years will not be those that automate the most processes. They will be the ones that know, from data, which processes to change, which to automate, which to hand to agents and which to leave with people, and that keep measuring after go-live. Starting with process intelligence is the most reliable way to join them.
How Hanoi Technology Can Help
Hanoi Technology builds object-centric event logs, process intelligence dashboards and evidence-based automation backlogs, delivered as projects, dedicated teams or managed services.