BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 30 November 2017
  5.  Subscribe via email
From this comment from Dr. Alexander Samarin: "I noticed in several RFPs that any coordination of work is considered as a process (very good) and it is forced to be described in BPMN (not always good)." So where have you seen BPMN used in a way that it wasn't well suited for with not always the best result?
Accepted Answer Pending Moderation
BPMN doesn't work well in describing the participant's journeys - which is increasingly being recognized as the most important aspect to focus on.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
Any time you force a business professional to understand BPMN, it is risky at the minimum and a mortal sin at the maximum. BPMN is great for a common communication capiliity for engineers and software, but as communication device to business professionals?
Comment
  1. John Morris
  2. 1 year ago
  3. #4846
Reminds me of BusinessWeek cover story (September, 1991) entitled "Software Made Simple", complete with baby at the keyboard. Apparently object oriented programming was going to make "computers a lot easier to use".

Turns out that, as you say, it's often more about IT professional conversations. Business is somewhere else. Business analysts however, different story.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
It may be quicker and easier to ask "Where is right place to use BPMN?" as it has a narrow sweetspot compared with the whole of BPM. Jim nailed it when he said "BPMN is great for a common communication capability for (dev) engineers and software"
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
No worries . ..

We sell "workflow/workload" management software, not BPM, not notations, so anytime we see an RFP that indicates a specific notation, a particular dbms, or a particular programming language, we pass.

When I call a plumber, I don't tell him on arrival what tools he should use to fix my problem.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
BPMN is just a language; a visual language, but a language nonetheless. We use language to communicate. Groups use a common languages to simplify this communication and make it efficient. (Being fluent in French is well and good, but doesn't get me far if my audience understands only German.) We follow a language's rules of grammar and syntax because communicating with others on this shared foundation allows us to understand each other even more easily. (Consider "Jabberwocky".) We can communicate using the simple words and sentence structures of a children's book (BPMN Level 1 palette), or the complexity of an academic paper (Level 3 Palette). The former offers less nuance but is a far better choice if it represents the limit of the audience's understanding.

The entire point of any conversation is an efficient and effective exchange of information BPMN is an excellent language if the "speaker" follows its rules of grammar and syntax, uses "words" (symbols) that accurately describe the idea at hand, and "speaks" using a vocabulary that the audience understands (or can be taught to understand quickly). BPMN stops being a useful tool when the "speaker" models in the equivalent of BPMN gibberish; when BPMN's vocabulary simply isn't capable of describing the idea at hand, or uses a vocabulary that's inappropriate for the audience's comprehension.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
As said above, in any communication you don't get too far if both parties don't speak the same language.
So it's fine for the customer to force BPMN in their RFP, if this is the language they understand. And it's fine to pass it as a vendor if you don't speak it yourself.
Still, as said many times over around here, I have yet to meet a small customer (with zero prior training) who does not get our BPMN process flows immediately. Maybe because all the powerful technicalities are already abstracted into call activities?

And it's valid for any language - if you use sophisticated jargon instead of plain, common expressions, your audience will shrink dramatically.
CEO, Co-founder, Profluo
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Maybe we are all missing something here. BPM.com runs the BPMNext conference, where BPMN is at the heart of the title, but probably not the presentations and content. Having BPMN in the name dramatically reduces the potential audience for the event. Which is a shame had some great speakers and is in a fantastic hotel in Santa Barbara - I still remember wine tasting on the rooftop terrace.

So the title of the event is clearly a place where BPMN shouldn't be used!!!
Comment
Well, you know, they spell it bpmNEXT so to be honest, Ian, this is the first time it's occurred to me that "BPMN" was in the title.
Also I think technically bpm.com is not the sponsor, though many of the same folks are involved. I could be wrong.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
+1 to Jon for his remark, "...when BPMN's vocabulary simply isn't capable of describing the idea at hand". Turns out that there are some ideas that are very difficult to communicate in some languages, and much easier to communicate in others. In fact, one's native language can even predict certain cognitive patterns, such as the ability to distinguish between shades of colors. Language is more than just a translation table from word to concept, object, or action—which means that choice of language is meaningful when you're approaching a given type of problem.

I'd argue that BPMN's vocabulary is too limited to support the conversations (solutions) in which organizations are engaged today.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
I use the following rule - classify activities into two groups: 1) added-value for the primary beneficiary of the process and the rest. If the first group is much smaller than the second one then BPMN has been misused. The real example - I was asked to review a process in which the ratio between the first and the second groups was 1 to 9. This was a signal for me that something is wrong with the process. After redesigning that process, the ration became 7 to 2.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Re: BPMN

Pitch: Psst, come over here to see our fantastic process mapping tools.

Pitch: Before we get started, though, you have to learn our language "BPMN".

Response: We don't want to have to learn a language, all we want is to be able to drag and drop circles on a graphic canvas and connect them with arrows, then compile the graph and run a few test Cases. We can get our IT to help with rules and data import/export.

