Unleashing the Effectiveness of Process-oriented Information Systems: Problem Analysis, Critical Success Factors, Implications

JOURNAL OF SYSTEMS, MAN, AND CYBERNETICS - PART C: APPLICATION AND REVIEWS, VOL. X, NO. X, MONTH YEAR 1

Unleashing the Effectiveness of Process-oriented

Information Systems: Problem Analysis,

Critical Success Factors, Implications

Bela Mutschler, Manfred Reichert, and Johannes Bumiller

Abstract—Process-oriented information systems (IS) aim at the computerized support of business processes. So far, contemporary IS have often fail to meet this goal. To better understand this drawback, to systematically identify its rationales, and to derive critical success factors for business process support, we conducted three empirical studies: an exploratory case study in the automotive domain, an online survey among 79 IT professionals, and another online survey among 70 business process management (BPM) experts. This paper summarizes the findings of these studies, puts them in relation with each other, and uses them to show that ”process-orientation” is scarce and ”process-awareness” is needed in IS engineering. Index Terms—Process-oriented Information Systems, Business Process Support, Critical Success Factors, Case Study, Online Survey.

✦

1

M

Providing effective IT support for business processes has be-come crucial for enterprises to stay competitive in their market [1]. In the automotive domain, for example, a broad spectrum of business processes, ranging from simple administrative procedures to very complex, knowledge-intense engineering processes has to be effectively supported [2], [3]. Similar scenarios exist in many other domains like e-commerce [4], transportation [5], or healthcare [6]. In all these cases, domain-specific processes must be defined, implemented, enacted, monitored, and continuously adapted to a changing context. Thus, process life cycle support [7] and continuous process improvement adopt a key role in contemporary and future enterprise computing.

The process life cycle (cf. Fig. 1) starts with the (re)de-sign of a business process. Process modeling and process analysis tools can be used during this phase. Thereafter, the business process has to be implemented resulting in a process-oriented IS. As a typical example consider a product

data management (PDM) system which offers a broad range

of business functions to deploy models and documentation of the managed product(s) to involved user groups (e.g., engineers, managers, suppliers). Following the implementation and deployment phase, multiple instances of the implemented business process can be created and executed during the enact-ment phase. Finally, process enactenact-ment logs can be analyzed and mined in the diagnosis phase to identify potentials for process optimizations.

This paper focuses on the implementation phase, i.e., the development and maintenance of process-oriented IS. We investigate why contemporary IS often fail to provide effective

• B. Mutschler and J. Bumiller are with the Department Process Design, DaimlerChrysler Group Research, Ulm, Germany (email: {bela.mutschler;johannes.bumiller}@daimlerchrysler.com).

• M. Reichert is with the Information Systems Group, University of Twente, The Netherlands (email: m.u.reichert@utwente.nl).

Manuscript received November 28, 2006; revised March 14, 2007.

Process Design Process Implementation Process Enactment Process Diagnosis

Fig. 1. Process Life Cycle [7].

business process support. We will consider business process support as being effective, if the following two goals are achieved: (1) the cost-effective implementation or customiza-tion of processes, and (2) the availability of a technical infrastructure supporting all phases of the process life cycle. Based on this, our empirical work has been guided by the following two research questions:

• Research Question 1: What are the major problems leading to ineffective process support by IS?

• Research Question 2: What are critical success factors enabling effective process support by IS?

In order to cope with these research questions, we conducted three empirical studies (cf. Fig. 2): one exploratory case study and two online surveys. The case study was accomplished in the automotive domain. Its goal was to identify major problem areas derogating the development and operational use of IS in practice. Following this case study, we accomplished an online

survey among IT professionals in order to analyze and study

selected findings of our case study in more detail. Finally, we conducted another online survey among BPM experts to derive critical success factors for process-oriented IS. While the first two studies address Research Question 1, the second survey is associated with Research Question 2 (cf. Fig. 2).

This work has been conducted in the EcoPOST project [8], [9], [10]. This project deals with the development of a comprehensive methodology, which enables IS engineers

Study 1 Deriving the Baseline

Step 1: Interviews with Domain Experts and IS Users

Step 2: Analysis of Process & Software Documentation

Step 3: Derivation of Shortcomings and Problem Areas

Engineers, Draw Chek-kers, Documentarists, etc.

System Handbooks, Pro-cess Instructions, etc.

>120 Critical Items, 5 Problem Areas

Step 5: Cross-organizational Survey involving BPM Experts

Step 4: Cross-organizational Survey involving IT Professionals

79 Participants from more than 65 Enterprises E x p lo ra to ry C a s e S tu d y

70 Participants from more than 55 Organizations F irs t S u rv e y S e c o n d S u rv e y 1 2 3

Study 2 Detailed Analysis of Selected Issues

Study 3 Critical Success Factor Analysis

R e s e a rc h Q u e s tio n 1 R e s e a rc h Q u e s tio n 2 C o n se c u ti ve A cco m p lish m e n t

Steps: Information Sources:

Case Study Results:

Information Source: Online Survey:

Information Source: Online Survey:

Fig. 2. Three Empirical Studies.

to model and evaluate the complex economics of process-oriented IS. In particular, we focus on the interplay between technological, organizational, and project-specific evaluation factors and resulting effects.

The remainder of this paper is organized as follows. Section 2 summarizes findings of the case study and details them based on results of the first survey. Section 3 summarizes results of the second survey. Section 4 discusses our overall findings and explains why ”process-orientation” is scarce and ”process-awareness” is needed in IS engineering. Section 5 shows how we utilized our results in the EcoPOST project. Section 6 discusses related work, and Section 7 concludes with a summary and an outlook.

2

P

I

This section summarizes and discusses major findings of our case study and our first survey.

2.1 Deriving the Baseline: An Exploratory Case Study in the Automotive Domain

Over a period of three months we analyze two characteristic automotive processes (a release management process and a data retrieval process) as well as their IT support (e.g., by a PDM system with more than 5000 users). We conduct 26 interviews with software developers, domain experts, and end users. The interviews are based on a predefined, semi-structured protocol comprising two parts. The first one ad-dresses the investigated process, whereas the second part deals with specific problems of the supporting IS. Besides, we analyze process documentation and organizational handbooks. Altogether, we collect more than 120 shortcomings related to the development and operational use of the investigated IS. These included both organizational and technological aspects.

Due to lack of space, we cannot present all of these 120 shortcomings in detail. Instead, we summarize major results along five main problem areas:

• Problem Area 1: Process Evolution. According to our

