A Conceptual Framework for Intention Driven Flexible Workflow Modeling

Transcription

1 A Conceptual Framework for Intention Driven Flexible Workflow Modeling Selmin Nurcan 1, 2 1 Université Paris 1 - Panthéon - Sorbonne Centre de Recherche en Informatique 90, rue de Tolbiac Paris cedex 13 France 2 IAE de Paris (Graduate Business School of Sorbonne) Université Paris 1 - Panthéon - Sorbonne 21, rue Broca Paris France nurcan@univ-paris1.fr Abstract. Traditional information system development was crystallized the vertical division of the enterprise activities and the construction of information and application islands. During the early 90 s, workflow technologies were the only ones to offer a transversal integration capacity to the enterprise applications. However, the formalisms developed for workflow specifications were and still largely are- almost systematically activity oriented. Consequently, the resulting process definitions have the advantage to be easily transformable in executable code but the disadvantage of being prescriptive and rigid. Recent work underlines the needs in term of flexible and adaptive workflows, whose execution can evolve according to situations that cannot always be prescribed. This paper proposes a conceptual framework for flexible workflow modeling. 1 Introduction Over the last twenty years, rapid market changes have led to a business environment that is constantly evolving. In all management challenges, information systems (IS) should be continuously adapted to changing business practices and needs. This can be achieved by developing process-centric solutions. The paradigm of Business Process Management stresses the importance of integrating entire processes rather than simply integrating data or applications [3], [14]. Since the beginning of the application of the Business Process Reengineering (BPR) [5] as a management method for transforming organizations, Workflow Management Systems (WFMS) have often been positioned as an appropriate technological solution to satisfy the objectives set by this management method. Workflow technologies allow integrating process islands at a high level so that they can collaboratively provide business solutions that each individual application is unable to provide. However commercial workflow solutions offer only limited evolution facilities. In this paper, we propose to use the MAP model, for modeling flexible and adaptive workflow applications being intra or inter organizations. The objective of the

2 research in progress is to measure the capacity of the MAP model - and more generally of the objective oriented formalisms- to represent business processes of different natures using conceptual models. The paper is organized as follows: Section 2 presents a non exhaustive list of requirements for an easier evolution of business processes and their support systems. Section 3 discusses some limits of the current workflow technologies which offer an automated support to the enactment of business processes. Section 4 proposes a conceptual framework for flexible workflow modeling based on the intentional modeling of business processes. 2 Findings and some requirements In a competitive and evolving environment only the organizations which can react quickly to environment demands can survive. That capacity of quick reaction is often due to the ability of handling the support systems in favor of the business evolution requirements. In order to take business through a well managed change process, the organization needs to strike a balance between the technical and the social organizational levels; i.e. there must be a consolidation of the diversity of perspectives that stakeholders, managers, and IS engineers have about the business and the way organization must change. Our experience of Business Process Modeling and Business Process Reengineering and the design of the supporting systems led us to the following findings: 1. The amount of detail to be handled in analyzing and improving business processes makes it difficult to master. 2. Approaches and models offering the ability to describe, initially, the invariants of the organization in terms of objectives and strategies before specifying the manner of making them operational, in a particular organizational context, facilitate to mastering these difficulties. 3. A clear representation of the business objectives simplifies also the comprehension of the organizational change and the evolution of the business model. 4. Using models to represent the enterprise allows a more coherent and complete description of business objectives, processes, actors and objects than a textual description. These models are useful because they allow (i) to improve the knowledge (understanding) about the enterprise, (ii) to reason on alternative solutions and diverging points of view, and (iii) to reach an agreement. 5. Business processes can be roughly classified into two categories depending on their nature. The first concerns well-defined and -often- repetitive processes having important coordination and automation needs. The second category concerns ill-defined processes. The essential preoccupation with the latter is the information and knowledge sharing between the actors implied in the processes more than the coordination of their tasks. 6. The importance of establishing and preserving the best fit between organization needs (whys) and system functionalities (how), i.e. between process models and IS specifications is commonly accepted by stakeholders.

