The BPMN specification presents lots of technical definitions and rules, but it does not teach you how to create process models that are effective in their primary mission - maximizing shared understanding of the as-is or to-be process. To do process modeling effectively, you need to go beyond the spec and learn a basic methodology, best practices, and specific diagram patterns to use in common situations.The other key point he makes in his article is
While the diagram is the key output, a process model is more than a drawing, and a modeling tool is more than a drawing tool. A real modeling tool has the semantics and rules of BPMN baked in, and gives you a Validate button that can display a list of errors when you violate the spec. A free BPMN stencil in Visio can’t do that.Some of my particular favourite tips are #3 (Make your model hierarchical) and #4 (Label your activities 'Verb/noun") . Both of these are things I constantly have to remind my clients.
Bruce does make one comment which I'm not totally aligned with. He believes that everything on your model should be labelled, not just activities, but subprocesses, intermediate events, gateways, sequence flows, end events and message flows. Up to a point I agree with this but I actually believe that a process model consists of two things:
- The diagram: This is the model you have created with all it's boxes, shapes and flows
- The supporting documentation of the diagram: This is the textual interpretation of the diagram which includes items such as descriptions, timings, resource uasge etc. Putting all of this on a diagram would be counterproductive, I feel.
But with that caveat I would heartily recommend Bruce's article to you.
Remember "Verb Noun"!
