TURNING ROBOTIC PROCESS AUTOMATION CHALLENGES INTO REAL SOLUTIONS

 Sharing an interesting article from SHAUN DAWSON

https://digitally.cognizant.com/rpa-case-study-challenges-triumphs/

Not all Robotic Process Automation (RPA) projects go smoothly. In fact, sometimes it seems like bumpy roads can be the norm, rather than the exception. How should you approach a troubled RPA project? What practices can be applied to turn a project around when things go sideways? I’d like to share an example with you.

Not long ago, we were engaged to revive a flailing RPA project. The existing vendor had not delivered (meaning deadlines were being missed, and code that seemed to work one day would break the next without warning) and we were asked if we could turn it around.

THE BEGINNING

Initially, we approached the situation as a technical challenge. There were a number of code quality issues that we felt would be resolved by migration to a strong overall design program. The customer had chosen UiPath as their RPA tool, so the first thing we did was migrate the implementation over to Cognizant’s UiPath Platforms methodology.

Platforms is a UiPath design pattern that we developed to provide design consistency, code modularity, and automated testing of components. This was the best tool for the job.

THE PROBLEM

The first indication that there was an issue started with the Exception Rate. In RPA implementations, the Exception Rate is a measurement of the transactions that encounter Business Exceptions instead of being successfully processed. Initially we typically see Exception Rates around 20% as a rule of thumb. This normally decreases fairly quickly as the automation is enhanced to accommodate for these cases.

In this case however, the Exception Rate came in higher than normal at 30%. Normally, this would be somewhat minor and not a huge cause for concern, but under the circumstances, this customer was extremely upset. It turns out that originally they were told to expect a very small 2-4% rate of exceptions. This was not a realistic starting point and, as you can imagine, we were off to a rocky start.

But there was another problem as well that, combined with the Exception issue, threatened to throw the entire engagement into a tailspin. The customer was not able to provide us with development systems, only production systems. This meant that development had to be done on the production robots. These robots were slated to run 20 hours per day, which left only 4 hours a day when the robots could be used to address the issues that were causing the Exception issues. To add insult to injury, the robots were taken down for those 4 hours because the production systems that the robots were working with were undergoing routine maintenance. This made them unreliable during those times and that meant development work was nearly impossible.

THE REAL PROBLEM

How could we turn this around? The first step was the realization that the technical problems we were seeing were not the root problem. After a bit of sleuthing, we determined that the real problem was a communication issue between the RPA implementation team and the business team:

1. The Exception Rate issue was only a problem because the customer expected an unrealistically low Exception Rate. They were not expecting a typical rate of exceptions in their initial release. Had the customer understood that the rate would start off higher and then quickly taper down, they would have been able to plan accordingly and this would not have been an issue.
2. The customer did not communicate effectively to us that we would be losing our development systems once we went to production. This meant that we were not in a position to either set appropriate expectations about issue resolutions or push back on the disappearance of those resources.

With the technical problems morphing into communication problems, we still found ourselves in a situation that could go South.

THE SOLUTION

Fortunately, although communication problems are sometimes difficult to diagnose, they are relatively simple to fix. Here are the communication principles that we have developed to ensure success in our RPA engagements:

• Plan skeptically: Avoid overselling and remember that the benefits start slow and get better over time in a properly-run project.
• Define and agree on metrics in advance: Everyone must be on the same page when it comes to business outcomes for the project.
• Set expectations for metrics and time frames: Agree in advance on these issues, and have a written plan.
• Regular reporting: A regular reporting cadence is important.
• Single Points of contact, with escalation predefined: Someone needs to be the Skipper.

In the case study above, it worked out to have a happy ending. But, we might have saved time and trouble had we gone in from day one with the realization that there might be a communications problem. How do your projects fare on this scale? Is the appropriate level of discipline present?