Submitted by

Christian Barth

Submitted at
Department of Business
Informatics - Informa-
tion Engineering

Supervisor
Univ.-Prof. Dr. Stefan
Koch

May 2017

Critical success factors in

ERP upgrade projects

Master Thesis
to obtain the academic degree of
Master of Science
in the Master’s Program
Business Informatics

JOHANNES KEPLER
UNIVERSITY LINZ
Altenbergerstraße 69
4040 Linz, Österreich
[Link]
DVR 0093696
Sworn Declaration
I hereby declare under oath that the submitted thesis has been written solely by me
without any third-party assistance, information other than provided sources or aids
have not been used and those used have been fully documented. Sources for literal,
paraphrased and cited quotes have been accurately credited.

The submitted document here present is identical to the electronically submitted text
document.

Linz, May 30, 2017

Christian Barth, BA
Abstract
In the last years the penetration of ERP systems within small, medium and large organi-
zations increased steadily and led to a broad consensus within the business community
about the benefits for organizations in different business sectors. To react to rapidly
changing business environments, technological enhancements and rising pressure of
competition, organizations are forced to adapt their ERP system and perform ERP
upgrades. This thesis identifies 14 critical success factors for ERP upgrade projects
based on qualitative interviews with CEOs, CIOs, ERP consultants and project man-
agers who recently carried out ERP upgrade projects in their respective organizations.
Among others, effective project management, external support, system testing, the
composition of the ERP team and the usage of a multiple system landscape play a
key role for the success of the ERP upgrade. Furthermore, a comparison between the
identified critical success factors and critical success factors in ERP implementation
projects discussed in literature was conducted. Even though there are many similarities
between ERP upgrade and ERP implementation projects, some differences emerged,
which have to be considered in detail to successfully carry out an ERP upgrade project.
Contents
List of figures IV

List of tables IV

1 Introduction 1
1.1 Motivation & problem statement . . . . . . . . . . . . . . . . . . . . 2
1.2 Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objectives & research questions . . . . . . . . . . . . . . . . . . . . 4
1.4 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Literature review 6
2.1 Enterprise resource planning . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 ERP evolution . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Characteristics of ERP systems . . . . . . . . . . . . . . . . 8
2.1.3 ERP research streams . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4 ERP lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 ERP implementation & success factors . . . . . . . . . . . . . . . . . 16
2.3 ERP maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 ERP upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.1 Reasons for ERP upgrades . . . . . . . . . . . . . . . . . . . 27
2.4.2 Impact of ERP upgrades on organizations . . . . . . . . . . . 28
2.4.3 ERP maintenance model . . . . . . . . . . . . . . . . . . . . 29

3 Methodology 32
3.1 Research strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Justification of the chosen methodology . . . . . . . . . . . . . . . . 32
3.3 Qualitative interviews . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Qualitative content analysis according to Mayring . . . . . . . . . . . 36

4 Results 48
4.1 Reasons for ERP upgrades . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Definition of success . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Objectives for ERP upgrades . . . . . . . . . . . . . . . . . . . . . . 50

I
 4.4 Critical success factors in ERP upgrade projects . . . . . . . . . . . . 51
4.4.1 Project management, project manager and project evaluation . 52
4.4.2 External support . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.3 System testing . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.4 Multiple system landscape . . . . . . . . . . . . . . . . . . . 55
4.4.5 ERP team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.6 Communication . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.7 Key user integration . . . . . . . . . . . . . . . . . . . . . . 58
4.4.8 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.9 Stick to the standard . . . . . . . . . . . . . . . . . . . . . . 59
4.4.10 Top management support . . . . . . . . . . . . . . . . . . . . 60
4.4.11 Resources & focus . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.12 Change management . . . . . . . . . . . . . . . . . . . . . . 61
4.4.13 Data & code cleansing . . . . . . . . . . . . . . . . . . . . . 61
4.4.14 Use of new potentials . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Differences in success factors between ERP implementation and ERP
upgrade projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Conclusion 65
5.1 Discussion of the results . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Implications for practice . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Implications for research . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Limitations of the study . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

References 71

Appendix 78

A Interview guideline 78

B Categorization of text passages 82

C Interview transcripts 118

C.1 Transcript Interview A . . . . . . . . . . . . . . . . . . . . . . . . . 119

II
C.2 Transcript Interview B . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.3 Transcript Interview C . . . . . . . . . . . . . . . . . . . . . . . . . 131
C.4 Transcript Interview D . . . . . . . . . . . . . . . . . . . . . . . . . 136
C.5 Transcript Interview E . . . . . . . . . . . . . . . . . . . . . . . . . 139
C.6 Transcript Interview F . . . . . . . . . . . . . . . . . . . . . . . . . . 143
C.7 Transcript Interview G . . . . . . . . . . . . . . . . . . . . . . . . . 146
C.8 Transcript Interview H . . . . . . . . . . . . . . . . . . . . . . . . . 156
C.9 Transcript Interview I . . . . . . . . . . . . . . . . . . . . . . . . . . 162
C.10 Transcript Interview J . . . . . . . . . . . . . . . . . . . . . . . . . . 174
C.11 Transcript Interview K . . . . . . . . . . . . . . . . . . . . . . . . . 179
C.12 Transcript Interview L . . . . . . . . . . . . . . . . . . . . . . . . . 184

III
List of Figures
1 ERP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 ERP evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Number of ERP journal publications per year . . . . . . . . . . . . . 13
4 ERP lifecyle model by Markus & Tanis . . . . . . . . . . . . . . . . 14
5 The impact of technological IT infrastructure changes on individuals
and organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 General content-analytical procedural model . . . . . . . . . . . . . . 38
7 Steps of deductive category assignment . . . . . . . . . . . . . . . . 44

List of Tables
1 Number of published articles for each theme . . . . . . . . . . . . . . 12
2 Interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Appearances of success factors in interviews . . . . . . . . . . . . . . 51

IV
1 Introduction
ERP systems are large packaged enterprise information systems, which provide organization-
wide integration of business processes and business activities into a single computer
system (Moon, 2007). Together with a high standardization and the employment of
a single logical database for the entire organization, ERP systems enhance the coor-
dination and the communication between departments and enable the centralization
of administrative activities (Gattiker & Goodhue, 2004). Storing all the information
related to an organization in one single location enables businesses to make realistic
estimates and more effective forecasts as well as to simplify customized reporting.

During the last 20 years many organizations implemented ERP systems because of
operational, managerial, strategic, infrastructural and organizational benefits (Shang
& Seddon, 2000). Therefore, the already huge ERP software market is growing from
year to year. While total revenues of the ERP market in 2012 amounted to 24.4 billion
US dollars, in 2013 it already grew by 3.8% to 25.4 billion US dollars (Columbus,
2014). In 2015 already 93% of large organizations (more than 250 employees) and
55% of SMEs (less than 250 employees) in Germany were adopting ERP systems in
their daily business (Marwan, 2016).

In times of rapidly changing business environments and newly emerging technologies,

companies are not only forced to adapt their business models, their strategy and their
organizational structures but also their information systems, which include their al-
ready implemented ERP systems as well. One possibility for adapting an existing ERP
system to changed circumstances is to upgrade the system to a new release version.
Due to the high complexity of ERP systems, upgrades can only be conducted within
comprehensive projects and require a huge amount of personal and financial resources
as well as a high degree of ERP know-how. Thus, in case of an unsuccessfully car-
ried out upgrade project, companies would have to accept a huge waste of personal
and financial resources as well as the possibility of not attaining functional objectives.
The knowledge and consideration of critical factors influencing the success of upgrade
projects is an easy option to minimize the risk of project failures.

1
1.1 Motivation & problem statement

In the business world, there is a wide consensus about the large potential benefits of
ERP implementation for organizations. Nevertheless, the success of ERP implementa-
tion projects is far from assured. According to Panorama Consulting (2016), only 57%
of companies would describe their ERP implementation projects as successful. Bear-
ing in mind that organizations spend on average 6.5% of their annual revenue on ERP
projects (Panorama Consulting, 2016), every company has to tackle this challenge in
order to be able to benefit from an ERP system.

Unlike traditional software systems, ERP implementation failure in most cases is not
caused by technical aspects. When companies decide to purchase an ERP software
package, they can usually be sure that it is technically sound and delivers the required
functionality. The reason for failure is rather the fact that business processes are not
understood or reconciled correctly (Davenport, 1998). ERP vendors offer common
process blueprints, which typically cover a large part of business processes within a
company. This leads to the necessity that organizations have to align their business
processes to the blueprint provided by the ERP package and that the focus in ERP
projects has to shift from writing software to understanding business processes (Kelly,
Holland, & Light, 1999). Therefore, ERP implementation projects not only lead to
technical changes but rather to extensive structural and organizational changes. More-
over, because of the involvement of many people from different departments and dif-
ferent perspectives, implementing an ERP system also often leads to a change in an
organization’s culture and strategy. If an ERP implementation project is only seen as
a technical project and not as a major change project it will either fail or be a waste of
money (Davenport, 1998).

So far, in the existing academic literature about ERP the focus is often put on the
ERP system selection and implementation, as these phases within the ERP lifecycle
were seen as the most critical areas. Numerous researchers studied many ERP projects
to determine critical success factors for ERP implementation projects, such as, top
management commitment and support, change management, business plan and vision,

2
project management, BPR and customization, ERP team composition, package selec-
tion, software testing, user training, communication plan, etc. (Nah, Lau, & Kuang,
2001; Dezdar & Sulaiman, 2009; Finney & Corbett, 2007).

The review of existing literature showed, however, that the post-implementation phase
of ERP systems has not been thoroughly researched over the last years (Esteves &
Pastor, 2001; Moon, 2007; Schlichter & Kræmmergaard, 2010). Understanding the
challenges during the post-implementation phase helps organizations to succeed in the
long run. One of the major activities within the post-implementation phase is the ERP
upgrade (Nah, Faja, & Cata, 2001). Typically, every three years organizations have
to conduct a major ERP upgrade and several small upgrades to guarantee a smoothly
running system. Because of the large amount of money which is spent on ERP up-
grades, a comprehensive understanding of ERP upgrade concepts and their challenges
is necessary to prevent nightmares and irretrievable disasters (Olson & Zhao, 2006).
Therefore, the objective of this thesis is to identify the main factors which lead to
success within ERP upgrade projects.

1.2 Significance

The significance of this thesis and the chosen topic are evident for various reasons.
First, the costs of an ERP upgrade project add up to 25-33% of the initial implemen-
tation costs (Ohlson, 2000). Taking into consideration that ERP upgrades have to be
done approximately every three years, the costs for ERP upgrades are quickly exceed-
ing the costs for the initial implementation.
Second, the execution of an ERP upgrade is a recurring activity and therefore organi-
zations not only have to deal with it once, but rather many times during the lifecycle
of an ERP system. Consequently, it is a great advantage to know beforehand on which
aspects the focus needs to be in order to successfully execute an ERP upgrade.
Third, the decision whether to execute an ERP upgrade or not is not only lying with
the organizations itself as they are often forced to upgrade their system because of
discontinued support contracts or changed business needs.

3
Fourth, more and more organizations have implemented ERP systems during the last
20 years. Therefore, the importance of the ERP implementation declined and more
and more organizations have to deal with ERP upgrades in order to stay competitive.
Fifth, little progress has been made in the research of ERP upgrades and the identifica-
tion of success factors in ERP upgrade projects.

1.3 Objectives & research questions

Due to the large amount of installed ERP systems, the huge investments made therein
and the necessity of optimization and change in order to stay competitive, further re-
search on ERP upgrades is necessary. Within this thesis the focus was put on ERP
upgrade projects and the critical stages within these projects. The objective is to un-
cover critical success factors within ERP upgrade projects in order to provide a set of
recommendations for organizations to be able to upgrade an ERP system successfully.

Based on the aforementioned objectives and the problem statement, the following re-
search questions were derived and will be answered within this master thesis.

• What are the objectives in ERP upgrade projects?

• What are the factors which enable the organization to reach these objectives
and therefore can be defined as critical success factors?

• What are the differences between critical success factors in ERP upgrade
projects and critical success factors in ERP implementation projects?

1.4 Thesis structure

This thesis is structured in five main parts. In the introduction, the background and
the motivation are discussed and the research questions are presented. In chapter two
the existing related literature is discussed. The focus in this chapter was put on ERP
as a concept, ERP systems, ERP literature, success factors in ERP implementation
projects and ERP upgrades. The following chapter presents the research methodology
used. The methodology used within this thesis is a qualitative approach. To answer
the research questions, expert interviews were conducted and analyzed according to

4
the qualitative content analysis. In Chapter 4 the results of the qualitative data analysis
are presented and summarized. The last chapter concludes the thesis by discussing the
results, the implications for practice, the limitations of the study and necessary future
research. Other relevant information not included in the body of the thesis, such as the
interview guideline, the interview transcripts and the categorization of the interviews
are attached in the appendix.

5
2 Literature review
In the following section the theoretical background for this study is discussed. The
basis for this section is a comprehensive literature search using the keywords ERP,
ERP systems, ERP implementation, ERP implementation success factors, ERP up-
grade and ERP upgrade success factors conducted on various academic databases, such
as ACM digital library, Wiley online library, SpringerLink, Emerald, ScienceDirect,
IEEE Xplore and Google Scholar as well as in the library of the Johannes Kepler Uni-
versity of Linz. Firstly, the term ERP, the history of ERP, the ERP research streams
and the ERP lifecycle are discussed. Then, the implementation of ERP systems and
the corresponding critical success factors are presented. The last part deals with the
ERP maintenance phase, where a special focus was put on the upgrade process of ERP
systems.

2.1 Enterprise resource planning

ERP is an acronym and stands for Enterprise Resource Planning. Wallace and Kremzar
(2001) define Enterprise Resource Planning as a set of management tools which are
established enterprise-wide. These tools balance demand and supply, employ busi-
ness processes for decision-making and provide cross-functional integration among
purchasing, logistics, manufacturing, sales, marketing, human resources and further
divisions. ERP systems support the handling of these tools.

ERP systems are large packaged enterprise information systems, which are designed
to optimize and integrate business processes within corporations and organizations
(Moon, 2007). They facilitate a unified data source for all activities within an orga-
nization and therefore represent the information backbone of a company. This leads
to a considerable improvement of the organization’s decision-making process in order
to be consistent, timely and reliable across organizational units and geographical loca-
tions (Chatzoglou, Chatzoudes, Fragidis, & Symeonidis, 2016).

6
ERP systems have significantly impacted nearly any business sector or industry. Davenport
(1998) states: "the business world’s embrace of enterprise systems may in fact be the
most important development in the corporate use of information technology in the
1990s". Worldwide ERP revenues grew 2.2% in 2012, followed by 3.8% in 2013. In
total the worldwide ERP software market grew to 25.4 billion US dollars in 2013, and
this trend is still increasing (Columbus, 2014).

Figure 1: An overview of ERP systems (Chen, 2001)

2.1.1 ERP evolution

ERP began more than 50 years ago. In the 1950s the first business applications were
designed in order to support the planning of the required materials for all products and
parts across multiple production plants. This has been described as Material Require-
ment Planning (MRP). During the 1970s, MRP was extended with further functionality
to support the entire production planning. Within Manufacturing Resource Planning
(MRPII) the focus was on the improvement of production processes. Later on, further
features such as finance, sales and human resources were introduced in MRPII pack-
ages (Klaus, Rosemann, & Gable, 2000).

7
At the beginning of the 1990s the first ERP systems emerged with the ability of
enterprise-wide inter-functional integration and coordination. This was the first time
software tools supported business processes including distribution, manufacturing, fi-
nancial, accounting, project management, human resource management, service and
maintenance in order to provide accessibility, consistency and visibility across the en-
terprise. During the 1990s more and more functionality like advanced planning and
scheduling (APS), supply chain management (CRM) or customer relationship man-
agement (CRM) has been added to ERP packages. At this point the term "extended
ERPs" was coined (Rashid, Hossain, & Patrick, 2002).

Figure 2: ERP evolution (Rashid et al., 2002)

2.1.2 Characteristics of ERP systems

ERP systems can be characterized by two main aspects, which not only influence the
initial implementation but also the management of these systems within an organiza-
tion. On the one hand, it is a high level of integration, on the other hand it is the
standard software which is mainly used as a basis for ERP systems (Hecht, 2014,
p. 10).

8
Integration

One main purpose of ERP systems is the high degree of integration of various organiza-
tional functions and business processes within the system (Jacob, 2008, p. 1f.; Markus
& Tanis, 2000). Integration can be described from two perspectives. On the one hand,
the subject of integration describes the objects that are integrated. These objects are for
example data, functions, processes, methods or programs which are consolidated and
have common databases as a basis. On the other hand, integration can be described
through its direction. Horizontal integration describes the connection of business func-
tions along the entire value chain and therefore describes the fundamental idea of ERP
systems. Vertical integration refers to the supply of planning and control systems, such
as data warehouses or analytical systems, with operative data (Mertens, 2013, p. 13ff.).

A high level of integration not only promises benefits, it also implies challenges. The
complexity of an ERP system increases with the degree of integration. Therefore,
small changes within the software or the configuration of the system can lead to signif-
icant implications in various business functions. Every change needs a well-planned,
thorough and structured procedure to ensure a smooth operation of business processes.
A high level of integration also leads to a large amount of users from various busi-
ness functions throughout the organization, who have different expectations and re-
quirements regarding the ERP system. Hence, cross-functional communication and
coordination is a main challenge throughout the ERP lifecycle (Hecht, 2014, p. 10).

Standard software

In information system literature, a distinction is made between custom-built and off-

the-shelf software. ERP systems generally use off-the-shelf software packages and
adopt them according to the organization’s requirements. This entails two major im-
plications (Markus & Tanis, 2000).

9
First, in contrast to custom-built software, where the software is built to support the
specific ways an organization is working, ERP systems offer generic business pro-
cesses, which have to be tailored to suit the organization’s needs (Markus & Tanis,
2000). ERP package tailoring can be done in different dimensions. The most basic
type is called configuration or customization, where parameters are set to define the
organization’s structure within the system or activate and deactivate various function-
alities. To change the behavior in various situations most vendors provide so called
user exits, which allow the organization to program additional software code in an
open interface. The most rigorous way of changing the software package is called
package code modification. In this situation the source code of the ERP package is
modified to be able to use individual functionality. These modifications range from
small behavioral changes to the change of entire modules. This kind of tailoring is
likely to affect the maintenance of ERP systems. As customization and user exits are
offered by the vendors, the impact on maintenance is not worth mentioning. Package
code modification, in the worst case, can lead to the necessity of a reimplementation
to be able to upgrade to a new version (Brehm, Heinzl, & Markus, 2001).

Second, with the purchase of an ERP system organizations often enter long-term re-
lationships with software vendors. Because comprehensive customization can lead
to various problems in the post-implementation phase, most organizations try to stay
as close as possible to the standard software product. Therefore, they are dependent
on the continuous enhancements provided by the software vendor to stay technically
up-to-date and to be able to use new functionality. Because of this dependency, orga-
nizations are susceptible to lacking further development or their vendor’s withdrawal
from business (Markus & Tanis, 2000).

10
2.1.3 ERP research streams

During the past decade ERP has developed into an important and interesting topic,
both for academic and industrial communities. Scientists have dealt with all kinds of
aspects in connection with ERP and ERP systems. Several authors analyzed scientific
papers in order to provide a comprehensive summary, the topics that have been dis-
cussed and which questions have been addressed in the area of ERP.

Esteves and Pastor (2001) analyzed 189 articles published from 1997 to 2000. They
categorized these articles according to an ERP lifecycle, proposed by them (Esteves &
Pastor, 1999). They defined six phases which the ERP system is passing through until
its retirement. These phases are:

• Adoption

• Acquisition

• Implementation

• Usage

• Evolution

• Retirement

Articles which couldn’t be assigned to a specific phase were summarized within a gen-
eral section. The main focus was on the implementation phase and on general topics.
41% of the papers dealt with the implementation phase and 20% dealt with general
topics. Esteves and Pastor (2001) classified ERP maintenance and upgrade activities
into the usage phase. Only 8% of the papers were related to this phase.

Another author who evaluated existing research in the ERP sector was Moon (2007).
He analyzed 313 articles which were published from 2000 to 2006. He categorized
them according to the following topics:

11
 Themes Number of articles
Implementation 135
General 61
Case study 17
Critical success factors 15
Change management 11
Focused stage in the implementation phase 16
Cultural (national) issues 17
Using ERP 44
General 21
Decision Support 4
Focused function in ERP 11
Maintenance 8
Extension 37
Value 34
Trends and Perspectives 55
General 48
In a particular sector 7
Education 28

Table 1: Number of published articles for each theme (Moon, 2007)

These numbers confirm the result of Esteves and Pastor (2001). The vast majority of
the articles dealt with the topic of ERP Implementation. Another large part of the arti-
cles discussed the trends and perspectives of ERP. Even though 44 articles were sum-
marized under the topic "Using ERP", only 8 articles about EPR maintenance were
published (Moon, 2007).

12
The most comprehensive and recent literature review was conducted by Schlichter and
Kræmmergaard (2010), who analyzed 885 peer-reviewed journal publications pub-
lished from 2000 to 2009. According to their findings the number of publications
concerning ERP systems has increased steadily until 2003, when 116 papers were
published in one year. From then on the number of papers has been slowly decreasing
(Schlichter & Kræmmergaard, 2010).

Figure 3: Number of ERP journal publications per year (Schlichter & Kræmmergaard,
2010)

They also analyzed the papers according to the topics discussed. Again, ERP imple-
mentation is the largest topic with 30% of all examined papers. ERP maintenance and
upgrades are classified into the topic "Optimization of ERP systems" (Schlichter &
Kræmmergaard, 2010). As post-implementation is only a smart issue of "Optimiza-
tion of ERP systems" it can be assumed that the amount of papers which are dealing
with maintenance and upgrades is similar to the ones stated above.

To sum up, the main focus in ERP research is still lying on ERP implementation, ERP
optimization, ERP tools and on trends and perspectives. The post-implementation
phase, in particular ERP maintenance and ERP upgrades, are only covered to a small
extent.

2.1.4 ERP lifecycle

During the last years many ERP lifecycle models have been developed. Two well
known and often adopted models are presented in this section.

13
Lifecycle model by Markus & Tanis

Markus and Tanis (2000) are trying to describe the lifecycle of an ERP system on the
basis of four phases, which are illustrated in Figure 4. The first phase, which is called
the chartering phase, consists of all necessary actions in order to define a business
case for the ERP system, to select the best suitable software package and to set up the
project. The outcome of this phase can be either the decision to proceed or not to pro-
ceed with the project. In the second phase, the project phase, the selected and defined
system is set up and running in one or more organizational units. The ERP system is
configured according to the organizational needs and rolled out to more and more end
users (Markus & Tanis, 2000).

Figure 4: ERP lifecyle model (Markus & Tanis, 2000)

With the beginning of the third phase, the shakedown phase, the system will be stabi-
lized, bugs will be eliminated and the system will start to operate normally. The last
phase, the onward and upward phase, covers all activities from normal operation to the
point where the system will be upgraded or replaced by another system. It is impor-
tant to mention that enterprises or organizations have to start again with the first phase
when they undertake major upgrades (Markus & Tanis, 2000).

14
ERP lifecycle model by Esteves & Pastor

The most adopted model, however, is the ERP lifecycle model according to Esteves
and Pastor (1999). It has been used as a reference by various authors (e.g., Esteves &
Bohórquez, 2007; Esteves & Pastor, 2001; Haddara & Zach, 2011) and consists of six
comprehensive phases.

1. Adoption decision phase

In the adoption decision phase the need of an ERP system will be questioned and
a general information system approach will be selected in order to improve the
organizational strategy and to address critical business challenges. This phase
also includes the definition of system requirements, its goals and benefits.

2. Acquisition phase
During the acquisition phase the product will be selected, where functionality
best fits the requirements of the organization. Factors such as price, maintenance
services and training are analyzed and contractual affairs are defined. Subse-
quently external consultants are hired, who provide support in the next phases of
the ERP lifecycle.

3. Implementation phase
This phase consists mainly of customization, adaptation and parameterization
of the acquired ERP system according to the organization’s needs. Typically
this is handled with the support of consultants who are providing know-how,
implementation methodologies and training.

4. Use and maintenance phase

During this phase the ERP system is already in a state, where it returns expected
benefits and minimizes disruption. Even though the system is productive it has
to be maintained in order to correct malfunctions, to meet optimization requests
or to make general system improvements.

15
 5. Evolution phase
In the evolution phase functionality is added and more capabilities are integrated
into the ERP system. Typical add-ons which deliver new benefits are supply-
chain management, advanced planning and scheduling or customer relationship
management.

6. Retirement phase
During this phase managers decide to replace the ERP software with more ade-
quate systems because of the appearance of new technologies, the inadequacy of
the existing systems or the change in business needs.

2.2 ERP implementation & success factors

The implementation of an ERP system is a highly challenging, complex and dynamic

process which does not only trigger technological but also organizational changes in
the affected organization (Otieno, 2010). These changes need to be carefully admin-
istered in order to be able to take advantage of an ERP solution (Al-Mashari & Al-
Mudimigh, 2003). However, there is a generally shared knowledge concerning these
challenges, ERP implementation failures still happen frequently (Soh, Kien, & Tay-
Yap, 2000; Willis & Willis-Brown, 2002; Barker & Frolick, 2003). Therefore the main
focus in ERP research during the last years has been put on ERP implementation and
corresponding success factors (see ERP research streams). Three prominent articles
which are dealing with ERP success factors were written by Nah, Lau, and Kuang
(2001), Dezdar and Sulaiman (2009) and Finney and Corbett (2007). They analyzed
existing literature about ERP implementation success factors and ranked them accord-
ing to how often they appeared within the analyzed articles. It showed that the main
critical success factors identified by them are overlapping and that there are only a few
differences between the articles. In the following section the most important critical
success factors are outlined with a detailed description.

16
Top management commitment and support

One of the most cited critical success factors are top management commitment and
support. This means the necessity of having committed leadership at the top man-
agement level (Finney & Corbett, 2007). According to Shanks et al. (2000) top man-
agement support is important through all stages of an ERP implementation project,
however it is especially critical in the early stages. It is substantial for the initiation
of the project and a key factor in order to facilitate the best resources for such large,
expensive and critical projects. To not only have management support at the beginning
of the project, but also the need to maintain it during the whole project has been identi-
fied as crucial by Sumner (1999). Additionally, top management support, as a symbol
of enterprise priority, leads to enterprise-wide commitment to the project which is in-
fluencing implementation success to a large extent (Bingi, Sharma, & Godla, 1999).

Change management

Along with top management commitment and support, change management is the most
often cited critical success factor in ERP implementation projects (Finney & Corbett,
2007). Change management has to be an important part during the implementation
phase where structural and cultural change must be managed organization-wide. ERP
implementation triggers massive changes which can cause resistance, confusion, re-
dundancies and errors if not managed adequately (Sumner, 1999). In order to succeed,
a culture with common goals, shared values and a strong corporate identity, which is
open to change, is essential (Nah, Lau, & Kuang, 2001). Another key task is the com-
munication of the benefits and the need for an ERP system to build a positive employee
attitude and user acceptance of the project (Finney & Corbett, 2007).

17
Business plan and vision

As ERP implementation projects are usually conducted over a long time-period, mea-
surable and identifiable goals, a business plan and a clear vision are needed to manage
the project successfully (Nah, Zuckweiler, & Lau, 2003). IT managers have to be
knowledgeable about how newly implemented ERP systems can be integrated into ex-
isting technologies, management systems, organizational structures, human resources
as well as tactical and strategic plans. Therefore it is inevitable that business plan,
vision and strategy are defined by both business and IT executives (Al-Mashari, Al-
Mudimigh, & Zairi, 2003). If organizations try to implement a system without un-
derstanding business processes and defining a clear vision, integration ambitions can
quickly turn into a nightmare (Davenport, 1998).

Project management

Success in most information system projects is mostly specified as the degree to which
time, budget and scope requirements are met. Consequently, good project management
is fundamental to secure implementation success (Nah et al., 2003). First, the scope of
the project has to be defined. This entails the amount of business process reengineer-
ing needed, the amount of systems implemented and which and to what extent business
units are included (Nah, Lau, & Kuang, 2001). Additionally, a detailed project plan
related to the project goals has to be determined (Shanks et al., 2000). Milestones
and critical paths have to be defined in order to get a clear view of the boundary of
the project (Holland, Light, & Gibson, 1999). Besides well selected project managers,
Somers and Nelson (2004) propose to establish a steering committee, consisting of
senior managers from various business functions, senior project management repre-
sentatives and ERP end users. This group of people should be integrated in system
selection and monitoring during the implementation phase.

18
Business process reengineering and customization

When implementing an ERP solution, companies always face the challenge of bringing
their business processes in line with the new ERP package. Especially when these
systems will be implemented worldwide, this task can be very challenging (Bingi et
al., 1999). In order to be able to exploit all advantages of an ERP system, business
process reengineering (BPR) is inevitable. As ERP systems are developed to improve
business processes in various business divisions, BPR has to go hand in hand with the
ERP implementation. Therefore, existing business processes have to be analyzed in
detail and adapted to the system, rather than developed as a customized system which
only makes the best of bad processes (Scheer & Habermann, 2000; Sumner, 1999).
Code modification or far reaching customization of the ERP system should be avoided
as far as possible to avoid complications with updates and upgrades (Nah, Lau, &
Kuang, 2001).

ERP team composition

Another often cited success factor is the ERP team composition. For these large and
complex projects the best and brightest people inside the organization should be se-
lected. The impact of this aspect is often underrated and thus, having people with the
wrong set of skills on the project is one of the major reasons for the failure of ERP
projects (Bingi et al., 1999). Internal resources who are working on the project should
be a mix of business experts, IT experts and end users and should understand the over-
all needs of the company. Furthermore, these people should be on the project full-time
and therefore completely released from other duties during the project (Bingi et al.,
1999; Shanks et al., 2000). In many publications, an experienced external consultant
team is also stated as an important success factor. During implementation, consultants
can offer comprehensive knowledge of certain modules as well as experience with
various software packages and requirement analysis (Somers & Nelson, 2004).

19
Software testing and troubleshooting

As enterprise systems can not be implemented in a single step, functionalities have to

be tested both alone and in connection with existing modules or systems. A go-live
without structured and comprehensive testing is the best recipe for project failure. The
focus should not only be put on technical functionalities, also the business processes
and their implementation have to be tested and validated. A successful test also in-
cludes testing whether represented business processes in the application match with
the processes in real life (Al-Mashari et al., 2003). In spite of extensive testing, many
unforeseen circumstances will occur during an ERP implementation. To cope with
these challenges, flexibility in adapting to various changes is unavoidable (Scott &
Vessey, 2000).

User training and education

Another often cited success factor is user training and education. Millions of dollars
and hundreds of deployment hours can not compensate for inadequate training of end-
users, which is one of the major reasons for ERP project failure (Al-Mashari et al.,
2003). Both technical knowledge about the ERP system and knowledge about business
processes as well as the handling of the ERP system have to be crucial parts of an
education strategy (Shanks et al., 2000).

Building a business case

The implementation of an ERP system represents a substantial investment for the or-
ganization. Therefore, a comprehensive business case must be built. Possible savings
and benefits have to be weighed against the huge costs which are caused by the ERP
implementation. The costs of such ERP implementations are mostly easy to quantify,
and thus easy to take into consideration. The hard part starts with the quantification
of savings and benefits. Major benefits such as streamlined communication caused by
universal, real-time access to financial and operating data, improved response to cus-
tomer demands, strong supplier relationships through information sharing, increase in

20
productivity or possible elimination of jobs are all crucial for the success and survival
of many organizations but are, to the same extent, very hard to convert to cash values.
Nevertheless, the difficulties in estimating this kind of data should not prevent a precise
analysis. This analysis is not only necessary in order to weigh costs against benefits,
it is also the basis for a performance evaluation, which has to be executed in a later
stage of the ERP implementation (Chen, 2001; Xu, Horn Nord, Brown, & Daryl Nord,
2002).

Selection of a project champion

The need to select a project champion for the ERP implementation project is also often
cited as a major critical success factor. The project champion should be someone
within the organization who has the power and reputation to promote the importance
of the project throughout the company. Ideally a business leader should be placed in
charge for this position to promote the benefits of the ERP implementation from a
business perspective (Sumner, 1999).

Managing cultural change

As already mentioned (see ERP implementation & success factors), an ERP imple-
mentation project is not only a typical IT implementation project, it is also a major
change project within the organization where the organization often has to adapt to
predetermined best-practices for the organization of data and processes. Major ERP
vendors and developers are located in North America and Western Europe and there-
fore, functionalities and processes are developed through a western-centred perspec-
tive. This may not lead to problems for companies which are only located in North
America and Europe. For companies with sites in other parts of the world, the man-
agement of cultural differences is a major success factor. That means a one-size-fits-all
or one-business-model-fits-all approach is not likely to be successful. To successfully
implement an ERP system, it is essential to adapt processes and services to different
cultural conditions to guarantee a comfortable and familiar working situation for all
regional parts of the organization (Davison, 2002; Skok & Legge, 2001).

21
Communication plan

Communication is another key success factor for ERP implementation projects. It is

crucial that expectations and goals have to be communicated effectively among stake-
holders and throughout all levels of an organization. Stakeholders have to understand
the capabilities as well as the limitations of the system at any given time of the project
(Nah & Delgado, 2006). In particular, stakeholders have to be informed about the lim-
itations of the system to prevent frustration due to "over-selling" (Somers & Nelson,
2001). Additionally, good communication of the project’s progress to the rest of the
organization is an easy way to promote and advertise the whole project and the project
team (Holland et al., 1999). Therefore, communication skills are a major competence
for every ERP project manager. He or she has to have the ability to communicate rel-
evant information appropriately to different stakeholders. A special focus has to be
put on the communication within the project team. A strong coordination of tasks and
efforts between all team members is absolutely necessary (Kræmmergaard & Rose,
2002).

Appropriate management of IT legacy systems

Most large companies nowadays generate and store a huge amount of data. This data
often is not stored in a single repository but rather in various information systems, each
of them created to support a special business unit, region or factory. One goal of the
implementation of an ERP system is to get rid of the large diversity of information
systems (Davenport, 1998). According to Holland et al. (1999) the high complexity of
these legacy systems is an indicator of the high amount of technical and organizational
changes required. Therefore, the appropriate management of IT legacy systems is a key
success factor, whether it is the replacement of a legacy system with an ERP system or
the development of interfaces between the legacy system and the newly implemented
ERP system (Lee, Siau, & Hong, 2003).

22
Vendor support

The relationship between the user-organization and the software vendor plays an im-
portant role from the beginning of any ERP implementation project. A strategic part-
nership enables competitiveness and efficiency for the organization and is a key factor,
especially in the early stages of implementation. Using implementation tools pro-
vided by the vendor, such as process modelling tools, templates for specific business
practices or packages of software, services and support, can significantly reduce the
implementation duration and costs. In addition, the organization can benefit from the
know-how, as well as the best-practices provided by the vendor. As most of the or-
ganizations’ ERP systems are used for many years, continual investment is necessary.
Additional functionality has to be added and upgrades have to be executed regularly to
match the system to changing business needs. Therefore, technical assistance, updates,
emergency maintenance and special user training are key factors to ensure a smooth
operation of an ERP system (Somers & Nelson, 2004).

Careful selection of ERP software

At the beginning of every ERP implementation project, an ERP package, which suits
the business needs, has to be selected. According to a large-scale European multicoun-
try survey the most important factor influencing the selection of an ERP package is the
best fit with current business processes, followed by flexibility, cost, user-friendliness,
scalability and vendor support (van Everdingen, van Hillegersberg, & Waarts, 2000).
Bernroider and Koch (2001) stated the differences in characteristics of the selection
processes between small or medium and large sized organizations as the following:
For SMEs a short implementation time and therefore lower costs are more important,
as budgets are tighter than in large companies. Furthermore flexibility and adaptability
of the software were rated as more important than there were by large organizations.
Aside from the stated factors for SME’s, Rao (2000) recommends taking the follow-
ing criteria into consideration: Affordability, domain knowledge of suppliers, level of
local support, upgradability and use of latest technology.

23
Post-implementation evaluation

At the end of any ERP implementation project it is necessary to evaluate its success.
This evaluation should focus on two main aspects. The first part of the evaluation
has to deal with project management metrics like completion dates, costs and target
achievement. The second part has to measure the production system, which includes
metrics like performance or reliability (Nah, Lau, & Kuang, 2001). Any evaluation
effort is only possible if specific measurable performance targets are defined at the
beginning of the project. This is the only way to identify improvements and to be able
to promote them after completion of the implementation project (Ross & Vitale, 2000).

2.3 ERP maintenance

As already stated (see ERP lifecycle) ERP maintenance is a major phase within the
ERP lifecycle. IEEE (1990) defined software maintenance as the following: "The
process of modifying a software system or component after delivery to correct faults,
improve performance or other attributes, or adapt to a changed environment." ERP
maintenance is a very comprehensive phase and includes a large amount of activities.
Within ERP literature, there are different proposals for the categorization of mainte-
nance activities.

On the one hand, Nah, Faja, and Cata (2001) proposed a classification of ERP main-
tance activities in six categories: Corrective maintenance, adaptive maintenance, per-
fective maintenance, preventive maintenance, user support and external parties.

On the other hand, based on four case studies, Brehm (2004, p. 181ff.) categorizes
ERP maintenance activities in the following categories: User support, troubleshooting,
function changes & enhancements, functional tasks during release changes, technical
tasks during release changes and technical maintenance of the ERP system.

The two mentioned classifications and the assigned tasks were combined by Hecht
(2014) in order to describe the maintenance tasks in detail.

24
User support

The main tasks within this category are the support and consultation of users con-
cerning questions and problems with the utilization of the system. In the case of new
features or a changing behavior of the system, users have to be trained and instructed to
enable a correct and productive usage of the system (Nah, Faja, & Cata, 2001; Brehm,
2004).

Troubleshooting

Troubleshooting describes the elimination of errors in the configuration of the ERP

system, in already implemented customizations of the ERP system, in system inter-
faces as well as the removal of errors caused by users. The handling of errors caused
by the original source code of the ERP vendor is also part of this category. In this case,
the vendor has to be notified and the elimination of the errors has to be coordinated
(Nah, Faja, & Cata, 2001; Brehm, 2004).

Functional changes and enhancements

This category comprises all changes and extensions of the configuration of the ERP
system as well as the changes and enhancements of the system via customization and
package code modification. Additionally, the testing of these changes and enhance-
ments is also included in this category (Nah, Faja, & Cata, 2001; Brehm, 2004).

Software upgrade - application side

In this category all activities are collected which occur on the application side when
an ERP software is upgraded. These are for example the examination of existing con-
figuration, the examination and revision of already existing customizations and the
configuration of new functionality as well as the testing of new functionality (Nah,
Faja, & Cata, 2001; Brehm, 2004).

25
Software upgrade - technical side

This category compromises all activities on the technical side which occur during an
ERP software upgrade. These are for example the installation of patches or new soft-
ware version as well as the adjustment of the necessary hardware components (Nah,
Faja, & Cata, 2001; Brehm, 2004).

Technical maintenance of the ERP system

Technical maintenance describes the maintenance of the technical infrastructure (hard-

ware, system software, databases etc.) as well as the administration of the system.
Administration includes for example the management of access rights, workflow mon-
itoring or monitoring of memory access. The movement of new features from develop-
ment system to the production system is also part of this category (Nah, Faja, & Cata,
2001; Brehm, 2004).

2.4 ERP upgrade

As already mentioned before (see ERP research streams) the research focus in the ERP
field in the last years was often not put on ERP upgrades. Subsequently, there exists
little relevant literature defining ERP upgrades. Sahin and Zahedi (2001) are providing
a general definition of an upgrade of a software system. They define upgrade action as
"adding new functions or features to a software system, in addition to any maintenance
and fault removal. An upgrade action involves new programs and constitutes an over-
haul of the system." Scheckenbach et al. (2014) describe the intention of ERP upgrades
as: "Enterprise resources planning upgrades are mainly intended to take advantages
of new technologies and business strategies to ensure that the organization keeps up
with the latest business development trends."

26
Therefore in this thesis an ERP upgrade is understood as a major change process re-
sulting from the implementation of a new version of an already installed ERP system,
whose main intent is to add functional upgrades and enable the usage of new tech-
nologies and business strategies. The term therefore excludes minor changes within a
version of an ERP system, such as new releases that only provide technical upgrades,
such as patches and bug fixes.

ERP upgrade activities are raising more and more attention in ERP-using organiza-
tions. On average an organization has to execute an ERP upgrade every three years
(Olson & Zhao, 2006) and costs reach between 25 - 33 % of initial implementation
costs. Taking into consideration that an ERP system has to be upgraded several times
during it’s life cycle, the upgrading costs will exceed the implementation costs even-
tually. Additionally, many companies and organizations have no experience and ex-
pertise in this area, as there exist hardly any standards or guidelines for ERP upgrade
preparation and execution (Ng, Gable, & Chan, 2003).

2.4.1 Reasons for ERP upgrades

The decision whether to upgrade an ERP system or not is guided by both internal
and external pressures on the organization. Beatty and Williams (2006) are describing
these pressures as Organizational push and Vendor pull. Organizational push occurs
when executives are motivated to further expand and improve their ERP system as their
organizations realize the business benefits from their initial ERP investments. At the
same time, vendors are urging organizations to upgrade their systems, as they have to
enhance their systems, in order to remain competitive. Also, they can not afford to
offer support for numerous versions of their software product.

The main benefits organizations gain when they upgrade their ERP systems are the
following:

• Take advantage of new technologies

According to Dempsey and Liam Sheehan (2013) an ERP upgrade offers the
possibility of taking advantage of new technologies. This is obligatory to stay
competitive.

27
 • New, expanded, or improved features to meet business and IT needs
As the main function of ERP systems is the support of business objectives, busi-
ness and IT needs are a main driver of upgrade decisions. Upgrading the ERP
system enables the company to take advantage of new or improved features in
order to meet changed business and IT needs (Collins, 1999; Otieno, 2010).

• The escalating costs of maintenance activities

Another main benefit of an ERP upgrade is the reduction of escalating costs of
maintenance activities. The longer an ERP version is deployed the higher the
amount and the costs of maintenance activities (Ng, 2001).

• Eligibility for help desk support

As ERP vendors stop their support for old versions of their software, companies
have to upgrade their systems in order to be eligible for vendor support (Collins,
1999; Otieno, 2010).

2.4.2 Impact of ERP upgrades on organizations

Upgrades of large information systems can only improve various weaknesses, but also
impact the user acceptance of this system. Shaw (2001) has developed a conceptual
model about the impact of information system upgrades on individuals and organiza-
tions. Changes in the user interface, compatibility, quality or functionality impact user
acceptance and furthermore lead to individual and organizational impact. In order to
stabilize user acceptance after technological changes it is necessary to train and sup-
port users extensively (Shaw, 2001).

Figure 5: The impact of technological IT infrastructure changes on individuals and

organizations (Shaw, 2001)

28
2.4.3 ERP maintenance model

The upgrade procedure is critical to the sucess of the ERP upgrade activity. Therefore
Ng et al. (2003) have developed an ERP maintenance model, which is consisting of
three major phases: ERP maintenance preparation, ERP maintenance procedure and
ERP software upgrade. As this thesis is focusing on ERP upgrade projects only, the
third phase of this model is relevant. The ERP software upgrade phase consists of
eleven subphases which will be described in detail below.

1. Design an upgrade project methodology

The best methodology from the software vendor or other organization’s success-
ful upgrade projects has to be identified and tailored for internal use. Addition-
ally, services and tools from the vendor have to be listed. The result of this phase
serves as a project blueprint to success.

2. Research for upgrade options available

Within this phase available upgrades and their availablity dates have to be re-
searched. Pros, cons and the stability of each option have to be analyzed and
the support window has to be identified. Further tasks are to ensure the chosen
version is the optimal solution in order to meet the organization’s needs and ob-
jectives and the latest technology and business potentials are known and have
been considered.

3. Develop a business case

In this phase, objectives, business drivers to upgrade and the nature of the pro-
posed upgrade are determined. Additionally, a business case to justify an up-
grade is developed. The objective is to make a solid business case for the ERP
upgrade and to ensure that the upgrade follows the management’s direction. The
developed business case should be used as a management tool which measures
benefits and costs.

29
4. Make full assessment of modifications in the current version and technical envi-
ronment
The number of modifications on the current system and the necessity of their
existence are investigated and linked with a business reason. The goal is to en-
able a precise cost computation of the upgrade and to ensure that only necessary
customizations are included in the new upgrade version.

5. Make full assessments of the new functionality and technical requirements in

each (potential) upgrade option
New features, functionality and technical requirements in each option are as-
sessed and the benefits for the organization are evaluated. Additionally it will be
identified if user-enhancements and modifications are available in a new version
and therefore ensured that an optimal version is selected for an upgrade.

6. Conduct impact analysis between the new upgrade version and the existing ver-
sion
All impacts of the new version on user training and supporting documentation
are examined. Additionally, all impacts on current modifications, interfaces,
hardware, network loading and server capacity are analyzed. This step is impor-
tant, as it minimizes future maintenance costs.

7. Install the new version onto the development system

This step covers the installation of the new version and all corresponding patches
on the development system. This ensures that the new version is up-to-date.

8. Construct the new system

All previous modifications, interfaces and reporting capabilities are re-developed
or re-applied on the new system. Hence, all competitive business processes re-
main in the new system.

9. Conduct a thorough testing of the upgrade system

In this phase the accuracy of the system functionality is verified, system and
user acceptance tests are conducted and data conversion is verified. Thus, the
new system meets the user’s requirements and the business objectives.

30
10. Carry out the trial upgrades
Trial upgrades between the development and testing system are conducted in
order to exercise the upgrade process before the real upgrade takes place on the
production system. Therefore, errors or potential problems are identified.

11. Conversion (or go live)

In the last phase the well-tested system is installed on the production system and
ready for use.

31
3 Methodology

3.1 Research strategy

In order to answer the research questions two main research methods were used. At
the beginning a comprehensive literature research was conducted, followed by a quali-
tative study. CEOs, CIOs, ERP consultants and IT project managers were interviewed
in a semi-structured interview format to explore critical success factors for ERP up-
grade projects. Afterwards the transcribed interviews were analyzed according to the
qualitative content analysis according to Mayring.

3.2 Justification of the chosen methodology

As discussed in the section ERP research streams, in the last years not much effort
has been put into the research of the ERP upgrade projects. Therefore, qualitative re-
search has been chosen to investigate the research questions. According to Flick, Kar-
dorff, and Steinke (2013, p. 13ff.), qualitative research methods are suitable for topics
which are barely researched. For quantitative research methods (e.g. standardized
interviews), on the other side, it is necessary to have a solid idea of the research ques-
tion beforehand. With the help of qualitative research methods, such as observation or
open, semi-structured interviews, there is the possibility to explore new information or
new insights and therefore, the new and the unknown can be researched.

The specific characteristic of qualitative research is the openness regarding the research
subject, which enables the possibility of gaining new findings and closing knowledge
gaps (Kuckartz, Dresing, Rädiker, & Stefer, 2008, p. 11ff.). Qualitative research per-
mits a look into the environment of the research subjects and to use it as a basis to
describe and interpret the reality from the view of the involved people. The objec-
tive is to better understand their social reality and thus include the perspective of the
participants (Flick et al., 2013, p. 13ff.).

32
3.3 Qualitative interviews

In this study expert interviews were used to gain information about critical success
factors in ERP upgrade projects. Bogner, Littig, and Menz (2005, p. 46) define an ex-
pert as someone who possesses technical, process and interpretive knowledge, within
his or her specific professional sphere of activity. Therefore, expert knowledge not
only consits of systematic and reflexive accessible in-depth knowledge but also repre-
sents experience and the rules of individual decision making. The interviewee is seen
as a representative of an organization or an institution, hence the focus is solely on
his/her organizational functions and knowledge. Information concerning their private
experiences, personal orientations and attitudes, in the context of their individual liv-
ing conditions, are intentionally ignored (Meuser & Nagel, 1991). In summary, the
objective of a systematic expert interview is to benefit from the experience and the
know-how of the expert.

Interview technique

The expert interviews were conducted as problem-centered interviews, which are de-
fined as the summary of all forms of open, semi-structured interviews. This form has
been chosen as it allows the interviewee to speak as freely as possible. Though the
focus of the conversation is put on specific topics and problems, this kind of interview
enables a nearly open conversation. The topics and problems have already been an-
alyzed and summarized within an interview guideline by the interviewer. During the
conversation these topics are adressed (Mayring, 2002, p. 67). This kind of interview is
specificially applicable for theory-based research approaches, as it doesn’t have solely
explorative characteristics but is rather based on aspects of prior research. The sec-
ond important factor is the standardization of the interviews, as the same interview
guideline is used for each interview. This allows an easy comparison between various
interviews (Mayring, 2002, p. 70).

33
Participants

All experts participated entirely voluntarily and each participant was informed about
the purpose and the nature of the study. All participants were interviewed anonymously
and all data collected was used strictly for the purpose of this master thesis. In total,
twelve persons, eleven men and one woman, were interviewed for this study. The in-
terviews were conducted either in person, via Internet telephony or mobile telephony
and were recorded with the approval of the participants. One single interview was con-
ducted in written form. Therefore the participant answered a questionnaire via e-mail.
The interviews which were conducted in person, took place at the sites of the respec-
tive organizations. All of the recorded interviews were transcribed in order to make
them useable for further analysis.

This study was conducted in organizations in Austria which have experience with ERP
upgrades. All of the interviewees were either ERP consultants or executive IT man-
agers, who are strongly integrated in ERP upgrade projects in their respective orga-
nization. They mostly had a predominant influence on the organization’s IT decision
making and were in charge of the upgrade procedure including making plans of the
upgrades, arranging teams to support the upgrades and conducting the upgrades.

34
The following table shows further information about the interviewed participants:

Person Position Industry Sector ERP System Approx. Users

Microsoft
A IT Project Manager Banking N.A.
Dynamics
Industrial
B Head of IT SAP 280
Manufacturing
C Head of Institute Education SAP 3.600
D Professor Education N.A. N.A.
Microsoft
E ERP Consultant ERP Consulting N.A.
Dynamics
F CEO ERP Consulting SAP N.A.
G Head of Applications Health Care SAP 6.000
Full-Service- Microsoft
H Head of IT N.A.
IT-Provider Dynamics
Industrial
I Head of Applications SAP 1.500
Manufacturing
Industrial
J Head of IT SAP 5.000
Manufacturing
K ERP Consultant ERP Consulting SAP N.A.
Industrial
L IT Project Manager SAP N.A.
Manufacturing

Table 2: Interviewees

Structure of the interview guideline

The interview guideline was derived from the previously conducted literature review,
the problem statement and the research questions. It was structured into five main
parts. In the first part the author and the purpose of the interviews were introduced.
Additionally, the interviewee was informed about the recording of the interview and
the anonymization of personal- and organization-related information.

35
The second part dealt with the background of the interviewee. Therefore, questions
concerning the person, the area of responsibility, the responsibilities, the organization
and the latest ERP upgrade projects were asked. The third section dealt with goals
and objectives of ERP upgrade projects. The main focus was put on the reasons why
ERP upgrades were performed and which goals and objectives were defined for these
projects.

The fourth section dealt with key success factors in ERP upgrade projects. Hence, the
interviewees were asked to state the key success factors for ERP upgrade projects from
their point of view and their experience and furthermore to judge their importance. Ac-
cording to their importance the stated factors had to be prioritized. Afterwards, prob-
lems during the projects and the countermeasures were discussed. At the end of this
section, interviewees were asked to define the term success pertaining to such projects.

The last section of the interview guideline dealt with the differences in success factors
between ERP implementation projects and ERP upgrade projects. Thus, interviewees
were asked to state the main differences from their point of view and rank success
factors for ERP implementation projects mentioned in existing literature according to
their importance for ERP upgrade projects.

The complete interview guideline can be found in Appendix A.

3.4 Qualitative content analysis according to Mayring

The qualitative content analysis according to Mayring has been chosen as the method
for the analysis of the transcribed interviews because the systematic and reproducible
approach was the most suitable for this study. The author described the fundamental
idea of the qualitative content analysis as the perpetuation of systematic analytical
steps within the entire content analysis procedure. This analysis procedure is based on
the following principles (Mayring, 2013, p. 469-471):

• The situation in which the material to be analyzed arose must be included in the
analysis.

36
 • The objective of the analysis is the accomplishment of intersubjectivity. In other
words, even if the analysis is done by different analysts, the results would be
similar due to the high traceability of this method.

• The analysis follows a clearly specified system. It is based on rules, theory and
a stepwise categorization and codification of the material to be analyzed.

Even though the qualitative content analysis is based on a determined system, there is
no strict standard on how the material is analyzed. Therefore, it has to be adapted to the
research questions and the material to be analyzed. The decision on how the material
is handled, which conditions are set for each category or in which order the material is
handled has to be made according to the research topic (Mayring, 2010, p. 43).

37
The above mentioned systematic analytical steps are described by Mayring within a
general content-analytical procedural model.

Figure 6: General content-analytical procedural model (Mayring, 2014, p. 54)

In the following sections the proposed steps and the corresponding application within
this thesis are described in detail.

38
Definition of the material

Before starting with the analysis, it is necessary to define the material which will be
used for the analysis. Only relevant parts for the research questions will be used for the
analysis. Therefore the parts of the interviews where the interview partner is explicitly
talking about the research question are selected. This corpus is determined once and
should not be extended or altered during the analysis (Mayring, 2014, p. 56).

For this thesis, 11 transcribed interviews and one answered interview guideline re-
ceived via e-mail are considered as the corpus for the analysis. As the recording of the
interviews was not started until the interviewee was answering questions concerning
the research field and stopped when he or she finalized to answer the last question, the
whole interview transcripts are used for the analysis.

Analysis of the situation of origin

In the following phase, all the information concerning the situation of origin of the
interview is collected. This includes a list of people who attended the interview, the
emotional, cognitive and motivational background of the interview partners and the
concrete circumstances of the interview situation (Mayring, 2014, p. 57).

All interviewees were strongly integrated in ERP upgrade projects in their respective
organizations and therefore can be seen as experts. Further details about the inter-
viewees can be seen in the prior section. All interviewees participated in this study
voluntarily and their responses were handled strictly confidential and anonymous. Be-
fore the execution of the interviews, all interviewees were informed about the purpose
of the interviews and the study. All personal interviews were executed, transcribed and
analyzed personally by the author of this thesis.

39
The author of this thesis studied in the field of information systems for five years and
conducted an intensive literature review before the execution of the interviews. As a
consequence, his prior knowledge effected the execution, the analysis and the interpre-
tation of the interviews. According to Meinefeld (2013, p. 271) it is impossible to enter
a research field without any prior knowledge of the researched field. "It is only possible
to understand the categories of other persons based on your own categories. You have
to accept, that the perception of researchers is influenced by their prior knowledge and
thus, can be seen as the basis of research", he states.

Formal characteristics of the material

Afterwards, it has to be described in which form the material exists. Content analysis
always requires a written text as a basis. Therefore, spoken language in the form of
tape-recorded interviews has to be transcribed. Not only does the "core text" have to
be transcribed, additional information as emphasis, speed of speech, pauses in speech
and pitches of the voice may be added. This additional information can substantially
contribute to understanding the core meaning of the interview (Mayring, 2014, p. 57).

As mentioned before, all the interviews were transcribed and therefore exist as writ-
ten text. In the literature, different variations of transcription rules exist. Kowal and
O’Connell (2013) differentiate between standard orthography, literary transcription,
eye dialect and phonetical transcription. For this thesis, standard orthography has been
chosen, as this type of transcription is using standard written language as a basis. Thus,
spoken language is adapted to standard written language where it differs. Standard
written language has the advantage of being understandable and easy to read. As the
focus in this thesis is put on the content of the interviews, this type of transcription is
the most suitable.

Kuckartz (2014, p. 136f.) proposes various precise transcription rules. The following
have been used in this thesis:

• The interviews were transcribed word-for-word and not summarized. Dialects

are not transcribed, they were translated into standard German.

40
 • Language and punctuation were approximated to standard written German. The
sequence of words and articles are kept, even if they are used wrongly.

• Explicit and long breaks are marked with ellipsis (..).

• Affirmative and confirmative words, such as mhm, aha, etc., were transcribed as
well.

• Passages of the interviewer were marked with the word "Interviewer" (german
for interviewer), passages of the Interviewee were marked with the word "Inter-
viewter" (german for interviewee) and an unique code, such as A, B, C, etc.

• Each change of speaker was marked with a new line.

• Incomprehensible parts of the interview were marked with (?..?).

• All personal and confidential information about the interviewee was made anony-
mous.

Direction of the analysis

After the description of the material in the first three phases, the question "What would
I like to find out?" must be asked. The answer to this question is dependent on the
research questions. Therefore, the main focus can be set, for example, on either the
content of the interviews, the emotional or cognitive background of the interview part-
ner or the behavior of the interviewee (Mayring, 2014, p. 57).

Within this thesis, the focus was put on the content of the interviews to answer the re-
search questions mentioned in the section Objectives & research questions. The emo-
tional or cognitive background of the interviewees and the corresponding information
provided is not relevant for this study.

41
Theoretical differentiation of sub- components of the problem

As the qualitative content analysis is based on rules and theory, in the fifth step the
theoretical differentiation of the research problem has to be executed. This means that
the research problem has to be related to the already existing research in the analyzed
field and divided into sub-issues (Mayring, 2014, p. 59).
The literature review in this thesis shows that a lot of research in the field of ERP
has already been conducted, especially in the field of ERP implementation. One of
the major topics in this field is key success factors in ERP implementation. On the
contrary, not much attention was paid to the ERP maintenance, and as a part of it, the
ERP upgrade phase. This is the subject where this thesis will follow up. Therefore, the
following questions emerge from this analysis.

• What are the objectives in ERP upgrade projects?

• Why are ERP upgrades executed?

• What are the factors which enable the organization to reach these objectives and
therefore can be defined as critical success factors?

• How is success defined and measured in ERP upgrade projects?

• What are the differences between critical success factors in ERP upgrade projects
and critical success factors in ERP implementation projects?

Determination of techniques of analyis

Within this phase one of three interpretative analysis techniques proposed by Mayring
will be selected. These are the following: Summary, Explication & Structuring. For
this thesis a sub-category of structuring, structuring with regards to content, has been
chosen.

42
Structuring has been named as the most central technique in content analysis by Mayring.
Its subcategory, structuring with regards to content, is used to filter particular topics,
content or aspects out from the material. Therefore various differentiable categories
will be defined deductively. Afterwards, all text components are systematically an-
alyzed and assigned to the corresponding category (Mayring, 2010, p. 92 ff.). This
process operates in three stages (Mayring, 2014, p. 95):

1. Definition of the categories

In this stage definitions will be derived from the problem statement and the re-
search tool. It has to be exactly defined, which text components belong in which
category.

2. Anchor samples
Afterwards, concrete passages of a category are set as typical examples. These
are called anchor samples and should illustrate the character of the category.

3. Coding rules
For categories, where differentiation is not always clear, coding rules have to be
defined to ease the assignement to particular categories.

43
For this part of the analysis, Mayring (2014) provides the following procedural model:

Figure 7: Steps of deductive category assignment (Mayring, 2014, p. 96)

Deductive development of categories

The problem statement, the research questions and the interview guideline were taken
as a basis to define the following categories. The definition of the categories and the
corresponding anchor samples can be seen in the following section. Coding rules were
not developed in this case, as the differentiation of the categories is clear.

44
• Duration and volume of the upgrade-project

– Definition: All text passages which describe the duration or the volume of
the ERP upgrade project.

– Anchor Sample: "Die Durchlaufzeit von dem ersten Zeitpunkt wo ich dabei
war, weil die Pläne in den Köpfen der Manager, hat es wahrscheinlich
früher gegeben, bis zur wirklichen Fertigstellung war knapp 9 Monate."

• Reasons for the upgrade

– Definition: All text passages which describe the reasons for the execution
of an ERP upgrade project.

– Anchor Sample: "Wir haben erstens funktionale Erweiterungen, speziell

im HR-Bereich gewollt, wo das alte Release, das nicht mehr leisten konnte,
was man sich da gewünscht hat."

• Objectives of the upgrade-project

– Definition: All text passages which describe the objectives of an upgrade

project.

– Anchor Sample: "Dass die Performance nicht schlechter ist, als die die wir
vorher hatten und dass wir wieder alle Applikationen innerhalb des ERP
sauber zum Laufen bringen."

• Definition of success

– Definition: All text passages in which the interviewee defines the success
of a project from his point of view.

– Anchor Sample: "Zielerreichung, in erster Linie, soweit es quantifizier-

bar ist, ist ganz klar, Vergleich, System vorher nachher, vor allem Perfor-
mance. Funktionalität, Umstellung, selber, Down-Time, also, das ist für
mich eigentlich das wichtigste."

• Success factors in ERP upgrade projects

– Definition: All text passages which indicate, that the described factor is
necessary to successfully carry out an ERP upgrade project.

45
 – Anchor Sample: "ich muss das Team richtig zusammensetzen, schon von
der Konzeptionsphase, weil ich kann Leute haben, [...] Also ich muss
die richtigen Leute im Team haben und zwar unter Umständen sogar ver-
schiedene für die Konzeptionsphase und für die Durchführungsphase."

• Priorization of success factors

– Definition: All text passages in which interviewees prioritize success fac-

tors.

– Anchor Sample: "1. Kommunikation, 2. Test des Upgrades auf identem

Testsystem, 3. Projektmanagement, 4. Einhalten von Terminen"

• Problems and their solutions within the project

– Definition: All text passages in which various problems during an ERP up-
grade project are described and potential solutions for them are presented.

– Anchor Sample: "Probleme bei Schnittstelle zu Einkaufsmodul am Test-

system. Umstellung musste daher um 1 Woche verschoben werden, dadurch
haben wir uns jedoch viele Probleme nach Go-Live erspart"

• Differences in success factors within ERP implementation and ERP upgrade

projects

– Definition: All text passages which describe the differences in success fac-
tors within ERP implementation and ERP upgrade projects.

– Anchor Sample: "Ich kann das dann beim Upgrade auch noch so machen,
ich mache eben dieses Testsystem, mach es dort einmal und sage dann,
schaut einmal darauf ob es das liefert, was ihr wollt. Bei einem Implemen-
tierungsprojekt, kann ich das alles nicht tun."

Analytical steps taken by means of the category systems and interpretation

Afterwards, the selected text components were analyzed according to the selected anal-
ysis technique. During the first run-through of the material, sub-categories for success
factors for ERP upgrade projects were defined to identify various important factors.
Subsequently, all the material was analyzed a second time to determine all suitable

46
text passages for the corresponding sub-categories. The category "problems and their
solutions" was used additionally to derive further success factors or complementary
mentioned success factors. The detailed classification of text passages to specific cat-
egories can be seen in Appendix B.

After the finalization of the analysis process the categorized material was structured
and summarized in order to present the results of the qualitative study.

47
4 Results
In the following sections the results of the qualitative analysis of the interviews are
presented. The presentation is based on the categories found within the qualitative
analysis. As already mentioned in the respective section, the results are based on ex-
pert interviews with either ERP consultants or executive IT managers who conducted,
consulted or were responsible for ERP upgrade projects within the last few years. The
duration of the discussed ERP upgrade projects ranged from one and a half months
for rather small projects to one and a half years for comprehensive and large projects.
All interviews were conducted anonymously, thus, the interviewees are referred to as
letters from A to L. All transcribed interviews can be found in Appendix C.

4.1 Reasons for ERP upgrades

For each interviewee different aspects triggered the decision to execute an ERP up-
grade. One of the main aspects was the ability to use new functionality offered by new
releases. Even though some organizations only need a small part of new functionali-
ties included in the release, upgrading the system is often preferred to the development
of individual enhancements for efficiency reasons (E, Appendix C.5, par. 6). In case
more of the included functionality is needed, it can be easily activated from that point
on (K, Appendix C.11, par. 8). Legal changes force organizations to adapt their sys-
tem in order to comply with new laws. Such legal patches offered by the ERP vendors
often require a specific release version, which is another reason why organizations are
forced to upgrade their ERP system (G, Appendix C.7, par. 18).

Another main reason for upgrading the ERP system is the imminent end of support
offered by the vendor (E, Appendix C.5, par. 8). Not only can the support for the ERP
system itself be a crucial factor in this matter, underlying systems, such as databases
or operating systems, also have to be updated because of support issues. The emerging
compatibility issues can be another reason why an ERP upgrade is inevitable (I, Ap-
pendix C.9, par. 10 & L, Appendix C.12, par. 6).

48
A key challenge in every organization should be to secure competitiveness. One way
to achieve this goal is process innovation, which is easier to implement during an ERP
upgrade project (F, Appendix C.6, par. 12). Another way to reach this goal from the
IT perspective is the establishment and use of emerging technologies. ERP upgrades
allow the use and application of new technologies provided by the ERP vendor and
enable the organization to keep up with the latest developments (J, Appendix C.10,
par. 8 & D, Appendix C.8, par. 6).

4.2 Definition of success

When talking about successful ERP upgrade projects, it is necessary to define suc-
cess. C doesn’t differentiate the success in ERP upgrade projects from success in other
projects. He states: "Projects have to meet time, budget and scope targets to be called
successful (C, Appendix C.3, par. 24)." H, on the other hand, thinks time is not the
main priority in ERP upgrade projects, as long as there is a usable system in place
and productivity is not endangered. However, functionality targets have to be achieved
and budget targets must be met (H, Appendix C.8, par. 21). For I, the main aspect
of success is functionality. Both the successful usage of already existing functionality
and the availability of new features are the key factors influencing the success of ERP
upgrade projects. Nevertheless, he states: "To qualify a project as successful, time and
budget targets also have to be met (I, Appendix C.10, par. 36)."

As a result of the high complexity of the project and the huge dependency on the ERP
system, B scales down the expectations and states: "As long as the system is running
smoothly on the day after the upgrade and the users are able to work without any un-
foreseen complications, the upgrade can be seen as successful (B, Appendix C.2, par.
27)." J takes the same line and considers an ERP upgrade project as successful when
time targets are nearly met and the company is able to continue their business without
complications (J, Appendix C.10, par. 22).

49
L and G also mention non-functional requirements, which have to be met to call an
ERP upgrade project successful. The down-time caused by the upgrade has to be
minimized to a level that barely influences the work-routine inside the organization.
Additionally, criteria such as performance and availability of the system have to at
least reach the level which they had before the upgrade (L, Appendix C.12, par. 16 &
G, Appendix C.7, par. 37).

4.3 Objectives for ERP upgrades

The interviews showed that there is a similar usage of the terms "What does success
in an ERP upgrade project mean?" and "What are the objectives in an ERP upgrade
project?". When asked about the objectives of ERP upgrade projects, many of the
interviewees talked about securing already existing functionality. After the implemen-
tation of the new release version, users must not discover any obstacles in their daily
work routine (B, Appendix C.2, par. 15 & C, Appendix C.3, par. 15 & D, Appendix
C.4, par. 8). Also, non-functional aspects, such as performance, security, stability or
reliability must at least reach the level they had before (G, Appendix C.7, par. 24 &
K, Appendix C.10, par. 11). Additionally, the basis for new functionality should be
established to be able to implement new functionality and benefit from it (I, Appendix
C.9, par. 14 & G, Appendix C.7, par. 24).

B and K agreed on the fact that one objective on an ERP upgrade project always has to
be an effort to replace individual developments of the system with standard function-
ality offered by the vendor. That means that new features of the new release version
have to be examined in detail in order to identify possible replacements of individual
developments. (B, Appendix C.2, par. 17 & K, Appendix C.11, par. 18). D emphasizes
the necessity to intensively study new technology offered by a new upgrade version in
order to adapt applications and processes and benefit from technological enhancements
(D, Appendix C.4, par. 8).

50
The technical upgrade is often executed on weekends, as in a lot of organizations em-
ployees are not dependent on the system during this time. In sectors such as Health-
care, users are dependent on the system 24/7. Thus, for G the minimization of the
system down-time and the connected non-availability are major goals in such projects
(G, Appendix C.7, par. 10).

4.4 Critical success factors in ERP upgrade projects

In this section, critical success factors in ERP upgrade projects mentioned by the inter-
viewees are presented. The author developed these factors by classifying statements in
generic categories, which can be adapted to different organizations. The order of the
presented success factors is based on the priorization of the factors conducted by the
interviewees and the amount of appearances of the factors within the interviews. The
following table shows the amount of text passages within the interviews which could
be assigned to the corresponding success factors.

Success factor Nr. of text passages

Project management 23
External support 21
System testing 14
Multiple system landscape 12
ERP team 11
Communication 10
Key user integration 8
Lessons learned 8
Stick to the standard 7
Top management support 5
Resources & focus 4
Change management 4
Data & Code Cleansing 3
Use of new potentials 2

Table 3: Appearances of success factors in interviews

51
4.4.1 Project management, project manager and project evaluation

Project management was the most often mentioned critical success factor in ERP up-
grade projects. Even though ERP upgrades are recurring tasks and thus would not
match the definition of a project, the long timespan between them and the criticality
lead to the absolute necessity to execute them within a project. This means compre-
hensive project management has to be conducted with all its components, such as an
exact project charter, a detailed time plan, the appointment of a project manager and
a project team, a work breakdown structure and project controlling (G, Appendix C.7,
par. 8). H and I emphasize the absolute necessity of putting the focus on the planning
and specification phase. It has to be defined in detail who is responsible for which
work package and when it has to be finished (H, Appendix C.8, par. 13 & I, Appendix
C.9, par. 20). Another part of the planning phase is the definition of fallback scenar-
ios in case of unplanned circumstances (I, Appendix C.8, par. 20). E also points out
that responsible persons should think thoroughly about features to be implemented and
their benefits. He states: "Only the fact that some processes are already established
within a company or the fact that key users and process owners desire some feature
is not reason enough for a specific functionality to be implemented. Each new func-
tionality has to be discussed in detail and its benefits have to be weighed out against
the costs in order to find the best solution for the company" (E, Appendix C.5, par. 12).

A special focus within the factor project management was often put on the project
manager. When asked about the most important key success factors J answered: "First
the project manager, second the project manager and third the project manager. Next
to his/her managerial tasks, he/she has to commit themselves to the project, he/she has
to know the current status of each work package at any time and has to compensate for
the problems that occur on the project levels below him/her" (J, Appendix C.10, par.
12). C and D took the same line and described the project manager as a person who not
only is a professional within the IT, he/she also needs deep knowledge of the business
and the processes of the organization (C, Appendix C.3, par. 10 & D, Appendix C.4,
par. 15).

52
Another important part within the management of ERP upgrade projects is the project
review and evaluation. This should be done in recurring time intervals, where the
project team checks if the project is on track and if there is room for improvement, in
order to be able to respond to unforeseen changes as quickly as possible (E, Appendix
C.5, par. 50). At the end of the project it has to be checked if the project has been
executed as planned, if expectations are met and if users get along with the upgraded
system (I, Appendix C.9, par. 80). Another important task, which is often forgotten by
organizations, is the measurement of the benefits of the project after finalization of the
project. K proposes to not only measure it one year after finalization, but also three and
five years after finalization to be able to identify the long-term benefits of the project
(K, Appendix C.11, par. 22).

4.4.2 External support

A substantial success factor often mentioned during the interviews was external sup-
port. Because of constant efforts to increase efficiency within organizations, employees
often work at full capacity and are not able to spare a large amount of their workload for
additional projects. Therefore, it is inevitable to engage external resources with com-
prehensive know-how to support the local ERP team within such a project (J, Appendix
C.10, par. 14). Another reason for the necessity of external resources is the econom-
ically unviable development of internal know-how in specific areas. This would not
only lead to high expenses but also to an increase in the lead time of the project (I,
Appendix C.9, par. 24). Additionally, companies benefit from the experience of exter-
nal consultants or implementation partners. I underlines this factor: "I expect from an
external consultant, that he is able to tell me which problems already occurred in other
similar projects and he knows a way to avoid them within our project" (I, Appendix
C.9, par. 24).

Nevertheless, organizations can only benefit from these factors, if external resources
are well selected. Even though most of the interviewees pointed out the importance
and benefits of external consulting, B described his experience with consulting as un-
satisfying: "I would have expected more input. He did not even know the features of
the new version and was not able to report on his experiences with this version" (B,

53
Appendix C.2, par. 21). D and H also emphasized the importance of the selection of
external resources. They not only have to offer deep technical knowledge but also have
to understand your business and have to be experienced (D, Appendix C.4, par. 47 &
H, Appendix C.8, par. 13).

Apart from consultants and implementation partners, the ERP system vendor also plays
an important role. SAP, for example, offers so-called "MaxAttention" support con-
tracts, which enhance the support level and place a system expert at the disposal of the
project team during the upgrade process in case there is need for support (G, Appendix
C.7, par. 29). G also proposes to contact companies within the same business sector
which already implemented the corresponding release version in order to profit from
their experience (G, Appendix C.7, par. 27). Furthermore, J recommended employing
students and interns for data cleansing tasks to allow ERP team members to focus on
the critical tasks within the project (J, Appendix C.10, par. 14).

4.4.3 System testing

System testing is one of the most important tasks to ensure an unobstructed opera-
tion of the ERP system after the upgrade procedure (L, Appendix C.12, par. 10). K
recommends establishing a quality assurance department, which knows the business
processes and the functionality of the system before the upgrade to be able to deter-
mine misbehavior within the system (K, Appendix C.11, par. 12). Additionally, it is
necessary to integrate key users of all departments to be able to validate both the al-
ready existing and the new functionality (B, Appendix C.2, par. 4).

The testing process should be executed in a well-structured manner. Therefore, de-

tailed test plans and test scenarios with various test cases have to be defined to secure
a comprehensive and wide-spread coverage of the functionality (B, Appendix C.2, par.
19 & H, Appendix C.8, par. 15). Even though test automation tools for ERP systems
are expensive and often not able to cover individually developed parts of the system,

54
test automation is a way to reach a high standardization of the testing process. In the
case of a system without much individual development, test automation tools should
be taken into consideration (G, Appendix C.7, par. 16).

System testing should not only focus on functional testing. Especially non-functional
factors, such as performance and reliability, have to be part of the testing process. The
fact that the working load on a productive system can hardly be emulated constitutes a
challenge. G states: "We are not able to generate the working load of our productive
system for testing. In this case we have some reference transactions, some reports for
example, with which we are able to compare the processing time before and after the
upgrade" (G, Appendix C.7, par. 16). In another part of the testing process, compati-
bility issues have to be dealt with to make sure that connected systems and peripheral
devices are working with the new version (A, Appendix C.1, par. 8). As the last part of
the system testing process, G proposes executing further tests on the already upgraded
productive system before go-live in order to eliminate potential missed misbehavior
(G, Appendix C.7, par. 12).

4.4.4 Multiple system landscape

Another important factor which increases the probability of a successfully executed

ERP upgrade project is the usage of a multiple system landscape. Such a multiple
system landscape for ERP systems typically consists of three systems: the develop-
ment system, the quality assurance system and the productive system. G even suggests
to use a fourth, preceding system: the sandbox system. The sandbox system is an
independent system, where the new release version is initially installed to identify
issues during the technical installation process. The goal of this step is the identifi-
cation of optimizations on the productive system before the technical upgrade to be
able to reduce down-time. The next step is to move to the development system, where
functional and non-functional tests are performed. Firstly, already existing function-
ality, especially individually developed functionality, is tested with a special focus on
compatibility with the new release version. Secondly, new available functionality is

55
configured and tested. On this level software developers perform basic tests. As soon
as basic functionality is guaranteed, key users should test detailed real-life scenarios
(G, Appendix C.7, par. 12 & I, Appendix C.9, par. 8).

Subsequently, the quality assurance system is used to test the interaction between the
ERP system and various connected information systems. That means not only is the
functionality of the ERP itself tested but also the influence of the new release version
on the interfaces of other systems. The last part is the deployment of the tested versions
on the productive system. Due to the experience gained with the preceding systems,
the whole upgrade process can be better calculated and the down-time of the productive
system can be reduced as much as possible (G, Appendix C.7, par. 16 & I, Appendix
C.9, par. 8). G recommends cloning the system before the upgrade procedure and
establishing a so-called "evidence system". This allows for a comparison with the
old system in the case of deviating behavior. Furthermore, users often tend to report
different behavior after the upgrade procedure. Given that no one is able to know
the whole system by heart, this system permits the discrepancies to be checked (G,
Appendix C.7, par. 37).

4.4.5 ERP team

The success in ERP upgrade projects heavily depends on the composition of the project
team. Employees with the best technical expertise are not always the most suitable
team members for such projects. Team members must be able to think in a project-
oriented manner and must be ready to show commitment. I proposes selecting different
team members for the conception phase and the realization phase in order to benefit
from the personal strengths of the employees (I, Appendix C.9, par. 22). J insists that
executive managers should not be a part of the project team. Firstly, employees don’t
always tell the inconvenient truth if their supervisor is in the same room, though this is
crucially needed. Secondly, the project manager needs to have the opportunity to put
pressure on team members if they are not putting enough effort in the project. If a team
member is an executive manager he is not in a position to do that (J, Appendix C.10,
par. 12).

56
The ERP project team should consist of a well selected mixture of employees with
business, process and technical competence. The existence of business and process
knowledge within the project team allows the handling of business-related topics with-
out consulting the appropriate department (C, Appendix C.3, par. 10). In addition to
that, a team member should be selected to act as a mentor in order to mediate between
team members in case of disagreements and to put the focus back on the project (I,
Appendix C.9, par. 30).

4.4.6 Communication

Communication is the basis for any cooperation and thus, an important factor to suc-
cessfully carry out ERP upgrade projects. This topic has to be discussed from two
angles. On the one hand there is communication within the ERP project team and on
the other hand there is the communication with other stakeholders, such as end users
and top management.

One major objective within such a project has to be the introduction of a communi-
cation culture, which enables effective coordination between various departments and
their interests. Within an ERP project many different departments are involved and
each of them is pursuing slightly different interests. These parties have to be in com-
munication from the beginning of the project in order to accomplish the best result for
the organization (J, Appendix C.10, par. 12). Additionally, there is a need for profes-
sional communication within the project. Even though team members have different
opinions on a topic, communication and discussion must take place on a professional
level and personal differences must be left behind (I, Appendix C.9, par. 22).

The second point mentioned is the communication with other stakeholders. An impor-
tant part is the communication with end users, as they can offer crucial process knowl-
edge and indicate potential problems from their point of view (L, Appendix C.12, par.
10). Another important factor within communication with end users is the manage-
ment of expectations. Users tend to expect a universal remedy from an ERP upgrade.
To avoid frustration after the upgrade, it is recommended to communicate in detail

57
which functionality and which improvements are included in the new version of the
system (I, Appendix C.9, par. 36). Furthermore, reporting is also a part of communi-
cation. There has to be a detailed plan to define how project reporting is done to avoid
misunderstandings (I, Appendix C.9, par. 22).

4.4.7 Key user integration

The analysis of the interviews showed that the integration of key users right from the
start is essential to the success of the project. H proposes integrating key users already
in the planning phase to profit from their process knowledge and thus be able to stay
on the right track (H, Appendix C.8, par. 13). In addition to the planning phase, key
users play an important role within the testing phase as they are able to deliver valuable
input for the definition of test scenarios and test cases (B, Appendix C.2, par. 19).

An awareness that such projects are necessary and important for the organization is
essential in order to get all employees on board. Key users are in a perfect position to
act as middlemen between the project team and the end users to promote the advantages
and point out the value of the project. This leads to a decrease in resistance to changes.
In addition, key users are in a position to prepare end users for possible system changes
and new challenges in order to increase the acceptance of the project (H, Appendix C.8,
par. 13 & F, Appendix C.6, par. 14).

4.4.8 Lessons learned

During the lifecycle of an ERP system, multiple ERP upgrade projects have to be
carried out. The improvement of the performance from one project to another has to
be a major goal for every organization. Thus, learning from mistakes is a key factor
for future success. G suggests implementing a structured and standardized lessons
learned process (G, Appendix C.7, par. 25). E emphasizes the importance of lessons
learned meetings, which are not only conducted at the end of each project, but rather
are established as a continous process. During the whole project, team members should
write down complications which are analyzed in regular meetings to be able to learn

58
from previous mistakes (E, Appendix C.5, par. 50). J also takes the same line: "Even
though this is often neglected by a lot of companies, from my point of view it is very
important to invest your time in lessons learned meetings to be able to learn from your
own mistakes" (J, Appendix C.10, par. 56).

4.4.9 Stick to the standard

An ERP system is characterized as off-the-shelf software, which is designed to be con-

figured and adapted by organizations in order to perfectly meet their business needs.
For this reason, ERP vendors offer various opportunities for adaptations without the
need of a source code modification. Nevertheless, many companies decide to modify
the source code to meet essential business needs. E and J strongly recommend avoid-
ing code modification, as it entails major difficulties during an ERP upgrade. If the
modified functions are changed by the vendor within the new release version, the de-
sired functionality cannot be guaranteed after the upgrade (G, Appendix C.5, par. 12
& J, Appendix C.10, par. 20).

Another important factor influenced by code modification is revision security. ERP

systems offer revision security and therefore are accepted by tax authorities. Code ma-
nipulation in critical parts of the system can lead to the refusal of tax audits as legally
correct archiving of fiscal information cannot be guaranteed (J, Appendix C.10, par.
20). G underlines these problems with the conclusion: "With code manipulation you
put potential bombs in your system, which can explode at any time" (G, Appendix C.7,
par. 51).

Because of the aforementioned reasons, K proposes using the upgrade project to an-
alyze both new functionality within the new release version and individual developed
functionality within the implemented system. The objective has to be the replacement
of as much individually developed functionality as possible by standard functionality
offered by the vendor. The more standard functionality is used within a system the less
problems will occur during an ERP upgrade (K, Appendix C.11, par. 18).

59
4.4.10 Top management support

ERP upgrade projects not only result in huge costs but also often necessitate consid-
erable organizational and technical change. Thus, top management support is another
critical success factor. As a result of the high complexity of such projects, financial
forecasts are often not met and costs exceed the planned budget. Top management has
to be aware of the importance of the project and assure financial and moral support.
Additionally, ERP upgrades often lead to changes for end-users as new processes are
implemented or new functionality is added. Therefore, top management has to commu-
nicate the necessity of the potential changes to avoid resistance within the workforce
and encourage commitment to the project (F, Appendix C.6, par. 14 & I, Appendix
C.9, par. 22 & J, Appendix C.10, par. 12).

4.4.11 Resources & focus

Another important factor which has been stated often is the availability of all neces-
sary resources. The ERP upgrade project has to be carefully coordinated with other
projects within the organization. A time frame has to be chosen in which no other
major projects take place in order to have the necessary workforce available for the up-
grade project. ERP team members must have the chance to put aside their regular field
of activity as much as possible during the project to be able to focus entirely on the
upgrade project (C, Appendix C.3, par. 20 & G, Appendix C.7, par. 22 & F, Appendix
C.6, par. 20).

Additionally, G suggests focusing on the upgrade itself and warns against viewing the
required downtime as a reason for further adaptations or improvements. Increasing the
already high complexity can lead to huge difficulties when the source for a specific
error has to be determined (G, Appendix C.6, par. 24).

60
4.4.12 Change management

In the case that the upgrade is not only a technical upgrade but also new processes are
implemented or existing processes are optimized, change management is a key factor
for a successful project (K, Appendix C.11, par. 27). Organizational structures have
to be adapted to new or changed processes and necessary stuffing changes have to be
managed to prepare the organization in the best way possible for the time after the up-
grade. Especially if employee dismissal or significant position changes are inevitable,
a change manager with sensitivity is needed (E, Appendix C.5, par. 12 & H, Appendix
C.8, par. 28).

4.4.13 Data & code cleansing

The upgrade of an ERP system should always be used for a system clean-up. Dur-
ing many years of usage, a lot of unneeded or incorrect data is accumulated within a
system. This ranges from open positions, which are not closed for years, to outdated
or wrong customer, supplier and material data. This clean-up prevents the transfer of
wrong or outdated data into the new system. H suggests not only cleaning up user
data but also cleaning up the source code. As source code review often is necessary
anyway, she thinks that this opportunity should be used to check the source code for
old or unused functions and if possible, get rid of them (H, Appendix C.8, par. 13 & J,
Appendix C.10, par. 14).

4.4.14 Use of new potentials

The decision to upgrade an ERP system is often driven by the availability of new
technologies. According to D, it is essential that companies use new technological
possibilites provided by the new release version. Organizations have to put their full
attention to the new technology and develop profound technical knowledge in order
to understand the implications for their business. All these findings must influence the
development of improvements, so that the new technological possibilites are beneficial.
D states: "The implementation of old processes with the new technology is only a

61
waste of money (D, Appendix C.4, par. 10)." He also advises against relying solely on
external consultants. The understanding of your own business is a key factor to be able
to get the best out of the new technology for your organization (D, Appendix C.4, par.
10).

4.5 Differences in success factors between ERP implementation

and ERP upgrade projects

In the following section the differences in success factors between ERP implemen-
tation and ERP upgrade projects are presented. Firstly, interviewees were asked to
present the differences in success factors between ERP implementation projects and
ERP upgrade projects from their point of view. Secondly, they were asked to rate the
importance of the success factors for ERP implementation projects mentioned in pre-
vious literature with respect to ERP upgrade projects. Based on these statements, the
following differences have been found.

A major difference between ERP implementation and ERP upgrade projects is the fact
that you already have a running system when you start with an ERP upgrade project
and don’t have to start from the very beginning. This leads to various changes in suc-
cess factors. During an ERP upgrade project only a part of the functionality is changed,
renewed or newly implemented. Therefore, the detailed specification has to be done
only for new functionality and can be aligned to the existing system. When imple-
menting an ERP system, the specification of the functionality has to take place in a
more detailed and extensive way as requirements from different departments have to
be collected, specified and proritized (I, Appendix C.10, par. 40). To sum it up, the
specification and conception phase in an ERP implementation project is more complex
and time-consuming compared to an ERP upgrade project.

62
The same applies to the factor business process reengineering and customization, which
is a key factor in ERP implementation projects. After an ERP upgrade, the majority of
business processes will not be touched and therefore stay as they are. Only processes
related to new functionality have to be reengineered and potential new modules have to
be customized. Therefore, this factor only plays a minor role in ERP upgrade projects
(A, Appendix C.1, par. 39 & H, Appendix C.8, par. 35).

Another consequence of already having a running system when you start with an ERP
upgrade is that users know the system. Therefore, basic user training is not necessary,
as users are already working with the system for a significant amount of time and are
used to it. Only in the case of newly implemented functionality or adapted functional-
ity users have to be trained. Because of the small amount of new functionality, users
can be informed about small changes via handouts or short guidelines and extensive
personal training can be avoided (B, Appendix C.2, par. 46 & G, Appendix C.7, par.
55). Not only do users already know the system when an ERP upgrade is executed, IT
employees also already acquired know-how about the system and the technology be-
hind it. Thus, project members can already estimate potential problems and obstacles
caused by the system and only have to rely to a smaller extent on external expertise (B,
Appendix C.2, par. 30 & I, Appendix C.10, par. 40).

L points out that in ERP implementation projects a sensible approach has to be cho-
sen regarding changes in business processes and field of activities to be able to reach
a high user acceptance (L, Appendix C.12, par. 18). This factor only plays a role in
ERP upgrade projects if new functionality is introduced which is changing the working
habits of the users. To successfully implement an ERP system, a clear business plan
and a vision have to be defined to carry out the project accordingly. For ERP upgrade
projects, this factor was estimated as not equally important, as only minor changes in
functionality are conducted and the basic strategy of the system remains as it was (C,
Appendix C.3, par. 35 & G, Appendix C.7, par. 47 & K, Appendix C.11, par. 30).

63
Change management is a key success factor in ERP implementation projects and was
also rated as one for ERP upgrade projects in case of newly implemented functionality
and processes. In case of only minor functional changes, the importance of change
management was rated as not very important by B and G (B, Appendix C.2, par. 34
& K, Appendix C.11, par. 28). Another key factor in ERP implementation projects is
the selection of the software packages, which best meets the business needs. As the
ERP package is not changed within an upgrade this factor is not applicable within ERP
upgrade projects.

Further success factors for ERP implementation projects, such as the selection of a
project champion, the building of a business case or the appropriate management of
legacy systems, were rated as not very important for ERP upgrade projects by the in-
terviewees. On the other hand, success factors for ERP upgrade projects are also not
relevant for ERP implementation factors. Firstly, the use of a multiple system land-
scape for testing and quality assurance is not necessary within a ERP implementation
project, as the system to be replaced can be in use until the newly implemented system
is ready for use. Secondly, data and code cleansing is also not relevant for ERP imple-
mentation projects because there is no existing code or data before an implementation
project.

The last factor for ERP upgrade projects which is not relevant for ERP implementation
projects is the factor "Use of new potentials". To use potentials of an ERP system is a
major part of business process reenginering, which is anyway a critical success factor
within ERP implementation projects.

64
5 Conclusion
During the last 20 years many organizations implemented ERP systems, as they real-
ized the benefits offered by these systems. In 2015 already 93% of large organizations
in Germany with more than 250 employees deployed ERP systems (Marwan, 2016).
In times of rapidly changing business environments, technological enhancements and
rising pressure of competition, companies are forced to keep their system up-to-date
and perform ERP upgrades to be able to respond to these challenges. However, not
only because of the complexity but also because of the high costs, a failed ERP up-
grade project can turn into a nighmare for any company. Therefore, this study focused
on the identification of key success factors in ERP upgrade projects. Since not much
research exists yet about ERP upgrades, open semi-structured interviews and the quali-
tative content analysis according to Mayring were selected. As a basis for this analysis,
twelve expert interviews with CEOs, CIOs, IT project managers and ERP consultants
who had recently carried out ERP upgrades in their respective organization were con-
ducted.

This section presents the conclusions of this thesis to answer the research questions.
Firstly, the objectives of ERP upgrade projects, secondly the identified success factors
and thirdly the differences in success factors between ERP implementation and ERP
upgrade projects are discussed. Furthermore, the implications for practice and aca-
demic research are adressed, the limitations of the study are discussed and suggestions
for future research are presented.

5.1 Discussion of the results

When analysing the objectives of an ERP upgrade project it becomes clear that the
securing of already existing functionality is perceived as more important than the ac-
tual implementation of new functionality. Organzations often carry out ERP upgrade
projects to lay the foundations for new functionality, which is then implemented within
separate projects. Another major objective is minimal influence of the ERP upgrade
on daily business. Therefore, the minimization of the ERP system down-time plays

65
a key role. Furthermore, users should be able to continue their daily work after the
upgrade without encountering obstacles such as severe changes in their workflow or
performance losses.

In this study 14 factors were identified which are strongly connected with ERP up-
grade project success. A major factor mentioned by most of the interviewees was
project management. ERP upgrade projects must not be underestimated and therefore
comprehensive project management with all its sub-components is an essential tool
to guarantee project success. A special emphasis has to be put on the planning and
specification phase as well as the selection of a motivated and skillful project manager.
Within the organization, the planning of other projects has to be aligned with the ERP
upgrade project in order to secure the availability of necessary personal resources and
to put the focus on the upgrade project. Furthermore, almost everybody agreed that a
successfully carried-out project heavily depends on external support, as the develop-
ment of the necessary know-how would be economically unviable and organizations
can benefit from the experiences of external stakeholders. However, interviewees also
reported unsatisfying experiences with external consultants. Thus, the careful selection
of them is required in order to benefit from external support. Not only the selection of
external stakeholders but also the composition of the ERP team has been identified as
a critical success factor. The ability to think in a project-oriented manner and to show
commitment was rated as more important than technical skills. In addition, there was a
broad agreement that the project team has to consist of a well-selected mixture of team
members with business, process and technical know-how.

The usage of a multiple system landscape enables the organization to reduce the com-
plexity of the upgrade process as the upgrade procedure is executed in smaller steps.
Before upgrading the productive system, technical installation procedure, functionality
and interfaces to other systems can be tested in various non-productive systems. This
leads to the next success factor identified. System testing was also named as an impor-
tant factor by many interviewees to be able to successfully carry out an ERP upgrade
project. System testing should not only be executed by IT staff but also by key users
and process owners, who bring along process knowledge and therefore can guarantee

66
correct functionality. Another key factor is the integration of key users in the project
from the very beginning of the project. Key users are able to deliver valuable insight
into various departments and their needs which enables the perfect alignment of the
system with the business needs.

Even though it implies additional work for all team members, many interviewees men-
tioned the importance of lessons learned meetings. As ERP upgrade projects are re-
curring, mistakes made are a chance to improve the upgrade performance for the next
upgrade project. Another stumbling block within an ERP upgrade project is a high
degree of individual code modification within an ERP system. Therefore, every up-
grade project should be used to remove individual developed functionality and replace
it with new available standard functionality provided by the ERP vendor. Additionally,
upgrade projects should also be a chance to remove unused or incorrect data and source
code.

There has been a broad consensus on the importance of all the above mentioned suc-
cess factors. When it comes to change management and top management support,
contradictory statements were made. The reason for this is the different amount of
new functionality implemented during an ERP upgrade project. For upgrade projects
where hardly any new functionality is implemented, both factors were estimated as
not very important, whereas for projects with many newly implemented processes and
much newly implemented functionality, they were estimated as rather important.

Many factors, such as project management, team composition, communication, system

testing and external support, are crucial for ERP implementation projects as well as for
ERP upgrade projects. Still there are various critical success factors which are only
relevant for one of the two. ERP implementation projects are more comprehensive and
therefore the specification phase is more crucial than in upgrade projects. Furthermore,
a clear vision and a business plan, as well as the definition of a business case and user
training, were identified as more important in implementation projects than in upgrade
projects. On the other hand, success factors such as the usage of a multiple system
landscape or data and code cleaning are only important for ERP upgrade projects. Ad-

67
ditionally, some success factors for ERP upgrade projects also have a huge impact on
ERP implementation projects. The study showed that a high degree of code modifica-
tion leads to major problems during the upgrade procedure. Therefore, organizations
are urged to avoid code modifications within the ERP implementation phase in order
to prevent issues during potential ERP upgrades.

To sum it up, there is a large overlap between critical success factors in ERP im-
plementation projects and ERP upgrade projects, though this thesis also showed dif-
ferences. Therefore, organizations must not make the mistake to misjudge an ERP
upgrade project as a small ERP implementation project. The detailed analysis of the
differences and the corresponding behavior is crucial for ERP upgrade success.

5.2 Implications for practice

ERP upgrade is a major topic in the business world, as many organizations will be
forced to upgrade their system within the next few years. Understanding the critical
success factors that influence the ERP upgrade success has strong practical implica-
tions for ERP upgrade projects. It enables managers of ERP upgrade projects to adjust
the approach for their project to maximize the benefits by emphasizing critical suc-
cess factors during the project. Additionally, ERP vendors get the chance to study the
identified factors in order to improve their upgrade procedures and upgrade support.
Finally, the ERP consulting sector can also benefit from the success factors presented.
ERP consultants are able to improve and adjust their services to increase ERP upgrade
project success for their clients. In general, all stakeholders of an ERP upgrade project
interested in project success can benefit from the results of this thesis.

68
5.3 Implications for research

A comprehensive literature review showed that the focus in ERP research has been put
mainly on ERP selection and ERP implementation, whereas little research has been
done regarding ERP maintenance and ERP upgrade. This study tried to increase the
understanding of ERP upgrade projects and their challenges. Given the large number
of implemented ERP systems along with the limited existing research on the post-
implementation phase of ERP systems, this study builds a basis for further empirical
research on ERP upgrade and ERP maintenance.

5.4 Limitations of the study

As a result of time and resource constraints, this thesis has several limitations. First,
because of region and time constraints, the data for the qualitative analysis was col-
lected mainly in Upper Austria and Vienna and therefore the thesis only focuses on
organizations in Austria. Thus, the results can only reflect ERP upgrade projects in
Austria and can not generalize on other regions or countries across the world. Sec-
ond, due to difficulties in finding interviewees for this study, the variety of represented
business sectors is limited. To compensate for this imbalance, ERP consultants with
experience in different business sectors were selected for interviews. Third, only one
of the twelve interviewees was female. This is a result of the fact that men dominate
the information technology sector and hardly any women responded to inquiries for
interviews. Finally, the results of this qualitative study are based on subjective impres-
sions of the interviewees. Thus, to be able to provide general reliable statements, the
assumptions made in this thesis must be verified within a broadly based quantitative
study.

5.5 Future research

This study identified 14 critical success factors in ERP upgrade projects by pursuing
a qualitative approach. There are some possible reseach directions that can further
advance the research in this area. First, a quantitative study with a larger sample size
would enable generalization of the results and therefore confirm the relevance of the
stated critical success factors in ERP upgrade projects for a large amount of organi-

69
zations. Second, more countries or continents should be considered in this study to
explore the influence of cultural differences on the criticality of identified success fac-
tors. Third, the impact of various design decisions during the implementation phase on
problems and challenges within an ERP upgrade project should be researched in order
to facilitate hints for organizations planning to implement an ERP system. Finally, the
critical success factors identified could be used as a basis for the development of a
detailed process model for ERP upgrade projects.

70
References
Al-Mashari, M., & Al-Mudimigh, A. (2003). ERP implementation: lessons from a
case study. Information Technology & People, 16(1), 21–33.
Al-Mashari, M., Al-Mudimigh, A., & Zairi, M. (2003). Enterprise resource plan-
ning: A taxonomy of critical factors. European Journal of Operational Re-
search, 146(2), 352–364.
Barker, T., & Frolick, M. N. (2003). ERP implementation failure: A case study.
Information Systems Management, 20(4), 43–49.
Beatty, R. C., & Williams, C. D. (2006). ERP II: best practices for successfully
implementing an ERP upgrade. Communications of the ACM, 49(3), 105–109.
Bernroider, E., & Koch, S. (2001). ERP selection process in midsize and large organi-
zations. Business Process Management Journal, 7(3), 251–257.
Bingi, P., Sharma, M. K., & Godla, J. K. (1999). Critical Issues Affecting an ERP
Implementation. Information Systems Management, 16(3), 7–14.
Bogner, A., Littig, B., & Menz, W. (Eds.). (2005). Das Experteninterview: Theorie,
Methode, Anwendung (2nd ed.). Wiesbaden: VS, Verl. für Sozialwiss.
Brehm, L. (2004). Postimplementierungsphase von ERP-Systemen in Unternehmen:
organisatorische Gestaltung und kritische Erfolgsfaktoren (No. Bd. 27). Frank-
furt am Main: P. Lang.
Brehm, L., Heinzl, A., & Markus, M. L. (2001). Tailoring ERP systems: a spectrum
of choices and their implications. In System Sciences, 2001. Proceedings of the
34th Annual Hawaii International Conference on System Sciences (pp. 9–pp).
IEEE.
Chatzoglou, P., Chatzoudes, D., Fragidis, L., & Symeonidis, S. (2016, October). Crit-
ical success factors for ERP implementation in SMEs. In 2016 Federated Con-
ference on Computer Science and Information Systems (FedCSIS) (pp. 1243–
1252).
Chen, I. J. (2001). Planning for ERP systems: analysis and future trend. Business
Process Management Journal, 7(5), 374–386.
Collins, K. (1999). Strategy and execution of ERP upgrades. Government Finance
Review, 15, 43–48.

71
Columbus, L. (2014, May). Gartner’s ERP Market Share Update Shows The Future Of
Cloud ERP Is Now. Retrieved 2016-11-09, from [Link]
louiscolumbus/2014/05/12/gartners-erp-market-share-update-shows-the-future
-of-cloud-erp-is-now/
Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard
Business Review, 76(4).
Davison, R. (2002). Cultural complications of ERP. Communications of the ACM,
45(7), 109–111.
Dempsey, R. V., & Liam Sheehan, S. (2013). Justification of an upgrade of an enter-
prise resource planning (ERP) system–the accountant’s role. Global Journal of
Human-Social Science Research, 13(1).
Dezdar, S., & Sulaiman, A. (2009). Successful enterprise resource planning implemen-
tation: taxonomy of critical factors. Industrial Management & Data Systems,
109(8), 1037–1052.
Esteves, J., & Bohórquez, V. W. (2007). An updated ERP systems annotated bibli-
ography: 2001-2005. Instituto de Empresa Business School Working Paper No.
WP, 07–04.
Esteves, J., & Pastor, J. (1999). An ERP lifecycle-based research agenda. In 1st
International Workshop in Enterprise Management & Resource Planning.
Esteves, J., & Pastor, J. (2001). Enterprise resource planning systems research: an an-
notated bibliography. Communications of the Association for Information Sys-
tems, 7(1), 8.
Finney, S., & Corbett, M. (2007). ERP implementation: a compilation and analysis of
critical success factors. Business Process Management Journal, 13(3), 329–347.
Flick, U., Kardorff, E. v., & Steinke, I. (2013). Was ist qualitative Forschung? Ein-
leitung und Überblick. In U. Flick, E. v. Kardorff, & I. Steinke (Eds.), Quali-
tative Forschung: ein Handbuch (10th ed., pp. 13–29). Reinbek bei Hamburg:
Rowohlt Taschenbuch Verlag.
Gattiker, T. F., & Goodhue, D. L. (2004). Understanding the local-level costs and ben-
efits of ERP through organizational information processing theory. Information
& Management, 41(4), 431–443.

72
Haddara, M., & Elragal, A. (2013). ERP Lifecycle: A Retirement Case Study. Infor-
mation Resources Management Journal, 26(1), 1–11.
Haddara, M., & Zach, O. (2011). Erp systems in smes: A literature review. In
Proceedings of the 44th Hawaii International Conference on System Sciences
(pp. 1–10).
Hecht, S. (2014). Ein Reifegradmodell für die Bewertung und Verbesserung von
Fähigkeiten im ERP-Anwendungsmanagement. Wiesbaden: Springer Gabler.
Holland, C. P., Light, B., & Gibson, N. (1999). A critical success factors model for en-
terprise resource planning implementation. In Proceedings of the 7th European
Conference on Information Systems (Vol. 1, pp. 273–287).
IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology. IEEE
Std 610.12-1990, 1-84.
Jacob, O. (2008). ERP Value. In O. Jacob (Ed.), ERP Value: Signifikante Vorteile mit
ERP-Systemen (pp. 1–22). Berlin, Heidelberg: Springer.
Kelly, S., Holland, C., & Light, B. (1999). Enterprise resource planning: A business
approach to systems development. AMCIS 1999 Proceedings, 271.
Klaus, H., Rosemann, M., & Gable, G. G. (2000). What is ERP? Information Systems
Frontiers, 2(2), 141–162.
Kowal, S., & O’Connell, D. C. (2013). Zur Transkription von Gesprächen. In U. Flick,
E. v. Kardorff, & I. Steinke (Eds.), Qualitative Forschung: ein Handbuch (10th
ed., pp. 437–447). Reinbek bei Hamburg: Rowohlt Taschenbuch Verlag.
Kræmmergaard, P., & Rose, J. (2002). Managerial competences for ERP journeys.
Information Systems Frontiers, 4(2), 199–211.
Kuckartz, U. (2014). Qualitative Inhaltsanalyse: Methoden, Praxis, Computerunter-
stützung (2nd ed.). Weinheim Basel: Beltz Juventa.
Kuckartz, U., Dresing, T., Rädiker, S., & Stefer, C. (2008). Qualitative Evaluation:
der Einstieg in die Praxis (2nd ed.). Wiesbaden: VS, Verlag für Sozialwis-
senschaften.
Lee, J., Siau, K., & Hong, S. (2003). Enterprise Integration with ERP and EAI.
Communications of the ACM, 46(2), 54–60.

73
Markus, M. L., & Tanis, C. (2000). The enterprise systems experience - from adoption
to success. In R. W. Zmud (Ed.), Framing the Domains of IT Management : Pro-
jecting the Future Through the Past (pp. 173–207). Cincinnati, Ohio: Pinnaflex
Education Resources.
Marwan, P. (2016). Angst vor der Cloud ist Bremsklotz für weitere Digitalisierung in
KMU. Retrieved 2017-01-12, from [Link]
-der-cloud-ist-bremsklotz-fuer-weitere-digitalisierung-in-kmu/
Mayring, P. (2002). Einführung in die qualititative Sozialforschung: eine Anleitung
zu qualitativem Denken (5th ed.). Weinheim Basel: Beltz.
Mayring, P. (2010). Qualitative Inhaltsanalyse: Grundlagen und Techniken (11th ed.).
Weinheim: Beltz.
Mayring, P. (2013). Qualitative Inhaltsanalyse. In U. Flick, E. v. Kardorff, & I. Steinke
(Eds.), Qualitative Forschung: ein Handbuch (10th ed., pp. 468–475). Reinbek
bei Hamburg: Rowohlt Taschenbuch Verlag.
Mayring, P. (2014). Qualitative content analysis: theoretical foundation, basic proce-
dures and software solution. Klagenfurt.
Meinefeld, W. (2013). Hypothesen und Vorwissen in der qualitativen Sozialforschung.
In U. Flick, E. v. Kardorff, & I. Steinke (Eds.), Qualitative Forschung: ein Hand-
buch (10th ed., pp. 265–275). Reinbek bei Hamburg: Rowohlt Taschenbuch
Verlag.
Mertens, P. (2013). Integrierte Informationsverarbeitung 1. Wiesbaden: Springer.
Meuser, M., & Nagel, U. (1991). ExpertInneninterviews - vielfach erprobt, wenig
bedacht : ein Beitrag zur qualitativen Methodendiskussion. In D. Garz &
K. Kraimer (Eds.), Qualitativ-empirische Sozialforschung : Konzepte, Metho-
den, Analysen (pp. 441–471). Westdt. Verl.
Moon, Y. B. (2007). Enterprise Resource Planning (ERP): a review of the literature.
International Journal of Management and Enterprise Development, 4(3), 235–
264.
Nah, F. F.-H., & Delgado, S. (2006). Critical success factors for enterprise resource
planning implementation and upgrade. Journal of Computer Information Sys-
tems, 46(5), 99–113.

74
Nah, F. F.-H., Faja, S., & Cata, T. (2001). Characteristics of ERP software mainte-
nance: a multiple case study. Journal of Software Maintenance and Evolution:
Research and Practice, 13(6), 399–414.
Nah, F. F.-H., Lau, J.-S., & Kuang, J. (2001). Critical factors for successful imple-
mentation of enterprise systems. Business Process Management Journal, 7(3),
285–296.
Nah, F. F.-H., Zuckweiler, K. M., & Lau, J.-S. (2003). ERP implementation: chief in-
formation officers’ perceptions of critical success factors. International Journal
of Human-Computer Interaction, 16(1), 5–22.
Ng, C. S. P. (2001). A decision framework for enterprise resource planning mainte-
nance and upgrade: A client perspective. Journal of Software Maintenance and
Evolution: Research and Practice, 13(6), 431–468.
Ng, C. S. P., Gable, G., & Chan, T. (2003). An ERP maintenance model. In System Sci-
ences, 2003. Proceedings of the 36th Annual Hawaii International Conference
on (pp. 10–pp). IEEE.
Ohlson, K. (2000). Study: R/3 users face high costs for upgrades. Retrieved 2017-
02-03, from [Link]
[Link]
Olson, D. L., & Zhao, F. (2006). Critical success factors in ERP upgrade projects.
In A. M. Tjoa, L. Xu, & S. Chaudhry (Eds.), Research and Practical Issues of
Enterprise Information Systems (pp. 569–578). Boston: Springer.
Otieno, J. O. (2010). Enterprise Resource Planning Systems Implementation and Up-
grade (PhD thesis). School of Engineering and Information Sciences Middlesex
University.
Panorama Consulting. (2016). Panorama’s 2016 ERP Report. Retrieved 2017-01-14,
from [Link]
-[Link]
Rao, S. S. (2000). Enterprise resource planning: business needs and technologies.
Industrial Management & Data Systems, 100(2), 81–88.

75
Rashid, M. A., Hossain, L., & Patrick, J. D. (2002). The evolution of ERP systems:
a historical perspective. In M. A. Rashid, L. Hossain, & J. D. Patrick (Eds.),
Enterprise Resource Planning: Global Opportunities and Challenges (pp. 1–
16). IGI Global.
Ross, J. W., & Vitale, M. R. (2000). The ERP revolution: surviving vs. thriving.
Information Systems Frontiers, 2(2), 233–241.
Sahin, I., & Zahedi, F. (2001). Policy analysis for warranty, maintenance, and upgrade
of software systems. Journal of Software Maintenance and Evolution: Research
and Practice, 13(6), 469–493.
Scheckenbach, T., Zhao, F., Allard, E., Burke, J., Chiwaki, K., & Marlow, S. (2014).
Issues of ERP Upgrade in Public Sectors: A Case Study. In M. Kurosu (Ed.),
Human-Computer Interaction. Applications and Services. HCI 2014. Lecture
Notes in Computer Science (Vol. 8512, pp. 754–763). Springer International
Publishing.
Scheer, A.-W., & Habermann, F. (2000). Enterprise resource planning: making ERP a
success. Communications of the ACM, 43(4), 57–61.
Schlichter, B. R., & Kræmmergaard, P. (2010). A comprehensive literature review of
the ERP research field over a decade. Journal of Enterprise Information Man-
agement, 23(4), 486–520.
Scott, J. E., & Vessey, I. (2000). Implementing enterprise resource planning systems:
the role of learning from failure. Information Systems Frontiers, 2(2), 213–232.
Shang, S., & Seddon, P. B. (2000). A comprehensive framework for classifying the
benefits of ERP systems. AMCIS 2000 Proceedings, 39.
Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., & Seddon, P. (2000). Dif-
ferences in critical success factors in ERP systems implementation in Australia
and China: a cultural analysis. ECIS 2000 Proceedings, 53.
Shaw, N. (2001). The Impact of Software Upgrades on Individuals and Organizations:
A Longitudinal Study. AMCIS 2001 Proceedings, 329.
Skok, W., & Legge, M. (2001). Evaluating enterprise resource planning (ERP) sys-
tems using an interpretive approach. In Proceedings of the 2001 ACM SIGCPR
conference on Computer personnel research (pp. 189–197). ACM.

76
Soh, C., Kien, S. S., & Tay-Yap, J. (2000). Enterprise Resource Planning: Cultural
Fits and Misfits: Is ERP a Universal Solution? Commununications of the ACM,
43(4), 47–51.
Somers, T. M., & Nelson, K. (2001). The impact of critical success factors across
the stages of enterprise resource planning implementations. In System Sciences,
2001. Proceedings of the 34th Annual Hawaii International Conference on (pp.
10–pp). IEEE.
Somers, T. M., & Nelson, K. G. (2004). A taxonomy of players and activities across
the ERP project life cycle. Information & Management, 41(3), 257–278.
Sumner, M. (1999). Critical success factors in enterprise wide information manage-
ment systems projects. In Proceedings of the 1999 ACM SIGCPR conference on
Computer personnel research (pp. 297–303). ACM.
van Everdingen, Y., van Hillegersberg, J., & Waarts, E. (2000). Enterprise resource
planning: ERP adoption by European midsize companies. Communications of
the ACM, 43(4), 27–31.
Wallace, T. F., & Kremzar, M. H. (2001). ERP: Making it happen: The implementers’
guide to success with enterprise resource planning. New York: Wiley.
Willis, T., & Willis-Brown, A. (2002). Extending the value of ERP. Industrial Man-
agement & Data Systems, 102(1), 35–38.
Xu, H., Horn Nord, J., Brown, N., & Daryl Nord, G. (2002). Data quality issues in
implementing an ERP. Industrial Management & Data Systems, 102(1), 47–58.

77
A Interview guideline

Name: Datum & Uhrzeit:

Hallo,
ich heiße Christian Barth und schreibe im Moment an meiner Masterarbeit über „Erfolgsfaktoren
bei ERP Upgrade Projekten“ im Rahmen meines Studiums an der Johannes-Kepler-Universität Linz.
Mein Ziel ist es herauszufinden, welche Faktoren Einfluss auf den Erfolg eines ERP Upgrade
Projektes haben. Vielen Dank, dass Sie sich die Zeit nehmen und an meiner Untersuchung
teilnehmen!
Ich werde, wenn Sie zustimmen, dieses Interview aufzeichnen um es für die wissenschaftliche
Auswertung verwendbar zu machen. Es wird jedoch anonymisiert, so dass keine Rückschlüsse
möglich sind.
Wenn es für Sie in Ordnung ist und Sie keine weiteren Fragen haben würde ich jetzt gerne starten.

Hintergrund
Könnten Sie bitte einen kurzen Überblick über Ihre Person, Ihren Aufgabenbereich und Ihr
Unternehmen geben?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Wann haben Sie ihr letztes ERP Upgrade durchgeführt und wie lange dauerte dieses Projekt?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

78
Ziele
Warum wurde das Upgrade durchgeführt?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Welche Ziele wurden für Ihr Upgrade-Projekt definiert?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Erfolgsfaktoren ERP Upgrade

Welche Faktoren sind Ihrer Meinung nach kritisch für den Erfolg eines ERP Upgrade
Projektes? Warum glauben Sie, dass diese Faktoren ausschlaggebend für den Erfolg sind?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Können Sie diese nach der Wichtigkeit für ihr Projekt priorisieren?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

79
Sind während oder nach dem Upgrade-Projekt Probleme aufgetreten? Können Sie diese
Probleme beschreiben? Mit welchen Maßnahmen sind Sie diesen Problemen
entgegengetreten?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Anhand welcher Merkmale würden Sie ein Projekt als erfolgreich definieren? Wie kann man
diesen Erfolg messen?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Unterschiede zu Implementierung
Wo glauben Sie, dass die größten Unterschiede zwischen Erfolgsfaktoren bei
Implementierungsprojekten und denen bei Upgrade-Projekten liegen?

Notizen:

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

In der Literatur werden folgenden Faktoren für den Erfolg eines Implementierungsprojektes
genannt:

Bitte beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der
Skala (sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig)

Top management Unterstützung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Change management  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Business Plan and Vision  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig

80
 Projektmanagement  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
BPR & Anpassung der Software Lösung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
ERP Team Zusammensetzung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Software Testing and Fehlerbehebung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
User Training and Schulung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Erstellung eines business case  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Auswahl eines Projektchampions  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Kommunikationsplan  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Management von Legacy Systemen  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Hersteller Unterstützung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig
Post-Implementierungs Evaluierung  sehr wichtig  wichtig  weniger wichtig  gar nicht wichtig

Danke für Ihr Interview!

81
B Categorization of text passages
Category: Duration and volume of the upgrade project

Int. Par. Text passage

B 11 für das ganze Upgrade haben wir ca. 50 Tage gehabt. Also das ist im
Mai ist es losgegangen, und also 5. Mai ist es losgegangen und 20. Juni
waren wir dann fertig und sind live ...
C 4 3 Monate alleine für das Upgrade von ERP on Hana auf S4Hana ERP
F 10 es hat so ca. ein halbes Jahr gedauert.
G 8 von einem Umfang von 280 Personentagen
G 8 dann komme ich immer auf plus minus 280 Tage, was wir in der
gesamten IT dafür brauchen.
G 8 dass wir knappe zwei Monate eigentlich damit beschäftigt sind
H 5 alleine der Prozess hat alleine glaube ich bis Mai/Juni gedauert, und
dann sind wir direkt ins Upgrade Projekt gegangen und im November
sind wir online gegangen.
I 8 Die Durchlaufzeit von dem ersten Zeitpunkt wo ich dabei war, weil
die Pläne in den Köpfen der Manager, hat es wahrscheinlich früher
gegeben, bis zur wirklichen Fertigstellung war knapp 9 Monate.
I 8 Die Durchlaufzeiten waren wirklich, wir haben dann die rein technische
Durchlaufzeit, sage ich einmal, wo wir wirklich angefangen haben was
zu tun, im Sinne von, Server sind fertig, jetzt muss ich das migrieren
und so, waren 3 Monate
J 6 ahh, 1,5 Jahre und inkl. aller Voranalysen rund 800 bis 1000
Personenstunden.
K 6 vielleicht von 3 bis ca. 6 Monaten.
L 4 Durchlaufzeit ca. 1,5 Monate

82
Category: Reasons for the upgrade

Int. Par. Text passage

A 12 erstens muss man am Zug der Zeit bleiben, zweitens ist man speziell
von Microsoft getrieben und verpflichtet,
A 12 Dann werden die Softwarekomponenten, die ja zum Teil unsere waren,
Wirtschaftssoftware eigentlich von deren Herstellern auch abgekündigt
und dann lauft das auch nur mehr unter Windows 7 oder Windows 10.
B 13 es gibt ein paar so Sachen, die sind dann, die werden halt dann
freigeschalten und die wären halt super und wenn du die dann nicht
hast,
B 13 ist natürlich auch die Vorbereitung Richtung SAP HANA auch gedacht
C 6 Also einerseits Technologiegründe, neue Oberfläche anstatt getrennter
Server, getrennte Geschichten, beim letzten Mal war es das bei uns,
dass wir quasi eine In-Memory Technologie haben, wo die operativen
Systeme darauf laufen, plus wir BW, also Data Warehouse, drauf laufen
lassen, war eigentliche der Grund, dass wir ERP on Hana upgegradet
haben.
D 6 weil der ERP Hersteller irgendwann einmal eine neue Technologie auf
den Markt bringt
D 6 nur mehr für eine bestimmte Anzahl von Jahren die Wartung der alten
Technologie garantiert.
D 6 Hersteller eine neue Technologie nur auf den Markt wenn es neue An-
wendungsfelder gibt und die sind meistens durch Technologieinnova-
tionen getrieben.
E 6 dass die Aktualität der Softwareversion ausgelaufen ist. Man be-
trachte mal AX4 wurde vom Nachfolgeprodukt AX2009, AX2012,
AX2012R3, AX7, neues Branding, Dynamics AX365 mehr oder min-
der nachgefolgt oder ersetzt. Das heißt es gibt sehr viele Weiterentwick-
lungen, welche in diesem ERP nicht zur Verfügung stehen, das heißt
es müsste ein sehr großer Aufwand betrieben werden, wenn das, sag
ich einmal, in Form einer Programmerweiterung implementiert werden
würde, was wirtschaftlich nicht vertretbar ist,
E 6 das heißt wenn bei Kunden ein gewisser Druck kommt, technologisch,
organisatorisch, Änderungen vorzunehmen und auch die Software in
einem gewissen Alter ist, sag ich jetzt einmal, älter als 5 bis 7 Jahre,
dann ist es beinahe unausweichlich, den Schritt zu einem Upgrade Pro-
jekt zu machen.
E 8 Der Support als solches wird natürlich auch für sehr alte Produkte
angekündigt, dass er dann abgekündigt wird.
F 12 dass der Supportvertrag ausläuft vom Anbieter

83
F 12 die Nutzung von neuen Möglichkeiten des neuen Releases
F 12 aufgrund von solchen Migrationsprojekten, ist einfach Prozessinnova-
tion viel leichter umzusetzen, als wie bei bestehenden Systemen
G 18 SAP liefert regelmäßig HR-Hinweise aus, wo halt vor allem gesetzliche
Änderungen drinnen stecken, die Anpassungen die es halt regelmäßig
gibt, jede Steuerreform, was weiß ich, ständig gibt es Änderungen. Und
die bedingen in der Regel immer auch einen gewissen Basisreleases-
tand. Und den Basisreleasestand zu ändern, muss ich patchen
G 18 also zumindest an zweit Patches an die ich mich erinnere, die haben wir
ausschließlich gemacht, weil wir nicht mehr in der Lage gewesen wären
sonst, HR-Patches einzuspielen, weil wir den Basis-Release-Stand nicht
mehr hatten.
G 18 Eher selten ist bei uns, dass wir jetzt mit irgendeinem Releasestand jetzt
irgendwelche Funktionalitäten bekommen, die wir unbedingt brauchen,
kommt vor, aber das wäre für uns jetzt noch nicht der Grund zu patchen,
weil, wie gesagt, das Übel so groß ist, dass der Nutzen auf der anderen
Seite jetzt selten da in Relation steht.
G 20 Da ist SAP eigentlich sehr kulant, also im Verhältnis zu anderen, ja
es gibt es meistens, wie es viele Hersteller jetzt haben, haben so einen
Major-Release zurück. Und bei SAP geht oft, also, war für uns noch nie
in der Situation, ich weiß nicht wie oft andere Patchen, wir sind mit dem
einmal im Jahr eher vorne dabei. Aber wenn ich mir die Releasestände
anderer anschaue, eben in der XYZ vor allem auch Krankenhausbe-
treiber, die bei weitem nicht diesen Eigenentwicklungsstand haben wie
wir, muss man auch dazu sagen, also wir sind da sicher ganz weit vorne,
wenn nicht überhaupt top, vielleicht die XYZ noch, die sind auch fleißig
und groß und sehr inhomogen in dem was sie anbieten. Das spielt auch
mit. Wir haben sehr spezialisierte Häuser. Das heißt, nicht alle haben
den so den Stress da wie wir und die sind oft locker 2 bis 3 Jahre hinten
und sind auch noch voll supported. Also, dass man wirklich aus der
Wartung fällt, war bei uns noch kein Thema.
H 7 wir haben manche Funktionen benötigt, das heißt wir haben bestimmte
Dinge, im Bereich Dokumentenmanagement, hat sich da viel getan, und
da war die Idee, dass wir, wir haben bis jetzt ein extra Dokumenten-
managementsystem gehabt, dass wir das dann ablösen können, also
mit dem alten System haben wir einige Probleme gehabt, dass wir das
ablösen können, wenn wir eben das Dokumentenmanagement im Nav-
ision machen, das war eine der Hauptgründe.
H 7 wir haben vom CRM Schnittstellen rein, wir haben vom Sharepoint
Schnittstellen rein, wir haben ein Zeiterfassungssystem was drauf hängt
usw. Und das ist halt mit der Zeit immer schwieriger geworden, je älter
das System geworden ist.

84
 I 10 Wir haben erstens funktionale Erweiterungen, speziell im HR-Bereich
gewollt, wo das alte Release, das nicht mehr leisten konnte, was man
sich da gewünscht hat.
I 10 dass man einfach die Hardwarebasis aus zwei Gründen upgrade wollte,
erstens weil man gesagt hat, das spart Kosten, weil wir haben dazumal
noch diese UNIX-Server gehabt, die speziell in der Wartung extrem
teuer waren im Verhältnis zu den Windows-Servern damals, war die
eine Geschichte und dann bei SAP haben wir immer, die unterliegen-
den Komponenten, Betriebssysteme, Datenbanken etc., die haben ja
auch ein Ende der Wartungsdauer usw., dann wird dieses Release nicht
mehr unterstützt und da muss ich dann immer überlegen ob, wenn ich
jetzt einen Main-Release-Wechsel mache, bei der Datenbank das geht
noch mit einem Upgrade, Betriebssystem-Upgrade machen auf einem
laufenden SAP-System halte ich für verwegen
J 8 Aus technologischer, mit der Zeit gehen.
K 8 ihre Wartung letztendlich dann auslaufen lässt, das heißt wenn man nie
upgradet, passierts, dass man den Wartungsvertrag verliert
K 8 dass die Business Functions sozusagen verfügbar sind, dass man sie
dann jederzeit aktivieren kann,
L 6 OS+DB Upgrades standen auch am Plan (Ende Support)

Category: Objectives of the upgrade project

Int. Par. Text passage

B 15 Da sind, dass wieder alles so funktioniert wie vorher.
B 17 Das Ziel ist natürlich dann diese Features im Endeffekt dann zu nutzen,
und schauen, dass man das dann nicht mehr mit Workarounds, sondern
eben im Standard dann auch verwenden kann.
C 8 Es soll im Endeffekt die Schulungsumgebung, die wir hatten, also die
gesamte Funktionalität, das ist von Logistik Prozessen bis hin zu einer
Bilanz und einer G & V und einer Erlösrechnung, sollte danach wieder
funktionieren
C 8 auch die Möglichkeit, mit der neuen Oberfläche, ebenfalls zu arbeiten,
wir haben einige Unis die wollen mit der neuen Oberfläche, das auspro-
bieren, also das zu ermöglichen.
C 26 bei einem Upgrade Projekt will ich einmal dass alles wieder so läuft wie
es vorher auch war.
D 8 die alten Funktionen sollten zumindest wieder funktionieren,

85
D 8 vernünftige Firmen machen das so, dass sie gleichzeitig auch schauen,
was gibt die neue Technologie her und wie können wir unsere Anwen-
dungen auch ändern. Oft passiert, dass halt dann erst im Lauf der Zeit,
das heißt in der ersten Phase schaut man erst einmal, dass man das Alte
einmal zusammenbringt und beginnt man die neuen Sachen zu nutzen.
E 10 Letztendlich geht es überall um die Wirtschaftlichkeit und auch darum
in gewissen Belange schneller zu werden. Das heißt es gibt nach wie vor
in Unternehmen manuelle Schnittstellen, Papierschnittstellen, das heißt
derartige Prozesse aufzuräumen, in Verbindung mit Dokumentenman-
agementsystemen, mit Workflow, mit elektronischen Datenaustausch,
was heute das ganze Supply-Chain anlangt, wird immer wichtiger.
Also, Prozesse im Tagesgeschäft elektronisch zu unterstützen, das ist
gewisser Leistungsdruck an die Unternehmen und wenn man eben auch
die Wirtschaftlichkeit betrachtet, ist es eben ein Nachteil Mitbewerbern
gegenüber, wenn man hier nachhinkt, sag ich einmal, höheren Person-
alaufwand hat, langsam ist teilweise dadurch, wenn gewisse Verrich-
tungen manuell erledigt werden müssen, und das drängt einfach auch
Unternehmen, sag ich jetzt einmal, am Fokus zu bleiben, was derzeit
technologisch möglich ist.
G 10 Wir haben wie gesagt 7 Krankenhäuser und davon ein Krankenhaus,
das Akuthaus in Ried, Regionalspital, Barmherzige Schwestern Ried,
die ein Unfallspital sind. Das heißt die haben 7 mal 24 Betrieb, für
die schmerzt jede Stunde, die bekommen rund um die Uhr die Patienten
rein und können quasi ohne SAP nicht mal eine Aufnahme machen. Das
heißt wir sind von daher natürlich, ist die ganze Near-Zero-Downtime-
Thematik eine große, ja. Zumindest die Downtime möglichst gering zu
halten.
G 24 Also der Zielreleasestand EHP 7, Stack 12 ist implementiert.
G 24 Zweitens, das SAP System läuft nach dem Upgrade ohne negative
Auswirkungen auf den laufenden Betrieb und dessen Performance.
Also es darf eigentlich nachher zumindest aus der reinen Betriebssicht
nichts schlechter sein, als vorher.
G 24 Also da ist ganz klar das Ziel, wir wollen patchen, wir wollen nachher
den neuen Releasestand haben, fertig. System soll so laufen wie vorher.
Ende. Alles andere wird gesondert gemacht.
G 24 Genau, dann, die mit der Umstellung einhergehenden Down-Time des
Systems überschreitet 18 Stunden nicht. Das ist das Zeitlimit.
G 24 Und ein NoNa-Ziel, mit der Umstellung wird das Potential für neue
Funktionalitäten gelegt. Also, dass man genau da diese funktionalen
Erweiterungen, die kommen auch, dafür die Voraussetzungen schafft.
G 24 Und als Nicht-Ziel. Funktionale Erweiterungen, die der neue Release-
Stand ermöglicht werden gesondert implementiert.

86
H 9 das Hauptziel war ganz pragmatisch, das Upgrade zu machen, ohne dass
der Arbeiter Finanz und die anderen Mitarbeiter, wir haben Bestellun-
gen drinnen, wir haben die Webpreise drinnen, wir haben die Zeiter-
fassung drinnen, dass die möglichst wenig gestört ist. Also möglichst,
ohne Unterbrechungen, ist natürlich Grundvoraussetzung, ohne Daten-
verlust, aber dass das auch ohne Unterbrechung weiterläuft.
H 9 die Nebenziele waren die eben zusätzlichen Funktionalitäten, die ich
zuerst erwähnt habe.
I 14 Ein Teil war die neue Funktionalität die danach nutzbar sein musste
I 14 Kostensenkung in punkto Hardwarewartung, also sprich laufende
Kosten weil ich muss das ja immer bezahlen und es war, dass man sagt,
ich habe jetzt wieder eine sichere Plattform auf der ich jetzt die näch-
sten, weiß ich nicht wie viele Jahre, einfach weiterarbeiten kann und
nicht fürchten muss, dass mein Betriebssystem nicht mehr unterstützt
wird, dass meine Datenbank nicht mehr unterstützt wird,
I 14 Es war nicht so, dass man jetzt sagt, ich will jetzt wirklich einen mess-
baren, also den messbaren Benefit, abgesehen von der IT-Wartung, der
wurde zumindest nicht definiert, weil erstens ist messen in diesem Bere-
ich immer sehr schwierig, weil Kosten kann ich messen, aber ob der
Anwender jetzt nachher schneller ist, nach dem Upgrade oder nicht,
wie messe ich das, und gerade bei einem Buchhalter sowieso nicht, weil
wenn der seinen Beleg bucht, der muss vorher gleich viel eingeben, wie
nachher. Da ist auch kein Performancegewinn oder so, das ist alles ir-
relevant in der Sache
I 14 Es gibt andere Sachen, gerade in Deutschland zum Beispiel, viele, mit-
tlerweile werden es immer mehr, automatisierte Kommunikation mit
den Behörden, wo ich sage, denen muss ich meine Lohnsteuerbelege
übermitteln, damit das korrekt abgerechnet wird, und, und, und. Das
war auch eins der Ziele, dass das einfacher wird. Das war mit dem alten
Release, ein bisschen, nun ja, es ist gegangen aber man hat halt ein biss-
chen mit der Kirche ums Kreuz arbeiten müssen und das hat sich schon
stark vereinfacht, allerdings, das war nicht das Ende der Entwicklung,
das ist natürlich ein laufender Prozess.
J 10 Dass die Performance nicht schlechter ist, als die die wir vorher hatten
und dass wir wieder alle Applikationen innerhalb des ERP sauber zum
laufen bringen
K 10 die Software auf eine höhere Version zu heben und die stabil produktiv
zu stellen letztendlich.
K 10 ist das wichtigste, Sicherheit, Stabilität und Fehlerfreiheit,
K 14 was will man sicher stellen, dass die die neue Software so funktioniert,
wie die alte Software.

87
 K 18 Schlechter sollte die Performance nicht werden und fachlich muss
natürlich auch das richtige rauskommen.
K 18 Was man natürlich auch bei Upgrade-Projekten nutzen sollte und da
ist man natürlich auch in einer Mischung aus Change- und Upgrade-
Projekten, man muss halt auch beleuchten, wenn sozusagen SAP etwas
ausliefert was sie bisher noch gar nicht gehabt haben, der Kunde aber
sozusagen was eigenen gebaut hat, dann sollte man natürlich die Chance
nützen, quasi von diesen kundeneigenen Funktionalitäten auf die Stan-
dardfunktionalitäten umzusteigen
L 8 Dokumentation der Tests, Tests mit Fachbereichen + KeyUsern, KEINE
Umstellung ohne Freigabe aller Bereiche, Zielarchitektur: EHP7

Category: Definition of success

Int. Par. Text passage

B 27 Wochenende das System dann upgegradet hast, dass dann am
nächsten Tag dann ganz normal weiterarbeitest ohne irgendwelche
Zwischenfälle.
B 28 System muss laufen, das ist ganz klar. Wenn irgendetwas nicht geht,
dann haben wir das Problem.
C 24 In Zeit, in Budget, in der Funktionalität!
G 37 Zielerreichung in erster Linie, soweit es quantifizierbar ist, ist ganz klar,
Vergleich System vorher nachher, vor allem Performance. Funktional-
ität, Umstellung selber, Down-Time, also, das ist für mich eigentlich
das wichtigste.
H 21 würde ich jetzt keinen Unterschied sehen, obwohl, Zeit ist vielleicht bei
einem Upgrade-Projekt nicht ganz so kritisch, wie bei anderen Projek-
ten, wenn ich eine Neueinführung mache.
H 21 Also, die Zeit ist vielleicht weniger kritisch wie in anderen Projekten,
aber natürlich Kosten, klar und Funktionalitäten ist auch klar.
I 36 Wie es bei uns war, einerseits wir wollen alles so machen wie vorher
plus das Neue machen können. Dann muss ich sagen, wann ist es erfol-
greich, wenn die funktionalen Tests erfolgreich sind, sprich, ich schaue
an, was habe ich vorher gemacht, geht das noch genauso gut, schnell,
vielleicht hat sich eine Maske ein bisschen verändert, kann natürlich
sein, aber rein von der Sache her gleich gut.
I 36 kann ich auf die neuen Features zugreifen, auch wenn ich die jetzt noch
nicht ultimativ nutzen kann, weil durch das Upgrade habe ich jetzt ein-
mal die Basis geschaffen.

88
 I 36 Dann habe ich meine Termine eingehalten, das gehört zum Erfolg von
einem Projekt dazu, habe ich meine Kosten eingehalten. Wobei Termin
und Kosten ist leicht zu messen, ja, da habe ich unter dem Strich, ich
zähle zusammen, und sage ja, ich war fertig zu diesem Termin, gekostet
hat es mich das.
I 36 Spannend wird es bei den funktionalen Tests, auch nicht bei den alten
Sachen sondern von den Neuen. Weil da kann es auch, wir haben einen
Fall gehabt, da haben wir etwas erwartet, was wir dann erst nicht gehabt
haben. Sagen wir einmal so. Was aber daran lag, dass die Anforderer
das falsch gelesen haben oder einem Verkäufer zuviel zugehört haben,
das kann man jetzt sehen wie man will. Der hat ihnen das versprochen
und gesagt mit diesem Release geht das und es ist trotzdem nicht gegan-
gen. Zumindest nicht ohne ein Zusatzpaket, dass man extra erwerben
hat müssen. Aber das war jetzt nicht das Problem des Upgrade-Projekts,
das war das Problem der Erwartungshaltung.
J 22 Ich glaube es ist erfolgreich, wenn du halbwegs in der Zeit geblieben
bist und wenn das Unternehmen danach funktioniert. Dann bist du er-
folgreich gewesen.
K 18 nachher so funktionieren wie vorher, sprich, fachlich so sein wie vorher,
das heißt das fachliche Ergebnis muss das gleiche sein, oder was auch
immer wichtig darauf zu achten, ist die Performance,
L 16 Einhalten von Zeitrahmen + Kostenrahmen, hohe Akzeptanz +
Zufriedenheit der Enduser (Performance-Steigerung, Verfügbarkeit),
wenig bis keine betriebs-einschränkenden Probleme oder Stillstände
nach Umstellung.

Category: Success factor - Project management, project manager &

project evaluation

Int. Par. Text passage

A 16 Okay, wir machen bei jedem Projekt ein Review, es gibt Soll-Vorgaben
von den Stunden, eine geschätzte Vorgabe, den vergleicht man natürlich
zum Ist-Aufwand und das muss von den Anwendern im Wesentlichen
finanziert werden.
A 37 Interviewer: Projektmanagement Interviewter A: Projektmanagement
ist ganz wichtig. Das irgendwer die ganzen Zyklen in der Hand hat und
die Termine vorgibt.
A 55 Habe ich eh schon vorher erwähnt, finde ich sehr wichtig. bei den Re-
views ist bei uns wichtig gewesen, hat es Probleme gegeben und auch
kostenseitig. Wie viele Mannstunden wurden geplant, wie viele sind es
dann geworden.

89
C 10 Einen heftigen internen Projektmanger, der sich auch mit den Prozessen
auskennt.
D 15 Ja und, dass auch das Projektmanagement was versteht davon, von dem
Projekt und nicht sagt, das macht nur die EDV.
D 17 dass man für neue Technologien neues Personal braucht. Das ist eine
neue IBM Weisheit, also zum Beispiel frische Absolventen, die mit
einem anderen Blickwinkel die Sachen anschauen, ist vielleicht auch
nicht schlecht, dass man diese ins Projekt nimmt.
E 12 Zum Einen muss man auch die Prozesse kennen, um die auch einmal
in einem neuen System zu designen und man muss sich selbst, dann
gewisse Dinge in Frage stellen. Ist es notwendig, ist es wirtschaftlich
vertretbar gewisse Dinge in ein System zu implementieren, sei es jetzt
aus Befindlichkeiten oder weil man das Jahre oder immer so gemacht
hat. Das heißt man muss durchaus Fragepunkte sich selbst stellen, ob
das vertretbar ist, ob das sinnvoll ist, in ein System überhaupt zu inte-
grieren, in der Form oder in der Wunschform wie das vielleicht Key-
User oder Prozess-Owner vielleicht haben, das heißt, da muss man
gemeinsam einfach schauen, das Optimum für das Projekt und für die
nachfolgende Phase, sag ich jetzt einmal, zu implementieren. Die Er-
fahrung hat gezeigt, dass teils Prozesse implementiert werden, die in
Folge dann sehr wenig, sehr selten genutzt werden und deren Imple-
mentierung viel Geld gekostet hat. Das ist ein kritischer, man kann das
sehr viel Zeit verlieren, sehr viel Geld investieren, man muss dann noch
einmal zurück, bis zu einem gewissen Punkt hat das gepasst, da hat
man sich dann verloren oder auf dem aufsetzend, muss man das ganze
dann noch einmal redesignen, irgendwelche Vorstellungen, wenn solche
Vorstellungen von Key-Usern oder Prozess-Ownern ohne Prüfung der
Sinnhaftigkeit dann in ein System implementiert werden, das sind sehr
sehr kritische Erfolgsfaktoren.
E 12 Und ein weiterer ist die Zusammenarbeit des Projektteams auf der Kun-
denseite, als auch auf der Dienstleister oder Lieferantenseite, das man
offen mit dem umgeht, dass man die Ziele im Fokus behaltet, Befind-
lichkeiten zur Seite legt.
E 50 Das muss man regelmäßig machen, es gibt bei uns je nach Umfang des
Projektes in einmonatig oder zweimonatigen Abständen Lenkungsauss-
chüsse, wo dieser Part aufgearbeitet wird auch dargestellt wird und
sofort reagiert wird. Das heißt auch intern, XYZ intern, wird das
besprochen und im Lenkungsausschuss auch, wenn etwas gut oder
schlecht gelaufen ist, Verbesserungspotential sollte sich nicht anstauen
bis ans Ende des Projektes, sondern wenn das erkannt wird, man macht
ja auch eine Risikobewertung, wenn da Risikofaktoren auftauchen,
sollte das eigentlich ein kontinuierlicher Prozess sein. Zumindestens
zyklisch.

90
F 20 mit wirklichem klassischen, sag ich jetzt mal, Projektmanagement,
F 20 dass man auch ganz klare Ziele und einen Nutzen festlegt, weil das
größte Thema ist, dass in Projekten, das sage ich jetzt einmal so als
Consulter komplett neutral, es wird einfach viel zu wenig der Nutzen
definiert, was soll denn eigentlich der Nutzen sein dieses ERP Sys-
tems, bei diesem Projekt. Beispiel jetzt, zurück zu kommen auf ein
ERP Migrationsprojekt, zu sagen, das Ziel ist es auf das neueste Re-
lease des ERP Herstellers zu migrieren, das ist noch kein Ziel, das ist
kein Nutzen.
F 22 dass man das nicht nur am Ende des Projektes misst, sondern auch 1
Jahr, 3 Jahre oder 5 Jahre danach, weil das sage ich jetzt einmal, das
macht im Prinzip fast überhaupt niemand.
G 8 Das kann ich Ihnen ganz genau sagen, wir machen das, also bei uns
ist ein Patch immer ein Projekt. Jetzt kann man sagen, ein Projekt ist
eigentlich normalerweise keine wiederkehrende Tätigkeit, aber es ist ja
nur ein Merkmal für ein Projekt, sondern auch die Kritikalität, ich mein
es ist ja unser Herz, SAP, das sind 7 Krankenhäuser und ein Haufen Fir-
men die da dranhängen, die da darauf fahren, also wenn das nicht läuft,
dann dampft es, dann haben wir wirklich ein Problem. Und alleine aus
dieser Kritikalität her, machen wir das immer als Projekt. Das heißt, das
ist ein gemanagtes Projekt, mit einem entsprechenden Auftrag, Zeit-
plan, Projektstrukturplan, Projektcontrolling, alles. Also da fahren wir
die ganze Maschine auf und wir sprechen da immerhin auch von einem
Umfang von 280 Personentagen, die wir eigentlich regelmäßig immer
haben, das ist interessant.
G 25 Das erste ist ein Mal, steckt ja schon in der Frage drinnen, Pro-
jekt. Ich würde es, wie ich eingangs auch gesagt habe, das ist eine
wiederkehrende Tätigkeit, stimmt schon, aber es liegen trotzdem Jahre,
liegen in der Regel dazwischen. Das heißt, das wirklich als Projekt
abzuwickeln. Da habe ich auch den großen Vorteil, wenn ich das
gescheit strukturiert abwickle, ich kann mir auch vor Beginn noch ein-
mal das letzte Projekt anschauen und mittlerweile haben wir da so eine
Routine, das ist ein Template, wenn ich sage ich patche, ich weiß ganz
genau was ich tue. Wo schiebe ich das hin, ich weiß was es heißt.
G 25 auch wie gesagt, als Projekt abwickeln. Also wirklich mit einem Pro-
jektmanager, der sich darum kümmert und nicht nur jetzt quasi so als
technisch, mache ich nebenher, macht die IT nebenher. Zumindest in
den Dimensionen wo wir uns bewegen.
G 49 Interviewer: Projektmanagement Interviewter G: Ja sehr wichtig, bin
ich ein absoluter Fan davon.

91
G 69 Interviewer: Post-Implementierungs-Evaluierung Interviewter G: Wir
haben normalerweise nach einem Patch eine Woche, das ist jetzt auch
noch im Projektplan abgedeckt, zumindest eine Woche Systembeobach-
tung, teilweise werden gezielte Tests gefahren im Vorher, Nachher-
Vergleich, wo wir wissen wie sich das verhält, welche Durchlaufzeiten,
und welche Reaktionszeiten man da hat. Und, ja dann kommen im-
mer erste Meldungen von Usern, weil die natürlich auch sensibilisiert
sind, die wissen, da ist jetzt was gemacht worden. Dann fallen teil-
weise Sachen auf, die immer schon so waren, teilweise auch wo sie was
verändert hat. Also normalerweise würde ich da ein bis zwei Wochen
rechnen, Nachphase, bevor man von Projektseite den Projektabschluss
macht.
H 13 je genauer ich zu Beginn spezifiziere, was brauche ich wirklich, was
muss sein, was darf sein, also was sind Pflichtfaktoren, was ist Nice-to-
have
H 15 Spezifikation
H 19 Kritisch ist sicher, wie bei jedem Projekt, dass jemand da ist, der die
Entscheidungen schnell trifft, richtig trifft, ich mein richtig, ja, oft gibt
es eh kein richtig und kein falsch, aber dass die Entscheidungen zumin-
dest getroffen sind und das Ganze dann schnell korrigiert werden kann,
damit man vorwärts kommt und nicht zurückrudert. Es braucht halt
oft Entscheidungsträger, dass die zur Verfügung stehen zum richtigen
Zeitpunkt.
I 20 Das Wichtigste ist das, dass ich es gescheit plane, sind wir uns ehrlich,
also einen gescheiten Plan und jetzt nicht, wo ich sage, an dem Tag
mache ich das, sondern, welche Schritte brauche ich, wer macht was,
was tue ich, wenn was in die Hose geht, was ja auch immer ist, also
diese ganzen Fallback-Szenarien, die darf man nie vergessen, man hofft
zwar, dass man nie hinkommt, aber, dass ist wie, ich zahle ja auch eine
Versicherung für mein Auto und hoffe trotzdem, dass ich keinen Unfall
habe. Das ist genau das gleiche. Ich muss einfach präpariert sein, für
alle Eventualitäten, was tue ich. Das ist für mich das aller wichtigste.
I 80 Interviewer: Post-Implementation-Evaluation Interviewter I: Ja natür-
lich muss ich nachher evaluieren. Wie schaut die Zufriedenheit aus?
Wie schaut es mit meinen erwarteten funktionalen Erweiterungen aus?
Das ist wichtig, aber ich kann eh nicht mehr zurück. Also ein Down-
grade, letztendlich ist das für mich was, wo ich sage, wenn ich vorher
in der Planung alles richtig gemacht habe, dann schaue ich zwar nach,
ob das wirklich geht und ob ich meine persönliche Erwartungshaltung,
weil über das haben wir vorher diskutiert, ob ich die erfüllen kann oder
auch die, die der Hersteller in mir berechtigt erzeugt hat, erfüllen kann.
Aber alles andere, ist, ja, ich muss natürlich schauen wie geht es den
Leuten damit.

92
 J 12 Erstens der Projektleiter, Zweitens der Projektleiter und Drittens der
Projektleiter. Ahm, nein Spaß ohne. Ich glaube, dass die Projek-
tleitung ganz ein wesentlicher Erfolgsfaktor ist, ich erwarte mir von
einem Projektleiter nicht nur, dass dieser mit Kollegen spricht, Meilen-
steine einfordert, sondern der muss zu jeder Tages- und Nachtzeit, muss
ich den aufwecken können und der muss wissen wo jedes einzelne Ar-
beitspaket steht und muss auch die Dinge kompensieren, die unterhalb
der Arbeitspaket-Teilprojektleiterebene nicht funktionieren.

Category: Success factor - External support

Int. Par. Text passage

B 21 hat der oft einmal nicht gewusst, was ist jetzt neu, oder sie haben jetzt
in dieser Tiefe sich auch noch nicht beschäftigt damit, muss man auch
dazu sagen. Der eine ein bisschen mehr, der andere sagt ja, phu, er
hat das Feature schon einmal gehabt bei einem Kunden, und das hat er
schon mal gehört aber es ist dann trotzdem.
B 23 Wir hätten uns ein bisschen mehr erwartet, muss man schon sagen. Aber
das, ahh, da da haben wir dann, da muss man sich einfach ein bisschen
durch die Dokumentation auch durcharbeiten. Also es gibt gottseidank
SAP Dokumente zum, wo du, wo dann drinnen steht ok, mit diesem
EHP Upgrade bekommst du jetzt die Features dazu, da muss man sich
das halt dann in der Doku ein bisschen anschauen, und dann herausfis-
chen, was wäre denn interessant, oder wo könnte man welchen Prozess
da vielleicht auch draufsetzen.
D 47 Ja, das ist immer wichtig, wobei es nicht nur auf den Hersteller drauf
an kommt, die Meisten haben ja auch Implementierungspartner und
es nützt nichts, wenn Sie eine super Software haben und der Imple-
mentierungspartner versteht Ihr Geschäft nicht, genau, die Beiden sind
natürlich, wobei letzteres sehr wichtig ist, also irgendwelchen technis-
chen Spielereien sind oft nicht so wichtig, wie, dass der versteht über-
haupt, was macht die Firma, auf was kommt es drauf an, wie funktion-
ieren die Prozesse, ahh, das ist glaube ich sehr entscheidend für so ein
Projekt. Dass man auch einen Partner findet, der einen auch versteht
und nicht der irgendein Technikfuzi ist oder der keine Erfahrung hat.
F 16 also beim Consulting muss man es wieder trennen, das eine ist der
Erfolgsfaktor des Consultants, des ERP Herstellers oder Implemen-
tierungspartners, und das andere ist noch der Erfolgsfaktor, wenn ich
jetzt einen neutralen Consultant, wie zum Beispiel die XYZ mitein-
beziehe. Ganz klar natürlich.
G 27 wir haben für den SPAU, also für den Objektabgleich haben wir an sich
immer Ressourcen vorgesehen die uns unterstützen, also vor allem im
HR haben wir das.

93
G 27 Also der wesentliche Beratungsaufwand, den wir haben ist Fehlerbe-
seitigung. Teilweise auch Fehler im Standard, kommt auch vor. Oder,
dass sich irgendwelche Entwicklungen aus der Vergangenheit mit dem
Releasestand nicht mehr so funktionieren. Das gibt es fast immer.
Meistens nur bei irgendwelchen Kleinigkeiten, selten auch gröbere
Geschichte
G 27 Weil man kann sich auch da im Vorfeld ein bisschen, wenn andere auf
dem Releasestand sind, kann man andere Betreiber, wie gesagt, wir sind
gut vernetzt, mal fragen, wie ist es euch dabei gegangen. War es eher
leicht oder eher schwierig? Da habe ich im Vorfeld nur Gutes gehört
jetzt von dem Releasestand, und, wir sind deutlich drunter geblieben.
Aber wie gesagt, ich habe da eher einen Posten Risikobudget, weil ich
es vorher einfach nicht weiß. Es kann irgendein, man kann sich irgen-
detwas eindrehen, wo man dann eine Woche Entwicklung dran hat, das
zu korrigieren oder auch nicht, weiß man im Vorfeld nicht.
G 29 Also ich muss mir die Ressourcen sichern, das heißt wir haben Bere-
itschaften, externe, das heißt ich muss alle Partner informieren, ja, und
in den kritischen Bereich muss ich mir die Ressourcen auch sichern.
Also, wir haben das sowohl bei der SAP selbst, wir sind Max Atten-
tion Kunde, das ist im Prinzip so ein erweiterter Service Level, und wir
haben vor allem beim Produktivgang immer SAP in Bereitschaft, also
nicht nur, wie haben sowieso als Kunde 7 mal 24, aber da haben wir
wirklich auch einen Bereitschaftsarbeitenden der unser System kennt
und der wirklich Gewehr bei Fuß steht. Das haben wir auch klinischen
System, einfach zur Risikominimierung. Da haben wir Bereitschaften
für den eigentlichen Produktivgang oder wenn wir am Sonntag am Vor-
mittag dann am Produktivsystem dann draufkommen, dass wir irgen-
detwas übersehen haben, war noch nie der Fall, haben wir noch nie
gebraucht, aber trotzdem muss man das haben.
H 13 Dann im Endeffekt, führen wir das nicht selbst durch, das heißt die
Dienstleisterauswahl ist auch sehr elementar, wenn ich den falschen Di-
enstleister habe, ich bin nur so gut, wie der Dienstleister das macht, das
heißt den kann ich dann nur begleiten, aber wenn der das nicht schafft
oder wenn der zeitlich nicht zusammenkommt, dann kann ich auch nix
machen, aber das ist auch relativ in der Anfangsphase
H 17 Das ist dann eher der Dienstleister, der setzt auch gleichzeitig um, das
ist der, der umsetzt und natürlich

94
H 19 Ja, beim Dienstleister, da haben wir einen Ansprechpartnerwechsel
gehabt, das war auch ein bisschen kritisch, der Eine ist weggegangen
während dem Projekt, quasi unser Hauptverantwortlicher, und der neue
ist gekommen und da haben wir Gott sei Dank sehr viel Wissen da
gehabt, das halt wir dann weiter geben konnten, weil wenn das jetzt
die Finanzabteilung ohne IT gemacht hätte, dann wär das wirklich ein
Problem geworden, aber so haben wir halt dann, also mein Projektman-
ager arbeitet ja schon jahrelange mit dem System, und der hat den dann
sehr gecoacht den Neuen.
I 8 externe Ressourcen rekrutiert man, weil bei viel Dingen, da kann man
intern das Know-How gar nicht aufbauen, weil das lohnt sich nicht,
weil das brauche ich einmal, das brauche ich einmal und die machen
das öfter, die haben mehr Erfahrung, und undund, also wir haben dann,
eine Basisberatung, eine Applikationsberatung gehabt und wir haben
sie immer noch, ja weil das ist ja nicht so, wenn das Upgrade-Projekt,
ich pflege ja längerfristige, auch, Lieferantenbeziehungen, sage ich in
diesem Fall, wenn ich mit jemanden zufrieden bin und einmal ein
Großprojekt mit ihm gemacht habe, dann mache ich die kleinen Sachen
auch mit ihm, dadurch halt ich ihn ""jour"" was die Konfigurationen
betrifft, was die Anforderungen betrifft und wenn ich ihn das nächste
Mal habe, dann muss ich nicht bei Adam und Eva anfangen ihm was zu
erklären. Also den Basisberater, den wir damals neu engagiert haben,
kurz vorher, der arbeitet immer noch mit mir zusammen,"
I 24 Wenn ich es mir leiste, dass ich mir das intern aufbaue, komme ich
auch ohne aus. Aber es ist erstens wirtschaftlich nicht sinnvoll und
zweitens, wie soll ich sagen, sogar wenn ich das Know-How habe aber
ich habe es noch nie praktisch angewendet, das ist das, das schaffe ich
nicht, weil ich mache es nur einmal. Und das erwarte ich von einem
Externen, dass er sagt, ja das habe ich bei der Firma schon gemacht
und bei der und bei der, und dann weis ich, ahh, und dort waren die
Probleme und dort waren die, dann weis ich, ahh, der weiß wie man
die umschifft und wenn bei uns welche sind, dann erwarte ich von ihm,
dass er uns da zumindest unterstützt, wenn sie technischer Natur sind,
ich mein organisatorisch müssen wir eh selber schaffen.
I 24 Aber es ist weder kosteneffizient, noch, weil ich muss ja meine Vor-
laufzeit verlängern, weil ich muss ja das Know-How vorher aufbauen.
Ich muss die Leute, während sie das Know-How aufbauen, vernachläs-
sigen sie was Anderes. Die sind ja nicht da und warten, dass sie eine
Arbeit bekommen, die haben ja was zu tun, die sind ja beschäftigt. Das
heißt das wird schwierig und eigentlich, aus meiner Erfahrung, leistet
sich das eine Firma nicht mehr, ganz egal wie groß die ist. Ein Jeder
sagt, da gibt es Experten am Markt, die hole ich mir, die kosten zwar
was, ja, aber es kommt mir unterm Strich gesehen wahrscheinlich im-
mer noch billiger, also wie wenn ich das selber mache.

95
J 12 hier ist die Erfahrung von erfahrenen Beratern, die hier unterstützen
können
J 14 Also die Erfahrung lehrt, dass es ohne externe Berater nicht geht,
warum, weil üblicherweise in Unternehmen nicht Menschen herum-
sitzen, die den ganzen Tag nichts zu tun haben nur drauf warten, dass
man so ein riesiges Projekt stemmt.
J 14 Und, ahm, kein Unternehmen hat heute noch den Speck, sich solche
Ressourcen zu leisten, die permanent da sind, aber nicht ausgelastet
sind, das heißt, das große Problem ist immer, dass du eigentlich
während des laufenden Geschäftes des Unternehmens praktisch die
Prozesse oder die Systeme umdrehen musst. Das heißt, du musst Men-
schen aus dem Tagesgeschäft rausreißen, dass sie Prozesse designen,
musst aufpassen, dass dir die nicht over-engineeren oder sich das rein-
wünschen, was immer sie schon gerne gehabt hätten, aber nie funk-
tioniert hat, bei den alten Systemen, ahm, und das Doing machen dann
Externe, normalerweise, weil du, teilweise oder ganz Externe, weil du
einfach die Manpower brauchst und das geht von externen Beratern
J 14 bis hin zu Studenten, in fast allen meinen Projekten, war es so, dass
wir dann Studenten oder so irgend etwas, Berufspraktikanten, engagiert
haben, die zum Beispiel Datenbereinigung machen
K 14 die Qualität der Berater extrem wichtig, wir müssen quasi fehlerfrei
arbeiten, wir müssen wissen was wir tun, wir müssen eben im Vorfeld
schon Fehler vermeiden, wir müssen wissen wenn wir am System was
ändern wir, was kann das für Konsequenzen haben, was kann das für
Risiken haben, die dann quasi auch beim Kunden aufzeigen.
K 14 die Beratungskompetenz ist wichtiger, wenn man wirklich Änderungen
am System vornimmt, sprich, ahhm, man führt neue Funktionalitäten
ein oder man so eine Grundeinführung dieser Produkte,
K 50 Interviewer: Herstellerunterstützung, in dem Sinne vom Software-
hersteller Interviewter K: Ja, kann man sagen nicht unwichtig, es ist
natürlich auch so, es hängt auch immer davon ab, wie große Sprünge
man macht und auf welche Version man bei SAP steigt, weil SAP ist
auch nicht perfekt, und die haben genug Fehler auch in der Software,
und dann würd ich dann gerade beim Release-Upgrade schon als sehr
wichtig beurteilen.

96
Category: Success factor - ERP team

Int. Par. Text passage

B 25 Früh, zu Mittag und am Abend, haben wir, haben wir uns getroffen,
d.h. das war das Kernteam mit ca. 10 Leuten, also das sind so die
Haupt-, Kernuser gewesen, die wir da dabeigehabt haben. Ahhh und
haben uns dann immer abgestimmt, ob es irgendwo Probleme gegeben
hat, wo Probleme aufgetretenen sind, ahh haben dann, ahh, im bei uns,
wir haben das über den Sharepoint gemacht, haben dann im Sharepoint
das dann auch mitprotokolliert, wann zum Beispiel ein Prozess nicht
funktioniert hat, dass dann sofort die Modulbetreuer, unsere internen
SAP Betreuer, dass sie diese Themen gleich anschauen, kontrollieren,
prüfen, Programmänderungen dann machen und das dann rückmelden.
B 50 Also wir heben da nie so wirklich wen explizit hervor, ahh, da ist, da
geht es eher darum, dass wir, wir haben eine Projektabschlussfeier dann
gehabt, wo wir dann, das haben wir bei der Projekteinführung schon
gehabt, haben groß Eis eingekauft beim ahh Eishändler und haben dann
eine große Eisparty unter Anführungszeichen gemacht. Es ist aber da
auch genauso nochmal die Geschäftsführung gekommen und hat sich
auch bedankt für die Einführungsunterstützung, weil ja trotzdem in
diesem Zeitraum diese zwei Wochen dort, werden einfach sehr viele
Personen aus der, aus dem aktiven, ahh aus der aktiven Arbeit her-
ausgenommen und stehen eigentlich nur zu dem Zeitpunkt für die Inte-
grationstests zur Verfügung.
C 10 die IT-Mannschaft, und das ist eigentlich für den Betrieb so eines Sys-
tems wesentlich, da Stefan ist so an der Schnittstelle zwischen Prozesse
kennen, aber auch noch wissen, wie man upgradet, der Kollege der da
hin und her wechselt, der kenn sich nur mit Upgrades aus, der ist dort
gestanden und hat nicht gewusst, wenn ein Problem war, was passiert.
C 10 inhaltliche Kompetenz plus Upgrade-Kompetenz im gleichen Team ist,
sonst hätten Sie quasi vier Abteilungen die Logistik machen, eine
Abteilung die FIBU macht, eine Abteilung die KORE macht, jetzt
müssen Sie andauernd die Leute quälen, was bedeutet, den das für
Sie, ich hab jetzt zum Beispiel, alle FIBU Konten mussten angereichert
werden.
G 33 Wenn der das nicht hat, wir haben in der Basis Experten, wir haben es in
allen Modulen, also das ist eigentlich schon Routine. Also wenn Sie da
jetzt irgendjemanden am Gang ansprechen und sagen Patch, dann wird
der wissen von was Sie reden und was das für ihn bedeutet.

97
 I 22 ich muss das Team richtig zusammensetzen, schon von der Konzeption-
sphase, weil ich kann Leute haben, wie sage ich das am besten, es gibt
Leute die sind in ihrem Fachbereich super, aber sie können nicht pro-
jektorientiert denken, die machen ihre Arbeit, perfekt, vorausschauen,
alles super, aber in dem Moment, wo es in die Projekte reingeht, sind
sie überfordert, das können sie nicht, nicht weil sie dumm sind, son-
dern einfach weil das ihrer Denkweise nicht so liegt. Also ich muss die
richtigen Leute im Team haben und zwar unter Umständen sogar ver-
schiedene für die Konzeptionsphase und für die Durchführungsphase.
I 22 Das ist die eine Geschichte, also Teamzusammensetzung, auf Basis
dessen, dann die Planung
I 30 Unter Umständen braucht man innerhalb vom Projektteam sogar einen
Art Mentor, der halt dann einmal sagt, he Burschen kommen wir wieder
zur Sache zurück und lasst jetzt euren Kleinkram da bei Seite,
J 12 die richtige Auswahl des Teams, das ist meiner Meinung nach der drit-
twichtigste Punkt, das Entscheidende.
J 12 dass die Teammitglieder keine Führungskräfte sein dürfen. Das heißt,
erstens wenn du an einem Tisch bei einem Workshop sitzt, wo du 10
Leute drinnen hast und 2 davon sind Führungskräfte, kannst du sicher
sein, dass die anderen Mitarbeiter manchmal nicht die Wahrheit sagen,
weil die gar nicht wollen, dass ihr Chef weiß, was da wirklich alles
läuft. Aber das System muss wissen, was da wirklich läuft. Das ist ein
Hauptthema, zweites Hauptthema ist, du musst etwas eskalieren kön-
nen, das heißt, arbeitet ein Teammitglied nicht ordentlich mit, musst du
zu seinem Chef gehen können um zu sagen, der muss sich mehr rein-
hängen. Wenn jetzt schon der Chef drinnen sitzt, wird schwierig.
L 10 Kommunikation mit Enduser, vorallem aber mit Fachabteilungen, da
diese für Tests benötigt werden.

Category: Success factor - Multiple system landscape

Int. Par. Text passage

G 6 ich kann während dem Patch, werden wir vielleicht auch noch drüber
sprechen, wie so ein Patch eigentlich abläuft über die SAP System
Landschaft, dass ich eigentlich natürlich während dem Patchzyklus
nicht Entwicklungen durchtransportieren kann.
G 12 die sagen wir haben ein Entwicklungssystem, wir haben ein
Konsolidierungs- oder Qualitätssicherungssystem

98
G 12 Die ersten 2 Wochen würde ich ca., 1 bis 2 Wochen auf der Sandbox ver-
bringen, also grundsätzlich, da ist der Fokus auf dem Patch einspielen
selber, da gibt es in der Regel immer da und dort Stolpersteine. Und da
finden auch die Optimierungen statt. Das heißt da schaut man dann, was
kann ich noch in die Uptime-Phase legen, vorher oder nachher, um die
eigentliche Down-Time möglichst gering zu halten. Das dauert ein bis
zwei Wochen. Dann beginnt das ganze am Entwicklungssystem, Patch
einspielen, dann kommen schon die ersten Tests, also auch funktional
und ganz wichtig dann SPAU, SPAU heißt die Transaktion in SAP, das
ist der Objektabgleich, weil natürlich seit dem letzten Patch, einerseits
Eigenentwicklungen die Objekte manipulieren auf der anderen Seite
auch Änderungen im Standard passiert sind und das gilt es immer abzu-
gleichen. Das ist am Entwicklungssystem ganz eine wichtige Phase
die auch einige Tage in Anspruch nimmt. Je nachdem wieviel Eige-
nentwicklung ich habe. Das hängt wiederum davon ab, wie lange ist
mein letzter Patch her. Also wenn ich da jetzt 5 Jahre Eigenentwick-
lung habe, weil ich 5 Jahre nicht gepatcht habe, dann wird das natürlich
mehr sein, wie wenn mein letzter Patch ein halbes Jahr her ist. Und
wenn ich grundsätzlich nicht eigen entwickle oder nur sehr wenig, dann
wird es auch wenig sein. Ja, dann Entwicklungssystem, da machen wir
es so, dass die erste Woche eigentlich vor allem die Entwickler darauf
schauen und wir erst in der zweiten Woche in die Breite mit den Tests
gehen. Wo wir dann wirklich auch Applikationsbetreuer draußen in den
Häusern testen lassen.
G 16 dann geht es aufs QS-System, dort haben wir auch schon die
Schnittstellen. Ganz wichtig, wir haben im Krankenhausbetrieb extrem
viel, also hunderte Schnittstellen zu Subsystemen, also sprich Patien-
tendaten, die vom führenden System, also SAP, an Subsysteme,
G 16 Ja so ist dieses Zusammenspiel und das haben wir dann nur am QS-
System, am Entwicklungssystem haben wir noch keine Schnittstellen,
das heißt dort ist dann sicher auch der Schwerpunkt, wie verhalten sich
die Subsysteme im Zusammenspiel vor allem beim Patch ist das nor-
malerweise unkompliziert,
G 16 Innerhalb von SAP Entwicklungssystem, QS-System, Produktivsystem
G 33 Wir haben ein Ausfallsystem, das ist auch ganz wichtig, weil sonst hät-
ten wir auf ganz wichtige medizinische Informationen keinen Zugang.
Befund, alles läuft bei uns über das SAP, die ganze Krankengeschichte.
Ohne SAP sind die blind, also das geht nicht. Das heißt Einschausystem
ist natürlich auch, wenn ich in einem kritischen Bereich bin zwingend
notwendig, da kann ich nicht einfach das Licht abdrehen und sagen, so
das war es, jetzt patchen wir.

99
 G 37 Was wir vielleicht auch noch haben, ist ein, was ich vielleicht auch
empfehlen könnte, Beweissystem nennen wir es. Das machen wir im
Prinzip bei allen größeren Releasewechsel, dass wir ein System zur Ver-
fügung halten, auf dem alten Releasestand, weil Anwender, damit ich
jederzeit den Vergleich habe Altsystem-Neusystem. Teilweise gibt es,
ich habe dann immer die Situation, ich habe jetzt dann das gepatchte
System, irgendwas verhält sich anders laut Anwender und ich komme
jetzt an den Punkt, man weiß das nicht, ich meine, kein Mensch kennt
das ganze System und jedes Verhalten. Und damit können wir jederzeit
die gleiche Situation schaffen unter alten Voraussetzungen und sagen,
stimmt das auch. Weil teilweise habe ich durchaus, muss ich ehrlich
sagen, den Anwender, jetzt hat sich was geändert und auf einmal fällt
ihnen was auf, was eigentlich immer schon so war. Das gibt es jedes
Mal. Und damit ist das dann schnell aufgeklärt. Aber es gibt natür-
lich mitunter auch Fälle, wo es sich tatsächlich geändert hat, das gibt es
auch. Oft sind es auch Menüpunkte die umbenannt sind.
G 37 Das lassen wir dann in der Regel so ein paar Monate, das alte System
und dann löschen wir es. Also das dient wirklich nur dem Vergleich.
I 8 Wie es in SAP üblich ist, hat man ja eine produktive Systemlandschaft,
aus mehreren Systemen und man fängt einmal mit dem Testsystem an
und man übt ein bisschen, so handelt man sich vor bis zum Produktiven,
das dann eher immer eine Nacht- und Nebelaktion wird, damit man die
Anbieter so kurz wie möglich offline setzt.
I 30 Aber ok, aber der Zeitrahmen war so konzipiert, dass sich das alles
ausgegangen ist, wir haben es geschafft, wir haben ca. 2,5 Monate
damit verbracht nur auf dieser Maschine zu spielen und sozusagen ein
Konzept zu entwickeln, wie machen wir das auf den Folgesystemen.
I 34 Aber ja, wenn man das Produktivsystem macht, wie es bei uns war, das
war dann das vierte SAP System. Das heißt wir haben gewusst, ok,
das erste Mal mit Problemen, da ist es natürlich auch länger down, weil
wenn ich in der Downtime-Phase ein Problem habe, dann muss ich das
auch beheben und wenn ich noch nicht weiß wie, weil ich noch keine
Erfahrung damit habe, dann muss ich einmal forschen gehen, lese dort
nach, frage jemanden und wenn der auch nicht mehr weiß, dann geht
man zu SAP fragen zum Beispiel oder man schaut nach.

Category: Success factor - System testing

Int. Par. Text passage

A 8 Da sind es dann eher größere Versionssprünge und wir haben dann das
natürlich im Umfeld bei uns testen müssen, auf mehreren Versionen, ob
dass dann auch mit diversen Druckern, Internetverbindungen, etc., die
Drucker und die Scanner sind vor allem die Probleme.

100
B 4 Nach diesen zwei Wochen hat es dann eine Phase gegeben, wo dann
die Keyuser dann, wo wir dann ca. 2 Wochen lang die Keyuser gehabt
haben zum Testen, ahh, das heißt wir haben einen Integrationstest dann
gemacht mit allen SAP Keyusernbzw. auch unterstützend teilweise
User aus den Fachabteilungen.
B 19 Testen. Also bei unserem, bei uns war es so, wir haben, wir haben
ahhh, eigentlich in der Vorphase, also in der Vorprojektphase, also bevor
wir da jetzt die eigentlich zur Umsetzung gekommen sind, haben wir
aber, haben wir schon Themen gehabt, dass wir eben ein Drehbuch
geschrieben haben für den Integrationstest, sprich, es hat, ein Kollege
von mir hat da einen, da muss ich jetzt schnell schauen, die Testpläne, da
haben wir ca., wann haben wir da angefangen, da haben wir angefangen
im Jänner, da ist es eigentlich schon losgegangen, dass wir ahhm Test-
fälle definieren mit den Keyusern, also, das heißt, das System verändert
sich.
B 19 Und jetzt ist es auch darum gegangen die Keyuser soweit mit an Boot
zu holen, mit an Boot zu holen, dass man sagt, welche sind wirklich
die relevanten Prozesse, die wir durchtesten sollen. Wir haben dann ca.
eine Liste von über 300 Testfälle gehabt
C 10 das depate bei der Geschichte war, das sie inhaltlich nicht geprüft hat,
weil es so viele Ausprägungen auf dem System gegeben hat, wie wir in
der kurzen Zeit, weil wir mussten ja gestern fertig werden, es kann ja
eh nix passieren laut SAP, naja, nicht alles testen konnten und dann ist
plötzlich, die TU Wien für 14 Tage gestanden,
G 12 was bei uns dann natürlich noch dazukommt, ist die Testphase. Das
heißt, wir testen auch am Produktivsystem, wo noch alle User draußen
gesperrt sind, testen wir am Produktivsystem ganz intensiv sehr zeitig in
der Früh. Alle mit SAP irgendwie betrauten Mitarbeiter, das ganze Sys-
tem noch einmal durch. Es gibt da kein Zurück, gepatcht ist gepatcht.
G 12 Die ganzen Tests werden dokumentiert, die Testfälle. Also testen ist
nicht einfach probieren, ich schau mal ob es geht, ich nehme einen Pa-
tienten auf und probiere mal alles durch, sondern testen tun wir an die,
es sind weit über 1000 Testfälle.
G 16 Es gibt Testautomationssoftware, wir haben das auch schon überlegt,
ist an zwei Dingen gescheitert, dass wir einen irrsinnig hohen, in den
Häusern, Individualisierungsgrad haben. Das macht es sehr sehr schwer
und auf der anderen Seite die Programme wirklich teuer. Also da ist die
Frage, ob da dieser Erkenntnisgewinn im Verhältnis zu dem, ob uns das
so viel bringt. Aber es ist, vielleicht haben wir einfach auch noch nicht
das richtige Produkt gefunden. Aber wir haben so viel Eigenentwick-
lung, dass es sehr schwer ist, das mit einem automatisierten Werkzeug
zu testen.

101
 G 16 Wo wir, die Last, die können wir in den Tests gar nicht generieren, die
dem entspricht, was draußen passiert. Also da hat uns unser Gefühl
bisher eigentlich immer ganz gut beraten, aber das ist so richtig immer
die Unbekannte, wo man dann am Montag in der Früh sagt, OK, wir
haben alles durchgetestet funktional aber wie sind die Antwortzeiten.
Wir haben gewisse Referenztransaktionen die wir ausführen, Reports
wo ich weiß, der läuft vorher nachher, jetzt auf dem gleichen System,
vor dem Patch, nach dem Patch, die Laufzeiten vergleiche, wo mir grobe
Sachen, sage ich einmal, auffallen.
G 16 Ja, und dann, das sind wiederum 2 Wochen circa, da testet man schon in
der Breite, da haben wir im betriebswirtschaftlichen Bereich auch Key-
User in den Fachbereichen, also im Personal, im Rechnungswesen, die
dann auch noch testen.
H 13 dass man sie zum Testen bringt, weil nur so kann ich mit einem halb-
wegs stabilen System online gehen,
H 15 Testdrehbücher zur Verfügung, dieses Testdrehbuch geben wir pro Un-
ternehmen jedem Haupt-Key-User
K 12 dass man eine starke Qualitätssicherung hat, das heißt, dass die Qual-
itätssicherungsabteilung, ob die jetzt extern oder intern ist, letztendlich
die Prozesse kennt, weiß was sie testen soll, was funktioniert hat, also
wie haben die Prozesse vorher ausgeschaut, funktionieren die Prozesse
sozusagen nach dem Upgrade gleich, wie vor dem Upgrade.
L 10 Tests unabdinglich um einen reibungslosen Betrieb nach Go-Live sich-
erstellen zu können.

Category: Success factor - Communication

Int. Par. Text passage

C 14 Koordination der Fachabteilungen fürs Zuarbeiten,
E 16 Grundsätzlich, wenn das anspricht wo es menschelt, wenn versucht
worden ist an veralteten Dingen, verkrusteten Dingen festzuhalten.
Dann muss man mitunter im Lenkungsausschuss oder mit den Pro-
jektauftraggebern auch darüber verhandeln oder diskutieren oder mit
einem Change Manager, das ist vielleicht die neuere Form, wie man
das ganze wieder auf Richtung bringt. Aus dem Projekt rauszugehen
und dann sagen, ja wir haben da ein Problem, wir müssen eine Lösung
suchen, wie geht man das an, zum einen Mal der fachliche Part, das
ist mitunter einfach aber der Bereich wo es menschelt, da braucht man
einen speziell geschulten Manager, Mitarbeiter, Projektbegleiter der die
Sachen, dann begleitet.

102
G 63 Interviewer: Kommunikationsplan Interviewter G: Kommunikation
ist auf jeden Fall wichtig. Das ist auch Teil des ERP Teams, die
müssen einfach gut zusammenpassen und somit auch gut miteinander
kommunizieren.
I 22 Dann brauche ich eine gescheite Kommunikation, ja, an dem führt kein
Weg vorbei, weil es hilft mir nicht, wenn jeder zwar Top in seinem
Bereich ist, aber nicht mit den Anderen redet und ich damit diese Ab-
stimmung nicht habe, die ich brauche, diese ineinander Verzahnung in
jeder Hinsicht und sobald ich das aufgesetzt habe,
I 22 gerade in punkto Kommunikation, es gibt Leute die können sowieso
miteinander oder können gut miteinander, aber ich muss auch mit je-
manden arbeiten können mit dem ich vielleicht nicht auf ein Bier gehe,
sagen wir es sehr salopp, aber dann muss ich das ebenso auf die Füße
stellen oder mir so überlegen, wie funktioniert das.
I 22 Projektplanung, dass ich sage, und an dem Milestone muss ich an wen
reporten und wer muss was wissen. Weil irgendwie muss das Manage-
ment ja auch informiert werden. Das wird nicht mit jedem Projektmi-
tarbeiter sprechen wollen.
I 36 Darum ist für mich das auch noch wichtig, ich muss die Erwartungshal-
tung vorher schon vielleicht ein bisschen runterbringen und nicht jetzt
himmelhochjauchzend machen, weil so, ahh, jetzt haben wir das neue
Release, das ist das Allheilmittel, da geht jetzt alles, was ich mir je-
mals gewünscht habe, das ist nicht so. Es gibt genau definiert Sachen,
die dann funktionieren, die zusätzlich funktionieren sollen und werden,
hoffentlich auch. Aber das so, ahh, dann geht dann sowieso alles. Man
muss auch die Anwender auch ein bisschen bremsen. Ich meine, ihr
habt euch das erwartet, aber das können wir nicht erfüllen. Also so auf
die Art, auch genau, also eigentlich fällt das unter Kommunikation.
I 36 Ich muss nach außen bringen, was profitiert ihr davon. Weil es gibt zwar
die Leute die das wollen, aber das ist halt ein kleiner, zwar meist ein-
flussreicher, aber ein kleiner Kreis, weil der hat sich informiert, der weiß
auch da will ich hin. Und die geben dann, dass auch unter Umständen
auch ein bisschen zu euphorisch weiter und der Endanwender draußen
sagt dann, boah super, das geht dann eh alles. Unter dann kommt die
große Frustration. Und das sollte man eigentlich vermeiden, finde ich.
Weil ich habe dann nichts davon, wenn ich dann viele Leute habe, die
dann frustriert sind, weil die Versprechungen die sie bekommen haben,
nicht eingehalten werden und ich eigentlich nichts dafür kann, aber ich
muss es dann ausbaden. Also muss ich immer probieren, dass so ein
bisschen korrekt zu kanalisieren und da die Erwartungshaltung nicht
allzu hoch werden zu lassen.

103
 J 12 Wenn Leute nicht rechtzeitig miteinander reden, ein ERP System hat
sehr viele Prozesse in einem Unternehmen, deckt bei uns von dem
kaufmännischen Bereich, Buchhaltung, Kostenrechnung, Controlling,
bis hin zur Produktion weltweit, über Vertrieb, Marketingaktivitäten
alles ab. Das heißt, dass sind tausende von Prozessen, hunderte von
Geschäftsfällen und das ist ganz natürlich, dass man manchmal, un-
terschiedliche Auffassungen haben, nicht, Controller verfolgen andere
Ziele als Vertriebler, Vertriebler wollen viel Freiheit haben, Controller
wollen alles kontrollieren. Liegt in der Natur des Menschen. Und hier
für einen Ausgleich zu sorgen, ist eigentlich, dass um und auf, damit
die Prozesse am Ende des Tages wieder nahtlos ineinandergreifen. Das
klingt jetzt banal, ist aber meiner Erfahrung, dass aller schwierigste in
so einem Projekt und auch der Hauptgrund, warum 70% aller ERP-
Implementierungen eigentlich scheitern.
L 10 Kommunikation mit Enduser, vorallem aber mit Fachabteilungen, da
diese für Tests benötigt werden.

Category: Success factor - Key user integration

Int. Par. Text passage

A 31 da darf man nicht vergessen, dass man eine Art Key-User System, in
der Einkaufsabteilung, in jeder Abteilung, definierte Key-User, die das
Projekt mittragen, mit testen, und dann dort in der Abteilung verteilen.
A 41 Interviewer: Zusammensetzung der ERP Team Interviewter A: Die
Key-User, die Verantwortlichen in einer Abteilung, die sind da sehr
wichtig, meiner Meinung nach
B 19 das haben wir zum einen mit den Keyusern durchgearbeitet, dass sich
diese einmal Gedanken machen, dass man diese mit an Boot holt, und
auch transportiert wie von der Wichtigkeit war es eigentlich eh fast je-
dem klar, was notwendig ist, dass das notwendig ist, um eben auch
Funktionalität 100%ige Funktionalität zu gewährleisten.
F 14 dass die Mitarbeiter, dementsprechend, auch, auf neue Herausforderun-
gen vorbereitet werden, nicht nur ERP-technisch, sondern auch
prozesstechnisch.
H 13 also die beteiligten Abteilungen sehr stark einbinde in das Upgrade Pro-
jekt, dann läuft nachher eigentlich alles relativ reibungslos, weil wenn
ich mich am Anfang gleich mal in das Projekt reinstürze und starte,
dann kommen, dann während dem Projekt soviele Fragen und es sind
soviele Möglichkeiten in eine falsche Richtung abzubiegen wo man
dann wieder zurückbiegen muss, dass die Zeit die man am Anfang in-
vestiert, sich hundert mal auszahlt.
H 13 dass man die User mit an Bord hat,

104
 H 13 wenn ich Wiederstand habe, dann habe ich sowieso verloren, und jede
unfreiwillige Änderung erzeugt Widerstand, das ist leider auch so, ja
wenn man sagt, wir graden up, dann sagen gleich mal alle, Oh mein
Gott, weil jetzt haben wir das alte System im Griff, das kann nur
schlechter werden, ich kenn mich mal kurzfristig nicht aus, das heißt
man muss, da sehr viele Ängste nehmen, gleich in der Anfangsphase,
man muss sie miteinbeziehen, man muss sie beim Testen schon sehr gut
einschulen, damit sie das Gefühl haben, OK, ich kenne mich aus,
H 15 Die Key-User-Integration ist sicher was ganz elementares

Category: Success factor - Lessons learned

Int. Par. Text passage

A 55 Aber auch Verbesserungen, was kann ich beim nächsten Release oder
Upgrade besser machen, um quasi die Fehler zu vermeiden. Ist im
Prinzip eine Fehlervermeidung, was ist gut gelaufen, was ist schlecht
gelaufen. Was kann man beim nächsten Projekt besser machen.
B 58 Ja, wir haben so eine, so eine Lessons-Learned Session, haben wir dann
gemacht,wo wir gesagt haben, was sind denn so die, die Dinge, die
sind, die gut gegangen sind einfach auch nochmal zu reflektieren, aber
genauso auch die Sachen, was sollte man anders machen.
E 50 Das heißt auch intern, XYZ intern, wird das besprochen und im
Lenkungsausschuss auch, wenn etwas gut oder schlecht gelaufen
ist, Verbesserungspotential sollte sich nicht anstauen bis ans Ende
des Projektes, sondern wenn das erkannt wird, man macht ja auch
eine Risikobewertung, wenn da Risikofaktoren auftauchen, sollte das
eigentlich ein kontinuierlicher Prozess sein.
G 25 Wir haben auch nach jedem Projekt immer, ganz wichtig, beim Projek-
tabschluss eine Lessons-Learned Sitzung, wo wir nochmal alle zusam-
mensetzt und wirklich, man macht das laufend im Projekt, wird da
schon befüllt. Alle Dinge wo ich sage, das hat mich jetzt erklatscht
aber, das darf uns nie wieder passieren. Genauso, und das nehme ich
mir dann ganz am Anfang vom nächsten Projekte dann wieder her, das
ist so ein lebendes LessonsLearned, was man durch- und mitzieht und
man macht auch jedes Mal einen Fehler aber ich wage zu behaupten,
wir machen jeden nur einmal.
G 49 Vor allem dieses, wirklich standardisieren, aus Fehlern lernen. Also,
jeder Patch wird bei uns besser, das ist, wenn man zurückblickt. Und
mittlerweile habe ich auch keinerlei Bauchschmerzen mehr.

105
 I 82 Ja haben wir auch gemacht. Und ja ist wichtig, aber die Frage ist wieviel
bringt es wirklich. Also da weis ich nicht, ob sich Aufwand und Nutzen
in einem sinnvollen Verhältnis verhalten, aber ja, man macht es. Aber
das hängt auch davon ab, wie oft man ein Upgrade macht. Je häufiger
man es macht, desto wichtiger ist das, weil man dann auch wirklich
noch davon profitieren kann.
J 56 Interviewer: Post-Implementation Evaluierung & Lessons Learned ?
Interviewter J: Meiner Meinung nach sehr wichtig, wird aber viel zu
wenig gemacht, in den Unternehmen
K 52 Kann man als wichtig beurteilen, weil letztendlich kann man Er-
fahrungswerte sammeln, sozusagen aus dem einen Upgrade Projekt und
in zwei Jahren kommt dann das nächste und dann kann man sicher
Dinge mitnehmen.

Category: Success factor - Stick to the standard

Int. Par. Text passage

E 12 Es werden teilweise bissl Ausflüchte gesucht, trotz alle dem sind die
Systeme im Standard so gut abgebildet, dass man möglichst standard-
nahe einführen sollen, das wiederum bringt den Vorteil, dass man sehr
rasch, mit einem Upgradesystem live gehen kann.
G 51 Entwicklung ist wirklich Code-Manipulation. Bis hin im extremsten
Fall von Abweichungen vom Standard. Also, da muss man auch noch
einmal unterscheiden. Da wird es dann schon heikel, davon würde ich
eher abraten. Standard-Manipulation sind immer potentielle Bomben
die ich mir in das System lege, die irgendwann hochgehen können,
wenn ich vielleicht gar nicht mehr daran denke und gar nicht mehr weiß,
dass es das gibt.
I 58 Also bei uns im Haus ist die Ansicht sowieso, dass wir so nahe wie
möglich am Standard bleiben, gerade was SAP betrifft, bei anderen
Paketen haben wir mit dem Standard nichts mehr gemeinsam. Dort
haben wir dann aber auch ein Problem, wenn wir ein Upgrade fahren.
Weil da machen wir fast eine Neueinführung, ja, also wir haben konkret
ein System unsere Produktionsplanung macht, wenn wir dort ein Up-
grade machen, das ist wie wenn wir es neu einführen würden.
J 20 Bis zu diesem Level hast du eigentlich kein Problem im Upgrade, weil
das sind definierte Schnittstellen wo der Hersteller zulässt, dass ein an-
deres System andockt, dass du irgendwas modifizierst.

106
 J 20 Wirklich haarig wird es, wenn du in den Source Code eingreifst, und,
im SAP nennt man das Modifikation, machst und wirklich den Source
Code veränderst des Programms. Davon ist eher abzuraten, es gibt aber
viele Unternehmen, die das machen und da hast du dann bei einem
Upgrade-Projekt ein brutales Problem. Weil du musst wirklich, du
weist nicht was der Hersteller im nächsten Release dann mit der Funk-
tion gemacht hast, die du verändert hast. Plus du bist möglicherweise,
begibst du dich in gesetzlich schwierige Situationen, weil du könntest
theoretisch, ein ERP System ist ja revisionssicher, das heißt es ist von
den Steuerbehörden anerkannt. Und wenn du da dann eine Modifika-
tion reinmachst, kann es sein, dass dir der Wirtschaftsprüfer die Bilanz
verweigert, oder dass die Steuerbehörden kommen und der Steuerprüfer
und sagen, du hast Steuer hinterzogen, also das kann richtig haarig wer-
den, wenn du das an den falschen Stellen machst. Und deswegen ist
von dem eigentlich abzuraten, es gibt aber sehr viele Unternehmen die
das machen.
K 18 Was man natürlich auch bei Upgrade-Projekten nutzen sollte und da
ist man natürlich auch in einer Mischung aus Change- und Upgrade-
Projekten, man muss halt auch beleuchten, wenn sozusagen SAP et-
was ausliefert was sie bisher noch gar nicht gehabt haben, der Kunde
aber sozusagen was eigenen gebaut hat, dann sollte man natürlich die
Chance nützen, quasi von diesen kundeneigenen Funktionalitäten auf
die Standardfunktionalitäten umzusteigen und diese dann entsprechend
zu nutzen und das wär dann halt ein zusätzlicher Erfolgsfaktor, mit
dem man immer gut punkten kann, wenn man sagt, OK, wir haben
jetzt, weiß ich nicht, 5 kundeneigenen Funktionalitäten im Zuge des
Upgrade-Projektes ablösen können.
K 20 Genau, alles was im Standard ist, sozusagen ist stabil, da gibt die SAP
die Garantie darauf, und ja, das ist, das hat halt Vorteile beim nächsten
Upgrade wirds leichter, und wenn irgendwann mal eine Schnittstelle
angebunden wird, ist die vielleicht, ist diese Funktionalität schon vorge-
sehen, also, und die Prozesse die SAP entwickelt, dann haben die halt
immer im Hinterkopf ihre eigenen Prozesse die sie ausliefern und nicht
die Kundenprozesse, man ist halt quasi weiter im Standard, was halt a
la long definitiv ein Vorteil ist.

Category: Success factor - Top management support

Int. Par. Text passage

F 14 dass die Geschäftsführung dahinter steht

107
 G 43 Also bei einem Patch-Projekt ganz genau so, der aller erste Schritt
ist immer, dass ich die Geschäftsleitung informiere und sage, und das
mache ich wirklich ein halbes Jahr im Voraus, und sage, dann werden
wir patchen, das ist der Zeitraum, die wesentlichen Meilensteine, die
sie interessieren, vor allem auch Transportstopp. Welche Projekte in
irgendeiner Form betroffen sein könnten. Das heißt, welche Produk-
tivgänge unbedingt vorher passieren müssen, weil ich sie sonst nicht
machen kann. Indem Sinn, ist das sicher sehr wichtig.
I 22 das ist die Unterstützung vom Management, weil natürlich haben die
Anwender Unannehmlichkeiten in so einem Projekt, weil da steht ein-
mal was, da geht nachher was nicht, da muss ich vielleicht Vorarbeiten
leisten, die es schon mühsam machen eigentlich, obwohl ich noch gar
nicht umgestiegen bin, weil es meine Arbeit erschwert. Und das muss
vom Management getragen werden, weil wie bekomme ich die Maß-
nahmen nie durch, und da stoße ich auf so viel Widerstand, dann
kann ich es nicht machen. Es geht dann immer irgendwie, aber die
Frage ist mit wieviel Reibungsverlusten und mit wieviel zusätzlichem
Zeitaufwand bekomme ich das durch
J 12 Der zweite Grund ist letzten Endes, dass man von der Geschäftsführung
die Freiheit und die finanzielle Unterstützung bekommt,
J 12 finanzielle Freiheit oder die finanzielle Leistungsfähigkeit, diese Dinge
auch wirklich durchzuführen, weil ich habe kein ERP Implemen-
tierungsprojekt erlebt, dass nicht, ich sag jetzt mal frech, doppelt soviel
gekostet hat, als man ursprünglich mal, also sich die Geschäftsführung,
die das wollte, gedacht hat.

Category: Success factor - Resources & focus

Int. Par. Text passage

C 12 Die Verfügbarkeit, ja, weil meine Finanzbuchhaltung jetzt im März sagt,
quäl mich nicht, ich hab den Jahresabschluss. Und das ist halt etwas,
das wir immer wieder sehen, in Projekten die wir auch unterstützen, wo
es dann heißt, ich hab jetzt keine Zeit, gerade in Projekten wo Sie Daten
anrühren, Daten anreichern müssen, die Fachabteilungen haben ja auch
nebenbei ihr produktives Geschäft und müssen jetzt praktisch sich mit
Ihnen hinsetzten, weil Sie meinen, das System wir upgegradet.
F 20 wo einfach auch die Leute intern die Ressourcen einfach auch
freigestellt, freigespielt werden

108
 G 24 Also bei uns geht es, und da würde ich auch jedem dazu raten, in erster
Linie mal um den Patch. Es ist oft die Versuchung da, wenn ich schon
die Down-Time habe, das große Abschaltfenster, dann könnte ich ja
dieses und jenes auch gleich mitmachen. Ich kann aus meiner Erfahrung
nur warnen davor an zu vielen Schrauben gleichzeitig zu drehen, weil
wenn nachher was nicht funktioniert, dann weiß ich nicht woran es liegt
und es ist sehr schwer die Quelle zu finden.
G 25 Ja, dann die Ressourcen in dem Zeitraum freischaufeln. Das heißt, ganz
bewusst. Wir haben sehr viel Testaufwand und wir brauchen auch die
Leute dazu, wir brauchen sie innerhalb der IT, das heißt auch andere,
im Projektumfeld andere Projekte müssen so getimet sein, dass ich da
in dieser Zeit keine Produktivgänge habe, was sowieso nicht geht, aber
auch, dass ich die Ressourcen zur Verfügung habe. Das heißt, es ist
bei uns wichtig, es muss von langer Hand geplant sein. Muss von der
Geschäftsleitung abgesegnet sein. Mindestens ein halbes Jahr vorher,
informiere ich alle, dass wir einen Patch machen, dass sich alle Projekte
rundherum auch danach richten können.

Category: Success factor - Change management

Int. Par. Text passage

C 33 Das Change Management der Prozesse meine ich, mein Change Man-
agement ist schon sehr wichtig, ja weil ich ja bei mir Sachen ändern
muss, also hier zu unterscheiden zwischen Change Management in der
IT-Abteilung versus Change Management draussen.
E 12 Ein Change Manager in diesem Bereich muss oder sollte so ein Pro-
jekt gegebenen falls begleiten. Auch die Organisation beim Kunden
entsprechend zeitgerecht anzupassen. Das ist ein wesentlicher Faktor,
wenn man heute optimiert, gewachsene Prozesse im System dann eine
Optimierung vornimmt und die Organisation als solches nicht vorbere-
itet wird, sei es wenn es Personalrochaden gibt, sei es wenn es Freiset-
zungen gibt, sei es wenn Tätigkeiten woanders hin verlagert werden.
Das muss man in der Organisation zeitgerecht mit Fingerspitzengefühl
vorbereiten und begleiten.
H 29 Interviewer: Change Management Interviewter H: ja sehr wichtig, weil
da haben wir das Thema mit der Abweisung, also die unfreiwillige Än-
derung quasi
K 28 Change Management Interviewter K: wichtig, wenn man neue Busi-
ness Functions sozusagen aktiviert, also wenn man sagt, im Zuge des
Upgrade Projektes.

109
Category: Success factor - Data & code cleansing

Int. Par. Text passage

H 13 dass man das Upgrade gleich benutzt alten Code rauszuhauen, den
man nimmer braucht, alte Funktionen rauszuhauen, die man nimmer
braucht, also für mich ist ein Upgrade Projekt auch immer gleich ein
Systembereinigungsprojekt. Nicht nur einfach nur auf die neue Version
zu heben, man muss sowieso den Code immer angreifen, man muss
eh reingreifen, also ist das auch immer eine Gelegenheit zu schauen,
welchen Code greifen wir an, welchen greifen wir nicht an und was
braucht ihr stattdessen.
J 14 bis hin zu Studenten, in fast allen meinen Projekten, war es so, dass
wir dann Studenten oder so irgend etwas, Berufspraktikanten, engagiert
haben, die zum Beispiel Datenbereinigung machen,
J 14 das vierte, ist die Datenbereinigung im Altsystem zu machen. Also weil
sonst hast du immer das Motto Shit-In, Shit-Out, ja, also wenn du im
alten System einen Scheiß drinnen hast, dann hast auch im neuen Sys-
tem einen Scheiß drinnen. Und Datenbereinigung, Salden abschließen,
von offenen Positionen, die schon Jahre mitgeschleppt werden, inak-
tive, falsche Lieferanten, Ansprechpartner, Materialien die man vielle-
icht nicht mehr braucht. Man muss natürlich immer ein bisschen auf-
passen, dass du die Historie, für buchungs- oder steuerrelevante The-
men mitnimmst, ja, und, das kann nur entweder in Massenverarbeitung
gemacht werden, wo die Menschen die sich auskennen, das bereinigen
oder diese Menschen, dann Arbeitskräfte anweisen.

Category: Success factor - Use of new potentials

Int. Par. Text passage

D 10 dass man mit der neuen Technologie die alten Geschäftsprozesse imple-
mentiert, das ist eine Geldverschwendung, das heißt in der Vorbereitung
sollte man sich wirklich mit der neuen Technologie beschäftigen, aber
nicht nur mit der Technologie, sondern auch mit dem eigenen Geschäft
und untersuchen, was kann ich wirklich Neues mit der neuen Technolo-
gie machen. Das ist im Wesentlichen eine Frage der Vorbereitung und
auch des Verständnisses vom Geschäft und dann muss man da auch
wirklich mutig sein und sagen, he mit der neuen Technologie könnten
wir ganz neue Sachen machen und die werden wir jetzt auch angehen.
Also einfach ein gründliches Verständnis der neuen Technologie und
ihrer Auswirkungen auf das Geschäft, das ist ein ganz ein wichtiger
Erfolgsfaktor.

110
 D 10 dass man sich auch in der Firma selbst mit der neuen Technologie
beschäftigt und das nicht irgendwelchen Beratern gibt, ja, das einfach-
ste ist, zu jemanden zu sagen, machen Sie mir eine Umstellung auf
SAP Hana und es soll genauso funktionieren wie bisher, hier ist das
Bisherige, machen Sie, ja. Man muss sich sicherlich im Unternehmen,
gründlich mit der neuen Technologie auseinandersetzen und auch wirk-
lich überlegen was kann ich wirklich neu machen.

Category: Priorization of success factors

Int. Par. Text passage

C 14 Projektmanagement, Koordination der Fachabteilungen fürs Zuar-
beiten, den depaten Patch einspielen, das ist nicht das Thema, wirklich
einen Zeitplan zu machen, wo alle Leute, dann auch mal Zeit haben
und sich vorher anzuschauen, was sich da an Stammdatenänderungen,
Bewegungsdatenveränderungen, plötzlich passiert.
E 14 Es sollten gewisse Ziele niedergeschrieben werden. Die bleiben im
Fokus. Das Zusammenspiel und die Zusammenarbeit des Teams und
auch die Begleitung und die Anpassung in der Kundenorganisation.
G 33 Nein, also ich kann nur sagen, für uns wirklich ganz kritisch, warum die
Projekte bei uns so gut laufen ist sicher, dass sie als Projekte abgewick-
elt werden, dass wir aus Fehlern der Vergangenheit lernen, dass wir
die Leute, die Ressourcen, die ganze Aufmerksamkeit für den Patch
haben, dass die auch freigespielt werden, dass die nicht 5 andere Pro-
jekte nebenherlaufen haben und dass die Organisation gut vorbereit ist
darauf. Also, dass auch alle Anwender wissen, was das für sie bedeutet.
I 26 genauso wie ich es erwähnt habe, also eigentlich die Planung, die
Teamzusammensetzung, die Unterstützung durch das Top Management
und die Kommunikation. So hätte ich das gesehen.
L 12 1. Kommunikation, 2. Test des Upgrades auf identem Testsystem, 3.
Projektmanagement, 4. Einhalten von Terminen

Category: Problems and their solutions within the project

Int. Par. Text passage

C 18 Alle Stammdaten im Argen, reicht Ihnen das?
C 20 ndem einerseits mein Team versucht hat, quasi, Programme zu finden
die die Stammdaten automatisch anreichern, hat es nicht gegeben, das
heißt manuell durch 600 Konten durchhatschen.

111
C 22 sehr viel manuelle, und zwar nur die eine Fachabteilung machen kann,
die gar nicht das IT-Team machen kann, sondern die Fachabteilung,
weil die Fachabteilung sich entscheiden muss links, rechts, oben oder
unten. Und das ist der scheiß Hammer dabei. Das ist etwas, dass die
IT-Abteilung auch gar nicht entscheiden darf. Ich brauch den Key-User
aus der Fachabteilung der sagt, so muss es funktionieren und dabei kann
die IT-Abteilung nur unterstützen.
F 18 Der größte Fehler ist, den man immer wieder macht, ist einfach, dass
man sagt, jaja, jetzt machen wir halt den Releasewechsel. Sie wissen
was ich meine. Da passiert nichts, und alles andere läuft so wie es ist, ja
und das ist eigentlich die größte Herausforderung, und dass das ganze
einfach unterschätzt wird und gar nicht als Projekt gesehen wird und
das läuft einfach so irgendwie nebenbei.
H 19 klassisches Problem ist sowieso immer, das gewisse Dinge nicht
wie spezifiziert möglich sind umzusetzen, nicht funktionieren, kom-
plizierter sind als gedacht, nicht in der Zeit, also der Klassiker ist dann
immer, dass man sagt, dass irgendwann mal der Punkt kommt, wo man
dann entscheiden muss, das nimmt man jetzt raus aus dem Upgrade
Projekt und geht einmal Live ohne diesen Punkten und das wird im
Nachgang gemacht, also diese ständige Entscheidungsfindung, quasi,
das muss dabei bleiben und das kann ich jetzt mal rausnehmen,
H 19 also da haben wir ein paar Funktionen gehabt gerade von den Neuen, die
dann doch nicht so funktioniert haben, wie geplant, weil einfach unsere
internen Systeme, die haben dann Probleme gemacht, also, unter einer
anderen Umgebung wäre das problemlos gegangen, aber mit unserer
Umgebung hat sich dann rausgestellt, dass das nicht so funktioniert wie
geplant und dann ist halt die Entscheidung, rausnehmen oder Zeitplan
nach hinten verschieben und dranbleiben, also das sind immer so die
Lösungsmöglichkeiten. Ja, das muss man dann immer abwägen, was
wichtiger ist, im Zeitplan bleiben oder die Funktion mit dabeihaben
H 19 Die kritischen Momente sind immer die, wo man den Key-Usern das
zum Testen gibt, weil da ist dann bei fast jedem Projekt einmal die
Verzweiflung groß, also, das find ich nimmer, und das geht nicht mehr,
das sind dann Sachen die einem trotzdem immer wieder überraschen,
obwohl man selber so gut durchgetestet hat, dass man sie dann wirk-
lich an der Hand nimmt, sich die Zeit nimmt für die Key User, ob-
wohl das oft gar nichts mit der IT zu tun hat, aber im Endeffekt die
Nerven ein bisschen beruhigt und weil dann schreien immer die Key
User, wir können nicht live gehen mit dem System, das sind aber oft
nur Kleinigkeiten,

112
H 19 dass die Berechtigungen vom alten System, also das Berechtigungssys-
tem hat sich geändert, und dass wir uns da was überlegen müssen
und wir haben noch ordentlich prüfen müssen, dass die User wirk-
lich nur das sehen, was sie sehen sollen und das ist vielleicht spezi-
fisch vom ERP-System, dass das eben extrem wichtig ist, diese ganzen
Sicherheitsrollen und Berechtigungen, weil es halt mehr Relevanz hat,
als in anderen Systemen, weil einfach bestimmte Zahlen, bestimmte
Daten nicht rausgehen dürfen. Und da hat uns Microsoft noch einen
kleinen Strich durch die Rechnung gemacht, also unser altes Berech-
tigungskonzept hat nicht mehr so funktioniert, da haben wir dann am
Sonntag noch etwas gebastelt. Das war vielleicht noch kritisch, aber
das war dann auch glücklicherweise so, dass der externe Dienstleister
da relativ genau gesagt hat, das müssen wir machen und das haben wir
dann eben manuell nachgezogen, das war halt noch viel Arbeit, aber im
Endeffekt hat dann alles funktioniert.
I 30 organisatorisch, ja, da gibt es immer wieder kleinere Reibereien, Un-
einigkeiten oder so, aber wirkliche Probleme würde ich das nicht se-
hen. Und das passiert, wenn Menschen kommunizieren, dass sie sich
abundzu falsch verstehen, dass sie nicht verstehen wollen, was der An-
dere sagt, das ist einfach so. Ich mein, da kann man ganz offen sprechen,
aber ich sage, das ist so, wenn Menschen miteinander arbeiten gibt es
auch Probleme, gibt es Reibereien, gibt es Animositäten, das passiert,
ja, aber das ist nichts, was man nicht schaffen kann.
I 30 Unter Umständen braucht man innerhalb vom Projektteam sogar einen
Art Mentor, der halt dann einmal sagt, he Burschen kommen wir wieder
zur Sache zurück und lasst jetzt euren Kleinkram da bei Seite,
I 30 zweitens haben wir natürlich das alles einmal auf einer kopierten pro-
duktiven Maschine durchgespielt und geschaut, was passiert denn da.
Das zählt bei mir auch zur Planung, Vorbereitung, weil das muss ich tun.
Alles andere, kann ich nie einen Zeitplan machen, weil ich muss dort
einmal schauen, wie lange brauche ich, wie lange habe ich Down-Time,
welche Probleme treten auf, weil ich erwarte ja, dass dann ähnliche auf
dem Echten sind. Dort hat es natürlich einiges gegeben, dort haben wir
aber den Zeitraum den wir uns dafür gegeben haben auch großzügig
genug geplant haben um diese Probleme dann vernünftig lösen zu kön-
nen und teilweise auch mit Hilfe des Herstellers, weil irgendwann dann
natürlich auch die externen Berater sagen, jetzt muss ich fragen gehen,
weil mein Pouvoir, wo ich da überhaupt etwas tun kann und eingreifen
kann, ist da am Ende.
L 14 Probleme bei Schnittstelle zu Einkaufsmodul am Testsystem. Umstel-
lung musste daher um 1 Woche verschoben werden, dadurch haben wir
uns jedoch viele Probleme nach Go-Live erspart

113
Category: Differences in success factors within ERP implementa-
tion and ERP upgrade projects

Int. Par. Text passage

A 35 Interviewer: Ein weiterer Punkt, den da ich da habe ist Business Plan &
Vision Interviewter A: Beim einem Upgrade ist das eher nicht wichtig,
A 39 Interviewer: BPR & Anpassung der Softwarelösung Interviewter A: Bei
einem Upgrade ist das nicht mehr wichtig, das ist nur bei der Einführung
wichtig
B 30 bei der Implementierung, du kennst das System noch gar nicht, mit dem
du eigentlich arbeitest. Das ist eigentlich, das, ahh, das was der große
Unterschied ist. Weil du hast natürlich, wir haben eine die Vorprojekt-
phase hat, war ca. 1 dreiviertel Jahr, ahh, mit Start der Einführung, du
lernst relativ spät SAP eigentlich erst kennen und auch zu verstehen.
B 34 Interviewer: Das zweite ist Change-Management? Interviewter B: Ist
dahingehend nicht so wichtig meiner Meinung nach, weil ahh bei der
bei der Umsetzung ja du jetzt nicht großartige Veränderungen machst.
Das haben wir, wir haben auch, wir haben im Projekt eigentlich auch
definiert, dass wir jetzt keine neuen ahh, es gibt ja sogenannten Busi-
ness Functions, so heißen diese, kann man Business Functions dazu
aktivieren, die werden eher zum Beispiel durch ein EHP Upgrade dann
freigeschalten.
B 36 Interviewer: Ok. Ah. Der nächste Punkt wäre Business Plan und Vi-
sion? Interviewter B: Naja, nein, das ist nicht so wichtig.
B 48 Interviewer: Ok. Usertraining und Schulung? Interviewter B: Gar
nicht. Also dadurch, dass ich das System theoretisch nicht verändert,
es sind ein paar so Kleinigkeiten, dass irgendwo auf einmal eine Maske
vielleicht ein bisschen anders aussieht, aber dahingehend ist gar nichts
trainiert worden. Interviewer: Business Case? Interviewter B: mhmm,
sehe ich als eher weniger wichtig.
B 54 Interviewer: Ja. Ahh. dann haben wir da noch Management von Lega-
cysystemen, also habt ihr alte Systeme, die irgendwie noch...? Inter-
viewter B: Nein, haben wir eigentlich dahingehend jetzt nicht. Also es
gibt natürlich, wir haben natürlich schon einige Schnittstellen zu sag
ich jetzt einmal, ahh, zu Legacysysteme, das ist aber, ist aber über-
schaubar, also das ist in unserer Größenordnung jetzt, aber natürlich
die Schnittstellentests haben genauso dazugehört, dass man schaut, dass
das funktioniert.
C 33 Change Management: Auch nicht, weil ich, also wenn es bei mir End
of Life ist, will ich nicht, dass sich unbedingt was ändert. Das Change
Management der Prozesse meine ich

114
C 35 Interviewer: Business Plan und Vision? Interviewter C: Nicht so
wichtig, eher bei Implementierungen wichtig
C 45 Interviewer: User Training & Schulung Interviewter C: Sollte hof-
fentlich unwichtig sein, aber manchmal, wenn sich was ändert
D 19 hat man natürlich viel weniger Erfahrung wie beim Upgrade, daher ist
meistens das Risiko bei der Erstimplementierung höher, als wie bei
Upgrades
D 19 das Problem ist, wenn man schon ein System hat, dann denkt man auch
in sehr eingefahrenen Bahnen und nutzt dann sehr oft eben die neuen
Technologien eben nicht optimal
D 23 Interviewer: Der erste wäre, Top Management Support? Interviewter
D: Ja, bei kleiner Upgrades natürlich nicht, aber bei wirklich neuen
Technologien, wie es dazumals R3 war oder jetzt HANA, ganz wichtig.
D 25 Interviewer: Change Management Interviewter D: Ja sicherlich auch,
wahrscheinlich nicht so stark wie beim ersten Mal, aber natürlich auch.
D 37 was ändert sich für die User wirklich, ja, wenn sich auch das User In-
terface ändert ist klar, dass sie viel trainieren müssen, wenn sich nur im
Hintergrund, im Backoffice irgendeine Engine aufstellen, und irgend-
was ausrechnen, dann ist das vielleicht etwas weniger wichtig.
E 18 Das ist bei einem Einführungsprojekt meist mehr Aufwand notwendig,
wie wenn man ein Upgrade-Projekt hat, wo der Kunde das Vorsystem
schon gekannt hat. Er ist teilweise schon sehr fit mit dem Neuen und
findet sich darin, im Neuen, sehr schnell zurecht. Es hat sich vielleicht
eine Oberfläche geändert, aber sehr viel von dem was von dem alten
System ins neue eingeflossen ist, findet er wieder.
G 47 Interviewer: Business Plan & Vision Interviewter G: Das ist jetzt eine
bisschen eine abstraktere Ebene. Also spielt bei uns eine nicht so
wichtige Rolle. Die Implementierung ist ja jetzt schon ein Baustein
der Umsetzung der Vision, dorthin, also, das sind für mich zwei völ-
lig verschiedene Ebenen, das eine ist wo will ich in 5 Jahren sein, wo
will ich in 10 Jahren sein und das andere ist was implementiere ich jetzt
konkret. Also würde ich da eher weniger nehmen.
G 55 Interviewer: User Training & Schulung Interviewter G: Beim Patch
überhaupt nicht, es sein den der Patch bringt, was er in der Regel nicht
tut, weil ich viele Neuigkeiten per Switch, ein- und ausschalten kann,
bringt zwangsläufig Änderungen mit sich.
G 59 Interviewer: Business Case Interviewter G: Sehe ich jetzt nicht so als
wichtig an bzw. machen wir nicht, weil der Patch oft einfach notwendig
ist

115
G 65 Interviewer: Management von Legacy System Interviewter G: Eher
nicht, eigentlich am Datenmodell selbst, ist kein Thema. Habe ich eh
kurz gestreift, Schnittstellen sind in der Regel bei Patch-Projekten kein
Problem.
H 31 Interviewer: Business Plan & Vision Interviewter H: nicht so wichtig
H 35 Interviewer: BPR & Customization Interviewter H: weniger wichtig
I 40 Also, wenn ich was implementiere. Dann mache ich das ja nicht, weil
ich Spaß daran habe, sondern, ich mache das, weil es Anforderungen
gibt, die in Summe dazu führen, dass ich sage, ich implementiere jetzt
ein Softwaresystem. So, das heißt, die wichtigste Phase bei einem Im-
plementierungsprojekt ist für mich, dass ich definiere, was will ich den
überhaupt. Ich muss meine Prozesse definieren, ich muss auch die Ab-
grenzung definieren, was will ich den nicht. Ich muss die Anforderun-
gen gewichten, was brauche ich unbedingt, was ist Nice-to-Have und
was ist Wunsch an den Weihnachtsmann, oder so
I 40 Ich kann das dann beim Upgrade auch noch so machen, ich mache eben
dieses Testsystem, mach es dort einmal und sage dann, schaut einmal
darauf ob es das liefert, was ihr wollt. Bei einem Implementierungspro-
jekt, kann ich das alles nicht tun.
I 40 Da muss ich meine Definition wirklich, ein gescheites Feinpflichten-
heft machen, muss letztendlich oft, gerade wie es in einem Konzern
ist, gibt es Anforderungen aus verschiedenen Bereichen, muss sagen,
was ist den da wichtiger, falls sich da etwas ausschließt. Muss genau
festlegen, was ist ein Must-Have und was ist ein Nice-to-Have. Also,
alleine in der Definitions- und Konzeptionsphase ist für mich das Im-
plementierungsprojekt, weit weit aufwendiger, weit weit detaillierter zu
machen und auf alle Fragen einzugehen
I 40 der Buchhalter wird nachher auch seine Belege wieder buchen wollen,
ob er das jetzt mit dem Release oder mit dem Release macht, ist dem
scheissegal, sehr salopp gesagt. Wenn ich was implementiere, dann ist,
das dem, der damit arbeiten will nicht egal, wie er damit arbeiten soll.
Sondern der hat ganz genaue Ideen, wo er, weil wegen dem will er ja
was. Der hat Ideen, wo er effizienter werden will, der will ja nicht so
arbeiten wie bisher

116
I 40 Und vor allem der Zeitrahmen ist viel länger. Auch wenn ich es einmal
implementiert habe, im Normalfall, habe ich dann, wie soll ich sagen,
ich nenne es immer ein nacktes System, das habe ich noch nicht für
meine Bedürfnisse eingerichtet und nicht für meine Bedürfnisse gecus-
tomizt. Je nachdem wieviel man, dass dann auch wirklich kann. Aber
der Prozess hört nicht auf, wenn ich es implementiert habe, dann habe
ich hoffentlich was, mit dem ich arbeiten kann. Und dann gehe ich
daran, dass ich das dann optimier. Das fällt weg bei einem Upgrade.
Bei einem Upgrade bin ich, wenn nachher alles geht, bin ich eigentlich
fertig.
I 40 Aber die Faktoren sind die gleichen, ich muss spezifizieren, ich muss
ein vernünftiges Team haben, ich brauche die Unterstützung durch das
Management, das ist immer das gleiche. Also der Unterschied für mich
ist einfach, wie lange dauert es, wo hört es auf und wie gut muss ich es
definieren, das ist für mich eigentlich der essentielle Unterschied. Also
außer so Kleinigkeiten wie, vielleicht ist das System so neu, dass ich
jetzt für mein Hard- und Software oder Systemsoftwarebetreuung noch
Leute ausbilden muss, weil das was Neues ist
I 40 mir ein Tool am Markt kaufe und das dann entsprechend meinen An-
forderungen customize, adaptiere, wie auch immer man, dass dann auch
nennt, dann ist das so, wie es ist. Dann kann ich mir das nicht aus-
suchen, ich hätte da gerne, weiß ich nicht, mit der Oberfläche oder mit
den Entwicklungstools, sondern das ist dann so. Und wenn ich da kein
Know-How habe, dann muss ich mir das vorher aufbauen, weil sonst
bin ich nachher ja überhaupt nicht in der Lage intern irgendetwas zu
tun.
I 48 Interviewer: Change Management Interviewter I: Für ein Upgrade halte
ich es für weniger wichtig
I 64 Interviewer: User Training & Schulung Interviewter I: Konkret haben
wir für unsere Endanwender überhaupt keine Schulung gemacht beim
SAP. Also die Schulung war in dem Fall, also halte ich für weniger
wichtig.
I 68 Interviewer: Business Case Interviewter I: Haben wir nicht gemacht,
weil einen Business Case macht man, für mich eigentlich, vor einer
Neueinführung, also rechnet sich das für mich, kann das System, dass
ich jetzt einführen möchte, das abbilden, kann ich da meinen Business
Case damit durchspielen und rechnet sich dann unterm Strich das für
mich.
J 26 weil die User kennen die Masken möglicherweise, die Grundlogik än-
dert sich nicht so wahnsinnig viel, dass du wirklich alle schulen musst
und du hast sozusagen ein Zehntel des Aufwands weil du upgradest.

117
K 22 Dann sind die Prozesse, dann gibt es gelebte Prozesse, die sind noch mit
der alten Software, SAP ist ein starkes Modul und sozusagen, kommt
daher und sagt, wir liefern diese und diese Prozesse aus und die funk-
tionieren bei uns so und so, und wenn ihr quasi die Prozesse, ihr Kunden
müsst euch an unsere Prozesse anpassen die wir ausliefern, sonst müssts
halt selber dazu entwickeln, sprich in vielen Bereichen muss der kom-
plette Prozess umgebaut werden, weil die SAP ja einen groben Prozess
hat an dem man sich orientieren muss, wenn man diese Software ein-
führt, weil sonst macht es keinen Sinn, dass man die Software einführt,
wenn man sagt, mache ich gleich weiter wie bisher, meine Prozesse
sind gleich wie bisher, dann brauche ich kein SAP einführen, wenn ich
SAP einführe, dann muss ich sagen, OK, SAP hat eine Best-Practice
Prozessauslieferung,
K 22 Ja, und dann gibt es natürlich, eine Softwareeinführung, gerade in
diesem Umfeld, ahh, ist wahnsinnig kompliziert, in unserem Umfeld,
wir haben meistens Systeme die haben, weiß ich nicht, zwischen 20
und 100 Schnittstellen zu anderen Systemen, wo Daten reinkommen
und Daten rausgehen, und ja, im Einführungsprojekt muss ich eben zu
all diesen Systemen die Schnittstellen aufbauen, wenn ich dann quasi,
das ganze Projekt einmal eingeführt ist, dann sind die Schnittstellen
alle da, und da muss ich maximal schauen, vielleicht sind ein oder zwei
Schnittstellen anzupassen, aber ich habe die ganzen Einführungen und
Diskussionen von Schnittstellen nicht mehr, und wie das ganze Han-
dling ist.
K 26 Interviewer: Top Management Unterstützung Interviewter K: gar nicht
wichtig
K 28 wenn ich nur die Software hebe ohne großartig die neuen Funktionen
zu nutzen, ist Change Management auch nicht wichtig,
K 30 bei einem Upgrade ist die Vision auch nicht wirklich wichtig.
K 40 Interviewer: User Training & Schulung Interviewter K: Hängt auch
wieder davon ab, mit neuen Business Functions ist es wichtig, sonst
ist es unwichtig
K 48 Interviewer: Management von Legacy Systemen Interviewter K: Nicht
wichtig
L 18 Implementierung benötigt eine sensible Herangehensweise für Schaf-
fung von User-Akzeptanz.
L 18 Bei Upgrade gibt es kleinstmöglichen Beeinflussung des produktiven
Betriebs. Es muss nachher immer alles möglichst so funktionieren wie
vorher.

C Interview transcripts

118
 C.1 Transcript Interview A
1 Interviewer: Bitte geben Sie einen kurzen Überblick zu Ihrer Person, Ihren
Aufgabenbereich, ihr Unternehmen?
2 Interviewter A: Ja, Moser Norbert ist mein Name und bin seit gut 2 Jahren in Pension, hab
aber vorher im XYZ IT Center den Bereich ERP, Warenwirtschaftssysteme geleitet. Ich war
dort Projektorganisator hauptsächlich für die ERP Systeme, unser Hauptkunde war dort die
XYZ Organisation, die XYZ, alles was im Umfeld mit der sogenannten "Ware", nennt man
das im XYZ Bereich zu tun hatte. In unserer Firma war unter anderem Kommunalsoftware,
da sind wir Markführer in Österreich, also die GEMDATS haben wir dort serviciert, für den
Bereich, war ich nicht zuständig und der Hauptbereich war eigentlich die Bankensoftware,
dort wo der XYZ das Machen und das Sagen hat. Und in diesem Bereich haben wir, ahh, wo
ich die Führung immer tätig war, ich hab dort als Programmierer begonnen auf Groß-EDV-
Systemen, Nixdorf Computer Anlagen, mittlere Datentechnikcomputer, dort waren wir
immer entweder Nixdorf-Anwender oder eben IBM. Diese beiden großem Anbieter haben
sich dort immer so im Wesentlichen am Markt gematcht.
3 Interviewer: Ich versteh
4 Interviewter A: Das ist einmal kurz zu meiner Vorstellung und zu den Softwarebereichen
kommen wir dann wahrscheinlich noch.
5 Interviewer: Ja genau. Bei meiner Masterarbeit geht es ja grundsätzlich um ERP Upgrades.
6 Interviewter A: Wo ich da gleich einhaken muss, ich hab das erst im Absatz darunter
gelesen, dass Sie ja die Softwareupgrades abtesten. Da bin ich mir nicht ganz sicher, ob ich
da der perfekte Ansprechpartner bin. Natürlich ist das immer bei den Upgrades von
Software Releases ein großes Thema und zwar dann, wenn man tausende Installationen
draußen hat. Da war immer das Thema, wir haben eher im XYZ Umfeld eine defensive
Strategie verfolgt, sowohl im Bankenbereich also auch im Waren oder Gemeindebereich.
Ahh, weil man nicht mit zu schnellen Upgrades dann natürlich irgendwelche Terminals
hinten lassen muss wo dann irgendwelche Treiber nicht verfügbar waren.
7 Interviewer:Aber dementsprechend, wenn man dann ein Upgrade durchgeführt hat, waren
dass dann eher größere Versionssprünge, oder?
8 Interviewter A: Da sind es dann eher größere Versionssprünge und wir haben dann das
natürlich im Umfeld bei uns testen müssen, auf mehreren Versionen, ob dass dann auch mit
diversen Druckern, Internetverbindungen, etc., die Drucker und die Scanner sind vor allem
die Probleme. Oder die exotischen Anbindungen wie Kassenladenansteuerungen etc. Dort in
diesem Bereich muss man aufpassen. Wir haben aber immer bei den Updates mitgeteilt,
unter welchen Bedingungen und mit welchen Hardwareteilen oder Komponenten wir
getestet haben. Und wenn ein Anwender eine andere Komponente eingesetzt hat, wie ein
Adler Kassenlade z.B., die nicht in unserer Unterstützungspalette gestanden ist, dann haben
wir gesagt, dass kann funktionieren, muss aber nicht. Das sind immer ein bisserl die
Kriterien, auf die wir aufgepasst haben. Also nur zum Upgrade, unter defensiver Strategie,
kann ich sagen, im XYZ-Bereich, haben wir erst vor 4 Jahren von XP auf Windows 7
umzustellen, also relativ spät im Lebenszyklus. Wir haben von Microsoft im Wesentlichen
ein Betriebssystem übersprungen. Wir sind von XP direkt auf Windows 7 gegangen, und
jetzt bereiten sie gerade vor die Umstellung auf Windows 10, aber da wird man auch noch
warten, erst dann wann dann gute Informationen vorhanden sind, wird upgedatet. Da ist man
relativ sicher unterwegs, man spart den Anwendern erstens mal ein Betriebssystemupgrade
von Microsoft, das sind auch Kosten, man muss dann auch einen neue PC Generation
anschaffen usw.
9 Interviewer: Aber trotzdem, vielleicht können wir nochmal kurz zurück zu ERP Upgrades,
haben Sie da in den letzten paar Jahren mitbekommen oder selbst durchgeführt, ist da ein
ERP Upgrade durchgeführt worden und wie groß ist das Projekt gewesen bzw. wie lange
dauertet dieses Projekt?
10 Interviewter A: Ja das zieht sich, bis der letzte PC draußen im Einsatz ist, das zieht sich über
zwei bis drei Jahre. Also das sind schon enorme Aufwände, weil von uns erstens mehrere

119
 Betriebssystemstände getestet werden müssen und parallel auch gehalten werden müssen.
Wenn man das Beispiel nimmt, weil das ist noch relativ aktuell, von Windows XP auf
Windows 7, das zieht sich über 3 bis 4 Jahren hin, mit allen Komponenten hin, ich schätze,
dass das so in (...) geht, solche Projekte. Aber ich will da jetzt keine Zahlen nennen.
11 Interviewer: Was sind so die Hauptgründe, dass man so ein Upgrade durchführt?
12 Interviewter A: Ja die Hauptgründe sind, das kann ich relative rasch sagen, erstens muss
man am Zug der Zeit bleiben, zweitens ist man speziell von Microsoft getrieben und
verpflichtet, weil XP durch Ankündigungen abgekündigt, und dann ist im
Sicherheitsbereich, mit den softwaretechnischen Sicherheitsvorkehrungen im Bereich, der
Patches, nicht mehr sicher. Du hast eh keine Chance mehr, als, dass du upgradest. Dann
werden die Softwarekomponenten, die ja zum Teil unsere waren, Wirtschaftssoftware
eigentlich von deren Herstellern auch abgekündigt und dann lauft das auch nur mehr unter
Windows 7 oder Windows 10. Und der zweite Grund ist, dass vom Multitasking und von der
Stabilität her, die neuen Microsoft-Versionen, wenn man auf der Microsoft-Welt bleiben
jetzt, wir haben andere Computersysteme ja auch, also Großcomputer, AS400, iSeries, des
unterstützen wir genauso. Dort wo ich daheim bin, die halt im Zentralcomputer oder am
Host am Großrechner oder auf iSeries, aber da ist es im Prinzip genau so ein Host, wo die
ganzen Transaktionsloggings laufen. Also eigentlich ist man immer von Microsoft oder IBM
getrieben, dass die einfach eine Abkündigung einer bestehen Software machen und natürlich
ich versteh das auch, sei es Microsoft oder IBM, dass die nicht hunderte Softwareversionen
weltweit im Einsatz haben und diese warten, das geht einfach nicht. Das kostet ja unendlich
und die Welt dreht sich weiter und man weiß jetzt der Unterschied ist zwischen Windows 7
und Windows 10, weil man es ja selbst betreibt, was da an neuen Features drinnen sind.
Natürlich in der Warenwirtschaftsebene, da möcht ich auch den Unterschied nochmal sagen,
ist es nicht so unbedingt zwingend, dass man immer auf die neueste Version geht im
Vergleich zum privaten. In der Warenwirtschaft, bei Kassenanwendungen ist wichtig, bei
den Anbietern die Stabilität, dass die Treiber verfügbar, dass a Scannertreiber da ist bei den
CheckOutkassen, dass alle sich im Einsatz befindlichen Komponenten funktionieren. Darum
ist dort eher eine defensive Strategie sinnvoller.
13 Interviewer: Dass da jetzt neue Funktionalitäten mit einem neuen Upgrade zur Verfügung
gestellt werden, passiert eher weniger?
14 Interviewter A: Dass da jetzt noch neue, schönere grafische Oberflächen und
Multitaskinggeschichten (...) wie der Privatanwender, im Inselbereich, benötigt, dass is es ja
nicht. Da sitzt ja jemand am Kassenpult und hat die Software zu bedienen und da muss der
Zugriff schnell funktionieren, auf den FileServer etc. und alles andere, und alle Treiber
müssen verfügbar sein, mit den vielen Druckertypen und Scannertypen die im Einsatz sind
und den Scannertypen. Internetanschluss ist dort nicht so entscheidend, dass die Bediener
nicht in der weiten Welt herumsurfen und sich auf die Arbeit konzentrieren.
15 Interviewer: Wenn man jetzt so ein ganzes Upgrade Projekt ansehen, es wird entschieden es
wird so ein Projekt durchgeführt. Was glauben Sie, dass die kritischen Faktoren sind, welche
unbedingt durchgeführt werden, damit man in Summe sagen kann, das Projekt hat seine
Ziele erreicht und ist erfolgreich durchgeführt worden?
16 Interviewter A: Okay, wir machen bei jedem Projekt ein Review, es gibt Soll-Vorgaben von
den Stunden, eine geschätzte Vorgabe, den vergleicht man natürlich zum Ist-Aufwand und
das muss von den Anwendern im Wesentlichen finanziert werden. Das ist dann erfolgreich
und b, dass es keine Crashes gibt, dass die Software wirklich überall mit den Komponenten,
mit allen (...) die draußen verfügbar sind, auch funktioniert. Wir haben natürlich bei
Versionsupgrades schon dort und da hingewiesen, speziell bei Direktdruck, z.B., bei den
Bondruckern, da haben wir jetzt bei der neuen Version alte Bondrucker nicht mehr
unterstützt. Das sind auch Erfolgsfaktoren, auf die man aufpassen muss. Das darf man nicht
vergleichen mit einem Home Office.
17 Interviewer:Sind bei solchen Projekten bereits einmal gröbere Probleme aufgetreten, die
man besonders managen musste?

120
18 Interviewter A: Immer wieder, gerade beim Umstieg, dasist jetzt über 20 Jahre her, da hat
die seinerzeitige Warenwirtschaft, das Management, und die Entscheidung selbst in Hand zu
nehmen, da waren wir ein wenig außen bei und hat sich einen Softwarehersteller in
Deutschland selbst ausgesucht, über IBM, da war der Streit zwischen Nixdorf, also unsere
Empfehlung, und der Schwenk Richtung IBM und dort hat man, geglaubt, man geht auf eine
Standardsoftware von IBM und das ist komplett in die Hose gegangen. Dann ist das
Management dort ausgetauscht worden und es hat auch personelle Konsequenzen gegeben
und ist dann die Verantwortung wieder zu uns ins Rechenzentrum gegangen. Wir haben aber
dann nach intensiver Prüfung, das was dort schon entwickelt worden ist, haben wir gesagt
OK, da ist schon sehr viel gemacht worden, wir setzen dort fort, weil grundsätzlich ist der
Ansatz nicht verkehrt. Wir haben aber dann die Problemfelder analysiert und haben die
beseitigt. Das größte Problem war, dass man da einen falschen Softwareanbieter aus
Deutschland gewählt hat. Wir haben das Projekt dann komplett selbst übernommen und wir
haben das bereits bestehende als Basis genommen und weiterentwickelt.
19 Interviewer: Welche Merkmale sind dafür verantwortlich, dass man Upgrade Projekte als
erfolgreich definieren kann?
20 Interviewter A:Ahh, da setze ich jetzt nicht auf die alte Geschichte, ich bin jetzt auch
Projektbegleiter bei neueren Entscheidungen bei der XYZ zum Beispiel gewesen. Jetzt geht
es eher darum, ERP Projekte, geht man Richtung Standard-Software, sprich SAP, das ist der
klassische Anbieter oder Microsoft Dynamics. Mit denen ich mich jetzt in letzter Zeit oder
in den letzten 10 Jahren stärker beschäftigt habe und habe Firmen in diese Richtung
begleitet und da geht es eher in die Richtung. Passe ich mich als Unternehmen dem
Standard, dem quasi internationalen ERP Standard wie SAP an oder will ich individuell im
Prozess bleiben. Und da habe ich in der Prozessbegleitung fünf Unternehmen begleitet und
bei einer Entscheidung habe ich selber für SAP votiert und bei den anderen eher für eine
flexible Lösung wie z.B. Microsoft Dynamics oder auch andere Unternehmen. Und das
muss man individuell betrachten. Und da ist mir quasi immer aufgefallen, man muss prüfen
als Unternehmen, will ich mich dem Standard im Betriebssystem und im Ablauf, im Prozess
in der Produktion dem Standard anpassen oder will ich das nicht und will ich hier individuell
bleiben mit diversen Vor- und Nachteilen. Und da war ich eigentlich auch relativ stolz auf
mich oder auf unser Unternehmen, dass ich da eigentlich mit meiner Einschätzung immer
sehr gut und richtiggelegen bin.
21 Interviewer: Wenn ich jetzt aber die Software sehr stark anpasse an meine Bedürfnisse, an
meine Prozesse, sehr stark customize sozusagen, kann das dann später bei eventuellen
Upgrades wieder zu Problemen führen?
22 Interviewter A: Also wir haben nie empfohlen, wenn ich vom Standard stark abweiche, dann
ist eine Standardlösung wie SAP eher nicht zu empfehlen. Wenn ich bereit bin mich dem
Standard anzupassen und dort nur z.B. Drucklayouts ändere, aber nicht im Kernprozess
eingreifend, bewege, dann ist das durchaus eine sinnvolle Lösung, weil bei den
Standardanbietern ist jedes Upgrade eine horrende Geschichte, die sind nicht im Preis
enthalten, etc. Gewisse Upgrade sind natürlich aber auch bei den anderen erforderlich, weil
wir haben uns auch intensiv beschäftigt mit Dynamics, das ist ja auf C#, das ist ja eine
objekt-orientierte Geschichte und ich bin jetzt ein Verfechter, und ich kenne jetzt die alte
Geschichte, die klassische Entwicklung von uns direkt, Basissoftware von Deutschland, von
einem deutschen Anbieter. Da musst du halt alle Komponenten de facto immer upgraden,
das muss im Wesentlichen auch die Anwendergruppe zahlen. Aber die Upgrades sind nicht
ohne. Aber der große Vorteil von so quasi objekt-orientierter Technik, ist der, dass die
Objekte relativ klein gekapselt sind und dass auf diese Objekte alle möglichen Programme
zugreifen. Die klassische Programmierung, wie es in der älteren Softwaretechnik ist und so
wie ich es noch gelernt habe, dass ich ein großes Auftragsprogramm habe und dort drinnen
ein Artikelnummer und -findungsmodul drinnen ist, aber das kann ich wieder nicht
verwenden in allen anderen Programmen. Bei der objektorientierten Technik ist, ich
schreibe mir ein Modul Artikelnummerfindung und dieses Modul rufe ich aus allen

121
 Programmen auf. Und da drinnen ist zum Beispiel die ganze Plausibilitätsprüfung, ist dort
eine EAN-Nummernfindung, eine Prüfziffernrechnung, etc. Das ist alles da drinnen und
funktioniert in allen Objekten, da brauche ich Ihnen als Informatiker auch nichts erzählen.
Und das ist der große Vorteil von den ganzen neuen objekt-orientierten Systemen, dass sie
dann bei Upgrades viel schneller auf der neuen Version sind. Das ist der gravierende
Vorteil. Wenn ich also viel individuelle Programmierung mache, so wie die XYZ, die gesagt
hat bei der Entscheidung, ich will nicht in Richtung Standard gehen, weil wir wollen
individuell bleiben. Die Software soll im Prinzip, das umsetzen, was ich als langjährige
Erfahrung im Betriebsprozess habe und nicht umgekehrt. Da muss ein Unternehmen sich
einmal grundsätzlich bei der Softwareauswahl in sich gehen, von der Unternehmensführung
von der Unternehmensphilosophie und am Anfang ein bisschen mehr Geld in die
Softwareimplementierung investieren, ist aber dann mit dem objekt-orientierten Ansatz
schneller, nicht schneller in der Erstimplementierung am Ziel, sondern in der Langfristigkeit
und in der Modernität. Das sind meine Erfahrungen und ich habe eher dann in der
Empfehlung immer eher in Richtung der neuen Methoden, Richtung Objektorientierung, ich
nenne es einfach objektorientierte Basissoftware, die also von einer stärkeren Layer-Struktur
geprägt ist und die tieferen Schichten, dass man da eher weniger eingreift. Nur, viele
Unternehmen können sich am Anfang da nicht so abfinden, weil die IT-Abteilungen in so
einem Unternehmen, bleiben wir beim Beispiel XYZ, ist natürlich stärker gefordert bei der
Implementierung. Da musst du dich einmal hinsetzen, bleiben wir mal alleine beim
Drucklayout. Ich muss einmal definieren, wie schauen meine Printouts aus, dort ist sowieso
für die ganze Drucktechnik, für die ganze Auftragsbearbeitung und die klassischen
Papierproduktionen wie Rechnung etc., was in einem ERP System eigentlich das zentrale
Element ist. Das muss funktionieren und da muss die Artikelnummer und der Kopf und der
Fuß so ausschauen, dass der Kunde zufrieden und der sich wiederfindet. Weil die
Drucktechnologie, es wird heute generell in eigene Layer ausgelagert, wo ich irgendwelche
Listreports-Systeme, da gibt es ja von Microsoft Systeme oder andere Anbieter, dass man
das von der Softwareentwicklung abkoppelt.
23 Interviewer: In der Literatur werden folgenden Faktoren für den Erfolg eines
Implementierungsprojektes genannt:
24 Bitte beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der
Skala (sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig).
25 Interviewter A: OK
26 Interviewer: Top Management Unterstützung
27 Interviewter A: Ja ist sehr wichtig. Wenn man sich entscheidet, SAP oder nicht SAP, dann
muss das Management voll dahinterstehen, weil da wird ein Weg eingeschlagen in eine
Richtung oder in eine völlig andere Richtung. Und da darf es nicht passieren, dass da ein
Teil sagt, ahhh, ich hätte es eh lieber in die andere Richtung gesehen. Weil da geht es so. Ich
mein es kann nicht, ich denk da immer an ein Pferdefuhrwerk, es kann nicht sein, dass ein
Pferd in die eine Richtung zieht und das andere in eine andere. Das geht sich in die Steine.
28 Interviewer: Und das ist nicht nur bei der Implementierung, sondern auch beim Upgrade
wichtig, oder?
29 Interviewter A: Ja, das muss man durchziehen. Weil am Anfang bei der Einführung gibt es
ein paar Hoppalas und dann darf man nicht sagen, das war ein falscher Weg, da muss man
dabeibleiben, weil sonst wird es echt teuer. Ich kann nicht, wenn ich mich z.B. für Dynamics
entscheide und ich gebe denen zu wenig Vorgaben, die die Implementierer sind, dann kann
es auch gefährlich werden. Ich muss, du bist als IT-Abteilung oder als
Bereichsverantwortlicher, die sind gefordert. Ich muss dann de facto denen sagen, wie die
Berichte auszuschauen haben und über das Berichtswesen komme ich ja zu Input. Was muss
in der Maske stehen, dass ich dann Output zusammenbringe.
30 Interviewer: Change Management
31 Interviewter A: Ja, da darf man nicht vergessen, dass man eine Art Key-User System, in der
Einkaufsabteilung, in jeder Abteilung, definierte Key-User, die das Projekt mittragen, mit

122
 testen, und dann dort in der Abteilung verteilen. Also rechtzeitig schulen.
32 Interviewer:Das passt dann eh gut zu weiteren Punkten, ich habe dann später auch noch
User-Training & Schulung.
33 Interviewter A: Ja wir sind mit diesem System relativ gut gefahren, mit sogenannten Key
Usern, in jeder Abteilung, in jedem Fachbereich, Einkauf, Verkauf, Lager,
Logistikabteilung, Berichtswesen, Buchhaltung, Rechnungswesen. Die sind verantwortlich
vom Projektstart bist zum Rollout diese Umsetzung mitzutragen. Die haben immer die
Verantwortung, wir haben das auch schriftlich eingefordert, Key-User-Tests, etc. , wenn ein
Bereich fertig ist haben die das abnehmen müssen mit einer Unterschrift.
34 Interviewer: Ein weiterer Punkt, den da ich da habe ist Business Plan & Vision
35 Interviewter A: Beim einem Upgrade ist das eher nicht wichtig, ich muss nur intensive Tests
machen und es müssen die gesamten Funktionen wieder funktionieren. Keine Frage.
36 Interviewer: Projektmanagement
37 Interviewter A: Projektmanagement ist ganz wichtig. Das irgendwer die ganzen Zyklen in
der Hand hat und die Termine vorgibt. Und wenn es irgendwo Bretzeln gibt, dass man das
dann Gesamtsystem, das hängt dann natürlich mit dem Roll-Out zusammen, wenn ich zuerst
plane, dass ich mit Jahresbeginn starte und ich komme dann nicht zusammen, dann hat das
schon eine große Konsequenz. Wenn ich jetzt einen sanften Umstieg schaffe, nennen wir das
mal so, z.B. am Wochenende, dann ist das egal, wenn ich die Umstellung um 3 Wochen
verschiebe, es sei denn, es ist notwendig, dass an einem genauen Termin bereits die neue
Software eingesetzt werden muss, dann sind das natürlich schon Abhängigkeiten.
38 Interviewer: BPR & Anpassung der Softwarelösung
39 Interviewter A: Bei einem Upgrade ist das nicht mehr wichtig, das ist nur bei der Einführung
wichtig
40 Interviewer: Zusammensetzung der ERP Team
41 Interviewter A: Die Key-User, die Verantwortlichen in einer Abteilung, die sind da sehr
wichtig, meiner Meinung nach
42 Interviewer: Software Testing
43 Interviewter A: Sowieso, das ist sehr wichtig!
44 Interviewer: Business Case
45 Interviewter A: eher weniger wichtig!
46 Interviewer: Projekt Champion
47 Interviewter A:ahmm, braucht man nicht unbedingt, weniger wichtig!
48 Interviewer: Kommunikationsplan!
49 Interviewter A: Die Kommunikation ist immer wichtig, in jedem Projekt, also gute
Kommunikation zwischen allen Beteiligten, also ja, sehr wichtig
50 Interviewer: Management von Legacy Systemen
51 Interviewter A: Da geht es eher um die Schnittstellen, dass die ineinandergreifen. Also ich
war immer ein Verfechter, das Alt-Systeme weiterlaufen. Wenn ich ein Neusystem einführe,
war ich immer der Meinung, dass es auch möglich ist, dass nur Teile ausgetauscht werden.
Somit habe ich nicht so einen Big-bang. Ich muss halt dann schauen, dass die Schnittstellen
passen.
52 Interviewer: Hersteller-Unterstützung
53 Interviewter A: Da muss man unterscheiden, bei SAP ist die Hersteller-Unterstützung sehr
wichtig, wenn ich Richtung Microsoft gehe, da hat man eher Softwarepartner die am Markt
stark sind. Ist aber bei SAP auch so, dass es da eine starke Beraterrolle gibt. Also ich muss
eine gute Beratung haben.
54 Interviewer: Post-Implementierungs-Evaluierung
55 Interviewter A: Habe ich eh schon vorher erwähnt, finde ich sehr wichtig. bei den Reviews
ist bei uns wichtig gewesen, hat es Probleme gegeben und auch kostenseitig. Wie viele
Mannstunden wurden geplant, wie viele sind es dann geworden. Aber auch Verbesserungen,
was kann ich beim nächsten Release oder Upgrade besser machen, um quasi die Fehler zu
vermeiden. Ist im Prinzip eine Fehlervermeidung, was ist gut gelaufen, was ist schlecht

123
 gelaufen. Was kann man beim nächsten Projekt besser machen.
56 Interviewer: Somit sind wir am Ende, danke für das Interview
57 Interviewter A: Gerne

124
 C.2 Transcript Interview B
1 Interviewer: Die erste Frage wäre einmal, könnten Sie vielleicht, oder könntest du vielleicht
einen kurzen Überblick über deine Aufgabe und inwieweit du sozusagen mit ERP Upgrade
Projekten in letzter Zeit zu tun gehabt hast?
2 Interviewter B: Ok. Also wir haben vor ca. 5 Jahren SAP eingeführt bei uns im
Unternehmen, haben damals gestartet mit SAP EHP 4. Das war damals der aktuelle ahh,
EHP Stand der von der SAP ausgerollt worden ist und wir haben damals schon das Thema
gehabt, dass wir ein EHP Upgrade sogar vorgesehen hätten in der Einführung. Das war aber
dann doch zu kurzfristig und ahh jetzt haben wir uns dann letztes Jahr entschlossen, dass wir
das ganze Thema nochmal aufrollen, weil wir jetzt gerade in der Produktion die ganzen
Prozesse umstellen. Also ahh... wir haben da ein großes Reorganisationsprojekt dann,und im
Zuge dessen haben wir auch gleich gesagt dann, wir wollen ahh auch dahingehend, dass
auch eventuell SAP HANA irgendwann ein Thema wird ahhh und da EHP 7 bzw EHP 8
Voraussetzung ist für Migration nach HANA, habenwir dann gesagt, ok, wir machen da ahh
um bei der Einführung von diesen neuen Prozessen, gleich auf den letzten Stand zuzugreifen
können, weil es sind ein paar Funktionen drinnen, da haben wir schon gewusst, die würden
uns unterstützen und somit habe ich gewährleistet, dass ich da optimal für dieses Projekt
aufgestellt bin.
3 Interviewer: Ok. In welchem Umfang befindet sich dieses Projekt ca. also wie lange dauert
das?
4 Interviewter B: Das Projekt selbst, wir haben ahhm ungefähr ahm wart einmal, ich hab
nämlich einen Projektplan, das ist nämlich doch schon relativ lange her. So, ahm ...ah, da
hab ich den Projektplan. Ahm, wir haben, also gestartet hat das. Das haben wir letztes Jahr
im Juni gestartet, ahm. Es war so aufgeteilt, dass wir als erstes in der IT, das wir in der IT
die Themen soweit einmal migriert haben, also diese ganzen technischen Voraussetzungen
einmal zu schaffen, dass eben eine Schatteninstanz aufgebaut wird, ah, dass die, die, dass
wir in der Entwicklung einmal schauen, was, dann muss man einen Abgleich machen, das ist
dann ein Vergleich, was muss ich jetzt mehr oder weniger, was muss man berücksichtigen,
welche Programme könnten betroffen sein und diese Überprüfung hat ungefähr ein bis zwei
Wochen gedauert. Nach diesen zwei Wochen hat es dann eine Phase gegeben, wo dann die
Keyuser dann, wo wir dann ca. 2 Wochen lang die Keyuser gehabt haben zum Testen, ahh,
das heißt wir haben einen Integrationstest dann gemacht mit allen SAP Keyusernbzw. auch
unterstützend teilweise User aus den Fachabteilungen. Das hat von genau von 6. Juni bis
zum 18. Juni, 2 Wochen hat das gedauert. Ahm, Freitag am Wochenende ist dann das Ganze
dann durchgelaufen also diese ganzen Reorganisations- und Updateprozesse und am Montag
sind wir dann live gegangen.
5 Interviewer: Ok. Das ist eigentlich dann relativ schnell gegangen!
6 Interviewter B: ahm. Das ist an sich relativ schnell gegangen. Also von daher, also diese, wir
haben geschaut, dass wir diesen Integrationstestteil kurzhalten, ahm, weil du hast ja dann
trotzdem in dieser Phase wo du quasi diesen EHP Upgrade dann mal beginnst, kannst du
nichts ins Produktivsystem migrieren oder transportieren. Also du entwickelt, weiß nicht
inwieweit du technisch...
7 Interviewer: Nicht so tief ...
8 Interviewter B: Also es ist ja so, du, man entwickelt ja immer in einem Entwicklungssystem,
hat dann teilweise ein Q-System und dann gibt es eine sogenannte Transportschiene und die
Transportschiene heißt ich muss meine Änderungen vom Entwicklungssystem ins
Produktivsystem oder über das Q-System transportieren um dann die Sachen produktiv zu
setzen, d.h. die machen nie eine Änderung direkt im Produktivsystem
9 In dieser Phase bist du, hast du dann einfach nicht, kannst du nicht, keine Änderungen
durchführen. Außer kritische Sachen, dann sperrt man unter Anführungszeichen das
Produktivsystem auf, ändert da drinnen wirklichen den Code, sperrt wieder zu und muss
dann schauen, dass beide Systeme gleich sind, weil wenn du dann im Nachhinein im
Nachgang wieder mit irgendwas kommst, dann würdest du das wieder überschreiben.
10 Interviewer: Ja, ich verstehe schon.

125
11 Interviewter B: Also, wir haben, für das ganze Upgrade haben wir ca. 50 Tage gehabt. Also
das ist im Mai ist es losgegangen, und also 5. Mai ist es losgegangen und 20. Juni waren wir
dann fertig und sind live ...
12 Interviewer: Ah, ok. Cool. Was waren so die Hauptgründe warum dieses Upgrade
durchgeführt worden ist? Das hast du eh schon ein bisschen erwähnt am Anfang!
13 Interviewter B: Das habe ich. Genau. Also zum einen, durch die Einführung von, ahm, dass
wir eine Reorganisation in der Produktion haben, ahh, wo wir SAP-PP eigentlich jetzt
wirklich einführen, weil das haben wir aktuell jetzt nur ahhm, sag ich einmal, kratzen wir so
ein bisschen an, also relativ einfache Arbeitspläne, aber wir machen dort wirklich von
Montageprojekte, also von Montageproduktion, auf Lager legen, da wird jetzt momentan
grad intern sehr viel umgestellt, auch baulich und zur Unterstützung wollten wir das Ganze
auch, wird das ganze natürlich auch im SAP umgesetzt, bzw. wir, da sind auch andere
Themen. Also das geht los von, ahh, dass ich, dass ich meine, momentan machen die
Terminplaner in der Projektierung, haben da aber jetzt also nicht in der Projektierung, in
dem PS-System, haben aber da ahh jetzt nicht die detaillierte Planungsmöglichkeit, wie das
PP machen kö[Link], wenn wir sagen, wir führen das jetzt ein, dann wollen wir den
letzten Stand haben, weil das war bei der Einführung, eh wie ich schon gesagt hab, gibt, es
gibt ein paar so Sachen, die sind dann, die werden halt dann freigeschalten und die wären
halt super und wenn du die dann nicht hast, und du weißt du hast sie, dann musst du wieder
mit Workarounds arbeiten und deswegen haben wir gesagt, wenn wir, wenn wir da schon
was machen, dann sollten wir zumindest den letzten EHP Stand haben, und zusätzlich ist
natürlich auch die Vorbereitung Richtung SAP HANA auch gedacht, wobei das jetzt
momentan kein Thema ist, aber es ist einmal Basis. Die zwei Themen haben uns eigentlich
dahin entschieden.
14 Interviewer: Ok. Was sind so die Hauptziele die definiert worden sind, also Ziele für das
Projekt, die umgesetzt werden sollen?
15 Interviewter B: Da sind, dass wieder alles so funktioniert wie vorher.
16 Interviewer: Ok, ja. Naja, das habe ich jetzt schon öfter gehört.
17 Interviewter B: Ahh, das ist, das ist sicherlich natürlich, aber wir haben uns natürlich im
Zuge dessen haben wir und gleich angeschaut, wir haben den Retourwagenprozess zum
Beispiel, das war eben so ein Workaround, wo, wo SAP eigentlich im Standard viel mehr
unterstützt, in dem, in den EHP 5 aufwärts Versionen. Das haben wir uns gleich angeschaut
und haben dann versucht, dass wir da die, die Umsetzung dann auch machen, und im
Einkauf hat es ein paar so Themen gegeben, bzw. PS-System sind ein paar Sachen
hinzugekommen, ahh. Das Ziel ist natürlich dann diese Features im Endeffekt dann zu
nutzen, und schauen, dass man das dann nicht mehr mit Workarounds, sondern eben im
Standard dann auch verwenden kann.
18 Interviewer: Sehr gut. Ahm, ja. Somit kommen wir dann eigentlich schon zum Hauptteil von
meiner Arbeit. So, was sind, was glaubst du sind die kritischen Erfolgsfaktoren von solchen
Projekten? Was, was muss passieren, damit so ein Projekt erfolgreich umgesetzt werden
kann?
19 Interviewter B: Testen. Also bei unserem, bei uns war es so, wir haben, wir haben ahhh,
eigentlich in der Vorphase, also in der Vorprojektphase, also bevor wir da jetzt die
eigentlich zur Umsetzung gekommen sind, haben wir aber, haben wir schon Themen gehabt,
dass wir eben ein Drehbuch geschrieben haben für den Integrationstest, sprich, es hat, ein
Kollege von mir hat da einen, da muss ich jetzt schnell schauen, die Testpläne, da haben wir
ca., wann haben wir da angefangen, da haben wir angefangen im Jänner, da ist es eigentlich
schon losgegangen, dass wir ahhm Testfälle definieren mit den Keyusern, also, das heißt,
das System verändert sich. Also wir haben, haben so ein Drehbuch beim Go-live gehabt und
die Prozesse ändern sich natürlich ständig oder vor allem verbessert oder es wird, oder es ist,
wieder, oder sind ja nicht mehr aktuell. Und jetzt ist es auch darum gegangen die Keyuser
soweit mit an Boot zu holen, mit an Boot zu holen, dass man sagt, welche sind wirklich die
relevanten Prozesse, die wir durchtesten sollen. Wir haben dann ca. eine Liste von über 300

126
 Testfälle gehabt, war einmal, da muss ich schnell schauen, also es hat dann ein Drehbuch
gegeben für die unterschiedlichen Kernprozesse, also wir haben, in dem Fall haben wir drei
Kernprozesse, das war der Anlagenauftrag, also unsere großen Projekte, dann der
Ersatzteilprozess, wo es darum geht, das Ganze, die ganzen Ersatzteilnachlieferungen zu
managen und der Kundendienstprozess, also quasi die Abwicklung, Customerservice und
das ganze was dort auch passiert. Zusätzlich hat es natürlich dort begleitende Prozesse
gegeben wie Buchhaltung, Lohnverrechnung bzw. diverse Schnittstellen zuanderen
Systemen, ahh ja, und da haben wir dann im Endeffekt ein Drehbuch geschrieben, also,
primär mein Kollege, und der hat, da sind halt diese Themen dann zum Teil dort
aufgegliedert worden, welche Transaktionen betreffen das, ahm, durch wen wird es getestet,
wer ist notwendig dazu, wer sind meine vorgelagerten Informationen die ich brauch zum
Testen vom Prozess, wer ist dann nachgelagert? D.h. und das haben, das haben wir zum
einen mit den Keyusern durchgearbeitet, dass sich diese einmal Gedanken machen, dass
man diese mit an Boot holt, und auch transportiert wie von der Wichtigkeit war es eigentlich
eh fast jedem klar, was notwendig ist, dass das notwendig ist, um eben auch Funktionalität
100%ige Funktionalität zu gewährleisten. Annähernd zumindest.
20 Interviewer: Habt ihr externes Consulting dabei gehabt bei diesem Projekt?
21 Interviewter B: Wir haben an sich kein externes, also wir haben schon, wir haben einmal
einen Tag gemacht, also wir haben zwei Tage eingeplant gehabt, wo wir alle Berater, die wir
beim Einführungsprojekt dabeigehabt haben eingeladen haben, ahh, weil wir wollten da
eigentlich so ein bisschen heraushören was welche, wo sind, wo sind aus der Sicht der
Berater, wo ist der Mehrwert, oder wo sind Features die wir vielleicht uns dann konkreter
anschauen sollten. Der Workshop war eher für die "Kathitant", wie man so sagt, also das,
den hätten wir uns sparen können. Also natürlich man hat ein paar Sachen schon gehabt, wo
man gesagt hat da schaut man ein bisschen rein, es hätte im Endeffekt auch dort gereicht, wo
wir uns ein bisschen, wo man sich einfach abstimmt, und man sagt, es ist auch nicht jeder
Berater arbeitet schon mit einem neuen System, das kommt auch oft dazu, also wir haben
relativ bald mit dem, mit dem EHP Upgrade eigentlich dran. Also in dieser, diesem Sprung
ahh, hat der oft einmal nicht gewusst, was ist jetzt neu, oder sie haben jetzt in dieser Tiefe
sich auch noch nicht beschäftigt damit, muss man auch dazu sagen. Der eine ein bisschen
mehr, der andere sagt ja, phu, er hat das Feature schon einmal gehabt bei einem Kunden,
und das hat er schon mal gehört aber es ist dann trotzdem.
22 Interviewer: d.h. sie haben zusammengefasst nicht so unbedingt das was man sich vielleicht
erwartet hätte.
23 Interviewter B: Wir hätten uns ein bisschen mehr erwartet, muss man schon sagen. Aber das,
ahh, da da haben wir dann, da muss man sich einfach ein bisschen durch die Dokumentation
auch durcharbeiten. Also es gibt gottseidank SAP Dokumente zum, wo du, wo dann drinnen
steht ok, mit diesem EHP Upgrade bekommst du jetzt die Features dazu, da muss man sich
das halt dann in der Doku ein bisschen anschauen, und dann herausfischen, was wäre denn
interessant, oder wo könnte man welchen Prozess da vielleicht auch draufsetzen.
24 Interviewer: Ok. Sind bei euch im Projekt dann irgendwelche Probleme aufgetreten, im
Nachhinein gesehen, und wie hat man die gelöst, wenn welche aufgetreten sind?
25 Interviewter B: Bei uns war es immer so, wir haben in der Früh, zu Mittag und am Abend,
haben wir, haben wir uns getroffen, d.h. das war das Kernteam mit ca. 10 Leuten, also das
sind so die Haupt-, Kernuser gewesen, die wir da dabeigehabt haben. Ahhh und haben uns
dann immer abgestimmt, ob es irgendwo Probleme gegeben hat, wo Probleme aufgetretenen
sind, ahh haben dann, ahh, im bei uns, wir haben das über den Sharepoint gemacht, haben
dann im Sharepoint das dann auch mitprotokolliert, wann zum Beispiel ein Prozess nicht
funktioniert hat, dass dann sofort die Modulbetreuer, unsere internen SAP Betreuer, dass sie
diese Themen gleich anschauen, kontrollieren, prüfen, Programmänderungen dann machen
und das dann rückmelden. Ah ja, das, das hat sich auf jeden Fall ausgezahlt, also grad diese
Abstimmung, weil man ja sehr oft einmal der Verkauf, die, legt einmal ein Projekt an, oder
legt den Auftrag an, dann geht das weiter in die Projektierung, die Projektierung muss das

127
 weitergeben an das KP und diese Abstimmung wird natürlich auch untertags mit Telefon,
aber ist dann oft einmal so, ok, die testen am Vormittag, und zu Mittag setzt man sich dann
zusammen und sagt: So, wir sind jetzt fertig. Burschen, ihr könnt jetzt anfangen im KP, dass
ihr die Stücklisten reinhängt und die Bedarfe auslöst und und das macht, das hilft eigentlich
auch recht gut, weil, ahh, bei der Einführung haben wir das so gehabt, da haben wir uns
wirklich unten bei unserem Speisesaal haben wir uns glaub ich mit 40 PCs oder was
eingesperrt, und haben dort unten wirklich intensiv getestet. Jetzt haben wir gesagt, das ist
jetzt eigentlich nicht mehr so notwendig, aber dadurch, dass wir nicht mehr diesen neuen
Kontakt gehabt haben, haben wir dann trotzdem gesagt, wir müssen uns einfach untertags
dann mehrfach abstimmen, dass das dann auch durchgehend lauft und das war sicherlich
auch durchaus sehr wichtiger Teil von dem ganzen Projekt.
26 Interviewer: Ok. Eine Frage habe ich dann noch ein bisschen zum zur Definition von
Erfolgreich, wie würdest du sagen, anhand welcher Merkmale kann man sagen: "Das Projekt
ist erfolgreich durchgeführt worden."
27 Interviewter B: Erfolgreich sicherlich dahingehend, wenn du am Wochenende das System
dann upgegradet hast, dass dann am nächsten Tag dann ganz normal weiterarbeitest ohne
irgendwelche Zwischenfälle. Das hat sich im Zuge dessen, es hat schon einen, es hat einen
Punkt dann gegeben, wo sich herausgestellt hat, wir können thailändische Kunden nicht
beliefern, weil die irgendein eigenes Mehrwertsteuersystem haben und das muss eingepflegt
sein, und wenn das nicht ist, dann geht das nicht ahh, aber das ist, das ist in der Summe dann
einfach auch für die, für die Leute draußen dann auch wichtig, dass sie sehen ok, das hat
jetzt alles funktioniert, das hat gepasst, also wir haben sauber getestet, ahh, die Keyuser
haben einfach ihren Job gemacht und haben das zu 100% dann einfach auch geschaut, dass
das auch wirklich dann lauft. Ahh, das ist sicherlich einer von den Erfolgsfaktoren, ahh, dass
man dann im Zuge dieser Über- also Abarbeitung der Möglichkeiten, oder dieser
Verbesserung, die mit dem EHP Upgrade kommen, dass man das dann auch sicherlich dann
aufbereitet und mit den Keyusern in den nächsten Wochen und Monaten dann durchzieht, ist
sicherlich der längerfristige Erfolg dann von dem ganzen Projekt.
28 Aber primär, das System muss laufen, das ist ganz klar. Wenn irgendetwas nicht geht, dann
haben wir das Problem.
29 Interviewer: Ahm. Ja und ein weiterer Teil, ich würde gern auch noch ein bisschen so quasi
herausfinden was jetzt die größten Unterschiede sind zwischen Implementierungs- und
Upgradeprojekten bezüglich Erfolgsfaktoren, wo glaubst du, dass da die größten
Unterschiede sind?
30 Interviewter B: Bei der Implementierung, ich sag immer bei der Implementierung, du kennst
das System noch gar nicht, mit dem du eigentlich arbeitest. Das ist eigentlich, das, ahh, das
was der große Unterschied ist. Weil du hast natürlich, wir haben eine die Vorprojektphase
hat, war ca. 1 dreiviertel Jahr, ahh, mit Start der Einführung, du lernst relativ spät SAP
eigentlich erst kennen und auch zu verstehen. Also du hast zwar die Berater bei der Hand,
bei der Einführung und bist eigentlich einmal froh, wenn deine wichtigsten Themen im SAP
abgebildet sind und das, der große Unterschied zum EHP Upgrade ist der, dass, das du das
System dann schon kennst, du weißt wie es tickt, du weißt was geht, was nicht geht und du
weißt dann im Endeffekt mit einem EHP Upgrade bekommst du das oder das dann dazu, das
du dann auch nutzen kannst. Also das Verständnis ist dann einfach eher gegeben, dass ich
eben diese neuen Features dann auch schneller verstehe und auch umsetzen kann. Im
Vergleich zu einer Einführung ist es einfach so, dass man, das ist durchaus, ich vergleiche es
also wie mit Auto, ich mache den Führerschein, ich weiß wie ein Auto aussieht, ich weiß
was das für, was das kann, aber so richtig handling-mäßig oder spüren tue ich das noch nicht
und das lernt man und diese Erfahrung die bekommt man einfach mit und die, die das ist zu
dem Zeitpunkt der Einführung einfach so, wenn du da live gehst, das hast du einfach noch
nicht. Also das ist einfach das Hauptproblem, sag ich jetzt einmal.
31 Interviewer: Ok. Ahm. Ich habe ein bisschen so in der Literatur recherchiert, da gibt es
ziemlich viele Publikationen zum Thema Erfolgsfaktoren bei Implementierungsprojekten.

128
 Ahm. Ich habe da jetzt ein paar aufgeschrieben, ich würde dich bitten, dass du mir da
einfach so vielleicht kurz von sehr wichtig bis nicht wichtig sagen könntest inwieweit das
auch für Upgrade-Projekte relevant ist? Das erste wäre einmal Top-Management Support
oder Top-Management Unterstützung?
32 Interviewter B: Das ist, das ist bei einem EHP Upgrade genauso notwendig, aber es kann
natürlich auch da Probleme auftreten und dann muss einfach das Management auch hinter
dir stehen, und sagt ok, wir brauchen Berater, wir brauchen Ressourcen, wir brauchen, ahh
wir dürfen verschieben, weil es ist, es hängt ja trotzdem sehr viel an Ressourcen also, ahh,
daran, und das ist einfach auch Zeit und Geld was man bindet.
33 Interviewer: Das zweite ist Change-Management?
34 Interviewter B: Ist dahingehend nicht so wichtig meiner Meinung nach, weil ahh bei der bei
der Umsetzung ja du jetzt nicht großartige Veränderungen machst. Das haben wir, wir haben
auch, wir haben im Projekt eigentlich auch definiert, dass wir jetzt keine neuen ahh, es gibt
ja sogenannten Business Functions, so heißen diese, kann man Business Functions dazu
aktivieren, die werden eher zum Beispiel durch ein EHP Upgrade dann freigeschalten. Ahh,
und wir haben im Zuge dessen auch ganz klar gesagt, dass halt diese Business Functions und
das war damals auch das Thema mit dem Berater, welche Business Functions sind da dazu
gekommen, was gibt es jetzt neu, ahh und das haben sie uns dann nicht so richtig sagen
können und noch auf ein paar hinweisen. Aber da, haben wir dann gesagt, nein, wir machen
keine und wir lassen das einmal so stehen, weil einfach, sonst würde das den Projektrahmen
sprengen. Du machst ein Upgrade von einer Funktion und du weißt nicht wie sich diese
verändert, wenn du diese Business Function auf einmal aktivierst.
35 Interviewer: Ok. Ah. Der nächste Punkt wäre Business Plan und Vision?
36 Interviewter B: Naja, nein, das ist nicht so wichtig.
37 Interviewer: Projektmanagement?
38 Interviewter B: Ist sicherlich wichtig also, dass man, dass man sich zumindest
Projektkommunikation auf jeden Fall, gerade Abstimmungen und natürlich auch ein
gewisser Projektzeitplan, muss einfach auch eingehalten werden.
39 Interviewer: Ah. Business Process Reengineering also habt ihr Prozesse auch geändert?
40 Interviewter B: Mmmh, also es hat nur eine kleine Änderung gegeben. Das war eh der
Retourwarenprozess, wo wir dann auf einmal gesehen haben, das bringt uns gleich etwas.
Den haben wir aber auch erst im Anschluss nach dem wir quasi live gegangen sind, in
diesen, und die nächsten zwei Wochen haben wir dann Sachen ausprobiert und dann auch
geändert, aber in der, das war eben auch gleich zu jetzt mit Change-Management, also es ist,
wir haben, du machst jetzt keine Veränderungen oder tust jetzt irgendwelche
Projektprozesse reengineeren.
41 Interviewer: Ja, ok. Dann, also Zusammensetzung vom ERP Projektteam? Also die richtigen
Leute im Projekt haben?
42 Interviewter B: Genau, das ist wichtig. Also das ist sicherlich sehr hoch, sehr wichtig.
43 Interviewer: Softwaretesting,Fehlerbehebung, ja, hast du eh vorher schon erwähnt
eigentlich.
44 Interviewter B: Ist ein ganz ein ganz ein klarer Bestandteil, weil ahh, es gibt immer wieder
Überraschungen, dass gewisse Sachen von der SAP einfach dann nicht mehr unterstützt
werden und das muss man im Zuge des Tests dann einfach ganz klar herausfinden.
45 Interviewer: Ok. Usertraining und Schulung?
46 Interviewter B: Gar nicht. Also dadurch, dass ich das System theoretisch nicht verändert, es
sind ein paar so Kleinigkeiten, dass irgendwo auf einmal eine Maske vielleicht ein bisschen
anders aussieht, aber dahingehend ist gar nichts trainiert worden.
47 Interviewer: Business Case?
48 Interviewter B: mhmm, sehe ich als eher weniger wichtig.
49 Interviewer: Ok. Auswahl eines Projektchampions, also quasi eine Person, die sozusagen
das Projekt innerhalb des Unternehmens als wichtig darstellt, verkauft sozusagen.
50 Interviewter B: Das, das tun wir nicht. Also wir heben da nie so wirklich wen explizit

129
 hervor, ahh, da ist, da geht es eher darum, dass wir, wir haben eine Projektabschlussfeier
dann gehabt, wo wir dann, das haben wir bei der Projekteinführung schon gehabt, haben
groß Eis eingekauft beim ahh Eishändler und haben dann eine große Eisparty unter
Anführungszeichen gemacht. Es ist aber da auch genauso nochmal die Geschäftsführung
gekommen und hat sich auch bedankt für die Einführungsunterstützung, weil ja trotzdem in
diesem Zeitraum diese zwei Wochen dort, werden einfach sehr viele Personen aus der, aus
dem aktiven, ahh aus der aktiven Arbeit herausgenommen und stehen eigentlich nur zu dem
Zeitpunkt für die Integrationstests zur Verfügung.
51 Interviewer: Kommunikationsplan?
52 Interviewter B: Ahmm, nein, ich wüsste nicht was das ist.
53 Interviewer: Ja. Ahh. dann haben wir da noch Management von Legacysystemen, also habt
ihr alte Systeme, die irgendwie noch...?
54 Interviewter B: Nein, haben wir eigentlich dahingehend jetzt nicht. Also es gibt natürlich,
wir haben natürlich schon einige Schnittstellen zu sag ich jetzt einmal, ahh, zu
Legacysysteme, das ist aber, ist aber überschaubar, also das ist in unserer Größenordnung
jetzt, aber natürlich die Schnittstellentests haben genauso dazugehört, dass man schaut, dass
das funktioniert.
55 Interviewer: Ahm. Herstellerunterstützung? Also jetzt in dem Sinne von SAP?
56 Interviewter B: Haben wir zum Teil gehabt, weil es ist, wir haben ein paar so
Servicemeldungen absetzen müssen, eben zum Beispiel das mit dem thailändischen Kunden,
ahh ja, das ist notwendig. Durchaus.
57 Interviewer: Genau. Und das letzte ist noch Post-Implementierungs-Evaluierung, also habt
ihr im Nachhinein auch irgendwie das Projekt evaluiert und..?
58 Interviewter B: Ja, wir haben so eine, so eine Lessons-Learned Session, haben wir dann
gemacht,wo wir gesagt haben, was sind denn so die, die Dinge, die sind, die gut gegangen
sind einfach auch nochmalzu reflektieren, aber genauso auch die Sachen, was sollte man
anders machen. Das war so zum Beispiel ein Thema, wir haben drei Excel Listen gehabt für
jeden anderen Prozess und zukünftig hätten wir das in einer Sharepoint-Liste zum Beispiel
geführt, die man schöner filtern kann, wo, wo jeder gleichzeitig darauf arbeiten kann, weil
da haben wir uns mit dem Excel nicht wirklich was Gutes angetan, weil der eine schreibt
rein, hat er getestet, lässt es offen und ja, ... Ist eh, aber, da sind, haben wir ein paar Sachen
im Endeffekt dann auch herausgefiltert, die relevant sind für uns dann.
59 Interviewer: Cool. Ja perfekt, somit wären wir eh schon eigentlich am Ende. Ich würde nur
ganz kurz wissen, wie viele Mitarbeiter hat das Unternehmen XYZ?
60 Interviewter B:Ahh, wir haben da am Standort, haben wir 400 Mitarbeiter, ahh, SAP User
haben wir ca. 280 im System. Ja, und zusätzlich, also wir haben noch einen Standort in
Amerika noch, SAP-technisch auch angebunden, also auch die Amerikaner machen dann
eben mit diesem Test eingebunden, wobei die sind primär von, der Test ist primär dann von
uns herüben gemacht worden. Aber es ist auch darum gegangen, technisch, gibt es technisch
eh keine Probleme mit Client oder solchen Sachen, also das sind, das ist dann getestet
worden.
61 Interviewer: Cool. Perfekt. Danke vielmals.
62 Interviewter B: Ja, bitteschön.

130
 C.3 Transcript Interview C
1 Interviewer: Ich würde Sie bitten am Beginn einen kurzen Überblick zu geben, inwieweit
Sie sich mit dem Thema ERP-Upgrades beschäftigen?
2 Interviewter C: Es gibt zwei Hüte die für Sie relevant sind, einerseits machen wir seit 99 das
XYZ, dessen wissenschaftlicher Leiter ich bin, das heißt wir providen für ca. 170
Institutionen SAP-Systeme für Lehre und Forschung, wir nehmen uns Curriculas, z.B. für
das Ministerium, übersetzen die Curriculas in Lernszenarien, in Demosysteme und providen
diese Demosysteme. Wenn ich jetzt sag 99, dann können Sie sich vorstellen, wir haben
schon ein zwei, drei Upgrades hinter uns, und ja von der Seite her, der XYZ ist der operative
Leiter vom XYZ. Das zweite ist, wir haben gemeinsam zehn Jahre die produktiven SAP
Systeme der TU Wien provided, upgegraded, sonstiges mit dem gemacht. Weil das sind die
beiden Kompetenzfelder, die Sie vielleicht interessieren könnten.
3 Interviewer: Wann haben Sie das letzte Upgrade durchgeführt und in welchem Umfang fand
dies statt?
4 Interviewter C: Letzten Herbst, 3 Monate alleine für das Upgrade von ERP on Hana auf
S4Hana ERP. Sind wir aber noch mittendrin und haben immer noch Verdauungsprobleme.
5 Interviewer: Was waren die Hauptgründe für das Upgrade?
6 Interviewter C: Der eine Grund war, auf dem ERP on Hana war die neue Oberfläche, das
Fiori, die quasi auf allen Browsern laufen sollten und auch auf allen Devices, war nicht
drinnen, sondern war eine eigene Maschine und wir wollten uns jetzt anschauen in der
neuesten Version, ist das quasi alles eine Maschine und wir wollten uns auch anschauen, wie
den unsere Curricula dann nachher ausschauen, wenn sie upgegradet werden. Also einerseits
Technologiegründe, neue Oberfläche anstatt getrennter Server, getrennte Geschichten, beim
letzten Mal war es das bei uns, dass wir quasi eine In-Memory Technologie haben, wo die
operativen Systeme darauf laufen, plus wir BW, also Data Warehouse, drauf laufen lassen,
war eigentliche der Grund, dass wir ERP on Hana upgegradet haben.
7 Interviewer: Was sind die Ziele die Sie definiert haben, für das Projekt, die dann erreicht
werden müssen.
8 Interviewter C: Es soll im Endeffekt die Schulungsumgebung, die wir hatten, also die
gesamte Funktionalität, das ist von Logistik Prozessen bis hin zu einer Bilanz und einer
G&V und einer Erlösrechnung, sollte danach wieder funktionieren. Aber, auch die
Möglichkeit, mit der neuen Oberfläche, ebenfalls zu arbeiten, wir haben einige Unis die
wollen mit der neuen Oberfläche, das ausprobieren, also das zu ermöglichen.
9 Interviewer: Dann kommen wir eigentlich eh schon zu unserem Hauptthema, was glauben
Sie, dass die Erfolgsfaktoren sind, damit ein ERP Upgrade erfolgreich durchgeführt werden
kann?
10 Interviewter C: Einen heftigen internen Projektmanager, der sich auch mit den Prozessen
auskennt. Wir haben das jetzt gesehen, die IT-Mannschaft, und das ist eigentlich für den
Betrieb so eines Systems wesentlich, da XYZ ist so an der Schnittstelle zwischen Prozesse
kennen,aber auch noch wissen, wie man upgradet, der Kollege der da hin und her wechselt,
der kenn sich nur mit Upgrades aus, der ist dort gestanden und hat nicht gewusst, wenn ein
Problem war, was passiert. Ja, wir mussten diesmal heftig Stammdaten updaten, also das ist
ein relative heftiger Wechsel von, quasi dem ERP on Hana, das ist noch halbwegs in der
Tradition vom R3, und deshalb sieht man ja auch S4Hana, das ist quasi R zu S und 3 zu 4,
da werden alle Stammdaten einmal zerrüttelt, ja fast nix mehr funktioniert nachher und
wenn Sie nicht wissen, quasi, wie das funktionieren soll in der Bilanz und der G&V, wie ein
Logistikprozess nachher funktionieren soll, dann sind Sie andauernd, also das ist unsere
Vorteil, dass wir das hier in einem kleinen Team haben, dass wir also nicht nur wissen, wie
eine Datenbank nachher ausschauen soll, sondern auch wie sie sich verhalten soll. Also auf
Ihre Fragestellung zurück zu kommen, als Firma, als Kunde hab ich den Vorteil, dass ja die
Trägerfirma, also in unserem Fall SAP, mit ihren Beratern dasitzt und mit ihren Erfahrungen
dasitzt, wir sind aber ganz nahe am (?Rainpub?), das heißt wir müssen selber mit der SAP
oft noch sagen, du vielleicht sollten wir hier noch etwas verbessern. Um Ihre Frage zu
beantworten, als Kunde draußen, bekomm ich einen fertigen Upgradeprozess hingelegt, mit

131
 Leitfaden, an den ich mich halten kann, bei uns ist es so, der Leitfaden ist zu 85% vorhanden
und den Rest dürfen wir noch gemeinsam mit SAP entwickeln. Auch das was mir im
Leitfaden fehlt, also zum Beispiel meine Jungs haben gesagt, du es gibt keinen Kreditor und
Debitor mehr, es gibt nur mehr die Partnerrolle, sag ich schön, ja, jetzt hab ich aber gewusst,
was ich vom Kreditor und Debitor brauch, weil meine Jungs hätten gesagt, nun ja was mach
ich jetzt. Weil es ja ein ganz inhaltlich neues Konzept ist, das ich jeden Lieferanten und
jeden Kunden plötzlich als Partner anlegen, ich brauch in meinen Prozessen, diese
Partnerrolle gar nicht, das ist leiwand, das es diese jetzt gibt, aber es bringt mir in meinem
Logistikprozess zur Zeit nicht wirklich einen Vorteil, jetzt muss ich mich mit meinen
Technikern aber zusammensetzen, was brauch ich, und das ist hier etwa der Vorteil, in
dieser Umgebung hier, inhaltliche Kompetenz plus Upgrade-Kompetenz im gleichen Team
ist, sonst hätten Sie quasi vier Abteilungen die Logistik machen, eine Abteilung die FIBU
macht, eine Abteilung die KORE macht, jetzt müssen Sie andauernd die Leute quälen, was
bedeutet, den das für Sie, ich hab jetzt zum Beispiel, alle FIBU Konten mussten angereichert
werden. Jetzt habe ich zum Glück die Kompetenz um zu sagen, warum, weil wir alle
Sekundärkostenarten plötzlich als Dummy, technisches FIBU-Konto anlegen müssen. Jetzt
mach ich eigentlich, obwohl wir FIBU-Konten anreichern, mach ich gerade ein Konzept für
KORE, und das macht es einfach bei einem Upgrade Prozess so heftig. Wir haben teilweise
das Thema, Upgradeprozess, (?BRCC?) hat uns teilweise ein System upgegradet und gesagt
und jetzt habt ihr 3 Stunden Zeit um das System zu testen und dann war es produktiv und
dann haben sie sich gewundert, warum nichts mehr gegangen ist, weil irgendwo etwas, das
wir auch nicht erahnt haben, da hat eine kleiner Haken drinnen gefehlt und das Ding hat er
ins Nirvana geschickt. Ja und also, (?BRCC?), hat zwar Technik brav alles nach Leitfaden,
den der XYZ erstellt hat, gemacht, das depate bei der Geschichte war, das sie inhaltlich
nicht geprüft hat, weil es so viele Ausprägungen auf dem System gegeben hat, wie wir in der
kurzen Zeit, weil wir mussten ja gestern fertig werden, es kann ja eh nix passieren laut SAP,
naja, nicht alles testen konnten und dann ist plötzlich, die TU Wien für 14 Tage gestanden,
da müssen Sie mal mit einem Produktivsystem (?antworten?). Ja also, dieses Thema bei
ERP-Systemen ist ja, Sie haben ja nicht nur, Hardware die Sie dazukaufen, irgendwelche
Datenbanken die Sie dazu upgraden, sondern Sie haben ja den ganzen Spaß des
Rechnungswesens und der Logistikprozesse, die draufgreifen, da haben Sie so viele
Abteilungen die normalerweise mitreden müssen.
11 Interviewer: Das heißt, man kann zusammenfassen, dass auch die Kommunikation zwischen
den verschiedenen Abteilungen sozusagen, ein Erfolgsfaktor ist?
12 Interviewter C: Die Verfügbarkeit, ja, weil meine Finanzbuchhaltung jetzt im März sagt,
quäl mich nicht, ich hab den Jahresabschluss. Und das ist halt etwas, das wir immer wieder
sehen, in Projekten die wir auch unterstützen, wo es dann heißt, ich hab jetzt keine Zeit,
gerade in Projekten wo Sie Daten anrühren, Daten anreichern müssen, die Fachabteilungen
haben ja auch nebenbei ihr produktives Geschäft und müssen jetzt praktisch sich mit Ihnen
hinsetzten, weil Sie meinen, das System wir upgegradet. Das Sie vielleicht alle Stammdaten
angreifen müssen, also jetzt beim Upgrade auf S4 müssen Sie alle FIBU-Daten einmal
angreifen, alle Stammdaten müssen einmal durgeschaut werden und die Daten ergänzt
werden. Jetzt stellen Sie sich einmal so eine kleine Firma à la Mondi oder OMV oder
sonstiges, dann können Sie sich mit allen Subdivisions anschauen wie viele Gesellschaften,
die haben mit unterschiedlichen FIBU-Konten, also viel Vergnügen, die müssen Sie jetzt
alle dazu bringen, weil ihnen ja sonst fad ist, und die ja sonst nichts zu tun haben, dass die
jetzt alle nochmal ihre Stammdaten überprüfen weil Sie jetzt ein Upgrade machen wollen.
13 Interviewer: Das haben wir jetzt eh implizit schon gemacht, aber könnten Sie vielleicht diese
Faktoren priorisieren? Was ist so das wichtigste, Ihrer Meinung nach?
14 Interviewter C: Projektmanagement, Koordination der Fachabteilungen fürs Zuarbeiten, den
depaten Patch einspielen, das ist nicht das Thema, wirklich einen Zeitplan zu machen, wo
alle Leute, dann auch mal Zeit haben und sich vorher anzuschauen, was sich da an
Stammdatenänderungen, Bewegungsdatenveränderungen, plötzlich passiert.

132
15 Interviewer: Ist externes Consulting, weil Sie das ja vorher angesprochen haben, auch ein
Erfolgsfaktor, wenn man jetzt davon ausgeht, dass man vielleicht ein Unternehmen ist, dass
nicht soviel Erfahrung hat wie Sie?
16 Interviewter C: Nein, weil Sie haben das Problem, dass, wie formulier ich das jetzt höflich,
Sie zitieren mich jetzt nicht wörtlich. Wir haben zum Beispiel, das Implementierungsprojekt
der TU-Wien gehabt, dass eigentlich ein Upgrade-Projekt war, wir haben das System von
dort genommen und an uns angepasst. Und die haben eine bestimmte Tagesanzahl und wenn
das vorbei war, haben sie geglaubt das Projekt ist fertig. Viele in diesem Umfeld, wissen
nicht, was ein Werkvertrag ist, nämlich ein Werk abzuliefern und nicht die Stunden die Sie
im Werkvertrag angeboten haben, durchgezogen zu haben. Na, und mhmm, viele im ERP
Umfeld, und ich habe jetzt am Wochenende eine Rechnung mir ausdrucken lassen müssen
vom Leiner, anderes ERP System, die hat gesagt, seit dem wir das neue Upgrade haben,
funktioniert alles nur mehr ganz langsam, ja, das ist wurscht ob Sie jetzt zu dem oder zu dem
gehen, wenn Sie ein ERP System haben, dann ist man gewohnt, dass das teuer ist und dann
muss man da halt reinstecken. Sie haben so unterschiedliche Bewertungen, von ein und dem
selben Produkt, wenn Sie sich dem Alfred Taudes seine Studie ansehen, über Zufriedenheit
mit ERP Systemen, streut die je nachdem, wenn Sie einen haben der alles macht, dann
haben Sie meist die gleiche Note, aber sobald Sie das Consulting, und Consulting ist bei
Navision genauso unterschiedlich oder Axapta, weil es unterschiedliche Firmen gibt wie bei
SAP und da können Sie einen guten haben der das öfters macht oder jemanden haben, der
sagt, super, ich hab den großen Kandidaten jetzt erwischt, na der wird jetzt bluten. Also, es
gibt ehrliche Firmen am Markt, es gibt aber, weil es so viele Firmen gibt, auch manchmal
interessante Angebote.
17 Interviewer: Sind bei ihrem Projekt gröbere Probleme aufgetreten?
18 Interviewter C: Alle Stammdaten im Argen, reicht Ihnen das?
19 Interviewer: Und mit welchen Maßnahmen haben Sie diese Probleme gelöst?
20 Interviewter C: Indem einerseits mein Team versucht hat, quasi, Programme zu finden die
die Stammdaten automatisch anreichern, hat es nicht gegeben, das heißt manuell durch 600
Konten durchhatschen. Und haben Sie erst wieder einmal Routinebuchungen machen
können, und jetzt nachkontrollieren wirklich ob hinten, die Erlösrechnung, die haben einfach
das erste mal durchbuchen geklickt und das Ding hieß: Erlösrechnung wurde neu
konfiguriert und jetzt schauen wir uns an, ob sie auch richtig konfiguriert ist.
21 Interviewer: Also sehr viel manuelle Arbeit?
22 Interviewter C: sehr viel manuelle, und zwar nur die eine Fachabteilung machen kann, die
gar nicht das IT-Team machen kann, sondern die Fachabteilung, weil die Fachabteilung sich
entscheiden muss links, rechts, oben oder unten. Und das ist der scheiß Hammer dabei. Das
ist etwas, dass die IT-Abteilung auch gar nicht entscheiden darf. Ich brauch den Key-User
aus der Fachabteilung der sagt, so muss es funktionieren und dabei kann die IT-Abteilung
nur unterstützen. Außer du hättest Kompetenz in der IT-Abteilung, aber das ist ja teilweise
auch von den Softwareherstellern nicht gewü[Link] mich an
Implementierungsprojekten die wir gehabt haben, wo der Softwarehersteller gekommen ist
und gesagt hat, warum haben Sie sich jetzt jemanden geholt, der SAP-kundig ist und mein
Chef hat gesagt, sind jetzt irgendwo angrennt. Ja, und das war bei uns halt, es führt, das ist
eine Frage wie Sie es aufsetzen, bei uns hat es mit einer Abteilung zu relativ heftigen
Bröseln geführt, weil die gesagt haben, wir sind die Abteilung die das bestimmt, und wir
haben gesagt OK, dann lassen wir die Finger weg, aber bitte dann schnell und die andere
Abteilung hat gesagt, ja, ihr könnt das, wir vertrauen euch, ihr macht das für uns. Das ist
also, ich glaube auch, dass es wichtig ist in der zukünftigen Ausbildung auch, der Leute die
oder der Auswahl der Leute, dass ich nicht nur eine IT-Abteilung habe die Server streichelt
und SQL-Datenbanken oder HANA-Datenbanken bearbeiten kann, sondern der sich mit den
Unternehmensprozessen, sie reden jetzt alle über Digitalisierung, die Fachabteilung weis
nicht was Digitalisierung bedeutet, der IT-ler weiß nicht wie die Prozesse draußen gehen,
leiwand. Und Digitalisierung ist genau die Schnittstelle, die das noch turbulenter macht.

133
23 Interviewer: Ok perfekt, Wie würden Sie ein Projekt als erfolgreich definieren?
24 Interviewter C: In Zeit, in Budget, in der Funktionalität!
25 Interviewer: Ich möcht in meiner Arbeit auch herausfinden, was die Unterschiede sind
zwischen Implementierungs- und Upgrade Projekten bezüglich den Erfolgsfaktoren? Wo
glauben Sie, dass die größten Unterschiede sind?
26 Interviewter C: Bei einem Implementierungsprojekt will ich neue Funktionalität auch noch
haben, bei einem Upgrade Projekt will ich einmal dass alles wieder so läuft wie es vorher
auch war. Vielleicht ist neue Funktionalität auch ein Ziel dann nachher die zu haben, aber
per se wenn ich upgrade will ich einfach, dass das System bitte sich nachher genauso verhält
wie vorher und nicht alles neu macht. Also jetzt zum Beispiel, ganz neue Masken, teilweise
Transaktionen die vorher so ausgeschaut haben, sind jetzt ganz anders. Soll ich jetzt neue
Bedienungsanleitung schreiben, neue Schulung der Mitarbeiter. Keiner wollte die neue
Maske, die wollen eigentlich zufrieden weiterarbeiten mit dem was sie kennen. Und jetzt
graden Sie up und plötzlich sind ihre Kastl ganz wo anders. Und neue Userumgebung,
manche Leute arbeiten schon seit 15 Jahren damit und die sind zufrieden mit dem was sie
haben, es ist schon okay, dass vielleicht Generation Y, sich ein bisschen was anderes
wünscht, aber ich kann ja nicht in einem Unternehmen wie zB hier TU Wien, 3600
Mitarbeiter, weil 50 Leute eine neue Oberfläche wollen, den 3500 sagen und jetzt schaut
alles anders aus. Wer schult den die? Wer schreibt den die Unterlagen? Wer zahlt den die
Schulungen für die? Also ja, wenn ich upgrade dann würde ich mal ganz gerne mein System
wieder so wie es ist, außer ich grade up weil ich etwas besonders haben möchte.
27 Interviewer: Wenn sich trotzdem gezwungenermaßen etwas ändert, ist Schulung, weil das
gerade angesprochen haben, vermutlich auch ein Kernthema?
28 Interviewter C: Zuerst versuche ich mal dass ich es gleich habe, außer ich hab upgegradet
wie bei uns wegen Fiori, wegen der neuen Umgebung, ja, aber ich will nicht, dass alle
Leute, bei uns hier wir haben über 3600 Leute, die einen Zugang haben, wenn ich die jedes
Mal schulen muss, nur deswegen weil ich einen Patch einspiele, und das ist ja auch ein
Upgrade, werde ich ja zum Häferl. Oder Sie machen ein Upgrade und plötzlich gehen einige
Browser nicht mehr. Schön. Dann erklären Sie jetzt mal dem Herrn Dekan, der bist jetzt
immer Safari genutzt, dass Safari ab jetzt nicht mehr opportun ist, weil die
Softwarehersteller durch das Upgrade Safari nicht mehr unterstützen. Ja, wegen Ihrer
depaten Software, muss der sich jetzt einen Explorer anschaffen, viel Vergnügen.
29 Interviewer: Weil wir jetzt ja noch bei den Unterschieden zur Implementierung sind, es gibt
ja extrem viel Literatur zum Thema Erfolgsfaktoren bei ERP-Implementierungsprojekten.
Könnten Sie mir vielleicht noch ganz kurz, von sehr wichtig bis gar nicht wichtig, ranken,
wie wichtig diese Faktoren jetzt für Upgrade Projekte sind?
30 Interviewter C:mhhmm
31 Interviewer: Top Management Unterstützung?
32 Interviewter C: Wenn wir jetzt von einem klassischen Upgrade sprechen, Sie müssen hier
unterscheiden zwischen einem Upgrade, dass ich machen muss, weil meine
Softwarehersteller meinen, die alte Version wird nicht mehr unterstützt. Ich bin End of Life,
ich muss jetzt irgendwas machen, dann will das Top Management bitte gar nichts wissen
davon, das will eigentlich, dass das weiter schnurrt. Wenn ich jetzt ein Upgrade mache um
eine neue Funktionalität zu haben, ist das ja wieder ein Implementierungsprojekt, also das
klassische Upgrade, wo ich nichts ändern möchte, sollte das Top Management bitte einen
Frieden haben.
33 Change Management: Auch nicht, weil ich, also wenn es bei mir End of Life ist, will ich
nicht, dass sich unbedingt was ändert. Das Change Management der Prozesse meine ich,
mein Change Management ist schon sehr wichtig, ja weil ich ja bei mir Sachen ändern muss,
also hier zu unterscheiden zwischen Change Management in der IT-Abteilung versus
Change Management draussen.
34 Interviewer: Business Plan und Vision?
35 Interviewter C: Nicht so wichtig, eher bei Implementierungen wichtig

134
36 Interviewer: Projektmanagement?
37 Interviewter C: sehr
38 Interviewer: BPR und Customization
39 Interviewter C: Ich muss es machen, aber es sollt eigentlich BPR, ich würde es also (...),
BPR sollte nicht passieren. Weil ich möcht ja eigentlich die da draußen nicht quälen damit!
40 Interviewer: ERP Team Zusammenstellung
41 Interviewter C: Sehr wichtig
42 Interviewer: Software Testing & Troubleshooting
43 Interviewter C: Auch sehr wichtig
44 Interviewer: User Training & Schulung
45 Interviewter C: Sollte hoffentlich unwichtig sein, aber manchmal, wenn sich was ändert
46 Interviewer: Business Case?
47 Interviewter C: Ist eher wichtig, weil es soll sich ja nachher rechnen.
48 Interviewer: Projektchampion?
49 Interviewter C: wichtig
50 Interviewer: Kommunikationsplan?
51 Interviewter C: auch wichtig
52 Interviewer: Management von Legacy Systemen?
53 Interviewter C: auch wichtig
54 Interviewer: Herstellerunterstützung
55 Interviewter C: Auch eher wichtig
56 Interviewer: Post Implementation Evaluation?
57 Interviewter C: Ist wichtig, weil es soll nachher wieder so laufen wie vorher. Also Sie
müssen vorsichtig sein, also wenn Sie wirklich nur ein Upgrade machen, weil End of Life
oder sonstiges versus einem Upgrade wo ich neue Funktionalität haben möchte. Das ist für
mich ein gewaltiger Unterschied. OK
58 Interviewer:Danke für das Interview
59 Interviewter C: Gerne

135
 C.4 Transcript Interview D
1 Interviewer: Könnten Sie bitte einen ganz kurzen Überblick über Ihre Person und inwieweit
Sie mit dem Thema ERP und ERP Upgrades verbunden sind, erläutern?
2 Interviewter D: Ja ich bin Professor am Institut für Produktionsmanagement der WU, dieses
Institut ist Teil des Departments für Informationsverarbeitung und Prozessmanagement. Ich
beschäftige mich seit ca. 30 Jahren ungefähr mit ERP Systemen, war bei den ersten
Einführungen in Österreich dabei, vom SAP R2, habe dann auch mitgearbeitet bei der
Umstellung, beim Upgrade auf R3 und im Moment mache ich auch mit bei der Diskussion
über SAP HANA.
3 Interviewer: Super, Danke. Haben Sie in letzter Zeit bei einem ERP Upgrade durchgeführt
bzw. waren Sie da dabei?
4 Interviewter D: Operativ bin ich als Professor natürlich nicht dabei. Wann dann mache ich
Gutachten oder begleite Unternehmen bei Fallstudien oder Ähnlichem oder mach
Wirtschaftlichkeitsberechnungen, direkt in den Projekten bin ich nicht involviert.
5 Interviewer: OK, Was ist Ihrer Meinung nach der Hauptgrund warum Upgrades
durchgeführt werden?
6 Interviewter D: Naja, meistens ein sehr pragmatischer Grund, weil der ERP Hersteller
irgendwann einmal eine neue Technologie auf den Markt bringt und nur mehr für eine
bestimmte Anzahl von Jahren die Wartung der alten Technologie garantiert. Das ist der
pragmatische Grund für den Anwender, aber natürlich bringt der Hersteller eine neue
Technologie nur auf den Markt wenn es neue Anwendungsfelder gibt und die sind meistens
durch Technologieinnovationen getrieben. Also wenn es neue technologische
Entwicklungen gibt, zum Beispiel bei der Hardware, ahh, die ganze neue Anwendungsfelder
erschließen und die alte Softwarearchitektur unterstützt das nicht mehr, dann gibt es in der
Regel einen großen Upgrade und dann müssen im Laufe der Zeit die Anwender mitziehen.
Davon unabhängig gibt es natürlich die vielen ganz kleineren Änderungen, aber ich glaube
um diese geht es in Ihrer Arbeit nicht.
7 Interviewer: Ja ganz genau, was glauben Sie, welche Ziele für solche Upgradea-Projekte
definiert werden? Ist es nur, dass es im Nachhinein wieder so läuft wie im Vorhinein oder
gibt es da auch andere Ziele?
8 Interviewter D: Naja, wenn man es dumm macht, dann ist das schon ein Ziel wobei das Ziel
meistens halt ist, die alten Funktionen sollten zumindest wieder funktionieren, auf der
anderen Seite, wenn man nur das als Ziel hat, dann ist das eine ziemliche
Geldverschwendung, weil man ja keine neuen Nutzeneffekte bekommt und vernünftige
Firmen machen das so, dass sie gleichzeitig auch schauen, was gibt die neue Technologie
her und wie können wir unsere Anwendungen auch ändern. Oft passiert, dass halt dann erst
im Lauf der Zeit, das heißt in der ersten Phase schaut man erst einmal, dass man das Alte
einmal zusammenbringt und beginnt man die neuen Sachen zu nutzen.
9 Interviewer: Welche Faktoren sind Ihrer Meinung nach kritisch für den Erfolg eines ERP
Upgrade Projektes und warum glauben Sie, dass diese Faktoren ausschlaggebend sind für
den Erfolg?
10 Interviewter D: Nun ja das Erste ist glaube ich, dass man sich bevor, dass man auf jeden Fall
vermeidet, die vorher angesprochene Dummheit, dass man mit der neuen Technologie die
alten Geschäftsprozesse implementiert, das ist eine Geldverschwendung, das heißt in der
Vorbereitung sollte man sich wirklich mit der neuen Technologie beschäftigen, aber nicht
nur mit der Technologie, sondern auch mit dem eigenen Geschäft und untersuchen, was
kann ich wirklich Neues mit der neuen Technologie machen. Das ist im Wesentlichen eine
Frage der Vorbereitung und auch des Verständnisses vom Geschäft und dann muss man da
auch wirklich mutig sein und sagen, he mit der neuen Technologie könnten wir ganz neue
Sachen machen und die werden wir jetzt auch angehen. Also einfach ein gründliches
Verständnis der neuen Technologie und ihrer Auswirkungen auf das Geschäft, das ist ein
ganz ein wichtiger Erfolgsfaktor. Das Zweite ist natürlich, das heißt aber auch, wenn man
den hat, dass man sich auch in der Firma selbst mit der neuen Technologie beschäftigt und
das nicht irgendwelchen Beratern gibt, ja, das einfachste ist, zu jemanden zu sagen, machen

136
 Sie mir eine Umstellung auf SAP Hana und es soll genauso funktionieren wie bisher, hier ist
das Bisherige, machen Sie, ja. Man muss sich sicherlich im Unternehmen, gründlich mit der
neuen Technologie auseinandersetzen und auch wirklich überlegen was kann ich wirklich
neu machen.
11 [Abbruch ... Telefonat]
12 Interviewer: Guten Tag Herr XYZ, leider ist die Verbindung unterbrochen worden
13 Interviewter D: Macht nichts, wo sind wir stehen geblieben?
14 Interviewer: Bei den Erfolgsfaktoren
15 Interviewter D: Ja, man muss sich in der Firma auch wirklich mit den neuen Möglichkeiten
auseinandersetzen und nicht nur alles extern vergibt. Ja und, dass auch das
Projektmanagement was versteht davon, von dem Projekt und nicht sagt, das macht nur die
EDV.
16 Interviewer: Fällt Ihnen da dazu noch etwas Weiteres ein vielleicht?
17 Interviewter D: Ja, oft ist es so, dass man für neue Technologien neues Personal braucht.
Das ist eine neue IBM Weisheit, also zum Beispiel frische Absolventen, die mit einem
anderen Blickwinkel die Sachen anschauen, ist vielleicht auch nicht schlecht, dass man diese
ins Projekt nimmt.
18 Interviewer: Wo sehen Sie die größten Unterschiede, bezüglich Erfolgsfaktoren, bei
Implementierungs- und Upgrade Projekten?
19 Interviewter D: Na ja, beim Ersten ERP Projekt, wobei das erste ERP Projekt in Österreich,
fast kaum mehr irgend eine Firma macht in einer gewissen Größenordnung, hat man
natürlich viel weniger Erfahrung wie beim Upgrade, daher ist meistens das Risiko bei der
Erstimplementierung höher, als wie bei Upgrades außer man stellt sich besonders depat an,
auf der anderen Seite, das Problem ist, wenn man schon ein System hat, dann denkt man
auch in sehr eingefahrenen Bahnen und nutzt dann sehr oft eben die neuen Technologien
eben nicht optimal, als wie wenn man sagt, man geht [.....]
20 Interviewer: OK, perfekt, Ich habe für meine Arbeit schon recherchiert, es gibt sehr viel
Literatur zum Thema Erfolgsfaktoren bei ERP Implementierungen und ich habe jetzt die
wichtigsten Erfolgsfaktoren herausgesucht. Dürfte ich Sie bitten, dass Sie diese quasi für die
Wichtigkeit bei Upgrade Projekten, zwischen sehr wichtig und gar nicht wichtig raten.
21 Interviewter D: Ja
22 Interviewer: Der erste wäre, Top Management Support?
23 Interviewter D: Ja, bei kleiner Upgrades natürlich nicht, aber bei wirklich neuen
Technologien, wie es dazumals R3 war oder jetzt HANA, ganz wichtig.
24 Interviewer: Change Management
25 Interviewter D: Ja sicherlich auch, wahrscheinlich nicht so stark wie beim ersten Mal, aber
natürlich auch.
26 Interviewer: Business Plan & Vision
27 Interviewter D: Ja, Vision auf jeden Fall, deswegen auch das Top Management dahinter, ich
meine, Business Plan, ja man braucht natürlich auch eine IT-Strategie und einen
längerfristigen Plan, aber oft hat es keinen Sinn, wenn man das in das letzte Detail
kalkuliert, weil sich dann sowieso das Umfeld ändert, also einen vernünftigen Business Plan
28 Interviewer: Projektmanagement
29 Interviewter D: Ja, sicher, auch wichtig, braucht man in beiden Fällen
30 Interviewer: Business Process Reengineering & Customization
31 Interviewter D: Ja, wie gesagt, es kommt darauf an, wenn die bestehenden Prozesse für gut
befunden werden und die brauchst du nur transformieren, dann muss ich natürlich weniger
reengineeren, aber wenn ich mit der neuen Technologie neue Sachen machen möchte, oder
auch bestehende Sachen, ganz anders machen möchte, dann ist das natürlich schon auch
wichtig.
32 Interviewer: ERP Teamzusammenstellung?
33 Interviewter D: Ja, das man die richtigen Leute findet, das ist bei beiden wichtig, den
richtigen Mix an Kompetenzen

137
34 Interviewer: Software Testing & Troubleshooting
35 Interviewter D: Ja, richtig, ja sicher auch
36 Interviewer: User Training & Weiterbildung
37 Interviewter D: Ja, das wird oft vergessen, aber ist natürlich bei beiden wichtig, aber da ist
natürlich immer die Frage, was ändert sich für die User wirklich, ja, wenn sich auch das
User Interface ändert ist klar, dass sie viel trainieren müssen, wenn sich nur im Hintergrund,
im Backoffice irgendeine Engine aufstellen, und irgendwas ausrechnen, dann ist das
vielleicht etwas weniger wichtig.
38 Interviewer: Business Case
39 Interviewter D: wichtig, sowas muss ich ja auch auszahlen
40 Interviewer: Kommunikation
41 Interviewter D: auch wichtig
42 Interviewer: Projekt Champion
43 Interviewter D: eher unwichtig
44 Interviewer: OK, Management von IT-Legacy Systemen
45 Interviewter D: Ja, das ist überhaupt ein großes Problem, was mache ich mit der alten
Software die keiner mehr versteht, das ist natürlich ein Problem, dass man bei der ersten
Implementierung nicht hat, mit der schafft man meistens das Problem, insbesondere wenn
man modifiziert bist zum geht nicht mehr und dann hat man Probleme die ganzen Jahre
hindurch, das ist sicher beim Upgrade ein größeres Problem wie wenn ich von der grünen
Wiese komme.
46 Interviewer: Herstellerunterstützung
47 Interviewter D: Ja, das ist immer wichtig, wobei es nicht nur auf den Hersteller drauf an
kommt, die Meisten haben ja auch Implementierungspartner und es nützt nichts, wenn Sie
eine super Software haben und der Implementierungspartner versteht Ihr Geschäft nicht,
genau, die Beiden sind natürlich, wobei letzteres sehr wichtig ist, also irgendwelchen
technischen Spielereien sind oft nicht so wichtig, wie, dass der versteht überhaupt, was
macht die Firma, auf was kommt es drauf an, wie funktionieren die Prozesse, ahh, das ist
glaube ich sehr entscheidend für so ein Projekt. Dass man auch einen Partner findet, der
einen auch versteht und nicht der irgendein Technikfuzi ist oder der keine Erfahrung hat.
48 Interviewer: Der letzte Punkt wäre dann: Post-Implementation Evaluierung
49 Interviewter D: Das macht meistens keiner. Jeder ist froh, wenn sie es irgendwie geschafft
haben, wenn die Firma nicht zugrunde gegangen ist, weil meistens sind die Projekte
aufwendiger als geplant und jeder ist dann froh, wenn er von dem nichts mehr hört und
keine Umstellung mehr machen muss. Daher wird dann meistens nicht mehr evaluiert, ist
meine Erfahrung. Ja, das ist leider die Wahrheit. Wenn Sie evaluieren, heißt das ja immer,
dass sie in der Zwischenzeit ja nichts geändert haben, außerdas Informationssystem, aber
das ist ja meistens nicht der Fall. Innerhalb eines Jahres ändert sich ja das Geschäft auch
wieder und so. Das ist auch das Problem oft, dass Sie mitten in der Umstellung wieder
umstellen müssen, weil sich irgendwo was geändert hat und deswegen ist es auch so, je
länger diese Projekte dauern, desto riskanter werden sie, weil sie [...] Ich glaube, dass
passiert, wenn, dann nur bei großen Unternehmen, aber bei den österreichischen KMU's, die
oft familiengesteuert sind, passiert das weniger. Die sind dann meistens froh, dass sie es
hinter sich haben und wenn es wieder halbwegs funktioniert und wie gesagt, klar, wenn Sie
jemanden anderen Rechenschaft schuldig sind, die vom Rechnungshof, die tun dann
natürlich auch etwas evaluieren, aber das ist auch meist nicht wirklich sinnvoll, da wird halt
dann irgendetwas zusammengerechnet, ja.
50 Interviewer: So perfekt, somit sind wir schon am Ende. Danke für das Interview

138
 C.5 Transcript Interview E
1 Interviewer: Könnten Sie bitte einen kurzen Überblick über Ihre Person und über Ihr
Unternehmen bzw. inwieweit Sie mit ERP Upgrade Projekten zu tun haben?
2 Interviewter E: Grundsätzlich bin ich seit Mai 2016 bei der XYZ Projektmanager und stehe
in einem Upgrade Projekt bei Dynamics AX 4.0 auf 365, ahhm, das ist das aktuelle und auch
Einführungen vom AX sag ich jetzt einmal, wo es um Cross-Upgrades geht von Navision
auf 2012. Vorher war ich 24 Jahre lang IT-Leiter auch vertraut mit Einführungen, Upgrade
Projekten anderer Hersteller. Dynamics ist bei mir aktiv seit knapp einem Jahr.
3 Interviewer: In welchem Umfang kann man sich ein ERP-Upgrade Projekt bei Ihnen
vorstellen? Wie lange dauert dies?
4 Interviewter E: Grundsätzlich gibt es verschiedene Ansätze wenn man heute beispielsweise
die bestehenden Prozesse in Dynamics 365 übernehmen kann und keine Änderungen der
Prozesse vorzunehmen hat sind derartige Projekte binnen einem halben Jahr durchzuführen.
Bissl abhängig von der Größe des Betriebs, von der Fitheit der Key-User, ob sie gleichzeitig
auch dann Business-Prozess OwnersiÍnd, hängt einfach vom ganzen Umfeld ab, aber ist
durchaus in Reichweite auch größere Projekte in einem halben Jahr durchzuziehen, das ist
auch das (?Ansinnen?) was mit Dynamics 365 mit verschiedenen Werkzeugen auch
bewerkstelligen kann. Werkzeuge eben für Datenmigration, Datenübernahmen.
5 Interviewer: Was sind Ihrer Meinung nach die Hauptgründe, warum Upgrades durchgeführt
werden?
6 Interviewter E: Zum einen ein Mal, im bestehenden Fall, auf den ich zurückgreifen kann ist
es so, dass die Aktualität der Softwareversion ausgelaufen ist. Man betrachte mal AX4
wurde vom Nachfolgeprodukt AX2009, AX2012, AX2012R3, AX7, neues Branding,
Dynamics AX365 mehr oder minder nachgefolgt oder ersetzt. Das heißt es gibt sehr viele
Weiterentwicklungen, welche in diesem ERP nicht zur Verfügung stehen, das heißt es
müsste ein sehr großer Aufwand betrieben werden, wenn das, sag ich einmal, in Form einer
Programmerweiterung implementiert werden würde, was wirtschaftlich nicht vertretbar ist,
weil man doch sehr viele Funktionen, aktuelle Sachen wie Kontoauszüge zu importieren,
MT940, das ist halt in Dynamics AX integriert, bei einer anderen war das modular, je nach
Hersteller, sag ich einmal, der das einmal entweder individuell für einen Kunden gelöst hat
oder in Form von Modulen zum Kauf zur Verfügung gestellt hat. Es ist jetzt funktionell sehr
stark erweitert, neue Technologien wie RFID etc. sind heute in modernen Systemen
integriert, das heißt wenn bei Kunden ein gewisser Druck kommt, technologisch,
organisatorisch, Änderungen vorzunehmen und auch die Software in einem gewissen Alter
ist, sag ich jetzt einmal, älter als 5 bis 7 Jahre, dann ist es beinahe unausweichlich, den
Schritt zu einem Upgrade Projekt zu machen.
7 Interviewer: Ich habe jetzt auch schon Interviews gemacht, mit Personen die im SAP-
Umfeld unterwegs sind, da wird oft auch genannt, dass der Support von SAP ausläuft. Gibts
das im Microsoft-Bereich auch?
8 Interviewter E: Grundsätzlich ist es so, dass wir als Partner von Microsoft den First-Level,
Second-Level bieten, erst dann wenn es eine, ein Fehler festgestellt wird, im Grundsystem,
dann gehen wir als Partner mehr oder minder auf Microsoft, dort gibt es das, dass mitunter
eine Fehlerbehebung bereitgestellt wird. Aber es ist genauso auch möglich, dass ein Partner
wie XYZ oder ein anderer auch im Source einen Fehler behebt. Der Support als solches wird
natürlich auch für sehr alte Produkte angekündigt, dass er dann abgekündigt wird.
Grundsätzlich ist es so im vorliegenden Fall, wo wir von dem AX4 sprechen, hat der Kunde
AX2009 offiziell lizenziert, bezahlt dafür Wartung und das somit auch berechtigt in Form
eines Upgrades neue Lizenzen oder die neue Version mehr oder minder zu vergünstigten
oder sehr günstigen Konditionen letztendlich in Anspruch zu nehmen.
9 Interviewer: Die nächste Frage wär, was sind so die Hauptziele die bei so einem Upgrade-
Projekt definiert werden?
10 Interviewter E: Letztendlich geht es überall um die Wirtschaftlichkeit und auch darum in
gewissen Belange schneller zu werden. Das heißt es gibt nach wie vor in Unternehmen
manuelle Schnittstellen, Papierschnittstellen, das heißt derartige Prozesse aufzuräumen, in

139
 Verbindung mit Dokumentenmanagementsystemen, mit Workflow, mit elektronischen
Datenaustausch, was heute das ganze Supply-Chain anlangt, wird immer wichtiger. Also,
Prozesse im Tagesgeschäft elektronisch zu unterstützen, das ist gewisser Leistungsdruck an
die Unternehmen und wenn man eben auch die Wirtschaftlichkeit betrachtet, ist es eben ein
Nachteil Mitbewerbern gegenüber, wenn man hier nachhinkt, sag ich einmal, höheren
Personalaufwand hat, langsam ist teilweise dadurch, wenn gewisse Verrichtungen manuell
erledigt werden müssen, und das drängt einfach auch Unternehmen, sag ich jetzt einmal, am
Fokus zu bleiben, was derzeit technologisch möglich ist.
11 Interviewer: Somit kommen wir schon zum Hauptthema meiner Arbeit, da geht es um die
Erfolgsfaktoren. Welche Faktoren, sind Ihrer Meinung nach kritisch, für den Erfolg so eines
Projektes?
12 Interviewter E: Das heißt man sollte das Rad nicht neu erfinden. Es werden teilweise bissl
Ausflüchte gesucht, trotz alle dem sind die Systeme im Standard so gut abgebildet, dass man
möglichst standardnahe einführen sollen, das wiederum bringt den Vorteil, dass man sehr
rasch, mit einem Upgradesystem live gehen kann. Zum Einen muss man auch die Prozesse
kennen, um die auch einmal in einem neuen System zu designen und man muss sich selbst,
dann gewisse Dinge in Frage stellen. Ist es notwendig, ist es wirtschaftlich vertretbar
gewisse Dinge in ein System zu implementieren, sei es jetzt aus Befindlichkeiten oder weil
man das Jahre oder immer so gemacht hat. Das heißt man muss durchaus Fragepunkte sich
selbst stellen, ob das vertretbar ist, ob das sinnvoll ist, in ein System überhaupt zu
integrieren, in der Form oder in der Wunschform wie das vielleicht Key-User oder Prozess-
Owner vielleicht haben, das heißt, da muss man gemeinsam einfach schauen, das Optimum
für das Projekt und für die nachfolgende Phase, sag ich jetzt einmal, zu implementieren. Die
Erfahrung hat gezeigt, dass teils Prozesse implementiert werden, die in Folge dann sehr
wenig, sehr selten genutzt werden und deren Implementierung viel Geld gekostet hat. Das ist
ein kritischer, man kann das sehr viel Zeit verlieren, sehr viel Geld investieren, man muss
dann noch einmal zurück, bis zu einem gewissen Punkt hat das gepasst, da hat man sich
dann verloren oder auf dem aufsetzend, muss man das ganze dann noch einmal redesignen,
irgendwelche Vorstellungen, wenn solche Vorstellungen von Key-Usern oder Prozess-
Ownern ohne Prüfung der Sinnhaftigkeit dann in ein System implementiert werden, das sind
sehr sehr kritische Erfolgsfaktoren. Und ein weiterer ist die Zusammenarbeit des
Projektteams auf der Kundenseite, als auch auf der Dienstleister oder Lieferantenseite, das
man offen mit dem umgeht, dass man die Ziele im Fokus behaltet, Befindlichkeiten zur
Seite legt. Es kann durchaus sein, dass kritische Momente entstehen, wenn man mit einem
System auch gewisse Arbeiten, Tätigkeiten, Verrichtungen wegbringt oder wegrationalisiert.
Da ist Vorsicht geboten. Mein Studienabschluss, den ich nebenberuflich gemacht habe, ist
noch nicht soweit weg. Ein Change Manager in diesem Bereich muss oder sollte so ein
Projekt gegebenen falls begleiten. Auch die Organisation beim Kunden entsprechend
zeitgerecht anzupassen. Das ist ein wesentlicher Faktor, wenn man heute optimiert,
gewachsene Prozesse im System dann eine Optimierung vornimmt und die Organisation als
solches nicht vorbereitet wird, sei es wenn es Personalrochaden gibt, sei es wenn es
Freisetzungen gibt, sei es wenn Tätigkeiten woanders hin verlagert werden. Das muss man
in der Organisation zeitgerecht mit Fingerspitzengefühl vorbereiten und begleiten.
13 Interviewer: Können wir die angesprochenen Faktoren vielleicht noch priorisieren? Was ist
Ihrer Meinung nach der wichtigste Faktor?
14 Interviewter E: Es sollten gewisse Ziele niedergeschrieben werden. Die bleiben im Fokus.
Das Zusammenspiel und die Zusammenarbeit des Teams und auch die Begleitung und die
Anpassung in der Kundenorganisation.
15 Interviewer: Sind in dem jetzigen Projekt, in dem Sie tätig sind oder vielleicht in einem
Früheren schon ein mal gröbere Probleme aufgetreten und mit welchen Maßnahmen ist man
solche Probleme angegangen?
16 Interviewter E:Grundsätzlich, wenn das anspricht wo es menschelt, wenn versucht worden
ist an veralteten Dingen, verkrusteten Dingen festzuhalten. Dann muss man mitunter im

140
 Lenkungsausschuss oder mit den Projektauftraggebern auch darüber verhandeln oder
diskutieren oder mit einem Change Manager, das ist vielleicht die neuere Form, wie man das
ganze wieder auf Richtung bringt. Aus dem Projekt rauszugehen und dann sagen, ja wir
haben da ein Problem, wir müssen eine Lösung suchen, wie geht man das an, zum einen Mal
der fachliche Part, das ist mitunter einfach aber der Bereich wo es menschelt, da braucht
man einen speziell geschulten Manager, Mitarbeiter, Projektbegleiter der die Sachen, dann
begleitet.
17 Interviewer: Ein zweiter Punkt in meiner Arbeit beschäftigt sich ja auch mit den
Unterschieden hinsichtlich Erfolgsfaktoren zwischen reinen Implementierungsprojekten und
Upgradeprojekten. Wo sehen Sie da die größten Unterschiede?
18 Interviewter E: Die größten Unterschiede, es ist eigentlich gar nicht so unterschiedlich. Ob
man jetzt von einer Vorversion auf eine neuere Version umsteigt oder ein Upgrade macht,
dort gibt es meiner Erfahrung nach Werkzeuge, Daten zu migrieren mit gewissen Features
die der Hersteller berücksichtigen kann, downgradable etc. Wenn man jetzt so ein Cross-
Upgrade macht, wenn man jetzt von anderen Systemen übernehmen muss und dort vielleicht
ein bisschen eine andere Philosophie, andere Begriffe sind, dann gibt es dort mitunter die
Notwendigkeit die Begriffe, wenn sie nicht gleich sind, sie auch zu erklären. Es gibt gewisse
Branchen, ein Projekt ist zum Beispiel jetzt Furniture-Bereich, ein Projekt aus Erfahrung ist
ein Hörgerätehersteller oder Vermarkter letztendlich, wo einfach gewisse interne
Firmenbegriffe sich eingeschlichen haben oder verwendet werden und die mitunter falsch
interpretiert werden von einem Consultant. Da muss man dann immer schauen, was versteht
der eine jetzt unter dem und was versteht der andere. Das heißt das auf einen gleichen
Nenner zu bringen, muss man mit Fingerspitzengefühl dran gehen, damit beide das gleiche
Verständnis haben. Das ist bei einem Einführungsprojekt meist mehr Aufwand notwendig,
wie wenn man ein Upgrade-Projekt hat, wo der Kunde das Vorsystem schon gekannt hat. Er
ist teilweise schon sehr fitmit dem Neuen und findet sich darin, im Neuen, sehr schnell
zurecht. Es hat sich vielleicht eine Oberfläche geändert, aber sehr viel von dem was von dem
alten System ins neue eingeflossen ist, findet er wieder. Bei einem Cross-Upgrade hat er
grundsätzlich eine andere Bedienung und andere Begriffe. Das sind so vielleicht
zusammengefasst, die markanten Punkte wo die Unterschiede liegt.
19 Interviewer: Ich hab mich in letzter Zeit mit der Literatur zu Erfolgsfaktoren bei ERP -
Implementierungsprojekten beschäftigt? Ich würde Sie bitten die folgenden Erfolgsfaktoren
zu priorisieren von sehr wichtig bis gar nicht wichtig.
20 Interviewter E: OK
21 Interviewer: Top-Management-Support?
22 Interviewter E: sehr wichtig
23 Interviewer: Change Management?
24 Interviewter E: sehr wichtig
25 Interviewer: Business Plan und Vision?
26 Interviewter E: wichtig
27 Interviewer: Projektmanagement
28 Interviewter E: sehr wichtig
29 Interviewer:BPR & Customization?
30 Interviewter E: wichtig
31 Interviewer: Zusammenstellung des Projektteams?
32 Interviewter E: wichtig, kann aber sein, dass man da oder dort einen Change machen muss
33 Interviewer: Software Testing?
34 Interviewter E: Wichtig
35 Interviewer: User Training & Schulung?
36 Interviewter E: Sehr wichtig
37 Interviewer: Business Case?
38 Interviewter E: weniger wichtig
39 Interviewer: Kommunikation?

141
40 Interviewter E: sehr sehr wichtig
41 Interviewer: Projektchampion
42 Interviewter E: weniger wichtig
43 Interviewer: Management von IT-Legacy Systemen?
44 Interviewter E: wichtig
45 Interviewer: Herstellerunterstützung?
46 Interviewter E: wichtig, sollte aber eine gewisse Basis sein, der Zugang
47 Interviewer: Post-Implementation Evaluation?
48 Interviewter E: Was verstehen Sie darunter?
49 Interviewer: Ich verstehe darunter, dass man am Ende des Projektes noch mal alles evaluiert
und schaut, was ist gut gelaufen, was ist schlecht gelaufen um für zukünftige Projekte zu
lernen.
50 Interviewter E: Das muss man regelmäßig machen, es gibt bei uns je nach Umfang des
Projektes in einmonatig oder zweimonatigen Abständen Lenkungsausschüsse, wo dieser
Part aufgearbeitet wird auch dargestellt wird und sofort reagiert wird. Das heißt auch intern,
XYZ intern, wird das besprochen und im Lenkungsausschuss auch, wenn etwas gut oder
schlecht gelaufen ist, Verbesserungspotential sollte sich nicht anstauen bis ans Ende des
Projektes, sondern wenn das erkannt wird, man macht ja auch eine Risikobewertung, wenn
da Risikofaktoren auftauchen, sollte das eigentlich ein kontinuierlicher Prozess sein.
Zumindestens zyklisch.
51 Interviewer: Somit sind wir am Ende des Interviews. Vielen Dank

142
 C.6 Transcript Interview F
1 Interviewer: Bitte geben Sie einen kurzen Überblick über Ihre Person, Ihren
Aufgabenbereich und Ihre Verbindung zum Thema ERP Upgrades?
2 Interviewter F: OK, ja, also Christoph Weiss mein Name, bin der Geschäftsführer der XYZ,
und die XYZ beschäftigt sich schwerpunktmäßig mit dem Thema Prozessmanagement,
Franchising und ERP-Auswahl, Einführung und stetige Weiterentwicklung und hinter dieser
stetigen Weiterentwicklung steht natürlich das ganze Thema Prozessoptimierung und
Upgrades von ERP Systems und das ist unser Tagesgeschäft und ich persönlich mache seit
20 Jahren, ahh, ich subsummiere es mal unter ERP Beratung.
3 Interviewer: Ok, super, danke. Können Sie einen kurzen Überblick über Ihr letztes ERP
Upgrade geben, in welchem Umfang sich dies ungefähr abgespielt hat, wie lange dieses
Projekt ca. gedauert hat?
4 Interviewter F: Ich muss jetzt kurz eine Frage dazwischen stellen, was Sie unter Upgrade
verstehen? Weil es verstehen, fragen Sie 4 Leute, dann bekommen Sie 4 Antworten.
5 Interviewer: Nun ja für mich ist, ich habe Upgrade in meiner Arbeit jetzt so definiert, dass
darunter sozusagen eine Installation einer neuen Version eines bereits installierten ERP
Systems sozusagen verstanden wird und der Grund für solche Upgrades einerseits, entweder
ein auslaufender Support-Vertrag bzw. auch die Notwendigkeit von neuer Funktionalität
gegeben ist und daher ein Upgrade notwendig ist.
6 Interviewter F: OK, machen wir ein einfaches Beispiel, also geht nicht darum, sie lösen,
keine Ahnung, [..] durch SAP ab, sondern Sie hätten jetzt ein SAP R3, ich bezeichne, das als
[..] und Sie würden das Ganze auf HANA migrieren, oder?
7 Interviewer: Richtig, ganz genau, das würde ich darunter verstehen.
8 Interviewter F: Und die Frage war jetzt?
9 Interviewer: In welchem Umfang sich so ein Projekt abspielt? Wie lange dauert dies ca.?
10 Interviewter F:Puhh, es hat so ca. ein halbes Jahr gedauert.
11 Interviewer: Was glauben Sie, sind die Hauptgründe warum solche Upgrades durchgeführt
werden?
12 Interviewter F: Ja, einen haben Sie eh schon genannt, dass der Supportvertrag ausläuft vom
Anbieter und man, genau, und es geht halt darum, die Nutzung von neuen Möglichkeiten des
neuen Releases. Ist einmal, sicher das Zweite und das Dritte ist einfach, aufgrund von
solchen Migrationsprojekten, ist einfach Prozessinnovation viel leichter umzusetzen, als wie
bei bestehenden Systemen.
13 Interviewer: Somit kommen wir eh schon zum Hauptthema, wo sehen Sie die größten
Erfolgsfaktoren bei solchen Projekten, welche Faktoren sind ausschlaggebend, damit
derartige Projekte erfolgreich durchgeführt werden können?
14 Interviewter F: Jetzt muss man unterscheiden, mache ich rein eine technische Migration,
oder mache ich eine Prozessmigration, ja wenn es eine technische Migration ist, mein Gott,
dann ist der Erfolgsfaktor, dass ich das ganze technisch umsetze, aber das Andere ist, eben,
der Erfolgsfaktor ist immer wieder das gleiche wie bei allen anderen, sag ich jetzt auch
Neueinführungsprojekten, dass die Geschäftsführung dahinter steht, dass die Mitarbeiter,
dementsprechend, auch, auf neue Herausforderungen vorbereitet werden, nicht nur ERP-
technisch, sondern auch prozesstechnisch.
15 Interviewer: OK, Sie sind jetzt natürlich auf der Seite des Consultants, aber sehen Sie auch
externes Consulting als einen Erfolgsfaktor?
16 Interviewter F: Es gibt natürlich viele Erfolgsfaktoren sag ich jetzt einmal, also beim
Consulting muss man es wieder trennen, das eine ist der Erfolgsfaktor des Consultants, des
ERP Herstellers oder Implementierungspartners, und das andere ist noch der Erfolgsfaktor,
wenn ich jetzt einen neutralen Consultant, wie zum Beispiel die XYZ miteinbeziehe. Ganz
klar natürlich.
17 Interviewer: Sind bei einem Ihrer letzten Projekte, irgendwie gröbere Probleme aufgetreten
und wenn ja, mit welchen Maßnahmen hat man diese Probleme gelöst? Oder was sind Ihrer
Meinung nach so klassische Probleme die bei solchen Projekten auftreten?
18 Interviewter F: Der größte Fehler ist, den man immer wieder macht, ist einfach, dass man

143
 sagt, jaja, jetzt machen wir halt den Releasewechsel. Sie wissen was ich meine. Da passiert
nichts, und alles andere läuft so wie es ist, ja und das ist eigentlich die größte
Herausforderung, und dass das ganze einfach unterschätzt wird und gar nicht als Projekt
gesehen wird und das läuft einfach so irgendwie nebenbei.
19 Interviewer: Das heißt Sie sind der Meinung, es ist auf jeden Fall sehr sehr wichtig, das klar
als Projekt zu definieren und dementsprechend auch dahinter zu stehen?
20 Interviewter F: Ja genau, mit wirklichem klassischen, sag ich jetzt mal, Projektmanagement,
wo einfach auch die Leute intern die Ressourcen einfach auch freigestellt, freigespielt
werden und jetzt komme ich wieder auf die Geschäftsführung zurück, dass man auch ganz
klare Ziele und einen Nutzen festlegt, weil das größte Thema ist, dass in Projekten, das sage
ich jetzt einmal so als Consulter komplett neutral, es wird einfach viel zu wenig der Nutzen
definiert, was soll denn eigentlich der Nutzen sein dieses ERP Systems, bei diesem Projekt.
Beispiel jetzt, zurück zu kommen auf ein ERP Migrationsprojekt, zu sagen, das Ziel ist es
auf das neueste Release des ERP Herstellers zu migrieren, das ist noch kein Ziel, das ist kein
Nutzen.
21 Interviewer: Anhand von welchen Merkmalen würden Sie ein Projekt als erfolgreich
bezeichnen?
22 Interviewter F: Das ist die Frage, was ist erfolgreich, Punkt 1, Punkt 2, ganz einfach, es
muss der Nutzen im Vorhinein definiert werden, damit ich es im Nachhinein messen kann,
also wieder klassisches Beispiel im Endeffekt, ich mache das Migrationsprojekt, um, also
Hausnummer, das müssen ja die Anwender, müssen das eigentlich festlegen, dass sie sagen,
ich möchte meine Aufträge um 10% optimieren oder meinen Prozessablauf im Einkauf
soviel verbessern, und das ganzheitlich und das ist der springende Punkt, und das ist
eigentlich ganz was anderes, dass man das nicht nur am Ende des Projektes misst, sondern
auch 1 Jahr, 3 Jahre oder 5 Jahre danach, weil das sage ich jetzt einmal, das macht im
Prinzip fast überhaupt niemand. Da sage ich Ihnen jetzt einmal Out-of-Record, das haben
Sie jetzt wahrscheinlich noch nicht gehört.
23 Interviewer: Ein weiterer Aspekt in meiner Arbeit beschäftigt sich mit den Unterschieden,
zwischen klassischen Implementierungsprojekten und Upgrade Projekten. Wo sehen Sie da
die größten Unterschiede, auch bezüglich Erfolgsfaktoren?
24 Interviewter F: Das ist kein Unterschied was Erfolgsfaktoren betrifft, es ist für mich ein
Migrationsprojekt, ein richtiges Migrationsprojekt, ist im Endeffekt für mich wie ein
Neuprojekt, ein Implementierungsprojekt zu sehen, es ist halt vielleicht nicht so
umfangreich.
25 Interviewer: In der Literatur werden folgenden Faktoren für den Erfolg eines
Implementierungsprojektes genannt:
26 Bitte beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der
Skala (sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig).
27 Interviewter F: Ok, gerne
28 Interviewer: Top Management Unterstützung
29 Interviewter F: sehr wichtig
30 Interviewer: Change Management
31 Interviewter F: sehr wichtig
32 Interviewer: Business Plan & Vision
33 Interviewter F: wichtig
34 Interviewer: Projektmanagement
35 Interviewter F: sehr wichtig
36 Interviewer: BPR & Customization
37 Interviewter F: Die Frage kann man so nicht beantworten, es sind zwei Fragen für mich. Für
mich muss man das trennen, das Eine ist Business ProcessRedesign, das hängt jetzt davon
ab, kann ich so nicht beantworten. Und was heißt Customization, da muss man
unterscheiden, bei dem einen Hersteller ist das eine reine Parametereinstellung und der
andere Anbieter sagt nämlich Programmieren dazu.

144
38 Interviewer: Zusammensetzung des ERP Teams
39 Interviewter F: Das ist jetzt Teil des Projektmanagements, jetzt lösen Sie es auf. Ahh, mein
Gott, also wichtig.
40 Interviewer: Software Testing
41 Interviewter F: ganz wichtig
42 Interviewer: User Training
43 Interviewter F: Also Schulungen meinen Sie damit?
44 Interviewer: Genau
45 Interviewter F: wichtig
46 Interviewer: Business Case
47 Interviewter F: wichtig
48 Interviewer: Kommunikation
49 Interviewter F: sehr wichtig
50 Interviewer: Projekt Champion, also jemand der das Projekt nach innen und außen gut
vertritt und gut verkauft?
51 Interviewter F: weniger wichtig
52 Interviewer: Management von Legacy Systemen?
53 Interviewter F: Was verstehen Sie darunter?
54 Interviewer: Ich verstehe darunter, dass zum Beispiel in einem Unternehmen noch Alt-
Systeme im Einsatz sind und bei einem Upgrade eventuelle Kompatibilitätsprobleme
auftreten können und man somit checken muss, ob die Funktionalität nach dem Upgrade
sichergestellt werden kann.
55 Interviewter F: wichtig
56 Interviewer: Hersteller Unterstützung, vom ERP Anbieter
57 Interviewter F: Da ist jetzt die Frage, ist es der Hersteller oder der Implementierungspartner?
58 Interviewer: Gute Frage, also im Falle von SAP wird vermutlich der Unterstützung sehr
stark vom Hersteller kommen?
59 Interviewter F: Nein, gar nicht, weil das macht alles der Implementierungspartner und daher,
ich würde das ganze als Anbieter, sozusagen, titulieren und dann auf jeden Fall sehr wichtig
natürlich
60 Interviewer: Der letzte Punkt, Post Implementierungs-Evaluierung
61 Interviewter F: Was verstehen sie darunter?
62 Interviewer: Projekt Review & LessonsLearned
63 Interviewter F: Sehr wichtig

145
 C.7 Transcript Interview G
1 Interviewer: Bitte geben Sie einen kurzen Überblick über Ihre Person, Ihren
Aufgabenbereich und inwieweit Sie mit dem Thema ERP-Upgrades zu tun haben?
2 Interviewter G: Ok, ja mein Name ist Christian Chvosta, ich leite das Competence Center
Applikationen in der XYZ das heißt ich bin mit meiner Mannschaft von insgesamt 20
Mitarbeiterinnen und Mitarbeitern für das eigentlich komplette SAP-System, für den Betrieb
von der Basis weg über sämtliche Module im betriebswirtschaftlichen und klinischen
Bereich verantwortlich. Auch für die Weiterentwicklung, wir haben in eigentlich allen
Bereichen entsprechende Systembetreuer die, oder auch Modulbetreuer, die auch selbst
entwickeln. Also es ist nicht nur der Betrieb, sondern auch die laufende Weiterentwicklung,
vor allem im klinischen Bereich, haben wir sehr sehr viel Eigenentwicklung. Ich selbst bin
jetzt seit 8 Jahren in der XYZ und bin eigentlich auch gleich eingestiegen mit, was war erste
Patchprojekt, ich glaube EHP 5. Und habe seither, meine Güte, da muss ich nachzählen, also
sicher 4-5 Patchprojekte gemacht auch geleitet, also als Projektleiter. Dazu eine Unicode-
Migration und eine Virtualisierung, also von physischen Maschinen in eine VM-Ware
Umgebung, das war letztes Jahr. Teilweise EHP-Projekt, teilweise auch nur Patchprojekte.
3 Interviewer: In welchem Größenbereich, befindet sich das System, das hier eingesetzt wird,
an Anwendern ungefähr?
4 Interviewter G: Ja, wir haben an die 6000 insgesamt, dazu muss man auch sagen, wir haben
eine Ein-System-Landschaft. Das ist ganz wichtig, das ist auch, wenn wir dann von
Erfolgsfaktoren sprechen, ist das natürlich die Komplexität und der Stress dahinter, ein
anderer wenn ich jetzt mein System geclustert hab, oder sei es mehrere Mandanten oder
überhaupt mehrere Systeme. Wir haben ein System und einen Mandanten am SAP System
für 6000 User, für über 130 Buchungskreise, also wir haben nicht nur in der XYZ die 7
Krankenhäuser, sondern wir haben auch eine Reihe von verbundenen Unternehmen und die,
also das ist entsprechend groß und da muss man immer. Ahh, wenn ich vorgreife dann sagen
Sie es mir, weil ich kenne die Fragen nicht.
5 Interviewer: Das passt schon
6 Interviewter G: Es ist natürlich, je größer das System und je mehr Betroffene und je vor
allem je mehr Eigenentwicklung, ist ja auch ein ganz ein wichtiger Faktor, desto einerseits
länger die Durchlaufzeit so eines Patchprojektes und damit auch länger der Transportstopp.
Das ist, wenn man viel eigen entwickelt ganz eine kritische Geschichte, weil ich in der Zeit
eigentlich entwicklungsmäßig Pause habe. Ja, ich kann während dem Patch, werden wir
vielleicht auch noch drüber sprechen, wie so ein Patch eigentlich abläuft über die SAP
System Landschaft, dass ich eigentlich natürlich während dem Patchzyklus nicht
Entwicklungen durchtransportieren kann.
7 Interviewer: Wenn wir vielleicht so kurz über eines der letzten Projekte sprechen, in
welchem Zeitraum hat das stattgefunden, wie lange hat das circa gedauert?
8 Interviewter G: Das kann ich Ihnen ganz genau sagen, wir machen das, also bei uns ist ein
Patch immer ein Projekt. Jetzt kann man sagen, ein Projekt ist eigentlich normalerweise
keine wiederkehrende Tätigkeit, aber es ist ja nur ein Merkmal für ein Projekt, sondern auch
die Kritikalität, ich mein es ist ja unser Herz, SAP, das sind 7 Krankenhäuser und ein
Haufen Firmen die da dranhängen, die da darauf fahren, also wenn das nicht läuft, dann
dampft es, dann haben wir wirklich ein Problem. Und alleine aus dieser Kritikalität her,
machen wir das immer als Projekt. Das heißt, das ist ein gemanagtes Projekt, mit einem
entsprechenden Auftrag, Zeitplan, Projektstrukturplan, Projektcontrolling, alles. Also da
fahren wir die ganze Maschine auf und wir sprechen da immerhin auch von einem Umfang
von 280 Personentagen, die wir eigentlich regelmäßig immer haben, das ist interessant. Wir
haben Zeitaufzeichnungen und wenn ich dann so 2,3 Wochen nach Produktivgang dann, da
ist es dann wirklich abgeschlossen, einen Strich ziehe, dann komme ich immer auf plus
minus 280 Tage, was wir in der gesamten IT dafür brauchen. Auch der Aufwand ist groß. Zu
dem Zeitplan. Den letzten Patch hatten wir im Herbst 2016, also bei uns realistisch ist,
dadurch, dass wir knappe zwei Monate eigentlich damit beschäftigt sind, haben wir
realistisch zwei Zeiten im Jahr wann wir überhaupt patchen können. Das ist vor dem

146
 Sommer und nach dem Sommer. In den Sommerferien ist natürlich ein Teil auf Urlaub,
dann haben wir Jahresabschluss vorher, dann Jahresende ist auch eher eine schlechte Zeit
projektmäßig so etwas zu machen, eben weil da oft grad viel Entwicklungen noch fällig
sind, die man noch umsetzen will. Also das sind so die beiden Zeitfenster die wir haben, das
ist so Mai-Juni bzw. dann eher August-September, in den Herbst hinein. Zum letzten Patch,
da hatten wir das Wochenende, Ende Oktober war das. Brauchen Sie genau Daten
9 Interviewer: Nein, ein grober Überblick reicht!
10 Interviewter G: Also so ein typischer Patchzyklus schaut so aus, dass man sagt, wir haben
eine 3-System-Landschaft plus Sandbox. Wenn man jetzt die 2 Monate hernimmt,
Durchlaufzeit, dann würde man wahrscheinlich die ersten, Pi mal Daumen verbringt man ca.
2 Wochen auf jedem System. Erste Phase mal auf der Sandbox den Patch einspielen, dass
man, wo es noch gar nicht jetzt um den Objektabgleich oder so geht, da geht es rein darum,
ist das Einspielen vom Patch, passt das, ja wir sind ca. die Durchlaufzeiten, da kann man
von der Sandbox hochrechnen auf die anderen Systeme, vor allem auf das Produktivsystem,
wo man circa liegt. Weil für ein Krankenhaus ist natürlich die Downtime die man mit einem
Patch hat ganz kritisch. Viele andere Unternehmen wird es wurscht sein, wenn man einmal
am Wochenende einen Patch macht, wenn die am Freitag heimgehen und am Montag läuft
es wieder. Wir haben wie gesagt 7 Krankenhäuser und davon ein Krankenhaus, das
Akuthaus in Ried, Regionalspital, Barmherzige Schwestern Ried, die ein Unfallspital sind.
Das heißt die haben 7 mal 24 Betrieb, für die schmerzt jede Stunde, die bekommen rund um
die Uhr die Patienten rein und können quasi ohne SAP nicht mal eine Aufnahme machen.
Das heißt wir sind von daher natürlich, ist die ganze Near-Zero-Downtime-Thematik eine
große, ja. Zumindest die Downtime möglichst gering zu halten.
11 Interviewer: Inwieweit kommt man da zu null?
12 Interviewter G: Nein, also zu null, also da sind wir schon weit entfernt. Wir reden von, nun
ja der Patch selber, da ist man in, je nachdem 4 bis 6 Stunden durch, was bei uns dann
natürlich noch dazukommt, ist die Testphase. Das heißt, wir testen auch am
Produktivsystem, wo noch alle User draußen gesperrt sind, testen wir am Produktivsystem
ganz intensiv sehr zeitig in der Früh. Alle mit SAP irgendwie betrauten Mitarbeiter, das
ganze System noch einmal durch. Es gibt da kein Zurück, gepatcht ist gepatcht. Also es gibt
de facto, sobald die erste Transaktion erfolgt ist der Weg zurück mehr oder weniger
ausgeschlossen. Vor allem bis ich darauf komme und dann die Entscheidung getroffen habe,
habe ich schon einen Haufen Transaktionen. Also es gibt natürlich ein Backup vom vorm
Patch, nur sobald ich Transaktionen hab, komme ich mehr darauf. Das heißt die sind auf
jeden Fall weg. Und Datenverlust ist in unserem Geschäft ein absolutes No-Go. Und das
geht nochmal erheblich auf die Zeit. Also würde ich das nicht machen, was wahrscheinlich
wiederum ein anderes Unternehmen, die sagen wir haben ein Entwicklungssystem, wir
haben ein Konsolidierungs- oder Qualitätssicherungssystem, ahhmm, da ist alles
durchgecheckt, ja die werden das nicht machen, die sind wesentlich schneller. Also wir
reden trotzdem unterm Strich, haben wir im Normalfall, es läuft bei uns immer über ein
Wochenende, Samstag, Sonntag, so gegen 20 Uhr schalten wir ab, stellen dann ein
Ausfallsystem zur Verfügung, ein lesendes, das heißt das ist mit einem Datenstand halt 15
Minuten Logship zurück, SQL-Server haben wir mit Logshipping, wird das
nachgeschrieben. Und somit hat das quasi den Datenstand zur Downtime-Beginn. Dann
haben wir ja circa bis plus minus Mitternacht, 1 Uhr ist der Patch eigentlich durch. Dann ist
in Wirklichkeit Pause, weil um 5 in der Früh ca. fangen wir zu testen an. Dann wird getestet
und so gegen 10 Uhr am Vormittag sind wir wieder da. Also man könnte, wenn man das
unter Tags macht die Downtime reduzieren, aber dann wären die Schmerzen unterm Strich
trotzdem größer, darum macht man es über Nacht. Also, effektiv Downtime würde ich
rechnen, ahh, 4 bis 6 Stunden für den Patch und 2 Stunden zum Testen. Also wenn ich es am
Stück mache, dann kann ich in 6 bis 8 Stunden durch sein, aber die brauche ich. Und, ja und
jetzt zum Projektplan, Durchlaufzeit plus minus 8 Wochen. Die ersten 2 Wochen würde ich
ca., 1 bis 2 Wochen auf der Sandbox verbringen, also grundsätzlich, da ist der Fokus auf

147
 dem Patch einspielen selber, da gibt es in der Regel immer da und dort Stolpersteine. Und da
finden auch die Optimierungen statt. Das heißt da schaut man dann, was kann ich noch in
die Uptime-Phase legen, vorher oder nachher, um die eigentliche Down-Time möglichst
gering zu halten. Das dauert ein bis zwei Wochen. Dann beginnt das ganze am
Entwicklungssystem, Patch einspielen, dann kommen schon die ersten Tests, also auch
funktional und ganz wichtig dann SPAU, SPAU heißt die Transaktion in SAP, das ist der
Objektabgleich, weil natürlich seit dem letzten Patch, einerseits Eigenentwicklungen die
Objekte manipulieren auf der anderen Seite auch Änderungen im Standard passiert sind und
das gilt es immer abzugleichen. Das ist am Entwicklungssystem ganz eine wichtige Phase
die auch einige Tage in Anspruch nimmt. Je nachdem wieviel Eigenentwicklung ich habe.
Das hängt wiederum davon ab, wie lange ist mein letzter Patch her. Also wenn ich da jetzt 5
Jahre Eigenentwicklung habe, weil ich 5 Jahre nicht gepatcht habe, dann wird das natürlich
mehr sein, wie wenn mein letzter Patch ein halbes Jahr her ist. Und wenn ich grundsätzlich
nicht eigen entwickle oder nur sehr wenig, dann wird es auch wenig sein. Ja, dann
Entwicklungssystem, da machen wir es so, dass die erste Woche eigentlich vor allem die
Entwickler darauf schauen und wir erst in der zweiten Woche in die Breite mit den Tests
gehen. Wo wir dann wirklich auch Applikationsbetreuer draußen in den Häusern testen
lassen. Die ganzen Tests werden dokumentiert, die Testfälle. Also testen ist nicht einfach
probieren, ich schau mal ob es geht, ich nehme einen Patienten auf und probiere mal alles
durch, sondern testen tun wir an die, es sind weit über 1000 Testfälle.
13 Interviewer: Aber es sind manuelle Testfälle, keine automatisierten?
14 Interviewter G: Nein, wir haben sie nicht automatisiert.
15 Interviewer: Ist das überhaupt möglich im SAP Umfeld?
16 Interviewter G: Es gibt Testautomationssoftware, wir haben das auch schon überlegt, ist an
zwei Dingen gescheitert, dass wir einen irrsinnig hohen, in den Häusern,
Individualisierungsgrad haben. Das macht es sehr sehr schwer und auf der anderen Seite die
Programme wirklich teuer. Also da ist die Frage, ob da dieser Erkenntnisgewinn im
Verhältnis zu dem, ob uns das so viel bringt. Aber es ist, vielleicht haben wir einfach auch
noch nicht das richtige Produkt gefunden. Aber wir haben so viel Eigenentwicklung, dass es
sehr schwer ist, das mit einem automatisierten Werkzeug zu testen. Darum ist die einzige
Unbekannte, die wir eigentlich wirklich immer letztlich haben, oder wo wir uns auf das
Gefühl verlassen müssen, ist Performance. Wo wir, die Last, die können wir in den Tests gar
nicht generieren, die dem entspricht, was draußen passiert. Also da hat uns unser Gefühl
bisher eigentlich immer ganz gut beraten, aber das ist so richtig immer die Unbekannte, wo
man dann am Montag in der Früh sagt, OK, wir haben alles durchgetestet funktional aber
wie sind die Antwortzeiten. Wir haben gewisse Referenztransaktionen die wir ausführen,
Reports wo ich weiß, der läuft vorher nachher, jetzt auf dem gleichen System, vor dem
Patch, nach dem Patch, die Laufzeiten vergleiche, wo mir grobe Sachen, sage ich einmal,
auffallen. Dann ist man am Entwicklungssystem, dann wird das irgendwann freigegeben,
dann geht es aufs QS-System, dort haben wir auch schon die Schnittstellen. Ganz wichtig,
wir haben im Krankenhausbetrieb extrem viel, also hunderte Schnittstellen zu Subsystemen,
also sprich Patientendaten, die vom führenden System, also SAP, an Subsysteme, wenn man
jetzt zum Beispiel die Vorstellung haben von einem Radiologiesystem. Sie, klassisch, Hand
gebrochen, Röntgenbild, das Radiologiesystem muss jetzt irgendwie erfahren, dass es Sie
gibt. Das heißt, es bekommt jetzt mal Patientendaten und muss irgendwie erfahren, was der
Assistent dort überhaupt tun soll. Es gibt einen klinischen Auftrag dazu, der sagt, die und die
Bilder sind zu machen. Wir haben Laborsystem und x andere. Dann passiert das, dann
kommt eine Rückübermittlung, das heißt in der Regel gibt es dann einen Befund, der wieder
ans führende System zurückkommt, der in Ihre Krankengeschichte kommt, Röntgenbefund,
und auch Leistungen die erbracht wurden, dann schon entsprechend codiert, die dann zur
Verrechnung gelangen. Ich muss ja die Leistung dann letztlich auch irgendwie in Geld
münden. Ja so ist dieses Zusammenspiel und das haben wir dann nur am QS-System, am
Entwicklungssystem haben wir noch keine Schnittstellen, das heißt dort ist dann sicher auch

148
 der Schwerpunkt, wie verhalten sich die Subsysteme im Zusammenspiel vor allem beim
Patch ist das normalerweise unkompliziert, bei Unicode, war das das ganz große Thema.
Weil ich dann auf einmal den Namen mitunter mit Unicode schicke und da haben wir
natürlich auch im Vorfeld abgecheckt, kann das System mit Unicode umgehen oder nicht.
Ja, und dann, das sind wiederum 2 Wochen circa, da testet man schon in der Breite, da
haben wir im betriebswirtschaftlichen Bereich auch Key-User in den Fachbereichen, also im
Personal, im Rechnungswesen, die dann auch noch testen. Und dann zwei Wochen, in der
Regel Freitagmittag Freigabe, ja, und dann am Wochenende wird der Patch eingespielt. Also
insgesamt, komme ich halt auf eine Durchlaufzeit, je nachdem ob ich die Sandbox jetzt so
mitrechne, weil die muss jetzt nicht so straff vorher passieren, das kann ein Monat vorher
auch schon sein. Also rein auf der 3-System-Landschaft die in der Regel, glaube ich, alle
Kunden so haben, sagt die SAP. Innerhalb von SAP Entwicklungssystem, QS-System,
Produktivsystem. Also durch diese Landschaft bewege ich mich in 6 Wochen.
17 Interviewer: Cool, was mich noch interessieren würde, was waren die Hauptgründe bei
Ihnen, warum ein Upgrade durchgeführt wird?
18 Interviewter G: Das kann ich ganz schnell beantworten. Der Hauptgrund ist, und das ist der
Nachteil bei einer Ein-System-Landschaft. Ein-System-Landschaft hat viele Vorteile, vor
allem ich muss alles nur einmal was ich jetzt systemweit mache, mandantenweit mache, nur
einmal machen. Von Customizing angefangen, bis natürlich auch Patch. Wenn ich ein
System habe muss ich es nur einmal patchen, wenn ich mehrere habe, muss ich mehrmals
patchen. Aber, es gibt auch Abhängigkeiten, also insbesondere im HR, SAP liefert
regelmäßig HR-Hinweise aus, wo halt vor allem gesetzliche Änderungen drinnen stecken,
die Anpassungen die es halt regelmäßig gibt, jede Steuerreform, was weiß ich, ständig gibt
es Änderungen. Und die bedingen in der Regel immer auch einen gewissen
Basisreleasestand. Und den Basisreleasestand zu ändern, muss ich patchen und wenn ich
patche, wie bei der Schwangerschaft, halb-schwanger gibt es nicht, halb-patchen gibt es
nicht. Also ich patche ein System. Das heißt, ich patche mich durch alle Module, ich patche
mich durch das klinische, also durch alles. Bei uns ISH, ISH-med, alles. Und wir hatten
durchaus, also zumindest an zweit Patches an die ich mich erinnere, die haben wir
ausschließlich gemacht, weil wir nicht mehr in der Lage gewesen wären sonst, HR-Patches
einzuspielen, weil wir den Basis-Release-Stand nicht mehr hatten. Und das ist, das geht
sogar so weit, dass wir eh schon ernsthafte Überlegungen jetzt haben, dass HR-System jetzt
überhaupt heraus zu lösen. Was eh viele Unternehmen haben, auch aus anderen Gründen,
hat auch viel mit Security zu tun und wie viele Leute haben Zugriff auf das System, weil
auch Entwickler natürlich, weil ich sage, Berechtigungen hin oder her, wenn ich mal in die
Tabellen schauen kann, dann kann ich auf dem direkten Weg gehen. Aus Datenschutz, aber
auch aus systemtechnisch durchaus interessant. Weil wenn ich ein eigenes HR-System habe,
dann kann ich das im Prinzip jede Woche patchen am Wochenende, wird niemanden stören.
Und löse diese Abhängigkeit auf. Und da kann man sagen, im Normalfall komm ich mit
einem Releasestand, also in dieser Abhängigkeit zu diesen HR-Patches und damit zur
Basisrelease, 1 bis 1,5 Jahre aus. Das heißt ich muss längstens alles 1,5 Jahre patchen. In der
Konstellation. Und bei unserem System mit, wie gesagt ca. 6000 Usern, sämtlichen
Modulen, einem Riesenbetrieb darauf, ist das großes Kino. Der Entwicklungsstopp, der ist
de facto, der geht los, wenn ich am Entwicklungssystem den Patch einspiele und endet mit
Produktivgang. Das heißt ich habe 6 Wochen Transportstopp und das heißt ich kann zwar im
Prinzip am Entwicklungssystem, dann wieder zum Entwickeln anfangen, also sobald es
gepatcht ist, aber durchtransportieren kann ich es erst, wenn ich hinten raus fertig bin. Und
das ist natürlich schmerzhaft, weil wir halt sehr viel eigen entwickeln und in der Zeit steht
es. Darum ist man da grundsätzlich interessiert, das möglichst selten zu machen, also ist der
Hauptgrund, ist diese Abhängigkeit aufzulösen für uns. Das zweite ist natürlich auch, ich
bekomme mit einem Patch gesammelt alle Hinweise natürlich zu einem Releasestand. Also
wir spielen jetzt, also wir haben im Routinebetrieb, einmal im Monat eine SAP Abschaltung,
die ist geplant über das ganze Jahr hinaus. Sie sehen auf meinem Kalender die lustigen roten

149
 Fenster. Das heißt 2 Stunden spät abends abgeschalten und dann werden alle Sachen, die
eine Abschaltung erfordern, also sprich Transporte, vor allem kritische Transporte werden
dort eingespielt und Hinweise auch eingespielt. Und mit dem Patch bekomme ich halt alles
gesammelt. Alle Korrekturen, die ich so mühsam einzeln einspielen muss. Darum ist es von
Zeit zu Zeit natürlich auch gut. Eher selten ist bei uns, dass wir jetzt mit irgendeinem
Releasestand jetzt irgendwelche Funktionalitäten bekommen, die wir unbedingt brauchen,
kommt vor, aber das wäre für uns jetzt noch nicht der Grund zu patchen, weil, wie gesagt,
das Übel so groß ist, dass der Nutzen auf der anderen Seite jetzt selten da in Relation steht.
19 Interviewer: Gibt es auch die Konstellation, eventuell, dass der Support von SAP
irgendwann wegfällt für alte Versionen. Passiert es?
20 Interviewter G: Da ist SAP eigentlich sehr kulant, also im Verhältnis zu anderen, ja es gibt
es meistens, wie es viele Hersteller jetzt haben, haben so einen Major-Release zurück. Und
bei SAP geht oft, also, war für uns noch nie in der Situation, ich weiß nicht wie oft andere
Patchen, wir sind mit dem einmal im Jahr eher vorne dabei. Aber wenn ich mir die
Releasestände anderer anschaue, eben in der XYZ vor allem auch Krankenhausbetreiber, die
bei weitem nicht diesen Eigenentwicklungsstand haben wie wir, muss man auch dazu sagen,
also wir sind da sicher ganz weit vorne, wenn nicht überhaupt top, vielleicht die XYZ noch,
die sind auch fleißig und groß und sehr inhomogen in dem was sie anbieten. Das spielt auch
mit. Wir haben sehr spezialisierte Häuser. Das heißt, nicht alle haben den so den Stress da
wie wir und die sind oft locker 2 bis 3 Jahre hinten und sind auch noch voll supported. Also,
dass man wirklich aus der Wartung fällt, war bei uns noch kein Thema.
21 Interviewer: Was sind bei Ihnen die Hauptziele bei so einem Upgrade?
22 Interviewter G: Ich zitiere es Ihnen einfach aus dem Projektantrag.
23 Interviewer: Sehr gerne
24 Interviewter G: Das ist jetzt vom letzten Patch, ERP 6.0 auf EHP 7, also Enhancement
Package 7, Support Package Stack 12 war damals der Stand. Vielleicht dazu auch noch,
ganz kurz ein Einwurf. Releasestand ja, natürlich schaut man auch bei der Patchplanung im
Vorfeld, SAP sagt immer auch so eine Roadmap auch wann gewisse Releasestände
rauskommen, dass man sich daran orientiert. Also man ist natürlich immer bemüht den
möglichst letzten Support Package Stack noch mitzunehmen und ich werde jetzt nicht kurz
bevor der rauskommt patchen, weil das kann man mitunter ein halbes Jahr bringen. Wo ich
dann sage, da kann ich dann länger fahren mit dem Releasestand. Das spielt vielleicht bei
der Terminfindung auch noch mit, dass man da auch immer schaut, OK wann sind die, wann
ist die General Availablity von dem Releasestand, wenn ich weiß im September kommt jetzt
noch der Stack 12 raus, den möchte ich noch mitnehmen, dann mache ich es halt ein
bisschen später. Also die Ziele, fünf Stücke. Also der Zielreleasestand EHP 7, Stack 12 ist
implementiert. Zweitens, das SAP System läuft nach dem Upgrade ohne negative
Auswirkungen auf den laufenden Betrieb und dessen Performance. Also es darf eigentlich
nachher zumindest aus der reinen Betriebssicht nichts schlechter sein, als vorher. Da in
diesem Fall haben wir explizit mit aufgenommen, dass die Implementierung eine rein
technische ist und keine funktionalen Änderungen für den Anbieter mit sich bringt. Das
heißt auch, dass es wo es welche gibt, dass wir uns bewusst angeschaut haben, gibt es wo
welche, wo man schulen muss. Aber es war nicht Projektgegenstand, dass wird funktionale
Änderungen ins Feld bringen. Das machen wir dann in gesonderten Projekten im
Nachhinein. Also da ist ganz klar das Ziel, wir wollen patchen, wir wollen nachher den
neuen Releasestand haben, fertig. System soll so laufen wie vorher. Ende. Alles andere wird
gesondert gemacht. Einfach um nicht zu viele Zahnräder auch auf einmal zu drehen. Das ist
oft eine schlechte Idee. Genau, dann, die mit der Umstellung einhergehenden Down-Time
des Systems überschreitet 18 Stunden nicht. Das ist das Zeitlimit. Wir waren deutlich
drunter. Das werden wir auch beim nächsten Mal reduzieren, weil wir in der virtuellen
Umgebung, da auch jetzt einige Möglichkeiten haben, die man auf einem physischen
System nicht hat. Und auch neue Hardware haben mit entsprechender Performance. Also,
das würde ich, wenn ich das jetzt noch einmal mache, setze ich das auf 12 Stunden. Genau.

150
 Und ein NoNa-Ziel, mit der Umstellung wird das Potential für neue Funktionalitäten gelegt.
Also, dass man genau da diese funktionalen Erweiterungen, die kommen auch, dafür die
Voraussetzungen schafft. Und als Nicht-Ziel. Funktionale Erweiterungen, die der neue
Release-Stand ermöglicht werden gesondert implementiert. Ein Projektauftrag ist auch
immer ein bisschen eine Botschaft an die Geschäftsführung, dass sie auch sehen, was sie
nicht bekommen. Also bei uns geht es, und da würde ich auch jedem dazu raten, in erster
Linie mal um den Patch. Es ist oft die Versuchung da, wenn ich schon die Down-Time habe,
das große Abschaltfenster, dann könnte ich ja dieses und jenes auch gleich mitmachen. Ich
kann aus meiner Erfahrung nur warnen davor an zu vielen Schrauben gleichzeitig zu drehen,
weil wenn nachher was nicht funktioniert, dann weiß ich nicht woran es liegt und es ist sehr
schwer die Quelle zu finden. Beim Patch alleine weiß ich, okay, es war der Patch. Wenn ich
jetzt gleichzeitig, es war auch das selbe bei uns bei der Unicode-Migration. Wir haben
virtualisiert und Unicode gemeinsam. Ich habe da einen kompletten Datenbankexport und -
import, das bietet sich an, dass ich das gemeinsam mache. Es Car auch damals schon die
Überlegung, da könnten wir einen Patch auch gleich mitmachen. Wäre kaum auf die
Downtime gegangen. Nur, nein, kommt nicht in Frage. Das ist ein Rad zu viel und gut war
es. Es war Unicode an sich dann aufwendig genug. Ja so viel zu den [Link]:
Somit sind wir schon beim Hauptpunkt, Erfolgsfaktoren. Was sind Ihrer Meinung nach die
kritischsten und wichtigsten Faktoren, die gut laufen müssen, damit so ein Projekt
erfolgreich durchgeführt werden kann und warum?
25 Interviewter G: Das erste ist ein Mal, steckt ja schon in der Frage drinnen, Projekt. Ich
würde es, wie ich eingangs auch gesagt habe, das ist eine wiederkehrende Tätigkeit, stimmt
schon, aber es liegen trotzdem Jahre, liegen in der Regel dazwischen. Das heißt, das
wirklich als Projekt abzuwickeln. Da habe ich auch den großen Vorteil, wenn ich das
gescheit strukturiert abwickle, ich kann mir auch vor Beginn noch einmal das letzte Projekt
anschauen und mittlerweile haben wir da so eine Routine, das ist ein Template, wenn ich
sage ich patche, ich weiß ganz genau was ich tue. Wo schiebe ich das hin, ich weiß was es
heißt. Wir haben auch nach jedem Projekt immer, ganz wichtig, beim Projektabschluss eine
Lessons-Learned Sitzung, wo wir nochmal alle zusammensetzt und wirklich, man macht das
laufend im Projekt, wird da schon befüllt. Alle Dinge wo ich sage, das hat mich jetzt
erklatscht aber, das darf uns nie wieder passieren. Genauso, und das nehme ich mir dann
ganz am Anfang vom nächsten Projekte dann wieder her, das ist so ein lebendes
LessonsLearned, was man durch- und mitzieht und man macht auch jedes Mal einen Fehler
aber ich wage zu behaupten, wir machen jeden nur einmal. Und irgendwas passiert auch
immer, weil sich Dinge ändern, auch das würde ich sehr empfehlen, auch wie gesagt, als
Projekt abwickeln. Also wirklich mit einem Projektmanager, der sich darum kümmert und
nicht nur jetzt quasi so als technisch, mache ich nebenher, macht die IT nebenher.
Zumindest in den Dimensionen wo wir uns bewegen. Wenn es jetzt irgendwo ein kleines
SAP System ist, dann wird die Welt vielleicht anders schauen. Ja, dann die Ressourcen in
dem Zeitraum freischaufeln. Das heißt, ganz bewusst. Wir haben sehr viel Testaufwand und
wir brauchen auch die Leute dazu, wir brauchen sie innerhalb der IT, das heißt auch andere,
im Projektumfeld andere Projekte müssen so getimet sein, dass ich da in dieser Zeit keine
Produktivgänge habe, was sowieso nicht geht, aber auch, dass ich die Ressourcen zur
Verfügung habe. Das heißt, es ist bei uns wichtig, es muss von langer Hand geplant sein.
Muss von der Geschäftsleitung abgesegnet sein. Mindestens ein halbes Jahr vorher,
informiere ich alle, dass wir einen Patch machen, dass sich alle Projekte rundherum auch
danach richten können. Auch ganz wichtig.
26 Interviewer: Wie schaut es mit externem Consulting aus bei Ihnen?
27 Interviewter G: Ja, wir haben für den SPAU, also für den Objektabgleich haben wir an sich
immer Ressourcen vorgesehen die uns unterstützen, also vor allem im HR haben wir das.
Ansonsten haben wir, muss man eigentlich mit Risikobudgets arbeiten, weil ich nie weiß im
Vorfeld, was bei den Tests passiert. Also der wesentliche Beratungsaufwand, den wir haben
ist Fehlerbeseitigung. Teilweise auch Fehler im Standard, kommt auch vor. Oder, dass sich

151
 irgendwelche Entwicklungen aus der Vergangenheit mit dem Releasestand nicht mehr so
funktionieren. Das gibt es fast immer. Meistens nur bei irgendwelchen Kleinigkeiten, selten
auch gröbere Geschichte. Also, das ist sehr schwer kalkulierbar. Ich kann nicht sagen bei
einem Patch, wir haben bei dem letzten Patch zum Beispiel kalkuliert, insgesamt 14 Tage
externe Dienstleistung. Es war deutliche weniger, weil es einfach so rund gelaufen ist. Weil
man kann sich auch da im Vorfeld ein bisschen, wenn andere auf dem Releasestand sind,
kann man andere Betreiber, wie gesagt, wir sind gut vernetzt, mal fragen, wie ist es euch
dabei gegangen. War es eher leicht oder eher schwierig? Da habe ich im Vorfeld nur Gutes
gehört jetzt von dem Releasestand, und, wir sind deutlich drunter geblieben. Aber wie
gesagt, ich habe da eher einen Posten Risikobudget, weil ich es vorher einfach nicht weiß.
Es kann irgendein, man kann sich irgendetwas eindrehen, wo man dann eine Woche
Entwicklung dran hat, das zu korrigieren oder auch nicht, weiß man im Vorfeld nicht.
28 Interviewer:Das heißt es kann sein, dass externe Dienstleistung ein Erfolgsfaktor ist, wenn
irgendetwas schiefgeht?
29 Interviewter G: Also ich muss mir die Ressourcen sichern, das heißt wir haben
Bereitschaften, externe, das heißt ich muss alle Partner informieren, ja, und in den kritischen
Bereich muss ich mir die Ressourcen auch sichern. Also, wir haben das sowohl bei der SAP
selbst, wir sind Max Attention Kunde, das ist im Prinzip so ein erweiterter Service Level,
und wir haben vor allem beim Produktivgang immer SAP in Bereitschaft, also nicht nur, wie
haben sowieso als Kunde 7 mal 24, aber da haben wir wirklich auch einen
Bereitschaftsarbeitenden der unser System kennt und der wirklich Gewehr bei Fuß steht.
Das haben wir auch klinischen System, einfach zur Risikominimierung. Da haben wir
Bereitschaften für den eigentlichen Produktivgang oder wenn wir am Sonntag am Vormittag
dann am Produktivsystem dann draufkommen, dass wir irgendetwas übersehen haben, war
noch nie der Fall, haben wir noch nie gebraucht, aber trotzdem muss man das haben.
30 Interviewer: Fällt Ihnen sonst noch etwas ein?
31 Interviewter G: Erfolgsfaktoren? Mhhmm, momentan nicht.
32 Interviewer: Können Sie die genannten Punkte vielleicht noch anhand der Wichtigkeit
priorisieren?
33 Interviewter G: Das ist schwierig, weil es kein entweder oder ist, ich muss einfach alles
berücksichtigen. Ich meine es ist jetzt auch, wir haben sehr vieles internes Know-How, das
schaut natürlich bei einem anderen ganz anders aus. Wenn der das nicht hat, wir haben in
der Basis Experten, wir haben es in allen Modulen, also das ist eigentlich schon Routine.
Also wenn Sie da jetzt irgendjemanden am Gang ansprechen und sagen Patch, dann wird der
wissen von was Sie reden und was das für ihn bedeutet. Das ist bei, das ist in unserer
Skalierung einfach möglich, weil wir eine IT mit 80 Leuten sind, SAP Landschaft mit 6000
Usern, das ist jetzt in anderen Unternehmen, wo 2 Leute eigentlich nur mehr oder weniger
am Laufen halten und die ansonsten mit externer Beratung arbeiten, wird das ganz anders
ausschauen. Also das ist jetzt wirklich sehr speziell für uns. Nein, also ich kann nur sagen,
für uns wirklich ganz kritisch, warum die Projekte bei uns so gut laufen ist sicher, dass sie
als Projekte abgewickelt werden, dass wir aus Fehlern der Vergangenheit lernen, dass wir
die Leute, die Ressourcen, die ganze Aufmerksamkeit für den Patch haben, dass die auch
freigespielt werden, dass die nicht 5 andere Projekte nebenherlaufen haben und dass die
Organisation gut vorbereit ist darauf. Also, dass auch alle Anwender wissen, was das für sie
bedeutet. Wir haben ein Ausfallsystem, das ist auch ganz wichtig, weil sonst hätten wir auf
ganz wichtige medizinische Informationen keinen Zugang. Befund, alles läuft bei uns über
das SAP, die ganze Krankengeschichte. Ohne SAP sind die blind, also das geht nicht. Das
heißt Einschausystem ist natürlich auch, wenn ich in einem kritischen Bereich bin zwingend
notwendig, da kann ich nicht einfach das Licht abdrehen und sagen, so das war es, jetzt
patchen wir.
34 Interviewer: Sind bei einem von Ihren Projekten schon einmal gröbere Probleme aufgetreten
und wenn ja, wie hat man diese gelöst?
35 Interviewter G: Nein, muss ich ehrlich sagen, nein, wenn dann alle im Vorfeld, also gröbere

152
 Probleme. Also, dass in der Testphase Fehler auftreten ist normal, darum habe ich die
Testphase. Problem ist für mich wenn wirklich, wenn ich irgendwie vom Projektplan
abweiche, wenn es vor allem, ab dem Produktivgang, oder aber der Freigabe vom QS-
System darf eigentlich nichts mehr passieren und da muss ich wirklich sagen, da ist uns bei
einem Patch noch nie wirklich was passiert, gröber, da ist beim, bei der Unicode ist auch gut
gelaufen, Virtualisierung da haben wir mit Host-Namen ein Problem gehabt, die irgendwie,
die unser durchgerutscht sind, die irgendwie hard-codiert waren und wir so irgendwie nicht
auf die neuen Host-Namen zugreifen konnten. Ansonsten, nein, also glücklicherweise, ich
klopfe auf Holz, immer gut gegangen.
36 Interviewer: Eine Frage würde ich noch kurz zum Erfolg kurz anhängen und zwar, anhand
von welchen Merkmalen würden Sie so ein Projekt als erfolgreich definieren?
37 Interviewter G: Zielerreichung in erster Linie, soweit es quantifizierbar ist, ist ganz klar,
Vergleich System vorher nachher, vor allem Performance. Funktionalität, Umstellung
selber, Down-Time, also, das ist für mich eigentlich das wichtigste. Und in der Regel, ist
man, ist das auch immer sehr gut gelungen, also performance-mäßig haben wir, bis auf ganz
wenige Sachen, die dann recht schnell behoben sind, keine Probleme. Was wir vielleicht
auch noch haben, ist ein, was ich vielleicht auch empfehlen könnte, Beweissystem nennen
wir es. Das machen wir im Prinzip bei allen größeren Releasewechsel, dass wir ein System
zur Verfügung halten, auf dem alten Releasestand, weil Anwender, damit ich jederzeit den
Vergleich habe Altsystem-Neusystem. Teilweise gibt es, ich habe dann immer die Situation,
ich habe jetzt dann das gepatchte System, irgendwas verhält sich anders laut Anwender und
ich komme jetzt an den Punkt, man weiß das nicht, ich meine, kein Mensch kennt das ganze
System und jedes Verhalten. Und damit können wir jederzeit die gleiche Situation schaffen
unter alten Voraussetzungen und sagen, stimmt das auch. Weil teilweise habe ich durchaus,
muss ich ehrlich sagen, den Anwender, jetzt hat sich was geändert und auf einmal fällt ihnen
was auf, was eigentlich immer schon so war. Das gibt es jedes Mal. Und damit ist das dann
schnell aufgeklärt. Aber es gibt natürlich mitunter auch Fälle, wo es sich tatsächlich
geändert hat, das gibt es auch. Oft sind es auch Menüpunkte die umbenannt sind. SAP hat ja
da eine gewisse Tradition, Dinge irgendwie seltsame Namen für Dinge zu haben,
Bildschirmabgriff und so Dinge und den Hinweis, Korrekturhinweis zu nennen und so auch
in den Menüpunkten ändert sich dann mit unter öfter was, eine Bezeichnung usw. Und dann
kann ich schauen, wie war das früher, muss ich schauen. Also das ist auch ganz praktisch.
Das lassen wir dann in der Regel so ein paar Monate, das alte System und dann löschen wir
es. Also das dient wirklich nur dem Vergleich.
38 Interviewer: Beim letzten Teil geht es noch um die Unterschiede hinsichtlich
Erfolgsfaktoren zwischen klassischen Implementierungsprojekten, also
Neuimplementierungen und Upgrade-Projekten. Sehen Sie da gröbere Unterschiede?
39 Interviewter G: Nun ja, ich sage einmal ein Patch betrifft potential alle, im Idealfall beim
Patch ändert sich nichts, beim Implementierungsprojekt, das ist der schlimmste Fall.
Ahhmm, Ahmmm
40 Interviewer: Machen wir es anders. Ich habe schon recherchiert, welche Erfolgsfaktoren in
der Literatur für Implementierungsprojekte genannt werden. Bitte beurteilen Sie die
Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der Skala (sehr wichtig,
wichtig, weniger wichtig, gar nicht wichtig).
41 Interviewter G:OK
42 Interviewer: Top Management Unterstützung
43 Interviewter G: Hängt jetzt von der Tragweite der Implementierung ab. Ich sage jetzt mal,
wenn eine Implementierung bei uns ein Ausmaß hat, wir haben so eine
Projektklassifizierung wo aus verschiedensten Kriterien, da gibt es ein Bewertungssystem,
wo ich so ein, ich nenne es mal Allgemein, ein Vorhaben im Prinzip hernehme und das
bewerte, beispielsweise, betrifft es alle Häuser oder nur ein Haus, das ist einmal quantitativ
ein großer Unterschied. Dann, was ist die Durchlaufzeit, was sind externe Kosten, und
undund. Da gibt es eine Reihe von Kriterien und da kann ich eigentlich jedes Vorhaben

153
 relativ einfach in wenigen Minuten bewerten und dann fällt mir unten raus, ist das jetzt ein,
einfach nur eine Erweiterung, ist das ein Kleinprojekt, ist das ein Großprojekt,
Projektprogramm, was immer sich auch, daraus ergibt. Und daran ist auch geknüpft, wie
wird es berichtet. In welchen Gremien wird darüber berichtet, also, und das entspricht dann
natürlich auch der Tragweite des Projektes. Also damit ist eigentlich die Geschäftsleitung
bei Projekten, die für sie relevant sind eigentlich immer an Bord. Und da ist es auch extrem
wichtig. Für irgendeine kleine Erweiterung, das wird ihnen relativ wurscht sein und das wird
nur den betreffenden Haus-Geschäftsührer interessieren. Also, aber grundsätzlich, dort wo
es notwendig ist, ist es ganz wichtig. Also bei einem Patch-Projekt ganz genau so, der aller
erste Schritt ist immer, dass ich die Geschäftsleitung informiere und sage, und das mache ich
wirklich ein halbes Jahr im Voraus, und sage, dann werden wir patchen, das ist der
Zeitraum, die wesentlichen Meilensteine, die sie interessieren, vor allem auch
Transportstopp. Welche Projekte in irgendeiner Form betroffen sein könnten. Das heißt,
welche Produktivgänge unbedingt vorher passieren müssen, weil ich sie sonst nicht machen
kann. Indem Sinn, ist das sicher sehr wichtig.
44 Interviewer: Change Management
45 Interviewter G: Ja, also da bin ich SAP-seitig eh vom System her schon relativ gut
unterstützt. Also, weil im Prinzip, jetzt bei Implementierungsprojekten. Ich habe die
Transportschiene mit all der Dokumentation und ist da habe ich vom System schon
Unterstützung. Ansonsten selbstverständlich, es muss jede Implementierung oder Änderung
dokumentiert sein. Bei gröberen Geschichten muss ich mir auch Gedanken machen, was ist
der Weg zurück als Notfallszenario. Also muss es auf jeden Fall geben.
46 Interviewer: Business Plan & Vision
47 Interviewter G: Das ist jetzt eine bisschen eine abstraktere Ebene. Also spielt bei uns eine
nicht so wichtige Rolle. Die Implementierung ist ja jetzt schon ein Baustein der Umsetzung
der Vision, dorthin, also, das sind für mich zwei völlig verschiedene Ebenen, das eine ist wo
will ich in 5 Jahren sein, wo will ich in 10 Jahren sein und das andere ist was implementiere
ich jetzt konkret. Also würde ich da eher weniger nehmen.
48 Interviewer: Projektmanagement
49 Interviewter G: Ja sehr wichtig, bin ich ein absoluter Fan davon. Vor allem dieses, wirklich
standardisieren, aus Fehlern lernen. Also, jeder Patch wird bei uns besser, das ist, wenn man
zurückblickt. Und mittlerweile habe ich auch keinerlei Bauchschmerzen mehr.
50 Interviewer: Customization. Also ich verstehe darunter, dass bei einem hohen Grad an
Customization, die Wahrscheinlichkeit steigt, dass bei einem Upgrade Probleme auftreten.
Kann man das so unterschreiben?
51 Interviewter G: Also ich sage einmal, das Schöne an SAP ist ja, dass es weitestgehend
offener Code ist, dass ich als Kunde meinen Namensraum habe, wo ich selber entwickeln
kann. Das ich entsprechende User Exits habe, also SAP lädt ja so richtig dazu ein,
Customizing bzw. auch Eigenentwicklung zu machen. Das ist für mich so ein bisschen die
Grenze, Customizing ist ja eigentlich, das sind ja eigentlich vorgesehene Individualisierung,
dass was SAP schon bietet. Wo ich sage, und da kann der Kunde dann individuell wählen
wie er das haben möchte. Entwicklung ist wirklich Code-Manipulation. Bis hin im
extremsten Fall von Abweichungen vom Standard. Also, da muss man auch noch einmal
unterscheiden. Da wird es dann schon heikel, davon würde ich eher abraten. Standard-
Manipulation sind immer potentielle Bomben die ich mir in das System lege, die
irgendwann hochgehen können, wenn ich vielleicht gar nicht mehr daran denke und gar
nicht mehr weiß, dass es das gibt. Aber ansonsten, ist ja gerade SAP, da muss man auch,
nicht vergleichbar mit anderen Systemen, ja wirklich, gerade dafür konstruiert und von der
Architektur her gebaut, dass ich selber tue. Darum ist ja auch, unter Anderem, so weit
verbreitet und so erfolgreich.
52 Interviewer: ERP Teamzusammensetzung
53 Interviewter G: Extrem wichtig, aber auch da muss ich sagen, wenn ich zurückblicke über
die letzten Jahre, wir haben zum Glück auch eine sehr geringe Fluktuation, sind die Teams,

154
 das Projektteam sind immer 7 bis 8 Leute, das Kernteam. Da verteilt, ich brauche im Prinzip
jedes Modul vertreten und natürlich Basis, Infrastruktur. Das ist auch sehr eingespielt. Sehr
wichtig.
54 Interviewer: User Training & Schulung
55 Interviewter G: Beim Patch überhaupt nicht, es sein den der Patch bringt, was er in der
Regel nicht tut, weil ich viele Neuigkeiten per Switch, ein- und ausschalten kann, bringt
zwangsläufig Änderungen mit sich. Also wenn ich jetzt zum Beispiel patche, unter
Anführungszeichen, SAP-GUI, das ist jetzt kein Patch in dem Sinne, kein Systempatch, aber
es ändert sich mit unter das Frontend. Dann muss ich natürlich schulen. Oder wir überlegen
jetzt, wir haben aktuell SAP-GUI 7.40 im Einsatz und werden NetViewer Business Client
einsetzen künftig, zumindest partiell, also im Prinzip Browserbasiert und das bringt einfach
Änderungen mit sich, wo man die User informieren muss. Auch da gibt es zwei
Möglichkeiten, ist es überschaubar, dann kann ich das mit Handouts machen, betrifft es nur
einen Teilbereich, dann kann ich es gezielt vielleicht über Key-User machen oder ist es
wirklich die gesamte Fläche und es ist mit Handouts nicht machbar, dann muss ich schulen,
dann bleibt mir nichts Anderes über.
56 Interviewer: Software-Testing
57 Interviewter G:sehr wichtig, da haben wir eh vorher schon viel darüber gesprochen
58 Interviewer: Business Case
59 Interviewter G: Sehe ich jetzt nicht so als wichtig an bzw. machen wir nicht, weil der Patch
oft einfach notwendig ist
60 Interviewer: Projekt Champion
61 Interviewter G: ahhmm, nicht so wichtig
62 Interviewer: Kommunikationsplan
63 Interviewter G: Kommunikation ist auf jeden Fall wichtig. Das ist auch Teil des ERP
Teams, die müssen einfach gut zusammenpassen und somit auch gut miteinander
kommunizieren.
64 Interviewer: Management von Legacy System
65 Interviewter G: Eher nicht, eigentlich am Datenmodell selbst, ist kein Thema. Habe ich eh
kurz gestreift, Schnittstellen sind in der Regel bei Patch-Projekten kein Problem.
66 Interviewer: Hersteller Unterstützung
67 Interviewter G: Ja, wir haben von SAP, einerseits Max Attention, das ist einfach ein erhöhter
Service Level, sowieso schon einmal ein bisschen höhere Aufmerksamkeit. Ist bei einem
Patch wichtig, Bereitschaft. Das sie im Falle des Falles da sind, ansonsten haben wir es
eigentlich nicht gebraucht.
68 Interviewer: Post-Implementierungs-Evaluierung
69 Interviewter G: Wir haben normalerweise nach einem Patch eine Woche, das ist jetzt auch
noch im Projektplan abgedeckt, zumindest eine Woche Systembeobachtung, teilweise
werden gezielte Tests gefahren im Vorher, Nachher-Vergleich, wo wir wissen wie sich das
verhält, welche Durchlaufzeiten, und welche Reaktionszeiten man da hat. Und, ja dann
kommen immer erste Meldungen von Usern, weil die natürlich auch sensibilisiert sind, die
wissen, da ist jetzt was gemacht worden. Dann fallen teilweise Sachen auf, die immer schon
so waren, teilweise auch wo sie was verändert hat. Also normalerweise würde ich da ein bis
zwei Wochen rechnen, Nachphase, bevor man von Projektseite den Projektabschluss macht.
70 Interviewer: Perfekt, somit sind wir am Ende. Danke für das Interview
71 Interviewter G: Gerne

155
 C.8 Transcript Interview H
1 Interviewer:Könnten Sie bitte einen kurzen Überblick über Ihre Person, Ihren
Aufgabenbereich und Ihr
2 Unternehmen geben?
3 Interviewter H: OK, Grundsätzlich bin ich die IT-Leiterin von XYZ und wir betreuen 9
Unternehmen, 540 User und wir IT Full Service Provider, wir haben sowohl von der
Infrastruktur, über die Projekte bis hin zu Strategie, also wir betreuen alles und unser ERP
System ist Navision, das stellen wir zentral für die 9 Unternehmen zur Verfügung, managen
auch alles Updates haben jetzt gerade eines hinter uns gebracht, betreuen auch, im Prinzip,
wir machen nicht direkt den Helpdesk für das ERP System sondern wir koordinieren den
Helpdesk, das heißt Anfragen laufen bei uns zentral auf einem Sharepoint-Portal zusammen,
wir schauen dann, entweder geben wir das an einen externen Dienstleister weiter und der
beantwortet dies dann oder es ist vielleicht ein Fall aus dem ein Projekt wird, weil mehrere
Unternehmen betroffen sind, mit der Weiterentwicklung, dann koordinieren und starten wir
das Projekt und machen die Weiterentwicklung. Also, die Idee ist, dass eben nicht jeder
individuell von den 9 Unternehmen beim Dienstleister einmeldet sondern, dass dies zentral
zusammenläuft und wir halt drüber schauen und gegebenenfalls weitergeben oder in eine
andere Richtung lenken, also, ja, Upgrade Projekt, sind wir gerade im November live
gegangen mit dem Navision 2016, da haben wir einen relativ großen Sprung gemacht, weil
wir vorher das 2011er gehabt haben und das war relativ großer Sprung.
4 Interviewer: In welchem Umfang hat sich das Projekt ca. abgespielt, wie lange hat es
gedauert?
5 Interviewter H: Ja, es war, also wir sind in einer Landesholding, das heißt wir haben es
ausschreiben müssen europaweit, weil es war 100.000 Euro vom finanziellen Betrag, somit
müssen wir immer ausschreiben. Das heißt, wir haben zuerst spezifiziert und dann
ausgeschrieben, international, dann haben wir die Angebote reinbekommen, dann haben wir
Anbieter-Hearing gemacht, Anbieter Auswahl gemacht, alleine der Prozess hat alleine
glaube ich bis Mai/Juni gedauert, und dann sind wir direkt ins Upgrade Projekt gegangen
und im November sind wir online gegangen.
6 Interviewer: Was waren die Hauptgründe, warum das Upgrade durchgeführt wurde?
7 Interviewter H: Gute Frage, Navision ist ja ein Microsoft System, man muss sowieso immer
wieder regelmäßig die Upgrades machen, grundsätzlich, wir haben manche Funktionen
benötigt, das heißt wir haben bestimmte Dinge, im Bereich Dokumentenmanagement, hat
sich da viel getan, und da war die Idee, dass wir, wir haben bis jetzt ein extra
Dokumentenmanagementsystem gehabt, dass wir das dann ablösen können, also mit dem
alten System haben wir einige Probleme gehabt, dass wir das ablösen können, wenn wir
eben das Dokumentenmanagement im Navision machen, das war eine der Hauptgründe.
Und der zweite Grund war, dass wir viele Schnittstellen schon schwierige bedienen haben
können, also weil das System ist sehr integriert, wir haben vom CRM Schnittstellen rein, wir
haben vom Sharepoint Schnittstellen rein, wir haben ein Zeiterfassungssystem was drauf
hängt usw. Und das ist halt mit der Zeit immer schwieriger geworden, je älter das System
geworden ist. Und irgendwann muss man es sowieso machen.
8 Interviewer: Was waren die Hauptziele die für dieses Projekt definiert wurden für dieses
Projekt?
9 Interviewter H: Also die Hauptziele, also das Hauptziel war ganz pragmatisch, das Upgrade
zu machen, ohne dass der Arbeiter Finanz und die anderen Mitarbeiter, wir haben
Bestellungen drinnen, wir haben die Webpreise drinnen, wir haben die Zeiterfassung
drinnen, dass die möglichst wenig gestört ist. Also möglichst, ohne Unterbrechungen, ist
natürlich Grundvoraussetzung, ohne Datenverlust, aber dass das auch ohne Unterbrechung
weiterläuft. Das war einmal das Hauptziel und die Nebenziele waren die eben zusätzlichen
Funktionalitäten, die ich zuerst erwähnt habe.
10 Interviewer: Wie lange war Ihr System beim Upgrade down?
11 Interviewter H: Ein Wochenende, Freitag Mittag wurde es ausgeschaltet und am Montag
sind wir wieder online gegangen.

156
12 Interviewer: Somit sind wir schon beim Hauptthema, welche Faktoren glauben Sie sind die
kritischten Faktoren, damit so ein Projekt erfolgreich durchgeführt werden kann?
13 Interviewter H: Also meiner Meinung nach sind das in einem ERP System keine anderen als
in einem CRM System, oder wie, natürlich hat ein kleines Projekt andere Erfolgsfaktoren
wie ein großes, aber ob jetzt ein CRM System von einem neuen Unternehmen verwendet
wird und 450 User drauf hat und man gradet das up, oder ein ERP System, das ist wurscht,
das ist ziemlich egal, also die Erfolgsfaktoren sind für alle gleich. Der große Erfolgsfaktor
ist meiner Meinung nach in der Anfangsphase, wie bei jedem Projekt, das heißt je genauer
ich zu Beginn spezifiziere, was brauche ich wirklich, was muss sein, was darf sein, also was
sind Pflichtfaktoren, was ist Nice-to-have, das ist auch nicht schlecht, wenn man sich Nice-
to-have's am Anfang vornimmt, weil wenn man dann im Laufe des Weges drauf kommt, das
ist noch da, dann nimmt man es mit, aber in der Anfangsphase, gerade in der
Spezifikationphase, wenn ich das gut mache und da genau definiere, was ich haben will und
auch die User, also die beteiligten Abteilungen sehr stark einbinde in das Upgrade Projekt,
dann läuft nachher eigentlich alles relativ reibungslos, weil wenn ich mich am Anfang gleich
mal in das Projekt reinstürze und starte, dann kommen, dann während dem Projekt soviele
Fragen und es sind soviele Möglichkeiten in eine falsche Richtung abzubiegen wo man dann
wieder zurückbiegen muss, dass die Zeit die man am Anfang investiert, sich hundert mal
auszahlt. Aber das ist meiner Meinung nach, bei jedem IT-Projekt, das ist zwar voll fad am
Anfang, sich da hinsetzen und das genau zu spezifizieren, mit allen Leuten reden, und was
darf sein und was darf nicht sein, und was benötigt ihr und was benötigt ihr nicht und im
Sinne von, dass das Upgrade dann auch wirklich die Funktionen implementiert bekommt die
neu möglich sind, dass man das Upgrade gleich benutzt alten Code rauszuhauen, den man
nimmer braucht, alte Funktionen rauszuhauen, die man nimmer braucht, also für mich ist ein
Upgrade Projekt auch immer gleich ein Systembereinigungsprojekt. Nicht nur einfach nur
auf die neue Version zu heben, man muss sowieso den Code immer angreifen, man muss eh
reingreifen, also ist das auch immer eine Gelegenheitzu schauen, welchen Code greifen wir
an, welchen greifen wir nicht an und was braucht ihr stattdessen. Und je genauer man das
spezifiziert, desto erfolgreicher wird es abgeschlossen, aber das ist bei jeden Projekt und das
ist auch immer das fade, wo man die meisten Projektmanager zwingen muss dazu aber im
Endeffekt zahlt es sich aus, die Zeit die man da investiert. Das ist für der wesentliche
Erfolgsfaktor, in der Anfangsphase genau spezifizieren. Dann im Endeffekt, führen wir das
nicht selbst durch, das heißt die Dienstleisterauswahl ist auch sehr elementar, wenn ich den
falschen Dienstleister habe, ich bin nur so gut, wie der Dienstleister das macht, das heißt den
kann ich dann nur begleiten, aber wenn der das nicht schafft oder wenn der zeitlich nicht
zusammenkommt, dann kann ich auch nix machen, aber das ist auch relativ in der
Anfangsphase, das ich spezifizier, dass ich den Dienstleister auswähle und ja ein
Erfolgsfaktor ist sicher auch, dass man die User mit an Bord hat, das heißt, dass ich die
schon in die Spezifikation mit einbeziehe, dann wieder, wenn der erste Prototyp da ist, dass
man den vorstellt, dass man sie zum Testen bringt, weil nur so kann ich mit einem halbwegs
stabilen System online gehen, weil erstens wenn ich Wiederstand habe, dann habe ich
sowieso verloren, und jede unfreiwillige Änderung erzeugt Widerstand, das ist leider auch
so, ja wenn man sagt, wir graden up, dann sagen gleich mal alle, Oh mein Gott, weil jetzt
haben wir das alte System im Griff, das kann nur schlechter werden, ich kenn mich mal
kurzfristig nicht aus, das heißt man muss, da sehr viele Ängste nehmen, gleich in der
Anfangsphase, man muss sie miteinbeziehen, man muss sie beim Testen schon sehr gut
einschulen, damit sie das Gefühl haben, OK, ich kenne mich aus, ich schaffe das, es wird
schon nicht so schlimm werden, und nur sie können es testen, weil wir verwenden es ja im
Alltag nicht, also wir können uns einmal durchklicken, aber mehr können wir nicht machen,
ja das heißt, sie müssen die Fehler finden.
14 Interviewer: Gibt es da eine Key-User-Gruppe die für sowas verantwortlich ist?
15 Interviewter H: Ja also, wir haben pro Unternehmen einen Haupt-Key-User und wir stellen
auch Testdrehbücher zur Verfügung, dieses Testdrehbuch geben wir pro Unternehmen

157
 jedem Haupt-Key-User und wir der das dann intern verteilt ist uns egal, aber wir die müssen
dann bis zu einem bestimmten Zeitpunkt ausgefüllt werden und dann melden wir eben die
Fehler ein und geben die dann weiter so. Die Key-User-Integration ist sicher was ganz
elementares, Spezifikation, die Dienstleister. Haben wir sonst noch andere kritische
Erfolgsfaktoren? Ja, also bei einem Upgrade Projekt habe ich eh keine Softwareauswahl.
16 Interviewer: Ich habe jetzt einige Interviews mit Menschen aus der SAP-Welt geführt und da
war ein großes Thema immer externes Consulting, ist das im Microsoft-Bereich auch
relevant?
17 Interviewter H: Das ist dann eher der Dienstleister, der setzt auch gleichzeitig um, das ist
der, der umsetzt und natürlich, bestimmte Dinge sind Voraussetzung, dass die Datenbasis
bleibt, aber das ist eigentlich nicht mehr erwähnenswert, bei einem ERP-Upgrade, weil das
ist eh schon sichergestellt alles. Also diese Revisionssicherheit, etc., aber da kann eigentlich
eh nichts mehr schiefgehen. Also, es kann immer alles schiefgehen, aber das ist halt
Voraussetzung. Fällt mir sonst noch was ein? Nein, jetzt nicht!
18 Interviewer: Sind bei dem Projekt irgendwelche gröberen Probleme aufgetreten, bzw. wenn
ja, wie hat man die gelöst?
19 Interviewter H: Ja, also Probleme treten immer auf, aber gröber, ja, klassisches Problem ist
sowieso immer, das gewisse Dinge nicht wie spezifiziert möglich sind umzusetzen, nicht
funktionieren, komplizierter sind als gedacht, nicht in der Zeit, also der Klassiker ist dann
immer, dass man sagt, dass irgendwann mal der Punkt kommt, wo man dann entscheiden
muss, das nimmt man jetzt raus aus dem Upgrade Projekt und geht einmal Live ohne diesen
Punkten und das wird im Nachgang gemacht, also diese ständige Entscheidungsfindung,
quasi, das muss dabei bleiben und das kann ich jetzt mal rausnehmen, also, weil es läuft
natürlich nie alles so wie geplant, also das ist, das ist auf jeden Fall in jedem Projekt und
auch in diesem Projekt wieder. Was war die Frage? Was schiefgelaufen ist? Ja, also da
haben wir ein paar Funktionen gehabt gerade von den Neuen, die dann doch nicht so
funktioniert haben, wie geplant, weil einfach unsere internen Systeme, die haben dann
Probleme gemacht, also, unter einer anderen Umgebung wäre das problemlos gegangen,
aber mit unserer Umgebung hat sich dann rausgestellt, dass das nicht so funktioniert wie
geplant und dann ist halt die Entscheidung, rausnehmen oder Zeitplan nach hinten
verschieben und dranbleiben, also das sind immer so die Lösungsmöglichkeiten. Ja, das
muss man dann immer abwägen, was wichtiger ist, im Zeitplan bleiben oder die Funktion
mit dabeihaben, das kommt dann immer auf die Funktion drauf an. Aber, da hat es sicher
vier oder fünf kritische Momente gegeben, wo man gesagt hat, wie geht man jetzt weiter
vor, so funktioniert es definitiv nicht, wie geplant und was machen wir jetzt?Die kritischen
Momente sind immer die, wo man den Key-Usern das zum Testen gibt, weil da ist dann bei
fast jedem Projekt einmal die Verzweiflung groß, also, das find ich nimmer, und das geht
nicht mehr, das sind dann Sachen die einem trotzdem immer wieder überraschen, obwohl
man selber so gut durchgetestet hat, dass man sie dann wirklich an der Hand nimmt, sich die
Zeit nimmt für die Key User, obwohl das oft gar nichts mit der IT zu tun hat, aber im
Endeffekt die Nerven ein bisschen beruhigt und weil dann schreien immer die Key User, wir
können nicht live gehen mit dem System, das sind aber oft nur Kleinigkeiten, wo man dann
sagt, das können wir ganz leicht lösen. Das sind immer kritische Momente, weil wenn man
da den Widerstand hat, dann braucht man gar nicht live gehen, weil dann ist die ganze Zeit
die man vorher investiert hat in der langen Phase davor, wann das System voll gut ist und
die Key-User sagen es ist schlecht, dann kann das Projekt kein Erfolg werden. Das ist immer
gewesen und war dieses mal natürlich auch wieder, dass die Key User, dass die Nerven
blank gelegen sind zwei Wochen vor dem Go-Live und ja, gesagt haben sie wollen nicht.
Das waren eh die beiden kritischen Dinge die schiefgelaufen sind, die aber meistens eh
schon erwartbar sind und einem trotzdem immer wieder überraschen. Ich habe schon extrem
viel Projekte begleitet und das ist immer wieder irgendwie in die Richtung. Was ist
spezifische beim ERP-Projekt gewesen? Ja, beim Dienstleister, da haben wir einen
Ansprechpartnerwechsel gehabt, das war auch ein bisschen kritisch, der Eine ist

158
 weggegangen während dem Projekt, quasi unser Hauptverantwortlicher, und der neue ist
gekommen und da haben wir Gott sei Dank sehr viel Wissen da gehabt, das halt wir dann
weiter geben konnten, weil wenn das jetzt die Finanzabteilung ohne IT gemacht hätte, dann
wär das wirklich ein Problem geworden, aber so haben wir halt dann, also mein
Projektmanager arbeitet ja schon jahrelange mit dem System, und der hat den dann sehr
gecoacht den Neuen. Und so ist dann alles weitergelaufen, aber ja das war sicher auch ein
kritischer Moment, wo einiges schiefgelaufen ist, weil der eben weggegangen ist vom
externen Dienstleister. Aber sonst ist alles ganz gut gelaufen. Also dann im
Umstellungswochenende, ja, hat sich dann noch herausgestellt, da haben wir dann
kurzfristig entscheiden müssen, dass die Berechtigungen vom alten System, also das
Berechtigungssystem hat sich geändert, und dass wir uns da was überlegen müssen und wir
haben noch ordentlich prüfen müssen, dass die User wirklich nur das sehen, was sie sehen
sollen und das ist vielleicht spezifisch vom ERP-System, dass das eben extrem wichtig ist,
diese ganzen Sicherheitsrollen und Berechtigungen, weil es halt mehr Relevanz hat, als in
anderen Systemen, weil einfach bestimmte Zahlen, bestimmte Daten nicht rausgehen dürfen.
Und da hat uns Microsoft noch einen kleinen Strich durch die Rechnung gemacht, also unser
altes Berechtigungskonzept hat nicht mehr so funktioniert, da haben wir dann am Sonntag
noch etwas gebastelt. Das war vielleicht noch kritisch, aber das war dann auch
glücklicherweise so, dass der externe Dienstleister da relativ genau gesagt hat, das müssen
wir machen und das haben wir dann eben manuell nachgezogen, das war halt noch viel
Arbeit, aber im Endeffekt hat dann alles funktioniert. Kritisch ist sicher, wie bei jedem
Projekt, dass jemand da ist, der die Entscheidungen schnell trifft, richtig trifft, ich mein
richtig, ja, oft gibt es eh kein richtig und kein falsch, aber dass die Entscheidungen
zumindest getroffen sind und das Ganze dann schnell korrigiert werden kann, damit man
vorwärts kommt und nicht zurückrudert. Es braucht halt oft Entscheidungsträger, dass die
zur Verfügung stehen zum richtigen Zeitpunkt.
20 Interviewer: Anhand von welchen Merkmalen würden Sie so ein Projekt als erfolgreich
definieren? Ist das ein klassisches Zeit, Kosten, Funktionalität, Projektmanagementdreieck?
21 Interviewter H: Ja, würde ich jetzt keinen Unterschied sehen, obwohl, Zeit ist vielleicht bei
einem Upgrade-Projekt nicht ganz so kritisch, wie bei anderen Projekten, wenn ich eine
Neueinführung mache. Bei einer Neueinführung habe ich vorher nichts und dann wird etwas
benötigt, hingegen bei einem Upgrade Projekt, wenn das alte System zwei Monate länger
läuft, ist wahrscheinlich der Schaden für das Unternehmen, hält sich sehr in Grenzen, glaub
ich. Wenn ich eine Neu-Systemeinführung mache und das System steht zwei Monate später
zur Verfügung ist das Potential sicher größer. Also, die Zeit ist vielleicht weniger kritisch
wie in anderen Projekten, aber natürlich Kosten, klar und Funktionalitäten ist auch klar.
22 Interviewer: Wo glauben Sie, dass die größten Unterschiede zwischen Erfolgsfaktoren bei
Implementierungsprojekten und denen bei Upgrade-Projekten liegen?
23 Ja, beim Implementierungsprojekt, also wenn ich jetzt wirklich von der grünen Wiese weg
implementiert, ist die Spezifikationsphase wahrscheinlich noch einmal elementarer, weil ich
noch einmal genauer spezifizieren muss, während ich bei einem Upgrade Projekt ja doch auf
vorhandene Funktionen referenzieren kann. Dann kann ich sagen, ja okay, und die Funktion
soll wieder in dieser Weise ausgeführt werden, das und das soll sie beinhalten, weil da
nehme ich ja schon vorhandene Funktionen. Ich muss nicht so genau spezifizieren, weil es
eben schon so etwas gibt, und auf das baue ich auf, während wenn ich auf der grünen Wiese
zu implementieren anfange, dann muss ich ja wirklich alles spezifizieren, dann muss ich die
Infrastruktur spezifizieren, die ich benötige, dann muss ich jede kleine Funktion und die
ganzen Schnittstellen muss ich von Null spezifizieren, also da ist einfach der
Spezifizierungsaufwand unvergleichlich viel größer und sicher auch wesentlich, also sicher
der elementarste Erfolgsfaktor, weil wo soll ich sonst beim Umsetzen anfangen, wann ich
nicht genau weiß, was ich will. Sonst habe ich sonst wieder das mit dem Baum, wo halt die
Schaukel in der Mitte hängt und nicht am Ast. Das ist die einzige Möglichkeit, dass das
richtig implementiert wird. Und ich denk mir auch, von den Zyklen, wie das Projekt dann

159
 durchläuft, wenn ich jetzt zum Beispiel von Prototyping-orientiertem Projektmanagement
ausgehe, dann werde ich da sehr viel mehr Prototypen haben, wenn ich wirklich von der
grünen Wiese entwickle, sodass ich halt immer schaue, OK, ist das jetzt eh noch immer in
einem Bereich, wie ich mir das vorstelle, auch mit den Key-User mehr Schleifen drehen, als
wie bei einem Upgrade-Projekt, da habe ich halt wirklich so, da lass ich einmal ein Modul
entwickeln, dann sage ich, das ist fertig, dann gebe ich das den Key-Usern zur Abnahme,
während bei einem Softwareentwicklungsprojekt habe ich sehr viel mehr Iterationen, sehr
viel mehr Schleifen, weil ich halt mal einen kleinen Teil habe, schaue mal, geht das
überhaupt in die richtige Richtung, passt die Funktion, gebe es einmal den Key-Usern, und
dann geht man erst in den nächsten Schritt und in den nächsten und in den nächsten und in
den nächsten. Wenn ich jetzt davon ausgehe, dass es ein größeres
Softwareentwicklungsprojekt ist, also ich von einer preislichen Größenordnung wie ein
Upgrade Projekt, dann werde ich da viel mehr Iterationen haben. Das ist sicher auch ein
Erfolgsfaktor, weil wenn ich da bei einem Projekt von der grünen Wiese, selbst wenn die
Spezifikation sehr gut ist, wann ich da dann sage, OK, jetzt entwickeln wir den ersten
Prototypen komplett fertig und dann gebe ich ihn erst dem User, wie bei einem Upgrade
Projekt, dann kann ich Glück haben und es ist genau das, was ich brauche, aber ich kann
auch Pech haben und der Entwickler hat irgendwas gemacht und der User sagt, oh Gott, ich
wollte ja ganz was Anderes. Das ist sicher ein Erfolgsfaktor. Das ich da viel mehr
Iterationen habe. Sonst würde ich sage, sind das die gleichen Erfolgsfaktoren.
24 Interviewer: In der Literatur werden folgenden Faktoren für den Erfolg eines
Implementierungsprojektes genannt:
25 Bitte beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der
Skala (sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig)
26 Interviewer: Top Management Unterstützung
27 Interviewter H: ja, halbwegs wichtig, in der Mitte würde ich sagen, wichtig
28 Interviewer: Change Management
29 Interviewter H: ja sehr wichtig, weil da haben wir das Thema mit der Abweisung, also die
unfreiwillige Änderung quasi
30 Interviewer: Business Plan & Vision
31 Interviewter H: nicht so wichtig
32 Interviewer: Projektmanagement
33 Interviewter H: sehr wichtig
34 Interviewer: BPR & Customization
35 Interviewter H: weniger wichtig
36 Interviewer: ERP Team Zusammensetzung
37 Interviewter H: wichtig, sehr wichtig, da haben wir wieder die Key User dabei
38 Interviewer: Software Testing
39 Interviewter H: sehr wichtig
40 Interviewer: User Training & Schulung
41 Interviewter H: sehr wichtig
42 Interviewer: Business Case
43 Interviewter H:wichtig
44 Interviewer: Projektchampion
45 Interviewter H: nicht wichtig
46 Interviewer: Kommunikation
47 Interviewter H: mittel wichtig
48 Interviewer: Management von Legacy Systemen
49 Interviewter H: wenn es da um Schnittstellen usw geht, dann sehr wichtig
50 Interviewer: Hersteller Unterstützung
51 Interviewter H:gibt es keine von Microsoft
52 Interviewer: Post-Implementation Evaluierung & Lessons Learned
53 Interviewter H: ist sehr wichtig

160
161
 C.9 Transcript Interview I
1 Interviewer: Bitte geben Sie einen kurzen Überblick über ihre Person, Ihren
Aufgabenbereich und inwieweit Sie mit dem Thema ERP-Upgrades zu tun haben?
2 Interviewter I: Ich erzähle Ihnen ein bisschen was über mich und vielleicht über meinen
beruflichen Werdegang, ich habe üblicherweise Pflichtschule, Gymnasium dann war ich an
der JKU Universität in Linz und habe Informatik studiert mit Abschluss 88, also 1988,
daraus können Sie jetzt auch mein Alter schließen, aber ist wurscht, war dann bei diversen
anderen Firmen und bin jetzt seit über 20 Jahren hier im Unternehmen. Das sollte über die
Person genügen, privat wird Sie ja vermutlich nicht interessieren. Ich bin hier Mitarbeiter in
der Abteilung Softwaremanagement, wir haben, also leite dort eine Gruppe die sich halt, wir
haben das immer so aufgeteilt nach Softwarepaketen, de facto eigentlich dann auch nach
wer arbeitet mit diesen Softwarepaketen, also ich bin eher im zentralen und
Produktionsbereich, wo ich sage, wir betreuen eigentlich alles von der Produktionsplanung
bishin zum Einkauf, FIBU, sogar Zeiterfassung, ist bei uns eine relativ große Geschichte
und das machen eben meine Leute und ich. Und wir kümmern uns, unter Anderem,
diesbezüglich auch um SAP, über das wir jetzt dann eigentlich über das Upgrade reden
werden. In SAP nutzen wir nur FI-CO und HR, derzeit als Module, die Produktion machen
wir mit etwas ganz anderem, das ist eigentlich ein eigenes ERP System, da könnten wir jetzt
ein bisschen plaudern. In meinem Verantwortungsbereich liegt dort die Betreuung,
Weiterentwicklung, Fehlerbehebung, Schnittstellen wie Sie schon gehört haben, und im
weiteren Sinne auch eine Art Organisationsberatung interner Natur, wie gehe ich mit den
Paketen um, was kann ich den überhaupt machen, was könnte ich mir noch wünschen, also
ich nenne es mal technische interne Organisationsberatung, klingt vielleicht geschwollen,
aber letztendlich trifft es das relativ gut was wir tun oder was ich tue oder auch meine
Kollegen tun und in dem Zuge sind wir auch bei den Upgrades, bei den Systemen, wofür
ich nicht verantwortlich bin ist Hardware, Netzwerk, da gibt es eine eigene Abteilung bei
uns. Sprich, wann wir ein Upgrade machen und dafür einen neuen Server brauchen, ja, dann
weis ich, dass ich einen mache, aber Aufsetzen usw. machen die Kollegen, also wir
kümmern uns rein um die Aspekte der Software selbst, wir gehen davon aus, dass das
Betriebssystem entsprechend aufgesetzt ist, dass die Voraussetzungen was User betrifft, bei
SAP ist da ja immer sehr kritisch, erfüllt sind, ja ich kümmere mich darum, dass es passiert,
aber ich tue es nicht selber. So in etwas würde ich das am besten beschreiben. Genügt das?
3 Interviewer: Ja, absolut.
4 Interviewter I: Zur Firma selber, weiß ich nicht wie gut Sie die XYZ kennen?
5 Interviewer: Grob, also ich weiß ungefähr was Sie machen.
6 Interviewter I: OK, angeblich, in bin mir nicht wirklich sicher, aber laut internen Dings, sind
wir ja der weltführende Schalungsanbieter. Also das ist so eine Streitfrage, aber das müssen
wir ja jetzt auch nicht auf die Goldwaage legen. Wir haben ca. 6300 Mitarbeiter mit Ende
2016, ca. 1 Milliarde Umsatz, sind in 65 Ländern weltweit, das ist auch immer so, das ändert
sich von heute auf morgen und dann machen wir dort wieder eine Niederlassung zu, mit
ungefähr 130 Standorten, davon gibt es derzeit aber nur 3 Produktionsstandort, also hier in
Amstetten, einen in BanskáBystrica, in der Slowakei und wir beginnen gerade in Russland
zu fertigen, das hat aber eher den Hintergrund, dass wir mit den ganzen
Handelsschwierigkeiten die man da mit Russland hat, dort kaum mehr was importieren darf.
Also hat man sich irgendwann dazu entschieden, die wichtigsten Produkte für diesen Markt,
versucht man dort zu produzieren, weil dann geht man all diesen Problemen aus dem Weg
und unter Umständen kann man es dort sogar billiger produzieren als in Amstetten, wobei
ich mir nicht so sicher bin, weil dort der Personaleinsatz einfach höher ist. Aber das müssen
sich andere Leute überlegen, dass alles nicht mein Thema. Alles nicht mein Thema, aber
man bekommt natürlich viel mit, weil es trifft mich dann immer, weil dann müssen wir dort
wieder das System zugänglich machen oder die Systeme, je nachdem. Sollten sie noch
irgendwo Fragen haben, bitten sofort einhaken, überhaupt kein Problem
7 Interviewer: OK, werde ich gerne machen. Vielleicht können wir dann eh schon über die
nächste Frage sprechen, so über das letzte ERP Upgrade Projekt, dass Sie gemacht haben. In

162
 welchem Umfang hat sich das ca. abgespielt und wie lange hat das Projekt gedauert?
8 Interviewter I: OK, Wie gesagt, damit es einen Sinn hat, nachdem ich mich ja um mehrere
ERP's kümmere, reden wir hier von SAP. Das letzte wirkliche Upgrade, wo ich echt sage, da
haben wir einen Version-Upgrade gemacht und gleichzeitig auch die Hardware-Basis
gewechselt, weil wir waren früher immer der Ansicht, dass wir Systeme die eine hohe
Zuverlässigkeit haben müssen unter UNIX laufen lassen, weil die zuverlässiger sind, usw.
Waren dann endlich soweit, dass wir gesagt haben, jetzt können wir Windows auch nehmen
und es ist eigentlich, wir haben Ende 2008 angefangen, also das sind 8 Jahre. Haben wir
damals auf ERP, also ECC 6.0, EHP 7 upgegradet, unser SAP. Die Durchlaufzeit von dem
ersten Zeitpunkt wo ich dabei war, weil die Pläne in den Köpfen der Manager, hat es
wahrscheinlich früher gegeben, bis zur wirklichen Fertigstellung war knapp 9 Monate. Ja,
also Kick-Off Projekt, so richtig, wo man dann einmal das Team definiert hat, was ein
bisschen dauert, wo man dann gesagt hat, welche externe Ressourcen rekrutiert man, weil
bei viel Dingen, da kann man intern das Know-How gar nicht aufbauen, weil das lohnt sich
nicht, weil das brauche ich einmal, das brauche ich einmal und die machen das öfter, die
haben mehr Erfahrung, und undund, also wir haben dann, eine Basisberatung, eine
Applikationsberatung gehabt und wir haben sie immer noch, ja weil das ist ja nicht so, wenn
das Upgrade-Projekt, ich pflege ja längerfristige, auch, Lieferantenbeziehungen, sage ich in
diesem Fall, wenn ich mit jemanden zufrieden bin und einmal ein Großprojekt mit ihm
gemacht habe, dann mache ich die kleinen Sachen auch mit ihm, dadurch halt ich ihn "jour"
was die Konfigurationen betrifft, was die Anforderungen betrifft und wenn ich ihn das
nächste Mal habe, dann muss ich nicht bei Adam und Eva anfangen ihm was zu erklären.
Also den Basisberater, den wir damals neu engagiert haben, kurz vorher, der arbeitet immer
noch mit mir zusammen, die werden mich jetzt dann wahrscheinlich gleich mal anrufen,
aber mein Handy liegt eh drüber. Die Durchlaufzeiten waren wirklich, wir haben dann die
rein technische Durchlaufzeit, sage ich einmal, wo wir wirklich angefangen haben was zu
tun, im Sinne von, Server sind fertig, jetzt muss ich das migrieren und so, waren 3 Monate,
circa. Wie es in SAP üblich ist, hat man ja eine produktive Systemlandschaft, aus mehreren
Systemen und man fängt einmal mit dem Testsystem an und man übt ein bisschen, so
handelt man sich vor bis zum Produktiven, das dann eher immer eine Nacht- und
Nebelaktion wird, damit man die Anbieter so kurz wie möglich offline setzt.
9 Interviewer: Was waren die Hauptgründe, warum das ERP-Upgrade durchgeführt wurden.
10 Interviewter I: Es hat aus meiner Sicht, hauptsächlich zwei gegeben. Wir haben erstens
funktionale Erweiterungen, speziell im HR-Bereich gewollt, wo das alte Release, das nicht
mehr leisten konnte, was man sich da gewünscht hat. Das geht hin bis zu, ich habe ein
Employee-Self-Service, ich habe ein Manager-Self-Service alles über ein Browser-Interface,
wäre mit der alten Variante nur mit Zusatztools usw. möglich gewesen, während des da,
sozusagen Out-of-the-Box, inwieweit bei SAP irgendwas Out-of-the-Box ist, kann man jetzt
diskutieren, mehr oder weniger mitgeliefert bekommen, war das Eine und das Zweite war,
wie ich im Vorhinein schon gesagt habe, dass man einfach die Hardwarebasis aus zwei
Gründen upgrade wollte, erstens weil man gesagt hat, das spart Kosten, weil wir haben
dazumal noch diese UNIX-Server gehabt, die speziell in der Wartung extrem teuer waren im
Verhältnis zu den Windows-Servern damals, war die eine Geschichte und dann bei SAP
haben wir immer, die unterliegenden Komponenten, Betriebssysteme, Datenbanken etc., die
haben ja auch ein Ende der Wartungsdauer usw., dann wird dieses Release nicht mehr
unterstützt und da muss ich dann immer überlegen ob, wenn ich jetzt einen Main-Release-
Wechsel mache, bei der Datenbank das geht noch mit einem Upgrade, Betriebssystem-
Upgrade machen auf einem laufenden SAP-System halte ich für verwegen und auch mein
Basisberater. Da sagt er, nimm einen neuen Server, installier das neu, schau, dass die Daten
rüberkommen und wenn man das sowieso schon machen muss, dann nimmt man natürlich
auch die neueste Version, weil man dann auch noch die Features dazu bekommt. Ich glaube
das waren aus meiner Sicht die Sachen, die man gebraucht hat, gerade so, ich sage, ein
Anwendungsbereich wie, die Finanzbuchhaltung oder so, die ändert sich nicht so stark, das

163
 ist eigentlich jetzt nirgends so wirklich die treibende Kraft, dass ich sage, da brauche ich ein
neues Release oder so, weil eine Buchhaltung ist eine Buchhaltung, die wird sich nicht
ändern, die gesetzlichen Vorgaben sind auch immer einzuhalten, also da hat man nicht viel
Spielraum. Aber gerade im HR-Bereich, da kann man auch kreativ sein, wir haben dann
auch zusätzlich noch, zu diesem Self-Service, haben wir auch noch eine sogenannte
Academy gegründet, das ist nur, unser, sage ich einmal, Projektname für so eine Art
Learning-Solution, das heißt man kann sich zu Kursen anmelden.
11 Interviewer: Also interne Weiterbildung?
12 Interviewter I: Genau, geht alles jetzt über dieses Java-Interface von SAP oder seit dem
Upgrade ist es technisch unterstützt und wir haben dann sukzessive natürlich auch da die
Funktionalitäten aufgebaut.
13 Interviewer: Welche Hauptziele würden für Ihr Projekt definiert?
14 Interviewter I: Ein Teil war die neue Funktionalität die danach nutzbar sein musste, es war
andererseits auch die bereits erwähnte Kostensenkung in punkto Hardwarewartung, also
sprich laufende Kosten weil ich muss das ja immer bezahlen und es war, dass man sagt, ich
habe jetzt wieder eine sichere Plattform auf der ich jetzt die nächsten, weiß ich nicht wie
viele Jahre, einfach weiterarbeiten kann und nicht fürchten muss, dass mein Betriebssystem
nicht mehr unterstützt wird, dass meine Datenbank nicht mehr unterstützt wird, und undund.
Das sollten eigentlich alle Faktoren gewesen sein, die damals wirklich den Anlass gegeben
hat. Es hat sich natürlich so entwickelt, das ist ja nichts, wo ich sage, und heute komme ich
darauf, morgen mach ich das. Das hat sich so sukzessive gesammelt und irgendwann hat
man gesagt, so jetzt sind wir soweit, dass sich das auch wirklich lohnt und dass wir den
Aufwand investieren um das zu tun. So waren eigentlich die Ziele. Es war nicht so, dass
man jetzt sagt, ich will jetzt wirklich einen messbaren, also den messbaren Benefit,
abgesehen von der IT-Wartung, der wurde zumindest nicht definiert, weil erstens ist messen
in diesem Bereich immer sehr schwierig, weil Kosten kann ich messen, aber ob der
Anwender jetzt nachher schneller ist, nach dem Upgrade oder nicht, wie messe ich das, und
gerade bei einem Buchhalter sowieso nicht, weil wenn der seinen Beleg bucht, der muss
vorher gleich viel eingeben, wie nachher. Da ist auch kein Performancegewinn oder so, das
ist alles irrelevant in der Sache. Ich darf nicht so abwertend über die Buchhaltung reden, das
muss man auch machen, aber dort ist halt Kreativität eher nicht angebracht, sondern lieber
schematisches Denken und schematisches Arbeiten und dort ist es auch schwierig jetzt
irgendwelche Benefits zu messen nachher. Es gibt andere Sachen, gerade in Deutschland
zum Beispiel, viele, mittlerweile werden es immer mehr, automatisierte Kommunikation mit
den Behörden, wo ich sage, denen muss ich meine Lohnsteuerbelege übermitteln, damit das
korrekt abgerechnet wird, und, und, und. Das war auch eins der Ziele, dass das einfacher
wird. Das war mit dem alten Release, ein bisschen, nun ja, es ist gegangen aber man hat halt
ein bisschen mit der Kirche ums Kreuz arbeiten müssen und das hat sich schon stark
vereinfacht, allerdings, das war nicht das Ende der Entwicklung, das ist natürlich ein
laufender Prozess. Da kommt permanent was dazu, die Behörden werden schlauer, habe ich
zumindest bisher immer gehofft. Also in Deutschland kommunizieren wir mit den
Finanzbehörden, mit den Krankenkassen und mit einer Behörde noch, aber auf drei
verschiedene Methoden.
15 Interviewer: Also es gibt keinen einheitlichen Standard oder keine einheitliche Schnittstelle?
16 Interviewter I: Genau. Ja gibt es nicht. Und da braucht man dann auch noch unterschiedliche
Zusatztools und, also ist spannend, aber Gesetzgebungen in einem Land, indem ich nicht
wohne.
17 Interviewer: Gibt es das in Österreich auch, dass man automatisiert mit Behörden
kommuniziert?
18 Interviewter I: Man könnte es, aber man muss es nicht, in Deutschland muss man, also aber
eine gewissen Firmengröße muss man in Deutschland, in Österreich darf man, mit den
Finanzämtern tun wir es auch, mit den Krankenkassen tun wir es deshalb nicht, weil es ja in
Österreich nicht so eine Vielfalt gibt. In Deutschland kann man sich ja bei einer beliebigen

164
 Krankenkasse versichern, aber man muss bei einer sein. Ja, in Österreich hat man eigentlich
ja keine Wahl. Insofern gibt es dort eine Kommunikation, die aber auf der Übermittlung von
fix definierten Dateien passiert, in Österreich, in Deutschland ist es etwas schwieriger.
19 Interviewer: Somit sind wir dann eh schon beim Hauptthema. Welche Faktoren sind Ihrer
Meinung nach die wichtigsten Faktoren, damit solche Projekte erfolgreich durchgeführt
werden können?
20 Interviewter I: Das ist eine interessante Frage und ich habe darüber nachgedacht und ich
habe ja in anderen Softwarepaketen auch so ähnliche Projekte gemacht und sie wirklich
Revue passieren lassen, was ist eigentlich bei uns passiert. Aber es kommt immer auf
dasselbe an, meiner Meinung nach. Also ich weiß nicht, wie es in anderen Firmen ist, da bin
ich schon zulange weg. Also, wie bei allen Projekten bei uns, wurscht ob ich ein Upgrade
Projekt oder irgendwas anderes, oder ein Implementierungsprojekt oder auch nur ein kleines
mache. Das Wichtigste ist das, dass ich es gescheit plane, sind wir uns ehrlich, also einen
gescheiten Plan und jetzt nicht, wo ich sage, an dem Tag mache ich das, sondern, welche
Schritte brauche ich, wer macht was, was tue ich, wenn was in die Hose geht, was ja auch
immer ist, also diese ganzen Fallback-Szenarien, die darf man nie vergessen, man hofft
zwar, dass man nie hinkommt, aber, dass ist wie, ich zahle ja auch eine Versicherung für
mein Auto und hoffe trotzdem, dass ich keinen Unfall habe. Das ist genau das gleiche. Ich
muss einfach präpariert sein, für alle Eventualitäten, was tue ich. Das ist für mich das aller
wichtigste.
21 Interviewer: Also klassisches Projektmanagement?
22 Interviewter I: Ja, wobei, das für mich noch verschiedene Spielarten hat, also, ich brauche
jetzt nicht das große Tool, sondern ich muss es einfach tun. Also es muss jetzt nicht mit 27
Tools und perfekt unterstützt sein, von einem, ich weiß nicht, Microsoft Project oder was
auch immer es am Markt gibt, es gibt viele. Aber es muss einfach gescheit passiert sein und
damit es gescheit passiert, kommt das, was für mich am zweit-wichtigsten ist, ich muss das
Team richtig zusammensetzen, schon von der Konzeptionsphase, weil ich kann Leute haben,
wie sage ich das am besten, es gibt Leute die sind in ihrem Fachbereich super, aber sie
können nicht projektorientiert denken, die machen ihre Arbeit, perfekt, vorausschauen, alles
super, aber in dem Moment, wo es in die Projekte reingeht, sind sie überfordert, das können
sie nicht, nicht weil sie dumm sind, sondern einfach weil das ihrer Denkweise nicht so liegt.
Also ich muss die richtigen Leute im Team haben und zwar unter Umständen sogar
verschiedene für die Konzeptionsphase und für die Durchführungsphase. Das ist das Eine.
Wie soll ich sagen, in dem Fall habe ich mir da leicht getan, wenn man lange in der Firma
ist, kennt man die Leute und man weiß auch, was man von wem erwarten kann und wenn
man dann eine Mitsprache hat in der Teamzusammensetzung, dann kann man sich da helfen.
Wobei manchmal auch bedingt, wenn ein Bereich den nominiert, im FI Bereich den
nominiert und sagt der arbeitet da mit, dann werde ich dem Buchhaltungschef nicht
vorschreiben können, welche Leute er da reinsetzt. Aber man kann einmal drüber reden und
kann sich da ein bisschen verwenden in die Richtung, dass die Richtigen drinnen sind. Das
ist die eine Geschichte, also Teamzusammensetzung, auf Basis dessen, dann die Planung.
Dann brauche ich eine gescheite Kommunikation, ja, an dem führt kein Weg vorbei, weil es
hilft mir nicht, wenn jeder zwar Top in seinem Bereich ist, aber nicht mit den Anderen redet
und ich damit diese Abstimmung nicht habe, die ich brauche, diese ineinander Verzahnung
in jeder Hinsicht und sobald ich das aufgesetzt habe, fehlt mir nur mehr eines und das ist die
Unterstützung vom Management, weil natürlich haben die Anwender Unannehmlichkeiten
in so einem Projekt, weil da steht einmal was, da geht nachher was nicht, da muss ich
vielleicht Vorarbeiten leisten, die es schon mühsam machen eigentlich, obwohl ich noch gar
nicht umgestiegen bin, weil es meine Arbeit erschwert. Und das muss vom Management
getragen werden, weil wie bekomme ich die Maßnahmen nie durch, und da stoße ich auf so
viel Widerstand, dann kann ich es nicht machen. Es geht dann immer irgendwie, aber die
Frage ist mit wieviel Reibungsverlusten und mit wieviel zusätzlichem Zeitaufwand
bekomme ich das durch. Wird schwierig, das sind für mich die Sachen, die brauche ich in

165
 jedem Projekt, das ist nicht nur auf Upgrade-Projekte bezogen. Aber das Upgrade-Projekte
unterscheidet sich ja andererseits auch wieder nicht. Das ist einfach notwendig und wenn
einer davon fehlt, wird es schwierig. Ja jetzt kann man, gerade in punkto Kommunikation, es
gibt Leute die können sowieso miteinander oder können gut miteinander, aber ich muss auch
mit jemanden arbeiten können mit dem ich vielleicht nicht auf ein Bier gehe, sagen wir es
sehr salopp, aber dann muss ich das ebenso auf die Füße stellen oder mir so überlegen, wie
funktioniert das. Ich hüpf da jetzt ein bisschen herum jetzt, aber zurück zur Projektplanung,
dass ich sage, und an dem Milestone muss ich an wen reporten und wer muss was wissen.
Weil irgendwie muss das Management ja auch informiert werden. Das wird nicht mit jedem
Projektmitarbeiter sprechen wollen. Aber ich glaube, wenn ich die vier Sachen, die vier
Sachen sind das Essentielle.
23 Interviewer: Sie haben ganz am Anfang über externes Consulting usw. gesprochen, ist das
auch ein wichtiger Punkt oder könnte man, wenn man jetzt, theoretisch viel Know-How im
Unternehmen hat, das auch ohne externes Consulting erfolgreich durchführen?
24 Interviewer: Wenn man das Geld in die Hand nimmt um sich dieses Know-How aufzubauen
das man braucht und es sich leistet, dass ich das Know-How, das ich einmal brauche, ja
natürlich, kann ich einen Großteil davon, dann anders auch wieder einsetzen, aber ein Teil
bleibt über, den brauch ich genau einmal. Wenn ich es mir leiste, dass ich mir das intern
aufbaue, komme ich auch ohne aus. Aber es ist erstens wirtschaftlich nicht sinnvoll und
zweitens, wie soll ich sagen, sogar wenn ich das Know-How habe aber ich habe es noch nie
praktisch angewendet, das ist das, das schaffe ich nicht, weil ich mache es nur einmal. Und
das erwarte ich von einem Externen, dass er sagt, ja das habe ich bei der Firma schon
gemacht und bei der und bei der, und dann weis ich, ahh, und dort waren die Probleme und
dort waren die, dann weis ich, ahh, der weiß wie man die umschifft und wenn bei uns
welche sind, dann erwarte ich von ihm, dass er uns da zumindest unterstützt, wenn sie
technischer Natur sind, ich mein organisatorisch müssen wir eh selber schaffen. Also ich
halte es nicht für sinnvoll, möglich ist es. Aber es ist weder kosteneffizient, noch, weil ich
muss ja meine Vorlaufzeit verlängern, weil ich muss ja das Know-How vorher aufbauen. Ich
muss die Leute, während sie das Know-How aufbauen, vernachlässigen sie was Anderes.
Die sind ja nicht da und warten, dass sie eine Arbeit bekommen, die haben ja was zu tun, die
sind ja beschäftigt. Das heißt das wird schwierig und eigentlich, aus meiner Erfahrung,
leistet sich das eine Firma nicht mehr, ganz egal wie groß die ist. Ein Jeder sagt, da gibt es
Experten am Markt, die hole ich mir, die kosten zwar was, ja, aber es kommt mir unterm
Strich gesehen wahrscheinlich immer noch billiger, also wie wenn ich das selber mache.
Wenn ich es selber mache und es geht dann alles gut, dann ist die Rechnung vielleicht
wieder eine andere, aber mit dem zu rechnen halte ich für verwegen. Weil irgendwelche
Probleme treten immer auf, es ist einfach so. Mit dem muss man leben.
25 Interviewer: Wie würden Sie diese Faktoren priorisieren?
26 Interviewter I: Ja, genauso wie ich es erwähnt habe, also eigentlich die Planung, die
Teamzusammensetzung, die Unterstützung durch das Top Management und die
Kommunikation. So hätte ich das gesehen.
27 Interviewer: Sind bei ihrem Projekt Probleme aufgetreten, gröbere, wo man sagt, ok, da hat
man jetzt wirklich entgegenwirken müssen und wenn ja, wie?
28 Interviewter I: Wir reden von technischen Problemen oder von anderen?
29 Interviewer: Von technischen sowie auch organisatorischen, würde ich sagen.
30 Interviewter I: Also in dem konkreten Fall gab es, fangen wir mal bei den anderen an,
organisatorisch, ja, da gibt es immer wieder kleinere Reibereien, Uneinigkeiten oder so, aber
wirkliche Probleme würde ich das nicht sehen. Und das passiert, wenn Menschen
kommunizieren, dass sie sich abundzu falsch verstehen, dass sie nicht verstehen wollen, was
der Andere sagt, das ist einfach so. Ich mein, da kann man ganz offen sprechen, aber ich
sage, das ist so, wenn Menschen miteinander arbeiten gibt es auch Probleme, gibt es
Reibereien, gibt es Animositäten, das passiert, ja, aber das ist nichts, was man nicht schaffen
kann. Unter Umständen braucht man innerhalb vom Projektteam sogar einen Art Mentor,

166
 der halt dann einmal sagt, he Burschen kommen wir wieder zur Sache zurück und lasst jetzt
euren Kleinkram da bei Seite, also abgesehen davon, war da eigentlich nichts. Nichts, das
ich wüsste. Ja, technisch, war es so, dass wir, wie soll ich sagen. Sowas macht man ja nicht
einfach indem man loslegt, erstens haben wir eine vernünftige Planung gemacht, auch
technischer Natur, zweitens haben wir natürlich das alles einmal auf einer kopierten
produktiven Maschine durchgespielt und geschaut, was passiert denn da. Das zählt bei mir
auch zur Planung, Vorbereitung, weil das muss ich tun. Alles andere, kann ich nie einen
Zeitplan machen, weil ich muss dort einmal schauen, wie lange brauche ich, wie lange habe
ich Down-Time, welche Probleme treten auf, weil ich erwarte ja, dass dann ähnliche auf
dem Echten sind. Dort hat es natürlich einiges gegeben, dort haben wir aber den Zeitraum
den wir uns dafür gegeben haben auch großzügig genug geplant haben um diese Probleme
dann vernünftig lösen zu können und teilweise auch mit Hilfe des Herstellers, weil
irgendwann dann natürlich auch die externen Berater sagen, jetzt muss ich fragen gehen,
weil mein Pouvoir, wo ich da überhaupt etwas tun kann und eingreifen kann, ist da am Ende.
War aber nur ein kleiner Fall wo wir einfach ein Problem gehabt haben, das eigentlich nicht
unser Problem war, weil wir konnten die erforderliche Software nicht runterladen, weil, das
hat irgendwie in der Berechnung nicht so funktioniert. Lag direkt bei SAP, da haben wir
dann mit Indien geredet, weil die Techniker sitzen alle in Indien, sind ganz leicht zu
verstehen, wenn sie englisch reden. Aber ok, aber der Zeitrahmen war so konzipiert, dass
sich das alles ausgegangen ist, wir haben es geschafft, wir haben ca. 2,5 Monate damit
verbracht nur auf dieser Maschine zu spielen und sozusagen ein Konzept zu entwickeln, wie
machen wir das auf den Folgesystemen. Und da war nichts, ja es gab welche, aber das waren
Kleinigkeiten, die gibt es sowieso. Kein Mensch erwartet, ich drücke am Knopf, ja,
vielleicht erwarten es welche, aber dann sind sie keine Realisten. Und es war eigentlich
nichts gravierendes.
31 Interviewer: Ganz kurz noch, eine Zwischenfrage, wie viele Anwender sind auf Ihrem
System ca. tätig?
32 Interviewter I: Ja, das ist eine gute Frage. Wir können es über die Useranzahl nicht wirklich
machen, weil wir haben ja unser Bewerbungsportal, schreibt direkt in SAP, das heißt wir
haben für jeden Bewerber, der bei uns eine Bewerbung abgibt, bekommt einen User. Das
heißt dann, wir haben in Summe so ca. an die 30.000 User, was wir lizenzmäßig natürlich
nie bezahlen würden, weil das ist ja keiner. Defacto, welche die wirklich arbeiten, also
theoretisch ist es jeder Mitarbeiter. Jeder kann seinen Gehaltszettel online anschauen,
mittlerweile nur mehr online, weil er bekommt keinen mehr seit letztem Jahr. Vorher hat
man es anschauen können und auf Papier bekommen, jetzt bekommt man es nur mehr
elektronisch. Insofern hat jeder einen User. Aber wenn wir schon über Lizenzen reden, das
ist nur ein sogenannter Info-User aus SAP Sicht, der kostet weniger. Also Leute die wirklich
operativ arbeiten, in der HR, in der Buchhaltung, im Controlling, sind so an die 1500. Das
sind schon einige, plus die, die noch anders darauf zugreifen. Wobei, da muss ich eine kleine
Anmerkung machen, das SAP System ist nicht nur das SAP System der XYZ. Wie Sie
wahrscheinlich im Eingangsbereich schon gesehen haben, gibt es ja auch XYZ. Unsere
Systemabteilung hier betreut die Server beider Firmen. Bis vor einem Jahr circa war ich
auch noch Mitarbeiter der Holding. Das heißt, die ganze IT, also waren eigentlich alle
Mitarbeiter, Mitarbeiter der Ur-AG, also der Gruppe eigentlich, wo darunter dann erst die
XYZ und die XYZ war. Das hat sich dann aus diversen steuerrechtlichen und
finanztechnischen Gründen und auch weil die Firmen sich mehr und mehr splitten wollten,
geändert. Jetzt bin ich XYZ-Mitarbeiter, aber im SAP System sind trotzdem auch noch die
Shopkonzept-Firmen drinnen. Also wenn man es so sieht, hätten wir dann noch einmal um
1000 Mitarbeiter mehr, die dieses System nutzen. Also, die in den Firmen arbeiten, die
dieses System betreut oder umfasst. Insofern haben wir, aber das sind die User, also wirklich
die Userzahlen aus SAP, also da sind auch ca. 10% aus dem XYZ-Bereich. Ich sage es jetzt
einfach einmal brutal, das sind halt noch zusätzliche Buchungskreise. Jedes Amt hat seinen
Buchungskreis und muss seine eigene Buchhaltung führen, und undund, aber es ist vom

167
 Aufwand her nicht mehr, was man technischer Natur hat nur mehr Koordinations-Aufwand,
wenn man zum Beispiel eine Downtime haben will. Ja, weil die haben natürlich andere
Arbeitszeiten, ich mein, es ist generell, Downtime gibt es sowieso, eine wo ich einfach was
tun könnte so unter der Woche im Normalfall gibt es nicht, weil ja entweder die Australier
arbeiten oder die Kalifornier oder die Europäer oder in Middle-East und es spielt keine
Rolle, irgendwer ist immer drauf.
33 Interviewer: Auf wie kurz schafft man es, dass man die Downtime herunter bringt?
34 Interviewter I: Die Downtime des Produktivsystems, weil das ist das, was die Anwender
trifft. Es gibt ja auch Power-User die dann Customizing machen, die brauchen die ganze
Systemlandschaft, da gibt es eigene Verfahren, wann das eine System schon upgegradet ist
und das andere noch nicht, das ist ein ziemlich mühsamer Task, den man da planen muss.
Die Downtime des Echtsystems, war in etwa 36 Stunden. Also sprich, da haben sie das
Arbeiten aufgehört und nachher hoffentlich gleich wieder weitergearbeitet. Aber es waren
keine großartigen Requests nachher, das irgendwas nicht funktioniert hätte, es waren ein
paar Kleinigkeiten für irgendwelche Nischenanwender, sage ich einmal, die halt mehr tun
als der Standardbenutzer, wo dann minimale Adaptierungen notwendig waren danach noch,
aber das hat sich in vernünftigen Grenzen abgespielt und mit dem habe ich auch gerechnet.
Kein Mensch geht danach in den Urlaub. Zumindest kein vernünftiger Mensch. Da geht es
ja auch um Arbeitsrecht, ich sage, wann kann ich sowas machen? Am Wochenende, ja. Laut
Arbeitsrecht, darf ich aber nur 50 Stunden in der Woche arbeiten und maximal 10 an einem
Tag. Da kann ich sowas nicht machen. In den 36 Stunden habe ich, glaube ich, 5 bis 6
Stunden geschlafen. Den Rest habe ich gearbeitet. Dann war halt dann jemand anderer da,
der aufgepasst hat, dass nichts passiert. Aber, das lässt sich nicht durchführen, es sei denn
ich habe so eine große Mannschaft, mit relativ gleich großem Know-How. Nein, das leistet
sich auch keiner. Und nachher muss man auch da sein. Ich kann nichts sagen, ahh, jetzt habe
ich das Wochenende durchgearbeitet, jetzt raste ich mich mal zwei Tage aus. Das ist schön,
aber genau die zwei Tage sind die interessanten oder vielleicht sind es auch mehr wie zwei.
Je nachdem wie gut es dann gegangen ist oder auch nicht. Also da muss man, aber die
wirkliche Downtime war ca. 36 Stunden. Sonst konnte immer gearbeitet werden. Und ich
war auch heilfroh, dass ich dieses 36 Stunden einhalten konnte. Aber ja, wenn man das
Produktivsystem macht, wie es bei uns war, das war dann das vierte SAP System. Das heißt
wir haben gewusst, ok, das erste Mal mit Problemen, da ist es natürlich auch länger down,
weil wenn ich in der Downtime-Phase ein Problem habe, dann muss ich das auch beheben
und wenn ich noch nicht weiß wie, weil ich noch keine Erfahrung damit habe, dann muss
ich einmal forschen gehen, lese dort nach, frage jemanden und wenn der auch nicht mehr
weiß, dann geht man zu SAP fragen zum Beispiel oder man schaut nach. Die haben da so
ein eigenes Hinweissystem oder ein Portal wo man sich informieren kann. Das dauert
einfach. Und so haben wir das halt sukzessive verfeinert, wobei wir dann berücksichtigen
muss, dass man am Testsystem, da gibt es auch einen reinen Datenumsetzungs-Step. Der
dauert natürlich länger am Produktivsystem, weil mehr Daten dauern natürlich länger, also
das muss man dann natürlich auch irgendwie gegenrechnen. Aber wir haben 40 Stunden
veranschlagt gehabt und waren nach 36 fertig und wenn man früher fertig ist, ist keiner
angefressen. Es darf nur nicht länger dauern, als man veranschlagt hat, dann geht es aber der
ersten Minuten. Das heißt man plant es einfach vorsichtig. Sagen wir mal so.
35 Interviewer: Wann ist so ein Projekt erfolgreich? Wenn nachher wieder alles wieder so geht
wie vorher?
36 Interviewter I:Mhhmm, abhängig davon, was ich als meine Anforderungen definiert habe.
Wie es bei uns war, einerseits wir wollen alles so machen wie vorher plus das Neue machen
können. Dann muss ich sagen, wann ist es erfolgreich, wenn die funktionalen Tests
erfolgreich sind, sprich, ich schaue an, was habe ich vorher gemacht, geht das noch genauso
gut, schnell, vielleicht hat sich eine Maske ein bisschen verändert, kann natürlich sein, aber
rein von der Sache her gleich gut. Dann schauen, kann ich auf die neuen Features zugreifen,
auch wenn ich die jetzt noch nicht ultimativ nutzen kann, weil durch das Upgrade habe ich

168
 jetzt einmal die Basis geschaffen. Ich muss dann ja noch was tun, damit ich die auch
wirklich nutzen kann. Dann habe ich meine Termine eingehalten, das gehört zum Erfolg von
einem Projekt dazu, habe ich meine Kosten eingehalten. Wobei Termin und Kosten ist leicht
zu messen, ja, da habe ich unter dem Strich, ich zähle zusammen, und sage ja, ich war fertig
zu diesem Termin, gekostet hat es mich das. Passt. Spannend wird es bei den funktionalen
Tests, auch nicht bei den alten Sachen sondern von den Neuen. Weil da kann es auch, wir
haben einen Fall gehabt, da haben wir etwas erwartet, was wir dann erst nicht gehabt haben.
Sagen wir einmal so. Was aber daran lag, dass die Anforderer das falsch gelesen haben oder
einem Verkäufer zuviel zugehört haben, das kann man jetzt sehen wie man will. Der hat
ihnen das versprochen und gesagt mit diesem Release geht das und es ist trotzdem nicht
gegangen. Zumindest nicht ohne ein Zusatzpaket, dass man extra erwerben hat müssen.
Aber das war jetzt nicht das Problem des Upgrade-Projekts, das war das Problem der
Erwartungshaltung. Darum ist für mich das auch noch wichtig, ich muss die
Erwartungshaltung vorher schon vielleicht ein bisschen runterbringen und nicht jetzt
himmelhochjauchzend machen, weil so, ahh, jetzt haben wir das neue Release, das ist das
Allheilmittel, da geht jetzt alles, was ich mir jemals gewünscht habe, das ist nicht so. Es gibt
genau definiert Sachen, die dann funktionieren, die zusätzlich funktionieren sollen und
werden, hoffentlich auch. Aber das so, ahh, dann geht dann sowieso alles. Man muss auch
die Anwender auch ein bisschen bremsen. Ich meine, ihr habt euch das erwartet, aber das
können wir nicht erfüllen. Also so auf die Art, auch genau, also eigentlich fällt das unter
Kommunikation. Ich muss nach außen bringen, was profitiert ihr davon. Weil es gibt zwar
die Leute die das wollen, aber das ist halt ein kleiner, zwar meist einflussreicher, aber ein
kleiner Kreis, weil der hat sich informiert, der weiß auch da will ich hin. Und die geben
dann, dass auch unter Umständen auch ein bisschen zu euphorisch weiter und der
Endanwender draußen sagt dann, boah super, das geht dann eh alles. Unter dann kommt die
große Frustration. Und das sollte man eigentlich vermeiden, finde ich. Weil ich habe dann
nichts davon, wenn ich dann viele Leute habe, die dann frustriert sind, weil die
Versprechungen die sie bekommen haben, nicht eingehalten werden und ich eigentlich
nichts dafür kann, aber ich muss es dann ausbaden. Also muss ich immer probieren, dass so
ein bisschen korrekt zu kanalisieren und da die Erwartungshaltung nicht allzu hoch werden
zu lassen. Das ist für mich das, wann es erfolgreich ist. Wenn man die Erwartungshaltung
erfüllen hat können, wenn man, also meine sehr persönliche Meinung ist noch, wenn, also
ich mache lieber was Gescheites und es dauert ein bisschen länger und kostet vielleicht um
das Spüren mehr, ist für mich persönlich nicht so wichtig, natürlich gibt es da viele
Manager, die anders denken, das ist korrekt. Aber zu sagen, ich muss den Termin jetzt auf
Biegen und Brechen einhalten auch auf Kosten dessen, dass was Gescheites rauskommt, da
habe ich dann meistens ein Problem und das führt dann öfter zu einem Disput, den keiner
haben will, aber der trotzdem wichtig ist, dass er geführt wird. Ich sehe mich da als
Techniker, und wichtig ist, dass das gescheit wird und dass wir uns vorher überlegen, was
gescheit ist. Und nicht ob wir jetzt eine Woche früher oder später fertig sind. Sorry Leute,
ich muss mit dem dann jahrelang leben, was ich da gemacht habe, ja, da kann es nicht darauf
ankommen. Termineinhaltung, schön und gut, bin ich dafür. Kosteneinhaltung auch, aber
nicht um jeden Preis. Für mich ist es wichtig, dass was Gescheites rauskommt und viele
Anwender sehen das natürlich auch so und meistens kann man das auch vernünftig
argumentieren. Ich bekomme das auch durch, also alles andere wäre absurd. Aber man muss
zumindest argumentieren, verstehe ich auch. Ist ok.
37 Interviewer: Bei der nächsten Frage geht es um die Unterschiede zu reinen
Implementierungsprojekten.
38 Interviewter I: Ja, habe ich auch schon gemacht.
39 Interviewer: Das ist perfekt. Wo sehen die größten Unterschiede hinsichtlich
Erfolgsfaktoren?
40 Interviewer: Also, wenn ich was implementiere. Dann mache ich das ja nicht, weil ich Spaß
daran habe, sondern, ich mache das, weil es Anforderungen gibt, die in Summe dazu führen,

169
dass ich sage, ich implementiere jetzt ein Softwaresystem. So, das heißt, die wichtigste
Phase bei einem Implementierungsprojekt ist für mich, dass ich definiere, was will ich den
überhaupt. Ich muss meine Prozesse definieren, ich muss auch die Abgrenzung definieren,
was will ich den nicht. Ich muss die Anforderungen gewichten, was brauche ich unbedingt,
was ist Nice-to-Have und was ist Wunsch an den Weihnachtsmann, oder so, und das habe
ich alles bei einem Upgrade nicht, ja wenn ich ein Upgrade mache, ich habe mein System,
dann kann ich sagen, OK, wenn ich jetzt ein Upgrade mache dann kommen die und die
Features dazu laut Aussage des Herstellers, weil überprüfen kann ich es vorher auch nicht.
Ich kann das dann beim Upgrade auch noch so machen, ich mache eben dieses Testsystem,
mach es dort einmal und sage dann, schaut einmal darauf ob es das liefert, was ihr wollt. Bei
einem Implementierungsprojekt, kann ich das alles nicht tun. Da muss ich meine Definition
wirklich, ein gescheites Feinpflichtenheft machen, muss letztendlich oft, gerade wie es in
einem Konzern ist, gibt es Anforderungen aus verschiedenen Bereichen, muss sagen, was ist
den da wichtiger, falls sich da etwas ausschließt. Muss genau festlegen, was ist ein Must-
Have und was ist ein Nice-to-Have. Also, alleine in der Definitions- und Konzeptionsphase
ist für mich das Implementierungsprojekt, weit weit aufwendiger, weit weit detaillierter zu
machen und auf alle Fragen einzugehen, also bei einem Upgrade. Weil bei einem Upgrade
habe ich, um auf das Beispiel von vorher wieder zurück zu kommen, der Buchhalter wird
nachher auch seine Belege wieder buchen wollen, ob er das jetzt mit dem Release oder mit
dem Release macht, ist dem scheissegal, sehr salopp gesagt. Wenn ich was implementiere,
dann ist, das dem, der damit arbeiten will nicht egal, wie er damit arbeiten soll. Sondern der
hat ganz genaue Ideen, wo er, weil wegen dem will er ja was. Der hat Ideen, wo er
effizienter werden will, der will ja nicht so arbeiten wie bisher, weil dann könnte er mit dem
alten Ding weiter tun, dann braucht er ja nichts Neues. Also, wie gesagt, für mich ist der
Unterschied einfach, erstens in der Definition, aus dieser Definition, ergibt sich natürlich
auch meine Zieldefinition, ergibt meine nachherige Prüfung ob das jetzt erfolgreich war oder
nicht. Und vor allem der Zeitrahmen ist viel länger. Auch wenn ich es einmal implementiert
habe, im Normalfall, habe ich dann, wie soll ich sagen, ich nenne es immer ein nacktes
System, das habe ich noch nicht für meine Bedürfnisse eingerichtet und nicht für meine
Bedürfnisse gecustomizt. Je nachdem wieviel man, dass dann auch wirklich kann. Aber der
Prozess hört nicht auf, wenn ich es implementiert habe, dann habe ich hoffentlich was, mit
dem ich arbeiten kann. Und dann gehe ich daran, dass ich das dann optimier. Das fällt weg
bei einem Upgrade. Bei einem Upgrade bin ich, wenn nachher alles geht, bin ich eigentlich
fertig. Als IT-Techniker, die Anwender, wieder was Anderes. Weil die wünschen sich dort
natürlich auch was. So kommt man ja dann zum Nächsten, nun ja, weil die lesen wo, ah, da
gibt es die Funktionalität usw. Aber bei der Implementierung ist das alles in einem Zug
mehr oder weniger. Aber die Faktoren sind die gleichen, ich muss spezifizieren, ich muss
ein vernünftiges Team haben, ich brauche die Unterstützung durch das Management, das ist
immer das gleiche. Also der Unterschied für mich ist einfach, wie lange dauert es, wo hört
es auf und wie gut muss ich es definieren, das ist für mich eigentlich der essentielle
Unterschied. Also außer so Kleinigkeiten wie, vielleicht ist das System so neu, dass ich jetzt
für mein Hard- und Software oder Systemsoftwarebetreuung noch Leute ausbilden muss,
weil das was Neues ist. Wird uns passieren, beim nächsten SAP Upgrade zum Beispiel, weil
da kommt dann sicher HANA als Datenbank und wer hat da Know-How nachdem man es
nie braucht. Das läuft auch nur mehr unter Linux, wir haben keine Linux Server und kein
Linux Know-How. Muss da alles in die Planung mit einfließen und das kann mir bei einem
Implementierungsprojekt natürlich immer passieren, weil wenn ich mir nicht die Software
selber stricke, was wir teilweise ja auch tun, sondern mir ein Tool am Markt kaufe und das
dann entsprechend meinen Anforderungen customize, adaptiere, wie auch immer man, dass
dann auch nennt, dann ist das so, wie es ist. Dann kann ich mir das nicht aussuchen, ich
hätte da gerne, weiß ich nicht, mit der Oberfläche oder mit den Entwicklungstools, sondern
das ist dann so. Und wenn ich da kein Know-How habe, dann muss ich mir das vorher
aufbauen, weil sonst bin ich nachher ja überhaupt nicht in der Lage intern irgendetwas zu

170
 tun. Ich mein, schön für den Lieferanten, weil der dann immer die Hand aufhalten kann aber
für uns nicht tragbar. Also wir versuchen schon immer für alles was wir erwerben, mehr
oder weniger auch, den Source Code zu erwerben. Bei SAP geht das natürlich nicht, aber bei
vielen anderen Softwareprodukten ist es so, dass wir über den Source Code verfügen, dass
wir da auch rein können, wenn es unbedingt sein muss. Die meisten Programme heutzutage
haben sowieso irgendwelche API's wo man sich andocken kann, da braucht man nicht
wirklich in den Source Code der Applikation rein. Aber ich rede jetzt von vor 20 Jahren, da
wo wir jetzt unsere Produktionsplanung machen, das benutzt man jetzt seit 20 Jahren, das
war gerade in der Einführung wie ich da in der Firma angefangen habe. Und wir haben den
Source Code, wir können da alles tun, wir könnten das Ding komplett umschreiben, wir
haben auch das Know-How dafür, wir werden uns hüten. Aber an manchen Stellen ist es
immer wieder gut, wenn man zumindest nachschauen kann, wie ist den das da realisiert, wie
ist das programmiert, wie funktioniert das, warum läuft das eigentlich nicht so, wie wir uns
das vorstellen, obwohl es ja unter Anführungszeichen Standard ist. Vielleicht ist unsere
Denke nicht Standard, das ist immer so eine Frage. Aber, noch einmal, für mich ist, ich muss
viel genauer definieren, ich muss viel feiner spezifizieren, was ich möchte.
41 Interviewer: Unter bei der Einführung ändert sich ja vermutlich auch prozessmäßig ja auch
viel mehr in einem Unternehmen wie bei einem Upgrade?
42 Interviewter I: Im Normalfall ja, aber nicht notwendiger weise, aber es gibt auch Prozesse
die kann ich vielleicht mit einem neuen Tool besser unterstützen, weil das Tool weiter
"geloren" ist oder wie auch immer. Aber oft ist es auch so, dass sich natürlich mein Prozess
ändern muss, nicht weil ich ein anderes Tool nehme, sondern weil ich festgestellt habe, dass
ich meinen Prozess optimieren muss und deswegen ein neues Tool brauche. Also diese
Anpassung des Prozesses an das Tool halt ich für fadenscheinig, auch wenn viele Leute
behaupten, dass gerade im SAP-Bereich die Software in der Produktion am Anfang so war,
dass sich nicht SAP an die Firma angepasst hat, sondern die Firma an SAP. Vielleicht haben
wir auch deswegen kein Produktionsmodul von SAP. Einfach weil wir sagen, da wollen wir
uns unterscheiden. Wir haben auch als wir vor mittlerweile auch schon wieder einigen
Jahren ein neues Vertriebssystem, das ist auch eines unserer ERP Systeme, das aber nicht
ich betreue, eingeführt haben, haben wir auch zum Beispiel SAP angeschaut und das war für
uns nicht verwendbar. Weil die haben unser teilweise kompliziertes Mietmodell, haben wir
nicht abbilden können dort. Also, vielleicht ein bisschen zur Info, die Baufirma muss bei uns
das Schalungsmaterial nicht kaufen. Die kann sagen, ich baue da jetzt eine Brücke, für die
Zeit die ich brauche. Ihr sagt mir was für ein Material ich brauche, weil dafür gibt es unsere
Statiker und Planer usw., können sie uns mit der Dienstleistung beauftragen, wenn sie das
nicht selbst können, ihr sagt mir welches Material ich brauche, ich sage euch wie lange ich
es brauche und ich miete das Zeug nur. Das kommt dann zurück und dann bekommt es
wieder wer anderer, wenn es angeschaut wird und repariert, saniert und teilweise auch
entsorgt, je nachdem. Und das war in SAP damals nicht abbildbar, also haben wir eine
andere Lösung gesucht und ein anderes Paket erworben. Das eigentlich auch alles könnte.
Das ist eine Axapta-Implementierung, da könnte man genau so die Buchhaltung machen,
und undund. Aber ja, unsere Landschaft krempelt sich ein bisschen um, da muss man, so,
dass wirklich im Vertrieb dann nur mehr im Vertrieb ist, was auch dem Vertrieb gehört und
nicht so wie jetzt, da gibt es auch die Hauptbuchabschreibung usw., muss alles dort
berechnet werden, weil ich dort auch die Daten habe, also, das ist einfach ein Prozess wo
sich die Landschaft laufend ändert und da muss man jetzt schauen, wie sich das in Zukunft
entwickelt. Also wenn wir in 5 Jahren reden, werde ich Ihnen wahrscheinlich eine ganz
andere Landschaft erzählen, als wie ich Ihnen jetzt sage. Aber ja, das ist bei jeder Firma so,
da dürfen Sie überhaupt keine Interviews machen, weil das überholt sich von selbst.
43 Interviewer: Ok, perfekt. Somit sind wir schon fast am Ende. In der Literatur werden
folgenden Faktoren für den Erfolg eines Implementierungsprojektes genannt: Bitte
beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der Skala
(sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig)?

171
44 Interviewter I: OK
45 Interviewer: Top Management Unterstützung?
46 Interviewter I: Also Top Management Unterstützung ist auf jeden Fall wichtig bis sehr
wichtig.
47 Interviewer: Change Management
48 Interviewter I: Für ein Upgrade halte ich es für weniger wichtig
49 Interviewer: Business Plan & Vision
50 Interviewter I: Natürlich brauche ich eine Vision, halte ich für wichtig
51 Interviewer: Projektmanagement
52 Interviewter I: halte ich für sehr wichtig
53 Interviewer: Anpassung der Softwarelösung
54 Interviewter I: Ist bei einem Upgrade weniger wichtig für mich, weil ich sage, das habe ich
ja im Normalfall schon. Ich drehe ja jetzt nicht alle meine Prozesse um, weil ich ein neues
Release verwenden möchte.
55 Interviewer: Kann sein, dass ich aufgrund von sehr starker Anpassung bzw. Customization,
eventuell bei einem Upgrade dann ein Problem hab, dass ich das mitziehe?
56 Interviewter I: Kann sein, natürlich, kann durchaus sein.
57 Interviewer: Kann das dann auch so sein, dass man als Unternehmen sagt, OK, wir
versuchen trotzdem näher am Standard zu bleiben um eventuell Probleme vorzubeugen, die
dann später auftreten können?
58 Interviewter I: Also bei uns im Haus ist die Ansicht sowieso, dass wir so nahe wie möglich
am Standard bleiben, gerade was SAP betrifft, bei anderen Paketen haben wir mit dem
Standard nichts mehr gemeinsam. Dort haben wir dann aber auch ein Problem, wenn wir ein
Upgrade fahren. Weil da machen wir fast eine Neueinführung, ja, also wir haben konkret ein
System unsere Produktionsplanung macht, wenn wir dort ein Upgrade machen, das ist wie
wenn wir es neu einführen würden. Weil das hat sich jetzt über viele viele Jahre, haben wir
das verändert, ein bisschen getürkt, da getrickst und dort angepasst und wenn wir jetzt ein
Upgrade machen, dort scheitern wir letztendlich, dass wir es tun, wahrscheinlich würd das
neue Release gar nicht so schlecht können, was wir wollen, weil wir haben halt dann schon
vorweggenommen und entwickelt, nur dort muss ich den Aufwand reinstecken und muss
meinen Anwendern sagen, schaut her, so machen wir es jetzt, das haben wir jetzt adaptiert
und so würde es im Standard gehen, passt das? Weil ich kann das nicht beurteilen. Und
wenn die sagen, für das haben wir jetzt keine Zeit, weil wir soviele andere Sachen zu tun
haben, dann machen wir das nicht. Da tun wir dann lieber noch ein bisschen herum. Und da
ist dann die Frage, irgendwann bin ich dann an dem Punkt wo ich sage, dann kann ich es
sowieso nicht mehr upgraden, dann muss ich sowieso neu aufsetzen, entweder die neue,
aktuelle Version des Tools, das ich bereits habe, oder ich überlege mir ob ich das überhaupt
noch weiter benutzen will oder ob ich nicht sowieso ganz was Anderes möchte. Ist dann sehr
naheliegend. Darum sage ich, die Anpassungen sind eher, weil die habe ich entweder schon
gemacht, aus dem können sich dann Probleme ergeben, wie Sie bereits richtig gesagt haben,
aber ich mache sie nicht in einem Zug mit dem Upgrade. Also, dass ich es an dieser Stelle
anpasse ist eher unwahrscheinlich.
59 Interviewer: ERP-Team Zusammensetzung
60 Interviewter I: Die Teamzusammensetzung ist natürlich wichtig
61 Interviewer: Softwaretesting
62 Interviewter I: Natürlich, logischerweise sehr wichtig
63 Interviewer: User Training & Schulung
64 Interviewter I: Konkret haben wir für unsere Endanwender überhaupt keine Schulung
gemacht beim SAP. Also die Schulung war in dem Fall, also halte ich für weniger wichtig.
65 Interviewer: Weil sich die Oberfläche wenig verändert hat?
66 Interviewter I: Das hat im Prinzip nachher gleich ausgeschaut. Ob dahinter jetzt was
Anderes liegt und mehr Features bietet, das ist dem Enduser egal und das braucht er auch
nicht zu wissen und dafür braucht er auch keine Schulung.

172
67 Interviewer: Business Case
68 Interviewter I: Haben wir nicht gemacht, weil einen Business Case macht man, für mich
eigentlich, vor einer Neueinführung, also rechnet sich das für mich, kann das System, dass
ich jetzt einführen möchte, das abbilden, kann ich da meinen Business Case damit
durchspielen und rechnet sich dann unterm Strich das für mich.
69 Interviewer: Projektchampion
70 Interviewter I: Halte ich nicht für wichtig
71 Interviewer: Kommunikationsplan
72 Interviewter I: halte ich für sehr wichtig
73 Interviewer: Management von Legacy Systemen
74 Interviewter I: ja, ist zwar wichtig, aber das habe ich vorher und nachher.
75 Interviewer: Gibt es die Möglichkeit, dass sich Schnittstellen aufgrund des Upgrades ändern
müssen?
76 Interviewter I: Also, die Schnittstellen ändern müssen, kann sein, weil einfach die Technik
dahinter unter Umständen eine andere wird. Im konkreten Fall war das nicht so, also die
haben wir abgedreht und nachher wieder aufgedreht und es war fertig. Nein, sonst hätten wir
das auch vorher mit dem Testsystem durchgespielt, natürlich, ich mein auf das lass ich mich
nicht ein.
77 Interviewer: Herstellerunterstützung
78 Interviewter I: Die Herstellerunterstützung ist nicht schlecht, wenn man sie hat, aber so
richtig herausragend wichtig, war sie in diesem Fall eigentlich nicht.
79 Interviewer: Post-Implementation-Evaluation
80 Interviewter I: Ja natürlich muss ich nachher evaluieren. Wie schaut die Zufriedenheit aus?
Wie schaut es mit meinen erwarteten funktionalen Erweiterungen aus? Das ist wichtig, aber
ich kann eh nicht mehr zurück. Also ein Downgrade, letztendlich ist das für mich was, wo
ich sage, wenn ich vorher in der Planung alles richtig gemacht habe, dann schaue ich zwar
nach, ob das wirklich geht und ob ich meine persönliche Erwartungshaltung, weil über das
haben wir vorher diskutiert, ob ich die erfüllen kann oder auch die, die der Hersteller in mir
berechtigt erzeugt hat, erfüllen kann. Aber alles andere, ist, ja, ich muss natürlich schauen
wie geht es den Leuten damit.
81 Interviewer: Was ich zu diesem Punkt noch gerne dazu fragen würden, haben Sie auch so
eine Art LessonsLearned nach dem Projekt gemacht, für eventuell zukünftige Projekte?
82 Interviewter I: Ja haben wir gemacht. Wobei, ob wir mit dem, was wir da aufgeschrieben
haben und notiert haben, dann wirklich was anfangen im nächsten Fall, weiß ich nicht, aber
man kann zumindest schauen und sagen, ah, in diese Kommunikationsfalle zum Beispiel
tappe ich nicht mehr, weiß ich, aber nachdem sich die handelnden Personen dann meistens
schon geändert haben, weil da ändert sich im Management was, da ändert sich in der
Teamzusammensetzung was, könnte man es wahrscheinlich eh nicht. Aber man lest es sich
einmal durch und denkt drüber nach und denkt sich, ahh, wie könnt ich das jetzt ummünzen.
Ja haben wir auch gemacht. Und ja ist wichtig, aber die Frage ist wieviel bringt es wirklich.
Also da weis ich nicht, ob sich Aufwand und Nutzen in einem sinnvollen Verhältnis
verhalten, aber ja, man macht es. Aber das hängt auch davon ab, wie oft man ein Upgrade
macht. Je häufiger man es macht, desto wichtiger ist das, weil man dann auch wirklich noch
davon profitieren kann.
83 Interviewer: Perfekt, somit sind wir am Ende. Danke für das Interview
84 Interviewter I: Gerne

173
 C.10 Transcript Interview J
1 Interviewer: Könnten Sie bitte einen kurzen Überblick über Ihre Person, Ihren
Aufgabenbereich geben und erklären inwieweit Sie mit ERP Upgrades zu tun haben?
2 Interviewter J: Mein Name ist XYZ, ich bin der Bereichsleiter IT & Organisation bei der Fa.
XYZ. Was habe ich damit zu tun? Wir, bei der Fa. XYZ haben ein sehr großes ERP System,
SAP seit 1993, haben jetzt vor einigen Monaten sind wir jetzt auf SAP Hana umgestiegen,
ahm und ich hab in meinem Leben vor Capgemini 14 ERP Implementierungen als
Projektleiter geleitet oder als IT Leiter geleitet. Also ich hab das schon ein paar mal gemacht
und daher schon ein bisschen Erfahrung.
3 Interviewer: In welchem Umfang hat sich das Upgrade Projekt bei Ihnen abgespielt, wie
lange hat da ca. gedauert?
4 Interviewter J: Ja das, wobei man dazusagen muss, hier ist jetzt ein reines technisches
Upgrade gewesen, du kennst ja die verschiedenen Layer, auf der Applikationsebene haben
wir noch relativ wenig getan noch, warum, weil wir davon ausgehen, dass hier ein Upgrade
auf die Applikation S4, das ist quasi der Nachfolger von R3, dass wir jetzt haben,
schätzomativ 4 bis 6 Jahre kosten würde und doch einen deutlichen zweistelligen Euro
Millionen Betrag und das heißt ohne, dass wir jetzt wirtschaftliche Vorteile haben durch die
Applikation, weil wir in den vergangenen Jahren die Applikation so an unsere Bedürfnisse
angepasst haben, dass die eigentlich alles das oder schon viel mehr kann, als die neue
Version von der SAP. Das heißt aber, technologisch muss man mit der Zeit gehen, wir
haben am Datenbanklayer, haben wir, müssen natürlich nicht, aber wir haben natürlich
Veränderungen gehabt, im ERP Umfeld ist es ja üblicherweise so, dass der gesamte Stack,
also das heißt von der Hardware die du nimmst, über das Betriebssystem, über Datenbank-
Layer zum ERP System dazu passen muss. Ahm, das kann man nicht, wir haben zwar
immer versucht datenbankagnostisch zu programmieren, das heißt datenbankunabhängig zu
sein in unseren Applikationen, damit man die Datenbank darunter wechseln können, aber
jetzt mit neuen Technologien, der In-Memory Spaltentechnologie und nicht mehr
Tabellentechnologie, die wir jetzt haben, muss man mit der Zeit gehen eigentlich, weil das
die Zukunft ist eigentlich. Und das war jetzt einmal der erste Schritt, und jetzt müssen wir
uns überlegen wie die Applikationen in den nächsten Jahren upgegradet werden, aber du
weist vielleicht im ERP Umfeld bin ich ja revisionssicher unterwegs, das heißt ich kann
nicht so einfach eine neue Version einführen ohne die Altwelt, die Aufbewahrungsfristen,
die gesetzlichen, aufzubehalten, also aufzuzeichnen. Und das macht das ganze so spannend,
weil wir sind ja in über 40 Länder vertreten, mit 40 unterschiedlichen Steuergesetzen, mit
unterschiedlichen Kostenrechnungskreisen, Buchhaltungsvorschriften etc. etc. Das heißt, das
macht es nicht so einfach. Ich glaub das beantwortet dann diese Frage.
5 Interviewer: Und wie lange hat das Projekt dann gedauert?
6 Interviewter J:ahh, 1,5 Jahre und inkl. aller Voranalysen rund 800 bis 1000
Personenstunden.
7 Interviewer: Was waren die Hauptgründe, warum das Upgrade durchgeführt worden ist?
8 Interviewter J: Aus technologischer, mit der Zeit gehen.
9 Interviewer: Ok, und die Hauptziele die definiert wurden für das Projekt?
10 Interviewter J: Dass die Performance nicht schlechter ist, als die die wir vorher hatten und
dass wir wieder alle Applikationen innerhalb des ERP sauber zum laufen bringen, weil
durch die Spaltentechnologie, In-Memory-Technologie, werden alle Objekte die nicht
Standard-SAP sind, was bei uns sehr viele sind auf Views, Table-Views umgestellt von SAP
selber, und dann muss man in den Applikationen, wir haben ca. 5,5 Millionen Zeilen
Eigencode im System drinnen, die muss man alle durchforsten, ob die dann in der neuen
Technologie wieder so funktionieren. Das Ziel war simpel.
11 Interviewer: Somit sind wir eh schon beim Hauptthema. Was sind deiner Meinung nach, die
wichtigsten Themen, die wichtigsten Punkte die notwendig sind um so ein Projekt
durchzuführen?
12 Interviewter J: Erstens der Projektleiter, Zweitens der Projektleiter und Drittens der
Projektleiter. Ahm, nein Spaß ohne. Ich glaube, dass die Projektleitung ganz ein

174
 wesentlicher Erfolgsfaktor ist, ich erwarte mir von einem Projektleiter nicht nur, dass dieser
mit Kollegen spricht, Meilensteine einfordert, sondern der muss zu jeder Tages- und
Nachtzeit, muss ich den aufwecken können und der muss wissen wo jedes einzelne
Arbeitspaket steht und muss auch die Dinge kompensieren, die unterhalb der Arbeitspaket-
Teilprojektleiterebene nicht funktionieren. Wenn Leute nicht rechtzeitig miteinander reden,
ein ERP System hat sehr viele Prozesse in einem Unternehmen, deckt bei uns von dem
kaufmännischen Bereich, Buchhaltung, Kostenrechnung, Controlling, bis hin zur Produktion
weltweit, über Vertrieb, Marketingaktivitäten alles ab. Das heißt, dass sind tausende von
Prozessen, hunderte von Geschäftsfällen und das ist ganz natürlich, dass man manchmal,
unterschiedliche Auffassungen haben, nicht, Controller verfolgen andere Ziele als
Vertriebler, Vertriebler wollen viel Freiheit haben, Controller wollen alles kontrollieren.
Liegt in der Natur des Menschen. Und hier für einen Ausgleich zu sorgen, ist eigentlich,
dass um und auf, damit die Prozesse am Ende des Tages wieder nahtlos ineinandergreifen.
Das klingt jetzt banal, ist aber meiner Erfahrung, dass aller schwierigste in so einem Projekt
und auch der Hauptgrund, warum 70% aller ERP-Implementierungen eigentlich scheitern.
Der zweite Grund ist letzten Endes, dass man von der Geschäftsführung die Freiheit und die
finanzielle Unterstützung bekommt, weil diese Prozesse üblicherweise sehr detailliert sind.
Also, ich sage immer gerne, jeder Button der da drinnen ist, das List-of-Value-Feld, da muss
ich ja definieren, was passiert, wenn das danach ausgewählt wird. Das heißt man ist da
wirklich im Mikro-Management drinnen und das fällt vielen Leuten sehr schwer Prozesse zu
beschreiben und hier ist die Erfahrung von erfahrenen Beratern, die hier unterstützen können
bzw. die richtige Auswahl des Teams, das ist meiner Meinung nach der drittwichtigste
Punkt, das Entscheidende. Und ich habe mir in meinen ganzen Implementierungen zu eigen
gemacht, dass die Teammitglieder keine Führungskräfte sein dürfen. Das heißt, erstens
wenn du an einem Tisch bei einem Workshop sitzt, wo du 10 Leute drinnen hast und 2
davon sind Führungskräfte, kannst du sicher sein, dass die anderen Mitarbeiter manchmal
nicht die Wahrheit sagen, weil die gar nicht wollen, dass ihr Chef weiß, was da wirklich
alles läuft. Aber das System muss wissen, was da wirklich läuft. Das ist ein Hauptthema,
zweites Hauptthema ist, du musst etwas eskalieren können, das heißt, arbeitet ein
Teammitglied nicht ordentlich mit, musst du zu seinem Chef gehen können um zu sagen, der
muss sich mehr reinhängen. Wenn jetzt schon der Chef drinnen sitzt, wird schwierig. Das
sind so meiner Meinung nach, die 3 wichtigsten Erfolgskriterien. Der Projektleiter, das
Projektteam und letztendlich auch die finanzielle Freiheit oder die finanzielle
Leistungsfähigkeit, diese Dinge auch wirklich durchzuführen, weil ich habe kein ERP
Implementierungsprojekt erlebt, dass nicht, ich sag jetzt mal frech, doppelt soviel gekostet
hat, als man ursprünglich mal, also sich die Geschäftsführung, die das wollte, gedacht hat.
Das ist so.
13 Interviewer: Habt ihr externes Consulting auch dabei gehabt bzw. würdest du sagen, dass
das auch ein wichtiger Faktor ist?
14 Interviewter J: Also die Erfahrung lehrt, dass es ohne externe Berater nicht geht, warum,
weil üblicherweise in Unternehmen nicht Menschen herumsitzen, die den ganzen Tag nichts
zu tun haben nur drauf warten, dass man so ein riesiges Projekt stemmt. Also meine ERP
Implementierungen haben immer, mehrere tausend oder mehrere zehntausend Personentage
Aufwand gehabt. Und, ahm, kein Unternehmen hat heute noch den Speck, sich solche
Ressourcen zu leisten, die permanent da sind, aber nicht ausgelastet sind, das heißt, das
große Problem ist immer, dass du eigentlich während des laufenden Geschäftes des
Unternehmens praktisch die Prozesse oder die Systeme umdrehen musst. Das heißt, du
musst Menschen aus dem Tagesgeschäft rausreißen, dass sie Prozesse designen, musst
aufpassen, dass dir die nicht over-engineeren oder sich das reinwünschen, was immer sie
schon gerne gehabt hätten, aber nie funktioniert hat, bei den alten Systemen, ahm, und das
Doing machen dann Externe, normalerweise, weil du, teilweise oder ganz Externe, weil du
einfach die Manpower brauchst und das geht von externen Beratern aber bis hin zu
Studenten, in fast allen meinen Projekten, war es so, dass wir dann Studenten oder so irgend

175
 etwas, Berufspraktikanten, engagiert haben, die zum Beispiel Datenbereinigung machen, du
hast ja auch immer, ein Erfolgskriterium vielleicht, das vierte, ist die Datenbereinigung im
Altsystem zu machen. Also weil sonst hast du immer das Motto Shit-In, Shit-Out, ja, also
wenn du im alten System einen Scheiß drinnen hast, dann hast auch im neuen System einen
Scheiß drinnen. Und Datenbereinigung, Salden abschließen, von offenen Positionen, die
schon Jahre mitgeschleppt werden, inaktive, falsche Lieferanten, Ansprechpartner,
Materialien die man vielleicht nicht mehr braucht. Man muss natürlich immer ein bisschen
aufpassen, dass du die Historie, für buchungs- oder steuerrelevante Themen mitnimmst, ja,
und, das kann nur entweder in Massenverarbeitung gemacht werden, wo die Menschen die
sich auskennen, das bereinigen oder diese Menschen, dann Arbeitskräfte anweisen. Also
ohne externe Hilfe wird es meiner Meinung nach in keinem Unternehmen gehen.
15 Interviewer: Habt ihr jetzt bei dem Upgrade auch Prozesse verändert?
16 Interviewter J: Wenig, sehr wenig, weil es war ein technisches Upgrade, das heißt die
Prozesse sollten gleich bleiben, wir haben Prozesse dort verändert, wo es auch technischen
Gründen notwendig war, aber das ist vernachlässigbar, in dem Projekt jetzt. In anderen
Projekten haben wir sehr viele, also ich hab die ganze Bandbreite erlebt, von gar nichts
verändern, über viel zu viel verändern.
17 Interviewer: Kann ein zu starkes "Customizing" zu Problemen bei späteren Upgrades
führen?
18 Interviewter J: Ja definitiv
19 Interviewer: Kann man sagen, dass ein eher nahe am Standard bleiben sozusagen vielleicht
ein Erfolgsfaktor sein kann?
20 Interviewter J: Für eine, ja das ist ein zweischneidiges Schwert, für eine Implementierung ist
es natürlich besser, je mehr man am Systemstandard bleibt. Die Realität zeigt aber, dass
zwei Dinge eintreten, wenn man im Standard bleibt. Erstens, tritt ein, dass ein Unternehmen
sehr sehr viel manuell machen muss, weil die meisten Standardprozesse sehr manuell sind.
In fast jedem System, wenn du Dinge automatisieren möchtest, Buchungen automatisiert
durchbuchen möchtest, etc. musst du eingreifen ins System. Obwohl Standard muss man
auch ein bisschen ausholen. Also gerade jetzt in SAP gibt es 3 Levels von Standards. Es gibt
einmal wirklich den absoluten Auslieferungszustand, da kannst du in einem neuen
Unternehmen, hast einen Standardkontenplan etc. alles drinnen, dann musst du den aber
customizen, weil zB die Kontonummer im Standard in deinem Unternehmen anders ist für
zB Materialverbrauch, keine Ahnung. Da tust du nur Stammdaten verändern, dann musst du
Prozesse einstellen ohne allerdings im System was zu programmieren. Und da gibt es in den
meisten ERP Systemen verschiedene Möglichkeiten wie man einen Vertriebsprozess
gestaltet, einen Buchhaltungsprozess gestaltet. Zum Beispiel hat ja ein Handelsunternehmen
andere Abläufe als eine Industrieunternehmen wie wir. Auch das kann ich noch im Standard
machen, aber ich muss das System verändern, konfigurieren. Der nächste Level ist, dass du
sogenannte User-Exits benützt. Definierte Bereiche wo du ausbrichst, wo du ausbrichst aus
der normalen Logik, dir selber ein Programm schreibst, das berechnet zB irgendwas und
schreibt dir den Wert dann zurück, die der Hersteller zulässt. Bis zu diesem Level hast du
eigentlich kein Problem im Upgrade, weil das sind definierte Schnittstellen wo der
Hersteller zulässt, dass ein anderes System andockt, dass du irgendwas modifizierst. Und
dann beginnen zwei Level wo du nicht mehr im Standard bist, du bist zwar beim dritten
auch nicht mehr im Standard, aber da ist kein Problem. Der vierte Level ist dann, dass du
echt was dazuprogrammierst, was sozusagen eine Tabelle nicht im Standard veränderst,
sondern daneben eine andere Tabelle stellst und nur diese verwendest. Das nennt man beim
SAP die Z-Welt üblicherweise, gibt auch Unternehmen die haben die Y-Welt, aber meistens
heißt das Z-Welt. Da wird das umgesetzt, was sozusagen ein ERP System einfach nicht
hergibt. Du aber als Prozess trotzdem brauchst, und wenn du es nicht schaffst die
Organisation zu überzeugen im Standard zu bleiben, musst du das programmieren. Das ist
sozusagen immer zu prüfen bei einem Upgrade, aber eigentlich auch noch nicht das ganz
große Problem, wenn du nur die Schnittstellen kontrollieren musst. Wirklich haarig wird es,

176
 wenn du in den Source Code eingreifst, und, im SAP nennt man das Modifikation, machst
und wirklich den Source Code veränderst des Programms. Davon ist eher abzuraten, es gibt
aber viele Unternehmen, die das machen und da hast du dann bei einem Upgrade-Projekt ein
brutales Problem. Weil du musst wirklich, du weist nicht was der Hersteller im nächsten
Release dann mit der Funktion gemacht hast, die du verändert hast. Plus du bist
möglicherweise, begibst du dich in gesetzlich schwierige Situationen, weil du könntest
theoretisch, ein ERP System ist ja revisionssicher, das heißt es ist von den Steuerbehörden
anerkannt. Und wenn du da dann eine Modifikation reinmachst, kann es sein, dass dir der
Wirtschaftsprüfer die Bilanz verweigert, oder dass die Steuerbehörden kommen und der
Steuerprüfer und sagen, du hast Steuer hinterzogen, also das kann richtig haarig werden,
wenn du das an den falschen Stellen machst. Und deswegen ist von dem eigentlich
abzuraten, es gibt aber sehr viele Unternehmen die das machen.
21 Interviewer: Anhand welchen Merkmalen, kann man so ein Projekt als erfolgreich
bezeichnen? Ist das eine reine Kosten, Zeit, Funktionsthematik?
22 Interviewter J: Ich sag dirs, es gibt kein erfolgreiches Implementierungsprojekt, wo alle
zufrieden sind, das ist meiner Meinung nach denkunmöglich. Es gibt immer, in jedem
Prozess Gewinner, Verlierer, Eigeninteressen von Abteilungen, etc. Das liegt in der Natur
des Menschen. Ich glaube es ist erfolgreich, wenn du halbwegs in der Zeit geblieben bist
und wenn das Unternehmen danach funktioniert. Dann bist du erfolgreich gewesen. Ganz
banal, wenn du danach nur ein halbes Jahr Nacharbeiten hast, dann bist erfolgreich gewesen.
Man muss sich verabschieden von dem Gedanken, dass man da alles umgesetzt bekommt.
Stell dir vor, XYZ hat jetzt knapp 6000 Mitarbeiter, und ich muss für 6000 Mitarbeiter alle
Prozesse neu machen, allen Menschen das beibringe, alle Menschen schulen mit dem neuen
System, mit neuen Masken. SAP hat 22.000 Transaktionen, davon wird ein Unternehmen
wie XYZ ca. 9000 - 10000 brauchen in den verschiedenen Bereichen. Das muss man alles
schulen, wenn man vorher kein SAP gehabt haben, wir müssen wir nachher mit dem System
arbeiten können und das heißt üblicherweise, ist das zuviel und das bedeutet, man macht das
dann irgendwann im Laufe des Projektes entscheidet man sich, das lassen wir weg, das
lassen wir weg und das lassen wir weg und das tut man dann nachher dranhängen. Und
wenn das Unternehmen trotzdem funktioniert, dann war es ein Erfolg. Ich hab schon andere
Beispiele auch erlebt, wo das Unternehmen schwer zu kämpfen hatte.
23 Interviewer: Wieviel Anwender sind bei euch in eurem SAP-System? Hat jeder Mitarbeiter
einen User?
24 Interviewter J: Nein, das wär viel zu teuer. Also in den verschiedensten Modulen arbeiten
de-facto alle, vom Unternehmen irgendwo drinnen. Also wir haben über 5000 User. Aber
nicht jeder benützt alles, nicht jeder hat die Lizenz für alles, und da muss man auch ein
bisschen kreativ sein, was die Lizenzmodelle der Anbieter so hergeben.
25 Interviewer: Somit sind wir eh schon beim letzten Teil. Ich würde gerne herausfinden, was
so die größten Unterschiede sind, hinsichtlich Erfolgsfaktoren, zwischen einem klassischen
Implementierungsprojekt und Upgrade-Projekt?
26 Interviewter J: Nun ja, ein Upgrade-Projekt ist normalerweise immer leichter, weil ich von
der selben Software auf eine andere Software des selben Hersteller upgradest, tust dir
meiner Meinung nach viel leichter, weil die User kennen die Masken möglicherweise, die
Grundlogik ändert sich nicht so wahnsinnig viel, dass du wirklich alle schulen musst und du
hast sozusagen ein Zehntel des Aufwands weil du upgradest. Wenn du ein
Implementierungsprojekt machst, heißt das üblicherweise du veränderst die Technologie,
und das heißt allen Menschen im Unternehmen wo du das tust, das auch beibringen. Und die
Technologie an die Prozesse des Unternehmens anpassen und das ist natürlich ungleich
aufwendiger, als wenn ich in einem Bestandsunternehmen so wieXYZ sage, jetzt tun wir
System upgraden, dann hast du vielleicht 5 neue Masken, 3 neue Felder, musst 300 User
schulen, statt 5000 und das ist natürlich eine ganz andere Hausnummer.
27 Interviewer: In der Literatur werden folgenden Faktoren für den Erfolg eines
Implementierungsprojektes genannt:

177
28 Bitte beurteilen Sie die Wichtigkeit dieser für den Erfolg bei Upgrade-Projekten anhand der
Skala (sehr wichtig, wichtig, weniger wichtig, gar nicht wichtig)?
29 Interviewer: Top Management Unterstützung
30 Interviewter J: sehr wichtig
31 Interviewer: Change Management
32 Interviewter J: mittel wichtig, wenn es ein Upgrade Projekt ist
33 Interviewer: Business Plan & Vision
34 Interviewter J: beim Upgrade Projekt gar nicht wichtig
35 Interviewer: Projektmanagement
36 Interviewter J:ultra wichtig
37 Interviewer: BPR & Customization
38 Interviewter J: ist zu vermeiden beim Upgrade Projekt, gibt es zwar nicht auf deiner Liste,
ist aber meiner Meinung nach zu vermeiden
39 Interviewer: ERP Team Zusammensetzung
40 Interviewter J: wichtig, sehr wichtig
41 Interviewer: Software Testing
42 Interviewter J:ultra wichtig
43 nterviewer: User Training & Schulung
44 Interviewter J: weniger wichtig
45 Interviewer: Business Case
46 Interviewter J: weniger wichtig
47 Interviewer: Projektchampion
48 Interviewter J: weniger wichtig
49 Interviewer: Kommunikation
50 Interviewter J: sehr wichtig
51 Interviewer: Management von Legacy Systemen
52 Interviewter J: sehr wichtig, weil die werden upgegradet
53 Interviewer: Hersteller Unterstützung
54 Interviewter J:sehr wichtig
55 Interviewer: Post-Implementation Evaluierung & Lessons Learned
56 Interviewter J: Meiner Meinung nach sehr wichtig, wird aber viel zu wenig gemacht, in den
Unternehmen

178
 C.11 Transcript Interview K
1 Interviewer: Könnten Sie bitte einen kurzen Überblick über Ihre Person und Ihren
Aufgabenbereich geben bzw. erläutern in wieweit Sie mit dem Thema ERP-Upgrade zu tun
haben?
2 Interviewter K: Ja ok, ich gebe Ihnen einen kurzen Überblick, also mein Name ist XYZ, bin
seit 7 Jahren Consultant im SAP Bereich, unser Unternehmen sozusagen, da muss man ein
bisschen das SAP Umfeld erklären, also wir sind im SAP ERP Umfeld tätig, ahhmm, das
SAP ist ein weites Feld und wir haben uns im Moment quasi auf zwei bis drei Komponenten
in dieser SAP Welt spezialisiert. Es gibt sozusagen, ich weis nicht wie weit Sie im SAP
Umfeld vertraut sind, es gibt sozusagen diese sogenannte "Hybris Billing Kette", ahh, auch
bekannt unter BRIM, das ist quasi eine Abrechnungskette die vom SAP in der
Standardauslieferung verkauft wird, die besteht einmal aus einem CRM System, SAP CRM
System, aus dem sogenannten SAP ConvergentCharging für die Abrechnung aus dem SAP
FI/CO für die Massenkontenbuchhaltung aus dem SAP CI, das ist ConvergentInvoicing,
wenn man quasi aus unterschiedlichen Abrechnungssystemen gemeinsame Rechnungen
erzeugen will, und dann gibts noch hinten raus, das sogenannte Core SAP, oder SAP ERP,
wo halt das SAP FI, CO, SD, MM usw. quasi abgebildet sind, also quasi mal ein
Gesamtkonstrukt das von der SAP ausgeliefert wird. Wir haben uns jetzt im Moment auf die
Komponenten SAP CI und SAP FI -CA spezialisiert, die hängen sozusagen systemtechnisch
am SAP System, sind eben aber vorgelagert, dort werden unterschiedliche Buchungen,
Zahlungsverkehr usw. abgebildet und wir buchen dann quasi aus unseren Komponenten, die
wir betreuen, buchen dann quasi in das klassische SAP ERP, SAP FI. Das heißt wir sind
jetzt keine klassischen Implementierer von ERP Projekten, sondern wir sind eben eine Stufe
vorausgelagert und bilden quasi diese Prozesse ab. Wir sind sozusagen in diesen
Vorsystemen, die diese Daten aufbereiten und dann halt in diese klassische ERP umbuchen.
Was bei uns ist, die Projekte sind vom Umfang her vergleichbar, oft ist es auch so, dass
ERP, SAP ERP eingeführt wird und unsere Module, die wir betreuen mit eingeführt werden.
Die Problemstellungen sind letztendlich ähnlich wie, sozusagen, ob es jetzt SAP FI-CA, das
wir einführen, oder SAP ERP FI einführst, die Problemstellungen sind im Prinzip ähnlich,
das heißt ich denk mir, dass das was ich Ihnen erzähle gilt letztendlich für das ERP auch.
Sozusagen zum Start.
3 Interviewer: In welchem Umfang findet ein klassisches Projekt bei Ihnen statt? Das heißt
wie lange dauert das ca.?
4 Interviewter K: Was genau verstehen Sie unter ERP-Upgrade? Also was wir unter Upgrade
verstehen ist, sozusagen, wenn das SAP System eingeführt ist, das gibts ja Lebenszyklen,
das heißt alle ein bis zwei Jahre gibts da größere sozusagen Neuigkeiten von der SAP, die
halt quasi, dann eingespielt werden und das nennen wir ein Upgrade.
5 Interviewer: Das ist auch meine Definition. Ich spreche jetzt nicht von einer klassischen
Einführung, sondern wie gesagt, das System sollte grundsätzliche eingeführt sein und es
wird eine neue Version installiert.
6 Interviewter K: Ja das ist eigentlich relativ harmlos würd ich sagen, ich mein, das hängt ein
bisschen vom Kunden ab, wie aufwendig das ist, wie vorsichtig der Kunde ist und wenn er
vorsichtiger ist, dann dauert es ein bisschen länger, wenn er ein bisschen risikofreudiger ist,
dann geht es ein bisschen schneller. Prinzipiell muss man sagen, sind die, dann hängt es
noch zusätzlich davon ab, also zumindest in unserem Modul ist es so, dass die SAP liefert
also neue Business Functions aus, und Updates zu bestehenden Functions, dann kann man
sich entscheiden, was möchte ich den überhaupt quasi aktivieren, was möchte ich nützen,
möchte ich neue Business Functions im Zuge des Upgrades implementieren oder möchte ich
einfach die bestehenden auf den neuesten Stand bringen, also, der Aufwand hängt halt stark
davon ab, in den meisten Fällen, bleibts eigentlich dabei, dass nur relativ wenig bei den
Upgrade-Projekten neu eingeführt wird. Das wird meist geschaut, dass das was besteht, wird
halt auf die neueste Version gehoben, aber die Kunden, ahh, aktivieren im Zuge des
Upgrade Projektes sozusagen, selten zusätzliche Business Functions, das passiert dann eher
hinten raus, wenn sie sehen, aha, jetzt habe ich theoretisch die Möglichkeit neue Functions

179
 einzusetzen und dann kommt quasi die Implementierung oder Aktivierung zu einem
späteren Zeitpunkt, das heißt, wenn man jetzt einmal sagen, OK, reines Upgrade Projekt,
zumindest in unserem Bereich, FI-CA, CI, was wir betreuen, ist relativ unspektakulär, wird
halt alle zwei Jahre ungefähr mal gemacht und dann ist man wahrscheinlich, dann ist das ein
Projekt aus unserer Sicht in eher kleinen Dimensionen, das heißt, es ist vielleicht von 3 bis
ca. 6 Monaten.
7 Interviewer: Wo sehen Sie die Hauptgründe, warum Upgrades durchgeführt werden?
8 Interviewter K: Ja es ist letztendlich in der Softwarebranche so, man muss letztendlich
immer nachziehen, weil im SAP Bereich, die SAP sozusagen, auch ihre Wartung
letztendlich dann auslaufen lässt, das heißt wenn man nie upgradet, passierts, dass man den
Wartungsvertrag verliert und die SAP sagt, OK, eure Software ist zu alt und wir warten sie
nicht mehr oder man muss einen zusätzlichen Vertrag dann abschließen oder man hat einen
Premium Wartungsvertrag, dann wird es nochmal verlängert, aber wie gesagt, der erste
Grund ist, es könnte theoretisch der Wartungsvertrag auslaufen, zusätzlich, man möchte halt
trotzdem schauen, dass die Business Functions sozusagen verfügbar sind, dass man sie dann
jederzeit aktivieren kann, wenn von der Fachseite die Anforderung kommt, OK, wir hätten
jetzt gerne etwas neues und wenn das im Upgrade schon verfügbar ist, dann braucht man das
nicht mehr selber entwickeln, und sozusagen, dass man immer mitzieht, mit den
Entwicklungen und Auslieferungen der SAP.
9 Interviewer: Die nächste Frage beschäftigt sich mit den Zielen. Was sind die grundsätzlichen
Ziele die für so ein Upgrade Projekt definiert werden?
10 Interviewter K: Die Ziele, ja, das Hauptziel ist die Software auf eine höhere Version zu
heben und die stabil produktiv zu stellen letztendlich. Das ist das Hauptziel, zumindest in
unserem Bereich ist es so, wir sind quasi in einem Massendatensystem unterwegs, das heißt
wir machen die ganzen Abrechnungen, Zahlungsverkehr für Kunden mit sehr vielen
Endkunden, wir sind also im Telekommunikationsbereich, im Versicherungsbereich
unterwegs und Medienbereich, also wo sehr viele Endkunden sind. Das heißt, jeder Fehler
der in unserem System passiert kann sozusagen Millionen, bei Millionen Kunden
aufschlagen, wenn wir Rechnungen rausschicken die falsch sind, betrifft das nicht 20
Kunden sondern im Millionenbereich, das können bis zu 20 bis 30 Millionen Kunden sein,
oder wenn wir Mahnung verschicken und wir Kunden falsch mahnen, dann sind nicht 10
große Lieferanten betroffen, die man eventuell sozusagen händisch anruft und sagt, da ist ein
Fehler passiert, sondern dann sinds halt 500.000 Kunden die betroffen sind. Das heißt in
unserem Bereich, ist das wichtigste, Sicherheit, Stabilität und Fehlerfreiheit, ja, und dass
man die Dinge, die man an der Software ändert sozusagen, so ausliefert an die Produktion,
dass halt kein Schaden entsteht, weil der hat sich durch die Anzahl der Kunden, die
sozusagen da betroffen sind, sich multipliziert oder potenziert.
11 Interviewer: Somit komme ich eh schon zu meinem Hauptthema. Welche Faktoren sind
Ihrer Meinung nach kritisch für den Erfolg eines Upgrade Projektes?
12 Interviewter K: Genau, Upgrade aus meiner Sicht, wie ich schon gesagt habe, ist relativ
simpel in unserem Bereich, bei uns sind die Einführungsprojekte die Großprojekte, die
zwischen 3 und 5 Jahren oder so dauern, aber die Upgrade Projekte, nachdem die Software
von SAP sehr stabil ausgeliefert wird, sind unkritisch, relativ unkritisch, zumindest aus
Beraterseite. Wir sind also die Berater und die Implementierer an der Stelle. Kritisch ist aus
meiner Sicht, wenn man jetzt ein reines Upgrade-Projekt hernimmt, dass man eine starke
Qualitätssicherung hat, das heißt, dass die Qualitätssicherungsabteilung, ob die jetzt extern
oder intern ist, letztendlich die Prozesse kennt, weiß was sie testen soll, was funktioniert hat,
also wie haben die Prozesse vorher ausgeschaut, funktionieren die Prozesse sozusagen nach
dem Upgrade gleich, wie vor dem Upgrade. Also für mich das Kernthema das erfolgreich
ist, ist wie gesagt, eine starke Qualitätssicherung, ja.
13 Interviewer: Nachdem sie jetzt auf der Beraterseite sind, werden Sie die kommende Frage
vermutlich mit ja beantworten aber sehen Sie externe Beratung auch als einen Erfolgsfaktor
in diesen Umfeld? Oder ist dies nicht immer zu 100%notwendig?

180
14 Interviewter K: Ich würd sagen, genau, bei uns prinzipiell, also nochmal zurück auf unser
Thema Massendaten, Massenkunden ist sozusagen die Qualität der Berater extrem wichtig,
wir müssen quasi fehlerfrei arbeiten, wir müssen wissen was wir tun, wir müssen eben im
Vorfeld schon Fehler vermeiden, wir müssen wissen wenn wir am System was ändern wir,
was kann das für Konsequenzen haben, was kann das für Risiken haben, die dann quasi auch
beim Kunden aufzeigen. Prinzipiell ja, also in unserem Bereich, jeder Fehler kann große
Auswirkungen haben, deshalb ist es natürlich immer wichtig, dass man vernünftige Berater
hat, gilt natürlich auch für das ERP Upgrade Projekt, aber die Beratungskompetenz ist
wichtiger, wenn man wirklich Änderungen am System vornimmt, sprich, ahhm, man führt
neue Funktionalitäten ein oder man so eine Grundeinführung dieser Produkte, im Release
Upgrade sehe ich es jetzt nicht so als kritischen Faktor. Es ist eher im Change Management,
wenn man Funktionalitäten neu implementiert, dass die halt richtig implementiert werden,
aber nicht so im Upgrade Projekt. Da würde ich sozusagen, die Qualitätssicherung, weil
letztendlich im Upgrade-Projekt, was will man sicher stellen, dass die die neue Software so
funktioniert, wie die alte Software. Wenn man eine gute Qualitätssicherung hat, die die
Prozesse kennt, und weiß was rauskommt, ist das wichtiger, dass die sagen, hoppala da gibts
ein Delta zum Prozess vor dem Upgrade, ist das so gewünscht oder ist das ein Fehler? Also,
sehe ich wie gesagt, Qualitätssicherung wichtiger also die Beratung in dem Spezialfall,
würde ich mal sagen.
15 Interviewer: Haben Sie vielleicht ein Beispiel eines Upgrade-Projektes wo gröbere Probleme
aufgetreten sind bzw. wenn ja, wie man dann diesen Problemen entgegengetreten ist?
16 Interviewter K: Nein, also in unserem Bereich, wir haben also einige Upgrades gemacht, das
waren immer von den Projekten her, eher die harmloseren, waren wir nie dabei, wo wir
gesagt haben, ok, das hat jetzt wirklich Probleme verursacht, nein, kann ich jetzt gar nicht
sagen, sind alle immer reibungslos verlaufen.
17 Interviewer: OK, perfekt. Anhand von welchen Merkmalen würden Sie ein Projekt als
erfolgreich definieren?
18 Interviewter K: Aus meiner Sicht, also würde man jetzt zusätzliche Business Functions
sozusagen aktivieren, wärs eh für mich schon eher ein Change Projekt als ein Upgrade
Projekt, das heißt aus meiner Sicht es soll nachher so funktionieren wie vorher, sprich,
fachlich so sein wie vorher, das heißt das fachliche Ergebnis muss das gleiche sein, oder was
auch immer wichtig darauf zu achten, ist die Performance, gerade in unserem Umfeld, wir
sind Massendaten, wir prozessieren nicht hundert oder nicht 50.000 Zahlungen von Kunden
sondern wir prozessieren halt quasi in dem Zahlenraum 500.000 oder irgend sowas. Und da
ist es halt wichtig, dass die Laufzeiten verträglich sind, weil der Tag hat nur 24 Stunden und
die Dinge müssen schnell raus und die Dinge müssen schnell abgerechnet werden und so
weiter, das heißt man muss, wenn Performance technisch keine Einbußen sind bzw.
vielleicht sogar Verbesserungen weil SAP intern Optimierung sozusagen ausgeliefert hat.
Schlechter sollte die Performance nicht werden und fachlich muss natürlich auch das
richtige rauskommen. Was man natürlich auch bei Upgrade-Projekten nutzen sollte und da
ist man natürlich auch in einer Mischung aus Change- und Upgrade-Projekten, man muss
halt auch beleuchten, wenn sozusagen SAP etwas ausliefert was sie bisher noch gar nicht
gehabt haben, der Kunde aber sozusagen was eigenen gebaut hat, dann sollte man natürlich
die Chance nützen, quasi von diesen kundeneigenen Funktionalitäten auf die
Standardfunktionalitäten umzusteigen und diese dann entsprechend zu nutzen und das wär
dann halt ein zusätzlicher Erfolgsfaktor, mit dem man immer gut punkten kann, wenn man
sagt, OK, wir haben jetzt, weiß ich nicht, 5 kundeneigenen Funktionalitäten im Zuge des
Upgrade-Projektes ablösen können. Also das ist definitiv auch ein Ding, wo man sagen
kann, ja, das ist ein sehr positiver Faktor. Weil Kunden wollen Standardsoftware nutzen
soweit es geht, sagen immer SAP-Standard, SAP-Standard, geht halt in vielen Bereichen
nicht, da braucht man Zusatzentwicklungen, aber wenn man dann sagt, kundeneigenen
Entwicklungen konnten im Zuge des Upgrades, weil jetzt neue Business Functions da sind,
die das abbilden, sollen durch Standardfunktionalitäten ersetzt werden, dann ist das definitiv

181
 auch ein Erfolgsfaktor, oder ein Erfolgsargument, dass man intern gut vermarkten kann.
19 Interviewer: Damit verhindert man ja auch eventuell zukünftige Probleme bei weiteren
Upgrades oder?
20 Interviewter K: Genau, alles was im Standard ist, sozusagen ist stabil, da gibt die SAP die
Garantie darauf, und ja, das ist, das hat halt Vorteile beim nächsten Upgrade wirds leichter,
und wenn irgendwann mal eine Schnittstelle angebunden wird, ist die vielleicht, ist diese
Funktionalität schon vorgesehen, also, und die Prozesse die SAP entwickelt, dann haben die
halt immer im Hinterkopf ihre eigenen Prozesse die sie ausliefern und nicht die
Kundenprozesse, man ist halt quasi weiter im Standard, was halt a la long definitiv ein
Vorteil ist.
21 Interviewer: Meine Arbeit beschäftigt sich auch mit den Unterschieden zu klassischen
Implementierungsprojekten hinsichtlich den Erfolgsfaktoren. Wo würden Sie größten
Unterschiede sehen zwischen einem klassischen Implementierungsprojekt und einem
Upgrade Projekt?
22 Interviewter K: Ja, da gibt es viele viele Unterschiede. Klassisches
Implementierungsprojekt, da gehts schon mal los, die Fachseite, oder der Kunde bekommt
eine neue Software vorgesetzt, er hat halt quasi jahrelange mit einer bestimmten Software
gearbeitet und wenn jetzt ein Implementierungsprojekt ist, bekommt er eine neue Software.
Da beginnt es schon mal. Dann sind die Prozesse, dann gibt es gelebte Prozesse, die sind
noch mit der alten Software, SAP ist ein starkes Modul und sozusagen, kommt daher und
sagt, wir liefern diese und diese Prozesse aus und die funktionieren bei uns so und so, und
wenn ihr quasi die Prozesse, ihr Kunden müsst euch an unsere Prozesse anpassen die wir
ausliefern, sonst müssts halt selber dazu entwickeln, sprich in vielen Bereichen muss der
komplette Prozess umgebaut werden, weil die SAP ja einen groben Prozess hat an dem man
sich orientieren muss, wenn man diese Software einführt, weil sonst macht es keinen Sinn,
dass man die Software einführt, wenn man sagt, mache ich gleich weiter wie bisher, meine
Prozesse sind gleich wie bisher, dann brauche ich kein SAP einführen, wenn ich SAP
einführe, dann muss ich sagen, OK, SAP hat eine Best-Practice Prozessauslieferung, die
man schon sehr variabel gestalten kann aber sozusagen, die grobe Struktur gibt trotzdem die
SAP vor, das heißt, der Kunde, man muss die Kunden einmal überzeugen, hoppala, das wird
alles quasi umgekrempelt, nicht nur die Oberfläche, sondern auch der Prozess der dahinter
liegt. Ja, und dann gibt es natürlich, eine Softwareeinführung, gerade in diesem Umfeld, ahh,
ist wahnsinnig kompliziert, in unserem Umfeld, wir haben meistens Systeme die haben,
weiß ich nicht, zwischen 20 und 100 Schnittstellen zu anderen Systemen, wo Daten
reinkommen und Daten rausgehen, und ja, im Einführungsprojekt muss ich eben zu all
diesen Systemen die Schnittstellen aufbauen, wenn ich dann quasi, das ganze Projekt einmal
eingeführt ist, dann sind die Schnittstellen alle da, und da muss ich maximal schauen,
vielleicht sind ein oder zwei Schnittstellen anzupassen, aber ich habe die ganzen
Einführungen und Diskussionen von Schnittstellen nicht mehr, und wie das ganze Handling
ist. Wie gesagt das ist bei uns 1:1000, würde ich sagen, zwischen einem Einführungs- und
einem Upgrade Projekt und deshalb sind auch die Faktoren komplett unterschiedlich.
Einführungsprojekt ist eine komplett andere Dimension und eine komplett andere Welt.
23 Interviewer: Ich habe mich den Erfolgsfaktoren für Implementierungsprojekten beschäftigt,
anhand der Literatur. Ich habe da jetzt ein paar Punkte notiert, die als die wichtigen
Erfolgsfaktoren genannte werden. Ich würde Sie bitten, dass die diese vielleicht zwischen
sehr wichtig, wichtig, weniger wichtig und gar nicht wichtig ranken im Hinblick auf ein
Upgrade Projekt?
24 Interviewter K:Mhm
25 Interviewer: Top Management Unterstützung
26 Interviewter K: gar nicht wichtig
27 Interviewer: Change Management
28 Interviewter K: wichtig, wenn man neue Business Functions sozusagen aktiviert, also wenn
man sagt, im Zuge des Upgrade Projektes. Aber wenn ich ein reines Upgrade Projekt habe,

182
 wenn ich nur die Software hebe ohne großartig die neuen Funktionen zu nutzen, ist Change
Management auch nicht wichtig, wenn man jedoch sagt, im Zuge dessen möchte ich
vielleicht meinen Prozess ein bisschen umbauen, weil eine neue Funktionalität hinzukommt,
die halt vielleicht auch den Prozess ein wenig ändert. Ja dann ist es wichtig würde ich sagen.
29 Interviewer: Business Plan & Vision
30 Interviewter K: Ja, Business Plan & Vision ist eigentlich schon mit der Einführung
geschehen und bei einem Upgrade ist die Vision auch nicht wirklich wichtig.
31 Interviewer: OK. Projektmanagement
32 Interviewter K: Ja, würde ich schon sagen, dass es wichtig ist, dass man den Zeitplan,
Budget und alles mögliche einhält, würde ich als wichtig bezeichnen.
33 Interviewer: BPR & Customization der Softwarelösung
34 Interviewter K: Ist das wichtig? nein, ja, es hängt immer ein bisschen davon ab, wie es
ausschaut mit neuen Business Functions, ob man die jetzt mitimplementiert oder nicht, wenn
man sagt, ja, man möchte sie aktivieren, dann ist es wichtig, aber sonst ist auch weniger
wichtig.
35 Interviewer: Teamzusammensetzung, quasi hinsichtlich des Projektteams
36 Interviewter K: Ja, das kann man als wichtig bezeichnen
37 Interviewer: Software Testing
38 Interviewter K: Sehr wichtig, das ist wie gesagt, ganz oben
39 Interviewer: User Training & Schulung
40 Interviewter K: Hängt auch wieder davon ab, mit neuen Business Functions ist es wichtig,
sonst ist es unwichtig
41 Interviewer: Business Case
42 Interviewter K: sollte wichtig sein, wird aber selten gemacht
43 Interviewer: Projekt Champion
44 Interviewter K: weniger wichtig
45 Interviewer: Kommunikation
46 Interviewter K: sehr wichtig, innerhalb des ERP-Teams aber auch genauso mit externen
Stakeholdern
47 Interviewer:Management von Legacy Systemen
48 Interviewter K: Nicht wichtig
49 Interviewer: Herstellerunterstützung, in dem Sinne vom Softwarehersteller
50 Interviewter K: Ja, kann man sagen nicht unwichtig, es ist natürlich auch so, es hängt auch
immer davon ab, wie große Sprünge man macht und auf welche Version man bei SAP steigt,
weil SAP ist auch nicht perfekt, und die haben genug Fehler auch in der Software, und dann
würd ich dann gerade beim Release-Upgrade schon als sehr wichtig beurteilen. Das heißt
wenn ein Fehler auftritt bei der Standardsoftware, man kommt selber drauf, durch die eigene
Qualitätssicherung, hoppala, der Prozess läuft ja gar nicht so wie er laufen soll, dass man
auch von SAP entsprechend schnelle Unterstützung bekommt, die den Bug in der
Standardsoftware beheben. Sehr wichtig würde ich sagen
51 Interviewer: Post-Implementierungs-Evaluierung
52 Interviewter K: Kann man als wichtig beurteilen, weil letztendlich kann man
Erfahrungswerte sammeln, sozusagen aus dem einen Upgrade Projekt und in zwei Jahren
kommt dann das nächste und dann kann man sicher Dinge mitnehmen.
53 Interviewer: Perfekt, somit sind schon am Ende. Danke für Ihr Interview

183
 C.12 Transcript Interview L
1 Interviewer: Könnten Sie bitte einen kurzen Überblick über Ihre Person, Ihren
Aufgabenbereich und Ihr Unternehmen geben?
2 Interviewter L: SAP Service Koordinator für Fa. XYZ, ein KMU mit ca. 270 MA. Zuständig
für Modul-Support und Systembetrieb SAP
3 Interviewer: Wann haben Sie ihr letztes ERP Upgrade durchgeführt und wie lange dauerte
dieses Projekt?
4 Interviewter L: Oktober/November 2016, Upgrade von EHP4 auf EHP7, Durchlaufzeit ca.
1,5 Monate
5 Interviewer: Warum wurde das Upgrade durchgeführt?
6 Interviewter L: In den div. SAP Komponenten waren wir schon etliche Jahre in Rückstand.
OS+DB Upgrades standen auch am Plan (Ende Support), auch dazu musst das SAP Release
auf aktuellen Stand gebracht werden.
7 Interviewer: Welche Ziele wurden für Ihr Upgrade-Projekt definiert?
8 Interviewter L: Dokumentation der Tests, Tests mit Fachbereichen + KeyUsern, KEINE
Umstellung ohne Freigabe aller Bereiche, Zielarchitektur: EHP7
9 Interviewer: Welche Faktoren sind Ihrer Meinung nach kritisch für den Erfolg eines ERP
Upgrade Projektes? Warum glauben Sie, dass diese Faktoren ausschlaggebend für den
Erfolg sind?
10 Interviewter L: Kommunikation mit Enduser, vorallem aber mit Fachabteilungen, da diese
für Tests benötigt werden. Tests unabdinglich um einen reibungslosen Betrieb nach Go-Live
sicherstellen zu können.
11 Interviewer: Können Sie diese nach der Wichtigkeit für ihr Projekt priorisieren?
12 Interviewter L: 1. Kommunikation, 2. Test des Upgrades auf identem Testsystem, 3.
Projektmanagement, 4. Einhalten von Terminen
13 Interviewer: Sind während oder nach dem Upgrade-Projekt Probleme aufgetreten? Können
Sie diese Probleme beschreiben? Mit welchen Maßnahmen sind Sie diesen Problemen
entgegengetreten?
14 Interviewter L: Probleme bei Schnittstelle zu Einkaufsmodul am Testsystem. Umstellung
musste daher um 1 Woche verschoben werden, dadurch haben wir uns jedoch viele
Probleme nach Go-Live erspart
15 Interviewer: Anhand welcher Merkmale würden Sie ein Projekt als erfolgreich definieren?
Wie kann man diesen Erfolg messen?
16 Interviewter L: Einhalten von Zeitrahmen + Kostenrahmen, hohe Akzeptanz + Zufriedenheit
der Enduser (Performance-Steigerung, Verfügbarkeit), wenig bis keine betriebs-
einschränkenden Probleme oder Stillstände nach Umstellung.
17 Interviewer: Wo glauben Sie, dass die größten Unterschiede zwischen Erfolgsfaktoren bei
Implementierungsprojekten und denen bei Upgrade-Projekten liegen?
18 Interviewter L: Implementierung benötigt eine sensible Herangehensweise für Schaffung
von User-Akzeptanz. Business Case ist ebenso wichtig. Bei Upgrade gibt es
kleinstmöglichen Beeinflussung des produktiven Betriebs. Es muss nachher immer alles
möglichst so funktionieren wie vorher.
19 Interviewer: In der Literatur werden folgenden Faktoren für den Erfolg eines
Implementierungsprojektes genannt: Bitte beurteilen Sie die Wichtigkeit dieser für den
Erfolg bei Upgrade-Projekten anhand der Skala (sehr wichtig, wichtig, weniger wichtig, gar
nicht wichtig)
20 Interviewer: Top management Unterstützung
21 Interviewter L: sehr wichtig
22 Interviewer: Change management
23 Interviewter L: sehr wichtig
24 Interviewer: Business Plan and Vision
25 Interviewter L: wichtig
26 Interviewer: Projektmanagement
27 Interviewter L: wichtig

184
28 Interviewer: BPR & Anpassung der Software Lösung
29 Interviewter L: wichtig
30 Interviewer: ERP Team Zusammensetzung
31 Interviewter L: wichtig
32 Interviewer: Software Testingand Fehlerbehebung
33 Interviewter L: sehr wichtig
34 Interviewer: User Training and Schulung
35 Interviewter L: wichtig
36 Interviewer: Erstellung eines businesscase
37 Interviewter L: sehr wichtig
38 Interviewer: Auswahl eines Projektchampions
39 Interviewter L: wichtig
40 Interviewer: Kommunikationsplan
41 Interviewter L: sehr wichtig
42 Interviewer: Management von Legacy Systemen
43 Interviewter L: wichtig
44 Interviewer: Hersteller-Unterstützung
45 Interviewter L: sehr wichtig
46 Interviewer: Post-Implementierungs Evaluierung
47 Interviewter L: wichtig

185