Once you have created the foundation for your RPA initiative and have identified a few “early adopters” who are willing and anxious to have some of their processes automated, and have established your governance policy and identified board members, it’s time to look ahead and see what challenges you may encounter. You can minimize some common mistakes by understanding what we did initially that wasn’t successful.
Throughout this book, we have mentioned many of the possible challenges you may encounter when starting your RPA journey. Some of these we were able to avoid, seeing the speeding bullet and figuring out how to dodge it. Some we crashed into head-on and then resolved the issue after the fact.
Expecting easy management acceptance. When faced with an opportunity to cut costs and improve efficiency, we thought management at least would welcome the new RPA program. We were mistaken. While line workers were sometimes reluctant, due to a fear of job loss, we were surprised by more than a little management resistance. Some managers seemed to think that RPA was the new buzz phrase, the solution of the moment, which would generate much excitement and quickly and quietly fade away. They had seen too many other “game-changing” solutions that had done just that. Others seemed concerned not for their own jobs, but for threats to their “empire”; they had X number of employees and didn’t want that number reduced. If a Bot was going to do some of the work their employees were now doing, they would possibly lose those employees, since they could be repurposed elsewhere in the organization or let go.
Tip If you are careful to follow the information in Chapter 2, you will be able to avoid this challenge.
Identifying the wrong processes to automate. It may seem simple to identify the right process; process XYZ is repetitive, so let’s automate it. But on closer scrutiny, it wasn’t as simple as we thought. As mentioned earlier, when you first identify a process for automation, you don’t know too much about it. But there are some “red flags” that we missed in some of our first attempts. For example, is a middle-management employee deeply invested in that process as it is currently performed? Would automating a process possibly step on the toes of a manager who does not want to recognize that their area could be improved? Or is it something as simple as an extremely complex process that could have been determined in a preliminary conversation? We learned in time to better discern these issues.
Attempting to automate an entire process when only part of it is a good candidate for automation. This is related to the item just mentioned. A process with multiple steps may be very manual and very repetitive, but that doesn’t mean that all of the steps can be automated at this time. The business owner may envision having the entire process automated, but that isn’t always reasonable. Remember, you may be able to automate a part of a process and still achieve significant savings in time or cost or provide a greatly enhanced customer experience. Look at the end-to-end process as you have mapped it, consider the time savings, and if only some of it can be automated, and that will achieve good results, then automate just that part of it. Work with the business owner to determine what may need to be done to make additional steps in the process better candidates for automation in the future.
Attempting to build the Bot without the required expertise. The developers who will do the actual work of building the Bot must have the knowledge to do so. Enthusiasm is great, but it isn’t a substitute for experience. Be sure to have at least one developer on the team who is highly qualified in RPA. They can mentor and train less-experienced developers.
Pause and Consider What potential “land mines” can you foresee in your organization? Who are the people who are particularly protective of their areas? How would you approach them if you are aware of process opportunities in their areas?
Governance board meetings. Initially, we submitted the document package with the intake form, business case, risk assessment, and other documents several days prior to the meeting to the governing board members. They and the requestor(s) were invited to the weekly meeting to review the request.
We found that, generally, no one read any of the documentation prior to the meeting. Therefore, instead of sending out detailed information in advance, we summarized the information into a page or two which we presented at the meeting. We stopped sending the detailed documentation, but maintained it for our records and just provided a high-level overview of the request at the start of the meeting. This overview consisted of the following:A brief description of the request (e.g., automate process XYZ which currently takes three people two days every week to accomplish).
A review of the savings (e.g., this will free up 2,250 hours per year [3 people times 15 hours per week times 50 weeks per year]). Multiply this by your company’s hourly rate.
An evaluation of the complexity of automating the process (e.g., high, medium, low).
An estimate of how long development will take (e.g., three weeks).
The architect who worked on the initial estimates should be present to answer questions.
Unfortunately, people often don’t read required information before meetings. What is your experience in your organization? Do decision-makers come prepared? If not, how do you usually reach decisions in meetings? How will you prepare decision-makers for RPA governance meetings?
- Inviting the requestor to the governance board meetings. We initially thought there was an advantage to this, in that the requestor could answer some questions about the request that the governing board members might have. But those questions were able to be answered by the business process analyst or the architect, and if the request was not approved to move forward, it didn’t provide anyone with the opportunity for tactfully explaining this to the requestor. Now if a request is turned down by the governing board, the requestor will receive an email similar to the following:
“Hello (name),
Thank you for your recent request to have process ABC automated. We have reviewed your request and evaluated the costs of automation, savings to be accrued, urgency of need, and other factors. At this time, there are higher-priority requests that we must focus on. Therefore, your request will be placed on hold to be periodically re-evaluated.
If you are aware of other processes that could possibly be automated with this one, please advise us.
If you have any questions about this, please contact me.
Sincerely,
(Name)
(Title)”
In the governing board meeting, the discussion is generally more direct, with board members possibly saying the process isn’t worth automating. This discourages the requestor from submitting other requests and casts a negative shadow on RPA.
Sometimes a process isn’t right for automation, but there may be other areas of the company that could provide some assistance. In those cases, that information should be included in the email to the requestor, and the RPA team should engage that other area and refer the request to it. No further work, except for the periodic re-evaluation of all projects on hold, is required for this particular request.
How would you best advise a business process owner who requested automation of a process that that request was denied? Remember, you don’t want to leave them with the impression that their request itself was not valid, only that the numbers didn’t work well enough to proceed.
Not obtaining sufficient information early on. Sometimes, even when we worked with the requestors in completing the request form, there was information missing. We adapted the form going forward and eliminated that issue, but be aware that the requestor may not have all the necessary information. That is why it is vital to meet with subject matter experts, the people who know how the process actually works, not how the documentation about it says it should work. There is often a significant disconnect between the two.
Tip Remember, the templates are made to be tailored to your specific needs. You may want to use them “as is” initially and see what works and what doesn’t work for your organization.
Not adequately addressing concerns about job loss due to automation. Sometimes this could be a real fear; management may see headcount savings as an advantage to automation. No one wants to assist someone in causing them to lose their own job.
Pause and Consider It’s possible that the goal of any particular automation may be to reduce headcount. How will you deal with this? How will you get assistance and information about a process from people who may be fully aware that by automating the work they do, they will be out of a job? What assistance and support can you get from your HR organization or senior managers?
Trusting existing (old) documentation. When a new process is introduced, there is often accompanying documentation. This documentation explains the purpose of the process and, more importantly, how the process is supposed to work. However, there is often a major disconnect between how the process is supposed to work and how it actually works in day-to-day practice. Sometimes when a request for automation is received, that documentation will be provided. But it is vitally important to map the process with the SMEs, the people who are actually doing it. A process may work very differently from the way it is supposed to work, and the longer the process exists, the farther it may be from what was initially documented. Be sure to map the process as it actually is performed today.
Tip Process mapping with the SMEs will assure that you understand the way the process actually works. Do not rely on any existing documentation.
Selecting the wrong tool. There are many things to consider when selecting your RPA tool, including how much programming it requires to meet your needs, how scalable it is, what is its record of changes and promptness in providing updated features, and how much maintenance does it require? And a big one for management, what is the cost? Just because a tool is expensive doesn’t mean it’s the best. Do your research: look online, talk to industry peers, and review journals to find out what RPA tools would work best for you. Remember, a tool that is ideal for one organization isn’t necessarily the best one for every organization. Do your homework and avoid this pitfall.
Overconfidence of the business. Once the Bot is up and running, there is always the risk that it will fail at some point. In that event, there must be personnel ready and sufficiently knowledgeable to manually perform the process until the Bot is once again functioning. Generally, there are one or two people assigned to handle the exceptions that the Bot can’t handle (such as invalid client IDs as indicated in our case study), and they are usually the people who would take over in the event that the Bot stops functioning. But we found that this sometimes needs to be reiterated to our business partners.
This is not a comprehensive list of everything that could possibly go wrong. You will probably add to it with your own mistakes! But these are some key challenges that we either encountered or anticipated, and it’s important that you be aware of them.