The Adventure of the RPA Derailment

A week later, Holmes and Watson met up in the Mumbai Cigar Club, just before Watson was flying back to Amsterdam. “Hello my dear Watson!” said Holmes. “That was an interesting client case that took me all around India. Too long a story, so let’s continue our RPA investigation. Where were we?”

“We agreed to discuss how you can recognize a good from a bad vendor, big fat promises and under deliveries, successful agreements and success factors,” reminded Watson. “So, Holmes, with RPA still being relatively new: How do you recognize a good from a bad vendor? Or an experienced from an inexperienced one? This seems like a project where parties can really overpromise or underestimate the project”.

“You’re absolutely right, Watson. A good vendor will look for a detailed discovery exercise. If you find a vendor who tells you that they can automate a process in x weeks without conducting a discovery exercise, you may well be in trouble," said Holmes.

“Another thing to watch out for are big, fat promises. You will hear how RPA can bring enormous amounts of cost and FTE savings, efficiency gains, etc. This, my friend, needs to be assessed very carefully. You as a client need to challenge the vendor and understand their solution in detail. Remember, there are no easy rewards. If your process is very complex, fragmented, and spread across regions with multiple touch points – how on earth will you be able to automate such a process? At the very least it is going to take lot of time."

“Hmm, that makes sense Holmes, but even companies with complex, fragmented processes want to implement RPA. Where do they start?” asked Watson.

“Look for early and easy successes if you want to make RPA work. Start small, with less complex and high volume processes that can deliver quick savings,” continued Holmes.

“The next best practice is to have a comprehensive agreement. Don’t trust verbatim commitments. Even in a good relationship with a vendor, it’s important to have a fully written contract,” said Holmes.

“I recognize this, Holmes,” said Watson. “My client is very happy about their vendor so they did not expect any issues”.

“Watson, I see this often,” Holmes interrupted. “The contract should not only cover the scope and activities but the vendor should be able to contractually put down the benefits he is going to deliver through RPA – and commit to it. It means that clients need to have the expertise to contract and negotiate with the vendors effectively.”

“That makes sense, Holmes, but I am sure it’s not only the vendors that need to commit contractually. When clients embark on a new project, they will be inexperienced too and make mistakes. What do they need to do to make the project run more smoothly?” asked Watson.

“That’s a good question, Watson. Indeed, clients have responsibilities, too. They need to ensure that IT has been involved at an early stage. It is the IT team that needs to ensure compatibility of solution and design of the RPA tool with the client’s environment. One of the risks that many companies do not plan for is they choose a tool and realize later that the integration of the tool to mainstream IT applications and infrastructure has not been planned. This takes a toll on the timelines. Remember, the RPA tool is going to access applications where the processes are operated upon. Hence, it is not only an integration concern but it can also be a security concern. This brings me to another point – Get your security checks done on time,” exclaimed Holmes.

“All of these are very important aspects of due diligence. Do not get into a contractual agreement unless all of these steps are verified and cleared by each department,” he added, finally finishing his case.

“So, my dear Watson, I would love to hear your investigation on how your client’s RPA journey turned from 6 weeks into 13 months?”

Watson looked at her watch and almost hit the roof of the Cigar Club. “I have to run and catch my flight!” she shouted. “Lets catch up by Web,” Holmes heard faintly as Watson was running out of the door. He smiled.

The free Sherlock Holmes - aka Ankur Bansal - summary:

1. Watch out for overpromising vendors who tell you that they can automate a process in x weeks without conducting a discovery exercise
2. Watch out for big, fat promises
3. Look for early and easy success
4. Have a comprehensive agreement where the vendor contractually puts down the benefits s/he is going to bring through RPA and commit to it
5. Involve IT at an early stage
6. Ensure compatibility of the solution to mainstream IT applications and infrastructure
7. Get your Security checks done on time

In our next article, The Case of Culture Mis-identity, we will look into how cultural differences turned an RPA implementation from 6 weeks into 13 months. Learn the warning signs that things are going wrong.

Read more from Ankur Bansal and Ilse Kerling in their SSON columns:

Smarter Outsourcing for Today's Enterprise – A. Bansal

Tools and Methodologies for Closing the Cultural Divide – I. Kerling