We introduce in this blog series the concept of Case Management Process Modeling (CMPM) - An emerging concept complementary to existing Business Process Management (BPM) concepts. In this second blog entry, we explain modeling aspects of a case that could be interesting for the currently developed standard for CMPM by the Object Management Group (OMG). This blog entry is relevant for enterprise architects, product managers and business analysts.

Goals of Case Management – Recap

I wrote in a Case Management Process Modeling (CMPM) – An Introduction that case management is focusing on dynamic evolving processes for managing critical business assets. It is thus fundamentally different from operational business processes modeled in the business process modeling notation (BPMN) and managed by workflow systems. Case management is complementary to business processes and requires new models as well as systems to support it. Examples for cases are insurance cases, healthcare cases or cases related to public services (e.g. crime investigations). Clearly, all those cases are of highly collaborative nature.

Stakeholders of Case Management

We illustrate in the following figure some typical stakeholders involved in case management.

These stakeholders seem to be similar to the ones involved in BPM. However, in case management, they need to collaborate much more to align their goals according to the evolving dynamic process.  We distinguish the following roles:

• Case Designer: The case designer is the creative business analyst describing and modifying cases according to business needs. This role allows the case workers to work freely on a case as they think it is the best way - given only few constraints (e.g. regulations). He has to align the case with enterprise-business rules defined by the global business rule designer.
• Case Worker: The case worker works on the case and manages the evolution of processes related to the case based on his/her experience. He reports to the case owner. Several case workers can work on the same case and thus they need to collaborate with each other mediated via the case. This type of collaboration offers much more freedom than enforced collaboration by a business process management system.
• Case Owner: The case owner manages the relationships between different types of cases and the people related to these cases. He ensures that cases generate the maximum business value taking into account risks and opportunities.
• Global Business Rule Designer:  The global business rules designer describes rules according to enterprise wide goals and regulations. This role has a more global and strategic perspective independent of specific cases. He works together with the case designers and case owner to continuous align global and local perspectives as well as perspectives of external stakeholders (e.g. shareholders or governmental organizations).

After having understood the stakeholder of case management, we describe in the following paragraph some guidelines for modeling cases, so that the different stakeholders can align their efforts more effectively and efficiently.

Modeling Guidelines

Every effort to map enterprise operations requires a consistent way to model them.  This ensures good information quality as well as process quality. The Guidelines of Business Process Modeling (GOM) support this from a business perspective [4]. There are six fundamental guidelines:

• Economic Efficiency: This guideline affects all the other guidelines. Case management should only be used where appropriate and where it provides adequate cost-benefit ratio. Many processes in companies are dynamic and evolve in an unstructured manner, but not every one of them should be management by a case management system.
• Correctness:  This guideline refers to syntactical and semantic correctness. A model should be syntactical correct according to the case management modeling language (see also the Case Management Process Modeling (CMPM) – An Introduction). Semantical correctness means that the static and dynamic aspects of the real world are correctly articulated in the case by the case designer and case worker.  Case management can help here to some extent, because it allows evolving processes to anticipate and react to changes in the environment.
• Relevance: Cases should not cover every aspect of a case, but only relevant aspects. An element in a case is irrelevant if it is not utilized by the case worker. Keep in mind that cases contain evolving processes for managing business assets, so new elements may become relevant and old elements may become irrelevant over time.
• Clarity: A case needs to be understood not only by the case designer, but also by case workers. It should be clear to every relevant stakeholder what has been done in a case, what is currently going on and what can be the next steps. We will see later that this is not always given, when considering current technology.
• Comparability: This means a company should use the same guidelines for all cases across the enterprise. Otherwise we cannot compare, for instance, the execution of different cases from a cost-benefit perspective.
• Systematic Design: The different perspectives on a case (e.g. business assets, data, rules, activities or people) should be aligned with each other not only in the case management system, but also in any other system integrated with case management (e.g. records management or enterprise resource planning)

