Robotics Process Automation at KKR

How do we identify opportunities for automation, and how do projects evolve over time? The first step is usually the short-to-mid-term fix used to provide coverage and gather more information on what the business truly needs. The long-term solution rarely ever relies on bots.

Working with tech may be frustrating at times, but I promise, we’re all just trying to make the best of what we have available. There comes a point in every solution where the architect says to him or herself: “I would have done this completely differently had I known back then what I know now.” When we reach that point, the tech team will make decisions that seek to balance out two competing forces: technical debt, and delivery speed. The team will usually fluctuate between two initiatives:

1. Refactor parts of the solution: reduce technical debt, but slow down on deliverables
2. Continue working with a sub-optimal design: increase technical debt, but continue adding features to the product.

An experienced architect has a feel for how to navigate this complex dilemma. A strong business analyst, architect, product manager, and development team can make this problem less acute. However, more often than not, you cannot avoid this problem all together. When designing a new solution from its inception, the initial scope and design often differ greatly from the final product. Some reasons for this are:

1. New discoveries about the business needs are revealed during the development process
2. New technical capabilities are made accessible (new resources, new products, etc.)
3. New initiatives or long-term strategies for the organization are prioritized
4. New users wish to adopt the solution, but have slightly different use cases

At KKR, we utilize Robotic Process Automation (RPA) as a short to mid-term solutioning and prototyping tool. RPA has a lot of hype. It can integrate with many things, it's fast, and it demos incredibly well. While it may be sold as THE solution to all your problems, as somebody who has been working with the technology for over six years now, I believe it’s a very powerful tool to have at your disposal, but its benefits are over-exaggerated (as is most technology).

RPA is powerful because it can solve problems quickly. A business user can demo their process to an automation team, and the team can turn around and create an RPA solution a lot faster than most other platforms. Sometimes you need to solve the immediate problem first, give the business some bandwidth to step back and think about their needs holistically, and then change the process (and thus change the solution) in order to better serve the needs of the business. If we can give a team an extra eight hours a week to think strategically, rather than perform routine and mindless tasks, that opens the opportunity for a lot of new thinking and long-term improvements.

We target low-complexity, high-volume tasks first. Say you have the option to build two different bots:

1. A quarterly process that will save 100 hours per run
2. A task that occurs 20 times a day and will save 5 minutes per run

Both of these bots are going to save about the same amount of active time, but one of them takes significantly longer to build, maintain, and support.  In addition, there’s a low chance that a quarterly process remains unchanged quarter-over-quarter.  If you dedicate your time to building complex bots, you’re borrowing against the time it will take to fix and maintain those bots in the future.  Think small and build the simple bots first. 

Last quarter, we saved around 2,500 hours of work using bots, but this is a subjective measurement. The estimate is based on the average amount of time it takes a person to complete a task (active time).  What it doesn’t include is how long a task sits in a person’s inbox (passive time).  A bot can pick up tasks almost immediately whereas a person’s tasks may sit in his or her inbox for several hours.  Your passive savings will often be more significant than your active savings.  While it’s important to have some quantifiable measurement for your program, I personally wouldn’t obsess over it.

Ok, so you’ve built a bot. Great! Problem solved, right? RPA sellers and marketers will tell you “Yes”, but I’m not one of those. I lead the RPA practice at KKR. I should be its biggest advocate, right? Unless RPA is literally the ONLY way to solve the problem, it’s probably not the most optimal solution.

RPA is a bit hacky. At its core, it replicates the actions a person would take to interact with an application (button clicks, page navigation, screen reading, etc.). RPA demos are incredibly engaging because people get to see a bot perform their work exactly as they understand it as a series of screen changes and button clicks. However, what exactly is a bot? A bot is a machine that is designed to interact with a user interface, which has been designed specifically for humans to interact with another machine. Do you see how this seems a little bizarre?

The real value comes from being able to break through technical roadblocks quickly so that a solution can come alive and be iterated rapidly.  The solution will continue to evolve, and the assumptions made during the initial design will eventually be challenged.  RPA serves as a tool to help us move quickly, with the expectation that we’ll need to refactor some things later on.  We’d never figure out what the optimal solution is unless we can move forward, iterate, and allow the solution to evolve with the needs of the organization.  Because of this, it is key that your RPA team is closely aligned with your Engineering team.  I sometimes consider my team to be “Tech Scouts” – we go out and discover needs across the business, and every so often, we’ll find one that requires a fundamental change to the business itself. 

There is a lot more I can say on this topic. You may be asking yourself, “Okay, so if RPA isn’t the optimal solution, what is?”  The answer is most likely a solution built in the cloud, utilizing serverless components, and leveraging the APIs of your other applications.  That’s a discussion for a later date.

Disclaimer

The views expressed in each blog post are the personal views of each author and do not necessarily reflect the views of KKR. Neither KKR nor the author guarantees the accuracy, adequacy or completeness of information provided in each blog post. No representation or warranty, express or implied, is made or given by or on behalf of KKR, the author or any other person as to the accuracy and completeness or fairness of the information contained in any blog post and no responsibility or liability is accepted for any such information. Nothing contained in each blog post constitutes investment, legal, tax or other advice nor is it to be relied on in making an investment or other decision. Each blog post should not be viewed as a current or past recommendation or a solicitation of an offer to buy or sell any securities or to adopt any investment strategy. The blog posts may contain projections or other forward-looking statements, which are based on beliefs, assumptions and expectations that may change as a result of many possible events or factors. If a change occurs, actual results may vary materially from those expressed in the forward-looking statements. All forward-looking statements speak only as of the date such statements are made, and neither KKR nor each author assumes any duty to update such statements except as required by law.