We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is BPMN 2.0 being adopted by business?

Vote 0 Votes
Last Autumn there was considerable discussion about the release of BPMN 2.0 (read Scott Francis' blog), with Jim Sinur saying BPMN should stand for, business people may not understand.  So now that we are comfortably into 2011, what is the current state of BPMN?

13 Replies

| Add a Reply
  • Assuming by "the business" you mean the 100,000s of people who work in the business, rather than Business Analysts who are process professionals paid to work 'on' the business

    Then the answer is summed up by : "The confused mind says 'No'".

    Why would "the business" adopt something that you don't / can't / won't understand. Nimbus has created UPN (Universal Process Notation) which is something that end users can and do understand. http://bit.ly/eUOVEb

    BPMN has a valuable role as the bridge between Business Analysts and IT, but we have hundreds of clients who have millions of end users who will never be trained enough to read a BPMN diagrams. So why force them to do something that they don't want to do? It is difficult enough to get them to even consider looking at a process. Why make that task even harder? UPN is at least allowing process professionals to engage business end users.

    Can I get off my soapbox now?

    BTW Before we start the "You would say that as Nimbus does not support BPMN", that is not true. The latest release of Nimbus Control supports BPMN 1.1

  • I think that any notation that can handle all of the semantic richness necessary for unconstrained business processes will be too hard for business people to author by themselves. Business people are used to being able to use flow-chart-like diagrams where they can represent critical aspects of the semantics by depending on the reader to understand through labels and context what should really happen, rather than through the notation.

    For example, if you are waiting for someone to finish a task, there might be two possible actions to take after two hours of the task not being done: 1) send a reminder to the person; or 2) take it from that person and hand it to someone else. A business user would be tempted to use the same clock icon in either situation, but for (1) the timer event should be non-interrupting, while for (2) it should be interrupting. This is an important difference that should be represented in the model, not just implied by the labels "remind" vs. "reassign".

    I do believe that BPMN is can be _understood_ by business people with a small amount of training. As such, a technical person can help with the creation of an executable model and the business person can understand the result in order to validate that what will run is what they wanted.

  • BPMN 2.0 is steadily emerging as the defacto standard for process modeling and process exchange. BPM vendors are already providing support for this standard and strongly behind it. I, however, still see this as an IT-driven requirement.

  • I don't think we are there yet, neither for business (end) users nor for business analysts.
    I also got the perception that BPMN 2.0 has been the occasion for the BPM community to stop and deeply question itself on the trend toward continuous development of newer and more complex versions of BP notations.
    Accordingly, I know about some tool and system providers that are quite cautious in adopting BPMN 2.0 in their implementations.. so, you can imagine how long it will take to become mainstream for the business.

  • Companies evaluating BPM suites are placing heavier emphasis on BPMN 2.0 support because they see it as a critical standard for providing modeling consistency across business processes. However, on the ground, adoption of BPMN 2.0 is taken more seriously within organizations that have numerous BPM teams using different BPM tools. For example, organizations like DoD and large multi-national banks have embraced the benefits of BPMN 2.0; however, smaller centralized-BPM teams are placing less emphasis on BPMN 2.0 as a panacea. Last year I challenged the OMG to consider benchmarking BPMN 1.x and 2.x adoption to get a handle on adoption trends. The response: We're focused on BPMN adoption numbers for members (i.e., vendors).

    - Clay Richardson, Senior Analyst, Forrester Research, serving Business Process Professionals

  • BPMN is far from perfect, but it's the only standard we have. The problem with alternative fit-for-purpose notations, some of which might be less expressive and more business-friendly, is they are proprietary, owned or supported by a single tool. Effective implementation of BPMN requires organizations to agree on standard working sets of the notation, as the full palette is more than anyone needs (except for executable models). The Descriptive subclass is mostly familiar from traditional flowcharting, and all most business users would need.

  • I disagree with Bruce Silver when it argues that is the only standard. It isn't because you can map a process flow using EPC and you can map it also using value stream flows, just to name a few. And it's not a very good standard as my previous analysis on this blog post http://antiamba.blogspot.com/2010/05/bpmn-can-bring-death-to-your-process.html .

    I agree with Ian and with others regarding BPMN is more complicated to understand by business people. BPMN have huge a pallet of symbols, lot's of rules, concepts different to understand: why communication between two different business units or across different stakeholders must be connect using a message flow artifact when most of the times there is no message attached. BPMN rules are difficult to validate (mapping tools makes a huge mess trying to do it).

    BPMN supporters argue that BPMN mapping can be simplified using only the artifacts that make sense, but this is a contradiction regarding the notation architecture.

    I think that the only true advantage is the BPEL link that fuels automatic web services development, very important when making system integration.

  • Bruce

    UPN - Universal Proces Notation - is freely available and every tool on the market can support it. It was true altrusim and not some clever marekting ploy by Nimbus. Plus it is proven for millons of people.


  • What is the primary objective? Bridging the communication gap between business and IT? Making it standardized to free it of wordy prose of "requirement documents", eliminating other causes of subjective interpretations by IT of biz need, requirements and objectives? Bring commonality in order to remove idiosyncrasies and quirks in the way product vendors like them to do it?

    And what does it look like now? Does it look like we are trying to get business to merely communicate what they need or more? Does it seem like we are trying to empower IT or business? Are we addressing an IT problem by weaving holy-cow logic around empowering business?

    I am afraid the answers may not necessarily be what we expected it to be when we set out looking for a standard.

    Or am I way off mark?

    Take a look at Phil Gilbert's comments in this talk. (Start at 22.00, if you are too impatient to listen to the whole talk)

  • BPMN 2.0 is indeed far from perfect. I also agree it's off-putting for business. What I don't agree is that this is because of the hundreds elements and rules. Yes, that is overwhelming but it's more a matter of communication.

    It's not the style of OMG but it would have been better to create and market actively a document that is simple, clear, with lots of examples of practical application, ideally supported by animated diagrams showing with token and message movements how things work. And when talking about attributes, stress on times on costs instead of "isForCompensation" and suchlike. The latter and all the formalisation logic, exceptions, compensation, meta-model and XSD can be in a separate document, somewhere behind, not in the BPMN home page. Whoever need it will find it.

    A good example is the Business Model Generation book. That was based on the PhD dissertation of Alexander Osterwalder. If he had published his dissertation as a book, it would wouldn't attract many readers, especially from the real target audience. Now, presented in the right way, it's a world best-seller.

    But well, back to OMG, you don't have a second chance for a first impression so the damage is done. Now may be the target would be those who business people listen to. If they take on BPMN, they'll find a way to sell it.
    And selling it is good for many reasons. First, this is the way to improve it. Then, it's really good to have one language. And third, it will good to be easier for clients to change not only tools but also consultants.

  • @Alberto and Ian... Love it or hate it, no problem, BPMN 2.0 is what it is, and as Ivo says, "the damage is done." My point is that it is really the only widely accepted multi-tool standard. So enlighten me please. What tools besides ARIS support EPC? What tools besides Nimbus support UPN? If we just mean a single tool with lots of users is the same as a "standard", then boxes and arrows in plain Visio is the overwhelming modeling standard.

  • Bruce:
    I think that you base your reasoning regarding a standard adoption if somehow is mostly available is business suites, meaning that is widely accepted by the systems users. But unfortunately it isn't.

    Drawing a BPMN process takes twice as long to do it (means you are wasting money to draw your business processes), and if you want to do it correctly because you need the information to translate it to BPEL or you have an expert or use a tool that can properly validate it like IBM's System Architect (not like other tools that makes users fool eluding you are drawing according to the standard).

    When you say that boxes and arrows in Visio is as overwhelming standard, I think you are right. Because the ultimate goal is to communicate the way work is performed in a very simple way and people need to do it quickly and in a way everyone understands.

    In manufacturing industries (long forgotten in this context) continue to draw processes in paper glued on a wall inviting blue collar workers to participate, because it makes part of it's culture with very good results.

    Pharmaceutical industries continue to use basic process flows ISO like on their standard operating procedures, clear, understandable by people that perform critical tasks assuring you can have your medicine without taking wealth risks.

  • Its a fad these days to adopt standards and not without reason. It does bring in a common language to a multi-cultural-lingual world we live in.

    However, BPMN being adopted by businesses is too far fetched and a "closed" question to an "open" subject.

    Without getting into "what is a standard" argument, BPMN is the most popular modelling notation that is currently floating around and so, businesses that have heard of it and want to deploy BPM are attempting to adopt BPMN. Whether they have adopted it is perhaps a question for another day.

    A clear example lies within my own employers. The unit responsible for managing the business requirements have said they will use BPMN from hereon. Irony is that not even a single person within their unit "knows" even what the acronym stands for. As a result, under the umbrella of BPMN, we see a basic flowchart taking life with ad hoc use of events to give it a BPMN flavour.

    The battle is going to be against the age old flow chart, so whether it is BPMN or EPC or UPN, the whole industry must come to a consensus and then wait until it seeps into the veins of the normal business user and the entire education system before they become a reality.

    Until then, we will see these arguments playing ping-pong among the "regulars" of the industry.

Add a Reply

Recently Commented On

Monthly Archives