In Part 1 of this series on automation alignment, we described an overall approach to fitting the right type of automation to the kind of work being done. We discussed the high level of looking at the type of work being done and fitting Digital Business Automation (DBA) capabilities to that work. In Part 2, we discussed automated decisions and the type of work they fit with. In this blog (Part 3), we’ll focus on the Task (RPA) portion of DBA, indicated in Figure 1 in orange.
Before we get into which types of work can be most helped by Task Automation, we need to point out our strong feelings on Task Automation, in particular, Robotic Process Automation (RPA). RPA is excellent when used correctly. That is, with a focus on automating mundane repeatable tasks. As we firmly stated in our RPA is Dead blog, we believe RPA is inappropriately named. It should be called Robotic Task Automation since RPA technologies cannot automate whole processes, only individual tasks within a process. We won’t cover this much deeper here since we gave the subject in-depth coverage in the RPA is Dead blog.
For the rest of this blog, we will give a lot of focus to RPA since that is where the market is today, and is also what IBM means by Tasks within the context of their DBA platform. However, there are other technologies which could be considered for Task Automation, and we will briefly touch on those as needed.
If you read any of the other blogs in this series, you may want to skip to the next section since the following paragraphs are definitions repeated in each blog in the series.
The way we approach making automation decisions is by leveraging our Automation Alignment Matrix (AAM). The Automation Alignment Matrix allows us to analyze the type of work being done and map that to the type of automation recommended.
Along the Y-axis, we measure the Uniqueness of Work being done, while the Volume of Work is measured along the X-axis. What we are attempting to do with this matrix is determine where an automation capability best fits into one of the four quadrants based on the type of work being done, with the type of work determined by its uniqueness and volume. There are other factors an organization should take into account, such as assessing the relationship between job performance and strategic value, which will help you determine the return on improved performance (ROIP). ROIP is a subject unto its own, which we may cover in another blog. For a deeper dive into ROIP, read Part 1 -> Step 2 of Reinventing Jobs by Ravin Jesuthasan and John Boudreau.
Before we go too much further, some definitions seem appropriate. Low and High Volume (X-Axis), as well as Repetitive and Unique (Y-Axis), are self-explanatory. However, the Programmatic, Transactional, and Exploratory terms along the X-Axis are less self-explanatory. The definitions for Programmatic, Transactional, and Exploratory are from the MWD Advisor’s article mentioned earlier. These criteria were added to the X-Axis because we felt they added more depth to the matrix. Below are definitions for the three words needing more explanation (somewhat appropriately, the definitions for each of these get longer the less prescriptively the work can be defined up front):
Now that we have these definitions, as we look across a company and begin trying to determine how and what to automate, we can look at things from a process and activity (task) perspective, and take a prescriptive approach to automation. When looking across a business process, it is quite common for all five types of automation capabilities in Digital Business Automation to be needed. However, the job of our Automation Alignment Matrix is to help us narrow down automation for specific types of work. We can also leverage a tool like IBM Blueworks Live to model out our processes and analyze what type of work is being done. This will prepare us to use the Automation Alignment Matrix since we’ll have classified the work as either Exploratory, Transactional, or Programmatic.
Our objective in this blog is to look at Task Automation in the context of all three types of work.
This is the sweet spot for Task Automation. Whether high volume or low volume, if the work is programmatic in nature, meaning we can fully define the work up-front, then Task Automation should be leveraged. Whether that Task Automation is accomplished by Robotic Process Task Automation, a low/no-code application development tool, or an application integration platform really depends on the level of flexibility you need, as well as the time to market required. If the tasks to be automated include the need for integration with legacy systems or your time to market requirements are very high, then RPA should be a consideration.
Figure 4 represents how Task Automation fits into the Automation Alignment Framework for Programmatic work. We’ve made the Tasks icon for the High Volume / Programmatic quadrant larger than the Tasks Icon in the Low Volume / Programmatic quadrant since we believe Task Automation is more prevalent in the High Volume / Programmatic quadrant.
The lower the volume of work, the less likely it is a company will want to automate it, especially for low-value mundane work. If it doesn’t happen very often, and it doesn’t cost you much to have someone do it, then you may not want to automate it. It may be sufficient to have the work done as part of a swivel-chair type workflow. Alternatively, if the work is predictable, repetitive, and high-volume, then that is a great place to look at Task Automation, and RPA in particular. However, there are caveats to this as the typical RPA implementation is limited by how quickly it can open and fill in screens (after all, when all is said and done RPA is sophisticated screen scraping). If you get into too high of a volume situation, then application integration may be a better choice. Of course, if you are automating what was previously done entirely manually, then we suspect any performance concerns would be a red herring, and RPA may be an excellent choice, at least in the short-term.
Transactional work, which can mostly be prescribed ahead of time, but typically requires human intervention, tends to be the domicile of workflow. However, within those workflows, many times there will be specific tasks which can be automated. Attended RPA would tend to play a more prominent role than Unattended RPA here. In Figure 5, we display the Transactional view of our Automation Alignment Matrix for Task Automation.
We display a Workflow icon here because this area is typically where Workflow is most prevalent, and other automation capabilities are called from the workflow. In this case, we see Attended and Unattended RPA are possibilities, although the icons are smaller than for Programmatic work since there is less opportunity for Task Automation. Also, the icon for Attended RPA is larger than the icon for Unattended RPA since Transactional work tends to be guided by humans, and the workflow can change based on what the human observes.
Exploratory work is, by definition, unpredictable. The very word explore brings to mind going off and doing exciting and unforeseeable things. Every company has a ton of exploratory work. This work is typically the highest value work done at a company. This area houses your knowledge workers, and we predict this is where automation will eventually drive all human workers to live. Applying prescribed automation to exploratory work becomes much more difficult than the other types of work, if not impossible. Think about the work your executive teams typically do. Mostly, it is making decisions and delegating work based on their experience and knowledge of the business. Trying to predict those decisions and actions through highly controlled sequential workflows would be a recipe for disaster.
Because of the nature of exploratory work, Task Automation, and RPA, in particular, will not play a significant role here. Thus, we’ll have a tiny Attended RPA icon in the Exploratory / Low Volume quadrant. For the Exploratory / High Volume quadrant, we won’t have Task Automation at all since there isn’t that much high volume exploratory work anyway, and also we don’t see a great fit for Task Automation in that quadrant.
As we mentioned in the first paragraph of this blog, this is Part 3 in a series of blogs (Part 1; Part 2) on taking a holistic approach to automation when leveraging Digital Business Automation. Hopefully, this blog will help you avoid what we see happening in some automation efforts; RPA as a panacea for all things automation related. RPA is outstanding in some situations, but you need an overall approach to automation which allows you to take a look at the big picture and determine what type of work you’re doing, and then what automation, if any, fits best with that work.
