Gustaf Juell-Skielse

Erik Perjons
email: perjons@dsv.su.se

VAMEE: A Value Aware Method for Evaluating Inclusive E-Government Initiatives

Keywords: e-government, benefit analysis, enterprise modeling, goal modeling, value modeling, requirements engineering

The growing use of ICT solutions for improving the public sector has created a need for valuating e-government initiatives. A number of methods for this purpose have been developed, but they are typically restricted to analyzing the benefits and costs of only one single actor. There is, therefore, a need for methods that take a broader view and take into account entire networks of actors. This paper proposes a novel method, called VAMEE, the purpose of which is to produce a well-grounded and easily understandable valuation of an e-government initiative that takes into consideration the benefits, costs, and interrelationships of all actors concerned. The basis of the proposed method is a combination of enterprise modeling techniques, in particular goal modeling and value modeling, with an established method for cost benefit analysis (i.e. Peng). VAMEE is designed to be inclusive, easily understandable, and visual. These properties of the method will support accurate and unbiased valuations as well as improved innovation in the development of e-government initiatives.

Introduction

The growing interest in applying ICT to achieve better government [START_REF] Grönlund | Ten Years of E-Government: The 'End of History' and New Beginning[END_REF] emphasizes the need for benefits valuation methods for e-government initiatives. E-government initiatives include investments in e-services to improve citizen service [START_REF] Gupta | E-government evaluation: A framework and case study[END_REF] as well as integrated processes to enhance government back office operations [START_REF]European Commission, A Digital Agenda for Europe[END_REF]. Through privatization and public private partnerships [START_REF] Savas | Privatization and Public-Private Partnerships[END_REF], e-government initiatives involve and affect entire networks of actors that depend on each other in terms of value creation, including actors such as citizens, employees at different levels of government, third party service providers, and companies [START_REF]Local self-government[END_REF]. Often, the benefits and costs of egovernment initiatives are unevenly distributed among the actors, and one actor could carry a large portion of the costs while most of the benefits are reaped by other actors [START_REF] Juell-Skielse | New Challenges for e-Government: Value Realization among Independent Actors[END_REF]. For example, local governments may carry costs for e-service platforms that primarily lead to administrative savings at third party service providers.

There are a number of models and methods available to measure and control egovernment initiatives. The Value measuring methodology [START_REF]The value measuring methodology: Highlights. Washington, DC7 CIO Council, Best Practices Committee[END_REF] by the CIO Council and the Guide for benefit realization [START_REF]E-Government Delegation. Vägledning i nyttorealisering[END_REF] by the e-Government Delegation are two examples of methods developed for measuring e-government initiatives. These methods include definitions of key concepts and steps to follow in order to measure costs and benefits of investments in e-government. However, they do not take into account the multitude of actors involved and their interdependence in terms of value creation. Hence, the methods take an internal rather than an external perspective on egovernment and focus on the benefits and costs of only one single actor. This restricted perspective limits the understanding of how investments in e-government enables value creation among networks of actors, which in turn may lead to erroneous investment decisions and slow e-government development and uptake.

The complexity of e-government initiatives has created a need for a practical approach that takes into account all actors involved in value creation, visualizes their relationships, and estimates the total value of such initiatives. In two previous papers [START_REF] Juell-Skielse | New Challenges for e-Government: Value Realization among Independent Actors[END_REF][START_REF] Juell-Skielse | Improving E-Government through Benefit Analysis and Value Modeling[END_REF], we have presented and demonstrated such an approach for benefits valuation of e-government initiatives. The approach combines two established approaches, Peng [START_REF] Dahlgren | Make IT profitable: PENG -A practical tool for financial evaluation of IT benefits[END_REF] and value modeling [START_REF] Gordijn | Value based requirements engineering: Exploring innovative e-commerce idea[END_REF], to visualize both the actors involved and the value creation that takes place within and between these actors.

In this paper, the purpose is to convert and extend the combined approach into a thorough and easily applicable method by clarifying and detailing its design objectives as well as its phases and activities. In addition, we expand the scope to include key aspects of change management, such as actor involvement and goal modeling. The method is named A Value Aware Method for Evaluating Inclusive E-Government Initiatives (VAMEE). The goal of VAMEE is to produce a wellgrounded and easily understandable valuation of an e-government initiative that takes into consideration the benefits, costs, and interrelationships of all actors concerned. The basis of VAMEE is a combination of enterprise modeling techniques, in particular goal modeling and value modeling, with an established method for cost benefit analysis, i.e. the Peng method [START_REF] Dahlgren | Make IT profitable: PENG -A practical tool for financial evaluation of IT benefits[END_REF].

The paper is structured as follows. Section 2 gives the theoretical bases of the proposed method and describes the fundamentals of goal modeling, value modeling, and the Peng method for cost benefit analysis. Section 3 discusses the design science approach used for developing VAMEE, and introduces a running example based on a case study. Section 4 describes VAMEE in detail, and Section 5 provides a brief demonstration and evaluation of the method. Section 6 compares VAMEE to other valuation approaches in the literature, and Section 7 concludes the paper and suggests directions for future work.

Theoretical Bases for VAMEE

The VAMEE method is based on three types of modeling approaches: cost benefit analysis using Peng, value modeling, and goal modeling.

Cost Benefit Analysis Using Peng

Peng has become a popular method for cost and benefits evaluation of IT-investments and process changes, in both the private and the public sector [START_REF] Dahlgren | Make IT profitable: PENG -A practical tool for financial evaluation of IT benefits[END_REF][START_REF] Dahlgren | Öka nyttan av IT i vården! : att skapa och värdera nytta i verksamheten med hjälp av PENG-modellen[END_REF]. It is presented as a "structural method to evaluate, in dollars, all the different types of benefits that IT generates within an operation" [10, p.26]. It is similar to the Value Measurement Model [START_REF]The value measuring methodology: Highlights. Washington, DC7 CIO Council, Best Practices Committee[END_REF] and includes both soft and hard measures [START_REF] Gupta | E-government evaluation: A framework and case study[END_REF]. The method consists of ten steps, and ideally it involves users and managers as well as functional and technical specialists from an organization. In Peng, cost and benefits are identified in workshops and organized in tree structures that depict the relationships between benefits, costs, process changes and IT functionality. All cost and benefits are expressed in monetary terms, although the intention is not to achieve accounting precision. In order to validate the results, the benefits are classified as direct, indirect and intangible benefits. Identification of IT costs is supported by a predefined list of types of costs. In the final step, the net value of the benefits and costs are calculated, and managers responsible for the realization of the benefits are appointed.

In addition, the many books on Peng provide a large number of cases from a variety of industries where the method has been applied. Through case based reasoning [START_REF] Riesbeck | Inside Case-based Reasoning[END_REF], participants can solve their own case by using or adapting existing cases. In a study of the Peng method [START_REF] Fredriksson | Beyond Assessing Economic Net Value from Electronic Commerce-Supported Business Process Redesign -a Discussion of the PENG Method[END_REF], its strengths were found to be the business process oriented approach, the mixture of personnel categories participating in the evaluation, as well as the inclusion of assessing soft benefits. Weaknesses were found to be the difficulties of attracting and involving the right participants, the subjective nature of assessment, and difficulties in verifying the net values.

The main terms from the Peng method, benefit and cost, are in this paper defined as:

A benefit is an increase in a resource, expressed in monetary terms, that is caused by the implementation of an e-government initiative.

A cost is a decrease in a resource, expressed in monetary terms, that is caused by the implementation of an e-government initiative.

Value Modeling

A value model is a representation of a network of cooperating actors that together create value through resource transfers. A value model aims to provide a high level view of a value network using a limited set of modeling elements, such as actor, resource, and resource transfer. Value modeling can be a basis for profitability analysis, that is, reasoning about the economic viability of the actors participating in a value network; for process and service design, that is, as a foundation for designing business processes and services for involved actors in the network; and for relationship analysis, that is, establishing roles and responsibilities among different actors in the network.

There exists a number of value modeling techniques and ontologies, such as REA [START_REF] Mccarthy | The REA Accounting Model: A Generalized Fra,ework for Accounting Systems in Shared Data Environment[END_REF], BMO [16] and e3value [START_REF] Gordijn | Value based requirements engineering: Exploring innovative e-commerce idea[END_REF]. The value modeling technique used in this paper is in line with the e3value technique. However, both the syntax and semantics differ in some respects in order to arrive at a technique that is as simple as possible given its purpose.

