When my wife was pregnant with our first child, many moons ago, the book; “What To Expect When You’re Expecting”, was required reading for both of us. The thinking being we’re in this together, so we need to prepare together. To say we were prepared for the blessed event is an understatement. The child’s name was picked, his room decorated, mom’s eating and prenatal supplements regimen defined, baby wellness visits and tests scheduled, transportation routes to both the primary and backup hospitals mapped out, etc. Nothing was left to chance. And thank God, all went off without a hitch.
However, as prepared as were for the road leading up to the “go live” event, we quickly learned how woefully unprepared we were to manage our new production environment, as our little bundle of joy transitioned into our little bundle of maintenance. And those maintenance requirements grew and changed every day.
Most organizations are still in the early stages of their RPA journey. RPA COE’s are being established, vendors are being evaluated, candidate automation projects are being reviewed, etc. All fun stuff, no doubt. I say ‘fun’ because, like the analogy above, though hectic, planning these activities is the fun part. The technology is new, expectations are high, and the possibilities are seemingly endless. But once the baby is born, everything changes. The baby showers and office parties are over, the well-wishers have moved on, and even grandma has gone home. And you and your partner are left to deal with the diapers, the sleepless nights, and of course, your day jobs.
It’s easy for newly minted RPA professionals to focus on the fun parts of the journey because the fun parts often come first. However, how one prepares for what comes after launch has just as much impact on the RPA initiative’s success as anything else. For RPA to be successful long-term, the program, like children, requires; nurturing, monitoring, guidance and at times, discipline and course correction. To this end, let’s look at some of things you should be expect when you’re expecting to roll-out an RPA initiative.
1) Humans Must Manage the Robots. While it is true RPA bots free up a lot of human resources, the bots cannot function optimally without the human touch. That human touch should be primarily delivered by the person defined in our Ratchet-X Methodology as the “Production Manager”. Regardless of whether the Production Manager is an IT liaison, or more common in my experience, a representative from the user organization, this person will ultimately be a major determining success factor. This person does not have to have a strong technical background but must be comfortable with the technologies and applications involved in the automation. The Production Manager often serves as the first line of support so he/she needs to be organized and have a rapid, yet methodical approach to problem solving. For more on the functions performed by the Production Manager, see my article entitled; RPA Projects – Roles and Responsibilities”.
Expect production bots to perform under the guidance of a human, and that human is the Production Manager. Budget and staff appropriately.
2) Keep Staging and Testing Environments Alive. After a project rolls into production, there is a temptation to repurpose the staging and testing virtual machines. This temptation should be resisted because that environment is still needed to help diagnose errors and develop and test future automation modifications. VMs are inexpensive and developing automations on live systems is no fun. Don’t skimp on this area and select vendors who offer testing and staging bots for a nominal, or no fee.
Expect to keep the staging and testing environment around in some form for the life of the automation (though you can scale this environment back to a certain degree).
3) The Project Spec Is Not A Historical Relic. For time and immemorial, keeping project specification documents in sync with the current production system has been a challenge, even for the most disciplined organizations. However, one of the most important assets that lives alongside the automation is the spec document. In the Ratchet-X Replay Viewer, a platform component that allows users to view a video replay of any transaction performed by a bot, each video is accompanied by a synced version of the spec allowing anyone, even those not intimately familiar with the process, to know exactly what the automation is supposed to be doing. Seeing what a given bot is doing and understanding exactly what the bot is supposed to be doing presented in a “language” the user understands is the best way to get problems diagnosed and quickly resolved.
Expect the spec to be a living, breathing document that needs to be updated any time the automation is modified.
4) Rejection Queues and Real-Time User Prompts Need to be Owned. Dealing with errors is a natural, and more frequent than you might expect, part of managing an automation. Whether the errors are data, connectivity or process-related, the goal should be to detect and fix them fast. The best way to accomplish this is to ensure each exception is routed to a queue or person who can be responsible for handling the exception. If an exception is routed to a rejection queue, make sure that queue is monitored, and the appropriate people alerted. If the exception generates a real-time user prompt, make sure the prompt is routed to a person or group who has the required “skills” to resolve the issue, and that each prompt has a reasonable time out and a fallback rejection queue defined.
Expect error handling to be a normal part of the process and do not let exceptions fall through the cracks. It is a best practice to designate the Production Manager as the final check on all rejection queues.
5) Not All Automations Should Have the Same Support Access Control Configuration. The Ratchet-X platform allows for the creation of a support network for each automation type. This allows the Production Manager and external Tier 1/Tier 2 support to be connected to all aspects of a given automation’s execution, (i.e. the bot VM, the video recording, logs, spec and testing and staging environment). By creating this network, all parties responsible for providing support can do so on a timely basis by having access to the same resources. We have found linking all support parties through our issues subsystem has significantly reduced resolution times by eliminating all the back-and-forth associated with replicating a given problem. In fact, in many cases, Tier 1 and 2 support can detect and solve an issue before the Production Manager actually reports the problem. While this is a great capability, not all automation types are created equally and may require different layers of access control based on the sensitivity of the transaction. This being the case, give careful consideration to who can see and access your automations, assets and environments.
Expect to build support into the RPA framework.
6) Bursting and Scaling Considerations. While some automations lend themselves to consistent volumes and execution times, this is often not the case. Transaction volumes and varying integrated application performance can dramatically affect how many bots will be needed in production. So, I recommend:
a. If you are paying for RPA based on the number of bots, buy fewer bots upfront because you probably will need fewer bots than you estimate. Unless your RPA vendor is giving you a significant quantity discount, it is usually more cost-effective to buy less upfront and purchase more later, than to buy more than you need upfront.
b. Seek out vendors who provide RPA as a service to accommodate your fluctuating needs. RPAAS providers generally allow customers to throttle configurations more cost-effectively than organizations managing the dynamic environment on their own. This can apply to both the bot VMs themselves (if security constraints permit), and the supporting RPA infrastructure.
Expect to adjust the number of bots deployed and your management procedures to fluctuate based on varying workloads.
7) Supplemental Automation Rules Can Get Out of Hand. Most good RPA platforms allow users to define on-the-fly supplemental processing rules based on the user’s responses to a real-time user prompt. While this feature can be quite powerful, it can also get out of hand rather quickly. So, I recommend:
a. Define the parameters associated with supplemental rule learning narrowly. Since supplemental rules are often open to interpretation and apply to all future transactions, it is important the supplemental rules are narrowly defined and reviewed frequently to make sure they do not alter the automation’s institutionalized rules in unintended ways.
b. Align Supplemental Rule Creation with Skill Sets. While routing a prompt to a person without the requisite skills to handle a prompt can create small problems, allowing a person who does not possess the requisite skills to create new rules can be catastrophic. Make sure the only users empowered to create supplemental rules are those armed with the skills to make such important decisions.
c. Review Supplemental Rules Often. If your automation allows for supplemental rules, it is a best practice to review them often for accuracy and institutionalize the most important rules within the automation itself. By doing so, the rules will become “official” and make their way back into the spec document.
Expect supplemental rule definition to create a bit of mayhem if not strictly monitored and controlled.
8) Reporting and Analytics Are Important. Because there is a perception that bots, especially unattended bots, run just fine on autopilot, it is important to review the metrics and analytics associated with your RPA program frequently. This not only includes analytics related to errors and exception handling, but also keep a close eye on performance metrics to ensure the bots and integrated applications are performing as expected, and the bots are being utilized in the most cost-effective manner. Just as we stress “spec’ing the negative” in our methodology, you should “analyze the negative” as well. While we hope reporting confirms all is well, the main purpose is to detect potential and/or growing problems.
Expect to develop a reporting review regimen to keep things running smoothly.
9) Put the Humans to More Meaningful Work. RPA is valuable because it performs repetitive tasks faster, longer and more accurately than humans can. Further, shifting low-value added work from people to bots has the added benefit of freeing up human resources to perform more higher-value added functions for the organization. This shift of human capital should not be taken likely for the following reasons:
a. Rarely are organizations afforded the opportunity to reallocate experienced people en masse to important and often neglected functions. If planned correctly, this shift can dramatically increase RPA’s ROI by factoring in the increased value provided by humans focusing more intently on tasks that only humans can perform (at least for now).
b. Idle hands are the devil’s workshop; idle lips are his mouthpiece. If displaced workers are not presented with a credible plan that depicts a brighter work day or stokes fears of job elimination, you can’t expect them to support the RPA initiative. In fact, it is possible they will proactively work against, and speak ill of, the initiative as a means of self-preservation. Make sure each user performing the shifted process clearly understands his/her changing role and that automation represents for him/her an opportunity to step up.
Expect to devise and execute a meaningful transition plan as early in the process as possible for users whose work is being shifted.
No doubt, rolling out RPA is an exciting endeavor. However, it is important to recognize that RPA is not about setting up some bots and putting everything on cruise control. Knowing what to expect and devising appropriate action plans that include managing the less glamorous parts of the initiative are just as important to the initiative’s success as selecting vendors, tooling and candidate processes.