3 Enterprise modeling frameworks stress the necessity to represent and structure enterprise knowledge taking into account different facets of the organizational domain in order to develop IS and IT architectures that enterprises need. These facets include operational (information systems), organizational (business processes, actors, roles, flow of information etc), and teleological (purposes) considerations [6], [9], [11], [13]. Our vision of the organization is structured according to three layers of concern [2], [7], [8]. The objectives of the organization are achieved by implementing the enterprise processes whose are themselves supported by the enterprise information systems. The two first layers focus on intentional and organizational aspects of the enterprise, i.e. the business objectives and how these are achieved through the cooperation of enterprise actors. The third one focuses on system aspects i.e., application components that will support the enterprise, its processes and its actors. The information and communication becoming one of the basic components in the modern organizations, the contribution of the information systems to the realization of the business processes and consequently to the objectives of the company is of prime importance. A change in one of these facets of the organization implies multiple impacts on the two other facets. In other words, it seems difficult to consider an organizational change without any impact on the IS or an evolution of the IS which does not call into question the processes or even the objectives of the organization. 3 Automated support for defining and executing business processes The Workflow Management Coalition defined the workflow as The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules [16]. Several classifications have been proposed for workflow applications. The commonly used divides workflows into four classes, depending on the nature of the processes they support and the value these processes have for the enterprise [1]: (i) Production workflows involve repetitive and predictable business processes. They implement the core processes of the enterprise and incorporate access to various information systems by the means of workflow activities; (ii) Administrative workflows involve repetitive, predictable processes with simple task coordination rules and do not concern the core processes of the enterprise; (iii) Ad hoc workflows have no predefined structure. Workflow support is limited to the provision of communication mechanisms to route case data between workers and possibly some support for logging and state tracking. Ad hoc workflows tend to be created to deal with exceptions, or where there is no set pattern for moving information among people. The coordination of the activities is controlled by human participants; (iv) Collaborative workflows include iterative tasks over the same step until some form of agreement has been made. Most of the co-ordination is done by human participants. In terms of automated support for executing business process models, commercial WFMS and the underlying control flow models are useful for well-defined and repeti-

4 tive processes (production and administrative). They cannot be used for ill-defined business processes (ad hoc and collaborative) neither to deal with the dynamic modification of well-defined ones. Nevertheless, users ask more and more for adaptive tools to control the execution of the business processes and for flexible models to be used in their definition [4], [15]. The flexibility by adaptation (a posteriori) offers the adaptation of the process definition and/or its instances. Approaches which offer this kind of flexibility can not anticipate the capacity to change of the business process during the built-time. The flexibility by selection (a priori) is based on modeling formalisms which offer the capacity to take into account the environmental change without any evolution of the process definition. This means that the process definition should be specified in a sufficiently flexible way so that it will yield under the influence of the environment without breaking. 4 A conceptual framework for modeling flexible business processes For many organizations, well-defined and ill-defined processes coexist and must be handled in the final business model. The integration aims to make the relationships between the different types of processes transparent. This requires homogeneity and coherence of handled concepts and a common technology or at least interoperable ones for their enactment. In order to deal with a wide range of business processes, we propose a conceptual modeling framework offering at one hand the rigor necessary for modeling well-defined business processes, and at the other hand, the flexibility and adaptability required for ill-defined business processes. 4.1 Intentional view of the enterprise: the MAP model We apply the Map model for representing enterprise objectives and the underlying business processes. According to [12], a map is a process model in which a nondeterministic ordering of intentions and strategies has been included. As shown in Figure 1, a business map is a labeled directed graph with intentions as nodes and strategies as edges between intentions. It consists of a number of sections each of which is a triplet < source intention I i, target intention I j, S ij >. A business intention expresses what the enterprise wants to achieve. It defines stable characteristics of the enterprise (disregarding the considerations about who, when and where) that any organization choice must respect. A is an approach, a manner to achieve an intention. The, as part of the triplet <I i, I j, S ij > characterizes the flow from I i to I j and the way I j can be achieved. The specific manner in which an intention can be achieved is captured in a section of the map. The business map contains a finite number of paths from Start to Stop, each of them prescribing a way to develop the product (for instance a service to be delivered for a customer), i.e. each of them is a Business Process Model.

