Kimberly Mestre

Kim Mestre is a Senior Process Architect - Intelligent Automation at SiriusXM-Pandora, where she has worked since 2015. Her background is in digital advertising operations and business systems, where she has held many roles, ranging from Client Services Manager, QA Engineer, to her current role on the Intelligent Automation team. She will always hold a special place in her heart for her first “real” job as a coordinator at an automotive advertising agency in Sacramento, CA where she learned more than she ever wanted to know about automotive advertising and spent countless meetings convincing car dealerships to advertise on this “new” medium called the internet.

Hello, Kim!

Can you tell us about what Robotic Process Automation is, in layman's terms?

It’s likely that most people benefit  from - or at least experience - automation in their daily lives. That customer service agent you engaged with online while booking your car’s oil change? That was likely a chat bot, programmed to help you schedule your appointment. And the grocery self check-out, which is somehow always more challenging than it should be, is another example of how automation plays a part in our daily lives.

The same is true for office life. An engineering team may leverage software to automate their quality assurance test process before anything goes live to production. A finance team might leverage macros to expedite manual spreadsheet tasks. There is an abundance of mundane, manual tasks that automation can help to relieve humans of, allowing them to focus on higher value-add tasks that require human input. 

One such automation technology that has gained much attention in recent years is RPA, which is an abbreviation for Robotic Process Automation. When someone hears the term ‘robot’ they may think of Rosey the Robot from The Jetsons, or, if they are far younger - the Roomba robot which keeps your floors clean. In either case, the robot is tackling the mundane (and in this case, dirty) work of cleaning, while the human is freed up to focus on other tasks.

The same is true of the bots used for RPA - they take care of the mundane, boring, and manual processes, allowing the humans to focus on higher value, judgement-based work.

For example, someone in the billing department may spend 4 hours every Monday validating billing data between two systems, and clicking the ‘Approve’ button at the end of each validation. If a bot can perform the same validation checks for 90% of the data, the human can spend time on the 10% of exceptions that require either historical knowledge, or human judgement.

RPA builds on existing software and automates processes or tasks associated with that software. Take the billing process above - the billing data already exists in the billing system, and automates the process via web UI, or ideally an API connection. To build on that example, if the data does not yet exist in the system, RPA can automate the ingestion of the data, whether it comes from another system, or a spreadsheet.

Another way to think about it is that RPA can help fill in the “white space” where existing technology systems lack. In the event that a system lacks an API, automation can act as the conduit by transferring data from one system to another

What are some of the tips you would give that could help companies that are starting to think about establishing a formal RPA practice?

If you spend any amount of time on LinkedIn, you will no doubt be familiar with the phrase “digital transformation”. While this can mean different things to different companies, generally speaking it involves taking a hard look at the status-quo of processes and workflows, and investigating ways to leverage technology to break the status-quo and transform how work is done. Many companies create teams dedicated to process improvement and improving efficiency and productivity across the organization. These teams will often look to RPA to automate manual processes, ultimately leading to a more effective and productive organization.

Having worked closely with many teams across the enterprise on various projects, we knew there was an appetite for improvements/less manual work from the business users themselves. The need for process improvement existed - most everyone was in agreement on that, or at least open to having the conversation. As we began those conversations, we realized that even more important was gaining the support of process improvement from leadership. That was something we could help prove - with data, successful use cases, and lessons learned. With a (relatively) small team leveraging established tools and systems, RPA seemed like a good opportunity to explore.

We initially started with a pilot program, selecting three processes from our Billing Operations and Client Services teams. We had buy-in from both executives and business users, and now three years later we are still running one of the processes from the initial pilot, and have close to 50 automated processes in production, spanning across multiple business units.

As we looked to expand our scope, we found it more challenging to branch out to teams with whom we did not have an existing relationship. We initially leveraged a bottoms-up approach when sourcing new RPA “clients”, in a way that really felt like a scrappy start up! At this time we automated processes that may not make the cut now (due to not meeting guidelines and KPIs in place) but it was important to automate something to show the business team what RPA is capable of. Put another way, we were looking for any work we could get, until we reached a point where we could be more selective about what processes we automated.

Once we had a more formalized program and automation examples to showcase, we started to tackle the top-down approach, and scheduled meetings with executives for buy-in. While this was successful in some business units, the same cannot be said for all. While most saw the value of leveraging a more automated approach, there was some push back ranging from justifications such as: their roadmap had already been built for the year, or that they were undergoing large process and system changes and automation didn’t make sense at that time. Our conversations with those executives continued, and as we built up our RPA work to showcase, our program continues to grow and scale.

What is the process for evaluating the maturity, or size of an organization for starting RPA practice?

The first step is establishing a COE - Center of Enablement. This is the strategic arm of the RPA program and you can liken it to the founders of a startup: the first year or two is lots of presentations for anyone that will listen! Our current COE started with representatives from the business units we were already working with, and as things changed and grew, we are now 3 full time employees strong, with a Senior Director, Intelligent Automation, Senior Process Architect, and Senior Developer - RPA Engineer. While we all have our own unique areas of expertise, there is much overlap amongst our roles.

