Method and system for managing a distributed workflow

TECHNICAL FIELD

[0001] The present invention relates to data processing system, and more specifically to workflow management system running on a data processing system.

BACKGROUND ART

[0002] The process of designing, developing and manufacturing new products and the process of changing or adapting existing products present many challenges to product managers and engineers to bring the products to market at low cost and within schedule while maintaining or even increasing product quality. Many companies are realizing that the conventional product design process may not be satisfactory to meet these needs. Thus, these companies may involve manufacturing engineering, cost engineering, logistic planning, procurement, manufacturing, service and support early in the design effort. Furthermore, they may plan and control product data through design, release and manufacturing.

[0003] The correct and efficient execution of business processes within a company, such as the development or production processes, may be of enormous importance for a company and may have a significant influence on company's overall success in the marketplace. Therefore, business processes are being regarded similarly to technology processes, and are being tested, optimized and monitored.

[0004] Computer-based workflow management systems (WfMSs) have thus been developed that support the modeling and execution of business processes.

[0005] It may happen that a whole or part of a business process is executed across multiple participating organizations. This is for example the case of a business process the execution of which is wholly or partly outsourced by an organization (the customer organization) to a provider organization.

[0006] Current workflow management systems do not allow different participating organizations to follow the progress of the process as a whole, i.e. not only of the parts of the process executed locally, but also of the parts of the process executed in the other organizations. For example, current workflow management systems do not allow the customer organization following the progress of the outsourced process in the provider organization.

SUMMARY OF THE INVENTION

[0007] It is an object of the present invention to overcome the limitations of current workflow management systems.

[0008] More generally, it is an object of the present invention to improve the cooperation of different entities participating to a common, distributed workflow.

[0009] According to the present invention, this and other objects are achieved by means of a method as set forth in appended claim 1, for managing a workflow distributed among at least two participating entities by means of respective distinct computer-based workflow management systems in each entity, each workflow management system managing a respective workflow part of the distributed workflow.

[0010] A common specification of the distributed workflow is defined, used as a reference by the workflow management systems. The common workflow specification specifies which workflow management system is in charge of managing a workflow part.

[0011] Additionally, a respective image of the distributed workflow is created within each workflow management system.

[0012] Based on the common workflow specification, the workflow management system of one entity communicates the progress of the workflow part managed by the workflow management system to the other entity.

[0013] In the notified workflow management system, an indication of progress on the distributed workflow image is updated in line with the progress of the workflow part managed by the workflow management system of the other entity.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The features and advantages of the present invention will be made apparent by the following detailed description of an embodiment thereof, provided by way of a non-limiting example, which will be made with reference to the attached drawings, wherein:

[0015]FIG. 1 schematically shows two entities, e.g. two organizations participating to the execution of a common business process, each having a computer-based workflow management system implementing a state-shadowing mechanism;

[0016]FIG. 2 shows in terms of functional blocks the main components of a state-shadowing engine, provided in each workflow management system for implementing the state-shadowing mechanism;

[0017]FIG. 3A schematically shows a shadow table created by the state-shadowing engine of one of the two organizations of FIG. 1 for implementing the state-shadowing mechanism in the execution of an exemplary business process;

[0018]FIG. 3B schematically shows a corresponding shadow table created by the state-shadowing engine of the other organization;

[0019]FIG. 4A shows the evolution of the state of the two workflow management systems during the execution of the exemplary business process;

[0020]FIG. 4B shows a common view of the exemplary business process shared by the workflow management systems of the two participating organizations by virtue of the state-shadowing mechanism.

[0021]FIG. 5 is a flowchart of the state-shadowing algorithm implemented by the state-shadowing engine;

[0022]FIGS. 6A. schematically show the routing of different and <b>6</b>B. workflow system management operations;

[0023]FIG. 7 is a flowchart of the operation of the state-shadowing engine when dealing with different management operations;

[0024]FIG. 8 schematically shows a situation in which each workflow management system has an internal representation of the exemplary business process different from the process common view.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0025] With reference to the drawings, FIG. 1 shows at a high level two organizations ORG<b>1</b>, ORG<b>2</b> participating to the execution of a common business process. For example, the two organizations ORG<b>1</b>, ORG<b>2</b> are peer organizations of a same enterprise or company, each of which is in charge of the execution of a respective part of the common business process; alternatively, one organization, e.g. organization ORG<b>1</b>, is a customer organization that has outsourced the execution of all or part of the business process to the organization ORG<b>2</b>, the provider organization. It is intended that, albeit only two organizations are considered in this example for the sake of simplicity, the present invention straightforwardly applies also in case the organizations participating to the execution of a common business process are more than two.

[0026] Each organization ORG<b>1</b>, ORG<b>2</b> participating to the execution of the business process, in the following referred to as participating organization, has a respective workflow management system WfMS<b>1</b>, WfMS<b>2</b>, for the management of the respective part of the business process. In particular, in each participating organization ORG<b>1</b>, ORG<b>2</b> the respective workflow management system WfMS<b>1</b>, WfMS<b>2</b> is a computer-based management system running on a respective data processing system of that organization. The data processing system in each organization ORG<b>1</b>, ORG<b>2</b> may include one or, more typically, several personal computers or workstations, interconnected through a data communication network, such as a local area network (LAN), a wide area network (WAN) where the organization is spread on different geographic locations, the Internet.

[0027] The workflow management system WfMS<b>1</b>, WfMS<b>2</b> in each participating organization ORG<b>1</b>, ORG<b>2</b> conventionally includes a workflow management system server WfMS<b>1</b>_S, WfMS<b>2</b>_S, in the following simply referred to as workflow server. The workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S is a server computer application, running on a dedicated or general-purpose personal computer or workstation of the data processing system behaving as the server of the workflow management system WfMS<b>1</b>, WfMS<b>2</b>. The workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S updates and persistently maintains information about the state of execution of the respective part of the business process. State changes are determined by operations in the workflow.