The main modeling elements in the value modeling technique used in this paper are: actor, resource, and resource transfer, which are defined as follows:

An actor is a human being, role, organization or organizational unit that can participate in the transfer of resources. Actor can refer to an individual actor (e.g. "Child Care Administration"), or a role (i.e. actor category, such as "Parent" and "Day Care Unit") that can be taken by multiple individual actors. In the notation, the actor is represented as a rectangle with a stick figure and the actor's name, see Figure 1.

An economic resource is an object that is viewed as being valuable by some actor and such that an actor can have legal control over it and transfers it to other actors. A resource can be categorized into one of the following categories: a good (e.g. "Food"); a service (e.g. "Day Care Service"); information (e.g. "Child Care Usage Info"); and money (e.g. "Child Care Fee"). In the notation, an economic resource is represented as a label on the transfer symbol (i.e. an arrow), and the category of the economic resource is represented as a label between square brackets after the economic resource label, see Figure 1.

A resource transfer is an action in which the right on an economic resource is handed over from one actor to another. For example, a day care service (an economic resource of the category "service") is transferred from a day nurse unit to a parent, which means that the parent has the right to use the service. In the notation, the transfer is represented as an arrow between two actors, see Figure 1. Value models could be constructed on different levels. In this paper we use two different levels: operational and policy/planning, see Figure 2. A value model on the policy/planning level includes resource transfers that support planning (e.g. scheduling) and commitments (e.g. orders), see Figure 2. These policy/planning level economic resource transfers are needed in some business settings before the transfers of economic resources on the operational level can be carried out. Another way to put it is that the results of economic resource transfers on the policy/planning level are used to regulate the economic resource transfers on the operational level.

Goal Modeling

A goal model is a representation of enterprise goals, usually structured as a hierarchy in which high levels goals are decomposed into sub-goals (which are supported by means). Goal modeling can be used to identify and structure desirable states of an actor in order to drive the actor towards these states.

There exists a number of goal modeling techniques and ontologies, such as i* [START_REF] Yu | Modeling Strategic relationships for process engineering[END_REF] and the Business Motivation Model (BMM) [18]. The goal modeling technique used in this paper is in line with the BMM technique. However, both the syntax and semantics differ in some respects in order to arrive at a technique that is as simple as possible given its purpose.

The main modeling elements in the goal modeling technique presented in this paper are goals and relations between these.

A goal is a statement about a desirable state of an actor. A goal can be decomposed into several sub-goals.

Motivating the Theoretical Bases

The VAMEE method is based on three types of modeling approaches: cost benefit analysis using Peng, value modeling, and goal modeling. Peng is a participative, bottom-up approach for identifying and valuating of IT-enabled benefits and costs [START_REF] Dahlgren | Make IT profitable: PENG -A practical tool for financial evaluation of IT benefits[END_REF]. However, Peng focus on the benefits and costs of one single actor and does not take into account the multitude of actors involved in e-government initiative. Value modeling is a well established top-down approach for visualizing the complete network of actors involved in the value creation process. A value model provides a high level view of the resources that are exchanged among the actors of a network. Therefore, value modeling can extend the one actor's perspective of Peng by taking a network perspective. Goal modeling helps in identifying and formulating desirable future states of an actor, and supports the Peng method's identification of benefit and cost of e-government initiative. All three approaches aid in the understanding of how IT, process changes and economic value are interrelated and how an e-government initiative affects actors involved in a value network.

Methodological and Empirical Bases for VAMEE

This section describes the research strategy used, the objectives of VAMEE, and the case study in which the method was designed and applied. The case study is also the basis for the running example used in Section 4.

Design Science

For developing the method, we have used design science [START_REF] Hevner | Design science in information systems research[END_REF][START_REF] Peffers | A Design Science Research Methodology for Information Systems Research[END_REF] as a research strategy, in particular Peffers et al.'s model for design research [START_REF] Peffers | A Design Science Research Methodology for Information Systems Research[END_REF], which consists of six steps: 1. Identify problem and motivate 2. Define objectives of a solution 3. Design and develop 4. Demonstration 5. Evaluation

Communication

The problem and its motivation have been discussed in Section 1. In the following sections, the remaining steps are addressed.

Objectives of the Method

The overall objective is to provide a method for measuring and controlling egovernment initiatives, which is applicable to networks of actors and can be easily adopted in practice. This overall objective is broken down into three specific objectives for the method:

 Inclusive in terms of involving all actors of a network  Comprehensible for actors in the public sector  Complementary to commonly used project management and system development methods

Case Study

VAMEE has been designed during an e-government initiative study in the area of child care in Järfälla, a Swedish municipality [START_REF] Juell-Skielse | New Challenges for e-Government: Value Realization among Independent Actors[END_REF][START_REF] Juell-Skielse | Improving E-Government through Benefit Analysis and Value Modeling[END_REF]. The method has been applied and the result has been used for refining the method.

The municipality Järfälla is one of Sweden's 290 municipalities, located 20 kilometers Northwest of Stockholm. With 65 000 inhabitants, it is, by Swedish standards, a relatively large municipality. More than 3 000 children in the age of 1-5 years are engaged in the child care provided by the municipality. Approximately three fourths of the day nurse units are owned by the municipality, and one fourth is privately owned.

The interaction between parents and child care administration is made up of four processes:  Application and placement offer  Schedule changes  Salary changes  Termination of contract

The interaction between parents and child care administration are based on paper forms that are sent using traditional mail services. A lot of phone contacts are made between parents and child care administrators, especially during the process of application and placement.

Schedule changes, which is the basis of the e-government initiative used as a running example in this paper, are primarily driven by changes in parents work schedules and are handled through forms that are handed in manually at the day nurse units. In 2007, Järfälla introduced e-services in order to replace the manual forms and the physical handling of these forms. value modeling: a top-down approach for visualizing the entire network of actors involved in the value creation process as well as a value modeling ontology [START_REF] Gordijn | Value based requirements engineering: Exploring innovative e-commerce idea[END_REF]. In addition, VAMEE emphasizes iteration, both within and between phases. For example, goals and value network descriptions are refined in several iterations, moving from ideas to detailed descriptions and commitments. Through iteration, the dynamic nature and learning aspects of technological change is recognized.

Description of VAMEE

The Motivate Phase

The phase Motivate aims at establishing a preliminary understanding of the goal and scope of the e-government initiative under consideration and to mobilize participants for the work in the following phases. The phase includes the following activities: Set Goals for Actors, Involve Participants, and Initial Design of Value Network.

Set Goals for Actors

The activity Set Goals for Actors aims at formulating goals for the e-government initiative, e.g. to improve the quality of citizen service and to become more cost effective. There exists a multitude of independent actors in the public sector and it is important to clarify goals for each actor. Typically, this activity would start with discussions within one actor or in discussions between a small numbers of actors. In iterations between this activity and the activities Initial Design of Value Network and Involve Participants, actors affected by the e-government initiative are successively identified and subsequently involved in goal discussions. The activity is completed when all actors affected by the e-government initiative have formulated and agreed on individual goals and their relations. Conflicts between the goals need to be managed in this activity, or in the second phase and the Synthesize activity. The output of this activity is goal statements for each actor.

Goal: Low adm costs

Goal: Low adm costs

Goal: Satisfied parents

Goal: Satisfied parents

Goal: Low fees

Running example: In the case at Järfälla municipality, three actors were identified: the Child Care Administration at the municipality, a private Day Nurse Unit, and the parents. The main goals, in the context of the e-government initiative, for the Child Care Administration and the Day Nurse Unit were Low costs for administrative work and Satisfied parents, while the main goals for the parents were High flexibility and Low fees, see Figure 4. These goals were elicited in discussions with participants representing the three actors.

Involve Participants

The activity Involve Participants aims at involving participants representing all actors in the value network. Ideally, both managers and functional experts from each actor are involved, thereby ensuring that decision powers, as well as operational understanding, are available. In this activity, the participants approve of the preliminary goals and they develop a shared understanding of how VAMEE will be applied. As the value network is scoped, the number of actors may increase, and more participants need to be involved in the work. The activity is completed when participants from all actors have taken an active part in the initial cost benefit analysis; have committed to preliminary goals; and have arrived at an adequate understanding of how VAMEE will be applied.

Running example: In the Järfälla case, relevant participants for the Child Care Administration included both managers and public servants, while the Day Nurse Unit included managers as well as child-care staff, see Figure 5.