It is crucial for case management to establish these guidelines throughout the organization, because the process can be influenced by different stakeholders and this should not lead to inconsistencies or ambiguities. Some of these guidelines can be supported by adequate case management information system support.

Of course, these guidelines need to be operationalized differently depending on your organization and what you want to achieve with case management. Keeping this in mind, we can now focus on the modeling elements in a case.

What could be Modeled in a Case?

We identified several modeling elements from our experience as well as research literature (e.g. [3,5-6]). A case has a lifecycle and is a container for the following elements:

• Business assets and their lifecycle
• Activities and their lifecycle
• Case Rules
• Data
• People

We explain these elements now in more detail.

Case

A case is a container for any other element relevant to it. It has a lifecycle describing the different states of a case. Of course, a case can only be in one of the states of the lifecycle. The states may also refer to important milestones of a case. This is similar to project management approaches.

We provide in the following figure an example for a case and its lifecycle. It is about an insurance case. It can be in the state “Initial” when it has been created. Further information about the person that needs to be insured as well as basic insurance contracts need to be added to the case, so it can change into the state “Active”. The state “Active” means that there are no problems with the insurance case and that for example further insurance contracts can be added. It may change to a state “Incomplete” if important events in the life of the insured person happen, such as marriage or illness, and important additional insurances are missing. It may also be in the state “Suspended” when the person moves for some time to another country and payments for the insurances in the case are on-hold for this time.  Finally, the case may change to state “Retirement”, e.g. when the person to be insured has died or left the insurance company.

Of course, other cases may have different lifecycles depending on the needs of the organization.

We have found out based on our experience that case workers need to describe also more information about the current state of the case. For example, it seems to be very important for different case workers to provide more information why a case is in a certain state, such as suspended, and what is needed to move it to another state. An insurance case might be suspended, because a case worker waits for information. Other case workers checking the case should know that this information is still missing so that they do not resume the case without it.

A case management system can provide more sophisticated means to do this by utilizing the available elements, such as rules or data.

Business assets

Business assets are of key importance for any company and generate value. It is thus important that business assets of the same category are treated the same to ensure consistent value generation. An example for a business asset in our case is a life insurance contract. We illustrate the business asset “life insurance contract” and its lifecycle in the figure below.

Similar to a case, a business asset can be in different states. For example, an insurance contract it is in state “Initial” when the business asset has been created. It is in state “Active” if all payments for it have been received, the customer did not die and is not retired. It is paid out when the customer is retired, but it is not paid out if payments are missing or the customer died. You can imagine that a lot of business processes are involved in managing a life insurance contract and thus having a business asset as a first class citizen exposing the same consistent view to all processes as well as stakeholders is beneficial to avoid inconsistencies (e.g. the life insurance contract is paid out when the customer died, but still payments are missing).

Several synonyms exist for business assets, such as business artifacts or business objects.

At the moment, we are able to describe business assets. However, how can we control how their state is changed and how do we define the relations to other business assets? For example, a life insurance contract may be related to a disability insurance contract.

There are two solutions: State changes are governed by activities and relations to other business assets can be described using rules.

Activities

Activities describe typical actions that can be performed in a case. There are different types of activities. For example, activities may refer to actions for opening a document and working on it. Other activities may require human action. Further activities may refer to completely automated business processes expressed in the business process modeling notation (BPMN).

Nevertheless, we expect that case management requires mostly human-based activities. Case data can be processed by activities. Activities may also have as an outcome a state change of a case or business asset. They may also have as a prerequisite a specific state of a case or a business asset. For example, new contracts can be added to an insurance case only if it is in state “Initial” or “Active”. Finally, activities may be constrained by rules (see below). For instance, if the age of a customer is above 80 then certain insurance contracts cannot be added to a case.