[0028] A workflow management system allows modeling a business process as a syntactical unit in a way that is directly supported by a data processing system. Once the model of a business process is created, it forms a template for a class of similar processes performed within an enterprise or company. The process template can be instantiated, interpreted by the data processing system and the individual sequence of work steps required to carry out the business process can be determined; the sequence of work steps will depend on the context of the instantiation of the process template. An instance of the process template and its interpretation represent an individual process. The fundamental elements of a process template are called activities: an activity represents a business action that can be viewed as a semantical entity. The process template describes the workflow activities, their execution order and the resources assigned to them. As schematically shown in FIG. 1, the workflow servers WfMS<b>1</b>_S, WfMS<b>2</b>_S store, for example, on the hard disk of the personal computer or workstation acting as the server of the workflow management system, a plurality of process templates PT<b>1</b>, PT<b>2</b>, . . . ; a process instance PI<b>1</b>(PT<b>1</b>) of the process template PT<b>1</b> is also schematically shown as running on the workflow server WfMS<b>1</b>_S, while a corresponding process instance PI<b>1</b>′ (PT<b>1</b>) of the same process template PT<b>1</b> is running on the workflow server WfMS<b>2</b>_S.

[0029] In each participating organization ORG<b>1</b>, ORG<b>2</b>, the workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S interacts with a respective state-shadowing engine SSE<b>1</b>, SSE<b>2</b>, running on the respective data processing system, for example on the same server computer or workstation on which the workflow server runs.

[0030] Also, in each participating organization ORG<b>1</b>, ORG<b>2</b>, a plurality of workflow management system clients WfMS<b>1</b>_C, WfMS<b>2</b>_C, in the following simply referred to as workflow clients, interact with the workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S through an interface provided by the respective state-shadowing engine SSE<b>1</b>, SSE<b>2</b>. The workflow clients WfMS<b>1</b>_C, WfMS<b>2</b>_C are client computer applications running on personal computers or workstations of the data processing system. Using the workflow clients WfMS<b>1</b>_C, WfMS<b>2</b>_C, users Ua, Ub, Uc, Ud of the workflow management systems WfMS<b>1</b>, WfMS<b>2</b> in the organizations ORG<b>1</b>, ORG<b>2</b> can interact with the workflow management system WfMS<b>1</b>, WfMS<b>2</b> of the organization to which they belong.

[0031] The workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S is equipped with an interface WfMS<b>1</b>_SI, WfMS<b>2</b>_SI allowing the users Ua, Ub, Uc, Ud within the organization ORG<b>1</b>, ORG<b>2</b>, operating through the workflow clients WfMS<b>1</b>_C, WfMS<b>2</b>_C, to log on the respective workflow server, read and possibly modify the state of activities (e.g., START, TERMINATE, COMPLETE) executed in that organization. Different users have respective user identifiers UIDa, UIDb, UIDc, UIDd, enabling the workflow clients WfMS<b>1</b>_C, WfMS<b>2</b>_C to interact with the workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S to read and modify the state of the workflow management system. Different levels of privilege can be assigned to the different user identifiers, so that different users are allowed to interact at different levels of privilege with the workflow management system. For example the user Ua, having the user identifier UIDa, can be assigned the privilege of reading and modifying the state of the workflow management system WfMS<b>1</b>, while the user Ub, having the user identifier UIDb, is assigned a lower privilege and can only read the state of the workflow management system WfMS<b>1</b>.

[0032] The state-shadowing engines SSE<b>1</b>, SSE<b>2</b> of the two organizations ORG<b>1</b>, ORG<b>2</b> interact with each other. The interaction is made possible by any suitable data communication infrastructure DCI connecting the data processing systems of the two organizations ORG<b>1</b>, ORG<b>2</b>, such as a LAN, a WAN, the Internet.

[0033] Each state-shadowing engine SSE<b>1</b>, SSE<b>2</b> implements a state-shadowing mechanism, allowing the users in any one of the organizations participating to the execution of the common business process to follow the evolution of the workflow in the other participating organizations. For example, the state-shadowing mechanism allows the users Ua, Ub of the workflow management system WfMS<b>1</b> in the organization ORG<b>1</b> following the workflow evolution in the organization ORG<b>2</b>, and vice-versa.

[0034] In particular, the state-shadowing mechanism implemented by the state-shadowing engines SSE<b>1</b>, SSE<b>2</b> allows creating in the workflow management system WfMS<b>1</b>, WfMS<b>2</b> of each participating organization ORG<b>1</b>, ORG<b>2</b> an internal replica, or a shadow, of that part of the common business process which is executed by the other organizations.

[0035] Whenever an action is performed by one of the participating organizations, e.g. the organization ORG<b>2</b>, in the execution of the respective part of the common business process, the local workflow management system changes state and, through the respective state-shadowing engine, sends to the workflow management systems of the other participating organizations, e.g. the organization ORG<b>1</b>, a message informing of the state change. The state-shadowing engines of the other participating organizations receive the message; the message is translated into a form suitable to effect corresponding state changes that allow the local workflow management system replicating the state of the workflow management system of the organization ORG<b>2</b>.

[0036] In one embodiment of the present invention, the state-shadowing engine SSE<b>1</b>, SSE<b>2</b> expediently exploits the existing interface WfMS<b>1</b>_SI, WfMS<b>2</b>_SI of the associated workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S for interacting therewith. To this purpose, the state-shadowing engine SSE<b>1</b>, SSE<b>2</b> is assigned a respective user identifier UIDx, UIDy, having a suitably high level of privilege. The state-shadowing engine SSE<b>1</b>, SSE<b>2</b> uses the user identifier UIDx, UIDy for logging onto the respective workflow server WfMS<b>1</b>_S, WfMS<b>2</b>_S. The state-shadowing engine is thus seen as a workflow client by the respective workflow server.

