The standard was originally developed at BPMI.org and following that organization's merger into the OMG, its ongoing development is now handled by the Business Modeling and Integration Domain Task Force.  While although many tool vendors are still using BPMN v1.0, the latest version is BPMN v1.1 and the folks involved at the OMG are now working on Version 2.0 which will probably not get released till toward the end of 2008 at the earliest.

The primary target audience for BPMN is the business people themselves who can use it to robustly model their business processes.  In BPMN, process modeling involves the capturing of an ordered sequence of business activities and supporting information. A Business Process describes how a business pursues its objectives—the objectives are an important part, but are not necessarily captured in the notation (at least at this point). That is, there is no standard way of capturing business objectives, goals, KPIs, etc., in the context of a business process. Only the process is modeled with BPMN.

In developing BPMN, we perceived that there were different levels of process modeling:

• Process Maps—simple flow charts of the activities; what you see on flow diagram without a lot of detail other than the names of the activities and perhaps the decision conditions.
• Process Description—providing more extensive information (defining the people involved in performing the process, data, information and so forth).
• Process Models—flow charts extended with sufficient information such that the process can later be analyzed, simulated, and perhaps executed. At least that information should capable of being fed into other tools that could execute that process (with further work).

The general aim was that it would help end users to have a single agreed notation. This would enable consistent training on a single notation, using any number of tools. It would also help the organization; it would not have to retrain every time they bought a new tool or hired people who had used other tools.

Another objective of BPMN was that it would provide a mechanism to generate executable processes – that’s one of the key reasons that BPM Suite vendors use it. The underlying semantics of the notation facilitate the translation of business level models into executable models that BPM Suites and workflow engines can understand. It is worth noting that most BPMS vendors only support a subset of BPMN in their process execution engines.

So where does all of this lead?  The reality that the skills gap is continuing to grow.  Most people can describe processes in some written from, while others can put boxes and arrows together in a roughly believable way.  Yet preparing realistic process model which provide value is another issue.  One of the misconceptions is that BPMN itself is methodology, when in fact it is simply a graphical notation.  Leveraging the value of BPMN requires investing in an education about process modeling, learning methods for discovery, definition and capture -- then transferring this to a BPMN model.   

BPMN is for most organizations the right choice for standardizing on single modeling format.  It can be a 'common language' of sorts for documenting processes across the organization.  For those who have attempted this with UML, you have no doubt already discovered the difficulty of engaging a business audience with what is fact programming notation.  In contrast, using free-form Visio diagrams without a standard notation (or worse, using a boilerplate flowchart template) leads to deadend.  What BPMN offers that these approaches do not is portable format, transferable across the organization or to other organzations.

About the Author: Derek Miers

Derek Miers is a well known independent industry analyst and technology strategist, publishing a great many white papers and product assessments. As Co-Chairman of BPMI.org, he helped merge the organization with the OMG and recently completed the most comprehensive review of BPM environments.  Over the years, he has carried out a wide range of consulting roles including running hundreds of training courses (in business and process modeling techniques), undertaking detailed technology selection assessments and project-risk assessment studies. Other engagements have involved the provision of strategic consulting advice from facilitating board level conversations around BPM initiatives, through establishing effective BPM Project and Expertise Centers, to helping clients develop new business models that leverage business process strategies.  Clients have included many of the worlds largest and well-known financial services companies (banks, building societies and insurers), pharmaceutical companies, telecoms providers, commercial businesses, product vendors and governmental organizations.