10 good practices of RPA

The idea at the heart of the codes of good practices is that they are not standards imposed by law or other regulations, but are established by entrepreneurs based on their experience. Is it worth applying the principles of cooperation between the suppliers of RPA solutions (producers of programming platforms, consulting companies, developers) and clients who receive these solutions, which have been checked in practice?

Generally speaking, it seems that it does. Certain proven methods of cooperation and carrying out automation projects result in removing some of the risks, including the main one, which is the failure of such a project.

To overestimate the value of automation is not good, because such a transformation is not easy for a company, but realistic cooperation between the supplier and client guarantees more effective use of the robotisation.

Code of good robotisation practices

We present a list of 10 most important aspects of cooperation with RPA solution providers, prepared on the basis of Crowe experts' experience.

1. Joint planning of actions to be taken

It is said, 'Having no plan is a plan to fail'. It is not advisable to start the robotisation process without developing a high-quality plan together. Robotisation is not only a software robot, it is also the working environment, the people working with it, parallel processes, as well as the new competences that follow. The correct identification of all limitations and opportunities, as well as all elements of this process, is a prerequisite for the correct formulation of a solution.

The solution provider should clearly set out the technological requirements for installing the RPA system in both on-premise and cloud formulas. Issues related to this in terms of necessary inputs, security, availability and maintainability of resources can often constitute a separate IT project accompanying the robotisation process.

2. Documenting the robotisation process

Tasks performed within the scope of automation should be documented, starting with the characteristics of the process to be robotised. The description should include a map of activities and their detailed course, including the characteristics of process metrics, possible exceptions to the rules, as well as ways of dealing with potential errors.

Such a description may be part of the Business Continuity Plan. If the robots fail, with the help of the PCD, it is possible to continue the process manually, by means of saved instructions, without significant threats to its execution. In this context, it is also important to provide documentation concerning the production of the robot code, e.g. in case the programmer who created it quits the job.

3. Realistic presentation of the robot's capabilities

Robotisation has its limitations - technical, resource, process, efficiency, time and many others. An honest presentation of the robot's functionality is the foundation for understanding its broad capabilities, but also its natural limitations. A robot does not make a non-standard decision, it may not be able to read the text file - despite the best OCR, and it will not learn anything by itself.

The necessity to train and control the robot in its daily work, correcting the code in the case of changes to the process flow, costs associated with outsourcing in the absence of own programmers should be clearly signalled at the beginning of the automation project. In this way, we will avoid misunderstandings related to the expectations and effectiveness of the whole project.

4. Clear and simple solutions

The comprehensibility and transparency of the script is indispensable when it comes to the opportunities for improvement, modularity, role taking, communication and continuous development of automation. Here, clarity means the extent to which the code created allows you to understand what a given robot is programmed for. The simplicity of the solution allows for savings in terms of searching for errors or keeping the robot working properly in its working environment.

Simplification of tasks and solutions in robotisation is essential. Wherever possible, it is good to reduce, eliminate unnecessary complexity. This will limit errors in coding, improve its efficiency, but also have a good impact on the efficiency of the automated processes.

5.  Modularity of the solution offered

Modularity means that a complex robotic program can be broken down into smaller, independent modules or sub-processes. There are two basic advantages of this approach. First of all, usually there are repeated activities in processes, such as logging into the accounting system. It is more effective to create an independent code and add it to the solution library than to programme a new part of a robot each time. This approach also increases the usefulness and effectiveness of the programmer's work.

The second advantage is that modularity supports precise programming and testing of the solution. This is particularly useful in the case of complex processes, as you can independently assign the creation and testing of specific components to individual stages or different developers.

6. Joint testing of the solution

In practice, it happens often that the original scenario adopted for programming the robot turns out to be more complicated than originally assumed. The process may involve more exceptions and the data to be processed turns out to be in a different format than the adopted one. One has to assume that an error in the code should have been noticed before the robot was started.

The practice of meticulous testing of a robot before it is put into operation in its working environment is helpful. It is best to test individual parts of the code - the postulate of modularity of the code works best here - that allows for catching errors at a specific stage of the robot's work. The ideal solution is if the developer and tester are two different persons.

7. Clear limitations on robotisation

No matter which RPA platform we choose, none will be perfect. There are always limitations, and no matter how carefully the robots are programmed, they will not work reliably all the time. There will be a natural need to adapt them to the changing conditions resulting from changes in the working environment (update, new document format).

An example of a limitation is the recognition of an image with a sensitivity to screen resolution, and this may prove to be difficult to implement in practice. Most RPA tools allow text to be extracted from web applications, either natively or by OCR. Please note that OCR is not 100% accurate. If precision matters, relying on current OCR technology can be risky.

8. Realistic assessment of the potential and time of return on investment

Starting a large robotisation process involves incurring costs related to the preparation of the process (mapping, measuring, optimisation), preparation of the IT environment, programming and implementation of the robots, training for the employees handling their work, maintenance and reprogramming of the robots. Most often these are the costs of several tens of thousands of PLN per year, but at the same time there are simpler solutions, the cost of which is 200 PLN per month.

The question of whether replacing human work with robot work - as the main source of savings - is able to generate the above added value largely depends on the labour intensity of the automated processes and the efficiency of the use of the programming platform.  Reliable calculation of the value and costs generated by automation will allow for realistic expectations in this respect.

9. Manage technological change

Taking over the employee tasks by the computer programmes is undoubtedly a new quality in the company. Sufficient involvement of employees to minimise resistance and fear of change depends to a great extent on the quality of communication provided by both the organisation and the solution provider.

It is widely believed that most people do not like change. Change causes resentment and resistance. In order to implement the new solution effectively, we need to ensure a sense of security, that is to say, information about what will happen next and - most importantly - the awareness that one can always count on support - including training aimed at improving competences - as well as breaking the belief that 'a robot will take my job'. Good cooperation between RPA's provider and an organisation may be insufficient if there is no such cooperation within the organisation.

10. Demonstrate the potential for robotisation development

Automation can begin by robotising one simple process (or even a part of it), so that it is to be a test ground for further automation development. Such a Proof of Concept - i.e. verification of the concept by the solution provider - will tell us whether a given automation will work properly. Starting the robotization process does not require building a new company strategy, and to test the idea we need only the generally available tools in beta version and thirty lines of code describing the nature of the robot's work.

It is often the case that, at the very beginning, employees involved in the robotised process are sceptical about this idea. However, after a year, it often turns out that this opinion changes dramatically. You have to be prepared for such situations. It is up to the solution provider to point out the effects of an evolutionary versus revolutionary approach to robotisation and to choose the optimal policy for the organisation. 

RPA becomes an instrument for the strategic development of the company, and not just a way to reduce manual labour costs. It is a team game of suppliers and clients buying a robotic programme, in which IT, business and compliance may see great added value within their own areas, but also the market value of their own individual, new digital competences, which in a few years' time may turn out to be indispensable on the labour market.