Business Process Modeling for developing Process Oriented IT Systems Track: Business Process Management Tools and Technologies

Information system developers are challenged to develop systems that should meet the requirements of modern organizations. By promoting the enterprise-wide integration, the paradigm of Business Process Management contrasts with traditional information system development, which was suffered, but also crystallized, the vertical division of the enterprise activities. In addition, the paradigms of Business Process Reengineering and Business Process Improvement contrast with traditional information system development that focused on automating and supporting existing business processes. Now, enterprises should create new ways of working to survive in a competitive environment. This organizational transformation depends of the creation of a powerful vision of what future should be like. We claim that an in depth understanding of the current functioning is also required. In this context, enterprise modeling can help understanding the current business situation and establishing a vision of what the future should be like. Therefore, business process modeling becomes a pre-requisite for system requirements elicitation and system development.

Introduction

Before the seventies, companies used the principle of scientific management founded by Frederik W. Taylor and were strongly production-oriented. The resulting organization let to a vertical division of the activities and to functional and extremely hierarchical structures having, most of the time, their own information systems.

Over the past decade, continuous challenges have been made to traditional business practices. Rapid market changes such as electronic commerce, deregulation, globalization and increased competition have led to a business environment that is constantly evolving. Organizational transformation became then a major issue. Several management methods have been proposed to this end. One of the most recent ones is the Business Process Reengineering (BPR), proposed by [START_REF] Hammer | Reengineering the Corporation: a Manifesto for Business Revolution[END_REF]. Companies change to better satisfy customer requirements, address increasingly tough competition, improve internal processes and adapt the products and services they offer [START_REF] Jacobson | The object advantage -Business Process Reengineering with object technology[END_REF]. At the same time, organizations also experience the effects of the integration and evolution of information technology (Liebowitz and Khosrowpour, 1997). While information systems continue to serve traditional business needs such as co-ordination of production and enhancements of services offered, a new and important role has emerged, namely the potential for such systems to adopting a supervisory or strategic support role. Information and Communication Technologies were thus positioned as a strategic resource that enables automation, monitoring, analysis and coordination to support the transformation of business processes [START_REF] Grover | Exploring the success of information technology enabled business process reengineering[END_REF].

In this evolving environment, companies need also (i) to integrate their new solutions with the existing ones (legacy systems) in a global IT architecture and (ii) to orchestrate the execution of their activities and the use of the supporting technological solutions in an integrated environment. This can be achieved by developing process-centric Enterprise Application Integration solutions. The paradigm of Business Process Management stresses the importance of integrating entire processes rather than simply integrating data or applications [START_REF] Burlton | Business Process Management-Profiting from process[END_REF], (Van der Aalst, 2000). This paper is organized as follows: Section 2 recalls the evolution of our glance on the relationship between the organization and its information system(s). Section 3 presents a state of the art on enterprise modeling from the point of view of process modeling formalisms, situates briefly the WFMSs with respect to the nature of business processes they can execute and presents examples of process modeling frameworks. Section 4 proposes a conceptual framework for modeling business processes of any type and illustrates the proposed concepts with an example.

Evolution of our glance on the relationship between the organization and its information system

The social structures do not develop free from technological influence. The information technology and the social structures inform and shape each other. While information technologies and information systems became an integrated aspect of organizations, the efficient communication between enterprise's actors and managers on a side, requirement engineers and IT specialists on other side, became more and more critical because systems should be continuously adapted to changing business practices and needs.

At 1977, J. L. Lemoigne proposed the "Operation-Information-Decision" (OID) model that set the articulation of the organization around three systems: the operation system (OS), the information system (IS) and the decision system (DS). In this model [START_REF] Le Moigne | La théorie du système général, théorie de la modélisation[END_REF], the IS was considered as a system, which will memorize all information useful for the operation system. The IS interacts also with the DS for providing the production data and information on control variables. According to this articulation between the three systems, the DS usually acts on the OS by setting (ordering) actions through the IS.