[0037]FIG. 2 schematically shows, in terms of functional blocks, the main components of a state-shadowing engine according to an embodiment of the present invention.

[0038] The state-shadowing engine, globally identified by SSE and part of a workflow management system WfMS, includes a state-shadowing algorithm implementing component SH_ALG, a workflow management system interface simulation component WfMS_ISC, a workflow management system interface adaptation component WfMS_IAC, a shadow table storage component SH_TAB_ST, a management interface component MG_INT and a communication component SE-SE_COM.

[0039] The workflow management system interface simulation component WfMS_ISC allows the state-shadowing engine SSE interfacing with one or more workflow applications Wf_APP, running under a workflow client. The interface simulation component WfMS_ISC implements and simulates a standard workflow server interface, such as the interfaces WfMS<b>1</b>_SI, WfMS<b>2</b>_SI of FIG. 1, that conventionally allows the workflow application Wf_APP interfacing with the workflow server WfMS_S. In particular, the interface simulation component WfMS_ISC supports the same standard functions, in the same form, as a conventional workflow server interface; the set of functions includes for example standard function sets such as WFMC IF <b>2</b>, OMG Workflow Facility, and functional interfaces of conventional workflow management systems, such as MQWF, FileNet, Staffware etc.

[0040] The workflow management system interface adaptation component WfMS_IAC maps the process management functions used by the state-shadowing algorithm implementing component SH_ALG onto functions that are supported by the underlying workflow server WfMS_S. In particular, the mapped functions can be proprietary to a particular workflow management system, or they can belong to standard function sets.

[0041] The state-shadowing algorithm implementing component SH_ALG is the core of the state-shadowing engine. The state-shadowing algorithm implementing component SH_ALG accesses the shadow table storage component SH_TAB_ST, used to persistently store shadow tables on which the operation of the state-shadowing engine is based. The shadow table storage component SH_TAB_ST is for example the hard disk of the personal computer or workstation acting as the server of the workflow management system.

[0042] The management interface component MG_INT enables one or more management application components MG_APP, external to the state-shadowing engine SSE, to access the shadow table storage component SH_TAB_ST for reading and writing the shadow tables. The management application component MG_APP is for example a computer application running on a personal computer or workstation coincident with or distinct from the personal computer or workstation acting as the server of the workflow management system, allowing authorized users to access the shadow table storage component SH_TAB_ST.

[0043] The communication component SE-SE_COM enables the state-shadowing engine SSE to interact with other state-shadowing engines in the workflow management systems of other participating organizations, over the data communication infrastructure DCI.

[0044]FIG. 3A schematically shows a shadow table, according to an embodiment of the present invention. A shadow table is created by the state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>1</b>, SSE<b>2</b> of one of the participating organizations ORG<b>1</b>, ORG<b>2</b> each time a process template PT<b>1</b>, PT<b>2</b>, modeling a given process type, in the workflow management system WfMS<b>1</b>, WfMS<b>2</b> is instantiated. Once created, the shadow table is stored in the respective shadow table storage component SH_TAB_ST.

[0045] In one embodiment of the invention, a shadow table template is created for each process template. The shadow table templates are created using the management application component MG_APP and, through the management interface component MG_INT, are loaded into the workflow management system WfMS and stored in the shadow table storage component SH_TAB_ST. The shadow table templates contain a description of how an instance of the shadow table template, or shadow table, is to be created by the state shadowing algorithm implementing component SH_ALG, upon detecting that a given process template has been instantiated.

[0046] In particular, the shadow table shown in FIG. 3A, identified globally by SH_TAB<b>1</b>(PT<b>1</b>), is created by the state shadowing engine SSE<b>1</b> and stored in the respective shadow table storage component SH_TAB_ST when the process template PT<b>1</b> is instantiated in the workflow management system WfMS<b>1</b>. The instantiation of the process template PT<b>1</b> creates the process instance PI<b>1</b>(PT<b>1</b>). By way of example only, the individual process corresponding to the process instance PI<b>1</b>(PT<b>1</b>) is supposed to include eight activities named A<b>1</b>, A<b>2</b>, A<b>3</b>, A<b>41</b>, A<b>42</b>, A<b>5</b>, A<b>6</b>, A<b>7</b>: the activities named A<b>1</b>, A<b>2</b>, A<b>5</b> and A<b>7</b> are to be performed within the organization ORG<b>1</b>, while the activities named A<b>3</b>, A<b>41</b>, A<b>42</b> and A<b>6</b> are to be performed within the organization ORG<b>2</b>; the activities A<b>41</b> and A<b>42</b> are supposed to be alternative to each other. It is also assumed that the order of execution of the activities specified in the process template PT<b>1</b> is: A<b>1</b>-&gt;A<b>2</b>-&gt;A<b>3</b>-&gt;A<b>41</b> or A<b>42</b>-&gt;A<b>5</b>-&gt;A<b>6</b>-&gt;A<b>7</b>. It is observed that the number, type and execution sequence of the activities comprising the process instance PI<b>1</b>(PT<b>1</b>) are normally context-dependent, i.e. they depend on the context of instantiation of the process template PT<b>1</b>.

[0047] The shadow table SH_TAB<b>1</b>(PT<b>1</b>) has as many entries ENTRY<b>1</b> ENTRY<b>8</b> as the activities of the process instance PI<b>1</b>(PT<b>1</b>). Any entry ENTRY<b>1</b>-ENTRY<b>8</b> of the shadow table SH_TAB<b>1</b>(PT<b>1</b>) has three fields ACT_NA, SH_TYP, NOT_SE. A first field ACT_NA contains the name A<b>1</b>-A<b>8</b> of a respective one of the activities, or in general an activity identifier. A second field SH_TYP contains an activity classifier NUL, LOC, REM, OUT, allowing the state-shadowing algorithm implementing component SH_ALG to identify to which class the activity belongs. A third field NOT_SE contains, depending on the class to which the activity belongs, the list of state-shadowing engines of other participating organizations to or from which activity execution requests or notifications need to be sent or received.