Pitch: . . . .
Comment
Yes Karl that is how to deliver. Our way think declarative from model to pre coded relational database and ready to run that first test; no compiling or code generation. BPMN should be redundant?
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
No one balks at "learning the language of accounting" when defining an accounting function as part of a business.

Everything above here is good commentary, but perhaps a little pessimistic. I believe that we are on a business process technology and practices adoption curve which is gently sloping On such a curve, it's easy to be discouraged about the potential for BPM (and the BPMN language).

OK, so BPMN doesn't do cross firewall customer journeys so well yet. At least BPMN is a "common-ish" language. But deploy on something less popular, or build your own coded apps (hello de facto proprietary language) and see how fast the cement freezes.

The hard part (at least when you're using the latest BPM software technology, which minimmizes the code-oriented roundtrip problem) in all this is business analysis. Where is your specific understanding of what you want to automate? Can you define and rank use cases, and business cases? Can you be specific enough to encode the tacit?

So, what's a misuse of BPMN? Thinking too much about BPMN, instead of business analysis. BPMN "just is" and it will evolve.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
BPMN has created to enable engineers and software experts to understand, what is the process about and maybe then to design the (it-)system to support the process or activity at focus. When working with the managers or performance developers I newer use symbols other than activity (rectangle) and information flow (arrow).
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
BPMN has definite strength in technical process automation. It is achieved through dozens of proprietary and open source implementations of BPMN engines tailored for interoperability with an impressive array of business software from various target domains. This strength is additionally reinforced with high degree of standardization ensuring transparent exchange of BPMN processes among all these applications and technologies. Perhaps, BPMN is one of most commonly used business language in the area of technical automated business processing.

Process transparency creates a unique ecosystem in growing family of tools supporting open BPMN process collaboration and increases its attractiveness for wider business generalization. However, exactly these voluntary expansions create a potential trap of BPMN misuse. In regard of generic business structuring and vision, usage of BPMN might look much less beneficial and relevant. There definitely exist many other dedicated languages for these business contexts. Even in technical execution area one can find many more alternative languages specifically designed for their specialized areas. As any language, BPMN is best to use in areas where it best suites in terms of its vocabulary and expressive capabilities and should be avoided of artificial enforcement into alternative areas where its relevance is dubious.

BPMN is one of widely spread languages for business modeling, which, as any other language, should be used in areas where its palette of objects and rules gives a convenient and efficient description of business practice. Where it is relevant or not, only practitioners, analysts and process owners can decide. If all of them are comfortable using BPMN in their daily communication, then it is the right choice. If substantial amount of users is dissatisfied, it is a good invitation to look for another, more relevant language. It is always important to see real business behind the language and not formal abstracts of the language itself. Business language is suitable when it helps to run the business and irrelevant in all other situations.

http://caseagile.com/wp-content/uploads/B.2.0.mid.png
References
  1. http://www.bpmn.org/
  2. http://www.omg.org/bpmn/
  3. http://www.omgwiki.org/bpmn-miwg/doku.php
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
I feel like the question has not been answered so far - what is a clear misuse of BPMN, and most importantly, what else would you use to achieve what BPMN has tried (i.e. to both communicate to business, and execute by computers), but failed in that use case?
CEO, Co-founder, Profluo
Comment
Let us be explicit ;) - only BPMN is not enough to properly implement explicit and machine-executable processes (i.e. understandable for all the stakeholders from the top management down to computers). Considering that any process is an explicit coordination of work then various coordination techniques may be used together. Flow-charting is only one of these techniques (see my list of them http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html ). So a clear misuse of BPMN is when BPMN is used instead of more appropriate coordination techniques. For example, in my previous comment, BPMN was use to “implement” a decision table.

As usual, we need a formal execution model which can unify all the coordination techniques (something similar to JVM).
  1. John Morris
  2. 1 year ago
  3. #4852
Following up from @Samarin's reference and @Bogdan's plea: how about business rules, or an entire decisioning function. Although not specific to BPMN, I have seen process models which were needlessly complex because decisioning was not abstracted out to a (e.g. DMN-supporting) rules engine.
Business rules is also only of one coordination techniques.
  1. John Morris
  2. 1 year ago
  3. #4854
@Samarin has suggested the larger context of "architecture". Consider that the business functional domain of operational processes is just one irreducible such domain. Business decisioning, business design and business modeling are other business functional domains. A misuse of BPMN technology is its use for purposes not suited or intended, such as these other complementary business functional domains. Here are three interesting references concerning at the use of BPMN and other technologies, e.g. the ArchiMate enterprise modeling language (No. 3 below, interestingly, from Signavio):

1. http://braimworks.blogspot.ca/2015/05/uml-vs-archimate-vs-bpmn-use-what-where.html (2015)
2. http://blog.bizzdesign.com/combining-archimate-3.0-with-other-standards-bpmn (2016)
3. https://www.signavio.com/post/enterprise-architecture-modeling/ (2017)

