Process & task mining for process improvement and automation discovery

Companies run order-to-cash, procure-to-pay or hire-to-retire on ERP and CRM systems, yet rarely know how cases really flow: how many variants exist, where work waits, how often it is redone. Process mining rebuilds the real process from system event logs, task mining adds what people do on their desktops, and AI layers (prediction, LLM copilots, agent context) turn the picture into ranked improvement and automation actions with measurable impact.

Problem & value

• Today: process documentation (BPMN workshops, interviews) describes the intended process, not the actual one. Improvement projects start from anecdotes; automation (RPA, agents) is chosen by loudest stakeholder rather than evidence. Rework, manual touches and waiting time stay invisible.
• AI value: (1) objective as-is model from data, (2) automatic detection of bottlenecks, loops and policy deviations, (3) prediction of late or failing cases while they are still running, (4) a quantified list of automation candidates, (5) an LLM copilot so process owners ask "why are 12 % of orders blocked?" without writing queries, (6) a live process model as context for AI agents and a yardstick for their effect after go-live.
• Evidence of market maturity: Gartner now covers the space as the Magic Quadrant for Process Intelligence Platforms (5 May 2026, successor of the Process Mining Platforms quadrant); the abstract lists 13 vendors including ARIS, Celonis, SAP Signavio, Microsoft, UiPath, ServiceNow and Pegasystems [1]. Vendor-reported savings figures exist but are marketing claims; measure your own baseline.

Variants

• Order-to-cash / procure-to-pay: the classic entry point; reasons for blocked orders, price or quantity changes, late payments, maverick buying, three-way-match failures (related: DOC-001, DATA-015).
• Hire-to-retire / HR processes: onboarding lead time, approval loops. Case data is about employees: see the regulation section (works council, profiling).
• Production-order and logistics mining: MES/WMS logs show waiting, rework and routing deviations on the shop floor and in warehouses.
• Object-centric process mining: one event refers to several objects (order, item, delivery, invoice) using the OCEL 2.0 standard [2]; avoids the distortion of forcing everything into one case ID.
• Task mining: desktop recordings reveal manual steps between systems, the main source of RPA/agent candidates (AGENT-003).
• Predictive process monitoring: next activity, remaining time, outcome (see PRED-024).
• Public sector / SMB: public bodies mine case-handling (permits, benefits); SMBs start with a single ERP or ticketing export and open-source tools.

How it works

1. source systems (ERP, CRM, ticketing, MES; desktop agent for task mining)
2. extraction & event-log building (case/object IDs, activity, timestamp; pseudonymise users)
3. process discovery (variants, directly-follows graphs / Petri nets)
4. conformance checking vs. reference model and business rules
5. performance & root-cause analysis (bottlenecks, rework, ML on case attributes)
6. prediction (delay / outcome) + LLM copilot for questions and explanations
7. opportunity ranking (automation potential, cost, volume)
8. actions: workflow/RPA/agent build, process redesign, alerts; re-measure after go-live

• Key AI components: classical discovery and conformance algorithms stay deterministic; ML is used for outcome/delay prediction on tabular case features and for root-cause attribution; LLMs translate questions to process-query languages (PQL, SQL), summarise variants, label task-mining steps and draft automation specifications; embeddings/clustering group similar desktop activity into tasks.
• Agent context: the process model is exposed to agents, for example via MCP or API, so an agent knows the normal path, current queue state and exceptions; a before/after comparison on the same event log shows whether the agent actually reduced cycle time or rework.
• Human-in-the-loop: analysts validate the event-log mapping (the most error-prone step), confirm that discovered deviations are real rather than data artefacts, and approve every change to the live process. Works council and data-protection officer approve scope for any task mining.

Data preparation

The raw material is event data: case ID, activity and timestamp per process step. It lives in the ERP (orders, invoices, goods receipts), CRM, ticketing tools and, for task mining, on employee desktops. Typical SMB gaps: ERP changelogs that record only the last change instead of every step, timestamps that carry only a date, case IDs that differ between systems, manual work in Excel, mail and on paper that leaves no trace, and unclear access rights to change tables.

