# Quality of Business Process Models

John Krogstie

► To cite this version:

John Krogstie. Quality of Business Process Models. 5th Working Conference on the Practice of Enterprise Modeling (PoEM), Nov 2012, Rostock, Germany. pp.76-90, 10.1007/978-3-642-34549-4_6. hal-01484403

HAL Id: hal-01484403

https://inria.hal.science/hal-01484403

Submitted on 7 Mar 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Quality of Business Process Models

**John Krogstie**

Norwegian University of Science and Technology (NTNU)

krogstie@idi.ntnu.no

**Abstract:** Processes modeling is done for a number of reasons in relation to enterprise modeling, business process modeling and information systems development, and is a widely used technique. In particular after the introduction of BPR and workflow in the nineties, much work has looked on quality of business process models. In this paper we present a specialization of a general framework for assessing quality of models to support the evaluation the quality of business process models. The specialization takes earlier work on quality of models, process quality and quality of business process models into account. Comparing the approaches we find on the one hand that the properties of business process model quality is subsumed by the generic framework on a high level, and that there are aspects in this framework that are not covered by the existing work on business process model quality. On the other hand, the comparison has resulted in an extension of the generic framework for these kinds of models, and in this way improved the practical applicability of the framework when applied to discussing the quality of business process models.

## 1 Introduction

Process modeling is done for a number of reasons in relation to enterprise modeling, business process modeling and information systems development. Process modeling in IS-development can be traced back to at least the 70ties, and business process modeling is gaining in importance. Process modeling can be done to achieve one or more of the goals of modeling. A focus here is on the use of business process models for sense-making, communication, and improvements of business processes, although ways of simulating and deploying the model of the new, improved process is also of importance.

As described in [11] there is a large number of process modeling languages from many modeling perspectives. Still in business process modeling most work has been done relative to languages combining functional and behavioral aspects, such as BPMN, EPC, and UML Activity diagrams.
In an enterprise, different processes are performed. If the enterprise wants to reach its goals and stay in front in the market, every process has to be evaluated and maybe changed to support the goals of the organization. The quality of business processes and business process models have been looked upon in this light in a number of partly uncoordinated works. On the other several more general quality frameworks exist. Inspired by [20], suggesting the need for an inheritance hierarchy of quality frameworks, we will in this paper provide a specialization of the generic SEQUAL framework [10, 14] for the evaluation of the quality of business process models.

In section 2, we present selected existing work on business process model quality. Section 3 provides a brief overview of SEQUAL, whereas the specialization of SEQUAL for business process model quality is described in section 4. The main research questions for the work are:

* Is it possible to specialize the SEQUAL framework to cover aspects of business process model quality as described in the literature?

* Will this specialization extend and introduce new areas of concern for business process model quality?

In section 5, we sum up planned work for developing and evaluating an approach for business process model quality making it applicable for practical use.

## 2 Existing Work on Quality of Business Process Models

There exist no universal rules for what a good process is. We will here present process aspects that can define if we have a good enough or a “bad” process, based on the so-called Process Excellence Principles.

**Customer value and economic profit:** The main goal for most enterprises is to have economic profit. In addition to this, and also as a way to reach this goal, the business wants to have satisfied customers. In Table 1 we present dimensions of value that is valid for most customer groups.

<table><caption>**Table 1** Dimensions of value</caption><thead><tr><td>Component of value</td><td>What a customer wants</td></tr></thead><tbody><tr><td>Time</td><td>Fast</td></tr><tr><td>Quality</td><td>Right</td></tr><tr><td>Cost</td><td>Cheap</td></tr><tr><td>Service</td><td>Easy</td></tr><tr><td>Flexibility</td><td>Sufficient</td></tr><tr><td>Resource-usage (including carbon footprint)</td><td>Low</td></tr></tbody></table>

A customer will experience improvement in an enterprise process if he/she gets his/her product faster, cheaper, with less resources used and with better quality or
service than before, addressing unforeseen needs with sufficient flexibility. Improvement in one of these dimensions could involve that the enterprise gets more customers, increases its market share etc.

