A Conceptual Framework for Intention Driven Flexible
Workflow Modeling
Selmin Nurcan1, 2
1Université Paris 1 - Panthéon - Sorbonne
Centre de Recherche en Informatique 90, rue de Tolbiac 75634 Paris cedex 13 France
2 IAE de Paris (Graduate Business School of Sorbonne)
Université Paris 1 - Panthéon - Sorbonne 21, rue Broca 75005 Paris France
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 applica-tions. 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 sim-ply 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 Man-agement Systems (WFMS) have often been positioned as an appropriate technologi-cal solution to satisfy the objectives set by this management method. Workflow tech-nologies allow integrating process islands at a high level so that they can collabora-tively 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 adap-tive workflow applications being intra or inter organizations. The objecadap-tive of the
research in progress is to measure the capacity of the MAP model - and more gener-ally of the objective oriented formalisms- to represent business processes of different natures using conceptual models. The paper is organized as follows: Section 2 pre-sents a non exhaustive list of requirements for an easier evolution of business proc-esses and their support systems. Section 3 discusses some limits of the current work-flow technologies which offer an automated support to the enactment of business processes. Section 4 proposes a conceptual framework for flexible workflow model-ing based on the intentional modelmodel-ing 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 organiza-tional 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 or-ganization must change.
Our experience of Business Process Modeling and Business Process Reengineer-ing and the design of the supportReengineer-ing systems led us to the followReengineer-ing findReengineer-ings:
1. The amount of detail to be handled in analyzing and improving business proc-esses 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, fa-cilitate to mastering these difficulties.
3. A clear representation of the business objectives simplifies also the comprehen-sion 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 so-lutions 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 con-cerns ill-defined processes. The essential preoccupation with the latter is the in-formation 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 organiza-tion needs (whys) and system funcorganiza-tionalities (how), i.e. between process models
Enterprise modeling frameworks stress the necessity to represent and structure en-terprise 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 co-operation of enterprise actors. The third one focuses on system aspects i.e., applica-tion components that will support the enterprise, its processes and its actors. The information and communication strategy becoming one of the basic components in the modern organizations, the contribution of the information systems to the realiza-tion 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 multi-ple 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 in-formation 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 pre-defined structure. Workflow support is limited to the provision of communication mechanisms to route case data between workers and possibly some support for log-ging 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 coordina-tion 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-tive processes (production and administrarepeti-tive). They cannot be used for ill-defined business processes (ad hoc and collaborative) neither to deal with the dynamic modi-fication 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 for-malisms which offer the capacity to take into account the environmental change with-out 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 influ-ence 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 non-deterministic 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 Ii, target intention Ij, strategy Sij>. A business
intention expresses what the enterprise wants to achieve. It defines stable characteris-tics of the enterprise (disregarding the considerations about who, when and where) that any organization choice must respect. A strategy is an approach, a manner to achieve an intention. The strategy, as part of the triplet <Ii, Ij , Sij> characterizes the flow from Ii to Ij and the way Ij can be achieved. The specific manner in which an intention can be achieved is captured in a section of the map. The business map con-tains 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 BusinessProcess Model.
Global Business Map
Refined Business Maps material Start Agent contact strategy Handle the loan C3 Handle the loan request Direct bank strategy C2 fixed rate strategy revisable rate strategy
flexible coverings with fixed term strategy C4 C5 contract renegotiation strategy Stop by normal cloture of the loan C6 C7 C8 by dispute by notification of cloture of the offer C9
The business map: Manage loans
C1 Intentional view of the enterprise C1.1 material partial Without Stop Monitor stock Start loan request By filtering filtering Stop Financial evalution strategy
I2: Make the loan offer Delegation strategy Risk strategy Offer limited in time strategy
Requirement on the confirmation of the customer strategy
C1.2
C1.3 C1.4 C1.5
C1.6 C1.7
The refined map: C1: <Start, Handle the loan request, Agent contact strategy> ISG1 SSG1 I1: Register Organisational and operational view of the enterprise To file the loan offer as refused Sign the contract Start the loan Filter the response Agent’s assistant Agent’s assistant Agent Customer PC_ C1.7
Event: Confirmation by customer
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
Business Process Chunks Financial responsible Loan manager Agent’s assistant Agent’s assistant ¬ D1 D1 D2 C to evaluate conditions to prepare the financial evaluation to validate the offer to prepare the offer Agent Agent Loan manager Register the loan request To write the letter ofrefusal to draft the offer ¬ A2 A2 ∧A3 A2 ∧A4 A4 D1 ¬ C PC_C1.1 PC_ C1.3 PC_ C1.4 PC_ C1.5
Event: Loan request by customer
To store the loan offer as aborted Software assistant PC_ C1.6 Event: Timout
Global Business Map
Refined Business Maps material Start Agent contact strategy Handle the loan C3 Handle the loan request Direct bank strategy C2 fixed rate strategy revisable rate strategy
flexible coverings with fixed term strategy C4 C5 contract renegotiation strategy Stop by normal cloture of the loan C6 C7 C8 by dispute by notification of cloture of the offer C9
The business map: Manage loans
C1 Intentional view of the enterprise C1.1 material partial Without Stop Monitor stock Start loan request By filtering filtering Stop Financial evalution strategy
I2: Make the loan offer Delegation strategy Risk strategy Offer limited in time strategy
Requirement on the confirmation of the customer strategy
C1.2
C1.3 C1.4 C1.5
C1.6 C1.7
The refined map: C1: <Start, Handle the loan request, Agent contact strategy> ISG1
SSG1 I1: Register
Global Business Map
Refined Business Maps material Start Agent contact strategy Handle the loan C3 Handle the loan request Direct bank strategy C2 fixed rate strategy revisable rate strategy
flexible coverings with fixed term strategy C4 C5 contract renegotiation strategy Stop by normal cloture of the loan C6 C7 C8 by dispute by notification of cloture of the offer C9
The business map: Manage loans
C1 Intentional view of the enterprise C1.1 material partial Without Stop Monitor stock Start loan request By filtering filtering Stop Financial evalution strategy
I2: Make the loan offer Delegation strategy Risk strategy Offer limited in time strategy
Requirement on the confirmation of the customer strategy
C1.2
C1.3 C1.4 C1.5
C1.6 C1.7
The refined map: C1: <Start, Handle the loan request, Agent contact strategy> ISG1 SSG1 I1: Register Organisational and operational view of the enterprise To file the loan offer as refused Sign the contract Start the loan Filter the response Agent’s assistant Agent’s assistant Agent Customer PC_ C1.7
Event: Confirmation by customer
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
Business Process Chunks Financial responsible Loan manager Agent’s assistant Agent’s assistant ¬ D1 D1 D2 C to evaluate conditions to prepare the financial evaluation to validate the offer to prepare the offer Agent Agent Loan manager Register the loan request To write the letter ofrefusal to draft the offer ¬ A2 A2 ∧A3 A2 ∧A4 A4 D1 ¬ C PC_C1.1 PC_ C1.3 PC_ C1.4 PC_ C1.5
Event: Loan request by customer
Financial responsible Loan manager Agent’s assistant Agent’s assistant ¬ D1 D1 D2 C to evaluate conditions to prepare the financial evaluation to validate the offer to prepare the offer Agent Agent Loan manager Register the loan request To write the letter ofrefusal to draft the offer ¬ A2 A2 ∧A3 A2 ∧A4 A4 D1 ¬ C PC_C1.1 PC_ C1.3 PC_ C1.4 PC_ C1.5
Event: Loan request by customer
To store the loan offer as aborted Software assistant PC_ C1.6 Event: Timout To store the loan offer as aborted Software assistant PC_ C1.6 Event: Timout
Fig. 1.Business Maps and Process Chunks
Because the next intention and strategy 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 Ii, except for Stop, one ‘Strategy Selection Guideline’ per node pair <Ii,Ij> and one ‘Intention Achievement Guideline’ per section <Ii,Ij, Sij>. Given an intention Ii, an Intention Selection Guideline (ISG), identifies the set of intentions {Ij} that can be achieved in the next step. Given two Intentions Ii, Ij and a set of pos-sible strategies Sij1, Sij2, ..Sijn applicable to Ij, the role of the Strategy Selection
Guideline (SSG) is to guide the selection of an Sijk.
The execution of each map section is supported by an IAG that provides an opera-tional or an intenopera-tional means to fulfill a business intention. For the former, the IAG is operationalized by a business process chunk which is a process knowledge
speci-fied in the operational level (who, when, where and how). In this case, the IAG de-scribe 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 objectiveslayer is to provide the intentional defini-tion of business processes. The refined business maps should then be operadefini-tionalized 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 opera-tionalizable business intentions are implemented using business processes (BP). In our framework, we consider that the business process chunk operationalizes a busi-ness map section (which cannot be refined any more). Accordingly, we have to de-scribe the roles, which will act in order to achieve the business intention according to the strategy 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 ill-structured 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 grouprole; 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, product-oriented 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 de-partment 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
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 in-tentions 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 model-ing 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 opera-tional 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 enter-prise.
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 con-stitutes 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 crite-ria.
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.
References
1. Alonso, G., Agrawal, D., El Abbadi, A. and Mohan, C. (1997) "Functionality and Limita-tions of Current Workflow Management Systems" IEEE Expert, Vol12, No. 5, Sept/Oct 1997
2. 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 Informa-tion Systems Engineering, (CAISE'04), Springer Verlag (pub), 2004.
3. Burlton, R. T. (2001) Business Process Management- Profiting from process, SAMS Pub-lishing, 2001.
4. 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, 1996.
5. 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, 352-357.
7. Nurcan, S. (2004) Business Process Modeling for developing Process Oriented IT Systems, The "Business Process Management Tools and Technologies" track of the 2004 IRMA In-ternational 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. 61-82.
9. 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, 513-529.
10. 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 Model-ling, Requirements Engineering Journal, 4:4, 169-187.
13. 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 Interna-tional Conference on System Sciences ( HICSS-34)-Volume 7, January 03 - 06, 2001. 16. WfMC-TC-1003 v1.1 (1995), V 1.1. Workflow Reference Model, January 1995.