case study, many problems are related to the evolution of business processes and their variability. In the analyzed domain, frequent process changes require the continuous adaptation of the supporting IS. However, realizing such adaptations is a difficult task to accomplish (cf. Problem Area 2 and Problem Area 3).

• Problem Area 2: Hard-coded Process Logic. The

ana-lyzed IS exhibit a ”hard-coded” process logic, i.e., process logic is hidden in the application code and is not sepa-rately managed, e.g., by a workflow management system (WfMS). Each time a business process changes, deep inspections and customizations of source code modules become necessary. This, in turn, results in large efforts and inefficient IS adaptations.

• Problem Area 3: Complex Software Customizing. The

analyzed IS are realized based on standard software components. Insufficient customization features of these components also result in an ineffective adaptation of process changes. In particular, existing software compo-nents lack possibilities to customize process logic at a sufficiently flexible and detailed level. This complicates the alignment of process-oriented IS to organization-specific requirements.

Besides these fundamental problem areas, we have iden-tified two additional problem areas. These are not directly related to the development of IS, but can be linked to the analysis of requirements prior to IS implementation:

• Problem Area 4: Inadequate Business Functions. Our

case study reveals that provided business functions do not effectively support business processes. Many of the implemented business functions are never used and are therefore without any ”value”. Other business functions provide more functionality than actually needed. Also, business functions which are actually needed for process support are missing, making the automation of certain process activities impossible.

• Problem Area 5: Missing Process Information. Some of

the analyzed IS log event-based execution data or status information (e.g., related to the start and completion of process activities). However, the structure of log data differs from system to system. Hence, keeping track of the processes or mining them generates large efforts (e.g., for normalizing available data). In any case, missing process information makes it difficult to identify possible process optimizations, process cycle times are longer than needed, and resources are not allocated in a cost-effective way. In summary, our exploratory case study has provided initial insight into many practical problems related to the develop-ment and maintenance of IS.

2.2 A Detailed Analysis of Selected Case Study Findings: Results from an Online Survey

In order to investigate the most-relevant results from our domain-specific case study in detail, we performed an ad-ditional (online) survey. Selected results of this survey are described in the following.

Background Information. The survey does not only

in-volve IT professionals from the automotive domain, but also from other organizations and domains as well, such as public

services, public transportation, and steel industry (cf. Fig. 3).

79 IT professionals (equating to a response rate1 of 20.2%) from more than 65 companies from Germany, Austria, and Switzerland have participated.

Most survey participants are IT consultants or software engineers. Others work in the field of IT management or IT controlling. Quality management, project management, and process design are represented as well.

0 5 10 15 20 25 A B C D E F G H I J K L A:01 (01.27%) telecommunication B:22 (27.85%) IT C:22 (27.85%) IT consulting D:04 (05.06%) automotive E:00 (00.00%) aerospace F:03 (03.80%) pharmaceutical/chemical G:02 (02.53%) engineering H:09 (11.39%) financial sector I :01 (01.27%) energy sector J:01 (01.27%) service sector K:01 (01.27%) industrial research L:11 (13.92%) other a b s o lu te n o m in a ti o n s *

*Two participants did not answer this question.

Fig. 3. Survey Background Information.

The questionnaire has been distributed via a Web-based delivery platform and comprises 29 questions. Most questions are structured, i.e., they provide a predefined set of possible answers. Some questions additionally allow to denote other than predefined answers. Some questions also allow to denote multiple answers (such questions are designated with ”*” in the subsequent Figures, e.g., in Fig. 7).

Survey Results. We first asked the survey participants

whether the current degree of process-orientation is sufficient. 25.32% of the participants state that IS only partly provide a sufficient degree of process-orientation (cf. Fig. 4). 8.86% even state that current IS do not provide a sufficient degree of process orientation at all. 29.11% of the participants consider the realized process support neither as problematic nor as ad-vantageous. Only 32.92% of the participants consider available business process support as (largely or completely) sufficient. One of the problem areas identified during our case study concerns process evolution (cf. Problem Area 1). Survey results confirm that the need to continuously adapt IS to 1. Mehta and Sivadas [11] describe that response rates for electronic surveys range from 40% to 64%. Bachmann et. al [12] identify response rates of 19% for email and 46% for mail surveys. Falconer and Hodgett [13] note that reasonable response rates for IS research are likely to be in the range of 10% to 35%. Thus, given the low response rates to IS and email surveys in general, and the large number of 29 questions, we regard the response rate to our survey as acceptable.

0 5 10 15 20 25 30

Question: Do process-oriented IS provide a sufficient degree of business process support?

A B C D E F a b s o lu te n o m in a ti o n s A:01 (01,27%) yes B:25 (31,65%) largely C:23 (29,11%) indifferent D:20 (25,32%) only partly E:07 (08,86%) no F:03 (03,80%) don’t know

Fig. 4. Degree of Process Support.

evolving processes constitutes a problem in practice. 43.04% of the survey respondents (cf. Fig. 5) answer the question, whether their current enterprise IS can be adopted to evolving business processes (and therefore to evolving requirements) quickly enough with no (2.53%) or only partly (40.51%). Only 2.53% answer this question with yes, 27.85% with largely.

0 5 10 15 20 25 30 35

Question: Can process-oriented IS be adopted to evolving business processes quickly enough?

A B C D A:02 (02,53%) yes B:22 (27,85%) largely C:18 (22,78%) indifferent D:32 (40,51%) only partly E:02 (02,53%) no F:03 (03,80%) don’t know E F a b s o lu te n o m in a ti o n s

Fig. 5. Information System Adaptations.

More than 90% of the participants agree that business processes change very often, often or sometimes in their organization (cf. Fig. 6A).

0 10 20 30 40 50 60

Question: Will the frequency of business process change increase in future when compared to today?

A:54 (68,35%) increase B:18 (22,78%) indifferent C:05 (06,33%) decrease D:02 (02,53%) don’t know a b s o lu te n o m in a ti o n s A B C D 0 5 10 15 20 25 30 35 40

Question: How often do business processes change in your organisation?

A B C D E F

A:02 (02,53%) very often B:36 (45,57%) often C:36 (45,57%) sometimes D:04 (05,06%) rarely E:00 (00,00%) never F:01 (01,27%) don’t know a b s o lu te n o m in a ti o n s A B

Additionally, 68.35% believe that the frequency of business process changes will increase in future (cf. Fig. 6B).

We also analyzed drivers for process evolution. Participants state that the need for process optimization (65.82%) is thereby the most important driver (cf. Fig. 7). Others are

organiza-tional engineering (49.37%), compliance issues (46.84%), and market dynamics (49.37%).

