Process Mining for AI Opportunities: Stop Picking Workflows in a Conference Room

Most enterprise AI pilots were chosen in a conference room. Someone drew a 2×2 on a whiteboard, the senior voice picked the workflow that sounded exciting, and three months later a team is shipping something the system logs never asked for. The data already knew which processes were painful, repetitive, and worth automating. Nobody pulled it.

Process mining — Celonis, Apromore, Disco, IBM Process Mining — extracts event logs from the systems that actually run your business (SAP, Oracle, ServiceNow, Salesforce, Jira) and reconstructs every path your processes take^[5]. Not the SOP from 2019. Not the BPMN diagram a consultant drew. The literal sequence of timestamped events your production systems emit. The output is a ranked list of workflows by volume, cycle time, bottleneck severity, and variant count — the raw material for an evidence-based AI use case pipeline.

The market is moving fast. Process mining software is projected to grow from roughly $850M in 2026 toward $2B by 2031^[7], with Celonis claiming 60% market share and holding category leader status across analyst assessments^[1]. The Deloitte Global Process Mining Survey 2025 found that 48% of organizations have reached company-wide adoption — up from 45% in 2021 — and 74% plan to integrate AI into their mining programs^[9]. Most adoption is still RPA-flavored. The LLM-era question is sharper: which mined workflows justify a language model, which want rule execution, and which are not worth touching at all?

One contrarian point worth stating directly: process mining will not fix your AI selection problem if your executives refuse to act on unglamorous findings. One logistics company ran a full Celonis deployment, surfaced accounts payable exception handling as the highest-ROI candidate, and ignored it because the CFO wanted to do AI for customer experience. The data is only as useful as the decision-making culture that absorbs it.

Workshop-driven selection fails predictably. The same three structural failures show up across industries.

The loudest voice wins. Every prioritization session has someone senior enough to override the analysis. They watched a vendor demo, they have a pet project, they find AI for contract review more interesting than AI for invoice routing. The team builds the interesting idea, not the high-ROI one. The incentive points at narrative, not throughput.

Nobody admits which workflow is actually painful. Ask a room of VPs which process is most broken and they describe a process in someone else's department. The order-to-cash exception handling that costs the finance team forty hours a week never surfaces because the finance VP will not air dirty laundry in front of the CIO. Mining surfaces the pain from system data. Politics has no vote.

The interesting idea beats the measurable one. AI for customer sentiment sounds innovative. AI to reduce the eight percent exception rate in supplier onboarding sounds unglamorous. ROI can be identical. The second one has a cleaner feedback loop, less hallucination surface, and a sharper success metric. Workshop groups pick the first one anyway. Mining-based selection lets the bottleneck data set the initial ranking before any human applies preferences.

The Deloitte 2025 survey identified management support as a barrier in 41% of organizations — up from 26% in 2021^[9]. That gap is not random. Mining programs surface unglamorous, politically charged findings, and organizations without C-suite sponsors shelve them.

If your background is ML rather than BPM, here is what process mining actually does. Every enterprise system of record — SAP, Oracle, ServiceNow, Salesforce, Jira — emits an event log: a timestamped record of which case (invoice, ticket, contract, employee record) hit which step, when, and in what sequence. Mining tools ingest those logs and run clustering and graph algorithms over the case sequences to reconstruct a process graph.

Every event log needs exactly three mandatory fields^[10]: a case identifier (the invoice number, ticket ID, or contract ID that groups all events belonging to one process instance), an activity name (the step label — 'Invoice Created', 'Sent for Approval', 'Exception Raised'), and a timestamp (when that activity occurred, in any parseable datetime format). Everything else — resource, cost, originating department — is optional enrichment. If your system has those three columns, you have the minimum viable event log.

The output is not a theoretical BPMN diagram. It is a map of every distinct path actually taken, annotated with frequency and duration. A workflow your SOP claims has two paths might have forty-seven variants in reality — each deviation a data quality issue, an edge case someone built a workaround for, or a policy exception that became the default. Variant count is one of the most diagnostic signals in the entire analysis. It tells you whether you have a stable process (low variants, safe for RPA) or a judgment-intensive one (high variants, candidate for an LLM).

Mining tools also compute conformance (how often the actual process matches the intended one), bottleneck attribution (which steps accumulate wait time), and root cause attribution (which case attributes correlate with slow cases). For every workflow in your event log, you get a quantified profile: volume, cycle time, variability, bottleneck location. That profile is the input to an AI suitability scoring model. The whiteboard is not.^[5]

