Process Mining for AI Opportunities: Find the Workflows Worth Automating Before Spending a Dollar

Process mining for AI opportunities starts with an uncomfortable observation: most enterprise AI pilots were chosen in a room. Someone drew a 2×2 matrix on a whiteboard, senior leaders debated which workflows sounded exciting, and three months later a team is building something the system logs never asked for. The data already knew which processes were painful, repetitive, and ripe for automation. Nobody looked.

Process mining — practiced by tools like Celonis, Apromore, Disco, and IBM Process Mining — extracts event logs from systems of record (SAP, Oracle, ServiceNow, Salesforce, Jira) and reconstructs every actual path your processes take^[5]. Not the SOP from 2019. Not the BPMN diagram the consultant drew. The literal sequence of timestamped events from your production systems. What comes out 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 for this category is growing fast. Process mining software is projected to grow from roughly $850M in 2026 toward $2B by 2031, with Celonis claiming 60% market share and consistently landing as the category leader in analyst assessments^[1]. But most adoption is still RPA-flavored — using mining to find rule-based automation candidates. The LLM-era question is different: which mined workflows are good candidates for language model automation versus which ones need rule execution versus which ones aren't worth automating at all?

Workshop-driven AI use case selection fails predictably, and it fails for the same three reasons across industries.

The loudest voice wins. Every executive prioritization session has someone senior enough to override the analysis. They've seen a vendor demo, they have a pet project, or they just find the idea of "AI for contract review" more exciting than "AI for invoice routing." The team builds the interesting idea, not the high-ROI one.

Nobody wants to admit which workflow is actually painful. Ask a room of VPs which process is the most broken and they'll describe a process in someone else's department. The order-to-cash exception handling that costs the finance team 40 hours a week never comes up because the finance VP doesn't want to air dirty laundry in front of the CIO. Process mining surfaces the pain from system data — not from organizational politics.

The interesting idea always beats the measurable one. "AI for customer sentiment analysis" sounds innovative. "AI to reduce the 8% exception rate in supplier onboarding" sounds unglamorous. Both can have identical ROI. The second one has a cleaner feedback loop, less hallucination risk, and a more straightforward success metric. Workshop groups consistently pick the first one. Mining-based approaches let the bottleneck data make the initial ranking before any human applies preferences.

If your background is ML, not BPM, here's 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. Process mining tools ingest those logs and run clustering and graph algorithms over the case sequences to reconstruct a process graph.

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

Process mining tools also compute conformance checking (how often the actual process matches the intended one), bottleneck analysis (which steps accumulate wait time), and root cause attribution (which attributes correlate with slow cases). This gives you, for every workflow in your organization's event log, a quantified profile: how big it is, how slow it is, how variable it is, and what's causing the pain. That profile is the input to an AI suitability scoring model — not a whiteboard session.^[5]

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

Volume measures 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 sufficient throughput, no automation investment pays back. Score it: 1 = under 1,000 cases/year, 3 = 10,000–50,000 cases/year, 5 = 100,000+ cases/year.

Variance is the LLM's competitive advantage over RPA. RPA breaks on variance — every new path through a process requires a new rule. The standard rule of thumb is that a process with more than 10–15 variants is a poor RPA candidate. LLMs handle variance differently: they read the case, interpret the context, and apply judgment to the anomaly rather than failing on it. A high-variant process (scoring 4–5 on this axis) is exactly where you want a language model, not a bot. Score it: 1 = 1-3 variants (pure RPA territory), 3 = 10-20 variants (borderline), 5 = 30+ variants (LLM territory).

Structure measures input parsability. A fully structured workflow — all inputs are database fields, all decisions are rule-based — doesn't need an LLM. RPA or a deterministic rule engine handles it more cheaply. When inputs include unstructured text (emails, PDFs, free-form comments, contracts), audio, or require contextual judgment (is this expense claim within policy?), the calculus flips. Score it: 1 = fully structured inputs and rule-based decisions, 3 = mixed structured and unstructured, 5 = primarily unstructured inputs or judgment-required decisions.

