Robotic Process Automation: Software That Clicks the Buttons

No connection built for the purpose exists, so an automation of this kind carries out a step by working another system the way a person would, through its screens and its keystrokes. The automation decides nothing, and follows only an order somebody wrote. Building one is quick, and stopping one takes nothing more than a changed screen. Somebody else makes those changes, and so somebody else sets the running cost.

The word robotic is the most misleading word attached to this kind of software. Nothing in the arrangement perceives anything, weighs anything, or chooses between two courses. The automation is a written list of instructions: open that screen, put the cursor in that box, type these characters, press this key, wait for that message, move on. Such an automation decides nothing at all, and every difficulty it creates comes from where it sits rather than from anything it works out. Almost every bad conversation about this kind of software starts by assuming the opposite, and no other idea about it matters more.

What is an automation that operates a system through its screens?

Picture a clerk at a counter with a printed card propped beside the keyboard. The card says: open the ledger screen, find the account, put the figure in the third box, press the confirm key, wait for the reference number, write it on the file. She does not decide whether the figure is right. She does not know why it is the third box. Somebody else settled all of that months ago; her job is to carry it out, in the same order, every time, without variation. Now take the clerk away and leave the card. Hand the card to a piece of software that can move a cursor, type characters and read what appears on the screen. The card and the software that follows it are the whole of it.

A screen-operating automationSoftware that carries out a step by driving another system's screens as a person would, using the same boxes and keys. is exactly that card, made executable. The automation sits in front of the same screens a person sits in front of, fills the same boxes in the same order, and waits for the same messages to appear before it moves on. To the system on the other side there is no difference at all between this and a fast, tireless, completely literal member of staff who never takes a break and never notices anything.

The distinguishing feature is not what it does but how it gets in, and every other difficulty follows from that one fact. The normal way for two systems to work together is a connection built for the purposeA defined way for one system to ask another for something, agreed in advance, which does not depend on screens.: one system asks the other for something in an agreed way, the request and the answer have a settled shape, and both sides know the arrangement exists. A screen automation has none of that. The automation is a guest that walked in through the front door meant for people, and the system it works never learns that it is there.

When is operating the screens the only way in?

There is exactly one condition that justifies building this, and it is worth stating as flatly as possible. Such an automation is built when no connection to the other system exists and none can be obtained inside the time the work has to start. Not when a connection would be slow to arrange. Not when the team responsible for the other system is busy. When there is nothing there, and nothing coming.

At Sumeru Bank Limited, invented throughout, that condition held. The core system that carries the loan book is old, it was bought long before any of this was contemplated, and it presents itself to the world as a set of screens and nothing else. There was no request the intake chain could send it. There were screens, and there was a keyboard, and that was the entire menu of options.

Where the condition does not hold, this is not a design; it is a decision to pay a running cost forever instead of a build cost once, usually made by somebody who will not be there to pay it. The distinction is worth remembering when the arrangement is proposed for a system that could perfectly well be connected properly. The screens route is genuinely faster to stand up, and that speed is real, but speed of building is a one-off benefit set against a cost that arrives every year.

Where does it sit in this one chain, and which steps does it carry?

The retail loan process at Sumeru ran in eleven numbered steps before any of this existed. Two of them are the concern here. Step 9 is recording the decision, and step 11 is raising the disbursal instruction. Both of those happen inside the core system, and both are carried today by an automation that operates that system through its screens. Between the two of them it touches twelve screens on every file.

Look at what those two steps used to cost. The intake and processing desk held seven of the eleven steps, and their hands-on times were 1.0, 2.0, 1.5, 3.0, 1.0, 1.5 and 1.0 minutes a file, summing to the 11.0 minutes that was the desk's handling time before go-live. Steps 9 and 11 are the two one-minute entries. Two minutes out of eleven is 18.2 per cent of the desk's hands-on time, spent typing figures that were already settled into boxes that were already waiting.

