STRUCTURAL AND QUANTITATIVE PERSPECTIVES ON BUSINESS PROCESS MODELLING AND ANALYSIS Henry M. Franken, Henk Jonkers and Mark K. de Weger* Telematics Research Centre * University of Twente P.O. Box 589 Centre for Telematics and Information Technology 7500 AN Enschede P.O. Box 217, 7500 AE Enschede The Netherlands The Netherlands E-mail: {h.franken, h.jonkers}@trc.nl E-mail: deweger@cs.utwente.nl KEYWORDS Business (re)engineering, model structuring, model design, performance analysis ABSTRACT In this paper we introduce and motivate the use of structural and quantitative perspectives on business process modelling and analysis. Structural perspectives are associated with certain model structuring styles. Quantitative perspectives are associated with certain process measures, in our case time-based measures. Furthermore, we relate these structural and quantitative perspectives. The introduced perspectives and their relationships enhance the insight in business process models and facilitate their analysis. INTRODUCTION Business process improvement or redesign using the enabling role of telecommunication and information technology applications is currently attracting significant attention. In many situations an understanding of the considered business processes is key to success. It is well accepted that understanding of business processes can be achieved by constructing business process models (Jacobson et al., 1995). Such models can be designed, analysed, and simulated off-line without actually having to build the business processes in practice. This so-called off-line modelling is especially useful for the redesign or improvement of business processes which are in the critical path of an organisation. Redesign of such processes should be carefully examined to avoid continuity risks for the considered organisation. The current paper contributes to the field of the modelling and analysis of business processes by relating structural and quantitative perspectives. By structural perspectives we mean providing a clear structure to a business process model. A clear structure enhances the comprehensibility of a business process model. By quantitative perspectives we mean providing clear quantitative measures for business process analysis and optimisation. Quantitative perspectives focus the analysis and optimisation of business processes on certain issues. We restrict ourselves to time-based quantitative measures in the current paper. We will also show in this paper how the time-based quantitative measures can be related to certain structural perspectives on business process models to provide additional insight during a business process modelling and analysis session. The main application area of our work is the service industry. This paper is structured as follows. First, we briefly introduce and motivate essential concepts for business process modelling. Second, we show how business process models can be structured and viewed from different perspectives. Third, we introduce a set of time-based quantitative perspectives on business process analysis. Then, we show how these quantitative perspectives can provide useful insight from a certain structural perspective on the business process model. Finally, we present and discuss our major conclusions. BUSINESS PROCESS MODELLING In (Franken et al., 1996) we presented a modelling framework enabling business process engineers to represent and analyse the structure and the behaviour of a business process. Here we summarise its foundation. When modelling dynamic discrete-event systems such as business processes, we distinguish two modelling domains, the behaviour domain and the entity domain. The former describes the dynamic behaviour, i.e., the actual business activities and their relationships; the latter describes the business entities performing the activities, such as people, offices, departments and technology, and the way in which these are organised. The entity domain is modelled by concepts for business entities (or resources) and their interconnection. The behaviour of the business process is modelled by concepts for business actions, performed by business entities, and interactions performed by co-operating business entities. The results and further characteristics of these (inter)actions, e.g., services or products realised, and time and place of realisation, are modelled by introducing (inter)action-attributes. Relationships between the (inter)actions are modelled by causal relationships that capture the business dynamics. These causal relationships can be summarised as follows: enabling (the occurrence of a certain action makes the occurrence of another action possible), disabling (a certain action inhibits the occurrence of another action) and synchronisation (a certain action can only occur together with another action). Modelling the behavioural characteristics of the business process gives qualitative insight in the way customers are serviced, the way internal activities are performed to provide this service, and enables quantitative optimisation based on quantitative process measures.
Modelling the entity characteristics of the business process facilitates, among others, the analysis of the role, responsibility and authority of business entities and their allocation to work (behaviour). These two domains are coupled by means of a mapping, which links activities and entities. An important issue to be considered when modelling a business process is the choice of the appropriate level of abstraction. A model at a high abstraction level only describes the global aspects of a process, while a model at a low abstraction level includes all kinds of details. It is important for modelling techniques to be applicable at different levels of abstraction. One way to work with different levels of abstraction is to iteratively use extensionally and intensionally structured models, as will be explained in the next section. The fact that we focus on time-based quantitative measures on business processes imposes a number of requirements on the choice of a modelling formalism. First, the modelling technique must have a formal basis in order to be able to define the analysis results unambiguously. Of course, it is necessary that we can express the evolution of time and the duration of activities. Furthermore, nearly all realistic business processes contain sources of uncertainty; we should also be able to quantify these, e.g., by means of a probability distribution. Finally, synchronisations have a major influence on the temporal behaviour (e.g., as a result of communication between people: an employee cannot start with a task before the necessary information from a customer is received), as well as the shared use of resources (e.g., only one person at a time can make use of a copier, which can lead to waiting times). STRUCTURING OF BUSINESS PROCESS MODELS An important objective of business process models of (both current and new) business processes is the provision of insight in particular aspects of these business processes. It is well known that, in addition to its presentation, the structure of a model, the way in which its elements are related, determines to a large extent this insight. For example, a modular structure (i.e., in terms of self-contained units) is necessary in order to obtain models which are comprehensible and easy to implement (Parnas, 1972). The consistent application of a structuring technique during modelling leads to a so-called modelling style (Vissers et al., 1991). In this paper we therefore investigate the relationship between the structure of business process models and the insight it gives in particular quantitative aspects of business processes. We classify structures as either extensional or intensional. An extensional business process model is a description as an integrated whole ( black box ). In such a model no reference is made to the internal structure and behaviour of the business process. It thus describes the business process from the perspective of its environment, which consists of its customers, suppliers, etc. An intensional business process model is a description as a system of interacting entities ( white box ). Such a model describes the internal structure and behaviour of the business process. It thus describes the business process from the perspective of its (internal) entities, resources, and processed items, such as employees, technological components, application form, respectively. Both the behaviour domain and the entity domain, as presented in the above section, can be structured this way. The structures of business process models defined in this section are summarised in Table 1. Local with respect to use-case local with respect to access-point extensional use-case-oriented access-point-oriented intensional workflow-oriented function-oriented Table 1. Classification of model structures. Extensional model structures In extensional model structures only interactions (and their results) between the business process and its environment and the way these are temporally related are presented. Use-case oriented structures represent either interactions (and results) of the business process with a single environmental entity (such as a customer) and the relations between them, or interactions (and results) of the business process with multiple external entities (e.g., customer and suppliers) and the relations between them. The use-case oriented model structure reveals a perspective on a complete flow of externally observable interactions with a well-defined beginning and end from a customer point of view. The name was originally proposed by Jacobson et al. (1995). Access-point-oriented structures represent either interactions (and results) that take place at a single access point (of a business entity) and the relations between them, or interactions (and results) that take place at multiple (remote) access points and the relations between them. The access-point-oriented model structure reveals a perspective on the business process in terms of (sequentially ordered) business entities (functional units). Intensional model structures In intensional model structures the internal structure and functioning of the business process are presented. Thus internal interactions and actions (and results), and relations between them are presented as well as the internal subentities to which these actions and interactions are assigned. Workflow-oriented structures represent the behaviour of a business process from the perspective of a single (logical or physical) item that flows through the process. A workflow refers to a complete chain of (inter)actions, being manipulations on the flowing item, to deliver a service or product (completed object) to an external entity, e.g. customer. A workflow-oriented structure is a natural implementation (refinement) of an (extensional) use-caseoriented structure.
Function-oriented structures represent the behaviour and its performing entities of a business process in terms of subsequent core business functions. This is in fact the classic structuring of organisations in functional departments with dedicated tasks and responsibilities for a complete functional area. A function-oriented structure is a natural implementation of an (extensional) access-pointoriented structure. The above-mentioned implementation relations between a given extensional perspective and related internal perspective can be applied iteratively. In this way, models at different abstraction levels can be derived. QUANTITATIVE BUSINESS PROCESS MEASURES A business process can be viewed from different timebased quantitative perspectives, resulting in different (but related) analysis and/or performance measures (Jonkers and Franken, 1996): Customer perspective: response time, the time between issuing a request (by a customer) and receiving the result; the response time is the sum of the processing time and queueing times (synchronisation losses). Examples in business processes are the time between the moment that a customer arrives at a counter and the moment of completion of the service, or the time between sending a letter and receiving an answer. Also in the supporting ITapplications the response time plays an important role; a well-known example is the time between a database query and the presentation of its results. Process perspective: completion time, the time required to complete one instance of a process (possibly involving multiple customers, orders, products, etc., as opposed to the response time, which is defined as the time to complete one request). In batch processing by means of an information system the completion time can be defined as the time required to finish a batch. An example of completion time of a batch process in businesses is the time needed to handle the incoming mail of a certain day. Product perspective: processing time, the amount of time that actual work is performed on the realisation of a certain product or result, i.e., the response time without waiting times (queueing times). The processing time can be orders of magnitude lower than the response time. An example of the processing time in businesses is the time needed to handle a certain claim (in comparison to the response time: the time between claim submission by a customer and the time of actual claim settling with the customer). In a computer system, an example of the processing time is the actual time that the CPU is busy. The complement of the processing time, the queueing time, can also be considered a performance measure associated with the product perspective. System perspective: throughput, the number of transactions or requests that a system completes per time unit (for example, the number of customers that is served per hour). Related to this is the maximum attainable throughput (also called the processing capacity, or in a more technically oriented context such as communication networks, the bandwidth), which depends on the number of available resources and their capacity. Resource perspective: utilisation, the percentage of the operational time that a resource is busy. On the one hand, the utilisation is a measure for the effectiveness with which a resource is used. On the other hand, a high utilisation can be an indication of the fact that the resource is a potential bottleneck, and that increasing that resource s capacity (or adding an extra resource) can lead to a relatively high performance improvement. In case of humans, the utilisation can be used as a more or less objective measure for the work stress. In telecommunication applications, a typical example of the utilisation is the network load. Different perspectives can lead to conflicting interests. For example, a higher throughput, which leads to a higher productivity and a better resource utilisation, generally results in a deterioration of the response time. In such a case overall costs based on resource utilisation could be minimal but this might lead to unsatisfied customers because of an overall higher response time. RELATING STRUCTURAL AND QUANTITATIVE PERSPECTIVES The different perspectives for time-based quantitative measures of business processes mainly correspond to the horizontal distinction between structures of business process models, i.e., between use-case-oriented and workflow-oriented on one side and access-point-oriented and function-oriented on the other side. The distinction between extensional and intensional structures is basically a matter of abstraction levels. Since the time-based quantitative measures can be applied at different abstraction levels, most of these measure perspectives can be applied to both extensional and intensional structures. An exception to this is the distinction between customer perspective and product perspective: it will be explained below that the former most closely relates to the (extensional) usecase oriented structure, while the latter needs a model with an (intensional) workflow-oriented structure. Relating the structural and quantitative perspectives from the previous sections, the following observations can be made: The customer response time is the time that is needed to complete a single use-case. Therefore, the customer perspective is useful for the analysis of a model with a use-case-oriented structure. To determine the processing time of a product associated with a use-case, the breakdown of the response time in resource access times and queueing times needs to be known. Because of this, the product perspective most closely corresponds to the (intensional) workflow-oriented structure. The throughput is defined from the point of view of either a single resource (business entity) or a system consisting of several resources (which in this context could also be considered as a single higher-level entity). In the former case the system perspective corre-
sponds to an access-point-oriented structure, in the latter case to a function-oriented structure. The utilisation is typically defined for a resource, and as such the resource perspective most closely matches the function-oriented structure. However, the utilisation of a whole system consisting of several resources can also be considered, in which case the access-pointoriented structure applies. The process perspective can be derived from both of the extensional structures, the use-case-oriented structure and the access-point-oriented structure. This will be made clear later in this section. Table 2 summarises the relations between performance measure perspectives and model structures. perspective use-caseoriented access-pt.- oriented workfloworiented functionoriented customer x process x x product x system x x resource x x Table 2. Relations between performance measure perspectives and model structures The different ways to structure a business process model provide different views on the same model. Models of the same process, but structured in a different way, are related and can, to a certain extent, be derived from each other. In a similar way, quantitative measures belonging to the different perspectives are related: they also provide different (quantitative) views on the same process. Many of the relations between the different performance measures, belonging to the different perspectives, follow from operational analysis (Denning and Buzen, 1978), which plays an important role in queueing theory. Operational analysis has a very general validity, i.e., very few assumptions are needed for its application. A central result used in operational analysis is (Little, 1961), which relates the population (number of jobs, e.g., customers or processes), throughput and residence time (e.g. response time or completion time) of a wide variety of systems. Generally speaking, relates the customer perspective, process perspective or product perspective with the system perspective, or resource perspective. Consider N parallel sequential processes ( use-cases ), u 1 u N, and M resources ( business functional areas ), r 1 r M, which together represent a business process. Usecase U i imposes a total demand/workload D ij on resource r j (see Figure 1 for N=M=3). Looking at the business process from the point of view of the use-cases results in a usecase-oriented or workflow-oriented structure, while the point of view of the resources results in an access-pointoriented or function-oriented structure. From the perspective of a customer (assuming that each use-case is associated with a different customer), the response time R i for use-case U i consists of the processing time P i and the total queueing time at resources Q i. Similarly, from the perspective of a resource, the total work time W j of resource r j (the time that the resource is operational ) consists of the resource load L j (the total time that the resource is serving customers) and idle time I j (the time that a resource is waiting for the arrival of customers). The processing time P i is equal to the sum of the workloads on each of the resources for use-case u i. Similarly, the load L j for resource r j is equal to the sum of the workloads for all processes on this resource. If we consider all use-cases together as one business process, the completion time C of that process is equal to the maximum of the response times of the separate use-cases or, alternatively, the maximum of the work times of the resources. The utilisation U j of resource r j can be defined as the ratio of the load of the resource and the completion time: U j = L j / C. If no distinction is made between the different (types of) use-cases, the throughput of the system follows from : X = N / C. Using the above relations between performance measures, different quantitative perspectives can be derived from each other, similarly to different structural perspectives. Figure 2 gives a schematic summary of the main relations between the performance measures. processing time + response time max completion time queueing time queue length throughput u 1 u 2 D 11 D 12 D 13 D 21 D 22 D 23 utilisation Figure 2. Summary of relations between performance measures. u 3 D 31 D 32 D 33 r 1 r 2 r 3 Figure 1.Parallel use-cases sharing resources ( u = use-cases, r = resources, D = demands). CONCLUSIONS AND DISCUSSION A model of a business process is made to gain insight in certain aspects of the process, either qualitative or quantitative. This is needed to, e.g., guide its improvement or redesign. Different model structures can be defined which make it possible to view a business process from different
perspectives. Similarly, different perspectives on quantitative aspects of a process can be defined. In this paper, we introduced a number of these perspectives, and identified the relations between the structural and the quantitative perspectives. The workflow-oriented and function-oriented structural perspectives, as presented in this paper, are similar to the material-oriented and machine-oriented perspectives which are often applied in the context of (simulation of) manufacturing processes. In the previous section we only considered parallel usecases which, apart from the shared use of resources, were independent. This is in general not the case in business practice. It is possible, however, to generalise the results for tasks with more complex synchronisation structures by using more complex business modelling patterns in terms of task graphs. More relations between performance measures than the above can be derived by using, in addition to operational analysis, other results from, e.g., queueing theory (see, e.g., (Jonkers, 1997)). However, this often requires more assumptions and therefore leads to less generally applicable results. and E. Kerckhoffs, eds., Simulation in Industry: Proceedings 8 th European Simulation Symposium, vol. I, Genoa, Italy, Oct., 175-179. Jonkers, H. 1997. The application of hybrid modelling techniques for business process performance analysis, in these proceedings. Little, J. 1961. A proof of the queueing formula L=λ W, Operations Research. 9, 383-387. Parnas, D.L. 1972. On the criteria to be used in decomposing systems into modules, Communications of the ACM, 15 (12), 1053-1058. Vissers, C.A.; G. Scollo; M. van Sinderen; and E. Brinksma. 1991. Specification styles in distributred systems design and verification, Theoretical Computer Science 89, 179-206. BIOGRAPHY Henry M. Franken received an M.Sc. and Ph.D. (with honours) in Electrical Engineering from the University of Twente. He now works as a member of the scientific staff of the Telematics Research Centre. His current research interest focuses on applying systems engineering principles to telematics and business process (re)design. He is currently manager of the Testbed Project. ACKNOWLEDGEMENT The research described in this paper has been carried out within the Testbed Project, which focuses on the creation and application of knowledge, methods and (software) tools for business process redesign in the service industry. The project is performed by the Dutch pension fund ABP, The Dutch Tax Department, ING Group, IBM and the Telematics Research Centre, and financially supported by the Dutch Ministry of Economic Affairs (Franken, 1996). We would like to thank Marc Lankhorst for his helpful comments on a previous version of this paper. REFERENCES Denning, P.J.; and J.P. Buzen. 1978. The operational analysis of queueing network models, ACM Computing Surveys, 10 (3), Sep., 225-261. Franken H.M. 1996. Testbed: a virtual test-environment for business processes, ACM Special interest group on office information systems, April. See also http://www.trc.nl. Franken H.M.; and Weger M.K. 1997. A modelling framework for capturing business process dynamics, Business change and re-engineering: Journal of business transformation, accepted for publication, Oct. 1997. Jacobson I.; M. Ericsson; and A. Jacobson. 1995. The object Advantage, Business Process Reengineering with object technology, ACM Books. Jonkers, H.; and H.M. Franken. 1996. Quantitative modelling and analysis of business processes, in A. Bruzzone