BPMN vs. professionals, 2.0

Last week brought us a vigorous debate about the role of BPMN, where I took the controversial position that “BPMN 2.0 is no longer for Business Professionals“.  Adam Deane collected quotes from the major contributors.  Sandy Kemsley calls it “The Great BPMN Debate of 2010” and her post is a very fair summary of the debate, but missing one important aspect of it:  what is a typical “business professional” and what do they desire?

Within the BPM community, we tend to talk only to BPM analysts, BPM theorists, BPM vendors, and people running BPM initiatives at companies.  Let call group “BPM fans” as a neutral term to describe these people who believe there should be some way draw a flow chart of the process, and use that to automate the process, or facilitate the process.  I consider my self a BPM fan.  So are, I assume, most people who read this blog.

Within the BPM fans group, BPMN is important. Within BPM fans, there is no doubt that flowcharting notation should tend towards a standard, and BPMN is the best choice.  I am not proposing that there should be an alternate flowcharting notation.   Sandy sums it up accurately with:

“if your business people are already flowcharting their business processes, then teaching them a few BPMN symbols in order to standardize those flowcharts has benefits.”

I heartily agree with this.  I have been a long time supporter of BPMN, in standardizing of symbols, in bringing people onto a single language that allows people to exchange ideas about process.  But notice that the quote starts with the conditional “if your business people are already flowcharting”.  This quote says nothing about people who are not already flowcharting.

One of biggest problems is that the BPM community tends to conflate “BPM fans” with “business professionals”.   We tend to assume that a BPM fan is representative of all professionals at large;  if they are not already BPM fans, then we assume they will be some day.  I question that assumption.

What is a Business Professional?

Some reacted as if I had used “tricky wording” to confuse the debate.  Honestly, I tried to state things as simply and clearly as possible.  I felt that “business professional” was the clearest way to say “all business people”.  However, I am indebted to those who pointed out in comments that this was not clear. I hope to clarify here.

Wikipedia  offers the following list of professionals: Accountants, Actuaries, Advocates, Architects, Dentists, Engineers, Lawyers, Librarians, Nurses, Pharmacists, Physicians, Professors, Teachers, Medical Laboratory Scientists, Statisticians, etc.  This is list is far from complete, and probably not even representative, but will work for this discussion.  What I really meant was to talk about how an Engineer, a Dentist, a Teacher, or a Lawyer might or might not see any need to use BPMN.  Let’s use “business professional” to mean any and all the trained people that work in an office setting.

What fraction of the population of all professionals are BPM fans?   We like to think we are representative, but in fact a very small percentage of professionals actually are BPM fans.  Let’s not flatter ourselves, it is probably more like 5%, 2%, 1%, or maybe even smaller.  A BPM fan is not, by any measure, a typical professional.  To gauge whether flowcharting is useful to professionals at large, we must consider primarily the non-BPM fans.

The Question of Flowcharting

I mentioned that I pioneered a form of modeling in 1993 which is remarkably similar to BPMN.  At that time we used ellipses instead of rounded rectangles for activities, but it included all the concepts of start nodes, end nodes, branching and converging gateways, and even had events represented as little circles on the edge of the activity.  If you wish to compare, please refer to the Visual Process Language paper, and see that it qualifies as an flowcharting language for BPM.

What I have found since publishing that paper is that the vast majority of professionals  do not want to flowchart their processes, and there is no compelling evidence that they need to.  I know this is a taboo topic, one likely to incite flames, but don’t flame me just yet.

Do professionals avoid flowcharting because they have never been trained?

A reasonable question;  many BPM fans believe that if everyone was trained in BPM, they would express all their work patterns as BPMN diagrams.  This is, in my opinion, a far oversimplification of the world. While flowcharting works for some forms of work, it simply is not useful for other forms of work.

There is a surprising dearth of discussion on the types of work that can not be modeled with a flowchart.  Why is that?  Do we (BPM fans) believe that there is no such work?  Or is it just too embarrassing to discuss? This  taboo topic causes a kind of blindness.  We pretend that a flowchart is useful for modeling every kind of work, but what we are really doing is ignoring all the data that does not fit the theory.

What is even more ironic is that most BPM fans don’t have a BPMN model for most of their own work.  As a simple example, which of you reading this has a BPMN model that says “read Keith’s blog” as an activity?  If not, why are you reading this?  How many actual flowcharts do you have? and what percentage of your daily tasks do those flowcharts represent.  Be honest now.  There are so many ready examples of people NOT using a flowchart.

We (BPM fans) like to blame the technology — “if it was only more usable we would use it for everything” — but I believe there is a deeper reason.  One that is inherent in the fundamental idea that one should make a flowchart in the first place.

Why attack BPMN?

As a community of BPM fans, we must not be blind to the need of multiple modeling paradigms.  There is far too much discussion based on the assumption that BPMN is the one and only language needed, and the implicit assumption that flowcharting is the only approach needed.

In doing this I am not attacking BPMN at all.  Instead I am questioning the idea that flowcharting is the end-all be-all approach for all business work.  There is so much focus on BPMN and BPMN tools, and we know they are good for some things.  Nobody is talking about what BPMN is not good for.  We need that discussion.  The BPM marketplace will be safe for consumers only when it is clear both what BPMN is good for, and what it is not good for.  Currently, I see only one side of that discussion within the BPM fans.

The BPM fan belief that flowcharting is good for everything draw us to a belief that if there is anything BPMN is not good for, it is a flaw with BPMN, and it will be fixed in a future version.  Thus if we can only “finish” the design of BPMN, it will will finally work for everything.  It is that belief that makes a taboo out of the suggestion that BPMN might not be good for something.

What do we use instead?

That is a much longer discussion — too long for one blog post.  What I can say is that in discussions with people outside the BPM community, I keep suggesting the idea of “check-lists” and I am encouraged by how often the response is “I think so too”.  There is in fact a considerable amount of interest in a simpler pattern of keeping lists of tasks, and marking them off, without the formalism of trying to write down the rules that would be necessary to make the decisions automatically.

Yet there is very little discussion of check lists within the BPM fans.  There is an interesting book “The Checklist Manifesto: How to Get Things Right” which I touched upon in “Is the Checklist mightier than the Model?”  The interesting thing about this is how people generally poo-poo a checklist as being too “low tech” and look for a higher tech solution.  I think part of that same thing is happening here: BPM fans think that the check lists are too simplistic, and instead all professionals should learn BPMN.  We should not be blind to the natural tendency to prefer a high tech solution over a low tech solution.

You might want to take a look at this post on how Interstage BPM handles this situation by offering both flowcharting and checklist.  There also are other options than just these two.  I believe that was the point in Jim Sinur’s original post: products support multiple paradigms today, and will continue to do so in the future, and as a BPM Fan you should be aware that this is not going away.

The proper response to this question would be to run a scientific study to compare the effectiveness of flowcharting and checklisting.  Set up a controlled study of an organization of normal, average, business professionals — not exclusively process experts, or BPM fans — and see which approach allows the organization to be more coordinated.  Clearly the results will depend upon what they are doing, and we will find that flowcharts (specifically BPMN) is useful for some types of work, but that checklists will be superior in other types of work.  There is no reason to treat this like a taboo at all: lets just study it and get down to facts.