Since a few years I help customers to visualize their business processes. It is still very challenging to get the message across that processes are not limited by organizational units. That business processes always drive people to act and start successive activities, maybe in other units. Following activities of the process through different units by visualizing the process using the BPMN helps a lot. Swim lanes in a pool will represent the different units.
It shows immediately that units (or a role in a unit) are not alone but need each other in certain distinct steps in the process and bring it all to the desired end. So, units, roles, people depend on each other, isn’t that an open door?
- A BPMN pool should be clarifying to others, test regularly when designing (convenient arrangement).
- A BPMN pool should not contain to much swim lanes (approx. max 5), otherwise split up the pool. For splitting-up see next rule.
- A BPMN pool always has one or more end-events. An end-event may be used to associate (association or message flow) with another pool (create symbol: “predefined process”). NB. Also very convenient and user friendly for hyper linking when publishing all BPMN pictures (procedures) as one BPM application (representing the complete business process).
- A BPMN pool should contain no more symbols than readable as printed. Customers always like printed pictures. Be sure that the text in the objects is readable without a magnifying glass.
- Try to avoid crossing lines as much as possible. Make other symbol or lane arrangements if necessary.
- Try to arrange the flow readable from top left to bottom right. Lanes do not have hierarchical or other order. Possibly arrange lanes.
- Don’t use different colors if they do not have a distinct meaning. It distracts from the essence. (gateways, events, tasks are distinct by shape)
Tools tend to add color to objects for fun looks, but is not standardized and therefore confusing when using several tools, as I do. Why? Maybe next blog.
Hi Alex,
you are touching a very important point in your post: Motivating people to take a look at the models. It is great if you can convince managers to finance a BPM effort, but it is even greater if people take up on the topic and support you in doing so. Here, good visuals are an important point. I agree with the rules you put up, but I would also add that you should use colors wherever possible. Also, don't use too many different symbols, but focus on few everyone understands.
Hi Sebastian,
I agree, you should use color. And with a good portion of common sense, as you do with any other bit of a model. Color should be used to emphasize and draw attention for a reason. What's more, color may also be used to spice up your models for presentations and brochures, to emphasize a certain flow, etc.
However, my concern is the model management. Models are stored somewhere and if you don't want it to be a paper tiger, then it should be used in daily practice. And therefore models need to be attractive, easy accessible, consistent and unambiguously interpretable. Then color is, in my opinion, just another object's attribute and should also be clearly defined and managed.
And yes, you are right, try to be modest with different symbols. Modeling is really all about simplicity. Simplicity means removing any needless bits. Until the remaining essence is so boring, that we need to add color ;-)
Alex
