This question certainly has been covered here before, but lately there seems to be a spate of 'BPM is Dead' posts. As BPM has been around a long time, and still means so many different things to different people, what aspects of BPM would you say are either dead or close to dying?

Peter, IMHO "BPMS" as a distinct thing (type of automation platform, market segment, etc.) has been effectively dead for awhile. Evidence of this is that the top-line vendors (stack vendors like Oracle and IBM, as well as next tier players like Appian and Pega) effectively sell what used to be known as BPMS engines as application development platforms in which BPMS applications effectively become design motifs or patterns that the platform makes easier to implement. Same is happening with Case Management Systems for those same vendors. (Check their marketing collateral, and you'll find yourself searching for BPMS or even Case Management System. Their small and large channel partners who are SIs or do SI work reference those terms more than the vendors.) The IDEs for these things have a process-centric or case-centric feel, but are really souped up - and more intuitively easier to use - SDKs. BPMS as a distinct thing is now only to be found, albeit in diminished form, in those vendors bolting on simple process automation engines to their process or case modeling designer tools as part of a grander plan to own the space. The IDEs for these other things are really more the pure process or case flavor of it all, requiring not all that much more than a semantically, syntactically, and behaviorally correct model to be able to execute its behaviors.

I also believe this evolution was/is inevitable, so I do not drop the paragraph above as a critique, just an observation. OTOH, maybe this will leave BPM (and its sibling Case Management) to continue to exist as management disciplines, irrespective of the implementing technology. For too long, BPM has been held hostage by the ubiquitous perception that it is a technology, WHICH IT IS NOT, confounding many otherwise meaningful examinations of how to improve business processes/cases. If so, then there is joy again in the BPM space.

the problem with BPM / CM as management disciplines is that no one likes "management disciplines". It sounds too Taylor-ish, too rigid, too centralized, too sequential.

people nowadays want to hear pretty stories about flat organizations (then dealing with the painful social span), empowerment of individuals (even without any proven skills), doing before planning (then cleaning the mess).

it doesn't matter that after all they will get back to some of those "management discipline" mantras - between the truth and a pretty story, people will always follow the pretty story.

@Bogdan, very nice social observation on management trends. Allow me to note regarding return to "management discipline" that it is already widely found, in the so-called "ideology of managerialism". Managerialism is the idea that management "science" and management cadres can manage anything, and that domain-specific knowledge, explicit or tacit, is not that important. So, failure on both poles -- faux-democratization without professionalism or alternatively managerial professionalism without domain knowledge. Ideally, one would like to combine respect for domain knowledge with managerial professionalism.

I don't think it is a "technology", but as a "technique" or "method" it provides a core capability for workflow management. (i.e. background orchestration at a Case run-time workflow/workload management platform).

BPM can provide some needed "workload " management by virtue of the possibility to tag BPM steps with "routings" i.e. plumber, electrician etc) that the run-time environment can use.

BPM can also provide some needed governance at Cases via rules at BPM step forms, rules at auto-execute BPM steps that have gatekeeper functions, rules at BPM branching decision boxes, rules at BPM loopbacks, with optional pre-processing rules incoming to BPM start steps (not just the first step) and post-processing rules going out from BPM end steps. The rest of governance needs to be provided via global variables at Cases\sub-cases.

What is missing from BPM is a workload management engine that is able to operate on templates of "best practices" workflows.