Figure 5. The actors and participants/roles in the e-governmental initiative

Initial Design of Value Network

The activity Initial Design of Value Network aims at specifying actors as well as resource transfers in the value network for the e-government initiative. This can be a highly complicated task when analyzing the public sector. First, there are many different governmental organizations at local, regional and national levels that regularly collaborate to provide governmental services to the citizens. Second, in most governmental areas, there are public organizations that source or purchase the services, using tax revenue from citizens. Third, there are organizations that will provide the services. In many countries, the latter type of organizations can be publicly or privately owned, but funded by public organizations.

The result of this activity will be a visualized draft of a value network for the egovernment initiative, which will be refined in the next phase.

Running example:

The value network for the Järfälla case when introducing a schedule change service is shown in Figure 6. The diagram identifies the three actors of the case as well as the main resource transfers between them. As can be seen, these resources are various kinds of information in digital form as well as an e-service. For example, the parents will provide the Day Nurse Unit with information on their planned child care usage in digital form, and the Child Care Administration will provide parents with the e-service for changing the schedule.

Figure 6. A Value model on policy level of a child care network

The Investigate Phase

The phase Investigate aims at identifying and quantifying costs and benefits for each of the actors involved in the e-government initiative. Investigate is made up of the activities Analyze Benefits and Costs and Synthesize Value Network.

Analyze Benefits and Costs

The activity Analyze Benefits and Costs aims at identifying and estimating costs and benefits for each of the actors in the value network. Benefits and costs are identified in workshops and organized in a tree structure that depicts the relationships between benefits, process changes, and IT functionality. Identification of IT costs is supported by a predefined list of cost types. All benefits and costs are expressed in monetary terms although the intention is not to achieve accounting precision. The net value of the benefits and costs are calculated. Running example: The benefits describe and quantify in monetary terms what improvements can be achieved if the e-government initiative is implemented, including both e-services and administrative back-office systems. For reasons of space, we only show the benefits of the Day Nurse Unit, see Figure 7. The costs as well as the relations between the costs, benefits, business processes and IT are showned in [START_REF] Juell-Skielse | Improving E-Government through Benefit Analysis and Value Modeling[END_REF]. The benefits for the goal "Low Adminstrative Costs" for Day Nurse Unit are: D1. Less questions and contacts (saving 39 000 SEK/year). The form used by the e-service includes information and controls that reduce the need for direct contact with the day nurseries. D2. Automated diary and delivery (saving 39 000 SEK/year). Manual diary entry is replaced by automated handling by a workflow system. D3. No data entry (saving 104 000 SEK/year). There is no longer need for manual data entry at the day nurse units since data is already entered by parents using the e-service. D4. Automated archiving (saving 26 000 SEK/year). Archiving is automated in the workflow system and replaces physical archives. D5. Improved resource planning (N/A). Schedules provided by parents are used for resource planning at day nurse units. The day nursery staffing plans become more accurate when the quality of the information provided by the parents improves. However, the value of this item was not assessed in the cost benefits analysis.

Synthesize Value Network

The activity Synthesize Value Network aims at mapping the results from the activity Analyze Benefits and Costs to the value model. In this activity, the benefits and costs from the Peng analysis will be mapped to the transfers of economic resources visualized in the value model, created in the previous phase. The benefits and costs are shown within parentheses after the resource labels. If a benefit or cost cannot be mapped to a resource transfer, another resource transfer needs to be added to the value model. The final step is to analyze the distribution of values visualized in the value model (i.e. actors and their transfers of economic resources) together with the results from the benefit and cost analysis in the previous activity. This will support government officials to prioritize e-government initiatives.

Running example: The initial value model from Figure 6 is in Figure 8 extended by mapping its resource transfers to benefits (for example benefits D1 to D5 presented in the previous step). That is, the model in Figure 8 shows which resource transfers that contribute to the various benefits. (Costs are not shown in Figure 8.)

Demonstration and Evaluation

Most parts of the method have been used in a case at Järfälla municipality, as described in Section 3. The experiences from this use provide an initial demonstration of the method and indicate that the method supports users in identifying actors and benefits that were not included at the beginning of the Järfälla municipality egovernment initiative, [START_REF] Juell-Skielse | Improving E-Government through Benefit Analysis and Value Modeling[END_REF]. The method has not yet been empirically evaluated in a thorough way, but we here offer an evaluation in the form of informed arguments:

 Inclusive in terms of involving all actors of a network: The visualization of the value network supports the identification of all relevant actors in an e-government initiative. Furthermore, as all actors are visualized in the network, it becomes easier for them to understand their role and contribute to the development and evaluation of the initiative. There is also a specific activity in VAMEE, Involve participants, that supports this objective.  Comprehensible for actors in the public sector: VAMEE is based on well-known concepts such as actor, goal, resource, benefit and cost, which are all widely used in the public sector. Furthermore, the method's results are offered in a visual form.

 Complementary to commonly used project management and systems development methods:

The method includes a value network perspective which is usually not considered in project management and systems development methods, thereby providing a complementary perspective to such methods. Furthermore, the method can easily be included, as a plug-in, in any project management or systems development method, as the goals in the VAMEE method can work as an interface to the goals specified in other kinds of methods.

Related Research

The increased investments in e-government in recent years have led to an increased interest in evaluating the results of e-government investments. Therefore, many researchers and practitioners have presented and discussed methods for evaluation, but also which types of benefits and costs shall be used for measuring investments in the public sector. In this paper, value modeling, goal modeling and benefit analysis based on Peng are combined in order to produce an evaluation of an e-government initiative.

Value models have been used for profitability analysis [START_REF] Gordijn | Value based requirements engineering: Exploring innovative e-commerce idea[END_REF][START_REF] Johannesson | Resourse Analysis and Classification of Purpose Driven Value Model Design[END_REF]. Such an analysis addresses the volumes and monetary values of resource exchanges in a value network. The aim is to analyze the economic viability of the network. However, existing profitability analyses using value models have no support for how to estimate the revenues and costs. The VAMEE method includes such support.

Using process analysis [START_REF] Kohli | Towards Developing a Framework for Measuring Organizational Impact of IT-Enabled BPR: Case Studies of Three Firms, The Data Base for Advances in Information Systems[END_REF][START_REF] Becker | Process-Based Governance in Public Administration Using Activity-Based Costing[END_REF] as the basis for evaluating the result of egovernment investments is a common approach in research, but these are mainly focusing on one actor and not the entire network of actors, which is the focus of the VAMEE method.

There are many research papers specifying which benefits, costs, and dimensions of benefits and costs that need to be measured in cost benefit analysis [START_REF] Gupta | E-government evaluation: A framework and case study[END_REF][START_REF]The value measuring methodology: Highlights. Washington, DC7 CIO Council, Best Practices Committee[END_REF][START_REF] Grimsley | e-Government information systems: Evaluation-led design for public value and client trust[END_REF]. In general, both researchers and practitioners have stated that such benefits, costs, or dimensions need to consist of both monetary values and softer values, such as social and public values. Several multidimensional frameworks for the evaluation of egovernmental initiatives have, therefore, been designed [START_REF] Chircu | E-government evaluation: towards a multidimensional framework[END_REF]. However, several researchers have claimed that the types of benefits and cost depend on the situation for the e-government initiative and cannot be specified in advance [START_REF] Irani | Evaluating e-Government: learning from the experiences of two UK local authorities[END_REF]. The VAMEE method supports actors to specify benefits and cost for the e-government initiative based on the situation for the e-government initiative.

Conclusions and Future Work

In this paper, we have proposed a new method for the valuation of e-government initiatives. The characteristics of the method include a network perspective, a high degree of visualization, and a firm grounding in enterprise modeling. Utilizing enterprise modeling for the purpose of valuation enables organizations to manage knowledge about themselves and the environment in which they are embedded. The method has been successfully used in a case at a Swedish municipality.

A main advantage of the method is that it widens the perspective of the actors involved in an e-government initiative, as the method requires the benefits, costs and interrelationships of all actors to be made explicit and taken into account. This widened perspective contributes to the correctness of the evaluation, as the interests of all concerned actors are taken into consideration. The broader perspective also supports innovation, as involving more actors opens up new opportunities for value creation and distribution. To involve all concerned actors is particularly important in the public sector, where the needs and interests of all citizens have to be respected.