The major contribution of the OID model was to provide the symmetry on the coupling of operation and information systems on one side and decision and information systems on the other side. Nevertheless, this apparent symmetry lead to a generation of information systems providing solutions based on the OS/IS couple, leaving the scope of the second couple (DS/IS), especially in France, to another research community working around the topics of artificial intelligence, expert systems or decision support systems.

Today, the information system does not exist only as an image of the real world but sometimes it could be the unique reality. In fact, we are more and more dealing with products and services that are only "information". It seems more appropriate to consider the organization as a whole system with its multiple facets: its strategy, its structure and its information systems. These three facets should be considered, not as different systems of the organization but as various views of the same system, the organization.

Our vision of the organization can be structured according to three levels of concern [START_REF] Nurcan | A multi-method for defining the organizational change[END_REF]. The objectives of the organization are achieved by implementing the enterprise processes whose are themselves supported by the enterprise information systems. The two first levels 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 manipulating such enterprise objects. The third one focuses on system aspects i.e., the computerized system that will support the enterprise, its processes and its actors in order to achieve the business objectives. The information and communication strategy 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 primary 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 information system or an evolution of the IS which does not call into question the processes or even the objectives of the organization.

In the field of Information Systems, the notion of "Enterprise modeling" refers to a collection of conceptual modeling techniques for describing different facets of the organizational domain including operational (information systems), organizational (business processes, actors, roles, flow of information etc), and teleological (purposes) considerations [START_REF] Bubenko | Enterprise Modelling[END_REF]. Existing enterprise modeling frameworks [START_REF] Dobson | The ORDIT Approach to Organisational Requirements[END_REF][START_REF] Van Lamsweerde | Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt[END_REF], [START_REF] Yu | Using Goals, Rules and Methods to Support Reasoning in Business Process Reengineering[END_REF], [START_REF] Loucopoulos | The ELEKTRA project: Enterprise Knowledge Modeling for change in the distribution unit of Public Power Corporation[END_REF], [START_REF] Nurcan | Describing business processes with a guided use case approach[END_REF], (Rolland et al., 1998b), [START_REF] Loucopoulos | Enterprise modeling and teleological approach to requirements engineering[END_REF] stress the necessity to represent and structure enterprise knowledge taking into account all these facets in order to develop information systems and IT architectures that enterprises need.

State of the art for enterprise modelling

The study of the literature suggests that existing approaches to enterprise modelling can be classified into two categories.

In the first category, an organization is represented as a set of inter-related elements satisfying common objectives [START_REF] Checkland | Soft Systems Methodology in Action[END_REF], [START_REF] Flood | Creative Problem Solving. Total System Intervention[END_REF]. For instance, VSM (Espejo and Harnden, 1989) allows us to model an organization as a set of viable subsystems representing respectively the operation, co-ordination, control, intelligence (reasoning, analysis) and politics (strategy) aspects of an organization.

In the second category, the focus is given to developing different views of the organization dealing respectively on actors, roles, resources, business processes, objectives, rules, etc. [START_REF] Bubenko | Enterprise Modelling[END_REF], [START_REF] Decker | An enterprise reference scheme for integrating Model based knowledge engineering and enterprise modeling[END_REF], [START_REF] Jarzabek | Model-based support for business reengineering[END_REF]. In the following, we focus our purpose on the second category.

A classification of process modeling formalisms

Business processes can be roughly classified into two categories depending on their nature. The first concerns well-structured and -often-repetitive processes having important coordination and automation needs. The second category concerns ill-structured or ad-hoc 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. For many organizations, well-structured, ill-structured and ad-hoc business processes coexist and must be handled in the final business model [START_REF] Nurcan | Quels modèles choisir pour les applications coopératives mettant en oeuvre les technologies de workflow et de groupware ?[END_REF], [START_REF] Nurcan | A method for cooperative information systems analysis and design: CISAD[END_REF]. 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.