**Employee well-being:** Every serious business tries to take good care of their employees. It is important that the persons working in the enterprise are pleased with their working situation. If the individuals' goals and motivation are in strong contrast to the overlying business goals, a conflict will often arise. Based on this, one should also consider the employees' needs and wishes when designing or rethinking business processes. This has to do both with physical aspects like ergonomics, and with psychological aspects such as motivation, needs etc.

**Focus on standard processes:** It is suggested to focusing on standard processes. If you design processes adapted to all kinds of exceptions, they often become too complex and therefore unsuited for the normal cases. It is often more effective to adjust the process for normal cases, and have specific methods for handling exceptions.

With this in mind, one has to find out what the most effective solution in every special case is. It is important to design a process chain that can handle all exceptions and in the same time treat normal instances efficiently.

## 2.1 How can Improvement be Measured?

In order to evaluate whether a new process is better than the existing one, some means of measurement are necessary. Some characteristics to help developing good measures are:

* Accuracy: Accuracy will be useful in the evaluation giving the ability to measure how well or to what extent you reached the goal.

* (Perceived) objectivity: Objectivity is important to ensure that you will get the same conclusion independent of which persons did the evaluation.

* One or more dimensions (e.g. time): The main advantage of using more than one dimension in the goals is that it gives the opportunity to evaluate the results against different criteria of success. If the measures focus on just one dimension, there is a danger of sub-optimization.

* Specify the target. A specified target will give a better evaluation of the result. A general target like "We want the process execution to become faster" is not as good as "We want the process execution to become 75% faster".

* Balancing the trade-offs between cost / quality and speed / flexibility. Unfortunately, lower cost often will entail decreased quality; higher speed will entail decreased flexibility and vice versa. When developing goals, one has to find goals that are possible to reach at the same time.

* Clearly communicated to all involved. The goals and measures must be clear to all persons involved. To get an effective and productive working process, everyone has to pull in the same direction. Understandable and motivating goals and measures are a prerequisite for this.
* Can be shown to support the organization's strategies. If some of the goals and measures are in conflict to the organization's strategies, it will never be able to reach its main goal.

One always should have to stretch to reach a goal. According to psychology and organizational theory both too low and too high goals can be demotivating.

## 2.2 Heuristics for Improving Processes

We will in this part present some ideas for improvement of the total process. Most of these can be traced back to [32]. A more detailed overview is found in [25] where 29 heuristics is mentioned based on a literature survey.

**H1: Specializing and generalizing tasks.** If a process consists of sequential tasks performed by different people with special competence, two problems often arise:

1. The tasks take up too much specialist time.

2. It is difficult to track status of the process because there are too many involved.

The idea is to give a group or one person the main responsibility for the process. This person or persons can execute smaller tasks between the specialist tasks, and also have customer contact. In this way, the specialists can release time for other more important duties and the customer have one contact point where he or she can have all the desirable information.

**H2: Reorganize partial processes.** A second guideline is to organize sequential partial processes in parallel. If it is possible, this will in most cases decrease the total execution time of a process.

Another possibility is to merge two or more partial processes, or split one partial process in various smaller processes. Merging can be an effective tool for improvement, if the processes are tightly bound. Desirable consequences of merging and splitting partial processes are for example better use of resources and faster execution. A thorough analysis of the partial processes and their internal dependency can also uncover parts that are useless for the whole process. These parts are only a waste of time and resources, and should therefore be eliminated.

**H3: Centralize and decentralize structures.** To gain advantage of both the centralizing and decentralizing structures, one can apply a combined model. The decentralizing principle gives flexibility and customer contact, and the centralizing gives control and efficiency.

**H4: Reduce inputs and outputs.** A high number of input and output flows between different departments and groups within an organization increase organizational complexity. The chance of misunderstandings and errors is high, and the many flows can also delay the process execution.
**H5: Postpone aggregated control.** When individually controlled transactions have a total cost that is higher than the cost of sending them together, there is a natural solution to make common control and postpone transactions.

