Typical problems in the transition from custom software to standard

Leibniz Universität Hannover
Wirtschaftswissenschaftliche Fakultät
Institut für Wirtschaftsinformatik
Typical problems in the transition from custom software
to standard software solutions.
vorgelegt von:
Horst-Oliver Hofmann
Matrikel-Nr.: 2284370
Osterhoop 28
38543 Hillerse
Telefon: 05373/7072
E-mail: [email protected]
Betreuer:
Dipl.-Ök. Marc Klages
Seminarthema:
Standardsoftware
Semester:
Sommersemester 2008
Hannover, den 19. Mai 2008
I
Table of contents
Page
List of figures…………………………………………………………..………...……....….II
List of tables…………………………………………………………………………………III
List of abbreviations………………………………………...……….…….….………….…IV
1 Information requirements and the change in a company’s IT system….….………..…1
2 A strategic question for applications: custom or standard software solutions.......…...2
2.1 Basics of application software: concept and range………………………………….…..2
2.2 Strategic software planning: A focus on functions, maintenace and replacement…...….3
2.3 A company’s specific solution or a solution off the shelf:
Individual and Standard software……………………………………………….………4
3 A focus on problems in the transition from custom to standard applications…..……..6
3.1 The economic approach: Value-benefit and cost-benefit analysis…………...……….…6
3.2 The Transition to a standard software solution: Tasks and measures……....……….…..7
3.3 Problems and their place of occurrence in the transition process…………..……...…..10
3.3.1 The project and its general problems………………………………….….......….10
3.3.2 A challenge: Specific problems caused by humans…...………………………....11
3.3.3 What shall be adapted, application or organisation?..………………......…….….14
3.3.4 Problems of modification, add-ons, informal systems and data migration…........15
4 Experiences from a practical point of view..……………............................................…16
4.1 Introduction of SHT Logistik company and its logistics manager Michael Kordes…...16
4.2 Practice experience of Michael Kordes: The transition to SAP……...………..….........17
5 Is there a silver bullet to avoid the implications of major transition problems?..........20
Bibliography………………………………………………………………...……………….22
Annex…………………...………………………………………………………………........A1
II
List of figures
Illustration 1: Objectives of transition projects
Source: Treutlein/Sontow (2006), p. 5
Illustration 2: Main steps in a transition project
Source: Treutlein/Sontow (2006), p. 5
Illustration 3: Typical transition problems in the magic triangle
Source: own contribution
III
List of figures
Table 1: Expenses for the different kinds of standard software
Source: Mertens et al. (2005), p. 157
IV
List of abbreviations
IT
-
Information Technology
SHT
-
Sanitär Heizung Tiefbau
ERP
-
Enterprise Resource Planning
CeBIT
-
Centrum für Büroautomation, Informationstechnologie und
Telekommunikation
IBM
-
International Business Machines Corporation
1
1 Information requirements and the change in a company’s IT system
Companies from all industries look for new solutions to increase productivity, improve
service, optimize processes, minimize risks and differentiate from rivals. Critical for that is
the availability of information. But access to information is not enough. For business use
information has to be specific, in time and easy to access. In addition it has to be aggregated
in a way that fundamental insights are provided.1 The IT infrastructure should support this
information requirement with adequate availability, performance, cost efficiency and efficient
administration. The use of data is to optimize processes, applications and productivity.2
As the development of custom solutions is time and cost intensive standard software is rising
in importance. The trend in the companies is a change from a variety of systems, e.g. for
book-keeping or warehousing, to one all-embracing standard system. Such a transition is
linked to busting budget, delay or even a stop of the project.3 Typical objectives of transition
projects are shown in illustration 1.
Reduction of complexity
Reduction of IT costs
Objectives
Better system performance
Reduction of systems
Higher data integration
Higher process integration
Automate processes
Better quality of information
Fast access to information
Simplify processes
0
10
20
30
40
50
60
70
80
Proportion of projects
Illustration 1: Objectives of transition projects4
This paper gives an overview of up-coming problems in transition projects with attention to
enterprise resource planning. To get closer to the theme of custom and standard software, part
two offers an impression of custom and standard software solutions. First, software is
classified; second custom and standard software are defined, followed by a look to strategic
software planning. Part three focuses on the problems in the transition from custom to
standard applications. It starts with an economic approach and introduces to the value-benefit
and the cost-benefit analysis. Afterwards a typical transition process and tasks and measures
1
IBM, 2007, p. 2.
Hurwitz/Kaufmann, 2007, p. 2.
3
Kraus/Götz, 2004, p. 1.
4
Source: Treutlein/Sontow, 2006, p. 5.
2
2
within are presentated, followed by a look to problems and their place of occurrence focused
on different levels and views. Starting with general project problems and a view on problems
due to humans and the system, this part closes with the matter if organisation or application
should be adapted. A glance to the practice in part 4 presents the transition project of the
company SHT Logistik. All the project information is derived from an interview. Herein the
logistics manager of Wullbrandt + Seele was confronted with thesis and questions to get an
impression of a real transition project and occurring problems.
2 A strategic question for applications: custom or standard software solutions
2.1 Basics of application software: concept and range
Software can be classified in different ways. One is to divide between system software,
developmental software and application software. System software supports the other
software categories and links them to the processing unit. It contains the central routines of
the operating system, which controls the applications on the hardware. Development software,
based on the operating system provides tools to create or modify system, development and
application software, according to the programming language.5 Application software is made
for a specific task and exists for all fields in a company. The entire applications and the
corresponding data of a work field are called application system. Application systems can be
operative systems, supporting functions like accounting, distribution or production,
management systems for planning, controlling or reporting and systems for electronically data
transfer, providing links to external systems as well as cross sectional systems like office or
multimedia systems. Systems, integrating operative and management applications are called
enterprise resource planning systems.6 This kind of Software became crucial for companies to
stay in business.
The progress in information technology is fast. Therefore an implementation of application
systems is a continuing process including maintenance, update and market observation.
Especially new versions could provide potentials for the company. Essential for buying
decisions is the individual company’s profile. There is no ideal software, suiting each
company.7 Therefore companies have to establish an information system management which
plans and optimizes the information technology. An appropriate measure is strategic software
planning.
5
Hansen/Neumann, 2005, p. 163.
Stahlknecht/Hasenkamp, 2005, p. 326.
7
Sontow/Köthner, 2005, p. 3.
6
3
2.2 Strategic software planning: A focus on functions, maintenance and replacement
An information system enlarges step by step to save or generate potentials in the company.
The process of change keeps alive by the enduring change of social, ecological and
organisational environment as well as technological progress. The performance of
information systems is granted by stable processing as well as development and
implementation of new software. Depending on the individual situation software components
can be bought, reused, reengineered or new developed.8 The up-coming question is which
system needs a change and which new system would be reasonable. Therefore a planning to
get an image of the future and to generate leeway is necessary.9 This planning is called
strategic information system planning. It fixes a long-time concept of five to ten years and
creates a global system of guide lines, development priorities as well as a concept for change
and implementation to assure an integration of all parts to a homogeneous system. In addition
to this many system decisions are hard to reverse e.g. for hardware, standard software or
networks. Such decisions can only be made according to the company’s way in future.10
Kirchmer divides strategic software planning into five phases. It starts with an analysis of the
current situation to get an overview of the kind of software already in use, the organisational
structure, which has to be supported, and the financial power of the company. With these
results and the expected effects to market and productivity in mind a target concept can be
built up, containing a schedule, the range of system integration and realization steps. In a
second phase the technological gap of current situation and target situation can be analyzed by
split up into a module gap and an integration gap. The module gap shows which systems are
not yet in the company like product planning or control systems and the integration gap
relates to tasks like logistics, order processing or even interfaces to customer or supplier
systems. Phase three applies to the technical background. In this context questions about the
development of infrastructure and the kind of system integration should be answered. The
fourth phase includes the time planning. The time of implementation and the speed of
integration have to be planned, like a slow step-by-step modification or a fast en bloc
implementation. Finally, phase five cares about achieving the capability to use the new
system. Employees need training classes and a technical concept for application systems,
infrastructure and database should be developed.11
8
Hansen/Neumann, 2005, pp. 154-163.
Steinle, 2006, p. 3.
10
Hansen/Neumann, pp. 154.
11
Kirchmer, 1998, pp. 49-53.
9
4
2.3 A company’s specific solution or a solution off the shelf: Custom and standard
software
Many companies still operate with specific applications, developed by own staff or by an
external software company and called custom software. Features are tailored for the
customer’s needs, balanced on the social and organizational environment and not useful for
other companies. Even interfaces to integrate other systems are difficult to implement.12
Another disadvantages of custom software is a long development process which could not
even be shortened significantly by professional software engineering. The so called software
crisis originate in this problem. It contains rising costs for maintenance and accumulation of
developments and a following inability to react to the market. Therefore the competitive
position drops.13 Due to these reasons there is a trend to change to standard software
solutions. But still a spectrum of individual functions or specific problems not covered by
these standard solutions exists.14 For some applications the demand is simply too low like
calculation software for the oil industry or applications to support specific ideas which
generate competitive advantages.
Stahlknecht and Hasenkamp define standard software as a software, universal applicable and
made as a solution for different customers is called standard software or more common
packaged software. Because most of standard software is offered as a package of applications,
e.g. office packages like Microsoft Office or ERP systems like SAP.
The purchase of standard software saves time, as the software companies have their product
on hand, it comes off the shelf. It also saves money due to economies of scale gained from
repeat selling of the once developed software. Software risks, like matching problems or
exceeding of the project deadline, are lower because of a missing joint development process
and the experiences of the vendor.15 Problems of the first release are vanquished. The time
and efforts for maintenance and updaets are reduced, they are provided by the vendor. On this
way know-how and experience of externals comes in the company and the danger to go in
circles is eliminated.
But there are some disadvantages as well. Often the needs of a customer do not meet the
standard software exactly and the standard software has to be customized. As a minimum
effort the input and output data has to be adapt in or to the system, e.g. the length of numbers
12
Hansen/Neumann, p. 165.
Koch, 2005, p. 19.
14
Mertens et al., 2005, p. 33.
15
Stahlknecht/Hasenkamp, pp. 295-296.
13
5
or fields.16 Also there could be a gap to organization or processes. To reduce requirements of
customization standard software provides multiple functions. Therefore it can be less efficient
in case of run-time or computing. In addition standard software is not easy to handle and to
understand. This is in contrast to custom software where close and long-time contacts
between developer and user support identification and knowledge about the functions.17 A
change in the standard software could provide problems to change releases in future.18
According to the kind of license standard software can be divided in traditional standard
software, open-source software and application-service-providing. Open-source software is
characterized by applications free of charge and a visible source code. It has a broad shared
development process because not only one but a lot of developer in the whole world work on
it. Everyone makes small improvements. There are many releases in a short time, to avoid the
development of the same function twice. Even the testing is on this broad base. With both,
fast up-coming new releases and broad testing bugs can be found and eliminated faster than in
traditional standard software.
Application-service-providing is a service model where providers offer an application on their
server and the customer can use the functions, e.g. via web browser. As broadband internet
connections are almost standard, even for small companies and together with the low
threshold costs for customer application-service-providing has future potential.19
Expenses for
Traditional
standard software
x
x
x
Open-source
software
Application-serviceproviding
License
x
x
Training
x
Implementation
(x)
Development
x
Utilisation
x
x
Maintenance
and
update
Table 1: Expenses for the different kinds of standard software20
All three concepts have their advantages but to find the best individual solution companies
have to compare possible solutions and their background by value-benefit and cost-benefit
analysis.
16
Geitner/Meyer, 1983, pp. 126-127.
Stahlknecht/Hasenkamp, p. 296.
18
Geitner/Meyer, 1983, p. 127.
19
Bechen, 2008, p. 27.
20
Source: Mertens et al, 2005, p. 157.
17
6
3 A focus on problems in the transition from custom to standard applications
3.1 The economic approach: Value-benefit and cost-benefit analysis
The benefits of a transition to standard software lie in the ability to integrate as much
company areas as possible to a holistic system. Otherwise a configuration with isolated
solutions implies the risk to intensify ineffective structures and boundaries. Only with a
simultaneous organization of all interacting factors potentials can be exploited.21 But where
are these potentials located and how can they assessed economically?
Often budgets of a transition project can not be held. This is due to different problems in the
implementation phase, with customizing, software licenses, hardware, middleware or training
for administrators and users.22 Therefore a cost optimization as well as an economical review
of strategic, organizational and technical factors is necessary. In addition the costs of a
software implementation should consider the whole software lifecycle, called the total cost of
ownership. Transition projects are situated in an area of conflict between optimal total cost of
ownership and the optimal support of critical success factors. 23 Such critical success factors
are needed to create strategic and economic advantages. To value these factors companies use
the value of benefit analysis. It aggregates a total benefit as a result of a series of sub benefits
created by valuing success factors.24 As an example the protection of investment can be
considered, which include strategic concepts to immunise the investment against unwanted
influences and to support desired adaptation. It is followed by supporting criteria such as the
criteria of standard software, covering basic processes and needs of the specific industry, the
criteria of individualisation, allowing an adaptation to the individual requirements of a
company, the criteria of release ability, providing an easy usability of the latest software
version, the criteria of scalability, giving an opportunity for company growth, the criteria of
internet ability, supporting business processes via web technology and the criteria of
integration, integrating the software smoothly in an existing system landscape.
25
It is
remarkable that not all of these top and sub criteria provide the same benefit. Therefore all
criteria have to be weighted by the decision makers, due to their preferences. On basis of
these benefits the total benefit can be determined. Originally the benefit is not monetary26 but
it is possible to express monetary benefits by referring to costs such as for maintenance or
purchase.
21
Koch, 2005, p. 88.
ABAS Software, 2007, p. 14.
23
Koch, 2005, p. 104.
24
Scholles, 2006.
25
Herzog, 2005, pp. 1-2.
26
Scholles, 2006.
22
7
But there is still a paradox to solve. The software shall be implemented in an optimal way. To
solve the conflict between costs and benefits manager look for ‘best practise’ cases in other
companies. But companies are individual organizations with different requirements and
process realizations. Therefore best practise can be a benchmark only. To get a clue the costs
of the reference system have to be scaled to derive theoretical costs. The difference of
theoretical costs and appearing costs is the estimated potential of optimization. The cost
relation is called progress of optimization which is multiplied by 100 expressed in
percentages.27
With such concepts project managers reach a higher level of control and get more efficiency
into the project, especially if they are considered in the transition process model.
3.2 The transition to a standard software solution: Tasks and measures
The implementation should be managed as a project and by a capable team to pay attention to
schedule, budget, resources and monitoring. Software implications can happen in different
ways. If the implementation is seen as a pure technological task and users as well as the
organization have to meet the software demands, it is called technology centric. Another
approach keeps in mind that only software accepted by the users can achieve intended effects.
The acceptance can be supported by user training. It is called user centric approach. Software
can coordinate users and processes in the organization. Such a view is called organization
centric. To get a balanced system which meets all needs, the project team should consider all
three approaches in a well-thought process model.28 A typical process model could be
sequential and parted in nine steps. It helps to get the project less complex. According to the
concept of Treutlein/Sontow the transition begins with the project establishment. To start the
project the targets have to be predefined, regarding the strategic plan made by the general
management. Project targets can be such as the improvement of work flows, a better data
quality or the reduction of the amount of current information systems.
For the project it is important to get the right team, containing employees of all impacted
departments. Often the effort is underestimated and more capacities for preparations of data,
systems and the organization are needed. Therefore the first task of the project team is to
build a project plan including time and budget.
The second step is to get an overview of provider and systems. Information can be
accumulated from trade journals, best practise cases and trade fairs like CeBIT or SYSTEMS.
27
28
Stammel, 2007.
Kirchmer, 1998, pp. 26-27.
8
As a third step a process analysis helps to get a solid basis for the tender documents. It is
important to capture the organizational structure and processes. Weak points have to be
identified otherwise they could be manifested with the new software. To ease theis analysis
the project team can use reference models, containing typical tasks and processes.
During the fourth step the tender documents should be created. They are needed to compare
different vendors and systems on a well-founded specification. Therefore the project team
shall content participants of all effected departments especially process owners. The
documents have to include restrictions of hardware, system software and. Before the
construction of the tender documents all requirements need to get a weight and sorted in a list
with must-requirements on the top and nice-to-have requirements below.
The market research is the fifth step to refine suitable providers and systems. Starting with
technological and industry fit, the research gets more sophisticated until there is a broad
image how the different solutions fit to the company’s individual case. To stay with the
project in the framework of time and budget the project team depends on competence and
experience of software partner. Therefore information about the software company itself,
reference projects and their experiences in this business sector are important.
Step six contains a preselection. Until now there was no focus on initial value or operating
expenses. Therefore key data of the company, the project and the tender documents have to be
sent to the requested providers. In an assessment centre a chosen group of six to eight
providers can give short presentations to underline their products. Afterwards there should be
a decision for about two providers with a high fulfilment of requirements and appropriate
experiences.
The seventh step contains a differentiation of the chosen systems in a practical test. This can
be made in a one or two-day workshop to get an impression about differences and how the
software will support the company’s daily work. By preparing and execution of these
workshops providers get the knowledge to make estimations for customizing. For questions
still not answered in the system test, a visit to reference customers can help and also provide
an opportunity to discuss implementation problems and interface configurations. Afterwards
all evaluation documents have to be combined to a final result. It is the base to select the most
suitable provider. But this decision has only an interim character. There still has to follow step
eight with the contract negotiations.
On basis of the tender documents, the documents of the system test and influenced by all
gained experiences a specification sheet will be created. All required work and performances
especially those not contained in the standard solution have to be documented. This is
9
important because expenses for adapting and interfaces as well as license and service costs are
significant parts of the budget. In addition a plan for implementation and employee training
should be attached to have a basis to control implementation and get-alive.29
Start
Project establishment
1
2
Orientation
3
Process analysis
Tender documents
Tr
an
sit
ion
pr
oje
ct
4
5
Market research
6
Preselection
Practical test
7
Selection
Implementation
8
9
Alive
Illustration 2: Main steps in a transition project30
The last step handles the implementation. After signing the contract a migration plan has to be
defined. Steps and strategies have to be defined to ensure a right timing of measures during
implementation and the kind of migration has to be fixed as key date or step-by-step
migration. Kirchmer provides a migration concept of three parts. The first part considers
information technology which covers installation, customizing and modification, as well as
hardware and test measures. A second part for organizational measures contains the actions of
human resources, e.g. user and administrator training or the creation of business units and
processes. Both, the information technology and the organizational measures have to be
organised to meet the standard software. To avoid problems with interdependencies of
technology and organisation or an adequate time planning, the project team could rely on a
versed vendor or a consultant.
The coming alive is the last part to handle.31 The implementation procedure follows the
migration plan and ends with the system start, which covers three steps. First the standard
software has to get running. Afterwards all prepared but not activated measures can be
executed. Then start-up has to be supported by monitoring processing and correction of
processing errors. Now the standard software is alive.32
29
Treutlein/Sontow, 2006, pp. 5-18.
Source: Treutlein/Sontow, 2006, 5.
31
Kirchmer, 1998, pp. 161-166.
32
Kirchmer, 1998, pp. 189-192.
30
10
3.3 Problems and their place of occurrence in the transition process
3.3.1 The project and its general problems
A transition project concerns the whole company. Problems occur on different levels and in
different range. Firstly general problems will be focused. Then the view will be moved to the
human, the technological, and the organisational side of the transition project.
Starting a transition project means to establish a project team and to give orientation. If the
project starts not from a strategic clear defined situation and an inadequate kick-off-phase
objectives of the project can be inexplicit.33 To get an orientation and the required resources,
like sufficient budget and employees, such a project needs to be supported by the company
management34 and by a well-defined process model to structure the project teams work. But
process model and project planning can be insufficient due to little experience and no process
know-how of the project manager. But even if the process model is right, it has to be accepted
and used.35 Also detail planning, project complexity and problems are underestimated quite
often because the basis of project planning are estimations which are derived from working
and project experience.36
Many projects get in trouble because of bad or incorrect project management. There are
inexplicit assignments and intransparent interfaces. Intransparent interfaces includes incorrect
defined interfaces between team, several responsible persons and no escalation strategies for
insolvable problems.37
A transition project should not try to “solve the world hunger”38 because the system
complexity growth fast. This is due to a wide coverage of the project with a high need of
consultations and the involvement of different departments and business processes. Therefore
system analysis, implementation and testing delay and get more expensive.39 With a rising
complexity it gets harder to keep a clear overview and a reliable analysis of systems and
processes which can lead to an insufficient quality of requirements.40 In large projects a
variety of experts express different opinions and everyone has different requirements for the
must-have criteria, which blow up the project and a common consensus is far.41 Often
ignorance of the project team, a changed objective or company political changes can lead to
33
Ahrendts/Marton, 2007, p. 190.
Ahrendts/Marton, 2007, p. 320.
35
Ahrendts/Marton, 2007, pp. 278-291.
36
Kotulla, 2002, p. 130.
37
Kotulla, 2002, p. 113.
38
Kotulla, 2002, p. 129.
39
Ahrendts/Marton, 2007, p. 194.
40
Ahrendts/Marton, 2007, p. 200.
41
Kotulla, 2002, p. 131.
34
11
requirements drifts42 and estimations for the project became incomplete or wrong, questioning
the projects budget and schedule.43
But not only requirements of low quality causes problems. Due to political reasons which are
external factors and not influenceable by the project manager44, inexplicit objectives or
unrealistic expectations as well as the specification of not needed functions blow up
requirements and overload the project resources.45 This problem called ‘scope creep’ comes
stealthy by the addition or change of requirements without adaptation of project plan.46
Further problems occur if requirements are agreed but not scrutinised, e.g. international
applicability, where problems can occur if the project team has not in mind that there can be
other languages, laws, metrics, currencies, typesets or special signs47 that has to be considered
to have a backdoor for company growth or changes in law and order48 e.g. introduction of
Euro.
Another place of problem occurrence is the cooperation with external partners. Imperfect
negotiated contracts, due to capabilities of the project management, unrealistic objectives or
political factors,49 which provides a dependence to a supplier, the neglection of tests due to
insufficient definition and time pressure are not seldom.50 Also lacks in external services, due
to insufficient ability of performance of external service providers, insufficient definition of
tasks and objectives or lacks in the delivery can occur51.
3.3.2 A challenge: Specific problems caused by humans
A transition project is a high complex process and not always the planned objectives are
reached. The complexity of such a project can demand external support by an experienced
software vendor or specialized consultants. Therefore a dependence can occur52 where the
management relies on the consultants instead of the project manager this is called gatekeeping approach and leads to insufficient acceptance and high trainings costs.53
42
Ahrendts/Marton, 2007, p. 210.
Kotulla, 2002, p. 141.
44
Kotulla, 2002, p. 146.
45
Ahrendts/Marton, 2007, p. 205-208.
46
Ahrendts/Marton, 2007, p. 332.
47
Ahrendts/Marton, 2007, p. 225.
48
Kotulla, 2002, p. 127.
49
Ahrendts/Marton, 2007, p. 274.
50
Ahrendts/Marton, 2007, p. 242.
51
Ahrendts/Marton, 2007, p. 358.
52
Koch, 2005, pp. 17-18.
53
Koch, 2005, p. 66.
43
12
The implementation of standard software, coming possibly with reorganization and causes
deep change in the employees’ working processes and contents, department membership and
workplace.54 Old and retracted power and information structures are prised open. The
employees have to forsake information monopolies. This is inconvenient55 and sometimes an
extremely psychological burden. Fears of excessive demand or system transparency arise.
Even more if the company culture is not open.56
The information technology became a strategically factor for managing the company.
Therefore an involvement of business politics in information technology projects is not
seldom. Power struggles between persons or departments occur, leading to scarcity in staff,
changing requirements and objectives or to a total blockage of the project. Sources of power
are position, personal character and capabilities of employees as well as the resources
available to the employees.57 Those power struggles can lead to non-acceptance of project
manager or employees. Little experience of the project manager, missing social competence,
local separation between team and manager, high performance and capability differences or
cultural differences and problems in the acceptance of the project manager or of employees
empowers problems in communication, motivation and team work.58 But employees storage
know-how. They take competency and capabilities in a project, but out as well if they leave. 59
Therefore employees need adaquate tasks. If they are under- or over challenged, in a bad
working atmosphere or not in balance with family and career the decision to leave is easy.
This leads to the problem of know-how drainage and the requirement to introduce new
employees to the team.60 Similar problems but even harder for the project occur with the loss
of the project manager, as responsible for the project within allocation and control of tasks,
support of team work and motivation of employees. Therefore besides the drainage of
knowledge team problems and schedule problems can occur.61 But just as well it can be that
due to a not suitable form of organization, a setting of wrong priorities, changeable strategic
objectives or political power struggle and an insufficient resource planning no suitable
employees are available in the company. Than costs to recruit and to develop the necessary
employees come up to the project budget.62
54
Koch, 2005, p. 94.
Kraus/Götz, 2004, p. 2.
56
Koch, 2005, pp. 95-97.
57
Ahrendts/Marton, 2007, p. 314.
58
Ahrendts/Marton, 2007, p. 307.
59
Knaese/Probst, 2001, p. 1.
60
Ahrendts/Marton, 2007, p. 344.
61
Ahrendts/Marton, 2007, p. 282.
62
Ahrendts/Marton, 2007, p. 327.
55
13
Another risky field is communication. Communication is very important because people
communicate even if they think they do not.63 But if they really do not, the coordination
between team, planning and project control suffers.64 Especially if communication is
disturbed e.g. by language barriers or cultural differences, what can lead to inexplicit
objectives on both sides, vendor and purchaser, misunderstanding in the gathering of
requirements or wrong development of functions.65 Language barriers can not only occur
between people from different countries, even in different departments they have different
technical terms. Another barrier are time zones, especially in global divided projects where
communication requires good infrastructure and is mostly virtual via e-mail or voice mail.66
People do not know each other personally, that makes it difficult to find trust and there may
be only a little feeling of togetherness.67 Sometimes the communication is just insufficient,
that means employees withdraw from their colleagues and the horizontal and vertical
communication is shortened. This is often due to inadequate group dynamics, insufficient
introduction of new staff and missing acceptance between project manager and employees.
This leads to poor motivated employees and inadequate teamwork.68
Close related to communication is a professional marketing of the project. Especially in the
case of software transition the user is an important element, he gets the system for daily work.
Sometimes the involved management do not recognize that the software has to be promoted to
the user because for the employee it is the use of a new system. He possibly has an unrealistic
image in mind. This may lead to fear of overwhelming and loss in power.69 For an effective
use of the system the users have to be trained. But it is remarkable that a missing or wrong
analysis about know-how and field of work can lead to not sufficient educated and
unmotivated users, reducing potential and productivity.70
In bigger companies the planning of staff is tricky. The project is possibly divided to different
sides in the whole world. Therefore the project manager is not always the employees
supervisor, follows that priorities could be set in different ways and the very employee might
be removed from the project work.71 Even if employees from other sides come to work in the
same place, the project manager has to differentiate carefully between local employees and
63
Eichler/Pankau, 2008.
Kotulla, 2002, p. 101.
65
Ahrendts/Marton, 2007, p. 317.
66
Kotulla, 2002, pp. 102.
67
Kotulla, 2002, pp. 109.
68
Ahrendts/Marton, 2007, p. 337.
69
Kraus/Götz, 2004, pp. 4-5.
70
Ahrendts/Marton, 2007, p. 268.
71
Kotulla, 2002, pp. 121.
64
14
expatriates. They could have different working contracts with different working hours and
holidays.72 Just as well problematically is to hold the whole team synchronized concerning the
objective and the equal treatment of employees. Often the team close to the project manager
gets information immediately but for the others there is a delay. Also gratifications have to be
divided to everyone. Otherwise employees feel neglected and isolated.73
3.3.3 What shall be adapted, application or organization?
The information technology got a new roll because the transition to standard software helps to
enable organisational optimisation.74 It will be visible if the transition to standard software
would be reduced to an abstract level, where only the software and the company’s
organisation rest. The objective is to reach an integration of both, software and organisation.
The more things they have in common the more successful the company will become.75 The
important question, rising in this context is if structure will follow software or software will
follow structure.
It is not an easy task to change the company’s organisation in a way to adapt to a standard
software because a company is a target-oriented, open and social technical system. It consists
of structural and process organisation76 which are linked to history and mission.77 Many
departments have special individual functions, necessary for their daily work. If they would
be cut by ignorance or just because the standard software do not support them, gaps such as
information gaps can occur, affecting work flow or even a competitive advantage. An other
example is redundancy. Redundant functions can be tied to save costs and resources but
sometimes they are necessary to find and correct mistakes.78
To find organisational areas which could cause problems in case of adoption an analysis of
the current situation in the beginning of the transition project is necessary.79 Often the results
question the organisational structures because in a functional organisation processes are not
organised in line with their logical course and splitted to different organisational entities very
often. As a result organisational breaks exist on every border of two entities. These breaks
have to be reduced to reach a higher level of function and data integration.80
72
Kotulla, 2002, pp. 115.
Kotulla, 2002, pp. 123-126.
74
Koch, 2005, p. 105.
75
Koch, 2005, p. 98.
76
Hentze, 2001, p. 148.
77
Koch, 2005, p. 90.
78
Loos/Krcmar, 2006, p. 123.
79
Koch, 2005, p. 40.
80
Scheer et al., 1996, p. 5.
73
15
Hence the adaptation to standard software provides a chance to improve processes and
workflows in the company and as shown by many company transformations or mergers and
acquisitions in past organizations are quite dynamic. They can change mission, strategies and
structure. In addition providers advice not to modify the standard software because of special
maintenance problems in later release changes and possibly disturbance of right working
software.81 Therefore the adaptation of the organizational structures should have priority to
the software structures82 even if most of the standard software provides user exits for software
modification and customizing components.83
It can be summarized that the decision to implement a specific standard software will be as
well a decision for organisation and processes determined by the software which provides
them by default. This is the reason why “Structure follows Software” quite often.84 But it has
to be considered that such changes of the organisation are comparable with the reconstruction
of a car engine on a motorway. Naturally this causes problems like double-burden for
employees and a dropping productivity in the daily business. It can not be expected to change
an organisation by the way.85 A change management could be provided but it requires extra
resources in staff, budget and time.
3.3.4 Problems of modification, add-ons, informal systems and data migration
The migration is one of the most critical tasks in the transition from individual to standard
software. The success of the new software relies on the perfect operation of the technology. In
addition data bases are the company’s mind. Therefore not only the hardware but good
working interfaces to existing resources are fundamental as well.
One of the first steps in the transition project is planning. Seen from the technical side this is
not an easy task. New technology comes to use and the requirements of every participated
team member are needed. If requirements of some areas are missing there have to be
estimations or these points will simply be skipped. This do not support any global
approaches86 and leads to insufficient interfaces and bad acceptance.
Something else, that has to be considered in planning especially for the budget, is the
complexity of the data migration. Mostly a standard system shall reduce the amount of
systems but old data is still important and a complex data migration necessary. The problem
81
Koch, 2005, p. 93.
Koch, 2005, p. 67.
83
Koch, 2005, p. 93.
84
Kirchmer, 1998, pp. 28-29.
85
Jörgensen et al., 2006, p.6.
86
Kotulla, 2002, p. 141.
82
16
to estimate time and costs is even higher if there is no or only little documentation of the
legacy system or the staff cared about in past left the company.87 This is also essential if some
of the legacy systems have to be used further. As slow interfaces or slow hardware cause slow
data transfer this can effect the whole system and its performance.88
Besides real legacy systems functional staff often creates informal systems mostly in
Microsoft Access or Microsoft Excel. This is due to insufficient functions, non-participation
of users in the transition project. An already existing system in the shadow can lead to
insufficient user acceptance and inefficient use of the new system.89
The system consists of software and hardware. Sometimes the hardware is neglected. But the
environment has to be adequate with regards to server and peripheral equipment to avoid slow
processing and non-acceptance by users.90 If problems with hardware performance are noticed
late in the project, often there is no alternative as to take expensive hardware. The budget
calculations get erroneous.91
To implement the standard software customizing is important to meet the company’s needs.
This customizing can include specific add-ons and interfaces developed only for this project.
Due to insufficient internal and external project communication, a not developed management
of requirements or individual wishes to gain some extra comfort the development of not
necessary functions can occur, leading to more expenses for test and documentation. Due to
time pressure or insufficient definition of test there can be a neglection of these very tests. But
insufficient testing can cause delays arising by malfunctions and bugs during the
implementation.92
4 Experiences from a practical point of view
4.1 Introduction of SHT Logistik company and its logistics manager Michael Kordes
In the year 2004 the company SHT Logistik started a project, dealing with the transition from
a thirty years old system landscape consisting of a couple of independent systems to one
standard software for the departments of administration, sales and logistics. The selected
enterprise resource planning software was a product of the SAP company, called SAP/R3.
Activator for this project was the wish to consolidate the different systems to only one but allembracing system. By this change the executive board hoped to achieve lower costs for data
87
Ahrendts/Marton, 2007, p. 245.
Ahrendts/Marton, 2007, p. 215.
89
Ahrendts/Marton, 2007, p. 259.
90
Ahrendts/Marton, 2007, p. 299.
91
Kotulla, 2002, pp. 144.
92
Ahrendts/Marton, 2007, p. 235-242.
88
17
processing, a higher quality of data, an enhanced feasibility of data analysis and an improved
overview to the state of affairs. In 2007, about one year after finishing the project the
company became insolvent.
The company SHT Logistik was a wholly-owned subsidiary of the Schulte company. Schulte
was a wholesaler for products from the areas of sanitation, heating, excavation and air
conditioning. The Schulte-Group hived off its logistics departments as SHT Logistik and was
the only customer SHT Logistik has had. With the headquarter placed in Essen the company
controlled 100 branches in the whole of Germany which has been distributed by 5 logistic
centres. The logistic centres were located in Aichnach, Braunschweig, Herne, Kerpen, and
Mainz. The Schulte-Group had about 1900 employees, 300 of them worked in SHT Logistik.
The sales volume was around 350 Million Euros per year. After getting bankrupted in 2007
the Heinrich-Schmidt-Group bought the logistic centre in Braunschweig with a couple of
branches between Hannover and Magdeburg and runs it under the former name of the
branches, Wullbrandt + Seele.
The interview partner Mr. Michael Kordes has a master of business administration and is still
working in the company as the logistics manager. When the project started in 2004, he was in
the company for 16 years. His field of responsibility spanned 80 employees of SHT Logistik
as well as 30 motorists of an external shipping company. In the project he was in charge of
the practical implementation of the new system in the logistics department of SHT Logistik.
4.2 Practice experience of Michael Kordes: The transition to SAP
After a more theoretical treatment of the theme a view to the practice follows. It is based on
an interview where Michael Kordes was confronted with some questions and thesis to find out
about how a transition project is handled in practice.93
The project was started with a kick-off period, where the management tried to prepare the
employees and take away their fear to the upcoming system change. The vision they
communicated was to implement an all-embracing standard software without much
modifications in the fixed time of six month.
The base of the project team was formed by the central department of information systems,
called “zentrale Datenverarbeitung”, located in the headquarter in Essen. The chief
information officer became the project manager, even if he did not have any experiences with
such a big project. To get a less complex project, the team was divided in three spheres, the
93
Please find the whole interview in the attachment, pp. A1-A9
18
administration, the sales and the logistics. Later the teams were completed with functional
managers and special key-users. These key-users were determined in every department and
got special training to serve as contact persons for their colleagues in the branches.
The project team designed a sequential process model containing six main steps. First, the
project team had to create a specification sheet. In a second step this specification sheet was
supplemented in the functional departments to their specific needs. On basis of this broader
specification sheet the project team had a look for possible software vendors. In the fourth
step demanded vendors could present their software solutions, followed by an assessment by
the company management. The management had to select the most suitable enterprise
resource planning system. The last step had to be the implementation, parallel to the daily
business. But after the decision for the SAP standard software problems occured because the
module for materials management was not sufficient for a logistics company like SHT
Logistik. The step for creating a new module was missing in the process model. In the
following the model had to be adapted to the projects needs. But there have been other
changes as well. It was planned to meet with all managers in charge in weekly talks to get
updates and discuss problems. As it was not practicable to withdraw the managers in charge
from their work to meet somewhere, this point was cancelled.
The analysis of benefits helps to assess the standard software. In this project the analysis
including setting of preferences was a privilege of the company management. The
management tried to find reference systems. Some of the friendly wholesalers already used
SAP/R3 but there was no logistic company for reference. As a main critical factor the
management considered the use of standard software. The standard software should obtain
investment protection and a fast implementation. Critical judged as well was a horizontal
scalability of the system for not getting captured in the system that limits growth.
The project was started in a software centric way. The management preferred a change in the
company organisation instead in the software. But at least in the logistics department
organisation and employees would be considered due to the creation of required applications.
To meet all requirements especially in the logistics department groups of employees and
fields of work were created e.g. bookers or commissioner. Based on this and the individual
knowledge the need for training was settled. In the following the employees were trained on
the test system in groups of only two or three because it was parallel to the daily business.
When the system came to life all employees had finished their courses. To motivate and
participate suggestions for improvements of the employees were desired. After an intensive
check everyone got feedback if his suggestion was helpful or even why it was not.
19
From the software view there was only little customizing needed except in the logistics
sphere. There the project team followed the motto “software follows structure” and a new
logistics software was created. While in other projects big problems with the migration of old
data occur, it has to be remarked that such problems could be neglected. Especially for the
logistics department with its big chaotic organized warehouses, a back-up was made before
starting the implementation phase. This back-up could be used parallel during implementation
and start of the SAP system.
The organisation was adapted as necessary. Therefore a new central department of accounts
receivable was installed in the headquarter and a new structure of order numbers was
introduced. In addition in every logistic centre the position of a special system administrator
was established as contact person and coordinator in case of problems with the standard
software.
The project was affected by three main problems, namely time planning, missing standard for
the logistics department and in communication. The project started in the end of 2004 and was
scheduled to finish half a year later. But due to the application creation for the logistics
department it was finished in the end of 2006. Another big problem of course was that the
standard SAP software did not meet the special requirements of SHT Logistik like a night
consignment which considers all branches, logistic centres and predefined shipping tours.
Important as well was an occurring communication problem. It was not because of a bad
communication culture. It was due to language and functional knowledge during the creation
of the logistic module. On one hand were the practitioner, which had to explain the work
process and on the other hand were the programmer, which had to create a suitable software
solution. Every side had its functional language and in addition specific things in mind, which
seem that trivial that it was just not mentioned. Therefore it came to misunderstandings and
mistakes in the applications. Due to the necessary corrections in the code the time problem
became worse. Some mistakes could not be found before the system was in use.
At the end there is always the question if the objections are reached. Mr. Michael Kordes
assures that the objectives such as lower costs for data processing, enhanced data quality,
improved feasibility of data analysis and at least one all-embracing system were reached. In
addition he remarked that a special challenge was the development and implementation of the
system parallel to the daily business.
20
5 Is there a silver bullet to avoid the implications of major transition problems?
Activated by environmental restraints and supported by the strategic software planning
companies set up projects to consolidate their system landscape. Often a couple of legacy
systems, partly still custom software, are transitioned to one all-embracing standard software
solution. However this transition is a tough task because it can be blocked with a variety of
problems occurring in the project itself, by interacting of concerned people, modification,
customizing and data migration as well as changes in the company organisation.
As the task was to localize and describe typical problems in software transition, it is obvious
to make an analysis of problems mentioned in the literature and compare the result with data
from practice. Problems can be marked as typical if the almost limitless theoretical problems
could be approved by practical experience.
The interview presented in part four has shown that an inadequate kick-off phase leaves poor
motivated, and scared employees, causing a variety of further problems. Also the experience
of the project manager is critical especially for good budget and time planning. Double
burden for the staff can occur followed by poor motivation and delays in the project schedule.
Really important are to be communication problems. They occur by differences in language
and functional knowledge. The process model as a leitmotif leads the involved people to the
target. A complex and intransparent model can question the whole project. Just as well if the
decision for a standard software is made as a kind of political and intransparent decision by
the company management and no reference system is available the whole project can get in
trouble. As shown this caused another big problem, the development of suitable add-ons or
better a whole logistics module. Therefore interfaces became important for data migration. In
the considered project data migration was only a small problem. In addition people can be
motivated by participation. If the employees are not participated in the project problems with
motivation and fear of the new system can occur.
These problems derived from the interview aligned with the problems mentioned in part three,
result as typical transition problems: an insufficient kick-off phase, budget and time planning,
too little experience of the project manager, a variety of communication problems, an
inadequate process model, no reference system, an unbalanced implementation, the
development of add-ons and the double burden of involved staff. All these problems lie in an
magic triangle of time, budget and objectives, if a problem occurs it effects at least one of
them. It is remarkable, that the conclusion is only limited because such an empirical analysis
needs more effort than one interview.
21
Schedule
Insufficient kick-off
Too little experience
Budget and time planning
Inadequate process model
Communication problems
No reference system
Unbalanced implementation
Budget
Software modification/development
Objectives
Illustration 3: Typical transition problems in the magic triangle94
Based on this analysis the question to avoid this typical problems occurs. As shown in part
two of this paper a strategic software planning links the strategic planning of the company
management with the whole software landscape of the company and gives orientation for
system changes or new systems according to the current situation, company objectives and
financial power. Based on this overview the management can generate an image of needs and
capabilities the company has if they start a transition project. To start the project the
management or the project team have to generate a value-benefit analysis. This analysis
shows where preferences are and eases the selection of the standard software. It would be
good for time and budget planning if the company can find a reference system in a company
of similar industry. Helpful as well is a simple process model because as seen in the example
it could be hindering, if to detailed. Another idea might be the use of change management to
avoid problems. Such a transition project impacts the whole company. Change management
provides a couple measures which should avoid problems in the transition from custom to
standard software. But it has to be analysed to what extend it can support a software transition
in a company.
As a conclusion it is remarkable that there is no silver bullet to solve or avoid all the
upcoming problems of a transition project, but a good organised project team on basis of a
good strategic software planning, using tools like an ingenious process model and a useful
reference system can help to avoid problems, may be embedded in change management.
94
Source: own contribution
22
Bibliography
ABAS Software (2007)
Auszug Konradin ERP-Studie 2007, Karlsruhe 2007
Ahrendts, F./Marton, A. (2007)
IT-Risikomanagement leben - Wirkungsvolle Umsetzung für Projekte in der
Softwareentwicklung, Berlin 2007
Bayer, M. (2008)
ERP-Migration - wieso, weshalb, warum?,
www.computerwoche.de/knowledge_center/enterprise_resource_planning/1862188/,
print date 27.04.2008
Bechen, P. v. (2008)
Webhosting - e-Mail und Groupware im SaaS-Angebot; in: Digital Business, Vol. 13,
2008, No. 3, pp. 26
Eichler, W./Pankau, J.
http://www.uni-oldenburg.de/germanistik-kommprojekt/sites/1/1_05.html, print date
17.04.2008
Geitner, U. W./Meyer, R. (1983)
Betriebsinformatik für Produktionsbetriebe - Teil 3 - Methoden, München 1983
Hansen, H. R./Neumann, G. (2005)
Wirtschaftsinformatik 1 – Grundlagen und Anwendungen, 9. Auflage, Stuttgart 2005
Hentze,J./Heinecke, A./Kammel, A. (2001)
Allgemeine Betriebswirtschaftslehre - aus Sicht des Managements,
Bern/Stuttgart/Wien 2001
23
Herzog, P. (2005)
Software-Investitionen richtig schützen: Auswahlkriterien für eine ERP-Lösung,
Sonderdruck aus ERP Management, H. 2, 2005
Hurwitz, J./Kaufmann, M. (2007)
Innovationen und Wettbewerbsvorteile durch dynamische Datennutzung, White Paper,
Waltham 2007
IBM (2007)
Dynamic Warehousing-Lösungen - Kurzinformation für Führungskräfte - Von
widersprüchlichen, nicht integrierten Langzeitdaten zu verwertbaren
Detailinformationen - Eine Einführung in Dynamic Warehousing-Lösungen von IBM,
Stuttgart 2007
Jörgensen, H. H./Albrecht, J./Neuss, A. (2007)
Making Change Work – Erfolgsfaktoren für die Einführung von Innovationen,
Stuttgart 2007
Kirchmer, M. (1998)
Business process orientated implementation of standard software: how to achieve
competitive advantage quickly and efficiently, Berlin 1998
Knaese B./Probst G. (2001)
Wissensorientiertes Management der Mitarbeiterfluktuation - Eine Methode zur
Reduzierung personeller Wissensrisiken; in: zfo, 70. Jg., 2001, H. 1, pp. 35 - 41
Koch, O. (2005)
Konzeption eines generischen Vorgehensmodells zur strategieorientierten und
partizipativen Einführung komplexer Softwaresysteme unter Berücksichtigung
organisatorischer Gestaltungsprozesse – Inauguraldissertation, Kassel 2005
Kotulla, A. (2002)
Management von Softwareprojekten – Erfolgs- und Misserfolgsfaktoren bei
international verteilter Entwicklung, Wiesbaden 2002
24
Kraus, G./Götz, T. (2004)
Wiederständen bei Softwareprojekten erfolgreich begegnen; in: Perspektive:blau Wirtschaftsmagazin, http://www.perspektive-blau.de/artikel/0411b/0411b.htm, print
date 21.04.2008
Loos, P./Krcmar, H. (2006)
Architekturen und Prozesse: Strukturen und Dynamik in Forschung und Unternehmen,
Berlin 2006
Martin, R. (2006)
So gelingt die ERP-Einführung; in: Computerwoche, 2006, H. 18, pp. 28
Mertens, P./Bodendorf, F./König, W. et al. (2005)
Grundzüge der Wirtschaftsinformatik, 9. Auflage, Berlin 2005
Mizrahi, I. (1998)
Business Reengineering With Standard Software – Tools and Process for Software,
http://infolab.stanford.edu/cs446/1998/Projectpresentations/SAPFinalCorregido.doc,
print date 31.03.2008
Scheer A.-W./Nüttgens, M./ Zimmermann V. (1996)
Business Reengineering in der Verwaltung; in: Veröffentlichungen des Instituts für
Wirtschaftsinformatik, Universität des Saarlandes, Heft 129, Saarbrücken 1996
Scholles, F. (2006)
Die Nutzwertanalyse und ihre Weiterentwicklung, http://www.laum.unihannover.de/ilr/lehre/Ptm/Ptm_BewNwa.htm, print date 30.04.2008
Sontow, K./Köthner, D. (2005)
Vielfältiger und ausgereifter Software-Markt; in: isreport, Business Guide Enterprise
Resource Planning 2005, Sonderausgabe Juli 2005, München 2005, p. 3
25
Stahlknecht, P./Hasenkamp, U. (2005)
Einführung in die Wirtschaftsinformatik, 11. vollständig überarbeitete Auflage, Berlin
2005
Stammel, N. (2007)
In sieben Schritten zur Kosten/Nutzen-Analyse, www.lexta.com/main/ de/31/
download.php, print date 29.04.2008
Steinle, C. (2006)
Grundlagen der Planung und strategische Planung; in: Grundlagen der
Unternehmensführung 2, Universität Hannover, Skript zur Veranstaltung 2006, p. 3
Treutlein/Sontow, 2006
In 8 Schritten zum richtigen ERP-System und –Anbieter – Von der effizienten
Erstinformation bis zum sicheren Vertrag, www.it-matchmaker.com/public/
downloads/0620.pdf, print date 09.04.2008
A1
Annex
Experteninterview zur Seminararbeit:
Typical problems in the transition from custom software to standard software solutions.
Das folgende Experteninterview mit Herrn Michael Kordes über das Transitionsprojekt von
einer veralteten Softwarelösung zu SAP in der SHT Logistik GmbH wurde am 06.05.2008 in
Braunschweig durchgeführt.
Jeder Themenblock wurde mit einer These eingeleitet und anhand von spezifischen Fragen
näher beleuchtet.
Das Interview begann mit einer kurzen Vorstellung von Unternehmen, Person und Projekt:
Das SAP-Projekt wurde in der SHT Logistik GmbH durchgeführt, die Ende 2007, gut ein Jahr
nach Abschluss des Projektes in Insolvenz gegangen ist. Die SHT Logistik GmbH war eine
Tochtergesellschaft der Schulte GmbH & Co KG. Der einzige Kunde von SHT Logistik war
Schulte, die in SHT Logistik ihren Logistikbereich ausgegründet hatte.
Schulte war ein Großhandelsunternehmen und vertrieb Produkte aus den Bereichen Sanitär,
Heizung, Tiefbau und Klima. Es besaß 100 Standorte in Deutschland, die durch 5 LogistikCenter der SHT Logistik versorgt wurden. Diese Logistik-Center befanden sich in Braunschweig, Kerpen, Herne, Mainz und Aichnach. Im Gesamtunternehmen waren fast 1900 Mitarbeiter, davon 300 bei SHT Logistik, beschäftigt. Der Umsatz betrug ungefähr 350 Millionen
Euro.
Herr Kordes ist heute bei der Wullbrandt & Seele GmbH als Leiter des Bereichs Logistik beschäftigt, die als Tochtergesellschaft der Heinrich-Schmidt-Gruppe das Logistik-Center
Braunschweig der früheren SHT Logistik mit einem Filialnetz von Hannover über Braunschweig und Magdeburg betreibt. Zum Zeitpunkt des Projektes war der diplomierte Betriebswirt Michael Kordes bereits 16 Jahre im Unternehmen. Sein Verantwortungsbereich im Logistik-Center umfasste 80 Mitarbeiter der SHT Logistik sowie 30 Fahrer einer Spedition, die
ihm weisungsbefugt unterstellt waren. Er betreute die praktische Einführung von SAP im Logistik Sektor der SHT Logistik.
Das Projekt befasste sich mit der Umstellung der gesamten Systemlandschaft auf die Standardsoftware für Enterprise Resource Planning SAP/R3, durchgängig in den Bereichen Verwaltung, Vertrieb und Logistik. Auslöser für das Projekt war, das die 30 Jahre alte Lösung,
basierend auf verschiedenen Systemen, nicht mehr anforderungsgemäß war, sowie der
Wunsch nach einer Zusammenführung verschiedener Systeme zu einem umfassenden System,
da man sich davon eine Kostensenkung im Bereich der Datenverarbeitungskosten, eine besse-
A2
re Datenqualität, bessere Auswertungsmöglichkeiten und damit eine bessere Sicht auf den
Stand der Dinge erhoffte.
Im Folgenden wird das Interview mit Herrn Kordes wiedergegeben:
These1:
Ein Transitionsprojekt startet gewöhnlich mit der Installation eine Projektteams sowie
dessen Orientierung.
Gab es Ihrer Ansicht nach eine angemessene Kick-off-Phase sowie eine klare Vision mit
anschaulichen Zielvorgaben?
Ja, die Kick-off-Phase wurde von der Geschäftsleitung geprägt, die die Mitarbeiter auf einen
bevorstehenden Systemwechsel vorbereitete und durch ihr Commitment versuchte den Ängsten der Mitarbeiter entgegen zu wirken. Ihre Vision war die Einführung einer Standardsoftware möglichst ohne große Modifikationen in einem relativ fixen Zeitfenster von 6 Monaten.
Diese Zielvorgaben wurden direkt ins Pflichtenheft übernommen.
Wie war das Projektteam zusammengesetzt?
Den Grundstamm des Projektteams bildete die Abteilung „Zentrale Datenverarbeitung“ in
Essen. Somit bestand ein Basisteam, das durch den Abteilungsleiter als Projektleiter geführt
und später durch die funktionalen Bereichsleiter und Key-User ergänzt wurde. Die Key-User
wurden in den einzelnen Abteilungen festgelegt und besonders geschult. In der Einführungsphase wurden sie als Ansprechpartner in den einzelnen Niederlassungen eingesetzt.
Wie schätzen Sie die Erfahrung des Projektleiters mit Softwareprojekten ein?
Der Projektleiter kam zwar aus der Abteilung „Zentrale Datenverarbeitung“ hatte bislang aber
noch keine Erfahrung in einem vergleichbaren Großprojekt.
Waren die Verantwortlichkeiten im Projektteam sauber definiert und für alle transparent?
Ja, das Projekt wurde in die Bereiche Verwaltung, Vertrieb und Logistik geteilt. Dort gab es
jeweils Unterteams.
A3
These 2:
Bei einem Wechsel von Softwarelösungen orientieren sich die Beteiligten an einem unternehmensspezifischen Vorgehensmodell, welches wichtige Schritte des Projektes enthält und eine Koordination der Beteiligten sowie die Kontrolle über das Projekt erleichtert.
Wie sah das Vorgehensmodell bei Ihnen aus, welche Schritte waren enthalten?
Zu Beginn ist man von einer sequentiellen Vorgehensweise ausgegangen. Es war vorgesehen,
dass man ein Pflichtenheft erstellt, das im zweiten Schritt spezielle Anforderungen durch Ergänzungen aus den Abteilungen aufnehmen sollte. Mit diesem erweiterten Pflichtenheft sollte
in Schritt drei die Suche nach möglichen Anbietern erfolgen, welche dann die Möglichkeit
bekommen sollten ihre Software zu präsentieren. Dann war eine Bewertung und Auswahl
durch die Geschäftsleitung vorgesehen. Anschließend sollte die Implementation der Standardsoftwarekomponenten phasenweise, parallel zum Tagesbetrieb erfolgen.
Als man sich für SAP entschied und feststellte, dass die Materialwirtschaft im Standard nicht
den Ansprüchen eines Logistikunternehmens genügte und man mit dem Softwarehaus eine
eigene Lösung kreierte wurde das Vorgehensmodell geändert.
Wurde das Vorgehensmodell von den Beteiligten angenommen und umgesetzt?
Ja, unser Vorgehensmodell ist akzeptiert worden, wahrscheinlich wurde es so gut angenommen, da sich gleich zu Beginn praktisch jeder im Rahmen der Pflichtenhefterstellung in das
Projekt einbringen konnte.
Gab es Probleme mit dem Vorgehensmodell?
Ja, einzelne Teile des Vorgehensmodells mussten geändert werden. Neben dem Problem im
Bereich Logistik, dessen Neuprogrammierung ganz fehlte, hatte man z.B. auch so genannte
Wochengespräche geplant, bei denen die Verantwortlichen zusammengezogen werden sollten. Man wollte in diesem Rahmen den aktuellen Stand sowie mögliche Probleme abrufen
und besprechen können. Dies hat sich aber als nicht praktikabel herausgestellt. Man konnte
die Verantwortlichen nicht einfach für ein paar Tage herausziehen, um irgendwo eine Sitzung
abzuhalten.
A4
These 3:
Die Nutzwertanalyse dient zur Bewertung der Standard Software. Es sollen die kritischen Faktoren, besonders auch nicht monetären Vor- und Nachteile einheitlich als Nutzengrößen in hierarchischer Reihenfolge dargestellt werden, um einen vergleichbaren
Nutzwert des Systems zu ermitteln.
Was waren die kritischen Erfolgsfaktoren für das Projekt?
Die Geschäftsleitung betrachtete den Faktor Standardsoftware als kritisch für den Projekterfolg. Zum einen sollte somit ein Investitionsschutz und zum anderen eine schnelle Realisierung gewährleistet werden. Aber auch eine horizontale Skalierbarkeit sollte gewährleistet
sein, um unserem wachsenden Unternehmen Rechnung tragen zu können und später nicht in
engen Systemgrenzen gefangen zu sein.
Wer hatte Einfluss auf die Reihenfolge bzw. wer konnte seine Präferenzen einbringen?
Das war ein Privileg der Geschäftsleitung und des Projektleiters. Deshalb konnten auch Teilprojekte nur verschoben werden, nachdem die Geschäftsleitung zugestimmt hatte.
Gab es Referenzsysteme und Benchmarks?
Natürlich wurde versucht Referenzen zu finden. Es gab Referenzsysteme in befreundeten
Großhandelsunternehmen. Dort wurde bereits mit SAP/R3 gearbeitet. Problematisch war,
dass es keine Referenz aus anderen Logistikunternehmen gab. Ob es auch Benchmarks gab
kann ich nicht beantworten.
These 4:
Für ein ausgewogenes und von den Mitarbeitern akzeptiertes System ist eine Balance
aus technik-, organisations- und anwenderzentrierter Einführung notwendig.
Denken Sie, dass das System ausgewogen implementiert wurde?
Ja, im Ergebnis kann man wohl von einer ausgewogenen Einführung sprechen. Zu Beginn
war aber eine eher technikzentrierte Implementierung geplant. Man dachte lieber die Organisation anpassen als die Software. Letztendlich wurde aber zumindest im Logistikbereich die
Organisation und, durch den Einbezug der Mitarbeiter zur Erstellung der benötigten Applikationen, auch die Mitarbeiterseite entsprechend gewürdigt. Wobei man natürlich sagen muss,
A5
dass ausführliche Mitarbeitertrainings in allen Bereichen geplant waren und auch gelaufen
sind.
Wie wurden Sie den einzelnen Anforderungen gerecht?
Hier kann ich natürlich nur für den Logistikbereich sprechen. Wir haben Mitarbeitergruppen
und Arbeitsfelder definiert, z.B. Disponenten, Kommisionierer usw. Hier konnte dann anhand
der Arbeitsfelder sowie des individuellen Vorwissens der Schulungsbedarf festgelegt werden.
Es ist kaum zu glauben, dass manche Mitarbeiter zwar die Abläufe und Vorgehensweisen
verstanden, dann aber bei simplen Dingen wie der Bedienung einer Maus Probleme bekamen.
Die Mitarbeiter wurden am Testmandanten geschult, immer in kleinen Gruppen von 2 bis 3
Personen, da der Tagesbetrieb weiterlaufen musste. Schließlich hatten beim Echt-Start alle
Mitarbeiter das nötige Rüstzeug erhalten.
Gab es Softwaremodifikationen?
Wirkliche Modifikationen gab es eigentlich nur im Logistikbereich. Hier wurde dann bei der
Neuprogrammierung dem Leitsatz „Software follows structure“ gefolgt, was aber erhebliche
Probleme allein schon in der Softwareerstellungsphase mitsichbrachte. In den anderen Bereichen konnte alles im Rahmen von Customizing bzw. mit Standardmodulen erschlagen werden. Modifikationen gab es dort eher auf der Organisationsseite wie z.B. eine neue zentrale
Rechnungseingangsprüfung oder ganz simple eine neue Struktur für z.B. Auftragsnummern.
Hatten Sie Schwierigkeiten bei der Migration von Altdaten?
Es sind zum Glück nur kleinere Probleme aufgetreten, die alle beherrschbar waren. Vor allem
gilt dies für den Bereich Logistik, wo man eine Altdatensicherung vorgenommen hatte. Diese
Altdaten waren noch längerfristig abrufbar. Es wäre schließlich eine Katastrophe, wenn in
einem Logistik-Center plötzlich bestimmte Teile im chaotisch organisierten Lager nicht mehr
auffindbar wären.
In welchem Maße gab es Veränderungen in der Organisation? Wurde sie an die Software und ihre Vorgaben und Prozesse angepasst?
Wo es notwendig erschien und möglich war, wurde die Organisation verändert. Wie ich bereits vorhin erwähnt habe hatte man die Parole ausgegeben lieber die Organisation anpassen,
als die Software. Natürlich ging das später im Logistikbereich nicht. Dort sind alle Prozesse
übernommen worden.
A6
Was man in diesem Rahmen vielleicht noch erwähnen könnte ist, dass es kaum personelle
Veränderungen gab. Für jedes Logistik-Center wurde zusätzlich die Stelle eines speziellen
Beauftragten für die Datenverarbeitung als Ansprechpartner und Koordinator in Problemfällen geschaffen.
Wie wurden die Mitarbeiter partizipiert und motiviert?
Es wurde versucht den Mitarbeitern die Angst vor neuen Dingen zu nehmen. Dies war dort
besonders kritisch, wo man vorher rein händisch und nun computerunterstützt arbeiten musste. Vor allem durch eine gute Schulung sollten die Mitarbeiter hier vorbereitet werden.
Auch wurden Anregungen für Verbesserungen von Mitarbeiterseite aufgenommen. Nach intensiver Prüfung gab es Feedback, ob man den Vorschlag umsetzen konnte bzw. weshalb er
leider nicht übernommen werden konnte.
Eine Motivation erfolgte nur über die Vergütung der Stunden. Eine Party nach erfolgreichem
Projektabschluss wie in manchen anderen Unternehmen war wegen der hohen Kosten, gesehen auf die 100 Standorte, nicht praktikabel.
These 5:
Softwareprojekte können in verschiedener Weise beeinträchtigt werden. Die Probleme
haben immer Auswirkungen auf die Projektziele, den Zeitplan oder das Budget.
Was waren die Hauptprobleme während des Projektes?
Als Hauptproblem lässt sich ganz klar die Zeit nennen. Projektbeginn war zum Ende des Jahres 2004 und das Projektende war für Mitte 2005 terminiert. Besonders durch die Sonderanforderung Logistikbereich konnte das Projekt schließlich erst Ende 2006 fertig gestellt werden.
Ein weiteres Problem war selbstverständlich auch der fehlende Standard für die Logistik. SAP
unterstützte aber z.B. keine Nachtverladung, die mehrere Standorte berücksichtigt und unsere
Tourenplanung übernimmt.
Als wie schwerwiegend schätzen Sie Kommunikationsprobleme für das Projekt ein?
Kommunikationsprobleme kommen gleich nach der knappen Zeit. Wobei es sich bei den
Problemen hier mehr um Sprachprobleme und Verständnisprobleme handelte, die auftraten,
als man sich des Logistikbereiches annahm. Auf der einen Seite waren die Praktiker, die die
Abläufe erklären mussten und auf der anderen Seite waren die Programmier, die diese Abläu-
A7
fe als Software umsetzen mussten. Während nicht nur jeder seine eigene Fachsprache hatte,
waren auch jeweils bestimmte Voraussetzungen und Folgerungen für die jeweilige Seite so
klar, dass nicht darüber gesprochen wurde. So kam es zu Missverständnissen und natürlich
falschen Applikationen. Durch die nötigen Änderungen im Code verschlimmerte sich natürlich auch das Zeitproblem. Teilweise konnten die Fehler erst im Reallauf gefunden und ausgebessert werden.
Wurden Nachrichten generell rechtzeitig, ehrlich und offen verbreitet?
Ja, es gab eine sehr offene Kommunikationskultur. Wenn doch einmal nicht rechzeitig informiert wurde, so war es meist ein individuelles unabsichtliches Fehlverhalten, jedem passiert
mal, dass man vergisst eine Nachricht weiterzugeben.
Konnten Zeitplan und Budget des Projektes eingehalten werden?
Nein. Der ursprüngliche Zeitplan musste bereits angepasst werden, als man erkannte, dass es
wohl keinen passenden Logistikstandard geben wird. Diese Anpassung war aber zu optimistisch.
In welchem Maße letztendlich das Budget überschritten wurde kann ich Ihnen nicht sagen.
Wurden alle angestrebten Ziele erreicht?
Nein, es konnten nur die Oberziele erreicht werden. Der Realbetrieb war zu Beginn von
Schwachstellen und Problemen gekennzeichnet. Dies lag vor allem an Problemen mit den
speziellen Anforderungen in den Unterzielen. Diese Probleme wurden bis zur endgültigen
Umsetzung händisch gelöst. So hat z.B. die Software bei der Tourenplanung die Rechnungsanschrift als Lieferadresse ausgegeben. Es gab Kunden, deren Sitz in Braunschweig war, die
Baustelle aber in Hannover. Dann kam die Lieferung automatisch in Tour 1 für Braunschweig. Dies musste jeweils durch manuelle Kontrolle erkannt und manuell geändert werden.
A8
These 6:
Bei einem großen Projekt wie dem Wechsel zu einem neuen Softwaresystem und seinen
Auswirkungen auf das Unternehmen kann man bereits von „Change“ und „Change
Management“ sprechen.
Die Frage ist bei Change immer wie groß die Auswirkung auf das Unternehmen selbst ist. Bei
uns konnte man eigentlich nicht von Change und Change Management sprechen, da wenig an
der Organisation geändert wurde. Es handelte sich schlicht um eine Softwareerneuerung.
Change ist in der Logistik auch schwierig, da es grob gesehen nur einen Prozess gibt und keine vielseitigen Wertschöpfungsprozesse wie in der Industrie.
War das Commitment des Top-Managements für das Projekt vorhanden?
Ja, es gab sogar ein besonderes Interesse für unseren Logistikbereich. Genau genommen war
die SAP-Einführung im Logistikbereich eine rein politische Entscheidung, da man mit
HELAS bereits eine standardmäßig SAP anschlussfähige Standardsoftware hatte, was keine
Umstellung erforderte, aber man wollte nur noch ein System und einen Softwarepartner haben.
Existierte im Unternehmen das Bewusstsein für die mit der Veränderung einhergehende
Herausforderung?
Die größte Herausforderung war im Logistikbereich, dass war von Anfang an klar. Der Betrieb sollte aufrechterhalten werden und das neue System sollte quasi nebenbei eingeführt
werden. Wir sahen dort schon sehr früh eine Doppelbelastung für alle Mitarbeiter in der Logistik kommen.
Wie groß war der Anteil des Projektbudgets, der für Change Management bereitgestellt
wurde?
Da kann ich Ihnen nicht weiterhelfen.
Abschluss:
Als wie erfolgreich bewerten Sie das Projekt rückblickend?
Auch hier kann ich wieder nur für den Logistikbereich sprechen. Ich würde es als ein erfolgreiches Projekt beschreiben, das aber nicht nötig gewesen wäre, wenn man HELAS weitergenutzt hätte.
A9
Was halten Sie für besondere Herausforderungen des Projektes?
Herausfordernd war das System während des laufenden Betriebes ohne Stillstandzeiten zu
implementieren. Aber auch die fehlerfreie Umsetzung der Nicht-Standards in meinem Bereich
war eine Herausforderung.
Sind Sie der Ansicht, dass bestimmte Probleme hätten vermieden werden können?
Ich denke vor allem das Zeitproblem hätte man in den Griff bekommen können, wenn der
Programmieraufwand für die Logistiksoftware detaillierter analysiert worden wäre.
Abschließend wurde Herrn Kordes noch Dank ausgesprochen, dass er für das Interview bereit
war.