Best practices in Process modelling
In this article we will present you ‘How to model a business process following the Best Practices Guide’. This effective method has 4 principal pillars that will help you model your first business process.
Keep a logical flow
- Use start and end events to represent the beginning and completion of a process.
- Have a consistent direction of the workflow (from the LEFT to the RIGHT).
- Design the process ‘HAPPY PATH’ on a straight horizontal line.
- Distinguish between success and failure end states by using separate end events to identify when a process finished successfully and when it didn’t.
- Use process colour code:
- User task: GREEN
- Integration task: PURPLE
- System task: ORANGE
- Sub-process: BLUE
- Use process colour code:
Use BPMN standards
- Don’t place a flow object (events, activities, gateways) outside Pool boundaries.
- A business process must have at least one Pool and one Milestone.
- A lane should contain at least one flow object. Don’t place any flow objects in the middle of two lanes and don’t create lanes to represent the area or entity that carries out automatic tasks or gateways.
- Always use gateways to collect or separate branch flows but don’t use it to join and split at the same time.
- Always use the same type of Gateway used for splitting to join the flow.
- Use Terminate End Events instead of End Events in Embedded sub-processes.
- Avoid coming back or looping back across a milestone.
Use strict labelling
- Add a label to every flow object for an easy and correct understanding of the process.
- Use a prefix when naming a process. The prefix is made out of 3 letters – project abbreviation (e.g project: Secure Document Management, project abbreviation: SDM, process name: SDM_ArchiveDocuments, process display name: Secure Document Management). Processes labels should clearly describe their main purpose. Add a short description to the process.
- Give activities a label composed of one verb, and one object. (e.g Approve Request)
- Use labelling when multiple start and end events are used.
- Milestones should be labelled with a noun making reference to a period of time (summer, maturity) or what happens in a period of time (creation, approval, delivery).
- 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.
- If names don’t apply for any gateway use abbreviations or numbers to differentiate them. (e.g GT01, GT02 …)
- Name transitions indicating the condition related
- Reduce the number of redundant tasks.
- Use sub-processes to manage and group activities that have the same purpose. Use embedded sub-processes when a group of consecutive activities has an owner different from the main process owner or it has a different goal from the main process. Use reusable sub-processes when a group of consecutive activities needs to be invoked from a different process.
- Don’t follow an Event-based gateway by elements other than Events and Tasks.
- Don’t use signals or messages in embedded sub-processes.