The BPMN specification provides a wealth of technical terms and regulations but it does not instruct you on how to build processes that work in their primary function to maximize understanding among all stakeholders of the current or planned process. In order to effectively model processes it is necessary to extend beyond the specifications and understand a basic method as well as best practices and specific diagrammatic patterns to apply in everyday situations. To help illustrate this Here are ten guidelines to help you model effectively using BPMN.
1. Let the process logic evident in diagrams
This is absolutely important, but it is frequently overlooked by novice modelers. The BPMN specification describes the various connectors and shapes that appear in the diagram. It also provides additional details in attributes that can be seen only by the modeling tool or the extensive documents that are produced by the tool. However, maximizing understanding for the entire group isn’t a result of individuals looking at your model using the software, or going through the 100 pages of documents. It’s about gathering around a table, taking a look at a printed copy of the diagram, and then discussing the model, and usually contemplating what it could be improved upon.
This implies two things: First make sure to label everything you have in your diagrams. Not just subprocesses, but activities the intermediate event, gateways sequence flows, events at the end and message flow. Certain attributes that are required, such as the timer’s duration event, might not be included on the diagram. If not, attach an event label which replicates the information. If you don’t see it on the graph, it’s unlikely to matter.
In addition, you should show exception handling reasoning clearly on the diagram. In contrast to traditional notations, BPMN offers you the means to achieve this, even when you’re not a programmer.
2. Validate your models
While the diagram is the primary output of a process model, it is more than just a drawing and modeling tools are more than a drawing software. A good modeling tool comes with the rules and semantics of BPMN integrated and provides an Validate button that will display the errors that occurred when you don’t meet the requirements. An unlicensed BPMN stencil that you can use in Visio cannot do this. If you want other people to get a sense of your designs then you must begin with making them valid which is why you need to make use of the Validate button, and then learn how to correct the mistakes.
3. Create models that are hierarchical
What makes BPM distinct from traditional management practices is the focus on looking at the business from an end-to-end view. The flat model of processes which take up 30 inches of space doesn’t permit that end-to-end view to be absorbed simultaneously. Instead, we recommend the top-down method in which the top-level diagram depicts all the steps on one page and then uses subprocesses to extend the detail of processes through nested diagrams and allow you to zoom into as well as out to show the process at any amount of details. The model can be printed as multiple pages, however internally, the authenticity of one model is protected.
4. Process activities for labeling Verb-Noun
BPMN describes processes using the concept of flow of activity where the activities represent the actions that occur. They are the work that is done within the process. They are not states, not business functions, and certainly not interactions with use cases. To help reinforce this we encourage students to label their actions by using the verb-noun construction for example, Check Credit or Validate Order and not Credit Check (a function) or Valid Order (a state). A resource will perform each task and the name of the activity must describe the action that is being performed.
5. Define task types
One of the BPMN attributes without a standard illustration in the graph is the type of task. The specification defines a variety of tasks, however there are two types that must be distinguished between the user (human tasks) as well as the service (automated tasks). Luckily, many BPMN tools distinguish between task types using icons in the shape of an activity… However, you must specify the kind you are referring to.
6. Use a task only to schedule work
Another mistake that beginners make is to add tasks such as Send to Manager. This is then an order flow for an employee’s swimming pool. This sequence flow is already sending tasks to the manager, therefore this task of sending to manager is not necessary. It is best to eliminate it.
There’s a third issue also. It is best to use the words “Send” or “Receive” in the task name to indicate the task’s send and receive kinds, which are similar to messages. In BPMN the term “message” refers to a communication that is sent between the program and an external entity. The manager in this case is not an external party however, he is an active part of the process. Therefore, it is not a message and shouldn’t be labeled as Send. If you need to convey an issue to the manager, but without directing the work then you can utilize a task titled Notify Manager. These procedures may appear to be a bit nitpicky initially but, in the end, they allow all employees to quickly understand by looking at the diagram of what’s taking place.
7. Separate failure and success states within a subprocess by having distinct end events
Every subprocess path that is enabled has to reach an end event prior to the process is completed. It is possible to draw one final event in the process, and then route all of the paths it takes to it or draw several end events and then route the appropriate paths to each. Since there’s the implied “join” between all end events technically, it’s not an issue. However, it is beneficial in creating and labeling distinct events at the end for each distinct state of the subprocess especially if certain end states are “success” and others “failure” or some other kind of failure.
The subprocess can be followed by using a gateway to test the state at which it is finished to determine whether it is better to continue the process or perform something different such as end it , or return to the previous step. The matching of the gateway’s label to the label of the final event makes this connection clear within the figure. In addition, an event that ends that is on an exception path within the subprocess could rethrow the error, which is detected by an error signal within the subprocess’s boundary. The end event can also stop the process or trigger different flow of exceptions. The matching of the names of throwing and catching actions will make the connection clear in the diagram.
8. Subprocesses are used to limit associated events
Intermediate events attached to a process activity means that if an event occurs during the activity is in progress stop the process and continue the sequence flow of the event, referred to as”the exception flow. One of the most effective techniques is wrapping the sequence of events by using a subprocess to serve solely the purpose of defining the scope of the event. For instance, if, for example, you are running an order processing procedure that includes steps A to Z, and you wish to permit the customer to alter or cancel their order without penalty at any point during the interval between step B and G. You could wrap the entire sequence starting with B into an unrelated subprocess, and then attach an event for a message and a specific handler flow for exceptions to that.
9. Use specific diagrams that differentiate different kinds of exceptions
BPMN provides a easy-to-use notation to describe exception handling behaviour. Although the BPMN specification allows the modeler plenty of flexibility the best way to go about it is to master specific diagram patterns for identifying the different types of exceptions, and to use them consistently. In our training for instance we will teach specific patterns to model internally-related business issues, systems failures timeouts, solicited responses incidents, unexpected events and many more. The key element is to understand exactly what is being described by the diagram.
10. Make use of message flow patterns consistently to demonstrate the the business context
As well as the flow of activity of real-time process management, BPMN allows you to display interaction between the processes and other processes using connected connectors that are outlined in a dash, referred to as messages flows. Message flows are typically used to are a representation of responses, requests, and uninvited events that are exchanged with other processes. In your own system messages flow are linked to specific actions and events that show exactly what your process does in response to an incoming flow of messages or creates an outgoing message flow. Since you are not in manage or even know the internal workings of the external process, it’s normal to attach the flow of messages to the boundaries of the pool that represents that process.
Message flow can add value business-related context in your model, however it is crucial to utilize them in a consistent way. For instance, if intend to display any messages flowing from or to the requester of your model it is essential to display every one of them. Additionally, you should display them in a consistent manner at each stage within your design. If the same message flow is displayed in a subprocess nestled three levels lower the process, it must be included within the high-level model and labeled with the same name at each level.
