<%@ Page Language="C#"%> FAQs > Best practices in modeling <% if(!RequestUserAgentHelper.IsGoogleBot()){ %> <%} %>

Best practices in modeling

<< Click to Display Table of Contents >>

Navigation:  FAQs >

Best practices in modeling

The BPMN (Business Process Modeling Notation) standard provides organizations with the capability of understanding their internal business processes in a graphical notation and the ability to communicate their procedures in a standard manner. However, the use of the standard do not make sure that processes are modeled in a clear and effective way; the way modelers interpret business conditions, and how they define its structure, is crucial to ensuring they are understood correctly.

 

This article provides process modelers some guidelines to build clear and effective models compliant with the BPMN standard.

 

BPMN modeling principles

 

When defining process diagrams you should take into account the following basic principles:

 

1. Keep a logical and clear sequence

2. Use the BPMN standard

3. Use strict labeling

4. Simplify diagrams

 

Below you will find useful tips to follow these principles and aid the correct processes definition and communication.

 

1. Keep a logical and clear sequence

 

This seems to be obvious but is one of the most common errors in process modeling. Diagrams can become unreadable and very confusing when the process logic is not explicit and clear. The following techniques will help you to maintain a logical and clear sequence in your models.

 

Define a clear beginning and end:

In BPMN, start and end events are optional. However, processes with implicit start and end events are undesirable and could lead to misinterpretations.

Use start and end events in each process and sub-process  to represent its beginning and completion.

 

BestPractices1

 

Follow a consistent direction of flow

Make the process logic visible in the diagram. Avoid crossed lines (connectors), maintain a time sequence and keep a consistent direction of flow. The diagram reading will be easier and its communication efficient.

 

BestPractices2

 

Keep primary scenario clear

The "happy path" should be easily identified when reading a diagram. Diagram the happy path first and then the alternative flows.

 

BestPractices3

 

Keep alternative scenarios clear

BPMN offers the necessary tools to represent exception handling logic explicitly in the diagram. Once the primary scenario is diagrammed, make use of the following elements to model alternative flows as required:

 

Use events attached to tasks

If an Event is attached to the boundary of an activity, it will change the normal flow into an exception flow when something happens (a message is received, a condition is met, a time is reached, etc). For further information see Attached events

 

Use transactional processes

Transactional processes allow business scenarios with transactions. A set of activities must be successfully accomplished, otherwise compensation or cancellation flows are followed. For further information see Sub-processes types

 

Distinguish success and failure end states

Use separate end events to identify when a process finished successfully and when it did not.

 

BestPractices23

 

Keep a format standard

Keep a unique format along your diagrams and focus on a clean and friendly look and feel. Using different font sizes, colors, boxes sizes or overlapping labels might make the diagrams reading a challenge.

 

 

BestPractices4

 

 

2. Use the BPMN standard

The BPMN standard defines the standards used to diagram business processes. However, following the BPMN guidelines is completely in your hands. Make sure your models comply with the standard to make sure its correct understanding.

 

Once the process logic has been defined, validate your diagrams making sure you properly use the different BPMN elements. The following aspect should be checked for each BPMN element:

 

What to check in Pools

Diagram processes completely within a Pool. Never diagram flows across Pool boundaries.

 

BestPractices6

 

Define as many pools as processes.  There must be always at least one Pool.

 

BestPractices5

 

What to check in Lanes

Create a lane only if at least one task or intermediate event is performed in it.

 

BestPractices7

 

Do not create lanes to represent the area or entity that carries out automatic tasks or gateways.

 

BestPractices8

 

Do not diagram tasks, gateways or events at the middle of two lanes.

 

BestPractices9

 

 

What to check in Activities

Do not diagram multiple instances of the same task to represent multiple performers. Just diagram one task in one area. Define the multiple performers as Allocation Conditions in the documentation.

 

BestPractices10

 

 

Do not branch flows using tasks. Always use gateways to do so.

 

BestPractices22

 

What to check in Gateways

Do not use gateways to join and split at the same time.

 

 

BestPractices18

 

 

Balance gateways. Splits must be joined equivalently.

 

 

