When we think about robots, we usually imagine metallic beings like the ones in Hollywood movies, or at least a device with grabbers that can accurately position objects and materials. This image is not so far from the truth. After all, robots are computer-assisted devices intended to relieve humans of certain, usually mechanical, tasks. Or they act as human-computer interfaces, like FRAnny, which provides passengers with information at Frankfurt Airport. However, the meaning of the word has changed over the years. These days, computer science also refers to computer programs that process repetitive tasks largely automatically as bots (short for “robots”). Software robots may have shed their physical shell, but as robotic process automation (RPA) shows, they can be every bit as helpful in our day-to-day work as their metal and electronic counterparts.
Robotic process automation (RPA) is being jointly implemented by DB Systel and Group CIO. RPA provides digital assistants that support people with repetitive, time-consuming and unpleasant tasks. These software robots do not work in the backend with interfaces. Instead, they simulate a person who works with the frontend in various applications, copies content and clicks buttons. “The software robot imitates the user on the computer,” explains Sven Pallus from the Robotics team at DB Systel. With RPA, it is now possible to exchange data between systems, even without an interface – and with absolutely no errors.
Pilot project with high appeal
For a pilot project with DB Regio, a process was selected that, while not particularly demanding, still takes a lot of time. “Once a week, we click through our SAP system and insert multiple vehicle numbers manually,” says Lisa Gerharz from DB Regio, explaining the process to be optimised. This involves verifying specific records and then copying them to another application. This is not an isolated case: Employees in the Group are constantly kept busy with monotonous tasks of this kind on their computers. They spend a considerable amount of their time handling standardised and repetitive business processes, limiting the extent to which they can use their core competencies. “For the pilot project, our case is the perfect job for a robot that does not have to think for itself. Using RPA will deliver time-savings of between two and three hours per run in the future,” says Lisa Gerharz. Because of time constraints, the data has up to now been exported manually on a weekly basis. In the future, the task will be handled by the software robot daily and automatically. This also enables us to manage maintenance at our depots better.
Using RPA will deliver time-savings of between two and three hours per run in the future.
RPA boasts a wide range of capabilities. The software robots can read structured data from a variety of sources, including the internet, e-mail or general applications, as well as MS Office documents, PDF files, databases or API/host applications. What’s more, RPA can process the data detected: for example, by opening applications and clicking buttons. Or it can fill in forms, send e-mails, compare data or copy and paste it from one location to another. But the real highlight is that software robots can also make decisions based on defined business rules. This is done entirely without the use of artificial intelligence. “AI is a system that learns,” says Sven Pallus. “RPA, by contrast, is the automation of processes. The robot can’t develop independently.” You could say the software robots are comparatively unintelligent, but diligent. They do only what they are told.
No nasty surprises
This is why developing any software robot takes time. For the robots to perform their work, they must be guided step by step through the relevant processes. In principle, this is done in the same way as programming a macro, which is an automatic sequence of commands. It is necessary to consider what will happen if unexpected events occur. If, for example, the robot has been programmed to press a button at a certain point, and this results in an operating error, or the button cannot be pressed for some reason, an error message must be generated.
Every special case has to be considered so that the robot is programmed to be as stable as possible.
To avoid unpleasant surprises, the developers first sit down with the customer, discuss the process to be automated and ask about the kind of errors and special cases that may arise. Every exception that is documented from the outset makes life easier for the developer. If anomalies that have not been defined in advance crop up repeatedly during development, they have to be implemented farther down the line, impacting on the development time. “Every special case has to be considered so that the robot is programmed to be as stable as possible,” explains Sven Pallus. For example, it took about five days to develop the software robot for DB Regio. “The normal case was mapped in just over two days, and all special cases were implemented in another two to three days,” says Pallus.
Greater freedom for employees
The advantages are obvious: the basic load on an IT workstation is reduced, legacy applications can be connected to new solutions even if no interfaces are available, enabling data from existing systems to be transferred to new applications automatically. The system can be scaled quickly and runs 24/7. Eliminating manual sources of error, monitoring system conditions and identifying defects improves quality. First and foremost, using RPA increases efficiency by automating business processes, cutting process costs, and significantly increasing employee satisfaction. The provision of RPA technologies to partially and fully automate business processes lightens the load on employees in the Group. This frees up additional capacity for core tasks. One thing is clear: the new technology is not intended to replace people, but rather to support them in their work.
Of course, not all processes can be supported by RPA. To enable the software robot to be used, certain criteria have to be met: the processes must be relatively stable and not subject to frequent changes. They should be clearly defined and documented. They should be of low to medium complexity, and decisions should be made based on rules. The data required for the process should be available in a structured, digital form. But above all, the processes should be executed frequently. “Processes that take an hour once a month are certainly not the best application examples. But if robots run every day and save several hours each time, you soon have an ideal use case,” says Sven Pallus.
The RPA service will be available throughout the Group soon. A DB Automation Center will serve as the central management unit for subsequent RPA activities, coordinating the requirements of the DB Group and departments. 25 customer pilots have already been developed, and by the end of 2019, as many as 200 robots are expected to be in operation. Then, employees in even more departments will have software robot colleagues.