business process modeling - from informal to formal ... - CiteSeerX

BUSINESS PROCESS MODELING - FROM INFORMAL TO FORMAL PROCESS REPRESENTATIONS Petra Elgass, Helmut Krcmar Universität Hohenheim Lehrstuhl für Wirtschaftsinformatik D 70593 Stuttgart Germany Andreas Oberweis Universität Karlsruhe Institut für Angewandte Informatik und Formale Beschreibungsverfahren D 76128 Karlsruhe Germany

Abstract In this paper we propose a concept for the stepwise development of formal business process models, starting from a semi-formal process model represented by customer/supplier-relationship diagrams. These diagrams focus on communication features of business processes and stress aspects like customers' requirements and satisfaction. They are especially useful at the early stages of process modeling, when the process is to be structured. The formal process model on the other hand is based on high-level Petri nets, which allow an integrated, procedural description of object and behaviour related aspects. Additionally, business rules can be declaratively expressed in Petri nets. The formal process model is directly executable. It can be evaluated by means of simulation and formal analysis and can also serve as basis for later implementation.

1. Introduction and Motivation Continuous transformations of the world market system, competitive pressure, shorter product life cycles, increasing customer demands as well as dramatic technological progress are affecting businesses during the 1990s. These factors require a stronger market and customer orientation of the enterprises. The restructuring of the enterprises' organization with respect to the core business processes and the innovation or reengineering of business processes [2, 8] are proposed as the key to success. However, some studies [7] show that disproportionally many projects aiming at

restructuring business processes fail due to unsatisfying methodological planning, lack of team orientation and insufficient computer support. New concepts like "Groupware", "CSCW" and "CATeam" [11] are therefore propagated in combination with a process view of business. These concepts represent an application field for information and communication technology which does not only improve individual productivity but which directly supports and improves the communication and cooperation of people working together in teams [12]. In this paper we survey a planning method and a concept for incremental business process modeling, leading stepwisely from semi-formal to formal process representations. The goal is to fill the gap between existing diagram notations in the area of business process modeling and formal languages in the area of information system behaviour specification. The practical application is briefly demonstrated with a small example. The paper results from the co-operation of the two research projects CUVIMA (Computer Support for Distributed Information Management Tasks) at the University of Hohenheim and INCOME/STAR (Cooperative Development of Distributed Information Systems) at the University of Karlsruhe.1 Both projects are working in the area of business process modeling since 1992. In the sub-project PROPLAN (Process Planning) of the CUVIMA project a tool for the computer supported, team oriented business process planning has been designed and partially implemented. The goal of PROPLAN was to develop a system, which methodologically supports the early planning of arbitrary business processes and provides a multi-user computer based planning environment [4, 5]. The INCOME/STAR project [15] mainly focuses on the formal modeling of business processes where the process models are later to be used for the development of (distributed) information or workflow systems. A formal representation language is provided which integrates high-level Petri nets with semantic data modeling concepts [9]. Simulation concepts are suggested to validate process models and a corresponding simulator is provided [14]. Both projects complement each other since PROPLAN especially supports informal and semi-formal notations whereas INCOME/STAR supports formal notations for business process modeling. This paper is structured as follows: in Section 2, an overview of the stepwise development of process models is surveyed, starting from semi-formal customer/supplier-relationship diagrams and finally leading to formal representations. Section 3 shows an example application and Section 4 concludes the paper with a brief summary.

1

Both projects are partially supported by the Deutsche Forschungsgemeinschaft DFG in the research program "Verteilte DV-Systeme in der Betriebswirtschaft" ("Distributed Information Systems in Business and Management").

2. Incremental Modeling of Business Processes The modeling of business processes is a complex task which usually can not be done in one single step. Instead, an incremental development process consisting of three different steps is proposed here. The development leads from semi-formal communication models via semi-formal channel/agency nets to procedural predicate/transition nets [5]. The determination of the process structure on the one hand is communication oriented, the validation of the process model on the other hand is organized procedurally. In the first step a semi-formal process model, given as a set of customer/supplierrelationship diagrams [18, 3], is developed. The underlying approach is based on speech act theory [19]. It is appropriate for the early structuring phase of processes since it focuses on the coordination of communicating elements of a system instead of stressing procedural aspects of processes as done in most classical approaches [18]. It allows to build the customer’s perspective (e.g. aspects like requirements and satisfaction) into the process design (as postulated by [2]). Furthermore according to [18] the communication based approach leads to more definite process models than classical approaches where activities are collected and logically grouped together. In classical approaches this usually leads to different process models in different planning teams. The central idea of the customer/supplier-relationship diagram is to consider a process as a sequence of customer/supplier-relationships, where the customer requests a service from the supplier as producer of the service by negotiation about the conditions of satisfaction (business rules). The initiating customer-supplier relationship of a business process usually is the relationship between an external customer and the responsive enterprise representative. The business rules either define admissible activity performances by the agents or define certain boundaries. Business rules may depend on ethical or cultural norms and also on legal aspects or on enterprise policies [10]. Inside the complete chain, the roles "customer" and "supplier" may change, which means that a supplier may become the customer of a succeeding relationship and a customer may be supplier of a preceding relationship [18]. The conversation is either initiated by a request of a customer or by the offer of the supplier. The course of conversation between customer and supplier is described in a so-called communication protocol consisting of the four phases "Opening phase", "Negotiation phase", "Performance phase" and "Assessment phase" with specific speech acts defined [18, 3]. Each communication protocol is a complete list of all relevant interactions between a customer and a supplier. During the opening phase a supplier offers a service or a customer requests a service. In the negotiation phase the customer and the supplier negotiate about the conditions of satisfaction. In the third phase the customer fulfills the service agreed upon in the negotiation phase with the customer. Finally the customer has to comment on the produced services.

