Improving business processes before introducing robotic process automation prevents doing work poorly, unnecessarily, and redundantly. RPA streamlines processes, but only when implemented effectively.

---

To improve or not to improve, that is the RPA question?

Sorry to Mr. Shakespeare for taking such an iconic line and turning it on its side, but it is fitting when we speak about the current RPA environment. For those who are unaware, robotic process automation (RPA) is a way to enhance the work experience by taking routine, repeatable, and rules-based tasks and turning these into software robots (bots). Then you use your choice of RPA tools offered by a multitude of vendors. However, this blog is not necessarily about RPA. It is about the process you want to automate and whether you should first improve the process or automate “as is.”

Improving Processes First

In conversations I’ve had with individuals and organizations across a variety of industries, there is a consistent stance for improving processes first and then automating. I, too, am in the “process improvement first” camp. Generally, if a customer chooses automation with no thought on improvement, I recommend otherwise. Automating as is, ultimately results in establishing an inefficient process that returns poor results, immediately. There are organizations that take the approach to automate everything brought to their attention with the intent of running it for some time, capturing the learnings, and going back and improving the process so they can modify the automation afterward. The issues I see with this plan are two-fold:

• Does an organization actually go back and modify the process afterward? Most likely, not.
• Aren’t you in some sense “re-inventing the wheel” changing a process after the fact, defeating the purpose of the initial automation?

Take the Time to Review

I learned early in my career an acronym I have used in all my projects and engagements. DIRTFT, pronounced “dirt foot,” stands for “Do It Right The First Time.” I am a firm believer in taking the time (and cost) upfront to review and make a process more efficient before looking at the potential for automation. Throughout that review and improvement of the process, you may find at the end of your improvement cycle, you create a process efficient enough automation is no longer needed. Or, you may find there are other technologies already available in your organization that might supplement your process without the need for an RPA automation cycle. Regardless of the outcome of your analysis, the first step you should take is a thorough review of the process. So, if at the end of that review RPA is still a viable solution, you are already ahead in meeting process requirements. Another plus for the “review for improvement first” camp.

Exceptions to the Rule

Now, this does not mean every process needs an initial in-depth evaluation determining the need for improvement first. I have spoken with organizations that have automated right from the start, knowing in some cases the “code” is throwaway code because their longer-term strategy includes a larger overhaul of the process or processes, as well as the applications used as part of the process. They believe short-term automation provides a lift for their long-term plan. If your organization agrees with that approach, consider this option. As you look at your processes for improvement and automation opportunities, to enhance the automation experience, keep the following areas and decision points in mind:

Is Your Process Routine, Repeatable and Rules-Based?

• The actions are consistent with the same step being performed repeatedly. Typically, repetitive processes are susceptible to human error.
• You can break the process into unambiguous rules that apply to most transactions.
• You repetitively enter data into specific fields into a template.
• It is rules-based, allowing decision flows to alter dynamically.
• The process, once started, needs limited human intervention. You can also partially automate decision-heavy processes.
• The process requires only limited exception handling.

Automate simpler processes first, then focus on more complex processes only when the company matures its RPA presence.

What is Driving the Need for Automation or Efficiencies?

A few areas to take into consideration:

• Continuous Volume and Handle Time: The value of automation increases with the increase in volume and handle time of processes.
• Error Rate: Processes which involve a high error rate are great candidates for automation which ensure flawless execution.
• Standardized vs. Exception-based Process: RPA is built to handle multiple use cases and rules-based exceptions. However, I recommend you look for the simpler, standard processes for quicker development time and more expedient ROI.
• Frequency of Re-keying and Collating Data: Processes composed mainly of copy and paste of information from one system to another or data validation (comparing data from one application to another) greatly benefit from automation.
• Process Adherence or Compliance Problems: Inconsistent processes are prone to security, compliance, and regulatory issues.
• Process and Underlying Application Stability: Your processes and target applications do not undergo frequent changes.
• Thick Client vs. Citrix: Processes in non-Citrix environments are more efficient, faster, and less complicated and challenging to develop (although Citrix environments are easily supported as well.)
• Speed of Underlying Applications: Targeted applications are generally faster and more effective, allowing for more efficient and quicker automation. Older legacy systems, those built on older infrastructures, are targets for automation, but the results may not be as positive as more robust applications or infrastructures.

This is not a comprehensive list, but a starting point.

What is the Complexity of the Current Process?

If you are unsure as to whether a process is too complex for automation, take the following points into account as you perform your analysis:

• There are no more than five decision points in the current process and those decisions are easily defined and objective.
• There are no more than five integrations or applications used as part of the process solution, such as internal applications, external websites, internal sites like SharePoint.
• There are no more than 40-50 clicks in the process (based on my experiences, most processes do not come close to that threshold).

In Conclusion

Regardless of which side of the process improvement first versus automation first coin you land, determine what makes sense for your organization in the short-term and long-term. Engage other companies going through an automation strategy and observe how they approach the improvement vs. automation question. There isn’t a singular answer to the question posed at the beginning of this post, but the important thing is you think about it, otherwise you may find yourself asking this question later; “’Tis nobler in the mind to suffer the slings and arrows of outrageous fortune, or to take arms against a sea of troubles?” (Thanks, Will!).