With all the attention Robotic Process Automation (RPA) has been receiving, one would think that we have entered a stage of widespread acceptance of its business value. Yet still today nearly all organizations encounter the RPA elephant in the room: Is RPA a valid part of the enterprise technology stack or are we entertaining an elaborate ducktape project to help the business overcome short term challenges that eventually will be solved by the interoperability that is promised to us as we migrate to a Service Oriented Architecture?
Everyone understands the value RPA can bring; but very few buy into the strategic importance until much later into the maturity journey. This can lead to significant challenges for organizations trying to get started. It also can undermine momentum long after the business case has already been proven.
To discuss the challenge I thought it would be helpful to start by looking at the problem from a different angle.
Let’s think about the technology stack that is being used to run your business in the following way:
Every technology solution provides three layers that drive it’s use:
Layer 1: Functionality and Interoperability: Every product has a set of features and functions that make up what you can do with the application. All solutions also include at least some level of interoperability. This could be a robust API layer or for some as simple as the ability to export information.
Layer 2: Implementation layer: This is how the applications are setup to support the business needs and business processes. How are the features and functions enabled? Which ones are turned on and who has access? What workflows are setup.
Layer 3: Business orchestration layer. In this example we use this fancy term to describes how people interact with the user interface of the application to complete the daily work.
Now consider the stack you use in your organization and it might look like the image below.
(Note that this image is different for every company given their business rules and for every product that is used)
We can see that every application may bring a certain level of core functionality to meet your business needs right from the start (Layer 1). The way the application has been implemented may help support even further how you can use the solution to operate your business (Layer 2). And lastly anything that is left is taken care of by people, processes and procedures that are followed (Layer 3).
In the format above, our problem statement then reads: “Should you solve business problems automating layer 3 (RPA) or should your efforts be solely focused on improving layers 1 and 2?” (note: I am deliberately leaving out the obvious option to streamline layer 3 using Lean for a moment)
We can all agree that adding new functionality to product; and ensuring proper implementation should be a core priority. But we should also acknowledge the limitations of these approaches.
Product functionality is enhanced at a painfully slow pace. This improves somewhat for cloud solutions but don’t believe for one minute that somehow the cloud solves everything here. So to run your business, new functionality (while you should take advantage of it when you can) simply will not fill your bucket of business needs fully. Ever. In part this is by design. for the most part product enhancements are born out of the need for businesses that express the pain point and thus the business is already experiencing the pain even before product gets it on the roadmap.
The way you implement a solution can have significant impacts to the value you get from your solution and your ability to support your business needs. Implementation is not owned by the business however and once implemented, making changes are hard and take time. Cloud solutions do help here somewhat but there is far more that needs to happen for solutions to allow the business to control configurability and ultimately extensibility.
In fairness to our first two layers, by the time we get where we wanted to be, the business demands have changed on us. And herein lies the problem. The speed at which the business requirements change outpaces our ability to adapt with just the first two layers.
Today business react to changes in demands through people and process with often little to no technology to support them (I am discounting Excel and email for a minute as technology options here).
A fundamental goal of IT is to drive technology into the hands of the business so that they can react to business needs rapidly leveraging technology, not people.
RPA provides a Technology based solution that gives the business control to automate and adjust their business operations. For the first time this solution does not discriminate the technology stack that is in use and delivers the control across the entire enterprise stack. This represents a true paradigm shift.
It is for these reasons that RPA needs to be fundamental part of an organization’s technology stack and not considered an operational short term bandaid. It is also for these reasons that IT needs to play a critical part in supporting the business with RPA. IT has to consult the business on how to optimally balance the layers as technology evolves in consideration of the business needs.
President, IN-RGY USA
Mr. Ramondino is a leader and change agent on a pursuit of service excellence through innovation. He has spent most of his career working with Global Fortune 1,000 organizations deploying Technology solutions and new approaches to service delivery. Working for and with a number of HR Service Providers in a variety of roles including Product Management, Implementation, Sales and Corporate Strategy, has given Johnny a unique perspective on the market.
With his latest focus on Service Delivery Automation, he is determined to maximize the benefits of the digital economy within Human Capital Management.