The honest shape of the prize is not cleverness but the removal of two minutes a file of pure transcription, on every one of the month's 8,600 files that reach a decision. The transcription is dull work, it is perfectly specified, it has one correct outcome that can be stated in advance, and nobody has ever enjoyed doing it. Dullness, exact specification and a single correct outcome are precisely the properties that make a step suitable, and none of them is a property of the software.

Two of these minute figures are easy to merge, and they are not the same figure. The exception desk today spends 19 minutes on a file it has to handle, and one of those minutes is recording. The exception desk's minute is the reviewer writing down what she found and what she decided, and it is not step 9. Step 9 is the decision going into the core system through those twelve screens, and it happens on all 8,600 files whether a person was involved or not. The two records sit in different places and serve different purposes, and an account that treats them as one has quietly lost a minute a file.

How does it break, and why is the cause always the same?

Everything awkward about this arrangement comes out of three absences, and once the three are named, the rest follows predictably. The automation has no agreement with the core system, so nobody on that side is obliged to keep anything stable. Nothing over there knows the automation exists, so it gets no notice when the core system changes. The system only knows how to admit people, so the automation has no identity of its own inside it.

Each absence produces exactly one named problem. No agreement produces a running cost set by somebody else's release schedule. No notice produces the breaks. No identity of its own produces the record problem, and the record problem is the worst of the three.

A breakAn interruption caused by the other system changing what it looks like, so the automation can no longer find what it was told to find. in this kind of automation is almost never a fault in the automation, and the arithmetic of the incident log says so plainly. The automation was told to put the cursor in the third box on a particular screen. Somebody added a field, or moved a button, or renamed a tab, and now the third box is a different box. The instructions are still perfectly correct instructions for a screen that no longer exists. There is nothing in the automation to adapt with, so it does not adapt. The automation stops, or worse, types the right characters into the wrong place.

Over the period the bank measured, the automation broke fourteen times. Every single one of the fourteen followed a change to a screen. Not one followed a change to the automation itself. The fourteen out of fourteen tells the person holding the pager where to look, and looking in the other place costs the first hour of every incident.

How many interruptions should be expected in a year?

Here is where most teams guess wrong, and the direction of the error is consistent. Asked which automation will be the most trouble, people point at the one doing the most complicated work. The instinct is right for almost everything else in software and wrong here. Complexity of the step has nothing to do with it. A screen is the part that changes underneath the automation, so the number of screens the automation depends on is the only predictor of an interruption.

Think of it as surface area. A person walking through one doorway a day is exposed to one doorway being repainted. A person walking through twelve is exposed to twelve. Nothing about what she does once she is through changes the count. Sumeru's automation touches twelve screens across steps 9 and 11. The bank measured about 1.2 changes per screen per year across that core system over the period. Twelve screens at 1.2 changes each is 14.4 expected interruptions in a year, and the actual count was fourteen.

Expected fragility is arithmetic, not judgement: count the screens, multiply by the change rate the other team actually runs at, and the result is a number that can go into a budget before anything is built. That is the whole of it, and it is available on the first day rather than after the first bad year.

Whose permissions does it run under, and why is that not a detail?

To type into a screen, something has to be let in. The core system at Sumeru knows how to admit people and nothing else: it asks for a name and a secret, checks them, and opens. The system has no notion of software asking to be let in on its own behalf. The door accepted only one kind of key, a person's name and secret, so the automation was given the credentialsThe identity something uses to get into another system, usually a name and a secret the system checks before it opens. of a person on the operations desk when it was built.

The arrangement has an ordinary explanation, and it matters as much as the explanations it rules out. Borrowing the key was not carelessness, it was not a shortcut anybody took to save an afternoon, and it was emphatically not the fault of the person whose credentials were used. The fault is in a design that had no other way in. Somebody built a step that had to run, in a system that could only admit people, and the only available answer was to make the automation look like one.