Question: What are factors leading to business processes evolution? 0 10 20 30 40 50 60 A B C D E F G H I J K L M N O P a b s o lu te n o m in a ti o n s A:39 B:37 C:52 D:39 E:26 F:22 G:20 H:08 I :03 J:15 K:08 L:18 M:04 N:26 O:00 P:02 (49,37%) (46,84%) (65,82%) (49,37%) (32,91%) (27,85%) (25,32%) (10,13%) (03,08%) (18,99%) (10,13%) (22,78%) (05,06%) (32,91%) (00,00%) (02,53%) organizational engineering laws and policies (compliance) process optimizations market dynamics management order change of enterprise goals new software technologies new hardware technologies compatibility with suppliers compatibility with customers norms and standards high process complexity low user acceptance quality program don’t know others

Fig. 7. Drivers of Evolution*.

Besides, we also investigate the problem of inadequate business function support in more detail (cf. Problem Area 4). 45.57% of the respondents share the opinion that business process requirements (specifying which business functions are to be implemented) must be considered when developing an IS (cf. Fig. 8A). 0 10 20 30 40 50

Question: The requirements and needs of the business processes are currently considered when developing

respectively customizing process-oriented IS?

A B C D A:07 (08,86%) yes B:42 (53,16%) largely C:15 (18,99%) indifferent D:13 (16,46%) only partly E:00 (00,00%) no F:02 (02,53%) don’t know E F a b s o lu te n o m in a ti o n s 0 5 10 15 20 25 30 35 40

Question: The requirements and needs of the business processes should be considered when developing

respectively customizing process-oriented IS?

A B C D A:36 (45,57%) yes B:33 (41,77%) if possible C:07 (08,86%) indifferent D:01 (01,27%) only partly E:01 (01,27%) no F:01 (01,27%) don’t know E F a b s o lu te n o m in a ti o n s _A B

Fig. 8. Considering Process Requirements.

41.77% state that respective requirements should be consid-ered if possible. Therewith, 87.34% of the participants expect business process requirements to be considered when imple-menting an IS. However, and this is important, only 62.02% of the participants acknowledge that respective requirements are indeed (yes and largely) considered when developing IS (cf. Fig. 8B).

2.3 Discussion

The results of both our case study and our online survey show that current IS are unable to provide business process support as needed in practice. In our case study, we have identified five major reasons for this drawback: (i) continuous evolution of business processes, (ii) hard-coded process logic of the supporting IS, (iii) complex software customization, (iv) inadequate business functions, and (v) missing process information.

Our survey confirms these problems. Moreover, it provides further insights, e.g., into the drivers of process evolution or the compliance of IS with process requirements. Picking up

Research Question 1, our results provide insights into critical

issues aggravating the introduction and operational use of IS.

3

C

S

F

A

In order to derive critical success factors (CSF) for achieving effective business process support (cf. Research Question 2), we have conducted a second online survey. As we want to identify success factors from a business process support perspective, only BPM experts have been involved in this survey. This section gives background information about this survey, presents major results, and discusses them.

3.1 Background Information

We performed our second survey over a period of two months in 2006. Like the first one, it was distributed via a Web-based questionnaire. The number of 70 participants corresponds to a response rate of 26.21%. Fig. 9 gives background information about survey participants.

The questionnaire is based on a profound literature study on

critical success factors (CSF) for IS implementation in general

(cf. Section 6) as well as on the results of the case study and our first online survey.

3.2 Survey Results

Basic to the survey2 is the distinction between organization, project-, and technology-specific CSFs.

Organization-specific Critical Success Factors.

Organi-zation-specific CSFs deal with attributes of an organization that bias the development of process-oriented IS. As an example consider domain knowledge and its positive impact on the redesign of business processes. Another example is provided by organizational process maturity. Process maturity can be assessed by dedicated maturity models that describe characteristics of effective process organizations. Examples are the capability maturity model integration (CMMI) [15] or the

software process improvement and capability determination

(SPICE) model [16]. If the process maturity of an organization is low, it will be more difficult to implement (optimized) business processes.

In our survey, end user participation (47.14%) and access to

required information (42.86%) are those organization-specific

CSFs that aggregate most nominations as ”essential factor” 2. We have described the complete findings of this survey in [14].

0 5 10 15 20 25 30 35 40 A B C D E F

Question: How would you rate your own knowledge regarding BPM?

a b s o lu te n o m in a ti o n s A:16 B:36 C:12 D:05 E:00 F:01 (22.86%) (51.43%) (17.14%) (07.14%) (00.00%) (01.43%) expert knowledge good knowledge some knowledge little knowledge no knowledge don’t know 0 5 10 15 20 25 30 A B C D E

Question: How long are you working in the field of BPM?

a b s o lu te n o m in a ti o n s A:25 B:20 C:16 D:07 E:02 (35.71%) (28.57%) (22.86%) (10.00%) (02.86%) >5 years >3 years >1 year <1 year don’t know 0 5 10 15 20 25 30 35 40 45 50 A B C D E

Question: What is your background?

a b s o lu te n o m in a ti o n s A:46 B:04 C:12 D:00 E:08 (65.71%) (05.71%) (17.14%) (00.00%) (11.43%) university industrial research industrial don’t know other A B C

Fig. 9. Survey Background Information.

(cf. Fig. 10). Factors that are considered as ”very important” are as follows: reorganization of information, availability of

process documentation, ability to redesign business processes,

and the ability of an organization to adapt its IT governance. In order to better understand the relevance of the analyzed evaluation factors, Fig. 11 shows the mean for each CSF.

0 5 10 15 20 25 30 35 Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10

Question: Evaluate the following ORGANIZATION-specific critical success factors regarding their importance for the use of BPM technology.

a b s o lu te n o m in a ti o n s Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10 A (22.86%) (34.29%) (18.57%) (32.86%) (47.14%) (42.86%) (12.86%) (14.29%) (10.00%) (17.14%)

Experiences in using BPM technology Ability to redesign business processes Reorganization of information Domain knowledge End user participation Access to required information Organizational process maturity Availability of process documentation Mature technology infrastructure Ability to adapt the IT governance E (08.57%) (07.14%) (07.14%) (11.43%) (05.71%) (07.14%) (07.14%) (05.71%) (08.57%) (08.57%) D (01.43%) (00.00%) (01.43%) (05.71%) (01.43%) (00.00%) (10.00%) (07.14%) (12.86%) (10.00%) C (41.43%) (20.00%) (24.29%) (12.86%) (15.71%) (17.14%) (32.86%) (44.29%) (44.29%) (35.71%) B (25.71%) (38.57%) (48.57%) (37.14%) (30.00%) (32.86%) (37.14%) (28.57%) (24.29%) (28.57%)