5 By partial filtering The business map: Manage loans Start Direct bank C2 by notification of C9 cloture of the offer Agent C1 Handle the contact material loan request flexible coverings with fixed term revisable rate Stop fixed rate C4 C5 by normal cloture of the loan C3 Handle C7 contract C6 the loan by dispute renegotiation C8 Start Without filtering C1.2 SSG1 C1.1 Delegation I1: Register C1.4 I2: Monitor Make the material loan C1.5 loan stock offer request ISG1 Financial evalution C1.6 C1.7 Offer limited Requirement on the confirmation Risk in time of the customer C1.3 Stop The refined map: C1: <Start, Handle the loan request, Agent contact > Global Business Map Intentional view of the enterprise Refined Business Maps Agent s assistant Event: Confirmation by customer PC_ C1.7 Filter the response PC_C1.1 Agent Organisational and operational view of the enterprise Event: Loan request by customer A4 Register the loan request A2 A4 Agent s assistant Sign the To file the contract Customer loan offer as refused Start Agent the loan Event: Timout To store the Software loan offer as assistant aborted PC_ C1.6 Agent D2 PC_ C1.4 A2 A3 A2 to prepare the offer D1 C C to validate Loan the offer manager D1 to draft the offer Agent s assistant to prepare the financial evaluation Financial responsible PC_ C1.5 to evaluate Loan conditions manager D1 Business Process Chunks PC_ C1.3 To write the letter Agent s ofrefusal assistant A2 : receivability condition is filled A3: delegation condition is filled A4: financial evaluation is required D1: loan is accepted D2: request to reconsider the loan conditions C: loan was accepted by the agent Fig. 1. Business Maps and Process Chunks Because the next intention and to achieve it are selected dynamically, guidelines that make available all choices open to handle a given situation are of great importance. The map has associated guidelines, namely one Intention Selection Guideline per node I i, except for Stop, one Strategy Selection Guideline per node pair <I i,i j > and one Intention Achievement Guideline per section <I i,i j, S ij >. Given an intention I i, an Intention Selection Guideline (ISG), identifies the set of intentions {I j } that can be achieved in the next step. Given two Intentions I i, I j and a set of possible strategies S ij1, S ij2,..s ijn applicable to I j, the role of the Strategy Selection Guideline (SSG) is to guide the selection of an S ijk. The execution of each map section is supported by an IAG that provides an operational or an intentional means to fulfill a business intention. For the former, the IAG is operationalized by a business process chunk which is a process knowledge speci-

6 fied in the operational level (who, when, where and how). In this case, the IAG describe the knowledge related to the production/operation aspects of the organization. For the latter, the IAG is defined as a refined business map. The purpose of the enterprise objectives layer is to provide the intentional definition of business processes. The refined business maps should then be operationalized in the enterprise processes layer to capture organizational and operational properties of the business processes. 4.2 Organizational and operational views of the enterprise In the domain of the enterprise modeling, it is a common way to consider that operationalizable business intentions are implemented using business processes (BP). In our framework, we consider that the business process chunk operationalizes a business map section (which cannot be refined any more). Accordingly, we have to describe the roles, which will act in order to achieve the business intention according to the associated to the section; the actors holding these roles; the activities they will perform and the pre-order of these activities when the BP is well-structured. A business process chunk is triggered by an event and its execution generates events. Organizations cannot only be described in terms of well-defined processes. An illstructured BP can be defined as a chunk grouping BP chunks of any type. Finally, an ad-hoc process, which cannot be represented in terms of flow of activities, can be specified as a non-structured group activity performed by a group role; triggered by an event; generating events; using and producing business objects. The representation formalisms used at this level can be classical activity-oriented process models for the production (or even the administrative) workflows, productoriented process models for the collaborative or the ad-hoc workflows. In [10], we applied the cooperative process meta-model in order to represent business process chunks as hierarchies of contexts called trees (see NATURE approach). The purpose of the MAP model is then to define the level of integration for the forest of trees, in other words of the islands of business process chunks. 4.3 Example We wish to model the loan handling process in a bank. When a customer applies for a loan, the clerk in charge of his account sets up a file with the data corresponding to the request (loan amount, rate, account situation...). When the request is registered, it could be evaluated, either by the loan service clerk himself, or by the financial department and then the loan manager, in order to accept or to refuse the loan request. In the second case, the financial department performs a financial evaluation (task carried out synchronously by a group of experts), and then the loan manager in the light of the suggestions made by them examines the request. The loan manager should validate the study of the request by the loan service clerk. He has the possibility either to accept the loan offer, to ask the loan service clerk to review it, or to ask a complete re-evaluation of the loan request to the financial department. When the decision is favorable, the clerk s assistant sends a proposal of loan stipulating the amount, the

