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.

About these ads
This entry was posted in BPM, Workflow and tagged , , . Bookmark the permalink.

10 Responses to BPMN vs. professionals, 2.0

  1. Scott says:

    It isn’t a taboo subject, but I do wish you and Jim Sinur had both approached it with this level of thoughtful discourse initially. It wouldn’t have garnered the same level of activity, of course, but it would have been more agreeable.

    Keith, this bit:
    ‘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.’

    That’s true, but why does it have to? the original position put forth was that bpmn was no good for all business professionals, and sandy’s response was the more measured, well, actually, if your business people are already doing some flowcharting, BPMN is a great addition. So, BPMN is good for some business professionals then. right? or wrong?

    If correct, then it is just a question of who and how much and such. Not quite as controversial.

    I don’t believe there’s any controversy that BPMN diagrams (or flowcharts) are not necessary to model reading an RSS feed. If I’m wrong I’m sure someone else will chime in. (It isn’t controversial to me ;) And yes, checklists are useful – we’ve been using those since paper and pen were invented, and maybe even before that. They’re a great way to organize our own work, less useful for organizing others’ work in relation to our own (but not useless in that regard, if you have a little infrastructure to share the checklist, a la ActionBase). I don’t think there’s a legitimate question of whether checklists or flowcharts are more useful – they’re useful for different things. And they’re often useful in combination (at this point in the process/flowchart, this is the checklist of things we need to accomplish… or, the other way, item 4 on the checklist is really just a matter of executing this process/flowchart).

    BPMN is not a religion. It isn’t be all and end all. It is useful however. I do get to hang out with BPM (and BPMN) fans, but I spend more time working with customers because of my profession, who can hardly be described as being in the BPMN fan club, until after the successful project implementation (or two or three).

    “What is even more ironic is that most BPM fans don’t have a BPMN model for most of their own work.” I don’t actually find this ironic. The shoemaker’s children often go without shoes. At a previous firm we used BPMN for modeling support tickets, recruiting process, and some other internal accounting related processes. We had a model to refer to and explain projects, though we didn’t literally run it on a server (more educational than runtime, and there are already specialized project mgmt tools on the market). And it doesn’t make sense to use BPMN to model (and execute) low volume processes (or low value processes, or both) – because you won’t get back in saved time/effort the time/effort you invested to build the model.

    Also this point: “BPM fan belief that flowcharting is good for everything” – there is no such belief expressed in this whole discussion, that I’ve seen. A point Sandy and I were commenting on in her summary blog post. Who are these “BPMN is good for everything” people and why don’t they step forward to argue?

    “BPM fans think that the check lists are too simplistic, and instead all professionals should learn BPMN.” – No, BPM fans (if I can speak for them for a moment) think that check lists are too simplistic for many process problems, and in addition, some business professionals should learn to author BPMN, and a greater number should learn how to read the basics of BPMN. Never would I use the world “all” or “none”. I almost hesitate to say never. :)

    Good thoughtful writeup, much appreciated.

  2. Keith,
    I’ll echo Scott here (we agree too much, perhaps ;-) – I really like the way you framed the point here. What I objected to and reacted against before was not the point you make here, but the black/white positioning that came to the fore in your previous post and Jim’s original post that just doesn’t reflect the reality I see with clients.

    Regarding the question of checklists vs flowcharts (and you might also include “esoteric” things like state-transition diagrams here too I guess) I agree, there are scenarios where particular modelling languages and work control/guidance mechanisms come into play.

    I think that one of the things that we all need to be a bit clearer on is that there’s a useful separation we can make when it comes to technology: that is, separating the models we use to express patterns/constraints for work and the specifics of the engines we use to allow those models to play out, from the other capabilities of a platform that are equally important for work management regardless of the predictability / “process-ness” of the work – that is, capabilities to help people carry out tasks, audit progress, monitor performance, and so on and so on.

    I think that with that distinction clear in our minds we can see that there’s a common technology thread that needs to run through what some people would call a traditional BPMS, an ACM platform, and other tools too.

    Anyway I’ll stop waffling now.

  3. Pingback: links for 2010-09-13 « steinarcarlsen

  4. I have been active in business process modeling since the nineties, got interested in Enterprise Architecture a couple of years and passed TOGAF 9 Certification a month ago. Apart from being a comprehensive method for enterprise architecture projects TOGAF also taught me some interesting things about modeling

    One. The artifacts that you model in TOGAF are divided in catalogs, matrices and diagrams. Catalogs are used to list things and describe them with properties. Matrices are used to relate things to each other. Diagrams are used to visualize things and their relationships.

    Two. One uses catalogs to develop matrices and both catalogs and matrices to develop diagrams (if applicable). If this is applied systematically, the final result may have quite complete coverage of the domain being modeled.

    Three. The choice of a modeling technique really depends on the domain and the aspect you try to clarify. For some aspects, such as a process or an organization the diagram is a good technique. For other aspects, such as business rules or financial booking schemes, another technique might be better.

    After all, the modeling is a means to an end. This end can be quite varied, ranging from describing processes for ISO certification to teaching people about processes to business process automation and formal process verification. In some cases one needs the power of a formal language, in other cases the business orientation or user friendliness is more important.

  5. John says:

    I’ve been following this since Sandy’s “The Great BPMN Debate”. Isn’t the proof in the pudding? Not every business professional/analyst/process person/whatever uses BPMN to model business processes, nor will it ever be universally adopted.

    It reminds me of programming languages. Java programmers will swear by the language and disparage dynamically typed languages like Python and Ruby. They all have pros and cons, and what we lose sight of is that they are just means to an end. Isn’t BPMN (or checklists) ultimately a means to an end as well? Isn’t that all that really matters?

    • Scott says:

      John- in a word, “yes”.

    • kswenson says:

      Yes, that is exactly it. Processes are a rich complex subject. Different people want to do different things with different styles of expression. There won’t be one process language for the same reason there is not one single programming language. The issue is with people who think that (for some strange reason) that there is going to be a single unified language for all purposes. Clearly BPMN should be used for what it is good for, but one should never assume that it will be useful for all uses.

      Very well put: it is all just a means to an end. We should focus on the end, and how to do that effectively, without needing to take side on a particular approach.

  6. Pingback: BPMN is Incompatible with ACM | Collaborative Planning & Social Business

  7. Pingback: iBPMS Expo – Jim Sinur presents Agents | Collaborative Planning & Social Business

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s