BPMN 2.0 Best Practice

The LinkedIn Group for BPMN has a discussion on the need for a best practice for BPMN 2.0.
People come at BPMN from a wide spectrum of use from initial discussion of a business process to the IT developer perspective and a matching wide variety of views of best practice will evolve.
BPMN supports a design to execution path.
Tom DeBevois makes a similar point ...

“Certainly, BPMN enables a powerful requirements gathering tool and it can be a part of the over-the-wall requirement. Still, the central focus of BPMN is to support an agile executing environment and promote visible active, responsive change.”

This focus in the notation is in my view highly desirable. A side benefit at BPMN 2.0 has been the tightening up of syntax and meaning. This should help in the process development by making it relatively easy to critique specifications, as Tom was able to do ...

“For instance, consider the car sales process example (Figure 5-5 in the Method and Style Book). At one point in the process, sales enters an order from the factory and a message is shown from the subprocess to the Factory process. This seems correct; however, when I review an actual BPMN process diagram, it suggests to me that the definition of the process might be insufficient. In reality, what happens in most corporations is a salesman takes the paper order form and punches in the car order into another system.”

This is not a defect in the example, or in the style of BPMN 2.0. It merely represents the stage reached in the process design (it is to be hoped, before critical review).
BPMN does not in itself do the design. Transforming thoughts and words into the formality of BPMN 2.0 reduces the ambiguity of common spoken language. Coming from the technical disciplines of IT , I am attracted by the concept of an execution specification of the process that relates directly to an expression of the apparent problem being addressed. I anticipate a few round trips between business process specification and execution design. That is, it is still best for there to be an ongoing conversation between the person originating the problem and the provider of the solution rather than throwing arbitrary specifications over a wall.
Jakob Freund provided a clear example of the happy path through the design process in BPMS. I particularly liked the transition between viewing the process as flowing between departments of an organisation (level 1) to those departments carrying out independent and complex activities communicating through messages (level 2).


This is an example of what could be described as a “best practice” as ..

• the process is decomposed by responsibility
• information required by the various responsibilities is clarified (it is the message content)
• organisational change (eg outsource development) does not necessarily force process change

It would be useful for organisations adopting BPMN to be able to point to practice notes. Those “best practices” must be appropriate to the organisation and to the task in hand.
I suggest that a reasonable approach at this stage in the life of BPMN the best approach is to take one or more of the publications like Bruce Silver’s and go through it crossing out and highlighting depending whether you feel the ‘rule’ is appropriate. This then becomes the initial quality manual for BPMN.

I do feel that any BPMN symbols used in the early stages should be used correctly.
Things important to the expression of the business requirement should be included (however complicated the diagramatic representation) but avoid the temptation to express unnecessary “how to” in the model. I do not feel that the symbol palette for level 1 or 2 of BPMN 2.0 should be a constraint on the modeller. It is more appropriate as a compliance statement for tool providers.