Navigation: BPMN Quick Guide > BPMN Modeling Best Practices

BPMN Modeling Best Practices

    

Process Scope

✪  Clearly define the scope of the Process by identifying the Who, What, When, Where and Why of your process (the Process is the How)
✪  Identify what each instance of your Process will represent
i  Instances are discreet and identifiable: you can refer to each one of them and can count them
✪  Identify the potential alternative ways to trigger the Process using Start Events
✪  Identify the potential alternative end states of the instances of the Process using End Events

 

Diagram layouts

✪  Aim for BPMN Diagrams that fit one page
✪  Layout your BPMN Diagrams neatly to ease readability by minimizing flow crossing
✪  Use consistent layout with horizontal Sequence Flows and vertical Data Associations and Message Flows
i  BPMN Diagrams are not strict temporal orderings (as it is possible to loop back) but most readers expect a left-to-right ordering
✪  Do not create zigzag layouts of elements
✪  It should be clear what the primary (“Happy”) path of the Process is
✪  Whenever possible, externalize the business rules from the Process to create more concise and more agile Process models using Business Rule Tasks
✪  Create alternative visualizations of the same Process for different communication purposes and stakeholders. For example:
❖  A summary Diagram with all Sub-Processes and Call Activities collapsed and not showing any Data Objects
❖  A verbose Diagram with all Sub-Processes and Call Activities expanded, showing all Data Objects and Annotations

 

Process Partitioning and Structure

✪  Create hierarchical multi layers of details for your Process
✪  Use Sub-Processes to split your Process into "phases"
✪  Use Call Activities to re-use other Processes

 

Start and End Events

✪  Always use Start and End Events
✪  Distinguish alternative instantiation of the process as separate Start Events
✪  Distinguish various end states as separate End Events
✪  Flows that end in the same end state should be merged to the same End Event

 

Gateways

✪  Always use Gateways to depict split or merge of flows
x  Do not use mixt mode Gateways (both diverging and converging)
✪  Always place an Activity that will determine the diverging condition(s) just before a diverging Gateway of type Exclusive, Inclusive and Complex
i  A benefit ' of this best practice is that this decision Activity can now be interrupted if need be
✪  Abstract multiple daisy-chained diverging Gateways into a Business Rule Task
i  A benefit of this best practice is simplification of overloaded diagrams

 

Collaborations

x  Do not model the internal process under focus into a Pool
i  Without a Pool to label, one will not have the opportunity to fall into the bad practice of naming the Pool with the Process Name