So, exactly what are the biggest problems you can expect with your robots?
In a word… “People!” are the biggest problem when it comes to robots.
But, more importantly, how can you avoid or fix them? What should you DO or NOT DO to avoid them?
This article comes clean on the main problems you will face, and some top tips to avoid them and make your own automation journey the most successful possible.
No such thing as a Silver Bullet
The world is obsessed with the notion of technology “Silver Bullets”. This is the dream of the ultimate, seemingly magical and miraculous solution to a known problem. The answer unfortunately, is there really aren’t any, and never have been. For example, penicillin didn’t cure all infections and electric cars alone won’t solve global warming, but together when combined with other technologies and actions, are greater than the sum of their parts.
RPA is no different. A silver bullet? No, but as a new tactical tool to address old issues or a strategic weapon to enable new transformation within a programme of other steps, YES?
Problems You Can Expect With Your Robots
People, by their very nature, make mistakes….and it’s often unbelievable, just how many mistakes we make.
Robots will do what they’re programmed to do. If a Robot behaves or performs in an unexpected way, it’s most likely due to a person’s mistake: a miscommunication; a missed detail; a misunderstanding.
So, what are the common problems you will experience with your own robots, from idea conception to deployment, and how should you look out for and plan to avoid those?
Concept & Idea Creation
It’s important to have a pipeline of automation candidates…and it’s also very important to have a business case and a clear idea of your own “why” for what you want to achieve with automation. This is incredibly important to ensure the correct processes are selected that generate the benefit everyone is expecting, and that the complexity and effort required for that process automation is clear for everybody involved in delivering it. It’s also important to know how and when those benefits will be realised. For example, if the automation reduces manual work and frees up 1 whole day per week for your team, how will that “day back” be used to realise that benefit. Relevant Reading: Process Automation Candidates
Process Discovery & Design
The intent of discovery and design is to properly understand and document how your process is currently being performed, by who and when, using what systems and data. First-hand knowledge of the process is absolutely essential, including all its variations and exceptions, not just the happy path or a supervisory view of what “should happen”. Relevant Reading: Skore Case Study
Then obtain some sample data from the process owner – this helps tease out all the little tricky variations in practices and scenarios that can and are, easily overlooked. It’s a key job of the robot developer to examine that sample data, evaluate it and detect those variations and plan accordingly. This does mean therefore, that you may need quite a lot of sample data, but this will pay dividends when you come to build and test.
The next step is to agree the design of the future automated process, so it’s clear for the current users, the scope of what the robot will do, but also what the users will do differently. This is also when your robot developer needs to begin thinking about exception handling and working with your users to agree human-hand-off actions properly. This is a perfect time to also begin thinking about the business continuity plan (BCP), for which the business users and process owner will need to decide what will happen when the robotic process cannot operate – and yes, it’s more of a when than an if – it’s very simple to address in practical terms, but it requires pragmatism. Relevant Reading: Business Continuity Planning & Robots
At this stage, you should also be collecting test data for the upcoming Robot Build phase. Not because it’s particularly complex, but it can take time to gather data in sufficient quantity to cover all the variations and scenarios involved. Getting “enough” and hoping for the best, is not the wisest policy, so if in doubt, always get more.
In practice, even if you’ve done everything right, there will always be something that is missed – back again to the opening statement about people – and this is where the skills and experience of a really great robot developer will pay-off, because they’ll design a robot that gracefully handles “unknown” exceptions and alerts people to this for resolution with minimum fuss and maximum effectiveness.
There’s often a tendency or temptation to over-engineer and try to automate everything in a process in one go. But this will only lead to delays and frustration, or even failure. It’s best to break-down a complex (or even a simple one) into smaller, manageable sub-process steps. This also applies to exceptions and variations within a process – look for commonalities between them and automate those first, leaving complex actions until last or later, and consider whether these are even suitable and feasible to automate, given your goals and business case expectations. You may even find that some variations can even be simplified or eliminated, all of which will make user testing, and therefore deployment, simpler and quicker to achieve successfully.
This very often overlooked phase, gives your robot developer the opportunity to properly consider the automated solution and how the build and construction can be optimised for a robust, scalable and successful robot. The temptation here is to jump straight into the build, but an experienced robot developer will pause to consider the most effective data model for the process and validate the business requirements. This is especially important where more junior robot developers will be building the automation or where the construction will be shared between multiple developers, and will avoid bad practices creeping in. This is also the stage where the robot developer should be thinking about data logging, especially with unattended robots, as this is key to understanding any errors that occur once the robot is deployed.
Build & Test
Ultimately a successful build depends on how good your solution design is.
People new to developing robots often believe that solution design is a waste of time. Unsurprisingly, these people end up with delayed deployments, whilst they use UAT to re-build and reconfigure the robot and capture what was missed or overlooked.
Such “on-the-fly” fixes and additions will often lead to over-complicated coding, bad practices and operational or support issues down the line. So, if you’re a business user and beneficiary of a robotic process, make sure you ask your developer about the solution design.
Despite the RPA industry being still relatively young, there are common established and recommended best practices that every robot developer should follow, regardless of which RPA software is being used. The following “do’s” and “do nots” are some examples:
- DO add Annotations and Comments, as this allows anyone to read and understand the code and even the coding approach, which is helpful if someone else needs to support or change the robot
- DO NOT hard-code variables, such as file names/locations or actions
- DO learn how to use the debugging features of the RPA tool. This enables quick testing and issue resolution during build
- DO NOT use message boxes, especially building unattended robots – it’s amazing how many times unremoved message boxes have appeared in the live process causing the robotic process to stop running
For Testing best practices, the following “do’s” and “do nots” are some examples:
- DO use a separate robot test environment to run the robot fully and under circumstances which match production as closely as possible to tease out potential issues before going live
- DO NOT waste business process user time with non-functional build testing as the robot is being built – it won’t make sense or add value
- DO define the testing success criteria in advance and DO focus user testing on business process outcomes, which people not only understand better, but there’s little value in them watching a computer screen flicker as the robot operates
- DO NOT expect to run through all user testing without finding some defects, there are nearly always small differences between the different non-production and production system environment versions…despite what you believe or are told
- DO obtain a completely fresh batch of test data for user testing
A fresh pair of eyes is always a good idea, and this is especially true for building robots. A good code review will identify any errors or omissions and check the logical flow before getting the business process users involved in testing (and wasting their time).
Production Readiness & Deployment
The work for this phase can and should often start in parallel with the solution design and build and covers the required change management and user training manuals and service support levels for the robot. Most of the early post-live issues will revolve around a lack of understanding of what people need to do differently once the robot is performing a process and who do they contact or what do they do when the robotic process is not running as expected.
Once a robotic process is live, it will be someone’s responsibility to monitor exceptions, notifications or errors and provide the first line of support for their new digital colleague.
All robots require a simple yet robust operating environment, that is professionally managed and maintained by IT people who are officially assigned and skilled to do so. Regular maintenance, updates and patches of the virtual robotic workstations, the applications they use and the robotic software they’re run on is essential to a successful robotic process. It’s relatively straight forward to do, and many of the activities can even be automated, but it is critical that these important tasks are somebody’s responsibility. Relevant Reading: Business & IT Collaboration
As stated at the beginning, most problems with robots can be traced back to people, with poorly thought-out designs, badly executed robot coding and construction, inadequate testing, all of which will result in a robotic solution that isn’t fit for purpose. This could lead to a lack of confidence or credibility in your robotic programme and ultimately, failure.
In conclusion, like any technology, RPA can be strategic and transformative or tactical and operational, but ultimately, it’s a tool like any other: it relies on being used for the right reasons, in the right way, by skilled resources and relies on an appropriate methodical approach to be successful.
Other Relevant Reading:
Read this UiPath whitepaper for insights into an IT Compliant RPA Implementation.