RPA speeds up the handling of matters in the City of Tampere

When the City of Tampere decided to tender for RPA, or Robotic Process Automation, the use of software robotics had not yet become as widespread as it is today. “We have always been eager here to boldly try new things. This project also had its roots in a couple of individual pilots,” says Pertti Vartola, who is the City of Tampere’s information management designer and project manager for the implementation project. “The idea started with the fact that things can be automated and people can do more meaningful work,” designer Pasi Paananen, who worked as Mr Vartola’s colleague in the project, continues.

Contrary to what is often feared, software robotics did not come to Tampere to take people’s jobs. The City of Tampere set out to innovate new ways to fill resource shortages and make more efficient use of people’s working time for more meaningful tasks. For example, in child protection, attempts are made to speed up the processing of non-urgent tasks through automation in order to allow more time to deal with urgent cases. “We already consider at the design stage what the work time saved by automation will be used for. It’s not the intention to lay anyone off due to automation,” Mr Paananen sums up.

Gofore was selected as a partner of the City of Tampere through competitive tendering. However, the start of the project had to be postponed by one and a half years because the tender was subject to a grievance process. It was nevertheless concluded that Gofore rightly won the tender. After this, in November 2018, co-operation with Gofore began. Unfortunately, due to the delay, the original projects planned for RPA were no longer relevant, so the design work had to start all over again.

In the next step, the workshops were used to chart ideas and consider where automation would be the most acute and, above all, sensible to use. “It really started from scratch. For example, there were no ready-made work documents to get started faster,” Vartola reflects on the project’s difficult first steps. The first months after the start of the deployment project were dedicated to having a closer look at use cases in relation to prioritisation, contrary to what was originally planned. “The situation was challenging, but also very instructive,” says Vartola.

However, finding new automated processes was not a problem, as there were abundant suggestions for potential uses. These suggestions had to be precisely screened to determine what is truly sensible and efficient to automate and which topics could be dedicated enough time within the framework of the deployment project. In the end, a decision was made to condense the original order for seven robots to five, as the six-month deadline was simply not enough to get acquainted with all the varying systems and train people.

“At the production level, we had no idea what kind of documentation about RPA should be produced, and there was a lot to learn on behalf of Gofore with regard to getting acquainted with all the new systems,” Mr Vartola notes, summarising the initial collaboration situation. Both parties learned something new and valuable documentation was generated. “Qentinel Pace provides good data and dashboards allow you to track processes. From there, you can easily see the volumes and constantly mirror not only the current state but also the estimates set for the project.”

Prior to the start of the project, production lines did not have an understanding or complete comprehension of software robotics, so the choice of processes to be automated was challenging. “Within the framework of this project, a model has been created for how to evaluate such situations; that is, how and in which processes software robotics can be introduced,” Mr Paananen states. Challenges have been related to technical issues and third-party operators. “The more players in the game, the more challenges there can be.”

Unforeseen problems were also encountered, such as the credentials of the software robot. Data transfers worked normally within a test environment but in production it was noticed that the robot could not operate without credentials required by a healthcare professional.  So far, according to the Finnish Institute for Health and Welfare, these cannot be granted to a software robot. The robot was designed to ease the workload of nurses by automating manual data transfer from systems directly to physicians. Currently the robot has been shelved, awaiting a decision from the Finnish Institute for Health and Welfare.

Ultimately, the deployment project resulted in the production of six robots:

1. Transfer of ice rink reservation system information from one system to another.
2. In child protection, activation of non-urgent notifications for processing. The system itself does not allow automatic forwarding.
3. Electronic archiving of support forms in the student system. About 40,000 files to archive, which must also be named correctly.
4. Early childhood day care decision. The robot does not make the decision by itself, but compiles the necessary information for making a decision.
5. Early education customer fees. Forming a decision when the customer agrees to the highest payment.
6. Targeting prescriptions. The patient information system receives prescription renewal requests, from which the nurse directs these to a doctor. There are about 20,000 requests annually per health centre. The robot is in the testing phase and is awaiting for approval from the Finnish Institute for Health and Welfare.