Preparation steps: (1) pick one process (for example purchase-to-pay) and define the case notion; (2) extract tables via standard connectors or exports (see PREP-005); (3) build the event log, harmonise activity names and time zones, remove test and duplicate records; (4) pseudonymise user IDs before analysis (PREP-022) and agree on role-level instead of person-level views; (5) validate the log with the process owner against known reality. Offline steps (paper, phone) can be added through simple digital capture (PREP-008). Rule of thumb: 50 to 70 percent of the project effort goes into extraction and cleaning, especially for the first process; later processes reuse the connectors. Check readiness with GUIDE-003 and the data inventory in PREP-001.

Implementation paths

Which path for whom

• SMB: Path A, because mature SaaS and ERP-bundled process-mining tools exist at moderate prices; limit it to event-log mining of standard ERP processes and skip desktop task mining.
• Enterprise: Path A, because process mining is a commodity function with established vendors and ERP-native connectors (SAP, Oracle, Dynamics).
• Developer: Path C, because open-source libraries such as PM4Py and OCEL tooling run on modest hardware and give full control over extraction and models.
• Public sector: Path C, because sovereignty, procurement rules and staff-council requirements favour self-hosted or sovereign-cloud operation of employee-related event data.

Path A — Buy (recommended for most SMBs and enterprises)

• Process intelligence platforms: Celonis (DE, EU), SAP Signavio (DE, EU), ARIS / Software GmbH (DE, EU), plus Microsoft Process Mining (Power Automate), UiPath Process Mining and Task Mining, ServiceNow, Pega, IBM, Apromore (Salesforce), iGrafx, QPR (FI, EU), mpmX (DE, EU), Appian [1].
• Task mining: typically part of the same suites (Celonis, Signavio, UiPath, Microsoft); check on-device masking of personal data and screenshot blurring.
• Choose A when: SAP/Oracle-centred landscape with standard connectors, no in-house data-science capacity, need for governance and sharing across business units. Ask for EU hosting, subprocessor list, retention controls and the ability to pseudonymise user IDs at extraction.

Path B — Build on cloud APIs

• Extract event logs into a lakehouse (Snowflake, Databricks, BigQuery, EU regions), run discovery with PM4Py [3], and add an LLM layer (Claude, Gemini, GPT, Mistral in EU regions) for text-to-query, variant summaries and root-cause narratives. Orchestrate with dbt/Airflow; use structured outputs.
• Choose B when: a data platform and engineers already exist, logs come from non-standard systems, or you want mining embedded in an internal product.

Path C — Self-host (open source)

• Tools: PM4Py (Python, incl. OCEL support), ProM, Apromore community edition, Disco is commercial but desktop-only; OCEL 2.0 as exchange format [2]. Open-weight LLMs (Qwen, Llama, Mistral families) via vLLM or Ollama for the text-to-query copilot.
• Hardware: discovery runs on a CPU server (HW1); an LLM copilot with a ~8–30B model needs HW2.
• Effort: log extraction and data modelling dominate; expect most of the time there, not in algorithms.

Path D — Custom training

Train outcome/delay predictors (gradient boosting, sequence models) on your own cases when generic platform models underperform; a few thousand completed cases with outcome labels are usually the minimum. Fine-tuning an LLM for PQL/SQL generation is rarely worth it versus schema-aware prompting.

State of the art (2026)

• Category shift: "process mining" has become "process intelligence": mining plus modelling, simulation, AI copilots and agent orchestration in one platform [1].
• Object-centric mining (OCEL 2.0) is supported by the leading platforms and by PM4Py [2][3], replacing the single-case-ID view for O2C/P2P where one order has many deliveries and invoices.
• LLM copilots answer process questions in natural language and generate queries; accuracy depends on a clean semantic layer (see DATA-001).
• Agents and processes: process models serve as grounding and as monitoring for agents (AGENT-002, AGENT-013); measuring agent impact on the same KPIs is the new selling point.
• Limits: results are only as good as the event log (missing timestamps, batch-posted dates, rework recorded as new cases); activities done outside the system (phone, email) are invisible; LLM explanations can state plausible but unsupported causes, so tie every claim to a filter on real cases; task mining on screenshots is privacy-heavy and often legally restricted.