The scoring model produces a ranked list. High-scoring workflows (above 40 out of 125) are genuine AI candidates — high enough volume to justify investment, high enough variance that RPA will fail, unstructured enough that LLMs outperform rule engines. Mid-range workflows (15–40) warrant a tool-selection conversation: some are clean RPA candidates, some need better data before they're automatable, some belong on a roadmap for later. Low-scoring workflows below 15 are usually best left alone — the ROI ceiling doesn't justify the build cost.

The pipeline isn't complicated, but the sequencing matters. Organizations that skip straight to AI suitability scoring without first running variant analysis and bottleneck profiling end up scoring the wrong attributes — what they assumed about the process 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 workflows. ServiceNow surfaces IT and HR processes. Salesforce covers sales and customer success workflows. Jira and similar tools capture engineering and operations processes. The practical constraint is usually connector availability — Celonis has hundreds of pre-built extractors; Apromore and open-source tools require more manual ETL work. Start with the two systems that cover your highest-volume operational workflows, not the ones that are easiest to connect.

Step 2: Variant analysis. Once the log is loaded, the mining tool constructs every distinct case sequence and ranks them by frequency. This is the moment of truth. The variant map tells you whether what you thought was a single workflow is actually six workflows under one name. High-variant processes (30+) immediately flag 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 3 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 for the longest aggregate hours across the year. This is different from cycle time. A step that takes 2 minutes per case but processes 100,000 cases per year at 60% yield is a massive bottleneck even though individual cases move quickly through it. Automate the bottleneck, not the step that's technically interesting. The ROI calculation is straightforward: hours accumulated × average hourly cost × fraction automatable.

Step 4: AI suitability overlay. Apply the Volume × Variance × Structure scoring model to the top 20 bottlenecks by accumulated wait time. This produces your ranked candidate list. Anything scoring above 40 is worth a pre-mortem conversation. Anything above 70 is worth a funded pilot.

Step 5: Pre-mortem and commit. Before committing to the top 3 candidates, run a structured pre-mortem against each one (covered in the next section). The candidates that survive the pre-mortem become your committed pilots. The ones that don't go back into the pipeline for a future cycle.

The process mining software market is dominated by Celonis, which claims roughly 60% market share and consistently leads analyst rankings^[1][4]. But market leadership doesn't mean best fit for your stack. The honest assessment depends on three questions: what are your primary source systems, how much technical capacity do you have for setup, and what's your budget horizon?

The enterprise space consolidated significantly in 2021 when SAP acquired Signavio, UiPath acquired ProcessGold, and IBM acquired myInvenio — all within months of each other. That consolidation was a signal: hyperscalers recognized that process discovery was a strategic moat for their automation suites^[2]. The consequence is that your choice of 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 actually automate it. These are different questions, and conflating them is how teams spend six months building pilots that never deploy.

The pre-mortem has five blockers to check. Data access: does your team have the permissions and API access to the systems involved, or will you spend three months waiting for InfoSec approvals? Change management: who owns this process today, and are they a sponsor or a blocker? Audit and regulatory: does this workflow have compliance constraints that require human sign-off at specific steps, and have you confirmed with legal that automation is permissible? Integration cost: what is the actual API work to connect the upstream source and downstream action systems, and does it fit in your pilot budget? Ownership dispute: does this workflow span multiple departments, and is there a clear single owner for the automation program? If two departments share ownership, the pilot will stall in cross-team approval loops.

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

Task mining fills this 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]. Tools like UiPath Process Mining's task capture module, Celonis Task Mining, and Microsoft Power Automate Process Mining all offer desktop recording modes. The output is similar to process mining: a variant map of how analysts actually execute screen-level tasks, with frequency and duration data.

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

The question your organization keeps asking — "which workflows should we automate with AI?" — has a data answer. It's sitting in your SAP tables, your ServiceNow event log, your Salesforce activity history. The workflows that are genuinely worth building are the ones with high volume, high variance, and unstructured inputs: the cases where an LLM's ability to read context and handle exceptions outperforms any rule engine you could build. Process mining gives you the ranked list. The Volume × Variance × Structure score gives you the tool-selection logic. The pre-mortem tells you which ones you can actually ship. None of this requires a workshop.

Stop building AI use cases out of opinion. Your event logs already know which workflows are painful, repetitive, and ripe for automation. Mine them, score them, run the pre-mortem, then pick. The team that builds the wrong thing confidently is still building the wrong thing — and the logs have been trying to tell you that from the start.