Why Your RPA Bot Keeps Breaking: A Process Mining Reality Check

Why Your RPA Bot Keeps Breaking: A Process Mining Reality Check

You've just shipped an RPA bot that automates invoice processing. It worked perfectly in UAT. Two weeks into production, it's failing 40% of the time. Sound familiar?

The culprit isn't your code—it's process variance you never knew existed. This is where process mining stops being a cool dashboard and becomes actual engineering work.

What Process Mining Actually Shows You

Process mining tools (SAP Signavio, Celonis, etc.) ingest event logs from your ERP, CRM, or whatever system you're working with. They reconstruct what actually happens versus what the process documentation claims happens.

Here's a real example from a warehouse management system integration I worked on:

Expected process:

Order Created → Picked → Packed → Shipped → Invoiced

What the event logs showed:

Order Created → Picked → Packed → Shipped → Invoiced (62% of cases)
Order Created → Picked → Packed → Invoiced → Shipped (23%)
Order Created → Invoiced → Picked → Packed → Shipped (8%)
Order Created → Split → Picked (partial) → ... (7% chaos)

That 38% variance? That's why your automation breaks. The bot was coded for the happy path. The business swore that was the only path.

The Gap Between "Should" and "Does"

This delta is called a conformance gap. As developers, we encounter this constantly:

• API documentation says the field is required, but 15% of records have it null
• The procurement process "always" requires three approvals, except when someone with director-level access shortcuts it
• Purchase orders "must" be created before goods receipt, but half your warehouses do it backwards

Process mining makes these gaps visible at scale. The problem is that discovering them is the easy part. The real work begins when you have to fix them.

Why This Matters for Automation Projects

Every process variant you don't account for is a potential failure mode. Consider this:

# What you wrote
def process_invoice(invoice):
    validate_po(invoice.po_number)
    check_three_way_match(invoice, po, goods_receipt)
    post_to_ledger(invoice)

# What actually needs to happen
def process_invoice(invoice):
    if invoice.po_number:
        validate_po(invoice.po_number)
        if goods_receipt_exists(invoice.po_number):
            check_three_way_match(invoice, po, goods_receipt)
        else:
            # Handle 12% of cases where GR comes later
            flag_for_manual_review(invoice)
    else:
        # Handle 8% of non-PO invoices
        route_to_exception_queue(invoice)

    post_to_ledger(invoice)

The difference between these two implementations is whether your automation has a 70% success rate or a 95% success rate.

The Developer's Role After Discovery

Once you've got process mining data, here's what actually needs doing:

1. Variant Analysis and Prioritisation

You can't code for every edge case. Use Pareto principle:

• Handle the top 3–5 variants that cover 80%+ of volume
• Build exception queues for the rest
• Don't try to automate the 2% of cases that involve manual overrides from the CFO

2. Root Cause Investigation

Why does the variant exist?

• System limitation: Legacy system doesn't enforce order, need middleware
• Legitimate business reason: Expedited orders follow different path
• Workaround: Users circumventing a broken approval flow
• Training gap: New hires don't know the standard process

Only the first two belong in your code. The others need process fixes.

3. Design for Observable Variance

Build your automation to log which variant it's processing:

logger.info(f"Processing invoice {inv.id} via variant: {variant_type}")
metrics.increment(f"invoice.variant.{variant_type}")

This gives you telemetry when new variants emerge (and they will).

Where Consultancies Come In

SAP and Celonis will sell you the mining tool. They won't:

• Interview stakeholders to understand why variants exist
• Redesign broken approval workflows
• Mediate between finance and operations when their processes conflict
• Retrain users or update documentation

That's consulting work. If you're at an agency focused on AI automation and software development, this is where you add value—bridging the gap between what the data shows and what engineering can actually automate.

Bottom Line

Process mining is brilliant for surfacing the mess. But turning those insights into stable, production-grade automation requires:

• Engineering rigour to handle variants gracefully
• Business analysis to fix what can be standardised
• Operational discipline to maintain conformance over time

The ML model that predicts process outcomes is impressive. The unglamorous work of handling the "invoiced before shipped" edge case? That's what keeps your bot running in production.

Don't confuse deploying a tool with solving the problem.