When writing a robotics blog, you would expect it to focus purely on robots. However, the more our journey progressed, the more we were realising that the heart and soul of robotics is in fact… the people.
In our first blog we spoke about procuring a ‘Lab’ for our teams to come together and work on everything RPA. Last month we introduced you to our robot family. This month we want to recognise our people, the ones who work tirelessly behind the scenes bringing the vision of RPA to life – the people within the Lab. Oh and our systems probably need a mention too!
Despite the tremendous efforts from our teams within the business and all the self-teaching happening through YouTube and Google, with little experience in RPA, we were always going to need a helping hand from our IT colleagues. Not that our IT team were particularly au fait with this particular aspect of robotics but they did have expertise in areas such as systems and coding and if we didn’t utilise this, our work on RPA was likely to grind to a halt. So after some begging and pleading for resource we welcomed Developers and a Product Owner (per process) into our Lab.
In our now buzzing (and slightly crowded) Lab we set about appointing a Scrum Master to lead us through what the plan for each week was and to co-ordinate what needed to be done and who was going to do it. Bringing a whole host of expertise together means that we covered a broad spectrum of talent and expertise but it did also mean that we brought more opinions and ways of working into the mix. With time very much against us and a need to drive the project forward, we couldn’t allow weeks, or even days, of debating and challenging each other, we needed to work together, allow more lenience to making decisions without the various levels of approval and all get on the same page. What could possibly go wrong?
The scrum was the perfect opportunity for these types of conversation to happen – mouth guards in and away we went! Luckily things didn’t quite get to that point but if I’m truthful, there were a number of difficult conversations had because we needed to increase pace and IT are notorious for taking time to ensure everything is precise and that we are kept secure. Agreed, this is all very important but our RPA journey had already been a risk and as the risk seemed to be paying off, we were ready to increase it. Conflict is always difficult and as it doesn’t bode well for harmonious working, we made sure the scrums were not left until we had come to an agreement.
If you liked this content…
People sorted, the next obstacle to tackle was system. IT didn’t have the perfect tool for this work in their application landscape, so we needed to find it… and FAST. With all the hype about RPA, there was a lot of option in the market. Let’s not forget that budget isn’t on our side to procure something, but we didn’t want to settle for something that didn’t meet our requirements, so we needed to get creative. Having so much option available played to our advantage as we were able to negotiate a free trial for a few more months than originally offered. Obviously it wouldn’t stay this way forever but it did mean that we could test the system thoroughly before agreeing a purchase.
You would think that having found what seemed like our perfect supplier would mean that we just loaded the disc and away we went, but that would be too easy! We needed to have possibly the quickest turnaround of conversations with our stakeholders, Legal, Security, Information Governance etc. etc. just to ensure everyone was kept up to speed on progress and ensure we weren’t in breach of anything.
We also needed to ensure that we tested the system properly before making a final decision about whether we would purchase the tool or not. I can’t recommend ensuring the right processes are identified, and understanding when RPA should be used over existing automation tools or technique more highly. You don’t want to go through all the stresses and strains that we did only to fall at this hurdle. Therefore, I would recommend that regardless of timescales, your time and effort is put into researching this, even if time is of the essence.
So what have we learnt so far? Apart from the fact that RPA is complex and there are lots of elements to it, we’ve learnt that behind every good robot you need a highly skilled team (or people that are really good at self-teaching). You can’t do this alone, you need IT to help support and you need to engage with all stakeholders before you implement a system. Finally, you need a great system behind you. It doesn’t have to be the most expensive one out there but it does have to be the right one for what you are trying to achieve. If you’re unsure, trial something fully before committing to it. If a company believes in their product then they’ll negotiate this with you.
See, there really is more to RPA than robots – all of this has been happening and we haven’t even mentioned the robots! Don’t worry though, there will be more about them in our blog next month…