The arrangement lacks a service identityCredentials belonging to the automation itself rather than to a person, so the record can name the software as the thing that acted., meaning credentials belonging to the automation itself, and the absence of one is not an access problem but a record problem. Whether the automation should be allowed to do what it does, who approves that, and how such an identity is granted and reviewed are covered separately, under governance and access. The consequence of that absence is severe.

What does the record say when a component acts as a person?

The chain carries an audit trailThe record of what acted, on what, producing what, and who could have intervened, kept so the sequence can be reconstructed later. of six numbered fields, and the first of them is which version of which component acted. For steps 9 and 11 that field said a person. Not a wrong person: a real one, correctly identified, who had genuinely logged in on the day the credentials were issued and had nothing whatever to do with the 8,600 entries that followed.

So the core system's own record, the one thing in the bank that exists specifically to say who did what, showed a single desk operator recording every one of the month's 8,600 decisions, at a pace no person has ever worked at, at hours when the building was empty. Every accepted file also carried a disbursal instruction raised under the same name, and at least the 4,902 files the chain accepted without a person touching them at all sit inside that count.

Repair it, or build the connection?

The replacement testThe check on whether to keep repairing a screen automation or to build a proper connection instead, made against a stated period rather than in the abstract. is where the comparison becomes useful in a room rather than interesting in the abstract. There are two costs of different kinds. Repairing costs 56 hours a year, forever, and that number belongs to somebody else's release schedule rather than the deploying team's. Building the connection costs 40 working days, once. A yearly cost and a one-off cost cannot be compared at all until somebody states a period, and without a stated period the argument goes in circles.

Convert them to the same unit and the argument ends. Sumeru's own assumed working month is 8,400 minutes a person over 20 working days, or 420 minutes a day, or 7 hours a day, so 40 working days is 280 hours. At 56 hours a year, repairing reaches 280 hours after 5.0 years exactly. Under five years the screens win. Over five years the connection wins. The crossover is not a matter of taste and it never was.

The comparison fails in only one direction. Nobody states the period, and the arrangement quietly becomes permanent by default. Ask the second question too: are the screens getting more stable or less? A core system heading into a rebuild will change far more than 1.2 times a screen a year, and the crossover moves in fast.

What belongs in its own change record?

Every component in the chain carries a change record, and for most of them the usual entries do the job: the version, who changed it, when, what changed and who approved it. A screen automation needs two more, and both of them are about the system it is a guest in rather than about itself.

The first is the list of screens it depends on. All twelve, named, and anybody looking at a proposed change to any of them can then see in one glance that something out there will stop if it goes ahead. The second is who to tell before a screen changes, meaning a name on the other side and a name on this side. Both entries exist to convert an interruption into a notification, and notification is the only defence available to something that has no agreement with the system it works.

The ask is modest and it works surprisingly well. Fourteen breaks a year is what happens when nobody is told, not what happens when the twelve screens are on a list that the team changing them actually reads.

How does a lender, an auditor or an operations head actually use this?

So was building it the wrong call?

No, and it would be dishonest to leave that impression. Nine working days against forty is the whole reason the arrangement exists, and the step it carries had to be automated for the chain to function at all. There was no third option in which the decision recorded itself. The choice was between this and not having a chain, and the bank chose to have a chain.

A good version of this decision differs from a bad one not in whether it is built, but in whether the running cost was measured in advance or discovered afterwards. Sumeru's fourteen breaks were not a surprise; 14.4 was calculable on day one from twelve screens and a change rate the bank already knew. A team that writes that number into the business case, gives the automation an identity of its own, lists the screens it depends on and sets a date to revisit the decision has done this well. A team that does none of those things has the same software and a much worse year.

Whatever it is called, the automation has no view about any file it touches. Software of this kind cannot tell a good application from a bad one, it cannot notice that a figure looks odd, and it will type a wrong number into the right box with exactly the same confidence as a right one. All the judgement in the arrangement was spent before it ran, by the people who wrote down what it should do.