benefit from all our premium research
related research from the MWD library
most recent posts
- Microsoft swoops for Revolution Analytics: another boost for the mainstreaming of R
- Box enjoys a bullish IPO, but where will all the cash go?
- Egnyte integrates analytics to optimise file sharing and collaboration
- It’s not ALL about collaboration ALL of the time
- Save the date: Making Social Collaboration Work, May 14th
Wednesday, September 1, 2010 by Neil Ward-Dutton
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.
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.
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]:
- It should prescribe a notation that’s understandable – not just by technologists but also by non-technical business process stakeholders.
- It should help create the biggest possible pool of process modelling skills in industry – making modelling skills transferable across tools and across employers.
- 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.