Future work will focus on further widening the perspective on the benefits of an egovernment initiative. The current use of the Peng method requires the benefits to be expressed in monetary terms, i.e. benefits are viewed in one dimension only. However, a multi-dimensional view on benefits can be preferable in many circumstances and should be investigated. Furthermore, the method needs more validation through comprehensive case studies and the involvement of other relevant actors such as software vendors.

Figure 1 .

 1 Figure 1. A Value model of a child care network in a Swedish municipality. The Value model is on operational level.

Figure 2 .

 2 Figure 2. Value models on different levels A value model on the operational level represents the transfers of economic resources on the operational level, such as in Figure 1. Resource transfers on the

Figure 4 .

 4 Figure 4. The goals for the actors involved in the e-government initiative.

Figure 7 .

 7 Figure 7. The benefits related to the goal "Low adm costs" of the Day Nurse Unit.

Figure 8 .

 8 Figure 8. A Value model on policy level of a child care network in the e-government initiative, including the benefits.

Parent Järfälla Child Care Administration Day Nurse Unit

	Planned	Tariffs for Child Care Fee [digital info]	Planned Child Care Usage
	Child Care Usage [digital info]	Calculated Child Care Fee [digital info]	[digital info]
		Schedule change
		service [e-service]

Parent Järfälla Child Care Administration Day Nurse Unit

	Planned	Tariffs for Child Care Fee [digital info] (C2)	Planned Child Care Usage
	Child Care Usage [digital info]	Calculated Child Care Fee [digital info] (C3)	[digital info] (D1-D5)
	(A1-A8)	Schedule change
		service [e-service] (C1)


Stefan Hofer

Instances Over Algorithms: A Dierent Approach to Business Process Modeling

Keywords: business process modeling, requirements engineering, instance modeling, CSCW

Most of today's approaches to business process modeling interpret processes as algorithms. As a result, modelers often try to cover every possible outcome of a process. This algorithmic view increases the amount of information that has to be captured and reviewed. As an alternative, we propose to focus on exemplary process instances instead. We call this concept Exemplary Modeling and have built a modeling method around it. In this paper we explain its merits and illustrate its feasibility by reporting on our practical experience.

Introduction

No matter if you optimize business processes, analyze requirements for the development of a new software system or aim to improve IT-business alignment:

Business process models are commonly used to capture the necessary information to achieve these goals. Usually, business process modeling can be divided into two major activities:

Modelers gather and condense information into graphical models. Domain experts review and approve the models.

These steps become increasingly dicult with the amount of information that has to be considered. The more information they comprise, the larger and more complex the models become. Also, the total number of models typically increases with the amount of information to capture. In professional environments modelers and domain experts have to cope with this situation. Thus they could draw signicant support from concepts that address gathering of extensive information, condensing it into models, and reviewing these models.

In this paper we describe a concept which provides that support exemplary modeling :

We will describe how modeling of exemplary instances of processes diers from classical approaches. We will point out how the concept helps modelers to gather and condense information and domain experts to review and approve models (see Sect. 2).

We demonstrate the applicability of exemplary modeling by presenting a modeling method that is based on this concept. The method was developed cooperatively at the University of Hamburg and C1 WPS GmbH (see Sect. 3).

We reect on the concept by sharing our experience gained by using the modeling method in commercial projects (see Sect. 4). Drawbacks and limitations will also be discussed.

A comparison of the concept with related work concludes this article.

Exemplary Modeling

Motivation

Being involved with business process modeling in academic and professional contexts, we noticed how hard it is to get domain experts to participate in modeling. Shipman and McCall provide a possible explanation:

The diculties that users have in formalizing information are not just interface problems. More eort is required of users in part because formal representations require the explicit statement of information that might have been left implicit [. . . ] in a less formal representation. In addition, substantial eort is typically required to learn a formal representation. This requires both talent and interest in formalization that users are unlikely to have. [13, p. 286] We compared this situation with a similar problem domain requirements engineering, and particularly user participation during software development. Our software engineering process is heavily inuenced by the Tools and Materials Approach [START_REF] Züllighoven | Object-Oriented Construction Handbook[END_REF]. This approach fosters the use of prototypes and pilot system to incorporate user feedback into the development process. Prototypes are very tangible and allow for the discussion of concrete workows and boundary conditions. Thus, they provide a proper basis for discussion about the system.

In our opinion, most approaches to business process modeling lack such a foundation because models are usually rather abstract and algorithmic descriptions of processes. Typically they are produced by decomposition. Processes are broken down into subprocesses until the level of activities is reached. Graphically, they are depicted as a sequence of boxes and arrows much like diagrams used in Structured Analyses and Design Technique [START_REF] Ross | Structured Analysis for Requirements Denition[END_REF] or similar engineering techniques. Two prominent examples of this kind of business modeling are the Business Process Modeling Notation (BPMN ) and Event-driven Process Chains (EPC ) (for both see [START_REF] Weske | Business Process Management[END_REF]). In fact, EPCs were originally conceived as a modeling technique for software engineers, not for business process modelers and domain experts. The underlying mindset aims at describing precisely how a process is executed. Thus, activities and decisions are modeled in an algorithmic way; a way suitable for automating processes with software. However, the behavior of interactive systems such as typical business applications cannot be reduced to algorithms as Wegner explains in [START_REF] Wegner | Why Interaction is More Powerful Than Algorithms[END_REF]. Jacobson et al. criticize that algorithmic modeling techniques are used for business processes: All these techniques come from the computer world. It is as though we learned to think in a way that works for computer systems, and we realized we could apply the same way of thinking to describe an organization [. . . ]. We believe information systems should be described so they are easy for people to understand, with abstractions that people can comprehend. We think it is bizarre to apply the way of thinking that governs computer systems to business process. [6, p. 36] A main feature of algorithmic modeling techniques is that case switches (called gateways in BPMN [2]) like exclusive or are an important element of the models. Each switch increases the number of paths from start point to end point. Therefore, a model displays all these possible paths a graphical representation of the process's transitive hull of states and state transitions. But from a domain expert's view, dierent paths may represent very dierent outcomes.

That means that their graphical proximity in the model does not necessarily correspond to their relationship in the real world. In a similar way, case switches do not express that some paths are more important or more likely than others.

Additionally, the use of case switches is suggestive of depicting complete models, meaning that every possible path is covered. This blends in with the underlying logic of algorithmic modeling techniques: The execution of an incomplete algorithm would result in an error or an undened state. In our experience, this ambition for completeness leads either to an increase in the number of models or the use of more case switches. In fact, completeness is unachievable for interactive business applications: Incompleteness is a necessary price for modeling independent domains of discourse whose semantic properties are richer than the syntactic notation by which they are modeled [. . . ]. [14, p. 98] In conclusion, the common practice of modeling business processes with methods that have an algorithmic nature does provide plenty of room for improvement.

Exemplary Modeling as a Dierent Approach to Modeling

Our approach to business process modeling is based on the idea that concrete instances of a process are easier to understand than abstract descriptions of all possible outcomes. These exemplary instances of a process can be modeled without case switches every model represents one path from process start to end. As a consequence, modelers and domain experts do not have to deal with the complete set of possible states that a process may have during its execution.

Consider this example:

A sales process for an insurance takes dierent paths depending on the client being already customer of the insurance company or not. In an usual process model, this would be modeled as a exclusive or switch, splitting the process model into two paths (see Fig. 1). With our approach, we would create one model for each signicant path through the model (so, two for this example see Fig. 2).

1 Omitting the possibly negative outcome of the second switch for the sake of brevity. In contrary to other modeling approaches, a scenario-oriented approach does not describe actions in an algorithmic way. Instead, it focuses on the actors (human or IT systems) that are involved and order their activities in an exemplary sequence. That way, activities and their IT support can be discussed without consideration of an algorithm that could automate these activities.

Obviously, modeling every unique path of a process may take would increase the number of models dramatically. However, in our experience it is usually sucient to look at some characteristic paths that a process may take. This is why the number of models for each process can be limited by focusing on the most important scenarios. Smaller variations and optional steps can easily be annotated in textual form. Reconsider the previous example: Let us assume that a new customer may be treated like an existing customer if his or her spouse is already an existing customer. The only dierence is that some additional elds have to be lled out on the application form. Instead of creating additional models for this variation, a textual annotation is sucient to incorporate it into the insurance sales process for existing customers. Figure 3 depicts this variation of Fig. 2b.

The Exemplary Business Process Modeling Method

