SAP R/3 - Universität Bern

Transcription

Vorgehensweisen und Erfahrungen bei der Einführung
von Enterprise-Management-Systemen
dargestellt am Beispiel
von SAP R/3
INAUGURAL-DISSERTATION
zur Erlangung der Würde eines Doctor rerum politicarum
an der Rechts- und Wirtschaftswissenschaftlichen
Fakultät der Universität Bern
vorgelegt von
Reto C. von Arb
von Neuendorf (SO)
Bern, Dezember 1997
Abstracts
Abstract
Eine Reduktion der "Time-to-Market" und hohe Flexibilität zählen heute für viele Unternehmen zu den wichtigsten Stützen ihres Erfolges. Enterprise-Management-Systeme
(EMS) bieten dazu die notwendige Flexibilität zur informationstechnischen Abdeckung
der Geschäftsprozesse. Das R/3-System der SAP AG ist auf dem europäischen und dem
amerikanischen Markt für EMS weit verbreitet und hat sich in diesem Bereich zu einem
"De-facto-Standard" entwickelt. Durch den hohen Integrationsgrad dieses Systems können Geschäftsprozesse durchgängig abgebildet werden und umfangreiche CustomizingMöglichkeiten bieten die zur Anpassung an neue Prozessvorgaben erforderliche Flexibilität. Gleichzeitig müssen die genannten Vorteile durch einen hohen Grad an Komplexität erkauft werden. Die Einführung eines solchen Systems ist daher kein einfaches
Unterfangen und stellt hohe Anforderungen an das Management.
Dieses Arbeit gibt einen Überblick über die Funktionalität und den Einführungsprozess
von SAP R/3. Ferner werden in einem empirischen Teil die Erfahrungen von Schweizer
R/3-Anwendern bei der Einführung von SAP R/3 dargelegt und daraus kritische Erfolgsgrössen für die Durchführung solcher Projekte abgeleitet.
Abstract
A reduction in the ”time to market” and great flexibility are today among the most important factors for the success of many companies. Enterprise Management Systems
(EMS) provide the flexibility required for supporting business processes through technical information. The R/3 system from SAP AG is widely used for EMS on the European
and American markets and has become the de-facto standard in this field. Through the
high level of integration offered by this system complete business processes and procedures can be shown in their entirety and comprehensive customizing facilities provide
the flexibility necessary for adapting to changing process requirements. At the same time
the benefits provided inevitably necessitate a high degree of complexity. The introduction of such a system is therefore not an easy matter and imposes considerable demands
on company management personnel.
This document gives an overview of the functionality of SAP R/3 and its introduction. In
addition, an empirical section illustrates the experiences of Swiss R/3 users on introducing the system and derives from those experiences the factors critical to the successful implementation of such projects.
I
Abstracts
Résumé
A l’heure actuelle, la clé du succès réside, pour de nombreuses entreprises, dans une
réduction des cycles de commercialisation («Time to Market») et dans une flexibilité
accrue. Les systèmes EMS (Enterprise Management System) vous apportent la souplesse
requise pour une prise en charge informatique des processus opérationnels. Très répandu sur les marchés européen et américain de l’EMS, le système R/3 de SAP AG est devenu un standard «de facto» dans ce domaine. Grâce à une forte intégration, ce système
permet de reproduire des processus opérationnels dans leur totalité; en outre, des options personnalisées très complètes procurent la flexibilité indispensable à l’intégration
des nouvelles données de processus. Mais tous ces bénéfices sont le fruit d’un haut niveau de complexité. L’introduction d’un tel système n’est pas une mince affaire et constitue un véritable défi pour les dirigeants.
Cet ouvrage présente les fonctionnalités et le processus d’introduction du système SAP
R/3. Une partie plus empirique relate les expériences vécues par des utilisateurs suisses
avec l’introduction de SAP F/3 et en déduit des facteurs critiques pour la réussite de tels
projets.
Riassunto
Per molte aziende la riduzione del "time-to-market" e una grande flessibilita fanno parte
dei fondamenti importanti del loro successo. Per i sistemi di gestione aziendale
(Enterprise Management System, EMS) la flessibilita e necessaria per il sostegno informatico dei processi aziendali. Il sistema R/3 della SAP S.p.a. e molto diffuso sul mercato
americano e europeo degli EMS e si e sviluppato verso uno standard di fatto in questo
settore. L'alto grado d'integrazione di questo sistema permette di modellare i processi
aziendali in una maniera continua. Le ampie possibilita di parametrizzazione offrono la
flessibilita necessaria per l'adattamento alle nuove situazioni dei processi aziendali.
Nello stesso tempo, il prezzo da pagare per i vantaggi sopra indicati e una maggiore
complessita. L'introduzione di un tale sistema non e semplice e pone delle esigenze
considerevoli alla direzione.
Questo lavoro da una visione generale sulla funzionalita et sul processo d'introduzione
di SAP R/3. Inoltre, una parte empirica presenta le esperienze fatte dagli utenti svizzeri
di R/3 durante l'introduzione di SAP R/3. Da li vengono dedotti i fattori di successo critici per l'esecuzione di tale progetti.
II
Vorwort
Vorwort
Die vorliegende Publikation ist Resultat einer mehrjährigen intensiven Beschäftigung mit
dem Einführungsprozess von Enterprise-Management-Systemen in Schweizer Unternehmungen aller Grössenordnungen. Im Mittelpunkt der Betrachtungen steht das R/3System der SAP AG, welches in der Abteilung Information Engineering des Instituts für
Wirtschaftsinformatik der Universität Bern seit 1993 für Forschung und Lehre aktiv eingesetzt wird.
Die vorliegende Fassung entspricht weitgehend einer 1998 an der rechts- und wirtschaftswissenschaftlichen Fakultät der Universität Bern eingereichten Inaugrual-Dissertation. In Abweichung zur Dissertationsfassung wurde die detaillierte Beschreibung der
Funktionalität von SAP R/3 in der vorliegenden Version in das Kapitel 3 eingebunden.
Speziell danken möchte ich meinem Doktorvater Prof. Dr. G. Knolmayer für die Betreuung der Arbeit und die Gewährung eines optimalen Arbeitsumfeldes. Herrn Prof.
Dr. N. Ragaz danke ich für die Erstellung des Zweitgutachtens.
Ferner möchte ich besonders Myriam Hess, Frank Wimmer, Martin Meyer und Dr.
Thomas Myrach und für das Korrekturlesen und die Hilfe beim Erstellen der Grafiken
danken.
Meinen ehemaligen Studenten Stefan Altendorfer, Benno Flury, Jean-Pierre Gerber,
Markus Jaun, Rolf Marchand, Raymond Stebler, Michael Stettler und Susanne Strebi
möchte ich meine Anerkennung für die Bearbeitung einzelner Themengebiete aussprechen.
Hervorheben möchte ich auch die Herren Rico Portner und Christoph Zimmerli, welche Im Rahmen von Lizentiatsarbeiten die empirischen Grundlagen für diese Arbeit erarbeitet haben.
Danken möchte ich ferner der SAP (Schweiz) AG für die Bereitstellung und Betreuung
des R/3-Systems an der Universität Bern sowie der IDS Prof. Scheer GmbH, Saarbrükken für die Bereitstellung des ARIS-Toolsets.
Nicht zuletzt möchte ich einen speziellen Dank an meine Eltern Othmar (†) und Verena
von Arb-Isenschmid richten, welche für mich während den ganzen Jahren eine wichtige
Stütze waren.
III
Vorwort
Ferner möchte ich allen weiteren Personen danken, welche mich in irgendeiner Weise
unterstützt haben und nicht namentlich erwähnt sind.
IV
Inhaltsverzeichnis
Inhaltsverzeichnis
1 EINLEITUNG .......................................................................................................................................... 1
1.1 PROBLEMSTELLUNG............................................................................................................................. 1
1.2 ZIELSETZUNGEN.................................................................................................................................. 2
1.3 FORSCHUNGSMETHODE ...................................................................................................................... 3
1.4 AUFBAU ............................................................................................................................................ 4
2 EVALUATION UND AUSWAHL VON EMS ........................................................................................... 7
2.1 EINLEITUNG ....................................................................................................................................... 7
2.2 ENTERPRISE-MANAGEMENT-SYSTEME (EMS) .......................................................................................... 7
2.2.1 Standardsoftware ..................................................................................................................... 7
2.2.2 Merkmale von EMS................................................................................................................. 10
2.2.3 Vor- und Nachteile von EMS .................................................................................................. 12
2.2.4 Der Markt für Enterprise-Management-Systeme..................................................................... 14
2.2.5 Alternativen zum Einsatz von EMS.......................................................................................... 17
2.2.5.1 Individualsoftware ......................................................................................................................... 17
2.2.5.2 Component Ware.......................................................................................................................... 19
2.3 AUSWAHL VON EMS......................................................................................................................... 25
2.3.1 Vorgehen................................................................................................................................ 25
2.3.2 Ist-Analyse und Soll-Konzept.................................................................................................. 26
2.3.3 Informationsbeschaffung zur Evaluation von EMS .................................................................. 33
2.3.4 Nutzwertanalyse zur Auswahl von EMS.................................................................................. 41
2.3.5 Neuformulierung des Projektauftrages ................................................................................... 44
2.3.6 Begründung der Wahl von SAP R/3 ........................................................................................ 44
2.3.6.1 Beschränkung der Betrachtungen auf ein einziges System ............................................................ 44
2.3.6.2 Argumente für SAP R/3.................................................................................................................. 45
2.3.6.3 Argumente gegen SAP R/3............................................................................................................. 46
3 DAS R/3-SYSTEM.................................................................................................................................. 51
3.1 EINLEITUNG ..................................................................................................................................... 51
3.2 UNTERNEHMENSPROFIL DER SAP AG ................................................................................................. 52
3.2.1 Geschichte ............................................................................................................................. 52
3.2.2 Unternehmensstrategie .......................................................................................................... 53
3.2.3 Produkte ................................................................................................................................ 54
3.2.4 Partnerkonzept....................................................................................................................... 56
3.3 HAUPTANWENDUNGSBEREICHE DES R/3-SYSTEMS ................................................................................ 58
V
Inhaltsverzeichnis
3.3.1 Überblick................................................................................................................................58
3.3.2 Organisationsstrukturen des R/3-Systems ...............................................................................61
3.3.2.1 Grundlegende Organisationseinheiten .......................................................................................... 61
3.3.2.2 Organisationseinheiten der Logistik ............................................................................................... 62
3.3.2.3 Organisationseinheiten des Finanzwesens..................................................................................... 63
3.3.2.4 Organisationseinheiten des Personalwesens.................................................................................. 66
3.3.3 Rechungswesen ......................................................................................................................68
3.3.3.1 FI - Finanzwesen (Financial Accounting) ....................................................................................... 70
3.3.3.2 TR - Treasury ................................................................................................................................. 73
3.3.3.3 CO - Controlling............................................................................................................................ 77
3.3.3.4 IM - Investitionsmanagement ........................................................................................................ 82
3.3.3.5 EC - Unternehmenscontrolling...................................................................................................... 83
3.3.4 Logistik....................................................................................................................................86
3.3.4.1 LO - Logistik allgemein .................................................................................................................. 88
3.3.4.2 SD - Vertriebsabwicklung (Sales & Distribution)............................................................................ 93
3.3.4.3 MM - Materialwirtschaft (Materials Management) ......................................................................... 97
3.3.4.4 PP - Produktionsplanung und -steuerung (Production Planning)................................................ 101
3.3.4.5 QM - Qualitätsmanagement........................................................................................................ 112
3.3.4.6 PM - Instandhaltung (Plant Maintenance) ................................................................................... 115
3.3.4.7 PS - Projektsystem ....................................................................................................................... 119
3.3.5 Personal................................................................................................................................123
3.3.5.1 PA - Personaladministration und - abrechnung ........................................................................... 124
3.3.5.2 PD - Personalplanung und -entwicklung..................................................................................... 127
3.3.6 CA - Anwendungsübergreifende Funktionen ........................................................................129
3.3.6.1 WF - Workflow............................................................................................................................ 130
3.3.6.2 Weitere anwendungsübergreifende Funktionen ......................................................................... 132
3.3.7 IS- Branchenlösungen (Industry Solutions)............................................................................139
3.3.8 BC- Basissystem ....................................................................................................................140
3.3.8.1 Systemverwaltung........................................................................................................................ 140
3.3.8.2 Datenbankverwaltung ................................................................................................................. 141
3.3.8.3 ABAP/4 Development Workbench ............................................................................................. 141
3.3.8.4 Business Engineer ........................................................................................................................ 143
3.4 SYSTEM-ARCHITEKTUR .....................................................................................................................148
4 EINFÜHRUNG VON SAP R/3.............................................................................................................155
4.1 EINLEITUNG ....................................................................................................................................155
4.2 ARTEN VON VORGEHENSMODELLEN ..................................................................................................156
4.3 SAP-VORGEHENSMODELL ................................................................................................................160
4.3.1 Darstellung des SAP-Vorgehensmodells ................................................................................160
VI
Inhaltsverzeichnis
4.3.1.1 Übersicht ..................................................................................................................................... 160
4.3.1.2 Organisation und Konzeption...................................................................................................... 162
4.3.1.3 Detaillierung und Realisierung..................................................................................................... 167
4.3.1.4 Produktionsvorbereitung ............................................................................................................. 171
4.3.1.5 Inbetriebnahme ........................................................................................................................... 174
4.3.2 Kritik am SAP-Vorgehensmodell ........................................................................................... 176
4.4 KRITISCHE ERFOLGSFAKTOREN BEI DER EINFÜHRUNG VON SAP R/3 ..................................................... 178
4.4.1 Das Konzept der kritischen Erfolgsfaktoren .......................................................................... 178
4.4.2 Mögliche Erfolgsfaktoren bei der Einführung von SAP R/3.................................................... 179
4.4.3 Methodische Faktoren.......................................................................................................... 182
4.4.4 Systemtechnische Faktoren .................................................................................................. 200
4.5 BEURTEILUNG DER CSF AUS DER SICHT DER BETROFFENEN ................................................................. 205
4.5.1 Expertenbefragung................................................................................................................ 205
4.5.2 Darstellung der Ergebnisse ................................................................................................... 207
5 BEFRAGUNG ZUR EINFÜHRUNG VON R/3 .................................................................................... 211
5.1 EINLEITUNG ................................................................................................................................... 211
5.2 UNTERSUCHUNGSZIELE ................................................................................................................... 213
5.3 BEFRAGUNGSKONZEPT .................................................................................................................... 214
5.3.1 Bezugsrahmen...................................................................................................................... 214
5.3.1.1 Bezugsrahmen im Überblick ....................................................................................................... 214
5.3.1.2 Unternehmensbezogene Einflussgrössen ..................................................................................... 215
5.3.1.3 Projektbezogene Einflussgrössen.................................................................................................. 216
5.3.1.4 Technische Einflussgrössen (Informatik-Situation)........................................................................ 217
5.3.1.5 Aktionsparameter ........................................................................................................................ 217
5.3.1.6 Zielgrössen................................................................................................................................... 218
5.3.2 Untersuchungshypothesen................................................................................................... 219
5.3.2.1 Hypothesenbildung ..................................................................................................................... 219
5.3.2.2 Hypothesen zu unternehmensbezogenen Bedingungsgrössen .................................................... 219
5.3.2.3 Hypothesen zu Bedingungsgrössen der bisherigen Informatiksituation........................................ 221
5.3.2.4 Hypothesen zu projektbezogenenen Bedingungsgrössen............................................................ 222
5.3.2.5 Hypothesen zu Aktionsparametern ............................................................................................. 223
5.3.3 Methodisches Vorgehen ....................................................................................................... 225
5.3.3.1 Stichprobe ................................................................................................................................... 225
5.3.3.2 Datenerhebung ........................................................................................................................... 226
5.3.3.3 Datenauswertung ........................................................................................................................ 228
5.3.3.4 Statistische Analyseverfahren ....................................................................................................... 228
5.4 DARSTELLUNG DER ERGEBNISSE ........................................................................................................ 232
5.4.1 Konzeptionelle Grundlagen.................................................................................................. 232
VII
Inhaltsverzeichnis
5.4.2 Profil Schweizer R/3-Anwender ............................................................................................232
5.4.2.1 Unternehmensgrösse ................................................................................................................... 232
5.4.2.2 Branchenherkunft........................................................................................................................ 236
5.4.2.3 Umfang des R/3-Einsatzes ........................................................................................................... 238
5.4.3 Evaluation und Produktentscheid.........................................................................................243
5.4.3.1 Auslösende Faktoren ................................................................................................................... 243
5.4.3.2 Intensität der Evaluation .............................................................................................................. 245
5.4.3.3 Konkurrenzprodukte ................................................................................................................... 246
5.4.3.4 Gründe für die Wahl von R/3...................................................................................................... 248
5.4.4 Projektmanagement..............................................................................................................252
5.4.4.1 Hauptproblembereiche ............................................................................................................... 252
5.4.4.2 Rechtliche Aspekte...................................................................................................................... 256
5.4.4.3 Projektorganisation ...................................................................................................................... 258
5.4.4.3.1 Projektgrösse ....................................................................................................................... 258
5.4.4.3.2 Projektverantwortung .......................................................................................................... 259
5.4.4.3.3 Lenkungsausschuss .............................................................................................................. 261
5.4.4.3.4 Zusammensetzung der Projektteams ................................................................................... 262
5.4.4.3.5 Projektleiter ......................................................................................................................... 264
5.4.4.3.6 Unterstützung des Managements ........................................................................................ 267
5.4.4.4 Projektdauer ................................................................................................................................ 268
5.4.4.5 Personaleinsatz während eines Projekts ...................................................................................... 272
5.4.4.6 Beratereinsatz .............................................................................................................................. 274
5.4.4.7 Projektkosten............................................................................................................................... 276
5.4.4.8 Einhaltung der Projektziele.......................................................................................................... 277
5.4.4.9 Methoden und Werkzeuge ......................................................................................................... 280
5.4.4.10 Kritische Erfolgsfaktoren............................................................................................................. 283
5.4.5 Systemtechnisches Umfeld ...................................................................................................285
5.4.5.1 Bisherige Systemarchitektur......................................................................................................... 285
5.4.5.2 Bisherige Softwarearchitektur ...................................................................................................... 286
5.4.5.3 Eingesetzte Systemkomponenten ................................................................................................ 288
5.4.5.4 Systemgrösse................................................................................................................................ 290
5.4.5.5 Integration von Desktop-Applikationen....................................................................................... 291
5.4.5.6 Outsourcing................................................................................................................................. 292
5.4.6 Anpassung des R/3-Systems ..................................................................................................295
5.4.6.1 Anpassung der Organisation und/oder der Software ................................................................... 295
5.4.6.2 Art der Anpassung ....................................................................................................................... 298
5.4.6.3 Schnittstellen ............................................................................................................................... 299
5.4.7 Produktionsvorbereitung und Inbetriebnahme.....................................................................300
5.4.7.1 Datenübernahme ........................................................................................................................ 300
VIII
Inhaltsverzeichnis
5.4.7.2 Schulung...................................................................................................................................... 302
5.4.7.3 Inbetriebnahme ........................................................................................................................... 306
6 MANAGEMENTEMPFEHLUNGEN FÜR DIE ABWICKLUNG VON R/3-PROJEKTEN....................... 309
6.1 EINLEITUNG ................................................................................................................................... 309
6.2 BEDINGUNGSGRÖSSEN .................................................................................................................... 313
6.2.1 Unternehmensgrösse............................................................................................................ 313
6.2.2 Kostenbestimmende Faktoren.............................................................................................. 315
6.2.3 Zeitbestimmende Faktoren................................................................................................... 318
6.3 AKTIONSPARAMETER........................................................................................................................ 320
6.3.1 Übersicht.............................................................................................................................. 320
6.3.2 Projektorganisation .............................................................................................................. 321
6.3.3 Projektabwicklung................................................................................................................ 327
6.3.4 Würdigung der kritischen Erfolgsfaktoren............................................................................. 331
7 ZUSAMMENFASSUNG UND AUSBLICK .......................................................................................... 333
7.1 ZUSAMMENFASSUNG ....................................................................................................................... 333
7.2 AUSBLICK....................................................................................................................................... 338
LITERATURVERZEICHNIS..................................................................................................................... 341
ANHANG A : ERFOLGSFAKTOREN ...................................................................................................... 353
ANHANG B : FRAGEBOGEN DER UMFRAGE VOM JULI 1996 .......................................................... 355
ANHANG C : STATISTISCHE ANALYSEN ............................................................................................. 367
INDEX .....................................................................................................................................................407
IX
Abbildungsverzeichnis
Abb. 1-1: Aufbau. ...................................................................................................................................... 5
Abb. 2-1: Marktanteile von EMS-Herstellern im Industriesektor 1995. ................................................... 15
Abb. 2-2: Die Positionierung verschiedener Anbieter von EMS 1995. .................................................... 16
Abb. 2-3: Component-Ware-Architektur der OMG. ............................................................................... 21
Abb. 2-4: Beispiel für ein auf dem Component-Ware-Prinzip basierendes PPS-System. ........................ 22
Abb. 2-5: Business Framework der SAP................................................................................................... 23
Abb. 2-6: Anwendungsbereiche von Add-On-Produkten für das R/3-System......................................... 24
Abb. 2-7: Auswahlverfahren von EMS. .................................................................................................... 25
Abb. 2-8: Continous System Engineering vs. Business Process Reengineering......................................... 27
Abb. 2-9: Ergebnisse einer Internet-Recherche mit Hotbot nach dem Suchbegriff 'ERP'........................ 36
Abb. 2-10: Web-Seite einer Online-Zeitschrift zum Thema 'ERP'........................................................... 37
Abb. 2-11: Auszug R/3-WWW-Seite des Instituts für Wirtschaftsinformatik der Universität Bern
(Stand: 17.03.1997)............................................................................................................... 39
Abb. 2-12: Verwendung der Nutzwertanalyse für die Auswahl von EMS. .............................................. 42
Abb. 3-1: Entstehungsgeschichte der SAP AG.......................................................................................... 52
Abb. 3-2: Das Vertriebskonzept der SAP AG........................................................................................... 56
Abb. 3-3: Modulgliederung des R/3-Systems........................................................................................... 59
Abb. 3-4: Grundlegende Organisationseinheiten des R/3-Systems. ........................................................ 62
Abb. 3-5: Organisationseinheiten der Logistik. ........................................................................................ 63
Abb. 3-6: Rechtliche Organisationsstruktur des Finanzwesens. ............................................................... 64
Abb. 3-7: Organisationseinheiten des Personalwesens............................................................................ 67
Abb. 3-8: Module des Rechnungswesens. ............................................................................................... 69
Abb. 3-9: Komponenten des Finanzwesens............................................................................................. 70
Abb. 3-10: Teilkomponenten des Treasury-Moduls. ............................................................................... 73
Abb. 3-11: Komponenten des Controllings. ............................................................................................ 78
Abb. 3-12: Prinzip der Prozesskostenrechnung. ...................................................................................... 81
Abb. 3-13: Komponenten des Unternehmenscontrollings. ..................................................................... 83
Abb. 3-14: Module des Hauptanwendungsbereichs Logistik................................................................... 86
Abb. 3-15: Komponenten des Anwendungsbereichs "Logistik allgemein". .............................................. 88
Abb. 3-16: Komponenten des Logistikinformationssystems..................................................................... 92
XI
Abb. 3-17: Komponenten der Vertriebsabwicklung.................................................................................93
Abb. 3-18: Komponenten der Materialwirtschaft.....................................................................................98
Abb. 3-19: Komponenten der Produktionsplanung und -steuerung......................................................102
Abb. 3-20: Spezielle Komponenten der Produktionsplanung und -steuerung.......................................109
Abb. 3-21: Komponenten der Qualitätssicherung..................................................................................113
Abb. 3-22: Komponenten der Instandhaltung. .......................................................................................115
Abb. 3-23: Komponenten des Projektsystems........................................................................................120
Abb. 3-24: Komponenten der Personaladministration und -abrechnung. .............................................124
Abb. 3-25: Komponenten der Personalplanung und -entwicklung........................................................127
Abb. 3-26: ALE-Szenarien. .....................................................................................................................135
Abb. 3-27: Zugriffsmöglichkeiten auf R/3 über Intra-/Internet...............................................................136
Abb. 3-28: Anbindung an R/3 über einen Internet Transaction Server. .................................................137
Abb. 3-29: Anbindung an R/3 über SAP-Automation. ...........................................................................138
Abb. 3-30: Komponenten von SAP Business Workflow.........................................................................146
Abb. 3-31: Schichtenarchitektur des R/3-Systems..................................................................................148
Abb. 3-32: Mögliche Hardware- und Systemsoftwareplattformen für das R/3-System..........................149
Abb. 3-33: Konfigurationsmöglichkeiten des R/3-Systems. ....................................................................150
Abb. 3-34: Integration von R/3 in das Internet.......................................................................................152
Abb. 4-1: Grundtypen von Vorgehensmodellen zur Einführung von Informationsystemen. .................157
Abb. 4-2: SAP-Vorgehensmodell............................................................................................................161
Abb. 4-3: Aktivitäten der Phase "Organisation und Konzeption"............................................................162
Abb. 4-4: Aktivitäten der Phase "Detaillierung und Realisierung"...........................................................167
Abb. 4-5: Aktivitäten in der Phase "Produktionsvorbereitung". ..............................................................171
Abb. 4-6: Aktivitäten in der Phase "Inbetriebnahme". ............................................................................174
Abb. 4-7: Mögliche Erfolgsfaktoren bei der Einführung von SAP R/3.....................................................181
Abb. 4-8: Einbeziehung des Managements in R/3-Einführungsprojekte ................................................183
Abb. 4-9: BPR-Varianten bei der Einführung von EMS. .........................................................................185
Abb. 4-10: Mögliche Evaluationskriterien für die Bewertung von EMS..................................................189
Abb. 4-11: Big Bang vs. Step-by-Step-Einführung. .................................................................................192
Abb. 4-12: Mögliches Anforderungsprofil an einen R/3-Projektleiter. ...................................................194
Abb. 4-13: Paarweise Bewertung von Erfolgsfaktoren bei der Einführung von SAP R/3. .......................206
XII
Abb. 4-14: Bewertung der Erfolgsfaktoren (Anwender und Berater). .................................................... 207
Abb. 4-15: CSF aus der Sicht von Anwendern und Beratern. ............................................................... 208
Abb. 5-1: Explorativer Forschungsprozess.............................................................................................. 212
Abb. 5-2: Bezugsrahmen für die Einflussgrössen von Kosten und Dauer einer R/3-Einführung. ........... 215
Abb. 5-3: Vorgehen bei der Datenerhebung. ........................................................................................ 226
Abb. 5-4: Jahresumsatz der untersuchten Unternehmungen. ............................................................... 233
Abb. 5-5: Beschäftigtenzahl der untersuchten Unternehmen................................................................ 234
Abb. 5-6: Grössenverteilung der Unternehmen mit maximal 500 Beschäftigten. ................................. 234
Abb. 5-7: Branchenzugehörigkeit der R/3-Anwender............................................................................ 236
Abb. 5-8: Eingeführte Module. .............................................................................................................. 239
Abb. 5-9: Moduleinsatz in der Industrie. ............................................................................................... 240
Abb. 5-10: Moduleinsatz im Handel. .................................................................................................... 240
Abb. 5-11: Moduleinsatz in der Dienstleistungssektor........................................................................... 241
Abb. 5-12: Ausdehnung des R/3-Einsatzes (Heute - In Zukunft). .......................................................... 242
Abb. 5-13: Auslösende Faktoren für die Evaluation von EMS................................................................ 244
Abb. 5-14: In Konkurrenz zu R/3 evaluierte Produkte........................................................................... 247
Abb. 5-15: Ausschlaggebende Argumente für SAP R/3.......................................................................... 249
Abb. 5-16: Bedeutung von Internet Computing (Sommer 1996). ......................................................... 250
Abb. 5-17: Bedeutung von Internet Computing in Zukunft................................................................... 251
Abb. 5-1: Kritische Problembereiche in den R/3-Einführungsprojekten. ............................................... 252
Abb. 5-2: Hauptprobleme des Projektleiters. ........................................................................................ 253
Abb. 5-3: Rechtliche Probleme bei Einführung von R/3. ....................................................................... 257
Abb. 5-4: Budgets der einführenden Unternehmen.............................................................................. 258
Abb. 5-5: Anzahl Projekte in den Unternehmungen. ............................................................................ 259
Abb. 5-6: Projektverantwortungen......................................................................................................... 260
Abb. 5-7: Mitglieder des Lenkungsausschusses...................................................................................... 262
Abb. 5-8: Typische Projektgruppe.......................................................................................................... 263
Abb. 5-9: Herkunft des Projektleiters..................................................................................................... 265
Abb. 5-10: Eigenschaften eines Projektleiters. ....................................................................................... 266
Abb. 5-11: Unterstützung des Projektleiters durch das Management.................................................... 267
Abb. 5-12: Einführungszeiten von R/3-Projekten 1995 weltweit (Anbieterangaben). ........................... 268
XIII
Abb. 5-13: Einführungszeit von SAP R/3-Projekten in der Schweiz. ......................................................269
Abb. 5-14: Vergleich des Projektaufwands im Zeitablauf. .....................................................................272
Abb. 5-15: Personaleinsatz während der Durchführung von R/3-Projekten..........................................273
Abb. 5-16: Beratungspartner in R/3-Projekten. ......................................................................................274
Abb. 5-17: Kostenaufteilung bei der Einführung von R/3.......................................................................276
Abb. 5-18: Zieleinhaltung in R/3-Projekten............................................................................................278
Abb. 5-19: Reaktion auf Zielabweichungen...........................................................................................279
Abb. 5-20: Verwendete Vorgehensmodelle...........................................................................................281
Abb. 5-21: Verwendete Tools. ...............................................................................................................282
Abb. 5-22: Kritische Erfolgsfaktoren bei der Einführung von SAP R/3....................................................283
Abb. 5-23: Ursprüngliche Hardwarekonfiguration.................................................................................286
Abb. 5-24: Durch R/3 ersetzte Softwarekategorien................................................................................287
Abb. 5-25: Eingesetzte Systemkomponenten.........................................................................................289
Abb. 5-26: Anteile der Unix-Betriebssysteme ........................................................................................290
Abb. 5-27: Entwicklung der Systemgrösse.............................................................................................291
Abb. 5-28: Integration von Fremdprodukten. ........................................................................................292
Abb. 5-29: Outsourcingvarianten von R/3..............................................................................................294
Abb. 5-30: Organisatorische Anpassung.................................................................................................296
Abb. 5-31: Art der Anpassung von R/3 an die betriebliche Umgebung. ................................................299
Abb. 5-32: Übernahme von Stammdaten und Bewegungsdaten. .........................................................301
Abb. 5-33: Probleme bei der Datenübernahme. ...................................................................................301
Abb. 5-34: Art der Schulung. .................................................................................................................304
Abb. 5-35: Verwendetes Schulungssystem.............................................................................................305
Abb. 5-36: Form der Anwenderunterstützung. ......................................................................................307
Abb. 6-1: Bedingungsgrössen und Aktionsparameter bei der Einführung von SAP R/3. ........................312
Abb. 6-2: Einsatz von R/3 im Mittelstand. ..............................................................................................314
Abb. 6-3: Kritische Erfolgsfaktoren bei der Einführung von SAP R/3......................................................321
Abb. 6-4: Reengineering-Varianten bei der Einführung von SAP R/3.....................................................329
XIV
Tabellenverzeichnis
Tabellenverzeichnis
Tab. 2-1: Alternative Begriffe für Enterprise-Management-Systeme. ....................................................... 12
Tab. 2-2: Vor- und Nachteile von Enterprise-Management-Systemen. ................................................... 13
Tab. 2-3: Prozessbeschreibung der Nachbestellung eines Lagerartikels................................................... 28
Tab. 2-4: Kriterien zur Auswahl von EMS. ............................................................................................... 33
Tab. 2-5: Mögliche Informationsquellen zur Auswahl von EMS. ............................................................. 34
Tab. 2-6: Internet Search Engines. ........................................................................................................... 35
Tab. 2-7: Übersicht über weltweit eingesetzte EMS. ............................................................................... 38
Tab. 3-1: R/3-Module und deren Komponenten..................................................................................... 60
Tab. 5-1: Übersicht zu den verschiedenen Skalentypen........................................................................ 228
Tab. 5-2: Masszahlen der deskriptiven Statistik. .................................................................................... 229
Tab. 5-3: Irrtumswahrscheinlichkeiten und Signifikanzniveaus. ............................................................ 230
Tab. 5-4: Übersicht über die verwendeten Korrelationsanalyseverfahren. ........................................... 231
Tab. 5-5: Hersteller von in der Schweiz evaluierten EMS...................................................................... 248
Tab. 5-6: Prozessmodellierungswerkzeuge zur Unterstützung der R/3-Einführung............................... 280
Tab. 6-1: Unterschiede bei R/3-Einführungen zwischen KMUs und Grossunternehmen...................... 313
XV
Abkürzungsverzeichnis
ABAP/4
Advanced Business Application Programming (4. Generation)
ALE
Application Link Enabling
AM
Anlagenwirtschaft
AMR
Advanced Manufacturing Research
API
Application Programming Interface
ASAP
Accelerated SAP
ATP
Available To Promise
BAPI
Business Application Programming Interface
BEW
Business Engineering Workbench
BOR
Business Object Repository
BPCS
Business Planning and Control System
CA
Computer Associates
CA
Cross Applications
CAD
Computer Aided Design
CASE
Computer Aided Software Engineering
CATT
Computer Aided Test Tool
CCMS
Computing Center Management System
CI
Coded Information
CIQ
Computer Integrated Quality Management
CO
Controlling
CO-ABC
Controlling - Activity Based Costing
CO-CCA
Controlling - Kostenstellenrechnung
CO-OPA
Controlling - Order Project Accounting
CO-PA
Controlling - Ergebnis- und Marktsegmentrechnung (Profitability Analysis)
CO-PC
Controlling - Product Costing
CO-PCA
Controlling - Profit-Center-Rechnung (Profit Center Accounting)
CORBA
Common Object Request Broker Architecture
CPI-C
Common Programming Interface-Communication
CSE
Continous System Engineering
CSF
Critical Success Factors (Kritische Erfolgsfaktoren)
DAX
Deutscher Aktienindex
DCE
Distributed Computing Environment
DTA
Datenträgeraustausch
DVS
Dokumentenverwaltungssystem
EDI
Electronic Data Interchange
EIS
Executive Information System
EPK
Ereignisgesteuerte Prozessketten
ERM
Entity-Relationship-Modell
FAZ
Frankfurter Allgemeine Zeitung
FI
Finanzwesen
GES
Geschäftsprozessorientierte Einführung von Standardsoftware
GIS
Geographisches Informationssystem
XVII
GL
Geschäftsleitung
GUI
Graphical User Interface
HIPO
Hierarchy of Input-Process-Output
HR
Personalwirtschaft
HTTP
Hypertext Transfer Protocol
IBIS
Integriertes Börsenhandels- und Informationssystem
IDES
International Demo and Education System
IDoc
Intermediate Document
IH
Instandhaltung
IMG
Implementation Guide
IPP
Iteratives Prozess-Prototyping
IS
Branchenlösungen (Industry Solutions)
ISW
Individualsoftware
IT
Information Technology
IV
Informationsverarbeitung
JDE
JD Edwards
JIT
Just in Time
KMU
Kleine und mittelgrosse Unternehmungen
MM
Materialwirtschaft
MS
Microsoft
NC
Network Computer
NCI
Non Coded Information
OLE
Object Linking and Embedding
OMG
Object Management Group
OMT
Object Modeling Technique
OOP
Objektorientierte Programmierung
ORB
Object Request Broker
OSS
Online Support System
PDC
Plant Data Collection
PM
Instandhaltungssystem
PP
Produktionsplanungs- und -steuerungssystem
PP-PI
Produktionsplanung für die Prozessindustrie
PPS
Produktionsplanung und -steuerung
PS
Projektsystem
PSP
Projektstrukturplan
QM
Qualitätssicherungssystem
R/2
Realtime-System 2
R/3
Realtime-System 3
RDBMS
Relationales Datenbank-Management-System
RFC
Remote Function Call
ROI
Return on Investment
SA
Structured Analysis
SADT
Structured Analysis and Design Technique
SAP
System, Anwendungen und Produkte in der Datenverarbeitung
XVIII
SAPGUI
Graphische Benutzeroberfläche der SAP
SD
Vertriebssystem
SD-IS
Vertriebsinformationssystem
SERM
Strukturiertes Entity-Relationship-Modell
SMA
Servicemanagement
SOP
Sales & Operation Planning
SSA
Systems Software Accociates
SSW
Standardsoftware
TCP/IP
Transfer Control Protocol/Internet Protocol
USD
U.S. Dollar
WF
Workflowmanagementsystem
WWW
World Wide Web
XXL
Extended Export of Lists
XIX
Einleitung
1 Einleitung
1.1 Problemstellung
Eine veraltete betriebswirtschaftliche Anwendungsplattform ist in vielen Unternehmen
der Auslöser für die Beschaffung eines modernen integrierten Standardanwendungssystems.1 Die Gründe für die unzureichende Abdeckung der betrieblichen Erfordernisse
durch die vorhandenen Altsysteme sind vielfältig. Häufig sind hohe Kosten, fehlende
Integration, unzureichende Flexibilität ("Jahr 2000-Problem", Veränderung gesetzlicher
Vorschriften etc.) oder eine veraltete Systemarchitektur die Hauptgründe für den Ersatz
der bisherigen Systeme.
Enterprise-Management-Systeme (EMS) der neuesten Generation (z.B. SAP R/3, Oracle
Applications oder Baan) decken weite Bereiche des betriebswirtschaftlichen Anwendungsspektrums ab. Sie bilden dadurch gleichzeitig eine Basis für die Optimierung von
Geschäftsprozessen.2 Durch die Integration der betriebswirtschaftlichen Funktionen und
die Online-Verarbeitung der Daten sind entscheidrelevante Informationen schneller und
in besserer Qualität verfügbar.
Die Einführung solcher Systeme verursacht aber meist hohe Kosten und stellt dementsprechend hohe Anforderungen an das Projektmanagement.3 In vielen Unternehmungen ist das Know-how für die Abwicklung von Grossprojekten nicht vorhanden.4 Dies
führt zu entsprechenden Problemen bei der Einführung eines EMS.
Die Probleme sind mannigfaltig und wirken sich primär auf die Kosten und die Dauer
eines Projektes aus.5 Der Grund für die grossen Zeit- und Kostenabweichungen ist vor
allem auf den Mangel an Erfahrungen mit solchen Projekten im Hinblick auf die Abschätzung der Projektdimension und das Fehlen von Hinweisen auf die erfolgsentscheidenden Faktoren zurückzuführen.
1
2
3
4
5
Vgl. Knolmayer/Portner/von Arb (1995), S. 12.
Vgl. Brenner/Keller (1995); Hammer/Champy (1994) S. 48; Österle (1995), S. 13; Zencke (1994).
Vgl. Balmer/Mirchandani (1996); Keller et al. (1996).
Mirchandani/Digrius (1996).
Vgl. z.B. Cameron et al. (1996); Eberlein/Koopmann/Okroy (1995); Mirchandani/Digrius (1996).
1
Einleitung
Da im Bereich des Einsatzes von EMS Wachstumsraten6 von 30-40% bis weit über den
Jahrtausendwechsel hinweg prognostiziert werden, ist ein entsprechend hohes Interesse
an Untersuchungen bezüglich Erfahrungen mit solchen Systemen zu erwarten. Der Gegenstand der vorliegenden Arbeit setzt sich aus diesem Grund vor allem mit der Problematik der Einführung von EMS auseinander.
1.2 Zielsetzungen
Die Einführung von EMS wird durch die verschiedensten Faktoren beeinflusst. Darunter
fallen u.a. betriebswirtschaftliche, systemtechnische und arbeitspsychologische Aspekte.
Dieser Facettenreichtum macht es schwierig, auf Anhieb die Ursachen für die vorhandenen Probleme zu bestimmen. Aus diesem Grund soll mit dieser Publikation das Ziel
verfolgt werden, die massgebenden Einfluss- und Regelgrössen für das Management von
EMS-Projeken zu bestimmen, um daraus Handlungsanweisungen für die konkrete Gestaltung des Einführungsprozesses abzuleiten. Die sich daraus ergebenden Ziele können
wie folgt formuliert werden:
• Schaffung eines Bewusstseins für die Komplexität und den Nutzen von EMS
• Sensibilisierung auf die Problemstellungen von EMS-Projekten durch Skizzierung des
Einführungsprozesses
• Untersuchung des Problemspektrums bei der Einführung von EMS
• Ableitung der projektbestimmenden Faktoren und Ermittlung der kritischen Erfolgsgrössen
• Herleitung von Schätzgrössen und Regeln für das Management zur erfolgreichen
Abwicklung von EMS-Projekten.
EMS-Projekte werden insbesondere von Anwendern häufig mit der Einführung von integrierten Anwendungssystemen für den Bürokommunikationsbereich (z.B. MS-Office)
verglichen. Diesem schwerwiegenden Irrtum soll durch die ausführliche Darstellung der
verschiedenen Anwendungsbereiche von SAP R/3 entgegengewirkt werden.
6
2
Vgl. Shepard (1996).
Einleitung
Die Einführung und Wartung eines EMS kann bis zu dreistelligen Millionenbeträgen erfordern und mehrere Jahre in Anspruch nehmen. Die Abwicklung von EMS-Projekten
unterscheidet sich in Teilbereichen deutlich von herkömmlichen Softwareentwicklungsprojekten. Durch die Darstellung des Einführungsprozesses von EMS anhand des SAPVorgehensmodells werden die Eigenheiten solcher Projekte deutlich.
Da bisher kaum strukturierte Informationen zu Erfahrungen bei der Einführung von EMS
vorliegen, wird mit der Durchführung von Expertenbefragungen und einer quantitativen
Untersuchung das Sammeln von Informationen zu Erfahrungen mit der Einführung von
R/3 bezweckt. Aus den daraus gewonnen Informationen sollen anschliessend die Bestimmungsgrössen und die erfolgsbeeinflussenden Steuergrössen von R/3-Projekten ermittelt und daraus Gestaltungsempfehlungen für den Einführungsprozess abgeleitet
werden.
1.3 Forschungsmethode
Zur Erreichung der gesetzten Ziele muss ein entsprechendes Forschungskonzept entworfen werden. Dieses stützt sich auf Gestaltungsempfehlungen zur Aufstellung eines
Konzeptionsrahmens und der Ableitung eines Entscheidungsrahmens.7 Der Konzeptionsrahmen umfasst das Begriffs- und Hypothesenschema. Dieses ist primär auf die
"Beschreibung und Erklärung realer Phänomene"8 ausgerichtet. Die nachfolgende Ableitung eines Entscheidungsrahmen bezweckt die Angabe von Handlungsempfehlungen
auf der Grundlage der ermittelten Ergebnisse.
Die Aufstellung des Begriffs- und Hypothesenschemas erfolgt in einem mehrstufigen
Prozess. Vorerst werden auf der Basis von Literaturrecherchen die theoretischen
Grundlagen (begriffliches Instrumentarium) erarbeitet. Ergänzend dazu werden die Ergebnisse einer empirischen Voruntersuchung und eigene Erfahrungen zur Aufstellung
des Bezugsrahmens herangezogen.
7
8
Grochla (1978), S. 62 f.
Grochla (1978) S. 62.
3
Einleitung
Auf der nächsten Stufe folgt eine Präzisierung des Bezugsrahmens durch eine qualitative
Untersuchung unter Anwendung teilstandardisierter Interviews. Aufgrund dieser Ergebnisse lässt sich der vorhandene Bezugsrahmen vervollständigen und damit wird die
Grundlage für die Durchführung einer quantitativen Untersuchung geschaffen. Diese
wird durch schriftliche Befragung aller Schweizer R/3-Anwender9 vorgenommen.
Die Auswertung der gesammelten Daten erfolgt mit den Methoden der empirischen
Sozialforschung. Aus diesen Ergebnissen werden anschliessend Handlungsempfehlungen für den Einführungsprozess von EMS abgeleitet.10
1.4 Aufbau
Die Gliederung dieser Arbeit richtet sich an den dargestellten Zielsetzungen und der
gewählten Forschungsmethode (vgl. Abb. 1-1). Die Kapitel 2, 3 und 4 dienen der Erarbeitung der Grundlagen.
In Kapitel 2 wird der Evaluationsprozess von EMS dargestellt und die Wahl von SAP R/3
für die weiteren Untersuchungen begründet. Kapitel 3 widmet sich der Beschreibung
der Hauptanwendungsbereiche und der Systemarchitektur von SAP R/3. In Kapitel 4
wird zunächst der Einführungsprozess von EMS am Beispiel des SAP-Vorgehensmodells
näher betrachtet. Die Beschreibung möglicher Erfolgsfaktoren für R/3-Projekte und die
Darstellung der Ergebnisse einer Expertenbefragung erfolgt im zweiten Teil des Kapitels.
In Kapitel 5 werden die Ergebnisse der quantitativen Untersuchung zu Erfahrungen bei
der Einführung von SAP R/3 in Schweizer Unternehmungen dargestellt. Dabei werden
alle Aspekte des Einführungprozesses mit einem Schwergewicht auf den im vorangehenden Kapitel untersuchten Erfolgsfaktoren behandelt. In Kapitel 6 werden aus den
gewonnenen Erkenntnissen Schätzgrössen zur Ermittlung des Projektvolumens und Management-Regeln zur Gestaltung des Einführungsprozesses abgeleitet.
9
10
4
Mit dem Begriff R/3-Anwender werden im folgenden Unternehmungen bezeichnet, welche auf der
betriebswirtschaftlichen Anwendungsplattform das R/3-System der SAP AG einsetzen.
Weitere Details zum Forschungsdesign können Abschnitt 5.3 entnommen werden.
Einleitung
Die Zusammenfassung in Kapitel 7 widmet sich den grundlegenden Erkenntnissen dieser Arbeit und in einem kurzen Ausblick werden mögliche Entwicklungstendenzen im
Umfeld von EMS aufgezeigt.
1
Einleitung
Problemstellung, Zielsetzungen, Forschungsmethode, Aufbau
2
Evaluation und Auswahl von EMS
Def. Enterprise-Managment-Systeme (EMS), Marktübersicht, Alternativen zum Einsatz von EMS,
Auswahl von EMS, Begründung der Wahl von SAP R/3
3
Das R/3-System
Unternehmensprofil der SAP AG, Hauptanwendungsbereiche des R/3-Systems, Systemarchitektur
4
Einführung von SAP R/3
Arten von Vorgehensmodellen, SAP-Vorgehensmodell, Kritische Erfolgsfaktoren bei der Einführung von
SAP R/3 (Expertenbefragung)
5
Befragung zur Einführung von SAP R/3
Untersuchungsziele, Befragungskonzept, Darstellung der Ergebnisse
6
Management-Empfehlungen für R/3-Projekte
Bedingungsgrössen (Unternehmensgrösse, zeit- und kostenbestimmende Faktoren), Aktionsparameter
zur Projektorganisation und Projektdurchführung
7
Zusammenfassung und Ausblick
Abb. 1-1: Aufbau.
5
2 Evaluation und Auswahl von EMS
2.1 Einleitung
Für die Bezeichnung von betriebswirtschaftlich-administrativer Standardanwendungssoftware sind in der Literatur sehr unterschiedliche Begriffe11 (z.B. ERP, EMS oder IBSIS)
zu finden.12 Im folgenden Kapitel werden die Eigenschaften solcher Systeme (Vor- und
Nachteile) beschrieben und eine Begriffsabgrenzung vorgenommen.
Der zweite Teil dieses Kapitels setzt sich mit Auswahlkriterien und Informationsbeschaffungsmöglichkeiten für die Evaluation von solchen Systemen auseinander. Dabei
wird ein grober Überblick über die aktuell auf dem Markt befindlichen Systeme gegeben und mögliche Alternativen zum Einsatz von Enterprise-Management-Systemen
(EMS) diskutiert.
2.2 Enterprise-Management-Systeme (EMS)
2.2.1 Standardsoftware
Der Begriff "Standardsoftware" (SSW) stammt aus dem Marketingumfeld und war während langer Zeit in den einschlägigen Begriffsnormen nicht zu finden.13 Dessen unklare
Bedeutung14 wurde erst im Verlaufe der achtziger Jahre konkreter beschrieben.15 Zwei
Definitionen, welche das heutige Verständnis von Standardsoftware im betrieblichen
Umfeld recht gut umschreiben, werden im folgenden wiedergegeben.16
11
12
13
14
15
16
Vgl. z.B. Barbitsch (1996), S. 9; www.gartner.com; www.ramco.com.
Vgl. Barbitsch (1996), S. 13.
Vgl. Ludewig (1994), S. 4.
Vgl. Horváth/Petsch/Weihe (1983), S. 6.
Vgl. Heinrich/Roithmayr (1986), S. 383; Horváth/Petsch/Weihe (1983), S. 4f.; Mertens et al. (1990),
S. 400 ff.; Österle (1990a), S. 15.
Vgl. Ludewig (1994), S. 4 ff.; Stahlknecht (1995), S. 312 ff.
7
Ludewig definiert Standardsoftware als "komplexe Anwendungssoftware, die ein Hersteller für den Markt entwickelt und anbietet, ein Anbieter kauft, anpasst oder häufiger
vom Hersteller anpassen lässt und einführt. Die Anpassung kann auf verschiedene Weise
erfolgen; lassen sich kleine Software-Systeme schon durch Parametrisierung oder durch
gezielte Eingriffe an definierten Schnittstellen adaptieren, so wird sie bei grösseren Systemen kaum ohne erhebliche Eingriffe in die Software zu erreichen sein. Der Anwender
muss sich umgekehrt auch der Software anpassen. Anpassung und Wartung werden um
so aufwendiger, je mehr "freie" Eingriffe in der Software nötig sind, also Änderungen an
Stellen, die nicht speziell dafür gemacht waren. Der Einsatz einer Standard-Software
macht den Anwender wegen des Wartungsbedarfs für lange Zeit sehr abhängig vom Hersteller."17
Mertens versteht unter Standardsoftware "Computerprogramme ("Standardprogramme"),
die
• eine definierte Funktion, d.h. eine genau beschriebene Problemlösung übernehmen,
• generell, d.h. für unterschiedliche Hardware bzw. Betriebssysteme sowie weitgehend
branchenunabhängig einsetzbar sind,
• in der Regel zu einem Festpreis angeboten werden und
• sich mit geringem, zeitlich und finanziell fixierbarem Aufwand organisatorisch anpassen lassen."18
Anhand der Definitionen wird deutlich, dass bei der Beschreibung des Begriffs
"Standardsoftware" verschiedenste Dimensionen berücksichtigt werden müssen. Grundsätzlich wird Standardsoftware für einen anonymen Markt entwickelt und lässt sich
weitgehend branchen- und plattformunabhängig einsetzen. Die Preise sind im voraus
festgelegt und hängen meist von der Anzahl Nutzer und bei modularisierten Systemen in
der Regel auch vom funktionalen Nutzungsgrad ab. Den unterschiedlichen Bedürfnissen
der Anwender wird durch vielfältige Anpassungmöglichkeiten (Customizing) Rechnung
17
18
8
Vgl. Ludewig (1994) S. 8.
Vgl. Mertens (1990), S. 400.
getragen. Ferner wird davon ausgegangen, dass sich der Anwender ebenfalls in einem
gewissen Grad an die durch die erworbenen Produkte vorgegebenen Abläufe anpasst.
Unter Berücksichtigung dieser Aspekte wird der Begriff "Standardsoftware" in dieser Arbeit wie folgt definiert:
Definition:
Unter Standardsoftware sind komplexe Anwendungssysteme zu verstehen, die für den anonymen
Markt entwickelt werden und sich weitgehend branchen- und plattformunabhängig verwenden lassen. Das Einsatzgebiet bezieht sich entweder auf einen oder mehrere Funktionsbereiche eines Unternehmens. Beim Erwerb solcher Systeme gilt in der Regel ein aufgrund der Benutzerzahl und des
Nutzungsumfangs angesetzter Festpreis. Die Integration von Standardsoftware kann sowohl durch
Abstimmung des Anwendungspaketes auf die Unternehmensprozesse (Customizing) als auch durch
Anpassung der betrieblichen Organisation an das erworbene Produkt erfolgen.
Die Einsatzgebiete von Standardsoftware lassen sich grundsätzlich in die Bereiche
• Systemsoftware
• mathematisch-technische Anwendungssoftware und
• betriebswirtschaftlich-administrative Anwendungssoftware
unterteilen.19 Zur Systemsoftware werden u.a. Betriebssysteme (z.B. Unix oder Windows NT) und Datenbanksysteme (z.B. Oracle) gezählt. Mathematisch-technische Anwendungssoftware umfassen vor allem auf mathematischen und statistischen Methoden
basierende Softwarepakete des technisch-wissenschaftlichen Anwendungsbereichs (z.B.
CAD-Systeme, Baustatik-Systeme oder Optimierungspakete).
Das Einsatzgebiet der betriebswirtschaftlich-administrativen Anwendungssoftware bezieht sich auf die klassischen betrieblichen Funktionsbereiche wie z.B. Finanz- und
Rechnungswesen, Personalwesen, Beschaffung, Produktion und Vertrieb. Im den folgenden Ausführungen ist der Begriff "Standardsoftware" immer unter dem Hintergrund
von betriebswirtschaftlich-administrativer Anwendungssoftware zu verstehen.
19
Vgl. Mertens (1990), S. 401.
9
2.2.2 Merkmale von EMS
Enterprise-Management-Systeme richten sich in ihrem Wesen grundsätzlich nach dem
im vorangegangenen Unterkapitel für Standardsoftware im betriebswirtschaftlichadministrativen Umfeld dargestellten Begriffsverständnis. Darüber hinaus verfügen solche Systeme aber über zusätzliche gemeinsame Merkmale20, welche vor einer eigentlichen Begriffsdefinition näher betrachtet werden sollen.
• Integration
EMS decken die administrativen Funktionen (Finanz- und Rechnungswesen, Beschaffung, Produktion, Vertrieb und Personalwesen) eines Unternehmens breit ab
und orientieren sich an durchgängigen Geschäftsprozessen. Alle Anwendungsbereiche verfügen über die gleiche Datenbasis. Dadurch kann eine redundante Datenhaltung weitgehend verhindert und die Datenkonsistenz in hohem Masse gewährleistet werden. Ferner erfolgt die Integration auch in vertikaler Richtung, indem sämtliche Führungsebenen (von der Unternehmensleitung bis zum Sachbearbeiter) bei der
Informationsverarbeitung berücksichtigt werden. Auf der Ebene der Führung findet
ebenfalls eine Integration statt. Die verschiedenen Aktivitäten während des Führungsprozesses auf strategischer und operativer Ebene (Planung, Durchführung und
Kontrolle) werden durch EMS unterstützt.21
• Flexibilität
Die Flexibilität eines EMS bezieht sich grundsätzlich auf die Anpassungsfähigkeit eines Systems in technischer und betriebswirtschaftlicher Sicht.
In technischer Hinsicht lassen sich EMS meist auf mehreren Hardwarewareplattformen und Betriebssystemen einsetzen. Durch die generelle Orientierung an den Prinzipien von Client/Server-Architekturen und durch die Unterstützung offener Standards (z.B. CORBA, COM oder DCE) entstehen umfangreiche Skalierungsmöglichkeiten.
20
21
10
Vgl. Barbitsch (1996), S. 3 f.; Buck-Emden/Galimow (1995), S. 88; CDI (1996b), S. 21 ff.
Vgl. Österle (1990a), S. 15.
Auf betriebswirtschaftlicher Ebene bieten EMS zur Abdeckung von Geschäftsprozessen meist verschiedene Alternativen an. Die Anpassung (Customizing) erfolgt dabei
entweder durch Parametersetzung oder durch Eingriffe an definierten Schnittstellen.
In Ausnahmefällen können sogar Veränderungen am Source Code vornehmen. Im
letztgenannten Fall erhöht sich aber der Wartungsaufwand (Releasewechsel) in erheblichem Umfang.
• Internationalität
Durch die Globalisierung der Märkte operieren viele grössere Unternehmen im internationalen Umfeld. Zur Abdeckung der damit verbundenen Bedürfnisse unterstützen EMS meist mehrere Sprachen und erfüllen die gesetzlichen Anforderungen der
wichtigsten Industriestaaten. Verbunden mit der organisatorischen Flexibilität
(Abbildung von komplexen Unternehmensstrukturen) eignen sich EMS für den Einsatz in international tätigen Konzernen.
Die oben dargestellten Hauptmerkmale stellen zusammen mit den im vorangehenden
Unterkapitel beschriebenen Grundeigenschaften von Standardsoftware die wesentlichen Kennzeichen von EMS dar. Daraus lässt sich folgende Definition für EnterpriseManagement-Systeme ableiten:
Definition:
Enterprise-Management-Systeme (EMS) decken sämtliche betriebswirtschaftlichen Anwendungsbereiche eines Unternehmens (Finanzwesen, Logistik und Personalwesen) ab und verbinden diese
durch eine gemeinsame Datenbasis. Durch die Ausrichtung auf die Grundprinzipien von Client/Server-Architekturen (Portabilität, Offenheit, Skalierbarkeit) lassen sich EMS in technischer Hinsicht beliebig an unternehmensspezifische Bedürfnisse anpassen. Auf betriebswirtschaftlicher Ebene findet
eine Anpassung (Customizing) durch Parametrisierung und ggf. durch Eingriffe an definierten Schnittstellen statt. In der Regel erfolgt parallel zur Anpassung des Systems eine Annäherung der Unternehmensorganisation an die Prozessvorgaben des EMS (Business Process Reengineering). Durch das
Vorhandensein verschiedener Landesversionen (Erfüllung der gesetzlichen Vorschriften des jeweiligen Landes) und die Unterstützung mehrerer Sprachen lassen sich EMS auch in international tätigen
Unternehmen einsetzen.
11
Alternativ zum Begriff "Enterprise-Management-System" sind in der Literatur eine Vielzahl weiterer Begriffe für solche Systeme anzutreffen.22 In Tab. 2-1 sind die am häufigsten verwendeten Bezeichnungen angegeben.
Deutscher Sprachraum
Englischer Sprachraum
• Integrierte betriebswirtschaftliche Standardsoftware
• Enterprise Resource Planning Systems (ERP)
• Betriebswirtschaftliche Anwendungssoftware
• Enterprise Applications (EA)
• Betriebswirtschaftliches (Standard-)anwendungen/
Standardpakete/Lösungen
• Packaged Applications
• Integrierte betriebliche Standardinformationssysteme
(IBSIS)
• Betriebswirtschaftlich-administrative Anwendungssoftware
• Packaged Client/Server Applications
• Business Software Solutions
• Enterprise-Wide Client/Server Software
Tab. 2-1: Alternative Begriffe für Enterprise-Management-Systeme.
Einige Beispiele für Enterprise-Management-Systeme sind SAP R/3, Baan IV, Oracle
Applications, SSA BPCS, Marcam Prism, JDEdwards OneWorld, Peoplesoft Solutions
oder CA-PRMS. All diesen Systemen sind die oben genannten Merkmale in unterschiedlicher Ausprägung gemeinsam. In Kap. 2.2.4 wird eine Marktübersicht über solche Systeme gegeben.
2.2.3 Vor- und Nachteile von EMS
Der Einsatz von Enterprise-Management-Systemen ist im Vergleich zur Entwicklung von
Individualsoftware mit wesentlichen Vorteilen verbunden. Gleichzeitig sind aber auch
Einschänkungen zu machen, welche bei der Evaluation von EMS berücksichtigt werden
müssen. Tab. 2-2 gibt einen Überblick über die in der Literatur erwähnten Vor- und
Nachteile von EMS. 23
22
23
12
Vgl. z.B. Barbitsch (1996), S. 9; Horváth/Petsch/Weihe (1983), S. 6; Keller (1995).
Vgl. dazu Adler (1990), S. 163; Barbitsch (1996), S. 13 ff.; Blume (1997), S. 16 ff.; Buck-Emden/
Galimow (1995), S. 22 ff.; Engels/Gresch/Nottenkämpfer (1996), S. 22 ff.; Gronau (1996), S. 13 ff.;
Horváth/Petsch/Weihe (1983), S. 7 f.; Keller/Teufel (1997), S. 68 ff.; Kirchmer (1996), S. 14 f.;
Knolmayer (1995a); Ludewig (1994), S. 1 ff.; Österle (1990a), S. 21 ff.; Stahlknecht (1995), S. 313.
f.; Scheer/Berkau/Kraemer (1990), S. 93 ff.
Vorteile von EMS
• EMS bieten eine Vielzahl von Prozessvarianten und
ermöglichen dadurch die Abdeckung aktueller und
künftiger Anforderungen (Höhere Flexibilität).
• Die von einem EMS unterstützten Prozesse können
als "Best in Practice" bezeichnet werden, da bei der
Entwicklung die Erfahrungen sehr vieler Anwender
eingeflossen sind (Zukauf von org. Know-how).
• Horizontale und vertikale Integration ist weitgehend
gewährleistet.
• Meist höhere Softwarequalität durch Praxiserprobung
und höheres Know-how bei der Softwareentwicklung.
• Schnellere Verfügbarkeit und somit kürzere Einführungsdauer.
• In der Regel bestehen Kostenvorteile beim Einsatz
von EMS und die Einführungskosten sind durch Festpreise besser kalkulierbar.
• Weiterentwicklung und Wartung sind weitgehend
gewährleistet (Zukunftssicherheit).
• Schnittstellenproblematik ist durch hohen Integrationsgrad weniger gravierend.
• Erfahrungsaustausch mit andern Anwendern (User
Groups) lässt das Risiko kalkulierbarer werden.
• Die Nutzung neuer Technologien ist durch die auf
dem Markt für EMS herrschende Konkurrenz schneller gewährleistet (Innovationsdruck).
• Auf dem Markt sind erfahrene Experten zu finden
(Diese müssen nicht zuerst ausgebildet werden).
• Grosses Schulungsangebot auf dem Markt (höhere
Qualität der Schulung, Einsatz von CBT-Software).
• Unternehmensübergreifender Datenaustausch wird
durch weitgehende Standardisierung (z.B. EDIFACT)
vereinfacht.
Nachteile von EMS
• Kritische Unternehmensprozesse (Core Processes)
lassen sich unter Umständen nicht "optimal" in der
SSW abbilden und müssen angepasst werden. Strategische Differenzierung gegenüber Wettbewerbern
entfällt.
• Gefahr der Gleichmacherei bei Prozessen in verschiedenen Unternehmungen unter Vernachlässigung betriebsindividueller Besonderheiten durch
mangelnde Übereinstimmung der vom EMS angebotenen Funktionalität mit den betrieblichen Gegebenheiten.
• Durch EMS erzwungene Änderungen der Geschäftsprozesse können erheblich sein und sind meist schwer
absehbar (Chance + Gefahr).
• EMS hat viel überflüssige Funktionalität (Hindernis für
schlanke Einführung).
• Akzeptanzprobleme in den IV-Abteilungen durch das
Obsoletwerden bisheriger Kenntnisse (Verlust von internem IV-Know-how, Rollenänderung)
• Release-Politik des Softwareanbieters ist wenig transparent und vielfach muss mit Verzögerungen von angekündigten Versionen gerechnet werden.
• Die Nutzung neu verfügbar gewordener Funktionen
kann mit dem Zwang zum Release-Wechsel des gesamten Systems verbunden sein.
• Starke Abhängigkeit vom Anbieter durch mangelnde
Transparenz der Standardsoftware.
• Der Quellcode ist häufig nicht verfügbar.
• Verschwenderischer Umgang mit Hardwareressourcen
durch eine Vielzahl von ungenutzten Funktionen
(generell höherer Ressourcenbedarf).
• Schnittstellen zu veralteter Individual- oder Standardsoftware sind oftmals schwierig realisierbar.
• Bessere Softwareergonomie durch die Verwendung
einheitlicher grafischer Benutzeroberflächen.
• Integration mit Produkten anderer Hersteller durch
die Verwendung von standardisierten Schnittstellen
besser gewährleistet (z.B. DCOM oder CORBA).
• SSW ist in der Regel besser dokumentiert und dadurch ist die Verständlichkeit besser gewährleistet.
Auf dem Markt ist eine Vielzahl von Zusatzliteratur
vorhanden.
• Datenschutz und Datensicherheit sind in hohem
Masse gewährleistet
• Durch Fremdbezug werden Personalressourcen in
den IV-Abteilungen freigesetzt (Verringerung des Anwendungsstaus, Konzentration auf Probleme, welche
nicht mit EMS gelöst werden können)
Tab. 2-2: Vor- und Nachteile von Enterprise-Management-Systemen.
13
Die dargestellten Merkmale können nicht in jedem Fall als allgemein gültig betrachtet
werden. Die betriebsspezifische Situation muss bei der Auswahl und Gewichtung dieser
Faktoren unbedingt mitberücksichtigt werden.
2.2.4 Der Markt für Enterprise-Management-Systeme
Der Markt von Enterprise-Management-Systemen wurde 1995 auf rund 4 Mia. USD
geschätzt.24 Bei Betrachtung der Marktentwicklung lässt sich eine Wachstumsrate zwischen 30% und 40% feststellen. In einer Studie von AMR (Advanced Manufacturing
Research) wurde geschätzt, dass das Marktvolumen im Jahr 2000 über 15 Mia USD betragen werde.25 Diese Zahlen beziehen sich nur auf die verkauften Softwarelizenz- und
Wartungsverträge. Darüber hinaus ist anzunehmen, dass die Nebenleistungen
(Hardwareverkäufe, Schulung und Beratungsdienstleistungen) die Basis-Werte um ein
Mehrfaches übersteigen werden.26
Da die einzelnen Produkte teilweise sehr unterschiedliche Bedürfnisse abdecken, lässt
sich der Markt für EMS nicht eindeutig abgrenzen. Einerseits sind die verschiedenen
Hersteller generell bestrebt, ihre Produkte auf eine möglichst grosse potentielle Kundengruppe auszurichten. Andererseits kann ein EMS unmöglich alle branchenspezifischen
Merkmale in einem internationalen Umfeld abdecken und gleichzeitig auch für KMUs
geeignet sein. Daher muss der Markt für EMS differenziert betrachtet werden. Als Gliederungsmerkmale können u.a. Unternehmensgrösse, Branchenzugehörigkeit und der
Grad der internationalen Ausrichtung herangezogen werden.
24
25
26
14
George (1996).
Shepard (1996).
Vgl. AFOS (1996), S. 36; vgl. dazu auch Kapitel. 5.3.
Wird beispielsweise der weltweite Markt von EMS im Industriesektor für das Jahr 1995
betrachtet, ist eine klare Dominanz von SAP festzustellen (vgl. Abb. 2-1). Wird dagegen
z.B. nur die Automobilindustrie betrachtet, erscheint in diesem Kundensegment SSA mit
BPCS als Marktführer.27 Dieser Vergleich soll verdeutlichen, dass über die Marktanteile
auf dem EMS-Markt je nach Sichtweise sehr unterschiedlich sind und die dargestellten
Vergleiche in der Regel nur für sehr grosse, über mehrere Branchen vertretene und international tätige Unternehmen repräsentativ sind.
Marktanteile von 27 EMS-Herstellern 1995 im Industriesektor (weltweit)
Other
19%
SAP
34%
Peoplesoft
3%
Oracle
5%
JDE
5%
Marcam
5%
Baan
7%
SSA
9%
CA
13%
Quelle: AMR 1996
Abb. 2-1: Marktanteile von EMS-Herstellern im Industriesektor 1995.
27
Vgl. George (1996).
15
Rebuild
High
Remain
J.D. Edwards
American
Software
SSA
BPCS C/S
QAD
Marcam
non-OOT
Functionality
SAP R/3
JBA
Cincom
CA-PRMS
Datalogix
WDS
Baan
Ross
CA-MMX
MDIS
Fourth
Shift
JIT
Symix
Oracle
Avalon
DBS
SCT
Spectrum
Marcam
Protector
SSA DOCA
Low
Low
Review
Reinforce
High
Technology
Quelle: Gartner Group (1995)
Abb. 2-2: Die Positionierung verschiedener Anbieter von EMS 1995.
In einer von der Gartner Group veröffentlichten Gegenüberstellung verschiedener
EMS28 im Hinblick auf die vorhandene Funktionalität und die dem EMS zugrundeliegende Technologie entsteht ein vergleichbares Bild (vgl. Abb. 2-2). SAP R/3 nimmt hier
ebenfalls die Führungsposition ein. Aber auch diese Einschätzungen beziehen sich vor
allem auf sehr grosse, international tätige Konzerne; häufig wird allerdings eher die
Mittelstandsfähigkeit von SAP R/3 als seine Konzernfähigkeit in Frage gestellt.29
Bei der Evaluation mag zwar die Markposition des Anbieters eine gewisse Rolle spielen,
dennoch sollte bei der Entscheidfindung primär die Abdeckung der unternehmensspezifischen Bedürfnisse im Vordergrund stehen. Da sich eine EMS-Einführung, wie bereits
darauf hingewiesen wurde (vgl. Tab. 2-2), nur mit grossem Aufwand wieder rückgängig
machen lässt und hohe Kosten verursacht, wird in der Regel nach einer Vorselektion,
28
29
16
Vgl. Keller (1995).
Vgl. Hufgard (1995), S. 44.
welche die generelle Eignung der auf dem Markt befindlichen Produkte überprüft, eine
detaillierte Evaluation von maximal 3 Produkten empfohlen. 30
Bevor sich ein Unternehmen für den Einsatz eines EMS entscheidet, sollten alternative
Lösungen geprüft und gegebenenfalls in die Betrachtungen einbezogen werden. Denkbar ist dabei die Entwicklung von Individualsoftware oder die Verwendung von Component Ware als Basis für den Bau von integrierten Systemen. Beide Alternativen werden im folgenden Abschnitt ausführlich diskutiert.
2.2.5 Alternativen zum Einsatz von EMS
2.2.5.1 Individualsoftware
Durch die Entwicklung von Individualsoftware können die Bedürfnisse eines Unternehmens exakt abgebildet werden. Verbesserte Softwareentwicklungsmethoden und
-werkzeuge (CASE-Tools, Repositories, objektorientierte Programmiersprachen) ermöglichen die Realisierung von Kosten- und Zeiteinsparungen im Entwicklungsprozess. Die
gesamten Entwicklungskosten liessen sich in der Vergangenheit durch die Verwendung
der genannten Methoden und Werkzeuge nur geringfügig reduzieren, da die finanziellen Aufwendungen für die Programmierung in Grossprojekten nur ca. 10-20% ausmachen. Die Hauptvorteile bei der Verwendung von modernen Softwarenetwicklungsmethoden und -werkzeugen gegenüber herkömmlichen Vorgehensweisen liegen vor allem
bei der besseren Beherrschbarkeit der Komplexität von Entwicklungsprojekten.31
Durch die Dynamik der Märkte und die Geschwindigkeit der technischen Entwicklung
werden die Entwickler ständig mit neuen Anforderungen konfrontiert. Der damit verbundene Wartungsaufwand von existierenden Anwendungssystemen ist erheblich und
bindet einen Grossteil der vorhandenen Entwicklungsressourcen. Für Neuentwicklungen
stehen zunehmend weniger personelle Ressourcen zur Verfügung. Dies führt mit der
Zeit zu einem schwer überwindbaren Anwendungsstau.32
30
31
32
Vgl. Brenner (1990), S. 13.
Vgl. Füller/Thomae (1990), S. 39; Hüttenhain (1990), S. 132.
17
Für die Entwicklung von komplexen Anwendungssystemen mit vergleichbarem Leistungsumfang, Integrationsgrad und entsprechender Qualität, wie sie heute von Standardsoftware geboten wird, muss mit einer Entwicklungsdauer von 5 - 10 Jahren gerechnet werden.33 Während dieser Zeit müssen die Anforderungen durch die Dynamik
im betrieblichen Umfeld ständig angepasst und erweitert werden. Dieser Umstand erhöht die Entwicklungsdauer zusätzlich. Dem steht die relativ kurze Einführungszeit von
EMS (in der Regel 1-2 Jahre) gegenüber.
Hohe Entwicklungskosten, fehlende personelle Ressourcen und lange Entwicklungszeiten sind die wesentlichsten Nachteile von Individualsoftware. Weitere Vor- und Nachteile von Individuallösungen können Tab. 2-1 entnommen werden.
Der Hauptvorteil von Individuallösungen liegt in der Erlangung von Wettbewerbsvorteilen durch Verwendung von einzigartigen und speziell auf das Unternehmen zugeschnittenen Anwendungssystemen. Dieser Aspekt spricht stark für die Entwicklung von
Individuallösungen. Können solche Potentiale durch den vorhandenen Anwendungsstau
nicht genutzt werden, gehen Wettbewerbsvorteile verloren und die Konkurrenzfähigkeit
wird geschwächt. Werden hingegen die für die Weiterentwicklung von administrativen
Systemen notwendigen Entwickler durch die Beschaffung eines EMS freigesetzt, können
diese Ressourcen für strategisch wichtige und standardmässig nicht lösbare Aufgaben
eingesetzt werden.34 Moderne EMS decken die betrieblichen Anforderungen in den
Anwendungsfeldern des Rechnungs- und Personalwesens in hohem Masse ab. Selbst im
Bereich der Produktion und Logistik sind heutige EMS in den meisten Fällen in der Lage, alle erforderlichen Funktionen für die Beschaffung, die Fertigung und den Vertrieb
zu unterstützen, so dass sich auch in diesem, in der Vergangenheit eher durch Individualsoftware geprägten Anwendungsbereich Standardsoftware einsetzen lässt.35
Ist die funktionale Abdeckung gegeben und werden die bereits erwähnten Vorteile Einführungsgeschwindigkeit, geringere Kosten und höhere Flexibilität in die Betrachtungen
33
34
35
18
Vgl. z.B. Kirchmer (1996), S. 14; Mertens/Knolmayer (1995), S. 32 f.; Österle (1990a), S 22 ff.
Vgl. z.B. Losbichler (1988), S. 91.
einbezogen, fällt die Beantwortung der "Make-or-Buy"-Frage36 ist in den meisten Fällen
zugunsten des EMS-Einsatzes eindeutig aus.
2.2.5.2 Component Ware
Das Prinzip der Verwendung einzelner Softwarebausteine (Component Ware) bei der
Anwendungskomposition entstammt der Objektorientierten Programmierung (OOP).
Die Wiederverwendbarkeit stellt eines der Grundprinzipien der OOP dar.37 Die einzelnen Softwarebausteine sollen nach der Idee der Object Management Group (OMG) in
Form von Objekten an einer Börse gehandelt werden und für die Anwendungsentwicklung zur Verfügung gestellt werden. Die Vertreter dieses Ansatzes erhoffen sich dadurch eine erhebliche Verkürzung der Entwicklungszeiten.38
In der Literatur besteht keine einheitliche Auffassung bezüglich des angemessenen Umfangs einzelner Anwendungskomponenten. Das Spektrum reicht von einfachen Softwarebausteinen ohne betriebswirtschaftliche Logik (z.B. Objektbibliotheken zur Oberflächensteuerung) bis hin zu komplexen Anwendungskomponenten in Form von vollständigen Business Objekten39 (z.B. für die Offerterstellung, Kundenbestellung oder
Kreditwürdigkeitsprüfung).
Eines der Grundprinzipien der Component-Ware-Architektur ist die Wiederverwendbarkeit der Anwendungskomponenten.40 Das ComponentWare Consortium schlägt vor,
zur Gewährleistung der Wiederverwendbarkeit folgende Bedingungen einzuhalten:41
• Unabhängigkeit von einem Object Framework (z.B. COM, CORBA, OpenDoc)
• Plattformunabhängigkeit auf Client- und auf Server-Ebene
• Sprach- und Werkzeugunabhängigkeit
• Gewährleistung von Datenrobustheit und Performance
36
37
38
39
40
41
Vgl. z.B. Mertens/Knolmayer (1995), S. 31 ff.
Vgl. Udell (1994), S. 46.
Vgl. Froitzheim (1994), S. 188.
Dodd (1994), S. 7. (Dodd definiert Business Objekte wie folgt: "A business object is a software unit
that corresponds to a real world entity from the user's domain." )
Vgl. Keller/Teufel (1997), S. 64 f.
Vgl. ComponentWare Consortium (1995).
19
• Gewährleistung unternehmensübergreifender Wiederverwendbarkeit.
Neben das Kriterium der Wiederverwendbarkeit treten zusätzlich die Kriterien Anpassbarkeit und Erweiterbarkeit.42 Der Anpassbarkeit sind insofern Grenzen gesetzt, als Modifikationen nicht vollständig frei vorgenommen werden können, sondern sich diese
nach dem vom Hersteller bereitgestellten Beziehungswissen richten sollen. Bei der Erweiterung von Anwendungskomponenten gilt es zu berücksichtigen, dass die Konsistenz
des Gesamtprozessmodells nicht gefährdet werden sollte.
Zur technischen Realisierung des Component-Ware-Konzepts schlägt die Object Management Group die in Abb. 2-3 beispielhaft dargestellte Grundarchitektur vor. Framework-Komponenten (z.B. CORBA43) stellen die Drehscheibe zwischen den ClientApplikationen und den RDBMS-Komponenten (Application Components) dar. Die zusätzliche Schicht ermöglicht die Loskoppelung zwischen den Desktop-Application und
den RDBMS-Applikations-Komponenten. Dadurch können die einzelnen Komponenten
unabhängig voneinander ausgetauscht werden. Der Object Request Broker (ORB)
übernimmt dabei eigentliche Vermittler- und Transportfunktion. Die Verbindung zwischen den Framework-Komponenten und dem ORB wird durch spezifische APIs
(Application Programming Interfaces) hergestellt.
42
43
20
Vgl. Keller/Teufel (1997), S. 65 f.
CORBA = Common Object Request Broker Architecture.
Desktop
Applications
Framework
Component
CW
C++
APP.
Application
Component
Enterprise
RDBMS
OTHER
SYBASE
CW
CORBA
RDBMS
ORACLE
OBJECT REQUEST BROKER
Naming
Persistence
Transaction
Event
Object Services
Common Facilities
Abb. 2-3: Component-Ware-Architektur der OMG.
Ein Beispiel für die Umsetzung des Component-Ware-Prinzips stellt das von der Universität Erlangen mit wissenbasierenden Ansätzen entwickelte Produktionsplanungssystem
GEPRODEX dar. Die Entwicklung der PPS-Funktionalitäten erfolgte bei diesem Anwendungsbeispiel auf der Basis von Microsoft-Standardanwendungskomponenten (insbes.
MS-Project, MS-Excel, MS-Access). Die in den einzelnen Softwarebausteinen enthaltenen Funktionen werden gezielt durch Visual-Basic-Komponenten erweitert und an die
Bedürfnisse der Produktionsplanung angepasst. Durch die Verwendung von Standardanwendungskomponenten, welche sich bereits tausendfach auf dem Markt bewährt
haben und bei den Endanwendern ausreichend bekannt sind, ist mit einer geringeren
Fehleranfälligkeit und kürzeren Einführungszeiten zu rechnen. 44
44
Vgl. Möhle et al. (1996), S. 30 ff.
21
PPS-System
MSExcel
MSAccess
Visual
Basic
MSProject
MSExchange
Abb. 2-4: Beispiel für ein auf dem Component-Ware-Prinzip basierendes PPS-System.
Ein weiteres Beispiel für die Umsetzung des Component-Ware-Prinzips auf der Grundlage von Business Objekten stellt das Business Framework der SAP dar. Die bereitgestellten Business Objekte (z.B. Kundenbestellung oder Stellenbewerbung) werden von
einem Business Object Repository (BOR) verwaltet und kommunizieren über sogenannte Business Application Programming Interfaces (BAPIs). Die einzelnen Business
Objekte können nach dem "Lego-Prinizp" zu ganzen Applikationen z.B. für den Bereich
des Electronic Commerce oder für die Unterstützung des Workflow Managements erstellt werden.
22
R/3 Anwendungen
R/3 Anwendungen,
SAP Business Workflow
CORBA
Client
Visual Basic,
MS-Excel,
MS Project,....
Internet
Explorer,
Netscape,...
JavaAnwendungen
CORBA
COM
DCOM
Object
Bridge
DCOM
Component
Connector
HTML
Internet
Transaction
Server
Java
Java
Component
Connector
B
r
o
k
e
r
BAPI
Lieferantenauftrag
BAPI
BAPI
Bedarfsanforderung
BAPI
BAPI
Material
Business Object Repository
R/3 Datenbank
Abb. 2-5: Business Framework der SAP.45
Einige Autoren46 sprechen bereits bei der Integration von herstellerfremden Softwarebausteinen in bestehende EMS von der Anwendung des Component-Ware-Prinzips. Im
R/3-Umfeld stellen Drittanbieter eine grosse Zahl von Add-Ons (z.B. Archivierungsoder Zeiterfassungssysteme) zur Ergänzung von einzelnen Funktionen des R/3-Systems
bereit (vgl. Abb. 2-6). Durch Hinzufügen von weiteren Softwarekomponenten soll ein
besser auf die Anwenderbedürfnisse zugeschnittenes Informationssystem entstehen.
Teilweise werden solche Add-Ons vom Hersteller zu einem späteren Zeitpunkt in ein
EMS übernommen.
45
46
Vgl. SAP AG (1996e), S. 19.
Vgl. dazu Froitzhein (1994), S. 188 ff.; Udell (1994), S. 56.
23
BDE
BDE
ZeitZeitwirtschaft
wirtschaft
EDI
EDI
BOR
...
...
R/3
Reise
Reise
kostenkostenabrechnung
abrechnung
ZugangsZugangskontrolle
kontrolle
CAD
CAD
Electronic
Electronic
Banking
Banking
Abb. 2-6: Anwendungsbereiche von Add-On-Produkten für das R/3-System.47
In anderen Bereichen (z.B. bei Textverarbeitungssystemen) ist es ebenfalls möglich
durch die Objekt-Technologie einzelne Anwendungskomponenten (z.B. den Formeleditor) durch andere Komponenten zu ersetzen.
Die sich durch Component Ware eröffnenden Möglichkeiten sind sehr vielfältig und
bieten insbesondere beim Customizing von grösseren Anwendungssystemen entscheidende Vorteile durch die rasche Verfügbarkeit und die bessere Robustheit der am Markt
erhältlichen Zusatzkomponenten. Für die Realisierbarkeit der Entwicklung von komplexen Anwendungssystemen nach dem "Lego-Prinzip" sind allerdings einige Fragezeichen
zu setzen. Es ist zu befürchten, dass solche Vorhaben an den gleichen Problemen
scheitern werden wie der Versuch der Integration von getrennt entwickelten Anwendungssystemen.48
47
48
24
Ein Überblick über Add-on-Produkte für SAP R/3 ist unter den WWW-Adressen www.sap.com oder
www.logimedia.com zu finden.
Vgl. Meinhardt/Teufel (1995), S. 71.
2.3 Auswahl von EMS
2.3.1 Vorgehen
Die Einführung eines EMS ist meist nur mit grossem Aufwand wieder rückgängig zu machen. Einer sorgfältigen Auswahl des zu beschaffenden System kommt deswegen erhebliche Bedeutung zu. Der Auswahlprozess erfolgt in der Regel anhand eines mehrstufigen
Verfahrens (vgl. Abb. 2-7), welches durch den Projektauftrag ausgelöst wird. Auf der
Grundlage einer Ist-Analyse und der daraus resultierenden Schwachstellenanalyse wird
ein Soll-Konzept erstellt. Basierend auf dem Sollkonzept werden für das Anforderungsprofil Muss-Kriterien (K.O.-Kriterien) formuliert. Anhand dieser Kriterien wird eine Vorselektion getroffen und die Auswahl auf wenige Produkte (z.B. drei49) eingeschränkt.
Die Bewertung der noch übrig gebliebenen Produkte kann anhand der restlichen Kriterien (Kann-Kriterien) durch die Anwendung entscheidtheoretischer Verfahren (z.B.
Nutzwertanalyse) erfolgen. Nach Auswahl des EMS sind Projektauftrag und Zielsetzungen zu überprüfen und gegebenenfalls anzupassen.
Projektauftrag
Kriterienkatalog
Erhebungstechniken,
Darstellungstechniken
IstAnalyse
Nutzwertanalyse
Schwachstellenanalyse
Auswahl
SollKonzept
Überprüfung
Projektauftrag/
Zielsetzungen
Ermittlung von Mängeln
und Ursachen
Darstellungstechniken
(z.B. ERM und EPK)
Grad der Detaillierung ist
unterschiedlich
Zielformulierung
Rahmenbedingungen
Leistungsumfang EMS, Konzeption
des EMS, Anwendererfahrungen,
Stellung des Lieferanten, Wirtschaftlichkeitsbetrachtung, etc.
Abb. 2-7: Auswahlverfahren von EMS.
49
25
2.3.2 Ist-Analyse und Soll-Konzept
Die Art und Weise der Erstellung eines Soll-Konzepts ist in der Literatur umstritten.50
Einige Autoren51 empfehlen die Anwendung des gleichen Vorgehens wie bei der Softwareentwicklung (Detaillierte Analyse der Ist-Situation, Ableitung eines Soll-Konzepts,
Erstellung eines Pflichtenhefts). SAP hingegen empfiehlt ihren Kunden, auf eine detaillierte Ist-Analyse zu verzichten und schlägt vor, die Anforderungen an das System aufgrund der vorhandenen Referenzmodelle festzulegen.52 Diese Vorgehensweise setzt
allerdings voraus, dass der Systementscheid bereits gefallen ist. Grundlage für ein Projekt stellt der Projektauftrag dar. Darin werden Projektbezeichnung, Zielsetzungen,
Inhalt des Anwendungssystems und Rahmenbedingungen für die Projektdurchführung
festgelegt. Durch eine einfache und möglichst treffende Projektbezeichnung wird dem
Vorhaben eine eindeutige Identität gegeben. Die Formulierung von Zielsetzungen verdeutlicht Zweck eines Projektes. Zielsetzungen in Zusammenhang mit Informatikprojekten beziehen sich häufig auf Kosteneinsparungen, eine Erhöhung der Durchlaufzeiten, Verbesserung der Kundenserviceleistungen oder Produktequalität etc. Anhand einer
fachlichen Abgrenzung werden in groben Zügen die betrieblichen Funktionen beschrieben, welche durch das neue Anwendungssystem abgedeckt werden sollen. Ferner werden alle für das Projekt relevanten Rahmenbedingungen (z.B. Einbezug von Beratungsunternehmen, Projektdauer, Berichterstattung, verfügbare personelle und finanzielle
Ressourcen, Kompetenzen des Projektleiters) festgehalten.
Die Grundlage für die Erstellung des Soll-Konzepts stellen die Ergebnisse der Ist-Analyse
dar. Das Ziel der Ist-Analyse ist die Aufnahme und Bewertung der vorhandenen Abläufe
(Geschäftsprozesse) und der damit verbundenen Daten.53 Der Detaillierungsgrad der
Ist-Analyse hängt im wesentlichen vom Ausmass der beabsichtigten organisatorischen
und technischen Änderungen während der Einführung eines EMS ab. Von einer reinen
Automatisierung ohne Veränderung der betrieblichen Ablauforganisation ist erfahrungs-
50
51
52
53
26
Vgl. Stahlknecht (1995), S. 315.
Vgl. z.B. Losbichler (1988), S. 90; Stahlknecht (1995), S. 315.
Vgl. Vaske (1996), S. 7.
gemäss eher abzuraten.54 Alternativ dazu wird die Anpassung der Organisation im Rahmen der EMS-Einführung der reinen Automatisierung vorgezogen. Bezüglich der Wahl
der Anpassungsstrategien herrscht keine einheitliche Auffassung. Während die Anhänger
des Business Process Reengineering (BPR) quantensprungartige Verbesserung von Geschäftsprozessen55 fordern, ziehen die Verfechter des Continous System Reengineering
(CSE) kurzfristige Verbesserungen in kleinen Schritten vor56 (vgl. Abb. 2-8). Während
beim CSE behauptet wird, dass durch ständige Anpassung des EMS eine bessere Übereinstimmung zwischen Betriebsorganisation und Informationsverarbeitung57 erreicht
werden kann, sind die Anhänger des BPR der Auffassung, dass Verbesserungen nur
durch eine radikale Änderung der Organisation58 realisiert werden können.
Informationsund
OrganisationsQualität
CSE
BPR
Ausgangslage
Heute
Zeit
Abb. 2-8: Continous System Engineering vs. Business Process Reengineering.
Diese beiden Denkansätze setzen auch unterschiedliche Auffassungen bezüglich der
Durchführung einer Ist-Analyse voraus. Während beim BPR gefordert wird, dass die
Ablauforganisation weitgehend unabhängig von der Ist-Situation neu entworfen werden
54
55
56
57
58
Vgl. Buxmann/König (1997), S. 166.
Vgl. Brenner/Keller (1995), S. 27; Hammer/Stanton (1995), S. 3.
Thome/Hufgard (1996), S. 79 f.
Thome/Hufgard (1996), S. 83 f.
Hammer/Champy (1994), S. 49 f.
27
soll,59 wird beim CSE die Bedeutung der Ist-Analyse nicht grundsätzlich in Frage gestellt.60 SAP empfiehlt ihren Kunden die Ist-Analyse wie auch das Soll-Konzept nicht zu
detaillieren, sondern für die Festlegung der notwendigen Funktionen das vom Hersteller
zur Verfügung Referenzmodell zu nutzen.61 Aber auch diese Empfehlung ist kritisch zu
betrachten, da für die anforderungsgerechte Festlegung der zu nutzenden Funktionen
eine detaillierte Kenntnis der betrieblichen Abläufe vorausgesetzt werden muss.62
Für und gegen die Durchführung einer detaillierten Ist-Analyse sprechen viele einleuchtende Argumente. Ungeachtet dieser Diskussion wird im folgenden kurz dargestellt, wie eine Ist-Analyse im Zusammenhang mit einer EMS-Einführung aussehen
könnte. In der Literatur lässt sich zum Beispiel folgender Vorschlag finden:63
• Beschreibung der Arbeitsabläufe (mit zeitlichem Ablauf und beteiligten Stellen)
• Entstehung, Verwendung und Mengengerüst aller relevanten Daten
• Schnittstellen zu internen und externen Stellen sowie
• bei der Prozessabwicklung anfallenden Kosten.
Im Zentrum der Ist-Analyse steht die Darstellung der betrieblichen Prozesse und der mit
einem Prozess verbundenen Organisationseinheiten. Diese können beispielsweise anhand verschiedener "W-Fragen" beschrieben werden. Am Beispiel der Nachbestellung
eines Lagerartikels könnte diese Prozessbeschreibung wie folgt aussehen:64
W-Frage
Antwort
W-Frage
Antwort
Wer?
Abteilung Einkauf
Wozu?
Nachbestellung
An Wen?
Lieferanten
Wann?
Falls Meldebestand erreicht
Was?
Lagerartikel
Wie?
Schriftliche Bestellung
Tab. 2-3: Prozessbeschreibung der Nachbestellung eines Lagerartikels.
59
60
61
62
63
64
28
Davenport/Stoddard (1994), S. 122 f.
Thome/Hufgard (1996), S. 20.
Stahlknecht (1995), S. 315.
Stahlknecht (1995), S. 254 ff.
Stahlknecht (1995), S. 256.
Ein weiterer Kernbereich der Ist-Analyse stellt die Beschreibung der relevanten Daten
dar. Dabei wird die Frage gestellt, welche Daten für die Durchführung eines Prozesse
notwendig sind und welche Daten allenfalls bei der Durchführung eines Prozesses erzeugt werden. In diesem Zusammenhang stellt sich auch die Frage nach dem Mengengerüst, d.h. über die Menge der benötigten resp. erzeugten Daten. Diese Angaben sind
insbesondere für die Dimensionierung der Rechenleistung, des Massenspeichers und
der Kommunikationsleitungen massgebend.
Zusätzlich zu Ermittlung der Prozesse und der Daten sind die von einem Prozess tangierten internen (z.B. Abteilung Rechnungswesen) und externen Schnittstellen (z.B.
Lieferant) betreffend Datenaustausch und bei der Abwicklung eines Prozesses entstehenden Kosten zu erfassen.
Für die Erfassung und Beschreibung der Ist-Situation können verschiedene Erhebungsund Darstellungstechniken zum Einsatz kommen. Die wichtigsten Techniken zur Erhebung des Ist-Zustandes sind65
• Unterlagenstudium
• Fragebogen
• Interview
• Konferenz
• Beobachtung und
• Selbstaufschreibung.
Für die Darstellung der vorhandenen Geschäftsprozesse und der damit verbundenen
Daten sind ebenfalls die verschiedensten Techniken einsetzbar. Grundsätzlich können
• verbale
• tabellarische oder
• grafische
65
Vgl. Schmidt (1991), S. 116 ff.; Stahlknecht (1995), S. 259 f.
29
Beschreibungswerkzeuge eingesetzt werden.66 Einige Beispiele für heute gebräuchliche
Darstellungstechniken aus dem Umfeld der Informationsverarbeitung sind:
• Entity-Relationship-Modell67 (ERM
• Structured Analysis68 (SA)
• Structured Analysis and Design Technique69 (SADT)
• Hierarchy of Input-Process-Output70 (HIPO)
• Petri-Netze71
• Object Modeling Technique72 (OMT)
• Ereignisgesteuerte Prozessketten73 (EPK).
Neben den IT-basierten Darstellungstechniken können eine grosse Zahl BWL-orientierter Methoden zur Aufgaben- und Aufbauorganisationsbeschreibung herangezogen
werden. 74 Darunter fallen z.B.
• Organigramme
• Stellenbeschreibungen
• Kommunikationsdiagramme
• Belegflussdiagramme oder
• GANTT-Diagramme (Balkendiagramme).
Die genannten Methoden stellen eine Auswahl möglicher Darstellungstechniken für die
betrieblichen Prozesse und die Aufbauorganisation dar. Bei der Einführung von EMS
(z.B. SAP R/3) wird häufig die Methode der Ereignisgesteuerten Prozessketten75 verwendet.
66
67
68
69
70
71
72
73
74
75
30
Vgl. Keller/Teufel (1997), S. 137 ff.; Stahlknecht (1995), S. 261 ff.
Chen (1976), S. 9-36.
De Marco (1978), S. 15-178.
Marca/McGowan (1988), S. 1-72.
Stevens/Myers/Constantine (1974), S. 115 ff.
Petri (1962).
Rumbaugh (1991), S. 21 ff.
ASAP World Consultancy/Blain, S. 94 ff.; Keller/Teufel (1997), S. 158 ff.; Scheer (1995), S. 49 ff.
Vgl. z.B. Keller/Teufel (1997), S. 145 ff.; Schmidt (1991), S. 263 ff.
Vgl. Kap. 4.3.1.2.
Parallel zur Erfassung des Ist-Zustandes erfolgt die Ermittlung der existierenden Mängel
in der vorhandenen Ablauforganisation. Im Rahmen einer nachfolgend durchgeführten
Schwachstellenanalyse müssen die Ursachen dieser Mängel bestimmt und die daraus
resultierenden Folgeschäden quantifiziert werden. Beispiele für Mängel sind durch ein
mangelhaftes Mahnwesen verursachte hohe Debitorenausstände. Die sich daraus ergebenden Schäden sind Liquiditätsengpässe und damit verbunden die Notwendigkeit der
Beschaffung von teurem Fremdkapital (z.B. Bankkredite) zur Überwindung dieser Engpässe. Durch Erfassung und Bewertung der Schwachstellen wird die Möglichkeit geschaffen, die festgestellten Mängel bei der Festlegung des Soll-Konzepts zu beseitigen.
Das Soll-Konzept legt auf der Basis der ermittelten Bedürfnisse und Schwachstellen
sowie aufgrund der erkennbaren Potentiale des aktuellen Entwicklungsstandes der Informationstechnologie die Anforderungen an das neue System fest. Zusätzlich zur Anforderungsdefinition werden die Wirtschaftlichkeit des aktuellen und des geplanten Zustandes verglichen.
Der Übergang von der Analyse der Ist-Situation zum Soll-Konzept ist eine schwierige
Aufgabe.76 Für die Ableitung der Anforderungen sind verschiedene Vorgehensweisen
denkbar:
• Ableitung eines auf eigenen Überlegungen basierenden Sollkonzepts (Einsatz von
Kreativitätstechniken).
• Ableitung eines auf allgemeinem Erfahrungswissen basierenden Sollkonzepts (Einsatz
von branchenspezifischen Referenzmodellen).
• Ableitung eines Sollkonzepts auf der Basis eines produktbezogenen Referenzmodells
(z.B. R/3-Referenzmodell).
76
Vgl. Thome/Hufgard (1996), S. 21.
31
Das erstgenannte Verfahren bietet zwar den Vorteil, dass unternehmensspezifische
Merkmale meist besser berücksichtigt und damit Wettbewerbsvorteile erhalten oder neu
dazu gewonnen werden können. Gleichzeitig verbirgt sich hinter dieser Vorgehensweise
ein enormer Aufwand und es besteht die Gefahr der Zementierung der vorgedachten
Prozesse. EMS decken die aufwendig erarbeiteten Soll-Prozesse meist in anderer Form
ab, so dass der in den kreativen Prozess investierte Aufwand obsolet wird.
Bei der Verwendung von branchenspezifischen Referenzmodellen für die Anforderungsdefinition kann ein Grossteil des durch den kreativen Gestaltungsprozesses verursachten Aufwandes eingespart werden. Der Abdeckungsgrad mit der Funktionalität der
am Markt erhältlichen EMS wird durch die Verwendung von standardisierten Prozessen
erheblich grösser sein. Allerdings wird die Chance zur strategischen Differenzierung
durch die Angleichung der Geschäftsprozesse an branchenübliche Vorgehensweisen
vertan.
Die Ableitung des Anforderungskatalogs aufgrund eines produktspezifischen Referenzmodells garantiert bei der Einführung den geringsten Anpassungsaufwand. Allerdings ist
diese Vorgehensweise als Grundlage für die Evaluation mehrerer Produkte wenig sinnvoll, da die zu wählende Alternative präjudiziert wird. Dieses Vorgehen kommt eigentlich nur bei der strategischen Auswahl einer Produktefamilie zur Ermittlung des Funktionsabdeckungsgrades in Frage.
Ein Anforderungskatalog für die Evaluation von EMS orientiert sich primär an den formulierten Zielsetzungen und kann die in Tab. 2-4 dargestellten Kriterien umfassen. Damit eine Vorselektion von EMS möglich ist, wird zwischen Muss- (K.O.-) und KannKriterien unterschieden. Der Kriterienkatalog umfasst neben fachlichen, technischen
und wirtschaftlichen Anforderungen auch Erfordernisse, welche sich auf die Eigenschaften des Lieferanten beziehen. Für die Evaluation von EMS ist der Beizug externer
Berater lohnenswert. Die Bewertung der in die Betrachtungen einbezogenen Systeme
erfolgt aufgrund dieses Kriterienkatalogs. Für die Auswahl des am besten geeignetsten
Produkts wird häufig die Nutzwertanalyse eingesetzt.
32
Kriterienkatalog zur Auswahl von EMS
• Leistungsumfang
− Daten, Funktionen
− Integrationsgrad
− Anpassungaufwand
− Schnittstellen zu anderen Anwendungen
• Konzeption des EMS
− Basisarchitektur (Portabilität, Offenheit, Skalierbarkeit)
− Systemvoraussetzungen
− Erfüllung bestimmter Softwarestandards
− Benutzerfreundlichkeit
− Antwortzeitverhalten
− Dokumentation (Benutzerdokumentation, technische Dokumentation)
− Weitere Softwarekomponenten
(Data Dictionary, Referenzmodelle, Einführungsunterstützungswerkzeuge, Office-Komponenten etc.
• Erfahrungen von Anwendern
− Fachliche Erfahrungen
− Branchenbezogene Erfahrungen
− Länderbezogene Erfahrungen
− Herstellerbezogene Erfahrungen
• Lieferant
− Stellung des Lieferanten am Markt
− Qualifikation der Mitarbeiter des
Lieferanten
− Branchenerfahrung
− geographische Nähe
− Vertragsbedingungen, Garantien
− Zusatzleistungen des Anbieters
(Beratung, Schulung etc.)
• Kosten/Nutzen-Relation
− Anschaffungskosten (Lizenzen)
− Einführungskosten
− Hardwarekosten
− Betriebs- und Wartungskosten
Tab. 2-4: Kriterien zur Auswahl von EMS.77
2.3.3 Informationsbeschaffung zur Evaluation von EMS
Für die Informationsbeschaffung zur Evaluation von EMS steht eine Vielzahl von Informationsquellen zur Verfügung. Diese eignen sich aufgrund ihrer Sichtweise und aufgrund des Detaillierungsgrades in unterschiedlichem Ausmass zur Wissensgewinnung in
den verschiedenen Phasen des Evaluationsprozesses. Darüber hinaus wurden in den
letzten Jahren die Informationsbeschaffungsmöglichkeiten durch die starke Ausdehnung
elektronischer Medien (insbes. Internet) grundlegend verändert.
Tab. 2-5 zeigt eine Auswahl verschiedener Informationsquellen für die Evaluation von
EMS und bewertet diese nach Eignung für die verschiedenen Phasen des Evaluationsprozesses.
77
Vgl. z.B. Brenner (1990), S. 15 ff.; Horváth/Petsch/Weihe (1983), S. 12 ff.; Stahlknecht (1995),
S. 318.
33
Informationsquellen
Produktsuche Vorselektion
Produktbeurteilung
Softwarekataloge (z.B. ISIS-Report)
l
¤
¡
Fachzeitschriften
¤
¤
¤
Messen (z.B. CeBIT)
¤
¤
¡
World Wide Web / Compuserve
l
l
¤
Konferenzen/Seminare/Tagungen
¡
¤
¤
Fachliteratur
¡
¤
l
Herstellerinformationen (Informationsmaterial)
¡
¤
¤
Beratungsunternehmen
¤
¤
¤
Marktforschungsinstitute (z.B. Gartner Group)
l
l
¡
Universitäten (Fallstudien, empirische Studien)
¤
l
¤
Erfahrungsberichte von Anwendern (Usergroups)
−
¡
l
Testinstallation
−
¡
l
¡ ungeeignet
¤ teilweise geeignet l gut geeignet
Tab. 2-5: Mögliche Informationsquellen zur Auswahl von EMS.78
Zur Produktsuche bieten sich Verzeichnisse in Software-Katalogen79, Marktübersichten
in Fachzeitschriften80 oder von Marktforschungsunternehmungen an. Die dabei gewonnen Information haben einen sehr geringen Detaillierungsgrad und geben nur groben
Hinweise auf die allfällige Eignung eines Produktes im konkreten Anwendungsfall.
Die Produktsuche auf dem World Wide Web (WWW) ist grundsätzlich auch möglich.
Mit Hilfe von Search Engines können alle über das Internet ansprechbaren WWWServer nach bestimmten Inhalten durchsucht werden. Da die Präsenz der einzelnen
IV-Anbieter auf dem Internet relativ gross ist, können mit einer seriösen Recherche viele
für eine Evaluation von EMS in Frage kommende Produkte ausfindig gemacht werden.81
Tab. 2-6 zeigt ist eine Auswahl verschiedener Search Engines für die Suche nach bestimmten Begriffen auf dem Internet. Die einzelnen Search Engines unterscheiden sich
78
79
80
81
34
In Anlehnung an Horvàth/Petsch/Weihe (1983), S. 15.
Vgl. Nomina Information Services (1995a-c).
Vgl. z.B. Chen/Geitner (1993), S. 52 ff.
Vgl. Knolmayer (1996a); Knolmayer (1996b); Knolmayer (1996c).
hauptsächlich nach dem bereitgestellten Datenvolumen und den Suchmechanismen.
Die Bedienung ist relativ einfach und in einigen Fällen ausführlich dokumentiert.
Internet Search Engines
Name
WWW-Adresse
Besonderes Merkmal
Alta Vista
http://www.altavista.digital.com/
-
Lycos
http://www.lycos.com/
-
Hotbot
http://www.hotbot.com/
-
WebCrawler
http://webcrawler.com/
-
Yahoo!
http://www.yahoo.com/
Kategorisierte Auflistung der Einträge
Infoseek Ultra
http://ultra.infoseek.com/
-
Excite
http://www.excite.com
-
Cyber 411
http://www.cyber411.com/search/
Parallele Suche auf mehreren Search Engines
DejaNews
http://www.dejanews.com/
Suche in News-Archiven (Newsgroups)
Lycos (CH,D,A)
http://www.lycos.de
Server mit Extensionen ch, de, at
Tab. 2-6: Internet Search Engines.
Mehrere Suchbegriffe können durch boolsche Verknüpfungsopertoren (AND, OR,
NOT) kombiniert werden (z.B. ERP AND "Market Share") und erlauben so eine Präzisierung der gesuchten Informationen.
Bei der Wahl der Suchbegriffe müssen verschiedene Überlegungen angestellt werden.
Meistens existieren für einen Suchbegriff (z.B. Integrierte betriebswirtschaftliche Standardsoftware) verschiedene Synonyme82 (z.B. Betriebswirtschaftliche Anwendungssoftware) nach welchen ebenfalls gesucht werden sollte. Bei Akronymen (z.B. ERP) und
mehrdeutig verwendeten Begriffen (z.B. Sun) besteht darüber hinaus das Problem von
Homonymen83. Die Ergebnisse einer Suche sind in solchen Fällen durchmischt mit
Fundstellen, welche in einem völlig anderen Zusammenhang stehen.84
82
83
84
Vgl. dazu Tab. 2-1.
Vgl. dazu Abb. 2-3; Beispiel: Anstelle von Enterprise Management Systems steht dieses Akronym auch
für Begriffe wie Eligibility Review Program, Event-Related Potential, Evoked Response Potential etc.
Vgl. Knolmayer (1996), S. 87 ff.
35
Ferner muss bei der Auswahl von Suchbegriffen die für das entsprechende Fachgebiet
am meisten verbreitete Sprache verwendet werden. In den Publikationen zur Themen
der Wirtschaftsinformatik dominiert auf dem Internet die englische Sprache. Aus diesem
Grund sind bei der Suche nach englischen Suchbegriffen die meisten Fundstellen zu
erwarten.
Eine weiterer Aspekt stellt das Problem der Aktualität der durch Search Engines ermittelten Informationen dar. Durch die Dynamik im Internet und durch den Time Lag der
Informationsbereitstellung auf Search Engines ist es wahrscheinlich, dass einzelne Fundstellen zum Zeitpunkt der Recherche gar nicht mehr aufrufbar sind. Ausserdem besteht
das Problem der Aktualität der Informationen. Auf schlecht gewarteten Web Servern
befinden sich häufig inhaltlich überholte Informationen.85
Abb. 2-9: Ergebnisse einer Internet-Recherche mit Hotbot nach dem Suchbegriff 'ERP'.
85
36
Vgl. Knolmayer/Buchberger (1997).
Abb. 2-9 zeigt einen Ausschnitt aus den Ergebnissen einer konkreten Internet-Recherche
nach dem Suchbegriff ERP (Enterprise Ressource Planning). In dieser eher allgemein
gefassten Suche mit der Search Engine HotBot wurden zum Zeitpunkt der Recherche
10'425 Fundstellen eruiert. Die gefundenen Web-Seiten werden hauptsächlich nach
Häufigkeit der darin aufgefundenen Suchbegriffe aufgelistet. Daneben sind das Erscheinen von Suchbegriffen im Titel und im Keyword-Bereich des Codes, die Dokumentenlänge sowie weitere Kriterien für die Bestimmung der Reihenfolge relevant. An erster
Stelle steht bei dieser Recherche eine Online-Publikation zur ERP-Systemen für den
mittleren Leistungsbereich (Midrange ERP Magazine).
Der Ausschnitt aus der Recherche in Abb. 2-9 zeigt auch deutlich die Homonymproblematik. Der Begriff ERP kann in einem anderen Zusammenhang eine abweichende
Bedeutung haben.
Abb. 2-10: Web-Seite einer Online-Zeitschrift zum Thema 'ERP'.
37
Abb. 2-10 zeigt einen Auszug einer Web-Seite (News) des bereits erwähnten MidrangeERP-Magazins. Darin sind aktuelle Produkt- und Herstellerinformationen enthalten.
Anhand solcher Übersichten können Informationen zu meisten auf dem Markt existierenden Systemen gesammelt werden. In einem zweiten Schritt lassen sich durch eine
gezielte Suche nach bestimmten Produkten weitergehende Informationen finden. Tab.
2-7 stellt die WWW-Adressen verschiedener international operierender EMS-Hersteller
zusammen. Auf den zugehörigen Web Sites können aktuelle Informationen zu den erhältlichen Produkten betrachtet werden und aufgrund der vorliegenden Informationen
eine Vorselektion getroffen werden. Natürlich besteht auch bei diesem Medium keine
Gewähr, dass die Hersteller aller für den konkreten Fall relevanten Systeme auf dem
Internet präsent sind oder deren WWW-Adresse eruiert werden kann. Das Internet
überzeugt aber vor allem durch die Schnelligkeit des Zugriffs und die Aktualität solcher
Informationen.
Produkt
Hersteller
WWW-Adresse
R/3
SAP AG
http://www.sap-ag.de/
CA-PRMS
Computer Associates
http://www.cai.com/
BPCS
SSA
http://www.ssax.com/
Baan IV
Baan
http://www.baan.com/
PRISM
Marcam
http://www.marcam.com/
JDE
J.D. Edwards
http://www.jdedwards.com/
Oracle Applications
Oracle
http://www.oracle.com/
PeopleSoft
PeopleSoft
http://www.peoplesoft.com/
QAD
QAD
http://www.qad.com/
CINCOM
Cincom
http://www.cincom.com/
Tab. 2-7: Übersicht über weltweit eingesetzte EMS.
Neben den eigentlichen Produktbeschreibungen sind auch Informationen zu Nebenleistungen (Beratungsfirmen, Ausbildungsangebote, Hardwarelieferanten etc.) auf dem
Internet verfügbar.86 Durch vorhandene Links können auf einer Web-Seite Bezüge zu
86
Vgl. Knolmayer (1996), S. 87 ff.
38
thematisch verwandten Seiten hergestellt werden. Auf der SAP R/3 WWW-Seite des
Instituts für Wirtschaftsinformatik der Universität Bern (vgl. Abb. 2-11) sind z.B. Links zu
vielfältigen Informationen im SAP-Umfeld vorhanden. Diese können direkt durch Anklicken auf den entsprechenden Servern aufgerufen werden.
Abb. 2-11: Auszug R/3-WWW-Seite des Instituts für Wirtschaftsinformatik der Universität
Bern (Stand: 17.03.1997).
Unter Berücksichtigung der genannten Einschränkungen stellt die Informationsbeschaffung über Internet eine echte Alternative zu den herkömmlichen, eher umständlichen
Informationsbeschaffungsmöglichkeiten dar.
Weitere Information für die Vorselektion von in Frage kommenden Produkten können
z.B. auch auf Messen (z.B. CeBIT), auf Informationsveranstaltungen der entsprechenden
Anbieter oder im Rahmen von Seminarien produkteunabhängiger Veranstalter beschafft
39
werden. Ferner stellen auch Hochschulen Informationen in Form von empirischen Studien87, Kundenzufriedenheitsuntersuchungen88 oder Fallstudien zur Verfügung.
Für die eigentliche Produktbeurteilung eignen sich bei einfachen Systemen am besten
Testinstallationen, bei welchen die vorhandene Funktionalität an konkreten Beispielen
beurteilt werden kann. Dieses Vorgehen ist allerdings sehr aufwendig und bei EMS
kaum durchführbar.
Eine weitere Möglichkeit der Informationsbeschaffung zur konkreten Beurteilung eines
Produkts stellen Besuche bei Referenzkunden dar. In diesen Fällen können allerdings
nur generelle Aspekte betrachtet werden und die Beurteilung der Eignung eines Systems
in Hinblick auf den individuellen Einsatz kommt eher zu kurz.
Für gewisse Produkte sind in der Literatur89 umfangreiche Publikationen zu finden, in
welchen die Funktionalität und Einsatzmöglichkeiten im Detail beschrieben werden.
Aber auch bei diesen Darstellungen fehlt ein direkter Bezug zu den Prozessen des betrachteten Unternehmens und es können nur Mutmassungen über die Eignung eines
Produktes angestellt werden.
Nicht zuletzt soll auch die Möglichkeit des Einbezugs von Beratungsunternehmen in den
Evaluationsprozess diskutiert werden. Dabei muss allerdings beachtet werden, dass das
gewählte Unternehmen nicht nur Beratungsdienstleistungen für ein bestimmtes Produkt
anbietet, weil dadurch die Unabhängigkeit der Evaluation leiden könnte. Ferner muss
darüber nachgedacht werden, ob für die Produktebeurteilung und die Einführung unterschiedliche Beratungsunternehmen herangezogen werden sollen, damit produktbezogene Präferenzen der Beratungsunternehmungen bei der Auswahl im Hinblick auf die
nachfolgende Einführung des Systems und die damit verbundenen Beratungsdienstleistungen weniger stark zum Ausdruck kommen.
87
88
89
40
Vgl. Knolmayer/Portner/von Arb (1995); Knolmayer/von Arb/Zimmerli (1997).
Vgl. Strebi (1996).
Vgl. z.B. Wenzel (1995a); ASAP World Consultancy/Blain (1997).
2.3.4 Nutzwertanalyse zur Auswahl von EMS
Bei der Nutzwertanalyse90 handelt es sich um ein Verfahren, das mit Hilfe der Multifaktorentechnik eine Lösungsfindung auf systematischem und nachvollziehbarem Weg
ermöglicht. Der Einsatz dieser Technik zur systematischen Lösungsfindung von Entscheidproblemen aller Art bietet grundsätzlich die gleichen Vorteile wie die Punktbewertung:91
• Gleichzeitige Betrachtung mehrerer Auswahlkriterien
• Berücksichtigung quantitativer und qualitativer Auswahlkriterien
• Beteiligung verschiedener Personen an der Auswahlentscheidung.
Der Hauptvorteil der Nutzwertanalyse ist die parallele Berücksichtigung von quantitativen und qualitativen Entscheidkriterien. Der Nutzen von EMS kann in den meisten Fällen nur teilweise quantitativ bestimmt werden, weil Faktoren wie beispielsweise Wettbewerbsvorteile, Informationsnutzen und Benutzerfreundlichkeit sich nur schwer monetär messen lassen.
Das Vorgehen bei der Nutzwertanalyse umfasst in vier Phasen. Im ersten Schritt werden
die Bewertungskriterien für die Auswahl der Alternativen festgelegt.92 Die Unterteilung
der Kriterien in Muss-Kriterien (Auswahlkriterien, welche die Gestaltungsalternative auf
jeden Fall erfüllen muss) und Kann-Kriterien ermöglicht die Durchführung einer Vorauswahl. Beispiele für Muss-Kriterien (K.O.-Kriterien) sind z.B. Preisobergrenzen, zwingend geforderte Funktionen oder die Gewährleistung von Wartungsleistungen (vgl. Abb.
2-12). Durch die Beschränkung der für eine detaillierte Evaluation in Frage kommenden
Produkte (z.B. auf drei bis maximal fünf Produkte93) kann der Aufwand für den Auswahlprozess reduziert werden. Es konnte z.B. empirisch nachgewiesen werden, dass
Entscheidträger meist nur eine geringe Zahl von Bewertungskriterien in ihre Betrachtun-
90
91
92
93
Vgl. z.B. Brenner (1990), S. 12 ff.; Grochla (1982), S. 401 ff.; Litke (1995), S. 144 ff.; Schmidt
(1991), S 254 ff.; Stahlknecht (1995), S. 319 ff.
Vgl. Grochla (1982), S. 400.
Vgl. Kap. 2.3.
41
gen einbeziehen. Deshalb wird häufig empfohlen, nicht mehr als 5-10 Zielkriterien für
die Bewertung der verschiedenen Alternativen zu verwenden.94 Im Rahmen einer mehrstufigen Nutzwertanalyse95 besteht die Möglichkeit, einzelne Kriterien (z.B. die Lieferantenbeurteilung) noch weiter zu unterteilen (z.B. in Marktstellung, Branchenerfahrung,
Vertragsbedingungen, Zusatzleistungen). Durch diese Verfeinerung können die einzelnen Hauptkriterien differenzierter ausgewertet werden.
Lösungsvarianten
EMS A
EMS B
EMS C
Muss-Kriterien
Maximalkosten 2 Mio. SFr.
Client/Server-Architektur
Oracle Datenbankunterstützung
.
.
.
Kann-Kriterien
Wirtschaftlichkeit
· Einführungskosten
· Wartungskosten
Systemmerkmale
· Integrationsgrad
· Funktionsabdeckungsgrad
· Flexibilität
Anwenderzufriedenheit
Herstellerbeurteilung
· Marktanteil
· Potential für
Weiterentwicklung
· Serviceleistungen
1.9 Mio.
Ja
Ja
1.7 Mio.
Ja
Nein
1.2 Mio.
Ja
Ja
Gewichtungsfaktor
Punkte
Gewichtete
Punktzahl
Punkte
Gewichtete
Punktzahl
Punkte
Gewichtete
Punktzahl
10
20
2
4
20
80
5
6
50
120
9
8
90
160
10
10
100
6
60
3
30
10
10
10
10
100
100
6
6
60
60
2
2
20
20
5
10
50
8
40
8
40
5
10
50
7
35
4
20
20
10
10
8
200
80
5
8
100
80
5
6
100
60
100
780
605
Abb. 2-12: Verwendung der Nutzwertanalyse für die Auswahl von EMS.
94
95
42
Vgl. Grochla (1982), S. 402.
Vgl. Stahlknecht (1995), S. 319 f.
540
Im zweiten Schritt wird die prozentuale Gewichtung der einzelnen Kriterien nach vorgenommen. Die Summe aller Gewichtungsfaktoren muss dabei 100% ergeben. Das
Problem dieses Schrittes stellen die subjektiven Einflüsse bei der Zuweisung der Einzelgewichte dar. Mögliche Verzerrungen lassen sich durch die Übertragung dieser Aufgabe
an mehrere Personen reduzieren.96
Anschliessend erfolgt im dritten Schritt die Bewertung der zur Auswahl stehenden Produkte durch Punktzuweisung. Häufig wird eine Punkteskala von 0 bis 10 für die Bewertung der Einzelkriterien verwendet (10 = höchster Zielerreichungsgrad).97
Im letzten Schritt werden die Werte der einzelnen Kriterien addiert und daraus die gewichteten Punkttotale errechnet. Für alle gewählten Produkte lässt sich anschliessend
eine Rangordnung aufstellen.
Durch die Durchführung einer Sensitivitätsanalyse kann untersucht werden, wie sich
eine Veränderung der Gewichtungs- oder Punktebewertung auf die das Gesamtergebnis
auswirkt. Dadurch lässt sich überprüfen, wie stabil oder empfindlich sich die favorisierte
Variante bei veränderten Bedingungen verhält.98
Die Vorteile dieses Verfahrens liegen in der Berücksichtigung quantiativer und qualitativer Aspekte bei der Bewertung der Alternativen. Als Nachteil mag sich die nicht unproblematische Bemessung der Gewichtungsfaktoren erweisen.99
96
97
98
99
Vgl. Grochla (1982), S. 401.
Vgl. Grochla (1982), S. 404; Schmidt (1991), S. 254.
Vgl. Schmidt (1991), S. 257.
43
2.3.5 Neuformulierung des Projektauftrages
Ähnlich wie beim Entwicklungszyklus von Anwendungssystemen erfolgt vor Abschluss
der Analysephase die Präzisierung resp. Neuformulierung des Projektauftrags.100 Erkenntnisse aus der Analysephase und spezielle Erfordernisse des gewählten Systems
machen diesen Schritt meist notwendig, weil dadurch entscheidende Weichen gestellt
werden. Unterlassungen in dieser Hinsicht können während des Projekts schwerwiegende Auswirkungen haben.101 Parallel zur Neuformulierung des Projektauftrags werden
die Vertragsverhandlungen mit den involvierten Parteien durchgeführt. Diese Gesichtspunkte werden hier allerdings nicht näher betrachtet, sondern in Kapitel 4 ausführlich
dargestellt.
2.3.6 Begründung der Wahl von SAP R/3
2.3.6.1 Beschränkung der Betrachtungen auf ein einziges System
Für die weitere Untersuchung des Einführungsprozesses von EMS werden die Ausführungen auf die Betrachtung eines einzigen Systems (SAP R/3) beschränkt. Der Grund für
diese Einschränkung ist vor allem im Funktionsumfang und in der Komplexität von EMS
zu suchen. Im folgenden Kapitel wird ein kurzer Überblick über den Funktionsumfang
von SAP R/3 gegeben. Mit dieser Darstellung soll ein Bewusstsein für die Komplexität
solcher Systeme geschaffen werden und gleichzeitig zum Ausdruck gebracht werden,
dass mit dem Einsatz von R/3 nahezu das ganze Spektrum betriebswirtschaftlich notwendiger Funktionen integrativ abgedeckt werden kann. Vergleichende Darstellungen
verschiedener Systeme würden den Rahmen dieser Arbeit sprengen. Die Wahl des R/3System für die Untersuchung von Einführungsprojekten wird in den folgenden Abschnitten ausführlich begründet.
100
101
44
Vgl. Groth et al. (1983), S. 89.
2.3.6.2 Argumente für SAP R/3
Als Massstab für die Bewertung des R/3-Systems soll der in Kap. 2.3.2 dargestellte Kriterienkatalog als Rahmen herangezogen werden. Die Hauptkriterien in dieser Aufstellung
waren
Leistungsumfang
Das R/3-System deckt aus betriebswirtschaftlicher Sicht die meisten Funktionen in den
Bereichen Finanzwesen, Logistik und Personalwesen ab. Für verschiedene Branchen
(z.B. Chemische Industrie, Automobilindustrie, Banken, Versicherungen oder Öffentliche Verwaltungen) existieren Speziallösungen, welche die Grundfunktionen des R/3Systems entsprechend den Bedürfnissen einer Branche ergänzen. Durch die Unterstützung verschiedener Sprachen und die Abdeckung der gesetzlichen Bestimmungen
mehrerer Länder lässt sich das R/3-System auch in international tätigen Firmen und
Konzernen einsetzen. Der grosse Funktionsumfang ermöglicht verbunden mit dem hohen Integrationsgrad der einzelnen Module die durchgängige Unterstützung der Geschäftsprozesse eines Unternehmens.
Architektur des R/3-Systems
Die Architektur des R/3-Systems basiert auf einer mehrstufigen Client/Server-Architektur, welche sich flexibel an den Leistungsbedarf eines Unternehmens anpassen lässt.
Die Benutzerinteraktion erfolgt über eine einheitlich gestaltete graphische Oberfläche,
was zu einer Erhöhung der Akzeptanz und einer Reduktion der Einarbeitungszeit führt.
Die Verarbeitung der Daten erfolgt, wie der Name des Systems andeutet (R = Realtime)
in Echtzeitverarbeitung. Darüber hinaus bietet R/3 einen hohen Grad an Offenheit
durch die Möglichkeit der Verwendung verschiedener Betriebssysteme, Datenbanken,
Benutzeroberflächen und Programmiersprachen. In technischer Hinsicht sind die Umsetzung der Client/Server-Architektur und die relative Offenheit Hauptargumente für
den Einsatz des R/3-Systems.
45
Stellung des Anbieters
Die SAP AG hat auf dem Markt für Enterprise-Management-Systeme in vielen Branchen
über 30% Marktanteil erreicht. Gleichzeitig ist auf dem Markt für EMS ein stetiges
Wachstum zu beobachten und eine Fortsetzung dieses Trends wird bis über die Jahrtausend-Grenze hinaus prognostiziert. Hohe Gewinne ermöglichen der SAP AG einen
überdurchschnittlich grossen Teil ihres Budgets in Forschung und Entwicklung zu investieren. Ansehnliche Marktanteile, die hohe Finanzkraft und im Verhältnis zur Grösse
des Unternehmens überdurchschnittliche Serviceleistungen vermitteln einen soliden
Eindruck und geben eine gewisse Sicherheit für die Weiterentwicklung von R/3.
2.3.6.3 Argumente gegen SAP R/3
Durch die starke Stellung der SAP AG auf dem Markt für Enterprise Management Systeme wird z.B. in Fachzeitschriften viel zum Thema R/3 publiziert. Neben teilweise
unkritischen und stark positiven Darstellungen ("Success Stories") wird die Diskussion
vereinzelt auf einem eher unsachlichen Niveau geführt. Einseitig recherchierte Berichte102 verbreiteten Gerüchte haben in der Vergangenheit zu Gegendarstellungen der SAP
AG und sogar zu mittelfristigen Beeinflussungen des SAP-Aktienkurses geführt.103
Es gibt etliche Argumente gegen den Einsatz des R/3-Systems. Das Gewicht der meisten
Argumente konnte in den letzten Jahren durch die Weiterentwicklung des Systems reduziert werden. Im folgenden sollen einige dieser Argumente kurz betrachtet werden:
Komplexität/Inflexibilität
Zu hohe Komplexität, mangelnde Flexibilität und eine damit verbundene Zementierung
der implementierten Geschäftsprozesse sind Vorwürfe, die im Zusammenhang mit dem
Einsatz von R/3 häufig zu hören sind.104 Das R/3-System deckt die betriebswirtschaftliche Anwendungsebene breit ab.
102
103
104
46
Vgl. Böndel (1995); Cameron et al. (1996).
Vgl. NN (1996a).
Vgl. z.B. Böndel (1995), S. 114; Eberlein/Koopmann/Okroy (1995), S. 8.
Der Vorwurf der Komplexität hängt mit der Funktionsvielfalt zusammen. Wird die vorhandene Komplexität derjenigen einer Eigenentwicklung mit vergleichbarem Funktionsumfang gegenübergestellt, dann lässt sich diese Aussage relativieren.
Der Vorwurf der Inflexibilität ist eher unzutreffend, denn gerade der grosse Funktionsumfang ermöglicht den Einsatz eines einzigen EMS auch wenn ein Unternehmen z.B.
über unterschiedliche Fertigungstypen verfügt. Sicherlich ist der Umstellungsaufwand
bei konzeptionellen Fehlern relativ gross und einige wenige Einstellungen lassen sich
nach durchgeführtem Customizing nicht mehr verändern. Dennoch können einmal implementierte Geschäftsprozesse in der Regel in relativ kurzer Zeit an die veränderten
Bedürfnisse angepasst werden.105
Der Vorwurf, das R/3-System sei monolithisch106, ist eher unverständlich. Durch die
weitgehende Modularisierung der betriebswirtschaftlichen Anwendungskomponenten,
die Möglichkeit der Integration von Internet- und Intranet-Applikationen und das bereits
teilweise umgesetzte Business-Framework-Konzept lässt sich das R/3-System an viele
Bedürfnisse anpassen und besitzt einen hohen Grad an Offenheit.
Fragwürdige Mittelstandsfähigkeit
Das R/3-System ist in seiner Struktur auf den Einsatz in Grossunternehmen ausgerichtet.
Versuche, eine Mittelstandversion ("Heidelberg") zu entwickeln sind an den zu unterschiedlichen Anforderungen von KMUs gescheitert.107 Durch teilweise vorkonfigurierte
Systeme und den Einsatz Softwareunterstützungswerkzeugen wird nun versucht, eine
Vereinfachung des Einführungprozesses zu bewirken. Dennoch ist es ratsam, in KMUs
eine detaillierte Kosten-Nutzen-Betrachtung zu machen und sich die Frage zu stellen,
ob sich der Einsatz von R/3 lohnt oder ob kostengünstigere Systeme die notwendigen
Bedürfnisse nicht auch abdecken können.
105
106
107
Vgl. Böndel (1995), S. 118; Eberlein/Koopmann/Okroy (1995), S. 6.
Vgl. Böndel (1995), S. 112; Cameron et al. (1996).
Vgl. Vaske (1996), S. 7, 10.
47
Einsatz veralteter Technologien
Die Vorwürfe der Verwendung veralteter Technologien beziehen sich vorwiegend auf
die scheinbar fehlende Prozess- und Objektorientierung.108 Das R/3-System ist funktionsorientiert gegliedert. Dies ist schon an den Modulbezeichnungen (z.B. Vertrieb,
Materialwirtschaft oder Personalwesen) erkennbar.109 Durch die Integration der einzelnen Funktionen können im R/3-System durchgängige Geschäftsprozesse abgebildet
werden. Die Transparenz über die einzelnen Prozesse wird durch entsprechende Werkzeuge (Business Navigator, ARIS-Toolset etc.) sichergestellt. Die Aussage, das R/3System sei nicht prozessorientiert, muss relativiert werden. Die Prozessorientierung
hängt im wesentlichen von der Art der Einführung ab.
Bezüglich der Objektorientierung gilt es anzuführen, dass R/3 nicht objektorientiert implementiert wurde. Allerdings werden verschiedene konzeptionelle Überlegungen der
Objektorientierung (z.B. Objektbindung und Objektkapselung) bei der Implementierung
von Business Objekten berücksichtigt.110 Die Datenspeicherung erfolgt in relationalen
Datenbanksystemen. Dies ist vor allem dadurch begründet, dass auf dem Markt zum
aktuellen Zeitpunkt keine kommerziell verwendbare, objektorientierte Datenbanksysteme mit hinreichender Stabilität und Funktionalität verfügbar sind.111
Lange Einführungszeiten
Die Einführung von R/3 dauert im Vergleich zu anderen EMS relativ lange.112 Dies ist vor
allem auf den grossen Funktionsumfang zurückzuführen, welcher sich bei der Ermittlung
und Implementierung der benötigten Funktionen als Ballast auswirkt. Darüber hinaus
erfordert die Integration des Systems den Einbezug weiter Bereiche eines Unternehmens. Dies führt zu einem erhöhten Koordinationsaufwand und damit verbunden oft zu
einer nicht unerheblichen Einführungsdauer. Auch hier steht die Komplexität des R/3Systems im Konflikt mit der Flexibilität. Durch Softwareunterstützungswerkzeuge
108
109
110
111
112
48
Vgl. Eberlein/Koopmann/Okroy (1995), S. 12.
Vgl. Eberlein/Koopmann/Okroy (1995), S. 7.
Vgl. Eberlein/Koopmann/Okroy (1995), S. 6 ff.
Vgl. Böndel (1995), S. 118.
Vgl. Böndel (1995), S. 117; Eberlein/Koopmann/Okroy (1995), S. 12; Vaske (1996), S. 7 ff.
(Business Engineering Workbench; BEW) wird versucht, den Einführungsprozess besser
zu strukturieren und dadurch zu vereinfachen, damit eine Verkürzung der Einführungszeiten realisierbar wird.
Zentrale Datenhaltung
Die Vor- und Nachteile dezentraler Datenhaltung sind grundsätzlich umstritten.113 Daher bietet das R/3-System durch das ALE-Konzept ansatzweise die Möglichkeit verschiedene R/3-Systeme zu koppeln und damit eine teilweise dezentrale Datenhaltung zu
ermöglichen.
Schlechte Qualität neu ausgelieferter Versionen
Die schlechte Qualität ist vielen auf dem Markt verfügbaren Anwendungssystemen festzustellen. Der grosse Konkurrenzdruck und die gegenüber der Vergangenheit gestiegene
Erwartungshaltung der Anwender verleitet die Standardsoftware-Hersteller schlecht getestete Versionen freizugeben. Aus diesen Gründen sind die ersten Putlevel-Stände
meist stark fehleranfällig und viele Anwender ziehen das Warten auf einen stabilen
Putlevel vor.
113
Vgl. Codd (1990), S. 391 ff.; Eberlein/Koopmann/Okroy (1995), S. 7; Elmasri/Navathe (1994), 703
ff.; Scheer (1995), S. 79 ff.; Stahlknecht (1995), S. 226 ff.
49
Das R/3-System
3 Das R/3-System
3.1 Einleitung
Im folgenden Kapitel wird die Funktionalität des betriebswirtschaftlichen Anwendungssystems R/3 der SAP AG dargestellt. Der erste Teil dieses Kapitels beschreibt die Geschichte, die Unternehmensstrategie und die Marktstellung der SAP AG. Im zweiten Teil
des Kapitels werden die grundlegenden Organisationsstrukturen, die Hauptanwendungsbereiche und die Architektur des R/3-Systems dargestellt. Die Beschreibung des
R/3-Systems basiert auf der Funktionalität des 1998 auf dem Markt verfügbar gewordenen Release 4.0.
Die ausführliche Darstellung der betriebswirtschaftlichen Funktionalität dient der Verdeutlichung der im vorangehenden Kapitel genannten Vor- und Nachteile von Enterprise Management Systemen. Insbesondere soll dadurch ein Verständnis für die Funktionsvielfalt, den hohen Integrationsgrad und die damit verbundene Komplexität eines solchen Systems geschaffen werden.
Gleichzeitig stellt dieses Kapitel die Wissensgrundlage für die in den folgenden Kapiteln
behandelten Themenbereiche (Einführung von EMS und Erfahrungen mit der Einführung von EMS) dar.
51
Das R/3-System
3.2 Unternehmensprofil der SAP AG
3.2.1 Geschichte
SAP wurde 1972 von 4 ehemaligen IBM-Technikern gegründet. Das Unternehmen,
welches anfänglich unter dem Namen "Systemanalyse und Programmentwicklung" existierte, wurde 1977 in die SAP GmbH (SAP = Systeme, Anwendungen und Produkte in
der Datenverarbeitung) mit Firmensitz in Walldorf umgewandelt. 1988 erfolgte eine
nochmalige Änderung der Rechtsform in eine börsennotierte Aktiengesellschaft. 1993
wurde die SAP-Aktie sogar mit einem Gewicht von 0.94 Prozentpunkten in den Deutschen Aktienindex (DAX 100) und in den FAZ-Index einbezogen. Seit Mitte 1994 ist die
SAP-Aktie auch im integrierten Börsenhandels- und Informationssystem (IBIS) vertreten
und kann dadurch auch international gehandelt werden. Die wichtigsten Meilensteine
des Unternehmens können Abb. 3-1 entnommen werden.
Jahr
Ereignis
1972
Gründung der SAP unter dem Namen "Systemanalyse und Programmentwicklung"
Ab 1973
Stufenweise Entwicklung und Einführung verschiedener Module einer betriebswirtschaftlichen Gesamtlösung
1976
Umwandlung in die SAP GmbH mit Sitz in Walldorf (D)
1979
Markteinführung des R/2-Systems
1984
Gründung der Holdinggesellschaft SAP (International) AG mit Sitz in Biel/CH (Zweck:
Errichtung eines Netzes von Landesgesellschaften)
1987
Entwicklungsbeginn von R/3
1988
Umwandlung in eine AG mit Börsennotierung
1992
Integration der Holdinggesellschaft in die SAP AG
1992
Einführung des R/3-Systems (Release 1.0)
Ab 1989
Gründung von und Beteiligung an verschiedenen Gesellschaften
1994
SAP durchbricht die 1'000 Mio USD Umsatzgrenze
1996
SAP wird zum viertgrössten unabhängigen Softwarehersteller
Abb. 3-1: Entstehungsgeschichte der SAP AG.
52
Das R/3-System
3.2.2 Unternehmensstrategie
Von Anfang an wurde die Idee verfolgt, Standardsoftware für betriebliche Abläufe zu
entwickeln. Dabei standen vor allem folgende Aspekte im Vordergrund:
• Branchenneutralität (durch Customizing individuell anpassbar)
• Internationale Einsetzbarkeit (rechtliche Anforderungen, Sprach- und Währungsunabhängigkeit)
• Vollständige funktionale Integration aller betrieblichen Bereiche
• Modularer Aufbau
• Zentrale Datenhaltung
• Einheitliche Benutzeroberfläche
• Offene Systemarchitektur
• Hardwareunabhängigkeit durch klare Trennung von Basis- und betriebswirtschaftlichen Anwendungen
Mittlerweile ist die SAP zu einem der grössten Softwarehäuser der Welt herangewachsen. Lange Zeit stand der deutsche Markt im Zentrum der Aktivitäten. Durch die Internationalisierung der Anwendungssoftware hat die SAP ihren Absatzmarkt zunehmend
ausgedehnt. Das Unternehmen ist heute in über 50 Ländern auf sämtlichen Kontinenten
der Welt vertreten. Der nordamerikanische Markt zählt aufgrund des zu erwartenden
Wachstumspotentials zu den Schlüsselmärkten.
Der technologische Vorsprung ist vor allem auf das hohe Forschungs- und Entwicklungsbudget zurückzuführen, welches gegen 20% des Umsatzes ausmacht. Hinzu
kommt, dass in den Entwicklungszentren in Deutschland, Japan und den Vereinigten
Staaten (verschiedene Zeitzonen) rund um die Uhr entwickelt werden kann.
Mit dem Release 4.0 deckt das R/3-System über 1'000 verschiedene betriebliche Geschäftsprozesse ab. Mit dieser Funktionsvielfalt können praktisch sämtliche Informationsbedürfnisse moderner Industriebetriebe abgedeckt werden. Zusätzlich vermindert
der hohe Integrationsgrad der einzelnen Funktionen die Datenredundanz und vereinfacht gleichzeitig die Abwicklung der betrieblichen Prozesse. Die im R/3-System vor53
Das R/3-System
handenen Prozesse können dabei als Referenzprozesse (Best Practice in Business) betrachtet werden und bieten die ideale Grundlage für Business Reengineering-Projekte.
Dem Aspekt der kundengerechten Lösungen trägt die SAP vor allem durch lange Tradition mit strategischen Partnerschaften Rechnung. Mit Hilfe dieser Partnerschaften
kann die Integration zu anderen Systemen erweitert werden. Zusätzlich wird indirekt
die Offenheit des Systems gefördert und erfolgversprechende neue Technologien können innert kürzester Zeit in das R/3-System integriert werden. Der geregelte Erfahrungsaustausch ermöglicht gleichzeitig eine bessere Berücksichtigung der Kundenbedürfnisse
bei der Entwicklung des R/3-Systems.
3.2.3 Produkte
SAP bietet auf dem Markt für betriebswirtschaftliche Standardsoftware 2 Produktelinien
an. Für Grossrechneranwendungen ist das funktionsorientierte R/2-System (R steht für
Realtime) und für offene Architekturen (Client/Server) das eher prozessorientierte R/3System vorgesehen. Die beiden Systeme unterstützen folgende Hauptanwendungsgebiete:
• Rechnungswesen
• Logistik (Beschaffung-, Produktions- und Vertriebslogistik)
• Personalwirtschaft.
SAP R/2
Das R/2-System kam 1979 auf den Markt. Es verfügt über eine funktionale Gliederung
und eignet sich speziell für grosse, zentralistisch organisierte Unternehmen mit einer
hostbasierten Datenverarbeitung und einem hohen Transaktionsvolumen. Die grössten
Installationen ermöglichen bis zu 4'000 Endbenutzern einen gleichzeitigen Zugriff auf
die betrieblichen Daten. Das R/2-System wurde seit 1973 kontinuierlich weiterentwickelt und hat mit dem Release 6.0 seine endgültige Version erreicht. Das Produkt
soll allerdings noch über die Jahrtausendwende hinaus aktualisiert und um neue Funktionen erweitert werden.
54
Das R/3-System
SAP R/3
Parallel zur Entwicklung des R/2-Systems wurde 1985 mit der Entwicklung des R/3Systems begonnen. R/3 stellt dabei eine konsequente Weiterentwicklung des R/2Systems dar und wurde primär für den Client/Server-Markt konzipiert. Mit dem Release
3.0 hatte R/3 ungefähr den gleichen Funktionsumfang erreicht, wie das R/2-System zum
Releasestand 5.0. Da sich SAP bei der Weiterentwicklung primär auf das R/3-System
konzentrieren wird, stellt dies auch den Standard-Migrationspfad für den Umstieg von
R/2 auf R/3 dar. Entgegen allen Gerüchten114, dass zum heutigen Zeitpunkt bereits an
der Entwicklung eines Nachfolgesystems gearbeitet wird, stellt SAP in Aussicht, dass R/3
weit über die Jahrtausendwende hinaus produktiv genutzt werden kann.115 Eine Weiterentwicklung soll evolutionär stattfinden und neben der Erweiterung der betriebswirtschaftlichen Funktionalität soll R/3 zunehmend für den Betrieb in unternehmensweiten
und globalen Netzen116 (Internet und Corporate Intranets) ausgerüstet werden.
114
115
116
Vgl. Cameron et. al. (1996).
Vgl. NN (1996a), S. 4.
Vgl. Bartholomew (1996a), S. 22.
55
Das R/3-System
3.2.4 Partnerkonzept
Viele Unternehmen haben erkannt, dass die Marktposition nur mit Hilfe von strategischen Allianzen erhalten und gestärkt werden kann. Durch entsprechende Kooperationen können Ressourcen gemeinsam verwendet und damit Zeit und Kosten eingespart
werden. Erfolgreiche Allianzen beruhen dabei auf den besonderen Fähigkeiten der
Partner und ermöglichen es durch Ausnutzung der eintretenden Synergieeffekte Wettbewerbsvorteile zu erzielen. Aus diesem Grund hat die SAP ein Partnerkonzept entwikkelt, welches diese Vorteile voll zum Tragen bringen soll. Dabei werden verschiedene
Arten von Partnern unterschieden (Abb. 3-2).
Vertriebsund Entwicklungspartner
Logopartner
BULL
AT&T
COMPAQ
SEQUENT
SNI
IBM
IBM
INFORMIX
Hardwarepartner
SUN
APPLE
DATA GENERAL
HP DIGITAL
Technologiepartner
iXOS
SOFTWARE AG
MICROSOFT
ORACLE
Abb. 3-2: Das Vertriebskonzept der SAP AG.
Die Vertriebs- und Entwicklungspartner bieten ergänzende Produkte zu R/3 an. Diese
Systeme weisen eine zertifizierte Schnittstelle zu R/3 auf. Einige Beispiele sind:
• Archivierungssysteme
• CAD-Systeme
• Geographische Informationssysteme
• Mobile Datenerfassungssysteme.
56
Das R/3-System
Die Beratungspartner (Logopartner) unterstützen R/3-Anwender bei der Implementierung und Schulung des Systems. Es werden dabei je nach Grösse und Marktabdekkung des Unternehmens folgende Arten unterschieden:
• Globale R/3-Logopartner
• Regionale R/3-Logopartner
• Nationale R/3-Logopartner
• R/3-Implementierungspartner.
Als offenes System basiert R/3 auf verschiedenen Betriebssystemen und unterstützt
mehrere Datenbanken und graphische Benutzeroberflächen. Zur Förderung der Kommunikation mit den Herstellern dieser komplementären Softwarekomponenten, hat SAP
diese Beziehungen institutionalisiert. Der Hauptzweck besteht im Austausch von Informationen zu neuen Funktionen und Produkten. Dabei wird zwischen Technologie- und
Plattform-Partnern unterschieden. Als Technologie-Partner gelten die Hersteller der
Datenbanken (z.B. Oracle oder Informix) und der graphischen Benutzeroberflächen
(z.B. Microsoft, Apple oder IBM).
Die Plattform-Partner sind meist mit einem Competence Center bei SAP in Walldorf
vertreten und stellen die Kommunikation zu den Hardware-Herstellern sicher. Dabei
geht es darum, das R/3-System optimal an die verschiedenen Betriebssystemplattformen
anzupassen, resp. diese Plattformen für den produktive Gebrauch zu zertifizieren. Einige
dieser Plattform-Partner sind DEC, HP oder IBM.
Ein Value Added Reseller (dt. R/3-Systemhaus) zeichnet sich dadurch aus, dass er über
Ressourcen für den Verkauf, die Beratung, die Schulung und den Support verfügt. Zusätzlich besitzt er ein eigenes Produkt, welches R/3 ergänzt. In dieser Eigenschaft unterstützt er in Zusammenarbeit mit anderen Beratungspartnern vor allem mittelständische
Unternehmen bei der Einführung von R/3.
57
Das R/3-System
3.3 Hauptanwendungsbereiche des R/3-Systems
3.3.1 Überblick
Das R/3-System deckt einen Grossteil der von Unternehmen verschiedener Branchen
benötigten betriebswirtschaftlichen Funktionen ab. Auf organisatorischer Ebene können
im R/3-System sowohl einzelne Unternehmensbereiche (z.B. die Vertriebsorganisation)
als auch ganze Konzerne mit einer Vielzahl von Tochtergesellschaften abgebildet werden.
Der Aufbau des R/3-Systems ist grundsätzlich funktionsorientiert und richtet sich nach
den allgemein üblichen Hauptanwendungsbereichen Rechnungswesen, Logistik und
Personalwesen. Unter diesen sind die einzelnen Module (z.B. Materialwirtschaft, Vertrieb oder Instandhaltung) angesiedelt. Neben den eigentlichen Hauptanwendungsbereichen werden alle übergreifenden Applikationen (z.B. Branchenlösungen) und das
Basissystem in separaten Anwendungsbereichen geführt. Dies ergibt folgende Grundgliederung für das R/3-System:117
• Rechnungswesen (FI, TR, CO, IM, EC)
• Logistik (LO, SD, MM, PP, QM, PM, PS)
• Personalwesen (PA, PD)
• Branchenlösungen (IS)
• Übergreifende Lösungen (CA)
• Basissystem (BC).
In Abb. 3-3 sind die einzelnen Module und in der folgenden Tabelle (vgl. Tab. 3-1) deren Bedeutung und Einzelkomponenten im Detail dargestellt. Die folgenden Ausführungen richten sich grundsätzlich an dieser Gliederung.
117
58
Auf die Bedeutung der einzelnen Modulbezeichnungen wird in Tab. 3-1 eingegangen.
Das R/3-System
IS
LO
FI
MM
TR
CO
SD
PP
SAP
R/3
IM
QM
PM
EC
PS
PA
PD
BC
CA
Abb. 3-3: Modulgliederung des R/3-Systems.
59
Das R/3-System
•
•
•
FI - Finanzwesen
•
•
•
QM - Qualitätsmanagement
−
Qualitätsplanung
Konsolidierung
−
Umweltdaten
−
Qualitätsprüfung
−
Kreditoren- und
Debitorenbuchhaltung
−
Prognose
−
Qualitätslenkung
−
Variantenkonfiguration
−
Qualitätszeugnisse
−
Anlagenbuchhaltung
−
Änderungsdienst
−
Qualitätsmeldungen
−
Spezielle Ledger
−
Logistikinformationssystem
−
TR - Treasury
−
Cashmanagement
−
Finanzbudgetmanagement
−
Treasury Management
•
CO - Controlling
−
Gemeinkosten-Controlling
−
Produktkosten-Controlling
−
Ergebnis- und
Marktsegementrechnung
•
−
Technische Objekte
Verbrauchsgesteuerte Disposition
−
Vorbeugende Instandhaltung
Instandhaltungsabwicklung
−
Einkauf
−
−
Bestandsführung
−
Instandhaltungsprojekte
Service Management
−
Lagerverwaltung
−
−
Rechnungsprüfung
−
Informationssystem
−
Informationssystem
Versand
−
Transport
−
Aussenhandel
EC - Enterprise Controlling
−
Fakturierung
−
Profit-Center-Rechnung
−
Vertriebsunterstützung
−
Unternehmensplanung
−
Informationssystem
−
Managementkonsolidierung
−
Executive Information System
Sachinvestitionen
PA - Personaladministration und
-abrechung
−
Personaladministration
−
Arbeitgeberleistungen
−
Personalbeschaffung
−
Zeitwirtschaft
−
Leistungslohn
−
Reise
−
Abrechnung
PD - Personalplanung und
-entwicklung
•
•
SD - Vertrieb
−
IM - Investitionsmanagement
PM - Instandhaltung
−
Verkauf
Prozesskostenrechnung
•
MM - Materialwirtschaft
−
−
•
LO - Logistik allgmein
Grunddaten Logistik
Hauptbuchhaltung
−
•
•
−
−
•
PP - Produktionsplanung und
-steuerung
PS - Projektmanagement
−
Grunddaten
−
Operative Strukturen
−
Projektplanung
−
Projektbudgetierung
−
Projektrealisierung/Integration
−
Informationssystem
BC - Basissystem
−
Kernel-Komponenten
−
Systemadministration
−
Betriebssystemplattformen
−
Datenbankplattformen
−
Frontend-Plattformen
−
ABAP/4 Development Workbench
−
Business Engineering Workbench
(Workflow Management)
−
Stücklisten, Arbeitsplätze und
Arbeitspläne
−
Absatz- und Produktionsgrobplanung
−
Produktionsplanung
−
Kapazitätsplanung
−
Bedarfsplanung
CA - Anwendungsübergreifende
Komponenten
−
Kanban
−
Dokumentenverwaltung
−
Planung- und Steuerung bei
Serienfertigung
−
Klassensystem
−
CAD-Integration
−
Montage
−
ALE
−
Produktionsplanung
Prozessindustrie
−
Organisationsmanagement
−
Personalentwicklung
−
Betriebsdatenerfassung
−
Personaleinsatz
−
Informationssystem
−
Veranstaltungsmanagement
−
Raumbelegungsplanung
•
•
IS - Branchenlösungen (Beispiele)
−
IS-Oil (Ölverarbeitung)
−
IS-Banking
−
IS-Retail
−
...
Tab. 3-1: R/3-Module und deren Komponenten.
Neben der Gliederung der Funktionen in einzelne Module verfügt das R/3-System über
eine grosse Zahl verschiedener Organisationseinheiten als Grundlage für die Abbildung
der betrieblichen Ausbauorganisation. Dabei existieren einerseits grundlegende Organisationseinheiten (z.B. zur Abbildung eines Konzerns), welche grundsätzlich im Rechtssystem verankert sind und andererseits Organisationseinheiten zur Abbildung einzelner
Anwendungsbereiche (z.B. der Vertriebsorganisation). Diese verschiedenen Arten von
Organisationseinheiten werden im folgenden dargestellt.
60
Das R/3-System
3.3.2 Organisationsstrukturen des R/3-Systems
3.3.2.1 Grundlegende Organisationseinheiten
Die Abbildung komplexer Unternehmensstrukturen wird im R/3-System durch die Existenz flexibler Organisationseinheiten sichergestellt. Das organisatorische Konzept des
R/3-Systems basiert auf einer Konzernstruktur. Diese wird durch Verknüpfung von einzelnen Organisationseinheiten charakterisiert. Neben den grundlegenden organisatorischen Einheiten (z.B. Konzern oder Tochtergesellschaft) verfügt jeder Bereich des R/3Systems (Rechnungswesen, Logistik und Personalwesen) über spezifische Organisationseinheiten.
Von der organisatorischen Gliederung ist die systemtechnische Gliederung zu unterscheiden. Diese ist der organisatorischen Gliederung übergeordnet hat nur einen indirekten Einfluss auf die organisatorische Struktur eines Unternehmens. Die Grundeinheit
von R/3 stellt das System dar. Ein System ist eine in sich abgeschlossene Installation von
R/3 mit eigenem Datenbestand. Innerhalb eines Systems können mehrere Mandanten
angelegt werden. Diese stellen jeweils einen Konzern dar. Bei einer R/3-Einführung
werden in der Regel mehrere Mandanten (Referenzmandant118, Testmandant und Produktivmandant) gleichzeitig verwendet.
Auf organisatorischer Ebene stellt der Mandant (Konzern) das übergeordnete Element
aller Organisationseinheiten dar. Verschiedene Datenbestände (z.B. Materialstamm)
können auf Mandantenebene geführt werden. Dadurch wird eine redundante Datenhaltung verhindert. Die einzelnen Tochtergesellschaften eines Konzerns werden Buchungskreise genannt und stellen rechtlich unabhängige Gesellschaften (z.B. eine AG
oder GmbH) dar. Die Betriebsstätten oder Niederlassungen einer Gesellschaft werden
als Werke bezeichnet. Auf dieser Ebene findet die Materialdisposition und die Bestandsführung statt.
118
Referenzmandant = voreingestellter Mandant mit einem Referenzdatenbestand (z.B. IDESDemosystem, vgl. Kapitel 3.3.6).
61
Das R/3-System
Grundlegende Organisationseinheiten
Mandant (Konzern)
001
0001
Buchungskreis
Werk
0001
0002
0002
0003
Abb. 3-4: Grundlegende Organisationseinheiten des R/3-Systems.
3.3.2.2 Organisationseinheiten der Logistik
Im Bereich der Logistik (LO, SD, MM, PP, QM, PM, PS) existieren weitere Organisationseinheiten, welche vorwiegend zur Strukturierung des Beschaffungs- und Vertriebsprozesses dienen. In der folgenden Darstellung werden nur die wichtigsten Elemente
genannt:
• Einkaufsorganisation
• Verkaufsorganisation
• Lager.
Die Einkaufsorganisation ist den einzelnen Werken übergeordnet und dient zur zentralen Beschaffung von Materialien oder Dienstleistungen. Durch die Konzentration des
Einkaufs lassen sich bessere Konditionen aushandeln und der Einkauf kann für mehrere
Werke gleichzeitig abgewickelt werden.
In einer Verkaufsorganisation wird ähnlich wie bei der Einkaufsorganisation der Verkauf einer Gesellschaft zentralisiert, resp. auf die Bedürfnisse des Marktes zugeschnitten.
Einem Werk können verschiedene Lager zugeordnet werden. In diesen werden die
Materialbestände eines Werkes räumlich zusammengefasst und verwaltet.
62
Das R/3-System
001
Mandant (Konzern)
0001
Unternehmen
Buchungskreis
0001
0002
0003
1000
Einkaufsorganisation
2000
3000
Verkaufsorganisation
Werk
0002
0001
Lager
Lagerort
4000
0002
0001
0003
0002
100-1
0004
0005
0003
100-2
100-3
100-4
Abb. 3-5: Organisationseinheiten der Logistik.
Eine Strukturierung der dargestellten Bereiche (Einkaufs- und Verkaufsorganisation) kann
durch zusätzlich vorhandene Organisationseinheiten vorgenommen werden (z.B. Verkaufsbüro, Verkäufergruppe, Vertriebsweg oder Sparte). Auf diese soll aber in diesem
Kontext nicht näher eingegangen werden.
3.3.2.3 Organisationseinheiten des Finanzwesens
Im Bereich des Finanzwesens (FI, CO, TR, EC und IM) wird grundsätzlich zwischen einer rechtlichen Organisationsstruktur und einer internen Organisationsstruktur unterschieden. Daneben existieren weitere Organisationseinheiten für die Zusammenfassung
bestimmter Merkmale des Finanzwesens. Folgende Organisationseinheiten dienen zur
Abbildung der rechtlichen Struktur:
• Gesellschaft
• Buchungskreis
• Kostenrechnungskreis.
63
Das R/3-System
Die Gesellschaft stellt ein rechtlich selbständiges Unternehmen dar, für das nach handelsrechtlichen Gesichtspunkten eine Bilanz sowie ein Gewinn- und Verlustrechnung
erstellt werden kann. Dabei kann eine Gesellschaft aus einem oder mehreren Buchungskreisen bestehen. Durch diese Zuordnungsmöglichkeit werden Buchungskreise
für eine gemeinsame Konzernrechnungslegung zusammengefasst.
Ein Buchungskreis ist in der Regel ebenfalls eine rechtlich selbständige Einheit
(Ausnahme: ausländische Betriebsstätte mit eigener Währung und speziellen steuerrechtlichen Anforderungen), für die eine abgeschlossene Buchhaltung (Bilanz, Gewinnund Verlustrechnung) geführt werden kann. Für jeden Mandanten können mehrere Buchungskreise eingerichtet werden. Dabei muss für jeden Mandanten mindestens ein
Buchungskreis angelegt sein.
Der Kostenrechnungskreis definiert die organisatorische Einheit, für die eine eigenständige Kostenrechnung erstellt werden kann. Ein Kostenrechnungskreis entspricht entweder einem Buchungskreis oder umfasst bei buchungskreisübergreifender Abrechnung
mehrere Buchungskreise. Der zweite Fall ist anzutreffen, wenn für verschiedene selbständig bilanzierende Gesellschaften eine Kostenrechnung geführt wird.
Rechtliche Organisationsstruktur
Mandant (Konzern)
0001
Kontenplan
CACH
Kostenrechnungskreis
Buchungskreis
CADE
CH01
0001
CH02
0002
0003
DE01
0004
Abb. 3-6: Rechtliche Organisationsstruktur des Finanzwesens.
64
0005
Das R/3-System
Folgende Organisationseinheiten dienen zur Abbildung der internen Struktur:
• Geschäftsbereich
• Kreditkontrollbereich
• Mahnbereich.
Zu Auswertungszwecken kann eine Gesellschaft in Geschäftsbereiche untergliedert
werden. Für diese können eigene Bilanzen sowie Gewinn- und Verlustrechnungen erstellt werden. Aus handelsrechtlicher Sicht hat dies jedoch keine Bedeutung; somit hat
diese Organisationseinheit nur internen Charakter. In einem Mandanten können mehrere Geschäftsbereiche angelegt werden. Die Kontierung der einzelnen Geschäftsbereiche kann dabei in allen vorhandenen Buchungskreisen, d.h. buchungskreisübergreifend
erfolgen. Ein Geschäftsbereich lässt sich zusätzlich zu einem Konsolidierungsgeschäftsbereich zusammenfassen.
Innerhalb eines Kreditkontrollbereiches existieren einheitliche Kreditlimiten für Debitoren. Für die Kreditlimiten kann pro Kreditkontrollbereich eine Währung festgelegt
werden. Zu einem Kreditkontrollbereich können ein oder mehrere Buchungskreise zugeordnet werden. Umgekehrt kann ein Buchungskreis aber nicht mehrere Kreditkontrollbereiche umfassen.
Innerhalb eines Mahnbereichs wird das Mahnwesen einheitlich geregelt. Grundsätzlich
entspricht der Mahnbereich einem Buchungskreis. Kann das Mahnwesen auf Buchungskreisebene nicht einheitlich geregelt werden, erfolgt eine Untergliederung des Buchungskreises in Mahnbereiche. Diese können z.B. Sparten oder Verkaufsorganisationen entsprechen.
Weitere wesentliche Organisationseinheiten des Finanzwesens sind:
• Finanzkreis
• Ergebnisbereich.
Der Finanzkreis ist eine organisatorische Einheit des Finanzmanagements (Treasury).
Durch diesen wird der Geltungsbereich für die Planung der finanziellen Mittel
65
Das R/3-System
(Budgetierung) festgelegt. Einem Finanzkreis muss mindestens einem Buchungskreis
zugeordnet sein. Für die buchungskreisübergreifende Budgetierung können einem Finanzkreis mehrere Buchungskreise zugewiesen werden.
Der Ergebnisbereich entspricht einem Segment des Absatzmarktes innerhalb eines Kozerns, für welches durch Gegenüberstellung von Kosten und Erlösen ein Ergebnis ausgewiesen wird (Ergebnis- und Marktsegmentrechnung). Je nach Gliederung des Konzerns kann der Ergebnisbereich entweder einem oder mehreren Kostenrechnungskreisen entsprechen.
3.3.2.4 Organisationseinheiten des Personalwesens
Die verschiedenen Organisationseinheiten des Personalwesens unterteilen diesen Bereich nach personaladministrativen, zeitwirtschaftlichen und abrechnungstechnischen
Gesichtspunkten. Das R/3-System stellt für diesen Zweck folgende Organisationseinheiten zur Verfügung:
• Personalbereich
• Personalteilbereich.
Personalbereiche werden auf Buchungskreisebene eingerichtet und stellen Unternehmensbereiche mit gemeinsamen Merkmalen bezüglich der oben genannten Kriterien
dar. Innerhalb eines Personalbereichs sind z.B. die Tarif- und Lohnartenstruktur sowie
die Sollarbeitszeit einheitlich geregelt. Zudem stellt der Personalbereich ein Berechtigungsobjekt für den Zugriffsschutz dar.
Ein Personalbereich kann weiter in Personalteilbereiche untergliedert werden. Diese
zusätzliche Untergliederung kann insbesondere aus abrechnungstechnischen Gründen
erfolgen (z. B. können durch die geographische Gliederung eines Unternehmens mehrere Sozialversicherungseinrichtungen für einen Personalbereich zuständig sein). Ausserdem können für jeden Personalteilbereich u.a. verschiedene Lohnarten, Zeitmodelle
oder Feiertagskalender eingerichtet werden.
66
Das R/3-System
Organisationseinheiten des Personalwesens
Mandant (Konzern)
001
0001
Buchungskreis
Personalbereich
0001
Personalteilbereich
0002
0002
0001
0002
0003
0003
Abb. 3-7: Organisationseinheiten des Personalwesens.
Durch zusätzliche organisatorische Einheiten des Personalwesens können Merkmalsgruppen für die Erfassung von Vorschlagswerten, für spezielle Auswertungen und für die
Verfeinerung des Berechtigungskonzepts gebildet werden. Für diese Zusatzaufgaben
stellt das R/3-System folgende Organisationsstrukturen zur Verfügung:
• Mitarbeitergruppe
• Mitarbeiterkreis.
Durch die Mitarbeitergruppe erfolgt eine Grobeinteilung der Arbeitnehmer nach deren
Stellung innerhalb des Unternehmens (z.B. Unterteilung in Voll- und Teilzeitbeschäftigte). Diese Gliederung wird insbesondere für die Erzeugung von Vorschlagswerten bei
der Datenerfassung und für die Bildung von Selektionskriterien bei Auswertungen vorgenommen. Zusätzlich stellt auch die Mitarbeitergruppe ein Berechtigungsobjekt für die
Regelung des Zugriffsschutzes dar.
Mitarbeitergruppen können weiter in Mitarbeiterkreise unterteilt werden. Durch diese
Feingliederung lassen sich z.B. verschiedene Hierarchieebenen innerhalb eines Unternehmens abbilden. Für Mitarbeiterkreise sind u.a. folgende Unterscheidungsmerkmale
vorgesehen:119
119
Vgl. SAP AG (1996a), Abschnitt: Mitarbeiterkreis pflegen.
67
Das R/3-System
• Festlegung der Behandlung in der Abrechnung
• Festlegung der Gültigkeit von Primärlohnarten
• Festlegung der Gültigkeit von Arbeitszeitplänen
• Festlegung der Gültigkeit von Tarifgruppen
• Festlegung der Gültigkeit von Zeitkontingententypen.
Ähnlich wie für Mitarbeitergruppen können auch hier Vorschlagswerte zur einfacheren
Stammdatenerfassung definiert werden. Ferner stellen Mitarbeiterkreise zusätzliche Selektionskriterien für Auswertungen und eigene Berechtigungsobjekte für den Zugriffsschutz dar.
3.3.3 Rechungswesen
Das Rechnungswesen stellt ein klassisches Anwendungsgebiet für betriebswirtschaftliche
Anwendungssoftware dar. Neben der Rechnungslegung, dem eigentlichen Kern des
Rechnungswesens, spielt zunehmend auch die Planung, Abwicklung und Kontrolle des
Finanzmitteleinsatzes eine wichtige Rolle (vgl. Abb. 3-8).
Das in den meisten Industrieländern anerkannte Prinzip der doppelten Buchführung
sowie das Vorhandensein von teilweise ähnlichen Bilanzierungsvorschriften hat zu einer
starken Vereinheitlichung der Rechnungslegung geführt. Dieser Bereich wird im R/3System durch das Finanzwesen abgedeckt. Für die zielgerichtete Anlage der brach liegenden und für die Bereitstellung der notwendigen finanziellen Mittel steht das Finanzmanagementmodul (Treasury) zur Verfügung. Neben der herkömmlichen Buchführung
und dem Management der finanziellen Mittel spielt auch die Auswertung der gesammelten Daten durch das Controlling als Basis für die Unternehmensplanung und führung eine wichtige Rolle. Ferner muss die Planung, Realisierung und Abrechnung
von Investitionsprojekten (Sachanlagen) durch entsprechende Funktionen unterstützt
werden. Dieser Bereich wird im R/3-System durch das Investitionsmanagement abgedeckt.
68
Das R/3-System
Durch die zunehmende Tendenz der Unternehmenskonzentration, hat ein weiteres
Anwendungsgebiet des Rechnungswesens - die Konzernrechnungslegung (Unternehmenscontrolling) - an Bedeutung gewonnen.
EC
Konzernrechnungswesen
FI
CO
TR
Finanzwesen
Controlling
Treasury
IM
Investitionsmanagement
Abb. 3-8: Module des Rechnungswesens.
Die dargestellten Anwendungsgebiete decken praktisch alle betrieblichen Bedürfnisse
im Bereich des Rechnungswesen ab und gewährleisten durch einen hohen Integrationsgrad bessere Transparenz und schnellere Verfügbarkeit der notwendigen Informationen.
69
Das R/3-System
3.3.3.1 FI - Finanzwesen (Financial Accounting)
Das R/3-System arbeitet mit einer einheitlichen Datenbasis und ermöglicht dadurch die
integrierte Verarbeitung eines jeden Geschäftsvorgangs. Dabei werden bei der Verbuchung einzelner Geschäftsvorgänge sämtliche damit verbundenen Buchungen automatisch durchgeführt. Durch die Integration aller Teilbereiche des Finanzwesens (vgl. Abb.
3-9) können Geschäftsvorfälle schneller abgewickelt und präziser ausgewertet werden.
FI - Finanzwesen
FIGL
FIAP
Hauptbuchhaltung
FILC
FIAA
Konsolidierung
Kreditorenbuchhaltung
Anlagebuchhaltung
FIAR
Debitorenbuchhaltung
FISL
Special Ledger
Abb. 3-9: Komponenten des Finanzwesens.
Die Hauptbuchhaltung (FI-GL) beinhaltet die laufende Geschäftsbuchhaltung (Führung
der Haupt- und Nebenbücher) und ermöglicht die Erfassung der Buchungsvorgänge für
den Jahresabschluss. Die Kontengliederung kann sowohl auf Firmenebene als auch auf
Konzernebene frei gewählt werden. Die Geschäftsvorfälle werden als Einzelbelege erfasst und unmittelbar nach jeder Buchung synchron fortgeschrieben, damit die betroffenen Kontostände, Summen- und Saldenlisten sowie Bilanz- und GuV-Auswertungen
jederzeit auf dem aktuellen Stand sind und vom Anwender eingesehen werden können.
Gleichzeitig werden die Nebenbücher und die relevanten Kostenbereiche mitgebucht.
Die Kreditoren- (FI-AP) und die Debitorenbuchhaltung (FI-AR) ermöglichen die rationelle Überwachung der Lieferantenverbindlichkeiten und der Kundenguthaben. Dabei werden offene Posten verfolgt und fällige Kreditorenrechungen automatisch beglichen. Bei fälligen Kundenguthaben lassen sich die ausstehenden Zahlungen mit einem
70
Das R/3-System
flexiblen Mahnwesen eintreiben. Zahlungsein- und Ausgänge können sowohl manuell
als auch über Datenfernübertragung verarbeitet werden. Entsprechende Schnittstellen
zur Ergebnis- und Marktsegmentrechnung sowie zur Finanzmittelüberwachung (TR-FM)
erlauben die ständige Überwachung des Verkaufs und ermöglichen die aktive Bewirtschaftung der vorhandenen flüssigen Mittel.
Die Konsolidierung (FI-LC) fasst die Abschlüsse einzelner Unternehmen zu einem Konzernabschluss zusammen. Durch die Ausnutzung von Bewertungswahlrechten haben
Konzerne die Möglichkeit, das Gruppenergebnis aufgrund einer eigenen Bilanzpolitik zu
beeinflussen. Die Konsolidierung ist sowohl mit dem Finanzwesen als auch mit der Anlagenwirtschaft verknüpft.
Mit der Komponente Anlagenbuchhaltung (FI-AA) können die im Unternehmen vorhandenen Investitionsgüter über ihre ganze Lebensdauer verwaltet und kostenmässig
überwacht werden. Die vorhandenen Schnittstellen zum Finanzwesen und zum Logistiksystem erhöhen die Transparenz und verbessern die Nutzung der vorhandenen Anlagen. Dabei beginnt die Unterstützung bereits bei der Investitionsplanung und setzt sich
über den gesamten Lebenszyklus eines Investitionsgutes fort. Die Anlagenwirtschaft besteht aus folgenden Teilkomponenten:
• Klassische Anlagenbuchhaltung und -bewertung
• Leasingabwicklung.
Die klassische Anlagenbuchhaltung und -bewertung protokolliert alle Wertzu- und
-abgänge eines Investitionsgutes über dessen ganze Lebensdauer. Dabei werden sämtliche anfallenden Kosten (Zinsen, Abschreibungen, Versicherungen etc.) ermittelt und als
Grundlage für die Investitionsrechnung bereitgestellt. Eine weitere Aufgabe der Anlagenbuchhaltung stellt die Bereitstellung von Grundlageninformationen für die Planung
der Wertentwicklung im Anlagevermögen dar (vgl. IM-Investitionsmanagement). Die
Integration der Anlagenbuchhaltung zu den anderen R/3-Modulen ist relativ hoch. Einerseits werden Informationen wie z.B. der Preis einer Anlage über die Einkaufskomponente des R/3-Systems bezogen und andererseits werden R/3-Module mit entsprechenden Daten versorgt. Beispielsweise werden Informationen über Zinsen und Abschrei71
Das R/3-System
bungen direkt an das Finanzwesen und an das Controlling weitergegeben. Die technische Betreuung der Anlagen stellt einen erheblichen Kostenfaktor für ein Unternehmen
dar. Neben den eigentlichen Wartungskosten sind natürlich auch die Ausfallzeiten in die
Kostenbetrachtungen miteinzubeziehen. Zur besseren Überwachung dieser Kosten stellt
die technische Anlagenverwaltung verschiedene Werkzeuge zur Verfügung. Die technische Instandhaltung kann entweder über CO-OM-OPA (Controlling-Order Project Accounting) oder über PM (Plant Maintenance) abgewickelt werden.
Ein weiterer Schwerpunkt der Anlagenbuchhaltung stellt die Leasingabwicklung dar.
Dabei können Leasinganlagen erfasst und entweder als Anlagevermögen aktiviert
(Capital Lease) oder ohne Aktvierung (Operation Lease) als Mietaufwand in der Gewinn- und Verlustrechung verbucht werden. Die zu leistenden Leasinggebühren werden
automatisch verwaltet und zur Zahlung termingerecht an die Finanzbuchhaltung weitergeleitet. Ferner können bei einer Vertragsänderung oder bei Vertragsablauf die bestehenden Anlagenstammsätze entfernt und wenn notwendig neu angelegt werden.
Über die Komponente Special Ledger (FI-SL) werden die Standardauswertungsmöglichkeiten (Standard Ledger) im Rechnungswesen durch ein flexibel einsetzbares Informationssystem zusätzlich erweitert. Konkret stellt FI-SL Funktionen für die Plausibilitätsprüfung und die Substitution bei der Datenerfassung, für die Sammlung von Daten
aus verschiedenen Anwendungen sowie für das Erstellen von aussagekräftigen Berichten
(Report Painter und Report Writer) zur Verfügung. Die Plausibilitätsprüfung der erfassten
Daten erfolgt anhand der in einem Regel-Manager erfassten Validierungsregeln. Die
Verprobung der Daten wird während der Erfassung durchgeführt und bietet dadurch
Gewähr, dass das Auftreten von Fehlern bei der Verbuchung reduziert werden kann.
Analog dazu können einzelne oder mehrere Werte beim Erfüllen von vorher festgelegten Bedingungen im Regel-Manager auch durch andere ersetzt werden. Dadurch werden die Datenqualität erhöht und wichtige Voraussetzungen für die zielgerichtete Auswertung der Daten geschaffen.
72
Das R/3-System
3.3.3.2 TR - Treasury
An verschiedenen Beispielen aus der Praxis kann gezeigt werden, dass durch geschickten Einsatz der brach liegenden finanziellen Mittel in einigen Fällen sogar höhere Gewinne erwirtschaftet werden können als bei der Ausübung des Kerngeschäfts. Daneben
muss ein Unternehmen bei finanziellen Engpässen zur Bewahrung der Glaubwürdigkeit
am Markt in der Lage sein, rechtzeitig auf Fremdmittel zurückgreifen zu können. Diese
Aufgaben werden durch das Finanzmanagement wahrgenommen.
Treasury Management Instrumente
TRTM
Geldhandel
- Termingeld
- Kündigungsgeld
FI
Ein-/Auszahlungen
- Forderungen /
Verbindlichkeiten
- Zahlungsbedingungen
- Zahlwege
Derivative
Instrumente
Forex
- Kassageschäft
- Termingeschäft
- Swap
- Swap
- Option
- Future
- ...
TRCM
Cash
Management
- Bankkonten
- Kassenstand
- Ausgleich
- Kontrolle
Wertpapiere
- Aktie
- Anleihe
- Optionsschein
- ...
Darlehen
- Hypotheke
- Police
- Schuldschein
- ...
TRFM
Finanzmittelüberwachung
- Planung
- Prognose
- Controlling
Abb. 3-10: Teilkomponenten des Treasury-Moduls.
Für die aktive Bewirtschaftung der finanziellen Mittel stellt die Treasury-Komponente
(TR) verschiedene Funktionen zur Verfügung. Obwohl Treasury grundsätzlich in das
Finanzwesen eingegliedert ist, wird es entsprechend dem Funktionsumfang als eigenes
73
Das R/3-System
Modul (TR) im R/3-System geführt. Für die Erfüllung der angesprochenen Aufgaben
stellt Treasury folgende Teilkomponenten zur Verfügung:
• Cash-Management
• Finanzmittelrechnung und -planung
• Finanzbudgetmanagement
• Market Risk Management.
Das Cash Management (TR-CM) bildet durch die ständige Auswertung der Debitorenund Kreditorenzahlungsströme die Grundlage für eine kurz- und mittelfristige Finanzdisposition. Voraussetzung für die aktuelle Ermittlung dieser Informationen ist die weitgehend automatisierte Abwicklung des Zahlungsverkehrs. Dabei können Bankkontenbewegungen (inkl. Valutenabgleich) für die Erhebung des Tagesfinanzstatus direkt in das
System eingespiesen und Zahlungen auf elektronischem Weg abgewickelt werden
(Electronic Banking). Daneben werden der Scheckverkehr und die Wechselverwaltung
(Schuld- und Besitzwechsel) weitgehend automatisiert durchgeführt. Zusätzlich ist es
möglich, die für das Tagesgeschäft relevanten Fremdwährungskurse maschinell zu pflegen und entstandene Kursdifferenzen automatisch auszubuchen. Durch ein integriertes
Kontenclearing (Konzentration der Salden verschiedener Konten auf ein Zielkonto) können kurzfristig Tagesgeldanlagen oder mehrtägige Festgeldanlagen resp. Geldaufnahmen getätigt werden. Etwas längerfristige Aussagen über die Liquiditätsentwicklung
werden anhand der Liquiditätsvorschau (Liquidity Forecast) getroffen. Diese wird auf
der Grundlage der zu erwartenden Zahlungsein- und -ausgänge ermittelt, welche ihrerseits wiederum durch die zur Verfügung stehenden Dispositionsquellen (offene Posten,
geplante Lohn- und Gehaltszahlungen, MWST-Verbindlichkeiten etc.) geschätzt werden. Die dargestellten Instrumente bilden die Basis zur Sicherung der Liquiditätsreserven und zur Verbesserung der Kapitalerträge.
Während die Finanzdisposition kurzfristig ausgerichtet ist, stellt die Finanzmittelrechnung und -planung (TR-FM) eine eher mittel- und langfristige Betrachtung der liquiden
Mittel dar. Die Hauptaufgabe stellt dabei das rechtzeitige Aufdecken von drohender
Illiquidität oder absehbaren Finanzmittelüberschüssen dar. Basis für diese Prognosen
74
Das R/3-System
sind alle realisierten und unmittelbar absehbaren Zahlungsein- und Zahlungsausgänge
(z.B. Rechnungsausgänge oder -eingänge), welche einander gegenübergestellt werden,
und die Liquiditätsentwicklung, die aufgrund der vereinbarten Zahlungsziele abgeschätzt wird. Darauf aufbauend kann für eine beliebige Anzahl Perioden eine Planung
der Zahlungsströme (Finanzmittelplanung) erstellt werden.
Das Finanzbudgetmanagement knüpft direkt an die Ergebnisse der Finanzmittelplanung an und bezweckt die buchungskreisübergreifende Budgetierung und Kontrolle
(Finanzkreis) der finanziellen Mittel. Die Zuweisung der Budgetwerte erfolgt an die im
Unternehmen festgelegten Verantwortungsbereiche (Finanzstellen) auf der Basis der in
der Finanzmittelplanung veranschlagten Werte. Die Budgetplanung gilt jeweils für ein
Geschäftsjahr und wird durch Soll-/Ist-Vergleich der Zahlungsströme ständig überwacht.
Im Unterschied zur Finanzplanung ist die Budgetierung absolut verbindlich und Anpassungen werden nur bei Veränderung der wirtschaftlichen Rahmenbedingungen vorgenommen. Das R/3-System bietet für diesen Fall die Möglichkeit, durch Umbuchung der
budgetierten Werte Korrekturmassnahmen vorzunehmen.
Während das Cash Management (TR-CM) und das Funds Management (TR-FM) die
Grundlageninformationen für Kapitalaufnahmen und -anlagen liefern, unterstützt die
Treasury Management-Komponente (TR-TM) die Verwaltung der angelegten oder von
dritter Seite zur Verfügung gestellten Gelder. Das R/3-System stellt zur Bewältigung dieser Aufgaben folgende Funktionsbereiche bereit:
• Geldhandel
• Devisenhandel
• Wertpapiermanagement
• Darlehensmanagement
• Derivative Finanzinstrumente.
Der kurzfristige Anlagebereich wird durch Funktionen zur Aufnahme resp. zur Anlage
von Termingeldern (Geld- und Devisenhandel) unterstützt. Durch die effiziente Ab-
75
Das R/3-System
wicklung dieser Transaktionen ist ein schnelles Reagieren auf Veränderungen an den
Finanzmärkten sichergestellt.
Im langfristigen Anlagebereich deckt TR-TM sowohl den Handel und die Verwaltung
von börsennotierten Wertpapieren als auch die Aufnahme und Vergabe von Darlehen
ab. Bei den börsengehandelten Wertpapieren gewährt das R/3-System Hilfe beim Kauf
und Verkauf, bei der Haltung von Depots und bei der Verwaltung von Portfolios. Auf
der Seite der Darlehensverwaltung können neben der Erfassung von Darlehensverträgen
auch die dazugehörigen Sicherheiten (Grundpfandrechte und Bürgschaften) mit dem
R/3-System verwaltet werden.
Für die verschiedenen derivativen Finanzinstrumente (Hedginggeschäfte wie z.B.
Swaps, Caps, Floors, Optionen oder Futures) stellt das R/3-System ebenfalls entsprechende Funktionen zur Verfügung. Im Vordergrund steht dabei die Bewertung der einzelnen Finanzanlagen. Daneben können durch verschiedene Analyseinstrumente z.B.
Fälligkeitsanalysen, "What-If"-Analysen oder sogar komplexe Simulationen durchgeführt
werden. Durch die Integration der Branchenlösung für Versicherungen (IS-IS) kann diese Funktionsvielfalt noch erweitert werden. Zusätzlich ermöglicht die direkte Anbindung
an das Rechnungswesen die Synchronisation der entstehenden Finanzströme mit der
Buchhaltung und der Liquiditätsplanung.
Das Market Risk Management (TR-MRM), welches zur Risikominimierung der verschiedenen Kapitalanlagen dient, rundet die verschiedenen Möglichkeiten des TreasuryFunktionsbausteins ab. Aktuelle Marktdaten lassen sich automatisch in das System einlesen und können neben der Bewertung der herkömmlichen Kapitalanlagen vor allem für
die Wertbestimmung der eher komplexen derivativen Finanzinstrumente herangezogen
werden. Finanzaktiva werden dabei zum Veräusserungspreis und Finanzpassiva zum
Rückkaufswert verrechnet. Durch verschiedene Risikoanalysen ("What-If"- und "Worst
Case"-Analysen) wird die Basis für Dispositionsentscheidungen an den Kapitalmärkten
geschaffen. Ausserdem können durch Standardreports die relevanten Kennzahlen (z.B.
Barwert, Internal Rate of Return, Liquiditätsentwicklung, Durchschnittskurse oder Sensitivitätsanalysen) ermittelt werden. Durch den Einbezug fiktiver Geschäfte kann das Ri-
76
Das R/3-System
sikopotential und die Festlegung der richtigen Strategie bei Marktveränderungen zusätzlich verringert werden.
Die verschiedenen Werkzeuge des Treasury-Moduls sorgen für eine effiziente Abwicklung der Finanztransaktionen und erhöhen durch gezielte Auswertung aller verfügbaren
Daten die Markttransparenz. Dadurch können sowohl die Rentabilität des eingesetzten
Kapitals verbessert, als auch die Kosten für Kapitalaufnahmen möglichst niedrig gehalten
werden. Da das Treasury ein relativ neuer Funktionsbaustein im R/3-Sytem darstellt, ist
zu erwarten, dass die Funktionalität in Zukunft in diesem Bereich noch erheblich erweitert wird.
3.3.3.3 CO - Controlling
Die Bedeutung des Controllings hat in letzter Zeit erheblich zugenommen. Durch die
zunehmende Dynamisierung der Märkte, immer kürzer werdende Produktlebenszyklen
und den allgemein steigenden Wettbewerbsdruck werden die Unternehmen gezwungen ihre Kosten, Erlöse und die Verwendung ihrer Ressourcen permanent zu planen, zu
überwachen und zu steuern. Damit diese Forderung erfüllt werden kann, ist jeder einzelne Geschäftsvorfall vollständig in die verschiedenen Controllingbereiche einzubetten.
Nur unter Berücksichtigung dieser Integrationsbedingungen lassen sich auch wirklich
aussagekräftige Plan/Ist-Analysen erheben und daraus die richtigen Massnahmen ableiten. Die dafür verwendbaren Kostenrechnungssysteme sind im R/3-System in die in
Abb. 3-11 dargestellten Bereiche untergliedert:
77
Das R/3-System
CO - Controlling
COOM
Gemeinkostencontrolling
COPC
COABC
Produktkostencontrolling
COPA
Ergebnis- und Marktsegmentrechnung
Prozesskostenrechnung
Abb. 3-11: Komponenten des Controllings.
Das Gemeinkostencontrolling (CO-OM) umfasst die Teilkomponenten Kostenarten-,
Kostenstellen- und Leistungsrechnung sowie Gemeinkostenaufträge und -projekte.
Die Kostenartenrechnung erfasst die für das Controlling relevanten Grundlagen. Dabei
wird zwischen primären und sekundären Kostenarten unterschieden. Die primären Kostenarten bilden auf Kostenrechnungsseite das Spiegelbild zu den betrieblichen Aufwandkonten. Die sekundären Kostenarten hingegen dienen ausschliesslich der Kostenrechnung und stellen die Basis für die Ermittlung des kalkulatorischen Werteflusses dar.
Dadurch stellt die Kostenartenrechnung quasi ein Grundgerüst für die anderen Kostenrechnungssysteme zur Verfügung.
Nachdem die Kostenartenrechnung die Frage beantwortet, welche Kosten angefallen
sind, gibt die Kostenstellenrechnung Auskunft, wo, d.h. von welchen betrieblichen
Leistungseinheiten die Kosten verursacht wurden. Kern der Betrachtung bilden dabei
die immer wichtiger werdenden Gemeinkosten. Da die entstandenen Ist-Kosten in der
Regel mit einem vorgängig erstellten Plan (Plankostenrechnung) korrespondieren müssen, werden die Abweichungen auf der Basis eines einfachen Plan-/Ist-Vergleich ermittelt und durch die Auswertung von verschiedenen, vom System gelieferten Berichten
analysiert.
78
Das R/3-System
Die herkömmliche Leistungsrechnung dient zur Planung, Bewertung und Verrechnung
von innerbetrieblichen Leistungen. Die Kostenstellen lassen sich dadurch leistungsbezogen planen und abrechnen. Durch die sofortige Umlage der Ist-Kosten können die Abweichungen zu den Plankosten umgehend offengelegt werden und verschiedene Berichtmöglichkeiten helfen, die Abweichungsursachen zu ermitteln. Die im R/3-System
vorgesehenen Leistungsarten bilden die Grundlage für die Leistungsverrechnung.
Durch die Festlegung der Planleistung, der Kapazität und der Ausbringungsmenge wird
eine Leistungsart definiert und dadurch die Ableitung der für die Leistungsverrechnung
relevanten Grössen ermöglicht.
Im Unterschied zum PS-Modul (Projekt System) des R/3-Systems, welches für das Planen und Überwachen von komplexen Projekthierarchien vorgesehen ist, dient die Teilkomponente Gemeinkostenaufträge und -projekte zur Planung und Kontrolle einstufiger Projekte. Zwischen Aufträgen und Projekten im letztgenannten Sinn wird im R/3System kein Unterschied gemacht. Da Aufträge und Projekte sehr unterschiedlichen
Aufgabenstellungen dienen können, bietet das R/3-System die Möglichkeit, diese verschiedenen Auftragsarten zuzuordnen. Die Auftrags- und Projektkostenrechnung verfolgt dabei unterschiedliche Ziele. Im Rahmen einer Kostenkontrolle sollen die angefallen Kosten ermittelt und in einem Plan-/Ist-Vergleich die Abweichungen dargestellt werden. Ferner stellt diese Teilkomponente verschiedene Kalkulationsvarianten und Kostenanalysefunktionen als Entscheidungshilfen zur Verfügung. Ausserdem können im
Rahmen einer Leistungsverrechnung die angefallenen Kosten auf verschiedene Zielobjekte (z.B. Kostenstelle, Anlage, Kundenauftrag, Projekt) umgelagert werden.
In der Komponente Produktkostencontrolling (CO-PC) werden die internen Kosten
über ein Umlageverfahren an die kostenverursachenden Leistungseinheiten des Betriebes (z.B. Produkte oder Aufträge) zugewiesen. In diesem Zusammenhang wird auch von
Kostenträgerrechnung gesprochen. Ein Kostenträger stellt demnach die zur Ermittlung
der Herstell- und Selbstkosten zu kalkulierende Einheit dar, d.h. die Kosten werden
stückbezogen ermittelt. Im R/3-System kann die Kostenträgerrechnung für folgende
Objekte (Kostenträger) durchgeführt werden:
79
Das R/3-System
• Materialien
• Fertigungsversionen eines Materials
• Fertigungsaufträge
• Netzpläne
• Instandhaltungsaufträge
• Serienaufträge
• Prozessaufträge
• Kundenaufträge
• Innenaufträge
• Kostenträger-Identnummern
• Kostenträgerhierarchien
• Projekte
• Projektstrukturplanelemente.
Pro Kostenträger können Plankosten aufgestellt (Vorkalkulation) und Ist-Kosten
(Nachkalkulation) ermittelt werden. In einer Plan-/Ist-Analyse werden die gesammelten
Daten einander gegenübergestellt und durch integrierte Berichts- und Analysesysteme
verdichtet und ausgewertet. Das Ergebnis sind Informationen, die zur Optimierung der
Prozesse sowohl unter wirtschaftlichen als auch unter qualitativen Aspekten verwendet
werden können.
Die Ergebnis- und Marktsegmentrechnung (CO-PA) liefert Informationen (z.B. Nettoergebnisse und Deckungsbeiträge) von verschiedenen Produkten oder ganzen Märkten.
CO-PA basiert auf sogenannten Ergebnisobjekten, welche eine Kombination von ganz
bestimmten Auswertungsmerkmalen darstellen. Solche Auswertungsmerkmale können:
• artikelbezogen (Artikel, Artikelgruppe, Sortiment, Erzeugnisform)
• kundenbezogen (Kunde, Kundengruppe, Branche)
• vorgangsbezogen (Auftragsart, Auftragsgrösse) oder
• organisationsbezogen (Vertretergebiet, Vertriebsweg, Profit Center)
sein. Für einzelne oder für Gruppen von Ergebnisobjekten lassen sich Kennzahlen definieren. Durch diese werden sowohl Erlös- als auch Kostenkomponenten für die Bestimmung des Ergebnisses ermittelt. Die Fixkosten werden periodisch von der Kosten-
80
Das R/3-System
stellenrechnung bereitgestellt und können direkt in die Ergebnisrechnung miteinbezogen
werden. Vor der Ist-Kostenerfassung kann periodisch eine Absatz- und Ergebnisplanung
aufgestellt werden. Der Plan-/Ist-Vergleich dient zur Überwachung der vorher definierten Ergebnisobjekte. Durch Standardanalysen und flexible Auswertungsmöglichkeiten
der Ergebnisrechnung (Berichte) lassen sich sehr detaillierte Informationen zu Produkten
und Märkten gewinnen. Nutzniesser dieser Erkenntnisse sind vor allem der Vertrieb, das
Marketing und das Produktmanagement. Selbst strategische Unternehmenseinheiten
sind für die Planung auf das Vorhandensein dieser Informationen angewiesen.
Die Prozesskostenrechnung120 (CO-ABC) stellt eine Erweiterung zur herkömmlichen
Leistungsverrechnung dar und ist auf die kostenmässige Erfassung der Leistungen in bereichsübergreifenden Unternehmensprozessen ausgerichtet (vgl. Abb. 3-12). Die Kostenzuordnung erfolgt über sogenannte Aktivitäten, welche einen Preis haben und von
den Geschäftsprozessen verbraucht werden. Unter der Voraussetzung, dass die Gemeinkosten mit der Anzahl der verbrauchten Aktivitäten variieren, lassen sich die Kosten
über Kostentreiber auf die Kostenobjekte verteilen. Gemeinsam mit den direkten Kosten
ergeben die Kosten der verbrauchten Aktivitäten die Prozesskosten. Durch diese Art der
Umlegung der Gemeinkosten soll eine verursachergerechtere Verteilung der Kosten ermöglicht werden.
Kostenbasis
Was wird verbraucht?
Kostenzuordnung
Aktivitäten
Kostentreiber
Kostenobjekte
Maschinenumstellung
Maschinenumstellung
Anzahl
AnzahlUmstellungen
Umstellungen
Bestellung
Bestellung
Qualitätsbericht
Qualitätsbericht
Anzahl Bestellungen
Anzahl Bestellungen
Produkt
Produkt
Reporting
Reporting
Anzahl
AnzahlLose
Lose
Prozess
Prozess
Materialtransport
Materialtransport
Materialvolumen
Materialvolumen
Teil
Teil
Inspektion
Inspektion
Produktionsausstoss
Produktionsausstoss
Auftrag
Auftrag
Weshalb wird es
verbraucht?
Wer verbraucht es?
Abb. 3-12: Prinzip der Prozesskostenrechnung.
120
Vgl. Busin (1996).
81
Das R/3-System
3.3.3.4 IM - Investitionsmanagement
Durch den zunehmenden Technisierungsgrad der für den Leistungserstellungsprozess
benötigten Anlagen und die damit verbundene hohe Kapitalbindung hat auch die Bedeutung des Investitionsmanagements (IM) zugenommen. Der ganze Prozess einer
Investition für eine Sachanlage wird im R/3-System von der Planung, über die Beschaffung und Nutzung bis zum Ende der Lebensdauer einer Anlage durch folgende Teilkomponenten unterstützt:
• Investitionsanforderungen
• Investitionsprogramme
• Investitionsmassnahmen.
Anträge für Investitionen können als Investitionsanforderungen im System erfasst und
für die Berücksichtigung der Planung vorgemerkt werden. Durch verschiedene Formen
der Rentabilitätsrechnung werden die Grundlagen für Investitionsentscheide geschaffen.
Ferner kann anhand einer Statusverwaltung jederzeit der aktuelle Stand eines Investitionsantrages ermittelt werden. Diese Funktionen bilden die Grundlage für die Investitionsplanung.
Durch die systemgestützte Erstellung von Investitionsprogrammen können konzernweit
Budgets vergeben und Kosten geplant werden. Durch die Verknüpfung von Investitionsmassnahmen und -programmen sowie die Möglichkeit der Aggregation einzelner
Investitionsvorhaben können jederzeit die budgetierten Werte mit den bereits entstandenen Ist-Kosten verglichen werden.
Investitionsmassnahmen werden im Rahmen von Innenaufträgen oder Projekten umgesetzt. Die in diesen Komponenten verfügbaren Instrumente (Ressourcen- und Kostenplanung sowie Kostenüberwachung) bilden ideale Werkzeuge für die Unterstützung bei
der Realisierung von Investitionsprojekten. Ausserdem ist durch die Integration mit dem
Unternehmenscontrolling eine transparente und verursachergerechte Abrechnung der
getroffenen Investitionsmassnahmen möglich. Die Wertbestimmung einer Anlage erfolgt
durch Zuweisung der für jede einzelne Anlage benötigten Fremd- und Eigenleistungen.
82
Das R/3-System
Dadurch steht nach der Endabrechnung ein vollständiger Herkunftsnachweis zur Verfügung. Bei der Wertbestimmung wird zusätzlich zwischen aktivierungspflichtigen und
nicht aktivierungspflichtigen Anlagen resp. Anlageteilen unterschieden. Die aktivierungspflichtigen Anlagen können zur wertmässigen Fortschreibung in der Anlagenbuchhaltung (FI-AA) verwaltet werden, und die nicht aktivierungspflichtigen Anlageteile fliessen der Kostenrechnung zu. Die Wertentwicklung einer Anlage kann durch Simulation
von Abschreibungen (Abschreibungsvorschau) vorgängig ermittelt und durch Aggregation der Einzelwerte zur Schätzung des gesamten Anlagevermögens herangezogen werden. Damit bildet das Investitionsmanagement zusammen mit der Anlagenbuchhaltung
und der Instandhaltung ein abgerundetes Instrumentarium für die finanzielle und technische Verwaltung der in einem Unternehmen vorhandenen Anlagen während deren
ganzen Lebensdauer.
3.3.3.5 EC - Unternehmenscontrolling
Die verschiedenen Instrumente des Unternehmenscontrollings (EC) erlauben eine
zeitnahe Überwachung aller Unternehmensaktivitäten anhand kritischer Erfolgsfaktoren
(CSF) und bilden dadurch die Grundlage für die strategische Planung auf Konzernebene. Das EC-Modul gliedert sich in die in Abb. 3-13 dargestellten Bereiche.
EC - Unternehmenscontrolling
ECEIS
Führungsinformationssysteme (EIS)
ECMC
ManagementKonsolidierung
ECPCA
Profit Center
Rechnung
Abb. 3-13: Komponenten des Unternehmenscontrollings.
Durch das in R/3 vorhandene Führungsinformationssystem (EC-EIS) können entscheidrelevante Informationen über alle Aktivitäten eines Unternehmens ermittelt werden. Dabei ermöglicht das System die Zusammenführung von Daten aus externen und
internen Quellen in einer speziell dafür vorgesehenen EIS-Datenbank. Dieser Daten-
83
Das R/3-System
pool ist frei definierbar und bietet dadurch die Möglichkeit, Informationen bedürfnisgerecht zu sammeln. Die meist sehr heterogene Struktur der gesammelten Daten erfordert eine Gruppierung von gleichartigen Daten. Zur Abdeckung dieses Bedürfnisses
können Teilbereiche der EIS-Datenbank in sogenannte "Aspekte" zusammengefasst werden. Diese bilden die Grundlage für die Datenanalyse. Dabei können die entscheidrelevanten Informationen entweder über eigene Auswertungen (flexible Analysen) oder
über sogenannte Standardreports ermittelt werden. Durch das EIS wird dem Management ein unverzichtbares Mittel für die operative und strategische Führung eines Unternehmens zur Verfügung gestellt.
Die Management-Konsolidierung121 (EC-MC) dient zur Erstellung einer Bilanz, Gewinn- und Verlustrechnung sowie einer Kapitalflussrechnung auf Konzernebene. Dabei
können für die Verdichtung der Werte beliebige Konsolidierungseinheiten (z.B. Gesellschaft, Geschäftsbereich oder Region) definiert werden. Für die Währungsumrechnung,
Aufwands- und Ertragskonsolidierung, Schuldenkonsolidierung, Eliminierung von Zwischengewinnen und für die Kapitalkonsolidierung lassen sich die Konsolidierungsverfahren und die einzelnen Konsolidierungsschritte frei auswählen. Die dafür notwendigen Daten werden in den operativen Anwendungen zur Konsolidierung vorbereitet und
an EC-MC weitergeleitet. Ferner können auch Daten aus Fremdsystemen in die Betrachtungen miteinbezogen werden. Durch Monitoring und umfangreiche Analysefunktionen werden die einzelnen Erfolgsfaktoren ständig überwacht und gezielt ausgewertet.
Die Behandlung von auftretenden Meldedifferenzen wird durch EC-MC ebenfalls unterstützt.
121
84
Vgl. Sinzig (1996).
Das R/3-System
Die Profit-Center-Rechnung (EC-PCA) stellt dabei eine Sonderform der Ergebnisrechnung dar. Wesentliche Zielsetzung ist die kostenund ergebnisbezogene Abbildung eines selbständig am Markt operierenden Unternehmensbereichs. Zur Ergebnisermittlung
kann entweder das Gesamtkostenverfahren oder das Umsatzkostenverfahren verwendet
werden. Dabei werden die Gesamtkosten einer Periode den Leistungen einer Unternehmenseinheit (Profit Center) gegenübergestellt. Dadurch kann der Erfolg einer quasi
eigenständigen Unternehmenseinheit ermittelt werden.
Für die Budgetierung und Zuteilung der Ressourcen auf Konzernebene steht im ECModul die Komponente Business Planning (EC-BP) zur Verfügung. Dabei können sowohl Planvorschläge aus den operativen Anwendungen übernommen (Bottom up) als
auch die auf Konzernebene ermittelten Vorgabewerte an diese übergeben werden (Top
down). Im Bereich der Investitionsplanung besteht zudem die Möglichkeit, Investitionsbedarfe aus den operativen Bereichen zu übernehmen, zu überprüfen, freizugegeben
und anschliessend zu überwachen. Ferner kann zur Unterstützung der Planung ein modellbasiertes Planungsinstrument verwendet werden.
Durch die dargestellten Komponenten stehen flexible Instrumente für die rasche Ermittlung der steuerungsrelevanten Daten und zur Vereinheitlichung des gesamten Controllings im Konzern zur Verfügung. Damit sind neben den operativen Bereichen auch
die strategischen Bedürfnisse des Rechnungswesens mehrheitlich abgedeckt.
85
Das R/3-System
3.3.4 Logistik
Die Logistik stellt einen weiteren Hauptanwendungsbereich innerhalb des R/3-Systems
dar. Durch die Integration der einzelnen Module (vgl. Abb. 3-14) ist die Durchgängigkeit des gesamten Prozesses von der Beschaffung, über die Fertigung, die Lagerhaltung
und den Vertrieb gewährleistet. Somit gehören im wesentlichen die Fertigungsbetriebe
zu den primären Anwendern dieses Bereichs. Ohne das Modul Produktionsplanung
und -steuerung ist aber auch ein Einsatz von R/3 in Handels- und Dienstleistungsunternehmen möglich.
Grunddaten
SD
Absatzplanung
Kundenauftrags-verwaltung
Ergebnisplanung
Kundenbedarf
Planbedarf
Prognose
- Kunden
- Lieferanten
Projektsystem
- Netzplan
- Projekte
- Material
- Stückliste
- Arbeitsplan
- Fertigungshilfsmittel
PP
QM
- Planungsprofil
SOP
- Equipment
Programmplanung
- Dokument
- Prüflos
- Prüfauftrag
- Klassifizierung
Bedarfsplanung
Grobkapazitätsplanung
MM
Direktanforderung
Einkauf
PlanAufträge
Rechnungsprüfung
Eröffnungshorizont
- Textverarbeitung
Auftrag:
- Eröffnung
- Freigabe
- Rückmeldung
- Mail
- Kommunikation
- EDI
Fertigungssteuerung
Kapazitätsabgleich
CAM
Bestandesführung
Wareneingang
Bewertung
PM
- Instandsetzung
- Wartung
SD
- Erzeugniskalkulation
- Versand
Fakturierung
Transport
Abb. 3-14: Module des Hauptanwendungsbereichs Logistik.
86
Lagerverwaltung
Das R/3-System
Im Bereich der Beschaffungslogistik steht das Modul Materialwirtschaft (MM) im Zentrum. MM stellt alle nötigen Funktionen zur Einkaufsabwicklung (Bestellanforderungsverwaltung, Angebotsanfragen, Offertvergleich, Bestellung, Bestellverfolgung, Wareneingang, Lagerverwaltung, Rechnungsprüfung etc.) zur Verfügung. Die Datenbasis
(Materialstamm) und weitere Grundfunktionen werden durch das Modul Logistik allgemein (LO) bereitgestellt.
Im Zentrum der Produktionslogistik steht das Modul Produktionsplanung (PP). PP
deckt sowohl den gesamten Planungsprozess (SOP-Sales and Operation Planning/Programmplanung, Bedarfsplanung und Kapazitätsplanung) als auch die eigentliche Abwicklung der Produktion (Fertigungssteuerung, Kapazitätsabgleich) ab.
Im Hinblick auf die Vertriebslogistik stellt das Modul Sales and Distribution (SD) einerseits Funktionen im Bereich des Marketings sowie des Verkaufs (Offert- und Kundenauftragsabwicklung) zur Verfügung. Der sich aus diesem Prozess ergebende Kundenbedarf wird in Abhängigkeit vom verwendeten Fertigungstypen als Inputgrösse für
die Produktionsplanung verwendet. Andererseits deckt SD alle zur Vertriebsabwicklung
notwendigen Funktionen (Versand, Transport, Fakturierung) ab.
Zur Sicherung der Qualität im Rahmen der gesamten Logistikkette stellt das Qualitätsmanagement (QM) Funktionen zur Qualitätsicherung zur Verfügung. Dabei werden
Qualitätssicherungsmassnahmen sowohl im Bereich Produktionslogistik als auch in den
Bereichen der Beschaffungs- und Vertriebslogistik zur Verfügung gestellt.
Zur Instandhaltung der eigenen Anlagen und für die Abwicklung von Wartungs- und
Servicedienstleistungen veräusserter Anlagen stellt das Modul Instandhaltung (PM) entsprechende Funktionen zur Verfügung. Zur Wartung der eigenen Anlagen werden Möglichkeiten zur Anlagenstrukturierung, zur Definition von Arbeits- und Wartungsplänen
und zur Durchführung von Instandhaltungsaufträgen geboten. Für die Erbringung von
Wartungs- und Serviceleistungen im Bereich der veräusserten Anlagen dient das Service-Management. Diese Anwendung unterstützt die Bearbeitung von Servicemeldungen, die Abwicklung von Serviceaufträgen und deren Abrechnung resp. Fakturierung.
87
Das R/3-System
Das Projektsystem (PS) ist ein weiterer Bestandteil des Logistiksystems und bezweckt
die branchenneutrale Unterstützung der Projektdurchführung. PS besitzt eine starke
Integration zu den Anwendungsbereichen Finanz- und des Personalwesen. PS unterstützt verschiedene Projektarten (z.B. Forschungs und Einzelprojekte, Kundeneinzelfertigung, Investitionsvorhaben, EDV-Projekte) und stellt dafür Funktionen sowohl für die
Projektstrukturierung als auch für die Projektplanung, -durchführung, -überwachung
und -abrechnung zur Verfügung.
3.3.4.1 LO - Logistik allgemein
Das Modul Logistik allgemein stellt als Basis für den gesamten Logistikbereich die in
Abb. 3-15 dargestellten Komponenten zur Verfügung. Im Zentrum steht insbesondere
die Erfassung der Materialstammdaten und die Auswertung sämtlicher für den Logistikbereich relevanten Daten. Daneben beinhaltet LO weitere, durch verschiedene Module
genutzte Komponenten wie die Chargenverwaltung, den Änderungsdienst, die Variantenkonfiguration und die Montageabwicklung.
LO - Logistik Allgemein
LOMD
LOVC
Grunddaten der
Logistik
Variantenkonfiguration
LOBM
LOLIS
Chargenverwaltung
Logistikinformationssystem
LOECH
Änderungsdienst
LOAP
Montageabwicklung
Abb. 3-15: Komponenten des Anwendungsbereichs "Logistik allgemein".
Im Zentrum der Grunddatenerfassung (LO-MED) des Logistikbereichs steht der Materialstamm. Über ein ausgeklügeltes Sichtenkonzept lassen sich für die einzelnen Unternehmensbereiche (z.B. Einkauf, Konstruktion oder Buchhaltung) die relevanten Materialstammdaten erfassen. Dabei ist die Nutzung der Materialstammdaten nicht auf die
88
Das R/3-System
Materialwirtschaft beschränkt, sondern umfasst den ganzen Logistikbereich. Der Aufbau
des Materialstamms ist hierarchisch und entspricht den verschiedenen Organisationsebenen des R/3-Systems. Dadurch ist klar definiert, welche Datenelemente des Materialstamms für welche Unternehmensbereiche (Organisationseinheiten) gültig sind. Gewisse grundlegende Angaben (z.B. Materialkurztexte, Gewicht und Volumen) sind auf
Mandantenebene festgelegt und gelten dadurch konzernweit. Andere wiederum gelten
nur auf Werks-, auf Lagerort- oder auf Vertriebsebene. Darüber hinaus lässt sich der
Materialstamm nach Branchen (z.B. Maschinenbau, Anlagenbau oder Chemie) und
nach Materialarten (z.B. Rohmaterial, Fertigerzeugnisse oder Handelswaren) untergliedern. Durch diese Gliederungsmöglichkeiten lassen sich branchen- und materialartabhängige Datenfelder in den Masken ein- resp. ausblenden.
Damit die steigenden Anforderungen in den Bereichen des Verbraucher- und Umweltschutzes (Produktehaftpflicht) erfüllt werden können, müssen die in einem Herstellungsgang gefertigten Erzeugnisse eindeutig einer Charge zugeordnet und entsprechend
dokumentiert werden können. Die integrierte Chargenverwaltung (LO-BM) des R/3Systems kann im ganzen Logistikbereich eingesetzt werden und erlaubt die Nachverfolgung einer Charge von der Beschaffung der Rohstoffe bis zur Auslieferung des Enderzeugnisses. Dadurch herrscht absolute Transparenz über den Fertigungsprozess und
Detailinformationen über einzelne Fertigungsschritte einer Charge können auch nachträglich jederzeit zur Abklärung rekonstruiert werden.
Durch den Änderungsdienst (LO-ECH) wird die Mutation von Stammdaten (z.B. Materialstamm oder Stücklisten) lückenlos protokolliert. Dabei wird zwischen Änderungen
mit und ohne Historie unterschieden. Ein Änderung ohne Historie ist vor allem für Produkte in der Entwicklungsphase sinnvoll. Der Zustand vor der Änderung wird nicht festgehalten. Bei Änderungen mit Historie gilt ein Zustand für einen ganz bestimmten Gültigkeitszeitraum. Dadurch existiert beispielsweise für Produktehaftpflichtfälle eine vollständige Dokumentation aller erfolgten Änderungen.
Die Forderung der Konsumenten nach mehr Individualität hat bei gewissen Produkten
(z.B. Fahrzeugen) zu einer enormen Variantenvielfalt geführt. Oftmals sind aber aus
89
Das R/3-System
technischen oder sonstigen Rahmenbedingungen nicht alle denkbaren Varianten möglich bzw. sinnvoll (z.B. die Kombination Cabriolet und Klimaanlage). Die Möglichkeit
der Abdeckung dieses Bedürfnisses durch die Variantenkonfiguration (LO-VC) stellt
einen idealen Kompromiss zwischen der teuren Einzel- und der oftmals nicht bedürfnisgerechten Serienfertigung dar. Das zur Konfiguration eines Produkts notwendige Beziehungswissen muss daher in einer Regeldatenbank abgelegt werden können. In Maximalstücklisten und -arbeitsplänen sind alle möglichen Komponenten und Arbeitsgänge
festgehalten. Über frei definierbare Merkmale werden den einzelnen Produkten verschiedene Eigenschaften zugewiesen. Durch das vorhandene Beziehungswissen kann
die Zulässigkeit einer Variante überprüft und anschliessend eine entsprechende Stückliste erzeugt werden. Parallel zum Konfigurationsprozess erfolgt die Preisbestimmung für
die gewählte Variante. Diese wird auf der Basis der festgelegten Variantenkonditionen
durchgeführt. Neben Materialien kann die Variantenkonfiguration auch für Standardnetze innerhalb des Projektsystems (PS) eingesetzt werden. Standardnetze sind projektneutrale Abläufe, die mehrfach verwendet werden können. Durch die Kombination
von verschiedenen Standardnetzen entstehen individuelle Netzpläne, deren Aufbau in
gleicher Weise über Merkmale und ein entsprechendes Beziehungswissen gesteuert
werden kann.
Im Bereich der Kundeneinzelfertigung kommt es oft vor, dass bei einer Kundenbestellung verlässliche Terminzusagen gemacht werden müssen. Da das Enderzeugnis in den
meisten Fällen aber nicht am Lager liegt und zuerst gefertigt werden muss, kann nur die
Verfügbarkeit von Baugruppen resp. einzelnen Komponenten überprüft werden. Durch
die Montageabwicklung (LO-AP) im R/3-System können die angesprochenen Überprüfungen vorgenommen werden. Dabei orientiert sich die Verfügbarkeitsprüfung an
der Menge und am gewünschten Liefertermin. Bei der Prüfung der Auftragsmenge wird
jene Komponente mit der geringsten Verfügbarkeitsmenge ermittelt. Die Bestimmung
des Liefertermins orientiert sich an jener Komponente, welche voraussichtlich als letzte
für die Montage bereitstehen wird. Für die Überprüfung des Liefertermins kann beim
Erfassen des Kundenauftrags ebenfalls bereits die Kapazitätsplanung durchgeführt werden. Bei gleichzeitiger Verwendung der Variantenkonfiguration wird im System nach
90
Das R/3-System
der Festlegung einer Variante für die Terminermittlung ebenfalls ein Montageauftrag
erzeugt. Neben Montageaufträgen in Form von Fertigungs- oder Planaufträgen können
auch Netzpläne zeitlich terminiert werden.
Das Logistikinformationssystem (LO-LIS) dient zur Auswertung der im Logistikbereich
vorhandenen Daten und besteht aus den in Abb. 3-16 dargestellten Teilkomponenten.
Zur Auswertung der vorhandenen Daten werden in allen Informationssystemen dieselben zentralen Auswertungswerkzeuge verwendet. Darüber hinaus sind für jedes einzelne Informationssystem speziell zugeschnittene Auswertungstechniken verfügbar. Zusätzlich zur Auswertung der Ist-Daten können mit einem gut ausgebauten Prognoseinstrument122 auch Planwerte ermittelt werden. Ferner steht für die kundenindividuelle Gestaltung des LO-LIS das sogenannte Logistics Data Warehouse zur Verfügung. Mit diesem Instrument kann eine eigene Datenbasis mit individuellen Fortschreibungsregeln
aufgebaut und für Auswertungen bereitgestellt werden.
122
Die Prognoserechnung wurde mit Release 3.0 zu einem zentral verfügbaren Instrument zusammengefasst und entsprechend erweitert.
91
Das R/3-System
LOLIS
LIS - Logistikinformationssystem
Vertriebsinformationssystem
Einkaufsinformationssystem
Bestandscontrolling
Fertigungsinformationssystem
Qualitätsmanagementinformationssystem
Instandhaltungsinformationssystem
Planung / Prognose
Frühwarnsystem
Logistikinformationsbibliothek
Abb. 3-16: Komponenten des Logistikinformationssystems.
Ein integriertes Frühwarnsystem ermöglicht die Überwachung von ausgewählten Kennzahlen mit dem Zweck, Ausnahmesituationen und Fehlentwicklungen frühzeitig zu erkennen. Das Frühwarnsystem ist in allen Teilbereichen des Logistikinformationssystems
verfügbar.
Für die verschiedenen Bereiche des LIS ist im R/3-Standard eine grosse Zahl von Kennzahlen vorhanden. Diese sind in der Logistikinformationsbibliothek (LIB) in Klassen
zusammengefasst und dadurch übersichtlich strukturiert. Komfortable Suchroutinen gewährleisten das rasche Auffinden der gesuchten Kennzahl. Darüber hinaus besteht die
Möglichkeit, benutzerdefinierte Kennzahlen in die Logistikinformationsbibliothek einzubinden und allgemein zugänglich zu machen. Durch diese Funktionen wird die Transparenz über die im R/3-System vorhandenen Auswertungsmöglichkeiten erheblich verbessert und gleichzeitig ist genügend Spielraum für die Integration von eigenentwickelten Kennzahlen vorhanden.
92
Das R/3-System
3.3.4.2 SD - Vertriebsabwicklung (Sales & Distribution)
Das Vertriebssystem von R/3 unterstützt den Verkauf und den Versand von Produkten
und Dienstleistungen an verschiedene Geschäftspartner. Eine Vielzahl von organisatorischen Gestaltungsmöglichkeiten gewährleisten die optimale Abbildung der eigenen Verkaufs- und Versandorganisation. Die Integration des Vertriebsbereichs ist recht ausgeprägt und insbesondere zur Materialwirtschaft und zum Finanzwesen existieren wesentliche Verknüpfungen. Aus der Materialwirtschaft werden sämtliche Informationen über
Produkte und Dienstleistungen (Materialstamm) entnommen und über das Finanzwesen
erfolgt die Zahlungsüberwachung und -abwicklung. Auch zu andern Modulen des R/3Systems (CO, PP, PS und PM) erfolgt ein Datenaustausch. Das Vertriebssystem besteht
aus den Abb. 3-17 in dargestellten Teilbereichen.
SD - Vertriebsabwicklung
SDMD
SDBF
Grunddaten
SDSHP
SDSLS
SDBIL
Versand
Verkauf
Grundfunktionen
SDCAS
Fakturierung
Vertriebsunterstützung
Abb. 3-17: Komponenten der Vertriebsabwicklung.
Bei der Vertriebsabwicklung muss entweder auf bereits bestehende Grunddaten (SDMD) - z.B. Materialstamm - zurückgegriffen werden können oder während des Verkaufsprozesses ist die Erfassung von neuen Daten (z.B. Kunden, Konditionen, Absprachen) notwendig. Die gesammelten Grunddaten bilden somit die Basis für alle weiteren
Schritte.
Die Grundfunktionen (SD-BF) der Vertriebsabwicklung stellen dem Vertriebsmitarbeiter ein breites Instrumentarium für die Unterstützung des Verkaufsprozesses zur Verfü93
Das R/3-System
gung. In diesem Zusammenhang sind im wesentlichen folgende Funktionsbausteine
relevant:
• Materialfindung
• Preisfindung
• Verfügbarkeitsprüfung
• Kreditmanagement.
Durch die Materialfindung kann ein bei der Verkaufsabwicklung erfasstes Material automatisch durch ein anderes ersetzt werden. Dieser Fall ist z.B. bei Aktionen oder saisonal bedingten Verpackungsänderungen (z.B. Ostern oder Weihnachten) sinnvoll. Wird
ein Produkt bestellt, substituiert das System automatisch den gewählten Artikel durch
einen andern.
Die Preisfindung dient zur Berechnung der Nettopreise. Diese werden auf der Basis der
Bruttopreise und der zusätzlich vorhandenen Preiselemente (Zu- und Abschläge, Fracht,
Steuern) bestimmt. Die Bruttopreise und die einzelnen Preiselemente sind entweder fix
vorgegeben oder werden kundenindividuell anhand eines speziellen Konditionsschemas
bestimmt. Dabei können die Faktoren Kunde, Produkt und Bestellmenge für die Bestimmung des Endpreises relevant sein. Ferner besteht die Möglichkeit, die Preise von
einem Gültigkeitszeitraum abhängig zu machen (z.B. Gültigkeitszeitraum von Aktionen
oder Preislisten). Durch die dargestellten Möglichkeiten können praktisch alle Facetten
der Preisbestimmung abgedeckt werden.
Eine integrierte Verfügbarkeitsprüfung unterstützt den Verkaufsangestellten bei der
Zusicherung von Lieferterminen während des Verkaufsprozesses. Für die Ermittlung der
Materialverfügbarkeit stellt das System verschiedene Verfahren zur Verfügung. Bei der
Überprüfung eines gewünschten Liefertermins auf der Basis der ATP-Menge123 werden
der aktuelle Lagerbestand und die geplanten Zu- und Abgänge für die Berechnungen
herangezogen. Bei der Prüfung gegen die Vorplanung wird die Materialverfügbarkeit
123
94
ATP = Available To Promise.
Das R/3-System
aufgrund eines kundenanonymen Primärbedarfs ermittelt. Dieser wird im Rahmen der
Produktionsprogrammplanung anhand von Erfahrungswerten bestimmt und sukzessive
gegen die eingehenden Aufträge verrechnet. Darüber hinaus kann eine Verfügbarkeitsprüfung mit oder ohne Einbeziehung der Wiederbeschaffungszeit durchgeführt werden.
Durch ein integriertes Kreditmanagement kann das Kreditrisiko bei der Vertriebsabwicklung verringert werden. Eine direkte Verbindung zur Finanzbuchhaltung liefert Informationen zum Stand der offenen Posten und ermöglicht dadurch die Überprüfung
der Einhaltung von Kreditlimiten und die Beurteilung der finanziellen Situation eines
Kunden. Bei kritischen Kreditsituationen wird der Vertriebsmitarbieter durch das System
via Mail benachrichtigt. Dadurch kann die Verkaufsabwicklung beschleunigt und das
Kreditrisiko minimiert werden.
Das R/3-System unterstützt den Verkauf (SD-SLS) mit einer ganze Palette von Möglichkeiten. Durch verschiedene Arten von Verkaufsbelegen können alle Stadien der Auftragsabwicklung (Anfrage, Angebot, Auftrag, Rahmenverträge und Reklamationen) dargestellt werden. Die aus der Verkaufsabwicklung resultierenden Informationen (Preis,
Konditionen, Versandtermine, zugesicherte Mengen, etc.) erscheinen im Verkaufsbeleg
und bilden die Basis für die ganze Vertriebsabwicklung. Zur Unterstützung der für den
Versand (SD-SHP) erforderlichen Aktivitäten stellt das R/3-System folgende Grundfunktionen zur Verfügung:
• Terminverfolgung der fälligen Aufträge
• Erstellung und Bearbeitung von Lieferungen
• Überwachung der Verfügbarkeit eines Artikels
• Transportdisposition
• Unterstützung der Kommissionierung (Anbindung an das Lagerverwaltungssystem)
• Verpacken der Lieferungen
• Druck und Übermittlung der Versandpapiere
• Abwicklung des Warenausgangs
• Überwachung des Arbeitsvorrats im Versand.
95
Das R/3-System
Der Versand basiert im wesentlichen auf den Versandbelegen Lieferung und Warenausgang. Mit der Eröffnung eines Lieferbelegs wird der Versand eingeleitet. Falls der Lieferung die Erfassung eines Auftrags vorangegangen ist (Regelfall), werden sämtliche versandrelevanten Informationen übernommen. Andernfalls muss eine manuelle Erfassung
durchgeführt werden. Nach der Erstellung des Lieferbelegs erfolgt der Warenausgang
und der Druck der Versandpapiere. Der Warenausgang als solches wird über das Materialwirtschaftsmodul (MM) abgewickelt, da es sich dabei um eine Materialbewegung
handelt. Nach dem Warenausgang ist der Versand abgeschlossen und die Lieferung
kann fakturiert werden.
Als letzte Aktivität des Vertriebs sind bei der Fakturierung (SD-BIL) Rechnungen aufgrund der erbrachten Lieferungen und Leistungen zu erstellen. Die dafür relevanten
Informationen werden aus dem Verkaufs- und aus dem Versandbeleg entnommen.
Auch Sonderformen der Fakturierung (Proformarechnungen, Gut- und Lastschriften)
sind im System vorgesehen. Weiter kann die Stornierung von Rechnungen und die Bonusabwicklung durchgeführt werden. Nach der Erstellung der Faktura erfolgt die Übergabe der Daten an die Finanzbuchhaltung (FI).
Die Vertriebsunterstützung (SD-CAS) bietet für alle Aktivitäten im Rahmen der Akquisition und der Kundenbetreuung entsprechenden Support. Die gesammelten Informationen werden in strukturierter Form hinterlegt und können durch die Mitarbeiter des
Vertriebs und des Marketings in vielfältiger Weise genutzt werden. Dabei werden vor
allem Daten zu Kunden und Interessenten erfasst. Neben den eigentlichen Stammdaten
(Firmenname, Adresse, Ansprechpartner etc.) werden auch marketingrelevante Informationen (Umsatz, Anzahl Mitarbeiter, Branche etc.) erfasst. Zur Pflege des Kundenverhältnisses erlaubt das R/3-System die Erfassung von sämtlichen Informationen aus Kundenkontakten. Die Auswertung dieser Daten ermöglicht die bessere Planung und Koordination der Vertriebsaktivitäten. Durch Mailingaktionen, welche ebenfalls im System
verwaltet werden können, lassen sich Kunden und Interessenten spezifischer bearbeiten. Neben der Sammlung und Auswertungen von kundenspezifischen Daten bietet das
R/3-System auch die Möglichkeit, Informationen über Wettbewerber und deren Pro-
96
Das R/3-System
dukte zu hinterlegen. Sämtliche Daten (inkl. Texte) müssen in strukturierter Form erfasst
werden. Dadurch ist die bessere Auswertbarkeit der Informationen gewährleistet, und
es können dadurch zuverlässigere Aussagen über die eigene Wettbewerbssituation und
über die Erfolgschancen bei der Erschliessung neuer Märkte gemacht werden.
Neben den dargestellten Grundelementen zur Vertriebsabwicklung unterstützt das R/3System zusätzliche Funktionen für die Anforderungen international ausgerichteter Unternehmen. Darunter fallen insbesondere Instrumente zur Abwicklung von Aussenhandelsgeschäften. Im Zentrum steht dabei nicht nur die Veräusserung von Waren über die
Landesgrenzen hinweg, sondern auch um den Import von Gütern aus dem Ausland.
Die Teilkomponente Aussenhandel berücksichtigt diese besonderen Bedürfnisse durch
spezielle Datenfelder in den relevanten Stammdaten (Kundenstamm, Lieferantenstamm, Materialstamm, Einkaufsinfosatz), eine integrierte Ausfuhrkontrolle, ein weitgehend automatisiertes Meldeverfahren für behördliche Vorgänge und eine Herkunftsermittlung der verwendeten Teile und Baugruppen (Präferenzabwicklung). Dadurch werden die Vertriebsaktivitäten bei der Abwicklung von Aussenhandelsgeschäften erheblich
erleichtert und durch Automatisierung gewisser Vorgänge beschleunigt.
3.3.4.3 MM - Materialwirtschaft (Materials Management)124
Innerhalb des Logistikbereichs nimmt die Materialwirtschaft zentrale Aufgaben wahr. Sie
ist vorwiegend auf die Beschaffungsseite in der Logistikkette ausgerichtet und stellt in
diesem Kontext Funktionen für den Einkauf von Gütern und Dienstleistungen sowie für
die Lagerverwaltung und Bewertung der beschafften Materialien dar. In Abb. 3-18 sind
die einzelnen Komponenten im Überblick dargestellt.
124
Vgl. dazu CDI (1996a) S. 113 ff.; Engels/Gresch/Nottenkämpfer (1996), S. 270 ff.; SAP AG (1996a);
SAP AG (1993a).
97
Das R/3-System
MM - Materialwirtschaft
MMPUR
Einkauf
MMIM
MMCBP
MMSRV
Bestandesführung
Dienstleistung
MMWM
MMIV
Lagerverwaltung
Verbrauch
Disposition
Rechnungsprüfung
Abb. 3-18: Komponenten der Materialwirtschaft.
Neben dem Einkauf (MM-PUR) von materiellen Gütern unterstützt das R/3-System
auch die Beschaffung von extern bezogenen Dienstleistungen (MM-SRV). Für diesen
Zweck existiert ein eigens dafür vorgesehener Dienstleistungsstamm, welcher eine ähnliche Struktur aufweist wie der Materialstamm. Die Bedarfsermittlung von Dienstleistungen stützt sich im Unterschied zu materiellen Gütern eher auf Begehren der Instandhaltung (PM) oder des Projektsystems (PS). Für die Einkaufsabwicklung benötigt das R/3System neben Materialstamm und Dienstleistungsstamm weitere Grunddaten. Dazu
gehören insbesondere der Lieferantenstamm und die Einkaufsinfosätze.
Der Lieferantenstamm bildet die Grundlage für den Einkauf und für die Buchhaltung.
Er ist in Analogie zum Materialstamm ebenfalls hierarchisch organisiert und die einzelnen Datenbereiche sind für verschiedene Organisationsebenen gültig (Mandant, Buchungskreis oder Einkaufsorganisation). Für den Einkauf sind vorwiegend Informationen
zu Ansprechpartnern, Konditionen und Lieferbedingungen von Interesse. Die Buchhaltung benötigt vor allem Daten zu Bankverbindungen und Zahlungsbedingungen für die
Rechnungsprüfung und die Zahlungsabwicklung.
Für die Lieferantenermittlung werden im R/3-System sogenannte Einkaufsinfosätze
verwendet. Diese stellen eine Beziehung zwischen den benötigten Produkten und den
dafür in Frage kommenden Lieferanten her. Der Einkaufsinfosatz enthält zusätzlich In-
98
Das R/3-System
formationen zu Preisen, Konditionen, Lieferfristen und Lieferantenbeurteilungsdaten.
Die im Einkaufsinfosatz vorhandenen Daten werden als Grundlage für eine Bestellung
verwendet.
Die Abwicklung der Logistikprozesse erfolgt auf der Basis der erfassten Grunddaten.
Aufgrund der Informationen aus anderen R/3-Modulen (SD, PP, PS oder PM) oder anhand der aktuellen Bestandssituation wird eine Materialdisposition (MM-CBP) durchgeführt. Diese löst in Abhängigkeit des verwendeten Dispositionsverfahrens (Verbrauchsgesteuerte Disposition oder Plangesteuerte Disposition) Bestellvorschläge aus.
Die verbrauchsgesteuerte Disposition stellt ein relativ einfaches Verfahren zur Bedarfsermittlung dar und wird vorzugsweise in Betrieben ohne eigene Fertigung oder in
Produktionsbetrieben für die Beschaffung von B- und C-Teilen, resp. Hilfs- und Betriebsstoffen verwendet. Die plangesteuerte Disposition richtet sich am effektiven Bedarf und wird in Produktionsbetrieben vorwiegend für die Beschaffung von A-Teilen
verwendet. Die aus der Materialdisposition resultierenden Bestellvorschläge, welche
unter Berücksichtigung des gewählten Dispositionsverfahrens und eines entsprechenden
Losgrössenverfahrens ermittelt werden, können in Abhängigkeit von der Beschaffungsart
des Materials (Fremdbeschaffung oder Eigenfertigung) entweder in eine Bestellanforderung oder in einen Planauftrag umgewandelt werden. Dadurch kann entweder der Beschaffungs- oder der Produktionsprozess ausgelöst werden.
Innerhalb der Materialwirtschaft setzt sich der Logistikprozess mit der Einkaufsabwicklung fort. Durch die Bestellanforderung sind für die zu bestellenden Materialien die
Menge und der Termin festgelegt worden. Ausgehend von diesen Rahmenbedingungen
hat der Einkäufer die Möglichkeit, über das System eine oder mehrere Bezugsquellen zu
ermitteln und Anfragen zu formulieren. Nach dem Eintreffen der verschiedenen Offerten lassen sich diese im System miteinander vergleichen, und eine Lieferantenauswahl
kann getroffen werden. Die nachfolgende Bestellabwicklung basiert auf den bereits erfassten Daten und ermöglicht ein weitgehend automatisiertes Vorgehen (Erstellen der
Bestellung und Bestellüberwachung). Die physische Einkaufsabwicklung wird durch den
Wareneingang abgeschlossen.
99
Das R/3-System
Jeder Vorgang der eine Veränderung des Warenbestandes bewirkt, wird im R/3-System
im Rahmen der Bestandesführung (MM-IM) erfasst. In diesem Zusammenhang wird
von Warenbewegungen gesprochen. Dabei werden verschiedene Arten von Warenbewegungen unterschieden:
• Wareneingang (Erhöhung des Lagerbestands)
• Warenausgang (Verminderung des Lagerbestands)
• Umlagerung zwischen verschiedenen Lagerorten
• Umbuchung (z.B. Übernahme von Konsignationsmaterial in den eigenen Bestand).
Zur Unterscheidung der verschiedenen Warenbewegungen sind im R/3-System sogenannte Bewegungsarten vorgesehen. Diese beinhalten zugleich eine Steuerungsfunktion
für die Fortschreibung der Bestände. Die Bestandsführung berücksichtigt aber nicht nur
die mengenmässigen Auswirkungen einer Warenbewegung, sondern schreibt auch die
wertmässigen Veränderungen fort. Aus diesem Grund wird vom System neben dem
Materialbeleg zusätzlich ein Buchhaltungbeleg erzeugt. Durch diese mengen- und
wertmässige Erfassung jeder Warenbewegung sind die Lagerbestände und der aktuelle
Wert des Lagers jederzeit bekannt. Ein Abgleich zwischen den Buchungsbeständen und
den effektiven Beständen im Lager kann über verschiedene Inventurverfahren
(Stichtagsinventur, Stichprobeninventur, Cycle-Counting) erfolgen.
Das Lagerverwaltungssystem (MM-WM) ergänzt die Möglichkeiten der Bestandsführung. Hier werden zusätzlich zu den rein mengen- und wertmässigen auch räumliche
Bewegungen erfasst und gesteuert. Dabei lassen sich die verschiedensten Lagertypen
(Hochregallager, Freilager, Blocklager etc.) mit dem R/3-System abbilden und verwalten. Zusätzlich können sämtliche Lagerbewegungen initiiert, gesteuert und überwacht
werden.
Die Bestandsführung und das Lagerverwaltungssystem stellen eine wichtige Informationsbasis für andere R/3-Komponenten dar. Beispielsweise wird die Verfügbarkeitsprüfung bei Kundenbestellungen (SD) oder bei kundenanonymen Fertigungsaufträgen
(PP) aufgrund der im Rahmen der Bestandsführung fortgeschriebenen Werte durchge-
100
Das R/3-System
führt. Aber auch andere R/3-Module (FI, CO, AM, PS, QM, PM, LIS) beziehen für die
Abwicklung bestimmter Geschäftsprozesse Informationen aus der Bestandsführung.
Endgültig abgeschlossen wird die Einkaufsabwicklung mit der Rechnungsprüfung (MMIV), welche ebenfalls ein Bestandteil von MM darstellt. Dabei werden eingehende
Rechnungen erfasst, auf sachliche, preisliche und rechnerische Richtigkeit geprüft und
in der Kreditorenbuchhaltung (FI) verbucht. Darüber hinaus können auch Rechnungen,
welche ausserhalb der ordentlichen Materialbeschaffung angefallen sind, über die
Rechnungsprüfung abgewickelt werden.
Im Rahmen der Materialbewertung wird der Bestandswert eines Materials errechnet
und in der Finanzbuchhaltung fortgeschrieben. Die dafür benötigten Informationen bezieht die Materialbewertung vom Einkauf, von der Bestandsführung und von der Rechnungsprüfung. Durch die aktuelle Berechnung der Bestandswerte kann der Wert des
Lagers für die Aufstellung von Zwischenbilanzen jederzeit ermittelt werden.
Im Material Ledger wird als alternative Methode zur Materialbewertung eine Art Nebenbuchhaltung für Materialien geführt. Dies hat den Vorteil, dass der Materialpreis für
einen bestimmten Zeitraum konstant gehalten werden kann. Ferner wird die Möglichkeit geboten die Materialbewertung in 3 verschiedenen Währungen zu führen, was die
Konsolidierung der einzelnen Bilanzen in einem Konzern erheblich erleichtert.
3.3.4.4 PP - Produktionsplanung und -steuerung (Production Planning)125
Zwischen dem Einkauf und der Lagerung von Rohstoffen und Baugruppen und dem
Vertrieb der Endprodukte spielt die DV-gestützte Planung und Steuerung des Fertigungsprozesses eine zentrale Rolle. In diesem Kontext trägt ein PPS-System wesentlich
zur Qualität, zur Variantenvielfalt und zur Erhaltung der Lieferbereitschaft in einem Fertigungsbetrieb bei. Aufgrund der Komplexität der Planung und Steuerung von Fertigungsprozessen haben viele Betriebe bereits frühzeitig erkannt, dass sich diese Problemstellung nur sinnvoll mit IV-Unterstützung lösen lässt. PPS-Systeme sind dementspre-
125
Vgl. dazu Wenzel (1995a), S. 299 ff., SAP AG (1996a), SAP AG (1994a).
101
Das R/3-System
chend komplex und stellen ein klassisches Anwendungsgebiet für betriebswirtschaftliche
Applikationen dar. Die allgemeine Produktionsplanung und -steuerung des R/3-Systems
lässt sich in die in Abb. 3-19 dargestellten Einzelkomponenten untergliedern.
PP - Produktionsplanung und -steuerung
PPBD
PPMP
PPSOP
Absatz- und Produktionsgrobplanung
Grunddaten
PPMRP
PPCRP
Lagerverwaltung
PPSFC
Kapazitätsplanung
Produktionsplanung
Fertigungsaufträge
COPC
Produktkalkulation
Abb. 3-19: Komponenten der Produktionsplanung und -steuerung.
Für die Planung und Abwicklung von Fertigungsprozessen benötigt ein PPS-System entsprechende Grunddaten. Dazu werden insbesondere Informationen über das Produkt
und dessen Bestandteile (Materialstamm, Stücklisten), über das Vorgehen bei der Fertigung (Arbeitspläne) sowie über die Art und Kapazitäten der vorhandenen Arbeitsplätze
benötigt.
Auf die Bedeutung des Materialstamms wurde bereits im Rahmen der Materialwirtschaft hingewiesen. In diesem Zusammenhang ist sicherlich noch erwähnenswert, dass
neben den Einzelteilen und Baugruppen im Materialstamm auch sämtliche Enderzeugnisse erfasst werden. Die unterschiedliche Rolle wird den Materialien über die Zuordnung zu einer Materialart (z.B. ROH, HALB, FERT) zugeschrieben.
102
Das R/3-System
Die Struktur eines Endprodukts wird durch die Erfassung von Stücklisten dargestellt.
Eine Stückliste definiert die Menge und Art der Einzelbestandteile eines Enderzeugnisses. Im R/3-System werden verschiedene Arten von Stücklisten unterschieden:
• Einfache Stückliste
• Variantenstückliste
• Mehrfachstückliste.
Bei einer einfachen Stückliste existiert zu einem Produkt nur eine Stückliste, bzw. diese
wird für kein anderes Produkt verwendet. Variantenstücklisten werden bei der Herstellung von ähnlichen Erzeugnissen, d.h. wenn die Grundstruktur identisch ist und nur
geringe Abweichungen in Einzelbereichen existieren (z.B. Variantenkonfiguration von
Fahrzeugen in der Automobilindustrie). Mehrfachstücklisten werden für Produkte verwendet, die je nach Losgrösse in unterschiedlichen Verfahren und unterschiedlichen
Mengenverhältnissen hergestellt werden. Diese Anwendung ist insbesondere bei Erzeugnissen aus der Chemischen Industrie üblich.
Neben der Art einer Stückliste wird auch der Verwendungszweck als Differenzierungsmerkmal herangezogen. Unterschieden wird dabei zwischen Verwendungen für die
Fertigung, die Konstruktion, die Instandhaltung, den Vertrieb oder die Kalkulation.
Durch Arbeitspläne wird die Reihenfolge einzelner Arbeitsgänge festgelegt. Gleichzeitig
erfolgt eine Zuordnung der Arbeitsgänge zu den im Betrieb vorhandenen Arbeitsplätzen. Zudem können in einem Arbeitsplan auch die benötigten Fertigungshilfsmittel
(Werkzeuge etc.) berücksichtigt werden. Für die Terminierung und Kalkulation des Herstellungsprozesses lassen sich für jeden Arbeitsgang Vorgabewerte erfassen. Im eigentlichen Fertigungsprozess werden die erfassten Arbeitspläne als Vorlage verwendet und
können gegebenenfalls nach der Übernahme in den Fertigungsauftrag noch angepasst
werden.
In den für die Erfassung der Arbeitspläne notwendigen Arbeitsplätzen wird festgelegt,
welche personellen oder maschinellen Ressourcen verfügbar sind. Dabei werden nicht
nur die Kapazitäten bestimmt, sondern auch die Kosten, welche bei der Nutzung dieser
103
Das R/3-System
Faktoren entstehen. Diese Informationen bilden die Grundlage für verschiedene R/3Komponenten. Insbesondere bilden sie die Grundlage für die Kalkulation, für die Terminierung und für die Kapazitätsplanung.
Am Anfang des Produktionsplanungs- und -steuerungszyklusses steht die Absatz- und
Produktionsgrobplanung (SOP = Sales & Operations Planning). Deren Ziel ist es auf
der Basis einer mittel- oder langfristigen Absatzmengenplanung die dazu notwendigen
Produktionsaktivitäten festzulegen. Dabei können die voraussichtlichen Absatzmengen
entweder manuell erfasst werden (z. B. geplante Absatzwerte) oder auf der Grundlage
von Vergangenheitswerten über verschiedene Prognoseverfahren bestimmt werden. Die
Planung kann wahlweise für einzelne Materialien oder ganze Produktgruppen durchgeführt werden. Ausgehend von den in der Absatzmengenplanung ermittelten Werten
wird anschliessend ein Produktionsgrobplan erstellt. Dieser bildet einen Richtwert für
nachgelagerte Planungsphasen.
Die Langfristplanung stellt eine Art simulative Planung für eine längere Zeitspanne (ca.
1 Jahr) dar. Dabei wird das Ziel verfolgt, längerfristig abzuschätzen, ob für einen gegebenen Absatzplan ausreichend Kapazitäten zur Verfügung stehen oder ob diese Kapazitäten allenfalls erweitert werden müssen (z.B. durch Zukauf neuer Maschinen). Ausserdem kann der Einkauf anhand der Planwerte das Bestellvolumen für einzelne Lieferanten ableiten und wird dadurch in die Möglichkeit versetzt, Kontrakte zu günstigen
Konditionen auszuhandeln. Die Langfristplanung wird simulativ, d.h. losgelöst von der
operativen Planung durchgeführt. Es besteht allerdings die Möglichkeit ein bestehendes
Produktionsprogramm durch eine bevorzugte Version der Langfristplanung zu ersetzen.
Bei der eigentlichen operativen Planung (Produktionsprogrammplanung) werden die
Bedarfsmengen und die Liefertermine für Enderzeugnisse und wichtige Baugruppen
festgelegt. Die Absatzzahlen zur Ermittlung des Produktionsprogramms entstammen
entweder der Prognoserechnung oder werden von der Ergebnis- und Marktsegmentrechnung (CO-PA) bzw. von der Planungskomponente des Vertriebsinformationssystems (SD-IS) geliefert. Auch Absatzzahlen aus externen Datenquellen können als Inputwerte für die Produktionsprogrammplanung verwendet werden.
104
Das R/3-System
Beeinflusst wird die Planung von der gewählten Planungsstrategie. Dabei können
grundsätzlich folgende Strategien unterschieden werden:
• Anonyme Lagerfertigung
• Kundeneinzelfertigung
• Losfertigung für Kunden- und Lageraufträge.
Über die Auswahl einer Vorplanungstrategie wird bestimmt, ob gegebenenfalls gewisse
Baugruppen auftragsneutral vorproduziert werden und wie diese vorproduzierten Baugruppen gegen eingehende Kundenaufträge verrechnet werden sollen.
Die Bedarfsplanung hat dafür zu sorgen, dass das richtige Material zum richtigen Zeitpunkt und in der richtigen Menge vorhanden ist. Dabei steht die Gewährleistung eines
möglichst optimalen Lagerbestands im Vordergrund. Bei der Durchführung der Materialbedarfsplanung können im R/3-System verschiedene Dispositionsverfahren verwendet werden:
• Plangesteuerte Disposition
• Leitteileplanung
• Verbrauchsgesteuerte Disposition.
Durch die plangesteuerte Disposition (oder auch deterministische Disposition genannt) werden die exakten Bedarfsmengen ermittelt. Dies ermöglicht eine Produktion
mit minimalen Sicherheitsbeständen. Ausgangspunkt für die plangesteuerte Disposition
sind Kundenaufträge, Planprimärbedarfe oder Materialreservierungen.
Für Teile, die einen erheblichen Einfluss auf den Produktionsprozess haben, wird eine
separate Disposition (Leitteileplanung) durchgeführt. Diese Differenzierung wird insbesondere aufgrund der Tatsache vorgenommen, dass bei vollständiger Erfassung aller
Teile die eingeplanten Puffer und Sicherheitsbestände zu einer hohen Kapitalbindung
führen.
Im Rahmen der verbrauchsgesteuerten Disposition wird der künftige Bedarf anhand
vergangener Verbrauchswerte durch verschiedene Prognoseverfahren bestimmt. Das
105
Das R/3-System
Verfahren basiert auf den aktuellen Beständen und errechnet die Primär- und Sekundärbedarfe bei Unterschreitung eines Meldebestandes.
Auf die zeitliche und mengenmässige Festlegung der zu produzierenden Güter
(Kapazitätsbedarf) folgt die Abstimmung mit den vorhandenen Kapazitäten (Kapazitätsangebot). In diesem Zusammenhang wird von Kapazitätsplanung gesprochen. Eine
Kapazität stellt dabei eine Ressource (z.B. Person oder Maschine) dar, deren Angebot
für einen Zeitraum festgelegt werden kann. Über die Arbeitspläne erfolgt die Zuordnung
der einzelnen Arbeitsgänge zu den verfügbaren Arbeitsplätzen. Für alle Arbeitsplätze ist
somit über die zugewiesenen Kapazitäten ein bestimmtes Kapazitätsangebot verfügbar.
Dieses Kapazitätsangebot wird im Rahmen der Kapazitätsplanung den aus den Vorgabewerten ermittelten Bedarfen gegenübergestellt (Kapazitätsauswertung). Die einzelnen
Bedarfe werden vor allem aus folgenden Anwendungsbereichen des R/3-Systems erzeugt:
• Vertrieb (Kundenaufträge)
• Absatz- und Produktionsgrobplanung (Produktionsgrobplanmengen)
• Langfristplanung (Planaufträge)
• Leitteileplanung (Planaufträge)
• Materialbedarfsplanung (Planaufträge)
• Serienfertigung (geplante Produktionsmengen)
• Fertigungssteuerung (Fertigungsaufträge)
• Projektsystem (Netzpläne)
• Instandhaltung (Instandhaltungsaufträge)
• Personalplanung (Personalplanungsaufträge).
106
Das R/3-System
Durch den Vergleich von Kapazitätsangebot und Kapazitätsbedarf lassen sich Über- und
Unterbelastungen innerhalb des Fertigungsprozesses bestimmen. Es ist das Ziel des Kapazitätsabgleichs, diese Schwankungen auszugleichen. Ferner werden folgende Ziele
verfolgt:
• Hohe Kapazitätsauslastung
• Hohe Termintreue
• Kurze Durchlaufzeit
• Niedrige Bestände.
Diese teilweise gegenläufigen Ziele erschweren die Planung. Werden Kapazitätsengpässe festgestellt, kann diesen durch verschiedene Massnahmen entgegengewirkt werden.
Ist der durchzuführende Auftrag bezüglich Endtermin flexibel, reicht eine einfache Umplanung der Arbeitsgänge. Bei fixen Endterminen können Kapazitätsengpässe nur durch
Ausweitung des Kapazitätsangebots (Überstunden, Schichtarbeit, temporäre Aushilfskräfte) überwunden werden. Die Auswirkungen auf die Planung können bei Änderung
des Kapazitätsangebots simulativ ermittelt werden.
Nach erfolgter Kapazitätsplanung werden die Fertigungsaufträge freigegeben und zur
Überwachung der Auftragsabwicklung an die Fertigungssteuerung übergeben. In einem
Fertigungsauftrag sind sämtliche Daten, welche für die Erbringung einer innerbetrieblichen Leistung relevant sind, zusammengefasst. Zusätzlich sind auch kostenrelevante
Informationen zur Auftragsabrechnung hinterlegt. Die Auftragsabwicklung ist in drei
Phasen unterteilt:
• Auftragseröffnung (Umsetzung von Planaufträgen, Stücklistenauswahl und Arbeitsplanselektion, Materialreservierungen, Ermittlung der Plankosten, Erzeugung von
Kapazitätsbedarfen, Bestellanforderungen für Nichtlagerpositionen und fremdbearbeitete Vorgänge)
• Auftragsabwicklung (Materialentnahme, Auftragsdurchführung, Rückmeldungen,
Lagerzugang)
• Auftragsabschluss (technischer Abschluss, Auftragsabrechnung)
107
Das R/3-System
Mit der Abrechnung ist der Fertigungsauftrag abgeschlossen und sämtliche Daten können einem elektronischen Archiv zugeführt werden.
Zur Preis- und Kostenbestimmung von Enderzeugnissen wird im R/3-System die Produktkalkulation (CO-PC) herangezogen. Diese besteht aus der Erzeugniskalkulation
und der Bauteilekalkulation.
Die Erzeugniskalkulation126 dient primär zur Ermittlung der Einzelpreise von gefertigten
Produkten. Dabei werden die Herstell- (Material-, Fertigungs- und Gemeinkosten) und
die Selbstkosten errechnet. Die dazu notwendigen Informationen bezieht das R/3System aus den Materialstamm (Materialpreise), aus den Stücklisten (Mengenangaben),
aus den Arbeitsplänen (Zeitvorgabewerte für die Durchführung des Arbeitsgangs), aus
den Arbeitsplätzen und aus der Kostenstellenrechnung (Leistungstarife). Die Gemeinkosten (Material- und Fertigungsgemeinkosten) werden über ein Kalkulationsschema als
Zuschlagssätze berücksichtigt. Die daraus resultierenden Herstellkosten bilden die
Preisbasis (Standardpreis) im Materialstamm.
Während die Erzeugniskalkulation in der Regel gemeinsam mit der Produktionsplanung
verwendet wird (Kalkulation von Materialien, Fertigungsaufträgen oder Kundenaufträgen), ist die Einzelkalkulation für die Bearbeitung von kalkulationsrelevanten Daten aus
Fremdsystemen vorgesehen. Die Bauteilekalkulation, welche die Funktionalität der
Einzelkalkulation nutzt, stellt ebenfalls ein Instrument zur Kostenplanung und Preisbildung für Produkte dar. Im Gegensatz zur Erzeugniskalkulation ist bei der Bauteilekalkulation aber eine Kostenermittlung ohne Bezug zu Stücklisten und Arbeitsplänen (resp.
Netz- und Wartungspläne) möglich. Zusätzlich lassen sich einzelne Kalkulationspositionen (Bauteile) hierarchisch zusammenfassen. Dadurch besteht die Möglichkeit der
Wiederverwendung einzelner Kalkulationselemente.
Neben den Standardfunktionen der Produktionsplanung und -steuerung unterstützt das
R/3-System in diesem Bereich spezielle produktionswirtschaftliche Bedürfnisse durch
Zusatzkomponenten. Darunter fallen die in Abb. 3-20 dargestellten PP-Komponenten:
126
Vgl. Wenzel (1995a), S. 385 ff.
108
Das R/3-System
Spezielle Komponenten von PP
PPREM
PPKAP
Serienfertigung
PPPI
Kanban
Produktionsplanung
Prozessindustrie
Abb. 3-20: Spezielle Komponenten der Produktionsplanung und -steuerung.
Die Komponente Serienfertigung basiert auf den Ergebnissen der Gesamtbedarfsplanung und stellt für die Planung und Steuerung der Fertigungsabwicklung spezielle Funktionen zur Verfügung. Der als Grundlage für die Serienfertigung notwendige Gesamtbedarf wird anhand von Bedarfsprognosen und Planprimärbedarfen bestimmt. Diese werden mit den eingehenden Kundenaufträgen verrechnet und stellen als Gesamtergebnis
das Produktionsprogramm dar. Ausgehend von diesem Produktionsprogramm werden
periodenbezogen die Produktionsmengen für jedes Erzeugnis festgelegt. Die kurzfristige
Einplanung erfolgt mit Hilfe einer grafischen Plantafel.
Für die Abwicklung der Serienfertigung stehen grundsätzlich zwei verschiedene Varianten zur Verfügung. Bei der ersten Variante können Serienaufträge durch Zusammenfassung von selbständigen Plan- oder Fertigungsaufträgen erstellt werden. Die Sammlung
der Ist-Daten erfolgt dabei auf Basis der Fertigungsaufträge. Bei der zweiten Variante
entfallen die Fertigungsaufträge. Ein Serienauftrag besteht aus mehreren Produktionseinteilungen, welche in gewissem Sinn mit Planaufträgen vergleichbar sind. Die Zuweisung der während der Produktion anfallenden Kosten erfolgt in diesem Fall über sogenannte Produktionskostensammler.
Die zeitraumbezogene Betrachtungsweise in der Planung und die Vereinfachung bei der
Ist-Datenerfassung ermöglicht im Unterschied zur Einzel- und Werkstattfertigung eine
entsprechende Reduktion des Aufwands bei der Abwicklung von Serienaufträgen.
Die Produktionssteuerung mit Kanban stellt eine elektronische Variante des bekannten
Kanban/Just-in-Time-Verfahrens (Kanban/JIT) dar. Dabei wird das für die Fertigung benötigte Material in Behältern direkt am Fertigungsort zwischengelagert. Entsteht bei der
109
Das R/3-System
Fertigung ein Materialbedarf, kann dieser durch Entnahme aus einem bereitgestellten
Behälter gedeckt werden. Die Materialentnahme wird über einen Barcode-Leser sofort
an das R/3-System weitergemeldet (analog der Weiterleitung einer Kanban-Karte). Dieser Impuls löst im System entweder einen Lagernachschub oder die externe Beschaffung
resp. die innerbetriebliche Fertigung des entsprechenden Teils aus. Die administrativen
Bereiche eines Unternehmens werden durch dieses Vorgehen entlastet und das Fehlerrisiko wird vermindert. Gleichzeitig bewirkt die Rückwärtsverkettung des Materialnachschubs eine Verringerung der Lagerbestände sowie eine Verkürzung der Durchlaufzeiten. Ein entsprechendes Informationssystem zur Überwachung des Materialflusses
schafft zusätzliche Transparenz, indem die Disponenten auf Engpässe und Störsituationen bei der Materialversorgung aufmerksam gemacht werden.
Die Produktionsplanung für die Prozessindustrie (PP-PI) richtet sich primär nach den
Bedürfnissen der chemischen, der pharmazeutischen, der Nahrungs- und Genussgüterindustrie sowie der prozessorientierten Elektronikbetriebe. Hauptmerkmale dieser Unternehmen sind:
• Der Fertigungsprozess ist nicht kontinuierlich (Chargenfertigung).
• Produktionsanlagen sind variabel einsetzbar.
• Durch die aufwendigen Reinigungsvorgänge steht die Reihenfolgeplanung im Vordergrund.
• In der Produktion fallen Kuppel- und Abfallstoffe an.
• Die Rezepturen sind umgebungsabhängig und müssen auch nachträglich jeder
Charge zugeordnet werden können.
Diese Besonderheiten werden durch entsprechende Funktionen in der PP-PI-Komponente unterstützt.
In der Ressourcenverwaltung werden sämtliche für den Produktionsprozess benötigten
Produktionsmittel verwaltet. Anstelle von Stücklisten und Arbeitsplänen werden die
Produktionsverfahren mit den dafür benötigten Ressourcen (inkl. Kuppel- und Abfallprodukte) in sogenannten Planungsrezepten beschrieben. Die Prozessplanung (Absatz-
110
Das R/3-System
und Produktionsgrobplanung, Langfristplanung, Programmplanung, Materialbedarfsplanung und Kapazitätsplanung) erfolgt mit den Planungsinstrumenten der Standard-R/3PP-Komponente. Die Prozessaufträge übernehmen in PP-PI die Funktion von Fertigungsaufträgen und beschreiben durch Übernahme und Anpassung der Planungsrezepte den konkreten Herstellungsvorgang. Die Prozesskoordination stellt die Schnittstelle zwischen PP-PI und automatisierten, teilautomatisierten sowie manuell gesteuerten Prozesssteuerungsanlagen dar. Dabei werden Steuerrezepte an die Prozesssteuerungsanlagen weitergeleitet und Prozessmeldungen von diesen entgegengenommen,
damit laufend der Prozessfortschritt überwacht werden kann. Zur Gewährleistung eines
weitgehend automatisierten Informationsflusses existieren für die Anbindung an Prozessleitsysteme und die Übernahme von Rückmeldedaten entsprechende Schnittstellen.
Die Prozessdokumentation und -auswertung wird durch die Anbindung von optischen
Archivierungssystemen sichergestellt. Gesetzliche Vorschriften verlangen, dass z.B. in
der pharmazeutischen Industrie die zum Prozessauftrag gehörenden Daten fälschungssicher archiviert und jederzeit für Nacherhebungen verfügbar gemacht werden können.
Die PP-PI-Komponente stellt somit ein leistungsfähiges Planungs- und Steuerungsinstrument für die spezifischen Bedürfnisse der Prozessindustrie dar.
111
Das R/3-System
3.3.4.5 QM - Qualitätsmanagement127
Neben der Optimierung des Produktionsabläufe und der Minimierung der Kosten spielt
auch die Qualität der Enderzeugnisse eine wichtige Rolle. Das Qualitätsmanagement
bezieht sich gemäss den ISO 9000 - Richtlinien nicht nur auf den Fertigungsprozess von
Enderzeugnissen, sondern erfasst die Qualitätssicherungsmassnahmen im gesamten
Auftragsabwicklungsprozess. Darunter fallen die Lieferantenbeurteilung bei der Beschaffung, die fertigungsbegleitenden Prüfungen während der Produktion und die Qualitätsprüfung unmittelbar vor der Auslieferung (Vertrieb).
Durch die Integration von Qualitätssicherungsfunktionen in die betroffenen R/3Komponenten, können die bei der ISO-Zertifizierung festgehaltenen Massnahmen weitgehend über das System abgewickelt werden. Die dabei unterstützten CIQ-Aufgaben
(Computer Integrated Quality Management) lassen sich im Überblick wie folgt darstellen:128
• Integration der Qualitätsdaten im Materialstamm
• Verwaltung der materialbezogenen Qualitätsinformationen zu Lieferanten und Kunden bzw. Vertriebsbereichen
• Verknüpfung von Prüfmerkmalen und Qualitätsmerkmalen in den Materialspezifikationen
• Verwaltung von qualitätsbezogenen Dokumenten
• Integration der Qualitätsprüfung in den SAP Business Workflow.
In erster Linie geht es um die Erfassung und Verwaltung der Qualitätsdaten und entsprechenden Richtlinien, um die kontrollierte Durchführung von Qualitätsprüfungen und
um die Verwaltung von qualitätsbezogenen Dokumenten. Zur Bewältigung dieser Auf-
127
128
Vgl. dazu Wenzel (1995a), S. 392 ff.; SAP AG (1996a), Abschnitt: Qualitätsmanagement; SAP AG
(1994a), S. 10-1 ff.
Vgl. SAP AG (1996a), Abschnitt: CIQ-Aufgaben des Moduls QM.
112
Das R/3-System
gabenbereiche stellt das R/3-System die in Abb. 3-21 dargestellten Komponenten zur
Verfügung.
QM - Qualitätsmanagement
QMPT
QMIM
QMQC
Prüfplanung
Prüfabwicklung
QMCA
QMQN
Qualitätszeugnisse
Qualitätslenkung
Qualitätsmeldungen
Abb. 3-21: Komponenten der Qualitätssicherung.
Die Grundlage für die Prüfplanung (QM-PT) bilden der Prüfplan und die Prüfmerkmale. Die Prüfmerkmale bestimmen, welche Sollwerte vorgegeben sind und welche Toleranzwerte eingehalten werden müssen. Zusätzlich können Stichprobenmerkmale festgehalten werden. Die Prüfmerkmale können anschliessend entweder Prüfplänen oder
Arbeitsplänen zugeordnet werden. In einem Prüfplan wird der Ablauf einer Prüfungsdurchführung festgelegt. Einige wesentliche Grunddaten der Qualitätssicherung sind
auch im Materialstamm (Sicht - Qualitätsmanagement) zu finden. Es handelt sich dabei
vor allem um Beschaffungs- und Prüfdaten.
Diese Grunddaten bilden die Voraussetzung für die eigentliche Prüfabwicklung (QMIM). Diese unterstützt die Funktionen Prüfungsverwaltung und Qualitätsdatenerfassung.
Die Prüfungsverwaltung löst Prüfungen aus und steuert deren Ablauf und sorgt für eine
entsprechende Bewertung der Prüfergebnisse. Im Rahmen der Qualitätsdatenerfassung
werden die Daten der zu prüfenden Merkmale abgelegt. Als Abschluss des Prüfprozesses erfolgt eine Bewertung der Prüfergebnisse und damit der Entscheid über die Verwendung eines Teils.
113
Das R/3-System
Parallel zur Durchführung der Qualitätsprüfung können die Prüfkosten ermittelt werden.
Gleichzeitig besteht die Möglichkeit, den während der Fertigung entstandenen Fehlleistungsaufwand zu bestimmen. Die Ermittlung dieser Kostenwerte bildet die Grundlage
für ein effizienteres Qualitätssicherungsmanagement (Qualitätslenkung QM-QC) und
trägt damit wesentlich zur Verbesserung der Kundenzufriedenheit und zur Erhöhung der
Wettbewerbsfähigkeit bei.
Durch Qualitätszeugnisse (QM-CA) werden bestimmte Eigenschaften eines Produktes
oder die Einhaltung eines genau festgelegten Herstellungsprozesses ausgewiesen. Es
wird zwischen kundenspezifischen Qualitätszeugnissen und Zeugnissen für einen grösseren Kundenkreis (Allgemeine Zeugnisse) unterschieden. Die einzelnen Zeugnisse sind
in der Regel an eine Lieferposition gebunden und werden weitgehend automatisch erzeugt. In speziellen Fällen können Qualitätszeugnisse auch direkt für eine Charge oder
ein Prüflos ausgestellt werden.
Qualitätsmeldungen (QM-QN) stellen eine wichtige Funktion des Qualitätsicherungsmanagements dar. Durch Qualitätmeldungen können Daten zu Produkten oder
Dienstleistungen von ungenügender Qualität erfasst und ausgewertet werden. Darunter
fallen sowohl Kundenreklamationen als auch Mängelrügen an Lieferanten sowie betriebsinterne Problemmeldungen. QM-QN ist Teil des integrierten SAP-Meldesystems
und dadurch eng mit der Instandhaltung und dem Servicemanagement verbunden.
Ferner bietet das Qualitätsmanagementinformationssystem, welches Teil des Logistikinformationssystems (LO-LIS) ist, zusätzliche Auswertungsmöglichkeiten zu den Aktivitäten
der Qualitätssicherung. Diese Informationen tragen ebenfalls zur Qualitätslenkung bei.
114
Das R/3-System
3.3.4.6 PM - Instandhaltung (Plant Maintenance)129
Ähnlich wie das Qualitätsmanagement trägt auch die Instandhaltung (PM) zur Steigerung der Produktequalität und zur Verbesserung der Kundenserviceleistungen bei. Regelmässig durchgeführte Instandhaltungsmassnahmen für die betrieblichen Anlagen reduzieren Stillstandszeiten und Fehlmengenkosten. Dies steigert die Kundenzufriedenheit und trägt damit indirekt zu einer Verbesserung der Wettbewerbsfähigkeit bei.
Das PM-Modul unterstützt den gesamten Bereich der Instandhaltung von der Planung
über die Abwicklung bis zur Abrechnung (vgl.
Abb. 3-22). Darunter fallen geplante (Wartungs- und Inspektionsarbeiten) und ungeplante Instandhaltungsmassnahmen (Störungen). Hauptsächlich bezieht sich das Instandhaltungsmanagement auf den Unterhalt eigner Anlagen. Daneben bietet eine spezielle Service-Komponente (Service Management) die Möglichkeit der Abwicklung von
Wartungs- und Serviceleistungen für veräusserte Produkte und Anlagen. Über eine besondere Schnittstelle kann zusätzlich das Service Support System eines Drittanbieters
angebunden werden. Durch dieses System werden Servicemitarbeiter via Notebook vor
Ort mit allen notwendigen Informationen versorgt.
PM - Instandhaltung
PMEQM
Anlagenstrukturierung
PMPRM
PMSMA
Arbeits- und
Wartungspläne
PMWOC
Instandhaltungsauftragsabwicklung
ServiceManagement
Abb. 3-22: Komponenten der Instandhaltung.
129
Vgl. dazu Wenzel (1995a), S. 414 ff.; SAP AG (1996a) Abschnitt: Instandhaltung; SAP AG (1996c).
115
Das R/3-System
Die Anlagenstrukturierung (PM-EQM) schafft die notwendige Transparenz über die
vorhandenen Anlagen. Dabei können die Anlagen nach folgenden Kriterien strukturiert
werden:
• nach funktionalen Kriterien (technische Plätze)
• nach objektbezogenen Kriterien (Equipmenthierarchien)
• nach technischen Gesichtspunkte (Klassifizierung)
• nach buchhalterischen Gesichtpunkten (in Sinne der Anlagenbuchhaltung).
Anhand dieser Strukturierungsmerkmale und durch zusätzliche graphische Darstellungsmöglichkeiten lassen sich die vorhandenen Anlagenstrukturen übersichtlich verwalten. Ferner besteht durch eine Schnittstelle zum Dokumentenverwaltungssystem
(DVS) des R/3-Systems die Möglichkeit, die einzelnen Anlagen durch technische Skizzen und Pläne visuell darzustellen.
Durch die Objektverbindung resp. die Objektvernetzung können die Abhängigkeiten
zwischen den einzelnen Anlagen erfasst werden. Dadurch ergeben sich bei komplexen
Anlagestrukturen (z.B. Chemische Industrie) im Störfall erhebliche Vorteile für die Fehlersuche (z.B. Auswirkungen von vorgelagerten Systemen). Gleichzeitig lassen sich die
Instandhaltungsmassnahmen besser planen, denn durch die Objektverbindung wird
klargestellt, welche vorgelagerten und nachgelagerten Systeme bei der Wartung einer
einzelnen Anlage betroffen sind.
Instandhaltungsstücklisten und -arbeitspläne bilden die Grundlage für Wartungsmassnahmen. Eine Instandhaltungstückliste beschreibt die Struktur eines technischen Objekts
und liefert gleichzeitig Informationen über die einzelnen Ersatzteile einer Anlage.
Instandhaltungsarbeitspläne (PM-PRM) halten die notwendigen Vorgehensschritte bei
der Wartung fest. Dadurch können stets wiederkehrende Aktivitäten standardisiert und
in einheitlicher Form für die Planung bereitgestellt werden.
Mit der Wartungsplanung wird das Ziel verfolgt, die Stillstandszeiten von Produktionsanlagen möglichst zu reduzieren. Bei der Wartungsplanung müssen neben Kosten- und
Qualitätsaspekten auch externe Rahmenbedingungen (Wartungsvorschriften des Her-
116
Das R/3-System
stellers, rechtliche Vorschriften und Umweltschutzbestimmungen) in die Betrachtungen
einbezogen werden. Durch Auswahl einer Wartungsstrategie werden allgemeine Terminierungsregeln festgelegt. In der Detailplanung wird anschliessend festgelegt, welche
technischen Objekte gewartet werden sollen und wie die Wartung zu erfolgen hat
(Zuordnung zu Instandhaltungsarbeitsplänen).
Durch eine Instandhaltungsmeldung wird der augenblickliche Zustand eines technischen Objekts beschrieben. Darunter fallen insbesondere Störmeldungen und Tätigkeitsmeldungen im Rahmen der Wartungsarbeiten und periodischen Überprüfungen
(z.B. Inspektionsbefund). Daneben können über sogenannte Instandhaltungsanforderungen vor allem Ersatzinvestitionen ausgelöst werden, ohne dass eine eigentliche Störung zwingend vorliegen muss. Diese stellen in den meisten Fällen den Auslöser für die
Instandhaltungsauftragsabwicklung (PM-WOC) dar.
Instandhaltungsaufträge dienen zur Planung, Durchführung und Abrechnung von Instandhaltungsarbeiten. Ausgelöst werden diese in der Regel durch eine Instandhaltungsmeldung. Bei der Planung von IH-Aufträgen wird der Termin, das genaue Vorgehen (Instandhaltungsarbeitsplan), die ausführenden Arbeitsplätze (auch Fremdvergabe
von Arbeiten), die benötigten Materialien und entsprechende Abrechnungsregeln festgelegt. Während der Durchführung können Arbeitspapiere erstellt werden, Material
eingeplant und vom Lager entnommen und entsprechende Rückmeldungen verfasst
werden. Schlussendlich wird der IH-Auftrag abgerechnet und die entstandenen Kosten
ermittelt.
Ebenfalls im Rahmen der Instandhaltung können zu den einzelnen Anlagen verschiedene Messwerte ermittelt und Zählerstände erfasst werden. Diese dienen zur Überwachung des Anlagengebrauchs und stellen ein wichtiges Instrumentarium für die Planung
von Instandhaltungsmassnahmen dar.
Ebenfalls von grosser Bedeutung für die Instandhaltungsplanung ist die Historie der im
Zeitablauf über eine Anlage gesammelten Daten. Durch die Erfassung der sogenannten
Instandhaltungshistorie werden verschiedene Ziele verfolgt: Auf der einen Seite kann
einer allfällig vorhandenen Nachweispflicht über die Wartung der Anlagen nachge117
Das R/3-System
kommen werden und auf der anderen Seite bieten diese Informationen die Grundlage
sowohl für Ersatzinvestitionsentscheide als auch für die Wiederholungsplanung von
Wartungsarbeiten.
Für die Instandhaltung der Geräte und Anlagen von Kunden dient das Service-Management (PM-SMA). Diese Anwendung unterstützt die Bearbeitung von Servicemeldungen,
die Abwicklung von Serviceaufträgen und deren Abrechnung resp. Fakturierung. Die
Servicedienstleistungen können auch losgelöst von einem gelieferten Produkt abgewikkelt werden. Damit wird dem allgemeinen Trend zum Outsourcing von Servicedienstleistungen Rechnung getragen.
Grundlage für die Abwicklung von Service-Leistungen bilden die zu den einzelnen Service-Objekten erfassten Daten. Der Verschiedenheit der einzelnen Service-Objekte
(z.B. Kopiergeräte, Eisenbahnlokomotiven oder Kraftwerke) wird durch unterschiedliche
Erfassungsmöglichkeiten der Stammdaten Rechnung getragen. Dabei können diese
entweder als Material, als Equipment oder als technischer Platz erfasst werden. Durch
die Erfassung von Stücklisten kann die Struktur eines Service-Objekts dargestellt werden. Die Einzelstücke von gleichartigen Materialien können über eine entsprechende
Seriennummernverwaltung unterschieden werden. Bei der eigentlichen Abwicklung der
Servicedienstleistungen stellt das R/3-System folgende Funktionen zur Verfügung:
• Garantieverwaltung
• Meldungsverarbeitung (Erfassung, Bearbeitung, Überwachung und Abschluss)
• Fakturierung des Serviceauftrags.
In der Garantieverwaltung wird zuerst die Garantieart (Herstellergarantie, Lieferantengarantie oder Kundengarantie) und die detaillierte Ausprägung der Gewährleistung (z.B.
Dauer, Umfang und Einschränkungen) festgelegt. Beim Eintreffen einer Kundenservicemeldung wird die Meldungsverarbeitung angestossen. Bei der Meldungserfassung werden die Objekt- und Partnerdaten, die Problembeschreibung sowie die Dringlichkeit
resp. die Ausführungstermine aufgenommen. Im Rahmen der Meldungsverarbeitung
erfolgt eine Zuweisung der Meldung zu einer entsprechenden Massnahme (Technische
Rückmeldung, Einsatz eines Technikers, Versand eines Ersatzteils) und durch den Mel118
Das R/3-System
dungsabschluss wird die entsprechende Massnahme ausgelöst. Die allfällige Fakturierung eines Serviceauftrags wird durch eine Fakturaanforderung vorgemerkt. Während
der Bearbeitung des Serviceauftrags werden sämtliche Massnahmen durch Rückmeldungen dokumentiert und alle Kosten zum entsprechenden Objekt gesammelt. Anhand
dieser Informationen wird am Ende der Abwicklung eine detaillierte Rechnung erstellt.
Die im Rahmen von Instandhaltungsmassnahmen und Serviceleistungen erfassten Daten
können über das Instandhaltungsinformationssystem ausgewertetet werden. Dadurch
lassen sich die getroffenen Massnahmen besser überwachen und die entsprechenden
Leistungen können stetig optimiert werden. Durch die Verbesserung der Instandhaltungsmassnahmen und Serviceleistungen wird ein wesentlicher Beitrag sowohl zur Erhöhung der Qualität von Produkten und Dienstleistungen als auch zur Kundenzufriedenheit geleistet.
3.3.4.7 PS - Projektsystem130
Das Projektsystem (PS) ist Bestandteil des Logistiksystems und bezweckt die Unterstützung der Projektdurchführung. Projekte weichen von Alltagsaufgaben ab und besitzen
ganz besondere Merkmale131:
• Klare Abgrenzung der Thematik: Zielvorgaben, Rahmenbedingungen
• Einzigartigkeit
• Zeitliche Begrenzung: Klar definierter Anfang und Ende (Termindruck)
• Neuartigkeit
• Komplexität
• Hohes Risiko: Technisch, wirtschaftlich, terminlich
• Kosten- und kapazitätsintensiv
• Hohe Qualitätsanforderungen
• Strategische Bedeutung: Grosse Bedeutung für die betroffene Unternehmung
130
131
Vgl. dazu SAP AG (1996a), Abschnitt: PS-Projektsystem; SAP AG (1994b).
Vgl. Litke (1995), S. 17.
119
Das R/3-System
Die Verschiedenheit der oben genannten Merkmale verdeutlicht die Komplexität der
Problemsituation. Projektmanagement ist eine sehr vielseitige Tätigkeit und kann nur
durch ein äusserst flexibles System angemessen unterstützt werden. Das PS-Modul des
R/3-Systems versucht diesen Anforderungen durch branchenneutrale Einsetzbarkeit und
Integration zu anderen R/3-Modulen (FI, CO, SD, MM, PP) gerecht zu werden und unterstützt z.B. folgende Projektarten:
• Forschungs- und Einzelprojekte
• Kundeneinzelfertigung
• Investitionsvorhaben
• EDV-Projekte.
Zur Unterstützung der Projektabwicklung in den oben genannten Bereichen stellt das
PS-Modul die in Abb. 3-23 dargestellten Komponenten zur Verfügung.
PS - Projektsystem
PSOPS
Projektstrukturierung
PSAPP
PSPLN
Projektplanung
PSEXE
PSIS
Projektrealisierung
Projektbudgetierung
Projektinformationssystem
Abb. 3-23: Komponenten des Projektsystems.
Grundvoraussetzung für ein Projekt sind präzis formulierte Zielsetzungen. Daneben
spielt die klare Projektstrukturierung eine massgebende Rolle für den Projekterfolg. In
diesem Zusammenhang ist insbesondere eine zweckmässige Ausbau- und Ablauforganisation wichtig. Zu den zentralen Projektstrukturen des PS-Moduls gehören:
120
Das R/3-System
• Projektstrukturpläne (Aufbauorganisation)
• Netzpläne (Ablauforganisation).
Durch Projektstrukturpläne (PSP) wird die Aufbauorganisation eines Projektes beschrieben. Diese sind für die Organisation und Steuerung eines Projektes von zentraler
Bedeutung. Die Ausprägung der hierarchischen Gliederung wird durch die vorgesehenen Aufgaben und durch die beteiligten Personen bestimmt.
Die Ablaufplanung wird anhand von Netzplänen festgelegt. Diese legen den zeitlichen
Ablauf und die vorgesehenen Tätigkeiten mit deren Abhängigkeiten fest. Die einzelnen
Aktivitäten sollten dabei klar abgegrenzten Phasen zugeordnet sein. Grob betrachtet
gliedert sich ein Projekt in die folgenden Phasen:
• Initialisierung (Idee, Zielsetzungen)
• Planung
• Durchführung
• Abschluss.
Auf der Basis einer neuen Idee oder aufgrund eines existierenden Problems erfolgt die
Inititalisierung eines neuen Projektes. Darauf aufbauend werden Zielsetzungen und
die existierenden Rahmenbedingungen formuliert.
Im Anschluss an die Initialisierungsphase findet die Projektplanung (PS-PLN) statt. Diese kann in eine Grob- und eine Detailplanung unterteilt sein. Bei der Planung erfolgt die
Festlegung der Aufbauorganisation und der Ecktermine im Rahmen der Projektdefinition. Anhand der PSP-Elemente werden die Aufgaben und Teilaufgaben beschrieben.
Diesen PSP-Elementen werden anschliessend konkrete Termine und Kosten zugeordnet. Netzpläne legen den Ablauf einzelner Aktivitäten inkl. Zuordnung der Ressourcen
(Arbeitskräfte, Materialien, Hilfsmittel und Dienstleistungen) fest. Der Netzplan muss
ebenfalls einem PSP-Element zugeordnet werden.
Nach der Planungsphase erfolgt die Genehmigung des Projekts. Diese gibt den Startschuss für die eigentliche Projektrealisierung (PS-EXE). Vor der Umsetzung des Projekts
werden die Plankosten als Budgetwerte in die PSP-Elemente übernommen. Diese bil121
Das R/3-System
den die Grundlage für die Projektbudgetierung (PS-APP) (Kosten- und Finanzmittelbudgetüberwachung). Während der Durchführung konzentrieren sich die Aktivitäten
des Projektmanagements vor allem auf die Überwachung des Projekts. Diese wird
grundsätzlich anhand der erfassten und ausgewerteten Rückmeldungen vorgenommen.
Das Projektmanagement-System überprüft laufend die Verfügbarkeit der für das Projekt
benötigten Ressourcen (Finanzielle Mittel, Arbeitskräfte, Material und Fertigungshilfsmittel) und stellt diese im Rahmen der Fortschrittsanalyse den erbrachten Leistungen
gegenüber.
Nach der Realisierung erfolgt mit der Abrechnung des Projektes der Projektabschluss.
Dabei werden alle angefallenen Kosten ermittelt und das veranschlagte Budget durch
Gegenbuchungen entlastet. Die Verteilung der Kosten wird anhand von festgelegten
Abrechnungsvorschriften (Aufteilungsregeln) vorgenommen und auf der Basis des Abrechnungsschemas abgewickelt. Die Kosten werden dabei den in den Aufteilungsregeln
festgelegten Empfängern (Kostenstelle, Projekt, Anlage, Sachkonto, Ergebnisobjekt) zugewiesen und für das Informationssystem verfügbar gemacht. Das PS-Informationssystem (PS-IS) unterstützt durch gezielte Auswertung der gesammelten Daten die
Überwachung und Steuerung von Projekten. Dabei werden folgende Informationen zur
Verfügung gestellt:
• Budget
• Kosten
• Finanzen
• Termine
• Ressourcen
• Fortschrittsanalyse.
Das PS-Informationssystem ist in die Bereiche Strukturen/Termine und Erlöse/Kosten/Finanzen gegliedert. Durch den Bereich Strukturen/Termine werden anhand der Selektion der Einzelobjekte (PSP-Elemente, Netzpläne etc.) deren Abhängigkeiten und hierarchische Beziehung dargestellt. Gleichzeitig erfolgt eine Ermittlung des aktuellen Status
122
Das R/3-System
der Einzelobjekte. Im Bereich Erlöse/Kosten/Finanzen kann entweder ein einzelnes
Projekt nach verschiedenen Kriterien (Strukturberichte, Kostenartenberichte, Einzelpostenverdichtung) ausgewertet werden oder die verfügbaren Daten mehrerer gleichartiger Projekte können in verdichteter Form dargestellt werden. Die für die Projektüberwachung notwendigen Information sind damit verfügbar, und die laufenden Projekte
lassen sich dadurch besser steuern.
3.3.5 Personal
Die Personalwirtschaftsmodule132 des R/3-Systems decken die Bereiche des betrieblichen Personalwesens breit ab. Dabei werden sowohl die gesetzlichen Anforderungen
der jeweiligen Länder als auch allgemeinwirtschaftliche Tendenzen wie der technische
Wandel und der damit verbundene steigende Bedarf an Fachkräften berücksichtigt. Ausserdem orientiert sich das System an den geltenden Datenschutz- und Datensicherungsbestimmungen und trägt den generell steigenden Anforderungen der Arbeitnehmer nach mehr Humanität am Arbeitsplatz Rechnung. Das Personalwesen ist in die
Module Personaladministration- und -abrechnung (PA) und Personalplanung und
-entwicklung (PD) unterteilt.
PA unterstützt sowohl den Personaladministrations- und -beschaffungprozess als auch
den ganzen Personalabrechnungsprozess (Zeitwirtschaft, Leistungslohn, Reisekosten
etc.). Die eigentliche Personalabrechnung ist stark auf die gesetzlichen Vorschriften des
jeweiligen Landes ausgerichtet. Das Schwergewicht dieser Aktivität liegt in der Berechnung des Entgelts pro Mitarbeiter und Periode unter Berücksichtigung der erfassten Arbeitszeiten und der vorgegebenen Leistungskomponenten.
PD umfasst die Bereiche Organisationsmanagment (Aufbauorganisation, Stellenbeschreibungen) und Veranstaltungsmanagement (Personalentwicklungsmassnahmen sowie Administration und Abrechnung von Veranstaltungen).
132
Vgl. dazu Wenzel (1995a), S. 531 ff.; SAP AG (1996a), Abschnitt: Personalplanung und -entwicklung
sowie Personaladministration und Abrechnung; SAP AG (1993c).
123
Das R/3-System
3.3.5.1 PA - Personaladministration und - abrechnung
Im Bereich der Personaladministration und -abrechnung wird ein Unternehmen mit
unzähligen gesetzlichen Vorschriften (z.B. Sozialversicherungsgesetzgebung oder Datenschutzvorschriften) konfrontiert. Diese können sowohl innerhalb eines Landes als auch
zwischen verschiedenen Ländern sehr unterschiedlich sein. Zusätzlich ist die Nachfrage
und das Angebot am Arbeitsmarkt durch allgemeinwirtschaftliche Veränderungen (z.B.
der technische Wandel und die damit verbundene erhöhte Nachfrage nach Fachkräften) grossen Schwankungen unterworfen. Flexibilität und Internationalität sind demzufolge unausweichliche Erfordernisse für ein konzernweit einsetzbares Informationssystem im Bereich des Personalwesens. Im R/3-System werden diese Grundanforderungen vorwiegend durch das Modul Personaladministration und -abrechnung (PA) abgedeckt. Dieses besteht aus den in Abb. 3-24 dargestellten Einzelkomponenten.
PA - Personaladministration und -abrechnung
PAPAD
Personaladministration
PAINW
PAAPP
Personalbeschaffung
PATRV
Leistungslohn
PATIM
PAPAY
Reisekosten
Personalzeitwirtschaft
Personalabrechnung
Abb. 3-24: Komponenten der Personaladministration und -abrechnung.
Die Personaladministration (PA-PAD) umfasst primär die Erfassung, Verwaltung und
Auswertung der mitarbeiterspezifischen Daten (Personalstammdatenverwaltung). Dabei
können die organisatorischen Verknüpfungen der Mitarbeiter abgebildet werden. Im
Rahmen der Personaldatenerfassung erfolgt parallel dazu die hierarchische Einordnung
des Mitarbeiters. Dieser wird zu einer für ihn geltenden Zeit-, Tarif- und Lohnartenstruktur zugeordnet. Durch sogenannte Personalmassnahmen wird sichergestellt, dass
124
Das R/3-System
für einen Personalvorgang (z.B. Einstellung, Beförderung oder Kündigung eines Mitarbeiters) sämtliche notwendigen Daten (Infotypen) erfasst werden und gleichzeitig eine
Historie der Bewegungen geführt wird. Durch die Zuweisung eines Infotyps zu einem
bestimmten Gültigkeitszeitraum wird sichergestellt, dass die Vergangenheitsdaten vorhanden bleiben und sich für jeden Zeitpunkt in der Vergangenheit können die gültigen
Daten ermitteln lassen. Darüber hinaus können die Personaldaten durch umfangreiche
Reportingmöglichkeiten bedürfnisgerecht ausgewertet werden. Ein Berichtsbaum fasst
die wichtigsten Reports zusammen.
Die Personalbeschaffung (PA-APP) besteht aus den Funktionen Ermittlung des Personalbedarfs, Personalwerbung sowie Verwaltung und Auswahl der Bewerber. Die Bestimmung des Personalbedarfs erfolgt entweder durch die manuelle Erfassung von Vakanzen oder anhand der aus der Personalplanung resultierenden und gleichzeitig als
"vakant" bezeichneten Planstellen.
In der Personalwerbung erfolgt die Verwaltung der Stellenausschreibungen (Medium,
Ausschreibungstext etc.) und die Zuordnung der Bewerber zu einer konkreten Ausschreibung. Gleichzeitig generiert das System einen Vorschlag für eine mögliche Vakanzenzuordnung. Diese kann gegebenenfalls noch geändert werden. Eine allfällige Zuweisung von Spontanbewerbern zu Vakanzen muss manuell erfolgen. Anhand der Verknüpfung zwischen Ausschreibung und Bewerber kann die Effektivität der verwendeten
Medien und anderen Personalbeschaffungsinstrumente beurteilt werden.
Durch die Personalzeitwirtschaft (PA-TIM) werden die An- und Abwesenheitszeiten
der Mitarbeiter erfasst und anderen R/3-Komponenten (Lohn- und Gehaltsabrechnung,
Verrechnung von Arbeitsleistungen in CO etc.) in ausgewerteter Form zur Verfügung
gestellt. Dabei werden verschiedene Arbeitszeitmodelle (z.B. Gleitzeit oder Schichtbetrieb) und viele Sonderformen (z.B. Bereitschaftszeiten, Dienstreisen oder Sonn- und
Feiertagsarbeit) für die Abrechnung der Leistungen unterstützt. Eine der wichtigsten
Funktionen der Zeitwirtschaft stellt die Auswertung der Zeitdaten dar. Diese erfolgt anhand der Erfassung von unternehmensspezifischen Regeln im Customizing.
125
Das R/3-System
Die Komponente Leistungslohn (PA-INW) dient zur Verarbeitung von Akkord-, Prämien- und Zeitlöhnen. Die Leistungslohndaten werden anhand von Lohnscheinen manuell erfasst und können Einzelpersonen oder Personengruppen zugewiesen werden. Zusätzlich können die Leistungsdaten über spezifische Schnittstellen zu den Logistikmodulen PP, PM und PS automatisch aus den dort vorhandenen Rückmeldungen übernommen werden. Gleichzeitig mit der Erfassung werden die Lohnscheine periodenweise kumuliert, so dass z.B. der Stundensaldo jederzeit aufgerufen werden kann.
Die erfassten Lohnscheine stellen die Grundlage für die Lohn- und Gehaltsabrechnung
dar.
Eine weitere Komponente des HR-Systems deckt die Erfassung und Auswertung der
Reisekosten (PA-TRV) ab. Die Reisedaten können entweder zentral oder dezentral
(durch den Mitarbeiter) erfasst werden. Das System unterstützt verschiedene Erfassungsarten (Einzelerfassung, Schnellerfassung, Belegerfassung), welche auf die unterschiedlichen Reisetypen (Inland oder Auslandreise, ein- oder mehrtägige Reise) ausgerichtet
sind. In der Regel muss eine Genehmigung für eine Reise vorliegen. Dieses Genehmigungsverfahren wird durch eine entsprechende Funktion unterstützt. Für absolvierte
Reisen mit dem Status "genehmigt" kann anschliessend die Abrechnung und Auswertung
der Reisedaten durchgeführt werden. Diese erfolgt nach den länderspezifischen Vorschriften. Zur Auszahlung der Spesenentschädigung werden die Daten entweder an die
Finanzbuchhaltung (FI) oder an die Lohn- und Gehaltsabrechnung (HR-PA) weitergeleitet. Sämtliche Daten können nach Abschluss der Abrechnung optisch archiviert werden.
Die eigentliche Personalabrechnung (PA-PAY) ist stark auf die gesetzlichen Vorschriften
den jeweiligen Landes ausgerichtet. Das Schwergewicht dieser Aktivität liegt in der Berechnung des Entgelts pro Mitarbeiter und Periode. Die Abrechnung basiert auf dem
Bruttogehalt, welches sich aus einer oder mehreren Lohn- und Gehaltsarten zusammensetzt. Von diesem Bruttogehalt werden allfällige Steuern und Sozialversicherungsbeiträge abgezogen. Das daraus resultierende Nettogehalt stellt das Entgelt dar, welches dem
Arbeitnehmer pro Periode ausbezahlt wird. Die Berechnung des Nettogehalts kann in
126
Das R/3-System
einem Abrechnungslauf simuliert werden. Beim Feststellen von fehlerhaften Stammdaten (z.B. unrichtig erfasste Lohnarten) können diese noch korrigiert werden (Rückrechnung). Danach erfolgt der definitive Abrechnungslauf. Damit ist die Lohn- und Gehaltsabrechnung für eine Periode abgeschlossen, und es können die notwendigen Entgeltsnachweise (Lohn- und Gehaltsabrechnungsbelege) ausgedruckt sowie die Zahlungsanweisungen vorbereitet werden. Zur Überweisung der Zahlungen stehen verschiedene Verfahren zur Auswahl. Entweder kann ein Überweisungsträger für den Datenaustausch mit der Bank erstellt werden (DTA-Verfahren) oder die notwendigen
Überweisungformulare können ausgedruckt und in Papierform übersandt werden. Nach
der Lohn- und Gehaltsüberweisung erfolgt die Auswertung der Abrechnungsergebnisse.
Im Rahmen dieser Aktivität werden Auswertungsdaten (kumulierte Werte) für die Abrechnung der verschiedenen Sozialversicherungen und für die Weiterleitung der Lohnabrechnungsdaten an FI und CO erzeugt. Mit der Zuführung der buchungsrelevanten
Informationen ist die Personalabrechnung abgeschlossen.
3.3.5.2 PD - Personalplanung und -entwicklung
Der zweite Hauptbereich der Personalwirtschaft konzentriert sich auf die Personalplanung und -entwicklung. Dieser umfasst die in Abb. 3-25 dargestellten Hauptanwendungsbereiche.
PD - Personalplanung und -entwicklung
PDOM
OrganisationsQualitätsmanagement
zeugnisse
PDSCM
VeranstaltungsQualitätsmanagement
meldungen
Abb. 3-25: Komponenten der Personalplanung und -entwicklung.
Im Rahmen des Organisationsmanagements (PD-OM) wird die Aufbauorganisation
eines Unternehmens beschrieben. Da sich diese im Zeitablauf ändert, muss eine ent127
Das R/3-System
sprechende Historie geführt werden, damit für jeden Zeitpunkt in der Vergangenheit, in
der Gegenwart oder in der Zukunft die jeweils gültige Aufbauorganisation bestimmt
werden kann. Zusätzlich zur Historienführung können verschiedene Planvarianten der
Aufbauorganisation verwaltet werden. Die aktuell gültige Organisationsstruktur stellt
dabei die jeweils aktive Planvariante dar. Die Darstellung der Aufbauorganisation erfolgt
durch Objekte (Grundinformationselemente). Darunter fallen z.B. Organisationseinheiten, Stellen, Planstellen, Arbeitsplätze und Aufgaben. Zu den jeweiligen Objekten kann
ein Status (aktiv, geplant etc.) und ein Gültigkeitszeitraum zugeordnet werden. Die einzelnen Objekte können nun zur Beschreibung der Aufbauorganisation herangezogen
werden. Es werden folgende Strukturierungsmöglichkeiten unterschieden:
• Organisationsstruktur
• Organigramm oder Matrixorganisation
• Stellenplan
• Arbeitsplatzkatalog
• Aufgabenkatalog.
Die Struktur entsteht durch Darstellung der Abhängigkeiten mittels Verknüpfung der
Einzelobjekte. Auf diese Weise wird z.B. ein Arbeitsplatz oder eine Planstelle zu einer
Organisationseinheit oder eine Aufgabe zu einer Stelle zugeordnet. Parallel zur Beschreibung der Aufbauorganisation können über Tätigkeitsprofile und zugehörigen Aktivitäten die notwendigen Berechtigungen eines R/3-Anwenders festgelegt werden. Zur
übersichtlichen Darstellung und Bearbeitung der Aufbauorganisation dient die Strukturgrafik, durch welche die Verknüpfungen der Einzelobjekte dargestellt und verschoben
werden können. Daneben können weiterführende Auswertungen mit dem Personalinformationssystem durchgeführt werden.
Das Veranstaltungsmanagement (PD-SCM) dient zur Planung, administrativen Durchführung und Abrechnung von Veranstaltungen. Unter Veranstaltungen sind sowohl Ausund Weiterbildungsveranstaltungen als auch Veranstaltungen zur Förderung des Informationsaustausches zu verstehen. Teilnehmer dieser Veranstaltungen können entweder
die eigenen Mitarbeiter oder Personen (Bewerber, Mitarbeiter eines Geschäftspartners
128
Das R/3-System
oder einer gänzlich fremden Firma) sein. Im Rahmen der Vorbereitung und Durchführung einer Veranstaltung unterstützt das System folgende Tätigkeiten:
• Anlegen und Planen von Veranstaltungen (Veranstalter, Ort, Ablauf etc.)
• Bestimmung der Veranstaltungskosten und Ermitteln eines Preisvorschlags
• Vormerken und Buchen von Teilnahmen
• Umbuchung und Stornierung von Teilnahmen
• Fixieren oder Absagen einer Veranstaltung
• Abrechnung oder Verrechnung einer Veranstaltung.
Durch das Organisationsmanagement werden die Voraussetzungen für die Personalplanung, d.h. für die Ermittlung des Personalbedarfs geschaffen. Das Veranstaltungsmanagement dient primär zur Unterstützung der Veranstaltungsabwicklung. Gleichzeitig können Ausbildungsbedürfnisse der eigenen Mitarbeiter erfasst und bei der Planung
von Ausbildungskursen berücksichtigt werden. Ausserdem besteht die Möglichkeit
durch Auswertung der besuchten Veranstaltungen eine Kontrolle über den Ausbildungsstand der eigenen Mitarbeiter zu führen. Dadurch sind auch die Belange der Personalentwicklung abgedeckt.
129
Das R/3-System
3.3.6 CA - Anwendungsübergreifende Funktionen
3.3.6.1 WF - Workflow
Während sich SAP Business Workflow auf die Verkettung von Vorgängen konzentriert,
unterstützen die in diesem Abschnitt diskutierten Werkzeuge vor allem den dokumentenbasierten Workflow, d.h. die Automatisierung und Beschleunigung des Dokumentenflusses. Dieses Bestreben wird durch folgende Funktionen unterstützt
• SAPoffice Grundfunktionen
• Die IDoc-Schnittstelle für den elektronischen Datenaustausch (EDI)
• SAP ArchiveLink
• Nachrichtensteuerung.
SAPoffice ist ein elektronisches Mail- und Ablagesystem für das Versenden, Empfangen
und Verwalten von Informationen. Diese Informationen können entweder innerhalb des
Systems (an andere Benutzer) oder über entsprechende Kommunikationsschnittstellen
(X.400, X.500 und Internet) auch ausserhalb verschickt werden. Der Kern des EmailSystems stellt der elektronische Eingangskorb (Universal Inbox) dar. Neben normalen
Textdokumenten (SAPoffice-Dokumente) kann der Eingangskorb in einer Worklist auch
spezielle Workflow-Objekte (Workitems) verwalten (vgl. SAP Business Workflow). Darunter fallen z.B. zu erledigende Tätigkeiten. Für diese Objekte existieren zusätzliche
Möglichkeiten für die Steuerung der Workflow-Prozesse (vgl. Nachrichtensteuerung).
Durch ein mit dem Email-System verbundenes Ablagesystem lassen sich die empfangenen und versendeten Dokumente in Mappen verwalten. Dabei wird zwischen persönlichen und allgemeinen Ablagen unterschieden. Letztere ermöglichen den gemeinsamen
Zugriff der Mitglieder einer Arbeitsgruppe auf die für die Arbeit relevanten Dokumente.
Über Verteilerlisten kann ein vorher definierter Personenkreis angesprochen werden
und zu erledigende Arbeiten können dadurch weitergeleitet und deren Erledigung
überwacht werden. Zur Bearbeitung der Dokumente können neben den im R/3-System
vorhandenen Werkzeugen auch systemfremde Applikationen (z.B. Word oder Excel)
eingesetzt werden.
130
Das R/3-System
Für den elektronischen Datenaustausch (EDI) ist im R/3-System die sogenannte IDocSchnittstelle (IDoc=Intermediate Document) vorgesehen. Diese Schnittstelle konvertiert für den elektronischen Datenaustausch genormte Dokumente gemäss den gängigsten EDI-Standards und ermöglicht damit den koordinierten Datenaustausch (inkl. Eingangs- und Ausgangsbearbeitung) mit verschiedenen Geschäftspartnern. Neben der herkömmliche Papierschnittstelle und der integrierten Fax-Übermittlung bildet die EDISchnittstelle ein wertvolles Instrument zur raschen Übermittlung von Dokumenten.
In Ergänzung zu den übrigen Komponenten bietet SAP-ArchiveLink die Möglichkeit,
Dokumente in einem angekoppelten optisches Archivierungssystem abzulegen. ArchiveLink übernimmt im wesentlichen die Funktion einer Schnittstelle zwischen R/3 und
Archivierungssystemen von Fremdanbietern. Dabei wird sowohl der Austausch von maschinell bearbeitbaren Dokumenten (Coded Information) als auch von eingehenden
Originalbelegen unterstützt. Letztere müssen eingescannt werden und können nur in
Form von Rasterbildern (Non Coded Information) abgelegt werden. Die Zuordnung der
archiverten Dokumente zu den entsprechenden R/3-Funktionen ist über Verknüpfungstabellen festgelegt. Dadurch können ein- und ausgehende Dokumente zugeordnet
und jederzeit aufgerufen werden. Die Kommunikation mit dem Archivserver erfolgt via
Remote Function Call (RFC). Zusätzlich ermöglicht ArchiveLink die Anbindung von Dokument-Viewern und Scan-Softwareprodukten über Industriestandardschnittstellen
(OLE und AppleScript). Durch die direkte Verknüpfung der Geschäftsprozesse mit den
zugehörigen Originaldokumenten sind jederzeit alle notwendigen Informationen rasch
verfügbar und einzelne Arbeitsschritte können dadurch erheblich vereinfacht und beschleunigt werden.
Die Nachrichtensteuerung dient zum automatisierten Austausch von Informationen
zwischen verschiedenen Partnern. Zusätzlich kann beim Eintreffen einer Information
eine Folgeverarbeitung angestossen werden. Die Steuerung erfolgt durch Regeln, welche über Tabellen verwaltet und den entsprechenden Geschäftsprozessen zugeordnet
131
Das R/3-System
werden. Zur Ausformulierung der Regeln kann die Programmiersprache ABAP/4133 verwendet werden. Damit lassen sich bei Bedarf auch sehr komplexe Regeln abbilden.
Beim Eintreffen einer Nachricht (z.B. Auftragserteilung eines Kunden) werden durch das
Regelwerk Nachrichtenvorschläge (z.B. Auftragsbestätigung) erzeugt. Diese können anschliessend über ein Verarbeitungsprogramm (Druck, Fax, Mail, EDI, CPI-C oder Workflow-Ereignis) an den entsprechenden Adressaten weitergeleitet werden. Durch diese
Steuerungsmöglichkeit des Informationsflusses können Geschäftsprozesse besser integriert werden und einzelne Bearbeitungsschritte schneller und zuverlässiger abgewickelt
werden.
3.3.6.2 Weitere anwendungsübergreifende Funktionen
Neben den bereits dargestellten anwendungsübergreifenden Werkzeugen (Cross Applications) runden weitere Teilkomponenten die Funktionalität des R/3-Systems ab. Zu
den wichtigsten Funktionen dieser Kategorie gehören folgende Anwendungsbereiche:
• Klassifizierungssystem
• Dokumentenverwaltungssystem
• Dokumentationswerkzeuge
• CAD-Integration
• ALE-Konzept
• BAPIs
• Schnittstellen zu Fremdsystemen.
133
ABAP/4 (Advanced Business Application Programming der 4. Generation) bezeichnet die Programmiersprache, mit welcher Erweiterungen zum R/3-System geschrieben werden können.
132
Das R/3-System
Das Klassifizierungssystem in R/3 hat die Aufgabe, beliebigen Objekten Merkmale zuzuordnen und diese dadurch in Gruppen zusammenzufassen. Diese Klassifizierung bezweckt vor allem das rasche Auffinden einzelner Objekte, indem bei einer Suche gleiche oder ähnliche Objekte aufgrund der Zugehörigkeit zu einer Klasse zusätzlich aufgeführt werden und damit das gesuchte Objekt möglichst schnell aufgefunden wird.
Die hohen Anforderungen an die Qualität und der steigende Komplexitätsgrad der hergestellten Produkte erfordern auch eine zuverlässige Verwaltung der für die Herstellung
und den Verkauf benötigten Dokumente. Dieser Anspruch wird von R/3 durch ein integriertes Dokumentenverwaltungssystem (DVS) gerecht. Dieses erlaubt dem Anwender
wichtige Dokumente unternehmensweit bereitzustellen und mit anderen R/3-Objekten
(z.B. Materialstammsatz oder Fertigungshilfmittel) zur verknüpfen. Zudem unterstützt
das DVS den Herstellungsprozess und die Freigabe einzelner Dokumente oder ganzer
Dokumenthierarchien (Dokumentenstückliste). Durch die Integration des DVS mit anderen Anwendungsbereichen des R/3-Systems (z.B. ArchiveLink, Klassifizierungssystem,
SAP Business Workflow oder Änderungsdienst) hat jeder Anwender schnellen Zugriff
auf die aktuell gültigen Dokumente und redundante und inkonsistente Datenbestände
können dadurch verhindert werden.
Durch verschiedene Dokumentationswerkzeuge können die im R/3-System vorhandenen Dokumentationen an unternehmensspezifische Bedürfnisse angepasst und erweitert
werden. Die Online-Dokumentation des R/3-Systems, welche mit der F1-Taste aufgerufen werden kann, lässt sich in der Dokumentationsdatenbank beliebig ändern oder
erweitern. Bei Erweiterung der SAP-eigenen Dokumentation bleiben kundeneigene Erweiterungen nach einem Release-Wechsel erhalten. Erfolgt hingegen eine Änderung der
SAP-Original-Dokumentation, dann gehen alle Änderungen nach einem ReleaseWechsel verloren. Die Dokumentationstexte können dabei in allen unterstützten Sprachen gepflegt werden. Eine weitere Möglichkeit besteht durch Anlage von eigenen Online-Dokumentationen. Diese haben eine hypertextähnliche Struktur (analog dem Einführungsleitfaden). Grundsätzlich ist eine solche Dokumentation hierarchisch gegliedert
und bietet zusätzlich die Möglichkeit, an Knoten Verknüpfungen zu anderen Textstellen
133
Das R/3-System
zu definieren. Durch diese Werkzeuge kann die Abwicklung der eigenen Geschäftsprozesse für den Anwender im System dokumentiert werden. Gleichzeitig können eigene
Dokumentationen z.B. Vorgehensmodelle für das Projektmanagement im R/3-System
abgebildet werden.
Die CAD-Schnittstelle (CAD = Computer Aided Design) stellt keine Besonderheit,
sondern eher eine unabdingbare Notwendigkeit für ein integriertes System dar. Die
Möglichkeit der Integration von CAD-Anwendungen in das R/3-System wird durch eine
logische Verbindung zwischen betriebswirtschaftlichen und technischen Standardanwendungen hergestellt. Beide Bereiche können davon profitieren. Der Konstrukteur
kann beispielsweise auf Datenbestände im PPS-System zugreifen und diese Erkenntnisse
für seine Arbeit nutzen. Auf der Gegenseite können Entwicklungen durch eine zentrale
Datenhaltung überwacht und Parallelentwicklungen verhindert werden. Durch den gegenseitigen Datenaustausch lassen sich Datenredundanzen und -inkonsistenzen vermeiden. Neben der Konstruktion lässt sich die CAD-Schnittstelle auch für die Integration
von geographischen Informationssystemen (GIS), z.B. für die Abbildung von Leitungsnetzen in der Versorgungswirtschaft verwenden.
Hinter dem ALE-Konzept verbirgt sich die Möglichkeit, allgemeine Entwicklungstendenzen der letzten Jahre im betriebswirtschaftlichen Umfeld, wie z.B. Lean Production oder
Dezentralisierung, beim Wandel eines Unternehmens voll zum Tragen zu bringen. ALE
(Application Link Enabling) schafft die Voraussetzung für die Koppelung verschiedener
Systeme über die Anwendungsgrenzen hinweg (vgl. Abb. 3-26).
134
Das R/3-System
SDSHP
ALE-Szenarien
PP
MM
R/3
3.X
synchron / asynchron
SDORD
FI
R/3
3.X
RFC
IDOCS
CO
R/2
Non
SAP
Abb. 3-26: ALE-Szenarien.
Durch den mit der ALE-Schnittstelle möglich gewordenen kontrollierten Datenaustausch
zwischen eigenständigen Systemen, kann eine konsistente Datenhaltung gewährleistet
werden. Die vielfach notwendige geographische Verteilung oder die Verselbständigung
einzelner Unternehmensbereiche (z.B. Produktion in einem Billiglohnland und Vertrieb
sowie Forschung & Entwicklung in einem High-Tech-Land) lässt sich dadurch ohne Reibungsverluste für die eingesetzten Informationssysteme realisieren. Der Datenaustausch
zwischen den gekoppelten Systemen erfolgt über synchrone und asynchrone Kommunikation. Im Vordergrund steht die Verknüpfung verschiedener R/2- und/oder R/3Systeme. Daneben besteht auch die Möglichkeit der Koppelung von einem oder mehreren Fremdsystemen mit R/3. Die Definition einer zwar proprietären, aber zumindest
einheitlichen Schnittstelle (ALE) ist zwar ein kleiner aber immerhin doch sehr wichtiger
Schritt in Richtung Verwirklichung einer vollen Integration von Standardanwendungen
verschiedener Hersteller über das Netz.
135
Das R/3-System
Business Application Programming Interfaces (BAPIs)134 stellen in gewissem Sinn eine
Ergänzung resp. eine Erweiterung des ALE-Konzepts dar. BAPIs sind offene Programmschnittstellen für den Datenaustausch zwischen R/3 und anderen betriebswirtschaftlichen Anwendungssystemen. Durch die Möglichkeit der direkten Anbindung von Internet-Applikations-Komponenten (IACs) an das R/3-System können alle R/3-Funktionen,
für welche BAPIs definiert sind, direkt über das Inter- oder Intranet verfügbar gemacht
werden. Dadurch besteht beispielsweise die Möglichkeit, dass ein Kunde über Internet
bestimmte Produkte direkt bestellen oder deren Verfügbarkeit beim Lieferanten überprüfen kann. Für den Zugriff auf R/3 über unternehmensexterne (Internet) oder -interne
Netze (Intranet) stehen grundsätzlich die drei in Abb. 3-27 dargestellten Varianten zur
Verfügung.
1
2
HTTP
Server
HTTP
Server
R/3-Internet
Transaction Server
Electronic
Commerce
Applications
(3rd party)
R/3-System
R/3 Internet
Application
Components
SAP
Automation
FI
MM
BAPIS
PP
SD
3
Java, Visual Basic, C
R/3 Business Objects
Web Server System
PA
...
Abb. 3-27: Zugriffsmöglichkeiten auf R/3 über Intra-/Internet.135
Variante 1 stellt die am meisten standardisierte und daher einfachste Zugriffsmöglichkeit auf R/3 dar. Der Zugang erfolgt dabei über einen sogenannten R/3-Internet Tran-
134
135
Vgl. SAP AG (1996b), S. 1-11; Roggenkemper (1996), S. 1-19.
Vgl. Hantusch/Matzke/Pérez (1996), S. 88.
136
Das R/3-System
saction Server136. Die Electronic Commerce Applikationen befinden sich auf der Ebene
des R/3-Systems und werden auf der Basis von speziellen R/3 Internet Application
Components (Internet-Anwendungskomponenten) erstellt. In Variante 2 sind die Internet Commerce Applikationen ausserhalb des R/3-Systems angesiedelt. Die Kommunikation erfolgt über SAP-Automation137, wodurch ein direkter Zugriff auf R/3-Transaktionen ermöglicht wird. Bei den beiden genannten Varianten wird die Transaktionskonsistenz über die Schnittstellenprogramme sichergestellt. Variante 3 zeigt den Zugriff
einer eigenständigen Internet Commerce Applikation auf das R/3-System, welche z. B.
in Java, Visual Basic oder C geschrieben ist. Der Zugang erfolgt dabei direkt über BAPIs.
Dies hat den Nachteil, dass die Transaktionskonsistenz innerhalb der Eletronic Commerce Applikationen sichergestellt werden muss.
Abb. 3-28 veranschaulicht als Anwendungsbeispiel die notwendigen Komponenten und
Netzverbindungen für den Zugriff auf ein R/3-System über einen normalen WebBrowser (z.B. Netscape oder Internet Explorer) anhand der Internet-Transaction-ServerVariante.138
Web Server System
WAN
Firewall
R/3
Internet
Transaction
Server
HTTP
Server
Internet
Intranet
Internet user
R/3 System
Intranet user
R/3 Internet
Application
Components
BAPIS
FI
MM
PP
SD
PA
...
Abb. 3-28: Anbindung an R/3 über einen Internet Transaction Server.
136
137
138
Ab Release 3.1 verfügbar.
SAP-Automation ist ein Werkzeug für den vereinfachten Zugriff auf R/3-Funktionen über ein Frontend via RFC (vergleichbar mit anderen Screen Scraping Tools).
Vgl. Hantusch/Matzke/Pérez (1996), S. 89.
137
Das R/3-System
Für die rein unternehmensinterne Verwendung kann das Netz von aussen durch entsprechende Vorkehrungen (Firewalls) abgeschirmt werden. Die Kommunikation zwischen dem HTTP-Server139
und den im R/3-System vorhandenen Internet-
Anwendungskomponenten (Internet Application Components) wird durch den R/3 Internet Transaction Server gesteuert. Diese auf R/3-Ebene vorhandenen InternetAnwendungskomponenten ermöglichen Consumer-to-Business- (z.B. Serviceanforderungen von Endabnehmern), Business-to-Business- (z.B. Bestellungen oder Bestellstatusabfragen von Kunden) und Intranet-Transaktionen (z.B. interne Stellenausschreibung
und Mitarbeiterrekrutierung). Die Möglichkeit der Nutzung von R/3-Funktionen über
das Netz wird dabei nur über das Vorhandensein von entsprechenden BAPIs beschränkt. Reicht der verfügbare Spielraum nicht aus, muss entweder ein eigenes BAPI
erstellt oder der Weg über SAP-Automation (Variante 2; vgl. Abb. 3-29) gewählt werden. Ferner existiert die in Variante 3 beschriebene Möglichkeit der WWW-Anbindung
von R/3 über Drittprodukte (z.B. HAHT140).
WAN
Web Server System
Firewall
HTTP
Server
Internet
Internet user
Intranet user
HTML
Generator
FI
Abb. 3-29: Anbindung an R/3 über SAP-Automation.
140
HTTP = Hypertext Transfer Protocol.
Vgl. www.haht.com.
138
Automation
Intranet
R/3 System
139
SAP
Electronic
Commerce
Apps.
MM
BAPIS
SD
IM
PA
Das R/3-System
Zusätzlich zu den genannten Anbindungsmöglichkeiten von Fremdsystemen an das R/3System existieren weitere, z.T. historisch gewachsene Schnittstellen zu Fremdsystemen. Darunter fallen auf der einen Seite eher allgemein verwendbare Schnittstellen,
wie die PDC-Schnittstelle, mit welcher Subsysteme auf der Basis von TCP/IP und RFC
mit dem R/3-System kommunizieren können (z.B. Betriebsdatenerfassungssysteme). Auf
der anderen Seite liegen Schnittstellen zu Fremdsystemen vor, welche für einen ganz
bestimmten Zweck vorgesehen sind. Zu diesen gehören beispielsweise folgende:
• QM-IDI Schnittstelle (Anbindung von Qualitätssicherungssystemen)
• PI-PCS Schnittstelle (Ankoppelung von Prozess-Steuerungssystemen)
• MM-MOB und WM-LSR Schnittstelle (Ankoppelung von Systemen für die mobile
Datenerfassung)
• ArchiveLink-Schnittstelle (Anbindung von elektronischen Archivierungssystemen)
Die dargestellten anwendungsübergreifenden Komponenten bieten eine sinnvolle
Ergänzung zur betriebswirtschaftlichen Grundfunktionalität des R/3-Systems und erhöhen dessen Flexibilität und Integrationsmöglichkeiten in erheblichem Ausmass.
3.3.7 IS- Branchenlösungen (Industry Solutions)
Viele Geschäftsprozesse sind in gleicher oder ähnlicher Weise in allen Branchen anzutreffen. In EMS werden diese Prozesse durch Integration einzelner Funktionen abgebildet. Durch Customizing können Standardprozesse in einem gewissen Spielraum an die
eigenen Bedürfnisse angepasst werden. Für viele Branchen reicht dieser Spielraum aus.
Daneben existieren aber Branchen mit besonderen Bedürfnissen, d.h. in gewissen Bereichen reicht die verfügbare Funktionalität nicht aus. Damit der hohe Integrationsgrad
des R/3-Systems für diese Branchen dennoch genutzt werden können, bietet SAP zusammen mit seinen Entwicklungspartnern verschiedene Branchenlösungen an. Diese
Branchenlösungen basieren auf den einzelnen Modulen des R/3-Systems. Für Bereiche,
in denen die vorhandene Funktionalität nicht ausreicht, werden die Standardmodule
(FI, CO, AM, MM, PP, SD etc.) durch massgeschneiderte Komponenten, sogenannte
139
Das R/3-System
Industry Solutions (IS) ergänzt. Zum Betrachtungszeitpunkt waren für folgende Branchen
Zusatzlösungen verfügbar:141
• Automobilindustrie (Automotive)
• Banken (Banking)
• Chemische Industrie (Chemicals)
• Konsumgüterindustrie (Consumer Products)
• Gesundheitswesen (Healthcare)
• High Tech- und Elektronikbranche (High Tech & Electronics)
• Versicherungen (Insurance)
• Oelindustrie (Oil & Gas)
• Pharmazeutische Industrie (Pharmaceuticals)
• Öffentliche Verwaltungen (Public Sector)
• Einzelhandel (Retail)
• Telekommunikation (Telecommunications)
• Versorgungswirtschaft (Utilities).
Durch die intensive Zusammenarbeit mit Software-Partnern ist davon auszugehen, dass
in Zukunft weitere Branchenlösungen auf den Markt kommen werden und damit das
Einsatzspektrum des R/3-Systems zusätzlich erweitert wird.
3.3.8 BC- Basissystem
3.3.8.1 Systemverwaltung
Die Systemverwaltung innerhalb des Basissystems (BC) bietet verschiedene Funktionen
zur Einrichtung eines neuen und zur Unterstützung von Betrieb und Wartung eines bestehenden R/3-Systems. Darunter fallen sehr unterschiedliche Werkzeuge, welche
nachfolgend im Überblick dargestellt sind:142
141
142
Vgl. z.B. Hernández (1997), S. 36.
Vgl. z.B. Hernández (1997), S. 165 ff.
140
Das R/3-System
• Systemüberwachung (CCMS143)
• Benutzereinrichtung und Berechtigungsvergabe
• Transportsystem (Transport von Systemeinstellungen bei einer Neuinstallation oder
einem Releasewechsel)
• Druckerkonfiguration
• Datenimport (Batch-Input)
• Werkzeuge zur Kommunikation mit anderen R/3-Systemen oder mit Fremdsystemen
auf der Basis von CPI-C und RFC
• Kommunikationsserver für EDI, Mail, und andere Telekommunikationsdienste
• Werkzeuge für die Formulargestaltung (SAPScript)
• Kopieren von Mandanten
• Archivierung von Anwendungsdaten.
3.3.8.2 Datenbankverwaltung
Die Datenbankverwaltung des R/3-Systems unterstützt mit verschiedenen Dienstprogrammen die Einrichtung und insbesondere die Administration (Reorganisation, Tuning,
Datensicherung) des Datenbanksystems, mit welchem die System- und Anwendungsdaten von R/3 verwaltet werden. Da die Möglichkeit besteht, verschiedene Datenbanksysteme (z.B. Oracle oder Informix) für die Datenhaltung einzusetzen, sind auch entsprechende Unterschiede in der Funktionalität der einzelnen Dienstprogramme vorhanden.
3.3.8.3 ABAP/4 Development Workbench
Die ABAP/4 Development Workbench ist eine komfortabel ausgebaute Entwicklungsumgebung, welche ursprünglich für die Entwicklung von Anpassungen und Erweiterungen für das R/3-System vorgesehen war. Mittlerweile wird die ABAP/4 Development
Workbench losgelöst vom R/3-System vermarktet und lässt sich für die Entwicklung von
143
CCMS (Computing Center Management System) ist ein System zur Laufzeitüberwachung zur vorsorglichen Diagnose von Problemen und zur Performanceoptimierung (z.B. Memorymanagement).
141
Das R/3-System
beliebigen betriebswirtschaftlichen Client/Server-Anwendungen einsetzen. Für diesen
Zweck stellt die Entwicklungsumgebung alle notwendigen Werkzeuge und Schnittstellen
zur Verfügung. Die folgende Auflistung gibt einen Überblick über die vorhandenen
Werkzeuge:144
• Verschiedene Werkzeuge zur Programmentwicklung (Programm-Editor, Funktionsbibliotheken, Screen Painter, Menü-Painter, Laufzeitanalysewerkzeug, Testhilfen)
• ABAP/4-Query (Erstellen von Reports)
• Programmierschnittstellen (z.B. Datenübernahme mit Batch Input)
• Externe Kommunikationsschnittstellen (z.B. RFC, API, OLE, SAP-Automation)
• SAP-Grafik (Werkzeug für die Erstellung von Geschäftsgrafiken)
• Data Dictionary (Datenbankstrukturverwaltung)
• Workbench Organizer (Organisatorische Unterstützung von Entwicklungsprojekten)
• Data Modeler (Datenmodellierung mit der SAP-SERM-Methode145)
• CATT146 (Testwerkzeug zur Überprüfung von Transaktionen, Systemmeldungen,
Datenfortschreibungen und Customizingeinstellungen)
• SAP Style-Guide (Leitfaden für die Oberflächengestaltung)
• Erweiterungskonzept (Leitfaden zur Verwendung von User Exits147)
• Tabellenpflege (Werkzeug zur Entwicklung von komfortablen Datenmanipulationsfunktionen)
• Zentrale Pflege- und Transportobjekte (Werkzeuge für die Zusammenfassung von
betriebswirtschaftlich zusammengehörigen Daten in entsprechenden Objekten für
die vereinfachte Pflege und den Transport dieser Daten)
• XXL-Listenexport148 (Werkzeug zur strukturierten Listenübergabe aus dem R/3System an PC-Anwendungen).
144
145
146
147
148
Vgl. Mende (1998), S. 21 ff.
SAP-SERM = Strukturiertes Entity Relationship-Modell der SAP.
CATT = Computer Aided Test Tool.
User Exits sind Programmschnittstellen innerhalb des R/3-Systems, an welche eigenentwickelte Anwendungen als Ersatz oder Ergänzung für R/3-Funktionen angebunden werden können.
XXL = Extended Export of Lists
142
Das R/3-System
3.3.8.4 Business Engineer
Der Business Engineer bezweckt die Unterstützung der Einführung des R/3-Systems mit
dem Ziel, bestehende Geschäftsprozesse zu optimieren oder grundlegend umzugestalten. Die Geschäftsprozessoptimierung bezieht sich nicht nur auf die Prozesse im industriellen Bereich sondern schliesst durch die Möglichkeit des Einsatzes von aktiven
Workflowkomponenten den Büro- und Verwaltungsbereich mit ein. Der Business Engineer umfasst folgende Komponenten:
• Vorgehensmodell
• Customizing Handbuch (IMG
• R/3 Referenzmodell.
• IDES-Demosystem
• SAP Business Workflow
Das Vorgehensmodell149 für die Einführung von R/3 bietet die notwendige Unterstützung für das Projektmanagement und liefert die Grundlage für das Customizing150 des
Systems. Es besteht aus 4 Hauptphasen und weiteren übergreifenden Anwendungsschritten:
• Phase-1: Organisation und Konzeption
• Phase-2: Detaillierung und Realisierung
• Phase-3: Produktionsvorbereitung
• Phase-4: Produktivbetrieb
• Projektadministration und Projektcontrolling
• Systemwartung und Release-Wechsel.
149
150
Vgl. Kap 4.3.
Unter Customizing wird die Anpassung des R/3-Systems an die betriebliche Aufbau- und Ablauforganisation mittels Parametersetzung verstanden.
143
Das R/3-System
Hauptsächlich unterstützt das Vorgehensmodell die Ersteinführung des R/3-Systems.
Daneben sind aber auch Empfehlungen für Releasewechsel und für die Einpflegung von
neuen Funktionen integriert. Die einzelnen für die jeweilige Projektphase notwendigen
Aktivitäten sind in einem Strukturplan dargestellt und darin ausführlich beschrieben.
Zusätzlich werden die einzelnen Einführungsphasen durch die verschiedenen Implementierungswerkzeuge des Customizings (Customizing-Handbuch, R/3-Referenzmodell)
unterstützt.
Der Einführungsleitfaden (Implementation Guide; IMG) liefert in strukturierter Form
detaillierte Hinweise für das Customizing des R/3-Systems. Für jedes Einführungsprojekt
kann ein auf die Erfordernisse zugeschnittener Einführungsleitfaden generiert werden.
Zusätzlich beinhaltet dieses Werkzeug Funktionen für die Projektsteuerung und -dokumentation.
Das R/3-Referenzmodell beschreibt in graphischer Form den Aufbau und die Funktionsweise des R/3-Systems. Die Darstellung erfolgt entweder über eine im R/3-System
integrierte Navigationskomponente (Business Navigator) oder über Zusatzwerkzeuge
(z.B. ARIS-Toolset), mit welchem das Referenzmodell auch losgelöst vom R/3-System
betrachtet werden kann.
Das IDES-Demosystem (IDES = International Demo and Education System) wird als
integrierender Bestandteil von R/3 ausgeliefert und bezweckt die Darstellung der Funktionsvielfalt des Systems. IDES stellt ein voll funktionsfähiges Demosystem für die Evaluation, die Einführungsunterstützung und Schulung des R/3-Systems dar. In der Evaluationsphase wird durch transparente Darstellung der verschiedenen Funktionen der Vergleich mit anderen Produkten erleichtert. Während der Einführung steht die IDESDatenbank als Ideenquelle für die Implementierung der abzubildenden Geschäftsprozesse zur Verfügung. Gleichzeitig existiert eine einheitliche Basis für die Schulung der
Projektmitglieder. Die während den Schulungsveranstaltungen verwendeten Beispiele
können in einer späteren Phase nachvollzogen und im Detail analysiert werden. Die
Internationalität der IDES-Datenbank lässt auch die Möglichkeit offen, länderspezifische
Bedürfnisse in einer realen Umgebung zu überprüfen. Durch die konsequente Verwen-
144
Das R/3-System
dung des Demosystems wird die Einarbeitung in das System erleichtert und damit der
Einführungsaufwand von R/3 reduziert.
Mit dem SAP Business Workflow151 stehen verschiedene Komponenten zur Optimierung und Automatisierung von Geschäftsprozessen zur Verfügung. Während sich die
Bestrebungen in der Vergangenheit vor allem auf Produktivitätssteigerungen im Fertigungsbereich beschränkt haben, bezieht sich das Workflow-Management primär auf die
Optimierung von Büro- und Verwaltungsprozessen. Im letztgenannten Bereich sind
durch die vielerorts vorhandenen langen Transport- und Liegezeiten bei der Aufgabenerledigung, sowie die mangelnde Prozesstransparenz und der oft erschwerliche Zugriff auf die vorhandenen Archive (Papier- und Mikrofilmarchive) erhebliche Effizienzsteigerungspotentiale zu vermuten. Bisher haben sich Verbesserungen von Büro- und
Verwaltungsprozessen schwergewichtig auf die zusätzliche Technisierung der einzelnen
Arbeitsplätze beschränkt, was aber im Hinblick auf die Optimierung von zusammenhängenden Prozessen keine nennenswerten Vorteile gebracht hat.
151
Vgl. dazu Fritz/Zuck (1996), S. 63 ff.; Wenzel (1995a), S. 575 ff.; SAP AG (1996a), Abschnitt: SAP
Business Workflow; SAP AG (1995b).
145
Das R/3-System
WorkflowDefinition
WorkflowSteuerung
WorkflowÜberwachung
Definitionswerkzeuge
Laufzeitwerkzeuge
Reporting
- Objekt-Repository
- AufbauOrganisation
- Ereigniserzeugung
- integrierter
Eingangskorb
- Workflow-Ausgang
- Workitem-Analyse
- Workload-Analyse
- Aufgaben-Analyse
Ziel: Optimierung von Büro- und Verwaltungsprozessen
Abb. 3-30: Komponenten von SAP Business Workflow.
SAP Business Workflow zielt auf dieses Defizit ab und ermöglicht durch die aktive Verknüpfung von einzelnen Arbeitsschritten und die flexible Abbildung organisatorischer
Strukturen die Realisierung von erheblichen Verbesserungen. Zur Gewährleistung eines
ganzheitlichen Workflowmanagement-Konzepts stehen die folgenden Werkzeuge für
die Definition, die Steuerung und Überwachung von Geschäftsprozessen zur Verfügung:
• Workflow-Definition (Workflow-Editor)
• Laufzeitsystem (Workflow-, Workitem- und Ereignismanager)
• Informationssystem zur Überwachung einzelner Arbeitsschritte (Workitems) und zur
Diagnose und Fehlerfindung innerhalb eines durchgängigen Prozesses
Die Workflow-Definition wird über einen graphischen Editor vorgenommen. Dabei
können die Kontroll- und Datenflüsse zwischen den einzelnen Bearbeitungsschritten
146
Das R/3-System
festgelegt werden. Über die Definition von entsprechenden Verknüpfungen erfolgt die
Zuordnung der für die Bearbeitung notwendigen Dokumente.
Das Laufzeitsystem steuert über Ereignisse (=Zustandsänderungen eines Objekts z.B.
das Erreichen einer Terminschranke oder auch das Eintreffen einer Nachricht von ausserhalb des Systems) die Auslösung von Folgeschritten. Die weiteren Bearbeitungsschritte werden anschliessend entweder automatisch abgewickelt oder in Form einer
Anweisung einem zuständigen Bearbeiter zugeteilt. Die Zuweisung der Aufgaben erfolgt
über einen elektronischen Eingangskorb (Universal Inbox). Über diesen werden alle zu
bearbeitenden Tätigkeiten (Workitems) in einer Pendenzenliste (Worklist) verwaltet. Der
elektronische Eingangskorb ist Bestandteil des Email-Systems. Die zugewiesenen Workitems werden durch eingehende Nachrichten dargestellt, welche der Klasse WF
(Workflow) zugeordnet sind und im Unterschied zu den herkömmlichen Mailnachrichten über spezielle Eigenschaften verfügen. Ein Workitem beinhaltet alle notwendigen
Informationen zur Erledigung einer Aufgabe. Gleichzeitig können Anwendungsobjekte
(z.B. bestimmte R/3-Transaktionen) für die Folgeverarbeitung mit dem Workitem verbunden werden. Parallel zur Bearbeitung der Aufgaben wird der Status (z.B. wartend,
angenommen, in Arbeit oder ausgeführt) mitgeführt. Beim Übergang auf den Status
"beendet" ist die Aufgabe erledigt und der im Workflow vorgesehene Zustand erreicht.
Durch ein integriertes Informationssystem ist es jederzeit möglich, sich einen Überblick
über den Stand der Arbeiten und der Belastung einzelner Stellen und ganzer Organisationseinheiten zu verschaffen. Durch die Workitem-Analyse können statistische Auswertungen einzelner oder mehrerer Tätigkeiten (z.B. Ermittlung des Bearbeitungsstatus)
vorgenommen und Objektverknüpfungen dargestellt werden. Die Workload-Analyse
dient zur Ermittlung der Arbeitsbelastung einzelner Stellen oder Organisationseinheiten.
Anhand der Aufgabenanalyse können die definierten Aufgaben und deren Abhängigkeiten dargestellt werden. Diese Auswertungsmöglichkeiten bilden die Grundlage für
die notwendige Transparenz über die Vorgänge.
SAP Business Workflow unterstützt durch die genannten Funktionen den prozessorientierten Ansatz bei der Vorgangssteuerung von Büro- und Verwaltungsprozessen. Diese
147
Das R/3-System
Abläufe können dadurch vereinfacht, beschleunigt, transparenter gestaltet und besser
überwacht werden. Zusätzlich wird ein asynchrones Arbeiten (zeitlich und örtlich versetzt) an den zu erledigenden Aufgaben ermöglicht. Insgesamt wird dadurch ein grosser
Beitrag zur Ausnutzung des noch vorhandenen Optimierungspotentials bei Büro- und
Verwaltungsprozessen geleistet.
3.4 System-Architektur
Das R/3-System basiert auf einer Client/Server-Architektur. Die Umsetzung dieses Prinzips wurde durch ein Mehrschichtenmodell realisiert (vgl. Abb. 3-31). Die einzelnen
Ebenen sind über Schnittstellen miteinander verbunden und gewährleisten dadurch
eine weitgehende Unabhängigkeit des R/3-Systems von der verwendeten Systemsoftware und damit auch von den verwendeten Hardwarekomponenten.
R/3-Anwendungen
ABAP/4
Development Workbench
FI
CO
TR
MM
.......
Basissystem(BC)
Systemsoftware
Abb. 3-31: Schichtenarchitektur des R/3-Systems.
Die Systemsoftware gehört dabei nicht zum R/3-System und umfasst das Betriebssystem, die Datenbank-Managementsoftware und die Kommunikationssoftware. Durch
die Middleware (BC-Basissystem), welche direkt mit der darunterliegenden Systemsoftware kommuniziert, können die verschiedenen Anwendungen des R/3Systems und die Entwicklungsumgebung des R/3-Systems (ABAP/4 Development
148
Das R/3-System
Workbench) neutral gehalten werden. Dadurch wird es möglich, R/3 mit verschiedenen
Betriebssystemen und Datenbanken einzusetzen. Die Variationsvielfalt wird nur durch
das Vorhandensein entsprechender Schnittstellen mit dem Basissystem eingeschränkt.
Mit Release 3.1 unterstützt das R/3-System, die in Abb. 3-32 dargestellten Betriebssysteme, Datenbanken und Benutzeroberflächen.
Hardware
Unix Systeme
Bull
IBM
DEC
SNI
HP
Sun
AT&T
Data General
Bull/Zenith HP (Intel)
Compaq
IBM (Intel)
...
...
Sequent
SNI
Digital
...
IBM
AS/400
IBM
S/390
Windows NT
OS/400
OS/390
ADABAS D
MS SQL Server
Informix-Online
ORACLE
DB2 for
OS/400
DB2 for
OS/390
Betriebssystem
AIX
Dec Unix
HP-UX
Datenbank
Reliant
SINIX
Solaris
ADABAS D
DB2 für AIX
Informix
ORACLE
Dialog (SAPGUI)
Windows 3.1, Windows 95, Windows NT
OSF/Motif*, OS/2 Presentation Manager (PM),
Macintosh*, Java
Sprachen
IF...
THEN...
ABAP/4,C,C++, HTML, Java
ELSE...
* Wird als Frontend für AS/400 nicht unterstützt
Abb. 3-32: Mögliche Hardware- und Systemsoftwareplattformen für das R/3-System.152
152
Releasestand 3.1.
149
Das R/3-System
Zusätzlich zur Offenheit bietet das R/3-System durch die Umsetzung des Mehrebennenmodells von Client/Server-Architekturen für jede Unternehmensgrösse eine massgeschneiderte Konfigurationsmöglichkeit (vgl. Abb. 3-33). Durch die Trennung von Präsentations-, Applikations- und Datenbankebene kann das R/3-System beinahe beliebig
skaliert werden. Dabei unterstützt die Präsentationsebene die graphische Darstellung
der Anwendungsfunktionen (GUI153) und ist somit für die Interaktion zwischen Anwender und System zuständig. Auf Applikationsebene ist die eigentliche Anwendungslogik
angesiedelt. Auf dieser Stufe werden die Verarbeitungsfolgen gesteuert und die notwendigen Integritätsbedingungen bei der Datenerfassung und -verarbeitung überprüft.
Auf Datenbankebene erfolgt die zentrale Speicherung und Bereitstellung der für die
betrieblichen Abläufe relevanten Daten. Ausgehend von diesem Mehrebenenkonzept
sind in Abhängigkeit von der Unternehmensgrösse verschiedene Skalierungsmöglichkeiten denkbar (vgl. Abb. 3-33 )
Präsentation
Applikation
Datenbank
Zentrales
System
Verteilte
Präsentation
Zweistufige
C/S-Architektur
Dreistufige
C/S-Architektur
Mehrstufige,
kooperative
C/S-Architektur
Abb. 3-33: Konfigurationsmöglichkeiten des R/3-Systems.
153
GUI = Graphical User Interface; im R/3-Umfeld wird in diesem Zusammenhang auch der Begriff
SAPGUI (Graphische Benutzeroberfläche der SAP) verwendet.
150
Das R/3-System
Bei Verwendung einer einstufigen Lösung (Zentrales System) sind alle Ebenen auf einem Rechner (z.B. Laptop) zusammengefasst. Diese Lösung ist nicht für den produktiven Einsatz vorgesehen und dient vor allem zu Präsentationszwecken. Bei der verteilten
Präsentation erfolgt der Zugriff auf ein zentrales R/3-System, in welchem Applikationsserver- und die Datenbankserverfunktionen zusammengefasst sind, von mehreren Präsentationsrechnern aus. Beim zweistufigen Ansatz beziehen mehrere Rechner, welche
Präsentations- und Applikationsfunktionen vereinen, ihre Daten von einem zentralen
Datenbankserver. Die beiden letztgenannten Varianten sind vor allem für kleinere und
mittelgrosse Unternehmen geeignet. In einer weiteren Ausbaustufe kommt das klassische dreistufige Client/Server-Modell zum Einsatz. Die Datenhaltung erfolgt zentral auf
einem Datenbankserver. Auf der zweiten Ebene werden je nach Benutzerzahl in den
verschiedenen Anwendungsbereichen werden mehrere Applikationsserver eingesetzt.
Durch zielgerichtete Verteilung der Anwender (Präsentationsebene) auf den verschiedenen Applikationsservern kann die zur Verfügung stehende Leistung optimal genutzt
werden und bei zusätzlichen Leistungsbedürfnissen durch Hinzufügen eines weiteren
Applikationsservers flexibel angepasst werden. Beim Einsatz einer mehrstufigen kooperativen Client/Server-Architektur können mehrere R/3-Systeme miteinander gekoppelt
werden. Selbst die Datenhaltung ist in diesem Modell verteilt. Diese Variante ist vor
allem in internationalen Konzernen mit geographisch weit auseinanderliegenden Funktionsbereichen anzutreffen. Befindet sich beispielsweise der Vertrieb sowie Forschung &
Entwicklung in Europa und die Produktion in Asien, dann ist es sinnvoll auf jedem Kontinent ein separates R/3-System einzusetzen. Damit eine konsistente Datenhaltung (z.B.
Materialstammdaten) gewährleistet ist, muss ein Abgleich zwischen den beiden Datenbankservern stattfinden können. Dieser Datenaustausch wird durch das ALE-Konzept
sichergestellt.
Für die Nutzung des R/3-Systems im Internet kann die Systemarchitektur durch die Einbindung einer Web-Server-Ebene zusätzlich erweitert werden (vgl. Abb. 3-34). Dadurch
wird es möglich, über einen normalen WWW-Browser (Web-Client) auf ein R/3-System
zuzugreifen und dessen Funktionen zu nutzen. Eine Electronic Commerce Applikation
auf dem Web-Server stellt für diesen Zweck die dazu notwendige Programmlogik zur
151
Das R/3-System
Verfügung. Über spezifische Schnittstellenprogramme (Internet Transaction Server oder
SAP-Automation) wird die Kommunikation mit den benötigten R/3-Transaktionen gesteuert. Dadurch wird die Möglichkeit geboten, R/3 über die Unternehmensgrenzen
hinweg zu nutzen und damit die existierenden Prozessketten durchgängig mit Informationssystemen abzudecken.
Client/Server-Architektur des R/3-Systems
Klassisches 3-Ebenen Modell
Präsentation
(SAPGUI)
Erweitertes 4-Ebenen Modell
(Internet Integration)
Präsentation
(Web Client)
Web Server
Applikationsserver
Applikationsserver
Datenbank
Server
Datenbank
Server
Abb. 3-34: Integration von R/3 in das Internet.
Die dargestellten technischen Gestaltungsmöglichkeiten bieten einen grossen Spielraum
für den Einsatz des R/3-Systems. Folgende Merkmale sind besonders hervorzuheben:
• Skalierbarkeit: Die Ausbaumöglichkeiten der technischen Architektur über mehrere
Stufen und die Verteilbarkeit der verschiedenen R/3-Applikationen und der zugehörigen Datenbestände gewährleisten eine weitreichende Anpassbarkeit des R/3Systems an die unternehmensspezifischen Erfordernisse und bieten genügend Spielraum bei Veränderung des Leistungsbedarfs.
152
Das R/3-System
• Portabilität: Das SAP-Basissystem ermöglicht die Nutzung des R/3-Systems auf verschiedenen Plattformen mit unterschiedlichsten Systemsoftwarekomponenten
(Betriebssysteme, Datenbanken und graphische Benutzeroberflächen). Diese Unabhängigkeit gewährleistet den Einsatz der am besten geeigneten Komponenten und
sorgt durch die damit verbundene längere Nutzungszeit der betriebswirtschaftlichen
Anwendungen für einen besseren Investitionsschutz.
• Offenheit: Durch die Möglichkeit der Verwendung von Hardware- und Systemsoftwarekomponenten unterschiedlicher Hersteller entfällt die bei rein proprietären Systemen üblicherweise vorhandene einseitige Abhängigkeit.
• Graphische Benutzeroberfläche: Die ausschliessliche Verwendung von graphischen Benutzeroberflächen als Frontend für das R/3-System reduzieren den Einarbeitungsaufwand und sorgen für eine bessere Akzeptanz bei den Anwendern.
• Desktop-Integration: Die Integration von Desktop-Applikationen (z.B. Winword
oder Excel) in das R/3-System schafft eine einheitliche Basis und erleichtert die
Weiterverarbeitung der betrieblichen Daten. Zusätzlich wird die Einstellung neuer
Arbeitskräfte durch Verwendung weit verbreiteter Office-Pakete vereinfacht und die
bereits erfolgte Ausbildung der Anwender auf solchen Systemen kann voll genutzt
werden.
153
4 Einführung von SAP R/3
4.1 Einleitung
Die Einführung eines EMS stellt eine in allen Belangen anspruchsvolle Aufgabe für das
Projektmanagement dar. Zur Strukturierung des Einführungsprozesses empfiehlt sich der
Einsatz von Vorgehensmodellen und der damit eng gekoppelten Methoden und Werkzeugen.154 Die SAP AG stellt zur Abdeckung dieser Bedürfnisse im Rahmen des Business
Engineers eine ganze Palette von Werkzeugen zur Verfügung.155 Kern des Business Engineers ist das R/3-Vorgehensmodell, welches das für die Einführung notwendige Gerüst
bildet und den Einsatz der verschiedenen methodischen Hilfsmittel und Werkzeuge
regelt. Zu diesen gehören die Komponenten R/3-Referenzprozessmodell, R/3-Organisationsmodell, R/3-Objektmodell, R/3-Datenmodell, R/3-Prototyping (IDES), Einführungsleitfaden (IMG) und R/3-Data Dictionary.156
Bevor im Detail auf das R/3-Vorgehensmodell eingegangen wird, sollen verschiedene
Vorschläge zu Grundtypen von Vorgehensmodellen für die Einführung eines EMS näher
betrachtet und einander gegenübergestellt werden. Daraus lässt sich bestimmen, welcher Kategorie von Vorgehensmodellen das R/3-Vorgehensmodell angehört und welche
grundsätzlichen Vor- und Nachteile mit seinem Einsatz verbunden sind. Im nächsten
Abschnitt folgt die detaillierte Beschreibung der einzelnen Projektaktivitäten und eine
kritischen Stellungnahme zu den dabei festgestellten Schwächen des R/3-Vorgehensmodells.
Auf der Grundlage dieser Erkenntnisse, verbunden mit der Auswertung verschiedener
Literaturquellen und der Ergebnisse einer empirischen Voruntersuchung157, werden
mögliche Erfolgsfaktoren für den Einführungsprozess identifiziert.
154
155
156
157
Vgl. z.B. Keller/Teufel (1997), S. 183.
Vgl. Kap. 3.3.8.4.
Keller/Teufel (1997), S. 197 ff.
Knolmayer/Portner/von Arb (1995).
155
Diese Faktoren wurden im Rahmen einer Expertenbefragung bewertet und daraus die
kritischen Projektaktivitäten ermittelt. Parallel dazu wurde versucht, anhand der kritischen Erfolgsfaktoren (CSF) die thematischen Schwergewichte einer nachfolgenden empirischen Untersuchung festzulegen und damit die Grundlage für die Bestimmung eines
empirischen Bezugsrahmens zur Formulierung von Hypothesen zu Einflussgrössen und
Aktionsparametern des Einführungsprozesses zu schaffen.
4.2 Arten von Vorgehensmodellen
Vorgehensmodelle zur Einführung von Informationssystemen werden auf dem Markt
und in der Literatur in grosser Vielfalt angeboten. Beinahe jedes Beratungsunternehmen
verfügt über ein eigenes Vorgehensmodell und betont dessen angebliche Vorteile mit
grossem Marketingaufwand. Auch in der Literatur lässt sich eine Kontroverse zur Eignung verschiedener Typen von Vorgehensmodellen im praktischen Einsatz feststellen.
Viele Autoren vertreten unterschiedliche Auffassungen und machen eigene Gestaltungsvorschläge zur Einführung von Informationssystemen.158
Ein Vorgehensmodell für die Einführung eines EMS unterteilt den Einführungsprozess in
eindeutig abgegrenzte Phasen mit klar definierten Zwischenzielen. Dabei lässt sich feststellen, dass sich Vorgehensmodelle zur Entwicklung von Individualsoftware und Vorgehensmodelle zu Einführung von EMS in vielen Punkten ähneln. Letztere sind in der Regel von den Erstgenannten abgeleitet und spezifisch auf die Bedürfnisse einer EMSEinführung angepasst worden. Ähnlich wie bei den Vorgehensmodellen zur Entwicklung
von Individualsoftware existieren auch bei Vorgehensmodellen zur Einführung von EMS
sehr unterschiedliche Phasen-Einteilungsvorschläge. In der Literatur wird diesen eher
marginalen Unterschieden aber wenig Bedeutung beigemessen.159 Vielmehr sind verschiedene Grundtypen von Vorgehensmodellen festzustellen, welche in einzelnen Entwicklungsstufen verfeinert und verbessert wurden (vgl. Abb. 4-1). Bei der Frage, welches
die geeignetste Art des Vorgehens sei, gehen die Meinungen der Experten auseinan-
158
159
Vgl. z.B. Barbitsch (1996), S. 95 ff.; Keller/Teufel (1997), S. 177 ff.; Österle (1995), S. 35 ff.
Vgl. z.B. Thome/Hufgard (1996), S. 19.
156
der.160 Daher wird im folgenden versucht, die verschiedenen Grundtypen von Vorgehensmodellen darzustellen und deren Vor- und Nachteile aufzuzeigen.
Sequentielle
Vorgehensmodelle
Merkmale
Sequentielle Vorgehensweise mit klarer
Phasenabgrenzung
Beispiele
Life-Cycle-Modell
Wasserfall-Modelle
a) klassisch
Iterative Vorgehensweise mit
Rückkoppelung zwischen
den einzelnen Entwicklungsphasen, Einfügen von
Validierungsschritten
Aufwand
SAPVorgehensmodell
t
b) prozessorientiert
BPR
Zusätzliche Fokussierung
auf die Umgestaltung von
Geschäftsprozessen im
Rahmen der Möglichkeiten
von EMS
IST
SOLL
Aufwand
IPP
GES
PROMET
GatewayManagement
t
Spiralmodelle
Konzeption
Analyse
Schrittweise Annäherung an
weitgehend optimierte
Geschäftsprozesse durch
zyklische Abfolge der
einzelnen Projektschritte
Realisierung
CSE
Integration
IPP
GES
CSE
Iteratives Prozess-Prototyping
Geschäftsprozessorientierte Einführung von Standardsoftware
Continous System Engineering
Abb. 4-1: Grundtypen von Vorgehensmodellen zur Einführung von Informationsystemen.
160
Vgl. Keller/Teufel (1997), S. 182.
157
Sequentiellen Vorgehensmodelle (Phasenmodelle) zeichnen sich durch einen stark
phasenorientierten Ablauf der Einführung ab. Die einzelnen Phasen sind in sich abgeschlossen, d.h. mit der folgenden Phase wird erst begonnen, wenn die aktuelle Phase
abgeschlossen ist. Dieses Vorgehen wird vorwiegend bei der Entwicklung von Individualsoftware angewendet. Die Problematik dieser Vorgehensweise ist einerseits die
starre Ausrichtung des Einführungsprozesses auf ein weit in der Zukunft liegendes Ziel
und andererseits die fehlende Rückkopplung zwischen den einzelnen Phasen. Durch
die starre Ausrichtung können während des Projekts vollzogene Veränderungen der
Aufbau- oder Ablauforganisation nur schwer berücksichtigt werden. Die fehlende Rückkopplung kann dazu führen, dass konzeptionelle Fehler erst spät erkannt werden und
nur mit grossem zeitlichen und finanziellen Aufwand wieder rückgängig gemacht werden können. Ein weiteres Problem stellt die klare Trennung der einzelnen Phasen dar.
Häufig würde die strikte Phasenabgrenzung durch die parallele Führung einzelner Projektaktivitäten aufgrund deren unterschiedlicher Dauer zu Projektverzögerungen führen.161 Beispiel für solche Vorgehensmodelle ist das Software-Life-Cycle-Modell.162
Auf der zweiten Entwicklungsebene stehen die Wasserfall-Modelle (Iterative Vorgehensmodelle). Bei diesen findet eine Rückkopplung zwischen den einzelnen Phasen
statt. Am Ende jeder Phase erfolgt ein Validierungsprozess zur Sicherung der Ergebnisse.
Vorteil dieses Vorgehens ist die verbesserte Möglichkeit, bei konzeptionellen Fehlern
Korrekturmassnahmen einzuleiten. Die Anwendung klassischer Wasserfallmodelle bei
der Einführung von EMS hat gezeigt, dass auf konzeptioneller Ebene eine Erweiterung
im Sinne einer stärkeren Fokussierung der Aktivitäten auf die Gestaltung zusammenhängender Geschäftsprozesse (Prozessorientierung) vorgenommen werden muss.163 Darüber hinaus stellt die Einführung von EMS eine Chance für die Reorganisation bestehender Geschäftsprozesse dar. In klassischen Ansätzen von Wasserfallmodellen wird
diesem Aspekt zu wenig Beachtung geschenkt, deshalb werden in der Literatur ver-
161
162
163
Vgl. Pomberger/Blaschek (1996), S. 21.
Vgl. Österle (1995), S. 31.
158
schiedene Vorgehensweisen (z.B. GES-Phasenkonzept164, Gateway-Management165,
PROMET166) vorgeschlagen. Durch ein gleichzeitiges Reengineering der Geschäftsprozesse können die Vorteile eines EMS in stärkerem Masse genutzt werden. Grösster
Nachteil der Wasserfallmodelle ist die fehlende Werkzeugunterstützung beim Übergang
vom Ist-Zustand zur Soll-Konzeption, durch welche die vorgedachten Prozesse simuliert
werden könnten. Obwohl im Unterschied zu sequentiellen Vorgehensmodellen eine
verbesserte Möglichkeit zur Korrektur von konzeptionellen Fehlern besteht, lässt sich die
Fortschleppung falscher Vorgaben nicht gänzlich vermeiden.
Ähnlich wie bei Vorgehensmodellen im Bereich der Software-Entwicklung wird der
Ausweg aus diesem Dilemma bei der Einführung von EMS ebenfalls im Bereich des
evolutionären Vorgehens gesucht. Mit sogenannten Spiralmodellen167 soll versucht
werden, sich einem Ziel durch den zyklischen Durchlauf einzelner Entwicklungsschritte
(Analyse, Konzeption, Realisierung und Integration) stetig zu nähern. Die gleichzeitige
Integration von Reengineering-Aktivitäten in den repetitiven Prozess ermöglicht eine
schrittweise Annäherung zu weitgehend optimierten Geschäftsprozessen (Continous
System Engineering; CSE).168 Vorteil dieses Vorgehens ist die raschere und in erträglicheren Schritten erfolgende Verbesserung von Geschäftsprozessen. Ferner können konzeptionelle Fehler unmittelbar behoben werden. Nachteilig bei diesem Konzept ist eine
mögliche Versandung der Projektaktivitäten bei sehr umfangreichen Projekten.
164
165
166
167
168
Kirchmer (1996), S. 73 ff.
Barbitsch (1996), S. 95 ff .
IMG (1997); Österle (1995) S. 31.
Boehm (1988).
Vgl. Thome/Hufgard (1996), S. 87 ff.
159
Die Frage, welche nun im Zusammenhang mit der Einführung von EMS die sinnvollste
Vorgehensweise sei, lässt sich nicht eindeutig beantworten. Über die Berücksichtigung
der Prozessorientierung bei der Wahl des Vorgehensmodells ist sich die Fachwelt einig.
Allerdings ist umstritten, ob die Anpassung der Organisation sprunghaft (BPR) oder in
kleinen Schritten (CSE) zu erfolgen hat. Damit ist die Entscheidung zwischen einem prozessorientierten Wasserfallmodell und einem entsprechenden Spiralmodell individuellen Neigungen zu überlassen.
Das SAP-Vorgehensmodell entspricht am ehesten dem klassischen Typ des Wasserfallmodells. Durch die frühe Integration von Protyping-Aktivitäten wird dem Aspekt der
schrittweisen Verbesserung von Spiralmodellen ebenfalls in gewisser Weise Rechnung
getragen. Konzeptionelle Fehler können dadurch besser erkannt und gegebenenfalls
frühzeitig korrigiert werden. In den folgenden Unterkapiteln wird das SAPVorgehensmodell im Detail vorgestellt und anschliessend auf einige Schwachpunkte
eingegangen.
4.3 SAP-Vorgehensmodell
4.3.1 Darstellung des SAP-Vorgehensmodells
4.3.1.1 Übersicht
Das SAP-Vorgehensmodell bildet den methodischen Rahmen für die Einführung des
R/3-Systems. In einzelnen Schritten werden sämtliche Projektaktivitäten nach dem Entscheid für R/3 bis zu dessen Produktivsetzung beschrieben. Dabei wird weder eine detaillierte Ist-Analyse noch ein ausführliches Soll-Konzept vorausgesetzt. Das Vorgehensmodell ist in vier Phasen unterteilt (vgl. Abb. 4-2). In jeder Phase werden die notwendigen Einführungsaktivitäten, gruppiert nach Arbeitspaketen, beschrieben. Am Ende jeder
Phase wird in einem speziellen Arbeitspaket die Qualitätssicherung der einzelnen Aktivitäten vorgenommen.
160
Organisation und
Konzeption
Detaillierung/
Realisierung
Systemumgebung
einrichten
Projektteam
schulen
Projekt
vorbereiten
globale
Einstellungen
vornehmen
Qualitäts-
Unternehmensstruktur
abbilden
Sollkonzept
Funktionen /
Prozesse
festlegen
Schnittstellen
und
Erweiterungen
entwerfen
prüfung
Grunddaten /
Stammdaten
abbilden
Funktionen /
Prozesse
abbilden
Produktionsvorbereitung
Produktivbetrieb
Schnittstellen
und
Erweiterungen
realisieren
Berichtswesen
abbilden
Archivverwaltung
abbilden
Berechtigungsverwaltung
abbilden
Qualitäts-
AnwendungsSystem
prüfung
Produktivsetzung
vorbereiten
Anwender
schulen
Anwenderdokumentation
erstellen
Systemadministration
organisieren
Produktivsystem
Produktivumgebung
einrichten
Daten in
Produktivsystem
übernehmen
prüfung
Qualitäts-
Produktivbetrieb
unterstützen
Systembetrieb
optimieren
Abschlusstest
durchführen
Projektadministration und Projektcontrolling
Systemwartung und Release-Wechsel
Abb. 4-2: SAP-Vorgehensmodell.
Inhaltlich behandelt das SAP-Vorgehensmodell sowohl Customizing-Aktivitäten als auch
Aktivitäten zur Projektsteuerung. Die notwendigen Tätigkeiten im Rahmen einer R/3Einführung werden in den folgenden Abschnitten hinsichtlich möglicher Erfolgsfaktoren
von R/3-Projekten beschrieben.
161
4.3.1.2 Organisation und Konzeption
In der Phase "Organisation und Konzeption" wird die Projektorganisation festgelegt,
das Projektteam im Hinblick auf die R/3-Einführung ausgebildet, ein Testsystem eingerichtet und ein Sollkonzept erarbeitet. Die dazu notwendigen Aktivitäten sind in einzelnen Arbeitspaketen zusammengefasst (vgl. Abb. 4-3).
• Projekt vorbereiten
− Projekt initialisieren
− Unternehmensziele des R/3-Einsatzes definieren
− Bestandsaufnahme durchführen
− Prozesse/Funktionen des R/3-Systems kennenlernen
− Geschäftsprozesse definieren
− Funktionale Anforderungen mit R/3-System abgleichen
− Abbildung der Unternehmensstruktur erarbeiten
− Ziele und Umfang von Standardisierungsvorhaben definieren
− Einführungsstrategie festlegen
− Hardware-Bedarf ermitteln
− Projektaufbauorganisation festlegen
− Projektstandards und -arbeitsweise festlegen
− Systemlandschaft festlegen
− Aufwands-, Termin- und Kostenplan erstellen
− Ergebnisse der Projektvorbereitung verabschieden
− Projektauftrag erstellen
− Kick-off des Einführungsprojektes durchführen
• Projektteam schulen
− Projektteam ausbilden
− R/3-Funktionalität kennenlernen
• Systemlandschaft einrichten
− Systeme und Mandanten einrichten
− Benutzerstammsätze für Projektmitarbeiter einrichten
− Mandantensteuerung, Korrektur-/Transportwesen einrichten
− Systemumfeld einrichten
− Remote-Verbindung einrichten
− Landesspezifische Voreinstellungen ändern
− Unternehmens-IMG erzeugen
− Customizing-Projekte anlegen
• Qualitätsprüfung Sollkonzept
− Projektaufbau- und -ablauforganisation überprüfen
− Einhaltung der Projektstandards überprüfen
− Systemlandschaft überprüfen
− Sollkonzept überprüfen
− Schnittstellen- u. Systemerweiterungsbeschreibung überprüfen
− Projektplanung überprüfen
− Prüfungsprotokoll erstellen
− Freigabe der nächsten Phase veranlassen
• Prozesse/Funktionen festlegen
− Prozesse/Funktionen anhand des Referenzmodells spezifizieren
− Verantwortung für Prozesse/Funktionen festlegen
− Input/Output-Informationsobjekte überprüfen
− Anforderungen an das Berichtswesen ermitteln
− Schnittstellen und Systemerweiterungen bestimmen
− Abbildung der Unternehmensstruktur festlegen
− Prototyping ausgewählter Prozesse/Funktionen durchführen
− DV-Konzept spezifizieren
− Fach- und DV-Konzept abstimmen
• Schnittstellen und Systemerweiterungen entwerfen
− Detailbeschreibung für die Schnittstellen erstellen
− Detailbeschreibung für die Systemerweiterungen erstellen
− Ausarbeitung für die Datenübernahme erstellen
Abb. 4-3: Aktivitäten der Phase "Organisation und Konzeption".169
Mit dem Arbeitspaket "Projekt vorbereiten" werden wichtige Grundlagen für die R/3Einführung geschaffen. In der Regel stehen nach dem Entscheid für SAP R/3 verschiedene Dokumente (z.B. Unternehmensdokumentation, Pflichtenheft, Projektauftrag) als
Produkt der bisherigen Tätigkeiten für die Vorbereitungsarbeiten zur Verfügung. Vorerst
sind die konkreten Ziele für den R/3-Einsatz zu formulieren. Damit verbunden ist die
Bestimmung des Umfangs der R/3-Einführung und die Festlegung der Vorgaben für die
Wahl der Einführungsstrategie. Dabei gilt es u.a. zu bestimmen, inwieweit Veränderun-
169
Vgl. SAP AG (1996a), Abschnitt: R/3-Customizing: Vorgehensmodell.
162
gen der Aufbau- und/oder Ablauforganisation (Business Process Reengineering) erwünscht sind.
Falls nicht bereits geschehen, ist anschliessend eine Bestandesaufnahme der Unternehmensstruktur durchzuführen. Eine weitere notwendige Tätigkeit stellt die Sichtung der
Prozesse und Funktionen des R/3-Systems dar. Dafür steht das R/3-Referenzmodell und
die weitergehende R/3-Dokumentation zur Verfügung. Diese Kenntnisse sind notwendig, um in einem nächsten Schritt die Geschäftsprozesse des Unternehmens zu definieren. Falls in der Evaluationsphase ein detailliertes Soll-Konzept erstellt wurde, kann auf
diese Aktivität verzichtet werden. Resultat der Gegenüberstellung der R/3-Funktionalität
und der existierenden Unternehmensprozesse ist die Erfüllung der funktionalen Anforderungen und die Ableitung von Lösungsansätzen bei der Feststellung von funktionalen
Defiziten. In Kenntnis des Funktionsabdeckungsgrads kann festgelegt werden, inwieweit
die Organisation an das System resp. das System an die Organisation angepasst wird.
Aufgrund dieser Erkenntnisse lässt sich nun die Einführungsstrategie konkret festlegen.
Im Anschluss an die Prozessdefinition und die Wahl der Einführungsstrategie gilt es eine
geeignete Projektorganisation zu finden. Diese umfasst die Regelung der Verantwortlichkeiten und Kompetenzen sowie die allenfalls notwendige Bildung von Teilprojekten.
Ferner müssen Projektstandards zur Vereinheitlichung der Arbeitsweise und Kommunikation festgelegt werden. Die Aufstellung eines detaillierten Aufwand-, Termin- und
Kostenplans stellt die Grundlage für die Durchführung eines aktiven Controllings während der Projektabwicklung dar.
In Zusammenarbeit mit technischen Beratern wird die Systemlandschaft für die künftige
R/3-Installation festgelegt. Für die Erarbeitung eines Prototypen und die Durchführung
der Anwenderschulung muss ein Testsystem eingerichtet werden und es müssen Richtlinien für die Nutzung der einzelnen Mandanten (z.B für die Entwicklung und Integration
des Systems) geschaffen werden.
Der Abschluss dieses Arbeitspaketes wird vollzogen, indem die einzelnen Konzepte vor
den entsprechenden Verantwortungsträgern (Lenkungsausschuss) präsentiert werden
und deren Inhalte bei Genehmigung in die Konkretisierung des Projektauftrags einflies163
sen. Der offizielle Start des Projekts erfolgt durch Bekanntgabe der Zielsetzungen und
Rahmenbedingungen im Rahmen eines Kick-off-Meetings.
Im zweiten Arbeitspaket "Systemlandschaft einrichten" wird das Ziel verfolgt, eine
Entwicklungs- und Testumgebung einzurichten. Dazu gehört die Einrichtung entsprechender Mandanten im R/3-System für die Entwicklung eines Prototypen und für die
Durchführung der Test-Aktivitäten. Dies umfasst u.a. auch die Festlegung von Berechtigungsprofilen für Projektmitarbeiter und die Konfiguration des Transportsystems für die
Übertragung von Einstellungen und Daten zwischen den einzelnen Mandanten.
Ferner erweist es sich für die Projektarbeit als sinnvoll, den Zugriff auf den SAP-RemoteService einzurichten, damit während des Projekts Informationen zu Fehlern und Problemen einzelner R/3-Funktionen abgerufen werden können. Gleichzeitig erlaubt diese
Verbindung auch die Übertragung von korrigierten Programmversionen zur Behebung
der festgestellten Fehler.
Durch die Generierung der für das Projekt notwendigen Landesversion werden die länderspezifischen Voreinstellungen für den für die Einführung verwendeten Testmandanten vorgenommen. Der nächste Schritt stellt die Generierung des unternehmensbezogenen Einführungsleitfadens (Unternehmens-IMG) dar. Dieser basiert auf den im Arbeitspaket "Projekt vorbereiten" gewählten Prozessen und Funktionen und umfasst alle für
das Gesamtprojekt notwendigen Customizing-Aktivitäten. Zur Gliederung der Customizing-Aktivitäten können anschliessend einzelne Customizing-Projekte definiert werden.
Diese richten sich an der für die Einführung vorgesehenen Projektstruktur und ausgewählten Einführungsstrategie.
Eine weitere Aktivität in der Phase "Organisation und Konzeption" bezieht sich auf die
Ausbildung des Projektteams. Dieses muss im Rahmen von Schulungen die betriebswirtschaftlichen Inhalte und Möglichkeiten des R/3-Systems kennenlernen, damit die Anforderungen des Unternehmens bestmöglich abgedeckt werden können. In einer zweiten Phase ist es sinnvoll, die erworbenen Kenntnisse durch die Arbeit am System zu vertiefen. Hilfreiche Stütze für die Vertiefung der Kenntnisse bieten der Business Navigator
164
und das IDES-System170. Mit dem Business Navigator können die im R/3-System abgebildeten Geschäftsprozesse in Form von Ereignisgesteuerten Prozessketten (EPK) betrachtet werden, und das IDES-System stellt ausführlich dokumentierte Beispielprozesse
zur Verfügung, welche sich direkt am R/3-System nachvollziehen lassen.
Im Arbeitpaket "Prozesse und Funktionen festlegen" werden die ausgewählten Prozesse und Funktionen des R/3-Referenzmodells spezifiziert und mit den spezifischen Bedürfnissen des Unternehmens in Einklang gebracht. Dies geschieht in der Regel durch
Anpassung des Referenzmodells mit dem ARIS-Toolset. Dabei wird auch definiert, welche Organisationseinheit künftig für die Abwicklung eines Prozesses verantwortlich ist
und welche Informationsobjekte (Input- und Output-Flüsse) zur Bearbeitung eines Prozesse notwendig sind. Ferner sind die Anforderungen an das Berichtswesen festzulegen
und nötigenfalls mit den Möglichkeiten des R/3-System abzugleichen.
Alle Funktionen, bei welchen ein funktionales Defizit ermittelt wird, sind im Rahmen
der Spezifikation der Geschäftsprozesse zu kennzeichnen, damit in einer späteren Aktivität die notwendigen Schnittstellen und Erweiterungen beschrieben werden und die
resultierenden Aufwendungen ermittelt werden können.
In einem weiteren Schritt muss die Unternehmensstruktur im R/3-System abgebildet
werden. Dabei sind die vom System vorgegebenen Organisationseinheiten den entsprechenden Organisationseinheiten im Unternehmens zuzuordnen. Diese Aufgabe stellt
eine wichtige Weichenstellung im R/3-Projekt dar, weil einzelne Funktionen an bestimmte Organisationseinheiten gebunden sind. Bei unzweckmässiger Verwendung der
systemseitig angebotenen Organisationseinheiten besteht die Gefahr, dass gewisse
Funktionen nicht ausgeführt werden können.
Häufig erweist es sich als sinnvoll, bereits in der Konzeptionsphase für ausgewählte Prozesse einen Prototypen zu erstellen, damit die am Projekt Beteiligten einen Eindruck
von der durchgängigen Unterstützung der Geschäftsprozesse im R/3-System erhalten.
170
IDES = International Demo and Education System.
165
Auf technischer Ebene erfolgt in diesem Arbeitspaket die Detailspezifikation des bereits
grob vorhandenen DV-Konzepts. Dabei gilt es zu ermitteln, welche technischen Anforderungen (Hardware, Betriebssysteme, Datenbanken, Kommunikationsleitungen etc.)
zur Abwicklung der vorgedachten Prozesse erforderlich sind. Insbesondere bei einem
geographisch verteilten System (Multitsite-Installation) muss auf diese Aktivität ein besonderes Augenmerk gerichtet werden, damit im Produktivbetrieb die geforderten Antwortzeiten erreicht werden können. Ergebnis dieser Projektaktivität ist die detaillierte
technische Beschreibung der Systemlandschaft zur Beantragung und Freigabe der dafür
notwendigen finanziellen Mittel.
Zur Verhinderung von späteren konzeptionellen Korrekturen müssen unmittelbar vor
Abschluss dieses Arbeitspakets das Fach- und das DV-Konzept im Detail aufeinander
abgestimmt und einem Management-Gremium zur Begutachtung vorgelegt werden.
Vor Abschluss dieses Arbeitspaketes sind in der Aktivität "Schnittstellen und Systemerweiterungen entwerfen" anhand der in der Prozessspezifikation ermittelten Defizite die
vorgesehenen Schnittstellen zu Fremdsystemen, die notwendigen Erweiterungen und
die aus Altsystemen zu übernehmenden Daten zu beschreiben. Dadurch kann der Aufwand für diese Arbeiten ermittelt werden.
Am Ende der Phase "Organisation und Konzeption" wird einem weiteren Arbeitspaket
eine "Qualitätsprüfung" des erstellten Soll-Konzepts vorgenommen. Schwerpunkte bilden die Überprüfung
• der Projektaufbau- und ablauforganisation,
• der Einhaltung der Projektstandards,
• der vorgesehenen Systemlandschaft,
• der Konsistenz des erstellten Soll-Konzepts,
• der Schnittstellen- und Erweiterungsbeschreibung und
• der Projektplanung für die folgenden Arbeitspakete.
Über die Ergebnisse der Qualitätsprüfung wird ein Püfungsprotokoll erstellt. Darin wird
auf die festgestellten Mängel und Risiken hingewiesen sowie Empfehlungen für allenfalls
166
notwendige Korrekturmassnahmen abgegeben. Dieses Protokoll wird dem Steuerungsausschuss zur Genehmigung vorgelegt und bei Annahme erfolgt die Freigabe für den
Start der nächsten Phase.
4.3.1.3 Detaillierung und Realisierung
In der Phase "Detaillierung und Realisierung" wird das Soll-Konzept durch Customizing des Produktionsvorbereitungsmandanten umgesetzt. Parallel dazu erfolgt Entwicklung der notwendigen Schnittstellen und Erweiterungen. Das eingerichtete System wird
abschliessend einem Test unterzogen und nach einer zusätzlichen Qualitätsprüfung aller
Aktivitäten dieser Phase dem Lenkungsausschuss zur Genehmigung vorgelegt. Im einzelnen sind die in Abb. 4-4 dargestellten Aktivitäten auszuführen.
• Globale Einstellungen vornehmen
− Globale Einstellungen kennenlernen
− Globale Einstellungen anpassen
• Unternehmensstruktur abbilden
− R/3-Systemorganisationseinheiten prüfen und anpassen
• Grund- und Stammdaten abbilden
− Felder und Inhalte für Stammdaten festlegen
− Systemeinstellungen für Stammdaten durchführen
− Systemeinstellungen für Stammdaten testen
− Beschreibung für die Stammdatenübernahme detaillieren
• Prozesse/Funktionen abbilden
− Felder und Inhalte für Prozesse/Funktionen festlegen
− Systemeinstellungen für Prozesse/Funktionen durchführen
− Systemeinstellungen für Prozesse/Funktionen testen
− Ausgewählte Prozesse/Funktionen Fachabteilungen vorstellen
− Beschreibung für die Datenübernahme detaillieren
• Schnittstellen und Systemerweiterungen realisieren
− Datenübernahmeprogramme erstellen
− Schnittstellen realisieren
− Systemerweiterungen realisieren
− Datenübernahmeprogramme testen
− Schnittstellen testen
− Systemerweiterungen testen
• Berichtssystem abbilden
− Informationsbedarf ermitteln
− Informationsbedarfsabdeckung prüfen
− Lösungen für noch offene Anforderungen erstellen
− Organisation des Berichtssystem festlegen
− Berichtssystem testen
• Archivverwaltung abbilden
− Konzept für Archivverwaltung erstellen
− Systemeinstellungen durchführen
− Archivierungsvorgänge testen
• Berechtigungsverwaltung abbilden
− Berechtigungskonzept erstellen
− Berechtigungskonzept realisieren
− Berechtigungen testen
• Abschlußtest durchführen
− Testkonzept erstellen
− Testplan erstellen
− Testaktivitäten durchführen
− Bericht zum Abschlußtest erstellen
− Abschlußreview mit den Fachabteilungen durchführen
• Qualitätsprüfung Anwendungssystem
− Projektaufbau- und -ablauforganisation überprüfen
− Einhaltung der Projektstandards überprüfen
− Umsetzung Sollkonzept überprüfen
− Schnittstellen- / Systemerweiterungsrealisierung überprüfen
− Berichtssystem überprüfen
− Archivverwaltung überprüfen
− Berechtigungskonzept überprüfen
− Abschlußtest überprüfen
Abb. 4-4: Aktivitäten der Phase "Detaillierung und Realisierung".
167
Primäre Aktivität des Arbeitspakets "Globale Einstellungen vornehmen" ist die Einstellung der Grundfunktionen (z.B. Masseinheiten definieren) mit Hilfe des Einführungsleitfadens. Das ausgelieferte System beinhaltet bereits umfangreiche Voreinstellungen
für die meisten Customizing-Aktivitäten. Diese können unverändert übernommen oder
im Bedarfsfall geändert werden.
Die Abbildung der Unternehmensstruktur im R/3-System (Arbeitspaket "Unternehmensstruktur abbilden") anhand der Vorgaben des Sollkonzepts stellt die Grundvoraussetzung für alle folgenden, sich primär auf die Abläufe beziehenden CustomizingAktivitäten dar.
Im nächsten Arbeitspaket "Grund- und Stammdaten abbilden" werden vorerst die
Stammdatenfelder und deren Inhalte festgelegt. Anhand der Prozessvorgaben erfolgt
anschliessend die Parametersetzung für die Stammdaten und das Austesten dieser Einstellungen. Anhand der detaillierten Beschreibung der Feldverwendungen der Stammdaten kann die Art und Weise der Stammdatenübernahme aus Altsystemen festgelegt
werden. Die Hauptproblematik bei der Datenübernahme stellt die Erhaltung resp. Verbesserung der Datenqualität dar.
Das nächste Arbeitspaket "Prozesse und Funktionen abbilden" befasst sich mit den
Hauptaktivitäten dieser Phase. Für die Abbildung der einzelnen betriebswirtschaftlichen
Prozesse erfolgt durch Vornahme der im Einführungsleitfaden vorgegebenen Customizing-Einstellungen. Analog zu der Abbildung der Stammdaten ist auch hier vorerst die
Feldbelegung zu bestimmen. Anschliessend können die für die Prozessführung notwendigen Systemeinstellungen vorgenommen und ausgetestet werden. Zur Förderung der
Akzeptanz des Systems erweist es sich in diesem Stadium des Projekts von Vorteil, den
späteren Anwendern einige ausgewählte Prozesse zu präsentieren und Lösungsvarianten
gemeinsam mit ihnen zu diskutieren. Nachdem sich alle Beteiligten über die Abwicklung der Prozesse geeinigt haben, lässt sich die Beschreibung der Datenübernahme aus
bisherigen Anwendungssystemen (vorwiegend Bewegungsdaten) erstellen.
168
Im Arbeitspaket "Schnittstellen und Systemerweiterungen realisieren" werden anhand
der Vorgaben des Fachkonzepts Datenübernahmeprogramme erstellt und permanente
Schnittstellen zu Fremdsystemen eingerichtet. Ferner erfolgt die Umsetzung der vorgesehenen Systemerweiterungen. Die zur Realisierung von Schnittstellen und Systemerweiterungen erstellten Programme sind Gegenstand einer anschliessenden Prüfung auf
Fehlerfreiheit und Einhaltung der vorgesehenen Funktionalität.
Zur Befriedigung der Informationsbedürfnisse der späteren Anwender muss der Informationsbedarf im Arbeitspaket "Berichtssystem abbilden" ermittelt und mit den vom
R/3-System angebotenen Auswertungsmöglichkeiten abgestimmt werden. Im Anschluss
daran können die notwendigen Berichte erstellt und die Organisation des Berichtswesens festgelegt werden. Auch hier ist das ganze Berichtswesen einem gründlichen Test
zu unterziehen und die erstellten Reports sind den Fachabteilungen zur abschliessenden
Begutachtung vorzulegen.
Die Gewährleistung der Datensicherheit ist Inhalt des Arbeitspakets "Archivverwaltung
abbilden". Dabei muss ein Archivierungskonzept entworfen werden, in welchem festgelegt wird, wie lange die Daten zur Bearbeitung der Prozesse aktiv zu halten sind, resp.
wann eine Archivierung erfolgen kann. Diese Vorgaben sind anschliessend im System
umzusetzen und an Musterdaten zu testen.
Zur Gewährleistung des Datenschutzes wird im Arbeitspaket "Berechtigungsverwaltung
abbilden" auf der Basis der im Soll-Konzept erstellten Verantwortungszuordnung der
Prozesse ein Berechtigungskonzept erstellt und im System realisiert. Die eingerichteten
Profile sind anschliessend in einem umfangreichen Test zu überprüfen.
Nachdem die Aktivitäten der in dieser Phase bearbeiteten Arbeitspakete bereits einzeln
getestet wurden, erfolgt in einem nächsten Schritt die Planung und Durchführung eines
integrativen Abschlusstests (Arbeitspaket "Abschlusstest durchführen"). Gegenstand
dieser Überprüfung ist die Fehlerfreiheit der einzelnen Funktionen und die Einhaltung
der Vorgaben des Soll-Konzepts. Die Basis dazu liefert ein Testkonzept und ein detailliert ausgearbeiteter Testplan. Parallel zur Realisierung der Testfälle erfolgt die Dokumentation der Ergebnisse und daraus die Erstellung eines Abschlussberichts. Bei der
169
Feststellung von Fehlern oder Abweichungen zu den Vorgaben sind Anpassungen und
Korrekturen vorzunehmen bis sich ein einwandfreier Betrieb gewährleisteten lässt. In
einem Abschluss-Review mit den Fachabteilungen und einem Management-Gremium
werden die Ergebnisse des Integrationstests vorgetragen und offene Punkte diskutiert.
Ziel dieses Reviews ist der formelle Abschluss der Phase "Detaillierung und Realisierung".
Im Arbeitspaket "Qualitätsprüfung Anwendungssystem" erfolgt die nochmalige Überprüfung sämtlicher Aktivitäten der "Detaillierung und Realisierung". Diese Qualitätsprüfung umfasst die Tätigkeiten:
• Projektaufbau- und -ablauforganisation überprüfen
• Einhaltung der Projektstandards überprüfen
• Umsetzung Sollkonzept überprüfen
• Schnittstellen- / Systemerweiterungsrealisierung überprüfen
• Berichtssystem überprüfen
• Archivverwaltung überprüfen
• Berechtigungskonzept überprüfen
• Abschlusstest überprüfen
• Projektplanung überprüfen
• Prüfungsprotokoll erstellen.
Über alle Aktivitäten dieses Arbeitspakets wird ein Prüfprotokoll erstellt und dem Lenkungsausschuss zur Genehmigung vorgelegt. Bei Bewilligung des Prüfberichts kann die
Freigabe der nächsten Phase veranlasst werden.
170
4.3.1.4 Produktionsvorbereitung
Nachdem in der Phase "Detaillierung und Realisierung" das Produktionsvorbereitungssystem gemäss den Vorgaben eingerichtet wurde, erfolgt in der folgenden Phase die
Übertragung der Systemeinstellungen in das Produktivsystem und die Schulung der Anwender (vgl. Abb. 4-5). Darüber hinaus werden die Daten aus den bisherigen Anwendungssystemen übernommen und vor der Freigabe wird eine Qualitätsprüfung des Produktivsystems durchgeführt.
• Produktivsetzung vorbereiten
− Konfiguration für das Produktivsystem konkretisieren
− Beschaffung der Systemausstattung durchführen
− Benutzerstammsätze anlegen
− Planung für die Datenübernahme erstellen
• Anwenderdokumentation entwickeln
− Struktur, Inhalt und Medien festlegen
− Erstellung der Anwenderdokumentation vorbereiten
− Änderungskonzept erstellen
− Anwenderdokumentation erstellen
• Produktivumgebung einrichten
− Netzwerk installieren
− Hardware und Software am Arbeitsplatz installieren
− R/3-System im Produktivsystem installieren
• Anwender schulen
− Schulungsprogramm erstellen
− Schulungen vorbereiten
− Schulungen durchführen
• Systemadministration organisieren
− Systemadministration festlegen
− Systemadministratoren schulen
• Daten in das Produktivsystem übernehmen
− Systemeinstellungen und Objekte übernehmen
− Datenübernahme durchführen
− Daten manuell erfassen
− Datenübernahme abnehmen lassen
• Qualitätsprüfung Produktivsystem
− Anwenderdokumentation überprüfen
− Produktivumgebung überprüfen
− Durchgeführte Anwenderschulung überprüfen
− Organisation der Systemadministration überprüfen
− Datenübernahmen überprüfen
Abb. 4-5: Aktivitäten in der Phase "Produktionsvorbereitung".
Das Arbeitspaket "Produktivsetzung vorbereiten" beinhaltet vorwiegend planerische
Aktivitäten. Während der Konkretisierung der Konfiguration des Produktivsystems wird
in Zusammenarbeit mit dem Hardware-Partner die notwendigen Hardwarespezifikationen (Prozessorleistung und Speicherbedarf) aufgrund der Erfahrungen in der vorangehenden Phase festgelegt und die Beschaffung ausgelöst. Gleichzeitig erfolgt die Planung
der Datenübernahme.
171
Im Arbeitspaket "Anwenderdokumentation entwickeln" wird grundsätzlich die Struktur
und die Form der Dokumentation (z.B. Windows Help-File) aufgrund der konkreten
Anwenderbedürfnisse festgelegt. Dabei bedarf es sowohl organisatorischer Regelungen
(Vorgabe von Standards) für den Erstellungsprozess als auch der Berücksichtigung einer
funktionierenden Änderungsverwaltung. Es empfiehlt sich, die Ausarbeitung der Anwenderdokumentation nach den im System eingerichteten Prozessen auszurichten.
Nach Eintreffen der bestellten Hardware erfolgt im Arbeitspaket "Produktivumgebung
einrichten" die Installation des R/3-Systems, die Konfiguration der Netzwerkumgebung
und die Einrichtung der Arbeitsplätze. Damit sind die technischen Voraussetzungen für
die Übertragung der Systemeinstellungen aus dem Produktionsvorbereitungssystem geschaffen und die Anwender haben in technischer Hinsicht Zugriff auf das R/3-System.
Bevor die Anwender die Arbeit am System aufnehmen, muss die Handhabung des Systems bedürfnisgerecht geschult werden (Arbeitspaket "Anwender schulen"). Dazu ist
im Vorfeld ein detailliertes und auf die Anwenderbedürfnisse ausgelegtes Schulungsprogramm zu erstellen. Bei der Gestaltung der Kurse ist es empfehlenswert, die eingerichteten Prozesse als Leitfaden für die Kursgestaltung zu verwenden. Der Zeitpunkt der
Schulung ist so festzulegen, dass die Anwender ihre Arbeit am System unmittelbar nach
Absolvierung der Kurse aufnehmen können.
Im Arbeitspaket "Systemadministration organisieren" wird eine wichtige Voraussetzung
für den reibungslosen technischen Betrieb des Produktivsystems geschaffen. Folgende
Tätigkeiten sind mit der Systemadministration verbunden:
172
• Netzwerkverwaltung
• R/3-Systemprofilpflege
• Monitoring (Computing Center Management System; CCMS)
• Jobverwaltung
• Spoolverwaltung (Printing)
• Backup/Recovery
• Archivierung
• Benutzerpflege.
Die Ausbildung der Systemadministratoren hat im Hinblick auf diese Tätigkeiten zu erfolgen. Zudem muss die Verantwortung für die einzelnen Bereiche eindeutig zugewiesen werden.
Unmittelbar vor der Produktivsetzung erfolgt im Arbeitspaket "Daten in das Produktivsystem übernehmen" die Übertragung der Systemeinstellungen (inkl. R/3-RepositoryObjekte), die Durchführung der automatischen Datenübernahme und bei Bedarf die
manuelle Ergänzung der übernommenen Daten. Vor der Übernahme sind die Quelldaten durch den Fachbereich auf Aktualität und Redundanzfreiheit zu prüfen. Nach der
Übernahme wird zur Gewährleistung einer hohen Datenqualität eine erneute Überprüfung und Abnahme der Datenbestände durch den Fachbereich vorgenommen.
Damit sind alle notwendigen Aktivitäten zur Produktionsvorbereitung ausgeführt und im
abschliessenden Arbeitspaket "Qualitätsprüfung Produktivsystem" werden diese noch
einmal überprüft. Dabei sind folgende Tätigkeiten auszuführen:
• Anwenderdokumentation überprüfen
• Produktivumgebung überprüfen
• Durchgeführte Anwenderschulung überprüfen
• Organisation der Systemadministration überprüfen
• Datenübernahmen überprüfen
• Projektplanung überprüfen
173
Auch von diesen Kontrollen muss ein Prüfprotokoll erstellt und dem Lenkungsausschuss
zur Genehmigung vorgelegt werden. Dieser entscheidet über den Abschluss der Phase
"Produktionsvorbereitung" und erteilt die Freigabe für die nächste Phase.
4.3.1.5 Inbetriebnahme
In der Phase "Inbetriebnahme" erfolgt per Stichtag die operative Aufnahme des Systembetriebs. Die dazu notwendigen Aktivitäten beziehen sich vor allem auf die Betreuung der Anwender zur Gewährleistung eines reibungslosen Betriebs und zur Förderung
der Akzeptanz (vgl. Abb. 4-6). Daneben gilt es, die Nutzung des Systems in technischer
und betriebswirtschaftlicher Hinsicht kontinuierlich zu verbessern.
• Produktivbetrieb unterstützen
− Anwender in der produktiven Anfangsphase betreuen
− Permanente Betreuung durch Help Desk Organisation
festlegen
• Systemnutzung optimieren
− Systemeinsatz überwachen und optimieren
− Anpassungen vornehmen
− Projekt offiziell abschliessen
Abb. 4-6: Aktivitäten in der Phase "Inbetriebnahme".
Im Arbeitspaket "Produktivbetrieb unterstützen" wird der Anwender-Support nach
Produktivstart geregelt. SAP empfiehlt ihren Kunden, für den First-Level-Support eine
Help-Desk-Organisation einzurichten. Für den Second-Level-Support stellt SAP ein Online Support System (OSS) zur Verfügung.171
171
Vgl. Knolmayer (1990).
174
Parallel zur Gewährleistung des Benutzer-Supports dienen die Aktivitäten des Arbeitspakets "Systemnutzung optimieren" zur technischen und betriebswirtschaftlichen Optimierung des Systemeinsatzes. In technischer Hinsicht sind Verbesserungen bezüglich
der Systembelastung durch entsprechende Tuning-Massnahmen vorzunehmen. Auf betriebswirtschaftlicher Ebene gilt es, die Abwicklung der Prozesse zu überwachen und
aufgrund der Anwendererfahrungen zu optimieren. Daraus können Anpassungen der
Systemeinstellungen und der Anwenderdokumentation resultieren.
Ist der Systembetrieb über eine längere Zeitspanne (z.B. 2 Monate) stabil, kann das
Projekt abgeschlossen werden. Der definitive Projektabschluss erfolgt durch die Genehmigung des Projektabschlussberichts. Die Projektorganisation wird aufgelöst und die
Wartung des Systems an eine dafür vorgesehene Organisationseinheit (z.B. Systembetrieb) übergeben.
Für Release-Wechsel und grundlegende Änderungen der Aufbau- oder Ablauforganisation muss eine situativ angepasste Projektorganisation wieder eingerichtet und einzelne
Phasen des dargestellten Vorgehensmodells erneut durchgearbeitet werden.
175
4.3.2 Kritik am SAP-Vorgehensmodell
Die SAP-Vorgehensmodell ist weitgehend in eine Sammlung von Einführungswerkzeugen (Business Engineer) integriert und bietet eine wertvolle Stütze für die Orientierung in
einem R/3-Projekt. Wird von der Voraussetzung ausgegangen, dass die Wahl von R/3
primär aus strategischen Gesichtspunkten getroffen wurde (z.B. Grundsatzentscheid für
den Einsatz von SAP R/3 im ganzen Konzern), dann sind die meisten der nachfolgend
dargestellten Argumente irrelevant. Wird allerdings von einer Situation ausgegangen, in
der eine detaillierte Evaluation durchgeführt wurde, erscheinen einige Aspekte des R/3Vorgehensmodells fragwürdig. Diese werden im folgenden erläutert und ihre Fragwürdigkeit begründet:
• Das SAP-Vorgehensmodell unterstützt im Einführungsprozess nur die nach dem Entscheid für R/3 notwendigen Aktivitäten. Alle für die Evaluation erforderlichen Aktivitäten sind durch das Vorgehensmodell nicht abgedeckt.172 Diesem Umstand ist ein
gewisses Verständnis entgegenzubringen, da ein produktespezifisches Vorgehensmodell den Evaluationsprozess einseitig beeinflussen könnte. Problematisch im diesem Zusammenhang ist die fehlende Integration der Ergebnisse aus dem Evaluationsprozess (z.B. die Berücksichtigung eines vorhandenen Sollkonzepts). Beim Übergang von der Evaluation zur Phase "Organisation und Konzeption" ist in dieser Hinsicht ein Bruch festzustellen. SAP stellt sich auf den Standpunkt, dass die Erstellung
eines detaillierten Soll-Konzepts vor der Produktewahl wenig sinnvoll sei, weil damit
die vorgedachten Strukturen und Abläufe zementiert würden.173 Darüber hinaus bestünde das Problem, dass ein grosser Teil des erstellten Soll-Konzepts durch abweichende Vorgaben von R/3 hinfällig werden könnte. Deswegen wird auf die neutrale
Definition der Geschäftsprozesse (Soll-Konzeption ohne R/3-Bezug) weitgehend verzichtet.174 Demgegenüber ist allerdings anzumerken, dass eine seriöse Evaluation nur
auf der Basis eines detaillierten Soll-Konzepts möglich ist.
172
173
174
Vgl. AFOS (1996), S. 199.
Vgl. Vaske (1996), S. 7.
Kirchmer (1996), S. 60.
176
• Ein weiteres Problem stellt das Defizit des Vorgehensmodells im Hinblick auf Reorganisationsmassnahmen dar.175 SAP legt ihren Kunden nahe, sich möglichst am
Standard zu orientieren und die vorgegebenen Referenzprozesse nur im Rahmen
der Customizingmöglichkeiten zu verändern. Diese Empfehlung zieht in den meisten
Fällen umfangreiche Reorganisationsmassnahmen nach sich. Darüber hinaus wird
die Einführung eines neuen EMS unabhängig davon häufig als Aufhänger für radikale
Reorganisationsmassnahmen genutzt. Trotz der grossen Bedeutung wird diesen
Aspekten im SAP-Vorgehensmodell kaum Beachtung geschenkt. Alternative Vorschläge für das Vorgehen bei der Einführung von EMS berücksichtigen die Durchführung von Reorganisationsmassnahmen wesentlich besser.176
• Die vorgeschlagenen Aktivitäten im SAP-Vorgehensmodell beziehen sich zu einem
wesentlich grösseren Anteil auf die technische als auf die betriebswirtschaftliche Implementierung des R/3-Systems. Die notwendigen Projektmanagement-Aktivitäten
(z.B. Change Management) werden teilweise vernachlässigt oder nur oberflächlich
dargestellt.177 So sind z.B. nur wenige Empfehlungen über die Gestaltung der
Kommunikationsbeziehungen zwischen den Beteiligten, die Projektleiterwahl, die
Beraterwahl oder die Problematik der Anwenderschulung vorhanden. Organisatorische Regelungen und generelle Projektmanagement-Aktivitäten haben einen bedeutenden Einfluss auf den Erfolg eines Projektes178 und deswegen müsste diesen
Aspekten grösseres Gewicht zugemessen werden.
• Bei der Einführung von R/3 ist die Anwendung unterschiedlicher Einführungsstrategien möglich. Grundsätzlich besteht die Wahlmöglichkeit zwischen einer Einführung
sämtlicher zu implementierender Module per Stichtag (Big Bang) und einer schrittweisen Einführung einzelner Module oder Modulblöcke (Step-by-Step). Diese sehr
unterschiedlichen Betrachtungsweisen erfordern ein differenziertes Vorgehen. Eine
entsprechende Berücksichtigung im SAP-Vorgehensmodell fehlt.179
175
176
177
178
179
Barbitsch (1996), S. 56.
Vgl. z.B. Barbitsch (1996), S. 108 ff.
Vgl. Kapitel 4.5.2.
Barbitsch (1996), S. 56; Kirchmer (1996), S. 61.
177
Trotz diesen teilweise erheblichen Einschränkungen ist das Vorhandensein von Gestaltungsempfehlungen für den Einführungsprozess grundsätzlich positiv zu gewichten. Die
Hauptkritik am SAP-Vorgehensmodell richtet sich einerseits auf die stark softwarekonzentrierte Betrachtungsweise des Einführungsprozesses und andererseits auf die eingleisige Darstellungsweise des Vorgehens. Die stärkere Berücksichtigung von Projektmangement-Aktivitäten und die Integration verschiedener Einführungsszenarien würde
den Wert des vorhandenen Vorgehensmodells erheblich steigern.
4.4 Kritische Erfolgsfaktoren bei der Einführung von
SAP R/3
4.4.1 Das Konzept der kritischen Erfolgsfaktoren
Das Konzept der Erfolgsfaktoren wurde im IT-Umfeld erstmals 1961 von Daniel180 diskutiert und 1979 von Rockart181 konkretisiert. Daniel stellte fest, dass in den einzelnen
Branchen in der Regel drei bis sechs Erfolgsfaktoren existieren, welche massgeblich für
den Erfolg eines Unternehmens verantwortlich seien. Herrschen klare Vorstellungen
über diese Erfolgsgrössen, sollen zur Realisierung der Erfolgspotentiale sämtliche Aktivitäten eines Unternehmens auf diese Faktoren ausgerichtet werden.
Ergänzend wies Rockart darauf hin, dass die Informationsverarbeitung durch gezielte
Datenauswertung und -aufbereitung einen wesentlichen Beitrag zur Realisierung dieser
Potentiale leisten kann. Er stellte eine Methode vor, durch welche Manager in die Lage
versetzt werden, ihren Informationsbedarf zur gezielten Überwachung dieser Erfolgsfaktoren selbst zu ermitteln.
180
181
Daniel (1961), S. 111 ff.
Rockart (1979), S. 18 ff.
178
Dieses Konzept lässt sich auf die Einführung neuer Systeme übertragen. In diesem Umfeld geht es darum, jene Einflussgrössen zu ermitteln, welche massgeblich für den Erfolg
von EMS-Einführungsprojekten verantwortlich sind. Die einzelnen Faktoren richten sich
nach verschiedenen Zieldimensionen (Qualität, Kosten und Zeit), und deren Erreichung
erfolgt durch Ausrichtung aller Aktivitäten innerhalb eines Projektes auf diese Erfolgsgrössen.
4.4.2 Mögliche Erfolgsfaktoren bei der Einführung von SAP R/3
Von der Einführung eines integrierten EMS sind in der Regel die meisten betriebswirtschaftlichen Anwendungsbereiche eines Unternehmens betroffen. Durch die in solchen
Systemen vorgegebenen "Best in Practice"-Prozesse entsteht oftmals die Notwendigkeit,
unternehmensspezifisch gewachsene Strukturen und Abläufe anzupassen. Die damit
verbundenen Auswirkungen einer R/3-Einführung auf die verschiedenen Bereiche eines
Unternehmens können erheblich sein. Hinzu kommt, dass oftmals die Erfahrung mit
Softwareprojekten in diesem Ausmass fehlt. Darüber hinaus entsteht beim Scheitern
eines solchen Projektes nicht nur kein Nutzen, sondern u. U. erheblicher Schaden182,
welcher ein Unternehmen existentiell gefährden kann. Unter Berücksichtigung dieser
Faktoren ist es durchaus plausibel, dass R/3-Einführungsprojekte hohe Anforderungen
an das verantwortliche Management stellen und mit einem grossen Risiko verbunden
sein können.
Die Bestimmung der Erfolgsfaktoren für diesen Problembereich soll helfen, den verantwortlichen Managern konkrete Handlungsanweisungen für die erfolgreiche Abwicklung
von EMS-Projekten zu geben. Unter kritischen Erfolgsfaktoren in diesem Zusammenhang werden jene Faktoren verstanden, welche massgebend für den Erfolg eines EMSEinführungsprojektes verantwortlich sind resp. welche bei Nichtbeachtung den Erfolg in
Frage stellen. Dabei wird versucht, den Erfolg an den bereits erwähnten Zieldimensionen Qualität, Kosten und Dauer der Einführung zu messen.
182
Vgl. Ludewig (1994), S. 9.
179
Die Bestimmung dieser Faktoren erfolgt in mehreren Schritten. In einer ersten Phase
werden mögliche Erfolgsfaktoren für die spätere Bewertung eruiert. Die Grundlage dazu
bilden das R/3-Vorgehensmodell, umfangreiche Literaturrecherchen, eigene Erfahrungen mit der Begleitung von Praxisprojekten und der Durchführung studentischer Pilotprojekte sowie eine im Herbst 1994 durchgeführte empirische Voruntersuchung183 zu
Fragestellungen im Zusammenhang mit der Einführung von EMS. Anhand dieser Quellen wurden 21 mögliche Erfolgsfaktoren ermittelt und näher spezifiziert (vgl. Abb. 4-7).
Die im Rahmen dieser Untersuchungen gesammelten Faktoren lassen sich grundsätzlich
in zwei Gruppen einteilen. Auf der einen Seite stehen die eher methodischen und projektmanagementspezifischen Faktoren. Diese beziehen sich generell auf die Vorgehensweisen bei der Einführung von EMS. Auf der anderen Seite stehen die systemtechnischen
Faktoren,
welche
sich
vorwiegend
auf
die
technischen
Aspekte
(Systemarchitektur, Datenhaltung etc.) einer EMS-Einführung beziehen. Im folgenden
werden diese Faktoren anhand dieser Gliederung einzeln dargestellt und anschliessend
auf der Grundlage einer im Herbst 1995 durchgeführten Expertenbefragung184 und einer
nachfolgenden zweiten empirischen Untersuchung bei Schweizer R/3-Anwendern im
Sommer 1996 bewertet.
183
184
Knolmayer/Portner/von Arb 1995.
Vgl. Strebi (1996).
180
1. Einbeziehung des Managements
• Aktive Beteiligung am Einführungsprojekt
• Vertretung im Lenkungsausschuss (Entscheidkompetenzen)
• Abbau von Widerständen aus Chefetagen
2. Klar formulierte Zielsetzungen
• Sachziele, Terminziele, Kostenziele
• Zielformulierung: Messbar und angemessen
• Setzen von Zwischenzielen
• Projektcontrolling
3. Change Management
• Aktive Gestaltung des Einführungsprozesses
• Information aller Beteiligten (Aufklärung)
• Aktiver Einbezug der Betroffenen
• Intensive Schulung der Endanwender
4. Umgestaltung der Geschäftsprozesse
• Nutzung des EMS als Katalysator für das BPR
• Überdenken bestehender Geschäftsprozesse
• Kundenorientierung
5. Vertragsgestaltung
• Klare Regelung der Verantwortlichkeiten
• Einbezug von Handlungsspielräumen
• Keine übertriebenen Sanktionsmassnahmen
6. Intensität der Evaluation
• Schwachstellen-Analyse
• Soll-Konzept/Kriterien-Katalog
• Kosten-/Nutzen-Analyse
7. Auswahl der Beratungspartner
• Fachliche Kompetenz (ausgewiesene Erfahrung)
• Branchenkenntnis
• Soziale Kompetenz
• Methodenwissen
8. Staffelung der Einführung
• Step-by-Step
• Einführung einzelner Modulblöcke
• Big Bang
9. Projektleiter
• Fachkenntnis
10. Projektorganisation
• Teambildung (Auswahl der Projektmitarbeiter)
• Regelung der Aufgaben und Verantwortlichkeiten
• Regelung der Kommunikationswege
11. Steuerungsausschuss
• Überwachung der Projektziele
• Schlichtungsstelle bei Konflikten
• Entscheidinstanz bei fachabteilungsübergreifenden Fragen
12. Methodisches Vorgehen
• Verwendung eines Vorgehensmodells
• Einsatz von Referenzmodellen
• Einsatz von Softwareunterstützungswerkzeugen
(z.B. ARIS-Toolset)
13. Kommunikation
• Organisation der Kommunikationswege
• Umfassende Information der Betroffenen
• Aktive Information des verantwortlichen Managements
14. Know-how-Transfer
• Gezielter Know-how-Transfer zwischen Berater und
Projektmitarbeiter
• Dokumentation
15. Dokumentation
• Dokumentation der Geschäftsprozesse
• Dokumentation der Systemeinstellungen
• Einsatz von Dokumentationswerkzeugen
16. Schulung der Anwender
• Schulung an einem unternehmensspezifisch angepassten
System mit Kopien von betrieblichen Echtdaten
• Schulungsinhalte richten sich nach den
Geschäftsprozessen
• Schulung ausserhalb der gewohnten Arbeitsumgebung
(Distanz zum Arbeitsplatz)
17. Gestaltung der Systemarchitektur
• Grosszügige Auslegung der Systemarchitektur (Einplanung
von Reserven zur Vermeidung von PerformanceProblemen)
• Outsourcing
• Trennung von Test- und Produktivsystem
18. Schnittstellen zu existierenden IS
• Reduzierung der Zahl der Schnittstellen auf ein absolutes
Minimum
• Temporäre Schnittstellen
• Auf Dauer angelegte Schnittstellen
• Berücksichtigung bei der Release-Planung
19. Release-Planung
• Kosten-/Nutzen-Analyse
• Berücksichtigung der Hardwareanforderungen
• Berücksichtigung der vorgenommenen Erweiterungen
• Möglichst nahe am Standard
20. Datenmigration
• Erhaltung resp. Steigerung der Datenqualität
• Automatische vs. manuelle Datenübernahme
• Schnittstellenproblematik
21. Umfassende Planung des Betriebs
• Anwender-Support
• Parallelbetrieb
• Krisenmanagement (Datensicherheit, Hochverfügbarkeit
der Systeme)
• Feintuning des Systems
Abb. 4-7: Mögliche Erfolgsfaktoren bei der Einführung von SAP R/3.
181
4.4.3 Methodische Faktoren
Einbeziehung des Managements
Durch die starke Ausdehnung eines EMS über mehrere Funktionsbereiche hinweg
(Integration von Rechnungswesen, Logistik und Personalwesen) und die oft erforderliche Anpassung bestehender Prozesse (Business Process Reengineering) ist eine aktive
Beteiligung des verantwortlichen Managements unumgänglich. Neben den Aufgaben
der Zielformulierung und der Projektüberwachung ist zusätzlich die Unterstützung der
Projektleitung durch das verantwortliche Management eine tragende Säule für den
Projekterfolg.185 Dieser aktive Einbezug hat vor allem folgende Vorteile:
• Das Projekt erhält durch die aktive Beteiligung des verantwortlichen Managements
die notwendige Durchsetzungskraft bei fachabteilungsübergreifenden Fragen.
• Entscheide über organisatorische Anpassungen können unmittelbar getroffen werden
und werden nicht unnötig verzögert.
• In Streitfragen steht ein Gremium zur Konfliktlösung zur Verfügung.
Die organisatorische Einbettung des verantwortlichen Managements in ein EMS-Projekt
wird in der Regel über den Einsitz im Lenkungsausschuss wahrgenommen. Dieser ist für
die Erfüllung der oben dargestellten Aufgaben verantwortlich. Darüber hinaus erscheint
es sinnvoll, den Projektleiter mit den für die Realisierung des Projekts erforderlichen
Kompetenzen auszustatten.186 Dadurch ist die Kontinuität des Projektfortschritts gewährleistet und die Geschäftsleitung kann sich auf die wesentlichen Fragestellungen
konzentrieren.
185
186
Vgl. dazu Bernner (1990), S. 14; Meister (1990), S. 37; Grupp (1987), S. 70.
Vgl. AFOS (1996), S. 45.
182
Empirische Untersuchungen zeigen aber, dass dieser aktive Einbezug nur in den wenigsten Fällen in ausreichendem Masse vorhanden ist (vgl. Abb. 4-8). 77% der Befragten
einer empirischen Untersuchung aus dem Jahre 1996 gaben an, dass sich die Geschäftsleitung nur einmal im Monat oder noch seltener über den Projektstand informiert. In diesen Fällen kann kaum von einer aktiven Beteiligung des verantwortlichen
Managements gesprochen werden.187
Information des Topmanagements über
R/3-Einführungsprojekte
seltener
21.3%
täglich
3.2%
monatlich
56.4%
w öchentlich
19.1%
Quelle: Cap Gemini
Abb. 4-8: Einbeziehung des Managements in R/3-Einführungsprojekte
Besonders nachteilig auf EMS-Projekte wirken sich Widerstände aus den Reihen der
Betroffenen und aus den Chefetagen aus. Diese sind oftmals auf eine unzureichende
Informationspolitik des Projektmanagements zurückzuführen. Fehlt der Managementeinbezug in solchen Situationen, ist das Projekt praktisch zum Scheitern verurteilt, weil
kaum Möglichkeiten vorhanden sind, diese Widerstände abzubauen.
Klar formulierte Zielsetzungen
Klar formulierte Zielsetzungen sind die Basis für den Erfolg jedes Einführungsprojektes.
Das Gesamtprojekt sollte in zeitlich gestaffelte Ziele untergliedert sein, damit auch Teil-
187
Vgl. Vaske (1996).
183
erfolge gemessen werden können. Dabei können folgende Zielgruppen unterschieden
werden:
• Sachziele (Was soll erreicht werden?)
• Terminziele (In welchem zeitlichen Rahmen sollen die Sachziele erreicht werden?)
• Kostenziele (Welches Kostendach soll bei einer Einführung nicht überschritten werden?).
Change-Management
Die mit der Einführung verbundenen Änderungen der Organisation und der Arbeitsabläufe führen innerhalb der Belegschaft oft zu Unruhe und unbegründeten Ängsten, die
sich durch mangelnde Motivation, Widerstand gegenüber neuen Techniken oder gar
Sabotage des neuen Systems ausdrücken können. Die Geschäftsleitung hat die Möglichkeit, der Angst und Unsicherheit durch folgende Massnahmen entgegenzuwirken:
• Rechtzeitige und offene Information aller Betroffenen, um ein Klima des Vertrauens
zu schaffen
• Aktiver Einbezug der Mitarbeiter bei der Gestaltung des neuen Systems
• Frühzeitige und genügend umfangreiche Schulung vorsehen.188
188
Vgl. CSF "Schulung der Anwender"
184
Umgestaltung der Geschäftsprozesse (BPR)
Der Nutzen eines neuen EMS hängt stark davon ab, wie das Unternehmen seine Prozesse auf die Möglichkeiten des Informationssystems abstimmt. Die Kundenorientierung
steht dabei im Fokus der Reengineering-Aktivitäten. Darunter fallen beispielsweise Erfolgsfaktoren wie Qualität, Serviceleistungen, Kosten und Zeit.189 Durch die Möglichkeiten und Grenzen eines EMS wird ein relativ verbindlicher Rahmen zur Gestaltung
von Geschäftsprozessen vorgegeben. In den meisten Fällen existieren in einem EMS
mehrere Varianten für die Abbildung eines realen Ablaufes. Auf der Basis dieser Möglichkeiten muss festgelegt werden, welche Variante die eigenen Bedürfnisse am besten
abdeckt. Für die Art und Weise des Zusammenspiels zwischen Business Process Reengineering (BPR) und Einführung eines neuen EMS sind verschiedene Varianten denkbar
(vgl. Abb. 4-9). Grundsätzlich muss unterschieden werden, ob das BPR durch die EMSEinführung oder von dritter Seite (z.B. durch die Geschäftsleitung initiiert wurde.
Reine ProzessAutomation
Jump Start
Implementation
Zweiphasige
Einführung
R/3-Einführung auf der
Basis bestehender Prozesse
Lean R/3Implementation
BPR
EMS-Implementierung
BPR
Parallele
Einführung
Gleichzeitige EMS
getriebene Umsetzung
BPR durch permanente
Systemverbesserung
EMS-Implementierung
Softwarebased
Ideal Design
BPR
EMSImplementierung
Abb. 4-9: BPR-Varianten bei der Einführung von EMS.190
189
190
Vgl. Brenner/Keller (1995), S. 18.
Vgl. Boll (1996).
185
Die Wahl der richtigen Variante hängt im wesentlichen davon ab, welche Veränderungen ein Unternehmen verkraften kann und welche zeitlichen Rahmenbedingungen für
diese Veränderungen vorhanden sind. In einer empirischen Studie, in welcher 220 R/3Einführungsprojekte in Europa untersucht wurden, bezeichneten 83% aller Befragten
ein BPR im Rahmen einer R/3-Einführung als sinnvoll. Dabei war in 45% der Fälle das
R/3-Projekt der Auslöser für die BPR-Massnahmen.191
Diese relativ deutliche Stellungnahme zugunsten flankierender BPR-Massnahmen während EMS-Projekten ist durch die oft notwendige und auch sinnvoll erscheinende Anpassung betrieblicher Abläufe an die weitgehend optimierten Standardprozesse von
EMS begründet. Nur in Ausnahmefällen, z.B. bei Zeitknappheit und hohem Anpassungsbedarf, ist von einer direkten Kombination dieser beiden Faktoren abzusehen. Ansonsten bietet sich die Einführung eines EMS als Chance geradezu an, gewachsene
Strukturen und Abläufe zu überdenken und besser auf die wirtschaftlichen Ziele des
Unternehmens auszurichten.
Vertragsgestaltung
In einem R/3-Einführungsprojekt sind neben der SAP in der Regel noch weitere Partner
(Beratungspartner, Hardwarelieferanten, Lieferanten von Umsystemen etc.) involviert.
Dabei müssen die Verantwortungsbereiche und Aufgabenstellungen der einzelnen Partner klar definiert und abgegrenzt sein. Wenn möglich, sollte ein Partnerunternehmen
die Gesamtverantwortung für das Einführungsprojekt als Generalunternehmer übernehmen. Die Verantwortlichkeiten und die Abgrenzung der Aufgabenbereiche müssen
vertraglich geregelt sein, damit grössere Konflikte von vornherein vermieden werden
können. Bei folgenden allgemein bekannten Problembereichen aus EMS-Projekten ist
eine Berücksichtigung bei der Vertragsgestaltung besonders empfehlenswert:
191
Vgl. Buxmann/König (1996), S. 164.
186
• Mangelhafte Vorgaben durch unvollständige Leistungsbeschreibung, verursacht
durch Zeitnot und Mangel an Kenntnissen
• Performance-Probleme durch zu knapp bemessene Hardwareressourcen, verursacht durch die stetig steigenden Hardwareanforderungen
• Zeitverzögerungen durch fehlende Präsenz und mangelnde Ausbildung der Berater,
verursacht durch Überlastung und fehlende Zeit für Weiterbildung
• Zeitverzögerung durch mangelnde Mitwirkung der Anwender, verursacht durch unzureichende Freistellung vom Tagesgeschäft
• Verminderung von Gewährleistungsansprüchen und Zusatzaufwendungen bei auftretenden Fehlern, verursacht durch Eingriffe in den Quellcode.
In Kenntnis dieser möglichen Konfliktpotentiale sollte bei der Vertragsgestaltung darauf
geachtet werden, dass eine Mischform zwischen akribischer Regelung aller Details und
Beibehaltung eines Handlungsspielraums gefunden wird. Zu detaillierte Verträge verursachen einen unnötig hohen Gestaltungsaufwand und damit verbunden hohe juristische
Beratungskosten. Darüber hinaus wird durch übertriebene Sanktionsmöglichkeiten das
Vertrauensverhältnis zwischen den Vertragspartnern unnötig belastet. Durch offene
Kommunikation und beidseitiges Verständnis können Konflikte besser beseitigt werden
als durch zeitraubende und kostspielige gerichtliche Auseinandersetzungen.
Durch eine vernünftige Vertragsgestaltung können demnach Konfliktpotentiale abgebaut
und gute Voraussetzungen für eine zeit- und kostensparende Projektabwicklung geschaffen werden.
187
Intensität der Evaluation
Durch die Evaluation verschiedener EMS soll sichergestellt werden, dass das gewählte
System die betrieblichen Abläufe möglichst gut unterstützt und gleichzeitig das beste
Kosten-/Nutzenverhältnis bietet. Ein mögliches Vorgehen zur Bestimmung des am besten geeigneten Systems sei im folgenden kurz dargestellt:192
Für die Evaluation von EMS ist es grundsätzlich ratsam, einen unabhängigen Beratungspartner beizuziehen, welcher aus unabhängiger Sicht die in Frage kommenden Systeme
untersucht und bewertet. Dabei empfiehlt es sich, das ausgewählte Beratungsunternehmen nur für die Evaluation einzusetzen und die gegebenenfalls nachfolgend notwendige Einführungsunterstützung einem anderen Unternehmen überlässt, damit die
Beeinflussung des Auswahlprozesses weitgehend verhindert werden kann.
Zu Beginn des Evaluationsprozesses muss eine Ist-Analyse gemacht und ein besonderes
Augenmerk auf die vorhandenen Schwachstellen gelegt werden. Die existierenden Prozesse sind dabei nur grob zu analysieren, damit nicht die Gefahr besteht, dass durch
eine allzu genaue Analyse der Ist-Zustand bereits in dieser Phase zementiert wird.
Ausgehend von den Ist-Prozessen und der vorgenommenen Schwachstellenanalyse
muss ein Soll-Konzept erstellt werden. Dieses soll ebenfalls den gewünschten Zustand
nur in groben Zügen umreissen, damit ein gewisser Spielraum für die Umsetzung der
Prozesse in einem EMS besteht. Die Art und Weise der Durchführung der Reengineering-Aktivitäten wird grundsätzlich beurteilt.193
192
193
Vgl. Brenner (1990), S. 9 ff.
Vgl. Stahlknecht (1995), S. 315; Vaske (1996), S. 7; Kapitel. 2.3.2.
188
Aus dem Soll-Konzept resultiert ein Kriterienkatalog (vgl. Abb. 4-10), welcher MussKriterien und Kann-Kriterien enthält. Auf der Basis dieses Kriterienkatalogs erfolgt nun
die Bewertung der am Markt befindlichen Systeme. In einer Vorselektion werden die
verschiedenen Systeme auf die Erfüllung der Muss-Kriterien (K.O.-Kriterien) überprüft.
Anschliessend folgt eine detaillierte Evaluation von 2 bis 3 Produkten mit ausführlicher
Messung der übrigen Kriterien. Die Bewertung der einzelnen Kriterien kann z.B. in Form
einer Nutzwertanalyse erfolgen.
• Leistungsumfang
− Daten, Funktionen
− Integrationsgrad
− Anpassungsaufwand
• Konzeption des EMS
− Basisarchitektur
− Benutzerfreundlichkeit
− Performance
− Dokumentation (Benutzerdokumentation,Technische Dokumentation)
− Weitere Softwarekomponenten
(Data Dictionary, Referenzmodelle, Einführungsunterstützungswerkzeuge, Office-Komponenten, etc.
• Erfahrungen von Anwendern
− Fachliche Erfahrungen
− Branchenbezogene Erfahrungen
− Länderbezogene Erfahrungen
− Herstellerbezogene Erfahrungen
• Lieferant
− Stellung des Lieferanten am Markt
− Qualifikation der Mitarbeiter des Lieferanten
− Zusatzleistungen des Anbieters (Beratung,
Schulung)
• Kosten/Nutzen-Relation
− Anschaffungskosten (Lizenzen)
− Einführungskosten
− Hardwarekosten
− Betriebs- und Wartungskosten
Abb. 4-10: Mögliche Evaluationskriterien für die Bewertung von EMS.194
194
Vgl. Brenner (1990), S. 15 ff.
189
Wahl der Beratungspartner
Die Wahl des Beratungspartners und damit verbunden die Qualität und Kompetenz der
Beratungsdienstleistungen können einen entscheidenden Einfluss auf die Qualität, die
anfallenden Kosten und Dauer eines EMS-Einführungsprojektes haben. Aus diesen
Gründen muss eine Auswahl sorgfältig erfolgen und sich an verschiedenen Gesichtspunkten orientieren.
Bezüglich der Beratungssituation kann zwischen Unterstützungsberatung zur Evaluation
verschiedener EMS und der konkreten Beratung bei der Einführung eines bestimmten
Produktes unterschieden werden. Für beide Arten der Beratung empfiehlt es sich, spezialisierte Beratungsunternehmen beizuziehen. Zur Unterstützung der Evaluation sollte
eher ein herstellerunabhängiges, also neutrales Beratungsunternehmen und für die Einführungsunterstützung ein Beratungspartner mit entsprechendem Produkt-Know-how
gewählt werden. Die folgenden Ausführungen beziehen sich auf den letzteren Fall. Die
Wahl eines Beratungspartners für die Einführungsunterstützung könnte beispielsweise
aufgrund der nachstehenden Kriterien erfolgen:
• Fachliche Kompetenz (ausgewiesene Erfahrung, überdurchschnittliches Wissen)
• Branchenkenntnisse
• Methodenwissen.
Fachliche Kompetenzen, welche sich vor allem auf Erfahrungen mit dem Einsatz des
entsprechenden Systems beziehen, und entsprechende Branchenkenntnisse stellen
wichtige Voraussetzungen für eine erfolgreiche Zusammenarbeit dar. Das BeraterKnow-how sollte sowohl theoretische Kenntnisse zum EMS umfassen als auch auf ausgewiesenen praktischen Erfahrungen aus verschiedenen Projekten beruhen.
Die Zusammenarbeit mit den Beratungspartner kann auf unterschiedliche Weise erfolgen. Die verschiedenen Formen der Zusammenarbeit unterscheiden sich vor allem
durch den Grad des Know-how-Transfers an die eigenen Mitarbeiter (Knowledge Ma-
190
nagement). Beim Coaching-Ansatz steht der Know-how-Transfer im Vordergrund, beim
klassischen Berateransatz die Implementierung des Systems. Ein Know-how-Transfer
findet bei letzterer Konzeption statt, steht aber nicht im Zentrum des Interesses. Bei der
Auslieferung von schlüsselfertigen Gesamtlösungen (Configure-to-order- Ansatz195) findet kaum ein Know-how-Transfer statt. Das Hauptinteresse gilt dem einwandfrei funktionierenden System.
Vor diesem Hintergrund müssen den Zielsetzungen entsprechend die richtigen Beratungspartner gefunden werden. Die Beraterqualität ist bei der Auswahl stärker zu gewichten als die damit verbundenen Kosten, denn durch den Einsatz von gut qualifizierten Beratern lässt sich die Projektabwicklung in der Regel qualitativ und in zeitlicher
Hinsicht positiv beeinflussen.
195
Vgl. Schroeder (1997); Haendly (1997).
191
Staffelung der Einführung
Bei der Einführung von R/3 lassen sich grundsätzlich zwei verschiedene Einführungsstrategien unterscheiden (vgl. Abb. 4-11). Auf der einen Seite steht die schrittweise Einführung (Step-by-Step-Einführung) einzelner Module oder kleiner Modulblöcke (z.B.
FI/CO). Alternativ dazu kann das ganze System oder ein grösserer Modulblock (z.B.
FI/CO/MM/SD) per Stichtag (Big Bang) eingeführt werden.
vs.
Step-by-Step
Big Bang
l Voraussetzung
n
n
überschaubare Unternehmenseinheit
volle Unterstützung
durch die Geschäftsleitung
l Höheres Risikobewusstsein
l Kapazitätsbedarf für Projektteam (hohe Anforderungen)
l Vorlaufzeit für Konzeption und
Schulung
l Konsequente Ablösung alter
Vorgehensweisen
l Schnellerer ROI
l Bevorzugte Lösung bei
grösseren Organisationen
l Geringere Kapazitätsprobleme
l Schnellere Teilerfolge
l Fehlende Integration durch
1:1-Abbildung der Abläufe
l Know-how-Transfer
(Schrittweises Vertrautwerden mit
dem Gesamtsystem)
l Organisatorische Zwischenlösungen
l Vorübergehend wirksam
werdende Schnittstellen
(Boll 1994)
Abb. 4-11: Big Bang vs. Step-by-Step-Einführung.196
Während bei der Step-by-Step-Einführung zur Implementation von Geschäftsprozessen
bei jedem Einführungsschritt ein besonderes Augenmerk auf die Nahtstellen der einzelnen Prozesse gelegt werden muss, damit sich die Durchgängigkeit gewährleisten lässt,
196
Vgl. Boll (1994).
192
können solche Integrationsprobleme bei einer Big-Bang-Einführung weitgehend vermieden werden.197 Die Fokussierung der Einführung auf zusammenhängende Geschäftsprozesse (Prozessorientierung) ist demzufolge bei einem Big Bang besser realisierbar. Voraussetzung für eine erfolgreiche Implementierung des R/3-Systems per
Stichtag ist allerdings die Überschaubarkeit der betroffenen Unternehmenseinheiten
und das Vorhandensein von ausreichenden Personalressourcen. Neben der höheren
Prozessintegration ist auch der Wegfall von temporären Schnittstellen und organisatorischen Zwischenlösungen bei einem Big Bang positiv anzuführen. Trotz dieser einleuchtenden Vorteile ist die Gesamteinführung per Stichtag mit einem erheblich höheren Risiko verbunden und nur realisierbar, wenn die Geschäftsleitung voll und ganz hinter
dieser Einführungsstrategie steht. In dieser Hinsicht bietet eine schrittweise Einführung
grössere Sicherheit.
Projektleiter
Der Projekterfolg wird massgeblich vom Persönlichkeitsprofil und vom Know-how des
Projektleiters mitbestimmt.198 Als Drehscheibe in einem EMS-Projekt muss dieser zur
Koordination und Steuerung des Projektes sowohl über fachliche Fähigkeiten als auch
über ausgeprägte soziale Kompetenzen (Souveränität, Verhandlungsgeschick, Durchsetzungsvermögen, natürliche Autorität etc.) verfügen. Ausserdem erfordert der Umfang
eines EMS-Projektes in den meisten Fällen eine vollständige Freistellung des Projektleiters (100%) von seinen übrigen Aufgaben.199 Auf fachtechnischer Ebene wird häufig die
Auffassung vertreten, dass in EMS-Projekten die Kenntnis der unternehmensinternen
Abläufe einen höheren Stellenwert einnimmt als das benötigte informationstechnische
Know-how. Daher wird oft empfohlen, den Projektleiter aus dem Fachbereich zu rekrutieren.200 Ein mögliches Profil für einen R/3-Projektleiter wird in Abb. 4-12 dargestellt.
197
198
199
200
Vgl. z.B. Kölle (1990), S. 48; Meister (1990), S. 38.
Vgl. Hüttenhain (1990), S. 134; Kupper (1988), S. 55; vgl. auch SAP (1996a), R/3-Customizing:
Vorgehensmodell, Abschnitt: Projektorganisation festlegen.
Vgl. z.B. Mertens/Knolmayer (1995), S. 81.
193
Merkmal
geringe
Bedeutung
mittlere
Bedeutung
hohe
Bedeutung
Verhandlungsgeschick
Kommunikationsfähigkeit
Motivationsfähigkeit
Entscheidungskraft und Durchsetzungsvermögen
Flexibilität und Weitsicht
Delegationsfähigkeit
Hohe Frustrationsgrenze
Vollständige Freistellung für das Projekt (100%)
Kenntnisse der eigenen Organisation
EDV-Kenntnisse
R/3-Kenntnisse
Abb. 4-12: Mögliches Anforderungsprofil an einen R/3-Projektleiter.
Projektorganisation
Die Projektaufbauorganisation muss primär den Gegebenheiten des betreffenden Einführungsprojektes Rechnung tragen. Dabei sind neben der Auswahl des Projektleiters
folgende Aspekte zu berücksichtigen:
• Einrichtung eines Lenkungsausschusses
• Bestimmung der Projektgliederung (Teilprojekte)
• Auswahl der Projektmitarbeiter.
Die Merkmale eines schlagkräftigen Lenkungsausschusses werden im nachfolgenden
Abschnitt behandelt.
Auf der Grundlage der Zerlegung der Geschäftsprozesse in überschaubare Teilprozesse
wird das Gesamtprojekt in Teilprojekte untergliedert. Die Abgrenzung der Teilprozesse
194
richtet sich nach dem möglichen Bearbeitungsvolumen eines Teilprojektteams von drei
bis sieben Mitgliedern.201
Bei der Auswahl der Projektmitarbeiter sind verschiedene Gesichtspunkte zu berücksichtigen. Neben Fachkenntnissen und entsprechender Flexibilität wird für die Einführung von betriebswirtschaftlichen Anwendungssystemen häufig gefordert, dass Projektmitarbeiter ein umfangreiches Wissen über die Abwicklung der Geschäftsprozesse benötigen und die Anforderungen einzelner betrieblicher Funktionsbereiche im Detail
kennen. Diese Ansprüche können in der Regel nur durch Einbezug von Mitarbeitern aus
den entsprechenden Fachabteilungen erfüllt werden.202
Ferner gilt es zu beachten, dass die ausgewählten Projektmitarbeiter ausreichend vom
Tagesgeschäft freigestellt werden. Eine vernünftige Untergrenze der Freistellung wird in
der Praxis auf rund 40% geschätzt.203 Unter diesem Wert entsteht ein Missverhältnis
zwischen produktiven und koordinativen Tätigkeiten. Ein höherer Freistellungsgrad ist
grundsätzlich wünschenswert, weil dadurch die Anzahl der am Projekt beteiligten Personen niedrig gehalten und ein überproportionaler Koordinationsaufwand verhindert
werden kann.
Lenkungsausschuss
Der Lenkungsausschuss steht in der Hierarchie über dem Projektleiter und den einzelnen Projektgruppen. Hauptaufgabe des Lenkungsausschusses ist die Zielformulierung,
die Fällung von Grundsatzentscheiden die Genehmigung der Phasenergebnisse und
generell die Überwachung des Projektes.204 Eine besonders wichtige Funktion nimmt
der Lenkungsausschuss als Schlichtungsstelle bei unüberwindbaren Meinungsverschiedenheiten wahr.205
201
202
203
204
205
Vgl. Lehner (1991), S. 526 f.
Vgl. z.B. Balmer/Mirchandani (1996); Gantenbein (1990), S. 77; Grupp (1987), S. 53; Mertens/Knolmayer (1995), S. 82.
Vgl. Balmer/Mirchandiani (1996); Grupp (1987), S. 52.
Litke (1995), S. 71.
Vgl. CDI (1996), S. 242.
195
Zur Erfüllung dieser Anforderungen ist es von Bedeutung, dass in einem Lenkungsausschuss Personen mit entsprechendem Fach-Know-how und den zur Entscheidfällung
notwendigen Kompetenzen (Mitglieder der Geschäftsleitung) vertreten sind.206 Je nach
Aufgabenstellungen können in Ausnahmefällen auch Entscheidträger eines externen
Beratungsunternehmens im Lenkungsausschuss mitwirken. Ausserdem ist für die Schlagkraft eines Lenkungsausschusses wichtig, dass dieser aus nicht zu vielen Mitgliedern besteht.
Methodisches Vorgehen
Zur Reduktion der Komplexität und Unsicherheit eines R/3-Einführungsprojektes empfiehlt sich der Einsatz von methodischen Hilfsmitteln. Ähnlich wie bei der Softwareentwicklung kann der Ablauf der Einführung eines EMS und die Implementierung der Geschäftsprozesse durch methodische Unterstützung besser strukturiert und systematisiert
werden. Im Rahmen einer R/3-Einführung stehen u.a. folgende Hilfsmittel zur Verfügung:
• Einsatz von Vorgehensmodellen: Vorgehensmodelle stellen das von einem konkreten Projekt abstrahierende Vorgehen dar. Sie zeigen auf, wie der zeitliche Ablauf
von Aufgaben einer Einführung sinnvoll zu untergliedern ist. Neben dem SAPVorgehensmodell existiert eine grosse Zahl weiterer Vorgehensmodelle zur Einführung von EMS, welche entweder in der Literatur vorgeschlagen oder von Beratungsunternehmen propagiert werden.
• Einsatz von Referenzmodellen: SAP stellt für den Einführungsprozess ein Referenzmodell als Hilfestellung für die Gestaltung der Geschäftsprozesse zur Verfügung.
Darüber hinaus können bei der Erstellung des Soll-Konzepts auch herstellerunabhängige branchenspezifische Referenzmodelle verwendet werden, durch welche eine neutrale Definition der Geschäftsprozesse möglich ist.
• Einsatz von Softwareunterstützungswerkzeugen: Bei einer R/3-Einführung lassen
sich unterschiedliche Tools einsetzen. Für das Design und die Simulation von Ge-
206
Vgl. Kölle (1990), S. 48; vgl. auch Meister (1990), S. 37.
196
schäftsprozessen können Prozessbeschreibungs- und -simulationswerkzeuge (z.B.
ARIS-Tools, Visio, Intellicorp LiveModel) eingesetzt werden. Für die Unterstützung
der Projektmanagementaktivitäten steht eine breite Palette von entsprechenden
Werkzeugen (z.B. MS-Project) zur Verfügung. Darüber hinaus können z.B. Upper
CASE Tools, Data Dictionary-Werkzeuge oder auch Office Pakete zur methodischen
Unterstützung des Einführungsprozesses eingesetzt werden.
Kommunikation
Da R/3-Projekten meist eine sehr komplexe Projektorganisation zugrunde liegt und oftmals weite Teile des Unternehmens und zusätzlich externe Stellen von einer Einführung
betroffen sind, muss die Kommunikation zwischen allen direkt und indirekt Beteiligten
geregelt werden. Grundsätzlich werden damit verschiedene Zielsetzungen verfolgt. Einerseits soll durch klar definierte Kommunikationsbeziehungen die Koordination des
Projektes erleichtert und andererseits durch eine offene Informationspolitik möglichen
Widerständen der späteren Anwender oder des verantwortlichen Managements entgegengewirkt werden. Ein weiterer Aspekt stellt die zielgerichtete Regelung des Knowhow-Transfers zwischen Beratern und den später für das System verantwortlichen Mitarbeitern dar (Knowledge-Management).
Zur Erfüllung dieser Zielsetzungen sind organisatorische Regelungen (wer informiert wen
über was und zu welchem Zeitpunkt?) zu treffen, dafür geeignete Kommunikationsmittel (E-Mail, Info-Board, Hauszeitungen, etc.) einzurichten und durch verschiedene Formen von Meetings (Workshops, Sitzungen, Informationsveranstaltungen) eine Institutionalisierung des Informationsaustausches herbeizuführen.
197
Dokumentation
Ähnlich wie bei der Dokumentation von Individualsoftware werden auch mit der Dokumentation von EMS wesentliche Voraussetzungen für die spätere Wartbarkeit und
den erfolgreichen Einsatz des Systems geschaffen. Diesem Aspekt wird in der Praxis oft
zu wenig Beachtung geschenkt.207
Die Dokumentation aller technischen und betriebswirtschaftlichen Einstellungen fördert
die Transparenz und erleichtert die Handhabung des Systems. Bei plötzlich auftretenden Fehlern lassen sich die Ursachen eher ermitteln, weil eine Veränderung der Customizing-Einstellungen (z.B. durch ein anderes Projekt) nachvollziehbar ist.
Neben der Dokumentation der Systemeinstellungen ist vor allem die Dokumentation
der Geschäftsprozesse als Vorgabe für die Projektabwicklung und als Hilfsmittel für die
Anwenderschulung wichtig. Anhand der Dokumentation der Geschäftsprozesse werden
während der Realisierung des Projekts Schulungsunterlagen erstellt, eine Online-Hilfe
implementiert und eine ausführliche Anwenderdokumentation erstellt.
Dafür können sehr unterschiedliche Werkzeuge eingesetzt werden. Die Dokumentation
der Customizing-Einstellungen erfolgt weitgehend im System selbst (direkt im Einführungsleitfaden und durch die Einbindung von Word-Dokumenten). Die Integration der
Dokumentation in das System hat den Vorteil, dass neben der einheitlichen Strukturierung, eine Kontrolle des Dokumentationsstandes jederzeit möglich ist.
Für die Erstellung der Online-Hilfe und der Anwenderdokumentation werden in der
Regel Hyperlink-Systeme (z.B. HTML-Editoren, Win-Help-File-Generatoren) und herkömmliche Textverarbeitungssysteme (z.B. MS-Word, Adobe Acrobat) eingesetzt.
Wichtig für eine einheitliche Dokumentationsform ist die Vorgabe eines einheitlichen
Standards. Für die graphische Illustration von Geschäftsprozessen eignet sich der Einsatz
von Modellierungswerkzeugen (z.B. ARIS-Toolset, Visio).
207
198
Schulung der Anwender
Der Nutzen eines gut eingerichteten Produktivsystems ist nur so gross, wie die Anwender über die vorgesehene Abwicklung der Geschäftsprozesse im System unterrichtet
sind und seine Handhabung kennen. Daher ist für einen reibungslosen Produktivstart
ein grosses Augenmerk auf die Anwenderschulung zu richten.
Die Orientierung der Schulung an durchgängigen Geschäftsprozessen ist der ausschliesslichen Schulung von Einzelfunktionen vorzuziehen. Dabei gilt es zu beachten,
dass sich das vermittelte Beziehungswissen weitgehend auf die für die Tätigkeit des Arbeitnehmers relevanten Arbeitsbereiche beschränkt und wenn möglich keine "Ausbildung auf Vorrat" betrieben wird.
Bei der Konzeption der Endanwenderschulung sind verschiedene Aspekte zu berücksichtigten. Wichtig ist die richtige Wahl des Schulungszeitpunkts. Endanwender sollten
wenn möglich unmittelbar nach Absolvierung der Schulungsveranstaltungen die Arbeit
am System aufnehmen können, damit eine möglichst gute Umsetzung des vermittelten
Wissens erreicht werden kann. Diese Zielsetzung steht aber in starker Konkurrenz zu
den begrenzten zeitlichen Ressourcen der späteren Anwender sowie dem hohen zeitlichen Auslastungsgrad der mit der Durchführung der Schulung betrauten internen Projektmitarbeiter. Weitere Probleme können die umfassende Funktionalität des entsprechenden Systems, die Wahl einer ungeeigneten Schulungsart, Wirtschaftlichkeitsaspekte
bezüglich der Durchführung von Schulungsveranstaltungen und allenfalls vorhandene
kundenspezifische Erweiterungen (Eigenentwicklungen) darstellen.208
Diese Rahmenbedingungen erfordern eine Durchführung der Schulung vor Ort, eine
flexible Termingestaltung und einen modularen Aufbau der Schulungsveranstaltungen.
Die massgeschneiderte Schulung, bei welcher in modularer Form die konkreten Arbeitsabläufe des Endanwenders geschult werden, ist dem Besuch von Standardkursen
vorzuziehen. Zur Bestimmung der dafür notwendigen Schulungsinhalte und einer ge-
208
Vgl. dazu Sturm (1996), S. 43 ff.; Goetzner/Sommerfeld (1995), S. 48;
Röthig/Peters/Thom (1987), S. 70 f.
199
eigneten Unterteilung in Lernmodule bedarf es einer intensiven Ausbildungsbedarfsanalyse.
Ferner ist auch zu prüfen, ob die Vermittlung der Grundlagen mittels CBT-Schulung209
mit individuellem Coaching erfolgen kann. Vorteile dieser Schulungsart liegen in der
Wirtschaftlichkeit bei grossen Benutzerzahlen und in der Berücksichtigung des individuellen Lerntempos.210 Ein auf die Anwenderbedürfnisse ausgerichtetes Schulungskonzept
fördert die Akzeptanz und setzt wichtige Voraussetzungen für die erfolgreiche Nutzung
eines EMS.
4.4.4 Systemtechnische Faktoren
Gestaltung der Systemarchitektur
Bei der Gestaltung der Systemarchitektur sind primär die geforderten Antwortzeiten und
der Grad der Ausbaubarkeit für künftige Erweiterungen massgebend. Die Vergangenheit
hat gezeigt, dass die Leistungsanforderungen an die Hardware im Zeitablauf stark zunehmen. Ausserdem ist die weitere Entwicklung des Unternehmens bei der Auslegung
der Systemarchitektur zu berücksichtigen. Steht die Systemarchitektur fest, drängt sich
die Beantwortung der Frage nach einem partiellen oder vollständigen Outsourcing der
Hardware und Systemsoftwareumgebung auf.211 In vielen Fällen lässt sich dadurch der
innerbetriebliche Wartungsaufwand und das damit verbundene Risiko verringern. Darüber hinaus kann sich das Unternehmen durch eine Entlastung in diesem Bereich bei
der Einführung und während des Betriebs stärker auf fachliche Fragen konzentrieren.212
Die Skalierungsmöglichkeiten des R/3-Systems wurden in Kapitel 3.4 dargestellt. Darüber hinaus gilt es zu beachten, dass sowohl während der Einführung als auch während
des Betriebs ein Testsystem (Integrationssystem) zur Verfügung stehen muss, damit eine
209
210
211
212
CBT = Computer Based Training (Multimediale, computergestützte Schulung).
Vgl. z.B. Bartels/Siebeck (1995), S. 291 ff.; Franken/Jörgensen (1995), S. 315 ff.
Vgl. z.B. Mertens/Knolmayer (1995), S. 17; Stahlknecht (1995), S. 457.
Vgl. Knolmayer (1991), S. 333.
200
Veränderung der Customizingeinstellungen ausführlich getestet und dieses gegebenenfalls auch für Anwenderschulungen eingesetzt werden kann.
Schnittstellen zu existierenden IS
In der Regel erfolgt eine EMS-Einführung auf der Basis einer bereits bestehenden Systemlandschaft. Wenn Altsysteme nach der Einführung des EMS weiterverwendet werden und ein Datenaustausch zwischen diesen und dem EMS erforderlich ist, dann müssen Schnittstellen eingerichtet werden. Die Realisierung von Schnittstellen kann aber
auch bei der schrittweisen Einführung eines EMS zur Aufrechterhaltung aller für den
Betrieb notwendigen Funktionen erforderlich sein. Aus diesem Umfeldbedingungen
ergibt sich die Unterscheidung von folgenden Arten von Schnittstellen:
• Auf Dauer angelegte Schnittstellen werden zu Drittsystemen eingerichtet, welche
entweder ergänzend zum EMS eingesetzt oder erst zu einem späteren Zeitpunkt abgelöst werden.
• Temporäre Schnittstellen werden während einer schrittweisen Einführung von einzelnen Modulen des EMS zur Aufrechterhaltung des Betriebs und zur Übernahme
bestehender Daten eingerichtet.
Auf Dauer angelegte Schnittstellen zu Drittsystemen (z.B. Individualsoftware, CAD,
BDE, Zeiterfassungssysteme) müssen sorgfältig geplant werden, damit deren rechtzeitige
Funktionsfähigkeit gewährleistet werden kann. Vielfach werden Schnittstellen zu weitverbreiteten Systemen entweder von den Herstellern selbst oder von Drittanbietern auf
dem Markt angeboten.
Release-Planung
Release-Wechsel gehören nach der eigentlichen Einführung zu den aufwendigsten Aufgaben beim Einsatz von EMS. Die Vorgehensweise ist mit dem Einführungsprozess vergleichbar. Durchgeführt wird ein Release-Wechsel in der Regel auf einem bereits bei
der Einführung verwendeten Test- oder Integrationssystem. Dieses verfügt meist über
eine identische Konfiguration und stellt deswegen die ideale Basis für die Übernahme
201
eines neuen Releases dar.213 Das Risiko kann durch die Verwendung eines Testsystems
erheblich reduziert werden.
Da ein Release-Wechsel eines EMS mit einem erheblichen Aufwand verbunden ist,
lohnt es sich detaillierte Vorabklärungen zu treffen. Dabei sind folgende Punkte zu berücksichtigen:
• Beschaffung von Informationen über die kurz- und mittelfristige Release-Planung des
Softwareherstellers
• Ermittlung von Kosten und Nutzen eines neuen Releases (z.B. zwingend notwendige
Funktionen)
• Ermittlung der allenfalls steigenden Hardwareanforderungen eines neuen Releases
• Bestimmung der Auswirkungen auf individuelle Erweiterungen und Änderungen am
System.
Ein besonderes Augenmerk bei der Beurteilung der Notwendigkeit eines ReleaseWechsels gilt es auf den Adaptionsbedarf von individuellen Erweiterungen und Veränderungen am System zu richten. Bei "harten Modifikationen" (Anpassungen und Erweiterungen ausserhalb des vorgesehenen Rahmens) müssen Veränderungen und Erweiterungen beim Übergang auf einen neuen Release in den meisten Fällen nachgepflegt
werden, was einen erheblichen Zusatzaufwand verursachen kann.214
213
214
Vgl. Füglistaler (1990), S. 159 f.
Vgl. Meister (1990), S. 36.
202
Datenmigration
Die Einführung eines EMS ist oftmals mit der Übernahme von Daten aus Altsystemen
verbunden. Diese Daten müssen auf möglichst einfachem Weg und ohne qualitative
Einbussen in das neue System übertragen werden. Häufig wird versucht, Daten, wenn
immer möglich, automatisch zu übertragen. Bei kleinen Datenmengen, bei völlig verschiedenen Datenstrukturen in der Quell- und Zieldatenbank oder bei erheblichen
qualitativen Problemen mit den zu übernehmenden Daten wird auf einen automatischen Datentransfer verzichtet und eine manuelle Übernahme vorgenommen. Die Ergebnisse der Datenverarbeitung im neuen System sind u.a. auch von der Qualität der
übernommenen Daten abhängig ist. Streng dem Grundsatz folgend "Garbage in - Garbage out" können nach der Einführung eines neuen Systems bei schlechter Datenqualität keine wesentlichen Verbesserungen erwartet werden. Deshalb lohnt es sich, die vorhandenen Daten genaustens zu prüfen und bei der Feststellung von Defiziten in diesem
Bereich, die Gelegenheit zu nutzen und "Datenfriedhöfe" zu beseitigen. In solchen Fällen ist eine manuelle Datenübernahme angebracht, denn mit einer automatischen Datenübernahme kann die Datenqualität in der Regel kaum verbessert werden. Eine manuelle Datenübernahme ist zwar erheblich aufwendiger, bietet aber einen gewissen
Grad an Sicherheit, dass nach Produktivsetzung des neuen Systems keine Probleme
durch unvollständige, veraltete oder fehlerhafte Daten verursacht werden.
Ein weiteres Problem bei der Datenübernahme stellen Semantikunterschiede zwischen
den Daten denjenigen des alten und des neuen Systems dar. Vielfach erweist sich die
Zuordnung der Datenfelder aufgrund der Verwendung unterschiedlicher Begriffe als
problematisch. Deshalb ist es von grosser Bedeutung, die Begriffswelt des einzuführenden Systems sehr genau zu kennen, damit eine korrekte Zuordnung der Datenfelder
erfolgen kann. Dies hat aber auch zur Folge, dass eine Begriffswelt, die sich in einem
Unternehmen über lange Zeit eingebürgert hat, geändert werden muss.215 Bei der
215
Vgl. Kengelbacher (1990), S. 146.
203
Schulung der Anwender ist dieser Aspekt (Verwendung einer einheitlichen Terminologie) entsprechend zu berücksichtigen.
Umfassende Planung des Betriebs
Im Rahmen der Produktionsvorbereitungen muss der Betrieb des neuen Systems umfassend geplant werden. Zu berücksichtigen sind hauptsächlich folgende Gesichtspunkte:
• Einrichtung der Anwenderunterstützung (Help-Desk)
• Planung eines Krisenmanagements für allfällige Systemausfälle (Darstellung von möglichen Krisensituationen inkl. Ausarbeitung von Lösungsszenarien)
• Durchführung von umfangreichen Performancetests zur Gewährleistung der vorgesehenen Antwortzeiten
• Sicherstellung der laufenden technischen und betriebswirtschaftlichen Optimierung
des Systems nach dem Produktivstart.
Die Aufmerksamkeit unter den genannten Punkten ist insbesondere auf den Benutzersupport zu richten, da die Art der Erfüllung dieser Aufgabe die Akzeptanz des neuen
Systems und dessen erfolgreiche Nutzung massgeblich beeinflussen kann.
204
4.5 Beurteilung der CSF aus der Sicht der Betroffenen
4.5.1 Expertenbefragung
Die Meinungen der Experten216 über die Erfolgsfaktoren bei der Einführung von SAP R/3
stimmen nicht voll überein. Aus diesem Grund wurde im Rahmen einer 1995 durchgeführten Expertenbefragung217 versucht, potentielle Erfolgsfaktoren zu identifizieren und
diese in einer qualitativen Befragung von Personen, die über Führungs- und/oder Beratungserfahrung in R/3-Projekten verfügen, begutachten und gewichten zu lassen.
In einer ersten Phase wurden 20 Experten zu Fragen der Einführung von SAP R/3 ausgewählt wurden. Dabei wurden sowohl Berater als auch Projektverantwortliche und
Projektleiter in die Auswahl einbezogen. Im Bereich der Berater wurden 4 Mitarbeiter
der SAP (Schweiz) AG und 5 Mitarbeiter anderer Beratungsunternehmungen (LogoPartner) befragt. Unter den Projektverantwortlichen und Projektleitern der R/3 einführenden Betriebe befanden sich 6 Vertreter von multinational tätigen Unternehmen und
5 Vertreter von kleinen und mittelgrossen Unternehmen (KMU).
Mit den ausgewählten Personen wurde jeweils ein einstündiges Interview zum Thema
"Kritische Erfolgsfaktoren bei der Einführung von SAP R/3" geführt. Das Interview gliederte sich in drei Teile: In einem ersten Teil wurden die Ziele der Untersuchung erläutert und erklärt, was unter kritischen Erfolgsfaktoren im Zusammenhang mit einer R/3Einführung zu verstehen sei. In einer zweiten Phase wurde der Experte nach kritischen
Erfolgsfaktoren aus seiner Sicht befragt. Dabei musste er mindestens fünf Erfolgsfaktoren
nennen und begründen, warum er diese als besonders wichtig erachtet. In der dritten
Phase wurde dem Befragten eine Liste von 21 möglichen Erfolgsfaktoren vorgelegt und
die Bedeutung der einzelnen Faktoren im Detail erklärt. Vor Abschluss des Interviews
erhielt der Experte eine Tabelle zum paarweisen Vergleich der 21 Erfolgsfaktoren (vgl.
Abb. 4-13) mit der Bitte diese Tabelle auszufüllen und zurückzusenden.
216
217
Vgl. Boll (1994), S. 15; Hüttenhain (1990), S. 141 f.; Knolmayer (1995a); Weber (1994), S. 58.
Vgl. Strebi (1996).
205
1
1
1
X
1
1
1
1
1
X
1
1
1
1
1
1
X
1
1
1
1
1
X
1
1
1
1
1
X
1
1
1
1
1
1
1
1
1
1
1
X
X
1
1
1
X
1
1
1
1
1
1
1
1
1
1
X
X
1
1
1
X
1
1
1
1
1
1
1
1
1
1
X
X
1
1
1
1
X
1
1
1
1
1
1
1
1
1
1
X
X
1
X
1
1
1
X
1
1
X
X
X
X
X
1
X
X
X
X
X
X
X
0
2
0
4
1
1
5
2
0
9
9
4
2
2
3
3
3
4
13 13
1
1
1
X
1
1
1
X
X
X
X
1
X
X
X
X
X
X
X
X
Evaluation
TOTAL
1
1
1
X
1
X
X
1
1
X
1
1
Datenmigration
1
X
1
X
X
X
X
X
X
X
X
X
X
X
X
1
X
X
X
X
X
Dokumentation
1
1
1
1
1
1
1
1
1
Release-Planung
1
1
1
X
1
1
X
1
Know-how-Transfer
X
X
1
X
1
X
X
Kommunikation
1
1
1
X
1
1
1
1
1
X
1
Projektorganisation
X
X
X
X
Projektleiter
1
1
1
X
X
1
Vertragsgestaltung
Steuerungsausschuss
0
Change Management
Einbeziehung des höheren Managements
Change Management
Steuerungsausschuss
Vertragsgestaltung
Evaluation
Projektleiter
Projektorganisation
Kommunikation
Know-how-Transfer
Release-Planung
Dokumentation
Datenmigration
TOTAL
Kritische Erfolgsfaktoren bei der
Einführung
von SAP R/3
Einbeziehung des höheren Managements
16
13
16
2
15
11
8
9
8
4
7
9
6
4
0
0
2
0
0
0
0
1 = horizontaler Faktor kritischer X = vertikaler Faktor kritischer
Abb. 4-13: Paarweise Bewertung von Erfolgsfaktoren bei der Einführung von SAP R/3.
Nach dem Erhalt der Bewertungstabellen wurde sowohl eine quantitative Bewertung
der einzelnen Faktoren (Kumulation der Bewertungspräferenzen und Bildung von
Rangsummen) als auch eine qualitative Auswertung der Interviews durchgeführt.
Im letzten Schritt der Untersuchung erfolgte eine Feedback-Runde in Anlehnung an die
Delphi-Methode.218 Die Befragten erhielten die Gesamtbewertung der einzelnen Erfolgsfaktoren und eine Auswertung ihrer eigenen Einschätzung. Es wurde Ihnen dann
die Möglichkeit gegeben, ihre eigene Bewertung aufgrund der Gesamtbewertung zu
verändern.
218
Vgl. z.B. Bea/Dichtl/Schweitzer (1991), S. 571 ff.
206
Der Vorteil diese Methode liegt darin, dass unterschiedliche Meinungen miteinander
konfrontiert werden und sich sukzessive eine Angleichung der verschiedenen Bewertungen aufgrund der überzeugendsten Argumente ergibt. Das hat zur Konsequenz, dass
sich die weniger Überzeugten von den stärker Überzeugten beeinflussen lassen.
4.5.2 Darstellung der Ergebnisse
Bei der Auswertung der Ergebnisse219 zeigte sich, dass projektmanagementbezogene
Faktoren eine massgebende Rolle für den Erfolg eines Projektes spielen, systemtechnische Faktoren dagegen eher von untergeordneter Bedeutung sind. Ziemlich deutlich in
den Vordergrund gehoben wurden die Faktoren "Projektleiter" und "Klar formulierte
Zielsetzungen". Unmittelbar danach folgen die Faktoren "Schulung der Anwender",
"Einbeziehung des Managements und "Kommunikation".
Erfolgsfaktor
Projektleiter
Kommunikation
Projektorganisation
Change-Management
Know-how-Transfer
BPR
Auswahl von Beratungspartnern
Lenkungsausschuss
Datenmigration
Verbindung zu existierenden IS
Dokumentation
Release-Planung
Aufwand für Vertragsgestaltung
Anwender + Berater (1. Runde)
Rangpunkte
Rang
112
1
128
2
131
3
162
7
149
4
168
8
151
5
182
9
161
6
184
10
206
11
240
14
259
16
250
15
224
12
259
16
234
13
276
18
299
19
347
20
357
21
Anwender + Berater (2. Runde)
Rangpunkte
Rang
91
1
98
2
137
3
138
4
143
5
157
6
165
7
172
8
175
9
177
10
232
11
233
12
257
13
262
14
266
15
268
16
268
16
269
18
317
19
345
20
349
21
Abb. 4-14: Bewertung der Erfolgsfaktoren (Anwender und Berater).
219
Die Detailauswertung ist im Anhang A zu finden.
207
Deutlich ersichtlich ist bei der Betrachtung der Ergebnisse auch die durch die Anwendung der Delphi-Methode verursachte Angleichung der Ergebnisse nach der 2. Fragerunde. Während sich die Rangzahlen in den Spitzenpositionen nach der 1. Auswertung
nur unwesentlich von den nachfolgenden Werten unterschieden haben, sind diese nach
der Konfrontation der Experten mit den Meinungen der übrigen Befragten meist wesentlich deutlicher in den Vordergrund gerückt.
Geamtbeurteilung der Erfolgsfaktoren nach der 2. Fragerunde (Anwender und Berater)
(n=20)
Projektleiter
Schulung der Anw ender
Kommunikation
Projektorganisation
Change-Management
Know -how - Transfer
BPR
Ausw ahl von Beratungspartnern
Lenkungsausschuss
Datenmigration
Dokumentation
Release-Planung
0%
20%
40%
60%
80%
100%
Abb. 4-15: CSF aus der Sicht von Anwendern und Beratern.
Bei inhaltlicher Betrachtung erstaunt zunächst die starke Bevorzugung projektmanagementbezogener Faktoren. Im SAP-Vorgehensmodell werden im Gegensatz dazu eher
systemtechnische Faktoren in den Vordergrund gestellt.
Dieser Umstand zeigt, dass aus der Sicht der Anwender und Berater bei der Einführung
systemtechnische Probleme eher im Hintergrund stehen und ein stärkeres Gewicht auf
die verschiedenen Aspekte des Projektmanagements gelegt wird.
208
Bei Berücksichtigung der qualitativen Auswertung der Interviews220 wird deutlich, dass
an erster Stelle personelle Aspekte (Projektleiter, Projektteam und Schulung der Anwender, Einbeziehung des Managements) stehen. Neben der sorgfältigen Wahl aller an
einem R/3-Einführungsprojekt beteiligten Personen auch das Treffen organisatorischer
Regelungen für deren Zusammenarbeit (Klar formulierte Zielsetzungen, Kommunikation, Change-Management, Methodisches Vorgehen oder generell die Projektorganisation) als kritisch beurteilt.
Bei der Bestimmung der zeitlichen Relevanz der als besonders kritisch beurteilten Erfolgsfaktoren fällt auf, dass sich diese vor allem auf die einleitenden Phasen eines Projektes beziehen. Die personelle Besetzung wird ganz zu Beginn eines Projekte festgelegt
und ändert sich in der Regel während des Projektablaufs nur noch unwesentlich. Die für
die Projektarbeit notwendigen organisatorischen Regelungen werden ebenfalls in den
ersten Projektphasen getroffen. Im Gegensatz zu einmaligen Aktivitäten (z.B. Auswahl
des Projektleiters) kommt Faktoren, wie z.B. Kommunikation, Change-Management
während des gesamten Projektes grosse Bedeutung zu. Daraus kann gefolgert werden,
dass die entscheidenden Weichen innerhalb eines Projektes bereits zu Beginn gelegt
werden und eine mangelhafte Festlegung dieser Rahmenbedingungen bei der Projektabwicklung zu wesentlichen Problemen führen kann.
In der nachfolgend dargestellten empirischen Untersuchung soll diesen Faktoren ein
besonderes Gewicht beigemessen werden. Darüber hinaus wird versucht, neben diesen
eher qualitativen Bestimmungsgrössen auch die für die Kosten und zeitliche Dauer eines
Projektes verantwortlichen Faktoren zu bestimmen.
220
Strebi (1996).
209
Befragung zur Einführung von R/3
5 Befragung zur Einführung von R/3
5.1 Einleitung
Das R/3-System deckt die betriebswirtschaftlichen Anforderungen vieler Unternehmungen in hohem Masse ab (Vgl. Kap. 3). Der damit verbundene Integrationsgrad einzelner Funktionen und die Möglichkeit, R/3 durch Parametersetzung sehr unterschiedlichen Bedürfnissen anzupassen, führen zu entsprechend hoher Komplexität in Einführungsprojekten.
Da EMS mit den oben beschriebenen Merkmalen erst seit Beginn der neunziger Jahre
auf dem Markt verfügbar sind und Einführungsprojekte bis zum produktiven Einsatz
teilweise mehrere Jahre in Anspruch nehmen können, liegen bisher kaum systematisch
gesammelte Erfahrungen zu solchen Projekten vor. Eine 1994 durchgeführte Voruntersuchung221 zu Erfahrungen mit der Einführung von SAP R/3 in der Schweiz bestätigt diese Annahme. Obschon Schweizer Unternehmungen in diesem Umfeld eher zur Gruppe
der Fast Movers zu rechnen sind,222 waren zu diesem Zeitpunkt nur die wenigsten R/3Projekte abgeschlossen.
Diese rein deskriptive Voruntersuchung diente zusammen mit der im vorangehenden
Kapitel dargestellten Expertenbefragung der Auswertung verschiedener Fallstudien als
Grundlage für die Bildung von vorläufigen Hypothesen, deren Generalisierbarkeit in
einer 1996 durchgeführten Folgeuntersuchung überprüft wurde (vgl. Abb. 5-1). Die
formulierten Hypothesen wurden dabei sowohl auf Basis der in der Voruntersuchung
und Expertenbefragung ermittelten Erkenntnisse, als auch aufgrund von in der Literatur
formulierten Äusserungen abgeleitet. Darüber hinaus flossen auch eigene Erfahrungen
oder begründete Vermutungen in die Hypothesenbildung ein.223
221
222
223
Vgl. Knolmayer, Portner, von Arb (1995).
Die Schweiz gehörte bis 1995 zu den 5 absatzstärksten Ländern der SAP AG. Vgl. dazu SAP AG
(1996b).
Nach Bortz werden Hypothesen in der empirischen Forschung sowohl aus der Literatur als auch
aufgrund eigener Erfahrungen und begründeten Vermutungen abgeleitet werden können, (vgl. Bortz
1984, S. 28). Darüber hinaus weist er auf die Bedeutung von rein deskriptiven Voruntersuchungen
für die Hypothesenbildung hin (vgl. Bortz 1994, S. 217 f.).
211
Literatur- und
Dokumentenanalyse
Expertenbefragung
Empirische
Voruntersuchung
Fallstudien /
eigene Erfahrungen
Bezugsrahmen
Quantitative
Erhebung
Ableitung von
Gestaltungsempfehlungen
Abb. 5-1: Explorativer Forschungsprozess.
Im den nachfolgenden Unterkapiteln werden die Untersuchungsziele und das Befragungskonzept dargestellt. Letzteres umfasst den Bezugsrahmen und die davon abhängigen Hypothesen. Anschliessend wird auf die verwendeten Auswertungsverfahren eingegangen und deren Wahl begründet. In einem weiteren Unterkapitel folgt die Beschreibung der Stichprobe. Nach den methodischen Ausführungen zur Untersuchung werden
die eigentlichen Ergebnisse in deskriptiver Form dargestellt. Der Aufbau richtet sich dabei grundsätzlich nach den Phasen des Einführungsprozesses. Ergänzend zu der deskriptiven Darstellung der Ergebnisse werden im Anschluss daran die Resultate aus der
hypothesenprüfenden Untersuchung vorgestellt.
212
5.2 Untersuchungsziele
Mit der im folgenden dargestellten quantitativen Erhebung werden verschiedene Ziele
verfolgt. Grundsätzlich sollen alle wesentlichen Aspekte des Einführungsprozesses untersucht werden. Besonderes Gewicht liegt dabei auf der Identifizierung von Problembereichen und der Überprüfung von Einflussfaktoren auf Kosten und Dauer einer R/3Einführung im Rahmen der aufgestellten Arbeitshypothesen. Ferner erfolgt eine Überprüfung der Ergebnisse aus der Expertenbefragung zu kritischen Erfolgsfaktoren bei der
Einführung von SAP R/3.
Anhand der aus dieser Untersuchung gewonnen Erkenntnisse wird anschliessend versucht, die Wirkungsrichtung der ermittelten Erfolgsfaktoren zu bestimmen und die für
Kosten und Einführungsdauer massgebenden Bedingungsgrössen festzulegen. Das Endziel stellt die Aufstellung eines Schätzmodells für die grobe Bestimmung von Kostenund Einführungsdauer eines R/3-Projekts aufgrund der wichtigsten Rahmenparameter
und die Ableitung von Gestaltungsempfehlungen für die Projektdurchführung dar.
213
5.3 Befragungskonzept
5.3.1 Bezugsrahmen
5.3.1.1 Bezugsrahmen im Überblick
Der Bezugsrahmen dient im Rahmen des Forschungsprozesses als Vorstufe auf dem
Weg zu praxeologischen Aussagen und kann deshalb als Grundlage für die Lösung realer organisatorischer Probleme betrachtet werden.224 Konkret ist darunter ein Ordnungsschemata über handlungsbezogene Vorstellungen zu verstehen, durch welches das reale
Phänomen der organisatorischen Gestaltung beschrieben wird. Basierend auf dem Bezugsrahmen werden Behauptungen (Hypothesen) über Wechselwirkungen zwischen
den darin enthaltenen Einflussgrössen aufgestellt.
Der Bezugsrahmen besteht grundsätzlich aus den Elementen Zielgrössen, Aktionsparameter und Rahmenbedingungen. Auf die Zielgrössen ist der organisatorische Gestaltungsprozess (z.B. Einführung eines neuen EMS) ausgerichtet. Durch Aktionsparameter
werden disponible Grössen beschrieben (z.B. Grad der organisatorischen Anpassung
eines EMS an bestehende Prozesse), welche für die Erreichung der Gestaltungsziele herangezogen werden können. Darüber hinaus werden die Wirkungszusammenhänge zwischen Zielgrössen und Aktionsparametern durch Rahmenbedingungen (kurzfristig nicht
disponible Grössen, z.B. die Grösse des betrachteten Unternehmens) beeinflusst.225
Durch den Bezugsrahmen in der vorliegenden Untersuchung wird versucht, die Wirkungszusammenhänge verschiedener Bedingungsgrössen und Aktionsparameter auf die
Dauer und die Kosten von R/3-Einführungen darzustellen (vgl. Abb. 5-2). Als Rahmenbedingungen werden einerseits die Unternehmenssituation des betrachteten Unternehmens (organisatorische Merkmale, Informatiksituation) und andererseits die projektspezifischen Festwerte herangezogen.
224
225
Vgl. Grochla (1982), S. 14 ff.
Vgl. Grochla (1982), S. 14 ff.
214
Unternehmensbezogene
Bedingungsgrössen
Projektbezogene
Bedingungsgrössen
Technische
Bedingungsgrössen
Branche
Anzahl Projekte
Bisherige Systemarchitektur
Anzahl Mitarbeiter
Anzahl Projektmitarbeiter
Bisherige Softwareachitektur
Singlesite-/Multisite-Organisation
Freistellungsgrad der Projekt-MA
Anzahl Schnittstellen
Anzahl Module
R/2-Erfahrung
Anzahl User
Funktionsabdeckungsgrad
Primäre
Wirkungsrichtung
Aktionsparameter
Management
Berater
Anwender
Projektorganisation
CSF
Organisations-/
Systemanpassung
Projektleiter
Zielsetzungen
Kommunikation
Beeinflussung ±
Sachziele
Beeinflussung ±
Kostenziele
Terminziele
Abb. 5-2: Bezugsrahmen für die Einflussgrössen von Kosten und Dauer einer R/3-Einführung.
5.3.1.2 Unternehmensbezogene Einflussgrössen
Zu den untersuchten unternehmensbezogenen Bedingungsgrössen zählen die Unternehmensgrösse, die Branchenzugehörigkeit und die Organisationsform (Singlesite/
Multisite).
Bezüglich der Unternehmensgrösse wird vermutet, dass grössere Unternehmen mehr
R/3-Module einsetzen und aufgrund der höheren Mitarbeiterzahl auch eine höhere Benutzerzahl haben als KMUs. Durch das breitere Anforderungsspektrum steigt der sowohl
der Integrations- als auch der Koordinationsaufwand.
215
Ferner wird davon ausgegangen, dass die Branchenzugehörigkeit eines Unternehmens
den Nutzungsgrad des R/3-Systems beeinflusst. In der empirischen Voruntersuchung
zeigte sich, dass in gewissen Branchen (z.B. in Banken oder Versicherungen) einzelne
Module des R/3-Systems (z.B. PP oder PM) kaum zum Einsatz kommen.
Weiter wird unterstellt, dass die geographische Verteilung eines Unternehmens oder
Konzerns den Einführungsaufwand des R/3-Systems beeinflusst. Bei Unternehmen, die
nur von einem Standort aus tätig sind (Singlesite-Organisation) erweist sich eine R/3Einführung insbesondere in Bezug auf den technischen und organisatorischen Gestaltungsrahmen als weniger komplex als bei geographisch verteilten Unternehmen
(Multisite-Organisationen). Vor allem bei international tätigen Unternehmungen müssen
unterschiedliche sprachliche und gesetzliche Rahmenbedingungen berücksichtigt werden und darüber hinaus ergeben sich zusätzlich technische Abstimmungsprobleme (z.B.
Datenkonsistenz bei verteilter Datenhaltung).
5.3.1.3 Projektbezogene Einflussgrössen
Die projektbezogenen Einflussgrössen werden unmittelbar von den unternehmensbezogenen Rahmenbedingungen bestimmt. Aufgrund der sich ergebenden Installationsgrösse
muss eine geeignete Projektorganisation gewählt werden. Je mehr Teilprojekte zur Bewältigung der Aufgaben notwendig sind, desto höher ist der Abstimmungsaufwand.
Damit indirekt verbunden ist die Zahl der Projektmitarbeiter und deren Freistellungsgrad. Je geringer der Freistellungsgrad, desto niedriger ist der Produktivitätsgrad der
Projektmitarbeiter, denn ein geringer Freistellungsgrad für das Projekt erhöht die Anzahl
der notwendigen Projektmitarbeiter bei gegebenem Arbeitsvolumen. Dadurch steigt der
Koordinationsaufwand und dies führt zu einer Zunahme der personellen Aufwendungen für das Projekt.
Ferner wird davon ausgegangen, dass die Systemgrösse, insbesondere bei KMUs, stark
von der Grösse und der Branchenzugehörigkeit eines Unternehmens beeinflusst wird.
Indizien für die Abhängigkeit der Systemgrösse von der Branchenzugehörigkeit liessen
216
sich bereits in der Voruntersuchung feststellen.226 Zusätzlich bleibt die Frage offen, inwieweit der Funktionsabdeckungsgrad von der Unternehmensgrösse und der Branchenzugehörigkeit abhängt. Die Kenntnis dieser Zusammenhänge ermöglicht die Bestimmung der Systemgrösse und davon ausgehend die Ableitung eines groben Budgetrahmens.
5.3.1.4 Technische Einflussgrössen (Informatik-Situation)
Die vorhandene Systemumgebung (Hardware- und Softwarearchitektur) hat möglicherweise einen Einfluss auf dem Einführungsaufwand eines R/3-Projektes. Bei einer grossen
Zahl von abzulösenden Altsystemen und zu integrierenden Umsystemen erhöht sich der
Einführungsaufwand im Vergleich mit einer Installation "auf der grünen Wiese". Messgrössen für die Komplexität der vorhandenen Systemumgebung sind die bisherige
Hardware- und Softwarearchitektur und die Zahl der temporären und auf Dauer angelegten Schnittstellen.
5.3.1.5 Aktionsparameter
Durch die gezielte Beeinflussung verschiedener Aktionsparameter aus dem Bereich des
Projektmanagements (Beraterwahl, Projektleiterwahl, Zusammensetzung der Projektteams, Einbezug des Managements etc.) kann nach der Meinung von Experten der Einführungsaufwand für R/3 reduziert werden.227 Verläuft das Projekt durch klare Zielvorgaben und einheitliche organisatorische Regelungen in einem geordneten Rahmen,
werden aller Voraussicht nach weniger Koordinations- und Akzeptanzprobleme zu erwarten sein. Darüber hinaus lassen sich durch eine seriöse konzeptionelle Systemplanung grundlegende Fehler weitgehend vermeiden, so dass in diesem Zusammenhang
keine nachträglichen und mit grossem Aufwand verbundenen Korrekturmassnahmen
notwendig sind.
226
227
Vgl. Knolmayer/Portner(von Arb (1995).
Vgl. Kap. 4.5.2.
217
5.3.1.6 Zielgrössen
Die mit einer R/3-Einführung verfolgten Ziele werden in drei Kategorien unterteilt. Die
erste Kategorie umfasst alle Sachziele, d.h. alle Ziele, welche die Art der informationstechnischen Unterstützung der Geschäftsprozesse eines Unternehmens betreffen. Der
Funktionsumfang des R/3-Systems ist weitgehend gegeben. Die Art der Nutzung der
einzelnen Funktionen wird durch das Customizing bestimmt. Von Modifikationen
(Erweiterungen oder Änderungen am System ausserhalb des vorgesehenen Rahmens)
wird weitgehend abgeraten. Unter Berücksichtigung dieser Rahmenbedingungen kann
die Realisierung der Sachziele weitgehend als gegeben betrachtet werden resp. wird in
erheblichem Masse durch den Funktionsumfang und die vorhandenen Customizingmöglichkeiten bestimmt. Bei der Messung des Zielerreichungsgrads von Sachzielen besteht zusätzlich das Problem der Objektivität und der Vergleichbarkeit. Aus diesen
Gründen wird auf eine detaillierte Analyse der Einflussgrössen auf Sachziele verzichtet.
Die Einhaltung von Kosten- und Terminzielen stehen bei R/3-Einführungen häufig im
Zentrum der Kritik. In vielen Fällen wurden die gesetzten Kosten- und Terminziele erheblich überschritten. Die Gartner Group schätzt, dass in 10-15% der R/3-Projekte mit
Beraterbeteiligung die veranschlagten Kosten und der vorgesehene Zeithorizont um
mehr als 25% überschritten werden.228 Aus diesem Grund konzentriert sich diese Untersuchung im wesentlichen auf die Bestimmungsgrössen von Kosten- und Terminzielen.
Dabei wird untersucht, von welchen Einflussgrössen diese primär abhängig sind und
durch welche Aktionsparameter eine Reduktion des zeitlichen und finanziellen Aufwandes herbeigeführt werden kann.
228
Vgl. Mirchandani/Digrius (1996).
218
5.3.2 Untersuchungshypothesen
5.3.2.1 Hypothesenbildung
Basierend auf den im Bezugsrahmen dargestellten möglichen Wirkungszusammenhängen, werden anschliessend Hypothesen formuliert. Die aufgestellten Hypothesen wurden entweder der Literatur entnommen (vgl. Querverweise) oder stützen sich auf eigene
Erfahrungen sowie begründete Vermutungen.229 Die Gliederung der Hypothesen richtet
sich nach den Ebenen des Bezugsrahmens.
5.3.2.2 Hypothesen zu unternehmensbezogenen Bedingungsgrössen
Es wird vermutet, dass sich R/3-Projekte in Abhängigkeit von der Grösse und der Branchenzugehörigkeit des betrachteten Unternehmens unterscheiden. Dabei wurden einerseits die Wirkungseinflüsse auf die projektbezogenen Bedingungsgrössen und andererseits Zusammenhänge zwischen unternehmensbezogenen Bedingungsgrössen und Aktionsparametern betrachtet. Im folgenden werden die vermuteten Abhängigkeiten in
Form von einzelnen Hypothesen dargestellt.
Untersuchungshypothesen:
(1.1)
Beim Einsatz von R/3 ist die vorgesehene Benutzerzahl (Named User) von der
Grösse des Unternehmens (Mitarbeiterzahl) abhängig.
(1.2)
Die Anzahl Named User beim Einsatz von R/3 in KMUs ist geringer als in
Grossunternehmen.
(1.3)
Grossunternehmen setzen mehr Module des R/3-Systems ein als KMUs.
(1.4)
Die Zahl der eingesetzten Module ist in den einzelnen Branchen (Industrie-,
Handels- und Dienstleistungssektor) unterschiedlich.
229
Vgl. Bortz 1984, S. 28: "Eine hypothesenprüfende Untersuchung ist auch dann zu rechtfertigen,
wenn eine Hypothese nicht der Literatur entnommen, sondern aufgrund eigener Erfahrungen oder
begründeter Vermutungen gebildet wird."
219
(1.5)
Die Gesamtkosten einer R/3-Einführung sind in KMUs niedriger als in Grossunternehmen.
(1.6)
Die durchschnittlichen Einführungskosten für 100 Named User sind im Dienstleistungssektor niedriger als im Industrie- und Handelssektor.
(1.7)
Die durchschnittlichen Einführungskosten für 100 Named User sind bei Grossunternehmen geringer als bei KMUs.
(1.8)
Die Kostenstruktur (Verhältnis von Softwarelizenzkosten zu Einführungskosten)
ist in KMUs und Grossunternehmen ähnlich.
(1.9)
Die Einführungskosten von Multisite-Installationen sind höher als jene von
Singlesite-Installationen.
(1.10)
Die Einführungsdauer in Personenmonaten ist im Dienstleistungssektor kürzer
als im Industrie- und Handelssektor.
(1.11)
Die Gesamteinführungsdauer ist bei KMUs geringer als bei Grossunternehmen.
(1.12)
Grossunternehmen setzen bei der Einführung von R/3 ein stärkeres Gewicht auf
die methodische Unterstützung (Verwendung von Vorgehensmodellen und
Tools) als KMUs.
(1.13)
KMUs passen Ihre Abläufe stärker an die Vorgaben von R/3 an als Grossunternehmen.
(1.14)
KMUs nehmen weniger häufig Veränderungen am Source Code vor als Grossunternehmen.
(1.15)
KMUs wählen häufiger eine Outsourcing-Lösung für den Systembetrieb als
Grossunternehmen.
(1.16)
Die Intensität der Evaluation ist in KMUs und in Grossunternehmen vergleichbar.
220
(1.17)
In KMUs ist der Funktionsabdeckungsgrad grösser als in Grossunternehmen.
(1.18)
Die Zahl der auf Dauer eingerichteten Schnittstellen ist in Grossunternehmen
grösser als in KMUs.
5.3.2.3 Hypothesen zu Bedingungsgrössen der bisherigen Informatiksituation
Die bisherige Informatiksituation kann einen Einfluss auf Einführungsdauer und Einführungskosten eines R/3-Projektes haben. Beispielsweise können Erfahrungen mit Standardsoftware (z.B. R/2) einen positiven Einfluss auf den Projektablauf haben.
(2.1)
Die Einführungsdauer (Personenmonate) für 100 Named User ist bei Unternehmen mit R/2-Erfahrung niedriger als bei Unternehmen ohne R/2-Erfahrung.
(2.2)
Die Einführungskosten für 100 Named User sind bei Unternehmen mit R/2Erfahrung niedriger als bei Unternehmen ohne R/2-Erfahrung.
(2.3)
Die Gesamtkosten einer Einführung sind bei Unternehmen mit Host-Einsatz
höher als bei Unternehmen, deren betriebswirtschaftliche Anwendungsplattform sich bisher auf PC-Server-Ebene befand.
(2.4)
Die Einführungskosten für 100 Named User sind bei Unternehmen mit bisherigem Grossrechnereinsatz höher als bei jenen, deren betriebswirtschaftliche
Anwendungsplattform sich bisher auf PC-Server-ebene befand.
(2.5)
Grossunternehmen haben bisher häufiger Individualsoftware eingesetzt als
KMUs.
(2.6)
Die Gesamtkosten bei der Einführung von R/3 sind bei Unternehmen, welche
bisher Individualsoftware (ISW) verwendet haben, höher als bei Unternehmen
mit Standardsoftware-Einsatz.
(2.7)
Die Gesamtkosten einer R/3-Einführung werden von der Zahl der auf Dauer
eingerichteten Schnittstellen zu Fremdsystemen beeinflusst.
221
(2.8)
Die Dauer einer R/3-Einführung (Personenmonate) wird von der Zahl der auf
Dauer eingerichteten Schnittstellen zu Fremdsystemen beeinflusst.
5.3.2.4 Hypothesen zu projektbezogenenen Bedingungsgrössen
Mit zunehmender Benutzerzahl steigen die Anforderungen und die Komplexität einer
R/3-Einführung. Das Gleiche gilt für die Anzahl der eingesetzten Module. Je mehr Module eingesetzt werden, desto höher ist der Integrationsgrad und desto komplexer wird
die Einführung. Die Anzahl Schnittstellen weist auf die Vernetzheit von R/3 mit Altsystemen hin. Ist die Zahl der Schnittstellen gross, findet die Einführung in einer komplexen Systemumfeld mit einer Vielzahl von Umsystemen statt. Diese Faktoren könnten
einen nachweisbaren Einfluss auf die Dauer und die Kosten einer R/3-Einführung haben.
(3.1)
Je mehr Module eingeführt werden, desto höher sind die Gesamtkosten einer
R/3-Einführung.
(3.2)
Mit zunehmender Benutzerzahl (Anzahl Named User) steigen die Gesamtkosten einer R/3-Einführung.
(3.3)
Je mehr Module eingeführt werden, desto höher ist die Dauer einer R/3-Einführung (Kalenderzeit).
(3.4)
Mit zunehmender Benutzerzahl (Anzahl Named User) erhöht sich die Dauer
einer R/3-Einführung.
222
5.3.2.5 Hypothesen zu Aktionsparametern
Bei der Betrachtung von Einführungskosten und Einführungsdauer stellt sich die Frage,
durch welche Aktionsparameter diese Grössen unter gegebenen Rahmenbedingungen
beeinflusst werden. Untersucht wurden die Einflussgrössen "Qualität der Beratungspartner", "Anzahl Projektmitarbeiter", "Art der organisatorischen Anpassung", "Unterstützung
des Managements", "Freistellungsgrad der Projektmitarbeiter", "Wahl einer OutsourcingLösung" und "Intensität von Evaluation und Projektorganisation".
(4.1)
Mit steigender Qualität der Beratungspartner sinkt die Dauer einer R/3Einführung (Personenmonate pro 100 Named User).
(4.2)
Mit steigender Qualität der Beratungspartner sinken die Kosten einer R/3Einführung für 100 Named User.
(4.3)
Mit zunehmender Projektdauer (Kalenderzeit) steigt die Zahl der eingesetzten
Projektmitarbeiter (PMA).
(4.4)
Eine grössere Zahl von eingesetzten Projektmitarbeitern erhöht die durchschnittlichen Kosten einer R/3-Einführung.
(4.5)
Je mehr sich ein Unternehmen an die Prozessvorgaben von R/3 anpasst, desto
geringer sind die durchschnittlichen Kosten einer R/3-Einführung für 100 Named User.
(4.6)
Je mehr sich ein Unternehmen an die Prozessvorgaben von R/3 anpasst, desto
geringer ist die durchschnittliche Dauer einer R/3-Einführung für 100 Named
User.
(4.7)
Je höher der Freistellungsgrad der Projektmitarbeiter desto kürzer die Dauer
einer R/3-Einführung pro 100 Named User.
223
(4.8)
Je höher der Freistellungsgrad der Projektmitarbeiter, desto geringer sind die
Kosten einer R/3-Einführung pro 100 Named User.
(4.9)
Bei der Wahl eines systemtechnischen Outsourcings reduzieren sich die durchschnittlichen Kosten einer R/3-Einführung (Kosten pro 100 Named User).
(4.10)
Bei der Wahl eines systemtechnischen Outsourcings verkürzt sich die durchschnittliche Dauer einer R/3-Einführung (pro 100 Named User).
(4.11)
Bei höherer Planungsintensität in den konzeptionellen Projektphasen reduziert
sich die durchschnittliche Dauer einer R/3-Einführung (pro 100 Named User).
(4.12)
Bei höherer Planungsintensität in den konzeptionellen Projektphasen reduzieren sich die durchschnittlichen Kosten einer R/3-Einführung (pro 100 Named
User).
224
5.3.3 Methodisches Vorgehen
5.3.3.1 Stichprobe
Die Untersuchung wurde als Vollerhebung bei Schweizer Unternehmen mit SAP R/3Einsatz durchgeführt. Die Beschränkung auf die Schweiz hat verschiedene Gründe: Seit
dem Erscheinen 1992 erfreute sich das R/3-System in der Schweiz einer grossen Beliebtheit. Auch 1995 gehörte die Schweiz trotz des weltweit starken Wachstums noch
immer zu den 5 umsatzstärksten Märkten für SAP-Produkte.230 Durch den relativ frühen
Einstieg vieler Schweizer Unternehmen in die R/3-Welt waren zum Zeitpunkt der Untersuchung im internationalen Vergleich überdurchschnittlich viele Projekte (65%) abgeschlossen. In den USA, dem seit 1995 umsatzstärksten Markt, waren zum gleichen Zeitpunkt nur rund 25% der Projekt abgeschlossen.231 Durch den höheren Anteil an abgeschlossenen Projekten in der Schweiz sind demnach zuverlässigere Aussagen über den
gesamten Projektablauf zu erwarten als bei stärkerer Einbeziehung anderer Märkte. Für
die Kosten- und Zeitermittlung stellte sich zusätzlich das Problem, dass im internationalen Vergleich die Verschiedenheit der im jeweiligen Land vorherrschenden Arbeitszeitmodelle und unterschiedliche Kostenstrukturen (z.B. Beraterhonorare) hätten berücksichtigt werden müssen.
Zum Untersuchungszeitpunkt (Sommer 1996) nutzten in der Schweiz 230 Unternehmungen SAP R/3 produktiv oder waren mit seiner Einführung beschäftigt. Die Adressen
dieser Unternehmen wurden freundlicherweise von der SAP (Schweiz) AG zur Verfügung gestellt. Von den 230 in die Untersuchung einbezogenen Unternehmungen sandten 95 einen ausgefüllten Fragebogen zurück. Dies entspricht einer für derartige Umfragen überdurchschnittlichen Rücklaufquote von 41.3%. In den meisten Fällen wurden
die Fragebogen von den verantwortlichen Projektleitern oder Mitgliedern des Steuerungsausschusses ausgefüllt. Aufgrund der Grösse der Stichprobe lassen sich repräsentative Aussagen für den R/3-Einsatz in Schweizer Unternehmungen ableiten.
230
231
SAP AG (1996d), S. 19.
Block (1996).
225
5.3.3.2 Datenerhebung
Die Datenerhebung erfolgte durch postalische Befragung mittels eines 8-seitigen Fragebogens.232 Die Bevorzugung der postalischen Befragung lässt sich vor allem durch den
erheblich niedrigeren Zeit- und Kostenaufwand im Vergleich zu qualifizierten Interviews
begründen. Ein wesentlicher Nachteil dieser Methode ist die Unmöglichkeit der Kontrolle der Befragungssituation. Aus diesem Grund wurde in einem Begleitschreiben genau festgehalten, an wen sich der Fragebogen richtet (an für die Einführung von SAP R/3
verantwortliche Personen) und welches das Untersuchungsobjekt ist (ausschliesslich
Unternehmungen mit Sitz in der Schweiz und deren Tochtergesellschaften).
1
Konzeption des Fragebogens
2
Pretest und Überarbeitung des Fragebogens
3
Erstellung eines Begleitschreibens und eines
Hinweisblattes zum Ausfüllen des Fragebogens
4
Versand der gesamten Untersuchungsunterlagen
5
Systematische Erfassung der eintreffenden Fragebogen
6
Nachfassung bei nach Einsendeschluss nicht
antwortenden Unternehmungen (Faxformular)
7
Telefonische Rückfragen bei Unstimmigkeiten
Abb. 5-3: Vorgehen bei der Datenerhebung.
Das bei der postalischen Befragung angewandte Vorgehen ist in Abb. 5-3 ersichtlich. Bei
der Erstellung des Fragebogens wurde versucht, offene Fragen möglichst zu vermeiden.
Die Struktur des Fragebogens orientiert sich grundsätzlich am Einführungsprozess des
R/3-Systems, wobei ein Schwergewicht auf Projektmanagementaspekten lag. Im einleitenden Teil des Fragebogens wurden darüber hinaus Fragen zur Unternehmenssituation
232
Vgl. Anhang B.
226
gestellt. Die Überprüfung der Verständlichkeit und Konsistenz der gestellten Fragen erfolgte anhand eines Pretests mit internen und externen Sachverständigen.
Die Fragebogen wurden versandt; zwei Wochen nach dem Einsendeschluss erfolgte der
Versand eines Mahnbriefes (Anschreiben mit Fax-Antwortblatt), welcher die Ankündigung einer Nachfrist enthielt. Dieser Mahnbrief zeigte eine grosse Resonanz, weil es
einigen Befragten aus terminlichen Gründen nicht möglich war, ihren Fragebogen bis
zum vorgegebenen Zeitpunkt zurückzuschicken. Sie konnten mit Hilfe des Faxformulars
ihren Einsendetermin bekanntgeben und hatten damit Gewähr, dass ihr Fragebogen bei
der Auswertung noch berücksichtigt wurde.
Unmittelbar nach Eintreffen der Fragebogen erfolgte eine Konsistenzprüfung der Antworten. Bei Unstimmigkeiten wurde telefonisch Kontakt mit den entsprechenden Personen aufgenommen und versucht, die festgestellten Probleme zu klären.
227
5.3.3.3 Datenauswertung
Die Datenerfassung wurde in MS-Excel 7.0 vorgenommen. Zur Erfassung der Anworten
wurden sämtliche Frage codiert. In Abhängigkeit von der Fragestellung kamen für die
Messung der einzelnen Merkmalsausprägungen unterschiedliche Skalenniveaus zur Anwendung. Eine Übersicht über die verschiedenen Skalentypen gibt Tab. 5-1.
Skalentyp
Merkmale
Beispiele
Nominalskala
Bestimmung von Gleichheit und Ungleichheit, keine natürliche Reihenfolge der einzelnen Merkmale.
Autonummern, Farben
Ordinalskala
Zusätzlich: Es besteht eine Rangordnung zwischen den einzelnen Merkmalsausprägungen.
Schulnoten, Richtersche Erdbebenskala,
Windstärkenskala
Intervallskala
Zusätzliche: Abstände (Intervalle)
zwischen den einzelnen Merkmalsausprägungen sind gleich, willkürlich
festgelegter Nullpunkt.
Temperaturskala nach Fahrenheit
Verhältnisskala
(Ratioskala)
Zusätzlich: Bestimmung gleicher Verhältnisse, absoluter Nullpunkt.
Längenmasse, Alter, Einkommen, Temperaturskala nach Kelvin
Tab. 5-1: Übersicht zu den verschiedenen Skalentypen.233
Die deskriptive Auswertung des Zahlenmaterials erfolgte ebenfalls in MS-Excel. Alle
weiteren statistischen Analysen, insbesondere die Überprüfung der einzelnen Hypothesen, wurden mit dem Statistikprogramm SYSTAT 6.01 vorgenommen.
5.3.3.4 Statistische Analyseverfahren
Bei der Auswertung der verschiedenen Fragen kamen sowohl univariate als auch biund multivariate statistische Analyseverfahren zum Einsatz.
Im erstgenannten Bereich erfolgt die Bestimmung rein deskriptiver Grössen. Darunter
fällt die Ermittlung von relativen und absoluten Häufigkeiten sowie deren kumulierte
Werte (kumulierte relative und absolute Häufigkeiten). Daneben sind zur Bestimmung
der zentralen Tendenz in Abhängigkeit vom vorhandenen Skalenniveau unterschiedli-
233
Vgl. z.B. Atteslander (1995), S. 267; Bleymüller/Gehlert/Gülicher (1996), S. 3 f.; Bortz (1984),
S. 44 f.
228
che Mittelwertsmasse (Modus, Median, arithmetisches Mittel) errechnet worden. Die
Messung der Streuung der Merkmalsausprägungen um einen Mittelwert erfolgte durch
Ermittlung der zugehörigen Varianzen und Standardabweichungen. Eine Beschreibung
der dargestellten Messgrössen kann Tab. 5-2 entnommen werden.
Statistische
Masszahlen
Skalenniveau
Beschreibung
Modus
Nominal
Merkmalsausprägung, welche am häufigsten vorkommt
(häufigster Wert)
Median
(Zentralwert)
Ordinal
Durch den Median wird der Wert bezeichnet, der in einer
der Grösse nach geordneten Reihe in der Mitte steht.
~
x = x  N +1 
 2 


Arithmetisches
Mittel
Intervall
Standardabweichung
Intervall
Durchschnittswert
1 N
x = ∑ xi
N i =1
Streuungsmass zu den Abweichungen der Einzelwerte von
ihrem arithmetischen Mittel
N
σ=
Varianz
Intervall
∑ (x
i =1
i
− x) 2
N
Arithmetisches Mittel der Abweichungsquadrate
σ2 =
1 N
∑ (x − x )
N i =1 i
Tab. 5-2: Masszahlen der deskriptiven Statistik.234
Im wesentlichen wurden in dieser Untersuchung Zusammenhänge oder Unterschiede
(Zusammenhangs- und Unterschiedshypothesen) zwischen zwei oder mehreren Variablen untersucht. Zur Messung dieser Unterschiede oder Zusammenhänge kommen die
eingangs genannten biund multivariaten Analyseverfahren zum Einsatz.
234
Vgl. z.B. Bleymüller/Gehlert/Gülicher (1996) S. 7 ff.
229
Die Beurteilung der Ergebnisse aus den hypothesenprüfenden Analysen erfolgt anhand
der Errechnung von Testgrössen und deren Gegenüberstellung zu entsprechenden
Grenzwerten (Signifikanzniveau). Üblicherweise wird das Signifikanzniveau in ähnlich
gelagerten Untersuchungen auf einer Höhe von α = 0.05 festgelegt. Dies bedeutet,
dass eine aufgestellte Hypothese bei 5 von 100 Realisierungen in den Ablehnungsbereich fallen würde. Bei der Bewertung einer Hypothese wird die aus der statistischen
Analyse gewonnene Irrtumswahrscheinlichkeit (p) dem vor Testbeginn festgelegten Signifikanzniveau (α) gegenübergestellt und anhand dieses Vergleichs über die Annahme
oder Ablehnung der Hypothese entschieden.235 Eine differenziertere Bewertung der
einzelnen Irrtumswahrscheinlichkeiten kann Tab. 5-3 entnommen werden.
Irrtumswahrscheinlichkeiten
Signifikanzniveau
p > 0.05
Keine Signifikanz
0.05 ≥ p > 0.01
Schwache Signifikanz
0.01 ≥ p > 0.001
Mittlere Signifikanz
P ≤ 0.001
Hohe Signifikanz
Tab. 5-3: Irrtumswahrscheinlichkeiten und Signifikanzniveaus.236
Zur Überprüfung, ob der gefundene Unterschied oder Zusammenhang signifikant von 0
verschieden ist, kommen verschiedene inferenzstatitische Verfahren zum Einsatz. Die
Bestimmung eines geeigneten Testverfahrens wird anhand folgender Kriterien vorgenommen:
• Stichprobenverteilung (parametrische und nicht-parametrische Verfahren)
• Skalenniveau der einzelnen Variablen
• Abhängigkeit der Stichprobe
235
236
Vgl. z.B. Bortz (1985), S. 141 ff.; Diekmann (1995), S. 589.
Vgl. z.B. Sachs (1992), S. 188.
230
Zum Test der Unterschieds- und Zusammenhangshypothesen kommen in dieser Untersuchung folgende inferenzstatistischen Verfahren zur Anwendung:
• Korrelationsanalysen zur Bestimmung der Stärke eines Zusammenhangs
• Lineare Regressionsanalyse zur Bestimmung der Richtung des Zusammenhangs
• t-Test für den Mittelwertsvergleich (Unterschiedshypothesen)
• F-Test für die Überprüfung der Varianzhomogenität.237
In Abhängigkeit vom Skalenniveau der beiden korrelierenden Variablen stellt SYSTAT
6.01 unterschiedliche Korrelationsanalyseverfahren zur Verfügung (vgl. Tab. 5-4).
Skalennivau
Intervall
Ordinal
Nominal
Intervall
Pearson ProduktMoment-Korrelation
Ordinal
-
Spearman RangKorrelation, Kendalls tau,
Goodmann/Kruxals, etc.
Nominal
Punkt-biseriale Korrelation
Biseriale Rangkorrelation Phi-Koeffizient
Tab. 5-4: Übersicht über die verwendeten Korrelationsanalyseverfahren. 238
Anhand der dargestellten Verfahren kann die statistische Signifikanz der aufgestellten
Hypothesen überprüft und daraus entsprechende Gestaltungsempfehlungen abgeleitet
werden.
237
238
SYSTAT berücksichtigt beim Mittelwertsvergleich sowohl homogener als auch inhomogene Varianzen
und errechnte zwei unterschiedliche t-Werte. Durch den F-Test lässt sich ermitteln, welcher t-Wert
verwendet werden muss.
Vgl. Blankenberger (1994), S. 42.
231
5.4 Darstellung der Ergebnisse
5.4.1 Konzeptionelle Grundlagen
Die im folgenden dargestellten Ergebnisse basieren auf dem im Anhang B abgedruckten
Fragebogen. Der Aufbau der einzelnen Fragenblöcke richtet sich nach den einzelnen
Phasen des Einführungsprozesses, wobei aus bereits erwähnten Gründen ein Schwergewicht auf Projektmanagementaspekte gelegt wurde.
Die Untersuchung der Einführungsprojekte erfolgte primär auf der Basis von geschlossenen Fragen, welche nur eine beschränkte Zahl fest vorgegebener Antworten zuliessen.
Neben geschlossenen Fragen wurde eine geringe Anzahl offener Fragen gestellt. Die
Antwortenden waren in erster Linie aufgefordert, Probleme sowie Gründe für bestimmte Verhaltensweisen in speziell interessierenden Bereichen festzuhalten. Die Auswertung solcher offenen Fragen stellt hohe Anforderungen. Es wurde versucht, die dazu
erforderliche Klassenbildung möglichst objektiv vorzunehmen. Allerdings entsteht bei
Fragenkomplexen dieser Art unvermeidlich ein Interpretationsspielraum, welcher verschiedene Betrachtungsweisen zulässt. Aus diesem Grund wird jeweils darauf hingewiesen, dass die Auswertung aufgrund einer offenen Fragestellung erfolgt ist.
5.4.2 Profil Schweizer R/3-Anwender
5.4.2.1 Unternehmensgrösse
Zur Bestimmung der Unternehmensgrösse wurden der Umsatz und die Anzahl Mitarbeiter als Messgrössen herangezogen. Von den 95 untersuchten Unternehmungen
machten insgesamt 66 Angaben über ihren Umsatz. Die Umsätze der R/3 einsetzenden
Unternehmen liegen zwischen 6.5 Mio und 15 Mia CHF, der Medianwert bei 300 Mio
CHF. Bei Betrachtung der Umsatzverteilung (vgl. Abb. 5-4) fällt auf, dass 42% der untersuchten Unternehmungen einen Umsatz von weniger als 200 Mio und 70% von weniger als 500 Mio CHF erzielen.
232
50%
8
40%
6
30%
4
20%
2
10%
0
0%
Kumulierte Häufigkeit
10
>1000
60%
901-1000
12
801-900
70%
701-800
14
601-700
80%
501-600
16
401-500
90%
301-400
18
201-300
100%
101-200
20
<100
Anzahl Unternehmen
Jahresumsatz der Unternehmen mit R/3-Einsatz
(n=66)
Umsatz (in Mio CHF)
Abb. 5-4: Jahresumsatz der untersuchten Unternehmungen.
Zu Abb. 5-4 ist anzumerken, dass sich unter den antwortenden Unternehmen einerseits
Konzerne befanden, welche das R/3-System entweder konzernweit oder in einzelnen
Tochtergesellschaften einsetzen (daher die hohen Umsatzwerte), und andererseits einzelne Unternehmungen, welche Tochtergesellschaften internationaler Konzerne sind
und indirekt von einer konzernweiten R/3-Einführung betroffen waren. Dies erklärt
wahrscheinlich die teilweise sehr geringen Umsatzwerte der antwortenden Unternehmungen.
Wird die Unternehmensgrösse aus der Sicht der Mitarbeiterzahlen betrachtet, schwankt
sie zwischen 4 (!) und 60'000 Mitarbeitern (vgl. Abb. 5-5). Im Durchschnitt beschäftigt
eine Schweizer Unternehmung mit R/3-Einsatz 515 Mitarbeiter (Medianwert).
233
Anzahl Mitarbeiter in den untersuchten Unternehmen
(n=90)
25
100%
20
80%
70%
15
60%
50%
10
40%
30%
5
20%
Anzahl Unternehmen
90%
10%
>2000
1801-2000
1601-1800
1401-1600
1201-1400
1001-1200
801-1000
601-800
401-600
201-400
0%
<200
0
Anzahl Mitarbeiter
Abb. 5-5: Beschäftigtenzahl der untersuchten Unternehmen.
Bei Betrachtung von Abb. 5-5 wird eine Unterteilung der Schweizer R/3-Anwender in
zwei Klassen ersichtlich: Die mittelgrossen Unternehmen (KMU) mit bis zu 500 Beschäftigten und Grossunternehmen mit über 500 Beschäftigten. Unternehmen mit weniger als 100 Beschäftigten stellen nur eine kleine Randgruppe dar (vgl. Abb. 5-6).
Grössenverteilung der Unternehmen mit maximal 500 Mitarbeitern
(n=45)
14
12
Anzahl Unternehmen
10
8
6
4
2
Anzahl Mitarbeiter
Abb. 5-6: Grössenverteilung der Unternehmen mit maximal 500 Beschäftigten.
234
451-500
401-450
351-400
301-350
251-300
201-250
151-200
101-150
51-100
<50
0
Durchschnittlich werden von den Schweizer R/3-Anwendern 18 Mitarbeiter (Medianwert, n=86) in der Informatik-Abteilung beschäftigt. Die Grösse der InformatikAbteilungen hat mit der Einführung von R/3 leicht abgenommen. Dabei wurden in diesem Funktionsbereich in 13 Unternehmen insgesamt 120 Stellen abgebaut und in 24
Unternehmen 51.5 Stellen neu geschaffen, in 34 Unternehmen blieb die Anzahl der
Beschäftigten in der Informatik unverändert (n=71). Insgesamt wurden in 71 Unternehmen netto 68.5 Stellen abgebaut. Dies entspricht einem durchschnittlichen Stellenabbau von 5.4 % oder rund einer Stelle bei der durchschnittlichen Unternehmung mit
R/3-Einsatz. Bei genauerer Analyse der Zahlen kann festgestellt werden, dass in grösseren Unternehmungen verhältnismässig mehr Stellen abgebaut wurden als in kleineren.
235
5.4.2.2 Branchenherkunft
Neben der Unternehmensgrösse wurde auch die Branchenzugehörigkeit der R/3Anwender untersucht. Dabei zeigt sich, dass über zwei Fünftel der R/3-Anwender (44%)
aus dem Industriesektor (vgl. Abb. 5-7) stammen. Innerhalb dieses Sektors sind die
Chemie mit einem Anteil von 10% und die Maschinenindustrie mit 7% am stärksten
vertreten.
Branchenzugehörigkeit der R/3-Anwender
(n=119, inkl. Mehrfachnennungen)
Telekommunikation
3%
Baugew erbe
7%
Andere
6%
Maschinenindustrie
7%
Öffentliche Verw altungen
4%
Elektrizität/Wasser
5%
Chemie
10%
Medien/Verlage
4%
Pharma
3%
Nahrungsmittelindustrie
3%
Übrige Dienstleistungen
8%
Uhrenindustrie
3%
Versicherungen
6%
Banken/Finanzdienstleistungen
7%
Detailhandel
3%
Übrige Industrie
18%
Handel
6%
Maschinenindustrie
Industriesektor
Detailhandel
Handel
Banken/Finanzdienst-leistungen
Dienstleistungssektor
Öffentliche
Übrige Branchen
Verw altungen
Abb. 5-7: Branchenzugehörigkeit der R/3-Anwender.
236
Dienstleistungsbetriebe stellen mit einem Gesamtanteil von 21% eine recht starke Anwendergruppe dar. Banken und Versicherungen setzen R/3 vor allem im Bereich des
Rechnungswesens ein (vgl. dazu Abb. 5-11).
Der Handel ist unter den R/3-Anwender relativ schwach vertreten (9%). Der Grund dafür kann auf den relativ geringen Funktionsabdeckungsgrad der Standardmodule und
die aufgeschobene Freigabe einer entsprechenden Branchenlösung/Industry Solution
(IS-Retail) zurückzuführen sein.
Bei einer Gesamtbetrachtung fällt auf, dass das R/3-System in sehr unterschiedlichen
Branchen eingesetzt wird. Dies ist auf die grosse Funktionsvielfalt der Standardmodule,
auf die hohe Flexibilität durch umfangreiche Anpassungsmöglichkeiten (Customizing)
und die für viele Branchen vorhandenen Speziallösungen (Industry Solutions) zurückzuführen. Diese Vorteile werden allerdings durch entsprechend hohe Komplexität bei
der Handhabung des Systems erkauft. Konkurrenzprodukte, welche auf ganz bestimmte
Branchen ausgerichtet sind, bieten Vorteile in der einfacheren Handhabung und decken
die realisierten Geschäftsprozesse möglicherweise in ähnlicher Form ab. Beim Kauf von
R/3 werden in allen Fällen Funktionen miterworben, die keine Verwendung finden.
Dies kann sich insbesondere für Grossunternehmungen bei organisatorischen und
strukturellen Änderungen durch die relativ rasche Aktivierung bisher nicht verwendeter
Funktionen positiv auswirken. Es ist allerdings von Vorteil, mögliche Szenarien in dieser
Hinsicht bereits bei der Implementierung des Systems zu berücksichtigen (z.B. flexibler
Aufbau der Organisationsstruktur). Die nachträgliche Änderung der abgebildeten Organisationsstrukturen kann erhebliche Aufwände verursachen.
Zusammenfassend lässt sich festhalten, dass die durchschnittliche Unternehmensgrösse
für den Einsatz des R/3-Systems bei einem Jahresumsatz von 300 Mio CHF und einer
Mitarbeiterzahl von 515 liegt. Interessant ist auch die Tatsache, dass 70% der untersuchten Unternehmen weniger als 500 Mio CHF Jahresumsatz erzielen. Daneben setzen aber auch einige sehr grosse Unternehmungen das R/3-System ein. Bezüglich Branchenverteilung dominiert der Industriesektor mit 44%. Im Bereich des Handels ist noch
ein eher zögerlicher Einsatz festzustellen (9%). Die Dienstleistungsbranche stellt mit 21%
237
ebenfalls eine starke R/3-Anwendergruppe dar. Bezüglich der genutzten Funktionalität
sind in den einzelnen Branchen grosse Unterschiede festzustellen.
5.4.2.3 Umfang des R/3-Einsatzes
Auf die Frage nach den eingesetzten Modulen haben alle R/3-Anwender geantwortet.
Bei Betrachtung der Ergebnisse (vgl. Abb. 5-8) fällt auf, dass in erster Priorität die Module des Rechnungswesens (FI, CO, AM) und in zweiter und dritter Priorität jene des
Logistikbereichs (MM, SD) und des Personalwesens (HR) eingesetzt werden. Weniger
häufig (46%) wird das Modul PP eingesetzt und die Module PM, PS, QM kommen vergleichsweise selten zum Einsatz. Durchschnittlich setzen die betrachteten Unternehmen
6 Module des R/3-Systems ein. In dieser Hinsicht besteht zwischen Grossunternehmen
und KMUs statistisch kein signifikanter Unterschied (vgl. H 1.3).239 Beide setzen gleich
viele R/3-Module ein.
Da die Module FI und CO die Grundlagen für den Einsatz aller anderen Module darstellen, ist dieses Ergebnis keineswegs erstaunlich. Die vorhandenen gesetzlichen Bestimmungen haben bei FI und HR zu einer weitgehenden Standardisierung der betrieblichen Anforderungen unabhängig von der Branche geführt. In bezug auf die gesetzlichen Vorgaben nimmt das HR-Modul eine ähnliche Stellung ein. Der Integrationsgrad
mit anderen Modulen ist allerdings wesentlich geringer. Die Logistikmodule lassen sich
nur in gewissen Branchen (vorwiegend in der Industrie) einsetzen. Während die Module
MM und SD ein breiteres Einsatzspektrum besitzen, beschränkt sich der Einsatzbereich
des PP-Moduls in der Regel auf Produktionsbetriebe. Darüber hinaus unterstützt das
Modul PP erst seit Release 3.0 die wichtigsten Funktionen der Produktionsplanung und
-steuerung. Die übrigen Module PM, PS, QM und die Branchenlösungen (IS) stellen
Spezialfunktionen dar. Der Verbreitungsgrad ist deswegen im Verhältnis zu den zuvor
erwähnten Modulen relativ gering.
239
Diese Aussagen beziehen sich immer auf die im ersten Teil dieses Kapitels dargestellten Hypothesen.
(H 1.3 = Hypothese 1.3 im Bereich der unternehmensbezogenen Bedingungsgrössen).
238
Eingeführte Module
(n=95)
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
FI
CO
MM
AM
HR
SD
PP
PM
PS
QM
IS
Abb. 5-8: Eingeführte Module.
Im Unterschied zu der 1994 durchgeführten Untersuchung240 zeigt sich, dass MM an
Bedeutung gewonnen hat und mittlerweile häufiger eingesetzt wird als die Module AM
und HR. Auch das Modul PM (Instandhaltung), welches im Sommer 1996 einen höheren Verbreitungsgrad aufwies als die Module QM und PS, hat an Bedeutung gewonnen.
Im Industriesektor werden die Logistik-Module (MM, SD, PP) und das Personalmodul
(HR) beinahe in gleichem Umfang genutzt wie die verschiedenen Module des Rechnungswesens FI, CO und AM (vgl. Abb. 5-9). Die übrigen Anwendungsmodule des R/3Systems spielen auch hier eine untergeordnete Rolle.
240
Vgl. Knolmayer/Portner/von Arb (1995), S. 27 f.
239
Eingesetzte Module in der Industrie
(n=41)
45
40
35
Anzahl Module
30
25
20
15
10
5
0
FI
CO
MM
AM
HR
SD
PP
PM
PS
QM
IS
Abb. 5-9: Moduleinsatz in der Industrie.
Bei Betrachtung des Moduleinsatzes im Handel zeigt sich ein ähnliches Bild (vgl. Abb.
5-10). Mit Ausnahme des PP-Moduls, welches nur in Handelsbetrieben mit eigener
Produktion (z.B. im Baustoffhandel) eingesetzt wird, sind der Finanz- und der Logistikbereich in etwa gleich stark vertreten. Auch hier werden die Module PM, PS und QM
nur selten eingesetzt.
Eingesetzte Module im Handel
(n=7)
8
7
6
5
4
3
2
1
0
FI
CO
MM
AM
Abb. 5-10: Moduleinsatz im Handel.
240
HR
SD
PP
PM
PS
QM
IS
Im Dienstleistungssektor dominieren eindeutig die Module des Rechnungswesens (vgl.
Abb. 5-11). Bei rund der Hälfte der Dienstleistungsunternehmen wird das HR-Modul
eingesetzt. Die verschiedenen Logistik-Module werden hingegen eher selten genutzt.
Die zunächst überraschend erscheinende PP-Installation ist auf eine Versicherungsgesellschaft zurückzuführen, welche Sicherheitsartikel in eigener Produktion herstellt. Relativ häufig werden im Dienstleistungssektor Branchenlösungen (IS) eingesetzt. Im Unterschied zu den anderen Branchenzweigen werden im Dienstleistungssektor
im
Durchschnitt nur rund 4 R/3-Module eingesetzt (vgl. H 1.4).
Eingesetzte Module im Dienstleistungssektor
(n=19)
20
18
16
14
12
10
8
6
4
2
0
FI
CO
MM
AM
HR
SD
PP
PM
PS
QM
IS
Abb. 5-11: Moduleinsatz in der Dienstleistungssektor.
Bei einer Gesamtbetrachtung fällt auf, dass der Einsatz der Module des Rechnungswesens (FI, CO) dominiert. Zunächst überraschend erscheint der eher zurückhaltende Einsatz von R/3 im Personalwesen. Gründe dafür mögen die grosse Vielfalt der branchenspezifischen Eigenheiten und in dem relativ geringen Integrationsgrad zu den anderen
Modulen zu suchen sein. In vielen Fällen werden Branchenspezifika durch das Modul
HR nicht ausreichend abgedeckt und machen die Entwicklung von Erweiterungen notwendig. Die geringe Integration und eine weit verbreitete Praktik, Personalinformationssysteme aus Datenschutzgründen von den übrigen Systemen abzukoppeln mögen für
den zurückhaltenden Einsatz von HR mitverantwortlich sein.
241
Demgegenüber steht die Möglichkeit, HR durch den geringen Integrationsgrad zunächst
isoliert einzusetzen (z.B. um Erfahrungen mit Client/Server-Architekturen zu sammeln)
und später zu einem breiten R/3-Einsatz überzugehen. Die Bedenken im Hinblick auf
den Datenschutz sind aus systemtechnischer Sicht eigentlich unbegründet, da über ein
relativ komplexes, aber dennoch gut funktionierendes Berechtigungssystem die Zugriffe
auf die sensitiven Personaldatenbestände klar geregelt werden können.
Einen weiteren Untersuchungsgegenstand stellten die R/3 einsetzenden Organisationseinheiten dar. Die Architektur des R/3-Systems ist technisch und betriebswirtschaftlich
grundsätzlich für den Einsatz in Konzernen ausgelegt; es kann aber natürlich auch in
einzelnen Unternehmen eingesetzt werden. Bei der Betrachtung der Unternehmensgrösse der Schweizer R/3-Anwender fällt auf, dass vorwiegend mittelgrosse Unternehmen
das System einsetzen.
R/3-Einsatz heute
(n=89)
Konzernw eit
16%
In mehreren
Unternehmen
des Konzerns
22%
R/3-Einsatz in Zukunft
(n=59)
In einzelnen
Unternehmensbereichen
28%
Unternehmensw eit
34%
Konzernw eit
29%
In mehreren
Unternehmen
des Konzerns
12%
In einzelnen
Unternehmensbereichen
14%
Unternehmensweit
45%
Abb. 5-12: Ausdehnung des R/3-Einsatzes (Heute - In Zukunft).
Diese Annahme wird durch die Analyse der organisatorischen Ausdehnung des R/3Systems bestätigt (vgl. Abb. 5-12). Momentan ist in vielen Projekten die Endausbaustufe
trotz produktivem R/3-Einsatz noch nicht erreicht. Vielerorts wird R/3 nur in Teilbereichen des Unternehmens eingesetzt (28%). Auf Konzernebene ist ein ähnliches Phänomen zu beobachten. In mehreren Fällen (22%) kommt das R/3-System vorerst nur in
242
einzelnen Tochtergesellschaften zum Einsatz. Später soll R/3 im gesamten Konzern eingesetzt werden. Bei Betrachtung des künftigen R/3-Einsatzes wird auch deutlich, dass
sich die R/3-Anwender, wie bereits angedeutet, in eine 'Zweiklassengesellschaft' aufspalten. Auf der einen Seite befinden sich Grossunternehmen, welche das System konzernweit einsetzen (29%) und auf der andern Seite der grosse Anteil an mittelständischen Unternehmungen (45%), bei welchen sich der Einsatz auf das einzelne Unternehmen beschränkt. Bei dieser Aussage ist allerdings zu berücksichtigen, dass nur 66%
der befragten Unternehmen Angaben über einen künftigen R/3-Einsatz gemacht haben.
5.4.3 Evaluation und Produktentscheid
5.4.3.1 Auslösende Faktoren
Bevor auf die Evaluation von EMS eingegangen wird, sollen vorerst die für die Auslösung
von Einführungsprojekten relevanten Faktoren dargestellt werden (vgl. Abb. 5-13).
Die Notwendigkeit für die Initialisierung von R/3-Projekten ist nach Meinung der Befragten hauptsächlich auf eine veraltete bestehende IV-Infrastruktur, auf hohe Wartungs- und Entwicklungskosten bei Individuallösungen sowie auf Probleme mit der Integration von Insellösungen zurückzuführen. Daneben spielen die zu erwartenden Vorteile von Standardsoftware (erweiterte Funktionalität, neue Technologie, schnelle Verfügbarkeit) ebenfalls eine wichtige Rolle bei der Initiierung von EMS-Evaluationen.
Erstaunlicherweise werden Markteinflüssen in diesem Zusammenhang eher eine geringe
Bedeutung beigemessen. Auch die Lösung des "Jahr 2000-Problems"241 spielt nach den
Angaben der Befragten für den Übergang auf EMS nur eine untergeordnete Rolle.
241
Vgl. z.B. Knolmayer (1997).
243
Evaluationsauslösende Faktoren
(n=75)
Veraltete bisherige DV-Infrastruktur
Erweiterte Funktionalität
Einsparung von Entwicklungs- und Wartungskosten
Verfügbarkeit neuer Technologien
Probleme mit Insellösungen
Schnelle Verfügbarkeit
Förderung interner Reorganisationen
Zu teure bisherige DV-Infrastruktur
Preisverfall der Hardware
Veränderte Konkurrenzsituation
Lösung des "Jahr 2000-Problems"
Globalisierung von Märkten
Deregulierung von Märkten
0%
völlig
unbedeutend
25%
unbedeutend
50%
mittlere
Bedeutung
75%
wichtig
100%
sehr
wichtig
Abb. 5-13: Auslösende Faktoren für die Evaluation von EMS.
Ein weiterer erwähnenswerter Faktor, welcher in der Literatur immer wieder hervorgehoben wird, ist die Bedeutung von Standardsoftware als Katalysator unternehmensinterner Reorganisationen.242 Dieser Faktor wurde von den Befragten nur knapp als "wichtig"
beurteilt. Betriebliche Reorganisationsmassnahmen sind in der Praxis oftmals schwierig
durchzusetzen. Gründe dafür sind Akzeptanzschwierigkeiten bei den Betroffenen und
das Fehlen entsprechender Sachzwänge. Mit Einführung eines EMS können die vielerorts längst fälligen organisatorischen Änderungen quasi als Sachzwang vermittelt werden. Das Projektmanagement sollte in diesem Zusammenhang dafür zu sorgen, dass
durch flankierende Massnahmen (z.B. rechtzeitige Information und Einbezug der Anwender) keine Widerstände entstehen.
242
Vgl. Adler (1990), S. 163; Barbitsch (1996), S. 16, 46; Meinhardt/Teufel (1995), S. 69 ff.
244
5.4.3.2 Intensität der Evaluation
Nach der Initiierung eines Einführungsprojektes stellt sich die Frage nach der Art und
Intensität der Evaluation. Der Markt bietet heute eine Vielzahl unterschiedlicher Produkte und im Prinzip kann nur durch eine umfangreiche Evaluation gewährleistet werden, dass auch wirklich ein den Bedürfnissen entsprechendes EMS gewählt wird. Dazu
sollte ein Pflichtenheft erstellt und ein Vergleich verschiedener Produkte auf der Basis
der formulierten Kriterien vorgenommen werden.
Diese Idealvorstellung wird von den Befragten nicht unterstützt. 71% der R/3-Anwender
haben vor der Produktentscheidung gar kein Pflichtenheft erstellt. Dies mag verschiedene Gründe haben: Einerseits waren unter den Befragten Tochtergesellschaften internationaler Konzerne, die sich gar nicht mit einer Evaluation befassen mussten, da die strategische Entscheidung für den Einsatz des R/3-Systems auf Konzernebene getroffen
wurde.243 Andererseits folgen viele Anwender einer allgemein vorherrschenden "metoo"-Strategie, vergleichbar mit dem IBM-Phänomen in den 60er und 70er Jahren.
Bei einigen R/3-Anwendern wurde trotz fehlendem Pflichtenheft nicht auf die Evaluation von Konkurrenzprodukten verzichtet. Ohne zugrundeliegende, klar formulierte Kriterien erscheint ein qualifizierter Vergleich jedoch fragwürdig.
29% der Befragten hatten ein Pflichtenheft erstellt und dafür durchschnittlich 100 Stunden (Medianwert) aufgewendet. Bei seiner Erstellung ist allerdings eine Trendwende zu
beobachten. Während früher eine detaillierte Analyse der Ist-Situation durchgeführt und
daraus die Soll-Vorstellungen abgeleitet wurden, verzichtet man heute aufgrund der
existierenden Referenzmodelle weitgehend auf eine detaillierte Ist-Zustandserfassung
und bestimmt in einem Soll-Konzept nur die Kernprozesse.244 Dies wird dadurch begründet, dass bei einer zu detaillierten Erfassung der Ist-Situation die Gefahr der Zementierung vorhandener Abläufe besteht und dadurch ein EMS mit grossem Aufwand
243
244
Vgl. Meinhardt/Teufel (1995), S. 76.
245
an suboptimale Prozesse angepasst werden muss, obwohl das System bessere Lösungen
anbieten würde.245
Interessant ist bei der Betrachtung des Evaluationsprozesses auch die Frage, ob in der
Intensität der Evaluation zwischen Grossunternehmen und KMUs Unterschiede bestehen. Hier zeigen sich identische Verhaltensmuster. Obwohl der Einsatz von R/3 in
KMUs eher zu hinterfragen ist, lässt sich kein signifikanter Unterschied in der Intensität
der Evaluation feststellen (H 1.16).
5.4.3.3 Konkurrenzprodukte
Die Befragten haben im Rahmen ihrer Evaluationen neben dem R/3-System insgesamt
50 verschiedene Konkurrenzprodukte (n=104) in die nähere Auswahl miteinbezogen.
Neben den drei in der Schweiz am häufigsten mit dem R/3-System konkurrierenden
Produkten Oracle Applications, Baan IV und Karat wurden u.a. Produkte wie BPCS,
PIUSS penta, Abacus, JDE, Movex, Mosaic, CGI und Marcam Prism in die Evaluation
miteinbezogen (vgl. Abb. 5-14). Das Vorhandensein einer grossen Restgruppe (39%)
weist auf die Vielfalt des Produkteangebots hin. Die dargestellten Systeme decken teilweise sehr unterschiedliche Bereiche ab. Dies verdeutlicht, dass oftmals auch nur Teilbereiche des R/3-Systems mit anderen Produkten verglichen werden.
245
Vgl. z.B. Vaske (1996), S. 7.
246
Konkurrenzprodukte
(n=104)
Oracle Applications
12
Baan IV
10
Übrige
42
Karat
10
BPCS
6
Prism
CGI
2
2 Mosaic
Movex
3
4
JDE
4
Abacus
4
PIUSS Penta
5
Abb. 5-14: In Konkurrenz zu R/3 evaluierte Produkte.
Diesen Resultaten sei hinzugefügt, dass in obiger Darstellung nur Produkte aufgeführt
sind, welche Schweizer Unternehmen in Konkurrenz zu R/3 evaluiert haben. Alle ähnlich gelagerten Projekte, bei denen schliesslich ein anderes Produkt gewählt wurde, sind
hier nicht berücksichtigt. Aus Abb. 5-14 kann somit nicht auf die Marktanteile verschiedener EMS-Hersteller auf dem Schweizer Markt geschlossen werden.
In Tab. 5-5 sind Quellen für weitere Informationen zu den in Abb. 5-14 genannten Systemen zusammengestellt.
247
Produkt
Hersteller
WWW-Adresse
Abacus
Abacus
http://www.abacus.ch/
Baan IV
Baan
http://www.baan.com/
BPCS
SSA
http://www.ssax.com/
Sigagip/HR-Access
IBM/CGI
http://www.hraccess.com/
JDE
J.D. Edwards
http://www.jdedwards.com/
Mosaic
Fides Informatik
http://www.fides.ch/
Movex
Movex
http://www.movex.com/
Oracle Applications
Oracle
http://www.oracle.com/
PeopleSoft
PeopleSoft
http://www.peoplesoft.com/
PIUSS penta
PSI
http://www.psi.de/
PRISM
Marcam
http://www.marcam.com/
R/3
SAP AG
http://www.sap-ag.de/
Tab. 5-5: Hersteller von in der Schweiz evaluierten EMS.
5.4.3.4 Gründe für die Wahl von R/3
Eine Machbarkeitsstudie haben 69% der befragten Unternehmen durchgeführt. Nicht
ermittelt wurde, auf welche Aspekte (finanzielle, technische und/oder organisatorische)
sich die Untersuchung der Machbarkeit konzentriert hat und wie umfassend diese
durchgeführt wurde.
Zur Frage nach den ausschlaggebenden Argumenten für die Wahl von R/3 haben sich
insgesamt 77 Unternehmen geäussert (vgl. Abb. 5-15). Als "sehr wichtig" wurde der Abdeckungsgrad der betriebswirtschaftlichen Anforderungen, der Integrationsgrad der einzelnen Module und das Potential für Weiterentwicklungen durch die SAP AG beurteilt.
Die Offenheit und die Flexibilität des R/3-Systems wurden neben der vorhandenen graphischen Benutzeroberfläche und der Marktstellung der SAP AG als "wichtig" erachtet.
Dies verdeutlicht, dass zum einen die Produkteigenschaften und zum andern ein grosses
Vertrauen in den Hersteller ausschlaggebend für die Wahl von R/3 waren.
248
Argumente für die Wahl von SAP R/3
(n=77)
Abdeckung betriebswirtschaftl. Anforderungen
Hoher Integrationsgrad der einzelnen Module
Potential für Weiterentwicklungen
Flexibler Einsatz (Anpassungsfähigkeit)
Offenheit der Systemarchitektur
Marktstellung/-position der SAP AG
Grafische Benutzeroberfläche (GUI)
Abbildbarkeit existierender Geschäftsprozesse
Wirtschaftlichkeitsüberlegungen
Sprach- und Währungsunabhängigkeit
Performance, Geschwindigkeit
Bestechender Gesamteindruck
Kundennähe durch leistungsfähige Informatik
Integrierte Entwicklungsumgebung
Internationale Ausrichtung
Offenes Unternehmensdatenmodell
Vorgehensmodell/Einführungsleitfaden
Integration von Microsoft-Produkten
Empfehlungen aus anderen Unternehmungen
Eigene Erfahrungen mit SAP R/2
Druck von Kunden/Lieferanten
0%
unbedeutend
25%
wenig
bedeutend
50%
mittlere
Bedeutung
75%
wichtig
100%
sehr
wichtig
u
Abb. 5-15: Ausschlaggebende Argumente für SAP R/3.
Zusammenfassend kann festgehalten werden, dass als Auslöser eines Einführungsprojekts vorwiegend das Vorhandensein einer veralteten IV-Infrastruktur sowie eine starke
Erwartungshaltung bezüglich der Nutzenpotentiale moderner EMS identifiziert werden
konnten. Die Intensität, mit der evaluiert wurde, besitzt für die Wahl von R/3 eher eine
sekundäre Rolle. Hauptargumente zugunsten von R/3 waren der hohe Funktionsabdekkungsgrad und das grosse Vertrauen in den Hersteller, dieses Produkt ständig weiterzuentwickeln und an neue Technologien und veränderte Bedürfnisse des Marktes anzupassen.
249
In einer im Frühjahr 1996 veröffentlichten, vieldiskutierten Publikation von Forrester
Research,246 welche die Zukunftsaussichten von R/3 eher kritisch darstellte, wurde darauf hingewiesen, dass die künftige Wettbewerbsfähigkeit von EMS-Herstellern im wesentlichen davon abhängen wird, wie es diesen gelingt, den Übergang zum Internet
Computing247 zu vollziehen. Darunter wird die Arbeit mit über das Internet kooperierenden Servern und Clients verstanden. Damit entsteht beispielsweise die Möglichkeit,
Geschäftsbeziehungen zu Kunden und Lieferanten über das Internet in direkter Verbindung mit dem EMS abzuwickeln.248 Die Internetfähigkeit ist zu einem wichtigen Wettbewerbsfaktor zwischen den EMS-Anbietern geworden.249 Abb. 5-16 zeigt die Einschätzung der Wichtigkeit der Internet- und Intranet-Integration in EMS durch Schweizer R/3Anwender.
Bedeutung von Internet und Intranets in EMS (heute)
Interessant, jedoch unter Sicherheitsaspekten problematisch
Eher unbedeutend, da in w eltw eit operierenden Unternehmen andere
interne und ex terne Kommunikationsmöglichkeiten existieren
Sehr w ichtiger Wettbew erbsfaktor sow ohl für SAP als auch für die
R/3-Kunden
Ist ein zentrales Ev aluationskriterium
Bedeutungslos
Andere Einschätzungen
0
5
10
15
20
25
30
35
40
45
50
Anzahl Nennungen
Abb. 5-16: Bedeutung von Internet Computing (Sommer 1996).
Es fällt auf, dass zum Zeitpunkt der Befragung Internet-Technologien zwar als "interessant" eingestuft wurden, im Hinblick auf Sicherheit aber erhebliche Vorbehalte festzu-
246
247
248
249
Vgl. Cameron et al. (1996).
Vgl. Robb et al. (1995).
Vgl. Kap 5.4.3.4.
Vgl. Cameron et al. (1996); Robb et. al. (1995).
250
stellen waren. Ferner glaubte rund ein Viertel der R/3-Anwender, dass der Einsatz von
Internet Computing im Verbund mit EMS eher unbedeutend ist, weil diese Aufgaben in
global operierenden Unternehmen bereits heute durch andere Systeme wahrgenommen werden. Bei der Frage nach der Einschätzung der künftigen Bedeutung der Internet- und Intranet-Technologie sieht der grösste Teil der Antwortenden diese Möglichkeit
als wichtigen Faktor beim Einsatz von EMS (vgl. Abb. 5-17).
Bedeutung von Internet und Intranets in EMS (in 3 Jahren)
Interessant, jedoch unter Sicherheitsaspekten problematisch
Eher unbedeutend, da in w eltw eit operierenden Unternehmen andere
interne und ex terne Kommunikationsmöglichkeiten ex istieren
Sehr w ichtiger Wettbew erbsfaktor sow ohl für SAP als auch für
die R/3-Kunden
Ist ein zentrales Ev aluationskriterium
Bedeutungslos
Andere Einschätzungen
0
5
10
15
20
25
30
35
40
45
50
Anzahl Nennungen
Abb. 5-17: Bedeutung von Internet Computing in Zukunft.
Nach einer rasanten Entwicklung bei der weltweiten Vernetzung im Jahr 1996 wird die
Notwendigkeit von Internet- und Intranet-Erweiterungen in EMS kaum mehr bezweifelt.
Bereits mit Release 3.1 verfügt das R/3-System über die Voraussetzungen zur direkten
Anbindung von eigenen Mitarbeitern und Geschäftspartnern über das Internet. Durch
die Einführung einer Java-Version des R/3-Frontends wird es sogar möglich sein, mit
einem normalen WWW-Browser auf dem R/3-System zu arbeiten resp. einen Teil der
PC-Arbeitsplätze durch preisgünstigere Network Computer250 (NC) zu ersetzen.
250
Network Computer = ein mit dem Netzwerk verbundener Arbeitsplatzrechner mit eigener CPU,
aber ohne Massenspeichermedien.
251
5.4.4 Projektmanagement
5.4.4.1 Hauptproblembereiche
Zum besseren Verständnis der für ein R/3-Projekt notwendigen Projektorganisation wird
zuvor auf die Hauptprobleme einer R/3-Einführung eingegangen. Dazu haben sich Vertreter von 93 Unternehmen geäussert. Die Komplexität des R/3-Systems befand sich mit
Abstand an erster Stelle unter den genannten Problembereichen. Zweitwichtigster Punkt
ist die unzureichende Freistellung der Projektmitarbeiter. Diese ist oftmals begründet in
der Teilzeit-Mitwirkung einzelner Mitarbeiter in einem R/3-Projekt bei gleichzeitig hoher
Belastung durch das Tagesgeschäft. Weitere nennenswerte Problembereiche sind Widerstände der Betroffenen, die häufigen Releasewechsel, die fehlende Verfügbarkeit
qualifizierter Berater und die unzureichende Ausbildung der eigenen Mitarbeiter. Alle
übrigen Problembereiche wurden von weniger als 25% der Befragten als "wichtig" erachtet.
Kritische Problembereiche
(n=93)
Komplex ität des R/3-Systems
Unzureichende Freistellung der Projektmitarbeiter
Widerstände gegen die Veränderung v on Geschäftsprozessen
Häufiger Releasew echsel
Fehlende Verfügbarkeit qualifizierter Berater
Unzureichende Ausbildung der Mitarbeiter
Unterschätzung v on Hardw are-Anforderungen
Fehlende Mitw irkung der Anw ender
Unvollständige/unpräzise Aufgabenstellung
Budgetüberschreitung
Unzureichender Support durch den Anbieter
Terminüberschreitung(en)
Unzureichende Unterstützung durch das Management
Unrealistische Zeitstrukturen
Vertragliche Probleme
Keine kritischen Situationen
Andere
0%
10%
20%
30%
40%
50%
Relative Anzahl Nennungen
Abb. 5-1: Kritische Problembereiche in den R/3-Einführungsprojekten.
252
60%
70%
Bei konkreter Betrachtung der Problembereiche aus Sicht der Projektleiter ergibt sich
ein ähnliches Bild (vgl. Abb. 5-2). Nachdem für die Nennung der Hauptproblembereiche von R/3-Projekten aus einer Liste von möglichen Problembereichen ausgewählt
werden konnte (inkl. Möglichkeit, zusätzliche Problembereiche zu formulieren), wurden
in der nachfolgend ausgewerteten Fragestellung keine Problemkategorien vorgegeben.
Hauptprobleme der Projektleiter
(n=196)
Fehlende Akzeptanz
Termindruck
Koordinationsprobleme
Zu geringe Entscheidkompetenzen/Verspätete Entscheide
Anforderungsspezifikation/Richtigen Umfang v on R/3 festlegen
Beraterabhängigkeit/Unzureichende R/3-Kenntnisse
Kommunikationsprobleme
Integration von Umsystemen
Probleme mit R/3
Motiv ationsprobleme im Projektteam
Komplex ität/Funktionsumfang
Integration von R/3
Budgetprobleme/Kostenüberw achung
Ständige Veränderung des Umfeldes
Überblick über das Projekt
0
5
10
15
20
25
30
Anzahl Nennungen
Abb. 5-2: Hauptprobleme des Projektleiters.
Akzeptanzprobleme stehen mit deutlichem Vorsprung an erster Stelle in dieser Liste.
Derartige Probleme sind bei Veränderungen der Organisation in einem Unternehmen
immer wieder anzutreffen. Da bei einer R/3-Einführung in der Regel weite Bereiche
eines Unternehmens betroffen sind und Anpassungen der Aufbau- und Ablauforganisation unumgänglich werden (vgl. Kap. 5.4.6), kommt die Problematik noch deutlicher
zum Ausdruck als in Projekten mit anderen inhaltlichen Schwerpunkten.
253
Ein weiteres Problem der Projektleiter, welches ebenfalls von über einem Viertel der
R/3-Anwender genannt worden ist, betrifft die unzureichende Freistellung der Projektmitarbeiter. Einzelne Mitarbeiter aus den Fachabteilungen werden z.B. zu 50% für die
Mitarbeit in einem R/3-Projekt verpflichtet. Gleichzeitig stehen aber für die Erledigung
des Tagesgeschäfts keine Ersatzkapazitäten zur Verfügung. Dies führt dazu, dass in einem beträchtlichen Ausmass Überstunden geleistet werden müssen und entweder die
Arbeit am Projekt oder das Tagesgeschäft teilweise vernachlässigt wird.
Ein ebenfalls häufig genanntes Problem ist der Zeitdruck, welcher vielen R/3-Projekten
anhaftet. Diese Problematik kann auf verschiedenen Ursachen beruhen. Oftmals werden zu ehrgeizige Zielsetzungen formuliert. Dies mag auf eine allgemeine Unterschätzung der Komplexität des R/3-Systems zurückzuführen sein. Eine weitere Ursache stellt
das zuvor angeschnittene Problem der unzureichenden Verfügbarkeit von Fachbereichsvertretern dar. Beide Faktoren können den Projektfortschritt verzögern (vgl.
H 4.7).
Koordinationsfragen wurden von 18 R/3-Anwendern als eines der Hauptprobleme
empfunden. Eine mangelnde Koordination mag verschiedene Gründe haben. Oftmals
stellt die Unerfahrenheit mit Projekten dieser Grössenordnung eine wesentliche Ursache
für Koordinationsprobleme dar. IV-Projekte betrafen früher häufig nur Teilbereiche eines Unternehmens. Ein EMS deckt die betrieblichen Prozesse durchgehend ab und erfordert daher zwingend ein funktionsübergreifendes Denken. Durch die zuvor oft vernachlässigte Prozessorientierung und der damit verbundenen geringen Bereitschaft zu
abteilungsübergreifendem Denken ist es schwierig, solche Denkprozesse anzustossen.
Ein weiterer Grund neben der Komplexität von R/3-Projekten mag in der unzureichenden Festlegung der Informationsflüsse vor Projektbeginn liegen. Dadurch fehlen vielfach
die notwendigen Informationen, um sich zielgerichtet verhalten zu können. Durch die
oftmals grosse Anzahl Mitarbeiter in einem R/3-Projekt und deren geringen Freistellungsgrad ergibt sich ein sehr hoher Koordinationsaufwand. Eine Empfehlung ist daher,
kleine und schlagkräftige Teams einzusetzen, deren Mitglieder über einen hohen Frei-
254
stellungsgrad verfügen, die notwendigen Fachkenntnisse und die nötige Motivation mitbringen.
Mehrfach wurde die Komplexität des R/3-Systems als Problem genannt. Die einzelnen
Facetten dieser Problematik wurden in Abb. 5-2 separat dargestellt. Eine Schwierigkeit
besteht darin, aus dem grossen Funktionsumfang von R/3 die relevanten Funktionen zur
optimalen Unterstützung der Geschäftsprozesse auszuwählen.
Der hohe Integrationsgrad von R/3 trägt ebenfalls zur Komplexität des Systems bei. Die
weitreichende Integration der einzelnen Funktionen ist oftmals nicht genügend transparent und bereitet bei der Umsetzung entsprechende Schwierigkeiten. Häufig ist diese
Problematik mit einem mangelnden Prozessdenken verbunden und es fehlt an Verständnis für die Probleme und Anforderungen anderer Funktionsbereiche innerhalb des
Unternehmens.
Die bei Einführung von neuen Releases vorhandenen Fehler im R/3-System sind eine
weitere Quelle für Projektverzögerungen. Beispielsweise versagt eine in einem früheren
Releasestand funktionierende Funktion ihren Dienst in einem neuen Release. Für die
betroffenen Mitarbeiter stellt sich die Frage, ob der Umstand auf fehlendes Verständnis
für das R/3-System (erweiterte Funktionalität) zurückzuführen ist oder ob es sich um
einen Fehler im neuen Release handelt.
Weitere häufig genannte Probleme sind u.a. fehlende Entscheidkompetenzen oder Verzögerungen beim Erwirken von Entscheidungen, unzureichende Fachkenntnisse der
Berater und Kommunikationsprobleme. Ferner wurden allgemeine ProjektmanagementProbleme mehrfach genannt.
255
5.4.4.2 Rechtliche Aspekte
Die Anwender sehen eine detaillierte Vertragsgestaltung nicht als zentralen Erfolgsfaktor
(vgl. Kap. 5.4.4.10). Dennoch darf diese Aufgabe nicht vernachlässigt werden. Die Formulierung von klaren Zielvorstellungen und eine angemessene Berücksichtigung solcher
Vorgaben in den Verträgen sind wichtige Voraussetzungen für den reibungslosen Ablauf
von Einführungsprojekten. Folgende Konfliktpotentiale konnten im Rahmen einer am
Institut für Wirtschaftsinformatik der Universität Bern durchgeführten Befragung ermittelt werden:
• Mangelhafte Vorgaben durch unvollständige Leistungsbeschreibung
• Performance-Probleme durch zu knapp bemessene Hardwareressourcen
• Zeitverzögerungen durch fehlende Präsenz oder mangelnde Fähigkeiten der Berater
• Zeitverzögerungen durch mangelnde Mitwirkung der Anwender (unzureichender
Freistellungsgrad)
• Verminderung von Gewährleistungsansprüchen bei Eingriffen in den Source Code.251
Bei der Betrachtung der Ergebnisse aus der aktuellen Befragung zeigt sich ein ähnliches
Bild. Rund 15% der Unternehmen gaben an, mit rechtlichen Problemen konfrontiert
gewesen zu sein. Ursachen dafür waren vor allem die Beschaffung von nicht einsatzkonformer Hardware, mangelhafte Kompetenzen der Berater sowie generell problematische Vertragsklauseln (vgl. Abb. 5-3).
251
Vgl. Marchand (1996), S. 80 ff.
256
Art der rechtlichen Probleme
Anschaffung nicht einsatzkonformer Hardw are
Mangelhafte Kompetenzen der Berater
Unfaire Vertragsklauseln
Ungenügend definierte Pflichten der Vertragspartner
Leistungsanpassungen nach Vertragsabschluss
Kostenüberschreitungen
Projektbeginn v or Vertragsabschluss
Andere
0
1
2
3
4
Anzahl Nennungen
Abb. 5-3: Rechtliche Probleme bei Einführung von R/3.
257
5.4.4.3 Projektorganisation
5.4.4.3.1 Projektgrösse
Bei der Betrachtung der Projektorganisation ist es sinnvoll, vorab einen Eindruck über
die Projektdimensionen zu gewinnen. Zu Beginn dieser Studie wurde die Grösse der
betrachteten Unternehmen erörtert. Dabei hat sich herausgestellt, dass auf der einen
Seite viele KMUs, auf der andern Seite viele Grossunternehmen das R/3-System entweder umfassend oder in Teilbereichen nutzen.
Budget für die R/3-Einführung
(n=61)
100%
14
90%
80%
10
70%
60%
8
50%
6
40%
30%
4
20%
2
Anzahl Nennungen
12
10%
0%
mehr als 10 Mio
9.5 - 10.0 Mio
9.0 - 9.5 Mio
8.5 - 9.0 Mio
8.0 - 8.5 Mio
7.5 - 8.0 Mio
7.0 - 7.5 Mio
6.5 - 7.0 Mio
6.0 - 6.5 Mio
5.5 - 6.0 Mio
5.0 - 5.5 Mio
4.5 - 5.0 Mio
4.0 - 4.5 Mio
3.5 - 4.0 Mio
3.0 - 3.5 Mio
2.5 - 3.0 Mio
2.0 - 2.5 Mio
1.5 - 2.0 Mio
1.0 - 1.5 Mio
.5 - 1.0 Mio
0.25 - 0.5 Mio
0
Abb. 5-4: Budgets der einführenden Unternehmen.
Trotz etwas zurückhaltender Antwortbereitschaft der befragten Unternehmen lassen sich
folgende Ergebnisse festhalten: Die durchschnittliche Projektgrösse betrug 4.8 Mio CHF
(Median 2.0 Mio CHF). Die Budgets der meisten Projekte (70%) bewegten sich im Bereich von 0.25 bis 4.5 Mio CHF (vgl. Abb. 5-4). Für KMUs liess sich ein Mittelwert von
2.0 Mio CHF (Median 1.8 Mio CHF) ermitteln. Über vier Fünftel der Einführungsprojekte (81%) wurden in weniger als drei Teilprojekten abgewickelt.
258
Bei Grossunternehmen wurden nur rund die Hälfte der R/3-Einführungen in einem oder
zwei Projekten abgewickelt (vgl. Abb. 5-5). Die durchschnittliche Projektgrösse unterscheidet sich signifikant vom Projektvolumen der KMUs (vgl. H 1.5) und beträgt nach
Entfernung eines Ausreisserwertes 7.5 Mio CHF (Median 4.75 Mio CHF).
Anzahl R/3-Projekte in KMU's
(n=42)
Anzahl R/3-Projekte in
Grossunternehmen
(n=49)
mehr als 5
Projekte
5 Projekte
7%
4 Projekte 5%
mehr als 5
Projekte
18%
2%
3 Projekte
5%
1 Projekt
38%
5 Projekte
2%
4 Projekte
8%
2 Projekte
17%
1 Projekt
64%
3 Projekte
14%
2 Projekte
20%
Abb. 5-5: Anzahl Projekte in den Unternehmungen.
Bei Vergleich der durchschnittlichen Einführungskosten in den verschiedenen Branchen
konnten keine statistisch signifikanten Unterschiede festgestellt werden (vgl. H 1.6).
259
5.4.4.3.2 Projektverantwortung
Oft wird die Auffassung vertreten, in Informatikprojekten sei die Projektverantwortung
an die betroffenen Fachbereiche zu übertragen.252 In besonders wichtigen Projekten
erscheint es sinnvoll, die Verantwortung auf Geschäftsleitungsebene zu belassen. Zudem wird bei der Delegation von Verantwortung auf Projektebene vielfach darauf hingewiesen, dass gleichzeitig eine angemessene Zuweisung von Kompetenzen zu erfolgen
hat, um unnötige Verzögerungen zu vermeiden. Dass diese grundlegenden Erkenntnisse
nicht immer eingehalten werden, zeigen folgende Auswertungen.
Zur Frage, welche Stellen in einem Unternehmen oder einem Konzern die Verantwortung für das Gesamtprojekt und für die Teilprojekte übernehmen, haben sich 94 Unternehmen geäussert (vgl. Abb. 5-6). Dabei liegt die Gesamtverantwortung für R/3Einführungsprojekte in 33% der Fälle bei der Geschäftsleitung. Daneben wird in 39%
der Fälle die Projektverantwortung einem Gremium übertragen, welchem in der Regel
mindestens ein Mitglied der Geschäftsleitung angehört. Nur in 10% der Fälle die Gesamtverantwortung im Informatikbereich und in 13% in den Fachabteilungen.
Verantwortung Gesamtprojekt
(n=94)
Informatik
10%
Andere Ex t. Berater
2%
3%
Fachabteilungen
13%
Informatik
5%
Gremium
39%
GL
33%
Abb. 5-6: Projektverantwortungen.
252
Vgl. z.B. Meister (1990), S. 38.
260
Verantwortung Teilprojekt
(n=92)
Ex t. Berater
2% Andere
GL
1%
3%
Gremium
46%
Fachabteilungen
43%
Bei den Teilprojekten stellt sich die Situation anders dar. Hier lag die Verantwortung in
46% der Fälle bei einem Gremium und in 43% in den zuständigen Fachabteilungen.
Daneben übernahmen in 5% der Fälle die Informatikabteilung und nur in 3% die Geschäftsleitung die Verantwortung für Teilprojekte (vgl. Abb. 5-6).
Ein Problem bei der Delegation der Verantwortung stellt offenbar die gleichzeitige Ausstattung der Verantwortungsträger mit entsprechenden Kompetenzen dar. Aus den von
den Projektleitern genannten Problembereichen geht hervor (vgl. 5.4.4.1), dass vielfach
zu wenig Kompetenzen übertragen werden und dadurch häufig lange auf für den Projektfortschritt notwendige Entscheidungen der entsprechenden Instanzen gewartet werden muss. Durch diesen Mangel an Kompetenzen werden R/3-Projekte unnötig verzögert; gleichzeitig wird die Motivation der Projektverantwortlichen dadurch erheblich
beeinträchtigt.
5.4.4.3.3 Lenkungsausschuss
Zur Steuerung und Überwachung von Einführungsprojekten werden bei nahezu allen
Befragten (93%) entsprechende Koordinationseinrichtungen (Lenkungsausschüsse oder
Steering Committees) eingesetzt.
Auf die Frage nach der Zusammensetzung des Lenkungsausschusses äusserten sich insgesamt 87 Unternehmen (vgl. Abb. 5-7). Die durchschnittliche Grösse beträgt 11 Personen (Median 9). In den meisten Fällen sind Mitglieder aus der Geschäftsleitung in diesem Gremium vertreten.253 Daneben gehören einem Lenkungsausschuss meist Mitarbeiter aus der Informatik, aus den einzelnen Fachabteilungen sowie externe Berater an.
Ferner wurden mehrfach Controller und Organisatoren als Mitglieder dieses Ausschusses genannt.
253
Vgl. auch Meister (1990), S. 37.
261
Vertretung in Koordinationseinrichtung
(n=87)
Geschäftsleitung
Informatik
Fachbereich
Ex t. Berater
Controlling
Andere
Organisation
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Vertretungshäufigkeit
Abb. 5-7: Mitglieder des Lenkungsausschusses.
5.4.4.3.4 Zusammensetzung der Projektteams
Häufig wird gefordert, dass IV-Projekte nur mit Beteiligung der Fachabteilungen durchgeführt werden sollen.254 Durch die Fokussierung auf betriebswirtschaftliche Aspekte gilt
diese Forderung in R/3-Projekten noch verstärkt.
Bei der Beantwortung der Frage nach der Zusammensetzung einer typischen Projektgruppe haben sich diese Erwartungen bestätigt (vgl. Abb. 5-8). 52% der Mitglieder einer
R/3-Projektgruppe stammen aus der Fachabteilung. Externe Berater machen einen Anteil von 23% und Mitglieder der Informatikabteilung von nur 21% aus. In einer kleinen
Restgruppe (4%) wurden mehrfach Vertreter aus der Organisationsabteilung genannt.
254
Vgl. z.B. Balmer/Mirchandani (1996); Gantenbein (1990), S. 77; Grupp (1987), S. 53; Mertens/Knolmayer (1995), S. 82.
262
Typische Zusammensetzung einer Projektgruppe
(n=93)
Andere
4%
Informatik
21%
Fachabteilungen
52%
Ex t. Berater
23%
Abb. 5-8: Typische Projektgruppe.
263
5.4.4.3.5 Projektleiter
Die Eigenschaften des Projektleiters stellen einen wesentlichen Erfolgsfaktor für das Gelingen eines R/3-Projektes dar.255 Es stellt sich die Frage, in welchem Ausmass technische, betriebswirtschaftliche Fähigkeiten oder soziale Kompetenzen für den Projekterfolg gefordert sind. Häufig wird die Auffassung vertreten, dass in R/3-Projekten die
fachlichen Anforderungen wichtiger sind als die informationstechnischen. Daher wird
oft empfohlen, den Projektleiter aus dem Fachbereich zu rekrutieren.256
Die Frage nach der organisatorischen Herkunft des Projektleiters haben 93 Unternehmen beantwortet (vgl. Abb. 5-9). Am häufigsten (26%) stammte der Projektleiter aus der
Informatikabteilung. Beinahe ebenso häufig wurden Mitarbeiter aus den Bereichen aus
Controlling und Finanzen als Projektleiter eingesetzt (25%). Daneben sind auch andere
Fachabteilungen sowie externe Beratungsunternehmen relevante Herkunftsbereiche von
Projektleitern.
Obschon empfohlen wird, dass die Projektleiter in grösseren Projekten (mehr als 7 Projektmitarbeiter) zu 100% von anderen Aufgaben freizustellen sind,257 zeigen die Anworten der Befragten ein deutlich davon abweichendes Bild. Bei einer Spannweite zwischen 20% und 100% beträgt der durchschnittliche Freistellungsgrad für ein R/3Einführungsprojekt bei 81 antwortenden Unternehmen nur 67% (Median 60%).
255
256
257
Vgl. 5.4.4.10 sowie Kölle (1990), S. 48; Meister (1990), S. 38.
Vgl. z.B. Mertens/Knolmayer (1995), S. 81.
Vgl. Hüttenhain (1990), S. 134; Kupper (1988), S. 55.
264
Herkunft des Projektleiters
(n=93)
Geschäftsleitung
8%
Andere
5%
Informatik
26%
Ext. Projektleiter
11%
Übrige Fachabteilungen
25%
Finanzen/Controlling
25%
Abb. 5-9: Herkunft des Projektleiters.
Durch die hohe Komplexität der Einführungsprojekte müssen umfassende Anforderungen an einen mit einer R/3-Einführung betrauten Projektleiter gestellt werden. Dabei
spielen neben fachlichen und informationstechnischen Kenntnissen auch soziale Kompetenzen eine wichtige Rolle.
265
Relevante Eigenschaften des Projektleiters
(n=92)
Gute Kenntnisse der eigenen Organisation
Entscheidungskraft, Durchsetzungsvermögen
Gute allgemeine EDV-Kenntnisse
Gute R/3-Kenntnisse
0%
völlig
unbedeutend
25%
unbedeutend
50%
mittlere
Bedeutung
75%
wichtig
100%
sehr
wichtig
Abb. 5-10: Eigenschaften eines Projektleiters.
Zur Beurteilung der notwendigen Eigenschaften eines R/3-Projektleiters haben sich insgesamt 92 Unternehmen geäussert (vgl. Abb. 5-10). Bei der Betrachtung der Ergebnisse
mag auf den ersten Blick erstaunen, dass die sozialen Kompetenzen und die Kenntnisse
der eigenen Organisation wesentlich höher eingestuft wurden als die Fachkenntnisse
eines Projektleiters. Betrachtet man allerdings die in Kapitel 5.4.4.1 dargestellten Probleme, mit denen ein Projektleiter hauptsächlich konfrontiert ist, und die Gewichtung
der Erfolgsfaktoren eines R/3-Projektes (vgl. Kapitel 5.4.4.10), so erscheint diese Bewertung plausibel.
266
5.4.4.3.6 Unterstützung des Managements
Neben dem Einbezug der Anwender stellt die Unterstützung des Managements einen
der wichtigsten Erfolgsfaktoren für EMS-Projekte dar.258 Fehlende Unterstützung durch
die Geschäftsleitung kann sich fatal auf die Akzeptanz eines neuen Systems auswirken.259 Darüber hinaus wird die Motivation der Projektmitarbeiter durch Fehlen dieser
Unterstützung erheblich beeinträchtigt.
Auf die Frage nach der Beurteilung der Unterstützung des Top Managements haben sich
alle Befragten (n=95) geäussert (vgl. Abb. 5-11). In 25% der Fälle wird diese Unterstützung als "sehr gut" bezeichnet und in rund 50% der Fälle immerhin noch als "gut". Rund
17% der Befragten bezeichnen die Unterstützung als "genügend" und in etwas mehr als
8% der Fälle scheint die Unterstützung "ungenügend" gewesen zu sein.
Unterstützung des Projektleiters durch das Management
(n=95)
ungenügend
8%
sehr gut
25%
genügend
17%
gut
50%
Abb. 5-11: Unterstützung des Projektleiters durch das Management.
258
259
Meister (1990), S. 37.
Vgl. z.B. Kölle (1990), S. 48; NN (1996b), S. 7 ff.
267
Dieses Ergebnis verdeutlicht, dass das Management mehrheitlich erkannt hat, wie wichtig die uneingeschränkte Rückendeckung für ein R/3-Projekt ist. Die Unterstützung kann
entweder durch Beteiligung im Lenkungsausschuss oder durch direkte Einflussnahme
konkretisiert werden. Wichtig ist in diesem Zusammenhang auch, dass für das Voranschreiten des Projekts notwendige Entscheidungen nicht verzögert werden und damit
der Projektrhythmus nicht gebrochen wird. Immerhin scheint bei rund einem Viertel der
Projekte die Unterstützung durch das Management unzureichend zu sein.
5.4.4.4 Projektdauer
In einer 1996 von der SAP AG im World Wide Web (WWW) veröffentlichten Untersuchung260 über die Einführungszeit von R/3-Projekten (vgl. Abb. 5-12) wird dargestellt,
dass 79% der 1995 weltweit abgeschlossenen Projekte ein Jahr oder weniger dauerten.
Diese Aussage basiert auf 1481 untersuchten Projekten.
Einführungszeit der 1995 beendeten R/3-Projekte
(n=1481)
400
350
Anzahl Nennungen
300
250
200
150
100
50
0
1-3
4-6
7-9
79%
10-12
13-15
16-18
>18
M onate
Quelle: SAP AG, Walldorf 1996
Abb. 5-12: Einführungszeiten von R/3-Projekten 1995 weltweit (Anbieterangaben).
260
Vgl. http://www.sap.com/r3/imple.htm.
268
Mit anderen Worten lag die durchschnittliche Dauer der 1995 produktiv gewordenen
R/3-Projekte ungefähr bei einem Jahr. Diese Daten werden durch die Betrachtung der
Schweizer Projekte nicht bestätigt (vgl. Abb. 5-13). Hier lag die durchschnittliche Einführungsdauer mit mehr als 15 Monaten deutlich höher. In der Schweiz lag die Dauer
von 84% der Projekte unter zwei Jahren, d.h. bei einem leicht höher liegenden Projektanteil (84% im Vergleich zu 79%) war eine erheblich höhere Projektdauer (bis zu 24
Monaten) festzustellen.
Dauer von SAP-Projekten
(n=81)
16
14
Anzahl Nennungen
12
10
8
6
4
2
0
1-3
4-6
7-9
10-12
13-15
16-18
19-21
22-24
25-27
28-30
>30
84%
Monate
© Institut für Wirtschaftsinformatik, Bern 1997
Abb. 5-13: Einführungszeit von SAP R/3-Projekten in der Schweiz.
Bei der Unterscheidung zwischen Grossprojekten und Projekten in KMUs entsteht ein
signifikanter Unterschied (vgl. H 1.11). Die durchschnittliche Einführungszeit betrug in
KMUs rund 12 Monate (n=37), in Grossunternehmen hingegen etwas mehr als 19 Monate (n=44).
269
Bei der Untersuchung der Bestimmungsgrössen für die Dauer der Einführung lässt sich
keine eindeutige Abhängigkeit erkennen. Zwar wird die Einführungsdauer bis zu einem
gewissen Grad von der Anzahl der vorgesehenen Anwender beeinflusst. Diese Abhängigkeit ist allerdings nur schwach signifikant (vgl. H 3.4). Hingegen lässt sich erstaunlicherweise zwischen der Zahl der eingeführten Module und der Dauer eines Gesamtprojektes keine Abhängigkeit feststellen (vgl. H 3.3). Dies lässt die Vermutung zu,
dass die Dauer eines Einführungsprojektes vor allem von der vorgesehenen Zeitplanung
bestimmt wird resp. durch die Anzahl der eingesetzten Projektmitarbeiter und deren
Freistellungsgrad beeinflusst werden kann (vgl. H 4.3 und H 4.8).
Abweichungen bezüglich der geplanten Projektdauer konnten bei KMUs in 13 von 37
Projekten festgestellt werden. In Grossunternehmen liess sich nur bei 8 von 44 Projekten ein zeitlicher Verzug feststellen. Die durchschnittliche Abweichung lag in beiden
Fällen bei rund 3 Monaten.
Beim Vergleich dieser Daten stellt sich die Frage, warum Schweizer R/3-Projekte
scheinbar länger dauern. Dies mag verschiedene Gründe haben:
• In der vorliegenden Untersuchung sind auch Projekte vertreten, welche vor 1995
produktiv wurden. Da zu diesem Zeitpunkt erst wenige Erfahrungen zur Einführung
von R/3 vorhanden waren, haben diese Projekte wegen ihres innovativen Charakters
möglicherweise länger gedauert.
• Ein weiterer Grund für die Verzerrung mag darin liegen, dass länger dauernde
Grossprojekte in der 1995 von SAP veröffentlichten Aufstellung untervertreten sind.
Der internationale R/3-Boom hat erst 1994 eingesetzt.261 Länger dauernde Projekte
waren somit nicht bereits im Verlaufe des Jahres 1995 beendet. Da zahlreiche
Schweizer Unternehmen im internationalen Vergleich hinsichtlich des R/3-Einsatzes
eine innovative Rolle übernommen haben, ist davon auszugehen, dass Grossprojekte in der Schweiz weiter fortgeschritten sind. Eine Bestandesaufnahme zum heu-
261
Vgl. SAP AG (1996b), S. 18 f.
270
tigen Zeitpunkt wird die Statistik folglich in Richtung längerer Projektdauer beeinflussen.
• Eine andere mögliche Erklärung für diese Abweichung ist der unterschiedliche Einsatz personeller Ressourcen. Es wäre denkbar, dass im Ausland mehr Personalressourcen für SAP-Projekte zur Verfügung stehen und damit die Einführungsdauer reduziert werden kann. Eines der Hauptprobleme in Schweizer Projekten stellen fehlende personelle Ressourcen (zu geringe Freistellungsgrade, Überlastung durch das
Tagesgeschäft) dar.262
Die Einführungszeiten sollen künftig durch bessere methodische Unterstützung der Einführung (Business Engineer, ASAP263), durch Vereinfachung des Anpassungsaufwandes
(vorkonfigurierte Geschäftsprozesse; Templates) und durch verbesserte Schulungsmethoden (IDES) reduziert werden.264
262
263
264
Vgl. dazu Kapitel 5.4.4.1.
ASAP = Accelerated SAP.
Vgl. z.B. Stein (1997).
271
5.4.4.5 Personaleinsatz während eines Projekts
Die Produktivität der Projektteams kann durch die seriöse Vorarbeit in den entscheidenden Phasen erheblich gesteigert werden. Fehlen die konzeptionellen Voraussetzungen, so ist bei der Realisierung des Projektes mit einem erheblichen Nachbesserungsaufwand zu rechnen (vgl. Abb. 5-14).
Aufwand
Ist
Soll
Zeit
Organisation
und Konzeption
Detaillierung
und Realisierung
Produktivbetrieb
Abb. 5-14: Vergleich des Projektaufwands im Zeitablauf.265
Bei der Betrachtung der Entwicklung des Projektaufwands entspricht die effektive Aufwandsverteilung in der Regel nicht genau den Sollvorstellungen (vgl. Abb. 5-14). In den
konzeptionellen Phasen (vor allem Organisation und Konzeption) werden tendenziell zu
wenig personelle Ressourcen eingesetzt. Daher ist nach der Detaillierungs- und Realisierungsphase keine wesentliche Abnahme des Personalbedarfs zu beobachten. Die
fehlenden konzeptionellen Rahmenbedingungen wirken sich bei der Umsetzung des
Projektes negativ aus und führen zu einem erheblichen Mehraufwand. Bei der statistischen Analyse dieses Zusammenhangs ist zwar eine Auswirkung der Intensität der Planung auf die Projektkosten und -dauer messbar (vgl. H 4.11 und 4.12), aber für einen
265
Vgl. Kupper (1988), S. 37; Thome/Hufgard (1996), S. 19.
272
statistisch signifikanten Wirkungszusammenhang sind die vorhandenen Angaben zu unpräzis.
Mitarbeiterzahl im Projekt
(n=61)
12
Anzahl Mitarbeiter
10
8
6
4
2
0
Organisation und
Konzeption
Detaillierung und
Realisierung
Produktionsv orbereitung
Produktionsanlauf
Einführungsphase
gesamt (100%-Stellen)
Vollzeit
Teilzeit
Abb. 5-15: Personaleinsatz während der Durchführung von R/3-Projekten.
Die Auswertung der Mitarbeiterzahlen in den Projekten ergab für die KMUs im Durchschnitt über alle Phasen 8.1 und für die Grossunternehmen 13.8 Mitarbeiter pro Projekt. Diese Werte spiegeln allerdings die effektiven Personalressourcen der Projekte
nicht wider, da noch keine Unterscheidung zwischen Vollzeit- (100%-ige Freistellung)
und Teilzeit-Beschäftigten vorgenommen wurde. Nach einer solchen Differenzierung
finden sich für KMUs im Durchschnitt 1.4 Mitarbeiter und für Grossunternehmen 2.3
Mitarbeiter, welche vollamtlich mit der Projektarbeit betraut waren, sowie 4.6 (KMUs)
und 7.8 Mitarbeiter (Grossunternehmen), welche nur teilzeitlich für das Projekt arbeiteten. Abb. 5-15 zeigt detaillierte Angaben der eingesetzten Personalressourcen über
sämtliche Projektphasen und über alle Projekte. Bei der Betrachtung der Freistellungsgrade der Projektleiter ist noch einmal darauf hinzuweisen, dass diese in etlichen Pro-
273
jekten nicht vollständig freigestellt waren (durchschnittlicher Freistellungsgrad 67%).266
Erwartungsgemäss finden sich hingegen für den durchschnittlichen Freistellungsgrad der
Teilzeitbeschäftigten Werte von knapp unter der empfohlenen 50%-Grenze267 (48% für
KMUs und 40% für Grossunternehmen).
5.4.4.6 Beratereinsatz
Der Beizug von externen Beratern in ein R/3-Projekt ist in der Regel unumgänglich. Die
Gründe für die Zusammenarbeit mit externen Beratern liegen vor allem beim fehlenden
internen R/3-Know-how und bei den nicht ausreichend verfügbaren internen Personalressourcen. Daneben spielen auch der Wunsch einer neutralen Betrachtungsweise sowie die betriebswirtschaftlichen und methodischen Kenntnisse der Berater eine wichtige
Rolle für die Zusammenarbeit. Bei allen antwortenden Unternehmen wurde während
des Projektverlaufs mindestens ein Berater eingesetzt.
Beratungspartner in R/3-Projekten
(n=144)
Andere
18%
SAP
25%
Plaut
2%
Muth Partners
2%
IPM
2%
Price Waterhouse
2%
CSC PLOENZKE
2%
Sohard
3%
DEC
3%
IMG
3%
KPMG Fides
3%
ATAG debis
4%
Andersen Consulting
6%
Consoft
11%
Datamind
7%
Abb. 5-16: Beratungspartner in R/3-Projekten.
266
267
Vgl. dazu Kap. 5.4.4.3.5.
Vgl. Balmer/Mirchandiani (1996); Grupp (1987), S. 52.
274
STG-Coopers & Lybrand
7%
Viele Beratungsunternehmen haben sich auf Dienstleistungen rund um R/3-Einführungen spezialisiert. Bei Betrachtung der herangezogenen Beratungsunternehmen wird
das Vertriebskonzept der SAP ersichtlich. Drei Viertel aller Projekte wurden von LogoPartnern oder von unabhängigen Beratungsunternehmen begleitet und nur ein Viertel
(25%) wird von SAP selbst betreut. Etwas mehr als 50% der R/3-Beratungsdienstleistungen wurde von Logo-Partnern oder Systemhäusern (vgl. Abb. 5-13) erbracht. Rund ein Fünftel teilten sich viele meist kleinere Beratungsunternehmen, welche
sich entweder auf bestimmte Gebiete (z.B. EDI, Electronic Commerce, Archivierung)
spezialisiert haben oder deren R/3-Aktivitäten sich erst im Aufbau befanden.
Für die Wahl der Berater waren neben den R/3-Kenntnissen auch deren Branchenkenntnisse und soziale Kompetenzen massgebend. Oft wurden Beraterpersönlichkeiten
unabhängig von einem präferierten Beratungsunternehmen gewählt. Diesem Auswahlkriterium steht die Grösse von Beratungsunternehmen gegenüber, welche Gewähr bietet, dass im Bedarfsfall auf ein ausreichendes Know-how-Potential zurückgegriffen werden kann.
Mit der Qualität der Beratungsdienstleistungen waren die meisten R/3-Anwender zufrieden. Jedoch wurden die systemorientierten R/3-Kenntnisse besser beurteilt als die
methodischen Kenntnisse. In rund einem Zehntel der Fälle waren die Kunden mit den
Beratungsdienstleistungen nicht zufrieden. Dies wird auch deutlich bei der Betrachtung
der Probleme der Projektleiter (vgl. Kap. 5.4.4.1). In diesem Zusammenhang wurden
die unzureichenden Kenntnisse einzelner Berater mehrfach erwähnt. Ein signifikanter
Einfluss der Beraterqualität auf die Kosten und die Dauer einer Einführung (vgl. H4.1
und 4.2) konnte nicht nachgewiesen werden.
275
5.4.4.7 Projektkosten
Ein repräsentatives R/3-Projekt mit den Modulen FI, CO, MM, AM, HR und SD für 100
Named User verursachte bei KMUs nach der Entfernung von Ausreisserwerten Kosten
von durchschnittlich 2,28 Mio CHF. In Grossunternehmen betrugen die vergleichbaren
Kosten für Projekte rund 2,34 Mio CHF. Damit lässt sich auf der Kostenseite kein signifikanter Unterschied zwischen KMUs und Grossunternehmen feststellen (vgl. H 1.7).
Die Höhe der Projektkosten wird stark von der Anzahl der vorgesehenen Anwender
(H 3.2) und nur geringfügig von der Zahl eingeführten Module (vgl. H 3.1) beeinflusst.
Dabei ergibt sich pro Named User ein Wert von rund CHF 20'500.- bei einer Standardabweichung von CHF 1'074.-. Bei der Untersuchung der branchenspezifischen Werte
ergeben sich nur geringfügige Unterschiede. Beispielsweise fallen in der Industrie durchschnittlich für einen Named User Kosten von CHF 19'500.- an (Standardabweichung
CHF 1'121.-).
Budgetverteilung (Mittelwert)
(n=56)
Schulungskosten
9%
Einführungskosten
44%
Hardw arekosten
25%
Softw arekosten
22%
Abb. 5-17: Kostenaufteilung bei der Einführung von R/3.
276
Die Betrachtung der Verteilung der Gesamtkosten268 in den Kategorien Hardware-,
Software-, Einführungs- und Schulungskosten ergibt folgendes Bild: Je rund ein Viertel
der Gesamtkosten wurde für den Kauf von Hardware und Softwarelizenzen benötigt,
etwas mehr als die Hälfte für die Einführung und Schulung (vgl. Abb. 5-17). Von den
gesamten Einführungskosten wurde rund ein Fünftel für die Schulung eingesetzt. Die
Kostenverteilung bei Grossunternehmen und bei KMUs ist identisch (vgl. H 1.8).
Grob gesehen ergibt sich daraus ein Verhältnis von 1:1:2 (Hardware, Software, Einführung). Allerdings wird vermutet, dass bei den Einführungskosten oft nur die direkten
Kosten angegeben wurden. Die indirekten Kosten, z.B. verursacht durch Arbeitsausfallzeiten der Endanwender, wurden wohl nur selten in die Kostenaufstellungen miteinbezogen. Da die einführungsbedingten Kosten unter Berücksichtigung auch aller indirekten Kosten möglicherweise erheblich höher angesetzt werden müssten, entspräche ein
Kostenverhältnis von 1:1:5 wahrscheinlich eher den realen Gegebenheiten.269
5.4.4.8 Einhaltung der Projektziele
Die Einführung von IS hat sich in der Vergangenheit oftmals nur auf einzelne Unternehmensbereiche beschränkt. Dabei hielten sich auch die Anpassungen und Veränderungen in der betrieblichen Aufbau- und Ablauforganisation in Grenzen, weil in vielen
Fällen massgeschneiderte Individualsoftware eingesetzt wurde. Mit dem Verfügbarwerden von EMS hat sich diese Situation verändert. EMS decken mit standardisierten Prozessen die meisten betriebswirtschaftlichen Vorgänge in den Unternehmen ab. Meist
wird jedoch eine Anpassung bestehender Abläufe im Unternehmen an die in den EMS
vorgegebenen Standardprozesse unumgänglich. Die Dynamik, welche ein derartiger
Eingriff in einem Unternehmen auslöst, ist vielfach schwer vorauszusehen. Darüber hinaus besteht zu Beginn eines Projektes wegen der Komplexität der am Markt angebotenen EMS selten ein klares Bild über die Einsatzmöglichkeiten eines neuen Systems.
Über- oder Unterschätzung der Möglichkeiten von EMS-Systemen sind keine Seltenheit.
268
269
Vgl. dazu auch AFOS (1996), S. 36.
Vgl. dazu Stein (1997).
277
Die Formulierung von realistischen und bis zum Projektende verbindlichen Zielsetzungen wird dadurch erheblich erschwert.270
Hingegen bleiben die Ziele aufgrund der verhältnismässig kurzen Einführungszeiten
weitgehend unverändert. Umfeldbedingte Anpassungen während des Projektes sind
zwar durch die grosse Dynamik innerhalb und zwischen den Unternehmen (z.B. Fusionen) insbesondere unter den heutigen Rahmenbedingungen nicht ausgeschlossen, stellen aber doch eher die Ausnahme dar.
Auf die Frage nach der Zielerreichung liess sich feststellen, dass in den meisten Projekten die gesetzten Ziele eingehalten werden konnten (vgl. Abb. 5-18). Dabei fällt auf,
dass Termin- und Sachziele besser eingehalten wurden als Kostenziele. Letztere konnten
in 30% der Fälle nicht eingehalten werden. Die gesetzten Sachziele wurden in einigen
Fällen (8%) sogar übertroffen.
Terminziele
Sachziele
Kostenziele
(n=80)
(n=78)
(n=73)
nicht
eingehalten
22%
nicht
eingehalten
23%
übertroffen
1%
nicht
eingehalten
30%
übertroffen
8%
eingehalten
76%
eingehalten
70%
übertroffen
5%
eingehalten
65%
Abb. 5-18: Zieleinhaltung in R/3-Projekten.
Die Zielüberwachung erfolgte in den meisten Fällen durch den Lenkungsausschuss anhand eines einfachen Soll/Ist-Vergleichs. Die einzelnen Reviews während des Projekts
fanden entweder periodisch (wöchentlich oder monatlich) oder bei Erreichen festgelegter Meilensteine statt.
73 R/3-Anwender (77%) stellten während ihres Projektes Zielabweichungen fest. Von
diesen 73 Anwendern haben 27% ihre Zielsetzungen in der Folge nicht angepasst (vgl.
270
Vgl. Litke (1995), S. 31.
278
Abb. 5-19). Viele Anwender versuchten, die gesetzten Ziele durch Mehrleistungen der
Projektmitarbeiter oder durch Reduktion der Anforderungen zu erreichen.
Reaktion auf Zielabweichungen
(n=73)
Keine Anpassung der
Ziele, sondern...
27%
Neuformulierung der Ziele
21%
Geringe Anpassung der
Ziele
52%
Abb. 5-19: Reaktion auf Zielabweichungen.
Von den Befragten, welche Zielabweichungen feststellten, haben 52% ihre Zielsetzungen geringfügig angepasst und 21% vollständig neu formuliert.
Bei Betrachtung dieser Zahlen wird deutlich, dass es nicht einfach ist, realistische und
bis zum Projektende verbindliche Zielsetzungen von Beginn an zu formulieren. Vielmehr muss am Anfang eines Projektes versucht werden, einen Rahmen vorzugeben,
welcher zwar einen gewissen Spielraum zulässt, während des Projektes aber nicht verlassen werden sollte. Die Detailziele können erst nach den einleitenden Phasen verbindlich festgelegt werden. Sie müssen rollierend überprüft und nötigenfalls angepasst
werden. Damit während eines Projektes Phasen der Orientierungslosigkeit verhindert
werden können, lohnt sich die Formulierung von Zwischenzielen. Diese sollen sich
grundsätzlich an den Endzielen orientieren, können aber von Phase zu Phase neu festgelegt werden. Die Motivation der Projektmitarbeiter bleibt durch die klare Zielorientierung und durch die greifbare Nähe der Ziele erhalten.
279
5.4.4.9 Methoden und Werkzeuge
Die Wichtigkeit der methodischen Unterstützung einer R/3-Einführung wird immer wieder unterstrichen.271 Ein Vorgehensmodell stellt den Rahmen für die Einführung dar und
legt fest, welche Aktivitäten in welcher Reihenfolge ausgeführt werden müssen. Innerhalb dieses Rahmens werden durch den Einsatz spezifischer Methoden (z.B. ereignisgesteuerte Prozessketten - EPK) bestimmte Bereiche eines Einführungsprojektes systematisiert. Eine sinnvolle Anwendung solcher Methoden kann nur mit entsprechender ToolUnterstützung (vgl. Tab. 5-6) erreicht werden.
Produkt
Hersteller
WWW-Adresse
ARIS-Toolset
IDS Prof. Scheer GmbH
http://www.ids-scheer.de/
LiveModel
IntelliCorp
http://www.intellicorp.com/
Visio Business Modeler
Visio Corporation
http://www.visio.com/
Tab. 5-6: Prozessmodellierungswerkzeuge zur Unterstützung der R/3-Einführung.
Die zu diesem Sachgebiet gestellten Fragen verdeutlichten, dass sich diese Sichtweise in
der Praxis keineswegs überall durchgesetzt hat. 30% der Befragten gaben an, bei der
R/3-Einführung kein Vorgehensmodell verwendet zu haben. In den anderen Fällen
wurde die Einführung mehrheitlich auf Basis des im R/3-System integrierten Customizing-Vorgehensmodells durchgeführt. Je 9% der Anwender setzten entweder eigene
Vorgehensmodelle ein oder griffen auf jene der unterstützenden Beratungsunternehmen
zurück (vgl. Abb. 5-20). Bei der Betrachtung der Verhaltensunterschiede zwischen
Grossunternehmen und KMUs liessen sich keine signifikanten Unterschiede bezüglich
der Verwendung von Vorgehensmodell und des Einsatzes von Softwareunterstützungswerkzeugen feststellen (vgl. H 1.12).
271
Vgl. z.B. Hufgard (1995), S. 43 ff.
280
Ein Vergleich zu den Ergebnissen von 1994 zeigt eine deutliche Veränderung. Während
1994 64% der Befragten bei der R/3-Einführung kein Vorgehensmodell verwendet haben272, waren es 1996 nur noch 30%.
Verwendete Vorgehensmodelle
(n=87)
Andere Vorgehensmodelle
v erw endet
(z.B. firmenspezifische)
9%
Beraterspezifische
Vorgehensmodelle
v erw endet
9%
SAP-Vorgehensmodell
v erw endet
52%
Kein Vorgehensmodell
v erw endet
30%
Abb. 5-20: Verwendete Vorgehensmodelle.
Die Frage nach dem Einsatz von Tools zur Unterstützung einer R/3-Einführung haben
46% mit "Ja" beantwortet. Dies mag insbesondere vor dem Hintergrund der beinahe
allgegenwärtigen ISO-9000-Zertifizierungsprojekte erstaunen. Zur Erreichung der Zertifizierung müssen u.a. die Prozesse in geeigneter Weise dokumentiert und laufend an die
stattfindenden Veränderungen angepasst werden. Dabei drängt sich die Verwendung
von Prozessbeschreibungswerkzeugen geradezu auf.
Unter den verwendeten Werkzeugen (vgl. Abb. 5-21) dominieren ProjektmanagementTools (MS-Project) und Prozessbeschreibungswerkzeuge (ARIS-Toolset, ABC-Flowcharter und Visio). Daneben werden insbesondere das MS-Office-Paket zur Dokumentation
und einige andere Tools (z.B. System-Architekt oder Rochade) zur Unterstützung des
Einführungsprozesses eingesetzt.
272
281
Auch bei dieser Frage zeigte sich, dass im Unterschied zu dem 1994 ermittelten Wert
(25%)273 im Sommer 1996 bei R/3-Einführungsprojekten wesentlich häufiger (46%)
Softwareunterstützungswerkzeuge eingesetzt wurden.
Eingesetzte Tools
n=80,
inkl. Mehrfachnennungen)
(
MS-Project
MS-Office
ARIS
ABC-Flowcharter
Visio
Andere
0
5
10
15
Anzahl Nennungen
Abb. 5-21: Verwendete Tools.
273
Knolmayer/Portner/von Arb (1995), S. 48.
282
20
25
30
5.4.4.10 Kritische Erfolgsfaktoren
Im Rahmen der vorliegenden empirischen Untersuchung wurden die 1995 ermittelten
Resultate überprüft. Abb. 5-22 zeigt die Gewichtung der einzelnen Faktoren aus der
aktuellen Untersuchung.
Kritische Erfolgsfaktoren
(n=79)
Ausw ahl v on Beratungspartnern
Projektleiter
Kommunikation
Schulung der Benutzer
Projektorganisation
Überdenken bzw. Neugestaltung der Geschäftsprozesse
Know -how -Transfer
Datenmigration
Verbindung zu ex istierenden Informationssystemen
Dokumentation
Lenkungsausschuss
Change-Management
Umfassende Planung des Betriebes
Releaseplanung
Aufw and für Vertragsgestaltung
0%
v öllig
unbedeutend
u
w
25%
unbedeutend
50%
mittlere
Bedeutung
75%
w ichtig
100%
sehr
w ichtig
s
Abb. 5-22: Kritische Erfolgsfaktoren bei der Einführung von SAP R/3.
Es zeigte sich, dass sich an der Grundhaltung wenig geändert hat. In der aktuellen Erhebung wurde den gleichen Faktoren der Vorzug gegeben wie in der 1995 durchgeführten
Befragung. Eine Ausnahme stellt die "Auswahl von Beratungspartnern" dar. Während
diesem Faktor in unserer Expertenbefragung ein relativ geringes Gewicht zugemessen
283
wurde, erscheint dieser nun an erster Stelle. Eine Ursache für die Änderung in der Einschätzung könnte in der stark gestiegenen Nachfrage nach Beratungsdienstleistungen
liegen. Durch die ständige Rekrutierung neuer Berater in grossen Beratungsunternehmen und durch das vermehrte Auftreten von "Freelancern" auf dem Markt scheint ein
erhebliche Unterschiede in der Qualität der Dienstleistungen entstanden zu sein. Darüber hinaus mögen strukturelle Probleme in kleineren Beratungsunternehmen zu einer
zusätzlichen Verunsicherung und zu einer stärkeren Gewichtung der "Auswahl von Beratungspartnern" beigetragen haben.
Die übrigen Faktoren decken sich mit dem bereits bekannten Bild. Der Wahl des Projektleiters kommt durch dessen zentrale Rolle innerhalb des Projektes eine massgebende Bedeutung zu (vgl. Kap. 5.4.4.3.5).
Die Kommunikation während eines Projektes wurde ebenfalls in den Vordergrund gestellt. Sie kann sich auf verschiedene Ebenen beziehen. Eine zentrale Rolle scheint in
diesem Zusammenhang die Kommunikation mit den Endanwendern zu spielen (vgl.
Kap. 5.4.4.1).
Klar formulierte Zielsetzungen werden im Zusammenhang mit EDV-Projekten immer
wieder als wichtig erachtet.274 Die Formulierung von messbaren und ehrgeizigen, aber
erreichbaren Zielen und deren Überwachung (Projektcontrolling) ist eine schwierige
und anspruchsvolle Aufgabe (vgl. Kap. 5.4.4.8).
Durch entsprechende Schulung werden die Anwender in die Lage versetzt, das eingeführte System in der vorgesehenen Art und Weise zu nutzen. Ein schlechter Ausbildungsstand der Anwender führt zu Akzeptanzproblemen und zu Fehleingaben, welche
die Qualität der vom System zur Verfügung gestellten Informationen massgeblich beeinträchtigen (vgl. Kap. 5.4.7.2).
274
Vgl. z.B. Meister (1990), S. 37.
284
Die restlichen projektmanagementbezogenen Faktoren (z.B. Projektorganisation, Einbeziehung des Managements, methodisches Vorgehen, BPR und Know-how-Transfer)
dürfen ebenfalls nicht vernachlässigt werden.
Es sei darauf hingewiesen, dass die dargestellte Gewichtung der Erfolgsfaktoren nicht
"allgemeingültig" ist. Analog der Unterschiedlichkeit der Erfolgsfaktoren verschiedener
Branchen275 ist auch bei der Einführung von R/3 davon auszugehen, dass diese Erfolgsgrössen situativ ermittelt werden müssen. Die dargestellte Gewichtung ist als Rahmen
für die Ermittlung unternehmensspezifischer Erfolgsfaktoren aufzufassen.
Wie bereits dargelegt, scheinen technische Faktoren eine eher untergeordnete Rolle zu
spielen. Bemerkenswert ist auch die Tatsache, dass sowohl in der Expertenbefragung
(vgl. Kap. 4.5) als auch in der hier dargestellten empirischen Untersuchung den Faktoren "Aufwand für Vertragsgestaltung" und "Intensität der Evaluation" nur wenig Gewicht
beigemessen wurde.
5.4.5 Systemtechnisches Umfeld
5.4.5.1 Bisherige Systemarchitektur
Vor der Einführung des R/3-Systems befanden sich die betriebswirtschaftlichen Anwendungen bei einer Mehrheit der Befragten (79%) auf einer Host-Plattform (vgl. Abb. 523).
Bei rund 14% der untersuchten Unternehmen fand eine Horizontalverschiebung der
Anwendungsplattform statt. Diese Gruppe von Unternehmen setzten vor dem Übergang
auf R/3 vorwiegend AS/400-Systeme ein. Da das R/3-System die AS/400-Plattform erst
seit kurzem unterstützt, sahen sich viele Unternehmen gezwungen, auf Unix oder Windows NT zu wechseln.
Ein Upsizing stellt eher die Ausnahme dar. Nur bei 7% der Unternehmungen befand
sich die betriebswirtschaftliche Anwendungsplattform vor der R/3-Einführung auf PCServer-Ebene.
275
Vgl. Rockart (1979), S. 87 f.
285
Plattform für betriebswirtschaftliche Anwendungen
vor der R/3-Einführung
(n=91)
Abteilungsrechner
(z.B. AS/400)
14%
PC-Serv er
(z.B. Nov ell)
7%
Host-Umgebung
79%
Abb. 5-23: Ursprüngliche Hardwarekonfiguration.
5.4.5.2 Bisherige Softwarearchitektur
Dem Alter des abzulösenden IS kommt als Auslöser für die Einführung eines neuen EMS
eine zentrale Rolle zu. Je älter ein bestehendes Anwendungssystem ist, desto schwieriger wird es, Fachkräfte für seine Wartung zu finden. Unzureichende Dokumentation
und der Einsatz unprofessioneller Systementwicklungstechniken verstärken dieses Problem. Auch bei regelmässiger Wartung von Individualsoftware entwickelt sich das vorhandene System zusehends zu einem "Flickwerk", dessen Unterhalt ab einem gewissen
Zeitpunkt praktisch unmöglich wird.
Ferner werden die Unternehmungen durch die rasante Weiterentwicklung im Hardware-Umfeld zum Release-Wechsel ihrer Betriebssysteme gezwungen. Vielfach ist damit auch eine Portierung der vorhandenen Applikationen verbunden, welche sich aus
den oben genannten Gründen nur noch schwer realisieren lässt.
Ein anderer Grund für den Ersatz vorhandener Systeme stellt das "Jahr 2000-Problem"
dar. Dieses beruht auf der Speicherung von zweistelligen Jahresangaben, welche ohne
entsprechende Modifikationen spätestens im Jahr 2000 Fehlerquellen darstellen wer-
286
den.276 Die meisten aktuell angebotenen EMS haben das "Jahr 2000-Problem" angeblich
gelöst. Die SAP AG hat das System R/2 bereits um 1990 auf vierstellige Jahresdarstellungen umgestellt und das R/3-System wurde von Beginn an so entworfen.277 Andere EMSAnbieter haben das Problem vorläufig durch Einsatz von Fenster-Techniken gelöst.278
Weitere Faktoren, welche für die Einführung einer neuen Software ausschlaggebend
sein können, wurden in Kapitel 5.4.3.1 beschrieben.
Abb. 5-24 zeigt, welche Kategorien von Software in den befragten Unternehmen durch
den Einsatz von R/3 abgelöst worden sind. In mehr als der Hälfte der Fälle betraf dies
Individualsoftware. Ein Drittel der ersetzten Systeme waren Standardsoftwarepakete.
Rund 10% der befragten R/3-Anwender ersetzten mit dem R/3-System das hostbasierte
R/2-System. Nur eine kleine Anzahl von Anwendern setzt R/3 ergänzend zu R/2 ein
(2%).
Ersetzte Softwarekategorien
Ersatz für SAP R/2
12%
Ergänzung zu SAP R/2
2%
Ersatz für eigenerstellte
Indiv idualsoftw are
39%
Ersatz für andere
Standardsoftw arepakete
32%
Ersatz für durch
Softw arehäuser erstellte
Indiv idualsoftw are
15%
Abb. 5-24: Durch R/3 ersetzte Softwarekategorien.
276
277
278
Vgl. Knolmayer (1997).
Walter (1997).
So z.B. JDEdwards; vgl. McKendrick (1995).
287
Die vermuteten Einflüsse der bisherigen Informatiksituation auf die Kosten und Dauer
von R/3-Projekten konnten nicht bestätigt werden. Es gab keine signifikanten Unterschiede zwischen Unternehmungen mit und ohne SSW-Einsatz einerseits noch zwischen Unternehmungen mit und ohne R/2-Erfahrung andererseits (vgl. H 2.1 und
H 2.2).
5.4.5.3 Eingesetzte Systemkomponenten
In Kapitel 3.4 wurden die verschiedenen Gestaltungsvarianten der Systemarchitektur
von R/3 beschrieben. Obwohl drei- und mehrstufige Client/Server-Systeme eine deutlich höhere Flexibilität bei der Lastverteilung bieten279, ist deren Verbreitung in der
Schweiz relativ gering. Weitaus am häufigsten ist die Zwei-Ebenen-Architektur vorzufinden (80%). Dabei werden PCs als Präsentationsrechner eingesetzt und die Applikationsund Datenbankebene ist auf einem Server zusammengefasst. Nur gerade ein Fünftel
(20%) der befragten R/3-Anwender verteilt die Daten- und die Applikationslogik auf verschiedene Server (dreistufige Architektur). Häufig ist neben einem produktiven R/3-System ein Test-System im Einsatz.
Durch die Offenheit von R/3 (vgl. Kapitel 3.4) können die verschiedensten Systemkomponenten für den Betrieb verwendet werden. Abb. 5-25 zeigt, welche Komponenten in
den befragten Unternehmen hauptsächlich eingesetzt wurden. Im Bereich der Datenbanken setzten 84% Oracle und 12% Informix ein. Die übrigen Datenbanksysteme besitzen in der Schweiz als R/3-Basis nur geringe Verbreitung.
Im Bereich der Betriebssysteme ist noch immer eine starke Dominanz von Unix festzustellen. Experten gehen jedoch davon aus, dass Windows NT spätestens 1998 als Basissystem für R/3 mit Unix gleichziehen wird.280 Gegenüber der Untersuchung aus dem
Jahre 1994281 ist der Anteil von Unix bzw. Unix-Derivaten bei den Betriebssystemen
unverändert geblieben und hat sich auf dem hohen Niveau stabilisiert (86%). Dagegen
279
280
281
Vgl. Buck-Emden/Galimov (1996), S. 29.
Vgl. Igler (1996), S. 14 f.; Igler (1997), S. 19 ff.
288
konnte Windows NT seinen Anteil an den Betriebsystemen seit 1994 von 7% auf 14%
auf Kosten von Open VMS verdoppeln.
Etwas differenzierter erweist sich die Situation bei den graphischen Benutzeroberflächen
(GUI). Während Windows NT in der Untersuchung von 1994 noch nicht vertreten war,
findet sich diese Oberfläche nun mit 12% Anteil bereits auf dem zweiten Platz wieder.
An erster Stelle befindet sich weiterhin Windows 95 (resp. Windows 3.1) mit 77%. Der
Anteil von OS/2 ist in etwa gleich geblieben (6%). Hingegen hat der Verbreitungsgrad
der Benutzeroberflächen von Macintosh (minus 5%) und OSF-Motif (minus 4%) beträchtlich abgenommen.
Eingesetzte Datenbank
(n=95)
ADABAS
D
MS SQL
1% DB/2
Server
1%
2%
Informix
12%
Graphische
Benutzeroberfläche
(n=90)
Eingesetztes
Betriebssystem
(n=91)
Macintosh
OSF-Motif 1%
OS/2
4%
6%
Windows
NT
14%
Windows
NT
12%
Oracle
84%
Unix
86%
Windows
95 (3.1)
77%
Abb. 5-25: Eingesetzte Systemkomponenten.
Bei der Analyse der Anteile der eingesetzten Unix-Betriebssysteme ergab sich ungefähr
ein ähnliches Bild wie 1994.282 Für IBM und DEC liessen sich Anteile von je einem
Drittel ermitteln. Beinahe die gleiche Bedeutung ist HP mit 28% einzuräumen, während
Sun OS und Solaris mit 6% deutlich zurücklagen (vgl. Abb. 5-26). Bei diesen Ergebnissen gilt es allerdings zu beachten, dass die Werte aufgrund des kleinen n die wirklichen
Marktanteile nicht exakt widerspiegeln. Ferner wurde die Grösse der Installationen bei
der Messung der relativen Anteile nicht mitberücksichtigt.
282
289
Eingesetztes Unix-Betriebssystem
(n=50)
Sun OS / Solaris
6%
IBM AIX
34%
HP UX
28%
DEC (OSF/2, Ultrix )
32%
Abb. 5-26: Anteile der Unix-Betriebssysteme
5.4.5.4 Systemgrösse
Die Systemgrösse der befragten Unternehmungen wurde anhand der Anzahl Named
User ermittelt. Bei KMUs betrug die durchschnittliche Systemgrösse 49 und bei Grossunternehmen 104 Named User.
Obschon im Sommer 1996 rund 65% der Projekte abgeschlossen waren, zeigte sich,
dass die Endausbaustufe erst in den wenigsten Fällen erreicht war. Bis zu diesem Zeitpunkt hatten bei KMUs rund 60% und bei Grossunternehmen aber erst rund ein Fünftel
der für die Endausbaustufe vorgesehenen Anzahl Benutzer Zugang zum System (vgl.
Abb. 5-27). Die vorgesehene Anzahl Named User im Endausbau unterscheidet sich signifikant und beträgt bei KMUs durchschnittlich 84 und bei Grossunternehmen 477
(vgl. H 1.2).
290
Durchschnittliche Anzahl Named User
Systemgrösse aktuell und in Zukunft
(n=83)
500
450
400
350
300
250
200
150
100
50
0
KMU's
Grossunternehmen
Aktuell
Endausbau
Abb. 5-27: Entwicklung der Systemgrösse.
Zur groben Bestimmung der Systemgrösse (Anzahl Named User) wurde untersucht, inwiefern eine Abhängigkeit zwischen der Mitarbeiter- und der R/3-Anwenderzahl eines
Unternehmens besteht (vgl. H 1.1). Dabei liess sich insbesondere in der Industrie eine
starke Abhängigkeit zwischen diesen Grössen ermitteln. Demnach benutzen bei einer
repräsentativen Installation (6 Module) rund ein Drittel der Mitarbeiter das R/3-System.
In den übrigen Branchen liess sich in diesem Zusammenhang keine signifikante Abhängigkeit feststellen.
5.4.5.5 Integration von Desktop-Applikationen
Die Systemarchitektur von R/3 erlaubt die Anbindung verschiedenster Fremdsysteme.
Schweizer R/3-Anwender nutzen diese Möglichkeiten in beachtlichem Umfang (vgl.
Abb. 5-28). Die weit verbreiteten MS Office-Applikationen wurden bei 60% der befragten Unternehmen an das R/3-System angebunden. Rund 18% der befragten Unternehmen verwenden ein Archivierungssystem als Ergänzung zum R/3-System und 7%
nutzen die Möglichkeit zur Integration von CAD-Anwendungen. Die letztgenannte Zahl
ist dahingehend zu relativieren, dass nur 44% der antwortenden Unternehmen dem
Industriesektor angehören. 20% der Befragten gaben an, Schnittstellen zu anderen als
291
den genannten Produkten eingerichtet zu haben. Darunter fallen u.a. Eigenentwicklungen (4), EDI (2), Barcode-Erfassungssysteme (2) und Wertschriftenpakete (1).
Integration von Fremdprodukten
(n=83)
70%
Relative Häufigkeit
60%
50%
40%
30%
20%
10%
0%
Office-Applikationen
(z.B. MS-Office)
Archiv ierungssy s teme
CAD-Anw endungen
Andere
Art der Applikation
Abb. 5-28: Integration von Fremdprodukten.
5.4.5.6 Outsourcing
Unter Outsourcing ist die mittel- und langfristige Übertragung einzelner oder aller bisher
innerbetrieblich erfüllten IV-Aufgaben an ein rechtlich unabhängiges Dienstleistungsunternehmen zu verstehen.283 Grundsätzlich ist zwischen einer sachlichen und einer zeitlichen Dimension zu unterscheiden. Die sachliche Sicht unterscheidet partielles von totalem Outsourcing von IV-Aufgaben sowie ein "Process Outsourcing", bei welchem sowohl das Basisgeschäft als auch die zugehörige IV-Abwicklung ausgelagert werden
("Business Solution"). Zeitlich kann eine IV-Aufgabe auf Dauer oder bloss vorübergehend ausgelagert werden.
Auch für die Einführung und den Betrieb des R/3-Systems kann sich eine betriebliche
Ausgliederung lohnen. Grundsätzlich ist im R/3-Umfeld eine Trennung zwischen betriebswirtschaftlicher Ebene (FI, CO, AM, MM, PP, etc.) und technischer Ebene (BC,
Betriebssystem, Datenbank, etc.) sinnvoll. Insbesondere in KMUs kann sich eine Ausla-
283
Mertens/Knolmayer (1995), S. 17.
292
gerung des technischen Betriebs von R/3 lohnen.284 Bei dieser Form des Outsourcings
stellt sich die Frage, ob nur das R/3-System (Server, Betriebssystem und R/3-Basis) oder
die
gesamte IT-Infrastruktur (inkl. Netzwerk und Client-Arbeitsplätzen) ausgelagert
werden soll. Zweifellos geht mit steigendem Auslagerungsgrad internes Know-how verloren und gleichzeitig steigt die Abhängigkeit von Dienstleistungsunternehmen.
Ein Outsourcing der betriebswirtschaftlichen Funktionen des R/3-Systems erscheint wenig sinnvoll, da dieses Wissen zu den Kernkompetenzen der Fachabteilungen gehört
und bei der Implementierung mit dem notwendigen Systemwissen ergänzt werden
muss. Beim Outsourcing dieses Know-hows entstehen starke Abhängigkeiten von den
involvierten Beratungsunternehmungen und die Wartbarkeit des System ist längerfristig
in Frage gestellt. Der ergänzende Einbezug von Beratungspartnern für den Einführungsprozess ist hingegen nahezu unumgänglich.285
Rund ein Drittel der Schweizer R/3-Anwender betrieben beim Einsatz von R/3 ein
Outsourcing. Bei der Form des Outsourcings zeigte sich ein einheitliches Bild. Eine
Mehrheit der R/3-Anwender (72%) hat sich für ein ausschliesslich systemtechnisches
Outsourcing (Einrichtung und Wartung der Hardware, der Systemsoftware, des R/3Basissystems und der Datenbank) entschieden. Die übrigen Bereiche wurden eher selten ausgegliedert. Abb. 5-29 veranschaulicht, welche im Zusammenhang mit dem R/3Einsatz anfallenden Aufgaben innerbetrieblich286 und welche ausserbetrieblich wahrgenommen werden. Zusätzlich wird gezeigt, welche Aufgaben in welchem Ausmass sowohl innerbetrieblich als auch durch den Outsourcer ('beides' in der Grafik) wahrgenommen werden.
284
285
286
Vgl. AFOS (1996), S. 33 ff.
Vgl. Kap. 5.4.4.6.
Unter innerbetrieblichem Outsourcing ist z.B. der Betrieb der Hardwareplattform für das R/3System im eigenen Unternehmen aber durch fremdes Personal zu verstehen.
293
Outsourcing
(n=29)
20
Anzahl Nennungen
18
16
14
12
10
8
6
4
2
0
Einführung
(Projektv erantw ortung)
R/3-Hardw are
(Serv er)
R/3-System: Basis
(Releasew echsel, DB)
R/3-System:
betriebsw irtschaftlich
(Customizing)
Netzw erke
(LAN, WAN)
Form des Outsourcing
innerbetrieblich
ausserbetrieblich
beides
Abb. 5-29: Outsourcingvarianten von R/3.
Zusätzlich zur Frage nach der Häufigkeit und der Art des Oursourcings wurde untersucht, ob sich die Wahl einer Outsourcing-Lösung auf die durchschnittliche Dauer und
Kosten einer Einführung auswirkt (vgl. H 4.9 und 4.10). Dabei konnten weder im Bereich der Kosten noch im Bereich der Einführungsdauer signifikante Unterschiede festgestellt werden. Auch bei der Betrachtung der Unterschiede in den Verhaltensweisen
von KMUs und Grossunternehmen liess sich kein signifikanter Unterschied feststellen:
KMUs wählen nur unwesentlich häufiger eine Outsourcing-Lösung für den Betrieb des
R/3-Systems als Grossunternehmen (vgl. H 1.15).
294
5.4.6 Anpassung des R/3-Systems
5.4.6.1 Anpassung der Organisation und/oder der Software
Ein noch so flexibles EMS kann den betrieblichen Ist-Zustand in den wenigsten Fällen
exakt abdecken. Daher stellt sich die Frage nach der Art der vorzunehmenden Anpassungen. Sollen die Unternehmensprozesse in vollem Umfang auf das System ausgerichtet werden oder soll das System mit allen zur Verfügung stehenden Mitteln an das
eigene Unternehmen angepasst werden? Beide Vorgehensweisen stellen Extremvarianten dar, deren Umsetzung in den meisten Fällen wenig sinnvoll ist.
Beim Kauf von EMS wird betriebswirtschaftliches Know-how in grossem Umfang miterworben. Diese betriebswirtschaftlichen Vorstellungen über den Ablauf von Prozessen
wurde in einer grossen Zahl von Projekten gesammelt und in den jeweiligen Systemen
umgesetzt. Die implementierten Varianten von Geschäftsprozessen können vielfach als
"Best in Practice" betrachtet werden. Die Einführung eines EMS bietet daher die Chance, gewachsene Strukturen und Prozesse zu überdenken und gleichzeitig mit der Einführung eines neuen EMS einen Reengineering-Prozess durchzuführen. Unter Business
Process Reengineering (BPR) wird das fundamentale Überdenken und radikale Neugestalten von Geschäftsprozessen verstanden. Man erhofft sich dadurch nachhaltige Verbesserungen in kritischen Zielgrössen wie Kosten, Qualität, Service und Geschwindigkeit.287 In Verbindung mit dem Einsatz von EMS führt ein Reengineering tendenziell zu
einer Standardisierung der betrieblichen Abläufe.
Im Gegensatz dazu versuchen viele Unternehmen, sich durch besondere Leistungsdifferenzen (z.B. eine besondere Dienstleistung) von der Konkurrenz abzuheben und so
Marktvorteile zu erlangen. Diese Merkmale richten sich in der Regel nicht nach einem
Standard und eine Unterstützung solcher Funktionen wird in EMS meist vergeblich gesucht. Gelang es einem Unternehmen, sich z.B. durch spezielle Dienstleistungen von
seinen Konkurrenten abzuheben, so wird es bestrebt sein, diesen Vorteil mit der Ein-
287
Vgl. z.B. Hammer/Champy (1993), S. 32.
295
führung eines EMS nicht zu verlieren, sondern beizubehalten oder sogar noch auszubauen.
Aufgrund dieser Überlegungen sind beide Formen der Anpassung als legitim zu betrachten. Damit aber eine passende Strategie festgelegt werden kann, muss vorgängig
der Funktionsabdeckungsgrad ermittelt werden. Dazu ist es hilfreich, wenn BPRAktivitäten mit Hilfe von Prozessbeschreibungswerkzeugen und entsprechenden Referenzmodellen strukturiert und dokumentiert werden.288 Verschiedene Unternehmungen
bieten solche Werkzeuge (z.B. ARIS Toolset, Visio, IntelliCorp LiveModel) an. Angaben
über den Umfang, in dem solche Instrumente in den Schweizer R/3-Einführungen zum
Einsatz gelangen, finden sich im Abschnitt 5.4.4.9.
Organisatorische Anpassung
(n=90)
50
45
40
35
30
25
20
15
10
5
0
22%
A. Anpassung von
Geschäftsprozessen
und Organisationsstrukturen an die
Vorgaben von R/3
50%
Auf beide Arten mit
einem
Schwergewicht bei A
7%
B. Anpassung des
R/3-Systems an die
eigenen Geschäftsprozesse und Organisationsstrukturen
21%
Auf beide Arten mit
einem Schwergewicht
bei B
Abb. 5-30: Organisatorische Anpassung.
Die Vorgehensweisen der Schweizer R/3-Anwender im Einführungsprozess sind Abb. 530 zu entnehmen. Es zeigt sich, dass in knapp einem Viertel der Fälle konsequent die
Unternehmensstrukturen an die Strukturen des R/3-Systems angepasst wurden. Am
288
Vgl. Wenzel (1995), S. 3.
296
häufigsten zu finden waren Unternehmen, welche schwergewichtig diesen Weg einschlugen, daneben jedoch auch Anpassungen des Systems an die Unternehmensstrukturen vornahmen. Nur in seltenen Fällen (7%) wurde versucht, das System vollumfänglich an vorgegebene Strukturen und Prozesse anzupassen.
In einer vom Institut für Wirtschaftsinformatik der Universität Frankfurt vorwiegend in
Deutschland durchgeführten Untersuchung289 wurden ähnliche Werte ermittelt. Dabei
hat sich gezeigt, dass drei Viertel der Unternehmen, welche eine reine Automatisierung
der Prozesse vorgenommen haben, diesen Weg bei erneuter Einführung nicht mehr
beschreiten würden. Eine deutliche Mehrheit der Befragten würde gemäss dieser Untersuchung künftig eine Einführung mit gleichzeitiger Software- und Organisationsänderung
bevorzugen.
Bei der Wahl der Anpassungsvariante ist auch von Interesse, inwiefern sich dadurch die
Kosten und die Dauer einer Einführung beeinflussen lassen.290 Bei der Untersuchung
dieser Zusammenhänge lassen sich grundsätzlich keine signifikanten Unterschiede feststellen (vgl. H 4.5 und H 4.6). Im Einführungsprozess benötigen organisatorische Änderungen Zeit und verursachen Kosten. Das gleiche gilt auch für Anpassungen des Systems. In der Betriebsphase ist allerdings davon auszugehen, dass sich Modifikationen
und Erweiterungen des Systems bei einem Release-Wechsel negativ auf die Kosten und
die Dauer einer Umstellung auswirken. Auch zwischen KMUs und Grossunternehmen
lassen sich in diesem Zusammenhang keine Unterschiede in den gewählten Vorgehensweisen feststellen (vgl. H 1.13).
289
290
Buxmann/König (1996), S. 161 ff.; vgl. auch Hüttenhain (1990), S. 142.
Vgl. Hiekel 1994, S. 43ff.; Buxmann/König (erscheint in Wirtschaftsinformatik).
297
5.4.6.2 Art der Anpassung
Das R/3-System lässt verschiedene Formen der Anpassung zu. Im Normalfall erfolgt das
Customizing durch Parametersetzung. Reichen diese Möglichkeiten nicht aus, können
zusätzlich benötigte Funktionen über User Exits in das System eingebunden werden.
Häufig besteht auch der Wunsch, Fremdsysteme mit dem R/3-System entweder über
Standardschnittstellen (z.B. Batch Input) oder über selbst erstellte Schnittstellen zu verbinden. Die einschneidendste Form der Anpassung stellen Änderungen bzw. Erweiterungen des Source Codes dar ("Harte" Codierung). Durch Anpassungen, welche über
das eigentliche Customizing hinausgehen, kann beim Übergang von einem Release zum
nächsten ein erheblicher Mehraufwand entstehen. Aus diesem Grund gilt die Empfehlung, möglichst wenig vom Standard abzuweichen und die Organisation weitgehend auf
die von EMS unterstützten Optionen abzustimmen.291
Abb. 5-31 vermittelt einen Eindruck, wie die befragten Unternehmen die notwendigen
Anpassungen vorgenommen haben. Obwohl ein recht hoher Funktionsabdeckungsgrad
angegeben wurde (88%), nahmen rund 50% der befragten Anwender Veränderungen
am R/3-System vor. Bezüglich des Funktionsabdeckungsgrads liess sich kein signifikanter
Unterschied zwischen KMUs und Grossunternehmen feststellen (vgl. H 1.17). In 29%
der Fälle wurden Erweiterungen durch Verwendung der vorhandenen User Exits vorgenommen und in 15% der Fälle wurde sogar in den Source Code eingegriffen. Dabei
nehmen KMUs gleich häufig Veränderungen am Source Code vor wie Grossunternehmen (vgl. H 1.14).
291
Vgl. Hiekel (1994), S. 43 ff.; Buxmann/König (erscheint in Wirtschaftsinformatik).
298
Anpassungen bzw. Erweiterungen von R/3 an die betriebliche
Umgebung
Ergänzung v on R/3 durch eigene Applikationen
Durch Verw endung v on User-Ex its
Durch Veränderung des R/3 Source Codes
Anders
0
10
20
30
40
50
Anzahl Nennungen
Abb. 5-31: Art der Anpassung von R/3 an die betriebliche Umgebung.
5.4.6.3 Schnittstellen
Das R/3-System erlaubt die Einbindung verschiedener Fremdsysteme. Applikationen,
die R/3 nicht oder nur in unbefriedigendem Masse anbietet, werden über dauerhafte
Schnittstellen in das System integriert. Über temporäre Schnittstellen werden während
einer Umstellungsphase Verbindungen zu Fremdsystemen unterhalten, damit nicht alle
Applikationen gleichzeitig abgelöst werden müssen (Step-by-Step-Einführung) oder damit während der R/3-Einführung durch die Parallelisierung von Systemen ein höherer
Grad an Sicherheit erreicht werden kann.
In 85% der befragten Unternehmungen wurden auf Dauer geplante Schnittstellen eingerichtet. Temporäre Schnittstellen konnten in 41% der Unternehmen ausfindig gemacht werden. Durchschnittlich verfügten die Systeme der untersuchten Unternehmungen über rund 8 dauerhafte sowie 5 temporäre Schnittstellen.
Bei genauer Untersuchung des Zahlenmaterials konnte ein signifikanter Unterschied
zwischen KMUs und Grossunternehmen beobachtet werden (vgl. H 1.18). KMUs haben
eine weniger stark integrierte Systemlandschaft und sind deutlich weniger häufig mit der
Integration von Fremdsystemen konfrontiert als Grossunternehmen. Die Zahl der auf
Dauer angelegten Schnittstellen ist in KMUs (4) deutlich geringer als in Grossunternehmen (12). Allerdings lassen sich auch hier keine signifikanten Auswirkungen auf die
Einführungskosten und -dauer feststellen (vgl. H 2.7 und 2.8).
299
5.4.7 Produktionsvorbereitung und Inbetriebnahme
5.4.7.1 Datenübernahme
Vorhandene Stamm- und Bewegungsdaten werden bei der Einführung eines neuen
EMS in den meisten Fällen teilweise oder vollständig übertragen. Dies geschieht durch
automatische Übernahme der Daten aus dem Altsystem oder durch eine komplette
Neuerfassung. Automatische Datentransfers sind nicht unproblematisch. Man nimmt ein
erhebliches Risiko in Kauf, entweder veraltete oder gar falsche Daten ins neue System
zu importieren. Die Problematik ist vor allem auf zwei Ursachen zurückzuführen. Zum
einen enthalten ältere Datenbestände oft einen nicht unerheblichen Anteil ungültiger
Daten, zum andern gilt zu berücksichtigen, dass die Datenqualität bei einer automatischen Übernahme eher sinken kann.
Auch das beste System ist nicht in der Lage, valide Ergebnisse zu generieren, wenn der
Input eine ungenügende Qualität aufweist ("Garbage in - Garbage out"). Die manuelle
Datenübernahme bzw. die Neuerfassung von überprüften und aktualisierten Datenbeständen stellt zwar einen erheblichen Aufwand dar, bietet aber bessere Voraussetzungen für eine hohe Datenqualität im produktiven Betrieb eines neuen Systems.
Abb. 5-32 zeigt, in welchem Umfang die befragten Unternehmen Daten automatisch
oder manuell aus dem Altsystem ins neue System übernommen haben. Dabei fällt auf,
dass bei Stammdaten in rund 90% der Fälle eine Datenübernahme erfolgt (In 10% der
Fälle werden keine Stammdaten übernommen). Bei 40% der Unternehmungen wurden
diese ausschliesslich automatisch übernommen, bei 32% sowohl automatisch als auch
manuell und bei 18% nur manuell.
Im Bereich der Bewegungsdaten haben nur 60% der untersuchten Unternehmungen
Daten übernommen. 33% haben Daten automatisch, 16% sowohl automatisch als auch
manuell und 11% haben Bewegungsdaten ausschliesslich manuell übernommen.
300
Übernahme von Stammdaten
(n=91)
Übernahme von Bewegungsdaten
(n=89)
keine
Datenübernahme
10%
keine
Datenübernahme
40%
automatisch
40%
automatisch und
manuell
32%
automatisch
33%
automatisch und
manuell
16%
manuell
18%
manuell
11%
Abb. 5-32: Übernahme von Stammdaten und Bewegungsdaten.
In Abb. 5-33 werden die Hauptschwierigkeiten bei der Datenübernahme dargestellt.
Am häufigsten wurden Probleme im Bereich der Schnittstellenprogrammierung sowie
der Gewährleistung der Datenintegrität genannt.
Hauptschwierigkeiten bei der Datenübernahme
Schnittstellenprogrammierung
Gew ährleistung der Datenintegrität
Übernahme v on Vergangenheitsdaten
Nummerungssysteme
Andere Schw ierigkeiten
Klassifizierung
Keine Schw ierigkeiten
0
5
10
15
20
25
30
Anzahl Nennungen
Abb. 5-33: Probleme bei der Datenübernahme.
301
5.4.7.2 Schulung
Ein gut eingerichtetes und sachkundig an das Unternehmen angepasstes EMS ist zwar
eine wichtige Voraussetzung aber noch lange keine Garantie für dessen erfolgreiche
Nutzung. Fehlen den Anwendern die zur Arbeit erforderlichen Kenntnisse und bestehen
damit direkt oder indirekt verbundene Akzeptanzprobleme, ist der erfolgreiche Einsatz
sehr fraglich. Dieses Defizit kann nur durch eine bedürfnisgerechte Anwenderschulung
beseitigt werden (vgl. Abschnitt 5.4.4.10).
Projektmitarbeiter und Endanwender haben sehr unterschiedliche Bedürfnisse. Projektmitarbeiter müssen bestimmte Bereiche eines Systems in ihrer ganzen Breite kennen, damit eine möglichst gute Unterstützung der Geschäftsprozesse gewährleistet werden kann. Ein Endanwender hingegen muss die für ihn relevanten Funktionen in ihrer
ganzen Tiefe kennen. Das bedeutet nicht, dass Endanwender nur in Einzelfunktionen
geschult werden sollen. Die Orientierung an durchgängigen Geschäftsprozessen sollte
bei der Konzeption der Anwenderschulung im Vordergrund stehen, damit der Anwender über das notwendige Integrationswissen verfügt.292 Neben der Kenntnis der notwendigen Zusammenhänge ist es aber von Vorteil, nur die für die tägliche Arbeit relevanten Bereiche zu schulen und nicht in hohem Ausmass eine "Ausbildung auf Vorrat"
zu betreiben.
Die Problematik der Anwenderschulung ist begründet durch die begrenzten zeitlichen
Ressourcen der späteren Anwender sowie die begrenzten zeitlichen und personellen
Ressourcen der mit der Durchführung der Schulung betrauten internen Projektmitarbeiter. Weitere Probleme können die umfassende Funktionalität des entsprechenden
Systems, Wirtschaftlichkeitsaspekte bezüglich der Durchführung von Schulungsveranstaltungen und allenfalls vorhandene kundenspezifische Erweiterungen darstellen.293
292
293
Vgl. z.B. Blume (1997), S. 164.
Goetzner/Sommerfeld (1995), S. 48; Sturm (1996), S. 43 ff.
302
Diese Rahmenbedingungen erfordern die Durchführung der Schulung vor Ort, eine
flexible Termingestaltung und einen modularen Aufbau der Schulungsveranstaltungen.
Aus den erwähnten Gründen ist der Besuch von Standardkursen der SAP oder anderer
Anbieter für Endanwender nur in Ausnahmefällen sinnvoll. Die massgeschneiderte
Schulung, bei welcher in modularer Form die konkreten Arbeitsabläufe des Endanwenders geschult werden, ist vorzuziehen. Zur Bestimmung der Schulungsinhalte und einer
geeigneten Unterteilung in Lernmodule bedarf es einer intensiven Ausbildungsbedarfsanalyse.
Ferner ist auch zu prüfen, ob die Vermittlung der Grundlagen mittels multimedialer
CBT-Schulung294 mit individuellem Coaching erfolgen kann. Vorteile dieser Schulungsart
liegen in der Wirtschaftlichkeit bei grossen Benutzerzahlen und in der Berücksichtigung
des individuellen Lerntempos.295
Diese Überlegungen werden durch die befragten R/3-Anwender mit einigen Ausnahmen bestätigt. Die Projektmitarbeiter werden mehrheitlich (55%) extern geschult, wobei
häufig eine Kombination zwischen interner und externer Schulung zu beobachten ist. In
den meisten Fällen (89%) werden bei externer Schulung Kurse der SAP besucht. Ein
deutlicher Unterschied besteht zwischen Schulung der Projektmitarbeiter und Endanwenderschulung. Endanwender werden nur in 21% der Fälle extern geschult, wobei
auch in diesen Fällen zuweilen eine Kombination zwischen interner und externer
Schulung gewählt wurde.
Die Schulung der Endanwender wird häufig von eigenen Mitarbeitern oder von SAPBeratern durchgeführt (vgl. Abb. 5-34). Weit weniger häufig sind andere Lernformen
wie das Selbststudium oder die Schulung mittels CBT-Software anzutreffen. Während
CBT-Software bei der Endanwenderausbildung 1994 nur bei einem Prozent der R/3Anwender zum Einsatz kam,296 liess sich bei dieser Schulungsart 1996 ein wesentlich
höhere, absolut gesehen aber immer noch geringe Verbreitung (7%) feststellen.
294
295
296
CBT = Computer Based Training (computergestützte Ausbildung).
Vgl. z.B. Bartels/Siebeck (1995), S. 291 ff.; Franken/Jörgensen (1995), S. 315 ff.
303
Projektmitarbeiter werden in den meisten Fällen von SAP-Beratern direkt ausgebildet.
Teilweise erfolgt die Ausbildung der Projektmitarbeiter auch im Selbststudium oder
durch andere Projektmitarbeiter. CBT-Software wird für die R/3-spezifische Ausbildung
von Projektmitarbeitern kaum verwendet.
Bei näherer Betrachtung der am Markt erhältlichen CBT-Produkte wird die eher geringe
Verwendung dieser Ausbildungsmethode plausibel. Die zum heutigen Zeitpunkt vorhandenen Produkte geben nur einen groben Einblick in einzelne Module des R/3Systems und sind deswegen für Projektmitarbeiter aufgrund der fehlenden Tiefe eher
ungeeignet. Auch für Endanwender sind diese Produkte nur für die Vermittlung der
Grundlagen empfehlenswert. Für die Detailausbildung fehlt bei den auf dem Markt erhältlichen Produkten die Möglichkeit, sich nur auf die auch wirklich relevanten Prozesse
zu konzentrieren und dabei firmenspezifische Merkmale zu berücksichtigen. Wie in
einer Vergleichsbetrachtung gezeigt wurde,297 kann der Einsatz von firmenindividueller
CBT-Software trotz des hohen Erstellungsaufwandes bei einer grossen Zahl auszubildender Anwender wirtschaftlicher sein und zusätzlich didaktische Vorteile bieten.
relative Anzahl Nennungen
80%
Zuständigkeit für die interne Schulung von
Projektleitern und Endanwendern
(n=91)
70%
60%
50%
40%
30%
20%
10%
0%
Schulung
erfolgte durch:
Eigene Mitarbeiter
SAP-Berater
Projektteams
Abb. 5-34: Art der Schulung.
297
Vgl. Franken/Jörgensen (1995), S. 332.
304
Selbststudium
Endanw ender
CBT
andere
Auf die Frage nach den Merkmalen des für die Anwenderschulung verwendeten R/3Systems gaben rund 90% der befragten Unternehmen an, dass diese an unternehmensspezifisch angepassten Systemen stattfand und nur in 10% der Fälle auf Systemen ohne
Unternehmensbezug (z.B. im Rahmen von Standardkursen bei SAP) durchgeführt wurde. Bei einer Schulung mit Unternehmensbezug wurde in rund zwei Drittel der Fälle mit
Kopien von betrieblichen Echtdaten gearbeitet (vgl. Abb. 5-35).
Art des für die Ausbildung verwendeten R/3-Systems
(n=95)
100%
90%
80%
70%
60%
50%
40%
30%
20%
System mit
Kopien
betrieblicher
Echtdaten
10%
0%
unternehmensspezifisch angepasstes
System
System ohne Abbildung
unternehmensspezifischer Merkmale
© Institut für Wirtschaftsinformatik, Bern 1997
Abb. 5-35: Verwendetes Schulungssystem.
Die Bestimmung des Schulungszeitpunktes ist für den Ausbildungserfolg ein wichtiger
Faktor. Sowohl Endanwender als auch Projektmitarbeiter sollten das Erlernte unmittelbar nach Absolvierung der Schulungsveranstaltung am System umsetzen können. Ist die
Zeitspanne zwischen Schulung und produktiver Nutzung zu lang, geht ein zu grosser
Teil des erworbenen Wissens verloren. Erfolgt die Ausbildung erst nach Produktivstart,
besteht die Gefahr, dass durch Fehleingaben Probleme mit der Datenqualität und zusätzlich Akzeptanzschwierigkeiten entstehen.
In Anlehnung an diese Rahmenbedingungen erachtete es eine Mehrheit der Befragten
als sinnvoll, die Endanwenderschulung unmittelbar vor Beginn der Produktivphase
durchzuführen, obwohl dies einen hohen Schulungsbedarf in kurzer Zeit bedeutet. Die
305
Schulung der Projektmitarbeiter erfolgt in den meisten Fällen vor Projektbeginn oder je
nach Bedarf während der Durchführung des Projektes.
5.4.7.3 Inbetriebnahme
Der Inbetriebnahme gehen unmittelbar die Datenübernahme (Übernahme von Systemeinstellungen aus dem Testsystem und Daten aus Altsystemen), die Organisation der
Systemadministration und des Benutzersupports, die Anwenderschulung und die Qualitätsprüfung des Produktivsystems voraus. Der Produktivstart erfolgt in der Regel per
Stichtag. Damit auch im Katastrophenfall der Betrieb der für das Unternehmen lebenswichtigen Systeme gewährleistet ist, werden Alt- und Neusysteme in besonders kritischen Fällen für eine Übergangszeit parallel geführt. Dieser Parallelbetrieb ist zwar kostenintensiv, bietet aber einen erhöhten Grad an Sicherheit. Für einen Parallelbetrieb
zwischen Alt- und Neusystemen haben sich 31% der befragten R/3-Anwender entschieden. Dabei wurden in den meisten Fällen die Module FI und HR parallel zu den zuvor
eingesetzten Systemen betrieben.
Auf die Frage nach Problemen und Ursachen nach dem Produktivstart haben sich nur
30 Unternehmungen geäussert. Dabei ist allerdings anzumerken, dass zum Zeitpunkt
der Untersuchung nur in 65% der befragten Unternehmen R/3-Installationen bereits
produktiv waren. Die am häufigsten genannten Probleme waren Performance-Probleme
und Akzeptanzschwierigkeiten der Anwender durch unzureichende Information und
Schulung. Daneben wurden mehrfach Probleme mit Fehlkonfigurationen (ungeeignete
Parametereinstellungen), Fehlern im R/3-System und nicht ausreichender Funktionalität
genannt.
Die Anwenderunterstützung nach Inbetriebnahme des R/3-Systems stellt einen wichtigen Faktor für die Akzeptanz des Systems sowie für die Förderung und Erhaltung der
Datenqualität dar. Dabei sind verschiedene Support-Formen zu unterscheiden (vgl.
Abb. 5-36).
Die häufigste Form des Benutzersupports ist die Abdeckung dieser Bedürfnisse durch
besonders ausgebildete "Super User" (57%). Diese zeichnen sich dadurch aus, dass sie
306
in der Regel den Fachabteilungen angehören, am R/3-Einführungsprojekt aktiv beteiligt
waren und über das notwendige fachabteilungsspezifische Wissen verfügen. Der
Hauptvorteil des Einsatzes von "Super Usern" ist die Nähe zum Anwender und damit
verbunden die enge Problemverbundenheit sowie die rasche Problemlösung durch Präsenz vor Ort.
Anwenderunterstützung
Relative Anzahl Nennungen
60%
50%
40%
30%
20%
10%
0%
Besonders
ausgebildete
"Super User"
Projekt- /
Systemverantwortliche
BenutzerServiceZentren (IC)
SAP
Anders
Keine formelle
Regelung
Abb. 5-36: Form der Anwenderunterstützung.
Sehr häufig (56%) werden auch Modulverantwortliche (Systemverantwortliche) für den
Anwender-Support eingesetzt. Diese verfügen über ein entsprechendes R/3-Know-how
ohne detailliertes Fachabteilungswissen und beschäftigen sich schwerpunktmässig mit
dem R/3-Support. Der Vorteil einer solchen Variante ist der grosse Spezialisierungsgrad
und damit verbunden die Möglichkeit, beim Einsatz von R/3 in einem bestimmten
Fachbereich (z.B. Controlling) über die Abteilungsgrenzen hinaus zu agieren. Diese Lösung ist in Kombination mit dem "Super User"-Modell besonders in grossen Unternehmen mit ausgedehntem R/3-Einsatz sinnvoll.
Anwender-Support könnte auch durch die Erweiterung der Aufgaben eines BenutzerService-Zentrums (Information Center; IC) um den R/3-Support erfolgen. Diese Variante
ist allerdings weit weniger verbreitet (36%). Die Gründe mögen in der Ferne zum An-
307
wender und in der fehlenden Kenntnis fachabteilungsspezifischer Aufgaben liegen. Im
Unterschied zum Support von anwendungsneutraler Standardsoftware sollte für den
nutzbringenden Support von R/3 ein detailliertes Know-how über die Abwicklung der
Prozesse in den Fachabteilungen vorhanden sein. Diese Voraussetzung kann in der Regel durch ein IC nicht sinnvoll erfüllt werden. Hingegen kann ein IC bei der Lösung von
technischen oder anderen anwendungsneutralen Problemen (z.B. SAPGUI-Installation,
Netzwerkwartung, Druckereinrichtung) gute Dienste leisten.
Eine eher seltene Form der Anwenderunterstützung stellt der direkte Support durch SAP
(z.B. via OSS) dar (17%). Diese Support-Form wird praktisch ausschliesslich ergänzend
angewandt und ist für den Support von Endanwendern (Ausnahme: sehr kleine Installationen) aufgrund der auftretenden Problemredundanzen eher ungeeignet. Für den Support der "Super User" und der Modulverantwortlichen ist dieses Mittel allerdings unerlässlich. Auf diese Weise ergeben sich mehrstufige Supportstrukturen.298
Trotz der hohen Relevanz der Benutzerunterstützung zur Gewährleistung einer effizienten Systemnutzung und zur Förderung der generellen Akzeptanz ist erstaunlich, dass
in einigen Unternehmen (8%) keine formelle Regelung für den Benutzer-Support getroffen wurde.
298
Vgl. Mertens/Knolmayer (1995), S. 63 ff.
308
Management-Empfehlungen für die Abwicklung von R/3-Projekten
6 Managementempfehlungen für die
Abwicklung von R/3-Projekten
6.1 Einleitung
Bevor auf konkrete Management-Regeln bei der Einführung von EMS im allgemeinen
und SAP R/3 im speziellen eingegangen wird, sollen noch einmal die mit der Einführung
eines EMS verfolgten Ziele betrachtet werden. Eine allgemeine Zielformulierung bei der
Einführung von SAP R/3 könnte wie folgt ausgedrückt werden:299
Allgemeine Zielformulierung für die Einführung eines EMS
Erreichung einer möglichst effizienten IV-technischen Unterstützung des Leistungserstellungsprozesses verbunden mit der Erhaltung oder Steigerung der Leistungsqualität
und der Kundenserviceleistungen unter Einhaltung eines vorgegebenen Zeit- und Kostenrahmens.
Eine solche allgemein gefasste Zielformulierung kann sicherlich nicht als Zielsetzung für
ein konkretes R/3-Projekt herangezogen werden, sondern zeigt lediglich die zu berücksichtigenden Zieldimensionen auf. Für ein konkretes Projekt müsste die gewünschte
Ausprägung jeder einzelnen Zieldimension spezifiziert werden. Dies erweist sich bei der
Festlegung von Kosten- und Zeitschranken als vergleichsweise einfach. Hingegen fällt
eine klare und eindeutig messbare Festlegung des gewünschten betriebswirtschaftlichen
Leistungsumfanges, der Produkte- oder Dienstleistungsqualität und der Kundenserviceleistungen schon erheblich schwerer. Die einzelnen Zieldimensionen werden im folgenden kurz diskutiert.
Eine möglichst effiziente IV-technische Unterstützung des Leistungserstellungsprozesses bezieht sich auf die bestmögliche Abdeckung der betriebswirtschaftlichen Anforderungen eines Unternehmens durch ein EMS. Diese Vorgabe lässt sich durch eine de-
299
von Arb/Stebler (1996), S. 15.
309
taillierte Evaluation und ein seriös durchgeführtes Customizing erreichen. Grundlage für
diese Aktivitäten bildet ein entsprechendes Soll-Konzept (Beschreibung der Geschäftsprozesse) und die Bereitschaft, die vorgedachten Prozesse unter Umständen an die Vorgaben des EMS anzupassen. Ausnahmen stellen individualisierte Geschäftsprozesse zur
Erlangung von Wettbewerbsvorteilen dar. Es muss allerdings im Einzelnen geprüft werden, ob eine Anpassung des Systems und die damit verbundenen Nachteile wirklich zu
verantworten sind.
Im Bereich der Qualitätsanforderungen sind in vielen Unternehmen die Vorgaben einer ISO-9000-Zertifizierung massgebend. Bei der Einführung des EMS muss angestrebt
werden, dass die durch eine ISO-Zertifizierung geforderten Qualitätssicherungsmassnahmen möglichst gut durch das System unterstützt werden. Als Beurteilungsmassstab
gelten die Prozessvorgaben und Richtlinien der Qualitätszertifizierung.
Alle Aktivitäten zur Erhaltung und Verbesserung der Kundenserviceleistungen stellen
einen weiteren wichtigen Aspekt dar. Auch diesem Gesichtspunkt muss bei der Einführung ein besonderes Augenmerk beigemessen werden, denn mit zunehmender Angleichung der produktespezifischen Merkmale wird bei Auswahlentscheiden ein erhöhtes
Gewicht auf die gebotenen Kundenserviceleistungen gelegt. Die Formulierung von verbindlichen Zielsetzungen in diesem Bereich ist schwierig und könnte im Einzelfall beispielsweise wie folgt aussehen:
Erledigung von Kundenproblemen innerhalb von 5 Arbeitstagen verbunden mit der
Möglichkeit, jederzeit (z.B. über Internet) über den Status der Abwicklung eines Kundenserviceauftrages Auskunft geben zu können.
Die drei genannten Zieldimensionen lassen sich zur Gruppe der Sachziele zusammenfassen und sind stark von unternehmensbezogenen Merkmalen abhängig. Bei einer
branchenspezifischen Betrachtung dieser Merkmale lassen sich allerdings starke Verwandtschaften feststellen, durch welche sich dennoch verallgemeinernde Aussagen ableiten lassen und ein Vergleich von Projekten gleicher Grössenordnung als zulässig erscheinen lässt.
310
Die Grössenordnung wird primär durch die benötigte betriebswirtschaftliche Funktionalität und die zur Bewältigung des Arbeitsvolumens notwendige Benutzerzahl bestimmt.
Daraus lässt sich der für das Einführungsprojekt notwendige zeitliche und finanzielle
Aufwand ableiten. Konkrete Aussagen über die projektspezifischen Bedingungsgrössen
könnten wie folgt aussehen:
Für die Einführung von SAP R/3 mit der im Soll-Konzept beschriebenen Funktionalität
steht ein Budget von maximal CHF 2.5 Mio zur Verfügung. Die Projektdauer darf 12 Monate nicht überschreiten.
Durch die beschriebenen Zielsetzungen, welche für die einzelnen Teilprojekte weiter
spezifiziert und bei längerer Projektdauer zeitlich gestaffelt werden müssen, sind die
Vorgaben für ein R/3-Projekt hinreichend definiert. Im Rahmen dieser Zielsetzungen gilt
es nun, das Projekt möglichst gut zu strukturieren und alles zu unternehmen, damit nach
Produktivstart die Abwicklung der betriebswirtschaftlichen Prozesse möglichst optimal
unterstützt wird und die Anwender gleichzeitig Willens und in der Lage sind, die ihnen
zugewiesenen Aufgaben bestmöglich zu erledigen.
Der in Kapitel 5 dargelegte Bezugsrahmen wird nun im Hinblick auf der Basis der ermittelten Ergebnisse aus der empirischen Untersuchung und den oben genannten Zielsetzungen ausführlich diskutiert und daraus Bedingungsgrössen für die Bestimmung des
Projektvolumens und Managementempfehlungen für den zweckmässigen Ablauf einer
R/3-Einführung abgeleitet (vgl. Abb. 6-1).
311
Unternehmensbezogene
Bedingungsgrössen
Projektbezogene
Bedingungsgrössen
Technische
Bedingungsgrössen
Anzahl Mitarbeiter
Anzahl User
Bisherige Systemarchitektur
Branche
Anzahl Module
Bisherige Softwareachitektur
Singlesite-/Multisite-Organisation
Anzahl Projekte
Anzahl Schnittstellen
Anzahl Projektmitarbeiter
R/2-Erfahrung
Freistellungsgrad der Projekt-MA
Primäre
Wirkungsrichtung
Management
Aktionsparameter
Berater
Anwender
Projektorganisation
CSF
Organisations-/
Systemanpassung
Projektleiter
Zielsetzungen
Kommunikation
pos., neg. Beeinflussung
Sachziele
pos., neg. Beeinflussung
Kostenziele
Terminziele
Abb. 6-1: Bedingungsgrössen und Aktionsparameter bei der Einführung von SAP R/3.300
300
Die Dicke der Pfeile gibt Auskunft über die Stärke des Einflusses.
312
6.2 Bedingungsgrössen
6.2.1 Unternehmensgrösse
Bei der Auswertung der quantitativen Befragung (Kapitel 5) wurde darauf hingewiesen,
dass Schweizer R/3-Anwender im Hinblick auf die Unternehmensgrösse in zwei Gruppen eingeteilt werden können. Auf der einen Seite steht die Gruppe der Grossunternehmen mit mehr als 500 Mitarbeitern. Auf der andern Seite gibt es eine grössere Zahl
kleiner und vor allem mittelgrosser Unternehmen (KMUs) mit bis zu 500 Mitarbeitern,
welche das R/3-System auf Unternehmensebene einsetzen. Bei der Gegenüberstellung
dieser Anwendergruppen stellt sich die Frage, inwiefern sich diese hinsichtlich einer
R/3-Einführung unterscheiden. Untersucht wurden im Rahmen der empirischen Untersuchung die in Tab. 6-1 zusammengestellten Unterscheidungsmerkmale.
Unterscheidungsmerkmal
KMUs
Grossunternehmen
Beurteilung
Zahl der eingeführten Module
6
6
l
Anzahl Named User
84
474
¡
Einführungskosten total
2,0 Mio. CHF
7,5 Mio CHF
¡
Einführungskosten für 100 Named User
2,3 Mio. CHF
2,3 Mio. CHF
l
1:4
1:3
¤
12 Monate
19 Monate
¡
6 PM
6 PM
l
90%
90%
l
Methodische Unterstützung
identisch
identisch
l
Organisatorische Anpassung
identisch
identisch
l
Veränderungen am Source Code
15%
15%
l
Outsourcing
42%
23%
¤
4
12
¡
Verhältnis Lizenzkosten:Einführungskosten
Einführungsdauer
Zahl der auf Dauer eingerichteten Schnittstellen
l identisch ¡ statistisch signifikanter Unterschied ¤ statistisch nicht signifikanter Unterschied
Tab. 6-1: Unterschiede bei R/3-Einführungen zwischen KMUs und Grossunternehmen.
313
Bei einer summarischen Betrachtung der Unterschiede zwischen KMUs und Grossunternehmen ist festzustellen, dass sich R/3-Installationen, ausgenommen von der Grösse
und dem Grad der Vernetzung mit Umsystemen, kaum unterscheiden. Es lassen sich
weder Differenzen in der Einsatzbreite noch in der Art der Einführung (Organisationsanpassung, Customizing etc.) erkennen. Die Kosten für 100 Named User bewegen sich
ebenfalls auf einem ähnlichen Niveau. Dies lässt die Schlussfolgerung zu, dass R/3 in
einer KMU bei gleicher Anzahl Named User im Vergleich zu einer Grossunternehmung
weder einfacher noch kostengünstiger eingeführt werden kann.
Die bei der Einführung von R/3 anfallenden Kosten und die dazu benötigte zeitliche
Dauer werden grundsätzlich als relativ hoch erachtet.301 In diesem Kontext stellt sich
nun die Frage, ob sich die Einführung von R/3 im Mittelstand lohnt und welche Alternativen gegebenenfalls in Betracht gezogen werden sollten. Diese Fragen lassen sich nicht
eindeutig beantworten. Abb. 6-2 soll diese Problematik veranschaulichen.
SAP R/3
Konkurrenzprodukt 1
Grossunternehmen
KMU A
KMU B
KMU D
KMU C
Abb. 6-2: Einsatz von R/3 im Mittelstand.
301
Vgl. z.B. Mirchandani/Dirigus (1996).
314
Das R/3-System bietet eine grosse Funktionsvielfalt und damit gleichzeitig eine entsprechend hohe Flexibilität für die künftige Anpassung von Geschäftsprozessen. Damit verbunden ist die Komplexität des Systems, welche zu hohen Kosten und langwierigen Implementierungen führt. Im Gegensatz dazu lassen sich Systeme, welche enger auf die
Bedürfnisse bestimmter Anwender zugeschnitten sind, schneller und kostengünstiger
einführen. Die Flexibilität für künftige Anpassungen ist dadurch aber stark eingeschränkt. Ein Mittelstandsunternehmen benötigt in der Regel eine kleine Auswahl der in
R/3 zur Verfügung stehenden Geschäftsprozessvarianten. In diesem Kontext steht die
Frage im Raum, wieviel Flexibilität ein Unternehmen zur Abdeckung der zukünftigen
Anforderungen überhaupt vorweisen sollte.
Damit die Einführungszeiten und -kosten des R/3-Systems reduziert werden können,
muss konsequent versucht werden, den Einführungsprozess weiter zu vereinfachen und
zu automatisieren. Werkzeuge zur automatischen Konfiguration von Geschäftsprozessen, Process Templates (vorkonfigurierte Prozesse) und andere methodische Hilfsmittel
(z.B. Business Engineering Workbench) sind Ansätze302, welche zur Verwirklichung dieses Ziels unbedingt weiterentwickelt werden sollten.
6.2.2 Kostenbestimmende Faktoren
Im Rahmen der empirischen Untersuchung liess sich feststellen, dass verschiedene Grössen massgebend für die Einführungskosten verantwortlich sind. Untersucht wurden in
diesem Zusammenhang unternehmensbezogene, projektbezogene und informatiksituationsbezogene Bedingungsgrössen für Kosten und Dauer eines R/3-Einführungsprojektes.
Eine häufig anzutreffende Meinung im Zusammenhang mit der Bestimmung der Projektkosten spiegelt die folgende Aussage wider: "When clients ask us the question, What
does it cost to install SAP? we reply, It depends, There is no simple answer."303 Dass diese Aussage nicht immer zutreffen muss, zeigt eine genaue Analyse der empirischen Da-
302
303
Vgl. Dailey (1996), S. 8 ff.
Dailey (1996), S. 12.
315
ten von Schweizer R/3-Anwendern. Die einzelnen R/3-Installationen innerhalb einer
Branche sind nicht so unterschiedlich wie gemeinhin vermutet wird. Ein grobes Projektvolumen in finanzieller und zeitlicher Hinsicht ohne detaillierte Analyse der Unternehmenssituation lässt sich durchaus ermitteln. Einzige Ausnahme stellen sehr grosse R/3Installationen (mehr als 2'000 Named User) und sehr kleine R/3-Installationen (weniger
als 30 Named User) dar. Bei den genannten Unternehmen streuen die ermittelten
Werte zu stark, so dass sich kaum sinnvolle Aussagen ableiten lassen.
Eine Analyse der empirischen Daten von R/3-Projekten in der Schweiz zeigt erstaunliche
Abhängigkeiten. Primär kostenbestimmend für ein R/3-Projekt ist die vorgesehene Named-User-Zahl und die Anzahl der eingeführten Module. Dabei besteht eine starke
Abhängigkeit im Bereich der Benutzerzahl und eine wesentlich geringere Abhängigkeit
hinsichtlich der Zahl der eingeführten Module. Dies lässt sich dadurch erklären, dass bei
der Zahl der eingeführten Module keine grossen Schwankungen festzustellen sind (in
den meisten Branchen werden im Durchschnitt 6 Module eingesetzt). Bei der Analyse
des Zusammenhanges zwischen Benutzerzahl und Einführungskosten lässt sich feststellen, dass ein Named User im Durchschnitt Einführungskosten von rund CHF 20'000.verursacht (der genaue Wert beträgt CHF 20'416.- bei einer Standardabweichung von
CHF 1'074.-). Besonders zuverlässig erscheint diese Approximation im Industriesektor
(CHF 19'587.-, Standardabweichung CHF 1'121.-). Anhand dieser Werte lässt sich folgender Zusammenhang schätzen:
Projektkosten = Anzahl Named User * CHF 20'000.Bei Betrachtung dieser Werte stellt sich zwangsläufig die Frage, wie sich die Anzahl
Named User ohne vorgängige Unternehmensanalyse bestimmen lässt. Natürlich ist die
empirische Ermittlung dieses Zusammenhangs eher fragwürdig, weil unternehmensspezifische Merkmale primär für die Bestimmung der Benutzerzahl verantwortlich sind.
Gleichwohl ergibt die Analyse der empirischen Daten insbesondere für den Industriesektor recht zuverlässige Werte. Dabei kann für eine durchschnittliche R/3-Installation
(6 Module) eine recht starke Abhängigkeit zwischen der Mitarbeiterzahl und der vorgesehenen Named-User-Zahl ermittelt werden. Im Industriesektor sind bei einer durch-
316
schnittlichen R/3-Installation (6 Module: FI, CO, AM, MM, HR, SD) im Endausbau rund
ein Drittel der Mitarbeiter Anwender des R/3-Systems. Bei branchenübergreifender Betrachtung lässt sich ein Anteilswert von durchschnittlich einem Fünftel ermitteln. Dieser
Wert ist allerdings ein eher unzuverlässiges Mass, da insbesondere im Handels- und
Dienstleistungssektor die Benutzerzahlen stark schwanken. Für den Industriesektor lässt
sich somit als grober Schätzwert der Anzahl Named User festhalten:
Named User Zahl Industrie , durchschnittliche R / 3− Installation =
Anzahl Mitarbeiter
3
Daraus ergibt sich beispielsweise für ein Unternehmen aus dem Industriesektor mit 300
Mitarbeitern mit einer durchschnittlichen R/3-Installation ein Projektvolumen von rund
CHF 2 Mio.
Bei der Ermittlung der Projektkosten stellt sich zusätzlich die Frage, welche Kosten durch
das veranschlagte Projektvolumen abgedeckt sind. Bei einer Analyse dieser Werte zeigt
sich, dass in vielen Projekten nur externe Kosten, d.h. durch Drittunternehmen verrechnete Lieferungen und Leistungen berücksichtigt wurden. Interne Kosten werden bei der
Bestimmung des Projektbudgets in der Regel nicht berücksichtigt.
Ein weiterer interessanter Aspekt ist das Verhältnis zwischen Softwarelizenzkosten und
Beratungs- resp. Einführungskosten. Die Gartner Group gibt in diesem Zusammenhang
Erfahrungswerte zwischen 1:2 bis 1:5 (in Extremfällen bis 1:15) an.304 In der vorliegenden Untersuchung konnten zwar in Einzelfällen ebenfalls Verhältniswerte von bis über
1:15 ermittelt werden. Insgesamt liegt das durchschnittliche Kostenverhältnis aber im
Bereich zwischen 1:2 und 1:4. Mit anderen Worten muss bei der Bestimmung des Projektvolumens auf diesem Weg mindestens der doppelte Betrag der Lizenzkosten für
Beratungsdienstleistungen resp. Einführungskosten veranschlagt werden.
Für die Bestimmung des Projektvolumens muss zusätzlich der Hardwarekostenanteil
bekannt sein. Dieser entspricht im Durchschnitt ungefähr den Lizenzkosten, so dass bei
ermittelten Lizenzkosten von CHF 500'000.- Einführungskosten von mindestens CHF
304
Keller et al. (1996); Stein (1997).
317
1.0 Mio und Hardwarekosten von rund CHF 500'000.- anfallen. Das sich daraus ergebende Projektvolumen von rund CHF 2.0 Mio entspricht ungefähr einer durchschnittlichen R/3-Installation im Industriesektor für 100 Named User. Bei grösseren Installationen (> 2'000 Named User) gelten diese Verhältniswerte durch die sich ergebenden
Skalenerträge nicht mehr.
Bei der Betrachtung dieser Verhältniszahlen wird deutlich, dass der Hauptanteil der Kosten durch die Einführungskosten verursacht werden und Einsparungen, da die anderen
Kostenblöcke (Lizenz- und Hardwarekosten) weitgehend konstant sind, sich am ehesten
in diesem Bereich realisieren lassen. Hauptverantwortlich für diesen relativ hohen Einführungskostensanteil ist sicherlich der Umfang und die damit verbundene Komplexität
des R/3-Systems. Bestrebungen der SAP AG durch den Einsatz von entsprechenden
Methoden und Softwareunterstützungswerkzeugen305 diesbezüglich eine Erleichterung
herbeizuführen sind seit einigen Jahren im Gang. Die SAP erhofft sich dadurch eine erhebliche Verkürzung des Einführungsprozesses.
Im Bereich der anderen Einflussgrössen wie z.B. der Grad der Vernetzung mit Umsystemen, die Wahl der Einführungsstrategie oder der geographischen Verteilung des R/3Systems (national/international, singlesite/multisite) lässt sich mit statistischen Methoden
für das vorliegende Datenmaterial keine Kostenwirkung nachweisen. In verschiedenen
Publikationen306 wird die Vermutung geäussert, dass auch diese Faktoren kostenwirksam
sind und deswegen bei der Ermittlung der Projektkosten mitberücksichtigt werden sollten.
6.2.3 Zeitbestimmende Faktoren
Bei der Bestimmung der Dauer einer R/3-Einführung muss grundsätzlich zwischen der in
Kalenderzeit und der in Personenmonaten gemessenen Projektdauer unterschieden
werden. Bei der Untersuchung der zeitbestimmenden Faktoren zeigt sich, dass die Einführungsdauer, ähnlich wie bei den Projektkosten, stark von der Named-User-Zahl ab-
305
306
Z.B. ASAP/Business Engineer; vgl. z.B. Bürkle (1997); Haendly (1997).
Vgl. Buxmann/König (1997); Keller et al. (1996), S. 12.
318
hängig ist. Die Zahl der eingeführten Module scheint keinen direkten Einfluss auf die
Projektdauer zu haben.
Bei einer detaillierten Analyse lässt sich eine starke Abhängigkeit zwischen der NamedUser-Zahl und den aufgewendeten Personenmonaten und nur eine geringe Abhängigkeit zwischen der Named-User-Zahl und der in Kalenderzeit gemessenen Projektdauer
feststellen. Eine Erklärung für diesen Unterschied mag die Tatsache sein, dass die Projektdauer in Kalenderzeit häufig durch exogene Grössen (z.B. Inkrafttreten gesetzlicher
Vorschriften, Beginn eines neuen Geschäftsjahres, Ablauf von Wartungsverträgen, Ablauf von Outsourcingverträgen) bestimmt wird. Die gesetzten Termine lassen sich durch
die Bereitstellung entsprechender personeller Ressourcen einhalten und dadurch besteht nur eine geringe Abhängigkeit zwischen der in Kalenderzeit und der in Personenmonaten gemessenen Projektdauer. Bei der Betrachtung des Zusammenhangs zwischen
der Named-User-Zahl und der Projektdauer in Personenmonaten lässt sich für ein R/3Projekt (6 Module) folgendes Verhältnis schätzen:
Projektdauer in Personenmonaten = 0.4 * Named User Zahl
Die empirisch ermittelten Werte zeigen sowohl bei branchenübergreifender Betrachtung (0.399) als auch im Industriesektor (0.372) bei nur geringen Standardabweichungen eine hohe Übereinstimmung. Wird nun der Kreis geschlossen und erfolgt die Ermittlung der Kosten für einen Personenmonat (inkl. Softwarelizenz- und Hardwarekosten), ergibt sich ein Wert von rund CHF 50'000.- (CHF 49'304.-, Standardabweichung
CHF 1'955.-).
Projektvolumen = 0.4 * Named User Zahl * CHF 50'000.−
Bei einem Projekt mit 100 Named User resultiert aus diesen Schätzungen ein Projektaufwand von rund 40 Personenmonaten und dies ergibt Projektkosten von ca. CHF
2 Mio. Eine Gegenüberstellung der im vorangehenden Unterkapitel ermittelten Werte
zeigt eine recht gute Übereinstimmung dieser Zahlen.
Für ein durchschnittliches R/3-Projekt für 150 Named User ergibt sich bei Kosten pro
Named User von CHF 20'000.- ein Projektvolumen von rund CHF 3.0 Mio. Gleichzei319
tig muss für dieses Projekt eine Dauer von rund 60 Personenmonaten veranschlagt werden. Bei durchschnittlichen Kosten von CHF 50'000.- pro Personenmonat resultiert
wiederum ein Betrag von CHF 3.0 Mio.
Die Bestimmung des Projektvolumens auf diesem Weg ist natürlich nur näherungsweise
gültig. Dabei sei noch einmal darauf hingewiesen, dass die dargelegten Berechnungen
vor allem für eine durchschnittliche R/3-Installation (6 Module: FI, CO, MM, AM, HR,
SD) im Industriesektor Gültigkeit haben. In den anderen Branchen variieren die Projektkosten stärker. Für eine seriöse Ermittlung der Projektkosten wird eine Unternehmung
aber kaum von einer detaillierten Analyse der Geschäftsprozesse und einer davon abgeleiteten Schätzung des Projektaufwandes absehen können.
6.3 Aktionsparameter
6.3.1 Übersicht
Neben den Bedingungsgrössen, welche primär die Dimensionen eines R/3-Projektes
abstecken, lässt sich die Erreichung der Projektziele durch unterschiedliche Steuergrössen (Aktionsparameter; kritische Erfolgsfaktoren) beeinflussen. Verschiedene Untersuchungen dieser erfolgsbeeinflussenden Faktoren haben gezeigt, dass vor allem Faktoren,
welche direkt mit dem Projektmanagement verbunden sind, für ein R/3-Projekt erfolgsentscheidend sein können (vgl. Abb. 6-3). Systemtechnischen Faktoren (z.B. Gestaltung
der Systemarchitektur) wurde im Rahmen dieser Untersuchungen keine kritische Bedeutung zugemessen. Im Bereich der projektmanagementbezogenen Steuergrössen liess
sich ferner feststellen, dass für die meisten dieser Faktoren bereits bei Projektbeginn
entscheidende Weichen gesetzt werden.
320
Detaillierung und
Realisierung
Inbetriebnahme
Auswahl der Beratungspartner
Projektorganisation
ProjektmanagementEbene
Organisation und
Konzeption
Projektleiter
Einbezug des Managements
Kommunikation
Business Process Reengineering
Systemtechnische
Ebene
Abb. 6-3: Kritische Erfolgsfaktoren bei der Einführung von SAP R/3.
In verschiedenen Untersuchungen in der Schweiz wurden rund 100 Projektverantwortliche zu deren Einschätzungen hinsichtlich der kritischen Erfolgsfaktoren bei der Einführung von SAP R/3 befragt.307 In der folgenden Darstellung wird versucht, die wichtigsten Wesensmerkmale dieser Faktoren zu umschreiben, um daraus konkrete Management-Empfehlungen ableiten zu können.
6.3.2 Projektorganisation
Die Grundsteine für den Projekterfolg werden bereits mit der Organisation des Projektes
gelegt. Wichtige Faktoren in diesem Zusammenhang sind die Wahl des Projektleiters
und der Berater, der Einbezug des Managements und die klare Formulierung der Zielsetzungen:
307
Vgl. Knolmayer/von Arb/Zimmerli (1997); Strebi (1996).
321
Wahl des richtigen Projektleiters
Dem Projektleiter wird eine entscheidende Rolle für den Verlauf eines R/3-Projektes
beigemessen.308 Er hat die Funktion einer "Drehscheibe" und ist gleichzeitig der
"taktgebende Motor" innerhalb eines Projektes. Aufgrund des Volumens von R/3Projekten (in der Regel liegt dieses zwischen CHF 2.0 und 7.5 Mio.), ist der Einsatz von
Personen mit Grossprojekterfahrung unbedingt empfehlenswert. Bei der Auswahl sind
Führungseigenschaften höher zu gewichten als fachliche Kompetenzen. R/3-Know-How
ist zwar wichtig, aber das Detailwissen muss aber vor allem auf der Ebene der Berater
und der Projektmitarbeiter vorhanden sein und im Bedarfsfall von diesen zur Verfügung
gestellt werden. Im Bereich des Know-hows sind Kenntnisse der eigenen Organisation
höher einzustufen als die System-Kenntnisse.
Unter Berücksichtigung der Probleme bei R/3-Einführungen ist es empfehlenswert, einen R/3-Projektleiter zu 100% für das Projekt freizustellen. Das gleiche gilt für die Projektmitarbeiter, welche zu mind. 50% freigestellt werden sollten. Freistellungsgrade unter 40% wirken sich projektbelastend aus. Bei der teilzeitlichen Freistellung eines Mitarbeiters für ein Projekt muss unbedingt darauf geachtet werden, dass eine entsprechende
Entlastung vom Tagesgeschäft stattfindet, damit die Projektaufgaben seriös wahrgenommen werden können.
Bei der Befragung zu den Eigenschaften eines Projektleiters wurden vor allem dessen
persönliche Merkmale in den Vordergrund gestellt. Wichtige Eigenschaften in diesem
Zusammenhang sind Kommunikationsfähigkeit, Motivationskraft und Durchsetzungsvermögen. In vielen R/3-Projekten wird von Kommunikationsproblemen, Motivationsdefiziten und Akzeptanzschwierigkeiten berichtet. Die Beeinflussung dieser Faktoren
hängt massgebend vom Projektleiter ab.
308
Vgl Kap. 4.4.3.
322
Wahl des geeigneten Beratungspartners
Die Auswahlmöglichkeiten am Markt für R/3-Beratungsdienstleistungen sind in den
letzten Jahren erheblich gestiegen. Neben fachlicher Kompetenz zu einzelnen Bereichen des R/3-Systems spielen bei der Beraterwahl auch Branchenkenntnisse eine wesentliche Rolle, denn R/3-Know-how kann in einem Unternehmen nur kombiniert mit
entsprechenden Branchenkenntnissen nutzbringend eingesetzt werden. Bei mangelnder
Erfahrung mit dem Management von Software-Projekten dieser Grössenordnung ist es
empfehlenswert, bei der Wahl der Berater ebenfalls auf das vorhandene Projektmanagement-Know-how und die methodischen Kenntnisse zu achten.
Bei der Betrachtung der Probleme im Bereich des Beratereinsatzes wird vor allem die
mangelnde Verfügbarkeit und das teilweise fehlende oder nicht mehr aktuelle R/3Know-how bemängelt. Bezüglich der fehlenden Verfügbarkeit kann sich der Kunde
durch entsprechende Verträge schützen, in welchen der Einsatz zeitlich, hinsichtlich des
Volumens und des notwendigen Know-hows klar geregelt ist. Probleme bezüglich fehlendem Wissen über neue Releasestände sind auf die hohe Auslastung der verfügbaren
Berater und die sich dadurch ergebende fehlende Zeit für die Weiterbildung zurückzuführen. Diesem Problem kann durch den ausschliesslichen Einsatz von Beratern, welche
für einen bestimmten Releasestand ein entsprechendes Zertifikat vorweisen können,
entgegengewirkt werden.
Häufig wird auch die Forderung nach Experten mit Überblick über weite Bereiche des
R/3-Systems laut. Angesichts der Komplexität und hohen Integration des R/3-Systems
muss fairerweise die Frage gestellt werden, inwiefern es für einen einzelnen Menschen
überhaupt möglich ist, einen umfassenden Überblick über dieses umfassende System zu
erhalten. Das durch die hohe Integration erforderliche Beziehungswissen setzt in dieser
Hinsicht klare Grenzen. Ein Berater kann sich in der Regel in einem Modul mit entsprechendem Beziehungswissen zu anderen Modulen auskennen. Gibt ein Berater an,
mehrere Module gleichzeitig zu beherrschen, sind entweder die Detailkenntnisse oder
das Beziehungswissen in Frage zu stellen.
323
Die Kosten für R/3-Beratungsdienstleistungen bewegen sich im Bereich von CHF
35'000-50'000.- pro Personenmonat (in Ausnahmefällen sogar noch höher). Aus diesem Grund muss eine sorgfältige Wahl getroffen und der Einsatz gründlich geplant werden. Bei der Betrachtung des Verhältnisses von Softwarelizenzkosten und Einführungskosten309 wird deutlich, dass im Bereich der Beratungskosten durch einen gezielten Einsatz dieser Ressourcen erhebliche Kosten eingespart werden können.
Einbezug des Managements
Ein R/3-Projekt muss vollumfänglich vom Management getragen werden und der Projektleiter muss sich in kritischen Situationen auf die Unterstützung des verantwortlichen
Managements verlassen können. Dies bedingt, dass auf Managementebene entsprechende Grundkenntnisse über das R/3-System und dessen Einsatzmöglichkeiten vorhanden sind. Durch Informationsverantstaltungen und Schulungen können in dieser
Hinsicht die Grundvoraussetzungen geschaffen werden.
Die direkte Verbindung zwischen Management und Projektteam kann durch Einsitz eines Geschäftsleitungsmitglieds im Projektsteuerungsausschuss gewährleistet werden.
Durch die gleichzeitige Delegation von entsprechenden Entscheidkompetenzen wird
dieses Gremium in die Lage versetzt, in kritischen Fragen rasch zu entscheiden. Dadurch wird einem Projekt die notwendige Schlagkraft verliehen und die Projektarbeit
gerät durch die Verzögerung von Entscheidungen nicht ins Stocken. Die klare Bekenntnis des verantwortlichen Managements für ein R/3-Projekt fördert gleichzeitig die Akzeptanz bei den betroffenen Mitarbeitern.
Die Gartner Group schätzt, dass in 15-20% der R/3-Projekte die vereinbarten Kostenund Terminziele um mehr als 25% überschritten wurden.310 In der in Kapitel 5 dargestellten empirischen Untersuchung konnten ebenfalls bei 77% der Einführungsprojekte
309
310
Vgl. Kap. 6.2.2.
Mirchandani/Dirigus (1996).
324
Zielabweichungen festgestellt werden. Diese Zahlen verdeutlichen die Problematik der
Formulierung von realistischen Projektzielen.
In der Einleitung zu diesem Kapitel wurden die verschiedenen Zieldimensionen (Sachziele, Terminziele, Kostenziele) dargestellt und durch Beispiele konkretisiert. Dabei gilt
bei der inhaltlichen Formulierung von Projektzielen zusätzlich zu beachten, dass verschiedene Grundprinzipien berücksichtigt werden müssen. Dies sind:
• Durch die Zielformulierung sollen keine möglichen Lösungen präjudiziert werden
(Lösungneutralität von Zielen).
• Ziele sollen operational formuliert sein (Ziele müssen einfach, verständlich und eindeutig messbar sein).
• Ziele sollen anspruchsvoll, aber erreichbar sein.
Im folgenden werden zwei Beispiele dargestellt, durch welche die Anwendung der
oben dargestellten Prinzipien verdeutlicht werden soll. Vorerst folgt eine Formulierung,
welche die oben genannte Prinzipien eindeutig verletzt und deswegen im Hinblick auf
eine gezielte Projektüberwachung ungeeignet ist:
Ziel dieses Projektes ist die möglichst optimale Einführung der R/3-Module FI, TR,
CO, IM und EC. Die Implementierung hat möglichst rasch und unter sparsamer Verwendung der verfügbaren finanziellen Ressourcen zu erfolgen.
Die Probleme dieser Zielformulierung liegen in Vorwegnahme der Problemlösung durch
die Festlegung der einzuführenden Module und in der nicht messbaren Formulierung
der Termin- und Kostenziele (...möglichst rasch und unter sparsamer Verwendung...).
Eine alternative Möglichkeit zur Formulierung eines generellen Projektziels unter Berücksichtigung der oben genannten Kriterien stellt die nachfolgend dargestellte Zielumschreibung dar:
Ziel dieses Projektes ist die informationstechnische Unterstützung der Geschäftsprozesse in den Bereichen Rechnungswesen und Controlling durch SAP R/3 gemäss beiliegendem Soll-Konzept. Die Produktivsetzung der Finanzbuchhaltung muss bis
1.1.19XX erfolgen und für die übrigen Anwendungsbereiche gilt der 1.7.19XX als
Stichtag. Die Projektkosten dürfen den Betrag von CHF 7.5 Mio nicht überschreiten.
325
Bei der Einführung ist der SAP-Standard massgebend. Harte Modifikationen des Systems sind, wenn immer möglich, zu vermeiden.
Diese eher allgemein gefasste Zielformulierung ist für die einzelnen Teilprojekte zu adaptieren und zu konkretisieren. Damit die Zielidentifikation bei grösseren Projekten
nicht verloren geht, ist es zwingend notwendig, ein formuliertes Fernziel in Zwischenziele zu unterteilen. Weit in der Ferne liegende Ziele erscheinen dem einzelnen unerreichbar und durch eine dadurch entstehende allgemeine Orientierungslosigkeit geht
die Motivation, auf ein vorgegebenes Endziel hinzuarbeiten, weitgehend verloren.
SAP-Projekten haftet im Bereich der Zielformulierung eine weitere Problematik an. Eine
präzise Formulierung der abzubildenden Prozesse ohne detaillierte R/3-Kenntnisse ist
schwierig. Das Gleiche gilt für die Abschätzung des zeitlichen und des finanziellen Aufwandes. Eine Zielformulierung, welche bei der Entscheidung für das R/3-System ohne
eine detaillierte Evaluation durchzuführen aufgestellt wurde, kann sich schon bald als
völlig unrealistisch erweisen. In solchen Fällen hat nach der ersten Projektphase unbedingt eine Anpassung der Zielsetzungen zu erfolgen, damit die Orientierungshilfe für die
Projektarbeit weiterhin erhalten bleibt. Die Zielformulierung im Rahmen eines R/3Projektes verhält sich somit wie ein iterativer Prozess. Es empfiehlt sich, vorerst Grobziele aufzustellen und diese in den einleitenden Projektphasen laufend zu verfeinern.
Zur laufenden Kontrolle der Zielsetzungen (Projektcontrolling) muss ein entsprechendes
Gremium eingesetzt werden. Diese Funktion kann entweder intern wahrgenommen
oder an eine externe Stelle übertragen werden. Oft ist eine Integration dieser Aufgabe in
den Steuerungsausschuss vorzufinden. In selteneren Fällen wird dafür ein separates
Gremium geschaffen. Die anfallenden Aufgaben richten sich grundsätzlich nach dem
Einführungsprozess (prozessfolgendes Projektcontrolling) und beinhalten die üblichen
Kontrollaktivitäten wie Kostenüberwachung, Projektfortschrittskontrolle und Qualitätssicherung.
326
6.3.3 Projektabwicklung
Als Grundlage für die Gestaltung der Projektabwicklung kann mit den in Kapitel 4 dargestellten Einschränkungen durchaus das SAP-Vorgehensmodell gewählt werden. Ergänzend dazu sind die nachfolgend dargestellten Aspekte bei der Einführung von SAP
R/3 besonders zu berücksichtigen.
Kommunikation
Eines der Hauptprobleme einer R/3-Einführung ist die fehlende Akzeptanz der Betroffenen. Ein perfekt funktionierendes und auf das entsprechende Unternehmen angepasstes
System an sich gewährt selbst noch lange nicht die erfolgreiche Nutzung von SAP R/3.
Widerstände bei den Betroffenen können alle Bemühungen lähmen. Gründe für diese
Widerstände sind primär in der Veränderung betrieblicher Abläufe und in der Umorientierung der Aufgaben in der Informatikabteilung zu suchen. Deshalb muss zur Förderung
der Akzeptanz bereits nach dem Entscheid für SAP R/3 mit der Aufklärungsarbeit begonnen werden. Im Rahmen dieser Tätigkeit sind folgende Aspekte zu berücksichtigen:
• Konsequente Einbeziehung der Anwender in das Projekt (Berücksichtigung von Änderungswünschen im Rahmen der Möglichkeiten von R/3)
• Ständige Information über den Projektstand und die weiteren geplanten Projektschritte
• Rechtzeitige und ausführliche Schulung der Anwender sowohl in systemtechnischer
als auch in betriebswirtschaftlicher Sicht.
Neben der Kommunikation mit den späteren Anwendern stellt aber auch die Kommunikation innerhalb des Projektes ein Problem dar. Die hohe Integration des R/3-Systems
erfordert eine ständige Abstimmung aller Projektaktivitäten, damit widersprüchliche
Einstellungen möglichst vermieden werden können. Bereits zu Beginn des Projekts sollten dazu die entsprechenden Kommunikationsmittel und -wege definiert und deren
Nutzung während des Projekts aktiv gefördert werden. Besonders geeignete Medien
sind Informationsveranstaltungen, Workshops, Info-Wände oder in beschränktem Masse auch E-Mail. Ferner ist die Einrichtung von Kommunikationszonen oder auch ge-
327
meinsamen Arbeitsräumen empfehlenswert, damit Koordinationsprobleme bilateral
besprochen werden können. Die aktive Kommunikation unterstützt die optimale Abstimmung der einzelnen R/3-Funktionen und verhindert Redundanzen im Bereich der
Projektarbeit.
Im direkten Zusammenhang mit der Förderung der Kommunikation während der Einführung von R/3 wird die Wichtigkeit der Anwenderschulung immer wieder in den Vordergrund gehoben.311 Akzeptanzprobleme sind häufig begründet durch fehlendes
Know-how der Anwender bei der Bedienung des neu eingeführten Systems. Fehleingaben reduzieren die Qualität der erfassten Daten und damit die Glaubwürdigkeit der
vom System zur Verfügung gestellten Informationen.
Diesem Problem kann durch eine rechtzeitige Schulung der Anwender entgegengewirkt
werden. Bei Bedarf muss zusätzlich ein Verständnis für die betriebswirtschaftlichen Inhalte (z.B. Anwendung von modernen Kostenrechnungsverfahren) geschaffen werden.
Mögliche Schulungsformen wurden in Kap. 5.4.7.2. behandelt. Dabei hat sich gezeigt,
dass der Frontalunterricht nach wie vor die häufigste Schulungsart ist. Im Bereich der
Schulungsinhalte wird ein vermehrtes Gewicht auf die Orientierung an durchgängigen
Prozessen gelegt. Dies fördert das Integrationsdenken und schafft ein besseres Verständnis für die zu erledigenden Aufgaben. Als Schulungssystem wird für die Endanwenderschulung meist ein betriebsindividuell angepasstes System mit Kopien von Echtdaten verwendet. Der Besuch von Standardschulungen bei SAP ist für Endbenutzer in
der Regel wenig sinnvoll, da in solchen Kursen die betriebsindividuellen Eigenheiten zu
wenig berücksichtigt werden können. Ein weiterer wichtiger Punkt ist die Wahl des
Schulungszeitpunktes. Wird die Anwenderschulung zu früh angesetzt, geht ein grosser
Teil des erworbenen Wissens vor dem Produktivstart wieder verloren. Deswegen sollte
der Schulungszeitpunkt unmittelbar vor dem Produktivstart angesetzt werden.
311
Vgl. Kapitel 5.4.4.10 und 5.4.7.2.
328
Business Process Reengineering
Im Bereich der Durchführung von Reengineering-Aktivitäten zusammen mit der Einführung von R/3 sind verschiedene Varianten denkbar. Grundsätzlich kann ein BPRProjekt durch eine R/3-Einführung ausgelöst werden (IT als Enabler). Im umgekehrten
Fall wird ein R/3-Projekt durch ein unabhängig davon durchgeführtes BPR-Projekt initiiert. Auf jeden Fall ist mit der Einführung von R/3 die Möglichkeit verbunden, die bestehenden Geschäftsprozesse zu überdenken und gegebenenfalls zu ändern. Wann ein
BPR-Projekt bei der Einführung eines neuen EMS durchgeführt werden soll, ist grundsätzlich umstritten. Es stehen die in Kap. 4.4.3. dargestellten Gestaltungsalternativen zur
Wahl (vgl. Abb. 6-4).
Sequentielle
Änderung der
Organisation und
von R/3
20 / 27
64
26
9
9
6
Simultane
Änderung der
Organisation und
von R/3
Automatisierung
9 / 40
20
58 / 86
93
1
Erklärung:
10
9
20 / 27
64
27 Befragte haben diese Variante bei
der Einführung von R/3 gewählt
20 Befragte würden ein zweites Mal
diese Variante wählen
64 Befragte würden sich insgesamt
ex-post für diese Variante entscheiden
1
2
Referenzmodell
2
7 / 26
12
Abb. 6-4: Reengineering-Varianten bei der Einführung von SAP R/3.312
312
Buxmann/König (1995), S. 166.
329
Die Gartner Group empfiehlt ihren Kunden, vor der R/3-Einführung ein Business Reengineering durchzuführen.313 Dies hat den Vorteil, dass die Umgestaltung der Geschäftsprozesse unabhängig von den Einschränkungen der IT quasi "auf der grünen Wiese" vorgenommen werden kann. Gleichzeitig ist die Alternative mit dem Nachteil verbunden,
dass sich die vorgedachten Prozesse mit dem ausgewählten System u.U. nicht implementieren lassen. Dies hat eine nachfolgende Anpassung einzelner Geschäftsprozesse
aufgrund der Einschränkungen des EMS zu Folge.
Bei einem simultan mit der R/3-Einführung durchgeführten Reengineering (häufigste
Variante) kann das im System vorhandene Know-how über die Abwicklung von Geschäftsprozessen (Best in Practice) vollumfänglich genutzt werden. Gleichzeitig entfällt
durch die gegenseitige Abstimmung die nachträgliche Anpassung einzelner Prozesse.
Die Einschränkungen des EMS hinsichtlich der Prozessgestaltungsmöglichkeiten können
sich allerdings negativ auf Optimierung von Geschäftsprozessen auswirken.
Auf ein Reengineering der Geschäftsprozesse wird nur in den wenigsten Fällen verzichtet. Viele Unternehmen, welche eine reine Automatisierung der Geschäftprozesse vorgenommen haben, würden ex-post diese Variante nicht mehr wählen und sich künftig
entweder für ein vorangehendes oder simultanes Reengineering entscheiden. In diesem
Sinne ist die Einführung eines EMS als Chance zu verstehen, bestehende Geschäftsprozesse zu überdenken und gegebenenfalls umzugestalten.
313
Mirchandani (1996).
330
6.3.4 Würdigung der kritischen Erfolgsfaktoren
Die im Abschnitt 6.3.3 dargestellten 7 Erfolgsfaktoren werden von einer Mehrheit der
R/3-Anwender als kritisch bezeichnet. Es sei noch einmal darauf hingewiesen, dass sich
alle Faktoren auf das Management von R/3-Projekten beziehen und systemtechnische
Aspekte eine geringere Bedeutung besitzen. In zeitlicher Hinsicht werden bei der Festlegung der Projektorganisation entscheidende Weichen für ein Projekt gelegt. Durch
eine seriöse Projektvorbereitung werden somit wichtige Voraussetzungen für den Projekterfolg und eine Reduktion des gesamten Projektaufwandes geschaffen (vgl. Abb.
5-14).
331
7 Zusammenfassung und Ausblick
7.1 Zusammenfassung
Enterprise-Management-Systeme (EMS) erfreuen sich in Unternehmungen verschiedener Branchen und Grössen zunehmender Beliebtheit. Diesem Markt werden weit über
die Jahrtausendwende hinweg Wachstumsraten von 30-40% prognostiziert. Gründe für
den vermehrten Einsatz von EMS sind vor allem veraltete Systemarchitekturen der bestehenden IS, die Möglichkeit der Nutzung einer gegenüber dem Ist-Zustand wesentlich
erweiterten Funktionalität, erhoffte Kosteneinsparungen sowie der Ersatz bestehender
Systeme aufgrund deren fehlender "Jahr 2000"-Fähigkeit zurückzuführen.
Die Einführung eines integrierten Systems ist kein einfaches Unterfangen, wie Kostenund Zeitüberschreitungen in vielen R/3-Projekten zeigen. Die Führung solcher Projekte
stellt hohe Anforderungen an das verantwortliche Management. Zur Problematik von
Einführungsprojekten existieren bisher nur wenige systematische Erfahrungssammlungen. Ausserdem waren die projektbestimmenden Rahmengrössen nur unzureichend
bekannt.
Mit der vorliegenden Arbeit wird das Ziel verfolgt, die verantwortlichen Entscheidungsträger für die mit einer EMS-Einführung verbundenen Nutzenpotentiale und Gefahren
zu sensibilisieren. Kapitel 2 widmete sich der Darstellung der Merkmale von EMS und
bietet eine Übersicht über die aktuell am Markt angebotenen Systeme. Während der
Darstellung des Evaluationsprozesses wurde ein Schwergewicht auf die Informationsbeschaffung im Umfeld von EMS gelegt. Die Wahl des R/3-Systems als Beispiel für die
anschliessende Untersuchung von EMS-Projekten lässt sich vor allem mit der hohen
Marktakzeptanz (Marktanteil in einzelnen Marktsegmenten von über 30%) und breiten
Anwendungsspektrum (Branchenübergreifende Einsatzbarkeit, Internationalität, Sprachen- und Währungsunabhängigkeit etc.) begründen.
Zur Veranschaulichung des Umfangs und der Komplexität wurden die Leistungsmerkmale und die Funktionalität des R/3-Systems in Kapitel 3 ausführlich dargestellt, weil ein
R/3-Projekt unzulässigerweise häufig mit der Einführung von Office-Paketen verglichen
333
wird. Dabei konnte gezeigt werden, dass praktisch das ganze betriebswirtschaftliche
Anwendungsspektrum (Rechnungswesen, Logistik und Personalwesen) durch R/3 abgedeckt werden kann. Ausserdem weist die vorhandene Client/Server-Architektur einen
hohen Flexibilitätsgrad auf und ermöglicht dadurch eine flexible Anpassung des Systems.
Kapitel 4 widmete sich der Darstellung des Einführungsprozesses. Dabei wurden verschiedene Typen von Vorgehensmodellen (sequentielle Vorgehensmodelle, Wasserfallmodelle und Spiralmodelle) miteinander verglichen und Vor- und Nachteile diskutiert.
Im Anschluss daran folgte die Darstellung des SAP-Vorgehensmodells, welches in der
Schweiz in mehr als 50% der R/3-Projekte als methodische Basis eingesetzt wird. Dabei
lässt sich feststellen, dass bei der Anwendung dieses Vorgehensmodells einige Einschränkungen zu beachten sind.
Das SAP-Vorgehensmodell vernachlässigt den Evaluationsprozess: seine Aktivitäten setzen erst nach dem Entscheid für R/3 an. Dadurch entstehen viele Doppelspurigkeiten
und die vorhandenen Ergebnisse aus dem Evaluationsprozess bleiben beim vorgeschlagenen Vorgehen weitgehend unberücksichtigt. Ein weiteres Manko bezieht sich auf die
fehlende Integration von BPR-Aktivitäten, welche in den meisten Fällen direkt mit der
Einführung gekoppelt sind. Viele Beratungsunternehmen haben dieses Defizit erkannt
und bieten eigene Vorgehensmodelle an, welche möglichen BPR-Massnahmen besser
Rechnung tragen. Ein weiterer Nachteil des SAP-Vorgehensmodells bezieht sich auf die
ungenügende Berücksichtigung von Projektmanagement-Aktivitäten. Schwächen bei
Einführungsprojekten sind häufig auf ungenügende Kenntnisse der Anwender und Berater im diesem Bereich zurückzuführen.
Zur Ermittlung der kritischen Erfolgsgrössen wurden im zweiten Teil dieses Kapitels in
Anlehnung an den Einführungsprozess mögliche Erfolgsfaktoren skizziert. Durch Expertengespräche unter Anwendung der Delphi-Methode erfolgte eine Bewertung dieser
Faktoren. Dabei zeigte sich deutlich die bereits erwähnte Gewichtung. Die Bedeutung
von projektmanagementbezogenen Faktoren wurde deutlich in den Vordergrund gehoben, während systemtechnische Faktoren eher als zweitrangig beurteilt wurden.
334
In Kapitel 5 wurde auf der Basis der in der Literatur gewonnenen Erkenntnisse und der
Ergebnisse der Expertenbefragung ein konzeptioneller Bezugsrahmen (Begriffs- und Hypothesenschema) als Grundlage für die Durchführung einer quantitativen Untersuchung
zu Erfahrungen bei der Einführung von R/3 aufgestellt. Anhand der dabei ermittelten
Einflussgrössen wurden Vorschläge für die Bestimmung des Projektvolumens und des
zeitlichen Aufwandes abgeleitet. Die von R/3-Anwendern als kritisch befundenen Erfolgsfaktoren dienten zur Formulierung von Handlungsempfehlungen für die erfolgreiche Abwicklung von Einführungsprojekten. Die empirische Untersuchung brachte folgende Haupterkenntnisse zutage:
R/3 wird praktisch in allen Branchen und in sehr unterschiedlich grossen Unternehmungen (4 - 50'000 Mitarbeiter) eingesetzt. Hinsichtlich der Unternehmensgrösse lassen sich
bei der Art des R/3-Einsatzes kaum Unterschiede feststellen. Hingegen unterscheidet
sich im branchenübergreifenden Vergleich die Einsatzbreite (Anzahl eingesetzter Module) im Dienstleistungssektor aus naheliegenden Gründen von der Einsatzbreite des
R/3-Systems in den übrigen Branchen.
Bei der Untersuchung der Kosten und des Zeitbedarfs von R/3-Projekten konnten starke
Abhängigkeiten zwischen der vorgesehenen Benutzerzahl und den finanziellen bzw.
zeitlichen Aufwendungen ermittelt werden. Im Bereich der Kosten verursacht ein Benutzer Gesamtaufwendungen (Software-, Hardware- und Einführungskosten) von rund
CHF 20'000.-. Dieser Wert gilt allerdings nicht für sehr kleine (weniger als 30 Benutzer)
und sehr grosse R/3-Installationen (mehr als 2'000 Benutzer). Die Zahl der eingesetzten
Module beeinflusst die Einführungskosten nur geringfügig. Verantwortlich dafür ist der
eher homogene Einsatz des R/3-Systems. Durchschnittlich werden 6 R/3 Module (meist
FI, CO, MM, AM, HR, SD) verwendet. Für die zeitliche Dauer von R/3-Projekten in
Personenmonaten liess sich aus den empirischen Daten ebenfalls eine Schätzgrösse ermitteln. Pro Benutzer muss mit einem zeitlichen Aufwand von 0.4 Personenmonaten
gerechnet werden. Aufgrund der errechneten Gesamtdauer in Projektmonaten lässt sich
die Zahl der Projektmitarbeiter abschätzen. Besonders zuverlässige Werte ergeben die
genannten Schätzgrössen im Industriesektor. In den anderen Sektoren (z.B. Dienstlei-
335
stungssektor) ist die Vergleichbarkeit der Projekte aufgrund der sehr unterschiedlichen
Anforderungen eher fraglich. Obwohl sich anhand der dargestellten Werte das Projektvolumen und der zeitliche Aufwand einer R/3-Einführung grob bestimmen lässt, kann
dadurch eine individuelle Aufwandschätzung nicht ersetzt werden. Die ermittelten
Werte sind als Näherungsgrössen zu verstehen.
Die ermittelten Hauptprobleme bei R/3-Projekten bezogen sich auf fehlende Akzeptanz, unzureichende Freistellung der Projektmitarbeiter, Koordinationsprobleme, Komplexität des R/3-Systems und fehlende Verfügbarkeit qualifizierter Berater.
In direktem Zusammenhang zu den erwähnten Problemen steht die Gewichtung der
kritischen Erfolgsfaktoren. Besonders in den Vordergrund gehoben wurden die Faktoren
Auswahl des Beratungspartners, Projektleiterwahl, Einbezug des Managements, klare
Fomulierung der Zielsetzungen, Kommunikation, Anwenderschulung und BPR.
Bei der Auswahl von Beratungspartnern spielen Kriterien wie ausgewiesenes R/3-Knowhow für den aktuellen Releasestand, Branchen- und Projektmanagement-Kenntnisse
eine massgebende Rolle.
Der Projektleiter hat innerhalb des Projektes eine Kernfunktion inne. Die Anforderungen an seine Person beziehen sich stärker auf persönliche Eigenschaften (Durchsetzungsvermögen, Motivationskraft und Kommunikationsfähigkeit). Betont werden
auch die Erfahrung mit Grossprojekten und die Kenntnisse der eigenen Organisation.
Durch den Einbezug des Managements wird dem R/3-Projekt die notwendige Durchschlagskraft verliehen. Wichtige Entscheide können dadurch sofort gefällt werden und
gleichzeitig führt die aktive Beteiligung zu einer Erhöhung der Akzeptanz.
Durch klare formulierte Zielsetzungen wird die "Marschrichtung" bestimmt und die Zusammenarbeit der beteiligten Personen geregelt. Probleme bei der realistischen Zielformulierung können auf Anhieb durch einen iterativen Zielfindungsprozess entschärft
werden.
Zur Förderung der Akzeptanz und der Reduzierung von Koordinationsproblemen muss
die Kommunikation mit allen Beteiligten ständig gepflegt werden. Eine offene Informa-
336
tionspolitik und klar geregelte Kommunikationsbeziehungen schaffen die dafür benötigten Grundlagen.
Eine gleich hohe Bedeutung nimmt die seriöse Vorbereitung und Durchführung der
Anwenderschulung ein. Durch eine schlechte Anwenderausbildung erhöht sich die Gefahr von Fehleingaben und dadurch vermindert sich die Datenqualität. Konsequenz ist
ein Vertrauensverlust in Aussagekraft und Korrektheit der vom System zur Verfügung
gestellten Daten und damit verbunden eine Erhöhung der Akzeptanzprobleme.
Die Einführung eines EMS hat in den meisten Fällen organisatorische Änderungen zur
Folge. Ein dazu notwendiges Reengineering der Geschäftsprozesse muss mit der Einführung des EMS koordiniert werden. Häufig wird zu diesem Zweck entweder eine vorgängige oder eine simultane Umgestaltung der Geschäftsprozesse empfohlen.
Durch die konsequente Berücksichtigung der dargestellten Erfolgsfaktoren können R/3Projekte zielgerichteter abgewickelt und latent vorhandene Probleme bereits im Keim
erstickt werden. Die Probleme mit der Komplexität des R/3-Systems lassen sich durch
Berücksichtigung dieser Faktoren zwar beeinflussen, können aber grundsätzlich nicht als
gelöst betrachtet werden. Zur Bewältigung dieses Problems muss auch die SAP AG zusätzliche Anstrengungen für mehr Transparenz und eine Vereinfachung des Einführungsprozesses unternehmen.
337
7.2 Ausblick
Die Beherrschbarkeit von integrierten betriebswirtschaftlichen Anwendungssystemen
wird durch die Forderung nach universeller Einsetzbarkeit zunehmend in Frage gestellt.
Im Unterschied zur Entwicklung von Individualsoftware wurde zwar mit der Einführung
von EMS in dieser Hinsicht eine quantensprungartige Verbesserung erreicht. Die Komplexität ist immer noch relativ hoch. Durch verschiedene, teilweise noch unausgereifte
Ansätze wird versucht, die Grenzen des Machbaren immer weiter nach oben zu schieben.
• Seit einigen Jahren wird versucht, das Customizing von EMS durch den Einsatz von
entsprechenden Tools zu vereinfachen.314 Mittels Fragenkatalog werden die Bedürfnisse des Anwenders ermittelt. Ein integriertes Regelwerk versucht anhand der angegebenen Informationen die optimale Systemeinstellung zu finden. Das Problem dieses Ansatzes ist die schwere Voraussehbarkeit der Wirkungszusammenhänge der vorhandenen Einstellgrössen (z.B. Konfigurationsmöglichkeiten eines PPS-Systems). Diese müssten für einen praxistauglichen Einsatz vollumfänglich bekannt sein. Gleichzeitig besteht das Problem, dass das Regelwerk für jeden neuen Release wieder angepasst werden muss. Bei einfacheren Einstellungen (z.B. Abbildung der Organisationsstruktur) ist eine Verwirklichung dieses Ansatzes mit Hilfe von regelbasierten
Werkzeugen durchaus praktikabel und auch bereits teilweise umgesetzt (vgl.
ASAP315).
314
315
Vgl. Hartinger (1995), S. 51 ff.; Mertens/Wedel/Hartinger (1991), S. 569 ff.
Vgl. Bürkle (1997).
338
• Eine weitere Möglichkeit zur Reduktion der Einführungszeit ist der Einsatz von kundenspezifisch voreingestellten Systemen (configure to order).316 Der Kunde sieht nur
die für ihn relevanten Bereiche und kann sich dadurch bei der Einführung auf das
Wesentliche konzentrieren. Der Vorteil dieser Methode liegt sicherlich auf der Kundenseite. Das Problem besteht aber darin, ein neues System sachgerecht kundenspezifisch einzustellen. Durch die Verwendung der Systemeinstellungen eines ähnlichen
Anwendungsfalls lassen sich gewisse Synergien ausnutzen. Aber grundsätzlich sieht
sich der Softwarehersteller mit sich ähnelnden Problemen (Releasewechselproblematik) konfrontiert wie beim toolbasierten Ansatz. Eine Vereinfachung könnte
durch die Isolation von einzelnen Geschäftsprozessen erreicht werden. Für jeden Geschäftsprozess existieren vorkonfigurierte Varianten und im Bedarfsfall wird ein Anwendungssystem nach dem Component-Ware-Prinzip zusammengesetzt. Durch die
starke Integration der einzelnen Anwendungsbereiche scheint auch mit diesem Ansatz vorläufig kein bahnbrechender Erfolg zu realisieren sein, weil die Problematik
der Integration der Komponenten besteht.
• In einem weiteren Ansatz wird die Idee verfolgt, betriebwirtschaftliche Anwendungsobjekte verschiedener Hersteller über das Netz zu integrieren (Network Business
Objects).317 Voraussetzungen dafür sind eine konsequente Kapselung der einzelnen
Objekte und die Standardisierung der Schnittstellen (z.B. CORBA). Der Anwender
könnte exakt auf seine Bedürfnisse abgestimmte Business Objekte auf dem Markt
erwerben und frei miteinander kombinieren. Der Konfigurationsaufwand könnte
durch massgeschneiderte Prozesse erheblich reduziert werden. Insgesamt betrachtet
erscheint dieser Ansatz plausibel. SAP verfolgt mit der Entwicklung ihres Business
Frameworks eine ähnliche Stossrichtung. Nachteile dieses Konzepts sind Probleme
mit der Standardisierung der Schnittstellen und die Probleme der einfachen Systemintegration.
316
317
Vgl. SAP AG (1997b).
Vgl. Shepard (1995).
339
Allen Konzepten ist eines gemeinsam: Es wird auf einfache Weise versucht, den Einsatz
von Informationssystemen auf der betriebswirtschaftlichen Anwendungsplattform zu
vereinfachen und damit eine Kostenreduktion und kürzere Einführungszeiten zu bewirken. Die geforderten Sachziele, die Steuerung des Leistungserstellungsprozesses und die
rasche Bereitstellung von entscheidungsrelevanten Informationen, bleiben immer die
gleichen. Der erforderliche Anpassungsaufwand bei einer Veränderung der Anforderungen muss weiter reduziert werden, damit mit den Marktveränderungen Schritt gehalten
werden kann. Lösungsansätze für die Reduktion der Komplexität integrierter Systeme
sind in der tool-basierten Einführungsunterstützung und in der Desintegration der einzelnen Anwendungsbereiche zu suchen.
***
340
Literaturverzeichnis
Literatur
Adler, G., Standardsoftware: Sackgasse oder Innovation, in: Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 1: Managemententscheidungen, Hallbergmoos: AIT 1990, S. 161-177.
AFOS, SAP, Arbeit, Management - Durch systematische Gestaltung zum Projekterfolg, Braunschweig/Wiesbaden: Vieweg 1996.
ASAP World Consultancy, Blain, J., Special Edition Using SAP R/3: The Most Complete Reference,
2. Aufl., Indianapolis: Que (1997).
Atteslander, P., Methoden der empirischen Sozialforschung, 8. Aufl., Berlin/New York: de Gruyter
1995.
Balmer, K., Mirchandini, V., Implementing Packaged Applications: The 13 Project Planning Steps, in:
Gartner Analytics o.J. (1996) 3, Report Nr. 29089 (www. gartner.com).
Barbitsch, Ch., Einführung integrierter Standardsoftware - Handbuch für eine leistungsfähige Unternehmensorganisation, München/Wien: Hanser 1996.
Bartels, U., Siebeck, C., SAP-Ausbildung im Wandel, in: Wenzel, P. (Hrsg), Geschäftsprozessoptimierung mit SAP R/3 - Modellierung, Steuerung und Management betriebwirtschaflticheintegrierter Geschäftsprozesse, Braunschweig/Wiesbaden: Vieweg 1996, S. 290-314.
Bartholomew, D., SAP Plans Net Version Of R/3 - Application package intended to run on corporate
intranets, in: Information Week, o.J. (1996a) 572, S. 22 f.
Bea, F. X., Dichtl, E., Schweitzer, M., Allgemeine Betriebswirtschaftslehre, Band 2: Führung, 5. Aufl.,
Stuttgart/Jena/New York: Fischer 1991.
Blankensberger, S., SYSTAT für Windows: Eine Einführung, Stuttgart/Jena/New York: Fischer 1994.
Bleymüller, J., Gehlert, G., Gülicher, H., Statistik für Wirtschaftswissenschaftler, 10. Aufl., München:
Vahlen 1996.
Blume, A., SAP Projektkompass: Arbeitsorientierte Planungshilfen für die erfolgreiche Einführung von
SAP-Software, Braunschweig/Wiesbaden: Vieweg 1997.
Boehm, B. W., A Spiral Model of Software Development and Enhancement, in: IEEE Computer 21
(1988) 5, S. 61-72.
341
Boll, M., Einführung von Standardsoftware aus der Sicht des Anbieters, in: Schweizer InformatikerGesellschaft (Hrsg.), Software Engineering beim Einsatz von Standardsoftware, Proceedings
der Fachtagung anlässlich der Gründung der Fachgruppe Software-Engineering in der
Schweizer Informatiker-Gesellschaft, Universität Zürich 1994.
Boll, M., Optimale R/3-Einführung, in: SAPPHIRE '96, Vienna (SAP VISUAL CD ROM), Walldorf: SAP
AG 1996.
Böndel, B., SAP - Wie Lemminge, in: Wirtschaftswoche 49 (1995) 12, S. 108-118.
Bortz, J., Döring, N., Forschungsmethoden und Evaluation, 2. Aufl., Berlin et al.: Spinger 1995.
Bortz, J., Lehrbuch der empirischen Forschung für Sozialwissenschaftler, unter Mitarbeit von Bonders,
D., Berlin et al.: Springer 1984.
Brenner, W., Auswahl von Standardsoftware, in: Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2: Auswahl, Einführung und
Betrieb von Standardsoftware, Hallbergmoos: AIT 1990, S. 9-24.
Brenner, W., Keller, G. (Hrsg.), Business Reenginering mit Standardsoftware, Frankfurt/New York:
Campus 1995.
Buck-Emden, R., Galimow, J., Die Client/Server-Technologie des Systems R/3 - Basis für betriebswirtschaftliche Standardanwendungen, Bonn et al.: Addison-Wesley 1995.
Bürkle, U., AcceleratedSAP (ASAP): Gesammeltes Know-how, in: SAP Info E&T, o.J. ( 1997) 54, S.
13-14.
Busin, R. A., Activity Based Value Chain Management in Industrieunternehmen, Proceedings zur Tagung
"SAP Solutions '96", Zürich 1996.
Buxmann, P., König, W., Empirische Ergebnisse zum Einsatz der betrieblichen Standardsoftware SAP
R/3, in: Wirtschaftsinformatik 39 (1997) 4, S. 331-338.
Buxmann, P., König, W., Organisationsgestaltung bei der Einführung von betrieblicher Standardsoftware, in: Management & Computer 4 (1996) 3, S. 161-168.
Buxmann, P., Lampe, R., Trautwein, J., Analysis and "Optimization" of Corporate Business Processes in
SAP R/3 Implementation Projects, Empirische Untersuchung des Instituts für Wirtschaftsinformatik der Johann Wolfgang Goethe-Universität und Gemini Consulting,
Frankfurt und Bad Homburg 1996.
Cameron, B. et al., Packaged Application Strategies - The Prudent Approach To R/3, 1 (1996) 1, Cambrigde: Forrester Research 1996.
342
CDI (Hrsg.), SAP R/3 Einführung - Grundlagen, Anwendungen, Bedienung, Haar bei München: Markt
& Technik 1996b.
CDI (Hrsg.), SAP R/3 Materialwirtschaft - Grundlagen, Anwendungen, Fallbeispiele, Haar bei München:
Markt & Technik 1996a.
Chen, J., Geitner, U., PPS-Marktübersicht 1993: 129 Standardsoftware-Produkte im Vergleich, in Fortschrittliche Betriebsführung und Industrial Engineering, 42 (1993) 2, S. 52.
Chen, P. P., The Entity-Relationship Model - Towards a Unified View of Data, in: ACM Transactions on
Database Systems 1 (1976) 1, S. 9-36.
Codd, E. F., The Relational Model for Database Management (Version 2), Reading et al.: AddisonWesley 1990.
Daniel, D. R., Management Information Crisis, in: Harvard Business Review, Sept.-Oct. 1961,
S. 111-121.
Davenport, T. H., Stoddard, D. B., Reengineering: Business Change of Mythic Proportions? In: MIS
Quarterly 18 (1994) 2, S. 121-127.
De Marco, T., Structured Analysis and Systems Specifications, New York: Yourdon Press 1978.
Diekmann, A., Empirische Sozialforschung: Grundlagen, Methoden, Anwendungen, Reinbek b. Hamburg: Rowohlt 1995.
Dodd, J., Developing Information Systems from Components: The Role of CASE, in: Spurr, K., et al.,
Business Objects: Software Solutions, Chichester et al.: Wiley 1994, S. 3-22.
Eberlein, E., Koopmann, F., Okroy, M., SAP: Die Kontroverse setzt sich fort, in: Business Computing o.J.
(1995) 6, S. 6-12.
Elmasri, R., Navathe, S. B., Fundamentals of Database Systems, 2. Aufl., Reading: Addison-Wesley
1994.
Engels, A., Gresch, J., Nottenkämpfer, M., SAP R/3 kompakt - Einführung und Arbeitsbuch für die Praxis, München: tewi 1996.
Flury, B., Möglichkeiten und Grenzen des Einsatzes von Windows NT als Basissystem von SAP R/3, Arbeitsbericht Nr. 85 des Instituts für Wirtschaftsinformatik, Abteilung Information Engineering, Bern 1996.
Franken, S., Jörgensen, N. H., Projektausschnitte Integration SAP R/3 - Planung und Konzeption für
Schulung (Aus-, Fort- und Weiterbildung), in: Wenzel, P. (Hrsg), Geschäftsprozessoptimierung mit SAP R/3 - Modellierung, Steuerung und Management betriebwirtschaflticheintegrierter Geschäftsprozesse, Braunschweig/Wiesbaden: Vieweg 1996, S. 315-337.
343
Fritz, F.-J., Zuck, W., Flexibles Prozessmanagement mit SAP Business Workflow, in: SAPinfo Special Continuous Business Engineering, Zeitschrift 1996, S. 63-66.
Froitzheim, U., Geniales Puzzle, in: Wirtschaftswoche 48 (1994) 42, S. 188.
Füglistaler, U., Technische Integrations von Standardsoftware, in: Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2, Hallbergmoos: AIT 1990, S. 153-168.
Füller, E., Thomae, K., Entscheidung für Standardsoftware: am Beispiel der Firma Dr. Karl Thomae
GmbH, in: Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den
Einsatz von Softwarepaketen, Band 1: Managemententscheidungen, Hallbergmoos: AIT
1990, S. 37-54.
Gantenbein, R., Aufgabenverteilung zwischen Fach- und Informatikabteilung bei Auswahl, Einsatz und
Betrieb von Standardsoftware, in: Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2: Auswahl, Einführung und
Betrieb von Standardsoftware, Hallbergmoos: AIT 1990, S. 75-92.
George, R., Who's Buying ERP? What Applications?, in: The Report on Manufacturing, o.J. (1996) 5,
Boston: AMR 1996.
Gerber, J.-P., Knolmayer, G., Informationsbeschaffung zu Softwareprodukten aus Newsgruppen am
Beispiel von SAP R/3, in: Wirtschaftsinformatik 38 (1996) 6, S. 633-638.
Goetzner, T., Sommerfeld, B., Inhouse-Schulung im Krankenhaus, in: Computerwoche 22 (1995) 26, S.
48.
Grochla, E., Grundlagen der organisatorischen Gestaltung, Stuttgart: Poeschel 1982.
Gronau, N., Management von Produktion und Logistik mit SAP R/3, München/Wien: Oldenbourg 1996.
Groth, R., et al., Projektmanagement in Mittelbetrieben, Planung und Durchführung einmaliger grosser
Vorhaben, Köln: Deutscher Instituts-Verlag 1983.
Grupp, B., EDV-Projekte in den Griff bekommen: Arbeitstechniken des Projektleiters; Planungs- und
Überwachungsmethoden; Zusammenarbeit mit der Fachabteilung, Köln: TÜV Rheinland
1987.
Gschwend, N., SAP R/3 - Das Grösste, auch für die "Kleinen" !?, Referat an der SAP Solutions, Zürich,
12.-14. März 1996.
Haendly, M., R/3 Simplification Group (1997 Overview), in Proceedings zur Tagung "Technologie Forum '97", Karlsruhe 1997.
344
Hammer, M., Champy, J., Reengineering the Coorporation: A Manifesto for Business Revolution, New
York: Harper Collins 1994.
Hammer, M., Stanton S. A., The Reengineering Revolution: A Handbook, New York: HarperCollins
1995.
Hantusch, T., Matzke, B., Pérez, M., SAP R/3 im Internet: Globale Plattform für Handel Vertrieb und
Informationsmanagement, Bonn et al.: Addison-Wesley 1997.
Hartinger, M., Die Pflege der Paramenter von Standardsoftware: Effizienter Einsatz des PPS-Systems
IBM-CIMAPPS, Wiesbaden: Gabler 1995.
Heinrich, L. J., Roithmayr, F., Wirtschaftsinformatik-Lexikon, 5. Aufl., München/Wien: Oldenbourg
1995.
Hernández, J. A., The SAP R/3 Handbook, New York et al.: McGraw-Hill (1997).
Hiekel, H.-U., Organisation ist auf die Software abzustimmen, in: Computerwoche 21 (1994) 17,
S. 43-44.
Horváth, P., Petsch, M., Weihe, M., Standard-Anwendungssoftware für die Finanzbuchhaltung und die
Kosten- und Leistungsrechnung: Auswahlkriterien, Marktübersicht, Leistungsprofile von
Softwareprodukten, München: Vahlen 1983.
Hufgard, A., Wirtschaftliche R/3-Einführung im Mittelstand - Einsatzmöglichkeiten von Methoden und
Tools, in: Wenzel, P. (Hrsg.), Geschäftsprozessoptimierung mit SAP R/3: Modellierung,
Steuerung und Management betriebswirtschaftlich-integrierter Geschäftsprozesse, Braunschweig/Wiesbaden: Vieweg 1995, S. 44-82.
Hüttenhain, T., Managementregeln zur Einführung von Standardsoftware, in: Österle, H. (Hrsg), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepakten, Band 1,
Hallbergmoos: AIT 1990, S.131-146.
Igler, M., Einigkeit macht Partner stark: Microsoft und SAP präsentieren sich gemeinsam, in: NT &
BackOffice Magazin, o.J. (1997) 3, S. 19-23.
Igler, M., Leistungsschub in Sicht: R/3 auf NT weiter im Aufwind, in: NT & BackOffice Magazin, o.J.
(1996) November/Dezember, S. 14-15.
IMG (Hrsg.), PROMET-SSW: Methodenhandbuch, Version 2.0, St. Gallen/München: IMG 1997.
Keller, E. et al., SAP: Hope of the Future or Legacy of the Past?, in: Gartner Analytics o.J. (1996) 6,
Report Nr. 30264 (www. gartner.com).
Keller, E., The Four R's of ERP, in: Gartner Analytics o.J. (1995) 11, Report Nr. 27050 (www. gartner.com).
345
Keller, G., Teufel, T., SAP R/3 prozessorientiert anwenden: Iteratives Prozess-Prototyping zur Bildung
von Wertschöpfungsketten, Bonn et al.: Addison Wesley 1997.
Kengelbacher, K., Konzeptionelle Integration von Standardsoftware, in: Österle, H. (Hrsg.), Integrierte
Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2, Hallbergmoos: AIT 1990, S.141-152.
Kirchmer, M., Geschäftsprozessorientierte Einführung von Standardsoftware: Vorgehen zur Realisierung
strategischer Ziele, Wiesbaden: Gabler 1996.
Knolmayer, G., Buchberger, G., Management of Temporally Anchored Hypertext Information, Arbeitsbericht 102, Institut für Wirtschaftsinformatik der Universität Bern 1997.
Knolmayer, G., Das Jahr-2000-Problem: Medien-Spektakel oder Gefährdung der Funktionsfähigkeit des
Wirtschaftssystems?, in: Wirtschaftsinformatik 39 (1997) 1, S. 7-18.
Knolmayer, G., Die Auslagerung von Servicefunktionen als Strategie des IS-Managements, in: Heinrich,
L.J., Pomberger, G., Schauer, R. (Hrsg.), Die Informationswirtschaft im Unternehmen, Linz:
Trauner 1991, S. 323-341.
Knolmayer, G., Informationsbeschaffung zu SAP-Produkten und deren Umfeld auf dem Internet: Die
Anbieterseite, in: Wirtschaftsinformatik 38 (1996a) 1, S. 87-93.
Knolmayer, G., Informationsbeschaffung zu SAP-Produkten und deren Umfeld auf dem Internet: Informationen von Anwendern, Online-Zeitschriften und Informations-Diensten, in: Wirtschaftsinformatik 38 (1996b) 2, S. 230-233.
Knolmayer, G., Kritische Erfolgsfaktoren einer erfolgreichen Einführung integrierter Anwendungssoftware, in: 1. Schweizer I.I.R. SAP-Forum'95, Luzern 1995a.
Knolmayer, G., Portner, R., von Arb, R., Erfahrungen mit der Einführung von SAP R/3 in Schweizer
Unternehmungen, Studie der Abteilung Information Engineering des Instituts für Wirtschaftsinformatik der Universität Bern, 1995.
Knolmayer, G., R/3-Projekte in der Schweiz, in: Business Computing, o.J. (1995b) 7, S. 66 - 67.
Knolmayer, G., SAP-Produkte und deren Umfeld im Internet: Wer bietet was?, in: Wirtschaftsinformatik
38 (1996c) 1, S. 87-93.
Knolmayer, G., Ein Konzept für einen verteilten, mehrstufig organisierten Benutzersupport, in: Wirtschaftsinformatik 32(1990) 2, S. 150-160.
Knolmayer, G., von Arb, R., Portner, R., Erfahrungen bei der Einführung von SAP R/3, in: Output 24
(1995) 2, S. 38 - 41.
346
Knolmayer, G., von Arb, R., Zimmerli, C., Erfahrungen mit der Einführung von SAP R/3 in Schweizer
Unternehmungen, Studie der Abteilung Information Engineering des Instituts für Wirtschaftsinformatik der Universität Bern, 1997.
Kölle, J., Projektmanagement bei der Einführung von Standardsoftware dargestellt am Beispiel von PPS,
in: Österle, H. (Hrsg), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz
von Softwarepakten, Band 2, Hallbergmoos: AIT 1990, S. 45-54.
Kupper, H., Zur Kunst der Projektsteuerung: Qualifikation und Aufgaben eines Projektleiters bei DVAnwendungsentwicklungen, München/Wien: Oldenbourg 1988.
Lehner, F., et al., Organisationslehre für Wirtschaftinformatiker, München/Wien: Hanser 1991.
Litke, Hans-D., Projektmanagement - Methoden, Techniken, Verhaltensweisen, 3. Aufl., München,
Wien: Hanser 1995.
Losbichler, B., Einsatz von Standardsoftware versus Softwareengineering, in: Österle, H. (Hrsg.), Anleitung zu einer praxisorientierten Software-Entwicklungsumgebung, Band 1: Erfolgsfaktoren
werkzeugunterstützter Software-Entwicklung, Hallbergmoos: AIT 1988, S. 87-99.
Ludewig, J., Standardsoftware: Grundlagen, Chancen, Risiken, in: Schweizer Informatiker-Gesellschaft
(Hrsg.), Software-Engineering beim Einsatz von Standardsoftware, Proceedings zur Fachtagung anlässlich der Gründung der Fachgruppe Software-Engineering in der Schweizer Informatiker-Gesellschaft, Universität Zürich 1994.
Marca, D. A., McGowan, C. L., SADT- Structured Analysis and Design Technique, New York et al.:
McGraw- Hill 1988.
Marchand, R., Rechtliche Aspekte bei der Einführung von betriebswirtschaftlicher Standardsoftware am
Beispiel von R/3, Lizentiatsarbeit am Institut für Wirtschaftsinformatik, Abteilung Information Engineering, Bern 1996.
McKendrick, J., A once in a century crisis: How is MIS preparing for converting dates to the Year 2000,
in: MIDRANGE Systems 8 (1995) 12, S. 17-18.
Meinhart, S., Teufel, T., Business Reengineering im Rahmen einer prozessorientierten Einführung der
SAP-Standardsoftware R/3, in: Brenner, W., Keller, G. (Hrsg.), Business Reengineering mit
Standardsoftware, Frankfurt/New York: Campus 1995, S. 69-94
Meister, C., Customizing von Standardsoftware, in: Österle, H. (Hrsg), Integrierte Standardsoftware:
Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2, Hallbergmoos: AIT
1990, S. 25-44.
347
Mende, U., Softwareentwicklung für R/3: Data Dictionary, ABAP/4, Schnittstellen, Berlin et al.: Springer
1998.
Mertens, P. et al. (Hrsg.), Lexikon der Wirtschaftsinformatik, 2. Aufl., Berlin et al.: Springer 1990.
Mertens, P., Knolmayer, G., Organisation der Informationsverarbeitung, 2. Aufl., Wiesbaden: Gabler
1995.
Mertens, P., Wedel, T., Hartinger, M., Management by Parameters?, in: Zeitschrift für Betriebswirtschaft 61 (1991) 5/6, S. 569-588.
Mirchandani, V., Dirigus, B., Implementing SAP R/3: Avoid Becoming a Statistic, in: Gartner Analytics
o.J. (1996) 5, Report Nr. 29850 (www. gartner.com).
Mirchandani, V., SAP R/3 Implementations: First Wave Experiences, in: Gartner Analytics o.J. (1996) 9,
Report Nr. 31576 (www. gartner.com).
Möhle S. et al., Dezentrale Produktionsplanungs- und -steuerungs-Experten: Kombination wissensbasierter Ansätze mit ComponentWare, in: Information Managment 11 (1996) 1, S. 30-37.
NN, Anwendern bereitet die R/3-Einführung viel Kummer, in: Computerwoche 23 (1996b) 12, S. 7-10.
NN, Hopp erteilt Spekulationen um inkompatibles R/4 eine Absage, in: Computerwoche 23 (1996a) 17,
S. 4.
Nomina Information Services, ISIS PC Report : ISIS PC Report : Software für PC & PC-Netzwerke,
Firmenprofile; Deutschland, Oesterreich, Schweiz; Branchen-Programme, Technische
Programme [ ... ], Bd. 2, München: Nomina 1995d.
Nomina Information Services, ISIS PC Report : Software für Personal Computer & PC-Netzwerke,
Firmenportraits ; Deutschland, Oesterreich, Schweiz, Bd. 1.1 und 1.2, München: Nomina
1995c.
Nomina Information Services, ISIS Software Report: Software für Minicomputer & Mainframes;
Deutschland, Oesterreich, Schweiz - Bd. 1.1: Kommerzielle Programme, München: Nomina 1995a.
Nomina Information Services, ISIS Software Report: Software für Minicomputer & Mainframes;
Deutschland, Oesterreich, Schweiz - Bd. 2.1: Branchenprogramme, München: Nomina
1995b.
Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 1: Managemententscheidungen, Hallbergmoos: AIT 1990a.
348
Österle, H. (Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 2: Auswahl, Einführung und Betrieb von Standardsoftware, Hallbergmoos: AIT
1990b.
Österle, H., Business Engineering: Prozess- und Systementwicklung. Band 1: Entwurfstechniken, 2.
Aufl., Berlin et al.: Springer 1995.
Petri, C. A., Kommunikation mit Automaten (Diss.), Bonn 1962.
Pomberger, G., Blaschek, G., Software Engineering, 2. Aufl., München: Hanser 1996.
Robb, J. M., et al., Computing Strategy Service, in: The Forrester Report 13 (1995) 2.
Rockart, J. F., Chief executives define their own data needs, in: Harvard Business Review 57 (1979) 2,
S. 81-93.
Roggenkemper, H., Internet-enabled R/3, in: SAP AG (Hrsg.), The SAP Technical Developers Conference, Orlando, May 1996.
Röthig, P., Peters, G., Thom, N., Bürokommunikation erfolgreich einführen: Ein Leitfaden, Wuppertaler
Kreis e. V. Deutsche Vereinigung zur Förderung der Weiterbildung von Führungskräften
(Hrsg.), Köln: Deutscher Instituts-Verlag 1987.
Rumbaugh, J., et al., Object Oriented Modeling and Design, Englewood Cliffs: Prentice Hall 1991.
Sachs, L., Angewandte Statistik: Anwendung statistischer Methoden, 7. Aufl., Berlin et al.: Springer
1992.
SAP AG (Hrsg.), Business Engineer - Dynamische R/3-Einführung und Anpassung (SAP Visual CeBit '97),
Walldorf: SAP AG 1997b.
SAP AG (Hrsg.), Geschäftsbericht 1995, Walldorf: SAP AG, 1996d.
SAP AG (Hrsg.), R/3 System Release 3.0D - Online Documentation (SAP CD-ROM), Walldorf: SAP AG
1996a.
SAP AG (Hrsg.), SAP R/3 System 3.1 - The Foundation for Genuine Business on the Internet (White
Paper), Walldorf: SAP AG 1996b.
SAP AG (Hrsg.), System R/3 - Controlling Grundlagen und Gemeinkostenrechnung, Funktionen im Detail, Walldorf: SAP AG 1993a.
SAP AG (Hrsg.), System R/3 - Das Business Framework (White Paper), Walldorf: SAP AG 1996e.
SAP AG (Hrsg.), System R/3 - Die Personalwirtschaft der SAP, Funktionen im Detail, Walldorf: SAP AG
1993c.
349
SAP AG (Hrsg.), System R/3 - Materialwirtschaft, Funktionen im Detail, Walldorf: SAP AG 1993b.
SAP AG (Hrsg.), System R/3 - Plant Maintenance, Functions in Detail, Walldorf: SAP AG 1996c.
SAP AG (Hrsg.), System R/3 - Produktionsplanung - Prozessindustrie, Funktionen im Detail, Walldorf:
SAP AG 1995a.
SAP AG (Hrsg.), System R/3 - Produktionsplanung, Funktionen im Detail, Walldorf: SAP AG 1994a.
SAP AG (Hrsg.), System R/3 - Projekt System, Funktionen im Detail, Walldorf: SAP AG 1994b.
SAP AG (Hrsg.), System R/3 - SAP Basis Technologie: Grundlage für moderne Client/Server-Lösungen,
Walldorf: SAP AG 1996c.
SAP AG (Hrsg.), System R/3 - SAP Business Workflow, Funktionen im Detail, Walldorf: SAP AG 1995b.
SAP AG (Hrsg.), The Java-Enabled R/3 3.1 - SAP's Extended Internet Technology (White Paper), Walldorf: SAP AG 1997a.
Scheer, A.-W., Berkau, C., Kraemer, W., CIM: Eigenentwicklung oder Standardsoftware, in: Österle, H.
(Hrsg.), Integrierte Standardsoftware: Entscheidungshilfen für den Einsatz von Softwarepaketen, Band 1: Managemententscheidungen, Hallbergmoos: AIT 1990, S. 79-106.
Scheer, A.-W., Jost, W., Geschäftsprozessmodellierung innerhalb einer Unternehmensarchitektur, in:
Vossen, G., Becker, J., (Hrsg.), Geschäftsprozessmodellierung und Workflow-Management:
Modelle, Methoden, Werkzeuge, Bonn et al.: Thomson 1995.
Scheer, A.-W., Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse, Berlin et al.:
Springer 1995.
Schmidt, G., Methoden und Techniken der Organisation, Giessen: Schmidt 1991.
Schroeder, G., Configure to order using the R/3 Business Engineer, in: Proceedings zu Tagung
"SAPPHIRE '97", Amsterdam 1997.
Shepard, J., Life after ERP: The Next Generation of Business Systems, in: The Report on Manufacturing
o.J. (1995) 19 (www.advmfg.com).
Shepard, J., The ERP Goldrush: Can It Continue?, in: The Report on Manufacturing o.J. (1996) 10
(www.advmfg.com).
Sinzig, W., Konzern-Controlling, in: SAP Visual, SAPPHIRE '96 (CD-ROM), Vienna, Walldorf: SAP AG
1996.
Stahlknecht, P., Einführung in die Wirtschaftsinformatik, 7. Aufl., Berlin et al.: Springer 1995.
Stein, T., Fast Deployment - New tools make implementation of client-server suites easier, less costly, in:
Information Week o.J. (1997) 616.
350
Stevens, W.P., Myers, G.J., Constantine, L.L., Structured Design, in: IBM Systems Journal 13 (1973) 2,
S. 115-139.
Strebi, S., Kritische Erfolgsfaktoren bei der Einführung von SAP R/3, Arbeitsbericht Nr. 91 des Instituts
für Wirtschaftsinformatik, Abteilung Information Engineering, Bern 1996.
Sturm, B., Anwenderschulung - wieviel Aus- und Weiterbildung verlangen immer komplexere Anwendungen, in: Computerwoche 22 (1995) 24, S. 43-45.
Thome, R., Hufgard, A., Continous System Engineering: Entdeckung der Standardsoftware als Organisator, Würzburg: Vogel 1996.
Udell, J., ComponentWare, in: Byte, 19 (1994) 5, S. 28.
Vaske, H., SAP-Vorstand Zencke sieht keine Versäumnisse: Scheitern an der Mittelstandsversion eingeräumt, in: Computerwoche 23 (1996) 23, S. 7, 10.
Vaske, H., Topmanager kümmern sich nur am Rande um SAP-Projekte, in: Computerwoche 23 (1996)
12, S. 7-10.
von Arb, R., Vorgehensweisen und Erfahrungen bei der Einführung von R/3, in: Computerworld Spezial
o.J. (1995) 34, S. A14 - A23.
von Arb, R., Stebler, R., Projektrisiken und Erfahrungen bei der Einführung von SAP R/3, in: Proceedings
zur Tagung "SAP und Sicherheit", Zürich und Frankfurt 1996, S. 6-44.
Walter, M., Vorgehensweise und Erfahrungen bei der Datumsumstellung im SAP System R/2, in: Wirtschaftsinformatik 39 (1997) 1, S. 19-24.
Weber, D., Lean Implementation - Ein Muss, in: Output Spezial, Sonderausgabe vom 18. Juli 1994,
S. 56-58.
Wenzel, P. (Hrsg.), Betriebswirtschaftliche Anwendungen des integrierten Systems SAP-R/3, Braunschweig/Wiesbaden: Vieweg 1995a.
Wenzel, P. (Hrsg.), Geschäftsprozessoptimierung mit SAP R/3 - Modellierung, Steuerung und Management betriebswirtschaftlich-integrierter Geschäftsprozesse, Braunschweig/Wiesbaden: Vieweg 1995b.
Wiborny, W., Datenmodellierung, CASE-Management, Bonn et al.: Addison Wesley 1991.
Zencke, P., Softwareunterstützung im Business Process Reengineering, in: Scheer, A.-W. (Hrsg.), Prozessorientierte Unternehmensmodellierung, Schriften zur Unternehmensführung, Band 53,
Wiesbaden: Gabler 1994, S. 63-76.
351
Anhang A
Anhang A : Erfolgsfaktoren
Erfolgsfaktor
Anwender (1. Runde)
Rangpunkte
Rang
104
10
Projektleiter
63
1
93
6
97
7
68
2
BPR
129
13
Projektorganisation
100
9
Kommunikation
72
3
Know-how-Transfer
91
4
Change-Management
97
7
163
19
130
14
146
18
Datenmigration
111
11
133
15
Lenkungsausschuss
136
16
92
5
Dokumentation
111
11
199
21
187
20
Release-Planung
141
17
Anwender (2. Runde)
Rangpunkte
Rang
62
3
52
1
83
6
105
9
74
4
114
11
85
7
60
2
90
8
82
5
163
19
126
12
161
18
154
16
142
15
137
13
108
10
140
14
201
21
186
20
156
17
Berater (1. Runde)
Rangpunkte
Rang
24
1
49
2
69
7
54
3
63
5
55
4
68
6
77
9
70
8
85
10
113
12
110
11
113
12
113
12
117
16
123
17
114
15
123
17
158
19
160
21
158
19
Berater (2. Runde)
Rangpunkte
Rang
36
1
39
2
55
3
60
4
63
5
63
5
72
7
83
8
85
9
90
10
106
11
107
12
107
12
112
14
120
15
120
15
124
17
128
18
148
19
159
20
161
21
Detailauswertung der kritischen Erfolgsfaktoren
353
Anhang B
Anhang B : Fragebogen der Umfrage vom Juli 1996
A. Unternehmensprofil
A1. Wieviele Mitarbeiter beschäftigt Ihre Unternehmung derzeit insgesamt?
q Weiss nicht
q Weiss nicht
ca. .................... MA
Wieviele davon sind in der Informatik beschäftigt?
ca. .................... MA
Wie änderte sich die Mitarbeiterzahl in der Informatik infolge Einführung des R/3-Systems?
Zunahme um ......................... MA
q Weiss nicht
Abnahme um ......................... MA
A2. Welchen Jahresumsatz erwirtschaftete Ihre Unternehmung im letzten Geschäftsjahr?
q
ca. ............ Mio CHF.
q Weiss nicht
Umsatzzahlen werden nicht bekanntgegeben
q Weiss nicht
A3. In welcher/n Branche/n ist die Unternehmung tätig?
q
q
q
q
q
q
q
q
Automobil
Banken
Baugewerbe
Beratung
Chemie
Computer
Detailhandel
Elektizität, Wasser
q
q
q
q
q
q
q
q
Elektrotechnik
Finanzdienstleistungen
Handel
Holz, Papier
Landwirtschaft
Maschinenindustrie
Mineralölindustrie
Möbel
q
q
q
q
q
q
q
q
q
Nahrungsmittel
Öffentliche Verwaltung q
q
q
q
q
q
q
Pharma
Software
Spital
Stahlproduktion
Telekommunikation
Textilindustrie
Tourismus
Transport, Verkehr
Unterhaltungselektronik
Versicherung
Werbung/Marketing
Ü brige Dienstleistungen
Übrige Industrie
Andere:.........................
A4. In welchen Organisationseinheiten der Schweiz wurde/wird das R/3-System in Ihrer Unternehmung eingeführt
resp. in Zukunft ausgebaut?
q Weiss nicht
Organisationseinheiten
Konzernweit
Unabhängig in mehreren Unternehmungen des Konzerns
Unternehmungsweit
In einzelnen Unternehmungsbereichen
Andere: ..............................................................................
bisher/derzeit
in Zukunft
q
q
q
q
q
q
q
q
q
q
B. Projektstand
B1. Wieviele R/3-Projekte laufen derzeit in Ihrem Unternehmen?
................. Projekt(e).
B2. In welcher Phase befindet sich das am weitesten fortgeschrittene R/3 Projekt?
q in Planung
q in Durchführung
q abgeschlossen
C. Evaluationsprozess und Produktentscheid
C1. Bewerten Sie bitte die nachfolgend aufgelisteten auslösenden Faktoren für die Evaluation des neuen Systems.
Skala: 1=sehr wichtig, 2=wichtig, 3=geringe Bedeutung, 4=unbedeutend, 5=völlig irrelevant
Verändertes Wettbewerbsumfeld
1
Deregulierung von Märkten
q q q q q
q q q q q
q q q q q
Globalisierung von Märkten
Veränderte Konkurrenzsituation
2
3
4
5
Zu teure bisherige DV-Infrastruktur
Probleme mit Insellösungen
L ö s u n g d e s „ J a h r 2 0 0 0 “-Problems
Andere wichtige Faktoren:...................
1
Preisverfall der Hardware
q q q q q
q q q q q
Verfügbarkeit neuer Technologien
(Client/Server, grafische
Benutzeroberflächen, Integration)
2
3
4
5
Vorteile von Standardsoftware
”Altlasten”
Veraltete bisherige DV-Infrastruktur
Verändertes technisches Umfeld
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
Einsparung von Entwicklungs- und
Wartungskosten
q q q q q
Erweiterte Funktionalität
q q q q q
q q q q q
q q q q q
Förderung interner Reorganisationen
Schnelle Verfügbarkeit
.............................................................
355
Anhang B
C2. Haben Sie im Rahmen der Evaluation von SAP R/3 eine Vor- bzw. Machbarkeitsstudie durchgeführt?
q Ja
q Nein
q Weiss nicht
C3. Haben Sie zur Formulierung der Zielsetzungen des Projektes ein Pflichtenheft bzw. eine Leistungsbeschreibung erstellt? Welchen Umfang hatte diese, wie gross war der Zeitaufwand für die Erstellung und an wieviele
Anbieter wurde es versandt?
Umfang ca. .......... Seiten,
Zeitaufwand ca. .......... Std.,
versandt an ca. ......... Anbieter.
q Kein Pflichtenheft erstellt
q Weiss nicht
C4. Für wieviele und für welche Softwareprodukte führten Sie zusammen mit SAP R/3 eine Endausscheidung in
der Evaluation durch?
q Weiss nicht
Für .................. (Anzahl) Konkurrenzprodukte.
Dabei handelte es sich um folgende Produkte (Name des Herstellers, Produktname):
(z.B. Baan, Triton) ..................................................................................................................
................................................................................................................................................
C5. Bewerten Sie bitte die nachfolgend aufgelisteten Argumente , die den Entscheid für SAP R/3 beeinflussen
können.
Allgemeine Argumente
1
2
3
4
5
R/3-spezifische Argumente
1
2
3
4
5
Kundennähe durch leistungsfähige
Informatik
q q q q q
Abdeckung der betriebswirtschaftl.
Anforderungen
q q q q q
W irtschaftlichkeitsüberlegungen
q
q
q
q
Abbildbarkeit existierender
Geschäftsprozesse
q q q q q
Hoher Integrationsgrad der einzelnen
Module
q q q q q
Grafische Benutzeroberfläche (GUI)
q
q
q
q
q
q
q
q
q
q
Eigene Erfahrungen mit SAP R/2
Druck von Kunden/Lieferanten
Empfehlungen aus anderen
Unternehmungen
Integration von Microsoft-Produkten
Anderes: .............................................
Anderes: .............................................
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q q q q q
q q q q q
q q q q q
Performance, Geschwindigkeit
Bestechender Gesamteindruck
Flexibler Einsatz (Anpassungsfähigkeit)
Sprach- und Währungsunabhängigkeit
SAP-spezifische Argumente
Marktstellung/-position der SAP AG
Potential für Weiterentwicklungen
Internationale Ausrichtung
Anderes: .............................................
Offenheit der Systemarchitektur
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
Integrierte Entwicklungsumgebung
Vorgehensmodell/Einführungsleitfaden
Offenes Unternehmensdatenmodell
Anderes: ..............................................
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
C6. Welche der folgenden R/3 Module führ(t)en Sie in Ihrer Unternehmung ein (oder planen deren Einführung)?
Bitte vergeben Sie Nummern für die Reihenfolge der Moduleinführung (Gleichzeitig eingeführte Modulblöcke
bitte mit derselben Nummer kennzeichnen).
....... FI
(Finanzwesen)
....... SD
(Vertrieb)
....... CO (Controlling)
....... MM (Materialwirtschaft)
....... AM (Anlagenwirtschaft)
....... PP
(Produktionsplanung)
....... PS
(Projektsystem)
....... QA
(Qualitätssicherung)
....... OC (Office & Communication)
....... PM
(Instandhaltung)
....... IS
....... HR (Personalwirtschaft)
(Branchenlösungen)
q Einführung sämtlicher Module in einem einzigen Projekt (Big Bang)
q Weiss nicht
C7. Wieviele Personenmonate haben Sie für die gesamte Evaluation aufgewendet?
ca. ...............................Personenmonate.
356
q Weiss nicht
Anhang B
D . P r o j e k t m a n a g e m e n t - Projektorganisation
D1. Wer ist für die Einführung von R/3 in Ihrer Unternehmung verantwortlich ? Bitte unterscheiden Sie nach der
Verantwortung für das Gesamtprojekt und der Verantwortung für Teilprojekte.
Abteilung
Verantwortlich für das Verantwortlich für Teilprojekte
Gesamtprojekt
(z.B. Einführung FI)
q
q
q
q
Andere: ......................................................
q
q
q
q
q
q
Andere: ......................................................
q
q
Geschäftsleitung
Abteilung Informatik
Zuständige Fachabteilung(en)
Externe Berater
q Weiss nicht
D2. Aus wievielen Projektgruppen bestand die Projektorganisation zur Einführung von SAP R/3?
q Weiss nicht
................................ (Anzahl) Projektgruppen
D3. Bestand in Ihrem Projekt eine Koordinationseinrichtung , wie z.B. ein Projektlenkungs- bzw. -steuerungsausschuss? Wenn ja, wie setzte sich diese zusammen (Bitte ungefähre Anzahl Personen angeben).
q Ja, bestehend aus:
q Nein
q Weiss nicht
....... Geschäftsleitung
....... Betroffene Fachbereiche
....... Abteilung Informatik
....... Controlling
....... Organisationsabteilung
....... Externe(r) Berater
....... Andere: .............................................................................................................
D4. Wie setzt(e) sich eine typische Projektgruppe zusammen? Geben Sie bitte die Anzahl eingesetzter Personen
und deren angestammtes Aufgabengebiet an.
q Weiss nicht
....... aus der Abteilung Informatik
....... Externer Berater
....... aus den zuständigen Fachabteilungen
....... Andere, aus: ......................................................
....... Andere, aus: ......................................................
....... Andere, aus: ......................................................
D5. Aus welchem der oben genannten Funktionsbereiche stammt(e) der Projektleiter ? Zu welchem Prozentsatz
war dieser für das Projekt freigestellt ?
q Externer Projektleiter
Abteilung: ...................................................................
q Weiss nicht
Freistellung: ............................%
D6. Welche Eigenschaften sollte ein R/3-Projektleiter Ihres Erachtens mitbringen?
1
gute allg. EDV-Kenntnisse
gute R/3-Kenntnisse
gute Kenntnisse der eigenen
Organisation
2
3
4
5
q q q q q
q q q q q
q q q q q
q q q q q
q q q q q
andere: ........................................... q q q q q
q Weiss nicht
1
Entscheidungskraft,
Durchsetzungsvermögen
andere: ...........................................
2
3
4
5
q q q q q
q q q q q
q q q q q
q q q q q
q q q q q
q q q q q
D7. Mit welchen Problemen ist ein Projektleiter in einem R/3-Projekt hauptsächlich konfrontiert?
a) ....................................................................................................................................
b) ....................................................................................................................................
c) ....................................................................................................................................
q Weiss nicht
D8. Wie stufen Sie die Unterstützung des Projektleiters durch das Management ein?
q Sehr gut
q gut
q genügend
q unbefriedigend
q Weiss nicht
D9. Welches war die geplante Dauer des Projektes ( Kalenderzeit und Arbeitszeit )?
Gibt es beim aktuellen Projektstand Abweichungen zum Plan?
Kalenderzeit
Arbeitszeit
Geplante Dauer :
.......... Monate
.......... Personenmonate
q Abweichung:
.......... Monate
.......... Personenmonate
q Keine Abweichung
q Weiss nicht
q Weiss nicht
357
Anhang B
D10. Wieviele Personen sind im Einführungsprojekt SAP R/3 beschäftigt? Bitte geben Sie die Mitarbeiterzahl (MA)
pro Projektphase (nach SAP) unterschieden nach Vollzeit- und Teilzeitbeschäftigung im Projekt an. Schätzen
Sie bitte zusätzlich den durchschnittlichen Mitwirkungsgrad für die Teilzeitmitarbeiter.
q Weiss nicht
Vollzeit
Teilzeit
∅ Projekt-Mitwirkungsgrad
Organisation und Konzeption
........... MA
............ MA
............ %
Detaillierung und Realisierung
........... MA
............ MA
............ %
........... MA
............ MA
............ %
Produktionsanlauf
........... MA
............ MA
............ %
SAP-Einführungsphase
q Weiss nicht
D11. Wie hoch ist Ihr Budget zur Einführung von SAP R/3?
q Budgetzahlen werden nicht bekanntgegeben
ca. ........................................CHF.
Dieses Budget teilt sich prozentual grob wie folgt auf:
Hardwarekosten
........... %
Einführungskosten
............%
Softwarekosten
........... %
Schulungskosten
............%
D12. Welche der folgenden typischen Problembereiche , die in Informatikprojekten auftreten können, waren bei
Ihrer Einführung von SAP R/3 kritisch ? (Mehrfachnennungen möglich)
q
q
q
q
q
q
q
q
Komplexität des R/3-Systems
Unrealistische Zeitstrukturen
Unvollständige/unpräzise Aufgabenstellung
Vertragliche Probleme
q Budgetüberschreitung
q Unzureichende Ausbildung der Mitarbeiter
Terminüberschreitung(en)
Fehlende Mitwirkung der Anwender
Widerstände gegen die Veränderung von
Geschäftsprozessen
q Unzureichender Support durch den Anbieter
q Unzureichende Unterstützung durch das Mgmt
q Fehlende Verfügbarkeit qualifizierter Berater
q Andere: ..............................................................
q Häufiger Releasewechsel
q Unterschätzung von Hardware-Anforderungen
q Andere: ..............................................................
..............................................................
..............................................................
..............................................................
q Keine kritischen Situationen
q Weiss nicht
E . P r o j e k t m a n a g e m e n t - Erfolgsfaktoren
E1. Bewerten Sie bitte die nachfolgend aufgelisteten 21 Kritischen Erfolgsfaktoren bei der Einführung von
Standardsoftware.
Change-Management
Datenmigration
Dokumentation
Know-how-Transfer
Kommunikation
1
2
3
4
5
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
L e n k u n g s a u s s c h u s s (steering committee)
Projektleiter
Projektorganisation
Releaseplanung
Schulung der Benutzer
Überdenken bzw. Neugestaltung der
Geschäftsprozesse (BPR)
Verbindung zu existierenden Informationssystemen
1
2
3
4
5
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q
q q q q q
q q q q q
E2. Klar formulierte Zielsetzungen tragen wesentlich zum Projekterfolg bei.
Welche Ziele haben Sie für Ihr(e) Projekt(e) formuliert? Wie beurteilen Sie die Zielabweichungen ?
Ziele
Kostenziele
Terminziele
Sachziele
358
eingehalten
übertroffen
nicht eingehalten
q
q
q
q
q
q
q
q
q
Grund:
......................................
......................................
......................................
q Weiss nicht
q Weiss nicht
q Weiss nicht
Anhang B
q Weiss nicht
E3. Wie wurden/werden die Ziele überwacht?
..................................................................................................................................................................................
q Weiss nicht
E4. Welches war/ist die Reaktion auf das Erkennen von Zielabweichungen?
q Neuformulierung der Ziele q geringe Anpassung der Ziele
q keine Anpassung der Ziele, sondern: .......
..................................................................................................................................................................................
F . P r o j e k t m a n a g e m e n t - Vorgehensmodell
F1. Haben Sie bei der Einführung von SAP R/3 ein Vorgehensmodell verwendet?
Falls ja, welches ?
q SAP-Vorgehensmodell (IMG)
q anderes: ....................................................................................................
q Nein
q Weiss nicht
F2. Haben Sie Aufgaben in der Einführung von SAP R/3 mit Softwarewerkzeugen unterstützt?
q Ja
q Nein
q Weiss nicht
Falls ja , nennen Sie bitte pro Projektphase den N a m e n und die Anbieter der Software-Tools (z.B. ARISToolset, MS-Project).
Projektphase
Name des Tools
Anbieter
.....................................................
.......................................................
.....................................................
.....................................................
.......................................................
.....................................................
.....................................................
.......................................................
.....................................................
.....................................................
.......................................................
.....................................................
G . P r o j e k t m a n a g e m e n t - Einsatz externer Berater
G1. Haben Sie bei der Einführung von SAP R/3 mit externen Beratungsunternehmungen zusammengearbeitet?
q Ja, mit folgender(n) Beratungsunternehmung(en): .........................................
q Nein
q Weiss nicht
.......................................................................................................................
.......................................................................................................................
G2. Welches waren die wichtigsten Gründe für eine Zusammenarbeit mit externen Beratern?
a) ....................................................................................................................................
b) ....................................................................................................................................
c) ....................................................................................................................................
q Weiss nicht
G3. Wie beurteilen Sie die Kenntnisse/Fähigkeiten der Berater?
sehr gut
gut
schlecht
sehr
schlecht
q
q
q
q
q
q
q
q
q
q
q
q
Im Projektmanagement
Von Methoden und Werkzeugen
In SAP R/3
q Weiss nicht
q Weiss nicht
q Weiss nicht
Bemerkungen: .........................................................................................................................................................
..................................................................................................................................................................................
H. Systemtechnische Veränderungen
H1. Welche systemtechnische Architektur wies Ihre Unternehmung bzw. Ihr Unternehmungsbereich vor der
Einführung von SAP R/3 auf ?
q Host(s)
q Abteilungsrechner (AS/400 usw.)
q PC-Netzwerk
Anzahl: .................................
q Weiss nicht
Anzahl: .................................
Anzahl Server: .....................
359
Anhang B
H2. Bezeichnen Sie bitte Ihre für R/3 eingesetzten Systemkomponenten :
q identisch
Datenserver und Applikationsserver sind
q nicht identisch
q Oracle q MS SQL Server q Informix q Adabas D q DB/2 q SQL/400
q Andere: ....................................................................................................................
q Unix: ............................................. (z.B. AIX)
q Windows NT
q OS/400
q Andere: ....................................................................................................................
q Windows 95 (3.1) q Windows NT
q OSF-Motif
q OS/2
q Macintosh
q Andere: ....................................................................................................................
Datenbank :
Betriebssystem :
GUI :
H3. Wieviele Datenbankserver sind in Ihrem Unternehmen installiert?
q Weiss nicht
........... Rechner.
H4. Wieviele Applikationsserver sind in lhrem Unternehmen installiert?
q Weiss nicht
........... Rechner.
H5. Wieviele Rechner auf Präsentationsebene sind in Ihrem Unternehmen installiert?
q Weiss nicht
........... Rechner.
H6. Welche Produkte von Fremdanbietern werden/wurden in Ihrem Unternehmen an das R/3-System angebunden?
q Office-Applikationen
q CAD-Anwendungen
q Archivierungssystem
q Weiss nicht
q andere: .................................................................................................
.................................................................................................
H7. Welche Softwarekategorie wird in Ihrer Systemumgebung durch SAP R/3 ersetzt ?
q Weiss nicht
SAP R/3
q
q ersetzt in erster Linie eigenerstellte
ist Ersatz für SAP R/2
q
q ersetzt in erster Linie durch Softwarehäuser
Individualsoftware
q
ersetzt in erster Linie andere
Standardsoftwarepakete
als Ergänzung zu SAP R/2
erstellte Individualsoftware
q
SAP R/3 ersetzt ..........................................
....................................................................
....................................................................
H8. W ieviele User haben derzeit resp. werden im Endausbau Zugang zum R/3-System haben (ganzes System)?
Derzeit ca. .............. User (Named Users).
Im Endausbau .................... User (Named Users).
q Weiss nicht
H9. Betreiben oder planen Sie für die Benutzung des SAP R/3-Systems ein systemtechnisches Outsourcing ?
q Ja, mit folgendem Anbieter: ...........................................................................
Form des Outsourcings:
−
Einführung (Projektverantwortung)
−
R/3-Hardware (Server)
−
R/3-System:
−
Netzwerke (LAN, WAN)
Basis (Release-Wechsel, DB)
betriebswirtschaftlich (Customizing)
q Nein
innerbetrieblich
q
q
q
q
q
q Weiss nicht
ausserbetrieblich
q
q
q
q
q
Geschätzte Kostenersparnis: ....................%
I. Customizing
I1. Wie erfolgt(e) generell die organisatorische Anpassung ?
q a) Anpassung von Geschäftsprozessen und Organisationsstrukturen an die SAP R/3-Erfordernisse
q b) Anpassung des R/3-Systems an die eigenen Geschäftsprozesse und Organisationsstrukturen
q Auf beide Arten, mit einem Schwergewicht bei
q a)
q b)
q Weiss nicht
360
Anhang B
I2. Wie haben Sie Anpassungen bzw. Erweiterungen von R/3 an die betriebliche Umgebung vorgenommen?
(Mehrfachnennungen möglich)
q
q
q
q
q
q
q
Durch Parametersetzung (Customizing)
Durch Verwendung von User-Exits
Durch Veränderung des R/3 Source Codes
Ergänzung von R/3 durch eigene Applikationen
Anders: .......................................................................................................................................................
Keine Anpassungen oder Erweiterungen
Weiss nicht
I3. Die in SAP R/3 vorgesehenen Customizing-Möglichkeiten zur individuellen Systemanpassung
q reichen immer aus
q reichen in ca. .......... % des Leistungsumfanges aus
q Weiss nicht
I4. Die R/3-Systemumgebung in Ihrem Unternehmen weist
ca. ................ (Anzahl) auf Dauer geplante Schnittstellen,
ca. ................ (Anzahl) temporäre Schnittstellen
q Weiss nicht
auf.
I5. Haben Sie Daten aus bisherigen Systemen ins R/3-System übernommen ?
q Ja, Stammdaten
q automatisch
q manuell
q Ja, Bewegungsdaten
q automatisch
q manuell
q Nein
q Weiss nicht
q Keine
q Weiss nicht
I6. Falls ja, welches waren dabei die Hauptschwierigkeiten ?
q Schnittstellenprogrammierung
q Gewährleistung der Datenintegrität
q Nummerungssysteme
q Übernahme von Vergangenheitsdaten
q Klassifizierung
q Andere: ........................................................................................................
J. Ausbildung
J1. Wo wurde/wird im Rahmen Ihres R/3-Einführungsprojektes geschult resp. wer war/ist für die Schulung der
Projektteams resp. der Endanwender zuständig ?
q Weiss nicht
Interne Schulung durch
SAP-Berater
Eigene Mitarbeiter
CBT (Computer Based Training)
Selbststudium
......................................................
Projektteams
Endan wender
q
q
q
q
q
q
q
q
q
q
Externe Schulung bei
SAP
einem anderen Anbieter
.................................................
.................................................
.................................................
J2. Zu welchen Zeitpunkten erfolgte die Schulung ? (Mehrfachnennungen möglich)
Projektteams
Endan wender
noch vor Beginn des
Einführungsprojekts
q
q
in der Anfangsphase des
Einführungsprojekts
q
q
Projektteams
Endanwender
q
q
q
q
q
q
q
q
q
q
q Weiss nicht
Projektteams
Endanwender
gegen Ende des Einführungsprojekts / unmittelbar vor Produktivstart
q
q
über alle Projektphasen verteilt
q
q
q
q
nach Bedarf in der Produktivphase
J3. An welcher Art R/3-System wird die Ausbildung der Anwender vorgenommen?
q An einem System ohne Abbildung unternehmensspezifischer Merkmale
q An einem unternehmensspezifisch angepassten System
q An einem System mit Kopien von betrieblichen Echt-Daten
q Weiss nicht
361
Anhang B
K. Inbetriebnahme
K1. Haben Sie einen Parallelbetrieb zwischen bisherigen Systemen und SAP R/3 vorgenommen?
q Ja, bei folgenden Modulen: ........................................................................
q Nein
q Weiss nicht
K2. Sind im produktiven Einsatz von SAP R/3 erhebliche Schwierigkeiten aufgetreten? Können Sie gegebenenfalls
mögliche Ursachen dafür angeben?
Problem
Ursache
.................................................................................
.......................................................................................
.................................................................................
.......................................................................................
.................................................................................
.......................................................................................
K3. In welcher Weise unterstützen Sie Ihre Anwender beim Auftreten von Problemen mit SAP R/3?
q
q
q
q
Durch Benutzer-Service-Zentren (IC)
Durch Projekt- / Systemverantwortliche
q Keine formelle Regelung
q Anders: ................................................................
................................................................
Durch besonders ausgebildete "Super User"
q Weiss nicht
Durch SAP
L. Rechtliche Aspekte
L1. War Ihre Unternehmung bei Realisierung des R/3 Projektes mit rechtlichen Problemen konfrontiert? Wenn
ja, in welcher Art und Weise? (Mehrfachnennungen möglich)
q Ja,
q Nein
q Weiss nicht
q verursacht durch Kostenüberschreitungen
q verursacht durch Terminüberschreitungen
q provoziert durch mangelhafte Kompetenzen der Berater
q infolge Anschaffung nicht einsatzkonformer Hardware
q infolge Projektbeginns vor Vertragsabschluss
q infolge Leistungsanpassungen nach Vertragsabschluss
q infolge unfairer Vertragsklauseln
q infolge ungenügend definierter Pflichten der Vertragspartner
q andere: .................................................................................................
..............................................................................................................
M. Zukunftsaussichten
M1. Die SAP AG arbeitet zur Zeit an einer weiterentwickelten Version von R/3, welche Schnittstellen zum Internet
einerseits und zu unternehmensinternen Netzen (Intranets) andererseits aufweisen soll.
Wie schätzen Sie die Bedeutung solcher Erweiterungen von R/3 ein?
sehr wichtiger Wettbewerbsfaktor sowohl für die SAP als auch für die R/3-Kunden
ist ein zentrales Evaluationskriterium
eher unbedeutend, da in weltweit operierenden Unternehmen andere interne und
externe Kommunikationsverbindungen existieren
Interessant, jedoch vom Sicherheitsaspekt her als problematisch einzustufen
bedeutungslos
andere Einschätzungen: ......................................................................................
.............................................................................................................................
Herzlichen Dank für Ihre Kooperation!
362
Heute
In 3 Jahren
q
q
q
q
q
q
q
q
q
q
q
q
q
q
Anhang B
Universität Bern
Institut für Wirtschaftsinformatik
Abteilung Information Engineering
Prof. Dr. Gerhard Knolmayer
Engehaldenstr. 8, 3012 Bern, Telefon 031 / 631 38 09
Fax 031 / 631 46 82, e-mail knolmayer@ie.iwi.unibe.ch
URL http://www.ie.iwi.unibe.ch/∼knolmayer
XYZ AG
Herrn Hans Muster
Bahnhofstrasse 11
8000 Zürich
Bern, 17. Juli 1996
Einführung von SAP R/3 in Schweizer Unternehmen
Sehr geehrter Herr Muster
Die Abteilung "Information Engineering" des Instituts für Wirtschaftsinformatik der Universität Bern
hat 1994 eine Umfrage Umfrage zu den Erfahrungen, die Schweizer Unternehmen bei der Einführung von R/3 gemacht haben, durchgeführt. Diese Umfrage ist auf grosses Interesse von Seiten der
Praxis gestossen. Wir haben in mehreren Medien, Fachtagungen und auf den SAPUS-Benutzerkonferenzen 1994 und 1995 über die Ergebnisse dieser Studie berichtet.
1994 waren erst wenige SAP R/3 Projekte abgeschlossen und es lagen noch keine längerfristigen
Erfahrungen mit R/3 vor. Nicht zuletzt die Gespräche mit der SAPUS haben uns veranlasst, die Studie zu aktualisieren und dazu möglichst alle Projektverantwortlichen in der Schweiz einzubeziehen.
Unser Ziel ist es, damit einen Beitrag zu einem fundierten Erfahrungsaustausch zwischen R/3 Anwendern zu leisten und zur Versachlichung der Diskussion um Nutzen und Kosten von SAP R/3Einführungen beizutragen.
Wir sind uns klar bewusst, dass Sie in Ihrer Funktion häufig mit solchen Begehren konfrontiert werden. Bitte brücksichtigen Sie bei Ihrem Entscheid über die Beantwortung des Fragebogens, dass
unsere Arbeitsgruppe den Themenkreis R/3 zu einem Lehr- und Forschungsschwerpunkt gemacht
hat (vgl. Beilage sowie unsere WWW-Seiten http://www.ie.iwi.unibe.ch/sap/sapr3.html). Wir
wären Ihnen daher sehr verbunden, wenn Sie den beiliegenden Fragebogen sowie das
Hinweisblatt ausfüllen und umgehend, spätestens aber bis zum
5. August 1996
an unser Institut zurücksenden könnten. Wir werden Ihnen als Gegenleistung gerne die Ergebnisse
unserer Untersuchung zur Verfügung stellen.
Mit bestem Dank für die Unterstützung unserer Bemühungen um eine praxisbezogene Forschung
und Lehre verbleiben wir
mit freundlichen Grüssen
Beilagen: Fragebogen, Rückantwortcouvert, Hinweisblatt, Infoblatt "Aktivitäten im R/3 Umfeld"
363
Anhang B
Umfrage: Erfahrungen bei der Einführung von SAP R/3
Hinweise zum Ausfüllen des Fragebogens
SAP R/3
An wen richtet sich der Fragebogen?
Der Fragebogen richtet sich an eine für die Einführung von SAP R/3 verantwortliche Person.
Untersuchungsobjekt
Untersuchungsobjekt ist ausschliesslich die in der Anschrift bezeichnete
Schweizer Unternehmung, inkl. deren inländischen Tochtergesellschaften
aber exkl. aller ausländischen Unternehmungseinheiten.
Kontaktpersonen
Allfällige Fragen richten Sie bitte an:
Universität Bern
Christoph Zimmerli oder Reto von Arb
Tel. direkt:
Tel. Sekretariat:
031/ 631 33 04
031/ 631 38 09
031/ 631 87 39
031/ 631 38 09
Angaben zu Ihrer Person
Bitte geben Sie nachfolgend für den Fall allfälliger Rückfragen zumindest Ihren Namen und Ihre TelefonNr. (inkl. Vorwahl) an. Senden Sie dieses Blatt zusammen mit dem Fragebogen an uns zurück. Falls Sie
an der Studie interessiert sind, notieren Sie bitte Ihre vollständige Adresse.
Name:
.........................................................................................................................................
Position/Funktion: .........................................................................................................................................
Abteilung:
.........................................................................................................................................
Firma:
.........................................................................................................................................
Tel.-Nr.:
.............. / .......................................................................................................................
Adresse:
.........................................................................................................................................
.........................................................................................................................................
q Ja
Erhalt einer Studie erwünscht:
Herzlichen Dank für Ihre Kooperation.
364
q Nein
Anhang B
Universität Bern
URL http://www.ie.iwi.unibe.ch/sap/sapr3.html
XYZ AG
Herrn Hans Muster
Bahnhofstrasse 11
8000 Zürich
Bern, 7. August 1996
Sehr geehrter Herr Muster
Vor rund zwei Wochen haben Sie von uns per Post einen Fragebogen zum Thema
"Erfahrungen bei der Einführung von SAP R/3 in Schweizer Unternehmungen" erhalten. Da
wir bestrebt sind, möglichst repräsentative Aussagen zu machen, ist eine grosse Zahl von
Rücksendungen unumgänglich.
Wir sind uns bewusst, dass diese Umfrage durch die Sommerferien tangiert wird. Aus
diesem Grund haben wir uns entschlossen, den Rücksendeschluss auf das Ende der
Ferienzeit zu verlegen. Da Sie uns den Fragebogen bisher noch nicht zurückgesandt haben,
möchten wir Sie bitten, dies wenn möglich bis
Mitte August 1996
nachzuholen. Sollten Sie den Fragebogen in der Zwischenzeit nicht mehr greifbar haben
oder bereitet Ihnen die Einhaltung des Termins Probleme, dann möchten wir Sie bitten,
uns dies entweder mit beiliegendem Faxformular oder telefonisch mitzuteilen
Fax: 031 / 631 46 82
Tel: 031 / 631 87 39 oder 031 / 631 33 04
Bei dieser Gelegenheit möchten wir Sie darauf hinweisen, dass sämtliche Angaben absolut
vertraulich behandelt werden. Sollten Sie den Fragebogen in der Zwischenzeit an uns
zurückgeschickt haben, betrachten Sie dieses Schreiben bitte als gegenstandslos.
Für Ihr Verständnis und die damit verbundene Unterstützung der universitären Forschung
danken wir herzlich.
Mit freundlichen Grüssen
Faxblatt
365
Anhang B
Universität Bern
URL http://www.ie.iwi.unibe.ch/∼knolmayer
Fax
From:
XYZ AG
Herrn Hans Muster
8000 Zürich
To:
Herrn Christoph Zimmerli
Engehaldenstr. 8
3012 Bern
Fax: 031 / 631 46 82
Bestellung
q eines Exemplares des Fragebogens "Erfahrungen bei der Einführung von
SAP R/3 in Schweizer Unternehmungen".
Schicken Sie dieses bitte an folgende Person (unbedingt ausfüllen):
Name, Vorname: .................................................................................................
Mitteilung
q Die Beantwortung des Fragebogens bis zum genannten Termin ist mir
nicht möglich. Ich werde diesen aber noch vor dem
.............................................. (bitte Datum angeben) ausfüllen und
zurücksenden.
Name, Vorname: ........................................................................................................
Datum: ........................................
366
Unterschrift: .....................................................
Anhang C
Anhang C : Statistische Analysen
H 1.1: Mitarbeiterzahl (A11) ð # Named User (H82)
Hypothese:
Beim Einsatz von R/3 ist die vorgesehene Benutzerzahl (Named User) von der Grösse des Unternehmens
(Mitarbeiterzahl) abhängig.
Statistische Analyse:
Pearson correlation matrix
A11
1.000
0.675
A11
H82
H82
1.000
Bartlett Chi-square statistic:
36.730 DF=1 Prob= 0.000
Matrix of Bonferroni Probabilities
A11
0.0
0.000
A11
H82
H82
0.0
Number of observations: 63
11 case(s) deleted due to missing data.
Model contains no constant
Dep Var: H82
N: 63
Multiple R: 0.843
Adjusted squared multiple R: 0.711
Effect
Standard error of estimate: 106.129
Coefficient
Std Error
0.200
0.016
A11
Squared multiple R: 0.711
Std Coef Tolerance
0.843
1.000
t
P(2 Tail)
12.341
0.000
Analysis of Variance
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
1715496.566
1 1715496.566
152.308
0.000
Residual
698326.434
62
11263.330
------------------------------------------------------------------------------Durbin-Watson D Statistic
First Order Autocorrelation
1.934
0.025
(nur Industriesektor)
H82
1.000
0.865
H82
A11
A11
1.000
36.623 DF=1 Prob= 0.000
H82
0.0
0.000
H82
A11
A11
0.0
Dep Var: H82
N: 29
Multiple R: 0.914
367
Anhang C
Effect
A11
Coefficient
Std Error
0.347
0.029
Std Coef Tolerance
0.914
1.000
t
P(2 Tail)
11.959
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
2432007.274
1 2432007.274
143.023
0.000
Residual
476119.726
28
17004.276
2.518
-0.266
Ergebnis:
Es besteht grundsätzlich eine Abhängigkeit zwischen der Mitarbeiterzahl und der Named-User- Zahl.
Im Industriesektor ergibt sich die stärkste Abhängigkeit. In diesem Sektor sind rund ein Drittel
(34.7%) der Mitarbeiter Anwender des R/3-Systems.
368
Anhang C
H 1.2: KMU - GU ð Anzahl Named User im Endausbau (H82)
Hypothese:
Die Anzahl Named User beim Einsatz des R/3-Systems in KMUs ist geringer als in Grossunternehmen.
Two-sample t test on H82 grouped by KMUGU$
Group
GU
KMU
N
44
38
Mean
474.068
83.789
SD
785.975
66.131
Separate Variance t =
Difference in Means =
3.280 DF =
43.7
390.279
95.00% CI =
Prob =
150.455 to
0.002
630.103
Pooled Variance t =
3.049 DF =
80
390.279
95.00% CI =
Prob =
135.553 to
0.003
645.004
1600
H82
1200
800
400
KMUGU$
0
60 50 40 30 20 10 0 10 20 30 40 50 60
Count
Count
KMU
GU
Ergebnis:
Zwischen KMUs und Grossunternehmen lässt sich ein signifikanter Unterschied (95%) hinsichtlich der
Anwenderzahl (Named User) feststellen. In KMUs verwenden durchschnittlich 84 User das R/3-System
und in Grossunternehmen 474.
369
Anhang C
H 1.3: KMU - GU ð # eingeführte Module
Hypothese:
Grossunternehmen setzen mehr Module des R/3-Systems ein als KMUs.
Two-sample t test on MOD grouped by KMUGU$
Group
GU
KMU
N
44
45
Mean
5.977
5.956
SD
2.215
2.110
0.047 DF =
86.6
0.022
95.00% CI =
Prob =
-0.890 to
0.962
0.934
Pooled Variance t =
0.047 DF =
87
0.022
95.00% CI =
Prob =
-0.890 to
0.962
0.933
12
10
MOD
8
6
4
KMUGU$
2
0
25 20 15 10 5
Count
0
5 10 15 20 25
Count
KMU
GU
Ergebnis:
Die Hypothese, dass Grossunternehmen das R/3-System breiter einsetzen, trifft nicht zu.
370
Anhang C
H 1.4: Branche ð # eingeführte Module
Hypothese:
Die Zahl der eingesetzten Module ist in den einzelnen Branchen (Industrie-, Handels- und Dienstleistungssektor) unterschiedlich.
Two-sample t test on MOD grouped by BRANCHE
(1 = Industrie, 2 = Handel)
Group
1
2
N
40
9
Mean
6.525
6.000
SD
1.724
2.179
0.677 DF =
10.4
0.525
95.00% CI =
Prob =
-1.196 to
0.513
2.246
Pooled Variance t =
0.786 DF =
47
0.525
95.00% CI =
Prob =
-0.818 to
0.436
1.868
12
11
10
9
MOD
8
7
6
5
4
BRANCHE
3
2
20
15
10 5
Count
0
5
10 15
Count
20
2
1
Ergebnis:
Zwischen der Industrie und dem Handel besteht kein signifikanter Unterschied im Hinblick auf die
Zahl der eingesetzten Module.
371
Anhang C
(1 = Industrie, 3 = Dienstleistungssektor)
Group
1
3
N
40
18
Mean
6.525
3.944
SD
1.724
1.662
5.407 DF =
34.0
2.581
95.00% CI =
Prob =
1.611 to
0.000
3.550
Pooled Variance t =
5.331 DF =
56
2.581
95.00% CI =
Prob =
1.611 to
0.000
3.550
12
10
MOD
8
6
4
BRANCHE
2
0
20
15
10 5
Count
0
5
10 15
Count
20
3
1
Ergebnis:
Zwischen der Industrie und Dienstleistungssektor besteht ein signifikanter Unterschied (95%) im
Hinblick auf die Zahl der eingesetzten Module. Im Industriesektor werden durchschnittlich 6 Module
eingesetzt und im Dienstleistungssektor durchschnittlich 4.
372
Anhang C
(2 = Handel, 3 = Dienstleistungssektor)
Group
2
3
N
9
18
Mean
6.000
3.944
SD
2.179
1.662
2.491 DF =
12.8
2.056
95.00% CI =
Prob =
0.270 to
0.027
3.841
Pooled Variance t =
2.732 DF =
25
2.056
95.00% CI =
Prob =
0.506 to
0.011
3.605
11
10
9
8
MOD
7
6
5
4
3
2
1
9 87 654 32 10 12 34 56 78 9
Count
Count
BRANCHE
3
2
Ergebnis:
Zwischen dem Handels- und dem Dienstleistungssektor besteht ein signifikanter Unterschied (95%) im
Hinblick auf die Zahl der eingesetzten Module. Im Handel werden durchschnittlich
6 Module eingesetzt und im Dienstleistungssektor durchschnittlich 4.
373
Anhang C
H 1.5: KMU - GU: Gesamtkosten der Einführung (D111)
Hypothese:
Die Gesamtkosten einer R/3-Einführung sind in KMUs niedriger als in Grossunternehmen.
Two-sample t test on D111 grouped by KMUGU$
Group
GU
KMU
N
30
30
Mean
7.471
1.955
SD
8.066
1.625
3.672 DF =
31.3
5.516
95.00% CI =
Prob =
2.454 to
0.001
8.578
Pooled Variance t =
3.672 DF =
58
5.516
95.00% CI =
Prob =
2.509 to
0.001
8.523
35
30
D111
25
20
15
10
5
0
60 50 40 30 20 10 0 10 20 30 40 50 60
Count
Count
KMUGU$
KMU
GU
Ergebnis:
Aufgrund der unterschiedlichen Anwenderzahlen (vgl. H 1.1) besteht ein signifikanter Unterschied
(95%) zwischen KMUs (2 Mio.) und Grossunternehmen (7.5 Mio.) in Bezug auf die Gesamtkosten der
Einführung.
374
Anhang C
1.6: Branche ð Einführungskosten/100 Named User (KOST100U)
Hypothese:
Die durchschnittlichen Einführungskosten für 100 Named User sind im Dienstleistungssektor niedriger als im Industrie- und Handelssektor.
Two-sample t test on KOST100U grouped by BRANCHE
Group
1
2
N
23
4
Mean
1992983.459
2916666.667
SD
760822.508
1397749.514
-1.289 DF =
3.3
Prob =
-923683.207
95.00% CI = -3.086E+06 to
0.280
1.239E+06
Pooled Variance t =
-1.977 DF =
25
Prob =
-923683.207
95.00% CI = -1.886E+06 to
0.059
38583.999
Group
1
3
N
23
10
Mean
1992983.459
2459452.381
SD
760822.508
2053770.611
-0.698 DF =
10.1
Prob =
-466468.921
95.00% CI = -1.954E+06 to
0.501
1.021E+06
Pooled Variance t =
-0.963 DF =
31
Prob =
-466468.921
95.00% CI = -1.454E+06 to
0.343
5.215E+05
Group
2
3
N
4
10
Mean
2916666.667
2459452.381
SD
1397749.514
2053770.611
0.479 DF =
8.3
Prob =
457214.286
95.00% CI = -1.727E+06 to
0.644
2.642E+06
Pooled Variance t =
0.404 DF =
12
Prob =
457214.286
95.00% CI = -2.006E+06 to
0.693
2.920E+06
Ergebnis:
Zwischen den einzelnen Branchen lassen sich keine signifikanten Unterschiede hinsichtlich der
Einführungskosten pro 100 Named User feststellen.
375
Anhang C
H 1.7: KMU - GU ð Einführungskosten pro 100 Named User (KOST100U)
Hypothese:
Die durchschnittlichen Einführungskosten für 100 Named User sind bei Grossunternehmen geringer als
bei KMUs.
Two-sample t test on KOST100U grouped by KMUGU$
Group
GU
KMU
N
28
26
Mean
2344383.602
2275784.712
SD
1713471.721
1102483.625
0.176 DF =
46.5
Prob =
68598.890
95.00% CI = -7.149E+05 to
0.861
8.521E+05
Pooled Variance t =
0.173 DF =
52
Prob =
68598.890
95.00% CI = -7.250E+05 to
0.863
8.622E+05
8000000
7000000
KOST100U
6000000
5000000
4000000
3000000
2000000
KMUGU$
1000000
0
30
20
10
Count
0
10
20
Count
30
KMU
GU
Ergebnis:
Die Einführungskosten pro 100 Named User weisen zwischen KMUs und Grossunternehmen keinen signifikanten Unterschied auf.
376
Anhang C
H 1.8: KMU - GU: Kostenverhältnis Software-Einführungskosten (SW_EINF)
Hypothese:
Die Kostenstruktur (Verhältnis von Softwarelizenzkosten zu Einführungskosten) ist in KMUs und
Grossunternehmen ähnlich.
Two-sample t test on SW_EINF grouped by KMUGU$
Group
GU
KMU
N
33
33
Mean
2.879
3.801
SD
2.065
4.695
-1.032 DF =
43.9
-0.921
95.00% CI =
Prob =
-2.721 to
0.308
0.878
Pooled Variance t =
-1.032 DF =
64
-0.921
95.00% CI =
Prob =
-2.705 to
0.306
0.862
20
SW_EINF
15
10
5
KMUGU$
0
40
30
20 10
Count
0
10
20 30
Count
40
KMU
GU
Ergebnis:
Der Unterschied in den Mittelwerten ist aufgrund der hohen Standardabweichungen nicht signifiant.
377
Anhang C
H 1.9: Singlesite-Inst. (ss) - Multisite-Inst. (ms) ð Einführungskosten in Mio. (D111)
Hypothese:
Die Einführungskosten
Installationen.
von
Multisite-Installationen
sind
höher
als
jene
von
Singlesite-
Two-sample t test on D111 grouped by SS_MS$
Group
ms
ss
N
21
33
Mean
8.685
2.011
SD
7.085
1.985
4.213 DF =
22.0
6.674
95.00% CI =
Prob =
3.388 to
0.000
9.959
Pooled Variance t =
5.129 DF =
52
6.674
95.00% CI =
Prob =
4.063 to
0.000
9.285
30
D111
20
10
SS_MS$
ss
ms
0
50 40 30 20 10 0 10 20 30 40 50
Count
Count
Two-sample t test on KOST100U grouped by SS_MS$
Group
ms
ss
378
N
21
28
Mean
2212863.816
2156489.062
SD
907742.050
1502334.595
0.163 DF =
45.2
Prob =
56374.754
95.00% CI = -6.408E+05 to
0.871
7.535E+05
Pooled Variance t =
0.152 DF =
47
Prob =
56374.754
95.00% CI = -6.890E+05 to
0.880
8.017E+05
Anhang C
7000000
6000000
KOST100U
5000000
4000000
3000000
2000000
SS_MS$
1000000
0
30
20
10
Count
0
10
20
Count
30
ss
ms
Ergebnis:
Die Einführungskosten von Projekten an mehreren Standorten (mulitsite ð z.B. konzernweite Einführung) sind signifikant höher als bei Singlesite-Installationen (95%). Der Hauptgrund dafür ist
aber auch hier in der deutlich höheren Benutzerzahl (Named User) zu suchen. Bei der Gegenüberstellung der Einführungskosten pro 100 Named User lassen sich keine signifikanten Unterschiede feststellen.
379
Anhang C
H 1.10: Branche ð Einführungsdauer in Personenmonaten (PM)
Hypothese:
Die Einführungsdauer in Personenmonaten ist im Dienstleistungssektor kürzer als im Indusstrie- und
Handelssektor.
Two-sample t test on PM grouped by BRANCHE
Group
2
3
N
5
10
Mean
71.200
42.500
SD
58.934
76.187
0.804 DF =
10.3
28.700
95.00% CI =
Prob =
-50.565 to
0.440
107.965
Pooled Variance t =
0.735 DF =
13
28.700
95.00% CI =
Prob =
-55.697 to
0.476
113.097
Group
1
3
380
N
21
10
Mean
129.429
42.500
SD
150.882
76.187
2.131 DF =
28.8
86.929
95.00% CI =
Prob =
3.462 to
0.042
170.396
Pooled Variance t =
1.710 DF =
29
86.929
95.00% CI =
Prob =
-17.028 to
0.098
190.885
Anhang C
600
500
PM
400
300
200
BRANCHE
100
0
30
20
10
Count
0
10
20
Count
3
1
30
Group
1
2
N
21
5
Mean
129.429
71.200
SD
150.882
58.934
1.381 DF =
17.6
58.229
95.00% CI =
Prob =
-30.508 to
0.185
146.965
Pooled Variance t =
0.837 DF =
24
58.229
95.00% CI =
Prob =
-85.371 to
0.411
201.828
Ergebnis:
Ein schwach signifikanter Unterschied (95%) in der Einführungsdauer in Personenmonaten kann nur
zwischen der Industrie (129.5 PM) und dem Dienstleistungssektor (42.5 PM) festgestellt werden.
381
Anhang C
H 1.11: KMU - GU ð Einführungsdauer (Monate)
Hypothese:
Die Gesamteinführungsdauer ist bei KMUs geringer als bei Grossunternehmen.
Two-sample t test on KZ grouped by KMUGU$
Group
GU
KMU
N
43
39
Mean
19.140
11.846
SD
10.414
6.576
3.828 DF =
71.7
7.293
95.00% CI =
Prob =
3.495 to
0.000
11.092
Pooled Variance t =
3.747 DF =
80
7.293
95.00% CI =
Prob =
3.420 to
0.000
11.167
50
40
KZ
30
20
10
0
20
KMUGU$
15
10 5
Count
0
5
10 15
Count
20
KMU
GU
Ergebnis:
Die Einführungsdauer von R/3 in KMUs ist signifikant kürzer als in Grossunternehmen.
382
Anhang C
H 1.12: KMU - GU ð Methodische Unterstützung (METH)
Hypothese:
Grossunternehmen setzen bei der Einführung von R/3 ein stärkeres Gewicht auf die methodische Unterstützung (Verwendung von Vorgehensmodellen und Tools) als KMUs.
Two-sample t test on METH grouped by KMUGU$
Group
GU
KMU
N
48
44
Mean
1.187
1.023
SD
0.816
0.731
1.021 DF =
90.0
0.165
95.00% CI =
Prob =
-0.156 to
0.310
0.485
Pooled Variance t =
1.016 DF =
90
0.165
95.00% CI =
Prob =
-0.157 to
0.312
0.487
Ergebnis:
Der Einsatz von Vorgehensmodellen und Softwareunterstützungswerkzeugen weist zwischen KMUs und
Grossunternehmen keine signifikanten Unterschiede auf.
H 1.13: KMU - GU ð Organisatorische Anpassung (ANPASS)
Hypothese:
Der Grad der organisatorischen Anpassung unterscheidet sich zwischen KMUs und Grossunternehmen.
Two-sample t test on ANPASS grouped by KMUGU$
Group
GU
KMU
N
46
44
Mean
1.304
1.227
SD
0.465
0.424
0.822 DF =
87.8
0.077
95.00% CI =
Prob =
-0.109 to
0.413
0.263
Pooled Variance t =
0.820 DF =
88
0.077
95.00% CI =
Prob =
-0.110 to
0.414
0.264
Ergebnis:
Ein signifikanter Unterschied (95%) kann nicht nachgewiesen werden.
383
Anhang C
H 1.14: KMU - GU ð Veränderungen am Source Code (I23)
Hypothese:
KMUs nehmen weniger häufig Veränderungen am Source Code vor als Grossunternehmen.
Two-sample t test on I23 grouped by KMUGU$
Group
GU
KMU
N
48
44
Mean
0.167
0.136
SD
0.377
0.347
0.402 DF =
90.0
0.030
95.00% CI =
Prob =
-0.120 to
0.689
0.180
Pooled Variance t =
0.400 DF =
90
0.030
95.00% CI =
Prob =
-0.120 to
0.690
0.181
Ergebnis:
In KMUs und Grossunternehmen werden mit gleicher Häufigkeit Modifikationen am R/3-System vorgenommen. Die Unterschiede sind nicht signifikant (95%).
H 1.15: KMU - GU: Wahl einer Outsourcing-Lösung (H91)
Hypothese:
KMUs wählen häufiger eine Outsourcing-Lösung für den Systembetrieb als Grossunternehmen.
Frequencies
KMUGU$ (rows) by H91 (columns)
0
1
Total
+-------------+
GU |
36
11 |
47
KMU |
24
17 |
41
+-------------+
Total
60
28
88
0 = No Outsourcing
1 = Outsourcing
Two-sample t test on H91 grouped by KMUGU$
Group
GU
KMU
N
47
41
Mean
0.234
0.415
SD
0.428
0.499
-1.809 DF =
79.4
-0.181
95.00% CI =
Prob =
-0.379 to
0.074
0.018
Pooled Variance t =
-1.828 DF =
86
-0.181
95.00% CI =
Prob =
-0.377 to
0.071
0.016
Ergebnis:
Tendenziell wählen KMUs häufiger (41.5%) eine Outsourcing-Lösung als Grossunternehmen (23.4%).
Allerdings ist der festgestellte Unterschied statistisch nicht signifikant.
384
Anhang C
H 1.16: KMU - GU ð Intensität der Evaluation (C7)
Hypothese:
Die Intensität der Evaluation ist in KMUs und Grossunternehmen vergleichbar.
Two-sample t test on C7 grouped by KMUGU$
Group
GU
KMU
N
28
35
Mean
6.714
5.957
SD
5.797
9.129
0.400 DF =
58.3
0.757
95.00% CI =
Prob =
-3.031 to
0.691
4.545
Pooled Variance t =
0.381 DF =
61
0.757
95.00% CI =
Prob =
-3.213 to
0.704
4.727
60
50
C7
40
30
20
10
0
60 50 40 30 20 10 0 10 20 30 40 50 60
Count
Count
KMUGU$
KMU
GU
Ergebnis:
Der Aufwand bei der Systemevaluation ist bei KMUs und Grossunternehmen ähnlich. Es besteht kein
signifikanter Unterschied (95%).
385
Anhang C
H 1.17: KMU - GU ð Funktionsabdeckungsgrad (H91)
Hypothese:
In KMUs ist der Funktionsabdeckungsgrad grösser als in Grossunternehmen.
Group
GU
KMU
N
38
40
Mean
0.880
0.902
SD
0.104
0.073
-1.088 DF =
65.7
-0.022
95.00% CI =
Prob =
-0.063 to
0.281
0.019
Pooled Variance t =
-1.097 DF =
76
-0.022
95.00% CI =
Prob =
-0.063 to
0.276
0.018
1.1
1.0
0.9
I3
0.8
0.7
0.6
KMUGU$
0.5
0.4
30
20
10
Count
0
10
20
Count
30
KMU
GU
Ergebnis:
Der Funktionsabdeckungsgrad in KMUs und in Grossunternehmen ist nicht signifikant unterschiedlich
(95%).
386
Anhang C
H 1.18: KMU - GU ð Anzahl auf Dauer eingerichtete Schnittstellen (I41)
Hypothese:
Die Zahl der auf Dauer eingerichteten Schnittstellen ist in Grossunternehmen grösser als in KMUs.
Group
GU
KMU
N
36
27
Mean
11.528
3.926
SD
16.492
2.615
2.720 DF =
37.3
7.602
95.00% CI =
Prob =
1.942 to
0.010
13.262
Pooled Variance t =
2.368 DF =
61
7.602
95.00% CI =
Prob =
1.183 to
0.021
14.020
90
80
70
I41
60
50
40
30
20
KMUGU$
10
KMU
GU
0
80 70 60 50 40 30 20 10 0 10 20 30 40 50 60 70 80
Count
Count
Ergebnis:
Bei der Zahl der durchschnittlich auf Dauer eingerichteten Schnittstellen lässt sich ein signifikanter Unterschied zwischen KMUs und Grossunternehmen feststellen (95%).
387
Anhang C
H 2.1: U mit R/2-Einsatz - U ohne R/2-Einsatz ð Einführungsdauer (PM100U)
Hypothese:
Die Einführungsdauer (Personenmonate) für 100 Named User ist bei Unternehmen mit R/2-Erfahrung
niedriger als bei Unternehmen ohne R/2-Erfahrung.
Two-sample t test on PM100U grouped by H71
(0 = keine R/2-Erfahrung vorhanden, 1 = R/2-Erfahrung vorhanden)
Group
0
1
N
45
5
Mean
58.971
53.240
SD
59.442
44.945
0.261 DF =
5.7
5.731
95.00% CI =
Prob =
-48.747 to
0.803
60.209
Pooled Variance t =
0.208 DF =
48
5.731
95.00% CI =
Prob =
-49.595 to
0.836
61.057
Ergebnis:
Die Einführungsdauer (in Personenmonaten für 100 Named User) in Unternehmen mit R/2-Erfahrung
weist keinen signifikanten Unterschied zu Unternehmen ohne R/2-Erfahrung auf.
H 2.2: U mit R/2-Einsatz - U ohne R/2-Einsatz ð Einführungskosten (PM100U)
Hypothese:
Die Einführungskosten für 100 Named User sind bei Unternehmen mit R/2-Erfahrung niedriger als bei
Unternehmen ohne R/2-Erfahrung.
Two-sample t test on KOST100U grouped by H71
(0 = keine R/2-Erfahrung vorhanden, 1 = R/2-Erfahrung vorhanden)
Group
0
1
N
45
10
Mean
2382665.029
1925988.372
SD
1526462.312
809641.961
1.333 DF =
25.6
Prob =
456676.657
95.00% CI = -2.480E+05 to
0.194
1.161E+06
Pooled Variance t =
0.913 DF =
53
Prob =
456676.657
95.00% CI = -5.463E+05 to
0.365
1.460E+06
(ANZMODXX.SYS)
Ergebnis:
Die Einführungskosten (für 100 Named User) in Unternehmen mit R/2-Erfahrung weisen keinen signifikanten Unterschied zu Unternehmen ohne R/2-Erfahrung auf.
388
Anhang C
H 2.3: Host-Umgebung - PC-Netzwerk-Umgebung ð Gesamtkosten (D111)
Hypothese:
Die Gesamtkosten einer Einführung sind bei Unternehmen mit Host-Einsatz höher als bei Unternehmen,
deren betriebswirtschaftliche Anwendungsplattform sich bisher auf PC-Server-Ebene befand.
Two-sample t test on D111 grouped by BSYSARCH
Group
1
3
N
49
4
Mean
5.307
1.558
SD
6.894
1.182
3.265 DF =
28.9
3.750
95.00% CI =
Prob =
1.400 to
0.003
6.099
Pooled Variance t =
1.077 DF =
51
3.750
95.00% CI =
Prob =
-3.239 to
0.286
10.738
35
30
D111
25
20
15
10
5
0
60 50 40 30 20 10 0 10 20 30 40 50 60
Count
Count
BSYSARCH
3
1
Ergebnis:
Im Hinblick auf die Gesamteinführungskosten der betrachteten Unternehmungen lässt sich ein signifikanter Unterschied (95%) feststellen.
389
Anhang C
H 2.4: Host-Umgebung - PC-Netzwerk-Umgebung ð Kosten für 100 User (KOST100U)
Hypothese:
Die Einführungskosten für 100 Named User sind bei Unternehmen mit bisherigem Grossrechner-Einsatz
höher als bei jenen, deren betriebswirtschaftliche Anwendungsplattform sich bisher auf PCServerebene befand.
Two-sample t test on KOST100U grouped by BSYSARCH
Group
1
3
N
44
3
Mean
2322179.862
2352380.952
SD
1530310.920
448428.852
-0.087 DF =
6.3
Prob =
-30201.090
95.00% CI = -8.705E+05 to
0.933
8.101E+05
Pooled Variance t =
-0.034 DF =
45
Prob =
-30201.090
95.00% CI = -1.832E+06 to
0.973
1.771E+06
8000000
7000000
KOST100U
6000000
5000000
4000000
3000000
2000000
BSYSARCH
1000000
0
25 20 15 10 5
Count
0
5 10 15 20 25
Count
3
1
Ergebnis:
Die Einführungskosten (für 100 Named User) sind bei Unternehmen mit bisherigem Host-Einsatz ungefähr gleich hoch wie bei Unternehmen, deren betriebswirtschaftliche Anwendungsplattform sich bisher auf PC-Server-Ebene befand (kein signifikanter Unterschied bei einem 95%-Vertrauensintervall).
390
Anhang C
H 2.5: ISW (1) - SSW (2) ð Unternehmensgrösse (Anz. MA = A11)
Hypothese:
Grossunternehmen haben bisher häufiger Individualsoftware eingesetzt als KMUs.
Two-sample t test on A11 grouped by BSWARCH
(1 = bisher ISW-Einsatz, 2 = bisher SSW-Einsatz)
Group
1
2
N
59
25
Mean
1790.983
715.960
SD
3501.393
1145.617
2.107 DF =
78.8
1075.023
95.00% CI =
Prob =
59.492 to
0.038
2090.554
Pooled Variance t =
1.497 DF =
82
1075.023
95.00% CI =
Prob =
-353.568 to
0.138
2503.614
25000
20000
A11
15000
10000
5000
BSWARCH
2
1
0
90 80 70 60 50 40 30 20 10 0 10 20 30 40 50 60 70 80 90
Count
Count
Ergebnis:
Der festgestellte Unterschied ist statistisch nicht signifikant (95%).
391
Anhang C
H 2.6: ISW (1) - SSW (2) ð Gesamtkosten der Einführung (D111)
Hypothese:
Die Gesamtkosten bei der Einführung von R/3 sind bei Unternehmen, welche bisher Individualsoftware
(ISW) verwendet haben, höher als bei Unternehmen mit Standardsoftware-Einsatz.
Two-sample t test on D111 grouped by BSWARCH
(1 = bisher ISW-Einsatz, 2 = bisher SSW-Einsatz)
Group
1
2
N
41
15
Mean
5.378
2.087
SD
6.835
2.613
2.606 DF =
53.8
3.291
95.00% CI =
Prob =
0.759 to
0.012
5.823
Pooled Variance t =
1.808 DF =
54
3.291
95.00% CI =
Prob =
-0.358 to
0.076
6.940
35
30
D111
25
20
15
10
5
0
60 50 40 30 20 10 0 10 20 30 40 50 60
Count
Count
Ergebnis:
Es lässt sich kein signifikanter Unterschied (95%) feststellen.
392
BSWARCH
2
1
Anhang C
H 2.7: # auf Dauer einger. Schnittstellen (I41) ð Einführungskosten/100 User (Kost100U)
Hypothese:
Die Gesamtkosten einer R/3-Einführung werden von der Zahl der auf Dauer eingerichteten Schnittstellen zu Fremdsystemen beeinflusst.
I41
KOST100U
I41
1.000
0.154
KOST100U
1.000
0.847 DF=1 Prob= 0.357
I41
KOST100U
I41
0.0
0.357
KOST100U
0.0
Ergebnis:
Es lässt sich keine signifikante Abhängigkeit zwischen den Einführungskosten für 100 Named User
und der Zahl der auf Dauer eingerichteten Schnittstellen feststellen.
H 2.8: # auf Dauer eingerichtete Schnittstellen (I41) ð Einführungsdauer (PM100U)
Hypothese:
Der Personalaufwand einer R/3-Einführung wird von der Zahl der auf Dauer eingerichteten Schnittstellen zu Fremdsystemen beeinflusst.
I41
PM100U
I41
1.000
-0.049
PM100U
1.000
0.079 DF=1 Prob= 0.779
I41
PM100U
I41
0.0
0.779
PM100U
0.0
Ergebnis:
Es besteht kein signifikanter Zusammenhang (95%) zwischen dem Personalaufwand und der Zahl der auf
Dauer eingerichteten Schnittstellen.
393
Anhang C
H 3.1: Anzahl eingeführte Module (MOD) ð Gesamtkosten der Einführung (D111)
Hypothese:
Je mehr Module eingeführt werden, desto höher sind die Gesamtkosten einer R/3-Einführung.
MOD
D111
MOD
1.000
0.144
D111
1.000
1.221 DF=1 Prob= 0.269
MOD
D111
MOD
0.0
0.269
D111
0.0
Erklärung:
Zwischen der Zahl der eingesetzten Module und den Gesamtkosten einer Einführung lässt sich keine
signifikante Abhängigkeit feststellen.
H 3.2: # Named User (H82) ð Einführungskosten (D111A)
Hypothese:
Die Gesamtkosten einer R/3-Einführung werden von der vorgesehenen Benutzerzahl beeinflusst.
D111A
H82
D111A
1.000
0.887
H82
1.000
68.785 DF=1 Prob= 0.000
D111A
H82
D111A
0.0
0.000
H82
0.0
Dep Var: D111A
N: 47
Multiple R: 0.942
Effect
H82
Coefficient
Std Error
20416.015
1074.273
Std Coef Tolerance
0.942
1.000
t
P(2 Tail)
19.004
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
8.72161E+14
1 8.72161E+14
361.171
0.000
Residual
1.11081E+14
46 2.41481E+12
394
2.026
-0.021
Anhang C
(Nur Industriesektor)
D111A
H82
D111A
1.000
0.933
H82
1.000
33.691 DF=1 Prob= 0.000
D111A
H82
D111A
0.0
0.000
H82
0.0
Dep Var: D111A
N: 19
Multiple R: 0.972
Effect
H82
Coefficient
Std Error
19587.751
1121.179
Std Coef Tolerance
0.972
1.000
t
P(2 Tail)
17.471
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
2.26756E+14
1 2.26756E+14
305.224
0.000
Residual
1.33725E+13
18 7.42914E+11
2.117
-0.138
Ergebnis:
Die Kosten einer R/3-Einführung werden signifikant (95%) von der vorgesehenen Benutzerzahl (Named
User Zahl) beeinflusst.
395
Anhang C
H 3.3: Anzahl Module (MOD) ð Dauer der Einführung (KZ)
Hypothese:
Je mehr Module eingeführt werden, desto höher ist die Dauer einer R/3-Einführung (Kalenderzeit).
KZ
MOD
KZ
1.000
0.171
MOD
1.000
2.346 DF=1 Prob= 0.126
KZ
MOD
KZ
0.0
0.126
MOD
0.0
Ergebnis:
Die Zahl der eingeführten R/3-Module hat keinen statistisch signifikanten Einfluss (95%) auf die
Dauer eines R/3-Projektes (Kalenderzeit).
H 3.4: Anzahl Named User (H82) ð Dauer der Einführung (KZ)
Hypothese:
Mit zunehmender Benutzerzahl (Anzahl Named User) erhöht sich die Dauer einer R/3-Einführung
(Kalenderzeit).
KZ
H82
KZ
1.000
0.255
H82
1.000
4.692 DF=1 Prob= 0.030
KZ
H82
KZ
0.0
0.030
H82
0.0
Ergebnis:
Zwischen der vorgesehenen Benutzerzahl und der Dauer einer R/3-Einführung (Kalenderzeit) besteht
ein schwach signifikanter Zusammenhang (95%).
396
Anhang C
H 3.4a: Anzahl Named User (H82) ð Dauer der Einführung (PM)
Hypothese:
Mit zunehmender Benutzerzahl (Anzahl Named User) erhöht sich die Dauer einer R/3-Einführung
(Personenmonate).
PM
1.000
0.898
PM
H82
H82
1.000
61.639 DF=1 Prob= 0.000
PM
0.0
0.000
PM
H82
H82
0.0
Dep Var: PM
N: 40
Multiple R: 0.947
Effect
H82
Coefficient
Std Error
0.399
0.022
Std Coef Tolerance
0.947
1.000
t
P(2 Tail)
18.359
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
299143.690
1
299143.690
337.053
0.000
Residual
34613.560
39
887.527
2.301
-0.156
397
Anhang C
(nur Industriesektor)
H82
1.000
0.904
H82
PM
PM
1.000
19.574 DF=1 Prob= 0.000
H82
0.0
0.000
H82
PM
PM
0.0
Dep Var: PM
N: 14
Multiple R: 0.944
Effect
H82
Coefficient
Std Error
0.372
0.036
Std Coef Tolerance
0.944
1.000
t
P(2 Tail)
10.311
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
82369.873
1
82369.873
106.314
0.000
Residual
10072.127
13
774.779
1.628
0.179
Ergebnis:
Zwischen der vorgesehenen Benutzerzahl und der Dauer einer R/3-Einführung gemessen in Personenmonaten besteht ein statistisch signifikanter Zusammenhang (95%).
398
Anhang C
H 3.4b: # Personenmonate (PM) ð Einführungskosten (D111A)
Hypothese:
Je mehr Personenmonate für die Einführung von R/3 benötigt werden, desto mehr erhöhen sich die
Gesamteinführungkosten.
D111A
PM
D111A
1.000
0.966
PM
1.000
82.213 DF=1 Prob= 0.000
D111A
PM
D111A
0.0
0.000
PM
0.0
Dep Var: D111A
N: 33
Multiple R: 0.976
Effect
PM
Coefficient
Std Error
49304.931
1954.636
Std Coef Tolerance
0.976
1.000
t
P(2 Tail)
25.225
0.000
Source
Sum-of-Squares
DF
Mean-Square
F-Ratio
P
Regression
9.12802E+14
1 9.12802E+14
636.281
0.000
Residual
4.59069E+13
32 1.43459E+12
1.949
0.013
Ergebnis:
Zwischen der Zahl der für die Einführung vorgesehenen Personenmonate und den Gesamteinführungskosten besteht ein statistisch signifikanter Zusammenhang (95%).
399
Anhang C
H 4.1: Beraterqualität Gut-Schlecht ð Einführungsdauer (PM100U)
Hypothese:
Mit steigender Qualität der Beratungspartner sinkt die Dauer einer R/3-Einführung (Personenmonate
pro 100 Named User).
Two-sample t test on PM100U grouped by B_QUAL$
Group
GUT
SCHLECHT
N
23
27
Mean
60.261
56.811
SD
65.318
51.772
0.204 DF =
41.7
3.450
95.00% CI =
Prob =
-30.612 to
0.839
37.512
Pooled Variance t =
0.208 DF =
48
3.450
95.00% CI =
Prob =
-29.852 to
0.836
36.753
Ergebnis:
Es lässt sich kein signifikanter Unterschied feststellen.
H 4.2: Beraterqualität Gut-Schlecht ð Einführungskosten (Kost100U)
Hypothese:
Mit steigender Qualität der Beratungspartner sinken die Kosten einer R/3-Einführung für 100 Named
User.
Two-sample t test on KOST100U grouped by B_QUAL$
Group
GUT
SCHLECHT
N
29
25
Mean
2258148.700
2367012.637
SD
1454519.392
1450533.164
-0.275 DF =
50.9
Prob =
-108863.938
95.00% CI = -9.047E+05 to
0.785
6.869E+05
Pooled Variance t =
-0.275 DF =
52
Prob =
-108863.938
95.00% CI = -9.044E+05 to
0.785
6.867E+05
Ergebnis:
Es lässt sich kein signifikanter Unterschied feststellen.
400
Anhang C
H 4.3: Anzahl Projektmitarbeiter (PMA) ð Dauer der Einführung (KZ)
Hypothese:
Mit zunehmender Projektdauer (Kalenderzeit) steigt die Zahl der eingesetzten Projektmitarbeiter
(PMA).
PMA
KZ
PMA
1.000
0.553
KZ
1.000
PMA
KZ
PMA
1.000
0.553
KZ
1.000
20.589 DF=1 Prob= 0.000
PMA
KZ
PMA
0.0
0.000
KZ
0.0
KZ
PMA
PMA
KZ
Ergebnis:
Zwischen der Projektdauer (Kalenderzeit) und der Zahl der eingesetzten Projektmitarbeiter besteht
eine statistisch signifikante Abhängigkeit (95%).
401
Anhang C
H 4.4: Anz. Projektmitarbeiter (PMA) ð Kosten einer Einführung (KOST100U)
Hypothese:
Ein grössere Zahl von eingesetzten Projektmitarbeitern erhöht die durchschnittlichen Kosten einer
R/3-Einführung.
KOST100U
PMA
KOST100U
1.000
-0.025
PMA
1.000
0.023 DF=1 Prob= 0.879
KOST100U
PMA
KOST100U
0.0
0.879
PMA
0.0
PMA
KOST100U
KOST100U
PMA
Ergebnis:
Zwischen der Zahl der eingesetzten Projektmitarbeiter und den Kosten einer R/3-Einführung pro 100
Named User kann kein statistisch signifikanter Zusammenhang (95%) nachgewiesen werden.
402
Anhang C
H 4.5: Grad der org. Anpassung (GRADANP) ð Kosten einer Einführung (Kost100U)
Hypothese:
Je mehr sich ein Unternehmen an die Prozessvorgaben von R/3 anpasst, desto geringer sind die
durchschnittlichen Kosten einer R/3-Einführung für 100 Named User.
GRADANP
KOST100U
GRADANP
1.000
-0.193
KOST100U
1.000
1.924 DF=1 Prob= 0.165
GRADANP
KOST100U
GRADANP
0.0
0.165
KOST100U
0.0
Erklärung:
Zwischen dem Grad der organisatorischen Anpassung und den Kosten einer R/3-Einführung für 100
Named User kann kein statistisch signifikanter Zusammenhang (95%) nachgewiesen werden.
H 4.6: Grad der org. Anpassung (GRADANP) ð Dauer einer Einführung (PM100U)
Hypothese:
Je mehr sich ein Unternehmen an die Prozessvorgaben von R/3 anpasst, desto geringer ist die durchschnittliche Dauer einer R/3-Einführung für 100 Named User.
GRADANP
PM100U
GRADANP
1.000
0.024
PM100U
1.000
0.026 DF=1 Prob= 0.871
GRADANP
PM100U
GRADANP
0.0
0.871
PM100U
0.0
Ergebnis:
Zwischen dem Grad der organisatorischen Anpassung und der durchschnittlichen Dauer einer R/3Einführung für 100 Named User kann kein statistisch signifikanter Zusammenhang (95%) nachgewiesen
werden.
403
Anhang C
H 4.7: Freistellungsgrad (FG) ð Dauer einer Einführung (PM100U)
Hypothese:
Je höher der Freistellungsgrad der Projektmitarbeiter desto kürzer die Dauer einer R/3-Einführugn
pro 100 Named User.
FG
PM100U
FG
1.000
-0.009
PM100U
1.000
0.002 DF=1 Prob= 0.961
FG
PM100U
FG
0.0
0.961
PM100U
0.0
Ergebnis:
Zwischen dem Freistellungsgrad der Projektmitarbeiter und der Dauer einer R/3-Einführung pro 100
Named User lässt sich kein statistisch signifikanter Zusammenhang (95%) erkennen.
H 4.8: Freistellungsgrad (FG) ð Kosten einer Einführung (KOST100U)
Hypothese:
Je höher der Freistellungsgrad der Projektmitarbeiter, desto geringer sind die Kosten einer R/3Einführung pro 100 Named User.
KOST100U
FG
KOST100U
1.000
0.005
FG
1.000
0.001 DF=1 Prob= 0.980
KOST100U
FG
KOST100U
0.0
0.980
FG
0.0
Erklärung:
Zwischen dem Freistellungsgrad der Projektmitarbeiter und den Kosten einer R/3-Einführung pro 100
Named User besteht kein statistisch signifikanter Zusammenhang (95%).
404
Anhang C
H 4.9: Mit Outsourcing (1) - ohne Outsourcing (2) ð Kosten einer Einführung (KOST100U)
Hypothese:
Bei der Wahl eines systemtechnischen Outsourcings reduzieren sich die durchschnittlichen Kosten
einer R/3-Einführung (Kosten pro 100 Named User).
Two-sample t test on KOST100U grouped by H91
Group
1
2
N
18
36
Mean
2405461.313
2232819.623
SD
1352081.853
1497035.818
0.427 DF =
37.4
Prob =
172641.691
95.00% CI = -6.471E+05 to
0.672
9.924E+05
Pooled Variance t =
0.412 DF =
52
Prob =
172641.691
95.00% CI = -6.680E+05 to
0.682
1.013E+06
Ergebnis:
Zwischen den durchschnittlichen Einführungskosten pro 100 User und der Wahl einer OutsourcingLösung lässt sich kein statistisch signifikanter Zusammenhang (95%) feststellen.
H 4.10: Mit Outsourcing (1) - ohne Outsourcing (2) ð Dauer einer Einführung (KZ100U)
Hypothese:
Bei der Wahl eines systemtechnischen Outsourcings verkürzt sich die durchschnittliche Dauer einer
R/3-Einführung (pro 100 Named User).
Two-sample t test on KZ100U grouped by H91
Group
1
2
N
19
49
Mean
15.790
15.808
SD
14.135
15.223
-0.005 DF =
35.2
-0.018
95.00% CI =
Prob =
-7.943 to
0.996
7.907
Pooled Variance t =
-0.004 DF =
66
-0.018
95.00% CI =
Prob =
-8.076 to
0.997
8.040
Ergebnis:
Zwischen der Wahl einer Oursourcing-Lösung und der durchschnittlichen Dauer einer R/3-Einführung
(Kalenderzeit) besteht kein statistisch signifikanter Zusammenhang (95%).
405
Anhang C
H 4.11: Intensität der Planung (ANTPLAN) ð Dauer einer Einführung (KZ100U)
Hypothese:
Bei höherer Planungsintensität in den konzeptionellen Projektphasen reduziert sich die durchschnittliche Dauer einer R/3-Einführung (pro 100 Named User).
ANTPLAN
KZ100U
ANTPLAN
1.000
-0.167
KZ100U
1.000
0.948 DF=1 Prob= 0.330
ANTPLAN
KZ100U
ANTPLAN
0.0
0.330
KZ100U
0.0
Ergebnis:
Zwischen der Planungsintensität in konzeptionellen Phasen und der durchschnittlichen Einführungsdauer (pro 100 Named User) lässt sich kein statistisch signifikanter Zusammenhang (95%) feststellen.
H 4.12: Intensität der Planung (ANTPLAN) ðKosten einer Einführung (KOST100U)
Hypothese:
Bei höherer Planungsintensität in den konzeptionellen Projektphasen reduzieren sich die durchschnittlichen Kosten einer R/3-Einführung (pro 100 Named User).
ANTPLAN
KOST100U
ANTPLAN
1.000
-0.235
KOST100U
1.000
1.566 DF=1 Prob= 0.211
ANTPLAN
KOST100U
ANTPLAN
0.0
0.211
KOST100U
0.0
Ergebnis:
Zwischen der Planungsintensität in den konzeptionellen Phasen und den durchschnittlichen Kosten
einer R/3-Einführung (pro 100 Named User) lässt sich kein statistisch signifikanter Zusammenhang
(95%) feststellen.
406
Index
Index
A
ABAP/4 ...............................................................141
Akzeptanzprobleme ......................... 253; 266; 305
ALE-Konzept.......................................................134
Anlagenbuchhaltung.............................................71
Anwender
Einbezug.........................................................266
Schulung ..............................199; 283; 301; 328
Arbeitspläne........................................................103
Arbeitsplätze .......................................................103
ArchiveLink.........................................................131
Archivierungssysteme .........................................290
ARIS-Toolset .......................................................295
AS/400................................................................284
ASAP...................................................................338
B
Baan.......................................................12; 38; 246
BAPI............................................................. 22; 136
Basissystem .........................................................140
Bauteilekalkulation .............................................108
Bedarfsplanung...................................................105
Benutzerservicezentrum .....................................306
Benutzersupport .................................................305
Benutzerverwaltung............................................141
Beratungspartner .............................. 190; 273; 323
Auswahl................................................. 274; 282
Berechtigungsverwaltung....................................141
Bestandesführung ...............................................100
Betrieb ................................................................204
BOR......................................................................22
BPCS...................................................................246
BPR............................27; 185; 244; 284; 294; 329
Branchenherkunft...................................... 236; 237
Branchenlösungen ............................ 139; 237; 238
Buchungskreis.......................................................61
Business Engineer ...............................................143
Business Framework .................................... 23; 339
Business Object ........................................... 19; 339
Business Object Repository ..................................22
Business Planning .................................................85
C
CAD-Schnittstelle ...................................... 134; 290
Cash Management................................................74
CATT ..................................................................142
CBT-Software ................................... 200; 302; 303
CCMS .................................................................141
Change-Management ........................................ 184
Client/Server-Architektur ...........................148; 287
COM.....................................................................19
Component Ware.................................................19
Controlling..................................................... 68; 77
CORBA ........................................................ 19; 339
Customizing...............................................295; 297
D
Data Dictionary ................................................. 142
Datenbankverwaltung........................................ 141
Datenmigration.................................................. 203
Datenübernahme .............................................. 299
Probleme....................................................... 300
Debitorenbuchhaltung..........................................70
Desktop Applikationen ...................................... 290
Dienstleistungssektor .................................237; 241
Dokumentation ................................................. 198
Dokumentenverwaltung .................................... 133
E
EDI..................................................................... 291
Einführungsdauer......................268; 270; 315; 318
Einführungskosten............................. 276; 315; 318
Einführungsleitfaden .......................................... 144
Einkauf..................................................................98
Electronic Commerce ................................137; 151
Enterprise Applications .........................................12
Enterprise Resource Planning ...............................12
Enterprise-Management-System ................1; 10; 11
Auswahl............................................................25
Evaluation.........................................................32
Markt................................................................14
Entity-Relationship-Modell ...................................30
Entscheidkompetenzen ..................................... 255
Ereignisgesteuerte Prozessketten........................ 279
Erfolgsfaktoren ..........................178; 179; 207; 320
Ergebnis- und Marktsegmentrechnung .................80
Erzeugniskalkulation .......................................... 108
Evaluation ......................................... 188; 245; 284
Auslösende Faktoren..................................... 243
Expertenbefragung............................................. 205
Externe Berater .........................261; 262; 263; 273
Auswahl......................................................... 274
407
Index
F
ITS...................................................................... 138
Fachabteilung .................. 259; 260; 261; 262; 263
Fakturierung..........................................................96
Fertigungsaufträge...............................................107
Finanzbudgetmanagement ...................................75
Finanzmittelrechnung und -planung ....................74
Finanzwesen.................................................. 68; 70
Firewall ...............................................................138
Freistellungsgrad ........................................ 254; 272
Fremdsysteme ........................................... 290; 298
Führungsinformationssystem ................................83
Funktionsabdeckungsgrad ................ 249; 295; 297
J
G
Gemeinkostencontrolling .....................................78
Gesamtverantwortung ........................................260
Geschäftsleitung................................ 196; 259; 260
Unterstützung ................................................266
Graphische Benutzeroberfläche .........................288
Grossunternehmen.......... 234; 243; 259; 268; 275
GUI............................................................ 150; 288
H
Handelssektor............................................ 237; 240
Hardwarekosten .................................................318
Hauptbuchhaltung................................................70
Host-Umgebung .................................................284
Hypothesen ........................................................219
I
IAC......................................................................136
IDES....................................................................144
IDoc....................................................................131
IMG ....................................................................144
Inbetriebnahme ..................................................305
Indirekte Kosten..................................................276
Individualsoftware ................................................17
Industriesektor ........................................... 236; 239
Industry Solutions ...............................................140
Informatikabteilung ..................235; 260; 262; 263
Information Center.............................................306
Informix ..............................................................287
Instandhaltung ............................................. 87; 115
Integration ................................................... 10; 255
Internet ...............................................................250
Internet-Transaction-Server ................................137
Intranet ...............................................................250
Investitionsmanagement ................................ 68; 82
ISO .....................................................................112
Ist-Analyse ............................................................26
408
Jahr 2000-Problem ........................... 243; 285; 333
Java .................................................................... 251
Just-in-Time-Produktion .................................... 109
K
Kanban............................................................... 109
Kapazitätsplanung.............................................. 106
Klassifizierungssystem ........................................ 133
KMU ............... 234; 243; 258; 268; 272; 289; 291
Know-how-Transfer ...................................197; 284
Kommunikation ................................ 197; 283; 327
Kompetenzen ............................................196; 260
Konkurrenzprodukte.......................................... 246
Konsolidierung......................................................71
Konzern ............................................................. 242
Koordinationsprobleme ..................................... 254
Kosten................................................................ 275
Kostenartenrechnung............................................78
Kostenstellenrechnung..........................................78
Kostenüberwachung .......................................... 326
Kostenverteilung ................................................ 276
Kostenziele......................................................... 277
Kreditmanagement ...............................................95
Kreditorenbuchhaltung.........................................70
Kritische Erfolgsfaktoren............178; 208; 282; 320
L
Lagerverwaltungssystem .................................... 100
Leistungsrechnung ................................................79
Lenkungsausschuss ........................... 182; 195; 277
Grösse ........................................................... 261
Logistik......................................................... 86; 238
Logistikinformationssystem ...................................91
M
Machbarkeitsstudie............................................ 248
Macintosh .......................................................... 288
Management
Einbeziehung................................................. 284
Unterstützung.............. 182; 207; 266; 321; 324
Management-Konsolidierung................................84
Mandant ...............................................................61
Market Risk Management .....................................76
Maschinenindustrie ........................................... 236
Material Ledger.................................................. 101
Materialbewertung............................................. 101
Materialdisposition ...............................................99
Index
Materialstamm......................................................89
Materialwirtschaft .......................................... 87; 97
Methodische Unterstützung ...............................279
Methodisches Vorgehen ............................ 196; 284
Middleware ........................................................148
Moduleinsatz ......................................................238
Modulverantwortliche ........................................306
Motivation ................................................. 261; 266
MS Office ...........................................................290
N
Nachrichtensteuerung ........................................131
Named User .......................................................289
Netzpläne ...........................................................121
Nutzwertanalyse ............................................ 25; 41
O
Offenheit ............................................................153
OMG ....................................................................19
Oracle....................................................12; 38; 141
Oracle Applications ............................................246
ORB......................................................................20
Organisationsänderung.......................................296
Organisationseinheiten .......................................242
Organisationsmanagement ........................ 127; 129
OS/2 ...................................................................288
OSF-Motiv ..........................................................288
OSS.....................................................................307
Outsourcing ........................................................291
systemtechnisch .............................................292
P
Packaged Applications ..........................................12
Parametersetzung ...................................... 297; 305
Partnerkonzept .....................................................56
Peoplesoft...................................................... 12; 38
Performance-Probleme ......................................305
Personalabrechnung ...........................................126
Personaladministration- und -abrechnung .........123
Personalbeschaffung...........................................125
Personalplanung und -entwicklung ....................123
Personalwesen....................................................238
Personalwirtschaft...............................................123
Personalzeitwirtschaft .........................................125
Pflichtenheft .......................................................245
Portabilität ..........................................................153
Preisfindung..........................................................94
Problembereiche ................................................252
Produktionsplanung..............................................87
Produktionsplanung und -steuerung ..................101
Produktivstart
Probleme....................................................... 305
Produktkalkulation............................................. 108
Produktkostencontrolling......................................79
Profit-Center-Rechnung........................................85
Projektauftrag........................................................26
Projektcontrolling............................................... 283
Projektdauer ...................................................... 268
Projektgrösse..............................................258; 259
Projektkosten ..................................................... 275
Projektleiter ..............................193; 207; 263; 322
Anforderungen.............................................. 265
Auswahl......................................................... 283
Herkunft........................................................ 263
Probleme....................................................... 253
Projektmitarbeiter
Freistellungsgrad............................................ 254
Projektmitarbeiter ......................................195; 322
Anzahl ........................................................... 272
Freistellungsgrad........................... 195; 272; 322
Motivation..................................................... 278
Schulung ....................................................... 301
Projektorganisation ...................194; 258; 284; 321
Projektplanung................................................... 121
Projektsystem............................................... 88; 119
Projektteam
Zusammensetzung ........................................ 262
Projektverantwortung ........................................ 259
Projektziele ........................................................ 277
Abweichungen .............................................. 277
Erreichungsgrad............................................. 277
Überwachung................................................ 277
Prozessindustrie ................................................. 110
Prozesskostenrechnung ........................................81
Q
Qualitätsmanagement.................................. 87; 112
R
R/2 ..................................................................... 286
R/3-Referenzmodell........................................... 144
Rechnungsprüfung............................................. 101
Rechnungswesen ......................................... 68; 238
Rechtlichen Probleme ....................................... 256
Referenzmodelle .......................................196; 245
Reisekostenabrechnung ..................................... 126
Release-Planung ................................................ 201
Reorganisation ................................................... 244
RFC .................................................................... 139
409
Index
S
Sachziele.............................................................277
SAP AG .................................................................52
SAP Business Workflow ............................. 130; 145
SAP R/2.................................................................54
SAP R/3.................................................................55
Gründe für die Auswahl........................ 243; 248
Hauptprobleme..............................................252
Komplexität....................................................255
Module ............................................................58
Softwarefehler................................................255
SAP-Automation .................................................137
SAPScript ............................................................141
SAP-Vorgehensmodell............................... 143; 160
Kritik...............................................................176
Schnittstellen ............................................. 201; 298
dauerhaft........................................................298
temporär ........................................................298
Schnittstellenprogrammierung............................300
Schulung.......................... 199; 207; 301; 305; 328
extern.............................................................302
intern..............................................................302
Zeitpunkt........................................................304
Schulungssystem.................................................304
Sensitivitätsanalyse................................................43
Serienfertigung....................................................109
Service-Management..........................................118
Skalierbarkeit ......................................................152
Soll-Konzept .........................................................26
Source Code.......................................................297
Special Ledger ......................................................72
Standardsoftware............................................... 7; 9
Steuerungsausschuss...........................................261
Stücklisten...........................................................103
Super User..........................................................305
Systemadministration .........................................305
Systemarchitektur ...................................... 148; 200
Systemgrösse.......................................................289
Systemüberwachung...........................................141
T
Terminziele.........................................................277
Tools .......................................................... 279; 280
410
Transportsystem................................................. 141
Treasury ......................................................... 68; 73
Treasury Management ..........................................75
U
Unix................................................................... 287
Unternehmenscontrolling.............................. 69; 83
Unternehmensgrösse ................215; 232; 237; 313
User Exits ........................................................... 297
V
Variantenkonfiguration .........................................90
Veranstaltungsmanagement............................... 128
Verantwortung................................................... 260
Verfügbarkeitsprüfung ..........................................94
Verkauf .................................................................95
Versand.................................................................95
Versicherungsbranche........................................ 237
Vertragsgestaltung ............................. 186; 256; 284
Vertrieb.......................................................... 87; 93
Vertriebsunterstützung..........................................96
Visio ................................................................... 279
Vorgehensmodelle............................ 156; 196; 280
W
Werk.....................................................................61
Werkzeuge.................................................279; 280
Widerstände ...................................................... 244
Windows 95 ...................................................... 288
Windows NT..................................... 284; 287; 288
Workbench Organizer ....................................... 142
Workflow...................................................130; 145
World Wide Web .................................................34
WWW ..................................................................34
Z
Zielformulierung ........................................309; 325
Zielsetzungen................... 183; 207; 311; 321; 325
Klare Formulierung........................................ 283
Zukunftsaussichten ............................................ 250

SAP R/3 - Universität Bern

Transcription

Similar documents

Career Counseling: Entwicklungen und Trends in den USA

Ausgabe 21

LVS HintergrundwiSSen

Copter Communication Camp

Flexible Haushaltsplanung und Mittel

SAP R/3 IDES System

Religiöse Gemeinden als komplexe adaptive Systeme

Sicherheit und Rendite im Zeichen der Lilie

Broschüre Mitgliedschaft - hotelleriesuisse Graubünden