blog

BPMN “not for the business”? Let’s lose the hype

Neil Ward-Dutton

Wednesday, September 1, 2010 by

In a post today called BPMN 2.0: no longer for Business Professionals, Keith Swenson of Fujitsu (lead author of Mastering the Unpredictable) builds on a recent post on BPMN from Gartner’s Jim Sinur (BPMN for Business Professionals: Burn Baby Burn).

Both focus on how the BPMN standard is out of the reach of “the business” – with Keith taking particular aim at the new version of the modelling language and notation.

Jim says:

Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark.

Keith says:

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.

If you haven’t read both posts then I urge you to do so!

In reaction to Keith’s post, Scott Francis (@sfrancisatx) – someone else I admire a lot – tweeted:

yes, learning 6 BPMN icons wud b 2 much, right?

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

So let me add a couple of thoughts.

First, let me say that in my mind there’s no doubt that the transition from BPMN 1.2 to BPMN 2.0 was primarily about adding more detail and sophistication (and complexity) to the specification to make models directly executable. This is an IT concern – in line with what Keith and Jim are saying. And for sure, as zur Muehlen and Recker have shown, the modelling elements within earlier versions of BPMN have not been what you might call exhaustively exercised in the field. So it’s likely that for the foreseeable future, if you consider the *whole* of BPMN 2.0, then for sure it’s not something that will be widely adopted in practice.

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

However let me also say that I’m  not of the opinion that BPMN (even a subset) is suitable in all environments. For BPM initiatives to succeed, business managers and front-line staff without specialist analysis skills need to be engaged and motivated to participate, particularly in the earliest stages of initiatives where improvement opportunities are being uncovered, explored and prioritised. Here, even a subset of BPMN is unlikely to be the right place to start. Scott, I think, uses a distinction between “process mapping” and “process modelling”. When “mapping”, a simple boxes-and-lines approach can work pretty well in my experience.

To circle back : as I wrote in a MWD report from earlier this year (BPMN 2.0: a good move, but for whom?) – talking about a set of tests that should indicate a useful BPM modelling standard:

Given that BPM best practice in industry reflects the importance of involving business experts as well as technologists in describing and implementing processes, we feel that the following are all very important [in a modelling notation standard]:

  1. It should prescribe a notation that’s understandable – not just by technologists but also by non-technical business process stakeholders.
  2. It should help create the biggest possible pool of process modelling skills in industry – making modelling skills transferable across tools and across employers.
  3. It should facilitate the exchange of process models between tools from different vendors – making it possible for work done by one team or organisation to be shared with another, and making it possible for organisations to use multiple best-of-breed BPM tools side-by-side without having to carry out lots of rework.

Right now, if you consider the *whole* of BPMN 2.0, it’s pretty tough to say it passes any of those tests in my opinion. But we don’t have to consider the whole of it – as Scott says, 6 (or 7) symbols can be pretty useful in representing work for the purposes of collaborative analysis and initial design elaboration, and straightforwardly understood by different groups of people – including BAs who aren’t “IT people”.

At this stage, key to making the value of BPMN real is the widespread adoption by tools vendors, consultants and trainers of a set of BPMN conformance classes (Bruce Silver has some good analysis of these) that were introduced at the late stage of 2.0 standardisation. So far, there are some positive signs.

To conclude: saying “BPMN is no longer for the business” might provide a great headline, but it’s just too simplistic a position. BPMN can’t play every role, but it does have a role to play.

Posted in BPM

6 Responses to BPMN “not for the business”? Let’s lose the hype

  1. Neil, you have said it better than I could have said it myself. I wrote my own response to Jim’s article here: http://www.bp-3.com/blogs/2010/08/apparently-bpmn-is-too-hard/

    Agreed: the “business” is not homogeneous, nor a single entity. In “mapping” even lines are optional – implied ordering from left to right or top-to-bottom (or both) is enough at that level to communicate. Also agreed, it is too much to expect people to know every corner of the BPMN spec. But it isn’t necessary, either.

    Excellent summary of all the issues, without the superlatives, Neil. Thankyou -

    Scott

  2. Keith says:

    Good summary. You are right, it is not that simple, but I hope I have made people think about what it really means.

    It is funny how saying that BPMN is not useful to everyone leads people to think you that you are (1) criticizing it or (2) saying it is going to die. I am only trying to say that other notations are necessary as well, particularly for one identified group of people.

    Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

  3. Neil Ward-Dutton says:

    Keith, I guess my reaction is more to the headline than the detail of your argument. I think it’s important to be careful about “headlines”, because in my experience things tend to run away with themselves easily in this industry. Lord knows we can do with a bit less invention for invention’s sake… a flawed standard still has uses and value. I think we are probably in agreement about the practical detail, anyway, judging from your other comments and thought pieces.

    If I understand the second part of your comment correctly, my view is that the risk of unintended consequences (re: your point about learning letters vs learning language) goes away in practice if teams work in a sensible way – that is, collaboratively, and with the right internal or external mentoring. A little knowledge is a dangerous thing, if applied in isolation. I would certainly worry if people with only minimal understanding were being asked to produce functioning process applications from BPMN models without any assistance – that would be a recipe for disaster. Fortunately I haven’t come across any situations like that…

  4. Keith, I can sum it up this way:
    1. you gave the impression not that “other tools are needed as well”, nor that BPMN wasn’t “useful to everyone”. you gave actually the impression that BPMN is not useful at all to anyone described as a “business professional”. That is a completely different thing, and I think you can see the difference as well.

    2. regarding 6 or 7 shapes, and your shakespeare analogy. Look, Keith, once again you have a sort of ad hominem attack using an analogy that sounds good in theory, but is irrelevant in practice. As Neil put so well, and without any tone of the frustration I regret expressing, in practice this concern goes away because people aren’t working in a vacuum. Think of it this way – many people know the story of Romeo and Juliet but can’t write it themselves. Nor even reproduce it, having read it. Some people struggle a bit with the vocabulary but a little cliff’s notes will fix that problem.

    I’m not worried about these theoretical problems because I see, in practice, that people easily overcome them.

    And just to be clear: I agree that BPMN is not useful in all situations :) Neither is any other tool I’ve ever heard of.

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

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

Leave a comment: