On an unsurprisingly cold Winter morning, I met up with Anne Katrine Houtved Tørring who is a project manager at University of Copenhagen. During the last twelve months, Anne Katrine and her colleagues have been working on an automation and robotics pilot project.
The results? A robot called Printa, as well as a sturdy framework for further automation. In addition, the holistic approach revealed a couple of other straightforward solutions, eliminating hours of monotonous work every week.
Interview by Martin Paludan.
Six months analyzing
Quite fittingly, our café of choosing in the center of Copenhagen is busy with the very same students that the ongoing automation efforts will ultimately help. As is the case with Copenhagen University, more and more public institutions are working to reap the benefits of automation. Could the potential here be even greater than in the private sector? In a recent article - Automation is the key to good governance - Datainnovation.org suggests that it could.
Government organisations tend to be large and highly complex, and the same holds true for Copenhagen University. It wasn’t a small task for Anne Katrine and her colleagues to determine where the pilot robots could make an immediate impact. That’s why they spent six months analyzing the organization with regard to the potential of automation and a realistic implementation that could gather widespread support:
It was imperative to us that we could successfully translate the idea and implementation of robotics to the language of our organization. We felt pretty sure that simply bringing in a rather fixed framework from eg. the private sector would never work. Our aim was to do it properly in a way that wouldn’t step on people's toes… which poorly executed automation certainly can do.
We needed to know what this required from us, so we had two main focus areas. One was how we could do it technical; what standards were required. The other was the organizational focus - how should RPA (robotic process automation) be anchored throughout the university, what should the criteria be, and how could our pilot work be continued afterwards.
The leadership team was comprised of the most interested and curious people throughout the organization. Not knowing all that much about automation before sitting down with Anne Katrine, I assume that IT would be dominant in this group from the very beginning. However, Anne Katrine explains that an IT department often has good reasons for being somewhat sceptical of new automation projects, since RPA-solutions are owned by the business, not IT. Anne Katrine stresses that it’s important that we don’t think of RPA-solutions as IT-solutions, because they never will be. Rather, we can think of them as a digitized employee.
Bad robots pile up on the desks in IT
But there is a second reason why IT are often sceptical about automation projects. Even though they will not have ownership of the project, it might still end up a burden on their desk:
It actually makes a lot of sense, since IT professionals have often experienced that automation simply means moving more maintenance onto their desks. This is obviously not what we - or for that matter any other team working to implement automation - wanted. But I think it can end up being the case, if you become over fixated on the potential gains. Then you might end up creating a lot of highly complicated robots that will break down every other day. Our approach was somewhat conservative, which also meant that we ended up having a good dialogue with insights from IT.
The goal was that the RPA-team should have the technical ability to perform ongoing testing themselves, but Anne Katrine and her colleagues were extremely aware that the university wouldn’t become world champions by building three robots:
We were building an RPA-raft, then setting it out on the turbulent organizational seas. So it was really about making that raft as sturdy as possible, allowing it to survive a long journey of continued development. All the robots are configured by tech experts, and they are built so well that the ongoing costs should be quite low. After all, the goal of our pilot wasn’t to build a couple of robots, but to pave the way for future automation. This would never happen, if our pilot robots ended up tying down resources left, right and center.
Three robots walks into a university… and two of them turn out not to be robots
The first robot was “placed” in salary, where one employee was pressing the same button for 20 hours each week. One button. 20 hours each week. I try to wrap my head around it while Anne Katrine goes on explaining:
She was opening Outlook and hitting print pay checks. These would then later have to be scanned back into the system. Obviously, we could have gone about this trying to automate the entire process, but this could easily have taken years. Instead, we opted for just automating the process of printing them. This was relatively simple, but it saved 20 hours of mind numbing work each week for that team. It wasn’t optimal, but it worked, and it allowed us to showcase quick results and gain support for increased work with automation, which is what a pilot project should be aiming for.
The second robot was in the administration of the university, where they are generating approximately 8.500 educational degrees a year. Generating just one of these froze the computer for one to two minutes, leaving an employee staring blankly into thin air - or sipping his or her way through unhealthy amounts of coffee.
To begin with, we wanted the robot to take over the entire process; pulling the data, generating them and archiving them, but again this would have been immense complicated, and could have taken years. So our goal here was to at least have the robot generate them.
Today, Anne Katrine’s colleagues in administration are sending in an arc with three different parameters, and the robot takes over from there. 5 out of 6 faculties already had that information organized in a way that matched the parameters, so it did relatively quickly lessen the workload.
The last robot turned was implemented at the Faculty of Health, where they have more than 100 dental treatments a day - people who all have to be billed. An employee was searching for all the patients - more than 100 each day - just to check, if they had been there before, or if she had to put them into the system for the first time. She pulled a list of all the patients in Excel, and then had to filter through this manually each time. In addition, pulling the list closed down the entire system down, so she had to meet early in the morning or stay late in the afternoon in an empty office, since this was the only time nobody else was using the system.
Again, the initial goal was to automate the entire process, but a solution - which could be quickly implemented - turned out to be a simple button. The biggest gain here was quite simple, and didn’t really have anything to do with automation. Just creating a filter option, so she could pull the excel-ark from a specific time period, made a big difference.
Sometimes you need a robot… sometimes you just need a button
So, the goal of the first pilot in salary was actually to remove a button. It can seem somewhat ironic that the solution in the third pilot was actually adding one. Anne Katrine laughingly agrees that from the outside it can seem a bit odd:
To us the pilot projects wasn’t just an opportunity to experiment with automation. It was also a strong mandate to look holistically at different processes in the organization, since people know that automation has the potential to deliver quick results. But we had a “gain-mapping” relative early in the process, which didn’t cover just building robots, but also making the processes smarter from a technical standpoint in general. Sometimes just having one specific task handled can make a person's job instantly better, while completely automating the entire process could take years.
Anne Katrine continues:
What I’ve learned is that the greatest value might not always come from the robot itselfs, but just as much from the dialogue that we needed to have before potentially implementing one. It gave us a mandate to start talking very openly about processes throughout the organization, getting different departments to talk to each other. This process proved extremely valuable, as we discovered alternatively solutions that we wouldn’t have considered ourselves.
No humans were harmed during this initial robot invasion
Copenhagen University have hired four people to continue the work with RPA that Anne Katrine and her colleagues started. They will be working from inside IT, and Anne Katrine is hopeful that they will be able to further develop the initial RPA-raft.
Drawing to the end of the interview, I wanted to ask Anne Katrine the question that gave birth to the slightly flamboyant headline of this article: Are robots taking over the jobs at Copenhagen University?
Of course there are employees who are happy with “boring” work, but we haven’t experienced anyone being unsatisfied. In our pilots I know people were extremely glad that some repetitive work was lifted away from their desks. Over in salary, they actually named their robot Printa. Now they can’t even imagine how they ever lived without it. Someone said that it was lovely with robots, because now she could get on with all her “archived” projects.
Automation is freeing up people’s time, and it’s our common responsibility, employees and managers alike, to find new and creative ways to utilize that time. If we fail to do that… well, I don’t think we can blame the robots.
So are robots taking over jobs?
No. Far from it. Right now they are just slowly beginning to lift the administrative burden of employees. Freeing up time that can be spend on students. So I guess our robot project has actually resulted in human beings having more time to devote to other human beings… I think those are some pretty great results.
Would you like to learn more about automation and robotics? Consider joining one of our automation & robotics peer groups.