When embracing automation, do you harness the power of internal teams, or do you engage a partner in your automation undertaking? Both approaches are used, but which delivers the best result? Sanna Koivu has experience on the client-side with both ways of automating processes and shares her thoughts in this new blog.
I have set up what you might call a self-sufficient RPA program without strong partner involvement, and I have also set up one with heavy partner involvement. I have thus seen both sides and I believe the chosen approach heavily depends on your organizational set-up and culture. Is your company one that often works with external parties? Or do you handle different undertakings internally? At the end of the day, it’s of course experience that matters.
In the one place where I was working largely without a partner, I was also busy setting up an RPA program for the first time during my own automation career. One could thus state I didn’t know what I didn’t know whereas the second time around there were aspects I recognized would benefit from specialized support. It was thus logical that a partner was brought in for those. Experience of something similar in terms of setting up an Automation Journey, whether that happens to be in-house already, or whether that comes from a partner, is most definitely required.
Knowledge & Network
A partner can obviously bring technical RPA development knowledge to an automation program, but I feel what really sets a partner apart is an understanding of the RPA architecture and how the automation components can fit into an existing (or a future vision of the) IT landscape. On top of that it is worth considering the consultation capabilities the partner can bring about in terms of advising on the Automation Operating Model and the Ways of Working, the setting up of a Center of Excellence or perhaps even on training resources and discovering automation use cases.
However, regardless of the chosen approach, there are certain key roles in any RPA program which you need to consider the fit for, the RPA Business Analysts and the RPA Developers to mention just a few. Your RPA Developers – whether external or internal – can embrace development work if your RPA Journey, Automation Operating Model and Ways of Working are well defined and governed. But the RPA Business Analyst role is a slightly different animal as these are resources that must know and understand your organization’s processes. And I find that knowledge to be hard to outsource.
Following the same train of thought, one could argue that – to an extent – project management should also be internal just because these are resources who understand how the organization works and how decisions are made internally. Additionally, they most likely already have an existing network within the organization and that is hard to replicate in a hurry.
Maturity
So, depending on the maturity and the culture of the organization you can do a lot of things yourself. But what I did notice from having trained both RPA Business Analysts and RPA Developers, it does take approximately four to six months for the RPA Developers to start producing code that really is robust and production ready. It is absolutely brilliant investing in technical knowledge, but it does take time whereas your RPA Business Analysts are ready to run as soon as they understand the skillset of an RPA BA and how it fits with their existing process knowledge.
I once worked with a very inspiring manager who had a vision of all of the company’s resources being trained as RPA Business Analysts in order for them to understand what automation is all about and what you can do with it. But by the time I had finished training approximately 150 people with just a few colleagues over a relatively short period of time it was perhaps not going to be doable with such limited internal resources – as much as I loved the vision!
Different view
One of the benefits of partnering is the wide experience of these external parties having seen implementations and set-ups from a range of customer journeys. Consequently, you get a different view on how to do things, rather than perhaps just searching internally. And if there is experience out there, why not utilize that as at the end of the day, companies want to scale up their Automation Journeys and get there relatively quickly. And don’t forget the ultimate goal of this technology is to help people and make their lives easier so capitalizing on the experience and knowledge of other people can only contribute to this quest.
Sanna Koivu is Senior Customer Success Manager at UiPath