Similarly to cases and business assets, different types of activities may have different lifecycles. For example, let us assume an activity for paying out a life insurance. It may be required that several people (see below) confirm that the life insurance can be paid out to the customer. An activity with such a lifecycle is illustrated in the following figure:

Other activities may have a simpler lifecycle. For instance, an activity for opening a document may only have the states “Initial”, “Execute” and “Finish”.

Other synonyms for activities are actions or transactions. The activity concepts presented here have been part of our research [3].

Furthermore, we can also leverage novel standards, such as Web Intents or Web Activities to rapidly deploy new enterprise or business network wide capabilities.

Case Rules

Case rules constrain the transition from one state of a business asset, activity or case to another state.  This means they define preconditions and post-conditions when changing the state of one of these elements. For example, a payment activity may only be initiated when the customer has paid 5 years into the life insurance.

They are specific to a case, whereby enterprise-wide business rules may apply to all cases.  Rules allow the user to specify freely in which order activities are performed given only some restrictions (e.g. regulatory ones). Furthermore, rules can be used to specify the relations between different business assets (e.g.  a life insurance contract is bundled with a disability insurance contract).

We distinguish between two types of rules:

• Event-Based Rules that are described using an Event (E) a Condition (C) and an Action (A) – ECA format.
  • Example:
    • Event: Customer dies
    • Condition: Payment of insurance rates over at least 5 years
    • Action: Payment
• Duration-Based Rules (see also [3]) :
  • Example:
    • As long as the life insurance is in state “Active” or “Payments missing”, insurance rates can be paid by the customer
    • As long as the customer is “married”, subsidiaries can be requested from the government

Both types are equally important. Event-based rules are used to react on a given event (e.g. customer dies). However, dynamic processes cannot only be about reacting to events. There is also a need to plan the evolution of a dynamic process to some extent in advance. This can be done using duration-based rules.

It is possible to use one out of the many different rule formalisms and mechanisms to verify correctness of a given set of rules, but intelligent case management systems combine different rule formalisms to do this. This enhances the performance and thus speeds up complex change operations for rules. This is important, because we have argued before that the process evolves with the case and thus is subject to continuous change.

One main challenge here is how rules should visualized to the case workers, so that they always know what has been done, what is currently going on and what can be done next.

Data

We have explained before that case management is particularly suitable for dynamically evolving processes. This implies that not everything can be modeled in a structured manner as a business asset. There is also data that is unstructured and exist in many different systems. For example, the case worker may need to generate a report on the average monthly payment for a life insurance for a certain group (e.g. based on age and ***). Other data can be meta data related to a customer, such as name or birth date.

This means the case management system needs to also support data analytics in form of Mashups composed of data from different sources. Here, it makes sense to rely on the new linked data standard.

People

Although this is the last item, it is one of the most important ones. People are involved in case management processes as we have described in the first figure. Additionally, we have also other stakeholders, such as customers that can be explicitly represented in the case.

Similarly to a case, business assets or activities, people in a case have also a lifecycle. For instance, they may be at the moment working on the case, be on sick leave or have left the company. If we consider more sophisticated case worker management (e.g. delegation of activities) then there are more states in their lifecycle (cf. [7]). Case management systems can help to efficiently and effectively schedule people to cases, activities or business assets.

Customers may also have a special lifecycle. This lifecycle can be very similar to the events in the life of the customer. For example, a customer may be married, divorced or has children. Depending on these events, certain actions might be required (e.g. health insurance for children).

Conclusion

Case Management enables flexible dynamic evolving processes centered around business assets.  It allows a more flexible, but structured way to deal with this type of processes and with business assets.  The stakeholders of a case, most notably the case worker, have a better overview what has been done, what is going on and what can be done next. This is mostly due to the structured and transparent way to model business assets, activities and rules governing them. They do not need check every time every system for business assets or data. Case workers or knowledge workers can work in more innovative and creative ways to solve a case. A case management system can help them to deal with them in a consistent way. This leads to reduced cost, improved delivery of service and has the potential to generate new ways of revenue previously locked in enterprise silos. Finally, case management systems can be used to capture dynamic evolving processes and improve the way they handle business assets.