For the graphical representation a semi-formal diagram technique is used (see Figure 1 for an example).2 The basic syntactic unit of the notation is a pair of circles which are connected by a directed arc (Figure 1 shows 7 basic units). The circle on the left hand side represents the customer, the circle on the right hand side represents the supplier. The big arc between customer and supplier represents the communication between customer and supplier, the small arcs within the big arc represent the different communication phases. The initiation phase is represented by a small upper left arrow, the negotiation phase by the small upper right arrow, the performance phase by a small lower right arrow and the examination phase by a small lower left arrow. The center of the big arc is annotated by the name of the basic unit, which represents the content of the customer supplier relationship. The explicit representation of the communication phases allows to assign refinements to the respective phases and serves furthermore as an intermediate representation to transform the model semi-automatically into Petri net notation. In the next step the semi-formal process model is transformed into a Petri net. Petri nets [16] are a graphical formalism for the procedural description of distributed system behaviour. They have a mathematical foundation and can be analyzed e.g. with respect to liveness, absence of deadlocks, restrictedness and existence of cycles. Petri nets allow to describe sequential activities as well as concurrent activities and mutual exclusion of activities. There exist different kinds of Petri nets, however we are especially interested in channel/agency nets [17] and predicate/transition nets [6]. Channel/agency nets are nets where the net components are informally inscribed by textual annotations to describe the meaning. This type of nets has a similar expressibility as dataflow diagrams. We use channel/agency nets as an intermediate representation from which formal predicate/transition nets are derived. Predicate/transition nets are high level nets, which are strongly related to relational databases and which allow to model procedural aspects as well as object related aspects of business processes. To the places ("predicates") in a predicate/transition net, relations of the respective types may be assigned as marking. Transitions represent classes of operations on their input and output relations. A transition is enabled (i.e. it may fire) if in each input place certain tuples exist which are specified by the arc inscriptions and if additionally in the output places certain tuples do not exist. When a transition fires, the respective tuples are removed from its input places and are inserted into its output places. Exceptional situations, integrity rules and business rules can be modeled by so-called fact transitions [6]. An enabled fact transition indicates that an exception has occurred or that a rule has been violated. An enabled fact transition does not fire itself, however it functions as a trigger for the execution of an exception handling mechanism. This exception handling mechanism can be separately modeled in a new net. Hence the description of regular process behaviour is not disturbed by the description of irregular behaviour [1]. Due to the formal semantics of the transition occurrence rule, predicate/transition nets are directly executable and can therefore be used for simulation and prototyping without further implementation efforts. 2

Another graphical representation is introduced in [14].

3. Example "Credit approval process" Credit approval is a typical service of a bank and is part of the money lending business. A credit is a loan for private households financing consumer goods. The credit has to be redeemed in monthly installments. The development of the communication diagram described above [5] starts with the definition of the customer who initiates the communication. In the example the customer is the client of the bank asking for a credit. After the definition of the customer the next step to perform is the definition of the responsible supplier. In the example the supplier is the clerk of the bank charged with the advisory service to customers. Subsequently the first communication protocol representing the communication between the client and the clerk has to be specified. After completing these three steps the first basic unit ("main unit") of the example is defined and it has to be refined gradually in the next steps. The refinement in the example is demonstrated by the negotiation phase and the performance phase of the main unit (see Figure 1). The other phases are not considered. The refinement of the negotiation phase provides a decomposition in the units "document verification and completion" and "advisory service to customers". Strictly speaking the negotiation phase starts with the clerk checking the customer documents related to his credibility. If necessary the clerk calls the customer upon completion of the documents. After checking all the documents the clerk and the customer negotiate about the credit. They try to agree on the conditions of the contract. If they do not reach an agreement the clerk may recommend the customer another kind of financing, else the performance phase starts. The refinement of the performance phase provides a decomposition into the units "type of the installment payment", "contract registration and customer signature", "agreement with the office manager" and "delivery and administration". At the beginning of the performance phase the clerk and the customer agreed upon the conditions of the credit contract. Now in the performance phase they have to agree upon the conditions of the installment payment. Therefore the clerk has to perform some further analysis like legitimization check. After the client and the clerk have established the payment conditions the next steps include the registration of the contract and the signature of the customer. Subsequently the clerk has to agree upon the credit contract with his office manager and then (s)he is allowed to initiate further administration steps like the delivery of the contract. After the process is completely described with communication diagrams and communication protocols the transformation into the corresponding channel/agency net starts. Therefore the first basic unit will be transformed phase by phase into the corresponding channel/agency net-fragments. These fragments will be refined analogously in the next steps. Finally the fragments will be composed to a complete net. Subsequently the channel/agency net will be transformed gradually into a practicable predicate/transition net by formalizing transitions and by adding further