A essential B very important C important D unimportant E don’t know

Fig. 10. Organizational CSFs.

Project-specific Critical Success Factors. Project-specific

End user participation 1 0 3 u n im p o rt a n t im p o rt a n t 2 v e ry i m p o rt a n t

Experiences in using BPM technology Ability to redesign/reengineer business processes Reorganization of information Domain knowledge

Access to required information Organizational process maturity

e s s e n ti a l

Availability of process documentation Mature technology infrastructure Ability to adapt the IT governance Organization-specific Critical Success Factors (shows the mean

for each factor)

M

e

a

n

V

a

lu

e

s

Fig. 11. Organizational CSFs (Means).

CSFs deal with project-driven attributes which influence the development of process-oriented IS. As examples consider factors such as knowledge about existing processes or access

to required skills.

Question: Evaluate the following PROJECT-specific critical success factors regarding their importance for the use of BPM technology. 0 5 10 15 20 25 30 35 40 45 50 Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10 Q 11 Q 12 Q 13 a b s o lu te n o m in a ti o n s

A essential B very important C important D unimportant E don’t know

Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10 Q 11 Q 12 Q 13 A (35.71%) (32.86%) (25.71%) (11.43%) (04.29%) (02.86%) (20.00%) (45.71%) (67.14%) (15.71%) (25.71%) (22.86%) (38.57%)

Overview of existing processes Knowledge about existing processes Information about existing processes Evolutionary process redesign Revolutionary process redesign Degree of job redesign End user fears

Communication with end users Management commitment Use of process modeling tools Adequate planning Access to required skills Motivation for the project E (11.43%) (10.00%) (10.00%) (14.29%) (17.14%) (18.57%) (18.57%) (10.00%) (10.00%) (08.57%) (08.57%) (10.00%) (08.57%) D (01.43%) (01.43%) (00.00%) (08.57%) (15.71%) (12.86%) (02.86%) (01.43%) (01.43%) (02.86%) (02.86%) (02.86%) (01.43%) C (20.00%) (18.57%) (32.86%) (44.29%) (44.29%) (45.71%) (17.14%) (12.86%) (05.71%) (40.00%) (28.57%) (27.14%) (18.57%) B (31.43%) (37.14%) (31.43%) (21.43%) (18.57%) (20.00%) (41.43%) (30.00%) (15.71%) (32.86%) (34.29%) (37.14%) (32.86%) Fig. 12. Project-specific CSFs.

According to our survey (cf. Fig. 12), management

commit-ment (67.14%) and communication with end users (45.71%)

aggregate most nominations as ”essential” project-specific factors. Several other CSFs are considered as ”very important”, including degree of job redesign, information about existing

processes, and project motivation. Fig. 13 shows the mean for

each CSF.

Technology-specific Critical Success Factors.

Technolo-gy-specific CSFs deal with the technical infrastructure for developing and maintaining IS. As an example consider the

degree of flexibility provided by an IS (e.g., regarding its ability

to allow for dynamic process changes at run-time; cf. Problem Area 1). Another example is the use of standards for process specification (e.g., BPMN, WS-BPEL, BPML).

1 0 2 3 u n im p o rt a n t im p o rt a n t v e ry i m p o rt a n t e s s e n ti a l

Revolutionary process redesign Overview of existing processes

Knowledge about existing processes

Information about existing processes

Evolutionary process redesign

Degree of job redesign

End user fears

Communication with end users

Management commitment

Use of process modeling tools

Adequate planning

Access to required skills

Motivation for the project Project-specific Critical Success Factors (shows the mean for each factor)

M

e

a

n

V

a

lu

e

s

Fig. 13. Project-specific CSFs (Means).

Finally, consider the availability of development tools. Recently, business process intelligence (BPI) tools [17] are often discusses in this context. BPI tools analyze event-based process execution data (e.g., start and completion times of process activities, resources consumed by a process activity, process cycle times).

Question: Evaluate the following TECHNOLOGY-specific critical success factors regarding their importance for the use of BPM technology. 0 5 10 15 20 25 30 Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10 Q 11 Q 12 a b s o lu te n o m in a ti o n s

A essential B very important C important D unimportant E don’t know

Q 1 Q 2 Q 3 Q 4 Q 5 Q 6 Q 7 Q 8 Q 9 Q 10 Q 11 Q 12 A (12.86%) (10.00%) (12.86%) (12.86%) (07.14%) (14.29%) (04.29%) (17.14%) (05.71%) (05.71%) (20.00%) (04.29%)

Technical maturity of the BPM platform Experiences using the BPM platform Available support for the BPM platform Supported degree of process flexibility Availability of developing tools Support of standards and norms Low license costs Good documentation Regular product updates Model-driven application development Usability of the BPM platform Powerful application programming interface E (12.86%) (11.43%) (11.43%) (11.43%) (15.71%) (11.43%) (12.86%) (12.86%) (12.86%) (14.29%) (11.43%) (14.29%) D (04.29%) (11.43%) (07.14%) (08.57%) (08.57%) (14.29%) (34.29%) (04.29%) (30.00%) (15.71%) (04.29%) (17.14%) C (38.57%) (35.71%) (32.86%) (27.14%) (34.29%) (32.86%) (35.71%) (27.14%) (38.57%) (37.14%) (27.14%) (32.86%) B (31.43%) (31.43%) (35.71%) (40.00%) (34.29%) (27.14%) (12.86%) (38.57%) (12.86%) (27.14%) (37.14%) (31.43%) Fig. 14. Technological CSFs.

Interestingly, none of the listed technology-specific CSFs is considered as essential by the majority of the survey respondents (cf. Fig. 14). Good documentation (17.14%) and

usability (20%) get most nominations as ”essential factors”.

Moreover, these two factors are considered as ”very important” by many survey participants (38.57% and 37.14%).

Several CSFs are considered as ”very important” or ”im-portant”. These CSFs include: available vendor support for a

BPM system and availability of suitable development tools.

Note that the number of survey respondents giving no answer (i.e., denoting ”don’t know”) does only slightly vary along the analysis of technology-specific CSFs (cf. Fig. 14). This indicates that some survey participants might not have been able to interpret the listed CSFs. Fig. 15 shows the mean for each CSF.

Availability of developing tools Technical maturity of the BPM platform

Experiences using the BPM platform Available support for the BPM platform

Supported degree of process flexibility

Support of standards and norms Low license costs

Good documentation Regular product updates Model-driven application development

Usability of the BPM platform Powerful application programming interface