In budget-constrained, and/or naive, environments, too much burden can be put on BPMN as a modeling platform beyond operational processes. There are better choices.
Great conversation! Can we just carve out of the scope of our discussion any "coordination technique" or "modelling standard" that is not machine-executable (as one of the two key missions of BPMN)?
Also, can we just collapse, for the purpose of simplifying the discussion, CMMN and DMN into BPMN?
What is then left? UML?
@Bogdan, I would start from the opposite direction: 1) detect coordination techniques, 2) formalise them as patterns (GoF patterns is an excellent example) and 3) select proper tool(s) to implement each pattern in a machine-executable manner.
If you start from this direction, you're still left with tools that can implement patterns in a machine-executable manner. Of these, which are the ones that can immediately communicate to business users as well, better than BPMN?
Again, we all know that SOME languages are much better than BPMN at communicating high-level design and SOME languages are much, much better than BPMN at executing business coordination patterns. But what about that one language that can perform BOTH, better than BPMN/DMN/CMMN?
Thank to microservices and breaking monoliths, fortunately, there is no need to have one language which is perfect for everything. Thus we may employ some DSLs. In this case, we need:
a) better architecture,
b) richer set of DSLs,
c) smarter guidance on how to assemble unique processes from a set of common patterns implemented in those DSLs, and
d) good IDE.
Basically what you're asking for is a completely rejuvenated architectural approach for enterprise digital platforms, one that would beat ANY single language... Not saying that this isn't the right answer (wink, wink), but it is a bit outside the scope of the question. And also right now this requires spending $ millions just to buy, let alone implement and use. This excludes the vast majority of businesses.
Fortunately, completely opposite, again :) Being architectured correctly, such a platform can be developed and deployed in the following way:
- incrementally (MVP approach);
- cooperatively by several organisations (different partners implement different components and use all of these components together);
- each component can have more than one implementation to serve different needs;
- each installation has its own life cycle;
- each installation may have its own agile solutions on top of the platform;
- useful agile solutions may be incorporated into platform.
sounds familiar ;-)
In all this discussion I see most relevant the short reply with voting approach suggested by Dr. @Samarin. Simple scoring among process parties best reveals, if BPMN is suitable or not. Otherwise, BPMN is just one of MANY languages around. Leading tools, such as ARIS, offer 200+ methodologies per tool. Use one, which is most fit for your task and which you like best. Don't mind switching from one notation to other. After all, it is just a notation! Business behind is what really matters.
Boris, "unfortunately" we need a machine-executable language. As far as I remember, the tool, which shouldn't be mentioned; provides only "illustrative" models.
@Alexander, on machine-executable language, it exactly falls under your definition: IT team should vote for notation, which provides best available integration gateways in process context. Enough votes - approval of notation.

On tool, which "shouldn't be mentioned", I do not advocate it at all but just have a lot of experience with it and used it as illustration. Alas, we do not have capability to edit comments, so let it be. Of course, the tool has direct and quite powerful execution projections. But this discussion will lead us too far from the topic. You may PM me, if need more detalization.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
In my opinion, BPMN can be misused in 2 ways: 1) errors and redundancies, using its iconography and 2) overemphasizing its importance for an actual BPM implementation.
For the first one, I always try to recall the very basics and fundamentals for a visual representation of logical process sequences with Petri Nets and from there, trying to gain a grasp on what the processes actually ought to do. There, Wil van der Aalst did an outstanding job with workflowpatterns.com of not only listing the most common workflow scenarios to be represented by any given notation, grouping them in the categories of workflow control, resource and data patterns, but to also describe and "flash-animate" the different scenarios. This gives an intuitive access to understanding the process logic on a macro level, reducing the risks of misusing a notion such as BPMN, committing aforementioned mistakes.
As for the second "misuse" group, I think that while adhering to a standard visualization of a rudimentary process logic has its obvious advantages, it's benefits in comparison with what the rest of the BPM implementation actually entails, are completely blown out of proportion. In my experience, drawing out the processes' "IF-THEN-ELSES" represents max. a 5% of the implementation efforts and surely not more than 20% of whats actually going on in the process. There are countless forms, variables, integrations and micro business rules underneath a BPMN diagram, w/o this giving any explanation to these, at all. It becomes more interesting, and realistic, when a BPMN flowchart gets complemented with a detailed business requirement narrative and BRE definitions (DMN, even).
When RFP's stress the importance of BPMN, it usually is an indicator of the prospect user having yet to gain an understanding about BPM implementations, methodologies as well as technologies.
References
  1. http://www.workflowpatterns.com/
NSI Soluciones - ABPMP PTY
Comment
outstanding perspective, Kay, thank you!
  1. Kay Winkler
  2. 1 year ago
  3. #4871
Thanks :)!
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.