information such as object structures to the places (see Figure 2, showing one predicate/transition net-fragment).3

Figure 1: Communication Diagram - "Credit Approval" The transition "START Opening Phase" is activated if there is at least one clerk able to serve a client. Then the transition removes one tuple from the predicate "client" and one tuple from the predicate "clerk", that is the clerk and the client are removed from the input predicates. The tuples are joined with each other and then a client-clerktuple is inserted into the predicate "Performance Phase 1" and a client-tuple is inserted in the predicate "served client". The transition "customer applies" removes a tuple from the predicate "served clients". The additional information can be taken from the credit approval instructions.

3

The object structures needed for the development of the predicate/transition net have to be derived from existing (semantic) data models. If there aren´t any existing data models available they have to be developed.

Figure 2: Predicate/Transition Net-Fragment - "Opening Phase"

4. Outlook The described concept should reasonably fill the gap between the informal process descriptions on the one hand and the exact mathematical representation and simulation methods on the other hand. Thus the kernel of each process planning - the process modeling - is methodically determined. However it is necessary to search for an efficient integration of the strategic planning and the informal process planning side as well as for an integration of the process controlling and the formal process planning side. At present a practical validation of the described concepts is conducted by means of case studies.

References [1]

[2]

Borgida A.: Language features for flexible handling of exceptions in information systems, IEEE Transactions on Database Systems, Vol. 10, No. 4, 1985, pp. 565-603. Davenport T. H.: Process Innovation. Boston, Harvard Business School Press, 1993.

[3] [4] [5] [6]

[7] [8] [9]

[10] [11]

[12]

[13]

[14]

[15]

[16] [17] [18] [19]

Dunham R.: Business Design Technology - Software Development for Customer Satisfaction. IEEE Proceedings 1991, pp. 792-798. Elgass P., Krcmar H.: Computergestützte Geschäftsprozeßplanung. Information Management, 1/93, pp. 42-49 (in German). Elgass P.: Prozeßmodellierung in PROPLAN. Arbeitspapier des Lehrstuhls für Wirtschaftsinformatik, Universität Hohenheim, 1994 (in German). Genrich H. J.: Predicate/transition nets, in: W. Brauer, W. Reisig, G. Rozenberg (edts.): Petri Nets: Central Models and Their Properties, Advances in Petri Nets 1986, LNCS 254, Springer-Verlag, 1987, pp. 207247. Hammer M., Champy J.: Reengineering the Corporation - A Manifesto for Business Revolution. Harper Business, 1993. Harrington H. J.: Business Process Improvement. New York, McCraw-Hill Inc., 1993. Jaeschke P., Oberweis A., Stucky W.: Deriving complex structured object types for business process modeling, in: P. Loucopoulos (Ed.): Proc. 13th International Conference on the Entity-Relationship Approach ER94, Business Modelling and Re-Engineering, Manchester/UK, Springer-Verlag, December 1994, pp. 28-45. Knolmayer G., Herbst H.: Business Rules. Wirtschaftsinformatik, 35 (1993) 4, pp. 386-390 (in German). Krcmar H.: Computerunterstützung für die Gruppenarbeit - Zum Stand der Computer Supported Cooperative Work Forschung. Wirtschaftsinformatik, 34, 4 (August 1992), pp. 425-437 (in German). Krcmar, H.; Schwarzer, B.: Prozeßorientierte Unternehmensmodellierung Gründe, Anforderungen an Werkzeuge und Folgen für die Organisation. In: Scheer (Hrsg.): Prozeßorientierte Unternehmensmodellierung. Schriften zur Unternehmensführung. Wiesbaden, Gabler Verlag, 1994. (in German). Medina-Mora R., Winograd T., Flores R., Flores F.: The action workflow approach to workflow management technology. In: CSCW Proceedings November 1992. Mochel T., Oberweis A., Sänger V.: INCOME/STAR: The Petri net simulation concepts, Systems Analysis - Modeling - Simulation, Journal of Modeling and Simulation in Systems Analysis, Vol. 13, 1993, pp. 21-36. Oberweis A., Scherrer G., Stucky W.: INCOME/STAR: Methodology and Tools for the Development of Distributed Information Systems, Information Systems, 1994, Vol.19, No.8, pp. 641-658. Reisig W.: Petri Nets, EATCS Monographs on Theoretical Computer Science, Springer-Verlag, 1985. Reisig W.: A Primer in Petri Net Design, Springer-Verlag, 1992. Scherr A. L.: A new approach to business processes. IBM Systems Journal, 32(1) 1993, pp. 80-98. Winograd T.: A language / action perspective on the design of cooperative work. In: Proceedings of the Second European Conference on ComputerSupported Cooperative Work, September 25-27, Amsterdam, 1991.