In the previous blog, you have read how to discover – more particularly how to identify – your business processes when you never mapped those before.
This blog reveals you 11 process modeling best practices to more effectively model your business processes, independently of the modeling notation you (want to) use – e.g. BPMN, EPC, UML activity diagrams, etc.
Indeed, such notations do not tell you how to draw process models that are effective in their primary objective, which is most often to maximise a common understanding of how the work is (as-is) or should be (to-be) organised.
Mind that below best practices are not only valid for process discovery, though for process (re)design as well.
1. Process levels allow you to keep clarity
As you want to be effective in applying BPM, you need process models that are easily understandable, thus very readable and interpretable, especially by non-geeks, say by the common (wo)man.
Even though spaghetti diagrams may be valuable to identify Lean wastes, you do not want to design the work in your organisation through spaghetti (like) models, which would not be adopted – or even read – by anyone.
That’s why modeling processes for an entire organisation occurs in levels of detail (or of abstraction) in which you can zoom in and out, similarly to Google maps. The highest (say most aggregated) level being the “value chain” at the top, from which you can drill level by level down to the “atomic” level, i.e. where you can – or should – not split activities further.
A convenient rule of thumb is to have no less than 5 steps, though not more than 15 steps in a process model. With less than 5, you should consider to add these few activities 
to another process of the same level – or a process at a higher level. While a model with more than 15 steps should be simplified by the use of subprocesses – and so putting activities at a lower level. Or by splitting the model into 2 – or possibly more – models.
At least, you should take care that when printing a model on paper, readers do not need a magnifying glass.
2. Atomic process steps (Tasks or Activities)
In the paragraph identify atomic activities and functionalities of this blog, I already explained what atomic activities or tasks are and what these do look like. Let’s now see why this is important.
Coupled with above paragraph (on process levels), atomic tasks help you to assess the right granularity of work, so you know whether or not you still need to further break down the work into more units, like sub-processes or activities.
Indeed, if a process step actually still includes many atomic tasks – like the example “apply for the job” in the mentioned previous blog, it is too coarse grained, meaning that it is a (sub)process that still can be further split in many smaller steps. And if you want to be exhaustive in modeling – for instance when you need to identify all possible functionalities for a new information system -, you better know every task. This means that you need to split any (sub)process into its atomic components.
On the other hand, an activity or task might be “too fine grained”, which means that it is unnecessarily split and thus creates unneeded complexity in the model. Like it could be the case if you further split a task like “complete the subscription form” while this is supposed to be carried out at once and by one and the same person.
3. Start activity names with a verb
A business process describes how the work is – or should be – organised. So, process steps represent something that has to be done by someone or by a system. Hence, a verb is obvious to describe such an activity.
To increase the chance that the process steps are atomic, you better start the naming of an activity with a verb, though followed by the corresponding direct object. E.g. read the manual, or extract a report, etc.
Indeed, if the process step cannot be covered by 1 unique verb with its direct object, it may be an indication that you probably better split it. Unless there is a second verb which is the ‘logical extension’ of the first one. For example: complete and print the form : when both actions are executed (nearly) together by the same person, then you may consider to use both verbs in a same activity.
4. Limit the use of symbol types in a process diagram
Unless you are “modeling for execution” – i.e. drawing a process model that generates an executable application -, using a rather limited number of symbols will avoid to confuse the reader. Particularly when you communicate through these models with business people who do not have much affinity with modeling notations.
Like illustrated here at the right, BPMN counts more than 60 different event symbols (being just one of the many symbol types), from which I most probably never used more than 10. Excepted when modeling processes ‘for execution’, for which you need to be more accurate.
5. What to model : activities, events, gateways,…?
When having a “brown paper workshop” (see also point 9 here below), I use rectangular post-it notes which represent the process steps (activities or tasks) and square notes sticked 45° to represent gateways. And very often, this is sufficient to obtain the process model ; at least its first, still draft, version.
For process design of a new product or service, I even often ask participants to stick the process steps only, by preference in their (chrono)logic order. Enriching the model with gateways, events and other artifacts (symbols) then happens later, as the insight progresses and becomes clearer and clearer.
6. Keep (complex) business rules apart when possible
Too often, modelers use gateways to reflect complex business rules. Even though gateways explicit the process logic, indeed, you better use them only for simple rules.
As a rule of thumb, as soon as you have many consecutive gateways, like the 5 gateways in a row in the first below picture, you should wonder whether you could not use a more concise though clear business rule – for instance a decision table – instead.
Another argument is that business rules are much more “volatile” than the process in general. Hence, when keeping the rule “outside” of the model, you will avoid to change your model each time, and will only need to change the decision table – or the business rule management system – instead.
Above example illustrates the rules to be applied with a leasing company, expliciting 5 business rules in the process model itself (corresponding with the 5 gateways). While below, you will find the same example, though where the rules are contained in a decision table.
The rules are as follows: the acceptance to lease an equipment for the client depends on 5 different criteria. The acceptance will be automatic when
- the value of the asset to be leased is less than 5.000
- there were no (payment) incidents with the customer in the past
- the cash flow / debts ratio of the customer is above 1
- the latest balance sheet has been published within the last 2 years
- the company exists for at least 4 years
When extracting the rule logic in a decision table, the diagram looks as follows (look at the left). A bit leaner, isn’t it? Mind the unique gateway, reflecting only the final possible outputs of the decision : either automatic or manual decision.
7. The power of (swim) lanes
Although some notations do not make use of (swim) lanes, I personally use them whenever possible. Especially when you have many actors, and once the process becomes quite clear. When using lanes, the reader can immediately see how the work is – or will be – organised. Indeed, the use of lanes allows you to immediately recognise who is supposed to do what and when (i.e. where in the model).
Seeing when the arrow (= workflow) crosses from one lane to another gives moreover a clear indication of a (work or output) transfer from one person – or team – to another. And such a transfer is very often a source of (potential) improvement, like better communication or better knowledge of expectations (by the “downstream customer”).
In some cases, e.g. when the process is still blurry in the minds of workshop participants, you might better ignore Lanes, so to avoid being blocked during the modeling exercise. You might remodel the process using Lanes at a later stage, once the process becomes clearer.
8. Individual interviews or workshops?
Some advantages of individual interviews are:
- You are sure that everyone (you plan or want to be involved) really participates ; in a larger group there is a risk that only one, or a few persons, will dominate the workshop indeed. Which obviously not happens when you interview persons individually. So you will have more certainty that the result, i.e. the process model, will be (more) complete and that everyone really contributed.
- Higher efficiency for the interviewees. You do not multiplicate the time consumption : 1 hour interview is 1 hour consumption for the interviewees. In the contrary with a workshop with 6 participants, 1 hour workshop means 6 hours time consumption for all the participants. Although at the end, as you will need to interview everyone separately, the difference will be discussable. Indeed, the modeler who facilitates the interviews will spend more time in total.
Advantages of workshops are : 
- You get a kind of cross-fertilisation of ideas and more team dynamic, which might be helpful later to get “all noses in the same direction”. E.g. when implementing a to-be business process, the probability to encounter ‘resistance to change’ will be lower.
- Workshops are easier to get agreement on a common view. When staying with individual interviews only, the modeler might encounter the risk to be sent from pillar to post.
- Because processes are very often cross-departmental or cross-functional, bringing persons from these different departments together – who might even not know each other yet – can be very beneficial. Particularly because they are supposed to work and think together for ‘the higher goal’ – the organisation’s objectives. Understanding each other’s challenges very often helps to identify and to remove inefficiencies.
My personal experience and recommendation is that you better start with individual interviews to discover as much as possible upfront, though you better end with a workshop to achieve a commonly agreed process model. Although I also applied the opposite: starting with a group workshop, while finalising with one or a few persons, particularly when it is about the tweaking of specific activities (process steps) in an already well elaborated process model – say for the ‘final touch’.
9. Live modeling or (brown) paper with sticky notes?
With live modeling, I mean modeling right away in the modeling (software) tool in the presence of the participant(s). This has following advantage:
- modeling efficiency: you do not have to model in the software ‘from scratch’ after the interview or a workshop, as you did it immediately in the tool. Even though you will most probably need to refine the models after the workshop or interview.
On the other hand, using brown paper & sticky notes has other advantages :
- you are not bounded to modeling constraints ; this is especially convenient in the beginning, i.e. when the process is still too blurry in the participant’s minds.
- you can get an (even) higher personal involvement of the participants, for instance by asking them to stick the notes themselves on the brown paper. From a psychological perspective, this makes sense to stimulate people to take (more) ownership of “their” process. You could hardly do this while modeling live with software…
- for the modeler him-/herself, live modeling in the software tools can be a focus challenge, especially when the same person plays the role of facilitator and modeler.
Here is my personal experience & recommendation : live modeling is certainly interesting when you finalise a process diagram, rather than when you still have to start from nothing.
For live modeling, it is also recommended that the audience has a sufficient level of knowledge of the modeling notation, so that participants can be critical enough to get to the final (i.e. commonly agreed) version.
When the modeling application forces you to respect semantic rules – so you will be confronted with modeling constraints -, it might be more challenging to model live, as you will need to focus on both the correct modeling (semantic) and on the right interpretation of input from the participants. However, the advantage is that when you finish, you are quite sure that your process model is correct.
10. Textual description or not?
A textual process description, especially when it is combined with its respective process model, is powerful because it helps to exclude misinterpretation of the model, more particularly when the knowledge of the modeling notation is rather poor within the organisation, or when the model is quite complex.
Do not underestimate, however, the efforts it takes to correctly describe the process by written. Hence, I seldom write a process description for an as-is model (as it will usually quickly be replaced by a new version). Though for a to-be model which will need to be well-respected by many actors, I tempt to do it so there are no excuses of misunderstanding.
11. Share the models and stimulate collaboration
Once you have modelled a process, share it with all persons who were involved for the modeling. But even better: share it also with any stakeholder, even the ones who did not participate during the modeling activities.
Invite these persons as well to give their opinion on a business process model with which they are involved. As you will read in later blogs, this is a valuable source of ideas for continuous (process) improvement.
Modern and quite elaborated BPM-software have such collaboration functionalities. In the more unfortunate case you would not have this kind of software, then you may consider a ‘simple’ intranet portal. Or even simpler, a dedicated drive – e.g. a Google drive or similar – where you publish the process models and their possible descriptions, while foreseeing a functional mailbox for suggestions to improvement.
Please share your findings, opinion or experience about business process discovery – or BPM in general – through below Comments box and receive a package of highly and professional educating videos on BPMN.
P.S.: Please share this information with your Facebook friends and fans, LinkedIn contacts, Twitter followers and Google+ circles, through the share buttons below. Thank you!