Business process modeling usually combines three basic views:

(i) The functional view is expressed based on Data Flow Diagrams [START_REF] Marca | IDEF0/SADT: Business Process and Enterprise Modeling[END_REF];

(ii) The behavioral view focuses on when and under which conditions activities are performed; this view is described using state diagrams or interaction diagrams [START_REF] Jacobson | Object Oriented Software Engineering -A Use Case Driven Approach[END_REF], [START_REF] Harel | STATEMATE: A working environment for the development of complex reactive systems[END_REF]; and

(iii) The structural view focuses on the static aspect of the business process capturing the objects that are manipulated by the business process and their relationships [START_REF] Rumbaugh | Object Oriented Modeling and Design[END_REF].

Each process modeling technique uses some of these views to model a process. For instance, STATEMATE [START_REF] Harel | STATEMATE: A working environment for the development of complex reactive systems[END_REF] deals with the traditional "who, what, where, when and how" of the process using activity, state and module charts while IDEF0 [START_REF] Ross | Applications and extensions of SADT[END_REF] employs a data flow perspective do model processes.

The study of the literature shows that existing process modeling formalisms can be classified into three categories: activity-oriented models, product-oriented models and decision-oriented models.

Activity-oriented models allow us to describe a business process as a set of activities with conditions constraining the order of these activities. These models are useful for representing the functional view of business processes. Nevertheless, the linear view of activity decomposition promoted by this paradigm is inadequate for modeling ill-structured business processes.

Product-oriented models do not put forward the activities of a process but rather the result of these activities. A positive aspect is that they model the evolution of the product and couple the product state to the activities that generate this state. They are useful for tracing the transformations performed and their resulting products, i.e. business objects, products or services. These are used for representing the structural view introduced below. This kind of models is more appropriate than activity-oriented models for representing ill-structured or adhoc business processes. However considering the highly non-deterministic nature of the strategic business processes, it is difficult to write down a realistic state-transition diagram that adequately describes what has to happen during the entire process.

The most recent type of process models, developed for IS engineering or requirements engineering processes [START_REF] Jarke | DAIDA -An environment for evolving information systems[END_REF], [START_REF] Potts | A Generic Model for Representing Design Methods[END_REF], (Rolland and Grosz, 1994, are based on the decision-oriented paradigm according to which the successive transformations of the product (business objects, products or services in our case) are looked upon as consequences of decisions. Such models are semantically more powerful than the two others because they explain not only how the process proceeds but also why. Their enactment guide the decision making process that shapes the business, help reasoning about the rationale of decisions [START_REF] Maclean | Questions, Options, and Criteria: Elements of A Design Rationale for User Interfaces[END_REF], [START_REF] Maclean | Design Rationale: The argument behind the artefact[END_REF] and record the associated deliberation process. The decision-oriented modeling paradigm seems to be the particularly appropriate for representing ill-structured or ad-hoc business processes [START_REF] Salinesi | A Methodological Framework for Understanding IS Adaptation through Enterprise Change[END_REF], [START_REF] Salinesi | Fitting Business Models to Software Functionality : Exploring the Fitness Relationship[END_REF], [START_REF] Rolland | Goal oriented Requirements Engineering[END_REF], [START_REF] Nurcan | Enterprise Knowledge and Information System Modelling in an Evolving Environment[END_REF], [START_REF] Nurcan | A multi-method for defining the organizational change[END_REF].

Position of Workflow Management Systems

In terms of automated support for executing business process models, commercial WFMS and the underlying control flow models are useful for well-structured and repetitive work processes. Nevertheless, they cannot be used for ill-structured business processes or deal with the dynamic modification of well-structured process models. More and more, users ask for adaptive tools to enact and to control the execution of the business processes and flexible models for their definition (Weske, 2001), [START_REF] Sadiq | Architectural Considerations in Systems Supporting Dynamic Workflow Modification[END_REF], [START_REF] Casati | Workflow Evolution[END_REF].

Most of the existing workflow models are activity-oriented and are devoted to the representation of business processes whose execution could be automatically supported by a WFMS based on the same paradigm (Ellis and Wainer, 1994), (Medina-Mora et al., 1992), (McCarthy and Sarin, 1993). 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' (WfMC-TC-1003, 1995), ( WfMC-TC-1011, 1999). The workflow definition comprises a number of logical steps, each of which is known as an activity. An activity can involve manual interaction with a user or workflow participant, or the activity might be executed using machine resources [START_REF] Allen | Workflow an introduction, Workflow handbook[END_REF], [START_REF] Ellis | Workflow Technology, Computer Supported CooperativeWork[END_REF].

Commercial WFMS propose their own model to graphically represent business processes. Models are numerous but there are a few theoretical studies on which they are founded. Two types distinguish themselves: a) models coming from Petri nets (for instance, ICN) which are activity oriented [START_REF] Ellis | Information Control Nets, A Mathematical Model of Office Information Flow[END_REF], (MacCarthy and Sarin, 1993), [START_REF] Swenson | Visual Support for Reengineering Work Process[END_REF], b) models coming from the Speech Act Theory (for instance, ActionWorkflow) which are conversation oriented. Models such as ICN [START_REF] Ellis | Information Control Nets, A Mathematical Model of Office Information Flow[END_REF] that are used for well-defined processes provide the robustness and security but not the flexibility. They cannot be used for ad-hoc or even illstructured business processes. The process-modeling paradigm underlying ActionWorkflow [START_REF] Winograd | A Langage/Action Perspective on the Design of Cooperative Work[END_REF] and (Medina-Mora et al. 1992) aims to study cooperative business processes from the point of view of the conversation and negotiation activities they contain. It is based on the Speech Act Theory [START_REF] Searle | A taxonomy of illocutionary acts[END_REF] and could be more appropriate for modeling ill-structured processes than activity-oriented models.

