When can a model be called a “good” model?
Modern modeling tools allow everyone, even an individual not familiar with BPM, to create their first process model quickly. By connecting some task boxes with arrows you can make a presentable flow chart in a mater of minutes. In fact, we all know it is possible to make some very nice looking flow charts in all sorts of presentation applications. But whether you should use these ‘nice looking’ models to build, maintain and improve your business processes on, is another story altogether. This is especially true if you are considering automating these processes at any point.
Good process models make process knowledge transparent and enable colleagues to understand specific details of the represented process without having to learn all the variables associated with an unconstrained set of conventions each modeler could potentially use when creating their models.
The benefits derived from establishing common modeling conventions applies to both individuals who are new to modeling as well as a business analyst with years of experience in 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 create the model. Without this consistency, process readers can easily become confused regardless of who authored the model.
Undoubtedly, standardized modeling languages help ensure a common understanding of the processes: There are consistent symbols for activities, decisions, responsibilities, etc., but often different possibilities to depict a process. When modeling, many questions often arise; How do I name activities to ensure that the reader understands what is meant? Which details must be included in the model and which may be left out. Do I need to mention the allocation of roles in an attached textual description or is this information represented graphically? The list goes on.
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. The application of these rules result in consistent high quality process model documentation and eliminate misunderstandings that are otherwise difficult to avoid.
What are modeling conventions and what do they include?
Usually, conventions are defined at the beginning of a modeling initiative. These documents may be very short and describe the essential rules on a few pages. Some other documents are very comprehensive and may include detailed examples exceeding often more than 50 pages. The conventions are usually made accessible to all employees as a PDF-file or via the Intranet.
Often, the document includes the following aspects:
- Introduction. What is a process and why shall processes be described? Who needs to follow the conventions?
- Process architecture. Which processes are in the center of interest? Which level of detail shall be applied in the documentation of processes and what does the structure of the process map looks like? How many hierarchical levels should exist?
- Used notations. Which modeling languages (e.g. BPMN, EPC) is applied? Which subset of modeling elements is relevant?
- Naming conventions. How should activities and gateways be named? How shall start and end events be described?
- Process structure. In which combination shall modeling elements be used? Is it complying with syntax rules? Are there semantic contradictions?
- Layout. Layouting is a very important point too: How shall the diagrams be structured? Colors, sizes, intervals?
- Responsibilities and roles. Who will be the process modeler? Who checks the model and gives final approval for publication?
The individual rules can have different “degrees of hardness”. While some of the rules may be just tips, others may be recommendations or even compulsory. Only if these rules are followed completely is the model deemed acceptable – otherwise it needs to be revised.
Do I need own conventions?
Many people have put considerable thought into the question of what defines good modeling conventions. Numerous books provide insights into this topic, e.g. “BPMN Method & Style” by Bruce Silver or “Real-life BPMN” by Jakob Freund.
Industry and government initiatives have also 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’s administration. The US Department of Defense has also addressed this topic by defining their own modeling conventions for creating process models (DODAF framework).
Most enterprises cannot simply adopt these ‘standard’ guidelines without content changes to make them relevant to their own organization. Once these documents are modified for the specific business, they can then be used for defining the organization’s own modeling conventions. Decisions regarding high level standards (e.g. the application of value chain diagrams on the top level and BPMN for detailed process models) are straight forward to establish. Modeling conventions which typically differ in the choice of process architecture, naming rules and responsibilities and roles are much more difficult. To be effective, an appropriate adjustment to the modeling conventions according to the organization’s individual needs, must be made. Once the enterprise standards are defined, the next question is; How to ensure that the modeling standards are applied to all models created and shared throughout the enterprise?
How do I ensure that my models comply with the conventions?
Typically, modeling conventions are distributed to the modelers and everyone hopes that they will create diagrams that comply with the modeling guidelines. 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 enterprise defined modeling rules. The syntactic correctness of the model is ensured, but when it comes to checking for adherence to the enterprise’s self-defined standards related to process structure and naming conventions, most tools simply give up.
Only Signavio offers comprehensive support for automated model checking against the enterprise’s defined modeling conventions. Our modeling conventions feature even guides you with suggestions to improve your model. For example, the software lets the modeler know “request details” is a better term for an activity compared to “insufficient information”.
Free check of your modeling conventions
To demonstrate the value of this new functionality for checking modeling conventions, Signavio offers a unique and free service: Send us your modeling conventions and we will provide individual feedback with regard to your individually defined framework.
Once you share your modeling conventions with us, you will receive answers concerning the following aspects:
- Completeness: Are all typical rules included in your conventions? What is missing?
- Consistency: Do the rules contradict each other? Which rules are unusual and difficult to obey?
- Automatic vs. manual check: Which rules can be checked automatically and which need to be reviewed manually?
This free service is available until May 31, 2013. To take advantage of this offer, simply send your conventions to:.
Since January 2013, the Signavio Process Editor has included this new functionality for validating process models according to individually defined modeling conventions. Try it yourself. Register for your free 30-day trial account at.