[0048] Four classes of activities are provided.

[0049] A first class of activities, identified by the activity classifier REM (“remote shadow”) such as the activities A<b>3</b>, A<b>41</b>, A<b>42</b> and A<b>6</b> in the shown example, includes remotely-executed (in the following, simply remote) activities, i.e. activities to be performed within the other participating organization ORG<b>2</b>, under the control of the respective workflow management system WfMS<b>2</b>, the state of execution of which is shadowed locally in the workflow management system WfMS<b>1</b> of the organization ORG<b>1</b>. If an activity is classified as remote, the third field NOT_SE contains an information representing the address ADD(SSE<b>2</b>) of the state-shadowing engine SSE<b>2</b> associated with the workflow management system WfMS<b>2</b> managing the execution of the activity.

[0050] A second class of activities, identified by the activity classifier LOC (“local shadow”) such as the activity A<b>5</b> in the shown example, includes locally-executed (in the following, simply local) activities, i.e. activities performed locally within the organization ORG<b>1</b> under the control of the workflow management system WfMS<b>1</b>. The execution of these local activities is shadowed by the workflow management system WfMS<b>2</b> in the other participating organization ORG<b>2</b>. If an activity is classified as local, the field NOT_SE of the corresponding entry of the shadow table contains an information representing the address ADD(SSE<b>2</b>) of the state-shadowing engine SSE<b>2</b> of the workflow management system WfMS<b>2</b>, to which notifications of state changes in consequence of the execution of the local activity are to be sent by the state-shadowing engine SSE<b>1</b>. More generally, in the case of multiple participating organizations, the field NOT_SE contains the addresses of the state-shadowing engines of all the other participating organizations.

[0051] A third class of activities, identified by the activity classifier NUL (“null shadow”) such as the activities A<b>1</b> and A<b>7</b> in the shown example, includes activities which are executed locally within the organization ORG<b>1</b>, under the control of the workflow management system WfMS<b>1</b>, and which are not shadowed in the workflow management system WfMS<b>2</b> of the other participating organization ORG<b>2</b>. In this case, the field NOT_SE is void, because the state-shadowing engine SSE<b>2</b> (more generally, the state-shadowing engines of all the other participating organizations) needs not be notified of state changes produced by the execution of these activities.

[0052] A fourth class of activities, identified by the activity classifier OUT (“outsourced shadow”) such as the activity A<b>2</b> in the shown example, includes activities determining the start of a shadowed process part. The field NOT_SE in the corresponding shadow table entry contains the address ADD(SSE<b>2</b>) of the state-shadowing engine SSE<b>2</b> of the other organization ORG<b>2</b> participating to the execution of the common business process. This address is used to notify the workflow management system WfMS<b>2</b> of the other participating organization ORG<b>2</b> that a new shadowed process instance PI<b>1</b>(PT<b>1</b>) of the process template PT<b>1</b> has been created.

[0053]FIG. 3B shows a shadow table SH_TAB<b>2</b>(PT<b>1</b>) created by the state-shadowing engine SSE<b>2</b>, and stored in the respective shadow table storage component SH_TAB_ST, when the workflow management system WfMS<b>2</b> instantiates the process template PT<b>1</b> upon receiving the prescribed notification from the state-shadowing engine SSE<b>1</b>. The shadow table SH_TAB<b>2</b>(PT<b>1</b>) contains only those activities, namely A<b>3</b>, A<b>41</b>, A<b>42</b>, A<b>5</b> and A<b>6</b> in the shown example, which are either performed in the organization ORG<b>1</b> and shadowed in the organization ORG<b>2</b>, or performed in the organization ORG<b>2</b> and shadowed in the organization ORG<b>1</b>. The activities classified as NUL, such as A<b>1</b> and A<b>7</b>, which are performed in the organization ORG<b>1</b> and not shadowed in the workflow management system WfMS<b>2</b> of the organization ORG<b>2</b>, are not included in the shadow table SH_TAB<b>2</b>(PT<b>1</b>). It is to be observed that the process template PT<b>1</b> may also include activities to be executed within the organization ORG<b>2</b> and not to be shadowed in the workflow management system WfMS<b>1</b> of the organization ORG<b>1</b>. It can be seen that the activities that in the shadow table SH_TAB<b>1</b>(PT<b>1</b>) are classified as REM (remote activities) and assigned to the organization ORG<b>2</b> (ADD(SSE<b>2</b>) in the field NOT_SE of the corresponding entry of the shadow table), are dually classified as LOC (local activities) in the shadow table SH_TAB(PT<b>1</b>), and vice-versa.

[0054] The state-shadowing mechanism will be now described with the aid of the diagram of FIG. 4A, schematically illustrating the workflow of the process instance PI<b>1</b>(PT<b>1</b>) of the process template PT<b>1</b>, and the flowchart of FIG. 5, schematically showing the flow of actions performed by any of the state-shadowing engines. It is assumed that the activity A<b>1</b> is the start activity of the process, and the activity A<b>7</b> is the end activity.

[0055] Using the assigned user identifier UIDx, the state-shadowing engine SSE<b>1</b> periodically logs onto the workflow server WfMS<b>1</b>_S to control if a process template has been instantiated by the workflow management system WfMS<b>1</b> of the organization ORG<b>1</b> to create the individual process, or process instance (blocks <b>501</b>, <b>503</b>, <b>505</b> and <b>507</b> in FIG. 5). Let it be assumed that, at a given time, the state-shadowing engine SSE<b>1</b> detects that the process template PT<b>1</b> is instantiated, so that the process instance PI<b>1</b>(PT<b>1</b>) is created. In response thereto, the state-shadowing algorithm implementing component SH_ALG of the stahe-shadowing engine SSE<b>1</b> creates (block <b>509</b>) and stores in the respective shadow table store component SH_TAB_ST (block <b>511</b>) the shadow table SH_TAB<b>1</b>(PT<b>1</b>) of FIG. 3A.

