For years councils have been viewed as antiquated – miles behind on the latest trends, ideas and innovation. Here at Orbis, the partnership between Surrey, East Sussex and Brighton and Hove Councils, we don’t claim to have this rectified just yet but our central projects and Information Technology (IT) teams are determined to dispel the myth that we don’t have the talent to make a difference. It hasn’t been an easy ride, not by a long shot, but it has been necessary. In a series of blogs, we are giving our story about the transition into Robotic Process Automation (RPA) – the good, the bad and the ugly.
Robotics became more and more evident as 2017 proceeded and with sales emails, consultancy firms, seminars, national media and even Politicians all beating the same drum about how the future is robotic, we couldn’t ignore that we needed to consider inviting the robots in to our offices with open arms. Whether they are embraced quite so easily remains to be seen but either way, they were coming and the strategy was to have control of their introduction rather than them crashing the party.
Being a Council does put us at a slight disadvantage with RPA, as fast moving technology is a new concept to us. We haven’t trained our teams to deliver what we were now asking from them, ‘red tape’ tends to be attached to the bulk of what we do and did I mention that we have zero budget to make this happen? Zero.
Surprisingly we managed to find a team of people willing to self-train, work long hours in a highly pressured environment for no extra pay. I’m still not entirely sure how we managed this, but we did. The team comprised of people from our central continuous improvement team, IT and our subject matter experts (who actually worked on the processes we were looking at).
Work started immediately with the first hurdle to jump being finding a base, which we loving called the ‘Bot Lab’, where our willing victims could sit together to discuss everything RPA. Immediately upsetting people by politely escorting them from their room and housing them elsewhere in our offices was, in hindsight, possibly not the best way to start getting robotics seen in a positive light but time was of the essence, so this is what we did. Our excuse… having a place to collaborate, build a sense of team and consistently feed in ideas without having to wait for responses was imperative to start building robots in the extremely short timescales given.
As predicted, when it was announced that “the robots are coming” people feared them and what this means for their future. Luckily for us the brains behind building the robots are fully embracing them and the benefits that they could bring to both the business and our employees.
Having said that, it hasn’t been a bed of roses for our robot specialists. Possibly because they weren’t specialists when appointed into the Bot Lab. With Robotics being such a brand new concept to Orbis, how do you ‘train the trainer’ when no-one knows the subject in hand? You self-teach. You Google and you Youtube.
You might also like
The rate at which the Bot Lab were getting themselves up to speed was incredible but this can lead to burn out and it can mean relentlessly having to adapt the robots because it’s a case of trial and error. Is this our recommended approach? Definitely not. It can lead to a lot of excess hours for staff and additional stresses that they don’t really need. However, it does prove that you could be sitting on goldmines in terms of hidden talents in the workplace that just need the opportunity to showcase their skills.
So where do you start? For us, we had a few things running concurrently. Before the robots made an appearance, the Lab needed to be fuelled with knowledge about the types of processes that could benefit from robot intervention. With over 3,000 core processes for us to choose from and an average of 15 steps per process, we aren’t short of options. Analysing this much data needed a strategy. Our choice of weapon? Project Pathfinder.
The concept of Pathfinder was based on ‘baselining’, but it wasn’t fast enough for our deadlines and we only had a resource of two. Instead of our two team members analysing such a large quantity of processes to find the best place to start, we asked the teams doing the processes to tell us which ones they thought could benefit most from robotic intervention. Feedback to the Lab consisted of the most highlighted processes and the ones that were simple enough for us to attempt building a robot for. It didn’t make sense to choose a process where the requirements for the Bot were just that little bit too far out of our capabilities (for now anyway).
Back in the Lab, they decided to get Agile. A Scrum Master was appointed to keep the team cohesive, on task, focus on value and remove any blockers that got in our way. We had been made aware from procuring a room for our Lab that early communication of what was happening was key. Regular reviews and feedback meant that the Lab had clear ideas on the size and complexity of automating processes pitched to them and resource from the team could be sourced with a bit of a ‘heads up’ before team members were (politely) abducted from their BAU role and taken to the Lab as subject matter experts.
What we did struggle to do, with the lack of time on our side, was iterative testing. As a result, we could only test the final outcomes, so data may not have been populated and calculated correctly. Not ideal in the grand scheme of things but we were able to fail fast and learn quick to produce robots in lightning speed (for a Council at least).
Next month we’ll introduce you to the robots and how we started to engage with the wider teams to attempt to turn fears and negativities into positive energy.