BPMN 2.0: no longer for Business Professionals

Jim Sinur in his post BPMN for Business Professionals: Burn Baby Burn points strongly to the conclusion that BPMN is simply not suitable for business users.  I am not surprised as this has been a topic of the case management crowd since March (see Is the Checklist mightier than the Model?).  There have been many discussion recently about the new version (BPMN 2.0) and how the only additions are programmer oriented.

Studies done on the usefulness (see How much BPMN do you need? and Who is at fault – the language or the speaker?)  have not had much effect on the new version of the language.  The BPMN standard group has been focused on providing constucts that map well to BPEL, without apparent concern for the business user.  My own proposal to allow Representing Choice in a Process Diagram — an activity common for actual human processes — was passed up.

I am sure to get flooded with comments on all the additions that are business oriented.  To be fair, there are a huge number of a additions, so no doubt some of them are business oriented.  But if one steps back and takes a look at the high view, there is no question that the main thrust of the change, and nearly all of the additions, were to make BPMN more suitable to programmers.

The issue is not entirely that BPMN has been enhanced too far.  My first proposal for a standardized graphical language in 1993 (see “A Visual Language to Describe Collaborative Work” in the Proceedings of the International Workshop for Visual Languages) was based on the idea that non-technical users would find a graphical language more comfortable.  Experience in the following 17 years convinces me that even though it is graphical, there is an abstractness & formality that non-programmers find uncomfortable.  There is evidence that business people do not think about their processes in this way, and find the graphical diagram unnatural.

2 Migrate, or not 2 Migrate?

The question I would like to pose: will vendors migrate to BPMN 2.0, or will they stick with BPMN 1.2 as “good enough”?

As usual, it depends.  For server integration style BPM, otherwise known as Enterprise Application Integration, or Web Service Orchestration, there is a reasonable advantage in getting the additional formalism of BPMN 2.0 for this kind of programming.

For human style BPM which uses diagram to depict the actions of organizational members, instead of servers, may find that the additional complexity of BPMN 2.0 only adds additional complexity without sufficient benefit to the users.  I guess that is what Jim means by “Burn Baby Burn”.

Time will tell, but Jim Sinur points to the most likely and reasonable solution and that is that products will continue to offer multiple modeling notations to meet the needs of the various users.

Are Business Users Too Lazy?

It would be arrogant to suggest that business users just need to hunker down and learn BPMN to be effective.  This would be like arguing that a graphical user interface is not needed if only users would take the time to learn to use a command line interface.

The counter point is that business people are so busy taking care of business, that they don’t have time or inclination to learn a programming language.  The point that Jim is making is that the capabilities that BPMN is providing, is simply not fit for use by business people.  Not that business people are too dumb or lazy.  About thinking that everyone wants to become a programmer, he says “It is this IT arrogance that could sink BPM technologies.”

Addendum

In light of the discussion that has resulted from the above post, let me add a few clarifications for the readers encountering this post fresh:

  • I used the term “Business Professional” to mean a typical worker in a typical office.  Clearly there are many specialties including process analysts and programmers.  Process analysts and programmers are not typical business professionals.  I mean to speak about the vast majority of business professionals, and not the relatively few exceptions.
  • I never say that BPMN is useless.  To the contrary, I say that it is useful for programmers and other specialists like business process analysts.  I have traditionally been one of the biggest supporters of BPMN.  Since 2005 I have been regularly giving presentation and tutorials on the benefits of BPMN.  Still, the preponderance of the evidence is that the majority of business professionals do not gain enough benefit to make it worth their while to learn about it.
  • When I say that BPMN is not useful to the typical worker in the workplace, that is not necessarily a bad thing, nor is this an insult.  Everything that has a purpose, has such only in specific situations.  I am simply pointing out that BPMN, contrary to a lot of the misinformation spread around, is not useful for a typical office worker.  I believe there are other, better ways of representing a process to those.  It is very important for people evaluating these technologies to be aware of where and when something will be useful.
  • Finally, I hoped to demonstrate how it is that technologists will claim that something is useful for everybody, when in fact they really mean a relatively small group of specialists.  Perhaps the comments on this post succeed better than I could have.

I welcome all the comments, and thank you to all who have contributed in making this a lively discussion.