1 0 2 3 u n im p o rt a n t im p o rt a n t v e ry i m p o rt a n t e s s e n ti a l Technology-specific Critical Success Factors

(shows the mean for each factor)

M

e

a

n

V

a

lu

e

s

Fig. 15. Technological CSFs (Means).

3.3 Discussion

Based on the results of the second survey, we answer Research

Question 2 (cf. Section 1). Thereby, it seems hardly possible

to consider all technology-specific CSFs when introducing an IS. In any case, these CSFs represent a validated baseline for enterprises that want to increase the effectiveness of their process-oriented IS.

Basic to our survey is the distinction between organization-, project-organization-, and technology-specific CSFs. It is possible to categorize CSFs in another way (e.g., using more technical categories). We consider the chosen categorization as the most useful one. In particular, it provides an intuitive baseline that can be easily understood by IT professionals (including our survey participants).

To ensure internal validity of our survey results we have developed the questionnaire based on the results of the pre-ceding case study and online survey as well as on a literature study on CSFs for IS implementation (cf. Section 6).

To increase external validity, only BPM experts may par-ticipate, i.e., we exclude answers of respondents having no ”process background” since the ”assumed answers” of these participants would falsify results. In this context, it is also important to mention that the survey questionnaire has allowed to denote other than the predefined answers. However, this opportunity was not used.

4

I

Based on results of our first survey, we take a closer look at the dissemination of process-oriented software technologies and explain why orientation” is scarce and why ”process-awareness” is needed in practice.

4.1 Process-oriented Software Technologies

In recent years, many process support paradigms (e.g., work-flow management, service orchestration and service choreogra-phy, case handling), process specification standards (e.g., WS-BPEL, BPML, BPMN), and BPM tools (e.g., ARIS Toolset, Tibco Staffware, FLOWer) have emerged [18]. Their goal is to realize effective IT support for business processes. In our

first survey, we have investigated the dissemination of these

approaches in more detail.

63.29% of the respondents confirm the use of WfMS (cf. Fig. 16). 36.71% even deploy more comprehensive BPM

systems. 53.16% of the respondents confirm the (exploratory)

use of web services. 32.91% already set up complete

service-oriented architectures. Enterprise application integration

plat-forms (e.g., to enable process integration) are applied by 39.24% of the respondents.

These results do not allow for any conclusion regarding the extent to which enterprises use a respective technology. Nevertheless, the increasing importance and use of process-oriented software technologies is indicated.

0 10 20 30 40 50 60 A B C D E F G H

Question: Which software technologies are used in your organization today?

I J K L M a b s o lu te n o m in a ti o n s A:50 B:29 C:31 D:26 E:19 F:25 G:53 H:36 I :24 J:42 K:27 L:05 M:03 (63,29%) (36,71%) (39,24%) (32,91%) (24,05%) (31,65%) (54,43%) (45,57%) (30,38%) (53,16%) (34,18%) (06,33%) (03,80%)

Workflow management systems BPM systems

Enterprise application integration Service-oriented architectures Rule-based systems Process portals

Knowledge and enterprise portals Data warehousing technologies Business intelligence Web services Collaboration tools Don’t know Others

Fig. 16. Technologies used Today*.

In order to investigate the sustainability of this trend, we have asked survey participants about which process-oriented software technologies they will use in future (cf. Fig. 17). The most frequent answers are WfMS (39.24%), services-oriented

architectures (36.71%), web services (32.91%), and process portals (30.38%). This indicates a continuing dissemination

of process-oriented software technologies.

4.2 Process-aware Information Systems

Our empirical studies (cf. Fig. 18) indicate that providing effective business process support by IS is a difficult task

Question: Which software technologies are planned to be used in your organization in the future?

0 5 10 15 20 25 30 35 A B C D E F G H I J K L M a b s o lu te n o m in a ti o n s A:31 B:22 C:17 D:29 E:12 F:24 G:21 H:21 I :23 J:26 K:17 L:16 M:04 (39,24%) (27,85%) (21,52%) (36,71%) (15,19%) (30,38%) (26,58%) (26,58%) (29,11%) (32,91%) (21,52%) (20,25%) (06,06%)

Workflow management systems BPM systems

Enterprise application integration Service-oriented architectures Rule-based systems Process portals

Knowledge and enterprise portals Data warehousing technologies Business intelligence Web services Collaboration tools Don’t know Others

Fig. 17. Technologies used Tomorrow*.

to accomplish. The currently realized degree of ”process-orientation” in IS is by far not satisfactory. By contrast, enterprises more and more crave for approaches that enable them to improve their business process performance. Reflect-ing the aforementioned results, we conclude that conventional process-oriented IS are scarce. What we need instead, are

process-aware IS (PAIS), i.e., IS that support all phases all

of the process life cycle.

PAIS can be implemented in two ways [18]: (1) by de-veloping an organization-specific process support system, or (2) by configuring a generic process support system. In the former case, the PAIS is build ”from scratch” and incorporates organization-specific information about the structure and pro-cesses to be supported. As an example consider an enterprise

resource planning (ERP) system. In the latter case, the PAIS

does not contain any information about the structure and the processes of a particular organization. Instead, an organization needs to configure the PAIS by specifying processes, organi-zational entities, and business objects. As an example consider the configuration of a WfMS.

In any case, PAIS strictly separate process logic (comprising the activities to be executed) from application code [19], i.e., PAIS are driven by process models rather than program code. PAIS are realized based on powerful process engines which orchestrate processes at run-time [20]. These process engines also provide extensive libraries of process-oriented functions at build-time, e.g., for accomplishing automatic process analysis (based on BPI tools). Empirical studies [21] confirm that PAIS enable the fast and cost-effective implementation and customization of new and of existing processes (cf. Problem Areas 2 + 3).

Realizing PAIS also implies a significant shift in the field of IS engineering. Traditional IS engineering methods and paradigms (e.g., procedural programming) have to be supple-mented with engineering principles particularly enhancing the operational support of business processes. This is crucial to tie up to those requirements that have been neglected by current

Organization-specific CSFs Technology-specific CSFs Process-oriented Information Systems Problem Areas (PA) Process-aware Information Systems Critical Success Factors enable the introduction of Project-specific CSFs Process Evolution Hard-coded Process Logic Complex Soft-ware Customizing Inadequate Business Functions Missing Pro-cess Information Case Study Survey 2

Research Question 1: What are the major problems leading to ineffective process support by IS?

Research Question 2: What are CSFs enabling effective process support by IS?

PA1 PA2 PA3 PA4 PA5

Survey 1 Subject of

Analysis

promise to overcome

