So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn - nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN.? I couldn't help but respond both within his blog as well as on our own blog.? I feel like Jim is letting the business off the hook - as he puts it - they don't care about process, and they're too busy making money to worry about process.? I think this is a cop out.? There is a comment thread on Jim's blog that I'd recommend reading for the follow up discussion, and the original "burn baby burn" statement got walked back somewhat.
But the debate didn't stay contained there.? Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN.? I can't accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention).? I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work.? I think the comment thread on his blog, and on Jim's, or incredibly telling.
But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:
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.
I literally could not have said this better myself. He goes on to make another important point I agree with:
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.
Great read from Neil.
In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else's thoughts on a process, or to communicate your own basic processes to others:
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.
For the record, I don't find Keith's "similes" confusing at all.? I find them inaccurate, misleading, and misrepresentative.? And when we turn the analogy on its head, I think that proves how pointless they are.? In practice, when people read Shakespeare they're usually in school and get help from cliff's notes, teachers, and fellow students.? Not unlike those working with business processes and BPMN ... and other tools (six sigma, lean, value stream, etc.? ).? Once again, I'll point out that analogies are illustrative, they simply don't constitute proof or refutation.
Jakob Freund of Camunda commented on Keith's blog and summed up a reasonable reader's interpretation of both Jim's post and Keith's post:
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 distinction 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 guess it just comes down to this: BPMN is quite useful.? It is even useful to people most of us would consider as "business professionals".? But there are other quite useful tools in our business process management space, and there's no reason not to use each one when appropriate.? I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog.? I liked how he closed his last comment:
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? ).
Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT.? Regardless of what the theory says, the practical reality is our customers' businesses are using this stuff.