**H6: Reallocate processes or process parts.** A guideline is to move processes or process parts to the customer or to other external supplies. This can be done to save money or move control to another place.

**H7: Change the number of alternatives.** If the number of alternatives is too large, this can result in complexity and inefficiency. If the selection of alternatives is too small, one risks that none of the solutions are appropriate for the special case.

**H8: Change the decision moment.** Earlier decisions will make it easier to continue the process and make it more efficient. Later decisions will give time to evaluate and choose between the alternatives, and therefore give more flexibility.

**H9: Introducing new technology.** Access to new technology will give opportunities to change and improve the process. It is important that the enterprise evaluate the time to do the change, so it matches with e.g. new releases of a software product. Introducing new technology might necessitate other processes that use resources, thus one need to look at the total resource consumption.

In [19] the authors suggest seven process modeling guidelines (7PMG) in an attempt to provide a limited set of easily understandable guidelines:

* G1: Use as few elements in the model as possible. Larger models tend to be more difficult to comprehend [17] and have a higher error probability than small models [17, 18].

* G2: Minimize the routing paths per element. The higher the degree of an element in the process model, i.e. the number of input and output arcs together, the harder it becomes to understand the model [17]. As shown in [18] there is a strong correlation between the number of modeling errors and the average or maximum degree of elements in a model. This is similar to principle H4 above

* G3: Use one start and one end event. The number of start and end events is positively connected with an increase in error probability [18]. Most workflow engines require a single start and end node for automatic process execution [29]. Moreover, models satisfying this requirement are easier to understand and allow for different types of analysis (e.g. soundness checks).

* G4: Model as structured as possible. A process model is structured if every split connector matches a respective join connector of the same type. Structured models can be seen as formulas with balanced brackets, i.e., every opening bracket has a corresponding closing bracket of the same type. Unstructured models are not only more likely to include errors [18]; people also tend to understand them less easily [17], although improving structure might violate G1 since this is often done by introducing duplicated elements [13].

* G5: Avoid OR routing elements. Models that have only AND and XOR connectors are less error-prone [18]. Also, there are some ambiguities in the interpretation of the OR-join leading to paradoxes and implementation problems [8].
* G6: Use verb-object activity labels. A wide exploration of labeling styles that are used in actual process models, discloses the existence of two popular styles and a rest category [23]. From these, people consider the verb-object style, like "Inform complainant", as significantly less ambiguous and more useful than action-noun labels (e.g. "Complaint analysis") or labels that follow neither of these styles (e.g. "Incident agenda") [16]. This is similar to the original guidelines for naming of tasks in DFD's [6].

* G7: Decompose the model if it has more than 50 elements. For models with more than 50 elements the error probability tends to be higher than 50% [18]. This means that large models should be split up into smaller models. Note that an early guidelines for DFD was more restrictive, e.g. to have no more than seven processes at a given decomposition level (based on the 7 +/- 2 guideline for human short term memory) [6].

It should be noticed that the potential interaction effects between the seven proposed guidelines are intricate and diverse. For a given process model, many guidelines can be applicable, at various places in a process model, and conflicting to different degrees. In [19] the authors suggested prioritization is G4, G7, G1, G6, G2, G3, and G5. This should obviously also be compared against achieving other quality types (e.g. model completeness and validity).

# 3 Introduction to SEQUAL

SEQUAL has the following properties [10]:

* It distinguishes between goals and means by separating what you are trying to achieve (quality of models) from how to achieve it.

* It can be used for evaluation of models and modeling languages in general, but can also be extended for the evaluation of particular types of models.

* It is closely linked to linguistic and semiotic concepts. In particular, the core of the framework including the discussion on syntax, semantics, and pragmatics is related to the use of these notions in the semiotic theory of Morris [22]. Extensions are partly based on extensions in organizational semiotics [5] and we have kept the original terminology from these areas.

* It is based on a constructivistic world-view, recognizing that models are usually created as part of a dialogue between the participants involved in modeling, whose knowledge of the modeling domain and potentially the domain itself changes as modeling takes place.

