“A Cyborg has been sent from the future on a deadly mission”. While this might have seemed a far-fetched plot descriptor when Terminator hit the big screen in 1984, it would likely turn fewer heads in 2017 – a world saturated with headlines about the impending robot takeover.
It’s easy to think about robots in terms of Cyborgs, or even as physical machines picking and posting parts along a manufacturing assembly line. Although a Cyborg is a little more exotic than a factory robot, they have one similarity in common that is (mistakenly) defining the conversation around robotics – they are both instances of robots that replace humans. This personification that we have allowed to evolve around robots is one of the key reasons that there is so much resistance to the technology in an enterprise context. The fact is, we’re imagining the wrong thing – robot armies taking over the enterprise, rather than process enhancements to ‘take the robot out of the human’.
Personification breeds mistrust
Of course, there is the human concern that jobs will be lost. This is true – as is the case whenever new processes are introduced that change the shape of human labour requirements. The Industrial Revolution is of course the standout example, and now we face the Back Office Revolution – automating mundane, repeatable tasks to free up skilled workers to concentrate on value-add, strategic tasks. It’s the ideal that most organisations should be striving for. The Robotic Enterprise™ has no business siloes, while barriers between the front and back office are destroyed forever. This leaves what analysts are now referring to as the OneOffice™, giving teams the time to become more customer focussed.
But there’s another thought keeping the IT teams awake at night – security. While Robotic Process Automation (RPA) is currently one of the most popular service enablers, there’s still plenty of mistrust, even fear, around the idea of unleashing an army of robots on enterprise systems. So what’s real and what’s not when it comes to RPA security concerns?
Contrary to the perceived wisdom, robotic processes tend to be far more secure than human-run processes. Why? Because software robots operate strictly within the defined regulatory and security perimeters. Needless to say, the same clearly programmed, unerring sequence of events is unlikely to occur under human watch – it’s all too easy to get distracted halfway through an email, leave a sensitive screen open during an emergency coffee run, or reply to rogue emails. This potential for error is even greater when a complicated end to end process extends across multiple geographies, requiring input from many different teams.
Concerns valid, but manageable
Despite the evocative name, a robot in this context is just another piece of software. It does what it is told to do. So as long as you test the code rigidly, based on a solid and in-depth understanding of the processes, and lock it up, no-one else can tamper with it.
Of course, this requires the implementation of strict controls, testing, and maintenance. To understand the reality of security issues within robotic process automation, we need look no further than the most regulated industry of our time: banking and financial services. Many of these firms are now entrusting their core operational data centres to robotic processing.
So if the bot is secure and traceable, what’s missing? Frankly, it’s where human input and robotic processes are mixed back and forth, transferring input from one to the other, and back again. The problem here is to do with simplification, and a lack of straight-through-processing or integration, whereby a single sign on allows continuous workflow without the stop-start that characterises handovers.
Don’t lock in system weakness
There’s also an important distinction to make between desktop or user-interface robotics, and software that is truly integrated with end to end global processes. This first type of robotics simply emulates the work that the human would do, bringing the greatest security risk of all – the threat of locking in these vulnerability prone legacy systems. In addition, once a business has robotically automated a process, the tendency is to ‘take the foot off the pedal’, forgetting to modernise the underlying systems because they’ve been ‘fixed’ by robotics.
A failure to use RPA as an opportunity to question and re-imagine the entire process is a great waste of investment. Getting it right takes a bit longer, and as ever, if it sounds too good to be true, it probably is. Businesses would be wise to avoid rash promises that herald a quick and cheap implementation, but at the expense of regression testing to make sure the system is robustly future-proofed and fit for purpose.
IT – a partner, not a blocker
The great vendor mistake in this arena is to boast how easily RPA can be implemented by the business, without too much input from IT. A cheap route to the C-Suite perhaps, but this approach will fall down – IT has to be involved from the start in building the Robotised Enterprise.
Without this buy-in, robotics will continue to bring fears of a slight re-imagining of Arnie’s famous line – “I’ll be hacked”.
Neil Kinson, Chief of Staff, Redwood
Image Credit: Flickr / Nathan Rupert