It is the BPMN (Business Process Modeling Notation) standard offers organizations the ability to understand their business processes within an graphical format and also the capability to communicate their procedures in a uniform way. However, the implementation of the standard does not guarantee that processes are described in a precise and efficient manner. The way that the modelers interpret the business context, and how they determine its structure, is essential in ensuring that they are properly understood.
This article offers process modelers with some guidelines to construct clear and effective models that are compliant with the standard BPMN.
BPMN modeling principles
1. Maintain a clear and logical order
It’s a common misconception however it is among the most frequently made mistakes when it comes to process modelling. Diagrams can be difficult to read and confusing if the logic of the process isn’t clearly and easily understood. The following tips will assist you maintain a clear and clear order within your diagrams.
Define a precise starting and ending point:
In BPMN The start and the ending events aren’t mandatory. However, processes that have implicit start and end dates are unsuitable and can result in misinterpretations. Utilize the start and end times within each sub-process or process to indicate the process’s beginning and ending.
Maintain a consistent flow of flow
The process’s logic should be apparent within the diagram. Avoid crossing lines (connectors) Maintain the time sequence and keep the flow in a constant direction. The reading of the diagram will be more easy and the effective communication.
Keep primary scenario clear
“Happy path” or “happy path” must be easy to identify in an illustration. Sketch it first, the path that is happy, and follow it with the other.
Keep alternative scenarios clear
BPMN provides the tools necessary to depict the logic behind exception handling clearly within the graph. After the initial scenario has been sketched out, use these elements in order to model alternate flow scenarios as required:
Utilize events that are linked to tasks
When an Event is linked to the boundaries that is associated with an activity, the event can change the flow that is normal to an exception flow whenever something occurs (a notification is sent or a condition is fulfilled the time has passed or exceeded, etc.).
Utilize the transactional process
Transactional processes permit businesses to run their business through transactions. The set of tasks must be completed successfully without which payments or cancellation processes are executed. For more details, see sub-processes and their types.
Differentiate between failure and success states
Utilize separate events at the end of a process to determine when a process completed successfully and also when it didn’t.
Make sure that the format is consistent
Maintain a distinct format for your diagrams and keep in mind an elegant and pleasant design and feel. The use of different sizes of fonts or colors, sizes of boxes or labels that overlap can make reading the diagrams difficult.
2. Utilize the BPMN standard
BPMN is the BPMN Standard defines the guidelines for describing business processes. But, adhering to your own BPMN guidelines is entirely your responsibility. Be sure that your models are in line with the BPMN standard to be certain that you are following the correct guidelines.
After the process logic is identified, verify your diagrams to ensure that you have used the appropriate BPMN elements. The following elements to be checked for every BPMN element:
What do you need to look out for in the pool?
Diagram processing is completely inside a Pool. Never diagram flows across Pool boundaries.
Create as many pools as process. There must always be at the very least one Pool.
What should you look for in Lanes
*Create a lanes only if at the very least one activity or intermediate event occurs within it.
Do not make lanes to depict the location or the an entity that performs automated functions or is connected to gateways.
Do not draw out activities, gateways, or other events within two lanes.
What should you look for in activities
Don’t draw several instances of the exact task in order to show multiple participants. Simply draw only one job in one space. The multiple performers should be defined by defining Allocation Conditions within the document.
Do not branch out flows with tasks. Always use gateways to do so.
What should you look for on Gateways
*Do not join and separate simultaneously.
*Balance gateways. Splits need to be joined equally.
Always ensure that you use the same Gateway to split the flow in order to connect the flows.
What can you check for in the Events
Always use end and start events.
Utilize terminate events only when it is absolutely essential. They can be used to simulate scenarios where multiple paths are available and the whole procedure must be completed once one option is finished.
What do you need to look for in Connectors?
Use sequence flows to connect all activities, events and gateways. Do not make use of messages to connect different activities inside the same pools, or let shapes remain unconnected.
Don’t utilize sequence flows to join elements from different pools. Utilize message flows to symbolize information exchange between the processes.
What should you look for in Milestones
Always identify and define phases. These are an amount of time or change within the process.
Do not loop over a point.
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 Methods
Labels for processes should clearly state the purpose for which they are intended. Be sure to not make use of short names or abbreviations.
Labeling Activities
Give the activity a label made up of a single verb with one subject. So that readers are able to clearly comprehend the purpose of a task. Be sure you don’t make use of abbreviations or short names.
Labeling Events
Don’t label start and end events if only one of them is being used. It is quite common to refer to them with “Process begin” as well as “Process end” however this is unnecessary and is not needed.
Use labels when multiple start and finish events are utilized. Label them according the event they represent by using an adjective. Don’t repeat names.
Labeling Milestones
Milestones must be identified with an adjective that refers to a specific period of time (summer maturity) or something that happens during the time frame (creation,approval or delivery).
Labeling Gateways
Divergence gateways need to be clearly identified with a name that identifies the condition or decision that is being evaluated for the time it is in use. Make sure to use a name that consists of a single verb, one object as well as a question mark, to determine what is being assessed. It is also possible to use questions to help clarify the process to be made.
If names are not required for gateways, make use of abbreviations or numbers to distinguish them.
Name transitions indicate the relationship between the condition.
4. Make diagrams simpler
Large diagrams don’t allow the reader to see the whole picture for viewers. They are hard to read and convey clearly the goal of the procedure.
The proper definition of work and the level of details of processes is essential to limit the amount of data. These tips can help:
Reduce the number of tasks that are redundant.
The amount of detail that is required of a procedure can be an actual challenge. There are many situations where you could have difficulty defining the scope of a particular task. Consider:
- When diagramming, it’s useful to imagine yourself as the final user. If a sequence of tasks can be carried out by the same individual at the same time , these tasks could be combined into a single task.
- A series of activities that are in the same lane could reveal missing participant information excessive detail or a misalignment of the terms of. Examine these patterns to find possibilities for integration of activities.
Group activities
Utilize sub-processes to organize activities for the same reason. You can extend the sub-processes in the future to reveal information about lower levels of the hierarchy. The process can contain many pages, but the integrity of one model is preserved.
Sub-processes embedded in embedded code are used when:
- A sequence of activities that is owned by a different person than the owner of the primary process (e.g an order request process is handled by the Purchasing department and the process of Accounts payable is handled by the Financial department).
- A sequence of actions that have a different purpose than the primary one (e.g the Credit Request is used to manage all processes to approve a credit application and the Verify the information submitted by the applicant concentrates on determining whether the applicant is on the blacklist as well as the information provided).
Utilize reusable sub-processes for:
- The sub-process must be invoked by different processes (e.g the Verify applicant information sub-process may be invoked through a credit request or an Insurance request).
Process patterns can be applied to the application.
Don’t reinvent the wheel. BPMN experts have been working on the definition of modeling patterns that can be applied to various business scenarios. Make use of them to represent the necessary business scenarios as well as simplifying diagrams.