[0056] Under the control of the workflow server WfMS<b>1</b>_S of the workflow management system WfMS<b>1</b>, the start activity A<b>1</b> is located, the respective assigned resources (e.g. the people working team) are determined and the activity A<b>1</b> is posted onto a work list of the selected people of the working team. When a user belonging to the selected working team selects the activity (through the respective workflow client WfMS<b>1</b>_C), the activity A<b>1</b> is executed and removed from the work list. The execution of the activity A<b>1</b> produces a result, constituting the exit condition of the activity. The exit condition of the activity A<b>1</b> is evaluated by the workflow server WfMS<b>1</b>_S and, if proper, the activity A<b>1</b> is considered completed.

[0057] The state-shadowing engine SSE<b>1</b> continues to periodically log onto the workflow server WfMS<b>1</b>_S to read the state of execution of the process instance PI<b>1</b>(PT<b>1</b>) and verifies if any state change has occurred (blocks <b>513</b>, <b>515</b>, <b>517</b> and <b>519</b>). Since the start activity A<b>1</b> is classified as NUL in the shadow table SH_TAB<b>1</b>(PT<b>1</b>), the state-shadowing engine SSE<b>1</b> does not notify state changes of the workflow management system WfMS<b>1</b> related to the execution of the activity A<b>1</b> to the state-shadowing engine SSE<b>2</b> of the workflow management system WfMS<b>2</b> in the other participating organization ORG<b>2</b> (block <b>521</b>).

[0058] The state-shadowing engine continues to read the state of the execution of the instantiated process PI<b>1</b>(PT<b>1</b>). Once the activity A<b>1</b> is completed, the workflow server WfMS<b>1</b>_S of the workflow management system WfMS<b>1</b> locates the next activity A<b>2</b> in the workflow to performed. The state-shadowing algorithm implementing component SH_ALG in the state-shadowing engine SSE<b>1</b>, looking at the shadow table SH_TAB<b>1</b>(PT<b>1</b>), detects that the activity A<b>2</b> is classified as OUT (block <b>523</b>). This causes the state-shadowing engine SSE<b>1</b> to send a notification NSPI(PT<b>1</b>,PI<b>1</b>) (“new shadowed process instance PI<b>1</b> of process template PT<b>1</b>”) to the state-shadowing engine SSE<b>2</b> in the workflow management system WfMS<b>2</b> of the participating organization ORG<b>2</b> (block <b>525</b>). The notification is sent through the communication component SE-SE_COM over the data communication infrastructure DCI linking the data processing systems in the two organizations ORG<b>1</b>, ORG<b>2</b>, using the address ADD(SSE<b>2</b>) of the state-shadowing engine SSE<b>2</b> stored in the field NOT_SE of the shadow table SH_TAB<b>1</b>(PT<b>1</b>) entry ENTRY<b>2</b> corresponding to the activity A<b>2</b>.

[0059] Similarly to the state-shadowing engine SSE<b>1</b>, the state-shadowing engine SSE<b>2</b> periodically logs onto the workflow server WfMS<b>1</b>_S of the workflow management system WfMS<b>2</b>, using the assigned user identifier UIDy (blocks <b>501</b>, <b>503</b> and <b>505</b>). When the state-shadowing engine SSE<b>2</b> receives the notification NSPI(PT<b>1</b>,PI<b>1</b>) (block <b>527</b>), the state-shadowing engine SSE<b>2</b> logs onto the workflow server WfMS<b>2</b>_S and causes the creation of a process instance PI<b>1</b>′ (PT<b>1</b>) of the process template PT<b>1</b> (blocks <b>529</b>, <b>531</b> and <b>533</b>); the process instance PI<b>1</b>′ (PT<b>1</b>) includes the activities and control flow comprising the part of the business process which comprises activities to be executed within the organization ORG<b>2</b> but shadowed in the organization ORG<b>1</b>, or vice-versa. In this example, the process instance PI<b>1</b>′ (PT<b>1</b>) includes the activities A<b>3</b>, A<b>41</b>, A<b>42</b>, AS and A<b>6</b>, and the associated control flow.

[0060] The instantiation PI<b>1</b>′ (PT<b>1</b>) of the process template PT<b>1</b> by the workflow server WfMS<b>2</b>_S causes the associated state-shadowing engine SSE<b>2</b> to create (block <b>509</b>) and store (<b>511</b>) in the respective shadow table store component SH_TAB_ST the shadow table SH_TAB<b>2</b>(PT<b>1</b>) shown in FIG. 3B.

[0061] In this way, a common view CW(PI<b>1</b>) (shown in FIG. 4B) of the business process is defined, agreed by the workflow management systems WfMS<b>1</b>, WfMS<b>2</b> of both the participating organizations ORG<b>1</b>, ORG<b>2</b>.

[0062] The workflow management system WfMS<b>2</b> locates the start activity A<b>3</b> in the process instance PT<b>1</b>′ (PT<b>1</b>), locates the resources assigned to the execution and posts the activity A<b>3</b> onto the work list of the selected team of people.

