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

    • 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

    • 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:

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

  • 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

    • 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

    • A benefit of this best practice is simplification of overloaded diagrams

Collaborations

  • Do not model the internal process under focus into a Pool

    • 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