Robotic Process Automation. Part 4. Common mistakes of the initial stage of projects
Continuing the theme of robotization of business processes, we want to offer to consider the most common mistakes that project teams allow. As in any other projects in business automation, there are pitfalls that are not obvious to the customer who first encountered this technology.
Mistake # 1. Reassessing the capabilities of Robotic Process Automation
Do not consider the robotization of business processes as a panacea for all ills. This technology has its clearly defined niche, in which it is most effective. Wherever full-fledged IT automation is possible and economically feasible, you should not try to use robots. Data exchange via buses and their processing by specialized IT systems will always be more effective than manual user actions, even if executed by robots 10 times faster and without errors.
It should not be at any cost to replace a person with a robot from the beginning to the end of the business process. This approach can significantly increase the complexity of the robotization project and lower the RoI (Return on Investment) achieved. The correct approach is to automate the simplest and most routine parts of the process, while preserving human participation in non-trivial situations. In this case, the project will pass quickly, it will be economically justified, and at the same time it will give a tangible effect. When after some time the company will reach a certain level of maturity in the field of robotics, it will be much easier to transfer the remaining sections of work to the robots in the business process, and the probability of a “failure” of the project will be minimal.
Mistake # 2. Re-evaluation of Proof of Concept results
Before making a decision on starting a project to robotize business processes, the customer usually conducts testing of the concept itself, that is, the confirmation of the technology’s performance (Proof of Concept, PoC). At this stage, there is often a situation where the RoC gives the simplest process. This choice can be due to many objective factors. Here are some of them:
- The complexity of organizing the full access of the performer to the interface of the customer’s applications is the preparation of a test environment, coordination with the security service, the organization of the artist’s access to the site or remote access.
- Terms and cost. RoC, by definition, should not last for months and is expensive.
However, a successful Proof of Concept can mislead the customer. It should be clearly understood that the robotization of a simple business process does not provide answers to all the challenges that can arise when a large-scale deployment of technology. The correct approach can be a three-stage project:
- Proof of Concept on a small business process with an understanding of how this technology works in a particular environment.
- A pilot in the robotization of one or two full-fledged business processes that maximally affect all technological aspects of robotics. If the customer is going to robotize processes affecting SAP, applications with the WEB interface, MS Windows applications, OCR (optical character recognition) technologies – all this is desirable to test in the pilot, so as not to stumble upon the platform limitations after buying a large number of licenses.
- Scaling the project to the entire pool of processes planned for robotics.
It should be noted that the presence of all three stages is not a mandatory requirement. If the customer needs to automate many similar processes, the right business process chosen by PoC can give him answers to all the questions. There may be another situation where the working capacity of the technology itself does not cause doubts (for example, in the banking and insurance spheres), and it is possible to start the project from the piloting stage.
Mistake # 3. Incorrect composition of the project working group
It is extremely important from the very beginning to correctly form the working group of the project on robotization of business processes. With a superficial glance at RPA technology, it may seem that for successful implementation of the project it is sufficient to involve the business unit of the owner of the robotized process and IT. However, this is a blunder, often allowed by many project teams. The correct approach should be to look at the robot, not as a program, but as a digital employee of the company. In this case, we will see that it is necessary to add to business and IT:
- IT security. The robot will need accounts to work in the IT systems of the company, which means that it needs to assign access rights. What rights will it be: a single access model for all robots or will each robot have its own set of accesses? The issue of issuing a digital signature to the robot remains open. For a signature within the company – this can be solved by an internal order. For a signature outside the company, this issue must be resolved by industry or state legislation. And here it should be noted that in Ukraine this issue is not even on the agenda of regulators, and even in the world as a whole, the situation is not much better.
- Controlling structural units. Robotic business processes often affect areas that need to be checked for compliance with industry standards. And although the transfer of certain tasks from a person to a robot only reduces the risks of non-compliance, the controlling structural units should be actively involved from the very beginning of the project to assess compliance with industry standards and issue appropriate recommendations.
- HR. The use of robots frees the company’s human resources, which means that it is necessary to involve the HR department, which should consider which employees will be released, plan their retraining (if necessary) and redistribution to tasks with greater added value.
Mistake # 4. Robotization of business processes without optimization
Although robotics often simply speeds up the user’s actions and improves performance, it would be a mistake to transfer the business process to the robot (even at the PoC or pilot stage) without first reviewing it.
The project team should understand that the GIGO (Garbage In, Garbage Out) rule is 100% applicable to robotics of business processes.
Mistake # 5. Underestimation of qualification requirements
If the company decided to develop its own competence center, it would be a big mistake to believe that it is possible to quickly reorient specialists of another profile to the implementation of RPA. Fast online training will allow several employees to be trained to the point where they can perform a small Proof of Concept. However, for large-scale introduction by own forces, it is necessary to train specialists in advanced training, then to give them the opportunity to work in real projects on robotization of business processes within 3-6 months under the supervision of experienced specialists, and only after such training new employees can be admitted to an industrial project on robotization.
One should not blindly believe the marketing materials of the developers of the Robotic Process Automation platforms, telling that to robotize the business process it is enough to simply perform the necessary actions on the process, and the RPA recorder will record them and create a working script that will simply be loaded into the robot. So it does not work. For full-fledged robotics, analysts and developers are needed. And although developers do not need to master any programming language perfectly, nevertheless, the robotics of a more or less complex business process will require programming skills and an algorithmic mindset.
Also, an important issue is the availability of a single Framework used in robotization. If robotization is carried out chaotically, then the customer is guaranteed to face huge problems when scaling the project, as well as when servicing already robotic processes.
In general, our recommendation for customers planning to build their competence center RPA is to attract a qualified partner and involve it not only in the implementation, but also in the preparation of a competence center in the field of RPA, both technically and methodologically.
The above problematic issues in the implementation of Robotic Process Automation, of course, are not an exhaustive list. Nevertheless, these are the most common and obvious mistakes that can easily be leveled by the competent planning of the project and the choice of a qualified partner that can help the customer “not step on the famous rake”.