Fig. 18. Three Empirical Studies: The Big Picture.

process-oriented IS so far. However, such a shift is difficult to accomplish as IS projects often use software technologies – at least today – that do not support the needed degree of process-orientation.

5

U

R

E

POST

In the EcoPOST project, we are developing a framework for modeling and investigating the complex interplay between the numerous technological, organizational and project-driven cost and impact factors which arise in the context of process-oriented IS and PAIS (and which do only partly exist in projects dealing with data- or function-centered IS).

Costs for business process redesign, for example, may be influenced by an intangible impact factor ”Willingness of Staff Members to support Redesign Activities”. If staff members do not contribute to a redesign project by providing needed information (e.g., about process bottlenecks), any redesign effort will be ineffective and will increase costs. If staff willingness is additionally varying during the redesign activity (e.g., due to a changing communication policy), business process redesign costs will be subject to more complex effects.

5.1 Motivating Example

In order to make the dependencies and the interplay between technological, organizational and project-driven factors ex-plicit in the EcoPOST project, we have developed the notion of evaluation models [10]. These models are formulated using the System Dynamics notation [22]. In addition, they can be simulated in order to unfold the dynamic behavior described by them. In the following, we abstract from formal and technical details regarding our evaluation models. Instead, we show how we validate our evaluation models based on the present survey results along an example.

Example. Fig. 19 shows a model which describes the

influence of an impact factor ”End User Fears” on a cost factor ”Costs for Business Process Redesign”. More specifically, this model reflects the assumption that the introduction of a PAIS may cause end user fears, e.g., due to job redesign and due to changed social clues. Such fears can lead to emotional resistance of end users. This, in turn, can make it difficult to get needed support from end users, e.g., during an interview-based process analysis.

Illustrating Example: Analyzing the Role of „End User Fears“

LOOP Degree of

Job Redesign

Change of Social Clue and

Interactions End User Fears Communication Ability to redesign Business

Processes acquire ProcessAbility to Knowledge Emotional Resistance of End Users + -+ + -+

Costs for Business Process Redesign

+ +

Fig. 19. Modeling the Impact of User Fears.

Basic to this evaluation model is a cyclic structure (or

feedback loop) connecting the four factors ”End User Fears”,

”Emotional Resistance of End Users”, ”Ability to acquire Process Knowledge”, and ”Ability to redesign Business Pro-cesses”. Their arrangement illustrates the following coherence: increasing end user fears lead to increasing emotional resis-tance of end users. This dependency is represented by a ”pos-itive link” from ”End User Fears” to ”Emotional Resistance of End Users” (cf. Fig. 19).

and y (with y the dependent variable) indicates that y tends in the same direction if a change occurs in x. A negative link, by contrast, would denote that y tends in the opposite direction.

Returning to our example, an increasing emotional resis-tance of end users may result in a decreasing ability to ac-quire process knowledge. Reason is that increasing emotional resistance makes profound process analysis, e.g., based on interviews with process participants, a difficult task to accom-plish. This causal dependency is represented by a negative link pointing from ”Emotional Resistance of End Users” to ”Ability to acquire Process Knowledge”.

The inability to acquire process knowledge, in turn, may result in a decreasing ability to redesign business processes (as needed information is missing). Finally, an increasing ability to redesign business processes can even enforce end user fears. Reason is that end users often consider business process redesign activities as a potential threat for their own job.

Note that the variable ”End User Fears” is not only influ-enced by the ”Ability to redesign Business Processes”, but by other variables as well, e.g., the expected ”Degree of Job Redesign” or the ”Change of Social Clue and Interactions”. Moreover, ”Communication” can decrease end user fears, e.g., by informing end users about the goals associated with the introduction of a PAIS. This is described by a negative link pointing from ”Communication” to ”End User Fears”.

Model Validation. Such evaluation models (cf. Fig. 19) are

of significant value for PAIS engineers. They can be used, for example, as a starting point for building more complex eval-uation models enabling the performance of cost simulations [23], or as a means for clarifying causal dependencies in PAIS engineering projects.

However, the expressiveness of such evaluation models depends on the availability, plausibility and resilience of data supporting the modeled causal dependencies. One approach to derive such data is the accomplishment of both empirical and experimental research activities (e.g., software experiments, online surveys, case studies).

Taking the results of our second online survey (cf. Section 3), for example, we can validate some of the causal depen-dencies from the evaluation model in Fig. 19.

5.2 Empirical Model Validation

In the second online survey we analyzed, for example, the causal dependency between ”End User Fears” and ”Emotional resistance of End Users” as well as the dependency between ”Communication” and ”End User Fears”.

For this purpose, we use a four-step sequence of questions to derive data. First, we ask for the relevance of a given factor (Question 1). Second, we want to know whether there exists a

causal dependency between this factor and another one

(Ques-tion 2). Only those survey participants – and this is important for understanding related results – who answer this second question with ”yes” are directed to two additional questions. These additional questions deal with the further specification of the previously confirmed dependency. Question 3 deals with the semantic specification of the dependency, whereas Question 4 addresses the strength of the impact.

0 5 10 15 20 25 A B C D E

Question 4: How strong is the specified impact of this relationship?

a b s o lu te n o m in a ti o n s 0 5 10 15 20 25 30 35 40 45 A B C D E F

Question 3: What is the direction of this relationship?

a b s o lu te n o m in a ti o n s 0 10 20 30 40 50 60 A B C

Question 2: Does there exists a relationship between end user fears and emotional resistance against BPM technology?

a b s o lu te n o m in a ti o n s 0 5 10 15 20 25 30 35 A B C D E

Question 1: How critical are end user fears for the success of a BPM project / for introducing BPM technology?

a b s o lu te n o m in a ti o n s A B C D A:20 B:32 C:06 D:04 E:08 (28.57%) (45.71%) (08.57%) (05.71%) (11.43%) very critical critical negligible not critical don’t know A:49 B:06 C:15 (70.00%) (08.57%) (21.43%) yes no don’t know A:21 B:23 C:03 D:00 E:02 (42.86%) (46.94%) (06.12%) (00.00%) (04.08%) very strong strong weak very weak don’t know A:41 B:02 C:03 D:00 E:02 F:01 (83.67%) (04.08%) (06.12%) (00:00%) (04.08%) (02.04%) increasing UF increasing ER increasing UF decreasing ER increasing ER increasing UF increasing ER decreasing UF don't know

there is another relationship UF = End User Fears

ER = Emotional Resistance

Fig. 20. The Impact of End User Fears.

Dealing with End User Fears. Consider Fig. 20. A majority