[0063] The state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>2</b>, continuing to periodically log onto the workflow server WfMS<b>2</b>_S (blocks <b>513</b> to <b>519</b>), detects a change in the state of execution of the process instance PI<b>1</b>′ (PT<b>1</b>) related to the starting of the execution of the activity A<b>3</b>. Looking at the shadow table SH_TAB<b>2</b>(PT<b>1</b>), the state-shadowing algorithm implementing component SH_ALG in the state-shadowing engine SSE<b>2</b> detects that the activity A<b>3</b> is classified as LOC and sends (block <b>535</b>) to the state-shadowing engine SSE<b>1</b> (whose address ADD(SSE<b>1</b>) is stored in the field NOT_SE of the entry ENTRY<b>1</b> of the shadow table SH_TAB<b>2</b>(PT<b>1</b>)) a notification UPD(PI<b>1</b>,A<b>3</b>,START) (“update: started activity A<b>3</b> of process instance PI<b>1</b>(PT<b>1</b>)”). The state-shadowing engine SSE<b>1</b> receives the notification UPD(PI<b>1</b>,A<b>3</b>,START) (block <b>537</b>), and logs onto the workflow server WfMS<b>1</b>_S of the workflow management system WfMS<b>1</b> as a user, using the assigned user identifier UIDx (block <b>539</b>). Once logged on, the state-shadowing engine SSE<b>1</b> supplies to the workflow server WfMS<b>1</b>_S, through the respective interface adapter component WfMS_IAC, management commands such as to cause the workflow server WfMS<b>1</b> to start the activity A<b>3</b>, thereby changing the state of the workflow management system WfMS<b>1</b> (block <b>541</b>); then, the state-shadowing engine SSE<b>1</b> logs off (block <b>543</b>).

[0064] Once a person of the team of the organization ORG<b>2</b> in charge of the execution of the activity A<b>3</b>, through the respective workflow client WfMS<b>2</b>_C, declares the activity A<b>3</b> completed, or once an activity-implementing application completes successfully, the state-shadowing engine SSE<b>2</b> sends to the state-shadowing engine SSE<b>1</b> a notification UPD(PI<b>1</b>,A<b>3</b>,COMPL) (“update: completed activity A<b>3</b> of process instance PI<b>1</b>(PT<b>1</b>)”). The state-shadowing engine SSE<b>1</b> receives the notification UPD(PI<b>1</b>,A<b>3</b>,COMPL), logs onto the workflow server WfMS<b>1</b>_S using the assigned user identifier UIDx and, by management commands provided through the interface adapter component WfMS_IAC, causes the workflow server WfMS<b>1</b>_S to put the activity A<b>3</b> in the completed state, thereby changing the state of the workflow management system WfMS<b>1</b>.

[0065] Depending on the result of the execution of the activity A<b>3</b>, the workflow management system WfMS<b>2</b> then locates the activity A<b>42</b> and posts it in the work list of the selected team of people.

[0066] The state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>2</b>, looking at the shadow table SH_TAB<b>2</b>(PT<b>1</b>), detects that the activity A<b>42</b> is classified as LOC and sends to the state-shadowing engine SSE<b>1</b> a notification UPD(PI<b>1</b>,A<b>42</b>,START). The state-shadowing engine SSE<b>1</b> receives the notification UPD(PI<b>1</b>,A<b>42</b>,START), and logs onto the workflow server WfMS<b>1</b>_S, using the assigned user identifier UIDX. Once logged on, the state-shadowing engine SSE<b>1</b> causes the workflow server WfMS<b>1</b>_S to start the activity A<b>42</b>, thereby changing the state of the workflow management system WfMS<b>1</b>.

[0067] Once a person of the team of people of the organization ORG<b>2</b> in charge of the execution of the activity A<b>42</b>, through the respective workflow client WfMS<b>2</b>_C, declares the activity A<b>42</b> completed, or once an activity-implementing application completes successfully, the state-shadowing engine SSE<b>2</b> sends to the state-shadowing engine SSE<b>1</b> a notification UPD(PI<b>1</b>,A<b>42</b>,COMPL). The state-shadowing engine SSE<b>1</b> receives this notification, logs onto the workflow server WfMS<b>1</b>_S using the assigned user identifier UIDx, and causes the workflow server WfMS<b>1</b>_S to put the activity A<b>42</b> in the completed state, thereby changing the state of the workflow management system WfMS<b>1</b>.

[0068] The control of the workflow passes now to the workflow management system WfMS<b>1</b> that, detecting that the activity A<b>42</b> has been completed, locates the next activity A<b>5</b> to be performed within the organization ORG<b>1</b>. The activity A<b>5</b> is posted onto the work list of the team of people within the organization ORG<b>1</b> in charge of the execution. The state-shadowing implementing algorithm SH_ALG of the state-shadowing engine SSE<b>1</b>, looking at the shadow table SH_TAB<b>1</b>(PT<b>1</b>), detects that the activity A<b>5</b> is classified as LOC and sends to the state-shadowing engine SSE<b>2</b> a notification UPD(PI<b>1</b>,A<b>5</b>,START). The state-shadowing engine SSE<b>2</b> receives this notification and logs onto the workflow server WfMS<b>2</b>_S, using the assigned user identifier UIDy. Once logged on, the state-shadowing engine SSE<b>2</b> provides to the workflow server WfMS<b>2</b>_S, through the respective interface adapter component WfMS_IAC, management commands causing the workflow server WfMS<b>2</b>_S to put the activity A<b>5</b> in the start state, thereby changing the state of the workflow management system WfMS<b>2</b>.

[0069] Once the activity A<b>5</b> is completed, the state-shadowing engine SSE<b>1</b> sends to the state-shadowing engine SSE<b>2</b> a notification UPD(PI<b>1</b>,A<b>5</b>,COMPL). The state-shadowing engine SSE<b>2</b> receives this notification, logs onto the workflow server WfMS<b>2</b>_S using the assigned user identifier UIDy, and causes the workflow server WfMS<b>2</b>_S to put the activity A<b>5</b> in the completed state, thereby changing the state of the workflow management system WfMS<b>2</b>.