The framework has earlier been used for evaluation of modeling and modeling languages of a large number of perspectives, including data, object, process, enterprise, and goal-oriented modeling. The framework is illustrated in Fig. 1. Quality has been defined referring to the correspondence between statements belonging to the following sets:
* **G**, the set of goals of the modeling task.

* **L**, the language extension, i.e., the set of all statements that are possible to make according to the rules of the modeling languages used.

* **D**, the domain, i.e., the set of all statements that can be stated about the situation.

* **M**, the externalized model itself.

* **K**, the explicit knowledge relevant to the domain of the audience.

* **I**, the social actor interpretation, i.e., the set of all statements that the audience interprets that an externalized model consists of.

* **T**, the technical actor interpretation, i.e., the statements in the model as 'interpreted' by modeling tools.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** SEQUAL framework for discussing quality of models</figcaption></figure>

The main quality types are:

1. Physical quality: The basic quality goal is that the externalized model *M* is available to the relevant social and technical actors.

2. Empirical quality deals with comprehension and predictable error frequencies when a model *M* is read or written by different social actors. Before evaluating empirical quality, physical quality should be addressed.

3. Syntactic quality is the correspondence between the model *M* and the language extension *L*. Before evaluating syntactic quality, physical quality should be addressed.

4. Semantic quality is the correspondence between the model *M* and the domain *D*. This includes both validity and completeness. Before evaluating semantic quality, syntactic quality should be addressed. Domains can be divided into two parts, exemplified by looking at a software requirements specification[9]:
* Everything the computerized information system (CIS) is supposed to do (for the moment ignoring the different views the stakeholders have on the CIS to be produced). This is termed the *primary domain*.

* Constraints on the model because of earlier baselined models such as system level requirements specifications, enterprise architecture models, statements of work, and earlier versions of the requirement specification to which the new requirement specification model must be compatible. This is termed the *modeling context*.

Perceived semantic quality is the similar correspondence between the social actor interpretation *I* of a model *M* and his or hers current knowledge *K* of domain *D*. Before evaluating perceived semantic quality, pragmatic quality should be addressed.

5. Pragmatic quality is the correspondence between the model *M* and the actor interpretation (*I* and *T*) and application of it. One differentiates between social pragmatic quality (to what extent people understand the models) and technical pragmatic quality (to what extent tools can be made that can interpret the model). Before evaluating pragmatic quality, empirical quality should be addressed.

6. The goal defined for social quality is agreement among social actor's interpretations. Before evaluating social quality, perceived semantic quality should be addressed.

7. The deontic quality of the model relates to that all statements in the model *M* contribute to fulfilling the goals of modeling *G*, and that all the goals of modeling *G* are addressed through the model *M*. In particular, one includes under deontic quality the extent that the participants after interpreting the model learn based on the model (increase *K*) and that the audience are able to change the domain *D* if this is beneficially to achieve the goals of modeling. This area was earlier called organizational quality. The term deontic is from Greek 'deon' - duty from impersonal dei - it behoves (i.e. it is fitting) relating the goal one want to achieve.

# 4 Business Process Models Quality Relative to SEQUAL

Quality of business process models is discussed here following the levels of the SEQUAL framework.

## 4.1 Physical Quality

Requirements at this level are the same for business process models as for other modeling activities, i.e. the model must be sufficiently persistent, current, and available relative to the goals of modeling and those involved. Only those that should
have access to the model should be able to see or change it, e.g. security can also be
an issue on this level. Tool functionality in connection with physical quality is based
on traditional repository-functionality.

## 4.2 *Empirical Quality*

This area inherits the standard guidelines for graph layout from SEQUAL. For com-
puter-output specifically, many of the principles and tools used for improving human
computer interfaces are relevant at the empirical level [28]. For visual presentation
of process models, one can also base the guidelines on work e.g. in cognitive psy-
chology and cartography with the basis that models are meant to be useful in connec-
tion to communication between people. Going back to [27], communication entails
both encoding by the sender and decoding by the receiver. Encoding has been dis-
cussed in detail e.g. in the work of Bertin [1]. According to [1] there are 4 different
effects of encoding:

1. Association. The marks can be perceived as similar

2. Selection. The marks can be perceived as different

3. Order. The marks can be perceived as ordered

4. Quantity. The marks can be perceived as proportional

8 different variables to convey one or more of these meanings in a model are:

* planar variables: horizontal position, vertical position

* retinal variables: shape (association and selection), size (selection, order and quantity), color (Association and selection), brightness (value) (selection and order), orientation (association), texture (association, selection and order)

For decoding, Moody [21] presents a model differentiating between aspects of
perception and cognition.

* Perceptual discrimination: Features are detected by specialized feature detectors. Based on this, the visualization is parsed into its parts.

* Perceptual configuration: Structure and relationship among elements are inferred. Within the area of Gestalt psychology, a number of principles for how to convey meaning through perceptual means are provided [30].

* Attention management: All or part of the perceived image is brought into working memory. Working memory has very limited capacity. To be understood, statements in the model must be integrated with prior knowledge in the long-term memory of the interpreter. Differences in prior knowledge (expert-novice differences) greatly affect the speed and accuracy of processing.

Rules for color-usage are also useful in connection to evaluating process models (if different colors are used). Around 10% of the male population and 1 % of the female population suffer from some form of color vision deficiency [30]. On the other hand, color is an important differentiator in other visual representations that is meant to be widely used (e.g. maps, see [1]). [28] Has listed a number of guidelines for the usage of color in visual displays in general.
The use of emphasis can also be in accordance with the relative importance of the different parts of the model. Factors that have an important impact on visual emphasis are:

* Size (the big is more easily noticed than the small)

* Solidity (e.g. **bold** letters vs. ordinary letters, full lines vs. dotted lines, thick lines vs. thin lines, filled boxes vs. non-filled boxes)

* Difference from ordinary pattern (e.g. *slanted* letters will attract attention among a large number of ordinary ones)

* Foreground/background differences

* Change (blinking or moving symbols attract attention)

* Position (looking at a two-dimensional model, people tend to start at its middle)

* Connectivity (objects that connects to many others (having a high degree) will attract attention compared to objects with few connections).

In addition, all the 7PMG guidelines can be positioned at this level, since they relate to comprehensibility and can be easily counted. Thus the following specific guidelines apply:

* G1: Use as few elements in the model as possible. This is the same as the general principle on expressive economy

* G2 and H4: Minimize the routing paths per element.

* G3: Use one start and one end event.

* G4: Model structured by ensuring that every split connector matches a respective join connector of the same type.

* G5: Avoid OR routing elements.

* G6: Use verb-object activity labels.

* G7: Decompose the model if it has too many elements.

The guideline on focusing on standard processes (and not include all exception in the main diagram) also applies here, something that is also supported in [31].

## 4.3 **Syntactic Quality**

From the generic SEQUAL framework we have that there is one syntactic quality characteristics, **syntactical correctness**, meaning that all statements in the model are according to the syntax and vocabulary of the language

Syntax errors are of two kinds:

* **Syntactic invalidity**, in which graphemes not part of the language are used.

* **Syntactic incompleteness**, in which the model lack constructs or information to obey the grammar of the language.

Since you usually have parts of a process model that at some time should be executable, you would like that the language-model also include a representation of the
behavioral semantics, especially if you have a meta-modeling environment where
you might want to make updates to the modeling language for tailoring.

## 4.4 Semantic Quality

To ensure the possibility of consistency checking two of the guidelines in 7PMG is
specifically important

* G3: Use one start and one end event.

* G5: Avoid OR routing elements.