Exemplary modeling is merely a concept. To turn it into a modeling method for professional use, one needs: This section describes how these were built around the idea of exemplary modeling. The result was a tool-supported method called exemplary Business Process Modeling (eBPM) (see [START_REF] Breitling | Design Rationale in Exemplary Business Process Modeling[END_REF]).

Cooperation Scenarios

The eBPM notation consists of several types of diagrams with cooperation scenarios being the most important one. It becomes obvious that cooperation scenarios implement the concept of exemplary modeling when looking at some of the graphical elements that can be used in this diagram type: Actors are people or IT systems that perform actions. They may interact with each other by exchanging Information (see Work Objects). Work Objects can take the form of documents, data, tools and so on. Relationships express interaction of actors, creation or editing of things, use of IT systems and so forth.

Consequentially, there are no case switches available. It should also be noted that modelers can choose whether they use actors to represent a concrete actor (e.g. Mr. Smith) or a role (e.g. agent). eBPM's cooperation scenarios were derived from a diagram type called cooperation pictures, proposed by Krabbel et al. in [START_REF] Krabbel | Participation of Heterogeneous User Groups: Providing an Integrated Hospital Information System[END_REF]. Cooperation pictures were created as a requirements engineering method to capture cooperation. Thus both diagrams have a strong focus on depicting cooperation. For example, they both use pictograms to create a more tangible view on cooperation.

Compared to cooperation pictures, cooperation scenarios describe a business processes as a sequence of steps. However, in contrast to other methods like BPMN this sequence is not depicted as a control ow. Instead, an order is established by numbering the steps (see Fig. 3). A more detailed look on cooperation scenarios shows that every step has to be carried out by an human or a software system. To do that, an actor performs an activity which is modeled as relation between actor and a work object. Activities are depicted as arrows and annotated with verbs. Thus, every step can easily be transcribed in textual form in a subject-predicate-object pattern. As a result, cooperation scenarios can be read" like stories just like suggested by Carroll (cf. Sect. 2.2).

Although the notation is not the focus of this paper, we nd it noteworthy that its tangibility complements exemplary modeling. As stated above, work objects are depicted as icons that match the real world objects they represent: A document icon symbolizes a document, a telephone icon symbolizes communication via telephone, . . . Since these diagram types are not necessarily required to comprehend the idea of exemplary modeling, we will not explain them any further in this article.

Additional information can be found in [START_REF] Breitling | Design Rationale in Exemplary Business Process Modeling[END_REF].

Modeling Process

Typically, eBPM models are developed in workshops. Participants include modelers, domain experts and, if needed, technically oriented experts. During the workshop, the model is visible for all participants (e.g. projected on a screen).

Since only concrete cases are modeled, the resulting models can easily be validated and agreed upon by the participants. Thus, the workshop covers both of the modeling steps described in Sect. 1: Information gathering and condensing as well as reviewing.

To ensure the models are scenario-based, the modeler has to guide the modeling process. She does so by discussing the boundary conditions of the exemplary processes and includes the description into the graphical model. The examples in Fig. 2 each contain such a description in a yellow textbox. Since every modeled action is performed by an actor, the modeling process advances by asking questions like:

Who performs this action?

What things does the actor use for that step?

Tool Support

Although eBPM may be used with a ip chart or generic drawing tools like Microsoft's Visio, tool support was implemented using the BOC Group's Ado modeling platform. A specic software tool oers various advantages:

References between models and/or model elements allow for a hypertext-like navigation.

The enumerated actions of a model can be visualized one step at a time. This walkthrough feature helps to read large models by telling a visual story.

Models can be evaluated by certain criteria for example, which IT systems are used by which actors.

A free version (without any restriction to non-commercial use) is available via the University of Vienna's Open Model Initiative website (see [9]) .

Reection

In this section, we reect upon the use of the eBPM method in general and upon the concept of exemplary modeling in particular. To do so, we begin with an overview of the elds where eBPM was used successfully. Then, we compare our experience with the initial claim that exemplary modeling supports modelers and domain experts to perform their modeling activities (see Sect. 1).

Field of Application

eBPM has been in use for several years now in so dierent domains as banking, insurance, federal government, logistics, and health care. It has mainly been adopted to support requirements engineering rather than for classical business process modeling. The following list presents some elds in which the method has been used so far: Software Development. Current business processes and their IT support were modeled using eBPM. From this starting point, the models for the to-be processes were derived. These models had a strong focus on how the new systems should support the user's activities.

Evaluation of Commercial O-the-shelf (COTS) Software. Organiza- tions that wanted to buy COTS software used eBPM to describe how IT support for their business processes looked like ideally. These models were used in the acquisition process. The vendors of possibly tting COTS software had to describe how the modeled activities would look like if their product was used. This way, it became evident for the organization how well each possible solution tted and how they compared against each other.

Bringing Software Into Service. Complex software solutions are often introduced into organizations incrementally. eBPM was used to model how each step aects the business processes. Also, the use of interim solutions (like adapters between systems or organizational workarounds) were planned with help of eBPM models. Thus, the transition to the new software system was smoothened.

Quality Assurance. Software migration projects require a quality assurance process that helps ensuring the success of the changes. eBPM was used to describe core business processes that were of crucial importance to the organizations. Then, to-be models of the processes were derived to describe the planned outcome of the migration. In a third step, these descriptions were turned into process-oriented test cases.

Organizational Changes. Organizations that wanted to change their struc- ture used eBPM to describe their current work places. After analyzing the models for improvement or reorganization, eBPM was used to outline how the to-be work places should look like and how IT could support them.

Experience

Comprehension. In our experience, eBPM models are easy to understand, regardless of one's background or domain. An indication of that ease of use is that we do not explain the eBPM notation to the participants of modeling workshops. These workshops can be successful even if the modeler is the only one of the participants who has experience with the method. However, we usually have to explain the exemplary character of the models. Especially participants who used other modeling approaches before are used to distinguishing cases. Concreteness of Scenarios. Although a cooperation picture depicts an in- stance of a process, modelers have some freedom in choosing its level of concreteness. As described in Sect. 3.1, actors may represent individuals or roles.

We recommend the latter as often several representatives of a role participate in a modeling workshop. Modeling roles as actors allows all representatives to identify with the actor. Simultaneously, it helps them to abstract from little details that dier from individual to individual.

Variations. The power of scenario based modeling becomes evident when participants are constrained to separate important from less important variations of business processes, thus facilitating information gathering as well as reviewing of models. However, the pragmatic approach of handling small, but not negligible variations as textual annotations comes with a pitfall. It may lead to lots of descriptive text accompanied by a weak model instead of a rather rigorous model with some additional textual comments.

Responsibilities of Modelers. Naturally, the concept of exemplary modeling and the freedom of choice that eBPM provides call for a skilled modeler. We learned from training prospective eBPM modelers that the usefulness of models increases dramatically with experience. That experience is of particular importance when conducting a modeling workshop (see Sect. 3.2). For example, the modeler has to guide the process of nding a sucient amount of scenarios for a given purpose.

Feedback Loop. Notation, modeling process and tool support allow for live modeling. Breitling et al. conclude: The modeler immediately translates the contributions of the participants into eBPM models that are visible to everyone. This procedure shortens the feedback loop signicantly. [3, p. 189] This eect is amplied by the walkthrough feature provided by the modeling tool (see Sect.

3.3).

We noticed that approving of models is supported especially well by exemplary modeling. Domain experts can easily dismiss incorrect models because of their concreteness. It is also interesting to see that domain experts identify with the actors in the model. They recognize their work objects and the actors they interact with. This too helps them to evaluate process models.

Notation. Both the symbols of the modeling language as well as the layout have a profound impact on model comprehension [START_REF] Schrepfer | The Impact of Secondary Notation on Process Model Understanding[END_REF]. Hence, it is dicult to distinguish to what extent the applicability of eBPM can be attributed to its notation, to the concept of exemplary modeling, and to the skills of the modeler.

Limitations. Processes that mainly consist of complex state transitions proved to be dicult to capture solely with exemplary models. Again, we found it useful to focus on a small number of typical chains of transitions so that one could gain an idea of the general purpose of the process. But in addition we used state transition diagrams to clarify the lifecycle of work objects. This combination was valuable when dealing with processes that have a legal dimension like for example dunning processes of insurance companies.

It should be noted that all this experience was gained in industries that rely on both people and IT systems to execute their business processes (see Sect. 4.1 for elds of application). eBPM was neither developed as a language for process automation nor as modeling method for embedded systems or similar areas.