We described how cases can be modeled to describe these kinds of processes and business assets. Some of these elements may become part of the Case Management Process Modeling (CMPM) – An Introduction.

What is next?
In the next blog entry, I will describe different system architectures for case management.  This is relevant for Enterprise Architects, Solution Architects and Developers. I plan further blog entries on research challenges for case management.

Acknowledgements

This work results from the collaboration between SAP Research and the SCORE group at LORIA-INRIA-CNRS of the Université de Lorraine,  Nancy, France.

References/Further Reading

 [1] Olding, E. & Rozwell, C., Expand Your BPM Horizons by Exploring Unstructured Processes, G00172387, Gartner, 2009                

[2] K. Bhattacharya, N. S. Caswell, S. Kumaran, A. Nigam, and F.Y. Wu. "Artifact-centered operational modeling: Lessons from customer engagements." IBM Systems Journal, 46(4):703- 721, 2007

[3] Franke, Jörn: Coordination of Distributed Activities in Dynamic Situations. The Case of Inter-organizational Crisis Management, PhD Thesis (Computer Science), to be published, LORIA-INRIA-CNRS, Université de Nancy/Université Henri Poincaré, France, 2011.

[4] Becker, Jörg; Michael Rosemann; von Uthmann, Christoph: Guidelines of Business Process Modeling, Business Process Management, 2000.

[5] de Man, Henk: Case Management: A Review of Modeling Approaches, BPTrends, January, 2009.

[6] Reijers, H.A.; Rigter, J.H.M.; van der Aalst, W.M.P.: The Case Handling Case, International Journal of Cooperative Information Systems, Vol. 12, No. 3, p. 365-391, 2003.

[7] Gaaloul, Khaled: A Secure Framework for Dynamic Task Delegation in Workflow Management Systems, PhD Thesis (Computer Science), LORIA-INRIA-CNRS, Université de Nancy/Université Henri Poincaré, France, 2010. 

Have you ever tried to manage a cold chain for medicine in a region with temperatures about 40° degrees? A region with no roads, an unclear situation after several earthquakes, an unstable political situation and you will have to work for the first time with many very different organizations to deliver the goods. By the way the medicine comes from all over the world… And have you thought about where you get the gas from when there is no map of gas stations and potentially many different suppliers? Of course, not everything can be planned ahead, further earthquakes may strike or people requiring medicine can be brought to new locations.

You think this is impossible to manage? This is one of the typical tasks of humanitarian aid organizations that help people all over the world….

Clearly, this domain is a somewhat extreme example for supply chain management, but we believe it is worth to research the problems related to information system support in this challenging scenario. Research in this domain can also bring benefits to typical enterprise supply chains from a management and technology perspective, given the fact that supply chains in business networks need to become more and more agile as well as flexible.

We present in this blog a challenging case for supply chain management and its information system support: humanitarian aid in sudden on-set disasters. We discuss solutions from a management [5-7] and information system support perspective [2-4]. We present first ideas for integrating them [1]. More particularly, we discuss from a management perspective the use of reference process models and tool support for dynamic ad-hoc processes from an information system perspective. We propose a process-based approach. In such an approach, the activities and their relations are made explicit to the stakeholders. It is clear for every stakeholder what has been done, what is currently going on and what can be done next. The activities are coordinated by humans based on their judgment of the complex situation.

Reference Process Models for Humanitarian Supply Chain Management / Business Process Library

Reference process models represent in our case generalized practices of humanitarian supply chain operations. They are based on extensive interviews and empirical studies with leading humanitarian aid organizations (e.g. Worldvision or MSF) [5]. You can compare a reference process model with a Business Process Library (BPL), where you can look for typical process, select the one you need, adapt and execute it. Of course, accountability and responsibilities can be defined according to a RACI Matrix [9].

