Implementing a pilot robot is simple…
Lessons learned from first mover RPA initiatives
The RPA journey is full of challenges – some become apparent only when it’s too late. From IT to operating model, many factors determine the success of RPA in the medium to long term.
We have covered the implementation complexity of Robotics Process Automation (RPA) in a previous article. So far, we have seen that the implementation of a pilot itself is usually not the major challenge.
The way an RPA pilot is usually implemented is straight forward. Install the robotics software on a Desktop and start implementing the pilot process based on the application landscape. Based on the process in scope, this can be done in rather a low amount of man days.
When our customers see how powerful the RPA technology is, what usually happens is that they take the robot and put it directly into production. While feasible, it comes along with some hidden challenges that may not be so obvious at first.
When the supporting elements such as operating model, IT infrastructure services and employee enablement are missing, everything goes down south – rather fast
Let’s start with the very basics. To run a software robot (RPA), we require an IT platform which is the same a human worker would work with, such as a Windows operating system. The installation is done within a few hours. However , what comes next provides the real challenges. First, a software robot usually requires password log-in screens (before logon) disabled for operational readiness. Alternative login procedures exist, but they still require adjustments of log-in screen policy. Have you ever tried to disable a log-in screen in an enterprise? Well, it’s far from “a simple thing”.
Secondly: the policies. Regulators impose strong requirements regarding business continuity management and operational risks. Internally, we also want to have a specific robotics policy in place:
- Who is responsible for the correct operation of the robot?
- How does a robot sign on?
- To which systems does it require access on what level?
We could continue this list endlessly, but these few examples already show the complexity of the topic.
In terms of operating model, most struggle with the concept of working “around” robots. Robots are good at executing, but their work schedule needs strategic planning and continuity. In case of issues, time effective and robust escalation to IT or business is desirable. This requires first of all a basic understanding of what issues a robot can run into and how to monitor them. For example, an issue related to the processing of client documentation will require expert business attention whereas unexpected system downtime will require IT support.
Same holds for change requests on the robot’s workflow: applications or business requirements will change with time, but the robot is not designed to adjust itself. Just as we need to adapt our processes, so do the robots.
These strategic questions do not only require staff with dedicated skills, vision and mandate, but most importantly communication across business and IT departments.
The best robots will be of little value without an appropriate operating model , hence the importance of recognizing this part of the equation and allocating resources accordingly.
What if your robot becomes ill and there is no-pharmacy around?
Whenever you start considering implementing robots and scaling up your automation initiative, think about your robots as if they were human beings. What if the robots become ill and don’t work anymore? Things as little as monthly software patches may cause a robot to severely struggle, so you better take care of them. Do you have a contingency plan? Unfortunately, there are no pharmacies for robots around (yet). If your virtual workforce of only two or three “virtual workers” are suffering from a flu, take into consideration that there might be 20, 30 or more human workers who would be required to perform the same tasks. Therefore it is essential not only from an operational, but also from a financial risk point of view to be prepared for such cases.
Don’t segregate your robots – work alongside them
The whole abstract thing of RPA and “virtual workforce” becomes more tangible if you think about them, the same way you do about your human workforce. What do you require in terms of security and specifically logical access? What are you doing in case, a robot is on strike or on sick leave? Where can the robot get help from a human?