BPM Explained - Part 2

Yesterday I tried to explain BPMN to those who don’t know what it is.  OK, they are probably saying, if BPMN is so great, why do I hear these complaints about it?  Yes, that’s a good question.

First, you need to understand exactly who is complaining.  If it’s a legacy tool vendor wedded to their proprietary (“much better!”) notation, well that speaks for itself.  Ditto if it’s a gray-haired process improvement consultant whose idea of a modern tool is a whiteboard that prints.  Which is most of them.  But even if you cross those guys off the list, there are normal end users who complain about it.

One complaint is there are too many shapes and symbols.  Actually, there are only three primary shapes, called flow nodes: activity, the rounded rectangle, denoting an action step in the process; gateway, the diamond, denoting conditional branching and merging in the flow; and event, the circle, denoting either the start or end of a process or subprocess, or possibly the process’s reaction to a signal that something happened.  Just three, much fewer than a legacy flowcharting notation.  In BPMN, the solid arrow, called sequence flow, must connect at both head and tail to one of these three shape types.

The problem is that the detailed behavior of the flow nodes is actually determined by their icons, markers, and border styles.  There are way too many of those, I will readily admit.  Only a small fraction of them are widely used and important to know; the rest you can simply ignore.  When I started my BPMN training many years ago, I identified a basic working set of shapes and symbols called the Level 1 palette, mostly carried over from traditional flowcharting.  The purpose was to eliminate the need to learn useless BPMN vocabulary that would never be used.  When BPMN 2.0 came out 4 years ago, they did a similar thing, officially this time, but for a different purpose.  The so-called Descriptive process modeling conformance class is essentially the Level 1 working set.  Its purpose, from OMG’s standpoint, was to limit the set of shapes and symbols a tool vendor must support in order to claim BPMN support.  So… if you are new to BPMN, just stick to the Level 1/Descriptive working set.  It will handle most everything you are trying to show, and good BPMN tools in fact let you restrict the palette to just those elements.

I sometimes hear the opposite complaint, that BPMN does not have a standard way to visualize important information, like systems, organizational units, task completion times, or resource costs, available in their current process modeling tool.  Actually, many BPMN tools do have ways to include these things, but each in their own tool-specific way.  BPMN just describes the process logic, that is, how the process starts and ends and the order of the steps.  It doesn’t describe the internal details of a task, like its data or user interface, or decision logic, or systems involved, or important simulation parameters.  Its scope is quite limited.  There are some emerging standards for those other things that will eventually link up with BPMN, but they are not yet widely adopted.  Anyway, it’s important to distinguish the information a BPMN tool can support from information that is part of BPMN itself.

Finally, some people don’t like the fact that BPMN has rules.  A tool validating models against those rules might determine, for instance, that the way you’ve been modeling something for years is invalid in BPMN.  You can ignore that, of course, but remember the goal of BPMN is clear communication of the process logic.  A diagram that violates the rules of the specification probably does not do that very well.  Like any new language, BPMN asks that you take a little time to learn it.  It’s actually not that hard.

SOURCE: Bruce Silver