The Case for a Business Automation Center of Excellence

I started writing this post about the incredibly confusing landscape of tools that organizations have to reconcile in their process improvement efforts, and pivoted slightly to propose a solution that I discuss with many of my clients: a business automation center of excellence (CoE).

I often work with large organizations that are trying to get their arms around how to improve and automate their processes. Some of them start their journey by mapping processes in a modeling suite to understand how to improve them; others start by automating a process using a business process management system (BPMS); still others start by creating a process CoE that gathers knowledge about methodologies and tools that may be used on projects. Different projects may be using different process tools, and even creating separate CoEs aligned with competing tools, so that there is a CoE for the BPMS from vendor #1, and a different CoE for vendor #2’s BPMS. This is a common situation in large organizations, and creates a huge “Maslow’s hammer” cognitive bias: a CoE focused on a single BPMS product will tend to recommend that tool for every project that comes along, which means that any specific project will end up with BPMS #1 versus BPMS #2 depending on which CoE they talked to first.

And, of course, these projects are not just about automating processes, but also imbuing them with intelligence through the integration of other technologies: process mining, decision management, task automation, AI, machine learning, simulation, event management, predictive analytics, performance monitoring, and more. That means that there are adjacent efforts where other teams are doing the same type of activities with related technologies, creating a decision management CoE or adding robotic process automation (RPA) to perform task automation.

Across projects and CoEs, there may be little consideration of the potential for combining the different technologies, or even whether they are using the right tool for a specific project. With the potential for multiple (competing) tools in the same product category, plus multiple tools that have some degree of overlapping capabilities, plus different combinations of complementary tools to solve any given business automation problem, how does anyone figure out what to use, and when?

That’s where a Business Automation CoE (BACoE) comes in: somewhere to bring together information not just about all tools of a certain product category (e.g., all BPMS tools) but all tools that are used for intelligent business process automation. If that seems like a daunting task, it is; it is more likely to be an overarching CoE that pulls together and coordinates existing technology-specific CoEs, while leaving specific technical expertise in the lower-level CoEs. One of the key capabilities of this CoE is to provide application architecture advice on how to combine a set of tools for a given business use case. If a project has a straight-through processing requirement, or is creating a human-centric case management application, the BACoE can start them off with a template that shows what technology categories (and even specific tools) that they should start with, and how to best combine them. The BACoE needs to be familiar with the entire suite of automation technologies to a certain degree in order to understand, for example, when to use a BPMS versus RPA, or when to use a decision table in an external decision management engine versus a branching structure in a process, or when to apply AI to automate actions without explicit process or decision modeling.

The process automation technology landscape is further confused by vendors who – either through marketing hubris, their own misunderstanding of their competitors’ capabilities, or too much time spent gazing at an analyst report – position their products as having completely unique capabilities that don’t overlap with any other products:

In reality, most products in the same category share a large number of capabilities, and products in adjacent categories often share a smaller number of capabilities. For example, almost all BPMS tools create model-driven executable processes; some also provide decision tables as part of the BPMS even though that could be done in a separate decision management system (DMS). Deciding which BPMS product to use requires matching business requirements to product capabilities, while deciding whether to use a separate DMS requires an assessment of whether the complexity of the decisioning requirement warrants the use of an additional tool. These are application architecture issues, and should only be undertaken by people who understand the capabilities – in this example – of each BPMS and DMS, as well as the design and implementation trade-offs.