by Business Analysis (BAPL)

Taxonomy

In general, all the wordings in a process map should be clear & concise; even the font type and size should be consistent with organisation’s template.

1. Event name: An event name should always be written in past tense, with the verb at the end
   .e.g. Request received, Message sent, Exception generated, etc. (Note: Message sender or Message receiver need not be mentioned as that is mentioned in the object it is coming from / going to)

2. Activity name: An activity should be written in current tense and should start with a verb. The noun component of the activity can refer to a data input or output. The knowledge of these inputs and outputs is vital from analysis perspective and also from potential system design perspective.
   .e.g. Process Request, Send Message, etc.
   1. Avoid actors in the name as they are denoted by lanes, e.g. Process Request – by customer care agents
   2. Avoid mentioning Automatically / Manually. This can be denoted by system lanes (automatic tasks).
   3. Avoid punctuation in the activity name e.g. full stops
   4. First letters in the word should be capital in an activity, makes it easier to read.
3. Process name: Process name should cover the entire scope of the process and should start with a verb as well. e.g. Resolve Customer Enquiry, Update Customer Details etc.

Semantics

BPMN 2.0 provides objects which can be used for a specific scenario. Not all the objects provided in the set need to be used for an organisation. The business or PCoE can select the appropriate objects which will be sufficient to model the business processes. Some common mistakes and inconsistencies can be avoided by using the correct objects to depict a scenario.

1. Pools & Lanes: A Pool is a participant (organisation) in a process
   1. Elaborating external pools (e.g. Customer, Banks etc.) should be avoided as we have no control over activities outside our organisation
   2. System lanes should not be used. An activity is always a function of a certain department/team within an organisation
   3. Communication going in/out of collapsed pools must be shown by using message flows. A sequence flow cannot cross the boundary of a pool or sub-process Refer to diagram 1.1

diagram 1.1

2. Activity: An activity is a generic term for work that the organisation performs.
   1. An activity must be used before an event or a gateway. Events merely represents the outcome. A gateway only depicts the split between multiple flows. Refer to diagram 1.2.

diagram 1.2

3. Event: An event is something that “happens” during the course of a business process
   1. A message start event must have an incoming message flow.
      Refer to diagram 1.3.

diagram 1.3

1. A message end event must have an outgoing message flow
2. There should be a start and an end event in a process; otherwise it’s hard to understand where the process starts and when the process finishes after certain activities are completed. Start and end events should align to the purpose of the process. The end event should reflect the purpose of the process being achieved. If this was achieved earlier in the process, either the scope is wrong, or we are modelling the next process.

4. Gateway: A gateway splits or combines multiple process flows
   1. When a process splits a gateway must be used.Refer to diagram 1.4.
      When multiple flows can trigger a single activity, a gateway may not be used. A scenario, where multiple conditions need to be met to trigger a task, cannot be shown without a parallel gateway.

diagram 1.4

1. A gateway is not a task; it cannot make decisions, nor can it send out messages. A task must precede a gateway. Refer to diagram 1.5.

diagram 1.5 

1. If a parallel gateway splits the process, another parallel gateway must be used where these flows merge together
2. A parallel gateway cannot be used to merge flows which were originally split using an exclusive or inclusive gateway.

This situation will become a deadlock. Refer to diagram 1.6

diagram 1.6

Exceptions

It is important to show all the possible scenarios that can occur during the End to end process. Processes should not show only the happy path but also the escalations and exceptions. E.g. in the diagram above, if there are any exceptions in the order, we need to go back to the customer to request correct order details. Refer to diagram 1.6

The aim of process modelling is to convey meaning. At the end of the day if the process models are not understood by the audience, they are useless even though they are technically correct. An analyst should educate the audience by taking them through the process models at least initially such that they understand the scenarios, exceptions and direction of the process flow. Any changes to the business process due to external or internal influences, should be communicated to the process analysts, so that these are reflected in the process models and the processes are always kept up to date.

If you would like to learn more about process modelling, Business Analysis (BAPL) has released an online BPMN Training course! If you would like to receive formal training on this important BA tool set, register your interest at training@business-analysis.com.au