We provide in the following figure an example process taken from the reference model described by [1].

Ad-Hoc Coordination of Activities Driven By Humans in Dynamic Situations

However, current information systems used by humanitarian aid organizations or disaster response organizations have some limitations with respect to coordination [2]. All information about activities and their relations can be found in a large pile of unrelated e-mails, phone exchanges or faxes. Information about currently executed activities can be found partially also on whiteboards. The next steps can be found in incident action plans. Every time something new is happening, this information needs to be related again from scratch. Contemporary process management tools focus on operational business processes with few predictable exception - obviously this is not the case in our scenario. Tool support is thus desired that allow modeling correctly the activities and their relations (what has been done, what is currently going on and what can be done next). Contrary to existing process management systems, the process cannot be fully specified in advance and is subject to continuous change. In fact, the processes evolves with the situation. Monitoring deviations from the process need to be visualized to the users to highlight shifting goals that lead to reassessment of activities and their relations. Some activities need to be related cross-organizations. For example, one organization can be responsible for deploying emergency teams and another organization performs a need assessment (cf. previous figure).  This is supported by our system by sharing selected activities among organizations and each organization can define relations between shared and internal activities. Consequently, the system needs to ensure correctness of the model of activities and relations cross organizations. Furthermore, it is crucial that deviations from the model and how shared activities have been executed are highlighted to every relevant stakeholder. It is more likely that deviations occur on the inter-organizational level, because each organization has its own goals and operating procedures. We designed and implemented such a system (see [1,2]).

Integration

Integration of these approaches means that (1) the reference process model is used to support a common understanding between different organizations and (2) our tool is used to create a consistent common view as well as coordination support for activities with relations cross organizations [1].

We illustrate a simple example in the following figure (cf. also the previous figure) [1]. Organization A is responsible for deploying an emergency team and for communicating the needs to other organizations. Organization B has its focus on exploratory teams and requesting goods for the people. Both organizations rely on initiating a needs assessment and prioritizing needs. They can be performed by the organization with the best skills in these areas.

Of course, this is just a simple example and we did not show here the dynamics of the situation. For example, organization B might already request some goods without waiting for the needs assessment. This needs to be highlighted to organization A so it can communicate the correct needs to the other organizations. The reference process model can thus be used in our proposed tool [2,5] to deploy and coordinate the process in a dynamic situation, so that every organization knows what has been done, what is currently going on and what can be done next.

We are looking for your comments!

It can be observed that the concepts described here are related to the WS-Human Task Standard [10] and the emerging OMG standard for Case Management [11]. More precisely, we describe also how they can work on the inter-organizational level, where selected shared activities are replicated in the systems managing different related cases.

People

The following people work on this project at SAP Research FRANCE:

• Jörn Franke, Business Intelligence & Public Security, SAP Research, France / LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France
• Adam Widera, Chair of Information Systems and Supply Chain Management, European Research Center for Information Systems (ERCIS), University of Münster, Germany
• François Charoy, LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France
• Bernd Hellingrath, Chair of Information Systems and Supply Chain Management, European Research Center for Information Systems (ERCIS), University of Münster, Germany
• Cédric Ulmer, Business Intelligence, SAP Research, France

Acknowledgements

This work results from the collaboration between Public Security, SAP Research FRANCE and the SCORE group at LORIA-INRIA-CNRS of the Université de Lorraine,  Nancy, France. The research was partially funded by means of the German Federal Ministry of Education and Research and the French government.

References