of 74.28% of the participants consider end user fears as ”very critical” (28.57%) or ”critical” (45.71%) for the overall success of a BPM project (cf. Fig. 20A). More specifically, 70% of the respondents confirm that there is a relationship between end user fears and the emotional resistance of end users against BPM technology (cf. Fig. 20B). This confirms the link between ”End User Fears” and ”Emotional Resistance of End Users” in Fig. 19.

What is still not clear at this point is the direction of the causal dependency – there are several possibilities in this respect (cf. Fig. 19). However, the semantics of the link can be clarified based on the next question.

83.67% share the opinion that increasing end user fears result in increasing emotional resistance (cf. Fig. 20C). This confirms that ”End User Fears” and ”Emotional Resistance of

End Users” need to be connected with a positive link pointing from the former variable to the latter one.

Finally, 89.8% of the respondents state (cf. Fig. 20D) that the impact of end user fears on emotional resistance is either ”very strong” (42.86%) or ”strong” (46.94%). This information helps us to quantify the causal dependency when we simulate the evaluation model.

Dealing with Communication. In the evaluation model

from Fig. 19, we assume that increasing communication results in decreasing end user fears. 92.86% of the survey participants consider communication between the stakeholders of a BPM project as ”essential” (47.14%), ”very important” (35.71%) or ”important” (10%) for its success. Furthermore, 78.57% of the respondents confirm that there is a causal dependency between communication and end user fears. Out of these, 74.55% are the opinion that an increasing communication results in decreasing end user fears. This confirms that ”Com-munication” and ”End User Fears” can be connected with a negative link pointing from the former variable to the latter one. Finally, 85.45% of the respondents consider the impact of communication on end user fears as either ”very strong” (29.09%) or ”strong” (56.36%). This information helps us when specifying a corresponding EcoPOST simulation model for this evaluation model.

These results exemplify how we utilize survey results for validating (or deriving) EcoPOST evaluation models.

6

R

W

There exist several studies dealing with CSFs for imple-menting IS, mainly in the context of ERP systems. Yusufa et. al [24], for example, investigate the introduction of an ERP system in a large manufacturing organization. This work focuses on technological and cultural CSFs and compares expected benefits of the realized ERP system with its actual ones. Vogt [25] analyzes failed ERP projects and identifies – from a software engineering viewpoint – factors which help to avoid such failures. A similar study is described by Voordijk [26], who investigates ERP implementations in large construction firms. Mandal et. al [27] describe experiences gathered during during the planning and implementation stages of an ERP implementation in a water corporation. Daneva and Wieringa use a ”success model” for reasoning about the factors enabling successful ERP implementations [28]. Focusing on risk factors, Sumner [29] investigates the re-engineering of processes prior to an ERP project. Discussed issues imply the recruiting and training of IT professionals, the involvement of consultants, and the integration of application-specific knowledge and technical expertise into the project team.

CSFs for workflow implementations are described by Parkes [30], [31]. Thereby, three CSFs are identified as being particu-lar important: management commitment, communication, and participation by end users. Note that our results confirm the importance of these three factors.

Focusing on organizational issues, Sarmento and Machado [32] investigate the impact of workflow implementations on an organization, identify relevant contingency factors, and

describe organizational domains which are affected by a WfMS. In his qualitative study [33], Kueng also investigates the impact of WfMS on organizations.

Davenport [34] deals with only one CSF, namely the ability of an organization to align its IS to business processes and business strategy. Baroudi et. al [35] investigate the impact of user involvement on IS usage and information satisfaction. Their results demonstrate that user involvement during IS development will enhance system usage and user satisfaction. Their results also show that growing user satisfaction results in greater system usage.

All these studies have been considered when conducting our empirical research. In particular, the work of Parkes [30], [31] has contributed to the design of the questionnaire for our sec-ond survey. However, none of these studies distinguishes be-tween organization-, project-, and technology-specific factors (though Parkes [30], [31] distinguishes between organizational and technological factors).

7

S

O

Two research questions (cf. Section 1) have guided the em-pirical research presented in this paper. In this context, we have conducted three empirical studies: an exploratory case study in the automotive domain and two cross-organizational online surveys. The case study and the first survey enable us to identify and analyze major problems related to the development, maintenance and operational use of process-oriented IS (cf. Research Question 1). The second online survey deals with CSFs for building better, i.e., more effective process-oriented IS and/or PAIS (cf. Research Question 2).

We have also discussed potential implications of our find-ings to the field of IS engineering. In particular, we have indi-cated that mere orientation” is scarce, but ”process-awareness” is needed in practice. In this context, we have also given a short characterization of PAIS. Finally, we have described the utilization of our results to validate causal de-pendencies in evaluation models of the EcoPOST framework. Altogether, this paper provides insights into important issues and challenges related to the introduction and use of IS in practice. It helps both IT professionals and researchers to understand those factors that can improve the operational effectiveness of process-oriented IS.

Future work will include additional case studies, online surveys, and controlled software experiments to generate ad-ditional data we can use for validating our evaluation models. Finally, we will investigate the impact of agile software development processes on the realization of PAIS.

R

[1] Y. L. Antonucci, Using Workflow Technologies to Improve Organizational Competitiveness, Int’l. Journal of Management, 14(1), pp.117-126, 1997.

[2] E. Knippel and A. Schulz, Lessons Learned from Implementing Config. Manag. within Electrical/Electronic Development of an Automotive OEM, Proc. 14th INCOSE, 2004.

[3] D. M¨uller, J. Herbst, M. Hammori, and M. Reichert, IT Support for Release Management Processes in the Automotive Industry, Proc. 4th BPM, LNCS 4102, pp.368-377, 2006.

[4] J. Gordijn and H. Akkermans, Value-based Requirements En-gineering: Exploring Innovative E-Commerce Ideas, Int’l. J. of Requirements Engineering, 8, pp.114-134, 2003.

[5] S. Bassil, Workflow Technology for Complex Socio-Technical Systems, PhD Thesis, University of Montreal, 2005.

[6] R. Lenz and M. Reichert, IT Support for Healthcare Processes: Premises, Challenges, Perspectives, Data and Knowledge Engi-neering, Volume 61, pp.39-58, 2007.

[7] W. M. P. van der Aalst, Business Process Management - A Personal View, BPM Journal, 10(2), pp.248-253, 2004. [8] B. Mutschler, M. Reichert, and J. Bumiller, An Approach for

Evaluating WfMS from a Value-Based Perspective, Proc. 10th IEEE EDOC, pp.477-482, 2006.