The data preparation barrier is real but consistently overstated. Most teams assume they need a dedicated ETL pipeline before they can start mining. For a proof-of-concept sprint, you need a SQL query and a CSV export.

Take a purchase order workflow in a typical ERP. The PO_EVENTS table has a PO_NUMBER (case ID), a STATUS column (activity), and a CHANGED_AT timestamp. That is all you need to build an event log good enough to run your first variant analysis.

If you need to go further — applying Python to do lightweight variant analysis before committing to a full tool deployment — the pm4py library (the open-source Python process mining framework maintained by Fraunhofer) reads XES and CSV directly and produces variant statistics with about fifteen lines of code.

Traditional process mining is case-centric: every event belongs to exactly one process instance. In a purchase order workflow, the case ID is the PO number, and every event — creation, approval, goods receipt, invoice match — attaches to that case. This works cleanly when a process has one primary object.

Most enterprise processes do not. An order-to-cash process involves a sales order, multiple delivery notes, one or more invoices, and potentially a customer dispute — all linked, all evolving in parallel. Forcing these into a single case ID produces convergence issues (one event appears to affect multiple cases) and divergence issues (one case fans out into multiple parallel objects). The resulting process graph is distorted.

Object-centric process mining (OCPM), standardized through the OCEL 2.0 format, solves this by letting events reference multiple objects simultaneously. A "Goods Receipt" event can link to both the purchase order and the supplier delivery note without duplicating the event. The OCEL 2.0 standard (SQLite, XML, and JSON exchange formats) adds object-to-object relationships on top of event-to-object relationships, enabling analysis of how objects interact across a process — not just how individual cases progress through steps.

For AI use case discovery, OCPM matters most in these scenarios: procure-to-pay (PO, invoice, payment), order-to-cash (order, delivery, invoice, payment), and HR onboarding (employee record, system provisioning tickets, training completions). When the workflow you are trying to automate spans two or more interacting objects, case-centric mining will systematically underestimate the variant count and misattribute bottlenecks. Check whether your mining tool supports OCEL 2.0 before signing the contract if multi-object processes are on your candidate list.

Once the mined process data exists, you need a scoring model that turns it into a ranked candidate list. The AI Suitability Score is a three-axis product: Volume × Variance × Structure. Score each axis 1–5, multiply, and every workflow in your inventory gets a comparable number on a 125-point ceiling.

Volume measures the ROI ceiling. A workflow that processes 50,000 cases per year at 25 minutes per case represents 20,000+ hours of annual labor. A workflow that runs 50 times a year is a rounding error. Volume is the non-negotiable axis — without throughput, no automation pays back. Score it: 1 = under 1,000 cases/year, 3 = 10,000–50,000, 5 = 100,000+.

Variance is where LLMs eat RPA's lunch. RPA breaks on variance — every new path through a process needs a new rule. Research confirms LLMs outperform standard methods on task grouping and labeling in process-mining-to-RPA workflows, achieving average NMI scores of 0.75 using GPT-4 on task clustering^[13]. A high-variant process (score 4–5) is exactly where you want a language model. Score it: 1 = 1–3 variants (pure RPA), 3 = 10–20 (borderline), 5 = 30+ (LLM territory).

Structure measures input parsability. A fully structured workflow — every input a database field, every decision rule-based — does not need an LLM. RPA or a deterministic rule engine handles it cheaper. When inputs include unstructured text (emails, PDFs, free-form comments, contracts), audio, or contextual judgment (is this expense within policy?), the calculus flips. Score it: 1 = fully structured, 3 = mixed, 5 = primarily unstructured or judgment-required.

The model produces a ranked list. Workflows above 40 are real AI candidates. Workflows between 15 and 40 are tool-selection conversations: some are clean RPA, some need better data first, some belong on the future roadmap. Workflows under 15 are usually best left alone.

The pipeline is not complicated. The sequencing is the leverage point. Teams that skip straight to AI suitability scoring before running variant analysis and bottleneck profiling end up scoring assumptions rather than what the log data shows.

Step 1: Source system selection. Not every system of record produces clean event logs. SAP and Oracle are the richest sources for finance and procurement. ServiceNow surfaces IT and HR. Salesforce covers sales and customer success. Jira and similar tools capture engineering and operations. The practical constraint is connector availability — Celonis ships hundreds of pre-built extractors; Apromore and open-source tools require manual ETL. Start with the two systems covering your highest-volume workflows, not the ones easiest to connect.

