READING TIME: 6 MINUTES
I like to get to know new people, who are dealing with RPA, and I like to generate RPA-related contents, and the reason for these is quite simple: I get to know how we are currently dealing with Robotic Process Automation. And the current situation is – based on the insider information I get from various RPA experts and the reactions I got to my posts and articles – RPA really suffers to scale.
The reason for this suffering is that we hardly ever see the RPA Trinity put properly together: Methodology, Infrastructure, People. So let me elaborate what went wrong with these attributes that are necessary for a successful RPA Initiative.
Methodology
Even though leading RPA providers are giving us a ready-made Implementation/Delivery Methodology, we tend to reinvent the wheel just to feel smarter than the Best Practices.
RPA has a necessarily heavily documented way of delivery, and every document has a reason. The Process Definition Document (PDD) serves as a future reference for the process we automated, and a Business Continuity backup plan, if something goes wrong with the robot. The Solution Design Document (SDD) serves as a blueprint for our solutions before development, what we need to develop solutions that are medium or high complexity solutions, and serves as a snapshot of what has been built after we have developed our robotic process.
If you leave any of the above, you might feel that the developments are faster, but when you’d like to examine the processes in the future, you’ll spend loads of time reverse-engineering your past processes searching for reasons why they have been built like that. Ian Barkin is already foreseeing RPA Forensics experts in the future, who are specialised in such field. (Ian, if you are reading this, thank you very much for the hint, I already see what I’m going to deal with in the upcoming years!)
Couple of RPA Initiatives are neglecting documentation needs, and when they asked why they don’t do it, they just give a shrug and tell that they use Agile instead.
I wrote an article about robot development, and it only got a tiny fraction of the attention of my articles about robot planning and robot testing, so I guess RPA Teams are just constantly developing robots without a second thought whether they do it right or wrong. Without proper planning and proper testing, we can already place a bet on those robots’ (in)stability.
So the common methodology issues with many RPA Initiative is that they don’t emphasise on the planning and testing parts of the delivery, they just aim on development, and then they are surprised why their robots are barely coming through the pipeline or running in production the way they are intended to.
Infrastructure
I wish I could say that I’ve seen many proper Robotic Infrastructures, but believe it or not, they exist! What amazes me is that every leading RPA Tools have infrastructure setup guides to reach the maximum stability and security.
Yet, I’ve seen an infrastructure that was in an open office environment unprotected, you just needed to turn on the screen and you had complete access to the robotic control environment, and even to the resource machines, where they had their core ERP system installed with an SSO instance. Just imagine the catastrophe a stranger could cause by sneaking in, turning on the screen, logging into the ERP using the robot’s SSO, downloading the whole GL, and stealing it.
Another infrastructure has only Production Environment, where they conduct developments, testing, and live runs. A third one has mainly community versions installed on several laptops, and only a couple of virtual desktops has been set up as developer environment in order to save license cost. So their robots have been developed without the ability to connect to the main robotic database, where they could use Queues.
Security, Stability and Scalability are vital attributes of a properly built infrastructure. If we save effort or money on achieving any of these, that will hinder the build of quality robots.
People
Robotic Process Automation is still about people, who are collaborating to reach the most optimal solutions possible. Subject Matter Experts, Process Owners, Business Analysts, Solution Designers, RPA Developers, all are key stakeholders during robot developments. A chain is only as strong as its weakest link, so the disengagement of any of the areas above can cause serious troubles within the RPA Initiatives.
Subject Matter Experts are the ones, who come up with automation ideas, and who need to show their processes thoroughly in order to capture all the necessary details. Without their engagement, RPA Initiatives will fail to extend their pipelines.
Process Owners know the core business intentions of the processes, so when there’s a better way of conducting the process itself, they can evaluate if a change like this would undermine the business intention or it would result in a valid improvement.
Business Analysts are capturing the processes properly, and asking all the questions that are important to prepare the design of the robot. If they miss key knowledge about RPA, they’ll miss the whole point, and will fail to record everything necessary, resulting in additional negotiation rounds between the RPA Team and SMEs.
Solution Designers will prepare robotic blueprints based on the findings of the Business Analysts. If they don’t thoroughly understand the capabilities of the tool they are working with, their design will be subpar, so if a design like this will be handled over to a junior developer, the failure is guaranteed, as they’d not be able to improvise for the missing robotic components.
RPA Developers will build the robots themselves. Their competence on using the RPA tool is paramount. If they lack training on robot development, exception handling and best practices, the projects will result in subpar solutions.
Engagement, competence and collaboration between these participants are crucial for our success. We should avoid common pitfalls that would result in complete meltdowns.
Takeaways
RPA, especially in Hungary is yet to scale due to the lack of properly built elements that are mentioned above. Many first generation RPA CoEs that has been set up are waiting to be fixed before they could scale further, while second generation RPA CoEs are fortunately built on the lessons we learned from the first generation centres. I think the future is still very promising.
In case your RPA program seem to have got stuck or you are about to do it first time right let’s talk!
Original article: https://www.linkedin.com/pulse/why-rpa-suffers-scale-balint-laszlo-papp/
