Implementing RPA solutions has allowed many organizations to see some very powerful results. In this blog, I will highlight some of the key “lessons learned” from implementing and operating RPA solutions. They are based on our experience in working with both our internal operations as well as with external clients.
RPA: Beyond the Hype
In part one of this blog series, I concluded that there is a lot of “hype and noise” around RPA, and that RPA is still somewhat of a work in progress. Many organizations are still trying to figure out how to get their RPA journey off the ground.
In my second post, I provided some tips on how to get started with RPA, offering organizations an effective methodology for identifying, capturing and quantifying RPA opportunities, in order to build your “RPA roadmap.”
Putting the hype aside, the “real” reality is that there are some organizations that have successfully tested and implemented RPA solutions (including Auxis).
Here are five important lessons learned about RPA implementation.
Lesson #1. Understand the Complexity of a Process (from an RPA perspective)
Automating business processes can be a tricky exercise. Sometimes a “simple” process, is not that simple from a robot’s point of view.
We humans make decisions every single day, based on the data presented to us, and our experience in dealing with that data.
However, what is a simple decision for a human may be quite daunting for a robot.
A robot will be very effective dealing with well defined, rule-based processes. It will be able to determine the appropriate next steps in the transaction workflow based on these rules. But if the rules are ambiguous, or if all the possible variances or exceptions are not well defined or captured, the robot will be forced to stop processing.
Identify Every Step in the Process
Make sure when you design a robotic process that you completely and accurately capture all of the steps in a process, the business rules, the frequency and timing of activities, and any and all exceptions.
And if there is a point in the process where the robot is truly unable to handle the next step (meaning a human’s judgement is required), all is not lost.
The Baton Exchange
Break down the process into the steps that can be automated and build a “hand off” to a human worker to resolve the next step(s), at which point you may be able to transition the process back to the robot to complete the transaction.
This would be considered an “assisted” process, where a robot and a human work together to complete the activities., with the robot handling the bulk of the process and the human worker steps in as needed.
All of this should be designed up front. Remember that the role of the human worker will now change, from pure “transaction processor” to what we like to call a “Robot Operator”, so training and change management considerations need to be applied.
What about AI?
What about AI, you ask, and the ability of the bot to “learn” how to resolve these judgement-based exceptions? “In due time” is my answer.
Today’s AI has its limitations, and it will likely take several years for the technology to advance to the levels needed to handle all judgement-based activities. However, the ability to free up employees from performing all manual activities, and enable them to perform higher value work, will bring tremendous value to today’s business operations.
Lesson #2. Timing (and volumes) are (almost) everything
In addition to the complexity of the process, make sure that you account for the timing and volumes involved in processing transactions.
Get ready to do some math
A lot of RPA design is a “math exercise.” You are calculating the amount of time that it takes to complete a transaction, and the volume of these transactions to determine the cycle time:
processing time x volumes = cycle time
Then you evaluate how and where the robot will impact the process, and what the improvements in cycle times will be.
Calculate how many robots you need
A robot can perform one process at a time. The number of robots needed to complete all of the transactions being processed is a function of the robotic processing time and volumes, plus the timing when these transactions need to be performed.
For example, if you need all transactions completed by 11:00 am every morning, and the data is not available until 8:00 am, you have a 3 hour window to get it done.
If you have 300 transactions that need to be processed and it takes the robot 30 seconds to process each transaction, you will only need one robot to perform the work (300 transactions x .5 minutes = 150 minutes, with 180 minutes to get it done.)
However, if the same transactions takes 1 minute for the robot to complete, you will need 2 robots to complete the processing of these transactions.
This seems simple enough, but in my experience this is often an overlooked element in the planning and design. People either “overkill” the processing with more robots (and cost) than needed, or get caught short because they didn’t do the “math exercise” properly. With RPA, be advised that there will be math.
Lesson #3. Designing an RPA process requires a certain “elegance.”
In addition to capturing all the steps and exceptions in a process, and designing the proper workflows around them, one of the classic mistakes I have seen developers make is to build large, complex workflows to perform the robotic process.
An RPA best practice is to break workflows into manageable “pieces,” one (robotic) step at a time. Breaking down the robotic process into smaller, “more elegant” workflows accomplishes several things.
- View the entire process. It allows you to easily view the process and workflow, and make sure that all the steps are represented.
- Capture and fix errors. Error handling is much easier, as you can identify more quickly where the process breaks down, and how to fix it.
- Easily modify the robotic code. When a process or the underlying infrastructure changes, you only have to go into the workflows that are impacted in order to make the revisions to the robotic code.
- Re-purpose the code. It makes it much easier to “re-purpose” robotic code for other processes that have identical (or similar) elements in them.
Take Advantage of Re-Usable Automation Components
Just as important: don’t “reinvent the wheel”. Don’t just reuse your own code; take advantage of the established libraries of re-usable automation components (essentially pre-built, standard workflows for common activities) that many RPA platforms offer. This will save you a lot of time and effort building your bot.
Also consider working with platforms that have pre-built connections to well-established software platforms such as Oracle, SAP, Citrix, Salesforce, etc. This will make the robotic implementation process faster, easier and more efficient to deploy.
For fairly simple processes, using pre-built process recording functionality is a great way to capture these processes, without having to code them. Not all RPA platforms have recording functionality, but when first getting started with RPA, this tool can really help you, and reduce your dependency on technical resources to write code.
Lesson #4. What about IT?
It is important to have IT involved in RPA deployment initiatives, but not necessarily to lead them. RPA should be a business-led initiative.
Why? Because the business users are the ones who truly understand the processes, and the business rules, timing, variants and exceptions that occur.
Ultimately, the robot will reside in the business operations, performing tasks that were previously done by human workers, so “embrace the bot” (name it if you have to) and make it “part of your team.”
IT plays an important role in the implementation and use of RPA. Work with IT on how and where the robot will “sit” in your infrastructure. Whether it is sitting on a server or workstation in your operation, or somewhere in the cloud, IT will need to manage the underlying infrastructure that the robot is leveraging.
IT should also handle the set up and administration of the robot’s access to the systems it needs to work with. This often becomes a sticking point with IT, as they are concerned about the permissions given to a robot, and the security required to ensure that it cannot be “hacked.”
Access Control Considerations
For permissions, a robot is typically set up with role-based access control based on the system access that it needs and the tasks that it will perform.
Many RPA solutions offer a credentials vault, wherein the robot’s access and passwords are stored and managed, providing another layer of security between the robot and the outside world.
However, defining (and limiting) the accesses given to a robot can sometimes be a challenging task, because in certain processes a robot will need to access several systems to perform a task (much as a human worker would).
Clearly defined access requires a strong robotic process design to make sure that you capture all the steps and systems needed, and only those required steps (and systems) are made available to the bot. IT and the business should work closely on ensuring that this is properly managed.
RPA Security Features
As for security, the robot will only be as secure as the security of your existing environment. Most RPA platforms offer robust security features, such as:
- Data encryption
- Credentials vault
- Credential expiration and renewal
- Account locking
- Overall security management
- Access control management through robotic monitoring and control software
Again, IT and the business should work closely to ensure strong security protocols are established around robotic processes.
Another key role that IT plays is in managing the systems and infrastructure that the robot utilizes. Changes to systems (upgrades, etc.) or infrastructure (failed devices or newly installed devices), even something as simple as changing the resolution of a screen, can cause the robot to crash or stop working.
There needs to be a strong communication between IT and the business on any changes that are being made which may impact the robotic process.
This communication should occur in advance of any changes, so that the RPA team can prepare for the change and can react quickly to address it.
Why does your IT department fear RPA?
RPA is a relatively new technology for many organizations, and as a result, most IT departments are unfamiliar with it. Unfamiliarity in this case often leads to fear and suspicion.
IT can sometimes be a roadblock to RPA deployments, rather than a facilitator. But the technology is sound, well established and has a large and growing install base.
Accelerate your RPA Journey with the Right UiPath Implementation Partner
Engaging with IT early, getting them involved where they need to be, on board and working collaboratively with the RPA Team, is the best practice.
Lesson #5. Know Your Bots.
There are many “flavors” of RPA and several different kinds of robots. Understanding which one best fits your needs is another important factor in a successful RPA initiative. Don’t “overkill” RPA processes with robots that are not needed. Make sure you understand which vendors provide the best range of solutions to meet your needs.
3 types of RPA automation that serve different needs:
- Attended Robots work with a user. They are designed to take on the manual tasks within a process, while the human worker handles the more complex aspects of a task. Sometimes they are referred to as “Virtual Assistants”. They are found in many back office processes that require human judgement or interaction. They can be deployed locally on a workstation or centrally through a server.
- Unattended Robots manage end-to-end tasks which require little or no human involvement (think pure data entry). They may have the capacity to use business rules to automatically determine how to handle a transaction when a decision point is reached. These robots are generally deployed, managed and controlled from a central server, which can schedule the robot to perform the designated tasks automatically.
- Cognitive Robots (a/k/a “AI”), takes the Unattended Robot into the world of advanced decision-making, using machine learning and natural language processing to “understand” the nature of a transaction and the judgements required to complete it, “learning” from a pattern of prior transactions to understand how to handle the next one. This technology is still somewhat of a work in process, and is not commonly found in most back office operations today.
Larger Scale RPA Implementations
One of the challenges that organizations are starting to see with larger scale RPA implementations is capacity and scalability management, as sometimes the central server’s capacity gets strained from the volume of robotic processes and the log files that these processes generate.
Logging Functionality
Most robotic solutions have logging functionality, recording every step that the robot performs. This is extremely useful for troubleshooting and audit purposes, but can create capacity and scalability challenges for the organization.
Centralized Management Platforms
Most robotic solutions have centralized management platforms that can automatically monitor and optimize the robotic environment, shifting robots to other workstations or servers when performance is impacted or capacity becomes a concern.
Having a strong RPA Administrative function, knowledgeable of robotic technology and its supporting infrastructure, is another important part of a successful robotic operation.
RPA adoption is still progressing
There are many benefits that can be attained from RPA technology, but it’s not without its challenges, organizationally, operationally and technically.
Emerging technologies have equally emerging best practices, and RPA is no different. There are many lessons to be learned for a successful RPA deployment, and one is to get the right guidance and support when getting started.
As for, “Where are We With RPA”, my belief is that there is still a ways to go before this becomes commonplace in the back office. The technology is advancing, as is its adoption, but the knowledge is still lacking for most organizations.
Want to gain better insights into the current state of RPA?
Auxis has just completed a survey of over 100 organizations to quantify the current state of RPA, and help to provide some context and perspective on the challenges that they have encountered and the benefits that they have attained.
Get a clearer picture on “Where Are We With RPA?,” by downloading a full copy of our 2018 RPA Survey Report.
