From [url="http://www.bplogix.com/"]E. Scott Menter[/url]: Do you think that the more a company is concerned with standards compliance, the less they are (perhaps) focused on changes in the marketplace, customer demands, and business trends.
I think this is always true when means become goals.
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 [url="https://en.wikipedia.org/wiki/Through_the_Looking-Glass"]Through the Looking-Glass[/url]:
"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.
- Bogdan Nafornita
- 10 months ago
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).
- karl walter keirstead
- 10 months ago
Never understand why people go overboard one way or the other and never take the middle path.
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
[i]suddenly[/i]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.
Now I think that is ridicule so we make progress! Now it might hurt your head a bit more to "get it" but once you do it really will clear your head...
- David Chassels
- 10 months ago
- Dr Alexander Samarin
- 10 months ago
- David Chassels
- 10 months ago
In our industry, though, because the standards are failing to adapt*, we've been forced to largely abandon them altogether. But it's a period of turmoil and innovation in this space, so perhaps useful standards have to wait for a certain amount of calm before they can emerge.
*) Exhibit A, in which the authors describe a significant gap in standards that, years later, remains unaddressed: Gagne, Denis, and Trudel, Andre — The Temporal Perspective: Expressing Temporal Constraints and Dependencies in Process Models, http://pheasant.acadiau.ca/Publications/BPMhandbook.pdf
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.
Co-founder and CTO, One Network Enterprises
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
[i]has [/i]ISO or ITIL processes, or i
[i]s standardized on BPMN.[/i]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.
It would be interesting actually to see a list of "must-have" constructs for BPM. (node, directional arc, . . .)
Seems to be a very short list when you look under the hood.
Easy enough to figure out what the start node is in a flowgraph - it's the one that has no predecessor. End nodes have no successors.
You can make a branching decision box by lassoing two or more nodes. Rules at the options within the decision box determine whether the decision box is single pick or multi pick. If the routing for a node or a decision box is "system", we can expect auto-execution based on data values acquired prior to the node.
A loopback is nothing more than an ordinary directional arc except that it goes in the opposite direction to the flow (right to left instead of left to right). Handy, of course, to be able to set a counter so you can have some control over the number of loopbacks,
- karl walter keirstead
- 10 months ago
What does the word "focus" mean in the context of the question? It means there is perceived to be
[u]a business case for expenditure on maintaining a given enabling capability[/u]. And thus the answer
[u]depends on the business model[/u].
1. COMMODITY FUNCTIONS -- NO JUSTIFICATION FOR ANY INVESTMENT IN MAINTAINING SIGNIFICANT KNOWLEGE OF TECHNICAL STANDARDS -- IT departments continue to be "disrupted" and
[u]BPO isn't done yet[/u]. Formerly, it was "why build my own software, even with RAD, when I can
[u]buy an ERP[/u]?" 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
[u]you don't build your own processes for commodity processes[/u].
2. DIFFERENTIATING FUNCTIONS -- JUSTIFICATION FOR YOUR OWN PROCESS LANGUAGE -- The outsourced parts of your business are
[u]the commodity parts[/u]. 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
[u]an order of magnitude better than off-the-shelf[/u].
[b]BALANCE PUBLIC AND PRIVATE LANGUAGES[/b]
The enabling capability referred to in the original question is as Keith has pointed out "a language". Let's explore.
We all "
[u]speak accounting[/u]" 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
[u]express the communal meaning of the work of business[/u]. 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
[u]a long way removed from business value[/u].
[b]THE MARKET ANSWER[/b]
[u]public technical languages are also necessary enablers[/u]for creating the
[u]very expressive and even private language[/u]we need for our work. So we have a dilemma,
[u]a classic management dilemma really[/u], 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
[u]market solutions[/u]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.
I have been on both sides of the desk, as a supplier and consumer of enterprise software. No doubt many of you have as well. And it seems to me that, even if BPM were not undergoing the constant innovation and reinvention that have become characteristic of this market, the domain of problems to which it is addressed would continue to defy standardization. As Keith wisely points out [url="http://bpm.com/bpm-today/in-the-forum/does-the-focus-on-bpmn,-cmmn,-and-similar-standards-steal-attention-away-from-solving-actual-customer-problems#reply-3577"]above[/url], “Thinking that all business behavior can be rendered in a single approach is pure foolishness”. It's fine to develop ways we can communicate fundamental ideas about business process; but, as in software engineering, one language will never be enough to do so.
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.
If we can agree that In BPM there are several coordination techniques ( see
http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html ) then we can develop a set of languages to cover all of these techniques and based on the same run-time.
- Dr Alexander Samarin
- 10 months ago
- Page :
However, you are not allowed to reply to this post.