In summary, we noticed that exemplary modeling does indeed support modelers and domain experts in their respective modeling activities.

5 Related Work

Instance Modeling

Since exemplary modeling deals with instances of business processes a discussion of instance modeling seems appropriate. Within the area of information modeling, there are several approaches that propose modeling instances as an alternative or an extension to some sort of a class model or schema. For example, Agarwal et al. suggest modeling schemas that describe the building blocks and relations that can be used to dene business processes (see [START_REF] Agarwal | Instance Modelling Beyond Object-Oriented Modelling[END_REF]). Although the resulting process models are instances of the process schema in terms of object-orientation, they are not scenarios. Thus, they are not instances in terms of exemplary modeling.

A dierent instance modeling approach proposed by Parsons and Wand in [START_REF] Parsons | Emancipating Instances from the Tyranny of Classes in Information Modeling[END_REF] aims for a semantically richer database design by making classication of data instances optional (i.e. allowing decoupling from a relational database schema). Their design consists of two layers of models, one for instances and one for classes. In a somewhat comparable way, cooperation pictures (containing instances) may refer to models of terms and models of roles (see Sect. 3.1). The latter model types can be used to dene structured collections of work objects and actor's roles, respectively.

Use Cases

Finally, we want to address a well known modeling approach that is also scenario based: Use Cases. Since there are several variants of use cases (see for example [START_REF] Jacobson | Object-Oriented Software Engineering: A Use Case Driven Approach[END_REF]) we will limit this discussion to Cockburn's prominent version as described in [START_REF] Cockburn | Writing Eective Use Cases[END_REF].

Apparently, use cases are text-based whereas eBPM is a graphical modeling method. Although there are so-called Use Case Diagrams in UML, Cockburn makes clear that they are not a notation for capturing use cases [5, p. 128]. Use cases and eBPM both center around actors and use scenarios to describe business processes. Yet, there are dierences in focus. In [START_REF] Cockburn | Writing Eective Use Cases[END_REF] Subfunction-level goals are those required to carry out user goals. [5, p. 66] We do not make this distinction as exemplary modeling works on all three levels. However, eBPM is not just based on exemplary modeling but also on modeling cooperation. Thus, we usually use eBPM to capture a level between user goals and summary-level goals. In summary, eBPM has a strong focus on how several actors work together to achieve a goal.

Still, the similarities between the two approaches may indicate that eBPM is merely a graphical addition to use cases. However, this paper only covers one of several of eBPM's model types, neglecting valuable modeling capabilities that are not related to use cases (see Sect. All in all, it should not be surprising that we have incorporated eBPM in use cases several times. Cooperation pictures are well suited as a use case's main

Fig. 1 :

 1 Fig. 1: An insurance sales process modeled with BPMN.

  (a) New Customer. (b) Existing Customer.

Fig. 2 :

 2 Fig. 2: Exemplary insurance sales process models.

Fig. 3 :

 3 Fig. 3: Small variations are covered by annotation rather than separate models.

  The cooperation scenario and the other diagram types of eBPM are embedded in a meta model. Other important diagrams include:Model of Terms for collecting and structuring work objects. Model of Roles for collecting and structuring roles that actors can assume. IT-Landscape for collecting and structuring IT systems.

  , Cockburn distinguishes three levels of use cases: User Goals correspond to elementary business processes. Summary-level goals involve multiple user goals. [. . . ] They show the context in which the user goals operate. They show life-cycle sequencing of related goals. They provide a table of contents for the lower-level use cases [. . . ]. [5, p. 64]

  3.1).

So far, the software is available in German language only.

success scenario [5, p. 28]. Extensions and variations of use cases blend well with the way we deal with variations in exemplary modeling (see Sect. 2).

Summary

In summary, we think that an algorithmic view on process modeling adds to the problem of how to handle extensive information:

The quest for completeness increases the amount of information that needs to be gathered.

Subsequently, more information needs to be condensed into models. This leads to either more complex models and/or an increased number of models, organized as hierarchies of processes and sub-processes.

Due to their abstract nature und their extensiveness, these models are usually hard to review and approve.

In this paper, we proposed a dierent approach to process modeling. This approach is based on the idea that it is easier to capture and evaluate exemplary instances of processes rather than an abstract description of all their possible outcomes. We explained how scenarios provide a proper basis for exemplary modeling. By introducing our Exemplary Business Process Modeling Method (eBPM) we showed that the concept of exemplary modeling is suitable for a professional modeling technique. This was illustrated by presenting several elds of application that eBPM has proven successful in. Using exemplary modeling in these elds of applications allowed us to gain experience and reect on the concept. We observed, that exemplary modeling (as implemented by eBPM) indeed helped to avert the disadvantages we experienced with other modeling techniques. Finally, we compared our approach to Use Cases and pointed out how these two approaches can be combined.


Wil M P Van Der Aalst
email: w.m.p.v.d.aalst@tue.nl

Intra-and Inter-Organizational Process Mining: Discovering Processes Within and Between Organizations

Keywords: process mining, cross-organizational mining, business process management

Due to the availability of more and more event data and mature process mining techniques, it has become possible to discover the actual processes within an organization. Process mining techniques use event logs to automatically construct process models that explain the behavior observed. Existing process models can be validated using conformance checking techniques. Moreover, the link between real-life events and model elements allows for the projection of additional information onto process models (e.g., showing bottlenecks and the flow of work within an organization). Although process mining has been mainly used within individual organizations, this new technology can also be applied in cross-organizational settings. In this paper, we identify such settings and highlight some of the challenges and opportunities. In particular, we show that cross-organizational processes can be partitioned along two orthogonal dimensions. This helps us to identify relevant process mining challenges involving multiple organizations.

Process Mining

We have applied process mining in over 100 organizations [START_REF] Van Der Aalst | Process Mining: Discovery, Conformance and Enhancement of Business Processes[END_REF]. Our experiences show that process mining is a new and exiting technology that can be applied in a variety of domains (healthcare, governments, banking, insurance, education, retail, production, transportation, high-tech systems, etc.). However, lion's share of today's process mining projects are conducted within a single organization, whereas many processes are distributed over multiple organizations and different organizations are executing similar processes. Therefore, this paper aims to describe the various cross-organizational settings where process mining can be used. Before doing so, we provide a brief overview of the state-of-the-art in process mining.

Process mining provides a new means to improve processes in a variety of application domains. There are two main drivers for this new technology. On the one hand, more and more events are being recorded thus providing detailed information about the history of processes. On the other hand, there is a need to improve and support business processes in competitive and rapidly changing environments. Performance information (e.g., the average time between two subsequent activities) can be extracted from the event log and visualized on top of the model. Decision rules (e.g., a decision tree based on data known at the time a particular choice was made) can be learned from the event log and used to annotated decisions.

The event log can be used to discover roles in the organization (e.g., groups of people with similar work patterns). These roles can be used to relate individuals and activities.

E

Discovery techniques can be used to find a control-flow model (in this case in terms of BPMN) that describes the observed behavior best.

Starting point is an event log. Each event refers to a process instance (case) and an activity. Events are ordered and additional properties (e.g. timestamp or resource data) may be present.

Fig. 1. Process mining techniques extract knowledge from event logs in order to discover, monitor and improve processes [START_REF] Van Der Aalst | Process Mining: Discovery, Conformance and Enhancement of Business Processes[END_REF].

Process mining is a relative young research discipline that sits between computational intelligence and data mining on the one hand, and process modeling and analysis on the other hand. The idea of process mining is to discover, monitor and improve real processes (i.e., not assumed processes) by extracting knowledge from event logs readily available in today's systems (see Fig. 1). Note that process mining includes (automated) process discovery (extracting process models from an event log), conformance checking (monitoring deviations by comparing model and log), social network/organizational mining, automated construction of simulation models, case prediction, and history-based recommendations. Process mining provides an important bridge between data mining and business process modeling and analysis. Over the last decade, event data have become readily available and process mining techniques have matured. Moreover, process mining algorithms have been implemented in various academic and commercial systems. Today, there is an active group of researchers working on process mining and it has become one of the "hot topics" in Business Process Management (BPM) research. Moreover, there is a huge interest from industry in process mining. More and more software vendors started adding process mining functionality to their tools. Examples of software products with process mining capabilities are: ARIS Process Performance Manager, Enterprise Visualization Suite, Interstage BPME, OKT Process Mining suite, Process Discovery Focus, ProcessAnalyzer, ProM, Rbminer/Dbminer, Reflect|one, and Reflect.

