Process mining and scripted automation are frequently presented as alternatives in vendor discussions. They are not. Understanding what each tool actually does and what problem it is designed to solve is the starting point for using either of them effectively in a back-office operations context.
Process mining is an analysis technology. It reads event logs from your existing systems, typically ERP or transaction processing systems, and produces a visual model of how processes actually execute. It tells you what happened: which paths were taken, in what sequence, with what frequency, and where deviations from the expected path occurred. It does not do anything to the process. It observes and describes.
Scripted automation, which includes traditional RPA at one end and orchestration-based automation at the other, executes a defined sequence of actions. It takes inputs, performs operations on systems, and produces outputs. It does not tell you anything about your existing processes. It executes the process you have defined for it.
Why the Order Matters More Than the Tools
The reason this distinction matters practically is that the tools address different phases of the automation lifecycle. Process mining is useful in the discovery and analysis phase. Scripted automation is the execution phase. Conflating the two, or treating them as alternative approaches to the same problem, leads to either expensive analysis without execution or execution without sufficient analysis.
The order failure that is most common in practice is execution without analysis. An operations team identifies a process that seems automatable, describes it in a few workshop sessions, and moves directly to script development. The script works on the clean path that was described in the workshop. It encounters failures on the variants that were not described because nobody knew they existed.
Process mining can address this gap if the relevant event logs exist. By analyzing how the process actually executed over the past six months, you can see all the path variants, their frequencies, and the conditions that trigger them. The automation is then built to handle not just the main path but the realistic population of cases that will actually come through.
Where Process Mining Works and Where It Does Not
Process mining works well when your systems produce structured event logs. Enterprise resource planning systems, claims management platforms, and workflow tools that generate detailed timestamped event logs are good candidates. The analysis is only as good as the log data it consumes. If a step in the process is not logged anywhere, process mining cannot tell you it exists.
The limitation that surprises teams most often is that process mining reflects what the system logged, not what the operators actually did. If an operator's decision step is not captured in an event log because it happened in an email or a conversation, the process model will show a gap where that decision sits. The model will appear to jump from one logged step to the next without explaining what happened between them.
For the kinds of back-office processes common in banking and insurance, where significant operator decision-making happens in tools that are not well instrumented, direct observation often produces a more complete process model than event log analysis alone. The two approaches are complementary. Event log analysis shows the system perspective; observation and interview shows the operator perspective. Combining them closes more gaps than either does alone.
Scripted Automation: The Calibration Question
Scripted automation that interacts with a system through its user interface has a specific technical characteristic that shapes everything about how it should be built and maintained: it depends on the stability of that interface. A selector that points to a button in a screen will break if the button moves, is renamed, or is replaced. A data extraction step that reads from a specific table position will break if the table layout changes.
For financial institutions where core systems are stable and UI changes are rare, this characteristic is manageable. Systems that have been in production for ten years with the same interface are genuinely predictable targets for automation. Systems that receive frequent vendor updates, or where the UI is subject to configuration changes by internal administrators, are higher maintenance automation targets.
The maintenance cost question is one that most automation business cases understate. Not because teams are being dishonest, but because it is genuinely difficult to predict how often a given interface will change and what the impact will be when it does. A reasonable approach is to categorize the systems your automation will interact with by their historical change frequency and build that into the maintenance estimate.
What Ops Teams Actually Need: The Practical Answer
In our experience at Pointee, the practical answer to the "process mining vs scripted automation" question is: you need both, but you need them in sequence, and you need to understand what each one is giving you.
The discovery and documentation phase needs to produce a structured process model that reflects how the process actually executes across all its real variants, not just the clean path. Whether that model is produced by process mining, direct observation, or a combination, the output needs to be the same: a complete process definition that can be used as the specification for automation development and as the reference for future maintenance.
The execution phase then builds automation against that complete specification. The automation handles as many real cases as the specification covers. A well-specified process with all variants documented will produce more durable automation than one specified only from workshop notes, regardless of which automation tool is used.
The gap we see most often is not between process mining and scripted automation; it is between informal process description and structured process definition. Teams that invest in the structured definition phase, however they achieve it, consistently produce automation that handles more of the real operating conditions than teams that move quickly from informal description to execution.
A Note on Process Mining as Continuous Monitoring
Process mining tools offer a function beyond initial discovery: continuous conformance checking against a defined process model. Once an automation is in production, conformance checking can detect when the automated process is drifting from its intended execution path. This is useful for compliance-sensitive processes where deviations have regulatory significance.
We think this is valuable when available. The caveat is that it requires keeping the process model and the automation implementation synchronized, which adds maintenance overhead. For teams with the operational maturity to manage that overhead, conformance checking provides a useful ongoing quality signal. For teams that are still working through their initial automation projects, it is a useful future-state capability rather than an immediate requirement.