Note that is article is part one of a two part series delineating BPMS and Low Code Platforms. To read the second part of this series, click here.
The BPMS Malaise
In a recent low-code vendor landscape report, Forrester analysts Clay Richardson and John Rymer identified five distinct flavors of Low-Code, one of which is process-focused Low-Code platforms. If you read between the lines in this and other Forrester reports, as well as analysis coming from the greater process community, a process-focused low-code platform is really just a synonym for today’s new breed of BPMS. This fact poses an interesting question: Why the new moniker? Is there just so much baggage with “BPMS” that vendors are looking for a euphemism, or is there really something so different between the two technologies that a reclassification is in order?
Technology or Ideology
From a technology standpoint, the evolution from BPM to low-code—sometimes referred to as the “appification” of BPM—has been in play for several years now, so you’d have to look back quite a ways to see a pronounced difference between an old-school BPM and a state-of-the-art, process-focused low-code platform. Even the stodgy, old-guard BPM incumbents are talking business apps, these days, And while there are well defined feature sets designed for both BPM and low code scenarios, the real gap between the two approaches to rapid application development (RAD) is probably more ideological than technological.
The Long and Short of BPMS
The Business Process Management (BPMS) technology class was founded on a business theory—that an entire organization could be viewed as a collection of discreet and interrelated business processes, and, that by systematically improving each process, an organization could continually improve its operational efficiency. BPM Suites, then, were software platforms designed to automate, monitor, measure, and improve processes. They were all about operational efficiency, which, in a broader context, provided management oversight. Increased oversight, in turn, facilitated governance, risk management, and, ultimately, better compliance with internal rules and regulations and external laws.
But there was, and still is, a downside to BPM—it sounds great in theory but is extremely difficult to implement on an enterprise-wide scale. The problems with BPM constitute a tangled web, which encompasses all of the following and more:
• Enterprise processes can be extremely complex.
• Processes often span multiple operational groups within an enterprise.
• Many organizations find it nigh unto impossible to get the necessary stakeholders to agree on optimal process methodologies.
• Most processes are, at best, dynamic and, at worst, downright unstable.
• Coding such processes, even with declarative, low-code/no-code tool sets, can take months, even years, during which time the process itself evolves, making the finished application dysfunctional out of the box.
• BPM initiatives require such broad buy-in and enterprise wide commitment—not just to embark on the journey, but to vigilantly maintain efforts, well . . . forever—that they’re really hard to get off the ground.
When Good Processes Go Dark
Jim Sinur, a onetime Gartner BPM analyst and current industry thought leader, once wrote an article entitled “Beware of the Dark Process.” The piece, which was published on his Gartner blog, has since been taken down, but the gist of it was this: One of the biggest challenges of BPM occurs when functional processes go dark, that is, when conditions change in such a way that business logic won’t allow workers to complete the task at hand using the instituted automated process. In such instances, workers have no choice but to revert to their old, non-automated habits. Herein is the onset of darkness—management has lost oversight on the process, which oversight was the real reason it implemented BPM to begin with.
BPM—the Treadmill of IT
Without having industry data at my finger tips, my bet is that most treadmills (in fact, exercise-related contraptions, in general) are purchased sometime during the first week in January, are put into heavy use for a few weeks, and by Valentine’s day have been moved into the garage, where they will collect dust until being listed in the local classifieds for pennies on the dollar. The sad part is that a treadmill is really good for anyone with the discipline to actually use itand will deliver the advertised benefits—lower cholesterol and the ability to squeeze back into last year’s wardrobe.
My point, of course, is that BPMs and treadmills have a lot in common—any organization that will make a broad commitment to BPM will be better off in the long run. Such enterprises will improve operational efficiency; eliminate costly—sometimes catastrophic—human error; and will have an institutionalized framework for systematic growth. But just as treadmills are, at best, boring and, at worst, flat-out painful, automated processes can likewise become mechanized task-masters.
Ding Dong, the Process Is Dead
So why do knowledge workers often develop a strong dislike of process automation in about the same amount of time it takes to get fed up with a treadmill? Consider this: Perhaps the biggest problem with BPM is that the actors in any given process may end up spending more time and effort to complete their sub routine than it used to take them doing it the old way. (Anyone who’s ever tried to get a bunch of old-school sales reps to use a CRM knows of what I speak.) Automated processes require strictures, protocols, and new stuff to learn. And from the perspective of those in the trenches, “if it ain’t broke, why fix it?”
The answer, of course, comes from the top down: Overall efficiency from automation, in many cases, is achieved only from the viewpoint of senior management, for whom the automated process imposes governance on a sometimes global and, often, undisciplined, workforce. And governance mitigates organizational risk by ensuring compliance with rules, regulations, and laws. Put another way, BPM may actually drive labor costs up, but the company’s bottom line will, nonetheless, improve via litigation averted, penalties avoided, and blunders headed off at the pass.
Just the same, the dissonance between the C-Suite and the rank and file is often impossible to overcome—when processes go dark, those in the trenches are often in no rush to get them fixed. And just as the Munchkins broke out in song the day the Wicked Witch met her end, so also might staff members break into their own little river dance once the process is gone for good. It’s this lack of grass-roots support that can erode the resolve of even the most committed senior management team, regardless of what unimaginably large sum it has already sunk into automated process efficiency.
Note that is article is part one of a two-part series. To read the second part of this series, click here.