Starting point for process mining is an event log. All process mining techniques assume that it is possible to sequentially record events such that each event refers to an activity (i.e., a well-defined step in the process) and is related to a particular case (i.e., a process instance). Event logs may store additional information about events. In fact, whenever possible, process mining techniques use extra information such as the resource (i.e., person or device) executing or initiating the activity, the timestamp of the event, or data elements recorded with the event (e.g., the size of an order).

Basically, there are three types of process mining. The first type of process mining is discovery. A discovery technique takes an event log and produces a model without using any a-priori information. Process discovery is the bestknown process mining technique. For many organizations it is surprising that existing techniques are able to discover the real process based on the example executions in the event log. The second type of process mining is conformance.

Here, an existing process model is compared with an event log of the same process. Conformance checking can be used to check if reality, as recorded in the log, conforms to the model and vice versa. The third type of process mining is enhancement. Here, the idea is to extend or improve an existing process model using information about the actual process recorded in some event log. Whereas conformance checking measures the alignment between model and reality, this third type of process mining aims at changing or extending the a-priori model. For instance, by using timestamps in the event log one can extend the model to show bottlenecks, service levels, throughput times, and frequencies.

Process mining may cover different perspectives. The control-flow perspective focuses on the control-flow, i.e., the ordering of activities. The goal of mining this perspective is to find a good characterization of all possible paths, e.g., expressed in terms of a Petri net or some other notation (e.g., EPCs, BPMN, and UML ADs). The organizational perspective focuses on information about resources hidden in the log, i.e., which actors (e.g., people, systems, roles, and departments) are involved and how are they related. The goal is to either structure the organization by classifying people in terms of roles and organizational units or to show the social network. The case perspective focuses on properties of cases. Obviously, a case can be characterized by its path in the process or by the originators working on it. However, cases can also be characterized by the values of the corresponding data elements. For example, if a case represents a replenishment order, it may be interesting to know the supplier or the number of products ordered. The time perspective is concerned with the timing and frequency of events. When events bear timestamps it is possible to discover bottlenecks, measure service levels, monitor the utilization of resources, and predict the remaining processing time of running cases.

Moreover, process mining can be used in online and offline settings. The results of process mining may be used to reason about processes (redesign) and to make decisions inside processes (operational support).

For a more comprehensive introduction to process mining, we refer to [START_REF] Van Der Aalst | Process Mining: Discovery, Conformance and Enhancement of Business Processes[END_REF].

Intra-and Inter-Organizational Processes

Although most applications of process mining have been conducted inside a particular organization, there is no foundational reason why the technology cannot be applied across different organizations. Of course there may be issues related to confidentially, privacy, and data heterogeneity. In this paper we abstract from such problems and simply explore the possibilities of intra-and interorganizational process mining. For this purpose, we consider two basic settings: (a) collaboration and (b) exploiting commonality.

In a collaborative setting, different organizations work together to handle process instances. A process instance, often referred to as case, corresponds to the "thing" that needs to be handled (e.g., a customer placing an order, a patient having a decease that needs to be treated, or a citizen applying for a building permit). The work associated to a case may be distributed over different organizations in a collaborative setting.

In the other basic setting (i.e., exploiting commonality) there are different organizations essentially doing the same thing. For example, there are 430 Dutch municipalities handing out building permits. Here the goal is not to distribute the work associated to a case as different organizations can do (more-or-less) the same thing. Organizations that have processes in common may be in competition, however, they can also learn from one another and share experiences and infrastructures. For example, Dutch municipalities are not competing with respect to handing out building permits. Although they may be competing for new citizens, they can still share a common IT infrastructure and share experiences to better (e.g. faster or more efficient) handle requests for building permits.

Collaboration: Distributing the Work Among Different Organizations

First of all, we consider the collaborative setting where different organizations work together to handle process instances. This requires that the different parties are able to inter-operate, i.e., coordinate their activities. In [START_REF] Van Der Aalst | Process-oriented Architectures for Electronic Commerce and Interorganizational Workflow[END_REF], we identified five forms of interoperability. These are depicted in Fig. 2 and described next.

-The first form of interoperability is capacity sharing. This form of interoperability assumes centralized control, i.e., the routing of cases is under the control of a single organization. The execution of tasks is distributed, i.e., resources of different organizations may execute tasks. -The second form of interoperability is chained execution: the process is split into a number of disjoint subprocesses which are executed by organizations in a sequential order. This form of interoperability requires that a partner transfers or initiates the flow for a case after completing all the work. In contrast to capacity sharing, the control of the workflow is distributed over the different organizations. -The third form of routing is subcontracting. In this setting, one organization subcontracts subprocesses to other organizations. Consider for example Fig. 2(c) where two subprocesses are subcontracted. For the top-level organization the two subcontracted subprocesses appear to be atomic. For the two organizations executing subcontracted work, the subprocesses can be very complex. Note that the control is hierarchical, i.e., although there is a top-level actor, control is distributed in a tree-like fashion. -The fourth form of interoperability is case transfer. Each organization has a copy of the same process description, i.e., the process specification is replicated. However, at any time, each case resides at exactly one location. Cases (i.e., process instances) can be transferred from one organization to another.

A case can be transferred to balance the workload or because tasks are not implemented at all organizations. Note that in Fig. 2(d) it is essentially assumed that each of the organizations uses the same process definition (although some may implement only a part of it). -The last form of interoperability is shown in Fig. 2(e): loosely coupled. For this form of interoperability the process is cut in pieces which may be active concurrently. Moreover, the definition of each of the subprocesses is local, i.e., the environment does not need to know the process. Only the protocol which is used to communicate is public for the other parties involved.

Note that chained execution and subcontracting can be seen as loosely coupled processes. One can think of such processes as "jigsaw puzzles", i.e., the overall process is cut into parts that fit well together. Case transfer uses a different kind of partitioning: cases rather than process fragments are partitioned. Capacity sharing is the only form of interoperability which does not require some partitioning of the process and its instances. We will not consider this for of interoperability as conventional process mining techniques can be used.

Exploiting Commonality: Sharing Knowledge and Infrastructures

As indicated earlier we consider two basic settings: (a) collaboration (cf. Fig. 2) and (b) exploiting commonality. Now we focus on the latter one. This type of cross-organizational processes does not involve interoperability, i.e., there is no explicit distribution of work. Instead, organizations are executing essentially the same process while sharing experiences, knowledge or a common infrastructure.

To better understand such cross-organizational processes, we consider some examples taken from [START_REF] Van Der Aalst | Configurable Services in the Cloud: Supporting Variability While Enabling Cross-Organizational Process Mining[END_REF][START_REF] Van Der Aalst | Business Process Configuration in The Cloud: How to Support and Analyze Multi-Tenant Processes[END_REF][START_REF] Buijs | Towards Cross-Organizational Process Mining in Collections of Process Models and their Executions[END_REF].

-There are about 430 municipalities in The Netherlands. In principle, they all execute variants of the same set of processes. For example, they all support processes related to building permits, such as the process handling applications for permits and the process for handling objections against such permits. -Suncorp is the largest Australian insurance group. The Suncorp Group offers various types of insurance using brands such as Suncorp, AAMI, APIA, GIO, Just Car, Bingle, Vero, etc. There are insurance processes related to different types of risks (home, motor, commercial, liability, etc.) and these processes exist for the different Suncorp brands. Hence, there are up to 30 different variants of the process of handling an insurance claim at Suncorp. -Hertz is the largest car rental company in the world with more than 8,000 locations in 146 countries. All offices of Hertz need to support the same set of processes, e.g., how to process a reservation. However, there are subtle differences among the processes at different locations due to regional or national variations. For example, the law in one country or the culture in a particular region forces Hertz to customize the standard process for different locations. -The sales processes of many organizations are managed and supported by

Salesforce. On the one hand, these organizations share an infrastructure (processes, databases, etc.). On the other hand, they are not forced to follow a strict process model as the system can be configured to support variants of the same process. -Easychair supports the review processes of many conferences. On the one hand, conferences share common functionality and processes. On the other hand, many variations are possible.

Organizations such as Suncorp and Hertz need to support many variants of the same process (intra-organizational variation). Different municipalities in a country need to offer the same set of services to their citizens, and, hence, need to manage similar collections of processes. However, due to demographics and political choices, municipalities are handling things differently. Sometimes these differences are unintentional; however, often these differences can be easily justified by the desired "Couleur Locale" (inter-organizational variation).

