Robotic Automation Before RPA Had a Name

Before robotic process automation had a name, a product category or an analyst quadrant, it existed in almost every finance department in the world. It was called "Dave's macro." Somewhere in every back office there was a person who could write Visual Basic. They had automated the thing that took four hours every Tuesday — downloading a report, reformatting it, matching it against another file, pasting the result into a template and emailing it out. It worked. It saved real time. It was never documented, never tested, never version controlled, and never disclosed to anyone in IT. By 2012 these scripts were doing a meaningful share of the operational work in large finance functions. Excel macros, Access databases, scheduled scripts, and — the most fragile category — screen-scraping automations that drove a terminal or an ERP interface by simulating keystrokes at fixed screen coordinates. None of it appeared on any system inventory. All of it was load-bearing.

Why This Happened and Why It Was Rational

It is tempting to treat shadow automation as an IT governance failure. It is more accurately a symptom of a queue. The formal route to automating a process ran through IT: raise a request, justify the business case, wait for prioritisation, wait for development, test, deploy. Elapsed time measured in quarters, for a change that saved one analyst four hours a week. The informal route took an afternoon. Given that comparison, building the macro was the correct decision for the individual and for their manager. It produced real savings immediately at apparently zero cost. The cost was real but deferred and invisible — which is the defining characteristic of technical debt in every context. Three structural conditions made it widespread: The tools were already installed. Excel with VBA sits on every finance desktop. No procurement, no approval, no installation. Process fragmentation created the need. Work split across an ERP, a banking portal, a spreadsheet and an email inbox generates exactly the kind of copy-move-reformat drudgery that scripting eliminates. Nobody asked. There was no register of desktop automation, no requirement to declare it, and no audit procedure that would find it. What is not asked about does not get reported.

What Goes Wrong

The failure modes are consistent and they arrive on a delay of two to five years. Key person dependency, in its purest form. The person who wrote it leaves. Nobody else can read it, modify it or explain what it does. The process either stops or reverts to manual, and the reversion is discovered during a close. Silent failure. A well-built system fails loudly. A macro fails quietly — it processes the file it can read, skips the row it cannot parse, and produces output that looks complete. Errors are discovered when someone downstream notices a number is wrong, often months later. Extreme brittleness in screen-scraping. Automation driven by screen position breaks whenever the interface changes. A vendor patch that moves a field by ten pixels stops the process, with no warning and no error that identifies the cause. No controls and no segregation of duties. Scripts frequently run with the credentials of whoever wrote them, perform steps that would otherwise require approval, and leave an audit trail that attributes the action to a person who was not involved. This is a genuine control weakness, not a theoretical one. Invisibility to change management. Nobody testing an ERP upgrade knows the macros exist, so nobody tests them. The upgrade goes live and several undocumented processes stop working simultaneously.

The Honest Counterargument

Before the governance response, it is worth conceding what the shadow automation got right, because organizations that respond only with prohibition lose something real. These scripts were built by the people who understood the process, deployed in days, and improved continuously in response to actual use. They automated work that no formal business case would ever have justified — four hours a week is invisible at portfolio level and substantial to the person doing it. And collectively they represented a detailed, accurate, working specification of how the back office actually operated, which no process documentation project has ever successfully produced. The organizations that handled RPA well later used exactly this: the macro inventory became the automation pipeline, because it identified real friction that real people had already been motivated enough to solve.

Practical Guidance for Managing Shadow Automation

• Run an amnesty and build an inventory. Ask people to declare what they have built, with an explicit guarantee of no consequences. Prohibition produces concealment; amnesty produces a map.
• Triage by consequence of failure, not by sophistication. A crude script that touches payments matters more than an elegant one that formats a report. Rank by what breaks and who notices.
• Fix the key person risk first. Documentation, a second person who understands it, and the source stored somewhere other than one laptop. This is cheap and addresses the most common actual failure.
• Add failure visibility before rebuilding. A script that logs what it did and alerts when it does not complete is substantially safer even if nothing else changes.
• Retire screen-scraping wherever an interface exists. An API or a database view is stable; screen coordinates are not. This is the category most likely to fail after an unrelated upgrade.
• Include desktop automation in change management. The upgrade test plan must cover it, which requires the inventory to exist first.
• Shorten the official path so the shadow path is less attractive. If small automation requests still take two quarters, the macros will keep appearing regardless of policy. This is the only durable fix.
• Treat the inventory as your automation roadmap. It is a ranked list of real friction, validated by the fact that someone already spent their own time solving it.

What RPA Changed, and What It Did Not

When RPA arrived as a product category later in the decade, it was frequently sold as something new. Technically, much of it was the same approach — software driving application interfaces — with better tooling: centralised orchestration, credential management, logging, exception handling and a development environment. Those additions were exactly the things the macros lacked, which is why RPA was genuinely valuable. But it inherited the underlying fragility. Interface-level automation breaks when interfaces change, and organizations that built hundreds of bots discovered a maintenance burden that consumed much of the promised saving. The industry's own correction — towards APIs, process mining and intelligent document processing — was an acknowledgement that driving a screen is a workaround rather than an architecture.

The Version Arriving Now

The same pattern is restarting, faster and with less visibility than before. Employees are building automations with AI assistance — scripts they could not previously have written, browser agents, workflow tools connected with natural language, spreadsheet formulas generated rather than authored. The barrier that limited shadow automation to the person in the team who knew VBA has effectively been removed. Anyone who can describe a process can now automate it. That is a genuine productivity gain and it will produce the identical problem at larger scale: undocumented, untested, uninventoried automation performing consequential work, built by people who cannot fully verify what the generated code does. The failure will look the same as it always has — a silent error, a departed employee, an upgrade that breaks something nobody knew existed. The response that works is the one that has always worked. Not prohibition, which produces concealment. An inventory, a triage by consequence, visibility into failure, and an official path fast enough that going around it is not worth the trouble.

Common Questions

What was automation in the back office before RPA?

Excel macros, Access databases, scheduled scripts and screen-scraping tools built informally by individual staff. They automated significant volumes of finance and operations work without documentation, testing, version control or IT awareness.

Why is screen-scraping automation risky?

Because it depends on interface layout rather than a stable interface contract. Any change to the application — an upgrade, a patch, a moved field — breaks it, usually without a clear error, and frequently at a time when nobody remembers the automation exists.

How should an organization deal with undeclared automation?

With an amnesty rather than a prohibition. Build an inventory, triage by consequence of failure, address key person dependency and failure visibility first, and shorten the official request path so the informal route stops being the rational choice.

Does AI make shadow automation worse?

It makes it far more widespread. The technical barrier that previously limited scripting to a few people has effectively gone, so the volume of undocumented, unverified automation performing real work is increasing sharply while inventory practices remain unchanged.

---

Automation Inventory Review — Outpace finds the undeclared scripts your operation depends on, ranks them by what breaks when they fail, and turns the list into a real automation roadmap.