[1] Franke, Jörn; Widera, Adam; Charoy, François; Hellingrath, Bernd; Ulmer, Cédric: Reference Process Models and Systems for Inter-Organizational Ad-Hoc Coordination - Supply Chain Management in Humanitarian Operations, short paper, 8th International Conference on Information Systems for Crisis Response and Management (ISCRAM'2011), Lisbon, Portugal, 8-11 May, 2011.

[2] Franke, Jörn: Coordination of Distributed Activities in Dynamic Situations. The Case of Inter-organizational Crisis Management, PhD Thesis (Computer Science), to be published, LORIA-INRIA-CNRS, Université de Nancy/Université Henri Poincaré, France, 2011.

[3] Franke, Jörn; Charoy, François; El Khoury, Paul: Collaborative Coordination of Activities with Temporal Dependencies, 18th International Conference on Cooperative Information Systems (CoopIS 2010), Heraklion, Créte, Greece, 2010.

[4] Franke, Jörn; Charoy, François; Ulmer, Cédric: Handling Conflicts in Autonomous Coordination of Distributed Collaborative Activities, 20th IEEE International Conference on Collaboration Technologies and Infrastructures (WETICE'2011), Paris, France, 27-29 June, 2011.

[5] Blecken, A. : Humanitarian Logistics: Modelling Supply Chain Processes of Humanitarian Organisations, Haupt Verlag, Stuttgart, 2010.

[6] Tomasini, R., van Wassenhove, L.: Humanitarian Logistics, Palgrave, MacMillan, Basingstoke, 2009.

[7] Tufinkgi, P. : Logistik im Kontext internationaler Katastrophenhilfe : Entwicklung eines logistischen Referenzmodells für Katastrophenfälle, Haupt Verlag, Stuttgart, 2006.

 [8] Schaad, A.; Ulmer, C. & Gomez, L. Rescueit - Sécurisation d'une chaine logistique internationale, Workshop Interdisciplinaire sur la Sécurité Globale, 2010, http://www.sichere-warenketten.de/

[9] Wikipedia, RACI matrix, http://en.wikipedia.org/wiki/Responsibility_assignment_matrix, retrieved 18.07.2011

[10] Wikipedia, BPEL4People, http://en.wikipedia.org/wiki/BPEL4People, retrieved 18.07.2011

[11] OMG, Case Management, http://www.omg.org/news/meetings/workshops/SOA-HC/presentations-10/13_F1_Cummins.pdf, retrieved 18.07.2011

In this blog entry we describe our research on different paradigms of distributed process management that have emerged over the last years. It is part of our research within Public Services team at the SAP Research Center (Sophia Antipolis) / SAP Research FRANCE.

We present the four basic paradigms underlying distributed process management including two novel promising paradigms that emerged at SAP Research.

Four Different Paradigms of Distributed Process Management

Overview

We see that four different paradigms emerge from this matrix. We describe these paradigms now and provide examples for them.

Individual Modeling/Centralized Execution

These are standard workflow systems (e.g. Netweaver BPM or SAP Business Workflow). The following figure provides an example for this paradigm. The process designer models the process and deploys it on a centralized server for execution by a workflow engine.

Individual Modeling/Distributed Execution 

Many approaches have been proposed in this area (e.g. [3-5]). The basic idea is that one entity defines a public process and this process is split into different pieces. The different entities then execute their part of their process in a distributed manner. Although the body of knowledge is very mature in this area and different research prototypes exist, it has not yet found its way into commercial products. The problem faced here is that there needs to be one central deciding entity who defines what the public process is (i.e. the organizations part of the process cannot act autonomous) - this is more a business/governance problem than a technical problem. In the following figure we illustrate how this paradigm works: A workflow designer defines a process and the parts of the process are distributed to different servers for execution.

Collaborative Modeling/Centralized Execution 

This is a new paradigm. It has recently emerged in form of the SAP Research Prototype "Gravity – Collaborative Business Process Modelling within Google Wave" which allows different distributed modelers to model the process via Google Wave or SAP Streamwork collaboratively and to import the model into the SAP Netweaver BPM engine to execute it centralized on a SAP Netweaver BPM server. Many interesting use cases have been described (e.g. M&A). The following figure provides an example for this paradigm. Process designers collaboratively model the process and the process is deployed for centralized execution on a workflow server (e.g. SAP Netweaver BPM).

Collaborative Modeling/Distributed Execution

This is a new paradigm. It is part of our research and has also been implemented in Google Wave. The idea is that different entities create activities and share activities with other entities. They also define dependencies/constraints (e.g. temporal ones) between their own activities and the shared activities. For example, in a crisis response scenario, the police commander can model that if “Protection of Residential Area from the Flood” by the fire fighters fails then “Evacuation of Residential Area” by the police starts its execution. This is very interesting for heterogonous and autonomous working organizations (e.g. in crisis management), because it is not required that different entities agree on a common public process. (Shared) Activities can change their state (i.e. they are executed in a distributed manner) and this may violate dependencies to these activities defined by different organizations in different models. This approach overcomes the problems of the individual modeling/distributred process execution approach.

The figure illustrates this paradigm using a crisis response management scenario. People can share activities and their current state with the Shared Activity Workspaces (SAW, comparable to distributed servers) of other organizations. Shared activities are illustrated with dotted borders.  The other organizations can define dependencies/constraints (e.g. temporal ones) to the shared and their own activities. For example, the military commander has shared the activity “C” with the fire fighter commander. The fire fighter commander creates a dependency to his/her own activity “A”. When activity “C” changes its state (e.g. initiated by the military) then this may violate dependencies in the SAW of the fire fighters. Sharing takes place on a social basis (i.e. from person to person) and it is not required to share activities. For example, the military commander and medical staff do not share activities.

Conclusions

We think that all paradigms are important and it depends on the process and the environment which paradigm should be used. One organization will probably use all four paradigms. We see a big need for providing software for all paradigms, in particular the last two, because not all paradigms are equally well supported by software.

We are looking for your comments!!!

What do you think of these paradigms for distributed process management?

The following people work on this project

• Jörn Franke, Public Security, SAP Research Center (Sophia Antipolis), France / LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France

• François Charoy, LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France

• Cédric Ulmer, Public Services, SAP Research Center (Sophia Antipolis), France

Acknowledgements

This work results from the collaboration between Public Security, SAP Research FRANCE and the SCORE group at LORIA-INRIA-CNRS of the Université de Lorraine,  Nancy, France. The research was partially funded by means of the German Federal Ministry of Education and Research under the promotional reference 01ISO7009 (see [6]) and the French government within the RescueIT project [7]. Another part was funded by the CIFRE PhD funding scheme of the French government.

References

[1] Franke, Jörn; Charoy, François: Design of a Collaborative Disaster Response Process Management System, 9th International Conference on the Design of Cooperative Systems (COOP'2010), Aix-En-Provence, France, 19-21 May, 2010.

[2] Franke, Jörn; Charoy, François; Ulmer, Cédric : Coordination and Situational Awareness for Inter-Organizational Disaster Response, 10th IEEE International Conference on Technologies for Homeland Security, Boston, WA, USA accepted

[3] Frederic Montagut, Refik Molva: Enabling pervasive execution of workflows. CollaborateCom 2005

[4] Walid Fdhila, Ustun Yildiz, Claude Godart: A Flexible Approach for Automatic Process Decentralization Using Dependency Tables. IEEE 7th International Conference on Web Services (ICWS 2009), July 6-10, 2009, Los Angeles, CA, USA : 847-855.

[5] Wil M. P. van der Aalst, Process-oriented architectures for electronic commerce and interorganizational workflow, Information Systems, Volume 24, Issue 8, December 1999, Pages 639-671

[6] http://www.soknos.de 

[7] Schaad, A.; Ulmer, C. & Gomez, L. Rescueit - Sécurisation d'une chaine logistique internationale, Workshop Interdisciplinaire sur la Sécurité Globale, 2010, http://www.sichere-warenketten.de/