The cross-organizational processes mentioned above refer to a different type of cooperation than the different ways of distributing work depicted in Fig. 2. Organizations can learn from one another. For example, one municipality may improve its processes by learning from experiences of a better performing municipality. Moreover, if there a sufficient commonalities, organizations may want to share configurable processes and infrastructures [START_REF] Van Der Aalst | Configurable Services in the Cloud: Supporting Variability While Enabling Cross-Organizational Process Mining[END_REF][START_REF] Van Der Aalst | Business Process Configuration in The Cloud: How to Support and Analyze Multi-Tenant Processes[END_REF][START_REF] Buijs | Towards Cross-Organizational Process Mining in Collections of Process Models and their Executions[END_REF].

Horizontal and Vertical Partitioning

After discussing the two basic forms of cross-organizational processes (collaboration and exploiting commonality), we conclude that there are two partitioning dimensions: the case dimension and the process dimension. Vertical partitioning uses the case dimension to partition work, i.e., the cases are distributed over several organizations but the process is not cut into pieces. Horizontal partitioning is based on the process dimension, i.e., the process is cut into pieces and organizations are responsible for specific parts of the jigsaw puzzle. The partitioning dimensions are in principle orthogonal but combinations are possible.

Chained execution, subcontracting, and loosely coupled, as described using Fig. 2, correspond to horizontal partitioning. Case transfer (Fig. 2(d)) and exploiting commonality (Section 2.2) correspond to vertical partitioning. Figure 3 illustrates these two partitioning dimensions. Traditionally, process mining has been focusing on processes that are not partitioned, i.e., all process instances belong to the same monolithic process. As will be shown in the reminder, the two dimensions shown in Fig. 3 can be used to structure the different process mining challenges.

Challenges for Process Mining

In Section 1 we introduced process mining as a new technology to analyze operational processes based on the footprints they leave in event logs. Subsequently, we provided a classification of intra-and inter-organizational processes in Section 2. Based on this we identified two main partitioning dimensions as shown in Fig. 3. These two partitioning dimensions serve as the basis for discussing various process mining challenges.

Horizontal Partitioning

A process that is partitioned horizontally can be seen as a jigsaw puzzle. Each "puzzle piece" corresponds to a fragment of the overall process and is under the control of one organization. In the classical setting (i.e., single process/organization) it is possible to capture all events relevant for a particular process, e.g., one can extract data from an SAP system clearly showing all steps taken in a particular process. However, when a process is partitioned horizontally one cannot assume this. An organization can only see some of the "puzzle pieces". It can see all events related to the puzzle pieces it is responsible for. Moreover, it can see the interactions with other puzzle pieces.

In a horizontally partitioned process there needs to be interaction between the different pieces. Typically, messages are exchanged between the puzzle pieces controlled by different organizations. Consider for example SOAP or EDI messages. SOAP (Simple Object Access Protocol) is a protocol specification for exchanging messages between web services. It uses a rather generic XML format which specifies a SOAP envelope consisting of a header and body. Elec-tronic Data Interchange (EDI) standards such as UN/EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport) impose more constraints on the messages being exchanged. The different fields in an EDI message have a predefined meaning. Note that messages can be exchanged in a synchronous or asynchronous manner. In some cases there may also be a party that is able to observe all message exchanges without being able to look "inside the puzzle pieces".

Hence, the main challenge is to conduct process mining while only seeing a part of the overall process [START_REF] Van Der Aalst | Conformance Checking of Service Behavior[END_REF]. Typical questions are:

-How to discover a process model when only seeing message exchanges and/or local events? -How to check conformance when only seeing message exchanges and/or local events? -How to identify bottlenecks when only seeing message exchanges and/or local events? -How to correlate messages to process instances? When sending a message from one organization to another it needs to be routed to the appropriate instance of the process. This is a problem that is often underestimated and most researchers simply abstract from it [START_REF] Van Der Aalst | Service Interaction: Patterns, Formalization, and Analysis[END_REF]. -How to deal with many-to-many relationships across different organizations?

One customer order may correspond to many order lines that may or may not be combined in different deliveries. Besides the problem of correlating messages there is the problem that one instance in one organization may refer to multiple instances in another organization and vice versa [START_REF] Van Der Aalst | Process Mining: Discovery, Conformance and Enhancement of Business Processes[END_REF].

Since more and more processes are distributed over multiple organizations, it is important to address the above questions.

Vertical Partitioning

When a process is partitioned vertically, cases are distributed over several organizations each using their own variant of the process. These organizations may collaborate (see case transfer style of interoperability illustrated by Fig. 2(d)) or simply share knowledge and infrastructures. The metaphor of the jigsaw puzzle is not applicable anymore. A better metaphor is the "spot the difference game" children like to play (i.e., looking at two figures to find the differences between both). The bottom line is that there are different events logs all referring to some variant of the same process. The challenge is to analyze commonalities and differences between these processes based on the different event logs [START_REF] Van Der Aalst | Configurable Services in the Cloud: Supporting Variability While Enabling Cross-Organizational Process Mining[END_REF][START_REF] Van Der Aalst | Business Process Configuration in The Cloud: How to Support and Analyze Multi-Tenant Processes[END_REF][START_REF] Buijs | Towards Cross-Organizational Process Mining in Collections of Process Models and their Executions[END_REF]. Besides a pair-wise comparison of logs and models, we can also use supervised learning to explain differences. For example, we can use classification techniques such as decision tree learning. For this purpose we need to label the data at the level of cases or at the level of event logs. Classification is based on a selected response variable and a set of predictor variables. For example, the response variable could be the (average) flow time or costs of a case or log. The fitness of an event log or case with respect to some reference model can also be taken as a response variable. Predictor variables are other properties of cases, event logs, or process models. For example, the complexity of the process model and the number or resources involved. Based on such information one can construct a decision tree that aims to explain the response variable in terms of predictor variables. This assists in understanding the essential differences between different organizations. For example, classification based on logs of different municipalities may reveal that (a) larger municipalities tend to have fewer deviations, (b) allowing for more concurrency results in shorter flow times but more deviations, and (c) a pre-check of building permits results in shorter flow times and a higher acceptance rate.

In [START_REF] Buijs | Towards Cross-Organizational Process Mining in Collections of Process Models and their Executions[END_REF], we provide some initial results obtained in the CoSeLoG project. In this project, 10 of the 430 Dutch municipalities are participating to investigate how process mining, configurable process models, and cloud technology can be used to reduce costs and improve service. All Dutch municipalities need to offer the same services to their citizens, and need to manage similar collections of processes. However, due to demographics and political choices, municipalities are handling things differently. The ten municipalities involved in CoSeLoG are eager to learn "proven best practices" from one another. This can be operationalized using cross-organizational process mining.

Conclusion

Although process mining is often applied within the boundaries of individual organizations, there are many process management questions that transcend the level of a single organization. Different organizations need to cooperate to realize a process, share an infrastructure, or may want to learn from one another. However, very few applications of process mining have been documented in literature. Therefore, this paper aims to structure the different cross-organizational settings in which process mining can be applied. Based on this, we highlighted some of the key questions. Currently, we are involved in several research projects that aim to address these questions:

-The EDImine project (http://edimine.ec.tuwien.ac.at) seeks to extend current process mining approaches in order to apply them to inter-organizational business processes while building on the additional information provided by traditional Electronic Data Interchange (EDI) standards. Advantages of using EDI technology are its widespread use and standardization of message content. -The CoSeLoG project (http://www.win.tue.nl/coselog/wiki/start) focuses on a particular application domain: Dutch municipalities. Since all of these municipalities need to execute the same collection of processes, it is interesting to analyze differences and commonalities. The goal is to let these municipalities learn from one another and share a common (configurable) infrastructure. -The ACSI project (http://www.acsi-project.eu/) uses artifact-centric modeling approaches to support service collaborations in open business networks.

Process mining is used to understand such collaborations and to improve performance.

Fig. 2 .

 2 Fig.2. Different ways of distributing work in a collaborative setting[START_REF] Van Der Aalst | Process-oriented Architectures for Electronic Commerce and Interorganizational Workflow[END_REF].

Fig. 3 .

 3 Fig. 3. Two partitioning dimensions: (a) horizontal partitioning and (b) vertical partitioning.