Robotic Automation is a business and technology practice that uses software ‘robots’ to act as synthetic application users to automate highly repeatable, highly structured tasks across business systems. Is it a good fit for your organisation?
At its heart, Robotic Automation is nothing new (technically)
The fundamental technology that powers Robotic Automation offerings, which provides the ability to capture the structures of applications’ user interfaces and then drive those interfaces through automated actions, has a heritage stretching back to the mid-1990s and automated GUI testing frameworks. However, it’s been extended and packaged in new ways to serve new business operations automation use cases.
Nevertheless, its time has come
Robotic Automation technology has become particularly valued by service providers today because of how it solves ‘legacy’ problems that their clients have typically created for themselves – in a relatively low-risk way. Now, adoption of Robotic Automation is rolling out in a second wave across enterprises themselves – particularly in contact centres, shared-service centres and other back-office administration environments.
Tackling ‘long tail’ integration and automation challenges
Most organisations of significant size struggle to meet demand for new technology, or technology change. Increasingly, business teams are taking responsibility for procuring platforms that can make them more productive, and then self-serving. Where central IT provision can tackle the largest, most demanding problems with centrally-funded platforms, “long tail” problems may never get enough priority to be addressed.
Robotic Automation technology offerings are relatively simple (from a technology point of view) to implement and inexpensive, and offer a compelling way for business teams to solve automation challenges that may otherwise remain unaddressed.
What is Robotic Automation?
The never-ending challenge of legacy systems
Legacy systems have been with us for decades. In the 1990s, mainframe and midrange computer systems were the chief sources of challenge for IT departments as new waves of investment focused on Unix and Windows-based client-server systems; now, the Windows-based desktop systems of the 1990s have joined the ranks of the mainframe and midrange systems. None of them have in fact gone away, despite the best efforts of an industry constantly highlighting their deficiencies. Windows XP, for example, is frequently estimated to retain around 8-10% share of installed operating systems; and almost all of the world’s largest 100 banks still use IBM mainframe computers for core banking transaction processing.
Clearly, these systems are not going away. Partly, this is about cost and benefit; in many organisations, although there’s widespread understanding that these systems would not in ideal circumstances be used, there’s never enough of a business case to make the investment needed to upgrade or rebuild the systems or find a replacement (and also then swallow the inevitable organisational and process reengineering that would be required to accommodate new systems). Partly, it’s also about business entropy; whether it’s because of mergers and acquisitions, or through the never-ending march of tactical business software applications to support new product lines, new promotional strategies or new communications channels, the supply of legacy systems for many large organisations in particular seems inexhaustible.
Although the business case for replacing these systems is often difficult to make – particularly in the context of a wider slate of projects competing for limited IT budgets – the consequences of ever-growing systems estates can be very challenging; particularly for people responsible for administering back-office operations or staffing call centres. It’s not uncommon to find, for example, call centre staff needing to re-key information across 7 or 8 different systems to deal with standard customer enquiries.
Automating the factories of the information age
As organisations in developed markets first began to adopt Business Process Outsourcing (BPO) practices in the mid-1990s, the value proposition of the BPO providers was largely based on labour arbitrage – the simple idea that offshore labour was dramatically cheaper than onshore labour. As use of offshore service providers and BPOs has become mainstream, though, competition for talent among service providers has begun to erode the offshore price advantage – and what’s more, that price advantage can only provide benefits to outsourcing clients once, in the first year of a contract.
Not surprisingly, then, offshore service providers and BPOs have sought ways to do more to lower their cost of operations – and work automation is one obvious way to do this. With many clients’ business processes being taken on by BPOs ‘as is’ – legacy technology investments included – and with little opportunity to invest large sums to re-engineer those processes or redevelop or replace core systems, providers have sought comparatively low-cost ways to automate the most repeatable, highly-structured (or ‘rules-driven’) tasks that occur within the processes they manage. The nature of a lot of outsourced processes means that this kind of highly routine work is concentrated, aggregated and executed at high volumes by service providers, so with the right practice and mindset, carefully-guided automation can make a big difference to operations cost and quality.
This is where Robotic Automation found its first major advocates.
Defining Robotic Automation
We define Robotic Automation as follows.
In the context of business administration processes (as opposed to manufacturing processes), Robotic Automation is a business and technology practice that uses software ‘robots’ to act as synthetic application users to automate highly repeatable, highly structured tasks across business systems.
With Robotic Automation, software robots gather and update information in other business software applications by automating actions against their existing (Windows-based, web-based, or other) GUIs rather than via specialised integration interfaces or hooking into underlying databases or program structures.