In addition to the COE, we also have a tactical arm of the RPA program who provide development and monitoring/support. From my standpoint, this is the most important part of establishing a successful RPA program as they are delivering the final RPA output. We have partnered with the same outside vendor for the last two years and have been very satisfied with their work. It helps that they have domain knowledge in our digital advertising business, and that we are able to work with the same developers over a period of time, meaning less time spent on knowledge transfer and getting new developers up to speed.

A RPA practice can only be successful if the business is ready for it. To that end, we have partnered with teams who have an existing COE or teams dedicated to process improvement. In general, these teams will have a backlog of process improvement tasks that they are working on, so less time spent brainstorming ideas, and best of all, they often have existing process documentation that can easily be converted to a Process Design Document (PDD) - that means less time documenting, and more time developing the solution. We also partner with the engineering teams supporting various systems across the company, tackling items on their roadmaps that get pushed to the side to make room for more strategic work.

Having said that, not all teams have the luxury of team members dedicated to process improvement. In that case, we work more closely with the team to assess ways in which we can improve and automate existing processes. We will also lean in on the documentation side of the process. While working this way will inevitably be more time-intensive, it also allows the COE to have more input on where automation can be of benefit.

Can you offer some examples of transformation and business benefits that you have delivered?

It is important to not only focus on FTE (Full Time Employee) hours saved, although that can be an important KPI when measuring automation success. If that is an important KPI for the company or business unit, be prepared to address (with assistance from the business stakeholders) how those hours saved will be put to use. It could be a reduction in contractor hours, moving a FTE to a more value-added role, or reducing the time spent in moving a product to market.

Initially our practice focused on FTE hours saved as the most important KPI, and it can (and did!) lead to some difficult conversations with business stakeholders (and the people who actually do the work). We’ve since broadened our KPIs to focus on things like improved accuracy, expediting month-end close, and increasing team capacity where no head count was assigned for the year.

The KPI I am personally most proud of is enabling an employee on our Business Operations team to… take a vacation! Historically, they had been the only person who knew how to create a weekly report for executives to gain insight to how a particular sales vertical was performing. This report takes data from Salesforce and Tableau, merges into an Excel spreadsheet, and creates many tabs of data and calculations. 

By automating this process, the bot downloaded reports from both systems, and performed the calculations in a database, removing the dependency on Excel (which often crashed from the amount of data and formulas involved). Most importantly, automation saves the employee an average of 4 hours weekly, and they finally get to take some much needed time off! Automating these types of human-dependent processes frees up the human dependency.

While the following example is specific to the digital advertising quote to cash (QTC) process, keep in mind as you’re reading through any processes that you are part of which involve various digital inputs, multiple technology systems, and validating the data that appears within all of them.

For every advertisement you hear or see, a client (or agency acting on behalf of a client) enters a contract with the publisher defining the dates and times the ads will run, as well as any targeting specifics (location, audience, etc). Both parties sign the contract and this simple PDF becomes the source of truth for anything related to the advertising campaign, including billing and invoicing.

Many teams are involved in this process, and downstream teams rely on the upstream teams to meticulously input data so that their workflows and processes run smoothly and accurately, ending with client payment for ads served. 

Given the number of humans and data points involved, mistakes happen. Some of these can be costly in terms of time and money. An audit process is in place wherein a Finance team validates manually input system data against the original PDF so that issues are addressed before the campaign goes live.

The automation team tackled this manual process two ways leveraging OCR and RPA:

1. OCR (Optical Character Recognition) technology to identify, scan and export key data points from the contracts.
2. RPA to validate the OCR output file against the data entered into various systems. When the bot identifies a mis-match, a human is alerted to investigate further.

With a success rate in the high 80% range, we are saving valuable human hours, increasing system data accuracy, and ultimately reducing any payment-related issues as the data is more accurate. Long term we are looking to automate the data input process, leveraging OCR, ML (machine learning), and RPA, thereby reducing the need to audit system data as it would be correctly input at the start.

What are your top 3 lessons learned in your RPA practice journey?

Don’t try to automate everything (human)

But also, don’t try to automate just 1 piece of a process

Look for the “white spaces” where there is a lack of system integrations, or space for a trigger-based automation.

Finally, are there any recommendations you'd like to call out for aspiring women trying to grow their in the automation space?

You don’t have to have a technical background to work in or succeed in the automation industry, you just have to be curious and comfortable asking questions. I graduated with a communications degree and have spent the majority of my career in various advertising operations roles. I understand the people, systems and workflows of the Quote to Cash process, and that has helped me immensely on the IT team as a Senior Process Architect.

Don’t be afraid to ask ‘why?’. And then ask again. Maybe one more time. We are all guilty of doing things a certain way because that’s just how it is done and has been done for years. Or that’s how we were taught to do it. Or because of system or people limitations. 

As someone who has walked into many situations having no previous knowledge of a process or part of a business, it’s important to listen, but equally as important to ask questions. So much of what we all do is taken for granted, second nature, stored in our head, without even realizing it. Our job within the Intelligent Automation team is to understand the current process, and recommend a transformed process, leveraging the automation tools within our tool kit.

Connect with Kim on LinkedIn