RPA Design for development – Disrupt or Destruct
Three years ago, when we demonstrated an RPA process to a crowd, I remember there being an applause in the room.People were stunned to see how a manual process was being seamlessly transformed into a process sans people!
Today, a lot of companies have already RPA’edsome of their lowest hanging fruits such as input of structured data into multiple systems, RPA+OCR for structured, semi structured image based processes etc. They have a choice of the service provider they use. Theyresearch, train and are well acquainted with what services and features each provide. Service providers are now showered by symbolic bouquet of questions: What makes you different? Why can I not just buy licenses and train my team? Why do I need you? Why should I opt for you? One now needs you to prove your worth to secure a seat at the round table of knights – where customer is king.
It’s not just automation that has become more intelligent!
So let’s pick at that key question – What makes that difference???
A few years ago, I had some work done in my kitchen. However I was on a timeline and had to get the job done pretty quickly. My architect assured me he would take care of things and would deliver on the promised date.
Then it began – first he said if he has to accelerate the work – he will need more workers, which wasn’t estimated in the original cost. He would have an array of questions that would require me to step away from my work and help resolve it. Needless to say I was over stretched managing both my work deliverable and the architect requirements. Finally after what seemed to be a lifetime, countless arguments, unforeseen delays, my kitchen was ready and I was pretty excited! The next few weeks were great, everything worked fine and the money seemed well spent. But then the drawers started getting stuck. The alignment of the cupboards seemed off. The magnets on the doors seemed weak. I called my architect and he came to fix these issues – once, twice, thrice. He then told me the design I had selected was not suited for the material used which is why the drawers were getting stuck. Hence I will have to redo the drawers again. This of course will be a cost. I had painted the side of my wall which started chipping off in a few months. I was told this is because there are leaks and we didn’t identify them before as we had tiles and the leaks were hidden. So either I re-tile it or repaint it, of course that will be an additional cost. In summary – at the end of 2 years, I had redone my drawers twice, worked on the leaks, painted, re-painted, re-tiled my wall, the alignment of the doors were still off and my leaks are still unfixed. The cost of maintenance tripling the cost of the original product.
This story resonates with meinferringthe state of our current business operations. Ironically, getting an RPA solution today is probably a lot easier than selecting which phone to buy!
However, if the solution designed is not compatible, it will keep impacting multiple areas, thereby, keeping maintenance costs perpetually high and vastly impacting cost of operations.
Recently, I encountered a client, servicing over100 processes across 300+ clients. The job here was executedby approx. 1200 processors and the client was looking forward toengaging some major automation initiatives, to bring down the operational costs via headcount reduction.
The major challenge here was that the processes being so large, providing an optimal solution is a mammoth task. If the objective is to reduce headcount by 30% i.e. around 360 human efforts out of 1200 – it does not mean it will be replaced by 300 Bots. Hence how do you determine if the design solution is providing optimal value in terms of costs and stability?
4 key aspects define design effectiveness
- 1. Volumes and Delivery Timelines
This is a very critical aspect and the first consideration for any design solution. In the case of this client, each process had about 15,000 to 20,000 transactions to be serviced per day. That results in around 1,500,000 transactions per day across 100+ processes. Each process is defined by its own turnaround time commitments, hence, the solution design has to cater to those requirements. If the process has a larger turnaround time, the BOT’s can take longer time to complete the processing. However, if the delivery timelines are very stringent then additional BOT’s will be required to process the same number of transactions at increasing costs.
- 2. Variance in processes
For this particular case study, we werelooking at firstly 100*300 processes to automate (100 processes across 300 clients). To add to the complexity, each process had an average of 50 to 60 sub-processes, which werefairly independent in nature – the total would seem like 100*50*300 processes.
In this case, a proper study of the processes is a mandate. In most cases providing solutions for such complexity generally is confronted by two main issues.
- 1. Most of the times, BOT’sare programmedwith all the different variations of the process to keep licenses minimal. However, the flip side to it is it will invariably increase BOTdevelopment time. Post deployment, it may impact the BOT processing time and the frequency of BOT downtime. They may also not function adequately where timelines are stringent.
- 2. To combat the previous issues, the easier option generally adopted is to deploy the number of bots as per the variances in the processes. Higher the variances, higher the number of bots. This solution will drastically increaselicense and maintenance costs.
The optimal design objective would be to incorporate an overarching solution across multiple processes and with the help of technology, tackle variances. This needs to be achieved within the stipulated timelines and minimal botlicences.
3.Scalable solutions and BOT onboarding
Here’s another important aspect that should be introspected in every design. Is the solution deployed scalable? The current business supports 300+ clients. However, should another 50 clients be added to this list, how easy is the change management process? Like humans, BOT on boarding time needs to be planned and considered from the very beginning.
4.BOT Productivity Index
Once a BOT has beendeployed, its efficiency and management becomes extremely critical. Here, we calculate the BOT productivity Index.
BOT Productivity index = Performance achieved/input resources consumed.
For example, if the objective is to reduce 50 human efforts but if we end up adding 5 just to monitor the queues, another 10 to process manual exceptions, 30% of that objective is already lost.
The methodology is to measure BOT effectiveness and efficiency and these metrics will define success quotient of the design.
The outcome of the designed solution is the difference that will set companies apart.
However, what makes the design for the solution provided ‘The Right one’?
This is quite a tough ask as it is quite difficult to assess the quality of the design solution at the onset. There however maybe a few critical aspects that can form a checklist to evaluate key areas (Development, Costs & Governance). This will highlight how robust and cost effective the design will be.
|1||Is a single solution being deployed across multiple processes?||Operational costs: Does the design target optimisation in development efforts and speedy time-to-market||What is the mechanism provided for real-time queue management?|
|2||How are BOT exceptions managed?||Licencing costs: Does the design target reduction in the number of BOT licenses.||How will I receive instant notifications of exceptions, errors and unforeseen circumstances?|
|3||How does the design address reduction in the number of BOT’s deployed?||Infrastructure costs: Is there a reduction in the number of desktops/Virtual machines deployed.||Can process owners manage and control selective Change management keeping the business fluid and agile, post automation?|
|4||Is the solution completely based on BOT development or are there a mix of IT interventions like API’s etc. to reduce costs?||Support Costs:How is Change management efforts addressed?||How will the data analytics and trends to reduce manual efforts and increase BOT efficiency be provided?|
|How is the solution scalable for future processes with minimal impact to current BOT processes?|
Automation is definitely getting intelligent and will change the delivery outlook completely.The question should not be “who” is bringing that solution but “what” they bring to the table!
Often the solution implemented will either be a Design developed for Disruption or Rework to destruct Development.
Best to choose wisely!