As BPM takes hold, organizations are finally beginning to acknowledge the need for a common language for process description, something that allows a broad base of users spanning departments, geographies – both business and IT – to look at a process diagram and understand what it says. And in BPMN, the business process modeling notation standard from OMG, we finally have near-unanimous acceptance from tools vendors of what that language looks like.
Version 1.x of the standard is supported by the majority of BPM Suite vendors as a front end to process implementation tools, as well as by an increasing number of repository-based business process analysis (BPA) tools. BPMN 2.0, nearing finalization, adds support of the big guns – IBM, Oracle, SAP, and Microsoft – so critical to connecting BPM to SOA and ERP. By this time next year, any BPM tool, on either the analysis or implementation side, that does not support BPMN will be relegated to the “legacy” category. It would be like a DBMS that does not support SQL.
One of the attractions of BPMN is its familiarity to business users. On the surface it looks like the swimlane flowcharts drawn in Visio or PowerPoint that have been around for twenty years. Of course, if that’s all it was, BPMN would not be any answer to the Tower of Babel we have now for process description. So it’s a lot more than that.
For one, BPMN has defined rules. Each shape and symbol has a specific meaning, rules about what can connect to what, and exactly what those connections mean. Unlike a regular Visio drawing, you can validate a BPMN diagram. In principle, the meaning of a diagram is defined by a specification, not by the interpretation of the person who created it. Without that, IT would have no interest at all.
Also, BPMN includes events, signals that “something happened” while the process was running. The process modeler can describe what should happen, for example, if a customer cancels the order in flight, or an expected response does not arrive in time, or an internal error occurs. These “exceptions” are often the reason why the current process takes too long, costs too much, or incurs too many errors. Does business need a way to model how they should be handled? Of course! But prior to BPMN, we never had that.
Third, BPMN includes subprocesses, encapsulated fragments of the whole process that can be rendered in the diagram either collapsed into a single box or expanded into a process view. And that expanded view can contain other subprocesses, leading to an inherently hierarchical structure to the process description. This is valuable because different users need different levels of detail in the process description, and BPMN lets you zoom in or out to the level you need.
Let’s recap so far. Universal support from tool vendors. Familiar to business users. But new and different in several respects: predefined semantics and rules, support for events, exceptions, and subprocess hierarchy. Maybe you see the problem here. Users (both business and IT) think they understand BPMN, but the very things that make this new universal language so valuable are the pieces that are new and different.
Lately we’ve seen a spate of BPMN books appear. Not to put too fine a point on it, but most of them are plain bad. The proof of this is that many of the diagrams in the books are themselves invalid. If the authors had used a good BPMN tool to create and validate them, they would have gotten an error list. It’s really shameful. One book, by White and Miers, is pretty good. All the diagrams in it are valid, as well they should be since White is the editor of the BPMN spec. But even it is not as good as it could be, because it is organized as a reference, i.e. a condensation of the spec written in plain English. Developers love this format, but it’s not what’s needed to bring BPMN understanding to business. What’s needed is a methodology for using it effectively. BPMN is officially “methodology-neutral.” I’m sure that was critical to winning adoption by such a wide variety of tool vendors. But users – both business and IT – need a methodology if the promise of shared process description is to be realized. That’s not the way BPMN is required to be used, but it is the implicit motivation behind the standard. We provide such a methodology in our workshop, Process Modeling with BPMN. It’s based on a simple principle: the process diagram, printed out, should convey exactly how the process works to anyone looking at it, without the need for an attached narrative by the author. That means identifying the exception paths and representing them clearly in the diagram. That means organizing process steps effectively in a subprocess hierarchy. That means understanding what is “inside” the process vs “external” to the process, such as requesters or service providers. Our goal is creating that common language shared by business and IT, and providing clear guidance on how to use it effectively. As with any language, you need more than a dictionary and grammar book to write effectively. You need a style manual, and that’s our goal.
Like it or not, BPMN is the standard in BPM. By 2009 you will be hard pressed to find a tool or consultant who does not at least pay lip service to it. Even most of them don’t know how to use it well yet. They’re still at the dictionary-and-grammar level. You need more than that.