34 thoughts on “BPMN 2.0: no longer for Business Professionals

  1. “It would be arrogant to suggest that business users just need to hunker down and learn BPMN to be effective. This would be like arguing that a graphical user interface is not needed if only users would take the time to learn to use a command line interface.”

    First, it isn’t arrogant, second, no one is saying all “business users” need to hunker down and learn BPMN. Second, BPMN is graphical, it is NOTHING like a command line interface. That’s a terrible analogy for what BPMN represents. It is almost the opposite of what BPMN represents for how to communicate a process between Business and IT.

    It would be condescending to assume that a little bit of notation is too hard for business people. A very small subset of business people would need to “hunker down and learn BPMN”, not every single user, as you suggest. But just as nearly EVERYONE in business can read a flow chart, nearly everyone in business should be able to get a sense of what a BPMN diagram does, when that diagram makes use of the basics (as an example, I’d take Bruce Silver’s subsets), especially since it is already so similar to a flow chart.

    If you have a process, BPMN is a good way to model that process with less ambiguity than a requirements document alone. BPMN is just part of the picture, by no means the whole picture. It doesn’t prevent you from using value stream mapping or other process mapping techniques that also help.

    Finally, I’d argue that it would be arrogant to say they are “so busy taking care of business, that they don’t have time or inclination to learn” how to document your processes. This is a bit like saying I’m so busy working, I don’t have time to think about improving my business and planning for the future. I’m too busy I don’t have time to exercise. Well, these things may be true but it is short-term/long-term trade-off in a very classic sense.

    For clarity, I am not arguing the business should write executable level process diagrams if they don’t have time/inclination/skill. The argument is whether BPMN has any place at all (Jim Sinur seems to argue no). If BPMN doesn’t, then neither does a flow chart, a gant chart, and other visual means of explaining what is going on to the business and to other stakeholders. Does the business have time to write requirements or to participate in their creation? Then they have time to learn 5-6 icons in BPMN that they can draw to represent their processes.

  2. Keith,
    My response to your post is a bit different, I do not see the BPMN 2.0 additions as more suitable for programmers, rather than helping this standard as a common language for both analysts and developers. For the following reasons:
    a) there is an interchange format, now people can interchange models: between analysts, programmers, or even between them. Yes, we had XPDL, but it was not as widely adopted.
    b) It supports the formalities required to push a BPMN model to a BPMS and execute without almost any transformation. Previously you had no easy way to ensure data was consistent in the model, for example.
    c) It properly support different types of models: private, public, executable, non-executable. This properly allows the construction of process maps, and process interfaces for colaborations. Your business users can model higher level processes, and programmers can continue with the private executable processes, without changing the paradigm.
    d) While I agree that many new features are too technical/detailed for a business user to use/define them, it is also true that business users can understand those concepts if a programmer enhances a model with them, allowing both of them to agree on a low level model.
    e) BPMN 2.0 is an enhancement over 1.2, you can define models with a descriptive or analytic conformance level and you would be allowing other people to enhance those models with more detail, and interchange and execute them.

    So I would say that BPMN 1.2 was not enough for the entire BPM community, it was easier for a group, but not enough for other. BPMN 2.0 achieves a better overall performance of the development process.
    Besides this, I would strongly push business analysts to be more formal in their definition of models. I believe it is a business analyst’s job to own the lower level processes, and ensure data, metrics, exceptions and flow are consistent. I’d rather give that responsability to someone with business orientation, instead of technical orientation.

  3. Mariano,

    Good points. Items b-e argue that BPMN 2.0 offers a better technical capability for writing and deploying programs, and I agree. Many ambiguous parts of BPM 1.2 are clarified in BPMN 2.0, and this is good.

    Item “a” talks about interchange formats, and I have a lot of experience in this area. The specification of the interchange format is not sufficient to actually work, but it provides a beginning. With time it may get to be as good as XPDL, but people will still be disappointed. But it is important to note that the proof that it actually works today is not there.

    Finally, notice that Jim is talking about “Business Professionals” and not necessarily “Business (Process) Analysts”. These are different roles. I expect that part of the problem is that BPMN designers implicitly assume that it is designed only for business analysts, and not for business professionals at large. If that assumption was known, this subject would not be controversial.

  4. Scott,
    Thanks as always for a vigorous debate! Please note that Jim uses the term “Business Processionals” and not “Business (Process) Analysts”. When you speak, do you mean business analysts, or are you speaking about the wider set of people: all business professionals.

    I find it odd that you take this position because I know you are a big fan of Lombardi BluePrint. BluePrint offers a “grid-notation” which is not at all like BPMN for the business professionals to use. Later, it can convert this automatically to BPMN, which is primarily for use by business analysts and programmers. To me, one of the slickest features of BluePrint is that it does NOT force the business professionals to use BPMN. The grid notation is seen in several products, and it appears to be a better notation than BPMN for business professionals. If it was not so, one might ask why it is in the product in the first place.

    Jim’s point is that grid notation, and other notations, are not going to go away to be replaced by a single, universal notation. There will continue to be multiple notations because there are always going to be different audiences. IBM/Lombardi BluePrint appears to support this position.

    • Keith, you’re putting a lot of words in Jim’s mouth – he didn’t mention any other notations going away, nor BPMN as a single, universal notation. Of course there will continue to be different notations that support different audiences. But the statement was that BPMN wasn’t suitable for “business professionals”. I take issue with that statement. BPMN *is* appropriate. As are other notations, as appropriate. When I speak, I refrain from using terms like “all” or “none” because those terms make the statements false. If I say BPMN is appropriate for “all” business professionals, that is false. If I say BPMN is inappropriate for “all” business professionals, that is also false. Absolutes just aren’t very relevant.

      As for Blueprint – it is a good tool/diagram approach for a *wider* audience than BPMN – but I wouldn’t say Blueprint is good for business professionals and BPMN isn’t. Blueprint is also appropriate for a technical audience, depending on the stage of process understanding. And BPMN is appropriate for business professionals when they can or need to be more precise or less ambiguous, than with process mapping.

      Just because I like Blueprint doesn’t mean I’d throw away BPMN as a tool for business. Both are useful.

  5. Pingback: On IT-business alignment and related things » BPMN 2.0: is it really “not for the business”?

  6. Pingback: links for 2010-09-01 « steinarcarlsen

  7. Keith,

    I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

    Furthermore, there has not been made any disctinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

    But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

    I see a lot of weaknesses in BPMN, no doubt about that. But I wish this whole debate could become a little bit more profound and be based on real project experiences with the standard, so we can improve it together. It’s always easier to tear sth. down then build it up, but it won’t lead anywhere.

    Maybe this is also interesting: http://bit.ly/bl5Z0a

    cheers Jakob

  8. Jakob, you’ve captured my feelings on the subject precisely. If I’d read your response before responding above, I could have just said written this much 🙂

  9. Jacob,

    You have hit on one of my frustrations and a big part of the reason for writing this post. There is a big disconnect between business and IT, even when they say the same words.

    When a business person talks about “business being in control of the process” they mean process will be completely under the control of non programmers. But strangely, when IT hears this statement, they think it means that there will be a few specialists called business analysts who will help the programmers with the implementation. It is strange and almost surreal to see this disconnect manifest.

    Both Jim and I used the term “Business Professionals”. Who ever got the idea that “business (process) analysts” had anything to do with the discussion? Why is it that we (the BPM community) automatically assume that the conversation can’t really be about all business professionals? There is a built-in filtering going on.

    That is really where I wanted to go with this: many BPM supporters will state that BPMN is good for all business people when they really mean that it is good for a very small, specialized subset of all business people. If you then press them, and point to a random office worker and ask is it good for them, they will roll their eyes and say “Of course not! When I said it was good for business professionals I didn’t mean it was good for all business professionals.” What remains unanswered is precisely which business professionals it is suitable for.

    I would like to point out that I don’t necessarily consider this a weakness. I did say that BPMN gained useful capability for programmers, and I never said that it was going to die. Why then can’t we accept that there exists a group that it is not useful for? There seems a presumption that BPMN can be considered “strong” only if it is universal.

    Ultimately the main message here is that there is NOT going to be a single, universal language for all people. I don’t see any strong arguments against that. The other notations are useful, necessary, and not going away. Most comments seem to be responding as if insulted by my suggestion that there is a substantial section of people for whom BPMN is not good. I am a big supporter of BPMN, but I know its limits.

    • Keith, no one was arguing for a single universal language for all people. So you’re not going to see any strong arguments taking that position 🙂 Any other windmills we need to knock over? 🙂 The second argument was off-topic (control, rather than usefulness of the notation).

      Keith, you made it sound as if BPMN was good for “no one” on the business side, as did Jim. That’s not constructive or true. Also, when someone says “business professional” that is a far cry from “business users”, and it is reasonable to assume that people responsible for operations and business process improvement are “business professionals” – I’m surprised you feel otherwise. It is also reasonable to assume that a “professional” is interested in self-improvement, education, understanding of their business and how it works. A user may not be a professional, but a professional may also be a user. If someone truly is a professional, I would expect that they can learn enough to read BPMN, or to have someone explain the consequences of a BPMN diagram to them. When people who do this day-in, day-out (like apparently, Jakob and I do), hear from other people that that “business professionals” can’t do this, who are we to believe? you and Jim, or our lying eyes?

      You like to set up straw men, that you can easily knock down, because you’ve set the conditions up nicely to make the playing field biased. I could just agree with a statement you make, because it is technically true, but the impression the statement gives is quite different from the truth of the statement. When you say that BPMN isn’t good for business users, the impression people will get is that BPMN isn’t good for “any” business users, but it isn’t strictly what the sentence says. But impressions matter. But when I make a distinction, you seem to demand an adherence to a black-and-white “all” or “none” group. I don’t know what’s driving that, except the interest to carve out an exclusive space for ACM, but you’re overreaching if that’s what you’re after.

      If we’re talking about READING business process diagrams, there are lots of people within the business who would benefit from being able to do this, or do this better. Authoring business processes, a smaller subset. Must I point to specific people in a cube farm for you to believe someone in the business is one of the “right people” – or does an operations group within the business that reports to the COO suffice for your taste? Or the owner of a customer service process, and the managers of the customer service teams? Or the lead user of a quality assurance process who wants a better process for their team of QA analysts? Or the folks responsible for processing bond payments for complex securities? We can accept there is a group BPMN is not useful for. But your efforts to define such groups go too far – using black and white all-or-nothing approaches. We both know the world isn’t like that, the world is grey. BPMN won’t be useful for the average retail “business user”. There’s one group. I’d say all, but someone will be able to point out an exception to my “all” to make me wrong. I can accept that.

  10. Thanks for clarifying, Keith.

    I think we both just want a productive debate without destructive generalizations like “BPMN is [no] good for Business users”.

    I am also frustrated by the BPMN hype, because it necessarily leads to the Desillusionment that BPMN is no silver bullet (surprise!) followed by the awareness that it can be indeed very useful in certain circumstances (surprise again!). I would love to come directly to that awareness (http://bit.ly/bZYTrT).

    Maybe the two of us are not totally aligned what those “certain circumstances” exactly are (e.g. I do discuss BPMN diagrams with no-BPMN-Users and it works out), but that’s actually what I would like to see this debate heading to: How and when can I use BPMN (2.0) successfully, and when not, or what do I have do watch out for when working with it for beeing successful. Hmh, this sounds somehow weird, but I hope I could clarify my point as well.

    cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen ;-)).

  11. Hi Scott, you say “no one was arguing for a single universal language for all people. So you’re not going to see any strong arguments taking that position”.

    I don’t know you Scott, so I hope you’ll forgive my being contrary 🙂 but – I believe lots of people *are* strongly arguing for a universal language. Would it not be an enormously important step forward? How much would it save in misunderstandings prevented, in project overruns and failures avoided, and in IT people not getting blamed for delivering the wrong thing? If a universal language were impossible then it’s a sterile debate, but there do seem to be viable options emerging.

    (I must declare an interest, in that a ‘single universal language’ is my day-job, but I hope you don’t mind my chiming in.)

    • @Whitcombe (sorry page layout is covering up your first name for some reason) –
      No apologies needed for chiming in and being contrary 🙂 You have caught me not being specific enough in my assertion. Nobody on this comment thread was arguing for BPMN being universal – I had already commented on Jim’s blog (and my own) to the effect that it is not the universal language for everything. But neither is it the language that is inappropriate for everyone in the business 🙂

      Please, by all means, you and Keith can have that argument between the two of you, because he and I are in agreement on that point 😉

  12. Very interesting debate, and it’s heartening to see that it has gravitated towards a higher level discussion on the overall scope of BPMN.

    I think that two aspects are important –
    a) BPMN as a standard – and its industry adoption as such.
    b) BPMN as a graphical process modelling language – and its target audience.

    Firstly, I think BPMN has done well as a standard. Many BPM vendors already support BPMN 2.0 directly i.e. the modelling language is BPMN, or support it as an interchange format (where you don’t model in BPMN, but can export your model to BPMN for greater interoperability with other tools). For those who don’t I assume its on their roadmap. I agree with Matthew Whitcombe that a standard is needed and is good for the industry in general, and BPMN as it continues to evolve is well placed to be that standard in the long term.

    On the second point (should BPMN be used for modelling) I am not so sure. Here I think, end users of the modelling tools should be allowed to choose their modelling tools (and associated notations) while maintaining interoperability. And this does happen. Should business users have to learn to model in BPMN? Not necessarily. That, business users (non programmers) would eagerly want to learn BPMN was an incorrect assumption and it has been proved so. It is a matter of individual choice and inclination. And there would be a trade-off between individual choice and conformity to an industry standard; if BPMN pushes too hard it will fail. The vendor community should leave business users with the tools they love for instance, MS Visio (which I think supports BPMN 2.0 now) where they can draw their boxes and arrows to tell IT at a very high level about what they want their process to do; and then IT can take care of the rest.

  13. And lastly I feel vendors should stop touting everything they develop as “business user friendly” or “aimed at business users” or “model and deploy without IT’s intervention”. That is the ideal state, not the current state. Marketing departments have to take a portion of the blame for creating unnecessary hype about things.

  14. Pingback: Process for the Enterprise » Blog Archive » I See Business Professionals… Using BPMN

  15. Keith

    “Experience in the following 17 years convinces me that even though it is graphical, there is an abstractness & formality that non-programmers find uncomfortable. There is evidence that business people do not think about their processes in this way, and find the graphical diagram unnatural”

    This does partially correspond to what I have also seen in related areas. But I think the issue has more to do with the graphical representation’s unability to cope with complexity than with their level of abstraction.

    Graphical representations tend to be very good at representing structures that exhibit a fair amount of regularity to them – and that do not change widely day to day – so that we can understand them by just looking at them and that we do not need to re-discover them every day.
    But as soon as you need to start dealing with exceptions to the established – which is frequently where most of the danger or the opportunity is for businesses -these representations break down. They get on the way, and, worse, they prevent the work from being efficiently done and make themselves irrelevant.

    Almost all cases that I have seen where the early jubilation with graphical representations gave way to frustration and worse had their roots in this issue.

    Standards, in particular if they are graphical, need to take “graceful degradation” with exceptions into account if they want to avoid becoming just marketing checkmarks and engineering “have-to-do-but-we-don’t-really-need-them”s.

  16. Pingback: BPMN Quotes of the week « Adam Deane

  17. BPMN 2.0 no longer for business professionals? I’ve never thought about this but I was always wondering … has BPMN ever been for business professionals?

    To answer the question I think we’ll have to answer another question firstly – Who are the business professionals? Are their foreheads marked with “I am a business professional”? I am sorry I’ve never met people with such foreheads but my clients – who never care about it is business or programming. Some of the questions I’ve been asked for hundreds times are like these, “Can the process be moudled and then automated?” “Is there any benifit?” and even “How many employees I can fair if the process is automated and improved?”

    Besides the programmers (I’m a programmer) I think all others users of BPMN are the so called “business professionals.” These people are not lazy at all but working hard and thinking hard about benefit every second. They are benefit-minded not programming minded even not business minded.

    To create a language that both fits the business people and the programmers is the major idea of BPMN but the OMG people (I guess they are mostly programming minded people) make the specification very complicated (this is not bad) and they forget one thing – that the business people understand the diagrams (many of them have the great MBA degrees, which I do not have) but not all the details.

    So the BPMN 2.0 should be of different levels (which the OMG guys ignore), at the high level it is useful to both the business people and the programming people, at the detailed level (I call it the executable level) it is the programmers’ business, and between the two levels there should be the adapters. This way the BPMN would be closer to “perfect” but unfortunately we are still here talking about “no longer for people who need it.”

    I do not know what I am saying and I’ve never been good at the great language (here I mean English not process modeling language) – I am sorry for that.

    Fan Yi
    Joinwork Software, Inc.
    http://www.joinwork.com

  18. Pingback: Column 2 : The Great BPMN Debate of 2010

  19. Pingback: The Great BPMN Debate of 2010

  20. Pingback: Covering all sides of the BPMN Debate « Fujitsu Interstage Blog

  21. Pingback: BPMN (and others): good … except exceptions? « Everything Decision Management, Technically Speaking

  22. Pingback: BPMN vs. professionals, 2.0 | On Collaborative Planning

  23. Pingback: BPM: Who is a Business User? « Adam Deane

  24. Finally, I’d argue that it would be arrogant to say they are “so busy taking care of business, that they don’t have time or inclination to learn” how to document your processes. This is a bit like saying I’m so busy working, I don’t have time to think about improving my business and planning for the future. I’m too busy I don’t have time to exercise. Well, these things may be true but it is short-term/long-term trade-off in a very classic sense.

    Scott I think you provided a great analogy with your comments on ‘planning for the future’ or ‘too busy to exercise’.

    All in all these are some great arguing talking points 🙂

    Thanks!
    Joe

    University of San Francisco – 110% online
    BPM Certification

  25. Pingback: BPM and 2018 | Thinking Matters

  26. Pingback: The Great BPMN Debate of 2010 • Column 2

Leave a comment