Step 2: Variant analysis. Once the log is loaded, the mining tool reconstructs every distinct case sequence and ranks by frequency. This is the moment of truth. The variant map tells you whether what you thought was a single workflow is six workflows under one name. High-variant processes (30+) flag immediately as LLM territory. Low-variant, high-frequency processes are clean RPA candidates. Processes with high variant counts but low frequency might be worth decomposing — the top three variants might be automatable even if the long tail is messy.

Step 3: Bottleneck identification. The mining tool shows where cases accumulate wait time — which step holds cases the longest in aggregate hours across the year. This is not the same as cycle time. A step that takes two minutes per case but processes 100,000 cases per year at 60% yield is a massive bottleneck even though individual cases move fast. Automate the bottleneck, not the step that is technically interesting. The ROI calculation is straightforward: hours accumulated × hourly cost × fraction automatable.

Step 4: AI suitability overlay. Apply Volume × Variance × Structure to the top twenty bottlenecks by accumulated wait time. That produces your ranked candidate list. Anything above 40 earns a pre-mortem. Anything above 70 earns a funded pilot.

Step 5: Pre-mortem and commit. Before committing to the top three, run a structured pre-mortem against each candidate. The candidates that survive become committed pilots. The ones that do not go back into the pipeline for the next cycle.

The process mining market is dominated by Celonis — roughly 60% market share, top of analyst rankings^[1][4]. Market leadership is not the same as fit for your stack. The honest assessment turns on three questions: what are your primary source systems, how much technical capacity do you have for setup, and what is your budget horizon?

The enterprise space consolidated hard in 2021. SAP acquired Signavio. UiPath acquired ProcessGold. IBM acquired myInvenio. All within months. That was a signal — hyperscalers recognized process discovery as a strategic moat for their automation suites^[2]. The consequence: choosing a mining tool is now partly a bet on your broader vendor ecosystem.

The AI Suitability Score tells you whether a workflow is technically worth automating. The pre-mortem tells you whether your organization can ship it. Different questions. Conflating them is how teams burn six months building pilots that never deploy.

Five blockers, every time. Data access: does your team have the permissions and API access for the systems involved, or are you about to spend three months waiting on InfoSec? Change management: who owns this process today, and are they a sponsor or a blocker? Audit and regulatory: does the workflow carry compliance constraints that mandate human sign-off at specific steps, and has legal confirmed automation is permissible? Integration cost: what is the actual API work to wire the upstream source and downstream action systems, and does it fit your pilot budget? Ownership dispute: does this workflow span multiple departments, and is there a single accountable owner for the automation? If two departments share ownership, the pilot stalls in cross-team approval loops every time.

The 2025 Deloitte survey underscores this: management support is cited as a barrier by 41% of organizations — the single most common obstacle to value realization, ahead of data quality and technical complexity^[9]. The pre-mortem is where you surface that barrier before it surfaces during the build.

Process mining works on system-of-record event logs. A significant share of enterprise work happens on surfaces that emit nothing structured: Excel spreadsheets, email threads, browser-based internal tools, legacy desktop applications. When an analyst exports an ERP table into a spreadsheet, reconciles it against a PDF invoice, pastes the result into a web form, and emails the approver — none of those steps appear in your SAP event log. They are invisible to process mining.

Task mining fills the gap by recording screen activity (keystrokes, mouse movements, application context) and using computer vision and NLP — increasingly LLM-based — to reconstruct the actual task sequence^[3]. UiPath Process Mining's task capture, Celonis Task Mining, and Microsoft Power Automate Process Mining all offer desktop recording. The output looks similar to process mining: a variant map of how analysts actually execute screen-level tasks, annotated with frequency and duration.

The practical constraint is consent and privacy. Screen recording requires explicit employee consent and disciplined data governance — especially in regulated industries. Setup overhead is higher than connector-based mining. Data quality depends on recording duration and coverage. For knowledge worker workflows with high strategic value but no system-of-record footprint, task mining is the right tool. For everything with clean event logs, stay in traditional process mining.

The question your organization keeps asking — which workflows should we automate with AI — has a data answer. It is sitting in your SAP tables, your ServiceNow event log, your Salesforce activity history. The workflows worth building share a profile: high volume, high variance, unstructured inputs. Cases where an LLM's ability to read context and handle exceptions outperforms any rule engine you could write. Mining gives you the ranked list. Volume × Variance × Structure gives you the tooling verdict. The pre-mortem tells you which ones you can actually ship. None of this requires a workshop.

Shipping the wrong thing confidently is still shipping the wrong thing. Your event logs have been saying so the whole time.