Unless your workflows are end-to-end, BPM does not offer any way to store goals or objectives - these became attributes of Case platforms out of necessity (i.e a Case has no "end" node so impossible to know when it is likely to close, so we need to park goals/objectives AT Cases (i.e. goals/objectives became run-time attributes, no longer plan-side attributes).

Also missing, is a method for non-subjective assessment of progress toward meeting Case goals/objectives.

The reason we talk about Case is that it hosts the run-time workload management engine (BPM feeds steps, Case lets users work across multiple Cases) AND it provides an infrastructure for auto-building of histories (i.e. each session or intervention results in a system applied date/timestamp and a user 'signature" Result - we get to know WHO did WHAT, WHEN , WHERE possibly also HOW and WHY).

Case is not necessarily the sole provider of an ad hoc intervention capability. You can, if you wish, take a BPM flowgraph comprising 10 steps and build 10 flowgraphs of one step each and you then can either stream a Case record on to the flowgraph or onto any one or more or all "processes of one step each". Case is actually just a "bucket" at a cursor position in an RDBMS.

Lastly, Case provides an infrastructure for bulk data in/out of Cases (i.e. general purpose data exchange). The most obvious benefit is a manufacturing Case at a process control point along a BPM template, waiting for a notice of shipment from a supplier. With a data exchanger you can automate the gatekeeping - this is much preferred to getting an e-mail and then manually removing the blockage at the gatekeeper step.

Agree. BPM is associated with a sequential perception of work to be done. This is a point of view of an external observer. Thus, the point of view of a planner how a work to be done will be done is missing.
If we consider the trio Governance, Management and Operations then BPM is ideally positioned as Management and Operations Discipline Enabler. “Work to be done” is the input for MODE and a result is the output of MODE.
So, this new BPM becomes free of flowchart inheritance and becomes open for any planning and coordination techniques including workload management.
See thus illustration - https://1.bp.blogspot.com/-fiqk4nXmXXc/WzM76-V7h-I/AAAAAAAAKcw/RxEvu-lt7HA7BIg2IC3huKWmV8segJPCQCLcBGAs/s320/MOT.PNG

I am trying to understand "... point of view of a planner how a work to be done will be done is missing"

Are you saying that in the case of work do be done along, for example, a production line (different steps being performed by different people), the "sequential perception of work to be done" (i.e. a run-time template of a flowgraph) is the result of a planner documenting various possible approaches, considering which ones are best, then implementing a selected approach?

If yes, then the tools of choice for the planner would reasonably be a mindmap/decision tree -> CPM for the one-time implementation -> a BPM run time flowgraph?

Feels like touching on what we call "informal processes" where people are free to do what is required in their way. This would be recognised by assignment to correct role and recoding the the "result". There could be a time limit which could trigger alert etc.

Not "informal processes", but planning logic. Before an observer can draw a typical flow-chart, the planner must explain WHY this flow-chart is like that. Some business specific, technological, etc. constrains may affect this WHY. For example, a classic publishing workflow is technical editing, drawings, proofreading and publishing. It is sequential because a document to be published was paper-based. After moving to electronic documents management, editing and drawing were allowed to be executed in parallel. After employing a fragment-based text management system, separate fragments were allowed to be published concurrently. But, proofreading is always after editing and drawing.

Among the strongest aspects that are phasing out, when it comes to BPM, are, on one hand, the "pure player" approach and, on the other hand, almost as a direct result, the idea of having only a single process automation platform per company in place.
The disappearance of the pure player BPMS's occurs in tandem with many platform providers offering some sort workflow engine, process design and simulation tools in addition to their core offerings (example: Data Transformation Engines with an embedded workflow tool). That, naturally, will provoke a company to have to deal with multiple BPM technologies at the same time, at any given moment. From my perspective, that democratization of BPM technologies is a positive development which also leverages the importance of BPM standards, frameworks and established methodologies.

@Kay . . . I wonder who got the notion of " . . only a single process automation platform per company"?

Reality is you only need to consolidate work that draws on a particular "pool of resources" i.e if the New York office has initiatives that need "local electricians", all you care about is having one available when you need one. You can have a different "local electricians" resource pool/different BPM/different workload management engine for Spain.

If there is a need for data exchange NY -> Spain or Spain -> New York, a generic data exchanger can take care of this traffic.

Nothing wrong with BPM the issue is recognising what it actually is. It is a discipline a way of thinking how to create step by step business outcomes...it is NOT a technology. However to achieve delivery does require supporting "adaptive" software and here has rested the failure which includes vendors jumping on the bandwagon with such as BPMS.

BPM creation recognised the gap between people and the way inflexible silo based applications have evolved which did not reflect the way business actually works where people drive, create and use information. With digital now top of agenda it is vital that the UI is seamless linked to the supporting back office which are reflected in the tasks and links making up the end to end process. The harsh fact is this requires a complete platform to build direct from business knowledge and use legacy as required. Trying to change legacy will be costly and become yet another IT failure. As reflected in previous discussion the rise of no low code should readily and efficiently deliver.

The BPM discipline is a sound and effective way to work out what is required in a simple step by way with direct input from users. Suggesting a change to the tag BPM would be a huge mistake and cause confusion which of course suits big vendors and their industry analysts.

Maybe this forum needs to make clear BPM is the way to think in "enabling the digital enterprise" ? Also might be helpful to apply a tags to both such software which supports this thinking (Digital Business Platform?) and to the resultant application (Adaptive?). Whatever both should have clear standards to avoid the usual industry hype and of course in language readily understood by business.

"The reports of my death are greatly exaggerated" is a comment attributed to American humorist Mark Twain. I'm of the same view concerning BPM software technology, that its death is greatly exaggerated. And I also hold BPM technology in fact to be "a technology" -- which is not to say BPM is not also "a methodology" or a "marketing category" at the same time.

Business process management technology is a technology in a similar way that accounting is a technology. (One can read up on the question of what exactly "is technology".) Both technologies are distinguished by an an irreducible core of technology, a core which is also orthogonal ( "mutually exclusive" ) with other related technologies. For example BPM technology is orthogonal to business rules technology. Certainly advanced BPM technology has a more mathematical core than accounting. One could say that the core of a BPM engine is the math and code that can resolve a graph in real time. thus defining what next work task may be performed.

The fact that BPM as a specific market presence is fading from major software vendor messaging says nothing about BPM core technology itself. Similarly, vast ERP systems are not sold as accounting systems anymore, but the core of an ERP system is still the general ledger and debits and credits. And certainly BPM technology is enormously complemented by business rules technology. BPM and business rules are now usually packaged together in one software platform, along with a half dozen or even a dozen other distinct technologies.

I have written elsewhere that BPM software automation technology is "the technology of the work of business" - by definition. In no other technology are the concepts of work first-class citizens of a technology. And because business is about work, the technology of the work of business is -- or should be -- centrally important. Business process automation software is found in every software, because business process (or work process) is what software is about. Lots of times, the process is encoded in code, or otherwise implicit. And thus hidden. And not so easy to manage. BPM software proper presents processes and workflows as more directly manageable and thus with BPM, one gains the flexibility and agility that apparently we all want.

My view is that (a) BPM software technology IS a technology and (b) that BPM software technology is also THE central technology of business.

Despite the ostensible merits of BPM software technology however, for various market and business social reasons (see earlier replies above) some or even much of the excitement around the BPM category -- from workflow thru BPM to up until, say, 2012 -- has diminished. Nevertheless, we catch a sense of a new excitement again. We are seeing now a new generation of BPM-touting software competitors which are bringing a fresh urgency to the BPM opportunity. The technology keeps getting better. The fundamentals are waiting.

Predominant trend of business development in technology age is growing complexity. This complexity is not concentrated densely in any specific area, such as IT but is distributed evenly across all areas and aspects of business.

At certain stage it became evident that it is impossible to hold and manage growing complexity of business by traditional means of classic business administration. BPM came to scene as a way to cope with versatility and volatility of modern business environments through systematic modeling and structuring organizations towards contemporary technology trends.

The idea appeared so tempting that many first stage BPMS pretended to be one stop solution for all business operations, especially in IT field. Of course, it was an exaggeration and false interpretation of real complexity challenge, which caused this development.

Consequently, the scope of BPM systems gradually dissolved into various workflow engines and form processors. Of course, this scope is too narrow and far from the original challenge, which brought BPM to agenda. It gradually eroded the original value of BPM by accidental associations with incomplete and limited systems from various IT domains.

However, the relevance of the original problem of managing complex business systems did not diminish but, on the contrary, continuously grows with progressive expansion of technology and digital platforms. It leaves no doubt that we will see explosive growth of BPM in next years on new level of universality and flexibility.

In terms of IT, we can expect that BPM will focus in a short prospect on micro-services and universal API tools to establish wider and more flexible system interaction. On wider scope we will definitely see deeper integration of business with equipment, robotics and IoT. BPM approach has no viable alternatives in unification of all these modern business trends.

I interpret you views that the software which supports BPM must evolve and expand its reach into collating and using the data collected by such as machines robotics and IoT. What is interesting the underlying business logic does not change....and BPM should have no limitations in thinking just as the supporting software must also have....the challenge is recognising much of legacy will become redundant...?

@David.. Sure - the logic has always been to do the right things, the right way, for the right reasons, at the right time, using the right resources (5 X).

That said, there seems to be two modes of use of "best practices" i.e Healthcare, where BPs are guidelines or second opinions and where the attending physician makes the final call, then Law Enforcement, where failure to strictly follow protocol leads to rejection of evidence when a Case goes to trial.

In Healthcare, it is very easy to justify a need for 1,000 + protocols.

In a homicide crime scene investigation app that we recently put on the market, we identified some 200 evidence gatheriing/tagging/bagging/transport protocols.

@David, thank you. I think that so called legacy systems are an essential asset comprising the core of every business. This explains why legacy systems are so deeply rooted in corporate environment. After all, legacy is very positive term, synonym of knowledge and experience. However the niche of accumulating and positively transforming legacy experience is almost vacant. This s the area where BPM can be especially productive.