[0070] The control of the workflow passes back to the workflow management system WfMS<b>2</b> that, identifying the activity A<b>5</b> as completed, locates the next activity A<b>6</b> to be performed within the organization ORG<b>2</b>. The activity A<b>6</b> is posted onto the work list of the team of people of the organization ORG<b>2</b> in charge of its execution. The state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>2</b>, looking at the shadow table SH_TAB<b>2</b>(PT<b>1</b>), detects that the activity A<b>6</b> is classified as LOC and sends to the state-shadowing engine SSE<b>1</b> a notification UPD(PI<b>1</b>,A<b>6</b>,START). The state-shadowing engine SSE<b>1</b> receives this notification and logs onto the workflow server WfMS<b>1</b>_S, using the assigned user identifier UIDx. Once logged on, the state-shadowing engine SSE<b>1</b> causes the workflow server WfMS<b>1</b>_S to start the activity A<b>6</b>, thereby changing the state of the workflow management system WfMS<b>1</b>.

[0071] Once the activity A<b>6</b> is completed, the state-shadowing engine SSE<b>2</b> sends to the state-shadowing engine SSE<b>1</b> a notification UPD(PI<b>1</b>,A<b>6</b>,COMPL). The state-shadowing engine SSE<b>1</b> receives this notification, logs onto the workflow server WfMS<b>1</b>_S using the assigned user identifier UIDx, and causes the workflow server WfMS<b>1</b>_S to put the activity A<b>6</b> in the completed state, thereby changing the state of the workflow management system WfMS<b>1</b>.

[0072] In this way, the shadowed part of the business process is carried out. The control of the workflow passes back again to the workflow management system WfMS<b>1</b>, which posts the next activity A<b>7</b>, the end activity of the business process, onto the work list of the team of people of the organization ORG<b>1</b> in charge of its execution. The state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>1</b>, looking at the shadow table SH_TAB<b>1</b>(PT<b>1</b>), detects that the activity A<b>7</b> is classified as NUL, and sends no further notifications to the state-shadowing engine SSE<b>2</b>.

[0073] It is observed that albeit in the foregoing only two kind of update notifications for each activity (start and completion of an activity) are exchanged between the state-shadowing engines, more notifications can be envisaged, each one associated with an operation performed on the activity within the organization in charge of the execution thereof. Responsive to each notification, the state-shadowing engines) of the other participating organization(s) will log onto the respective workflow server, providing thereto management commands corresponding to the notification received.

[0074] By exchanging notifications of state changes between the state-shadowing engines of different participating organizations, the state of one workflow management system is replicated in the other workflow management systems. Any organization, albeit not in charge of the execution of a given part of a common business process, can thus follow, looking at the respective local shadow of the process, the activities performed in the other participating organizations. In particular, this allows any participating organization controlling the workflow in another participating organization, and synchronizing the workflows in the different participating organizations.

[0075] Additionally, the execution of local activities by an organization can be made dependent on the state of remote activities executed in different participating organizations. For example, referring back to FIG. 4A, the execution of the activity A<b>5</b> within the organization ORG<b>1</b> is made dependent on the execution of the activity A<b>42</b> within the organization ORG<b>2</b>, and the execution of the activity A<b>6</b> within the organization ORG<b>2</b> is made dependent on the execution of the activity A<b>5</b> within the organization ORG<b>1</b>.

[0076] In the context of a customer organization (e.g., organization ORG<b>1</b>) that outsources a part of a business process to a provider organization (organization ORG<b>2</b>), the provision of the state-shadowing mechanism allows the provider organization to outsource some activities (e.g., activity A<b>5</b> in FIG. 4A) back to the provider organization; this may be expedient where the business process is long and complex and where some activities and decisions should be brought back to the customer organization before continuing with the main outsourced part of the process.