Examples of process modeling frameworks

In [START_REF] Nurcan | Defining Ways-of-Working for Cooperative Work Processes[END_REF] and [START_REF] Nurcan | Meta-modelling for cooperative processes[END_REF] The I * framework [START_REF] Yu | From E-R to "A-R" -Modelling Strategic Actor Relationships for Business Process Reengineering[END_REF] has been developed to help supporting process modeling and reengineering. Processes are taken to involve social actors who depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. The framework includes a Strategic Dependency model and a Strategic Rationale model. According to I * , a business process would typically appear as a chain of dependency relationships, rather than as a sequence of input-output flows. A Strategic Dependency model is an intentional model and allows a richer representation of an organization than conventional workflow models that are based on non-intentional entity and activity relationships. It describes the network of relationships among actors. The Strategic Rationale model describes and supports the reasoning that each actor has about its relationships with other actors. It shows "how" an actor meets its incoming dependencies or internal goals and desires by modeling actor's "ways of doing things" which are called tasks.

The OSSAD method (Office Support System Analysis and Design) [START_REF] Dumas | La méthode OSSAD -Pour maîtriser les technologies de l'information -Tome 1: Principes[END_REF] developed within the context of an ESPRIT project aims to conduct business transformation, taking advantages of opportunities offered by new technologies. OSSAD proposes two levels of modeling: the abstract and the descriptive ones. The abstract level aims to represent the organization from the point of view of its objectives disregarding currently used resources. The descriptive level aims to represent current or future realization conditions in accordance with objectives expressed in the abstract level. It takes into account organizational (organization choices, responsibility sharing, information flow), human (arrangement of workers in different departments) and technical (tools) means.

Main concepts for analyzing and modeling business processes

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 or even for ad-hoc business processes. Our proposition results from the study of existing business process models applied during the last decade.

The meta-schema shown in Figure 1 includes the concepts that we judge essential to model various type of business processes and their support IT systems. The model is represented using UML notations.

Intentional view of the enterprise

