If you’re an old consultant like me, when you hear the phrase ‘process modeling,’ you probably think of a group of people in a stuffy conference room, arguing over how the business does things while someone draws boxes and lines on a whiteboard. For hours and hours.
Such exercises were painful at best, and only modestly helped to achieve their primary goal of process improvement – although in many cases, what the business people really meant by improvement was automation.
Automation, however, belonged to the world of software, while process modeling was stubbornly human in scope. That room full of people were largely spinning their wheels.
The Rise of BPMN
That is, until XML came along. Today the idea is downright quaint, but the notion of an extensible markup language took the process modeling world by storm.
If we can represent a boxes-and-lines model as XML, so the reasoning went, then we could build software that could execute it – as though the XML representation of the process model were itself a computer program. And behold, all our automation dreams would come true.
Only that’s not what happened.
True, the idea of an executable business process markup language rapidly matured, and in parallel, the notion of a standard process notation to go along with it. These two approaches – markup language and process notation – finally merged into the pièce de résistance of process modeling: The Business Process Model and Notation, or BPMN.
And lo, BPMN was a wondrous construct. When BPMN 2.0 hit the shores in 2011 as an Object Management Group (OMG) specification (now at version 2.0.2), it appeared as a 532-page pdf file with 15 sections on topics as wide-ranging as symbols, choreography, and execution semantics.
This masterpiece surely represented the ultimate in process modeling and notation, giving consultants, process analysts, subject matter experts, and others the perfect tool for creating executable process diagrams that would both optimize and automate all the processes in the organization.
Instead, BPMN became more of a boat anchor than a facilitator. While it was remarkably comprehensive, it turned out to be too comprehensive – too long and detailed for all but a small cadre of BPMN experts to use properly.
Furthermore, whether software could execute BPMN models directly ended up as a moot point, first because organizations weren’t producing sufficiently accurate, detailed models, and second, because that’s not how effective process automation actually works.
Reinventing the Modeling Process
While BPMN ostensibly reinvented how organizations modeled and automated processes, what it failed to do was rethink the modeling process itself.
The problem: even with BPMN in place, process modeling still followed a waterfall approach, where requirements gathering in the form of process modeling took place as a distinct step before throwing the model over the wall to the software folks for coding and execution.
Today we know better, of course. Most organizations recognize that waterfall takes too long, costs too much, and delivers poor quality software at the end – if waterfall projects deliver anything that works at all.
Furthermore, many years of Agile and Lean software practices have brought new software best practices to the table, where iterative, results-focused approaches trump the waterfall processes of yore.
However, BPMN – and the process thinking that goes along with it – have failed to make the jump to modern software practices, even though such practices are in large part processes themselves.
One cannot miss the irony in this situation: all that time and effort to create the massive BPMN specification, only to find that BPMN itself is appallingly unsuitable for the very processes organizations would need to follow in order to put it into practice.
Low-Code to the Rescue
If the waterfall-centric process modeling approach that BPMN favors doesn’t cut the mustard, then what does?
Essentially, organizations require software platforms that enable them to iterate quickly between process modeling and application creation tasks in such a way that each iteration delivers business value.
The good news: such platforms are now on the market. We call them low-code platforms – especially the subcategory of process-centric low-code platforms.
True, some of these tools actually support BPMN (or some subset of the spec) – but the focus is less on the conference room with the whiteboard and more on drag-and-drop modeling that creates a working application as the immediate result of a modeling activity.
Automating the Modeling Process
Taking a combination of approaches to process modeling and automation we would call Agile (iterative and customer-focused, with shift-left testing) and Lean (each iteration provides business value while eliminating wasteful steps) addresses many of the issues that BPMN was woefully unable to solve – but there is still one important challenge remaining.
Even with low-code, the process modeling activities are largely manual. How do we automate the process modeling processes themselves?
After all, using a low-code platform to create working applications that automate processes is itself a set of tasks that humans must tackle manually, right?
Not so fast. Artificial intelligence (AI) is rapidly changing this equation.
Most low-code platforms are incorporating AI capabilities today for such tasks such as ‘next best action’: if an application creator is building a workflow, the tool may suggest the next likely step in the workflow based upon what it has learned from other, similar workflows.
Next best action is a useful innovation to be sure, but today, the real excitement over automating process modeling and automation falls into the category of cognitive robotic process automation (cognitive RPA).
As I recently wrote in Forbes, RPA itself faces challenges, as most organizations use it to automate interactions with existing apps, presenting an integration nightmare that works poorly at best. Adding AI to the mix doesn’t address such integration challenges, but it does represent the next generation in the automation of process creation.
The idea behind cognitive RPA is to leverage various aspects of AI (namely machine learning and natural language processing) to drive the behavior of an automated (or partially automated) process.
A simple, but common example: a virtual assistant that can shoulder many of the tasks of a human customer service rep, answering questions and completing tasks dynamically based upon customer requests and other conversational interactions.
The Intellyx Take
It’s important to note that the behavior of such a virtual assistant doesn’t follow any pre-determined flow, and thus you would never be able to model its behavior with BPMN. Instead, the software is smart enough to determine the process logic appropriate for the task at hand on its own, in real-time.
It’s also important to understand that we’re in the very early days of cognitive RPA – and by extension, cognitive process automation generally. After all, you don’t have to spend much time with one of today’s virtual assistants before you realize they tend to be frustratingly limited in their capabilities.
Nevertheless, the writing is on the wall: the future of process automation won’t consist of humans creating models (BPMN or no), but rather humans creating cognitive platforms that can figure out how to automate processes to meet user needs on the fly.
In this AI-driven future, then, what will be the role for human process modeling? Certainly, many processes are relatively static and easy to understand before putting together software that might automate them. AI may be overkill for such processes.
Even for these processes, however, low-code techniques still trump manual process documentation, as the end result is a working application rather than a model. Models, after all, were always supposed to be means to an end, never an end in themselves.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: deboxer (flickr).
Comments
Comments are closed.