Your robot is just as good as instructions it is working on

Robots are never wrong – this is one of their most important advantages. First of all, they are completely immune to the mistakes people often make, whether they result from fatigue, rush, or excessive routine. Regardless of whether the robot works for a few minutes or several dozen hours – it will perform all tasks without errors and with due diligence.

Are the robots flawless?

Can we then be sure that we can fully rely on their faultlessness in every situation? It turns out that even in the case of robots, humans can be a weak link. In the process of creating and maintaining robots, there are several very important aspects that must be taken care of in order to minimize the risk of error.

First of all, the robot works according to strictly defined instructions. If they are incorrect or inaccurate, the final result will be incorrect. Even if we do the rest of the process in accordance with the rules of engineering practice. Of course, the bug can be introduced later – at a stage of the robot’s life cycle called coding, and then undetected in tests, it can be run on real data. It may also happen that the application or process changes during its course. Then the robot itself, while working as it does, will suddenly start producing inappropriate results.

Each of these aspects is a topic for a separate entry. Meanwhile, today I will focus on the role of instructions, because as I mentioned, making a mistake at this stage will be the most difficult to fix.

Is documentation of the robotic process a necessary expense?

I fully agree with the agile manifesto, which in one of its postulates states that working code is more important than documentation of the robotic process. With Digital Teammates, it makes even more sense. Robots from a low-code or no-code environment look so transparent that any documentation seems redundant. Unfortunately, this approach carries very serious risks. First of all, most business process owners are not proficient in reading the code of robots, so they cannot quickly find a possible source of an error. Second, instructions are the final reference of how the robot should operate. In case of doubt, it always makes the final decision as to whether it is a mistake at all. If there is any doubt, it is very difficult to state the intention of the process owner in any other way than by referring to the documentation. Written and stored in the repository, the always up-to-date instruction is necessary and greatly facilitates the correct maintenance of the robot.

How to document a robotic process?

Since documentation of the robotic process is necessary, how to create it to minimize the costs associated with it? First of all, it should have a uniform electronic form to be able to safely store and version it. There is nothing worse than different versions of the manual circulating around the organization. There must be a central repository accessible to all people involved in the process and from which you can easily download the latest version of the manual, as well as review any changes with information about their authors. Fortunately, most of the available robotic platforms include or work with such repositories, and their operation is intuitive. The only thing that remains is the appropriate assignment of roles so that the right people have access only to the materials they are interested in.

A good manual should describe both the typical flow of the process (the so-called “happy path“) as well as any exceptions that are handled. Screenshots of screen fragments are very helpful. They allow developers to quickly see what elements of the user interface are important from the point of view of application modelling. However, do not rely only on screenshots, because if the application changes, the cost of updating the manual increases significantly. Whenever possible, you should rely on verbal descriptions as much as possible, because the logic of the process usually changes slower than the appearance of the windows.

Particular attention should be paid to a precise description of exceptional situations. It is in these places that the most discrepancies between the expectations of process owners and their translation into the robot’s code appears. Most often, the way of dealing with exceptional situations is obvious to people who deal with the process on a daily basis, but also completely unintuitive for robots’ developers. Writers of instructions need to know that any exception that is not documented in the best case will not be handled. In the worst case scenario, the developer will creatively think of what the robot should do in such a situation, and it will not necessarily agree with the intention of the owner of the process. If this exception is rare, it is possible for the robot to make a big mistake after months of error-free operation.

When to update documentation for a robotic process?

One must remember that since the instruction is the ultimate source of knowledge about the process, we have to change it every time something important for the robot’s work happens with the process. In practice, it is not very burdensome, because by nature, processes subject to robotization should be relatively slow-changing. Usually, such a change in documentation simply starts the process of adapting the robot to changes in the application or business environment. After such an update has been made, the development team can start analysing the necessary modifications to the robot and start the process of its redeployment.

It sometimes happens that changes surprise us. In such situation there is no time to change the documentation. We direct all our forces to restore the robot to its correct operation as soon as possible. However, you should remember to update the documentation as soon as possible in such situation. Otherwise, there is a risk that such change will not be included in the documentation. As a result, the robot itself will become the ultimate source of knowledge about the process. It is a very dangerous situation. As a consequence, it may lead to the removal of a correctly functioning fragment of the robot during the next change, when the documentation will be analysed again by robot developers.

Conclusions

The responsibility for the correct execution of the process always rests with its owner, regardless of whether the process is performed by people or robots. Up-to-date and precise process instructions guarantee that the robot will never make a mistake. That is why it is so important to prepare it carefully. Good instructions make the development process much shorter, because we avoid unnecessary interactions related to clarifying doubts. Thanks to this, the results of the robot’s operation are available faster, and the time saved can be devoted to the development of our business.