The purpose is to describe what the enterprise wants to achieve or to avoid. Reasoning on the enterprise objectives makes easier understanding of problems and communication on essential aspects (what and why instead of who, when, where and how). This representation "by intentions and strategies" may (i) constitute a documentation for business analysts to discuss about the enterprise and its evolution, and (ii) help, in term, analysts, designers and developers of information systems. For representing the intentional view of the organization, we are using the map meta-model presented in (Rolland et al., 1999c).

According to (Rolland et al., 1999c), a map is a process model in which a non-deterministic ordering of intentions and strategies has been included. It is a labeled directed graph with intentions as nodes and strategies as edges between intentions. The map-meta model allows specifying process models in various domains such as method engineering, process engineering, requirements engineering [START_REF] Nurcan | A multi-method for defining the organizational change[END_REF]) [START_REF] Nurcan | Enterprise Knowledge and Information System Modelling in an Evolving Environment[END_REF], [START_REF] Ralyte | An approach for evolution driven method engineering[END_REF] .

In this paper, we apply the map model for representing enterprise objectives and the underlying business processes. For the sake of clarity, we will use the 'business map' notion, in the following, instead of generic 'map' notion of (Rolland et al., 1999c). As shown in Figure 1 and illustrated in Figure 2, a business map consists of a number of sections each of which is a triplet < source intention I i , target intention I j , strategy S ij There are two distinct intentions called Start and Stop respectively that represent the intentions to start navigating in the map and to stop doing so. Thus, it can be seen that there are a number of paths in the graph from Start to Stop. A business intention expresses what the enterprise wants to achieve.

It reflects a choice that can be made at a given moment in the business process. A business intention defines stable characteristics of the enterprise (disregarding the considerations about who, when and where) that any organization choice must respect. The business map is a navigational structure that supports the dynamic selection of the business intention to be achieved next and the appropriate strategy to achieve it whereas the associated guidelines help in the achievement of the selected intention using the selected strategy.

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 whereas the various sections having the same intention I i as a source and I j as target show the different strategies that can be adopted for achieving I j when coming from I i . Similarly, there can be different sections having I i as source and I j1 , I j2 , ....I jn as targets. These show the different intentions that can be achieved after the achievement of I i .

There are three relationships between sections, namely the thread, path and bundle that generate multi-thread and multi-path topologies in a map. The path relationship establishes a precedence/succession relationship between sections. There might be several flows from I i to I j , each corresponding to a specific strategy. In this sense the business map offers multi-thread flows. Finally, a section, that is a bundle of other sections, expresses that only one of these sections can be used in realizing the target intention. There might also be several strategies from different intentions to reach an intention I i . In this sense the map offers multi-flow paths to achieve a business intention. The business map contains a finite number of paths, 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. Therefore the map is a multi-model. The approach suggests a dynamic construction of the actual path by navigating in the business map. As shown in Figure 2, some sections in a business map can be defined as maps in a lower level of abstraction and so on. A decision driven business process resolves repeatedly two issues, namely, (1) how to fulfil the business intention according to a strategy and (2) how to select the right business map section to progress. 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 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 >. In (Rolland et al., 1999c) they are referred as IAG, ISG and SSG respectively. 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 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 . ISGs and SSGs describe the business know-how of decisional level.

The execution of each map section is supported by an IAG that provides an operational or an intentional means to fulfil a business intention. For the former, the IAG is operationalized by a business process chunk which is a process knowledge specified 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 business map in a lower level of abstraction.

These concepts allow representing the intentional view of the enterprise (the top part of Figure 1). Figure 2 illustrates the concept of Business Map and the underlying Process Chunks and Figure 3 shows an example.

Organizational and operational views of the enterprise

Enterprises are structured as networks of business processes in order to meet their objectives (business intentions). Business processes are represented using the concepts defined at the second level of the conceptual framework (Figure 1).

The concept of role