We noted that these where given low priority in the 7PMG report. On the other
hand if consistency and formal analysis (or simulation vs. analysis of throughput
[12] are important, one might want to prioritize these higher. The same applies for
checks of that decompositions are correctly modeled (so-called constructivity).

When working on process improvements, one compares to an improved domain;
thus relative to validity of the model, one has the following guidelines:

* H1: Ensure the right level of specialization of tasks

* H2: Arrange process in parallel if possible

* H3: Have the right level of centralization in the process

* H4: Reduce the number of inputs and outputs

* H5: Postpone aggregated control

* H6: Reallocate process parts of it saves resources

* H7: Have a reasonable number of alternatives

* H8: Put the decision moment at the appropriate time

* H9: Use new technology if appropriate.

The use of these mechanisms relates to evaluating the value for customers and
company, as discussed in section 2 according to measures developed and described
there.

Another mean for supporting semantic quality is that the languages used makes it
possible to represent the necessary aspects in the domain (domain appropriateness).
A number of more detailed evaluations of process modeling languages exist [24].

## 4.5 Pragmatic Quality

Pragmatic quality as we define it relates to the comprehension of the model by par-
ticipants. Two aspects can be distinguished:

* That the interpretation by human stakeholders of the process model is correct
  relative to what is meant to be expressed by the model.
* That the tool interpretation is correct relative to what is meant to be expressed by the process model.

Starting with the human comprehension part, pragmatic quality on this level is the correspondence between the process model and the audience's interpretation of it. Moreover, it is not only important that the model has been understood, but also who has understood the business process model.

It is important to notice that the pragmatic goal is stated as *comprehension*, i.e. that the model has been understood, not as *comprehensibility*, i.e. the ability of the model to be understood (which is what we treated under empirical quality above). There are several reasons for doing so. Comprehension can be very dependent on the process by which the model is developed, the way the participants communicates with each other and various kinds of tool support, such as paraphrasing of the visual model to text [13].

Guideline G3 might also be relevant making it possible to executing the process model e.g. for prototyping [15], explanation generation [7], animation [2] or simulation [12]. An executing process model can also be used for audience training.

## 4.6 Social Quality

The goal defined for social quality is *agreement*. Six kinds of agreement can be identified, according to the following dimensions:

* Agreement in knowledge vs. agreement in interpretation. In the case where two models are made based on the view of two different actors or groups, we can also talk about agreement between the models.

* Relative agreement vs. absolute agreement.

Relative agreement means that the various sets to be compared are consistent -- hence, there may be many statements in the model of one actor that are not present in that of another, as long as they do not contradict each other. Absolute agreement, on the other hand, means that all statements are the same. In practice relative agreement is what one should strive for achieving. Agreement both on the measure used to judge process improvement and the final process are important. Often a final process is based on a merge of several processes, e.g. different processes form different department, or the existing process merged with the process implied through a cured software system such as an ERP system. In this regard mechanisms for comparison of different models would be useful. Matching business process models is discussed in [3, 26]. Three aspects of model similarity are identified, node matching, structural and behavioral similarity: *Node matching* tries to map nodes from one model to nodes of the other model by comparing the labels, attributes and types of nodes. Node matching can be effected with semantic or syntactic measures. The latter is based on the string-edit distance, i.e. the number of letters that need to be added, replaced or deleted to transform the label of an activity in one model to that of an activity in the other model. Semantic matching is based on a database of synonyms or an ontology. Based on the node matching the two models can be compared with
the help of structural or behavioral similarity. The former uses only structural information on the model, i.e. the way in which activities are connected with “arrows”, but does not look at their meaning in terms of control flow. Behavioral equivalence looks at the actual execution of the processes described by the models. Here two models are considered equivalent if, at any time during process execution, an activity that can be performed in one process can also be performed in the other, and vice versa. A weakness with these types of similarity measures is that they usually do not focus on which areas of the model where similarity is of most importance.

One should also be able to deal with inconsistencies, in the sense that not all need to follow the same process in all areas. If two models were inconsistent, it would have been useful to generate some kind of information on the differences. Are the parts that do not match important parts of the model? How hard is it to change parts to make them consistent? Are the inconsistent parts automated or manual processes? The tool could after the analysis suggest which processes or process parts to change.

## 4.7 Deontic Quality

A goal for these type of model is to improve the business process according to improvements relative to time, quality, cost, flexibility, resource consumption, and service level. The goals for this will guide the use of guideline H1-H9. At this level, we are particularly focused on that the process model results in an improved process, i.e. that we improve the domain. Secondarily it is important that involved people get necessary knowledge about the improved model to follow up the enactment of the improved process in practice.

For most models, the goal of total validity and completeness is impossible to reach. If one is trying to include everything in the model, the modeling activity will become a never-ending story. To end up with a model with high semantic quality, it is also essential to have a clear understanding of what that single model should contain. We can think of cases where we have reached the state of feasible validity and completeness, but the modeling domain is too big, and therefore we still do not have a really good model. A model that tries to cover too many aspects becomes unusable for all of them, because it does not cover any of them well enough. The preparation ensuring that the goal of modeling is clear before one starts to make a model is thus very important.

# 5 Relevance for Practice and Concluding Remarks

As with the quality of a software requirements specification (SRS) [9], we see some benefit both for SEQUAI and for a framework for business process model quality by performing this kind of exercise, getting back to our research questions:
* Existing work on business process model quality can be positioned within the generic SEQUAL framework, although it is not a 1-1 match e.g. guideline G3 applies on a number of different levels.

* These existing overviews are weak on explicitly addressing areas such as physical, syntactic quality.

* The existing work on business process quality on the other hand enriches the areas of in particular empirical, semantic and social business process model quality and thus extends the generic SEQUAL framework in these areas.

This overview on the other hand also illustrates one of the weaknesses with a comprehensive framework like SEQUAL. Although the main distinctions between syntactic, semantic and pragmatic quality is used by industrialists [31], it is hard to use the whole framework unguided by practitioners. For most practitioners it is easier to use a limited framework such as 7PMG, given that these guidelines actually address important aspects (as for 7PMG mainly empirical aspects, which are one of many aspects that are relevant for achieving understanding (pragmatic quality)). Thus an extension of this work is developing a two-level framework, which based on the goal of modeling first helps one to identify those quality areas are important, and then highlights the aspects that should be evaluated. Future work will be to device more concrete guidelines along this line and evaluate the use of these empirically, especially how to analyze trade-offs between the different quality types. Some generic guidelines for this already exist in SEQUAL [10], which can be specialized for business process model quality.

## References

1. Bertin J (1983) Semiology of Graphics: Diagrams, Networks, Maps, University of Wisconsin

2. Brown RA (2010) Conceptual Modelling in 3D Virtual Worlds for Process Communication. Proc. 7th APCCM, Brisbane, Australia

3. Dijkman R, Dumas M, van Dongen B, Käärik R, Mendling J (2010) Similarity of business process models: Metrics and evaluation. Information Systems 36, 498-516

4. Dumas, M, La Rosa, M, Mendeling, J, Maesalu, R, Reijers, HA, Semenenko, N (2012) Understanding Business Process Models: The Costs and Benefits of Structuredness. Proceedings CAiSE 2012, Gdansk Poland

5. Falkenberg ED, Hesse W, Lindgreen P, Nilsson BE, Oei JLH, Rolland C, Stamper RK, Assche FJMV, Verrijn-Stuart AA, Voss K (1996) A Framework of information system concepts - The FRISCO Report, IFIP WG 8.1 Task Group FRISCO

6. Gane C, Sarson T (1979) Structured Systems Analysis: Tools and Techniques. Prentice Hall

7. Gulla JA (1996) A General Explanation Component for Conceptual Modeling in CASE environments ACM Transaction on Information Systems Vol 14 Issue 3

8. Kindler E (2006) On the semantics of EPCs: Resolving the vicious circle., Data & Knowledge Engineering 56 (1) 23-40

9. Krogstie J (2001) A Semiotic Approach to Quality in Requirements Specifications. Proceedings IFIP 8.1. Working Conference on Organizational Semiotics, Montreal, Canada, 23-25 July

10. Krogstie J (2012) Model-based Development and Evolution of Information Systems: A Quality Approach, Springer

11. Krogstie J (2012) Perspectives to Process Modeling - A Historical Overview. EMMSAD

12. Kuntz, JC, Christiansen, TR, Cohen, GP, Jin, Y, Levitt, RE (1998) The Virtual Design Team: A Computational Simulation Model of Project Organizations, Communications of the ACM, vol. 41, no. 11.
13. Leopold, H, Mendling, J, Polyvyanyy, A (2012) Generating Natural Language Texts from Business Process Models. Proceedings CAiSE 2012, Gdansk Poland

14. Lillehagen, F, Krogstie, J (2008) Active Knowledge Modeling of Enterprises, Springer

15. Lindland OI, Krogstie J (1993) Validating Conceptual Models by Transformational Prototyping. Paper presented at the 5th International Conference on Advanced Information Systems Engineering (CAiSE'93), Paris, France, June 8-11

16. Mendling J, Recker J (2008) Towards systematic usage of labels and icons in business process models. In: Halpin T, Proper HA, Krogstie J (eds.) 13th International Workshop on Exploring Modeling Methods in Systems Analysis and Design, CEUR Workshop Proceedings Series, Montpellier, France

17. Mendling J, Reijers H, Cardoso J (2007a) What makes process models understandable? In: Alonso G, Dadam P, Rosemann M (eds.) Business Process Management, 5th International Conference, BPM 2007, Brisbane, Australia, September 24-28, 2007, Proceedings, Vol. 4714 of Lecture Notes in Computer Science, Springer, Brisbane, Australia, pp. 48-63.

18. Mendling J, Neumann G, van der Aalst WMP (2007b). Understanding the occurrence of errors in process models based on metrics. In: Meersman T, Tari Z (eds.), OTM Conference 2007, Proceedings, Part I, Vol. 4803 of Lecture Notes in Computer Science, Springer, pp. 113-130

19. Mendling J, Reijers HA, van der Aalst WMP (2010) Seven Process Modeling Guidelines (7PMG). Information and Software Technology (IST). Volume 52, Number 2, pages 127-136

20. Moody DL (2005) Theoretical and practical issues in evaluating the quality of conceptual models: Current state and future directions. Data and Knowledge Engineering 55 (2005) 243-276

21. Moody DL (2009). The "Physics" of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE TSE, 35, 756-779

22. Morris C (1938) Foundations of the Theory of Signs, in International Encyclopedia of Unified Science, vol. 1, University of Chicago Press, London.

23. Recker J, Mendling J (2006) On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages. In: Latour T, Petit M (eds) Proceedings of the CAiSE Workshops, Luxembourg, Luxembourg pp. 521-532

24. Recker J, Rosemann M, Krogstie J (2007) Ontology- versus pattern-based evaluation of process modeling language: A comparison. CAIS 20:774-799

25. Reijers, HA, Liman Mansar, S (2005) Best Practice in business process redesign: An overview and qualitative evaluation of successful redesign heuristics. OMEGA 33 283--306

26. Rittgen, P (2011) Business Process Model Similarity as a Proxy for Group Consensus POEM 2011, Oslo Norway 2-3 November

27. Shannon CE, Weaver W (1963) The Mathematical Theory of Communication. Univ. of Illinois Press

28. Shneiderman, B (1992) Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison Wesley, Reading, Massachusetts, 2nd edition

29. van der Aalst WMP, ter Hofstede AHM, Kiepuszewski B, Barros AP (2003) Workflow Patterns. Distributed and Parallel Databases 14 (3), pages 5-51, July

30. Ware C (2000) Information Visualization Morgan Kaufmann

31. Wesenberg H (2011) Enterprise Modeling in an Agile World. Proceedings of the 4th conference on Practice of Enterprise Modeling, Oslo, Norway, November 2-3

32. Willoch BE (1994) Business Process Reengineering – En praktisk innføring og veiledning, Fagbokforlaget Vigmostad og Bjorke AS, Bergen