Transforming the Public Service Delivery Landscape through Automation
Government Case Study:
Scaling and Maturing Automation to Drive Employee and Student Experience
Manager, Process Automation
University of Melbourne
The Use of RPA and IA
In large institutions, be they government agencies or public universities, there are many processes and actions that are necessary but largely repetitive.
Given the technology that is available these days, many of these could be replaced by robotic process automation (RPA) or intelligent automation (IA).
Shiv Chandra, the Manager of Process Automation at the University of Melbourne, says that the pathway towards automation at the university began in 2016. By the time he arrived in mid-2017, “they had started a proof-of-concept,” which meant that “16 processes were automated, delivering just under $100,000 in benefits.” This was good, but immediately it was obvious that there were inhibiting factors and scope for greater potential.
The main focus of the automation was bots, software programs designed to perform repetitive tasks. But most of these bots “were on individual computers with no consistent coding.” There also wasn’t a lot of control around the bots, but the biggest problem was that there “was a lot of fear from staff around jobs,” specifically that automation could render some roles redundant. Overall, there were a lot of issues and misconceptions.
Changing the Processes
The purpose of automation and RPA is to have “something that is scalable, easy to use and consistent amongst all environments.” Ultimately it is about reducing risks and errors, and creating more time for staff to focus on other things.
Bots on individual computers were not achieving that, “so we set up a virtual machine,” allowing the bots to work where they are needed. Related to that, rather than having separate bots for separate processes, “we started breaking down each of the processes into simple features and designed the features into modules.”
”This means bots can come together when needed for scalability, or can act independently when required as well. And as part of that, they removed time pressures and now there is no specific timeline or cycle. “It's a continuous cycle. As soon as features are ready, we test and deploy.” To get to that point though, “consistent peer review coding standards, and proper version controls” were also introduced.
Changing the Culture
The technical processes were relatively easy to change and develop. Changing the culture and the mind-set of the automation team was much more complicated. The first thing to do was to create a culture of “being more outcomes-focussed.” Like many IT teams, agile and lean methodologies were being used by the automation team. These are very useful practices but didn’t seem appropriate in this instance because the lean and automation processes together “created a bit of a friction,” and the whole “process was quite exhausting. So we removed that approach.”
”The new approach is that we encourage businesses (business units within the university) to say to us, ‘here is my problem, you guys find a solution for it’. And once we receive that, we then look at what different tools and techniques we might need to fix that problem. We look at the problem first.”
Sometimes it still means using the lean approach, but the motivation is now different. Changing the focus in other ways helped too. For instance, “we removed daily stand-ups and introduced weekly check points.” Previously, daily meetings were good for the team overall, but “were not very useful for the developers. Often they held their own meetings about how to address a solution.” So now at the start and end of the week, the developers give an update of where they are at. “It’s really lifted their morale quite a bit” because they are not focussed on daily updates. “Developers need time to think about what they’re actually developing,” rather than timelines, so now they “come up with a solution design, however long it takes.” Speed and constant updates are less important than “developing solutions that will be good in the future, and will be scalable.”
The most important change was “creating a culture where people aren’t scared of automation. We’re not here to target jobs or even hours saved. We’re here to provide solutions for services.” To make that change, “we stopped reporting on how much bots were processing.” That was designed to allay fears and remove pressures. Without daily or weekly reports about numbers, staff could relax more. The reports were changed to simply say what the bots were doing. They should be seen as “virtual workers, like another member of staff.” Business unit managers were also invited into automation team meetings, and all automation staff started to dress like all other staff. All of these things together led to familiarity, workplace connections, and “a change in culture.”
Using Bots during the Pandemic
Like in all workplaces, COVID-19 brought about many changes. For some of the students, it meant they became “disadvantaged and the university wanted to help with some financial benefits.” The grant money was available, but getting it to the students would have taken a long time with many manual processes. So the automation team was called in. “We had all the features there. All we needed to do was join the feature together to form an automation process. It took about two days to do that and a bit of testing before we went live.” It obviously took some time but saved a lot more time for other department, with a lot of positive feedback coming in from across the university. “To date we have made about $50 dollars in payments to students using this automation.”
The changes across the automation program have resulted in other success too. There are now “50 processes across the university that are automated and that’s saved about 70,000 hours.” Overall, between 2017 and now, that has resulted in “approximately $7 million in yearly benefits, including cost reductions and cost avoidances.” This means that the university as a whole is pleased and staff are also much less fearful about the future of their jobs.
”Staff are quite relieved and quite grateful that the bots are making things easier, and are now also sending us requests for automation, rather than being scared about automation.Shiv Chandra, Manager, Process Automation, University of Melbourne
The problem for the automation team is that their capacity is quite limited. “The next challenge for us is to learn how to prioritise and keep everyone happy, because the demand now is just so high.”