BestPractices20

 

 

Always use the same type of Gateway used as for splitting to join the flow.

 

BestPractices21

 

What to check in Events

Always use start and end events.

 

BestPractices1

 

Use terminate events only when this is strictly necessary. They are used to model situations where several alternative paths are enabled and the entire process have to be finished when one of them is completed.

 

BestPractices11

 

What to check in Connectors

Use sequence flows to connect all the activities, events and gateways. Never use message flow to connect activities within the same pool or leave shapes unconnected.

 

BestPractices12

 

Never use sequence flows to connect elements of different pools. Use message flows to represent information exchanging between processes.

 

BestPractices17

 

What to check in Milestones

Always identify and define phases; these represents a period of time goal or transition in the process.

 

BestPractices13

 

Avoid come back or looping back across a milestone.

 

BestPractices14

 

3. Use strict labeling

Correct labeling of the different elements of the diagrams is fundamental for an easy and correct understanding of processes. Here are some recommendations to help you do so:

 

Labeling Processes

Processes labels should clearly describe their main purpose. Make sure that you do not use short names or abbreviations.

 

Labeling Activities

Give activities a label composed of one verb, and one object. This way readers can clearly understand the objective of a task. Also, make sure that you do not use short names or abbreviations.

 

BestPractices15

 

Labeling Events

Do not label start and end events when only one instance of them is used. It is very common to label them as "Process start" and "Process end" but this is redundant and not necessary.

 

BestPractices16

 

Use labeling when multiple start and end events are used. Label them according to what they represent using a noun. Do not repeat names.

 

BestPractices27

 

Labeling Milestones

Milestones should be labeled with a noun making reference to a period of time (summer, maturity) or what happens in a period of time (creation,approval, delivery).

 

BestPractices13

 

 

Labeling Gateways

Divergence gateways should have a clear name indicating the decision or condition evaluated when it applies.  Use a name composed of one verb, one object, and a question mark to identify what is being evaluated. You can even use questions to clarify the decision involved.

 

 

BestPractices25

 

If names do not apply for any gateway use abbreviations or numbers to differentiate them.

 

BestPractices28

 

 

Name transitions indicating the condition related

 

BestPractices26

 

4. Simplify diagrams

Large diagrams do not allow giving an end-to-end perspective to readers. They are difficult to read and clearly communicate the purpose of the process.

Defining the correct scope of tasks and level of detail of processes is key to reduce the overage of information.  The following tips will help:

 

Reduce the number of redundant tasks

The level of detail in a process is sometimes a true challenge. In many cases you may face difficulties to define the scope of a single task. Take into account that:

 

When diagramming it is useful to imagine that you are a final user. If a set of consecutive activities can be performed by the same person, at the same time then these activities could be integrated into a single activity.

 

A set of consecutive activities in the same lane may indicate missing participant details, too much detail, or a misalignment in scope. Review these patterns to identify opportunities for activity integration.

BestPractices24

 

Group activities

Use sub-processes to group activities with the same purpose. You can expand the sub-processes later to expose details of lower levels of hierarchy.  A process will contain multiple pages, but internally the integrity of a single model is maintained.

 

Use embedded sub-processes when:  

A set of consecutive activities has an owner different from the main process owner (e.g a Purchase request process is performed by the Purchasing area and the Accounts payable process is performed by the Financial area).

A set of consecutive activities has an different goal from the main process one (e.g a Credit request is focused on managing all the activities to approve a credit request and the Verify applicant information is focused on checking if the applicant is in the black list as well as the information submitted).

 

Use reusable sub-processes when:

The sub-process needs to be invoked from different processes (e.g a Verify applicant information sub-process can be invoked from a credit request process or from a Insurance request process).

 

Apply process patterns

Do not reinvent the wheel. BPMN experts have worked on defining modeling patterns to different business situations. Use them to  model the required business conditions while simplifying your diagrams.

 

For further information about modeling patterns please check the BPMN Workflow patterns document

 

Document minor details

Leave details to documentation. Do not include all the information on diagrams. Additional information should be documented as shape properties not as objects or text in the diagram.