Enterprise processes can be first analyzed in terms of roles played by actors. The concept of role is common to all existing business process modeling frameworks. A role is the definition of an organizational intention shared by a collection of users, all of whom have the same privileges and obligations. The role seems to be the main concept for the representation of business processes. We specialize it using two points of view. First, a role may be external or internal to the organization. In the same time, it can describe an individual or a group.

The concept of business process

For the enterprise modeling techniques, it is a common way to consider that operationalizable business intentions are implemented using business processes. In our modeling framework, a business map section can be defined using:

(i)
a business map in a lower level of abstraction; or (ii) a business process chunk

In the last case, we consider that the business process chunk operationalizes the business map section. In fact, we have to describe not only the roles, which will act in order to achieve the business intention according to the strategy associated to the section, but also the actors holding these roles; the activities they will perform and the pre-order between these activities if the business process is well-defined.

An actor holds an individual role. The actor can be a person or automate. A person belongs to an organizational unit, which is also a group role. Actors perform activities that specify the smaller work steps in a business process. An individual activity defined as a set of primitive actions performed by an individual role. An activity, as a business process chunk, is triggered by an event and its execution generates events.

The essential preoccupation of well-defined processes is the coordination of their component work steps. A well-defined business process is defined as a pre-order individual activities.

Using the concepts of our meta-schema, it can be defined as a compound business process chunk having individual activities, at the lower level of the decomposition. The pre-order (sequence, parallelism and alternatives) is defined using precedence links and choice criterion based on arguments set on the states of the business objects.

Organizations cannot only be described only in terms of well-structured processes. An illdefined business process can be defined as an ill-structured BPC grouping a set of business process chunks, which could be of any type.

Actors can also perform activities requiring simultaneous presence or using a synchronous communication. 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 set of roles;

triggered by an event; generating events; using and producing business objects. The key concept of ad-hoc processes is the information and knowledge sharing in the work group.

IT support view of the enterprise

The focus of the bottom level of the conceptual framework is the IT system that has to support the enterprise processes in order to achieve the enterprise objectives. An individual software component supports an individual activity and a group component supports a group activity, if these activities can be computerized.

The individual software components are specified thanks to the actions that define the activity and the corresponding execution and/or iteration conditions. Each action handles (creates/modifies/suppresses) a given business object. This corresponds to traditional transactional activities, which perform well-identified operations on the database (repository). For all other kind of individual activities, the relationship is defined by does not apply.

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 duration and the refunding modalities of the loan to the customer. When the decision is 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 business map, shown in Figure 3, is specified by instantiating the concepts of the intentional level of the conceptual framework. There are two high-level business intentions in the business map of the loan domain and nine strategies are used. 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. This local C1 includes two business intentions in a lower level of abstraction.

The execution of each section of this local map (except C1.2) is supported by an IAG operationalized by a business process chunk surrounded in dotted line (lower part of Figure 3). A business process 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.

Conclusion

Using models to represent the enterprise allows a more coherent and complete description of enterprise objectives, business processes, actors and enterprise 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. They proved their efficiency as well as for improving communication than making easier the organizational learning.

The intention driven modelling provides basis for understanding and supporting the enterprise objectives, the alternative way-of-workings, and when required, 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.

Figure 1 -

 1 Figure 1 -A conceptual framework for intention-driven modeling of business processes and their IT support

Figure 2 :

 2 Figure 2: Business Maps and Process Chunks

Figure 3 -

 3 Figure 3 -Example of intentional modeling of a business and the underlying business process

  , a meta-model is proposed as a basis for cooperative process model definition. The cooperative process meta-model provides means to deal with secure and rather well structured processes and provides the flexibility to handle ill-structured processes. It allows us to represent cooperative work processes; to integrate conversations between agents; to guide and keep track of what happened in cooperative brainstorming sessions; to model the emergence of new contexts; all these being made in an homogeneous manner. The cooperative process meta-model allows us to deal with many different situations in a flexible, decision-oriented manner.