Is it possible to automate new business processes without IT integration?
How old are you? Remember “screen scraping”? You plugged a lead into a computer terminal's auxiliary port in order to intercept the characters displayed. This information could then be fed to another program. Screen scraping was a crude way to integrate two systems and so make a new process.
Over time, screen scraping grew in sophistication. Eventually it became possible to reliably drive one system, via its green screen UI, purely by simulating keystrokes generated by another program. In effect, software was pretending to be the user. When real users were employed to do this it was called “swivel chair integration.” The idea of screen scraping was to avoid manual re-keying when several systems that had not been designed to work together were involved in a process or transaction.
Surely we don't need screen scraping today? Don't we now have enterprise service buses, service oriented architectures and business process engines? Aren't all of our enterprise applications designed to work seamlessly together via well-defined, clearly published, loosely coupled and RESTful interfaces?
Dream on. Imagine this:
A large enterprise has tens or hundreds of applications. They sit on various platforms. They share some, but not all, of the enterprise data. The CIO is seeking to reduce the complexity, and cost, of her IT estate. A transformation (modernization) program is under way, but many business-critical applications are a long way down the queue for treatment. A top-down strategic initiative is under way to “service enable” the enterprise architecture (EA), but it seems to be making slow progress.
Now hop over to the C-Suite:
The business exists in a rapidly moving market. The CMO is trying to build new end-to-end customer experiences. It comes as a shock to him that the IT team claim that before this is possible several systems will need to be re-factored, re-platformed and then integrated to support the new “customer experience” that the “digital” team with their walls full of Post-It notes has envisaged. While the business case for these complex IT changes is being prepared, the call center is coming under pressure. They are reporting that they cannot cope with escalating workloads. They sense the opportunity to automate some processes. Surely, those manual steps in customer-facing processes – copying information from one system to another, reconciling databases, handling each case – could be automated. A lot of the mess seems like non-value-added work to the newly formed “Digital” team. And just to make matters more complicated for all, two business units have decided to outsource routine customer transaction processing (the clerical, well-defined, repetitive work not requiring much human judgement) to third-party BPO specialists, including offshore.
What's to be done?
In this fast-moving business environment, does it make sense to wait for neatly automated processes in the IT queue? It would be cute to believe that the EA team can create the clean IT environment in which building a new process is nothing more than a point-and-click exercise. In reality this is rarely the case, perhaps other than in green-field Web scale enterprises.
For all of these reasons, it appears that screen scraping has not gone away, but may have grown up. The industry is now calling it “Robotic Process Automation.” RPA may not be regarded as a strategic solution by purists, but it will find a role in the IT mix. Whether your IT strategy can support it is a question only individual CIOs can answer.
In the past there was no way on earth that a traditional screen-scraping solution could provide what a modern major enterprise now needs: transactional integrity across their systems when data changes, inherent data protections, audit trails and other systems management functions. Put simply: screen scraping of old was “Lipstick on a Pig.” The same is true of what some call “Web scraping.” Changing the surface UI format alone does not make a modern automation solution.
As screen scraping technology evolved, it needed a new name. Start-ups bringing new tools to market did not want to be associated with the negative connotations of the past.
Robots. Robots everywhere!
The phrase “robotic software automation” sometimes “robotic process automation” (RPA) was coined as an illusion to the use of robots in manufacturing to replace humans on the factory line. The idea is more subtle than it might first appear.
Robotic software is designed to be used directly by business users, allowing them to build and deploy new processes across systems that were never designed or intended to work together. Suppose you are the manager of a BPO unit or call center operation. You are always being asked to do more with less. You are facing targets for head count reduction. Or perhaps your business is growing, and more customer interactions need to be supported yet the business cannot afford to increase front-office capacity. With the right tool, perhaps a software robot could offload repetitive work from the humans?
In one case study, 10 software robots replaced 20 human FTEs. The processes that were automated (partially or fully) included client data changes, client policy changes, complaints handling and renewals. Using robot software, no costly IT integration was required. Even consistency and accuracy improved. How?
I should explain that I am not in the business of advocating the replacement of knowledge workers with robots. Far from it. Decisions on these matters are for those who understand their own their business priorities. The possibility to automate away non-value-added work, however, does exist in RPA. One manufacturer used software robots to replace 200 people from its order-taking process. Pressure on front or back office may drive such difficult decisions. And there could be other factors that demand automation. For example, companies operating in a global environment must provide 24-hour customer response.
Putting aside debates about “The Future of Work,” how does robotic software automation actually work?
The key is to place the automation capability directly into the hands of those who know what to do with it – the staff intimately involved in the processes they deliver to customers. They know their IT systems inside-out, not from the perspective of systems architecture, but by how they support (or don't support) a good customer experience and – most importantly – productivity of the front-office and back-office teams. These “on-stage” and “backstage” customer workers also understand the intricate details of the application UIs and what is required to make their job easier. Trying to pin down a functional specification for a new IT project is not going to work for them, simply because the business is moving too fast!
Just as a spreadsheet user knows how to plug in formulas to get a job done, the user of robotic automation software knows what rules and interactions to configure to create a new process that works for them, in the context of what they do – day-to-day, hour-to-hour. As long as the automation software is user-friendly they can do the job themselves, and they often do. That's not to say that consultants (internal or external) might not also be needed to shape the project, to find the business cases and high-impact opportunities to automate. Such process redesign expertise is often required.
And the IT organization will need to be involved. After all, they are being asked to support a new tool. The CIO will want to know how the new software works, whether it can be supported, whether it is resilient, what load it places on existing applications, and whether it could compromise corporate compliance. They will also want to see a business case in advance of any software purchase.
Sceptics abound.
When software robots are discussed one question always arises: If existing applications are themselves subject to change, will the robots continue to work, or will the rules and workflows break as the application UIs change? How stable can RPA be?
The best robotic automation solutions are designed to minimize such impacts. Remember how the “model-view-controller” principle applies to the design of a good UI. Well, robotic automation software can also isolate itself (within limits) from changes in the application it orchestrates. Newly coded business logic can be written in a way that is transparent and does not hold any temporary data of its own. Robots can even be written to deal with exception cases arising from unexpected application behavior. Permissions can be added to ensure that new robot scripts are only modified by those authorized to do so.
It is helpful to think about the potential of robotic automation using the standard model of any automation. Does the process replace a human, or assist a human? Does it automate all tasks, or a subset? Does it extend the human work, or limit it? Where is boundary between non- and value-added work?
The best robotic automation software will assist the business analyst to identify and evaluate opportunities to automate, and provide features to ensure that those processes evolve thereafter with the business. Yes, RPA can be a form of business process management (BPM).
Robotic software is, however, a fuzzy field.
Despite the efforts of industry analysts to define the field of “robotic automation,” it remains ill-defined. The functionality of products in the marketplace varies considerably.
The grandly titled Institute for Robotic Process Automation (IRPA) has said that the automation of knowledge work will be “this decade's engine of growth.” Robotic solutions will “free up human labor to provide additional capacity for more strategic work.”
The new industry group points to solutions that allow non-technical employees to reconfigure software “robots” and “assistants” to capture and interpret existing applications for processing transactions not envisaged by the IT teams that created those applications: manipulating data, triggering responses and communicating with other digital systems. The primary benefits will accrue to “those companies whose people perform high-volume, highly transactional functions.” Use cases cited include IT support processing, workflow processes, remote infrastructure management and back-office work of all kinds.
The technology of robotic automation is not well-defined.
RPA solutions certainly include presentation-layer automation software. Solutions of this kind mimic the steps of a rules-based, non-subjective process, without compromising the existing IT systems. Examples exist in finance operations, procurement, supply chain, customer service, data entry and purchase order processing. In this way, human teams can use software robots to scale up to meet demand, perhaps in response to a spike in workloads, or permanently control labor costs. Such solutions can either be bolted into an existing application to enhance its ability to capture routine work, or across multiple applications in “swivel chair” fashion.
The problem with a fuzzy field like RPA is that it can quickly lose its focus.
Some proponents of the term “software robot” extend its use to all kinds of diverse approaches, including workflow engines, intelligent agents and voice response systems. IBM was even invited to speak about its Watson technology in this context at Automation Innovation 2014, the inaugural conference of IRPA. There is nothing in common between Watson and RPA. Nothing.
The interest in software robots appears to have grown out of the outsourcing industry's interest in all kinds of automation, and their constant quest for relevance and efficiency. Presentation-layer automation (a.k.a. the evolution of screen scraping) is claimed by some to be a mysterious transformation technology, disrupting many outsourcing players. I think this may be somewhat of an exaggeration, but the fact remains that automation is playing a greater and greater role in all business processes.
Vendors that took to the stage at Automation Innovation 2014 included BluePrism, Automation Anywhere and a raft of BPO providers, including HCL, Cognizant and Tata. Other solutions that have appeared in media and analyst coverage include OpenSpan, IPSoft, GenFour, OpenConnect, Verint Systems, Celaton inSTREAM, Arago, Thoughtonomy, Innovise and Pegasystems. What a crazy mix of chalk and cheese!
It is interesting to see Pegasystems mentioned. Pega's “BPM” solution is built on a rules, not a workflow, foundation. Decision-making is a large part of what's required in robotic automation. Expect other BPM suite vendors to consider jumping on the marketing momentum created by the “robotic automation” moniker.
I should clarify one final point. Software robots – however defined – will not replace traditional IT systems and application integration. It will not replace message queues, SOA, process design and process execution engines. Far from it. Surface-layer robots will always act in a complementary role.
Whether you regard this modern form of “screen scraping” as lipstick on a pig, or a strategic business weapon, only you can decide. A tool is a tool. And a fool with a tool is still a fool. Long live business process thinking.
Re-published with the kind permission of CSC
Howard Smith
Latest posts by Howard Smith (see all)
- Southbeach Notation: Its Semantics and Case Study - February 3, 2020
- Software Robots for Process Automation: Fudge or a Strategic Solution? - June 1, 2015
- Thinking Processes, Capabilities and Services What’s in a Word? - October 6, 2014
- The Elements of Southbeach Notation 0.9 - June 7, 2011
- Red, Green and Blue – Situational Improvement Using Southbeach - January 4, 2011
Speak Your Mind