Lot has been talked about RPA as a concept, benefits and trends. RPA has become so much of a commonplace now, that any business leader from support function organization not working on it, is seen as someone who missed the bus.
RPA may sound very simple and look enticing as a quick bang for the buck initiative, but when it comes to putting BOTs in production, it requires well-orchestrated execution and strong leadership to derive the benefits out of it. While still majority of the organizations are in early adoption stages with POCs and Pilots, it is imperative to understand the on-ground challenges and essential levers to adopt to put BOTs into production.
From my point of view and experience, I have listed down top 10 levers that need to be considered to succeed in RPA implementation journey.
1. Start with a Proof of Concept: Most of business leaders now understand RPA and seem to accept it as viable technology however, they are not convinced enough to try it out in their process. Showcasing RPA through a quick working BOT POC video, triggers the enthusiasm and it is essential for getting the initial buy-in from the process owners. For POC, choose an activity which everyone in the organization understands, configure automation and screen record the BOT performing the activity as POC video. Showcasing this POC video and its impact helps in evangelizing the concept of RPA among the process owners and get them share the vision of RPA. Try implementing the POCs through multiple RPA tools, which also gives opportunity to evaluate and select the right tool that fits well with your organization’s applications landscape.
2. Identify & on-board evangelizers : RPA challenges the way in which operations team have been performing the tasks, leaders are being measured and the way processes are engineered. RPA is a transformational journey and organizations require strong leadership will, long term sponsorship and core committee to succeed in this journey. It is imperative to identify first set of functional / operational leaders who are excited about RPA , supporters of change, and on-board them into core operational committee. Initial few production live implementations should be implemented in their processes since there will be strong will and acceptance from the business. Core team should be from the organization itself and not from the outsourcing service providers – since the objective of the RPA conflicts with their interest. Organization can take help from tool agnostic independent advisory firms to shape this journey.
3. Choose processes wisely : Success of RPA projects is as good as selecting the right candidates / processes for implementation. Almost 60% of RPA projects fail or benefits does not meet the cost of implementation, owing to wrong process selection. Many a times, business leaders with limited practical RPA knowledge and heavy prejudice, choose wrong processes and end up wasting significant effort in force-fitting RPA in that process. By seeing this result, other business leaders lose trust on RPA and misconception starts spreading within organization. Choosing first set of processes is very critical, as the success of this implementation would lay precedent for adoption of RPA across other processes in organization. Process selection has to be done only after thoroughly understanding the possibilities, and very importantly limitations of RPA.
The magic lies in having robust process selection and prioritization framework. We use set of criteria under the heads of ‘Ease of implementation’ and ‘Benefits derived’ and apply quantitative rating methodology across processes to assess its RPA suitability, and prioritize them for RPA implementation
Examples of wrong processes for RPA
- Process that involves performing activities on applications that undergo frequent changes / upgrades – not suitable for RPA as it would require re-configuration every time the application changes
- Process that depend on regulatory changes – may not be suitable for RPA, if the regulation changes result in activity changes– this would result in re-configuration every time the activity changes
- Process that have low volume / run few times e.g once in a quarter or annum – not suitable for RPA as it would not yield significant man-hours saving
Always perform a detailed feasibility assessment to identify and assess the scale of automatability of activities within process and baseline manual time spent on them. Choose activities that are rule based, consistent and are of high volume for RPA implementation.
4. Set the expectations low: There is a lot of hype around RPA and often times, the benefits estimated in business case are theoretical and high compared to what RPA can achieve on ground. Some business leaders come with a notion that BOTs would take over the entire process and completely replace all the human FTEs in the process, but in reality BOTs would be capable to perform only some of the activities within a process and human FTEs would need perform the rest of the activities alongside BOTs. Implementing BOTs and automating activities does not release FTEs form day 1, but gradually over a period of time because of following reasons
- Even after robust user acceptance testing on functional and non-functional requirements, we have seen not more than 70% of the transactions pass through BOTs immediately after production go-live. This is owing to business and technical exceptions which reduces gradually through training business users in BOT usage
- Not all the manual time spent that were earlier on automated activities are saved. Human FTEs would need to spend time on providing inputs (triggers and data) to BOTs, which was not the case pre-automation. So the net benefit will always be lesser than the time spent on automated activities.
- Many a times, automated activities are spread out across the process and human intervention are interspersed within the automated activities. To realize benefits of FTE savings, the activities within the process need to be re-sequence so that the automated activities are grouped together
Hence, it is advisable to factor in post-production stabilization period and set the expectation low on the benefits derived out of automation. Having said this, it is always good to set the expectations low and beating it in unproven territory.
5. Have complementing tools – RPA tool need not be the only tool of choice to automate all the activities. Consider having a set of complementary tools or point solutions ready with the help of internal IT / tool team and while performing automation feasibility assessment, select the right tools based on the nature of the activity. For e.g.: Consider OCR tools for extracting data from raw files, SaaS based ETL tools for data transformation, excel macro for data computation / formatting etc. RPA being UI based tool, can work well with other tools and play orchestrator roles tool of stitching together automation of other tools. This way the scope of automation is not limited to only what RPA tool can do.
6. Make IT integral part of the Journey: RPA is definitely a business led program, but not keeping IT involved from the beginning of journey will lead to disappointments. Unlike other IT implementations which takes months and years, RPA takes weeks to go-live. Hence, IT should also be prepared and nimble enough to setup environment & provision BOTs infra in short notice. IT need to ensure a robust architecture in place, that would allow fungilibility of BOTs between processes and ability to scale up / down number of BOTs to manage peaks & turfs in the volume of transactions. In some organizations, we have seen IT team bringing in information security issues and protocols just before the production go-live. Hence it is important to keep the IT team apprised enough of the processes to be automated and seek sign off before making investment in configuration.
7. Have robust solutioning focus: In any successful implementations, not more than 30% of the time is spent on configuration of BOTs in RPA tool. Significant effort need to spent in understanding the processing activities at keystroke level, its variations, trigger points and non-functional requirements like work volume variations, SLA commitment . Based on this, robust ‘To-Be‘ state of the processes need to be designed bi-furcating BOT and Human activities with clear exception handling mechanism. The solution design gets refined through the implementation with constant feedback form the process team members.
What should a typical solution design contain?
- Logics of how BOTs should be configured and take decisions during the processing
- Human BOT interaction/ handoffs : How would data pass from Human to BOT and vice versa in terms of variables and exceptions
- BOT estimation & scheduling: How many BOTs and how should it be scheduled to handle the work volume and meet the SLA commitment of the process
- BOT trigger points: What event / action should qualify BOT to start the activity
- Exception handling mechanism: Scenarios qualify to be exception and how should BOTs handle the exceptions
- Activity standardization pre-requisite: Activities which are automatable but not standardized need to be identified and standardized before configuration, so as to make the configuration as reusable as possible
8. Follow quick win delivery methodology: RPA implementations are faster and its chances of success raises if the configuration is broken into several small incremental configuration and follow agile methodology. Following a waterfall delivery methodology and covering all the requirements at once before configuration is not possible as most of the variations, exceptions reside in the memory of process associates and are not documented well. Configuration of BOT has to be first done for ‘happy-path’ scenario (scenario with no exceptions or variations throughout), test it and incrementally add variations and exception handling with immediate testing at each step. It is imperative to have the process team members sit alongside RPA configuration team for frequent feedback and provide input on incremental configuration.
9. Track and reap benefits continuously: Ultimate benefits of RPA is derived only when manhours effort saved through automation result in reduction of FTEs. It is important to have a baseline of time effort spent on the manual activities to track the post automation benefits. Business process team should take the ownership of tracking benefit through quantifiable framework based on BOT run logs. When the BOT run process reaches stabilization and when manhours saving are realized, business team should look at redeploying / reskilling the manpower. Till the estimated benefits are realized, have a dashboard published regularly to bring in accountability and transparency in the success of the program. Some of the areas in which the measurements can be done are:
- BOT performance: Utilization of allocated BOTs, Average handling time of BOT per Transactions, Number of technical (RPA tool related) exceptions per 100 transaction, % of transactions adhering to SLA commitment, % of transactions adhering to quality commitment
- Manual time saved: Number of manual runs Vs BOT runs, Time saved through BOT, Number of business exceptions
10. Plan for sustainability: Once the first set of implementations have gone-live and the methodologies are tried, tested and finalized – establish a CoE to industrialize these methodologies. Design operating model, comprehensive toolkit across the implementation phases, define governance and performance tracking mechanism. Parallely, build support mechanism team to provide ongoing support to the existing automation and take care of re-configuration to accommodate process / application change. It is said that, it takes 21 days of sustained effort to imbibe a new habit, but we have seen it takes much more effort and strong leadership to imbibe the new habit of using BOTs instead of going back to manual processing. Including BOT usage as part of scorecard metric for operations team helps in bringing the cultural shift and imbibe the habit of using BOT. Organizations should start thinking about CoE very early on in the journey when selecting pilot processes for implementation, as it may take anywhere before 4 to 6 months to have fully functional CoE in place.
Source: Linkedin-Ten levers of successful RPA implementation