Absolutely, without a doubt. How many clients, projects, initiatives out there use all three, much less do them all well? How many use more than one BPMS? There's one, maybe two, they go into that platform, use its tools and they're heads down working on delivering solutions, applications in just that platform with just its tools.
You know who, what, is truly, really ripe for disruption? Us.
Maybe, although they’re intended to steal time away from (re-)inventing terminology, graphical notations and other wheels instead. Whether they achieve these goals is something that you probably have to evaluate on an, um… case by case basis.
Personally, I feel slightly sick every time I start reading something whose author has created their own special personal process modelling notation.
That’s almost as bad as when they write ‘I use these terms slightly differently to most people so here are some new definitions.’ And that, my friends, is straight out of Through the Looking-Glass:
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
BPMN, CMMN are the tools which are extrmely powerful in the hands of IT analysts and IT developers. They are not designed to be used by business users and business analysts - even if you use a sub-set of the notation.
Understandng you customers probems and therefore how you need to operate, organise and measure your workforce requires a less technical view of business process. A simplified notation like UPN that Nimbus created, enebales the enture workforce to be engaged at any level of seniority, across any departmernt, and inside suppluers and partners. It is not a proprietary standard and most modelling tools can support it.
UPN and BPMN or CMMN can work in harmony. UPN = "what should we do, and how should we do it" BPMN.CMMN = "and how do the apps support it".
Yes, because these techno-approaches put end users, the true process owners and outward-facing contact point with customers, at a distance in terms of customer outreach and customer inreach..
The true focus should be on enabling customer outreach/inreach at Cases where all of the action takes place or should be taking place, i.e. (hosting of objectives, structured interventions/unstructured interventions with provision for customer outreach/inreach, workload management, assessment of progress toward meeting objectives).
Standards compliance should be the concern of vendors, not of customers.
Vendors should focus on standards compliance for the purpose of lowering the cost of innovation, design and delivery of solutions to customers, for the benefit of the whole BPM market.
Unfortunately, there are two massive wastes being perpetuated in the BPM market:
1/ vendors who invent their own crap "standard" and proprietary components designed to value trap their unsuspecting customers;
2/ vendors who keep pushing BPMN and other generic trainings with utter disregard to actual usability of such training in the day-to-day life of the customers.
From my perspective, BPMN and CMMN are good steps towards developing good declarative languages for expressing business requirements that can be directly executed. They're good steps, but we have a long way to go.
For example, the majority of the effort spent on implementing process applications always seems to be User Interface implementation. We don't yet have a good language for declaring operational UIs... and that means there's an aweful lot of code written to implement process UIs (and a lot of churn to get it right).
YES....should be sent into history book of IT. The point about supporting software for the BPM thinking is it must be in hands of business people not IT. 20 years of R and D working with early adopters has proven that use of declarative technique with pre coded business logic that supports people and machines where all information is created opens a new door and will close old doors at great cost to old IT driven vendors. Therein lies the real challenge somewhat evidenced that Microsoft tried to patent but failed so guess what they dropped; why cut your own throat....but just a question of time. RIP BPMN and CMMN
Excellent and highly relevant question. When you have a hammer, every problem starts to look like a nail. If you ask a surgoen about your health problem, the answer will be in terms of the kinds of surgery that can be performed for it. The language of expression colors how you view the world tremendously. The users of that langauge often fail to realize exactly how boxed-in they are.
Like most programmers, I know quite a few programming languages. I think most programmers have had the experience of a challenge that defies solution; then it occurs to you to try a different language, and it becomes suddenly easy. Nothing is more frustrating that reading code written in one language, struggling to do something that is trivial in another language.
That is the general principle, and it applies to BPMN and CMMN as well! It is quite important to remember that these languages --- any language really --- can never be universal. The designers of these languages had certain problems in mind, and when you stick to those problems they are fine. But the range of human experience in a business is far more varied than that. Thinking that all business behavior can be rendered in a single approach is pure foolishness.
The wise approach is to understand what each such language is suitable for, use if for that, and try to avoid the mistake of inappropriate application: you can pound a screw into the wood with a hammer, and if the only thing you have is a hammer it might be better than nothing, but there are better solutions afforded by other tools.
I don't think they add much value for the following reasons. As I've mentioned before, I believe the BPM market is better classified as IT-oriented and business-user-oriented (rather than Workflow and Case-oriented). This attempt to straddle both worlds creates a beast that is satisfying to neither type of user.
For business users, I think these notations actually intimidate and hence add negative value. For I.T., they may under some circumstances add some value, but even here, BPM is devolving towards app development, and these notations are not the best way of structuring app development.
The one place I think these notations could add real value is as a communication tool to visualize processes. However, because their explicit goal is to not only visualize but also to create executable processes they end up with a lot of detail that detracts from their acting as a communication tool. But still, this is where I see them having the most value.
For business users, conversational processes are catching fire and that's where I think the future is. (See Slack, Siri, Amazon Echo etc.). This is an entirely different mindset than conventional BPM. To the extent that a notation is needed for this (fwiw, I don't think it's needed) it would be a notation that would describe stateful conversations.
For all the good reasons why standards like BPMN, CMMN are developed; they tend to get commercialized and boxed and, as with the BPM acronym, end up at a certain nerd or specialist desk. As soon as there is a need for a solution ("We want to increase customer satisfaction.", "We need to increase productivity.", "We need to be in better shape to comply to new regulations."), these standards suddenly pop up and religious warfare has started.
So, yes, in this sence they steel away precious time. Which is a shame. I always have used the idea of: "It's great to use and apply a standard, but don't bother the rest of the business, do it as least silently." An accountmanager want's to walk around with a current, authorized pricelist. He couldn't care less about the standards used to achieve that. The fact that standards or method's are being used to improve operational excellence is cool, but don't let them become the objectives: Not a single business has ISO or ITIL processes, or is standardized on BPMN. If you get my drift...
Standards done correctly are very useful for customers. HTML5 and other W3C standards around it is the best example. They are universal, customer-market-driven (not industry-market) and vendors are competing on the level of compliance and execution speed. Enterprises can concentrate on the unique challenges of their business and not waste time re-inventing the wheel.
Having the WEB ARCHITECTURE makes a huge difference! Where is a commonly-agreed BPM ARCHITECTURE?
Yes. I’d go further in stating that the focus on standards has been a disaster for the BPM and Case Management industry. Standards have throttled innovation in process design and raised unnecessary barriers for widespread adoption. Obviously standards are great for consultants and business analysts.
What does the word "focus" mean in the context of the question? It means there is perceived to be a business case for expenditure on maintaining a given enabling capability. And thus the answer depends on the business model.
1. COMMODITY FUNCTIONS -- NO JUSTIFICATION FOR ANY INVESTMENT IN MAINTAINING SIGNIFICANT KNOWLEGE OF TECHNICAL STANDARDS -- IT departments continue to be "disrupted" and BPO isn't done yet. Formerly, it was "why build my own software, even with RAD, when I can buy an ERP?" Now it's why do a business process for A/R if A/R is outsourced? And the result is there is no economic case for fussing around maintaining anything other than basic knowledge of process-oriented technical standards -- because you don't build your own processes for commodity processes.
2. DIFFERENTIATING FUNCTIONS -- JUSTIFICATION FOR YOUR OWN PROCESS LANGUAGE -- The outsourced parts of your business are the commodity parts. But the differentiating parts of your business model that are left you should be very good at. And likely that means mastering your own domain-specific process language. Because when you have the right language, your productivity is an order of magnitude better than off-the-shelf.
BALANCE PUBLIC AND PRIVATE LANGUAGES
The enabling capability referred to in the original question is as Keith has pointed out "a language". Let's explore.
We all "speak accounting" and accounting is a language which is essential for business, and for which every organization maintains varying degrees of fluency.It is inconceivable and logically impossible to run a business without having languages to express the communal meaning of the work of business. Some business languages are more formal than others, especially both the language of accounting and the languages of business process.
The standards under discussion (CMMN and BPMN and DMN etc.) are formal and technical languages. But also in significant part due to their formality, these public technical languages are also a long way removed from business value.
THE MARKET ANSWER
Nevertheless, such public technical languages are also necessary enablers for creating the very expressive and even private language we need for our work. So we have a dilemma, a classic management dilemma really, which is how to maintain access to the advanced technical skills we need to run our business, without the on-going expense?
A characteristic of a successful modern organization will be partly determined by how they are achieve the right balance between technical public enabling languages and private and semi-private business production languages. And there are lots of market solutions that contribute to answers, including consulting, channels, purchased software, BPO etc. etc. Funny how one can mash up a discussion of language and a discussion of market structure.
I begin with this disclaimer: the folks I know who are working on BPM standards are among the smartest people around. Indeed, those of my friends and colleagues who have spent time developing software engineering and networking standards (I'm old enough that that includes a lot of people☺) are virtually always the leaders in their space. My comments are not meant to reflect the quality of work represented by these standards.
Customers have figured this out. When is the last time any of you lost a deal because the degree to which your solution complies with BPMN, CMMN, or some other N was insufficient? Time for us to take the hint.