Why Process-Orientation is Scarce: An Empirical Study of
Process-oriented Information Systems in the Automotive Industry
Bela Mutschler, Johannes Bumiller
DaimlerChrysler Research & Technology
P.O. Box 2360, 89013 Ulm, Germany
{bela.mutschler;johannes.bumiller}@daimlerchrysler.com
Manfred Reichert
University of Twente
Information Systems Group
Abstract
Several studies have indicated that existing IS (IS) often
fail to provide adequate business process support. To sys-
tematically identify the reasons for this drawback, we con-
ducted a case study in the automotive domain and a survey
among 79 IT practitioners. This paper presents the findings
of this empirical research and explains why mere ”process-
orientation” (regarding business process support) is scarce.
1 Motivation
Effectively managing the flow of work within their or-
ganization is crucial for enterprises. One critical success
factor in this context concerns the alignment of information
systems (IS) and business processes [6]. In the automotive
domain, for example, a broad spectrum of processes ranging
from administrative procedures to knowledge-intense engi-
neering processes has to be supported by IS. As a typical ex-
ample, consider a product data management (PDM) system,
which usually offers a broad range of business functions for
the integrated support of engineering processes and product
data management.
However, many contemporary enterprise IS fail to pro-
vide adequate business process support. The reasons for
this drawback are manifold. To systematically identify the
reasons for this drawback, we conducted a case study in the
automotive domain and a survey among 79 IT practitioners.
In particular, it was our goal to identify shortcomings that
derogate the development, maintenance, and use of process-
oriented IS in practice. Our empirical research has been
guided by four research questions:
•RQ#1: What are major problems leading to inadequate
business process support in IS?
•RQ#2: What are the rationales for these problems?
•RQ#3: What are critical success factors which help to
overcome the identified problems?
•RQ#4: What is needed from the perspective of IS en-
gineering to provide more effective process support?
The analysis and discussion of these research questions
is reflected by the structure of this paper. Section 2 shortly
sketches the research methodology underlying our empiri-
cal research. Section 3 presents the findings of a case study
we conducted in the automotive domain, and amends them
with results of a cross-organizational survey among 79 IT
practitioners. Both activities were accomplished to iden-
tify and analyze shortcomings and problem areas related
to the development, maintenance and operational support
of process-oriented IS (RQ#1 and RQ#2). Based on these
empirical results, Section 4 derives critical success factors
for process-oriented IS (RQ#3). Section 5 shortly discusses
our findings from a practical perspective and explains why
mere ”process-orientation” is scarce in today’s IS engineer-
ing (RQ#4). The paper concludes with a summary and an
outlook in Section 6.
2 Research Methodology
This section illustrates the design of our empirical re-
search (cf. Fig. 1). In particular, it consists of two separated
studies: a case study and a survey.
We conducted a case study in the automotive domain
over a period of three months across several engineering
departments. This case study focused on the identification
of shortcomings hampering the effective support of a major
automotive business processes. Altogether, we conducted
26 formal interviews and additionally analyzed documen-
tation such as handbooks, guidelines, and process instruc-
tions. The case study resulted in a list of more than 120
Step #1: interviews with domain
experts and IS users
Step #2: analysis of available
process & software documentation
Step #3: derivation of
shortcomings and problem areas
engineers, draw checkers,
documentarists, etc.
system handbooks, pro-
cess instructions, etc.
>120 critical items,
5 problem areas
Step #5: critical success factor
analysis
Step #4: cross-organizational
survey among IT professionals
79 participants from more
than 65 enterprises
Section 3
Section 4
Figure 1. Research Methodology.
shortcomings negatively affecting the efficiency and the ef-
fectiveness of the examined process. As the presentation of
all items is neither possible (due to space restrictions) nor
reasonable (as most items are very specific), we generalize
the results and abstract from the list’s level of detail.
Analyzing the case study results, we wanted to see
whether our findings are representative for enterprise IS in
general. Thus, we decided to additionally perform a survey
in order to put the findings of the case study on a more reli-
able and broader basis. This survey did not only involve IT
professionals from the automotive industry, but from other
organizations and domains as well. Altogether, 79 IT prac-
titioners from more than 70 companies all over Germany,
Austria, and Switzerland participated. Figure 2 shows the
different industry domains the survey participants belong to.
Other named sectors include public services,public trans-
portation, and steel industry.
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
absolute nominations
Figure 2. Industry Branches.
Most survey participants were IT consultants (29.11%)
and software engineers (29%). Others worked in the IT
management (22.78%) and the IT controlling (22.78%).
Quality management,project management, and process de-
sign were named as well.
The questionnaire was distributed via a web-based de-
livery platform. It included 29 questions. Most questions
were structured, i.e., provided a predefined set of possi-
ble answers. Some questions also allowed for other than
the predefined answers or for multiple answers1. The total
number of responses was 79.
3 Primary Empirical Findings
This section presents the aggregated results of the case
study and the survey described in Section 2. In particular,
we identify and discuss five problem areas (PA#1 to PA#5)
that affect the effective development, maintenance and use
of process-oriented IS:
PA1: Process Evolution. The case study revealed that
many problems are related to the evolution of processes and
their variability across different car lines. This necessitates
the continuous adaptation of the IS and, consequently, the
business process implementations.
We analyzed the phenomenon of process evolution in
more detail in our survey. First, the survey confirms that
the continuous adaptation of IS to evolving requirements
constitutes a problem. Second, 43.04% of the survey partic-
ipants (cf. Fig. 3) answer the question whether their current
enterprise IS can be adopted to evolving business processes
(and therefore to evolving requirements) quick enough with
no (2.53%) or rather no (40.51%). Only 30.38% answer
this question with yes (2.53%) or rather yes (27.85%).
0
5
10
15
20
25
30
35
Question: Can enterprise information systems be adopted to
evolving business processes sufficiently fast?
ABCD
A:02 (02,53%) yes
B:22 (27,85%) rather yes
C:18 (22,78%) indifferent
D:32 (40,51%) rather no
C:02 (02,53%) no
D:03 (03,80%) don’t know
E F
absolute nominations
Figure 3. IS Adaptations.
More than 90% of the participants agree that business
processes within their organization change very often,often,
or sometimes (cf. Fig. 4A). Additionally, 68.35% believe
that the frequency of business process changes will increase
in future (cf. Fig. 4B).
We further analyzed potential drivers for process evo-
lution in more detail. Participants state that the need for
1Respective questions are designated with a ”*” in the following.
process optimization (65.82%) is the most important driver
in this context (cf. Fig. 5). Other ones are organizational
restructuring (49.37%), compliance issues (46.84%), and
market dynamics (49.37%). Also mentioned drivers are or-
ganic growth as well as mergers and acquisitions.
0
5
10
15
20
25
30
35
40
A) 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%) rare
E:00 (00,00%) never
F:01 (01,27%) don’t know
0
10
20
30
40
50
60
A:54 (68,35%) increase
B:18 (22,78%) indifferent
C:05 (06,33%) decrease
D:02 (02,53%) don’t know
B) Question: Will the frequency of business process change
increase in the future compared to today?
AB C D
absolute nominationsabsolute nominations
Figure 4. Process Changes.
PA2: Hard-coded Process Logic. All IS analyzed dur-
ing the case study exhibited a ”hard-coded” process logic,
i.e., the process logic is hidden in the application code and
not managed separately (e.g., by the use of a workflow man-
agement system). This makes the adaptation of business
processes a difficult task. In fact, most software technolo-
gies currently used to implement IS are not providing suit-
able mechanisms to separate process logic from applica-
tion code at build-time and to provide comprehensive pro-
cess support during runtime. Instead, source code has to
be inspected to identify the implementation artifacts (e.g.,
modules, routines) that incorporate fragments of the process
logic.
PA3: Complex Procedures for Software Customizing.
The interviews conducted during our case study revealed
that most IS fail to meet basic functional requirements. As
major reason for this phenomenon, we identified the real-
ization of IS based on off-the-shelf standard software com-
ponents. This results in high efforts for implementing cus-
tomized business functions. However, none of the analyzed
IS offered interfaces that enabled software customization at
a sufficiently detailed level.
PA4: Inadequate Business Functions. Our case study
also revealed that many IS fail to adequately satisfy func-
tional needs. Many implemented business functions are
0
10
20
30
40
50
60
A B C D E F G H
Question: What are factors that lead to business processes evolution?
I J K L M N O P
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 restructuring
laws and policies
process optimizations
market development & 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
absolute nominations
Figure 5. Drivers of Evolution*.
never used (and are therefore without any ”value”), or they
implement more functionality than needed and can there-
fore be regarded as too complex to be efficiently used. Even
more, some process activities cannot be covered by existing
business functions at all, i.e., the respective business func-
tion have not been implemented. This issue is a direct con-
sequence of the aforementioned discussed problem area of
software customizing.
0
5
10
15
20
25
30
35
Question: Do enterprise information system provide a
sufficient degree of business process support?
A B C D
A:01 (01,27%) yes
B:25 (31,65%) rather yes
C:23 (29,11%) indifferent
D:20 (25,32%) rather no
C:07 (08,86%) no
D:03 (03,80%) don’t know
E F
Percentage
Figure 6. Degree of Process Support.
We further analyzed this finding by our survey. Process-
orientation means to provide those business functions that
are requested by a process. However, 25.32% of the partic-
ipants state that IS do rather not provide a sufficient degree
of process orientation (cf. Fig. 6). 8.86% state that current
IS do not provide a sufficient degree of process orientation
at all. 29.11% of the participants consider the realized pro-
cess support as neither problematic nor advantageous. Only
32.92% of the participants regard the business process sup-
port currently provided as sufficient.
Furthermore, 45.57% of the survey participants state that
requirements of a business process should be explicitly con-
sidered when developing or maintaining enterprise IS (cf.
question A in Fig. 7). Another 41.77% state that respective
requirements should eventually be considered. This means
that an overall of 87.34% of the participants expect the in-
corporation of business process requirements when imple-
menting an IS.
0
5
10
15
20
25
30
35
40
Question 7A: The requirements and needs of the business
processes should be considered when developing
respectively customizing enterprise information systems?
A B C D
A:36 (45,57%) yes
B:33 (41,77%) rather yes
C:07 (08,86%) indifferent
D:01 (01,27%) rather no
C:01 (01,27%) no
D:01 (01,27%) don’t know
E F
absolute nominations
0
10
20
30
40
50
60
Question 7B: The requirements and needs of the business
processes are considered when developing
respectively customizing enterprise information systems?
A B C D
A:07 (08,86%) yes
B:42 (53,16%) rather yes
C:15 (18,99%) indifferent
D:13 (16,46%) rather no
C:00 (00,00%) no
D:02 (02,53%) don’t know
E F
absolute nominations
Figure7.ConsideringProcessRequirements.
However, only 62.02% of the participants acknowledge
that respective requirements are indeed (yes and rather yes)
considered when developing and maintaining enterprise IS
(cf. question B in Fig. 7).
PA5: Missing Process Information. Some of the IS
analyzed during the case study log event-based execution
data (e.g., related to the start and completion of process
activities). However, log data is structured in different
ways from system to system, and only very simple log files
are used. As a consequence users are unable to keep track
of their processes or to mine [5], what makes it difficult
to quickly react to exceptional situations or to optimize
work with respect to the current process status. Therefore
process cycle times are longer than necessary and resources
are not utilized in a cost-effective way.
The described problem areas affect different stages of
the life cycle of an IS (development, maintenance, and use).
Figure 8 assigns each problem area to those stages it is in-
fluencing. As can be seen, the most significant problem area
is process evolution.
D M O
PA #1: Process Evolution
PA #2: Hard-coded Process Logic
PA #3: Complex Software Customizing
PA #4: Inadequate Business Functions
PA #5: Missing Process Information
x x x
x x
x x
x x
x x
PA = problem area; D = development; M = maintenance, O = operation
Lifecycle
Stages
Figure 8. Overview of Problem Areas.
In Section 4, we pick up our empirical findings and de-
rive critical success factors (CSF) for process-oriented IS.
4 Critical Success Factor Analysis
The empirical study presented before provides insights
into critical issues related to process-oriented IS in produc-
tion environments. This section concerns our interpretation
of the study results. In particular, we use the findings to
develop guidelines that help practitioners to overcome the
identified problems and shortcomings. We formulate these
guidelines (derived from the findings of our empirical anal-
ysis) by a number of critical success factors (CSF). Section
4.1 depicts three general applicable success factors and con-
firms their importance by additional results of our survey.
Section 4.2 introduces organization-driven success factors
and Section 4.3 deals with technology-centered ones.
4.1 General Applicable Success Factors
The success factors presented in this section deal with
issues that have to be addressed by any enterprise IS re-
gardless whether it is ”process-oriented” or not:
•CSF#1: Costs. The estimated costs of a process-
oriented IS significantly determine the decision for its
introduction. In fact, the introduction of a process-
oriented IS, first of all, causes high efforts (e.g., caused
by a necessary redesign of business processes).
•CSF#2: Benefits. Costs have to be justified by ben-
efits. Process-oriented IS, in particular, generate ben-
efits by supporting business processes. This implies,
for example, reduced process cycle times, optimized
allocations of resources, and increased process quality.
•CSF#3: Risks. Benefit realization is influenced by
risks. As a typical risk consider, for example, an im-
mature organization regarding the degree of process-
orientation.
The survey clearly confirms the relevance of these three
success factors. Costs are considered to be the most impor-
tant evaluation part (87.43%), but other evaluation dimen-
sions have to be incorporated as well. Especially benefits
(82.28%) and an IT investment’s contribution to organiza-
tional goals2(49.37%) are considered as highly significant
(cf. Fig. 9).
0
10
20
30
40
50
60
70
A:69 (87.34%) costs
B:65 (82.28%) benefits
C:28 (35.44%) risks
D:26 (32.91%) strategic implications
E:39 (49.37%) contribution to ent. goals
F:00 (00.00%) no soecial focus
G:01 (01.27%) don’t know
H:02 (02.53%) other focus
A B C D E F G H
Question: What is focussed on when developing
a business case in your organization?
absolute nominations
Figure 9. General Applicable Factors*.
By contrast, the survey also indicates that risks (35.44%)
as well as an IT investment’s impact on the overall enter-
prise strategy (32.91%) are considered being of minor rele-
vance. Besides, there are other success factors.
4.2 Organization-driven Success Factors
The paradigm of process-orientation implies a shift from
functions to processes. As consequence of this shift we can
observe an increasing importance of IS supporting business
processes. Based on the results of our case study (see Sec-
tion 3) we derive four success factors that deal with organi-
zational issues:
•CSF#4: Integration. Typically, many IS support an
organization’s process map. To enhance the coopera-
tion of these IS, they have to be integrated. Thereby,
integration needs to be achieved on two levels: con-
ceptually on the enterprise architecture level and tech-
nically on the enterprise application level.
•CSF#5: Process Maturity. High process maturity is a
major prerequisite to successfully implement process-
oriented IS. Process maturity can be assessed by ded-
icated maturity models that describe characteristics of
effective processes. Examples are the CMMi or the
SPICE model.
•CSF#6: Process Knowledge. This CSF deals with
the analysis of execution details of business processes.
2Though this can be regarded as a benefit too, we decided to separately
treat this issue due to its fundamental importance.
This includes knowledge about data and control flows.
Process knowledge is increased by analyzing each pro-
cess step of a business process, e.g., through interviews
with process participants.
•CSF#7: Process Transparency. Process transparency
is closely related to process knowledge. It deals with
the identification of all activities of a business process
from start to end. Details about the exact purpose of
single process activities are not relevant.
4.3 Technology-driven Success Factors
Besides, there are also technology-driven success fac-
tors that influence the successful introduction of process-
oriented IS in a production environment. This section de-
scribes four success factors dealing with the technical im-
plementation of IS:
•CSF#8: Standardization and Norms. Recently, there
has been an explosion of standards and norms enhanc-
ing business process support. The use of well estab-
lished standards and norms is success critical. It is not
recommendable, by contrast, to use proprietary and not
standardized technologies.
•CSF#9: Separation of Process Logic. The separa-
tion of process logic from application code is success-
critical as well. IS which separate process logic from
application code (compared to classical programming)
allow for the handling of business process changes at a
high semantic level (e.g. using process modeling tools)
and reduce the need for recoding application programs.
•CSF#10: Support of Audit Trails. Detailed knowl-
edge about existing business processes helps to pro-
vide adequate support (see CSF#6). One promising
approach in this respect is the application of business
process intelligence tools [3] that analyze event-based
real process execution data. Such data (e.g., resources
consumed by a process activity, process cycle times)
needs to be generated, i.e., monitoring modules have
to log as many activities as possible and store them in
audit trails.
•CSF#11: Workflow Support. Business processes and
their separated process logic (see CSF#9) need to
be managed by WfMS. To effectively adapt process
changes, the WfMS has to support a sufficient degree
of process flexibility. ADEPT2 [4], for example, is a
WfMS offering promising features in this respect.
Figure 10 relates the success factors to the five major
problem areas presented in Section 3. It illustrates the co-
herency of the problem areas and the success factors, i.e., it
shows which of the success factors help to overcome which
of the described problem areas. Take for example the suc-
cess factor process knowledge. Process knowledge helps
to better deal with process evolution. It also helps to iden-
tify business process requirements, i.e., it constitutes to re-
alize adequate business functions. Finally, process knowl-
edge can also ease the customization of an IS as it helps to
understand which parts of the IS have to be customized in
order to achieve an organization-specific tailoring.
(cf. Section 3)
CSF#4: Integration
CSF#5: Process Maturity
CSF#6: Process Knowledge
CSF#7: Process Transparency
CSF#8: Standardization & Norms
CSF#9: Separation of Process Logic
CSF#10: Support of Audit Trails
CSF#11: Workflow Support
x x
x x
x x x
x x x
x
x x
x
x x
Organization-
driven CSF
Technology-
centered CSF
PA#1
PA#2
PA#3
PA#4
PA#5
PA = problem area; CSF = critical success factor
Figure 10. Coherency Analysis.
Altogether, it is still doubtful whether it is really possible
to consequently address and fulfill these eleven success fac-
tors in all cases. Some of them are even conflictive (e.g.,
costs and benefits). However, they represent a validated
baseline for enterprises that want to increase the effective-
ness of their process-oriented IS.
5 Implications for IS Engineering
The degree of realized ”process-orientation” of enter-
prise IS is often scarce. The reasons for this are diverse
and have been described in Section 3. Furthermore, Section
4 has introduced a number of issues whose strict adherence
is a major prerequisite to enable adequate process support.
In fact, the strict adherence of all these factors en-
ables the development of a new class of IS that particu-
larly meet those requirements an organization’s business
process environment places upon them: process-aware IS
[2]. These provide more agility compared to classical,
function-oriented software. They are realized by strictly
following the process paradigm during IS development and
the intensive use of process-oriented software technolo-
gies. While the latter includes approaches such as WfMS
or EAI tools, the former is based upon the strict separa-
tion of process logic from application code, and the system-
supported modeling, execution, and monitoring of busi-
ness processes by powerful process engines. Altogether,
”process-awareness” can be considered as a special subset
of ”process-orientation”.
The need for process-aware IS also implies a fundamen-
tal shift of IS engineering. Traditional software engineer-
ing methods and paradigms (e.g., procedural programming)
have to be replaced with engineering principles particularly
enhancing the effective operational support of business pro-
cesses (e.g., approaches that enable the separation of busi-
ness functions from process logic). This seems crucial in
order to tie up to those requirements that are neglected by
current enterprise IS.
6 Summary and Outlook
Four research questions (see Section 1) guided the em-
pirical research presented in this paper. To answer the re-
search questions RQ#1 and RQ#2, we conducted a case
study in the automotive domain and a cross-organizational
survey among 79 IT practitioners. Both studies enabled
us to identify and analyze the reasons for problems re-
lated to the development, maintenance and operational use
of process-oriented IS. We further used our empirical find-
ings as a baseline to answer RQ#3. In particular, we used
them for the derivation of a number of (general applicable,
organization-driven, and technology-centered) success fac-
tors for process-oriented IS. Finally, we discussed the em-
pirical results with respect to its implications for IS engi-
neering (and therewith addressed research question RQ#4).
In particular, we explained why ”process-orientation” is
scarce, but ”process-awareness” is needed.
Future work will particularly focus on a detailed analy-
sis of the economics of process-aware IS and the process-
oriented software technologies (e.g., workflow management
systems) used to implement them [1].
References
[1] Economic-driven Evaluations of Process-oriented Software
Technologies (EcoPOST). Project Homepage: www.mutsch-
ler.info/ecopost, 2006.
[2] M. Dumas, W. M. P. van der Aalst, and A. ter Hofstede.
Process-aware Information Systems: Bridging People and
Software through Process Technology. Wiley, 2005.
[3] B. Mutschler, M. Reichert, and J. Bumiller. An Approach
to quantify the Costs of Business Process Intelligence. Proc.
Int’l. Workshop on Enterprise Modeling and Information Sys-
tems Architectures (EMISA ’05), LNI P-75, pp.152-165, Kla-
genfurt, Austria, 2005.
[4] M. Reichert, S. Rinderle, U. Kreher, and P. Dadam. Adap-
tive Process Management with ADEPT2. Proc. Int’l. Conf. on
Data Engineering (ICDE ’05), Tokyo, Demo Session, 2005.
[5] W. M. P. van der Aalst and A. J. M. M. Weijters. Process
Mining - A Research Agenda. Computers in Industry, 53(3),
pp.231-244, 2004.
[6] P. van Eck, H. Blanken, and R. Wieringa. Project GRAAL -
Towards Operational Architecture Alignment. Int’l. Journal of
Cooperative Information Systems, 13(3), pp.235-255, 2004.
