Digital Process Automation

Digital Process Automation: A Logical Successor To Business Process Management?

Connie Moore, Vice President and Principal Analyst at Deep Analysis, has recently compiled a deep dive into Digital Process Automation, which consists of two reports, the State of the Market: Current Analysis and the State of the Market: Trends 2020-2025.  We sat down with her to find out more.

Hi Connie, thanks for agreeing to help us understand your interesting research a bit more. Why do you say Digital Process Automation (DPA) is ‘the newest incarnation of BPM (Business Process Management)’ – that sounds intriguing? You also say BPM made some mistakes, and maybe some claims that weren’t always delivered on in the real-world?

My pleasure. As we see it, Digital Process Automation’s roots are workflow (earliest version), then morphing into business process suites that included design (modelling), execution (workflow or orchestration), monitoring (dashboards) and improvement (changes/improving the processes iteratively).

As a result, one type of BPM emerged: automation for highly structured processes that are largely predictable (e.g. a bank’s loan processing). But you also saw another type of BPM emerging — straight-through processing with system-to-system integration and little human involvement (think, of processing trade settlements). Then, a third type emerged: automating processes that change frequently, have unique paths for different types of instances or are highly dynamic (an example could include contract management, or underwriting), and even a fourth – automation of processes that are highly content-oriented (e.g. new drug approvals).

Eventually, these different types of BPM converged into a single product or subset versions of converged products. But the BPM term has lost favour because it implies heavy, expensive, slow continuous process improvement projects that never end. Part of the reason for this ‘heaviness’ is that BPM was joined at the hip with big process transformation initiatives that targeted complex, end-to-end processes that were not only hard to automate but very politically risky and methodology heavy (looking at you Six Sigma, Lean!).

Now, the new term widely in use is digital process automation (DPA) or just plain old process automation. Most companies stopped trying to wrestle those really complex processes to the ground and instead have started picking off smaller processes, or less complex processes or less politically laden processes that still deliver value.

Interesting, thanks. What do you mean when you say process management can be both loose/ad hoc but also rigid/formalised… what examples spring to mind to make that more concrete for our readers on thedmcollaborators?

Loose/ad hoc might be a long running process instance that can follow lots of different paths to completion. For example, take a long-term disability insurance claim; these claims can stay open for years, amassing a tremendous number of notes and documentation, involving interactions with lots of doctors and caregivers etc. To automate this, you’d need a highly flexible, adaptable process engine.

Rigid can be something in the back office, where compliance is crucial and the process must follow a prescribed path. For example, settlements for stock trades. It is also possible, of course, to have both elements in a single process, particularly if the process spans multiple workgroups and departments.

At certain stages the business process might also be heavily regulated (and therefore prescribed) whereas at other points it may be very customer-engagement focused and require significantly more flexibility. Many of these highly dynamic processes also require significant document processing and repository management, which would mean that the process automation vendor either provide content services or integrate with third party content solutions.

Thanks. Your research saw some real disparities in capability on the tools you surveyed – can you say more?

Well, first off, the process automation vendors are trying to figure out how to partner with RPA (Robotic Process Automation) vendors, and which ones to engage with. The problem here is that RPA products should become part of the process automation platform, but RPA company valuations are currently sky-high, so it is next to impossible for process automation vendors to buy them. How a process automation vendor addresses its RPA partners and integration approach is a differentiator.

Next, a lot of the vendors have wrapped themselves in low-code, but they are actually all over the map.

To a certain extent, all process automation products are low-code, because the goal of process automation has always been to support graphical process design, visual dashboards, pre-built process models and forms, and other capabilities that minimise coding.

But now, the pre-built, pre-configured products are even more low code than before, so there is less applications development and more tools for process design that business analysts can do. However, some products are mainly or exclusively low code for developers, while some others are low code for business analysts – and a few process automation vendors are trying to create a new mass market using low code for ordinary business people who have other jobs.  Who the vendor is really targeting with low code is important for buyers to figure out.

In my opinion, the idea of citizen developers is largely a myth, by the way!

OK… so Why isn’t AI & Machine Learning really coming through yet to help, in your opinion?

Because process automation vendors aren’t sure how fast and to what extent their customers will want AI/ML (Artificial Intelligence/Machine Learning) in the process software. They don’t know if it is three years out, five years out, or longer; they are not getting much demand for it.

They also have to sort through how to add AI/ML inside the process automation product, versus how to add AI/ML alongside the executing processes. It’s a lot easier to figure out the latter than the former.  The latter could be something like integrating with a natural language product whereas the former could be using AI/ML to analyse process designs and make recommendations on process model improvements. However, it is very much early days for the former.

I see. Final question, then; What’s the smartest thing to do right now when it comes to Digital Process Automation… stay put, or actively investigate?

Actively investigate – because the products can make a huge difference in cost savings and productivity, but also can move the needle on customer impact, customer engagement and customer satisfaction. Getting the right skills on the project is important for these types of initiatives.

The takeaway has to be that most companies are stuck in improving business operations (which is great) but there is a whole new world to explore in linking process automation to digital transformation initiatives.

Connie Moore, Vice President and Principal Analyst, Deep Analysis

 To find out more

Connie has written a report about the divide between process excellence practitioners and customer experience professionals that might be of interest to readers of thedmcollaborators, as well as a blog post about the upside-down world of RPA and process automation

She also recommends community members check out Deep Analysis’s reports on their website that are also about customer experience and the ‘hand-off’ syndrome, which may provide additional insight.

One thought on “Digital Process Automation: A Logical Successor To Business Process Management?

  1. Excelente contenido , favorece el crecimiento empresarial en función de las nuevas interacciones entre el eficiente manejo de los procesos y la transformación digital .
    Saludos desde Ecuador

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s