In the first part of this paper we introduce general quality criteria for conceptual models, which are independent of the application domain of the model. Furthermore we describe an evaluation framework for behavior models used for modeling business processes, which is more specific than the general quality criteria.
In the second part of this paper we introduce the conceptual framework as developed in the Testbed project, which is directed at improving business processes using a model-based approach. We argue that this conceptual framework meets the quality criteria described in the first part of the paper, and we illustrate the use of this framework by an example of a car insurance company.
Within the Testbed project a number of large, administrative organizations strive to improve their businesses by using a model-based approach, as shown in Figure 1. The current business process is modeled by abstracting from irrelevant details and focusing on the (from a business point of view) essential issues. This model is optimized according to the company’s strategic vision or the customer’s comments on the current business process, resulting in alternative models of the redesigned service. These alternative models will be compared on the basis of business criteria, and may be refined and analyzed using pragmatic principles regarding the use and availability of information, the employment of technology, the organization of work, etc., such as suggested by e.g. Hammer [Hamm90] and Davenport and Short [DaSh90]. Several redesigned "to be" processes can be modeled and compared in an "off-line" way, i.e., without endangering the continuity of the real-life business process. Only after considering all pros and cons a selected process may be refined into a real-life implementation, starting a migration trajectory.
Figure 1. Model-based approach to business process re-engineering.
The Testbed project develops knowledge, methods and tools for the modeling, analysis and redesign of business processes according the approach shown in Figure 1. Testbed supports business process redesign (BPR) and business process improvement projects.
Most of today’s approaches to business process modeling start from an activity-centred perspective. Activity models, such as process algebras, state charts, Petri nets, flow charts or data flow diagrams are used to define the activities within a business process and the relations between them. Although we do not question the central role of processes, a business model consists of more than activities only. In particular we need organization models to define the organizational entities that are involved in a business process and data models to describe (the structure of) the objects that are manipulated within a business process. Business modeling should integrate activity modeling, organization modeling and data modeling. With integrate we mean that it is not enough to define different models for each of the three aspects (in coincidentally existing languages), because there is a strong connection between these three aspects. Therefore business modeling should integrate these three aspects into a single model. An important question remains: What constitutes a "good" business model?
In this paper we focus on this question. This paper is structured as follows. Section 2 focuses on what conceptual models are and introduces a number of quality criteria for conceptual models in general and behavioral models in particular. Section 3 shows the Testbed approach to meet these quality criteria. Section 4 shows an example case of the Testbed approach. Section 5, finally, presents our conclusions.
This research is partly financed by the Dutch Ministry of Economic Affairs as part of the "Testbed Project", a co-operation of ABP (a major Dutch pension fund), The Dutch Tax Department, ING Group (a major Dutch bank and insurance company), IBM and the Telematics Research Centre (see also http://www.trc.nl/projects/testbed.htm).
The notion of quality of conceptual models, what it means and how it can be achieved, is not yet well understood. Often, only an ad hoc list of desired properties of a model is provided. Moreover, quality in the sense of "fitness for use" [JuGr88] is also a matter of taste. In a more systematic way, Lindland et al. introduce three kinds of quality [LiSS94]:
These three categories closely match our view on what a conceptual model is. Figure 2 shows our view on a conceptual model. A model in the "conceptual world" captures all essential aspects of the "real world". The word essential refers to a specific modeling objective. This model will be represented in a language (the "symbolic world"), so that we can communicate about it. A designer always looks through this "window" of its representation to the shared (i.e., interpreted in the same way) conceptual model but, of course, still might have his own, individual interpretation of the model.
Figure 2. Conceptual model related to reality, language and interpretation.
In this paper, we focus on concepts for modeling and the degree up to which concepts are able to capture the essence of the real world. We assume the concepts can be captured in a suitable language. From this point of view, syntactic quality is not relevant. To capture semantic quality (completeness and validity) and pragmatic quality, we propose the following quality criteria, which are mainly derived from design applications in the area of computer architecture [BlBr85] en protocol specification [Sind95]:
These criteria mainly focus on the "external" quality of concepts, i.e., the satisfaction to the users. We may also distinguish "internal" quality of concepts, i.e., quality aspects that refer to the intrinsic properties of concepts. Van Sinderen [Sind95] distinguishes four internal quality criteria for concepts: consistency, orthogonality, inherence (called propriety) and generality. This gives us three additional criteria:
These six criteria have been used to define our (Testbed) concepts. Another requirement of the concepts is correctness (represent the real world in a correct way, without errors). Although this requirement is very important, we cannot translate it to a testable quality criterion; however, this requirement is being verified by the partners in Testbed by using the concepts.
The above mentioned six quality criteria are generic, i.e. independent of any application domain. The Testbed project focuses on the administrative sector, in particular on modeling business processes. To evaluate whether the concepts (or modeling language as you wish) will be suited for this specific purpose, we need more than only these generic criteria: we also have to evaluate what aspects of business processes can be expressed with the concepts and how easily or insightfully they can be expressed. Besides that, one also needs to know when to use specific models. Given these considerations, Testbed developed an evaluation framework for modeling frameworks and tools consisting of four dimensions [JaJV97], as shown in Figure 3:
Figure 3. The dimensions of the evaluation framework
The dimensions "BPR trajectory" (which phases of a BPR trajectory are supported) and "General" (e.g. the price of a tool and customer support) are important when purchasing a BPR tool, but not for an evaluation of behavioral models in general. Therefore, they will not be considered further in this paper.
The "Functionality" dimension mainly applies to the possibilities that the underlying modeling concepts offers. The following list of criteria is used to evaluate modeling concepts:
In order to guarantee that the modeling concepts are actually used, ease of use is at least as important as the functionality. This dimension includes the following criteria:
The Testbed Project focuses on the development of knowledge, methods, and tools for modeling, analysis, and redesign of information-intensive business processes. The conceptual framework developed comprises a set of modeling concepts, construction rules, and design criteria that facilitate the construction of business process models. In the following we focus on the models only (not the methods). To meet the quality criteria as mentioned in the previous paragraph, the Testbed project applies three basic principles:
To structure a model, Testbed distinguishes three dimensions: specification domain, level of detail and abstraction level.
A model in Testbed consists of three specifications:
Although these specifications are orthogonal and can therefore be described separately, they are closely linked: behaviors are assigned to entities and use (read) and/or change (write) items. Together, these three specifications form a single model.
This model can be specified on several levels of detail. For example, from an external point of view ("black-box specification") the model shows how the (business) process or organization is viewed from the outside (the service an entity provides to the environment). From an internal point of view ("white-box specification"), details are added and the model shows how the service provided to the environment is implemented by internal components. In turn, these components can be viewed as either black-boxes or white-boxes (iteration). The level of detail is related to composition and decomposition. The structure and overall behavior of the model are preserved.
On the other hand, the abstraction level refers to related models that may have a different structure. The similarity between these models is that they are all abstractions of the same real-life process or organization, though on a different "distance" from reality. In particular, we distinguish a logical model in which roles and business functions are specified, and a physical model that represents physical objects (a person, a resource) and properties (geographical aspects, time, the results of scheduling, etc.).
Figure 4 summarizes the overall structuring of a model in Testbed. In the following we focus on the concepts to construct these model parts. (So methodological issues like the order in which the several model parts are developed, i.e. the design strategy, are outside the scope of this paper).
Figure 4. High-level structuring of a conceptual model.
The concepts for modeling in Testbed are subdivided in three layers, as shown in Figure 5. First, we have a set of basic, general concepts and associated construction rules. These basic concepts are sufficiently powerful for modeling all relevant aspects of business processes, but their use may lead to complex models which are hard to understand. On top, therefore, we have defined a layer of compositions and specializations of these basic concepts. These (higher level) concepts are closer to the application area. Moreover, they have a higher descriptive power and therefore simplify the modeling process and lead to more comprehensible models. They are specific for business processes (visualized in the figure by the Testbed Project logo). Finally, we can in turn use these concepts to define a composition and/or specialization that is specific for a single line of business or situation (visualized by the names of the participants of the Testbed Project).
Figure 5. Three levels of concepts.
In this paper we focus on the basic concepts. Their conceptual basis lies in causality relations [QFS+97].
Behaviors are defined as sets of (related or non-related) actions and interactions. An action represents an (on a given level of detail considered as atomic) activity in a business process. Actions are characterized by three attributes: value, actor, and time. These designate the result of the action, the entity (in the entity domain) to which the action is assigned, and the moment at which the result of the action becomes available. An action that is assigned to several entities jointly is called an interaction (i.e., an action shared by different behaviors and entities). The logical or physical "locations" in the entity domain to which actions are assigned are called action points or interaction points (an interaction point being an action point that is shared by different entities). As suggested by their respective names, actions are assigned to action points, and interactions to interaction points.
Between (inter)actions we have two basic causality relations, as shown in Figure 6:
Combined causality relations can be modeled using the operators AND- and OR-split or -join. Also repeated behavior can be modeled (in Figure 6 a enables the continuous repetition of b).
Figure 6. Some examples of causality relations between actions.
Generally, a business process designer wants to structure large behavior definitions. This enhances clarity, facilitates the identification of recurring sub-behaviors, and makes it possible to split a behavior into sub-behaviors that can be assigned to different entities. In Testbed, two structuring techniques are available: causality-oriented and constraint-oriented structuring. Metaphorically speaking, causality-oriented structuring cuts through causal relations, and constraint-oriented structuring cuts through actions, separating them into parts of an interaction. A single (sub-)behavior delineated by these structuring techniques is called a behavior block.
A behavior definition can be constructed at different levels of abstraction. A lower level of abstraction means that more details are added. To this end, we distinguish the operations of action refinement, relation refinement, and specialization. Action refinement replaces an action by a number of actions that together constitute the behavior of the original action. Relation refinement does the same for causality relations. Specialization constrains either the result of actions or their conditions, thereby limiting the possible executions of the model.
An entity represents a logical or physical object that can perform behavior. Entities may be structured and nested, i.e., composed of other entities. Examples of entities are people, machines, teams, departments, organizations, etc. Actions can be assigned to an entity, which means that those actions are executed by that entity. Interactions can be assigned to two or more entities, which means that those interactions are executed by those entities together. Entities can be replicated, meaning that there is a set of similar entities, like a set of desks in a postoffice.
An item represents an independent physical or information object in a business process. Other words that are sometimes used for items are enterprise objects and jobs. Items may be nested, i.e., composed of other items. Examples of items are documents, dossiers, archives, accounts, writing-desks, etc. Four kinds of operations are defined for an item: new, dispose, use and modify. The operations on an item are transactions (ACID properties). An action is only allowed to use an item that has been modified by another action if and only if there is a causal relationship from the modifying to the using action. In Testbed, the items are specified in a subset of the database specification language TM [BaBZ93] that conforms to ODMG-1993 [Catt93]. TM is also used to specify conditions and attribute values in the behavior domain. As opposed to what several other frameworks for business modeling do, we think it is not a good idea to identify aspects or views on a model with the things that (fortuitously) can be expressed in an existing language.
We have chosen to use the concept of causality instead of the (perhaps more intuitive) concept of data flow as the basic relationship between actions because of the greater expressiveness of the former. Modeling concurrency, deadlock, independence, and disjunction is difficult or impossible using purely flow-based concepts. The expressiveness of the basic concepts includes the expressiveness of Petri nets [Reis85] and all concepts of the workflow paradigm [CVSG97, WfMC96].
The behavioral concepts have a formal semantics that is based on Katoen’s extended dual event structures [KaBr96]. Event structures are partially ordered sets of events or action occurrences. These events are linked with actions by means of a labelling function. Between events of the partial order we can have causality (enabling) relations and conflict (disabling) relations. We have augmented the original extended dual event structures with synchronization, may/must labels and internal (invisible) actions. Based on this formal semantics, simulation, analyses and model checking can be implemented in computer tools.
To illustrate the concepts introduced in the previous sections, we give a brief example of the use of these concepts. The example we give is fictitious, but realistic. It describes a car insurance company called PRO-FIT. We will not illustrate the complete approach to business process redesign as shown in Figure 1, but only one (model of a) business process. The business process we will describe briefly here is the process of settling insurance claims. First we will describe the process from an external viewpoint.
After some car damage has occurred, the owner of the car has to notify PRO-FIT of the damage. PRO-FIT then gives the owner the address of the nearby damage repair garage, which is under contract by PRO-FIT (which means that the garage is authorized to value car damage). The owner delivers his car to that garage for an valuation of the damage, while sending his insurance claim to PRO-FIT. The garage sends the damage valuation to PRO-FIT. On the basis of both the claim and the damage valuation, PRO-FIT decides whether or not the claim can be accepted and paid. PRO-FIT informs both the owner and the garage of its decision. If the claim is accepted by PRO-FIT, the garage can repair the damage, after which the owner can pick up his repaired car. The garage then sends the bill to PRO-FIT, and receives payment from PRO-FIT. This behavior is shown in Figure 7.
Figure 7. The behavior of settling an insurance claim.
This behavior is performed on several items, as shown in Figure 8.
Figure 8. Behavior and items of settling an insurance claim.
The entities and their interaction points which are involved in settling claims are depicted in Figure 9.
Figure 9. The entities involved in settling an insurance claim.
Assigning the actions in Figure 7 to the entities in Figure 9 results in Figure 10. Interactions are depicted by ‘cut-through’ actions.
Figure 10. Behavior assigned to entities.
The figures above describe the external view on this process. Using the concepts and operations described in section 3, the process can be modeled from an internal view and on different levels of detail as well. As an example, we now describe the action ‘judge claim’ from an internal point of view. This action consists (from an internal, more detailed point of view) of three separate actions: create customer file (a file is opened for the claim and the valuation), check completeness (check if all information is available, and if not, collect all necessary information) and judge claim (where the actual decision is made). This part of the behavior is shown in Figure 11.
Figure 11. A more detailed behavior description of judge claim.
A more detailed behavior description of check completeness is shown in Figure 12.
Figure 12. A more detailed description of check completeness.
If we assign this behavior to the entities involved, it results in Figure 13.
Figure 13. Assigning the behavior to the entities involved.
The above example shows (although very briefly) the concepts, specifications, abstraction levels, and views a Testbed model consists of. It illustrates the way Testbed can be used to model processes in the course of improving business. In a similar way Testbed has been and is being used by the partners in the Testbed project for improving their businesses.
Within the Testbed project a number of large, administrative organizations strive to improve their businesses by using a model-based approach: the current business process is modeled, analyzed, and optimized, resulting in alternative models of the redesigned service. These alternative models can be compared, refined and analyzed. Only after considering all pros and cons a selected process may be refined into a real-life implementation, starting a migration trajectory. The conceptual framework developed in the Testbed project comprises a set of modeling concepts, construction rules, and design criteria that facilitate the construction of business process models. This framework is based on a formal semantics, and implemented in a tool. In this paper we have described the concepts from which these models are build. We have given several quality criteria for such models, and argued why our concepts and models meet these criteria. The conceptual framework is illustrated by an example showing how Testbed can be used for improving businesses.
[BaBZ93] Balsters, H., R. de By and R. Zicari, "Typed sets as a basis for object-oriented database schemas", in Proceedings Seventh European Conference on Object-Oriented Programming, Kaiserlautern, Germany, 1993.
[BlBr85] Blaauw, G.A. and F.P. Brooks Jr., Computer Architecture, Lecture notes University of Twente, Enschede, The Netherlands and University of Carolina, Chapel Hill, August 1985.
[Catt93] Cattell, R.G.G. (ed.), The Object Database Standard: ODMG-93. Morgan Kaufmann, San Francisco, 1993.
[CVSG97] Chan, D.K.C., J. Vonk, G. Sánchez, P.W.P.J. Grefen, and P.M.G. Apers, "A specification language for the WIDE workflow model", in Proceedings of the 9th International Conference on Advanced Information Systems Engineering, Barcelona, Spain, June 16-20, 1997. To appear.
[DaSh90] Davenport, T.H. en J.E. Short, "The new industrial engineering: Information Technology and Business Process Redesign", Sloan Management Review, Summer 1990, 11-27.
[Hamm90] Hammer, M., "Reengineering work: Don’t automate, obliterate", Harvard Business Review, July-August 1990, 104-112.
[JaJV97] Janssen, W., H. Jonkers and J. Verhoosel, "What Makes Business Processes Special? An evaluation framework for modelling languages and tools in Business Process Redesign", In Siau, Wand and Parsons (Eds.), Proceedings 2nd CAiSE/IFIP 8.1 international workshop on evaluation of modeling methods in systems analysis and design, Barcelona, June, 1997
[JuGr88] Juran, J.M., and F.M. Gryna (ed.), Juran’s quality control handbook. McGraw-Hill, New York, 1988, 4th edition.
[KaBr96] Katoen, J-P., and E. Brinksma, "Disjunctive causality", in Mathematical Foundations of Programming Semantics XII, Boulder, Colorado, June 1996.
[LiSS94] Lindland, O.I., G. Sindre and A. Sølvberg, Understanding quality in conceptual modelling, IEEE Software, Vol. 11, No. 2, March 1994, 42-49.
[QFS+97] Quartel, D.A.C., L. Ferreira Pires, M.J. van Sinderen, H.M. Franken and C.A. Vissers, "On the role of basic design concepts in behaviour structuring", Computer Networks and ISDN Systems, vol. 29, no. 4, March 1997, 413-436.
[Reis85] Reisig, W., Petri Nets, an Introduction, EATCS Monographs on Theoretical Computer Science, Springer-Verlag, 1985.
[Sind95] Sinderen, M.J. van, On the design of application protocols. Ph.D. Thesis, University of Twente, Enschede, The Netherlands, 1995.
[WfMC96] Workflow Management Coalition, Terminology and Glossary, document WfMC TC-1011, Issue 2.0, June 1996.