Shared resources & combinations

• Same stack: tabular-ml and time-series pipelines with PRED-024 (predictive monitoring), text-to-query with DATA-001, data quality checks from DATA-008 on event logs.
• Downstream automation: AGENT-002 (workflow automation), AGENT-003 (computer-use/legacy UI), AGENT-013 (multi-agent processes) execute what mining identifies.
• Detection: ANOM-006 flags ledger anomalies; mining adds control-flow deviations (skipped approvals).
• User-behaviour analytics on web/app front ends: DATA-026 is the customer-facing analogue.

Effort, cost & KPIs

• Path A: 6–12 weeks to the first insight on one process with standard connectors; licences usually priced by data volume or user, plus integration services.
• Path B/C: 2–6 months; cost driven by log extraction, data modelling and domain expertise.
• KPIs: end-to-end cycle time, share of cases on the happy path, rework rate, touchless/automation rate, conformance rate, on-time delivery or payment, realised savings per implemented action, and for agents: before/after change on the same measures.

People & change

Start with management (goal: improvement, not surveillance) and the process owner, who defines scope and validates findings. Involve IT and the data owners for extraction, the DPO early (personal data in user IDs and timestamps; a DPIA is likely, especially for task mining) and the works council before any data is collected. Works council: yes where a council exists. Event logs and desktop recordings are objectively suited to monitor behaviour and performance, so §87(1) no. 6 BetrVG applies; §90(1) no. 3 requires early information about AI-supported work design, and §80(3) allows an external expert. Public sector: staff council. A works agreement should set purpose limitation, role-level aggregation, no individual performance ranking, retention periods and no use for disciplinary action (see GUIDE-004).

Communicate openly which data is captured and why; let employees see their own data and flag wrong process variants, which also improves quality. Choose a pilot group from a volunteering team, run it for a limited time and measure process KPIs only. Typical fear: "this measures me". Address it with aggregation, transparency and works-agreement guarantees. Humans decide on every change; the tool only proposes. Support staff with short literacy sessions (GUIDE-006, AI Act Art. 4 support duty) and a change plan (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: depends. Mining of business processes is typically minimal risk. It becomes high-risk (Annex III point 4, employment and worker management) if outputs are used to allocate tasks, monitor or evaluate individual employees' performance. Art. 5: emotion inference from employees at work is prohibited; do not combine task mining with such features. AI literacy (Art. 4) applies [4].
• GDPR: event logs and especially task-mining data contain employee personal data (user IDs, window titles, screenshots, timing). Needs a legal basis, purpose limitation, data minimisation, a DPIA for task mining, pseudonymisation at source and short retention [5]. Analyse processes, not people: aggregate by role or team, hide individual-level drill-down.
• Labour law (Germany): a works council has co-determination rights over technical systems able to monitor performance or behaviour (§ 87(1) no. 6 BetrVG); agree a works agreement before starting.
• Other risks: wrong conclusions from poor logs, productivity-surveillance perception, sensitive data in screenshots (health, bank). Mitigations: on-device masking, application allow-lists, no individual scoring, human review of findings, documented purpose.

Getting started

1. Pick one process with measurable pain (e.g. P2P or O2C) and agree KPIs and baseline.
2. Clear data protection first: DPO, DPIA, works council agreement, pseudonymised user IDs.
3. Extract one event log (case ID, activity, timestamp) and validate it with process owners.
4. Run discovery plus conformance on 6–12 months of data; shortlist bottlenecks and automation candidates.
5. Implement the top 2–3 actions (rule fix, workflow, agent) and re-measure on the same log.

Sources

1. Gartner — Magic Quadrant for Process Intelligence Platforms (May 2026), abstract — https://www.gartner.com/doc/7810417
2. OCEL 2.0 object-centric event log standard — https://www.ocel-standard.org/
3. PM4Py process mining library — https://github.com/process-intelligence-solutions/pm4py
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Pega — Gartner process intelligence 2026 page — https://www.pega.com/gartner-process-intelligence-2026
7. Celonis documentation — https://docs.celonis.com/
8. Microsoft Process Mining (Power Automate) — https://learn.microsoft.com/power-automate/process-mining-overview