7 duration and the refunding modalities of the loan to the customer. When the decision is unfavorable, the same person sends a refusal letter. The customer has to sign the contract, in the authorized time, for going on the loan handling, otherwise the offer is cancelled. The global business map, shown in Figure 1 includes two high-level business intentions and nine strategies. As shown in this business map, a loan can be handled following different ways, for instance <C1, C5, C7> or <C1, C4, C6, C8>. The map section C1 is defined as a local map shown in the same figure. The execution of each section of this local map (except C1.2) is supported by an IAG operationalized by a BP chunk surrounded in dotted line (lower part of Figure 1). A BP chunk can be an individual activity performed by an individual role held by an actor. For instance, PC_C1.1 is performed by a human actor, which holds the role loan service clerk, whereas a software assistant performs PC-C1.6. A business process chunk can also be compound of other chunks, the composition being described using the precedence (conditional or not) links. This is the case for the business process chunks PC_C1.4 and PC_C1.5. Using an intention-driven modeling, it is easier to highlight the business intentions, and strategies. The Map model provides a priori flexibility since the navigation will be dynamically performed during the execution. 5 Conclusion A major advantage of the proposed approach is the systematic way of dealing with enterprise modeling and organizational transformation in terms of knowledge modeling used with a process guidance framework. The intention driven modeling provides basis for understanding the enterprise objectives, the alternative way-of-workings and the reasons of change. The intentional view of the business represents the enterprise from the point of view of its objectives disregarding the considerations of the operational level. In fact, this view should be completed with the realization conditions of these objectives, i.e. taking in consideration the organizational and operational choices in order to specify the requirements on the IT systems needed by this enterprise. The Map model is intention-oriented; the business process model is described in term of intentions to be achieved and strategies to be followed. A business map constitutes a strategic business plan: it expresses the missions with regard to the business intentions they should achieve and the possible strategies. The Map model is also decision-oriented thanks to the navigation guidelines and the associated choice criteria. The purpose of the MAP model is to define the level of integration for the islands of business process chunks. The model offers the advantage of being able to represent in the same business process model the well-structured business process chunks as well as ill-structured or ad hoc ones.

8 References 1. Alonso, G., Agrawal, D., El Abbadi, A. and Mohan, C. (1997) "Functionality and Limitations of Current Workflow Management Systems" IEEE Expert, Vol12, No. 5, Sept/Oct Barrios, J. and Nurcan, S. (2004) "Model Driven Architectures for Enterprise Information Systems" To be published in the Proceedings of the 16th Conference on Advanced Information Systems Engineering, (CAISE'04), Springer Verlag (pub), Burlton, R. T. (2001) Business Process Management- Profiting from process, SAMS Publishing, Casati, F., Ceri, S., Pernici, B. and Pozzi, G. (1996) Workflow Evolution. Proceedings of the 15th ER'96 international Conference, Oct 7-10, Cottbus, Germany, Springer Verlag Lecture Notes in Computer Science, Hammer M. and Champy J. (1993) Reengineering the Corporation: a Manifesto for Business Revolution, Harper Collins Publishers, Inc., New York. 6. Loucopoulos, P., Kavakli, V., Prekas, N., Dimitromanolaki, I. Yilmazturk, N., Rolland, C., Grosz, G., Nurcan, S., Beis, D., and Vgontzas, G. (1998) The ELEKTRA project: Enterprise Knowledge Modeling for change in the distribution unit of Public Power Corporation. IMACS-CSC 98, Athens, Greece, Nurcan, S. (2004) Business Process Modeling for developing Process Oriented IT Systems, The "Business Process Management Tools and Technologies" track of the 2004 IRMA International Conference- May 23-26, 2004, New Orleans, USA. 8. Nurcan, S. and Rolland, C. (2003) A multi-method for defining the organizational change, Information and Software Technology, Elsevier. 45:2(2003), p Nurcan, S., Barrios, J., Grosz, G. and Rolland, C. (1999) Change process modelling using the EKD - Change Management Method. 7th European Conference on Information Systems, ECIS'99, Copenhagen, Denmark, June 23-25, Nurcan, S., Rolland, C. (1997) Meta-modeling for cooperative processes, in: Proceedings of the 7th European-Japanese Conference on Information Modelling and Knowledge Bases, May 27-30, Toulouse, France (1997). 11. Papazoglou, M.P., van den Heuvel W.-J. (2000) Configurable business objects for building evolving enterprise models and applications, Business Process Management, Van de Aast W, Desel J., Oberweis A. (eds), Springer. 12. Rolland, C., Prakash, N. and Benjamen A. (1999) A Multi-Model View of Process Modelling, Requirements Engineering Journal, 4:4, Scheer, A.-W., Nüttgens, M. (2000) ARIS architecture and reference models for business process management, Business Process Management, Van de Aast W, Desel J., Oberweis A. (eds), Springer. 14. Van der Aalst, W., Desel, J. and Oberweis, A. (eds) (2000) Business Process Management Models, techniques and empirical studies, Springer-Verlag. 15. Weske, M. (2001) Formal Foundation and Conceptual Design of Dynamic Adaptations in a Workflow Management System. HICSS 2001 management 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 7, January 03-06, WfMC-TC-1003 v1.1 (1995), V 1.1. Workflow Reference Model, January 1995.