[9] B. Mutschler, M. Reichert, and J. Bumiller, Why Process-Orientation is Scarce: An Empirical Study of Process-oriented Information Systems in the Automotive Industry, Proc. 10th IEEE EDOC, pp.433-438, 2006.

[10] B. Mutschler, M. Reichert, and S. Rinderle, Analyzing the Dynamic Cost Factors of Process-aware Information Systems: A Model-based Approach, Proc. 19th CAiSE, pp.589-603, 2007. [11] R. Mehta and E. Sivadas, Comparing Response Rates and Response Content in Mail versus Electronic Mail Surveyed, J. of the Market Research Society, 37, pp.429-439, 1995. [12] D. Bachmann, J. Elfrink, and G. Vazzana, E-mail and Snail

Mail Face Off in Rematch, Marketing Research, 11(4), pp.11-15, 2000.

[13] D. J. Falconer and R. A. Hodgett, Why Executives Don’t Respond to Your Survey, Proc. 10th ACIS, pp.279-285, 1999. [14] B. Mutschler and M. Reichert, A Survey on Evaluation Factors

for Business Process Management Technology, Technical Report TR-CTIT-06-63, University of Twente, 2006.

[15] CMMI, Capability Maturity Model Integration, Software Engi-neering Institute: www.sei.cmu.edu/cmmi/, 2007.

[16] SPICE, Software Process Improvement and Capability dEtermi-nation, www.sqi.gu.edu.au/spice/, 2007.

[17] B. Mutschler, M. Reichert, and J. Bumiller, An Approach to Quantify the Costs of Business Process Intelligence, Proc. EMISA Workshop, LNI P-75, pp.152-165, 2005.

[18] M. Dumas, W. M. P. van der Aalst, and A. ter Hofstede, Process-aware Information Systems: Bridging People and Soft-ware through Process Technology, Wiley, 2005.

[19] J. Dehnert and W. van der Aalst, Bridging the Gap between Business Models and Workflow Specification, Int’l. J. of Coop. IS, 13(3), 289-332, 2004.

[20] M. Reichert, S. Rinderle, U. Kreher, and P. Dadam, Adaptive Process Management with ADEPT2, Proc. 21th ICDE, pp.1113-1114, 2005.

[21] N. Kleiner, Can Business Process Changes be cheaper Imple-mented with Workflow-Management-Systems?, Proc. IRMA ’04, pp.529-532, 2004.

[22] J. D. Sterman, Business Dynamics - Systems Thinking and Modeling for a Complex World, McGraw-Hill, 2000.

[23] B. Mutschler and M. Reichert, Exploring the Dynamic Costs of Process-aware IS through Simulation, Proc. Workshops and Doctoral Consortium at 19th CAiSE ’07, Volume 1, EMMSAD Workshop, pp.173-182, 2007.

[24] Y. Yusufa, A. Gunasekaranb, and M. S. Abthorpe, Enterprise Information Systems Project Implementation: A Case Study of ERP in Rolls-Royce, Int’l. J. of Production Economics, Volume 87, pp.251-266, 2004.

[25] C. Vogt, Intractable ERP: A comprehensive Analysis of failed Enterprise-Resource-Planning Projects, ACM SIGSOFT Soft-ware Engineering Notes, 27(2), pp.62-68, 2002.

[26] H. Voordijk, A. van Leuven, and A. Laan, Enterprise Resource Planning in a Large Construction Firm: Implementation Anal-ysis, Construction Management and Economics, 21(5), pp.511-521, 2003.

[27] P. Mandal and A. Gunasekaran, Issues in Implementing ERP: A Case Study, European Journal of Operational Research, 146,

pp.274-283, 2003.

[28] M. Daneva and R. Wieringa, A Conceptual Framework for Research in Cross-organizational ERP Cost Estimation, Proc. PROMan Workshop, 2005.

[29] M. Sumner, Risk Factors in Enterprise-wide/ERP Projects, J. of Information Technology, 15(4), pp.317-327, 2000.

[30] A. Parkes, Critical Success Factors in Workflow Implementation, Proc. 6th PACIS, pp.363-380, 2002.

[31] A. Parkes, A Case Study of Workflow Implementation Success Factors, Proc. 15th ACIS, 2004.

[32] A. Sarmento and A. Machado, The Adoption of Workflow Systems: Proposal of a Model for a Methodology to Analysis the Impact of Workflow Systems in Organizations, Proc. 2nd ICEIS, pp.349-355, 2000.

[33] P. Kueng, The Effects of Workflow Systems on Organization: A Qualitative Study, Business Process Management, LNCS 1806, pp.301-316, 2000.

[34] T. H. Davenport, Mission Critical: Realizing the Promise of Enterprise Systems, 2000.

[35] J. J. Baroudi, M. H. Olson, and B. Ives, An Empirical Study of the Impact of User Involvement on System Usage and Informa-tion SatisfacInforma-tion, Comm. ACM, 29(3), pp.232-239, 1986.

Bela Mutschler Bela Mutschler received his diploma in computer science from the University of Ulm, Ger-many, in 2003. Currently he works as a process engi-neer at DaimlerChrysler (Group Research), Germany. Bela is an expert in the fields of automotive process management and software engineering, business pro-cess management (BPM), and propro-cess maturity mod-els (such as CMMI). Besides, he is an external Ph.D. student in the Information Systems Group at the Uni-versity of Twente (UT), The Netherlands, where he is currently finishing his Ph.D. thesis. In his dissertation, Bela investigates causal dependencies and resulting cost effects in projects dealing with the introduction of process-aware information systems.

Manfred Reichert Manfred Reichert holds a Ph.D. in computer science and is currently Associate Profes-sor in the Information Systems Group at the University of Twente (UT), The Netherlands. At UT he is also a member of the Management Team of the Centre for Telematics and Information Technology (CTIT), which is the largest ICT research institute in the Nether-lands. Before Manfred joined UT in January 2005, he had been assistant professor in the Institute for Databases and Information Systems at the University of Ulm, Germany. There, he also finished his Ph.D thesis on adaptive process management in July 2000 (with honours). Manfred received several awards for his outstanding work on the ADEPT process management technology. He is an expert in the field of business process man-agement (BPM) and has conducted many BPM-related projects in application domains like healthcare and automotive engineering.

Johannes Bumiller Johannes Bumiller received a diploma in computer science from the University of Karlsruhe, Germany. Afterwards, he joined the AEG research center in Ulm, Germany, which was later merged in the DaimlerChrysler corporate research. Johannes is an expert on the the development of interactive systems, on the design of user interfaces, and on workflow support. Currently, his research is concentrating on the integration of distributed E/E development processes.