Customer Conversations is an ongoing series designed to answer the questions you have from professionals who are at great Companies worldwide.
Today’s edition is on Robotic Process Automation, which is a hot topic, particularly given COVID and the economic devastation that has ensued.
Below is a conversation I recently had with a top, large, global consulting firm that implemented an RPA program of significant scale. Learn about their initial use cases, which departments adopted first and why, and what they did to successfully scale to an operation with over 150 bots deployed.
1. When did your company start using RPA?
Our Consulting arm was providing RPA services to clients. As usual, there were pet projects at Corporate, and RPA caught on fairly quickly for internal use (e.g., IT, Finance, HR, etc.). During 2017, a Center of Excellence (COE) was up and running. The COE leader came from IT and had previously worked with our Consulting practice to implement RPA for clients. He was then brought in from the field to implement a COE designed to serve internal needs. The original model for our COE was to train members on our RPA tool of choice (Automation Anywhere) and let them build their own (less complex) bots (e.g., compare spreadsheets). Over 90 business-side people were trained. Ultimately, we needed some centralization as there was a need for a more robust support program, coding standards, security and processes to ensure that our quest for efficiency didn’t result in inefficiency!
2. What department championed RPA? What department ended up funding it?
Finance originally funded the COE, but it was offered to all departments (nobody had to budget for RPA). This is currently in transition and the question is, will groups fund their own bots, will IT fund them centrally, etc. Finance was smart to do this because it led to rapid adoption and overall Enterprise support for the value, but I do think that a company would be wise to anticipate a centralized funding model at a certain point of scale.
3. What were some of the biggest successes?
Within HR, the benefits team was manually performing Quality Assurance (QA) on Employee year end statements regarding total compensation (they included annual salary, bonuses, quantification of soft benefits, etc.). Three bots were built to do the QA. These bots logged into the Company’s ERP and home grown systems to compare statement data against the system of record. The end of year QA effort used to require 8-10 people for 6 weeks at year end, working 15-18 hour days. With bots, it was completed in 48 hours, hence we freed up 8-10 FTE for more fruitful things in the November/December timeframe.
Another powerful use case was a scanning bot for new clients. Bots looked at the materials for specific terms (either in Word or PPT). The questionable terms were then highlighted and sent back to the authors by the bot. This initiative greatly reduced field review time, time to contract execution, and dramatically improved risk management.
Note: be sure to see our blog on RPA use cases for IT Service Management4. What were the top use cases originally?
Communications and training compliance were top use cases – bots were created to send new hire welcome messages, employee reminders, cross check consultant regulatory compliance and ensure gaps got closed.
5. Do you now have a line of departments wanting to use RPA?
By 2018, the pipeline for internal projects went out for 3 years (see below, this was for our COE of 30 people!).6. Which departments were most willing to try bots initially?
Finance was the clear early adopter, given a myriad of manual processes around invoicing and accounts payable (hence their move to finance it initially). HR was a close second. Marketing also had a lot of bots and, compared to others, was more likely to have their own people trained to build bots directly (compared to HR and Finance). Marketing used bots for repetitive Communications, to customize client-facing Powerpoint templates (data would be retrieved from Sharepoint and populated into PPT fields) and to scan Twitter and other Social Media for trends. It is noteworthy that some social media platforms, like LinkedIn, prevent the use of bots; bots would have saved HR a ton of time when scanning potential hire profiles, or searching for talent. We are actually looking at work arounds for that because, given our annual scale of new hires, scanning social media takes a tremendous amount of manual effort.
The risk team was beginning to adopt and came up with a reporting bot that pulled daily reports for the team. Risk automation projects would take longer to implement as they had to be careful with how they utilized the technology.7. As your organization matured its use of RPA, did the use cases change? What were they?
The use cases didn’t radically change, but the use of RPA strikingly caused most groups to really put a lens on their processes, and to think about how they could be reengineered using automation.8. Did you ever measure business impact for RPA? How, and what impact did it have?
We were just starting to dive into evaluating broad business impact, and our leaders were asking for it. However, we did implement standard analyses out of the gate using a 3rd party ROI tracking and analytics platform: we tracked the performance of the bot itself (i.e., how many transactions it processed, how many dollars it saved, how many FTE).9. What were some of the barriers to implementing RPA and how did you overcome them?
Getting business buy-in because, if we save 5 FTE, for example, we are reducing their workforce and taking away jobs. We really had to educate our audiences that our goal was to get robots to do “unintelligent” work and to enable our people to take on more meaningful work. We had a very strong marketing pitch, which was essential to getting to the scale we were able to achieve. As different groups inside the company learned about what the bots could do, they started to really believe in the concept.
10. Tell me about the scale of RPA used by your company?
150-200 bots are currently deployed…some were more productive than others! We did have to have a process of retiring bots and creating second versions. We constantly learned about ways to make them better. As our developers learned our bots improved and became even more useful.
11. What kind of infrastructure did that require?
Our COE contained over 30 people at one point, approximately 1/3 of whom were analysts, over half were developers, there were (3) domain-focused portfolio managers, (2) Automation Anywhere system administrators and (2) and post-production support analysts (this component was comprised of offshore developers).
12. If an organization wants to start with RPA, what are your top recommendations?
You MUST have a marketing pitch. How are you going to “sell” RPA to Departments? How are you going to overcome their concerns about being replaced by robots?
Data security is critical and often an afterthought. I wouldn’t necessarily start with a full blown data security plan or users will get scared away. In the beginning, start with benign data where data security will not be an issue. However, be proactive and determine who is responsible for Data Governance and Security in your organization and get them on your side. Find out what their process is for securing data, and make sure it becomes part of your development process. Build extra time into the project to allow for a review of the data and ensure it is being pulled from a secure location and the output is stored in a secure location as well. Typically this means talking about the type of data you will be accessing up front when requirements are being discussed.
Also, Analysts and Developers really need domain process knowledge, meaning, if you are going to deploy bots in HR, make sure your Analysts and Developers understand HR processes and technologies in your industry. This is why a portfolio approach is really smart – our portfolio managers came from the domains (e.g., HR, Finance, etc.) they supported and understood them better than anyone, how they could be improved, which ones took the most time, etc.
13. If an organization wants to set up a COE, what are your top recommendations?
|Marketing, marketing, marketing! See #12 above.|
In addition, be sure to think through an organizational structure that will work in your organization. In ours, a COE was critical given our size, scale, risk profile and need for domain-specific knowledge and portfolio management approach. Craft a short term funding model that will drive adoption and prevent barriers, and a longer term one that will ensure strong centralized support where bots provide strong ROI. Have a strong proof of concept (POC) process in your development cycle, and for the COE overall. Regarding POC process, it is necessary within the Bot creation lifecycle to ensure quality bots get deployed for any particular use case. Make sure that your POC process ensures that the bots work well, are stable, and won’t require a disproportionate amount of support. Make sure your POC process defines expected ROI up front, and tracks and reports it back over time. You should also POC the COE itself – test the COE structure and adjust it.
Guard against your COE becoming inefficient and unimpactful – after all, RPA is designed to increase efficiency! This is particularly critical as the COE grows. Measuring and communicating ROI becomes increasingly critical as the COE gets larger. The RPA COE needs to be much more hyper-focused on continuous improvement and efficiency than any other department in the company.