Discover and automate business processes. Covers process mining tools, task mining, RPA platform selection, automation opportunity assessment, and measuring automation ROI.
Enterprise processes span systems, teams, and time. Process Mining & RPA in Enterprise is the practice of discovering, analyzing, and automating business workflows—across ERP, CRM, HR, and supply chain systems—by extracting event data from transactional systems and using it to drive intelligent automation. It matters when organizations face inconsistent execution, manual handoffs, and visibility gaps in end-to-end processes like order-to-cash, procure-to-pay, or onboarding. The goal is to move from "what we do" to "how we really do it," then from "how we do it" to "how we should do it."
Enterprise systems generate event data—each transaction, status change, or approval is a record. To uncover actual process flows, extract and structure this data into a unified event log. The core input is a table with at least three columns: caseId, activity, and timestamp. The caseId groups related events into a process instance (e.g., a sales order, a purchase requisition). The activity column contains the performed action (e.g., "Approved by Finance", "Shipped to Customer"), and timestamp records when the action occurred.
To build this log, query transactional databases using standard SQL. For example, to extract procurement events from an ERP database:
SELECT
pr.RequisitionId AS caseId,
CASE
WHEN pr.Status = 'Created' THEN 'Requisition Created'
WHEN pr.Status = 'Approved' THEN 'Requisition Approved'
WHEN pr.Status = 'PO Generated' THEN 'Purchase Order Created'
WHEN pr.Status = 'Goods Received' THEN 'Goods Received'
WHEN pr.Status = 'Invoice Received' THEN 'Invoice Received'
END AS activity,
pr.CreatedOn AS timestamp
FROM Procurement.Requisitions pr
WHERE pr.CreatedOn >= '2023-01-01'
ORDER BY pr.CreatedOn;This yields a flat list of events. For process mining, the log must be normalized: all activity values must be consistent (e.g., "PO Created" and "Purchase Order Created" are treated as the same). Missing caseId values result in fragmented cases; timestamps with incorrect time zones cause misaligned process flows. The most common failure is using caseId values that are not globally unique across systems—e.g., RequisitionId from one module but POId from another—leading to disjointed process instances.
Use csv as the standard format for event logs. Include optional columns: resource (who performed the action), cost, duration, and attributes (JSON or semicolon-separated key-value pairs). Tools like Process Mining Software (e.g., Disco, ProM, Celonis) consume these logs and generate process graphs, showing actual paths, bottlenecks, and deviations.
Once an event log is available, analyze process execution to identify inefficiencies. The most common analysis is process conformance checking: comparing actual process execution (from the event log) against a reference model (e.g., BPMN diagram or workflow specification). Deviations appear as paths not in the model (e.g., a purchase requisition skipped the "Budget Approval" step), or as missing steps (e.g., "Invoice Received" without "PO Created").
To extract conformance metrics, compute the process instance trace—a sequence of activity values, ordered by timestamp, per caseId. Then, align this trace with a reference process model. A common failure is assuming that the order of activities in the event log is sufficient, but not accounting for parallel paths or concurrent activities.
Use the elapsed time between the first and last activity in a case to detect bottlenecks. For example:
WITH case_durations AS (
SELECT
caseId,
MIN(timestamp) AS start_time,
MAX(timestamp) AS end_time,
EXTRACT(EPOCH FROM (MAX(timestamp) - MIN(timestamp))) / 3600 AS duration_hours
FROM event_log
GROUP BY caseId
)
SELECT
AVG(duration_hours) AS avg_duration,
PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY duration_hours) AS p90_duration
FROM case_durations;This reveals that 90% of procurement processes take less than 48 hours, but the average is 72 hours, indicating a small number of long-running cases. These outliers often stem from manual interventions or missing approvals.
To diagnose root causes, join event logs with resource data. For example, to find which team is responsible for delays:
SELECT
e.resource,
COUNT(*) AS case_count,
AVG(EXTRACT(EPOCH FROM (e.end_time - e.start_time))) AS avg_time_seconds
FROM event_log e
JOIN ProcessResources pr ON e.resource = pr.employee_id
WHERE pr.department = 'Finance'
GROUP BY e.resource;A common failure is misclassifying resource values: using employee names in one system but IDs in another, leading to inconsistent resource assignments. The timestamp resolution must be at least one second; coarse-grained timestamps (e.g., rounded to minutes) hide timing details and cause incorrect sequence alignment.
Robotic Process Automation (RPA) executes workflows across multiple systems using software robots. A robot reads data from an ERP, performs actions in a CRM, and updates a shared database—all without human intervention. The automation is triggered by a process orchestration engine, which manages the flow and state of each instance.
Define a process automation using a task graph—a sequence of actions, each with a unique taskId, name, description, input, output, and executionContext. The execution context includes the current caseId, currentStep, variables, and lastError. Each task executes a script or a command.
For example, a task to create a sales invoice in an ERP system:
{
"taskId": "create-sales-invoice",
"name": "Create Sales Invoice from Order",
"description": "Generate invoice from completed sales order",
"input": {
"salesOrderNumber": "SO-2023-00123",
"invoiceDate": "2023-10-15"
},
"output": {
"invoiceNumber": "INV-2023-00456",
"status": "Generated",
"generatedOn": "2023-10-15T14:30:00Z"
},
"executionContext": {
"caseId": "SO-2023-00123",
"currentStep": "invoice-generation",
"variables": {
"currency": "USD",
"paymentTerms": "Net 30"
},
"lastError": null
}
}The orchestration engine executes this task by calling a REST API endpoint:
POST /api/v1/tasks/create-sales-invoice
Content-Type: application/json
{
"input": {
"salesOrderNumber": "SO-2023-00123",
"invoiceDate": "2023-10-15"
},
"context": {
"caseId": "SO-2023-00123",
"currentStep": "invoice-generation"
}
}The response includes the taskId and status. The engine polls the task until completion or failure.
A common failure is state drift: the task state is not persisted across retries. If a robot crashes during an invoice creation, the next run might start from the beginning instead of resuming from the last known step. To avoid this, use a checkpoint mechanism: after each significant step, the robot writes the current state to a database.
Each task should log its execution using structured JSON:
{
"taskId": "create-sales-invoice-98273",
"caseId": "SO-2023-00123",
"step": "invoice-generation",
"timestamp": "2023-10-15T14:30:15Z",
"level": "info",
"message": "Invoice created successfully",
"data": {
"invoiceNumber": "INV-2023-00456",
"totalAmount": 2495.50,
"currency": "USD"
}
}Logs are stored in a centralized logging system (e.g., Elasticsearch or a time-series database) and indexed by caseId and taskId. This enables real-time monitoring and debugging.
The true power of Process Mining & RPA lies in feedback loops: use mined processes to improve automation, and use automation to refine process models.
After running an RPA workflow for a month, collect event logs from the automation system. Each task execution becomes an event. The caseId is the workflow instance ID. The activity is the task name. The timestamp is when the task started or completed.
Use these logs to update the process model. For example, after analyzing the order-to-cash process, you discover that 35% of cases skip the "Credit Check" step. The RPA system is then updated to enforce credit checks for high-value orders.
To synchronize process mining and RPA, define a process execution lifecycle:
The transition between states is managed by a process engine that tracks the state of each case. The engine stores state in a database:
CREATE TABLE process_cases (
caseId VARCHAR(50) PRIMARY KEY,
processModelId VARCHAR(50),
currentState VARCHAR(50),
lastUpdated TIMESTAMP WITH TIME ZONE,
metadata JSONB
);When a new event arrives, the engine updates the currentState and logs the transition. A common failure is state inconsistency: the process engine thinks a case is in "Invoice Generated" state, but the RPA system has already started the "Send Invoice" task. This leads to duplicate or missed actions.
To resolve this, implement event-driven state updates using a message queue (e.g., Kafka or RabbitMQ). Each task completion publishes an event:
{
"eventId": "evt-0012345",
"eventType": "task.completed",
"caseId": "SO-2023-00123",
"taskId": "create-sales-invoice",
"timestamp": "2023-10-15T14:30:15Z",
"payload": {
"invoiceNumber": "INV-2023-00456",
"status": "Generated"
}
}A consumer service listens to the queue and updates the process_cases table. This decouples the RPA system from the process engine and allows independent scaling.
Failures in process mining and RPA are often silent and cumulative. The most common failure is event log corruption: missing, duplicate, or out-of-order events. For example, an invoice creation task is recorded twice, once in the ERP and once in the RPA system, leading to double counting.
To detect this, use event deduplication based on caseId, activity, and timestamp. A simple check is to compute the event sequence number:
WITH ranked_events AS (
SELECT
caseId,
activity,
timestamp,
ROW_NUMBER() OVER (PARTITION BY caseId ORDER BY timestamp) AS seq_num
FROM event_log
),
duplicates AS (
SELECT
e1.caseId,
e1.activity,
e1.timestamp,
e2.timestamp AS duplicate_timestamp,
e1.seq_num,
e2.seq_num AS duplicate_seq
FROM event_log e1
JOIN event_log e2 ON e1.caseId = e2.caseId
WHERE e1.timestamp < e2.timestamp
AND e1.activity = e2.activity
AND e1.seq_num = e2.seq_num - 1
AND e2.timestamp - e1.timestamp < INTERVAL '30 seconds'
)
SELECT * FROM duplicates;This identifies events that are likely duplicates. The process engine should automatically flag these and trigger a reconciliation task.
Another failure is missing event data. A task in the RPA workflow completes but no event is recorded. This often happens when the robot fails to call the event recording endpoint, or when the network is down. To detect this, set up health checks for the event recording API:
GET /api/v1/events/healthA successful response returns {"status": "ok", "lastHeartbeat": "2023-10-15T14:35:00Z"}. The process engine monitors this endpoint every 5 minutes. If a heartbeat is missing, it raises an alert.
For high reliability, implement event replay: when an event log is corrupted, replay the event stream from a known checkpoint. The RPA system can reprocess cases from the beginning, ensuring consistency.
To maintain process quality, establish process governance. Define process KPIs such as:
These KPIs are computed periodically and stored in a process performance dashboard, updated every 15 minutes. The dashboard includes:
The dashboard is consumed by both engineers and business analysts. Engineers use it to debug automation issues; analysts use it to identify training needs or process redesign opportunities.
Finally, version control for process models is critical. Each process model is stored as a file (e.g., BPMN XML or JSON) and tracked in a Git repository. When a process is updated, a new version is created, and all event logs are tagged with the model version. This enables process lineage: tracing how a case evolved across versions.
With this foundation, Process Mining & RPA in Enterprise becomes a living system—where data drives automation, and automation generates data.
This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy