Business Process Modeling Notation, or BPMN, is a process modeling standard; it defines how processes should be described visually. It consists of a number of standardized elements, which when taken together ensure that each process model, BPMN diagram,, and workflow within an organization is constructed using common BPMN modeling conventions. This in turn ensures that all business users understand exactly how process models should be constructed, making for quicker and easier process modeling, with fewer errors.
In addition, a common understanding of the language of BPMN means each participant in a process, no matter where they are located, can see and understand the way a given process works within their organization. This understanding can be further enhanced when organizations also define their own modeling conventions, specific to their company. The overall consistency and quality of models, regardless of who produces them, can be significantly improved through the application of enterprise-wide BPMN modeling conventions.
A modern business process management tool allows everyone, even an individual not familiar with BPM, to create process models relatively quickly. By connecting a few task boxes with arrows you can create a diagram that offers graphical representation of almost any business process in a mater of minutes. In fact, we all know it is possible to make some very nice-looking flowcharts in all sorts of presentation applications. The question is, of course, whether you should use these ‘nice-looking’ models to build, maintain and improve your business processes. Most modern businesses will agree that for true process optimization, in the pursuit of operational excellence, flowcharting is not enough.
Good process models make process knowledge transparent. An effective BPMN model should enable colleagues to understand specific details of the represented process (for example, which flow objects are executable, which are event-based, and so on) without having to learn any additional set of conventions associated with the particular flair and creativity of an individual modeler.
The benefits derived from establishing common modeling conventions applies to both individuals who are new to modeling as well as, say, a business analyst with years of experience creating business process models. To establish a common understanding in regards to processes within any organization, it is essential that all process creators represent the model in consistent fashion regardless of who in the organization created the model.
Therefore, we can see that a ‘good’ process model is one that allows any reader to understand it easily, no matter their expertise or role within the company. Without this consistency across an organization, process readers can easily become confused, and the purpose of the process model existing in the first place is undermined.
Standardized modeling languages help ensure a common understanding of the way your organization works, from a strategic level right down to the simplest sub-process. BPMN ensures each object within every business process diagram your organization uses has a consistent symbol, no matter if that object represents activities, decisions, participant responsibilities, or whatever else. (For more information on the symbols, and definitions, check out our.)
Of course, within any BPMN model, these objects are combined in different ways to depict a certain process to the required specification. As such, when modeling, many questions often arise: “How do I correctly name flow objects so the reader understands the activities they are supposed to represent?” or, “Which details must be included in my BPMN diagram, and which can I safely leave out? or, “Do I need to mention the allocation of roles in an annotation to the diagram itself, or is this information already represented graphically?” The list goes on—no doubt you could add some questions of your own!
To provide guidance to modelers while creating process diagrams and orientation to readers in their effort to understand process diagrams, the definition and application of specific modeling rules are very helpful. It is not just a question of semantics—the application of consistent rules should result in consistent high quality process modeling, as well as eliminate misunderstandings that are otherwise difficult to avoid. This is especially true if you are considering automating your business processes at any point.
Usually, conventions are defined at the beginning of a business process modeling initiative. A list of conventions may be very short, simply describing the essential rules on a few pages, or may stretch to dozens of pages offering detailed and comprehensive examples of every type of BPMN diagram an organization uses. Regardless of size, the conventions should be made accessible to all employees, with the intention once again of ensuring everyone understands the way your organization constructs a BPMN diagram.
When developing your list of BPMN modeling conventions, it is important to consider the following points.
What does our organization consider as a ‘business process’, and why do we think it is important to define each business process? Who needs to follow the conventions?
Which processes are in the most vital? What level of detail shall we apply to the documentation of processes, and what does the structure of our process models actually look like? How many hierarchical levels do we need? Should we include everyin every diagram?
Which modeling language should we use? Which subset of modeling elements is relevant? What BPMN tool do we use?
What should we call activities and gateways? How should start and end events be described? (This can go right down to the grammar used for naming each object, e.g. “Any activity must be named with a past participle using an active verb.”)
What combinations of modeling elements are allowed, or not allowed? Do our process models comply with syntax rules? Are there contradictions in the semantics within any of our process models? What does our ‘sequence flow’ look like within any single model?
How are our diagrams laid out? What is the graphical specification of each of our models, i.e. what do they actually look like when it comes to colors, fonts, size of different elements, etc.
Who can or cannot be a process modeler? Who checks a new process model when it is created, and gives final approval for publication?
The individual rules can be enforced to different degrees, of course—some may be just tips, others may be recommendations, and many BPMN modeling conventions will be compulsory. In any case it is important to ensure the message flows from management through to all employees within a company: “This is how we do process modeling and BPMN.”
Most enterprises cannot simply adopt standard BPMN guidelines without instituting changes to make them relevant to their own organization. Once the questions above have been considered, they can then be used for defining an organization’s own modeling conventions. Decisions regarding high level standards (e.g. the application of value chain diagrams at the top level, or BPMN for very detailed process models) are generally straightforward to establish.
However, modeling conventions which differ in the choice of process architecture, naming conventions, and the way responsibilities and roles are defined and allocated can be much more difficult. To be effective, an appropriate adjustment to the modeling conventions according to the organization’s individual needs must be made. This is clearly a matter for each individual organization to consider and decide, with the caveat that it is generally best not to deviate to widely from the standard approach to BPMN, as the more complexity introduced into a system, the more likely it is for employees to struggle with the requirements.
A range of industry and government initiatives have recognized the importance of this topic. Switzerland’s eCH-initiative provides an important example of a program providing guidelines for modeling consistent process models within the Swiss Government. The US Department of Defense has also addressed this topic by defining their own modeling conventions for creating process models, known as the DODAF framework.
Typically, an organization’s BPMN modeling conventions are distributed to workers, and everyone hopes they will create diagrams that comply with the modeling guidelines. To provide some assurance that this is in fact the case, individual workers can think about the ‘three C’s’—completeness, consistency, and checking.
To act as a further guarantee, often there is a central person or department reviewing each model to ensure adherence to the modeling conventions. Usually, this happens manually, as many tools do not offer an automatic validation of an organization’s self-defined modeling rules. In other words, while the syntactic correctness of the model is ensured, most tools simply give up when it comes to checking for adherence to an organization’s self-defined standards.
Fortunately, thecan offer comprehensive support for automated model checking against an enterprise’s own modeling conventions. Our modeling conventions feature even guides you with suggestions to improve your model, for example when the software lets the user know that “request details” is a better term for an activity when compared to “insufficient information.”
has the ability to automatically validate process models according to individually-defined modeling conventions, as well as a whole lot of additional features to make your BPMN (and BPM) journey easier. If you’d like to know more, check out some practical examples with Signavio’s guide to . Whether you’re a certified expert, or you don’t know your from your non-interrupting sub-process, Signavio has the solution for you. See for yourself, and register for a free today.