The economic and operational malaise caused by the COVID-19 pandemic has forced many companies to focus on quick automation wins. It appears a majority of those quick wins have been RPA (task automation) implementations without a focus on the bigger picture and business processes the task automations are a part of. We believe this will create long-term process and technical debt for companies.
Thus, we are starting a series on Hyperautomation, which is the bigger picture for automation and scaling beyond RPA. This blog, defining Hyperautomation, is Part 1 in a multi-part series. All of the items in the series will have both a blog and a recorded presentation so you can consume the content in the method you prefer. However, we do recommend the recorded presentation format over the blog format. The blogs are derived from the recorded presentations, so they may not flow as well as the presentations. However, we understand there are still a minority of people who prefer reading over watching a video.
We may not do them in that particular order, and we may even add or subtract titles as we go along. The general idea is this series will give anyone interested a fantastic foundation in understanding Hyperautomation.
Business-driven Hyperautomation refers to an approach in which organizations rapidly identify, vet, and automate as many approved business and IT processes as possible through a disciplined approach. Hyperautomation involves the orchestrated use of multiple technologies, tools or platforms.
(Gartner, Dec 2019).
The critical thing in the definition is the bolded words. Hyperautomation is business-driven, disciplined, and involves the orchestrated use of multiple technologies, not just RPA. It is our intention you will see the importance of these bolded words as we dive deeper into what Hyperautomation is.
What we’re going to discuss in this blog is the core of Hyperautomation. We’re going to step through the disciplined, iterative, and infinite loop that is Hyperautomation. We will go through every step in Figure 1 and explain what they represent and why they are essential.
The first step is to define your business objectives (Step 1). What are you after? What needs to change? Are you trying to chase growth, and thus revenue needs to increase? Are you trying to boost profitability? Do your costs need to go down? Is compliance a big driver for your company? For Wells Fargo the last few years, compliance has been their primary driver. Due to them breaking some rules, everything they are doing needs to be driving back towards lowering risk and making sure they are compliant with government regulations. When you start with the business objective, this will drive what your Digital Ambition ends up being. This makes sure you don’t lose the forest for the trees. It is always about the business objectives you are trying to achieve. The technology is just there to help.
Now that you have your business objectives, you can start to explore what you need to do with your programs and processes. Much of the improvements and changes will be automation, given the fact so many jobs have substantial pieces of them that can be automated. According to WorkMarket, 53 percent of employees believe they could save up to 20 hours per month by automating tasks (WorkMarket 2020 In(Sight) Report). However, you should take a more comprehensive view than just automation. To widen your perspective, you may decide to employ approaches like Design Thinking or Game Theory to take your company through What-If scenarios. Your vision may end up being to completely tear down what you have and automate everywhere you can, or to iteratively improve on what you have by automating portions of it.
Now that you have objectives and a vision, the hard detailed work begins. You need to do process analysis to see how you can make your process outcomes align with your business objectives. Fortunately, this work is not as hard as it used to be. Data Mining and automated Process Discovery tools have come a long way from where they used to be. However, don’t let the smooth taste fool you. You are still going to need subject matter experts working with process analysts to take your models “the last mile.” Automated process mining and discovery tools have inherent limitations that still require human intervention and analysis to give you the necessary insights to design your processes so they align with your digital ambitions.
In particular, the Process Mining tools attached to RPA tools are almost always going to direct you towards RPA. If you have a hammer, everything looks like a nail. Also, this is where you will want to simulate scenarios to see what happens as you make changes to your processes. What happens if instead of manually sorting through invoices, I have a document ingestion engine doing that? What happens if I have bots take over certain rote and mundane work? You can use Salient’s Automation Compass tool to help with this analysis.
This leads us to the Automation Alignment Matrix, which is a matrix Salient Process created to fit the type of work being done with the most appropriate automation technology. The matrix was created because our customers were struggling to determine when to use which of the many automation tools available. The tools Gartner lists as being part of what they call the DigitalOps Toolbox make up what our matrix aligns against. Automation Alignment is a very crucial step that makes sure you avoid the “I have a hammer, so everything looks like a nail” problem.
We will cover the Automation Alignment Matrix in another presentation in this series. For the purposes of this presentation, it is vital a step you need to take to make sure you’re using the right automation tool at the right time and right place in your processes. One could argue it belongs in the Process Analysis step. However, we felt it was important enough to give it its own step.
You’ve done some excellent groundwork to make sure what you build is aligned with your objectives. Now we get into the part everyone has been doing a lot of already, at least concerning RPA and deploying bots, and that is Prototyping, or building minimum viable products to determine fit quickly. We won’t spend a lot of time here, as this is well appreciated and practiced throughout the industry. And, the same with being able to deliver and go to production, at least for initial deployments. Where there are challenges are with scaling beyond prototypes, pilots, and limited production deployments. We’ll get deeper into that later, as well as in future presentations in this series.
This next piece is very critical. All of the steps are key. However, monitoring and measurement are essential to being able to establish scale and grow your Hyperautomation efforts. I like to think of measurement and monitoring as being a bit like having Google Maps or Waze on your phone. The map is beneficial to help you get where you want to go. However, it is much less helpful if it does not know where you are right now. It can’t possibly give you directions if it doesn’t have that context. Also, where you’ve been is very helpful for the map software in predicting where you may want to go. In the case of your automation landscape, none of that is possible without Analytics. However, it isn’t good enough to have analytics for the business data collected as your business processes execute. To truly map and track where you want to go, and accurately know if you are getting there, you’ll also need to be able to measure your program’s performance. And, you’ll want to be able to predict what will happen based on what has happened. Essentially, all of this data has to report and forecast if your process outcomes will help or hinder you from achieving your business objectives defined in Step 1. Fundamentally, this is all that matters. It doesn’t matter if your process is running more efficiently (faster) if the end outcome isn’t helping you reach those business objectives. If you aren’t getting the proper process outcomes, you’ll need to figure out how to affect the appropriate change to achieve the desired result.
With all of this, as you start to see initial success, you’ll need to be able to govern and scale your program. What is both interesting and challenging now is you have many disciplines necessary for the breadth of tools available in the DigitalOps Toolbox, as well as less technical, but no less critical, disciplines such as process analysis. Also, as you scale, you will be running concurrent automation efforts. You may have 5, 10, 15, even 20 parallel automation efforts going on across your organization. Your methodologies and COEs will have to take all of this into account. It is Salient’s contention you need an automation COE, which will encompass multiple COEs specific to the disciplines necessary for the various DigitalOps capabilities, as well as for process analysis. Trying to scale without this in place will create duplicate efforts, fiefdoms, and chaos. In other words, you may be automating, but your approach will be highly inefficient across your company, and thus you will fall behind your competitors. This is a vast subject and will be covered in one, or more, of the later presentations in this series.
The iterate and optimize step is vital, and is integral to the fact we have now built an infinity symbol to represent our model for iterative business-driven Hyperautomation. Through the course of my career in process improvement, which started back in 2005 at Intel, people have always asked me, “when do we stop improving the process?” What they’re really asking is, “when can they stop spending money on process improvement?” My answer then was the same as it is today, even with all of the advances in technology. The answer is, “when you decide your process is so good you don’t need to worry about the competition anymore, then you can stop improving it.” So, the question you need to ask yourself is, “are you that good?” Or, more importantly, “are you ever that good?” It isn’t very likely given the churn in the Fortune 500. As of 2019, only 10.4% of Fortune 500 companies from 1955 are still on that coveted list. On the other hand, basing this decision strictly on competition is an oversimplification. There is also the consideration of business objectives. Those objectives, as well as the reality of non-infinite resources, will dictate there are only certain processes you can commit to continually improving. However, Hyperautomation is depicted as an infinite loop for a reason.
What we’ve seen frequently in the automation space is initial successes with RPA implementations. Everyone gets excited about the initial success, but then gets bogged down in how to scale and grow to Hyperautomation. The keys to success are only partially the right, or the High Expertise, side (steps 5 and 6) of the infinite loop. The more significant drivers for success, once you get beyond the initial low hanging fruit, is the left two-thirds, of the infinite loop. This is where there is low expertise in Hyperautomation. Steps one through four, and seven through nine, are where the disciplined, iterative portion of the infinite loop comes in. These steps are where the heavy lifting is. They are the discipline part of Hyperautomation. However, they also have the most significant payback for your efforts. The best way to distance yourself from your competition is if you are tying process outcomes to business objectives and adjusting based on those outcomes. To achieve this, you need to take a holistic approach to automation, and not just focus on the right one-third of the Hyperautomation Infinite Loop.
In summary, Hyperautomation is a business-driven, iterative, and disciplined approach to automation, that allows you to accelerate your automation efforts and results. You cannot achieve Hyperautomation with RPA alone. The DigitalOps Toolbox is key to being able to have the necessary tools to scale. While automation efforts are usually successful in the initial pilot and small departmental deployments, companies struggle with scaling beyond those initial successes. To get to Hyperautomation requires a more rigorous approach of defining your business objectives up-front, and letting those drive the digital decisions you make as you grow your automation program.
As we mentioned, this blog is the first in a series. We’ll follow this with blogs and presentations about how you can scale beyond RPA to reach Hyperautomation, leveraging IBM Digital Business Automation to reach Hyperautomation, how you align the right automation tools with the right type of work, and discuss the scaling strategies that will allow you to navigate the Hyperautomation roadmap.