[0077] The provision of a shadowing mechanism also enables remote management of activities: remote activities, executed in a first participating organization, can be managed from a second participating organization in the same way as activities executed locally to the second organization are normally managed. As shown schematically in FIGS. 6A and 6B and in the flowchart of FIG. 7, let it be supposed that a user Ua, Ub in the organization ORG<b>1</b> wants to perform, through a respective workflow application Wf_APP running on the workflow client WfMS<b>1</b>_C in the workflow management system WfMS<b>1</b>, an operation OPh on the activity Aj of the process instance PIi of a given process template. An operation request (PIi,Aj,OPh) is provided to the state-shadowing algorithm implementing component SH_ALG of the state-shadowing engine SSE<b>1</b>, through the interface simulation component WfMS_ISC. The state-shadowing algorithm implementing component SH_ALG, receiving the operation request (block <b>701</b> in FIG. 7) looks into the shadow table of the process instance stored in the shadow table store component SH_TAB_ST (block <b>703</b>), to identify the class of the activity Aj (blocks <b>705</b>, <b>707</b> and <b>709</b>). If the activity Aj is classified as LOC or NUL, the state-shadowing algorithm implementing component SH_ALG allows the workflow application Wf_APP to log into the workflow server WfMS<b>1</b>_S, thereby the operation request (PIi,Aj,OPh) is transferred, through the interface adaptation component WfMS_IAC, to the workflow server WfMS<b>1</b>_S (block <b>711</b> or <b>713</b>); the workflow server WfMS<b>1</b>_S changes its state in consequence to the operation OPh. Additionally, if the activity Aj is classified as LOC, and the state-shadowing algorithm implementing component SH_ALG notifies (UPD(PIi,Aj,OPh)-block <b>715</b>) to the other participating organization ORG<b>2</b> the change of state, so that the state of the workflow management system WfMS<b>2</b> is correspondingly updated. If the activity is instead classified as REM, the state-shadowing algorithm implementing component SH_ALG sends to the state-shadowing engine SSE<b>2</b> in the workflow management system WfMS<b>2</b> in the other participating organization ORG<b>2</b> a remote operation execution request EXRQ(PIi,Aj,OPh) (block <b>717</b>) and waits for the notification of state update indicating that the operation has been executed (block <b>719</b>); upon detecting the incoming remote operation execution request (block <b>721</b>) the state-shadowing algorithm implementing component SH_ALG in the state-shadowing engine SSE<b>2</b> looks into the shadow table stored in the respective shadow table store component SH_TAB_ST block <b>723</b>) to verify that the activity Aj is classified as LOC, i.e. local to the organization ORG<b>2</b> (block <b>725</b>). In the negative case, the remote operation execution request EXRQ(PIi,Aj,OPh) is ignored, otherwise the state-shadowing angine SSE<b>2</b> logs into the workflow server WfMS<b>2</b>_S (block <b>727</b>) and supplies thereto the remote operation request (PIi,Aj,OPh) (block <b>729</b>), logging then off (block <b>731</b>); the workflow server WfMS<b>2</b>_S applies the operation to the activity Aj as if coming from one of the workflow applications Wf_APP running on the workflow clients WfMS<b>2</b>_C of the workflow management system WfMS<b>2</b>, thereby changing the state of the workflow management system WfMS<b>2</b>, then the state-shadowing engine SSE<b>2</b> notifies ((UPD(PIi,Aj,OPh)) the change of state to the workflow management system WfMS<b>1</b>. Possible conflicts are resolved in the following way: if the state-shadowing engine SSE<b>1</b>, before receiving the remote operation execution request EXRQ(PIi,Aj,OPh), receives from one of the local workflow applications Wf_APP an operation execution request for the same activity Aj, thereby the state of the workflow management system WfMS<b>2</b> is changed in such a way that the operation OPh specified in the remore operation execution request EXRQ(PIi,Aj,OPh) cannot be executed anymore, the remote command execution request EXRQ(PIi,Aj,OPh) is ignored. In other words, to resolve conflicts a strategy is adopted according to which operation execution requests local to the workflow management system of a participating organization have the priority over remote operation execution requests originating in other participating organizations.

[0078] The state-shadowing engine thus provides, in each workflow management system, a reference monitor for applications such as the workflow clients or other managing applications, providing the same functionality as the conventional interfaces of the workflow servers. The reference monitor determines the location of the activity on which a management operation is to be performed: if the activity is local to the organization where the management operation request is originated, the reference monitor allows the management operation to be performed by the local workflow management system, otherwise the management operation request is forwarded to the reference monitor of the workflow management system of the organization in charge of executing the activity. The strategy for resolving possible conflicts provides that the workflow management system in the organization in charge of executing an activity has the right to override management operation requests coming from the workflow management system of a remote organization.

[0079] It is observed that the part of the common business process executed under the responsibility of one of the organizations participating to the common business process can differ, in terms of activities and/or order of execution, from the common view of the process agreed upon by all the workflow management systems. Referring to FIGS. 4A and 4B, this means for example that the process instance PI<b>1</b>′ (PT<b>1</b>) created in the workflow management system WfMS<b>2</b> of the organization ORG<b>2</b> can include different activities, with a different execution order, than those comprising the common view of the process shown in FIG. 4B. An example of this situation is depicted in FIG. 8, where it is shown a process instance PI<b>1</b>′ (PT<b>1</b>) differing from the common view CW(PI<b>1</b>) of the process. In particular, the process instance PI<b>1</b>′ (PT<b>1</b>) forms an internal representation of the common view CW(PI<b>1</b>) of the process, comprising the activities A<b>10</b>-A<b>14</b>. The state-shadowing engine SSE<b>2</b> in the workflow management system WfMS<b>2</b> implements a suitable mapping MAP of the real process PI<b>1</b>′ (PT<b>1</b>) to be executed within the organization ORG<b>2</b> onto the common view of the process CW(PT<b>1</b>). The mapping shall guarantee that the messages exchanged between the two participating organizations ORG<b>1</b> and ORG<b>2</b> to notify the workflow progress are compatible with the common view of the process. Such a mapping can be for example implemented by the state-shadowing implementing algorithm component SH_ALG in the state-shadowing engine SSE<b>2</b>; in particular, the shadow table SH_TAB<b>2</b>(PT<b>1</b>) shown in FIG. 3B can be modified to allow a transcoding of the activities A<b>3</b>, A<b>41</b>, A<b>42</b>, A<b>5</b> and A<b>6</b> in the common view of the process into the real activities to be executed under the responsibility of the organization ORG<b>2</b>. Alternatively, the mapping can be implemented by the state-shadowing engine SSE<b>1</b> in the workflow management system WfMS<b>1</b>.

[0080] More generally, the workflow management system of each participating organization may have a respective internal representation of the common view of the business process, and the respective state shadowing engine may implement a suitable mapping (MAP<b>1</b> and MAP<b>2</b> in FIG. 8) of the respective internal process representation onto the common view of the process. The provision of the common view of the process and the mapping allows any participating organization to have a respective internal representation of the common business process, chosen to best suit the internal needs of each organization, at the same time allowing information on the workflow progress to be exchanged between the different participating organizations.

[0081] The described system and method is applicable in general whenever multiple organizations participate to carrying out a business process under the control of computer-based process management systems. The state-shadowing mechanism allows all the participating organizations tracking the business process progress.

[0082] The described system and method is also applicable to the management of a business process within a single organization, in which different entities within the organization, for example different teams or departments, participate to carrying out the business process, by relying on respective workflow management systems. More generally, the different entities participating to the management of the business process can include entities belonging to a same organizations and entities belonging to different organizations.

[0083] Although the present invention has been disclosed by way of some embodiments, it is apparent to those skilled in the art that several modifications to the described embodiments, as well as other embodiments of the present invention are possible, without departing from the scope thereof as defined in the appended claims. By way of example only, and not at all exhaustively, the workflow management systems may adopt different communication protocols; different login and logoff policies may be envisaged; the information on state changing events may be communicated by the workflow server to the respective state-shadowing algorithm implementing component, instead of being detected by the latter by regularly polling the workflow server.