Paul Wenzel (Hrsg.

GeschiiftsprozeBoptimierung
mit SAP.Rj3
Modellierung, Steuerung und
Management betriebswirtschaftlich-
integrierter Geschaftsprozesse
 Wirtschaftsinformatik / Business Computing

DV-gestiilzte Produktionsplanung
von Stefan Oeters und Oliver Woitke
Die Strategie der integrierten Produktenentwicklung
von Oliver Steinmetz
Informationssysteme der Produktion
von Birgid S. Kranzle
Datenbank-Engineering fUr Wirtschaftsinformatiker
von Anton Hald und Wolf Nevermann
Management von DV-Projekten
von Wolfram Brummer
Praxis des Workflow-Managements
hrsg. von Hubert Osterle und Petra Vogler
Handbuch Interorganisationssysteme
von Rainer Alt und Ivo Cathomen
SAP, Arbeit, Management
hrsg. von AFOS
Betriebswirtschaftliche Anwendungen
des integrierten Systems SAP-R/3
hrsg. von Paul Wenzel
GeschaftsprozeBoptimierung mit SAP-R/3
hrsg. von Paul Wenzel
Client/Server-Architektur
von Klaus D. Niemann
QM-Handbuch der Softwareentwicklung
von Dieter Burgartz
Untemehmenserfolg mit EDI
von Markus Deutsch

Vieweg
Paul Wenzel (Hrsg.)

GeschiiftsprozeB-
oplilllierung
miISAP-Rj3
Modellierung, Steuerung und Management
betriebswirtschaftlich-integrierter Geschaftsprozesse

II
Vleweg
Das in dies em Buch enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie
irgendeiner Art verbunden. Der Herausgeber, die Autoren und der Verlag libernehmen infolgedessen
keine Verantwortung und werden keine daraus folgende oder sonstige Haftung libernehmen, die auf
irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht.

Aile Rechte vorbehalten

© Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden, 1995
Softcover reprint of the hardcover 1st edition 1995

Der Verlag Vieweg ist ein Unternehmen der Bertelsmann Fachinformation GmbH.

Das Werk einschlieBlich aller seiner Teile ist urheberrechtlich geschlitzt. Jede
Verwertung auBerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung des Verlags unzuliissig und strafbar. Das gilt insbesondere flir
Vervielfiiltigungen, Ubersetzungen, Mikroverfilmungen und die Einspeiche-
rung und Verarbeitung in elektronischen System en.

Gedruckt auf siiurefreiem Papier

ISBN-13: 978-3-528-05508-0 e-ISBN-13: 978-3-322-83724-0

DOl: 10.1007/978-3-322-83724-0
 Inhaltsverzeichnis

Inhaltsverzeichnis

Vorwort .... ... .... ...... .. ... ..... ....... .... ........ .. .. .... ..... .... ..... .... .. .... ... ..... XVII

Implementierung von Geschaftsprozessen mittels

SAP R/3: Unmoglichkeit oder Konigsweg?
Priv.-Doz. Dr. Thomas A. Gutzwiller

1 Oberblick .. ... ......... ...... ......... ...... ... ..... ... ... .... .. .. ............... .... ..... 2
2 Business Process Redesign .... ........ ... ........ ...... ............... ..... .... 2
3 Der Zusammenhang zwischen Unternehmensstrategie
und Geschaftsprozess ....... .... ... .. .... ... .... ...... .... ......... ... ... ... ... ... 4
4 Abbildung von Geschaftsprozessen auf das Informations-
system ...... ... ......... .... .... ... .... ... .. .. ...... ......... .... .. .. .. .... .... .... ... .. .. .. 6
5 M6glichkeiten zur Prozessimplementation .. .. .......... .. .... .. .... .. 8
6 Erfahrungen mit der Prozessimplementation mittels
SAP-R/3: Der K6nigsweg? ....... ... ... ... ................ .. .................. 10
7 Zusammenfassung und Fazit.. ... ....... ....... ... .... ..... ... .. ... .... .. .. . 12
Literaturhinweise .. ... .... .. ...... .... ... ......... ........... ...... .. .. .. ... ..... .. ....... .. 13

Modellbasiert~ Organisations- und Informations-

systemgestaltung unter Verwendung der R/3-
Referenzmodelle
Michael RosemanniThomas Rotthowe/Reinhard Schiitte

1 Oberblick ... ......... ....... .. .... .... .. .. ......... .. ... .. ....... .......... ....... .... .. 15
2 Konkretisierung aktueller Unternehmensstrategien ...... .. .... . 15
3 Architektur integrierter Informationssysteme ........ ..... ... ... .... 17
3.1 Beschreibungssichten ..... ... ...... ..... .... ... ... ...... .. ..... .... .. ... 17
3.2 R/3-relevante Modellierungsmethoden .. ..... ..... .. .. .... .. .. 20
3.3 Der R/3-Analyzer .. ....... .... ... ........ ...... ... .... ... ...... ... ........ . 28

v
Inhaltsverzeichnis

4 ProzelSmodelle bei der Rl3-Einfuhrung .. .. .. ........ ... ... .......... 31

4.1 Organisations- und Informationssystemgestaltung ...... 31
4.1.1 Modellbasierte Organisationsgestaltung .... ........ 31
4.1.2 Modellbasiertes Customizing ........ .. .. ................. 36
4 .2 ProzelSrealisierung und -an pas sung .... .. ........ ...... ......... 38
5 Zusammenfassung und Ausblick. .... .... .. ........ .. .. .. .......... .. .... . 40
Literatur ............... .... .......... ..... ...... .. ....... ..... ............ ..... ... ........ ..... .. 41

Wirtschaftliche R/3-Einfiihrung im Mittelstand

- Einsatzmoglichkeiten von Methoden und Tools
Dr. rer. pol. Andreas Bufgard

1 Oberblick .. ..... ......... .... ....... ... ....... .. .. ......... .. ... .... ........ ..... ...... . 44
2 Empirischer Befund der Befragung "Mittelstands-
fahigkeit Rl3" ... .. ..... ........ ... ........ .. ........... .. .. .. .. .... ........ ......... . 45
2.1 Branchenubergreifende Erfahrungen im COMET-
Anwenderkreis .... ... .. ..... ..... ... .... ...... ......... .... ........ ..... .... 46
2.1.1 Ablauf der Befragung ...... ............ .... ........ .. ......... 47
2.1.2 MelS- und Auswahlverfahren ...... .......... ...... .. .. ... 48
2.1.3 Interviewstrategie ....... ..... ............. .... ....... ... ....... . 49
2.2 Situation in mittleren Industrie- und Handels-
unternehmen ... .. .. ..... ... ....... .... .. ...... ..... .. .. .. ...... ... ........... 49
2.2.1 Neue Generation von Anwendungssoftware .... 50
2.2.2 Gestiegene betriebswirtschaftliche Anfor-
derungen .... .... ........ .. ..... ... ..... .. .... .. .. ... ........ ........ 52
2.2.3 Informationstechnischer Fortschritt ........ .. .. .. .. .. . 54
2.2.4 Breit verwendbare Standardsoftware ........ .... .... 55
2.2.5 Probleme der Integration und Koexistenz
mit Individualentwicklungen .. .. .. ...... ........ .. ...... . 58
2.2.6 Fachkraftemangel .. .. .. .. .. .. ........ .... .. .. ...... .... ......... 59

VI
 Inhaltsverzeichnis

3 ODYSSEUS - Mittelstandsorientierte Methoden-

entwicklung fur Rl3 ........... ... ... .. ......... .. .. ...... .......... ... ...... .. ... 60
3.1 Ziele der ODySSEUS-Methode .... ...... .. ... .. .................... 61
3.1.1 Pramissen der ODySSEUS-Methode ........... .. ..... 62
3.1.2 Heuristischer Druchbruch zum Basissystem
mit dem LIVE KIT ..... .... ........... ... ....................... 63
3.2 Von der ODYSSEUS-Methode zum Werkzeug
LIVE KIT ... ...... .... ...... .... .. .... ....... ... ...... ......... ...... .... ... ..... 64
3.2.1 Profilcheckliste, optionale Funktionsauswahl
und Reduktionscheckliste ..... ... .. ... ................ ..... 65
3.2.2 Zuordnungscheckliste .... ....... ............................. 68
3.2.3 Effektivitat nach Komplexitat der Anforde-
rungen ... ....... ..... ..... ..... .......... .. ................... ........ 69
3.2.4 Erfahrungen aus den LIVE KIT - Workshops .... 70
3.2.5 LIVE Modelling - Einbettung in ein Vorgehens-
modell ......... .. ........... .. ..... .... .. ... .. ........................ 72
3.3 Voraussetzung fur die GeschaftsprozeBgestaltung
im Mittelstand: Anpassende Referenzmodellierung ... .. 74
3.3.1 Bauplane fur betriebswirtschaftliche Informa-
tionssysteme .. ... ... ......... ........... ... ... .... .............. ... 75
3.3.1.1 Referenzmodelle zur Adaption von
Softwarebibliotheken .. ............... .. ... ... ... 75
3.3.1.2 Adaptions-Monitoring ... ............ .. .......... 76
3.3.1.3 Modellansichten - Typische L6sungen
der ODYSSEUS LIVE KIT-L6sungs-
bibliothek .... .. ........ ..... .... ... .. ... .. .... .... .. .. . 77
3.3.2 Luckenanalyse .................... ... ........... .. ..... ......... .. 79

Literatur ...... .... ........................................... ...... ...... .. .. .......... .. ........ 82

VII
Inhaltsve rze ichnis

Das SAP-R/3-Berechtigungskonzept
Dipl.-Inf. Michael Hofebauer

1 Dberblick ....... .. .. .... ....... ......... .. ..... .. ...... ........ .... .... ... .... .......... 84
2 Grundelemente des Berechtigungskonzepts ..... ........ ..... ..... 84
2.1 Berechtigungs-Feld ..... .... ..... ....... ........ ... ........... ...... .. .... 84
2.2 Berechtigungs-Objekt ... ...... ... ... ... ....... .. .............. .. .... .... 85
2.3 Berechtigung ... ... ..... ..... ...... ....... .. ....... ............ ..... ... ....... 85
2.4 Einrichtung von Berechtigungen .................................. 86
2.5 Berechtigungsprofil... ....... ... .... ..... ..... ....... ... ... ...... ......... 88
2.6 Einrichtung von Berechtigungsprofilen .. ..................... 88
2.7 SAP-Namenskonvention .. .... .... ..... ... ..... .. ................. ... .. 89
2.8 Benutzerstamm ... ....... .... ..... ... ... ....... ... .... .... ... ....... ... .. .. . 89
3 Versionenkonzept und Administration .. .... ... ........ ..... ..... ... .. 90
3.1 Versionenkonzept ..... .. ...... .. ..... .. .. ... ...... ..... ...... ...... ....... 91
3.2 Administration ........ ... .... ... .. ...... ......... .. ... ... .... .... ... ......... 91
3.3 Systemhilfen .. .. ...... .... .... .... ... ... .. .. .... .... ... .. ... ...... .... ...... .. 93
3.4 SAP· und Superuser.. .... .... ..... .. ........ .. ..... ... ............... .... 94
4 Einftihrung des R/3-Berechtigungskonzepts .... .... .... .. .. ........ 95
4.1 Konzepteinftihrung im Basisbereich ...... .......... ..... ... .... 95
4.2 Konzepteinftihrung im Anwendungsbereich .... .... .. .. ... 97
4.3 Einfuhrungsleitfaden - Bereich Finanzwesen .... ... ..... .. 98
5 SchluBbemerkung .......... ... .... ... .... .... ... .. ..... ....................... .. 100

SAP Business Workflow zur Steuerung von

Geschaftsprozessen
Dipl-Inf. (FH) Edgar BahmanniProf. Dr. Paul Wenzel

1 Dberblick ...... ... ........ .. ... .. ....... .... .... .... ...... ..... .. ..... .......... .. .... 102
1.1 Begriffliche Kiarung .. ..... ... ..... ..... ... ......... ... ... ......... .... . 102
1.2 Merkmale von Vorgangsverarbeitungssystemen ... .. .. . 104

VIII
 lnhaltsverzeichnis

1.3 Chaneen und Risiken ... .... .. .. .... ................ ... .. .... .......... 107
2 Einfilhrung von Vorgangsverarbeitungssystemen .............. 110
2.1 Voraussetzungen .. .. ......... ... ............. .. ....... .... ........... .... 110
2.2 Methodisehes Vorgehen .. .......... .. ............ .. ................. 111
2.2.1 Organisatorisehe Sieht.. ................................ .. .. 111
2.2.2 Teehnisehe Sicht .. .. ............. .. .. ......................... 112
2.3 Kategorien von Softwarepaketen .. .... ..... .. .................. 113
2.3.1 Diagramm oder Zeichnungstools ........ ............ 113
2.3.2 Traditionelle Workflow Tools ......... ................ . 113
2.3.3 CASE Tools u. Software Engineering Tools .. .. 114
2.3.4 Workgroup Programme ...... .. .. ......................... 114
2.3.5 Klassisehe Workflow Tools .... .......................... 114
3 Workflow und Optisehe Arehivierung ....... .. ...... ........ .... .. .. 115
3.1 Integration eines Arehivsystems .. .. .. .. .... .... .... ............. 116
3.2 Marktkonsequenzen .. ..................... .. .. .. .. .................. .. 118
4 Vorgangsverarbeitung im System SAP-R/3 ...... .. .. .. ........ .. .. . 119
4.1 Grundlagen .. .. ............................... .......... .................... 119
4.2 Grundelemente der Dokumentenverarbeitung .......... 121
4.3 Beispiel fur dokumentenbasierten Workflow ............ 122
4.4 Optirnierung von Gesehaftsprozessen .... ............. .. .... 128
4.4.1 Verarbeitung der Originalbelege .. .... ....... .. .. .... 128
4.4.2 Szenario: Automatisehe Postverteilung
von erfaBten Originalbelegen ................ .. .... .. 129
4.4.3 Voreinstellungen fur das "Pri.ihe Erfassen"...... 132
4.5 Bewertung des Workflows in SAP-R/3 ...... .. .......... .... 133
5 Ausbliek: SAP Business Workflow ..... .... ...... ...... .... .. ........ .. 136
6 SehluBbetraehtung .... .. .... ........................ .. .......... .. .. .. .. ........ 142
Literaturverzeiehnis ...... .... ..... ...... .. .. ........ .. .. ....... ....... ....... .. ..... .... 144
Anlage .. ............ ......... ....... ..... .... .. .. .... ... .......... ... .... ... .. ....... ... ...... . 146

IX
Inhaltsverzeichnis

Optische Archivierung und Dokument-

Management in SAP-R/3
Dipl.-Inf. Jiirgen Gulbins

1 Dberblick ........ .... .... ..... .. .... .... ......... .. ......... .. .... .... ....... .. ... .. .. 150
2 Das ArchiveLink-Konzept .................. .... .. .................. .... ... .. 151
2.1 Rl3-Dokumente im Archiv ....... ... ..... ....... ......... ..... ..... 152
2.2 Dokumententibernahme ........ .. ..... ... .... ................ ...... . 153
2.3 Rl3-fremde Dokumente .. ...... .. ... .. ...... .. .. .. .. ...... ........ ... 154
2.4 Archivierungsstufen ..................... ... ............................ 155
3 Erfassungsszenarien .. ..... .......... .. ........ ... ... ..... .... ...... .... .. ... ... 157
3.1 Erfassungsszenario: "Spates Erfassen" .... .. ...... .......... .. 158
3.1.1 Ablauf beim spaten Erfassen ....................... ... . 159
3.1.2 Vor- und Nachteile des spaten Erfassens .. ...... 161
3.2 Szenario: "Gleichzeitiges Erfassen" ........ .. .... .......... .... 162
3.2.1 Ablauf bei der Erfassung zum Bearbeitungs-
zeitpunkt. ......... ... ............. .... .... .... ............ .... ..... 162
3.2.2 Argumente zum direkten Erfassen .......... ... .. ... 163
3.3 Szenario "Frtihes Erfassen" .... .. .......... .... ................. .. .. 164
3.3.1 Schematischer Ablauf.. ...... .... .. .. .............. .. .... ... 164
3.3.2 Vor- und Nachteile des "Frtihen Erfassens" .... 167
3.4 Mehrfachzuweisungen ........................... .. ....... ............ 167
3.5 Drucklisten ..... .. .. ...... .. ... .... ... ...... ... ... .. .... .. ...... .. .... .... ... 168
4 Archivkonfigurationen ...... .................. ..... ................... .. ... ... 169
4.1 Verteilte Archive und Remote-Zugriffe .. ......... .. .... ..... 172
4.2 Remote Zugriffe .. .... ... ... ..... .... .... ...... ...... ... .. ........ ....... . 172
5 Zusammenfassung ... ...... ... ..... ....... ... .. .......... .... .................. . 174

x
 Inhaltsverzeichnis

Integration von Fremdprodukten in R/3 - Vorteile

der funktionalen Kopplung
Dipl.-Inf. Stephan Schilling

1 Oberblick ... ..... .. .. ....... ... ..... ......... ........ ....... ...... .......... ... ... .... 177
2 Anwendungsgebiete fur Desktop-Integration ...... ....... ...... . 178
2.1 Individuelle Frontends ...... .......... ... .... .... ... .... .... ......... . 178
2.2 Offline Applications ....... ..... .......... ... ... ..... .... .... .... ....... 178
2.3 Desktop Tool Integration ................. ...... .................... 179
2.4 Fremdanwendungen .. .. ..... ... .. ...... ........ .... .. ........ .... ..... 180
3 Schnittstellenvarianten ... .. .... ...... .. ....... ..... ...... ......... .. .. .. ... .. . 180
3.1 ODBC / Native SQL.. .. .. .. ................ ...... ..... .. ............. .. 181
3.2 RFC-CALLs .............. .. .... ....... .... .. ..... ........... ....... ..... .. .... 181
4 Entwicklungsschritte zur Integration .............. .... ................ 183
4.1 Konkrete Aufgabenstellung .... .. .... ........ .. ...... .............. 183
4.2 Losungskonzept .... ... .. ... .... ...... .... ..... ...... ... .... ...... .... .... 184
4.3 Softwareentwicklung ........ ...... ........... ...... .. .............. .. . 188
4.3.1 Desktop .... .... .... .. .. .... .... ............ ..... .. .. .. ... .. ...... .. 188
4.3.2 Backend ............ ...... .. .. .... ... ... .. .. ...... .... ........ ...... 189
4.3.3 Middleware ..... ... .. .. ......... ................ ............ ..... . 190
4.3.4 Testing, Dokumentation .. .......... .... .. .... .... ...... .. 191
4.3.5 Zertifizierung .. .... .. .............. .. ...... .. .... .. .. .. ... .. ..... 191
5 Starken und Probleme des Ansatzes .. .... .. ........ .. .......... .. .. .. 191

Integration heterogener Systeme:

Kopplung COPICS-MRP und SAP-R/3-Einkauf
Dipl-Inf. (FH) Karl-Heinz Reutter/Prof. Dr.-Ing. Herbert
GlOckle

1 Oberblick .. .. ..... .. .. .. ........ .. .. .. .. ..... .. .. .............. .... .... ....... .. ...... 194
2 Stufenkonzept ....... .... .. ............................ .. ...... ... .. .. .. .. .... ..... 195

XI
Inhaltsverzeichnis

3 Losungsansatz fur die Systemkopplung COPICS

und SAP-R/3 ............ .. .. ... .. ....... .... ...... .... .......... .. ......... .. ....... 196
4 Datentransfer IBM COPICS nach SAP-R/3 .. ........ ...... ......... 200
4.1 Die BATCH-INPUT-Schnittstelle .......... .. .... .... .. .. ......... 201
4.2 Fortschreibung der Beschaffungsauftrage .......... ........ 205
5 Ruckmeldungen von SAP-R/3 nach IBM COPICS ...... .. ..... 206
5.1 Anderungsbelege .................................. .... .................. 207
5.2 Erstellung und Obertragung der Ruckmeldungen .. .. . 208
6 Nachbetrachtung zur Losung ...... .. .. .................. .... .. ............ 210
Literaturverzeichnis ................... .... ..... .. .. .. ...... .. .. ......................... 212

Konzeption und Umsetzung einer System-

architektur fUr die Produktionssteuernng in der
ProzeSindustrie
Dr. Peter Loos

1 Oberblick ... .... ...... .. ... ... ... .. .. ..... .. .. .. ..... .. .. ........ .. .... .. .. .. ... ...... 214
2 Charakterisierung der ProzeBindustrie ...... ...... .. .. .. .. ........ ... 214
3 Das Projekt CAPISCE .... .... .. ...... .................. .. .. .................... 216
4 Die Anwendungsmodulkonzeption .. ........ .. .. .. .. .. .. .. ........ .. . 218
4.1 Ressourcenverwaltung ..... .. .... .......... .. ................. ..... ... 219
4.2 Rezeptverwaltung .... .. ...................... .. .. ...... .. ...... .... ..... 221
4.3 Bestandsfuhrung .. .... .... .... .... .. .. .... ...... ........ .. .. .. ...... ..... 226
4.4 ProzeBplanung .. ......... .. .. .................... .. .... .............. ..... 226
4.5 ProzeBmanagement .... .... .. ...... .. .......... .. .... .......... .. ...... 228
4.6 Verbindung zur ProzeBautomatisierung .......... .... ...... 230
4.7 Verbindung zu LIMS .. .. .... .... .. ........ .. ...... .. .... .. .... .. ....... 230
4.8 Dokumentation und Auswertung .... ...... .. .. ...... .. .. ....... 231
5 Systemintegration .. .. ........ ......... ... ....... .... .. ..... ......... ...... ....... 232
6 Pilotinstallationen ... ..... ..... .. .... ...... ..... .... .. ...... .. .. .... .... .. ........ 234
Literaturverzeichnis .................. ... .. .. ......... .. ......... .... .. .. ... ........ .. ... 235

XII
 lnhaltsverzeichnis

Bericht tiber das Projekt

"Einheitliche Anlagenabwicklung Vertrieb" (EAV)
am Beispiel des "Internationalen Fachbereichs
Hochspannungstechnik" der AEG Daimler Benz
Industrie
Theo G. Sulzmann

1 Dberblick .......................... .... ............... .... ... .... ..................... 238

1.1 Projektziel ......... ...... ........................................... ......... 238
1.2 Zum Unternehmen ........... ............................... ........ ... 238
2 PRO]EKTMANAGEMENT ALS AUSGANGSBASIS .............. 239
3 ANLAGENGESCHAFf ................................................... ...... 241
3.1 Besonderheiten und Anforderungen .. ....................... 241
3.2 Die technischen Strukturen einer Anlage .................. 242
3.3 Die Angebotskalkulation ............................................ 242
3.4 Zusammenspiel der vorhandenen DV-Systeme ......... 243
4 UMSETZUNG IN SAP R/3 ............................. ...................... 245
4.1 Projektabwicklung und Struktur. ....................... ......... 245
4.2 Projektkontroll-Termine .............................................. 247
4.3 Projektkontroll-Kosten ............................... .... ............. 248
5 VORGEHENSWEISE ............................ ........ ........................ 250
5.1 Das Projektteam und die Methodik ..... ...................... 250
5.2 Der Projektplan als Richtschnur ............. .................... 251
6 DIE UMSETZUNG .... ........................... .... ............................ 253
6.1 Das Fachkonzept mit den Geschaftprozessen ........... 253
6.2 Vom Fachkonzept in die R/3-Anwendung und
die Dokumentation ................... ....................... .... .. ..... 255
6.3 Der Feldversuch ...................................... .. .................. 256
6.4 Der Know-how-Transfer. .................................... ........ 257

XIII
Inhaltsverzeichnis

Wellpappeproduktion - ein Fall fUr

branchenunabhangige Standardsoftware?
Prof. Dr. Alfred Taudes/Dr. Martin Lukanowicz/Peter
Schneider

1 Oberblick ........... ........ .. ...... .. .... ............. ........ .. .......... .. .... ..... 259
2 Wellpappeproduktion - Produkteigenschaften,
Produktionsablauf und Wettbewerbsfaktoren ................... 259
3 Informationssysteme in der Wellpappeproduktion ........... 263
3.1 Die Variantenproblematik .......................................... 263
3.2 Stucklistenkonfiguratoren - neue Werkzeuge
zur Bewaltigung der Variantenproblematik ............... 266
4 Einftihrung von branchenunabhangiger Standard-
software in der Wellpappeproduktion ............................... 268
5 Zusammenfassung .............................................................. 273
Literaturverzeichnis .......... ........................................................... 274

Paneuropaisches Informationsmanagement mit

SAP-R/3
Dipl.-Wirtsch.-Ing. Dr. Siegbert Kern

1 Oberblick ........................... .. ................................................ 276

2 Paneuropaische Geschaftsprozesse und Fuhrungs-
strukturen ......... .... .............. .. .............. .. ......... .. .. ............. ..... 277
3 Losungsmoglichkeiten mit SAP-R/3 ................................... 281
4 Ausblick ............................................................................... 289

XIV
 Inhaltsverzeichnis

SAP-Ausbildung im Wandel
Dipl.-Inf. Ulrich Bartels/Christoph Siebeck

1 Anforderungen an die Anwenderschulung ... ............ ........ . 291

2 Die klassische Ausbildungsmethode - Serninare .... ... .... .... 292
3 Die alternative Ausbildungsmethode - CBT ...................... 299
4 Rahmenbedingungen fur den Einsatz von CBT ...... ..... ... .. 306
5 Mindestanforderungen an ein CBT-Programm ............... ... 308
6 Die R/3-Schulung der Zukunft ........ .... ...... ...... ... ......... ..... .. 312

Projektausschnitte Integration SAP-R/3

Planung und Konzeption fiir Schulung
(Aus-, Fort- und Weiterbildung)
Stefanie FrankeniDipl.-Ing. Nils H. Jorgensen

1 Dberblick ............ .. .... ...... ....... ......... ... ........ ........... .......... ..... 316
2 Betrachtungsweise der SAP-R/3-Schulung ........ ... .... .... ...... 317
3 SAP-R/3-Basisanforderungen in der Ausbildung .... ....... .... 318
3.1 Das Anforderungsprofil .. ... .... .... .. ..... ..... ... ....... .. .. ...... . 319
3.2 Schulungsbedarf.... .... .. .. .. ... .. ... .. .. .. .... .. .. .. .. .... ........ .. .. .. 319
4 R/3-Ausbildungsmethoden u. -MaBnahmen .... ....... .... .... ... 322
4.1 "Live-Training" ... ...... ......... ...... ..... ... ..... .... .. ........ ...... ... 322
4.2 "Computer Based Training" (CBT) ... .... .. ...... ... ... ..... ... 322
4.3 "Lemen durch Anwendung" .... .... .... ..... ............ ... .. ... .. 324
4.4 "Lernstoff durch Lesen" ... ....... ............ .... ... ... .. .......... .. 324
5 Sicherung der AusbildungsmaBnahmen .. .. ...... ....... ... ..... ... 325
5.1 "Medium & Workshop"-Konzept. ....... .... ... .... .. .. .. ... .. .. 325
5.2 Konfiguration - "Medium & Workshop" .. .... ....... ....... 326
5.3 Verteilung "Medium & Workshop" .... .. ... ... ... .... ......... 328
5.4 Die Realisierung "Medium & Workshop" .. ...... .. .. ...... 329
5.5 Indikation und Ziele "Medium & Workshop"... ......... 330

xv
Inhaltsverzeichnis

6 Kostenvergleich der Ausbildungsmethoden ... .. ... .... ....... .. . 332

6.1 Kosten fUr Live-Training ... ... ....... .... ........ ....... ...... .. ..... 334
6.2 Kosten filr "Medium & Workshop" ... ... ...... ... ... ........ .. 335
6.3 Kostenvergleich ...... ..... .... ...... ....... .... .... .... .... ... .... ....... 336
7 Fazit ... .. .. .. ..... .. ..... ... .... ... ........ .. ...... .... ....... ... .... .. .... ... ... ..... ... 337

Autorenverzeichnis .............................................................. 338

Stichwortverzeichnis ............................................................ 346

XVI
 Vorwort

Vorwort
Zunehmend werden die Arbeitsplatze in unternehmensweite
Datenverarbeitungs-, Informations- und Kommunikations-
Systemen integriert und die Geschaftsprozesse durch flexible,
benutzerangepaBte "Standard-Software" unterstiitzt, die mit der
individuellen Datenverarbeitung korrespondiert.
Die Software zur Unterstiitzung betrieblicher Geschaftsprozesse,
also die Anwendungsprogramme zur Abwicklung der logisti-
schen Ablaufe (sowohl qualitativ als auch quantitativ) sowie zur
Ergebnisrechnung und -kontrolle im Sinne des Unternehmens-
controlling wurde bis vor wenigen Jahren meist von Informatik-
abteilungen der Unternehmen selbstentwickelt und gepflegt.
Idealtypischerweise wurde und wird dabei eine integrierte Ge-
samtlosung fOr samtliche betriebliche Funktionsbereiche auf Ba-
sis redundanzfreier Daten angestrebt.
Infolgedessen wurden in den Unternehmen in der Vergangen-
he it urnfangreiche Informatikabteilungen zur Entwicklung, pflege
und zum laufenden Betrieb derartiger DV-Systeme aufgebaut.
Der in den letzten Jahren erhohte Kostendruck auf die Unter-
nehmen auBert sich jedoch nun u.a. in einem geplanten Dber-
gang von GroBrechnern auf vernetzte, dezentrale Systeme (z.B.
Client/Server-Systeme unter UNIX) und softwareseitig in einem
verstarkten Trend zu Standardanwendungsprogrammen, wie
bspw. der betriebswirtschaftlichen Standardlosung "SAP-R/3".
Die Beitrage in diesem Sammelband zum Thema "Geschafts-
prozeBoptirnierung mit der Standard-Software SAP-R/3" stammen
von Praktikern und Hochschullehrern, die durchweg Ober lang-
jahrige Erfahrungen im Umgang mit betriebswirtschaftlicher An-
wendungssoftware verfugen.
Bei der Zusammenstellung der einzelnen Beitrage wurde keinen
Wert auf durchgangige inhaltliche Konsistenz gelegt, sondern
vielmehr auf die Darstellung einzelner projektspezifischer Er-
kenntnisse. Denn gerade aus der projektrnaBigen Umsetzung
einzelner Problemstellungen - im Rahmen der Einfuhrung von
Standardsoftware - resultieren wertvolle praxisnahe Informatio-
nen fur den Einstieg in die Thematik "GeschaftsprozeB-
optimierung" im betrieblichen Alltag.

xvn
Vorwort

Bei der Zusammenstellung der Inhalte dieses Sammelbandes war

es das Ziel, eine mbglichst grolSe Spannweite an R/3-spezifischen
Themen - von "A" wie Ausbildung bis "W" wie Workflow - zu
erreiehen. Das Spektrum der vorgestellten Inhalte kann aufgrund
der Vielzahl projektspezifischer Problemstellungen eine wOn-
schenswerte Beschreibungstiefe nur ansatzweise erreichen. Be-
sonders auf diesem Gebiet der analysierenden, tiefgreifenden
Fachliteratur fehlen derzeit ausreiehende Werke, urn dem Ent-
scheider und fachkundigen Interessenten eine weiterfuhrende
Mbglichkeit der Wissensbefriedigung urn das Thema "Standard-
Software mit SAP-R/3" zu erbffnen.
Die in dies em Buch beschriebenen Projekte zur Verbesserung
betrieblicher Ablaufe und zur Optimierung von Geschaftsprozes-
sen zeigen dem Leser die spezifische Verbindung von Betriebs-
wirtschaft und Informatik in der angewandten Form einer pra-
xisnahen Wirtschaftsinformatik.
Dr. Thomas A. Gutzwiller von der Hochschule St. Gallen und
geschaftsfuhrender Partner der IMG Information Management
Gesellschaft, St. GalleniMilncheniVaduz/Breslau, schafft die Ba-
sis filr ein gemeinsames Verstandnis von Geschaftsprozessen.
Dabei hinterfragt er - aus der Sieht einer Geschaftsleitung - den
Ansatz von Business Process Redesign mittels SAP-R/3, die Zu-
sammenhange zwischen Unternehmensstrategien und Geschafts-
prozessen, die Abbildung von Geschaftsprozessen auf betriebli-
che Informationssysteme und die Mbglichkeiten zur ProzelSim-
plementation.
Michael Rosemann, Thomas Ronhowe und Reinhard SchUt-
te vom Institut filr Wirtschaftsinformatik der Westfalischen Wil-
helms-Universitat Milnster, konkretisieren in ihrem Beitrag ak-
tuelle Unternehmensstrategien in bezug zu objektbezogenen und
funktionsilbergreifenden Geschaftsprozessen. Sie stellen die Ar-
chitektur integrierter Informationssysteme vor und beschreiben
auf hohem Abstraktionsniveau unternehmensindividuelle Pro-
zeBmodelle in den Konfigurations-, Realisierungs- und Anpas-
sungsphasen.
Dr. Andreas Hufgard von der IBIS Prof. Thome GmbH in
Wilrzburg stellt eine Wirtschaftlichkeitsstudie vor, die vor allem
die Situation in mittleren Industrie- und Handelsunternehmen
vor und mit der Einfilhrung von SAP-R/3 analysiert. Er be-
schreibt die Hinleitung zu einem "ertraglichen" Continous Syste-
mengineering, das anstatt aufwendige Sprilnge, viele kleine

XVIII
 Vorwort

schnelle Schritte zu einer verbesserten Informationsqualitat ver-

langt.
Michael Hofebauer von der Fa. RATIODATA Informationssy-
sterne, Wirtschaft und VeIWaltung GmbH in Koln beschaftigt sich
mit Grundelementen von Rl3-Berechtigungskonzepten, mit der
Festlegung von komplexen Berechtigungen, dem hierarchischen
Aufbau von Berechtigungselementen und der Verteilung der
Administrationsaufgaben.
Edgar Bahmann von der Fa. iXOS Software GmbH, Grasbrunn
bei Munchen und Prof. Dr. Paul Wenzel von der Fachhoch-
schule fur Technik, Wirtschaft und Gestaltung in Konstanz zei-
gen in ihrem Beitrag die grundlegenden Argumente zur Optimie-
rung von Geschaftsprozessen uber Workflowkonzepte. Neben
den Voraussetzungen, Chancen und Risiken bei Einfuhrung von
Vorgangsverarbeitungssystemen wird auf die optische Archivie-
rung und die exemplarische Umsetzung von SAP Business
Workflow im Rl3-System eingegangen.
(In der Anlage zu diesem Beitrag befindet sich eine ausfuhrliche
Produktubersicht uber Workflow-Management-Programme mit
den entsprechenden Herstellern.)

Jiirgen Gulbins von der Fa. iXOS Software GmbH, Grasbrunn

bei Munchen, beschreibt die optische Archivierung und das Do-
kument-Management in SAP-Rl3. Er geht dabei auf das
"ArchivLink-Konzept", auf die unterschiedlichen Erfassungsszen-
arien und die verschiedensten Archivkonfigurationen mit Rl3
ein.
Stephan SchiUing von der Firma icons information & communi-
cation network systems gmbh in Ennepetal, beschaftigt sich mit
den Vorteilen einer funktionalen Kopplung bei der Integration
von Fremdprodukten in Rl3. Ober Techniken, wie bspw. OLE,
ODBC, Software Development-Kit, kann eine Integration vor-
handener Desktop-Anwendungen ermoglicht werden, urn die
Geschaftsprozesse des Users homogener und schlanker zu ge-
stalten. Ferner werden Anwendungsgebiete fur Desktop-
Integration, Schnittstellenvarianten sowie Entwicklungsschritte
zur Software-Integration vorgestellt.
Karl-Heinz Reutter von der Fa. TANGRAM, Gesellschaft fur
Informations- und Kommunikationsmanagement mbH in Gar-
tringen und Prof. Dr.-Ing. Herbert Glikkle von der Fachhoch-
schule fur Technik und Wirtschaft in Reutlingen beschreiben die
Integration heterogener Systeme, am Beispiel der Kopplung von

XIX
Vorwort

COPICS-MPR und SAP-R/3 (EinkauD. Auf Grundlage der Neuge-

staltung von Geschaftsprozessen werden das Stufenkonzept, der
Lbsungsansatz fur die Systernkopplung, der Datentransfer und
die Ruckmeldungen zwischen R/3 und IBM-COPICS erbrtert.
Dr. Peter Loos vom Institut fur Wirtschaftsinformatik - IWi an
der Universitat des Saarlandes in Saarbrucken stellt in seinem
Beitrag den besonderen Charakter der ProzeBindustrie bei der
verfahrenstechnischen Umwandlung ungeformter Rohstoffe und
Endprodukte, insbes. in der chemischen und pharmazeutischen
Industrie, in den Vordergrund. Eine wichtige Pramisse - hier ge-
zeigt am Projekt CAPISCE - ist die Integration der lang- und mit-
telfristigen Planung und der ProzeBautomation im Sinne einer
ganzheitlichen GeschaftsprozeBuntersti.itzung.
Theo G. Sulzmann von der AEG Daimler Benz Industrie in
Frankfurt berichtet uber das Projekt "Einheitliche Anlagenabwick-
lung Vertrieb" (EAV) am Beispiel des "Internationalen Fachbe-
reichs Hochspannungstechnik" der AEG Daimler Benz Industrie.
Er beschreibt die Projektziele, das Projektmanagement, die Pro-
jektabwicklung und -vorgehensweise, das Fachkonzept mit den
Geschaftsprozessen bis zum Fachkonzept in der R/3-Anwendung
mit der entsprechenden Dokumentation.
Peter Schneider von der Fa. Duropack Wellpappe Gesellschaft
mbH, Dr. Martin Lukanowicz und Prof. Dr. Alfred Taudes
vom Institut fur Informationsverarbeitung und Informationswirt-
schaft, Abteilung fur Industrielle Informationsverarbeitung der
Wirtschaftsuniversitat Wien evaluieren die wichtigsten Problem-
felder einer branchenunabhangigen Standard-Softwareeinfuh-
rung im Bereich der angebotenen Sti.icklistenkonfigurationen
(PPS-Komponenten) fur die Wellpappebranche.
Dr. Siegbert Kern von der Fa. RUBBERMAID GmbH in Diet-
zenbach beschreibt paneuropaische Geschaftsprozesse und Fuh-
rungsstrukturen aus europaweit agierenden Unternehmensberei-
chen "Verkauf" und "Logistik". 1m weiteren werden aufgezeigt,
welche Lbsungsmbglichkeiten fur eine optima Ie europaweite
DV-Unterstutzung existiere, und welche generellen und speziel-
len Anforderungen von SAP-R/3 in bezug auf ein paneuropai-
sches Informationssystem erfullt werden.

xx
 Vorwort

Ulrich Bartels von der Fa. CLS InterService Gesellsehaft fur

Unternehmensberatung und Informationsverarbeitung mbH in
Bonn und Christoph Siebeck als selbstandiger EDV-Faeh-
journalist erortern den Wandel in der SAP-Ausbildung. Dabei be-
sehreiben sie Anforderungen an eine effiziente Anwendersehu-
lung, klassisehe Ausbildungsmethoden (Seminare), alternative
Ausbildungsmethoden (CBT), Rahmenbedingungen und Min-
destanforderung an CBT-Programme sowie eine modulare, mul-
timediale R/3-Sehulung der Zukunft.
Stefanie Franken und Nils H. Jorgensen von der Fa. NETG
Applied Learning GmbH in Willich stellen einen wesentlichen
Erfolgsfaktor bei der Optimierung des Integrationsprozesses von
SAP-R/3-basierenden DV-Strukturen vor: die Vorgehensweise
und Betraehtung der Ausbildungs- und SehulungsmaBnahmen
der Endanwender (Mitarbeiter). Neben der Vorstellung eines
"Medium & Workshop"-Konzeptes beleuehten die Autoren ins-
besondere die wesentlichen Kosten der jeweiligen Ausbildungs-
maBnahmen und geben Anregungen fur eine betriebswirtsehaft-
liehe Budgetierung bei der methodisehen und teehnisehen Um-
setzung von TrainingsmaBnahmen.

Fur die gesehatzte Mitarbeit und das Engagement der Autoren

bedanke ich mich herzliehst. Zuletzt danke ich ganz besonders
meiner lieben Frau, die viele Tage und Woehen das Lektorat fur
dieses Werk ubernommen hat.

Paul Wenzel, Hainburg imjuni 1995

XXI
Implementierung von Geschaftsprozessen
mittels SAP Rl3: Unmoglichkeit oder
Konigsweg?

Priv.-Doz. Dr. Thomas A. Gutzwiller

IMG - Information Management Gesellschaft, St. Gallen

1
1 Oberblick

1 Uberblick
In der Informatik-Presse wird das Thema SAP R/3 sehr kontro-
vers diskutiert. Die Kommentare reichen von totaler Begeiste-
rung bis zur abgriindigen Ablehnung. Mit dem nachfolgenden
Beitrag solI die Diskussion urn SAP R/3 einmal von einer ande-
ren Warte aus erfolgen: aus der Optik einer Geschaftsleitung in
einem sich transformierenden Unternehmen. Es sollen insbeson-
dere folgende Fragestellungen beantwortet werden: Was haben
Business Process Redesign und SAP R/3 miteinander zu tun? Was
kann SAP R/3 hier bieten? Wieso laufen Business Process Rede-
sign-Projekte oft aus dem Ruder, wenn es an die Implementation
der Prozesse ins Informationssystem geht? Worauf ist im Imple-
mentationsprozeB besonders zu achten?

2 Business Process Redesign

Business Process Redesign ist ein vieldiskutiertes Management-

thema, von dem in der Praxis tiber extreme Erfolge sowie MiBer-
folge berichtet wird. Die Fachleute sind sich aber einig, daB Bu-
siness Process Redesign eine neue Ara in der Managementlehre
erbffnet hat.
Nicht nur die prozeBorientierte Sichtweise, die dem Business
Process Redesign inharent ist, ist neu. Ein weiteres Novum cha-
rakterisiert die neue Ara: Es werden ingenieurmaBige Methoden
auf die (Neu-)Strukturierung von Unternehmen angewendet.
Interessant ist, daB die Methoden des Business Process Rede-
signs ihre Wurzeln in der wissenschaftlichen Disziplin des Soft-
ware-Engineerings haben. Aus diesem Grunde ist es leicht nach-
vollziehbar, daB Promotoren und Exponenten in der Arena des
Business Process Redesigns, wie z.B. Hammer [1], Scheer [2] oder
bsterle [3], aus dem universitaren Bereich kommen und einen
"Wirtschaftsinformatik-Hintergrund" haben.

2
 2 Business Process Redesign

Die Prinzipien des Software-Engineerings haben in den letzten

zwei Dekaden die Softwareentwicklung von der Kunst zur In-
genieurdisziplin entwickelt. Eine Analogie existiert fur das Busi-
ness Process Redesign, das vor allem in Europa daran ist, den
gleichen Weg einzuschlagen. Wir sprechen in diesem Zusam-
menhang von Business-Engineering (3). Es ist heute moglich, das
Geschaft, ausgehend von einer definierten Unternehmensstrate-
gie, ingenieurmaBig zu entwerfen. Dies ist der eigentliche
Durchbruch, der mit Business Process Redesign erzielt wurde:
weg von der intuitiven Reorganisation von Strukturen und Ab-
laufen, hin zu einem ingenieurmaBigen Entwurf des Geschafts-
systems.
DaB heute mehr Meldungen iiber Flops von Business Process
Redesign-Projekten als Erfolgsmeldungen zu vernehmen sind,
hat vielschichtige Griinde. Zu starkes Festhalten am Ist-Zustand,
schlechte Informationspolitik wahrend des Transformations-
prozesses, mangelndes Management Commitment, ungeniigende
Analyse der Kundenbediirfnisse, Analyse von ProzeBketten bis
zum ExzeB, mittelmaBige Projektmitarbeiter etc., so lauten die
Auswertungen iiber gescheiterte Redesign-Projekte. Der Schliis-
selfaktor fur den Erfolg oder MiBerfolg eines Business Process
Redesign-Vorhabens im Zeitalter der ISO 9000-Norrnreihe (4) und
Humphrey's ProzeB-Reifeschema [5) ist ganz eindeutig: der Pro-
zeB des Business ProceB Redesigns muB beherrscht sein. Dies ist
aber allzuoft nicht der Fall. Wiirden heute alle Business Process
Redesign-Projekte anhand von Humphrey's ProzeB-Reifeskala
bewertet, wiirde mancher ProzeB-Auditor zum SchluB kommen,
daB sich sehr viele dieser Projekte auf der initialen, unorgani-
sierten, sogenannten 'chaotischen' Ebene bewegen. Projekterfolg
resp. MiBerfolg wird so zu einem eigentlichen Lotteriespiel und
ist stark abhangig von den Personlichkeiten, die im Projekt
vertreten sind. Verschiedene universitare Einrichtungen und
Unternehmensberatungsgesellschaften haben diesen Mangel
erkannt und bieten heute ProjektprozeBmodelle an, resp.
arbeiten noch an soIchen, die den Business Process Redesign-
ProzeBstrukturieren. Wenn es sich dabei urn in der Projekt-
arbeit mehrfach validierte und optimierte Methoden handelt,
werden unter Anwendung soIcher Projekt-ProzeBmodelle Busi-
ness Process Redesign-Projekte wesentlich sicherer. Bekannte
Exponenten in diesem Kontext sind z.B. die St. Galler Metho-
den PROMET®BPR (6) - ein ProzeBmodell fur die Abwick-
lung von Business Process Redesign-Projekten - sowie PRO-
MET®SSW (7) fur die prozeB-orientierte Implementation neuer

3
3 Der Zusammenhang zwischen Untemehmens-strategie und Geschajtsprozefl

Geschaftssysteme mit Hilfe der Standardsoftware SAP Rl3 oder

anderer hochparametrisierter Produkte.
Abb. 1 zeigt schema tisch den Zusammenhang zwischen Ge-
schaftsstrategie, Prozessen und Informationssystem. In den
nachfolgenden zwei Kapiteln wird der Zusammenhang zwischen
Geschaftsstrategie und Prozessen einerseits sowie zwischen Pro-
zessen und Informationssystem andererseits kurz besprochen.
Abbildung 1:
PROMET®BPR: PROME~BPR
Untenehmens-
strategie -
Prozesse - Informati-
onssystem

Infonnatlonssvslam

3 Der Zusammenhang zwischen Unternehmens-

strategie und GeschaftsprozeB
Ein methodisch sauber fundiertes Business Process Redesign
fuhrt zu einer konsequenten und ingenieurmaBigen Implemen-
tierung der Unternehmensstrategie.
Eine Unternehmensstrategie definiert im wesentlichen, welche
Produkte Cz.B. Videorecorder und Fotoapparate) auf welchen
regionalen Markten Cz.B. Deutschland, Osterreich und
Schweiz) an welche Segmente Cz.B. private Endverbraucher,
Medienschaffende und Unterhaltungselektronik-Fachgeschafte)
vermarktet werden. Die Kombination aus Produkt, regionalem
Markt und Segment wird 'strategisches Geschaftsfeld',
'strategische Geschaftseinheit' o.a. genannt.

4
3 Der Zusammenhang zwischen Untemehmensstrategie und GeschiiJtsprozess

Ein GeschaftsprozeS wird identifiziert durch ein homo genes

Bundel von Leistungen, das fur einen (externen oder internen)
Kunden erbracht wird.
Eine Leistung ist eine Interaktion, die zwischen ProzeBkunde
und ProzeB stattfindet resp. ein Objekt, das dazu dient, eine sol-
che Interaktion herzustellen, z.B. ein Akquisitionsgesprach, ei-
nen Prospekt, eine Offerte, einen elektronischen Produktkatalog,
eine Auftragsbestatigung, das physische Produkt selbst oder den
Abruf einer Service-Dienstleistung durch den Kunden.
Der Leistungsaustausch im Rahmen der Kundenbeziehung ist
das, was einen GeschaftsprozeB charakterisiert und nicht, wie oft
irrturnlich angenommen wird, die ProzeBkette.
Die Leistungen definieren das 'Was', die ProzeBkette schlieBlich
das 'Wie'. Das 'Was' legt fest, welche Leistungen im Rahmen der
Kundenbeziehung erbracht werden und welches Qualitatsprofil
diese aufweisen mussen.
Die Leistungsanalyse spielt im Rahmen eines Business Process
Redesigns eine wesentliche Rolle: Der Wettbewerb findet auf der
Ebene der Qualitat der Leistungen statt und weniger auf der
Ebene der Art und Weise, wie die Leistungen erbracht werden.
Das 'Wie' ist die Abwicklungsebene, die festlegt, auf welche Art
und Weise die Leistungen erbracht werden. Auf der Leistungs-
Ebene sprechen wir von Makro-Prozessen, auf der Ebene der
Leistungserbringung von Mikro-Prozessen. Ein Makro-ProzeB
bundelt Leistungen. Ein Mikro-ProzeB definiert, wie Leistungen
erbracht werden. Zu einem Makro-ProzeB existieren sornit meh-
rere Mikro-Prozesse.
Der MikroprozeB reprasentiert die Abwicklungsebene. Aufgaben
werden hier zu ProzeBketten zusammengefaBt. Auf der Abwick-
lungsebene wird schlieBlich auch das Informationssystem, das
aus Online- und fur den Benutzer nicht sichtbaren Background-
Transaktionen besteht, integriert.

Abb. 2 zeigt eine Zusammenfassung der bisher verwendeten Be-

griffe:

5
4 Abbildung von Gescbiiftsprozessen auf das Informationssystem

Abbildung 2:
Semanlisches Nelz·
werk der verwendelen
Begriffe

beinhaltet in
der Prozesskette

4
Auf der Makro-Ebene sind Geschaftsprozesse durch die Leistun-
gen charakterisiert, weJche sie zugunsten ihrer ProzeBkunden
erbringen. Die Makro-Ebene ist die Filhrungsebene des Proze-
Bes.
Auf der Mikro-Ebene des ProzeBentwurfs interessiert hingegen
die Frage, wie die ProzeBleistung erbracht wird. Es werden Auf-
gaben identifiziert und in eine Ablauffolge gebracht. Die Pro-
zeBkette schlieBlich steHt den Ablauf innerhalb des Prozesses
dar. 1m wesentlichen ist dies die Festlegung, welche SteHen im
Unternehmen oder beim Kunden welche organisatorischen

6
 4 Abbi/dung von GeschaJtsprozessen auf das Informationssystem

Aufgaben iibernehmen und in welcher Reihenfolge diese Aufga-

ben ablaufen.
Damit bleibt aber immer noch die Frage offen, wie die Integrati-
on in das computergestUtzte Informationssystem gestaltet wird.
Die Gestaltung der Aufgaben und der Aufgaben-Ablauffolge muB
unter Beriicksichtigung der Einbindung der administrativen An-
wendungen erfolgen. Auch hier bedarf es methodischer Ansatze,
welche den ImplementationsprozeB strukturieren. In PRO-
MET®SSW wird z.B. die Integrations-Strategie verfolgt,
Mikro-Prozesse aus standardisierten, wiederverwendbaren
Geschaftsvorfatlen zu montieren, so daB bei einer ProzeBviel-
faIt auf der Mikro-Ebene maximale Synergiegewinne beziiglich
des Informationssystems erreicht werden konnen. Ein Geschafts-
vorfall ist eine computergestUtzte standardisierte Aufgabe, wel-
che jeweils durch einen Mitarbeiter zu einem bestimmten Zeit-
punkt an einem bestimmten Ort wahrgenommen wird. Es ist
auch moglich, daB ein Geschaftsvorfall im Batchverfahren voll-
standig automatisiert, ohne Benutzerinteraktion ablauft. Ge-
schaftsvorfalle beinhaIten selbst mehrere Arbeitsschritte, die ma-
nuelle Aktionen, Kontrollverfahren, Formulare, Belege, Listen,
Berichte, Online- oder Background-Transaktionen sowie Biiro-
kommunikationsprodukte u.a.m. kombinieren. In der Modellie-
rung ist darauf zu achten, daB ein hoher Grad an Wiederver-
wendbarkeit von Geschaftsvorfallen erreicht werden kann. Die
Geschaftsvorfalle selbst sind die 'Building Blocks', aus welchen
Prozesse montiert werden (s. Abb. 3).

Geschiiftsprozesse
Abbildung3:
PROMET®SSW:
GeschlUtsvorfiille 1 2 3
Monlagevon
'Angebote bearbeiten
Geschiiftsprozessen 'Angebote mit Kostenvoranschlag bearbeiten

aus standardisierten
mehrfachverwend-
baren Geschiifts-
vorfiillen
• •
0
• Angebote ohne KostenllOranschlag bearbeiten
'Auftriipe bearbeiten
• Ku ndenauftraae bearbeiten
• Term inauftraae bearbeiten
• Streckenauftraae bearbeiten
• Demo·Auftraae bearbeiten
• •
• Reparatur-Auftriige bearbeiten
0
oAlternativ-Produkte bearbeiten
•
'Auftragsbestatigung erstellen
0
• •
' Kreditl imite prOfen

' Verfugbarkeit orOfen

• Verfugbarkeit auf Komponentenebene prOfen
0
• •
•
0
• lIerfiiabarkeit auf Endorodu ktebene orOfen
• VerfOgbarkeit auf Zeitachse prOfen 0

7
5 M6glichkeiten zur Prozej3implementation

Welche Beziehung besteht nun zwischen ProzeB und Informati-

onssystem? Wie oben gesagt, beinhalten einzelne Geschiiftsvor-
falle bestimmte Online- oder Background-Transaktionen. Diese
sind Bestandteil administrativer Anwendungen, welche im beste-
henden Informationssystem existieren und ggf. modifiziert wer-
den mussen, im Rahmen eines Entwicklungsprojektes neu erstellt
werden oder im Rahmen einer Standardsoftwareeinfuhrung, z.B.
mit SAP R/3, parametrisiert werden.
Die Betrachtung muB in Zukunft noch weiter gespannt werden:
Fur bestimmte hochstandardisierte, hochvolumige Mikro-ProzeBe
werden elektronische Formulare, Document Image Processing
mit Intelligent Character Recognition, Dynamic Data Exchange,
Screen-Scrapping etc. im Rahmen der Geschaftsvorfallsbearbei-
tung in Zukunft eingesetzt und die ProzeBabwicklung mit
Workflow-Management-Systemen gesteuert und uberwacht.

5 Moglichkeiten zur ProzeBimplementation

Kann eine Software prozeBorientiert sein und eine andere funk-

tional orientiert? 1st die prozeBorientierte Software besser als die
funktional orientierte?
Aus der oben geschilderten Optik "Transaktion - Geschiiftsvorfall
- GeschiiftsprozeB" kann es diese Frage nicht geben. Jede Soft-
ware ist funktionsorientiert. Sie bietet eine Summe von Online-
und Background-Transaktionen an. Die Transaktionen zeichnen
sich dadurch aus, daB sie gewisse Effekte erzielen, sei dies das
Lesen oder Schreiben auf bestimmten Tabellen einer Datenbank,
das Absetzen einer EDI-Meldung, die produktion einer Liste
u .v.m .. 1m Rahmen des ProzeB-Designs werden Transaktionen in
Geschiiftsvorfallen eingesetzt, welche ihrerseits zu Prozessen
montiert werden. Es soBte zum guten Stil des Business- sowie
des Software-Engineers gehbren, den ProzeBablauf nicht in die
Online- und Background-Transaktionen hineinzucodieren.
1m Rahmen eines umfassenden Business Process Redesigns wird
es oft notwendig, das Informationssystem anzupassen resp.
ganzlich zu ersetzen. Dies liegt weniger in der Tatsache begrun-

8
 5 M6glichkeiten zur Prozessimplementation

det, daB sich die ProzeBablaufe geandert haben, sondeen daB

aufgrund des Oberdenkens der Prozesse die bestehende Aufga-
benstrukturierung nicht mehr adaquat ist. Bestimmte Aufgaben
fallen weg, andere Aufgaben werden breiter, wieder andere Auf-
gaben werden aufgeteilt etc.. Da bei den heute eingesetzten
Anwendungen Aufgaben weitgehend 1: 1 in die Software umge-
setzt wurden, betrifft eine Reorganisation der Aufgaben auch fast
immer die Reorganisation der im bestehenden Informationssy-
stem implementierten Transaktionen.
Es gibt grundsatzlich drei Arten der Implementation von Trans-
aktionen im Rahmen eines urnfassenden Business Process Rede-
signs:
1. Durch die Verwendung und ggf. Weiterentwicklung des
bestehenden Informationssystems.
2. Durch die Neuentwicklung von Transaktionen mit einer
entsprechend neuen darunterliegenden Datenbasis.
3. Durch den Einsatz administrativer Standardanwendungs-
software.

Wesentlich ist hier, zu verstehen, daB es bei der Umsetzung ei-

nes Business Process Redesigns eigentlich nicht urn die Imple-
mentierung des Prozesses, sondeen urn die Irnplementierung von
Online- und Background-Transaktionen geht, die im Rahmen
von Geschaftsvorfallen in einen Mikro-ProzeB eingebunden sind.
In der durch Informatiker oft geftihrten Argumentation gegen
Standardanwendungssoftware ist es deshalb nicht legitim, aus
der prozeBorientierten Optik neue Munition gegen den Einsatz
von Standardanwendungssoftware zu sammeln. 1m Prinzip geht
es nicht urn Prozesse in der Standardanwendungssoftware-
Diskussion, sondeen nach wie vor urn die Moglichkeiten der Be-
reitstellung adaquater Online- und Background-Transaktionen,
welche die organisatorischen Aufgaben optimal untersttitzen. Die
Standardsoftware selbst liefert tiblicherweise keine fertigen Pro-
zeBablaufe. Gegen Standardsoftware darf dann argumentiert
werden, wenn die Standardanwendungssoftware keine Parame-
trisierungsmoglichkeiten ftir das Customizing von Transaktionen
bietet, und wenn die ProzeBablaufe in die Software codiert wur-
den. In diesem Fall ist die "Standardanwendungssoftware" (die
dann eigentlich keine mehr ist) zu spezifisch entwickelt worden,
mit irgendeinern Geschaftssystem im Hintergrund, ftir das man
die Software konzipiert und realisiert hat.

9
6 Eifahrungen mit der Prozessimplementation mittels SAP-R/3: Der Konigsweg?

Es ist aber ein Irrglaube, mit einer hoch parametrisierbaren Stan-

dardsoftware wtirden die ProzeBablaufe und die Geschaftsvorfal-
Ie vorgeschrieben. Fur SAP R/3 kann diese Behauptung nicht
stehen.

6 Erfahrungen mit der Prozessimplementation mittels

SAP-Rl3: Der Konigsweg?
Die IMG coacht urnfassende Business Process Redesign- und
Implementierungs-Projekte, in welchen, ausgehend von einer
Neudefinition der Unternehmensstrategie, die Prozesse restruk-
turiert und implementiert werden. Bei einer schnellen Gangart
werden fUr die Strategieentwieklung ca. 3 Monate beansprucht.
Fur eine anschlieBende forcierte ProzeBentwicklung gemaB
PROMET®BPR, d .h. ProzeB-Makro- und -Mikro-Entwurf, und die
anschlieBende Implementation der Prozesse nach PRO-
MET®SSW, werden nochmals ca. 12 Monate veranschlagt. Nach
ca. 15 Monaten kann eine 'neue Firma' implementiert sein.
Aus der Sieht der Geschaftsleitungen ist ein schneller Implemen-
tierungsprozeB kritisch, da sieh das Unternehmensurnfe!d gene-
rell rasch w andelt, und wei! die organisatorische Transitionspha-
se, die Unsicherheiten fur aile Mitarbeiter bringt, so kurz wie
mbglich gehalten werden soil. Wir wissen, daB wir das Zeit-Zie!
mit einer Neuentwieklung des Informationssystems auch mit CA-
SE-Technologie und/ oder objektorientierten Werkzeugen nicht
erreichen kbnnen, wenn wir von 'Scratch' anfangen mussen. Fur
die Neuentwicklung der administrativen Basissysteme in einer
Unternehmung mussen wir heute auch bei Verdoppelung der
Informatik-Kapazitat zwischen drei und sechs Jahren rechnen.
Ganz abgesehen davon stellt sieh die Frage der Bezahlbarkeit
eines solchen Vorhabens.
1st damit Standardanwendungssoftware wie SAP R/3 der Kb-
nigsweg? Wenn das administrative Basissystem zu einem hohen
Prozentsatz paBt, ist die Antwort "ja". Dies ist in Industrie und
Hande! oft der Fall.

10
6 Erfahrungen mit der Prozessimplementation mitte/s SAP-R/3: Der K6nigsweg?

Weil die Implementierung schnell gehen muB, mussen wir fast

zwangsweise auf Standardsoftware zUrUckgreifen, und zwar auf
eine solche, welche so gut wie moglich den Bedurfnissen ent-
spricht, hervorragende Customizing-Fahigkeiten hat und dazu
noch eine Entwicklungsumgebung bietet, urn gewisse individuel-
Ie Transaktionen, Belege, Listen und Berichte selbst zu entwik-
keln.
Auch in auBerst schwierigen Fallen gelingt es immer wieder, un-
passende Funktionalitat zu umschiffen und mit den Entwick-
lungswerkzeugen der Standardanwendungssoftware entspre-
chend den Bedurfnissen diese Funktionalitat neu zu bilden. Die-
se Strategie erlaubt es schlieBlich, 70 - 95 Prozent der Basisfunk-
tionalitat zu verwenden, nicht passende Funktionalitat zu isolie-
ren und neu benotigte Funktionalitat mit den mitgelieferten
Werkzeugen als "Rucksack" resp. als vorgelagertes System zu er-
stellen. Durch dieses Verfahren, das Modifikationen an der Soft-
ware verhindert, bewahren sich unsere Kunden die Release-
Fahigkeit, d.h. die Moglichkeit, ohne groBere Probleme auf ho-
here Release-Levels der Software zu migrieren.
In vielen Fallen sind unsere Kunden deshalb mit SAP R/3 als in-
tegriertes, administratives Basissystem gut bedient. SAP R/3 spielt
in dies em Faile die Rolle einer Werkbank, die es erlaubt, ausge-
hend von Kenntnissen der vielfaltigen Moglichkeiten des R/3-
Systems Geschaftsvorfalle rasch zu implementieren, urn sie spater
im Rahmen eines ProzeB-Prototypings zu integrierten Prozessen
zu montieren.
Unsere Erfahrungen zeigen aber auch eine potentielle Gefahr
des Implementationsansatzes mittels Standardsoftware: Es macht
keinen Sinn, den ProzeB-Mikro-Entwurf und die Geschaftsvor-
fallsmodellierung im Detail anzugehen, bevor das Projektteam
Kenntnisse der moglichen Funktionalitat und der Customizing-
Fahigkeiten der Standardanwendungssoftware hat. Hier lauert
die latente Gefahr, daB Geschaftsvorfalle konzipiert werden, die
sich nur mit einem uberproportionalen Aufwand auf das Stan-
dardsoftwaresystem abbilden lassen, wo andere, wesentlich ein-
fachere Wege, welche das Standardsoftwarepaket bietet, uner-
kannt bleiben. Wegen dieses Sachverhalts haben sich schon
manche Projekte groBe Zeitverluste eingefahren. Auf der Detai-
lebene des Business Process Redesigns ist es deshalb unabding-
bar, daB das Redesign-Team sich auch in die Implementierungs-
details hinunterwagt.

11
7 Zusammenfassung und Fazit

7 Zusammenfassung und Fazit

Zusammenfassend Hi1~t sieh festhalten, daB eine hoch-
parametrisierte Standardsoftware aus unserer Sieht gegenwartig
das beste Vehikel ist, urn im Rahmen eines umfassenden Busi-
ness Process Redesigns eine 'neue Firma' innerhalb kurzester
Frist zu tragbaren Kosten zu implementieren.
DaB das Werkzeug dabei in Industrie und Handel oft SAP Rl3
heiBt und daB ABAP/4 eine propriellire Sprache ist, ist in diesem
Zusammenhang im Prinzip - auch wenn es fur den Informatiker
hart ist - sekundar. Wichtig ist, das adaquate Vehikel zu haben,
mit welchem der Wandel auch auf der Ebene des Informations-
systems schnell vollzogen werden kann, so daB sich eine ausrei-
chende Nutzungsdauer ergibt, bis sich die Firma aus marktbe-
dingten Entwicklungen wieder transformieren muB.
Wir leben heute im Zeitalter von ISO 9000 und der ProzeBorien-
tierung. Diese Entwieklung ist sehr positiv, bringt sie doch sehr
viel Transparenz ins Geschehen. Es ist aus diesem Grunde er-
schreckend zu beobachten, mit welcher Naivitat und mit wie
wenig Verstandnis fUr die Projektabwicklung solche ehrgeizigen
Projekte oft in Angriff genommen werden. Generelle Projektma-
nagementprinzipien zu beherrschen, reieht nieht mehr aus. Eine
umfassende ProzeBimplementation mittels Standardanwendungs-
software ist so anspruchsvoll wie ein umfassendes Neuentwiek-
lungsprojekt. Fur den letzteren Fall wurden in der letzten Deka-
de mit dem Aufkommen von integrierten Entwurfsmethoden und
-werkzeugen erhebliche Fortschritte erzielt. Derselbe MaBstab
muB auch fur den Business Process Redesign- und den Standar-
danwendungssoftware-EinfiihrungsprozeB angelegt werden. Lei-
der ist es heute noch immer so, daB die Einsicht diesbezuglich
noch nieht so weit gereift ist. Dies fUhrt dazu, wie eingangs er-
wahnt, daB viele Projekte nieht erfolgreich sind. Aus unserer
Sieht wollen wir aber mit aller Deutlichkeit sagen: daran ist die
Standardanwendungssoftware in den allerwenigsten Fallen
schuld. Den Projekt-ProzeB galt es eigentlich zu verbessern. Es
gilt, das Redesign-Projekt auf Basis von Standardsoftware zu be-
herrschen. Die Antwort sind klare und validierte Projekt-
ProzeBmodelle, wie z.B. die St. Galler PROMET-Familie.

12
 Literaturhinweise

Literaturhinweise

[1] Hammer, M., Champy, J., Reengineering the Corporation,

Harper Business, New York, 1993
[2] Scheer, A.-W., Wirtschaftsinformatik: Referenzmodelle fur
industrielle Geschaftsprozesse, 4. Auflage, Springer, Berlin
e.a., 1994
[3] bsterle, H., Business Engineering: ProzeB- und Syste-
mentwicklung, Band 1: Entwurfstechniken, Springer, Ber-
lin e.a., 1995
[4] o.V., ISO 9000-3 - Quality management and quality as-
surance standards - Part 3: Guidelines for the Application
of ISO 9001 to the development, supply and maintenance
of software, International Organisation for Standardization
(ISO), 0.0., 1991
[5] Humphrey, W.S., Managing the Software Process, Addi-
son-Wesley Publishing Company, Reading e.a., 2. Auflage,
1990
[6] o.V., PROMET®BPR - ProzeBmethode fUr das Business
Process Redesign, Version 1.0, IMG - Information Mana-
gement Gesellschaft, St. Gallen, 1994
[7] o.V., PROMET®SSW - Methode fur die prozeBorientierte
Einfuhrung von Standardanwendungssoftware, Version
2.0, IMG - Information Management Gesellschaft, St. Gal-
len, 1994

13
 Modellbasierte Organisations- und
Informationssystemgestaltung unter
Verwendung der Rl3-Referenzmodelle

Michael RosemannlThomas Rotthowe/Reinhard

SchOtte

Institut fur Wirtschaftsinformatik der Westfalischen Wilhelms-

Universitat, Lehrstuhl fUr Wirtschaftsinformatik und Informa-
tionsmanagement, Prof. Dr. Jorg Becker, Munster

14
 2 Konkretisienmg aktueller Unternehmensstrategien

1 Uberblick

Die Einfuhrung der Standardsoftware R/3 wird derzeit von vielen

Unternehmen - im Sinne eines Business Reengineering - zum
AnlaB fUr eine Restrukturierung betrieblicher AbHiufe genom-
men. Ein wesentliches Ziel ist dabei die Kongruenz zwischen
Organisations- und Informationssystemgestaltung. Hierzu bedarf
es allerdings einer hinreichenden Operationalisierung der oft-
mals unternehmensphilosophischen Managementkonzepte, fUr
die Informationsmodelle besonders geeignet erscheinen.
In diesem Beitrag solI - aufbauend auf einer ErHiuterung der
ARIS-Architektur sowie der von der SAP verwendeten Methoden
- fUr die R/3-Einfuhrung dargestellt werden, welche eigen-
standigen Lbsungsbeitrage Informationsmodelle, hier insbeson-
dere ProzeBmodelle, liefern kbnnen. Die Ausfuhrungen werden
an Beispielen vor allem aus den Logistik-Modulen konkretisiert.

2 Konkretisierung aktueller Unternehmensstrategien

Die mannigfaltig konstatierte Strukturschwache deutscher Unter-

nehmen sowie die Dberflutung mit neuen Managementkonzep-
ten aus den USA und Japan haben unter dem Schlagwort des
Business Reengineering vielfach die Bereitschaft zur grundlegen-
den Neustrukturierung initialisiert. In diese Reorganisation sind
neben der Neugestaltung der Aufbau- und Ablauforganisation
sowie der Unternehmenskultur aufgrund des hohen durch-
schnittlichen DV-Untersrutzungsgrads insbesondere auch die In-
formationssysteme eingebunden. Damit ist auch die Einfuhrung
von R/3 in einem engen Kontext zur Organisationsgestaltung zu
sehen.
Gemeinhin wird Business Process Reengineering [1] mit der
radikalen prozeBorientierten Reorganisation des Unternehmens
gleichgesetzt, wobei empirischen Untersuchungen zufolge insbe-
sondere der Wandel in der von der Unternehmung verfolgten

15
2 Konkretisierung aktueller Unternebmensstrategien

Zielrichtung das Charakteristikum von Reengineering-Projekten

ist [2]. Urn die Intensitat der Diskussion zur verstarkten ProzeB-
ausrichtung nachvollziehen zu kbnnen, bedarf es einer Definiti-
on der oftmals unreflektiert verwendeten Vokabel 'ProzeB': Unter
einem ProzeB wird die inhaltlich abgeschlossene zeitlich-
sachlogische Abfolge der Funktionen verstanden, die zur Bear-
beitung eines betriebswirtschaftlich relevanten Objekts not-
wendig sind [3]. Das Objekt kann dabei sowohl ein materielles
Objekt (z. B. Rohmaterial, Palette) als auch jedes Informa-
tionsobjekt (z. B. Fertigungsauftrag, Arbeitsplan) sein. Ein ProzeB
besitzt somit das Basischarakteristikum der Objektbezogenbeit. Da
an einem Objektdurchlauf mehrere elementare Funktionen be-
teiligt sind, sind Prozesse zudem stets funktionsubergreifend. Zur
bedarfsgerechten Detaillierung der Prozesse ist eine Pro-
zeBhierarchie aufzubauen, deren Ausgangsknoten die Ge-
schattsprozesse bilden, welche die Kerngeschafte des Unter-
nehmens reprasentieren.

Die Problematik der operativen Umsetzung aktuell diskutierter

prozeBorientierter Ansatze konzentriert sich auf die Beant-
wortung der Frage, wie Prozesse identifiziert, beschrieben und
optimiert werden kbnnen. Zur Unterstiitzung dieser Aufgaben
werden von Wissenschaftsdisziplinen, wie der Wirtschafts-
informatik [4] und der Organisationstheorie [5], schon seit lange-
rem ProzeBmodelle entwickelt. Als semi-formale, objektbezo-
gene Reprasentation der Ablauforganisation eignen sie sich so-
wohl fur Beschreibungs- als auch fur Gestaltungsaufgaben in-
nerhalb des Business Reengineerings. Bereits die Beschrei-
bungsaufgabe mit ihrer Erklarungsfunktion erfullt eigenstandi-
gen Nutzen: mit der Dokumentationspflicht wird der Zwang zu
einer funktionsubergreifenden Betrachtung operationalisiert, aus
der sich Optimierungspotentiale ergeben. Dber die Doku-
mentation des Organisationsablaufs hinaus hat ein ProzeBmodell
insofern eine Gestaltungsaufgabe, als es Optionen offenlegt,
die sich im Vergleich zur Realwelt in komplexitatsarmeren Pro-
zeBmodellen einfacher identifizieren lassen. Wahrend ProzeB-
mode lIe erst seit kiJrzem eine intensivere Beachtung erfahren,
stellen Datenmodelle seit den siebziger Jahren ein wichtiges
Hilfsmittel fur den konzeptuellen Datenentwurf dar. ProzeB- und
Datenmodelle sind in einem engen Kontext zu sehen, da jeder
ProzeB eine Vielzahl an Inputdaten benbtigt bzw. an Outputda-
ten erzeugt.

16
 3.1 Beschreibungssichten

Von unternehmensindividuellen Informationsmodellen sind

branchen- und softwarespezifische Referenzmodelle abzugren-
zen, die einen hbheren Grad an Allgemeingiiltigkeit besitzen
und somit als Grundlage fur die Entwicklung unternehmens-
spezifischer Modelle dienen kbnnen.

3 Architektur integrierter Informationssysteme

3.1 Beschreibu ngssichten

Mit der Architektur integrierter Informationssysteme CARIS)
von Scheer [61, die sich in Theorie und Praxis zunehmend eta-
bliert, liegt ein Ordnungsrahmen vor, durch den Informations-
modelle in Beziehung gesetzt werden. Innerhalb von ARIS wird
eine Problemdekomposition in die Daten-, Funk-tions-, Organi-
sations- und ProzeiSsicht vorgenommen. Jede einzelne Beschrei-
bungssicht wird dartiber hinaus nach der Nahe zur information-
stechnischen Realisierung in die drei Beschreibungsebenen Fach-,
DV- und Implementierungskonzept unterteilt (vgl. Abbildung
3.1). Informationsmodelle werden vorrangig auf der Ebene des
Fachkonzepts eingesetzt und besitzen somit eine hohe Nahe zur
betriebswirtschaftlichen Problemstellung.

Abbildung 3.1
ARIS-Architektur [6) f'achkonzept Organisationssicht
DV-Konzept
lmplementieruog

Fachkonzept
f'achkonzept f'achkonzept

DV-Konzept DV-Konzept
lmplementierung
Implemeotieruog Implemeotierung

Datensicht Proze6sicht Funktionssicht

17
3 Architektur integrierter Infonnationssysteme

In der Vergangenheit ist eine Vielzahl an Methoden zur Daten-,

Funktions- und zur kombinierten Daten- und Funktionsmodellie-
rung entwickelt worden, wahrend der Organisationsbezug auf-
grund der hohen DV-Orientierung nur eine geringe Beachtung
gefunden hat. Dies ist zugleich der Grund fUr die mangelnde
Anschaulichkeit 'konventioneller' Informationsmodelle, die den
Einbezug der Anwender aus Fachabtei!ungen erschwert.

Datensicht
Die Konsistenz, Redundanzfreiheit und Aktualitat der Daten ist
sowohl innerhalb der operativen Aufgabendurchftihrung als
auch fur die Unterstutzung strategischer Entscheidungen von be-
sonderer Bedeutung. Zur konzeptionellen Strukturierung der
Daten ist ein semantisches Datenmodell erforderlich, welches
die Integration der Anwendungssysteme erm6glicht. Ein Daten-
modell beschreibt ein Unternehmen aus Sicht der fur den jewei-
ligen Betrachtungsbereich relevanten Objekte (Entitaten) und der
Beziehungen zwischen diesen Objekten (Relationships) [7,8,91.
Durch Attribute werden die Eigenschaften von Entitaten und
Relationships festgehalten. Ein Datenmodell steHt damit das Ba-
sisangebot an Informationen des Betrachtungsbereichs unab-
hangig von Einzelfunktionen formal dar. Die klassische Methode
der konzeptioneHen Datenmodellierung ist die der Entity-Rela-
tionship-Modellierung. Aufbauend auf den Ausfuhrungen von
Chen [101 ist eine Vielzahl weiterer Methoden entwickelt wor-
den, die eine semantische Anreicherung des einfachen ERM an-
streben [111. Eine Erweiterung ist das Strukturierte ERM (SERM)
von Sinz [121, welches sich durch die strukturierte graphische
Anordnung der Objekttypen nach dem Grad ihrer Existenzab-
hangigkeit vom ERM unterscheidet.

Funktionssicht
Die Funktionssicht ist die klassische Betrachtungsweise bei der
Entwicklung von Informationssystemen, wei! sie die vorherr-
schende Denkweise der Betriebswirtschaftslehre widerspiegelt.
Funktionen (Vorgange, Aktivitaten) stellen die aktiven Kompnen-
ten eines Informationssystems dar, indem sie zu einer Transfor-
mation von Input- in Outputdaten fuhren [61. Zur Funktionsmo-
dellierung werden gemeinhin Funktionsdekompositionsdia-
gramme [6,131 verwendet, die eine Funktion mit dem Ziel der

18
 3.1 Beschreibungssichten

Komplexitatsreduzierung in einer strengen Hierarchie in Teil-

funktionen zerlegen. Die Zerlegung kann nach Verriehtungen,
nach Objekten, nach dem Rang (Entscheiden, Ausfuhren), nach
der Phase (Planen, Realisieren, Kontrollieren) und nach dem
Zweck erfolgen [14]. Sie kann maximal bis zur Darstellung von
Elementarfunktionen (betriebswirtschaftlich nieht mehr sinnvoll
detaillierbare Funktionen) reichen.

Organisationssicht
Die Betrachtung der Aufbauorganisation ist eine traditionelle
Aufgabe der Organisationstheorie. Eine weit verbreitete Darstel-
lungsmethode sind Organigramme, die insbesondere AufschluB
tiber das AusmaB an Zentralisation (z.B. Funktional-, Divisional-
organisation) und die Art der Konfiguration (z.B. Ein-, Mehrlini-
ensystem) geben. Die Ablauforganisation und speziell ihre Mo-
dellierung ist im Gegensatz zur Aufbauorganisation von der Or-
ganisationstheorie vernachHissigt worden. 1m Rahmen der ARIS-
Architektur findet sie hingegen in einer eigenen Sieht, der Pro-
zeBsieht, ihren expliziten Niederschlag.

ProzeBsicht
Die ProzeBsicht stellt eine derivative Beschreibungssieht dar, da
sie die Zusammenhange zwischen der Daten-, Funktions- und
Organisationssicht objektbezogen abbildet. Somit kann in der
ProzeBsieht die Frage beantwortet werden, wie die zeitlieh-
sachlogische Abfolge einzelner betrieblicher Funktionen
(Funktionssicht) zur Bearbeitung eines betriebswirtschaftlich re-
levanten Objekts (Datensicht) ist und welche Organisationsein-
heiten (Organisationssieht) fur diesen Ablauf verantwortlich sind.
Damit ist sie die einzige Sicht innerhalb der ARIS-Architektur, die
dynamische Sachverhalte wiedergibt. Ein typisches Beispiel fur
einen ProzeB ist der BeschaffungsprozeB von der Bedarfsmel-
dung bis zur Regulierung der Verbindlichkeit durch die Kredito-
renbuchhaltung. Neben der Betrachtung des Kontrollflusses
werden in der ProzeBsicht folgende drei Fragen beantwortet [15]:

19
3 Architektur integrierter Informationssysteme

Welche Daten werden zur Bearbeitung der Funktionen benotigt

und welche Daten werden durch die Funktionen erzeugt?
• Welche Daten werden durch welche Organisationseinheiten
benotigt und wer darf welche Informationen manipulieren?
• Welche Organisationseinheiten fGhren welche Funktionen
durch?
Der ProzeBsicht sind die Methoden zuzuordnen, die mehr als
eine Beschreibungssicht der ARIS-Architektur tangieren. Zur Mo-
dellierung von Prozessen werden gerichtete Graphen verwendet.
Abhangig von der mit der ProzeBmodellierung verfolgten Ziel-
setzung konnen beispielsweise Petri-Netze, Ereignisgesteuerte
ProzeBketten, Kunden-Lieferanten-Protokolle oder objektorien-
tierte Ansatze herangezogen werden.

3.2 Rl3-relevante Modellierungsmethoden

Die SAP AG verfolgt mit der Offenlegung ihres softwarespezifi-
schen Referenzmodells, welches die komplexen Strukturen und
Ablaufe des Rl3-Systems mit Hilfe von Informationsmodellen
abbildet, im wesentlichen drei Ziele: zum einen ist die Doku-
mentationsfunktion zu nennen. Unternehmensweite Anwen-
dungssysteme konnen nicht mehr ohne eine geeignete semi-
formale Beschreibung gewartet und weiterentwickelt werden.
Zudem stellen Informationsmodelle eine Moglichkeit dar, sich
bei hinreichender Methodenkenntnis die Systemfunktionalitat zu
erschlieBen. Ferner wirkt die Vereinheitlichung der verwendeten
Begriffe durch Modelle kommunikationsreduzierend. Zweitens
kann durch den Abgleich unternehmensindividueller Modelle
mit dem Rl3-Referenzmodell eine Analyse des Abdeckungsgra-
des erfolgen. Drittens erlauben Informationsmodelle eine mo-
dellbasierte Integration von SAP Rl3 mit anderen Softwaresyste-
men [161. In der Konsequenz ftihrt die Modellverwendung zu
einer beschleunigten EinfGhrung von Software, wobei die Da-
ten- und ProzeBmodelle die groBte Bedeutung besitzen. 1m fol-
genden werden die von der SAP verwendeten Methoden inner-
halb der Beschreibungssicht, in die sie einzuordnen sind, kurz
skizziert.

20
 3.2 Rl3-relevante Modellierungsmethoden

Datensicht
Das Datenmodell mit seiner Durchgangigkeit vom Fachkonzept
bis hin zur Implementierung bildet im SAP-System die Basis der
Informationsmodellierung Cvgl. im folgenden: [17]). Zur Be-
schreibung der Objekte des SAP-Systems sowie der Beziehungen
zwischen diesen Objekten wird die SAP-eigene SERM-Methode
CSAP-SERM) verwendet, die eine Weiterentwicklung des "ERM"
darstellt. Die von der SAP verfolgten Ziele mit der Entwicklung
von Informationsmodellen erfordern die Verwendung eindeuti-
ger formaler sowie graphischer Strukturierungsregeln, urn ein
einfacheres und schnelleres Verstandnis der Modelle sowie eine
bessere Navigation durch diese zu gewahrleisten. Aus diesem
Grunde ist bei der Datenmodellierung eine Begriffsklarung der
eigentlichen Modellierung vorgeschaltet. Es wird durch die Eli-
mination von Homonymen, Synonymen, Aquipollenzen und
Vagheiten der Versuch unternommen, eine eindeutige Benen-
nung der Modellierungsobjekte zu erreichen. Charakteristisch fur
die Darstellung sind graphische Strukturierungsregeln fur die
horizontale und vertikale Anordnung der modellierten Objekte.
Die Anordnung der Objekttypen entsprechend ihrer Existenzab-
hangigkeit von links nach rechts, wie dies aus Abbildung 3.2
hervorgeht, ist dem Strukturierten ERM entnommen.

Abbildung 3.2
Existenzabhangige
Anordnung der Mo-
dellierungsobjelde

Grad der Existenzabhan i wI

Bei den Modellierungsobjekten wird innerhalb von SAP-SERM

nicht explizit zwischen Entitytypen und Relationshiptypen unter-
schieden. Beziehungstypen werden identifiziert durch zwei Enti-
tytypen, die Beziehungstyp-Kardinalitat, die Beziehungs-typ-Art
sowie ihre betriebswirtschaftliche Bedeutung [17].

21
3 Architektur integrierter Infonnationssysteme

Die Kardinalitiiten werden im Datenmodell durch unterschied-

liche Pfeilspitzen reprasentiert, wie dies aus Abbildung 3.3 her-
vorgeht.
Abbildung 3.3 Graphische Bezeichnung im
Kardinalitaten im Darstellung SAP·SERM ERM
SAp·SERM und im
ERM ;;. 1:1 (1,1) : (1,1)
D I: C (1,1) : (0,1)
~ I:M (1,1) : (l,n)
,~ 1 :CM (1,1) : (O,n)

Bei den Beziehungstyp-Arten werden grundsatzlich drei For-

men unterschieden: der hierarchische, der aggregierende und
der referentielle Beziehungstyp [17]. 1m folgenden werden die
Beziehungstyp-Arten anhand von Beispielen kurz erlautert. Zum
besseren Verstandnis werden den graphischen Darstellungen
mittels SAP-SERM die Abbildungen im klassischen "ERM" gegen-
ubergestellt.
• Der hierarchische Beziehungstyp charakterisiert eine Be-
ziehung zwischen zwei Entitytypen, wobei der weiter rechts
angeordnete Entitytyp eine Verfeinerung des weiter links ste-
henden Entitytyps darstellt (vgl. Abb. 3.4). So ist das Werks-
lager eine semantische Verfeinerung des Werkes hinsichtlich
seiner bestandsmaBigen Betrachtung.

Abbildung 3.4 ,"",

Hierarchischer Be· Werk ''''- Werkslager

ziehungstyp im SAp·
SERM und Abbildung
er •
imERM Werk
O.n 1,1
Werkslager
~ uO

• Der aggregierende Beziehungstyp erweitert die hierarchi-

sche Beziehung dergestalt, daB zwei oder mehr Entitypen
pragend wirken (vgl. Abb. 3.5). Die Beziehung von Lager-
komplex und Werk zeigt auf, welche Werke einem Lager-
komplex zugeordnet sind. Bei der konditional-
aggregierenden Beziehung ist die Beziehung fakultativ, d.h.
bei der Anlage eines Entities wird entschieden, ob eine Ag-
gregation besteht oder nicht. Dari.iber hinaus liegt auch dann
eine konditional-aggregierende Beziehung vor, wenn beim

22
 3.2 Rl3-relevante Modelliernngsmethoden

Customizing des Systems entschieden werden kann, ob eine

Beziehung zustande kommt.

Abbildung 3.5
Aggregierender Be- Wc<k

ziehungstyp im SAP-
L..crkomplcx-
SERM und Abbildung Werk·
Zuordnun,
imERM
Lqerkomp1eA

Lagerkomplex Werk

• Der referentielle Beziehungstyp, exemplarisch in der Ab-

bildung 3.6 wiedergegeben, beschreibt den Sachverhalt, daB
der referenzierende Entitytyp CLagerkomplex-Werk-Zuord-
nung) existentiell von dem referenzierten CWerkslager) ab-
hangig ist und diesen nach bestimmten Sachverhalten einteilt,
jedoch nicht identifikatorisch von ihm abhangig ist. Ein
Werkslager kann fur genau eine Lagerkomplex-Werk-
Zuordnung gtiltig sein, eine Lagerkomplex-Werk-Zuordnung
bezieht sich nur auf ein Werkslager.

Abbildung 3.6
Referentieller Bezie- Werkslaaer

hungstyp im SAP-
SERM und Abbildung Week
imERM

Lagerkomplex

Lagcrlcomplex

1st die Beziehung optional, d. h. anwendungsabhangig und

damit nicht immer gtiltig, so liegt ein konditional-referen-tieller
Beziehungstyp vor. Eine noch schwachere Form des

23
3 Architektur integrierter Informationssysteme

referentiellen Beziehungstyps stellt der temporar-referentielle

Beziehungstyp dar. In diesem Fall kann bei der Anlage eines
existenzabhangigen Entities die Beziehung noch nicht bestehen
oder im Zeitablauf aufgehoben werden [14].
Funktionssicht
Die Funktionen des R/3-Systems werden auf einer hohen Aggre-
gationsstufe mit Hilfe des SAP-Applikationsrautendiagramms
dargestellt. Dieses enthalt die einzelnen Module des SAP-
Systems, die durch den Kern der SAP-Anwendungen, die SAP-
Basis, gekoppelt sind.
Auf einer detaillierteren Ebene werden die Funktionen durch
Funktionsdekompositionsdiagramme beschrieben. Insgesamt
gibt es drei Hierarchiestufen in den Modellen, die als Ausgangs-
knoten die Applikationen des SAP-Systems (z. B. MM, SO) und
als Endknoten die den Hauptfunktionen zugeordneten Funktio-
nen besitzen, eine Darstellung der Elementarfunktionen ist nicht
vorhanden. So besteht beispielsweise die Hauptfunktion
"Auftragsbearbeitung" unter anderem aus der Funktion
"Terminauftragsbearbeitung". Diese Funktion ist nicht weiter
untergliedert, obgleich im SAP-System die Elementarfunktionen
"Auftragspositionen bestimmen" und ,,Auftragsversandstelle be-
stimmen" dieser Funktion untergeordnet sind [191.
Ebenso der Funktionssicht waren u. E. die ProzeBauswahlma-
trizen zuzuordnen, da die in ihnen enthaltenen Elemente keine
interacts with-Beziehung zueinander aufweisen. Nach unserer
ProzeBdefinition sehen wir in dieser semantischen Relation je-
doch ein konstitutierendes Merkmal ftir die Zuordnung zur Pro-
zeBsicht. In ProzeBauswahlmatrizen sind die Szenario- und
Hauptprozesse der SAP-Module enthalten. Szenarioprozesse be-
inhalten zu Funktionen verdichtete Prozesse, die einen Oberblick
tiber das Spektrum des Prozesses geben und anhand zentraler
systemtechnischer Konstrukte identifiziert werden. So lassen sich
die Szenarioprozesse in der Materialwirtschaft beispielsweise an-
hand der Bestell- und Bestandsarten differenzieren. Einen
Oberblick tiber den Aufbau der Szenarioprozesse gibt Abbildung
3.7, in der Ausztige aus den im Modul SD abgebildeten Szena-
rioprozessen "Streckenauftragsabwicklung" und "Lieferplanab-
wicklung" dargestellt sind. In der ersten Spalte der Abbildung
befinden sich die Hauptprozesse "Stammdaten", "Verkauf" u.a.
Jedem dieser Hauptprozesse sind in der zweiten Spalte mehrere
Prozesse zugeordnet, d.h. der HauptprozeB Stammdaten besteht
unter anderem aus den Prozessen "Kundenbearbeitung" und
"Sortimentsbearbeitung" .

24
 3.2 Rl3-relevante Modelliernngsmethoden

Die Prozesse eines Hauptprozesses mtissen nicht in jedem Szen-

arioprozeB enthalten sein.

Abbildung 3.7
Ausschnitte aus den
Szenario-
prozessen
"Streckenauf·
tragsabwicklung" und ~
"Lieferplan' ~
abwicklung"

( Verkau~
( ve~iJ ~Ueferun~
bearbeirun

Die in den Szenarioprozessen enthaltenen Hauptprozesse sind

als Funktionen der zweiten und dritten Hierarchieebene in
Funktionsdekompositionsdiagrammen enthalten. Aus diesem
Grunde ist die ProzeBauswahlmatrix in die Funktions- und nicht
in die ProzeBsicht der ARIS-Architektur einzuordnen.

Organisationssicht
Die Organisationssicht des SAP-Systems beschreibt die system-
technischen Organisationseinheiten, wie Buchungskreis, Ver-
kaufsorganisation, Einkaufsorganisation sowie deren Beziehun-
gen zueinander (20). Die Beschreibungssprache ist datenorien-
tiert, da sie mit Hilfe von SAP-SERM im Rahmen des SAP-
Datenmodells erfolgt. Abbildung 3.8 stellt einen exemplarischen
Auszug aus dem im R/3-Analyzer dargestellten Organisationsmo-
dell dar. Der Vertriebsbereich besitzt zu den organisatorischen
Einheiten Verkaufsorganisation, Sparte und Vertriebsweg jeweils
eine n:m-Beziehung.

25
3 Architektur integrierter Informationssysteme

Abbildung 3.8
Ausschnitt aus dem
SAP-Organigramm
der Vertriebsorgani-
sation

ProzeBsicht
Die SAP verwendet zur ProzeBmodellierung die Methode der
Ereignisgesteuerten ProzeBketten (EPK) [15, 18]. Dabei han-
delt es sich urn gerichtete Graphen, die aus drei Elementen be-
stehen:
• Funktionen, die als aktive Knoten Input- in Outputdaten
ubertragen und Entseheidungskompetenz uber den weiteren
ProzeBverlauf besitzen. Graphiseh werden sie als abgerunde-
te Reehteeke dargestellt.
• Ereignisse reprasentieren ablaufrelevante Umweltzustande
und sind das passive Element der EPK. Sie werden als
Seehseeke dargestellt und besitzen keine Entseheidungs-
kompetenz. Ereignisse erfullen zwei Aufgaben: Zum einen
l6sen sie Funktionen aus, zum anderen werden sie von die-
sen erzeugt.
• Zur Darstellung von nicht-linearen ProzeBverlaufen dienen
sog. Verkniipfungsoperatoren. Kommt es innerhalb einer Pro-
zeBkette zu einer Aufspaltung, liegt ein "Verteiler" vor; laufen
mehrere Teilprozesse an einer Stelle zusammen, so handelt
es sich urn einen "Verknupfer". Dabei wird untersehieden in
das 'Exklusive-oder' - @ - (a oder b), das 'Inklusive-oder' -
Q; - [(a) oder (b) oder (a und b)] und das logisehe 'und' -
® - (a und b). Zur Darstellung komplexer Operationen
k6nnen ferner Regeloperatoren verwendet werden, die bei-
spielsweise Entseheidungstabellen reprasentieren.
EPK's sind bipartit, d.h. es durfen jeweils nur Knoten (Funk-
tionen und Ereignisse) untersehiedlieher Art verbunden werden.
Daruber hinaus enthalten die Notationsregeln der EPK's nur
noeh zwei weitere Vorgaben:

26
 j.2 Rlj-relevante Modelliernngsmethoden

• Jede ProzeBkette muB mit einem oder mehreren Ereignissen

beginnen und enden, wodurch sichergestellt wird, daB die
Anfangs- und Endbedingungen des Prozesses benannt wer-
den.
• Einem Ereignis kann sich kein C'Inklusives-' oder 'Exklusives-
'Yoder' anschlieBen, da einem Ereignis die in diesem Fall
notwendige Entscheidungskompetenz tiber den weiteren
ProzeBverlauf fehlt.
2ur Visualisierung von organisatorischen und informations-
technischen Schnittstellen kbnnen EPK's urn diverse weitere In-
formationen, wie ProzeBverantwortlicher bzw. ausfuhrende Or-
ganisationseinheit, genutztes Informationssystem oder ein- und
ausgehende Daten, erganzt werden. Werden in der EPK die In-
put- und Outputdaten nieht mit aufgenommen, so werden diese
in Form eines eigenen Input-Ouput-Diagramms, dem Funk-
tions-Zuordnungs-Diagramm, dargestellt [21]. Erganzt wird
dieses Input-Output-Diagramm urn die fur die Bearbeitung dieser
Funktion (bzw. dieses Prozesses) notwendige systemtechni-
sche(n) Organisationseinheit(en). 1m SAP-System ist immer min-
des tens eine systemtechnische Organisationseinheit fur die
Durchftihrung eines Prozesses verantwortlich.
Die bei der SAP als ftinfte Sieht betrachtete Informationsflu8-
sicht wird hier ebenfalls der ProzeBsicht zugeordnet, da sie sieh
als modelltibergreifende Verdiehtung aus ProzeBmodellen ablei-
ten laBt. Sie stellt die Informationsfltisse zwischen unterschiedli-
chen Funktions- oder Organisationsbereichen dar. Abbildung 3.9
beschreibt das InformationsfluBmodell zwischen Verkauf und
Versand im R/3-System. Die geriehtete Kante zwischen den
Funktionsbereiehen reprasentiert - je nach Modellierungsgenau-
igkeit - die Entitytypen bzw. Attribute, die in dem jeweils ande-
ren Funktionsbereich zur Bearbeitung benbtigt werden. So ver-
wendet der Versand beispielsweise die Daten des Kundenauf-
trags, die im Verkauf entstehen und der Verkauf die der Kun-
denlieferung, urn den Kundenauftrag ggf. korrigieren zu kbnnen.

27
3 Architektur integrierter Informationssysteme

Abbildung 3.9 Kundenauftrag. Kundenlieferplan

InformationsfluB-
mode II zwischen
,
Kundenreklamationsauftrag u .a. .....
Verkauf Versand
Verkauf und Versand ~

..... Kundenlieferung. Kundenlieferungs-

position

Zusammenfassend werden die von der SAP verwendeten Me-

thoden - nach dem hier zugrundeliegenden Verstandnis - den
unterschiedlichen Beschreibungssichten der ARIS-Architektur in
Abbildung 3.10 zugeordnet.

Abbildung 3.10
Einordnung der von
der SAP verwende-
ten Modellierungsme-
thoden in die ARIS-
Architektur

3.3 Der Rl3-Analyzer

Bei dem R/3-Analyzer [19) handelt es sich urn eine software-
spezifische Modelldatenbank, die mittels einer Navigationskom-
ponente die Suche durch die Referenzmodelle der SAP (ProzeB-,
Funktions-, InformationsfluB-, Daten-, Organisationsmodelle)
unterstutzt. AuBerdem ist die Vorgehensweise zur Erstellung des
Anforderungskonzepts Bestandteil des R/3-Analyzers (vgl. Abbil-
dung 3.11).

28
 3.3 Der Rl3-Analyzer

In der Vorgehensweise wird insbesondere danach unterschie-

den, ob bereits eine 1st-Analyse durchgeftihrt wurde oder nicht.
Liegt eine 1st-Analyse noch nicht vor, so konnen die Prozesse
des R/3-Analyzers als Ausgangslosung dienen. Nach der Ist-
Analyse wird eine wesentliche Komplexititsreduzierung durch
die ProzeBauswahlmatrizen erreicht, in denen die relevanten
Szenarien im R/3-System auszuwahlen sind. Wichtig ist im weite-
ren Verlauf die Analyse der Organisationseinheiten im SAP-
System, da diese die zentralen Datenhaltungsebenen darstellen.
Eine besonders sorgfaltige Prtifung der Abbildbarkeit der Unter-
nehmensstruktur, der ProzeBalternativen und der Informations-
fltisse bildet die Grundlage fUr die R/3-orientierten Soll-
Informationsmodelle, die, urn individuelle Anforderungen er-
ganzt, zum Unternehmensmodell fUhren.

29
3 Architektur integrierter Informationssysteme

Abbildung 3.11
Vorgehensmodell zur
Entwicklung des be-
triebswirtschaftlichen
Fachkonzepts [19]

e- _1_
--'9' --

=,
. -.
Lw:I~_

.. _RIJ.

,. ® ..
.. t
-1;;. ,
e
Pr
R1Hd.
.

30
 4.1 Organisations- und Injonnationssystemgestaltung

4 ProzeBmodelle bei der Rl3-EinfOhrung

Auf der Basis der unternehmensindividuellen Informationsmodel-
Ie erfolgt in der Konjigurationsphase sowohl die Restrukturie-
rung der Organisation als auch die Parametrisierung der Software
(Customizing) .
1m Rahmen der Veranderung der Prozesse (ProzeBverander-
lichkeit) erfolgt dabei die Anpassung der Organisation in den
Bereichen, in denen R/3 restriktiv wirkt. Parallel hierzu wird die
Software unternehmensspezifisch konfiguriert (Softwareverander-
lichkeiO.
In der Phase der Prozeflrealisierung und -anpassung vollzieht
sich die operative ProzeBabwicklung, die begleitet wird durch
ein permanentes ProzeBmonitoring und -controlling. Dieses gibt
Hinweise fUr standige ProzeBanpassungen im Rahmen des sog.
Process Change Management.
Fur die skizzierten zwei Phasen wird im folgenden der L6sungs-
beitrag von ProzeBmodellen bei der EinfUhrung von R/3 dis-
kutiert [22].

4.1 Organisations- und Informationssystemgestaltung

4.1.1 Modellbasierte Organisationsgestaltung

ProzeBmodelle k6nnen einen wichtigen Beitrag bei der Unter-
sti.itzung des Organisatorischen Wandels leisten, der sich in die
Phasen Destabilisierung des bestehenden Gleichgewichts
(unfreezing), Analyse der entworfenen Gestaltungsoptionen
(moving) und Festsetzung der zukunftigen Organisationsstruktur
und -ablaufe (refreezing) unterteilen liiBt [23].
1m Rahmen der Organisationskonfiguration werden insbe-
sondere ProzeBmodelle erstellt, die die jeweilige ProzeBverant-
wortung sowie die organisatorischen Schnittstellen beschreiben.
Bereits durch die in der Regel neue durchgehende Darstellung
der (zumeist nur in Teilabschnitten bekannten) Istablaufe ent-
stehen wesentliche Erkenntnisse, die die notwendige Sensibilitat
fUr die Verbesserung der oftmals ineffektiven ProzeBausgestal-

31
4 Prozeflmodelle bei der Rlj-EinJiihrnng

tung schaffen (unJreeziniJ. Dabei ist es bedeutsam, daB Pro-

zeBmodelle in Form von EPKs intuitiv zuganglich sind.
In der Phase der Analyse der Gestaltungsoptionen (maviniJ lei-
sten ProzeBmodelle einen wichtigen Beitrag, indem sie den Ge-
genstand der Reorganisation fur ein interdisziplinar zusammen-
gesetztes Projektteam erkennbar und kommunizierbar machen.
So sollten sich beispielsweise an einer Reorganisation des Be-
schaffungsprozesses - dem funktionsubergreifenden Charakter
dieses Prozesses entsprechend - Mitarbeiter aus den Bereichen
Einkauf, Disposition, Wareneingang, Kreditorenbuchhaltung
sowie Informationsmanagement beteiligen. Verabschiedete Er-
gebnisse der Projektdiskussionen werden in Sollmodellen fest-
gehalten, die als formale Organisationsvorgabe die bisherigen
Organigramme und Stellenbeschreibungen urn eine Darstellung
der Ablauforganisation erganzen (reJreeziniJ.
Zur Konkretisierung des Nutzens von ProzeBmodellen fur die
Organisationskonfiguration mage nachfolgendes Beispiel zur
Wareneingangsbearbeitung dienen, das einem konkreten Projekt
entnommen wurde. Die Abbildung 4.1 gibt den aufgenommenen
IstprozeB wieder. Die korrespondierende Ausgangslasung des
Rl3-Analyzers findet sich in Abbildung 4.2. Der realisierte Soll-
prozeB, unter Einbezug der beteiligten organisatorischen Einhei-
ten, ist Abbildung 4.3 zu entnehmen. Die 1st-Situation ist ge-
kennzeichnet durch den Medienbruch zwischen der Erfassung
der Lieferscheinmenge in der WE-Liste und der systemseitigen
Erfassung der tatsachlichen Wareneingangsmenge abends in der
Abteilung Einkauf. Insbesondere die Genauigkeit und Aktualitat
der Informationen sind ungenugend. Der verfugbare Lagerbe-
stand ist erst am nachsten Morgen im System abrufbar. Weiterhin
werden Preis- und Mengendifferenzen erst nach Einlagerung der
Ware erfaBt, wenn der korrigierte Lieferschein endgUltig im Ein-
kauf eingeht.
Der Rlj-Analyzer-Prozefl "Wareneingang mit Bestellbezug fUr
Lagermaterial" (24) wurde als Ausgangslasung fur eine Rl3-orien-
tierte Neugestaltung des Wareneingangsprozesses genutzt. Dabei
wurden die manu ellen Tatigkeiten sowie die organisatorischen
Zustandigkeiten erganzt, die im Rl3-Analyzer nicht enthalten
sind. 1m SollablauJwird die Wareneingangsbuchung sofort nach
Kontrolle der Anlieferung an der Rampe im WE-Buro erfaBt. Die
Mengendifferenzen werden bei der Kontrolle "Ware gegen LieJer-
schein" identifiziert. Die Eingabe der korrigierten Liefer-

32
 4.1 Organisations- und InJormationssystemgestaltung

scheindaten triggert die Funktionen "Warenbegleitschein druk-

ken" und "EinkauJ benachrichtigen ". Auf diese Weise sind un-
nbtige Transportwege und -zeiten durch die Dberrnittlung der
WE-Liste tiberfltissig, da der Einkauf unmittelbar nach erfolgtem
Wareneingang eine Nachricht erhalt tiber die aktuellen und kor-
rekten Wareneingangsdaten, so daB er tiber exaktere Dispositi-
onsinformationen verfiigt.

~~.=-.)
Abbildung 4.1
IstprozeB
.Wareneingangs·
bearbeitung"
888
····e--- -----
<~~) <~~)
§
--e --
0@ £
tb ~
C§J §J5J §J
<~) <~~) §
[ En~~ ) ® . . . . ---
§J
e~ @
[~~J (~l)G
e ···-----······ ---------

33
4 Prozefimodelle bei der R/3-Einfuhnmg

Abbildung 4.2
R13-Analyzer-ProzeB
.Wareneingang mit
Bestellbezug f(jr La-
germaterial" [24] ·--s- --
u_. .
(u.r~I~) ¢dt>
semaJlOl

-- -~ -- -- -- --({y ---
...----'L--..- - - - ® , -------''-----.,
,-- s- -,
@ (~~t~)
-- ~-
.--0;;---
~I-::i
~ L::::J
-- ~ -- -

--6------
@-----------
,- -e

34
 4.1 Organisations- und Injornzationssystemgestaltung

Abbildung 4.3
SoliprozeB
"Wareneingangs-
bearbeitung"

~
~

35
4 ProzejSmodel/e bei der Rl3-Einfiihrung

4.1.2 Modellbasiertes Customizing

In Abstimmung mit der Restrukturierung der Organisation sind
die die Prozesse unterstutzenden Informationssysteme zu konfi-
gurieren. Bei einem urnfangreichen Softwareprodukt wie Rl3
kann diese Konfigurationsaufgabe, die sich als Selektion und Pa-
rametrisierung der unternehmensspezifisch benbtigten Pro-
grarnrnfunktionalWit darstellt, einen erheblichen Zeitraum des
Gesamtprojekts einnehmen. Deshalb wird insbesondere durch
die Verwendung von Informationsmodellen versucht, den Vorteil
von Standardsoftware gegenuber Individualsoftware - die schnel-
lere Produktivnahme aufgrund der fehlenden Programmierar-
beit - aufrechtzuerhalten.
1m Rahmen der SAP-seitig als Customizing bezeichneten Soft-
warekonfiguration werden mit dem Einfuhrungsleitfaden sowie
dem Einstellungsmenu zwei Werkzeuge zur kundenindividuellen
Systemeinrichtung zur Verrugung gestellt. Erganzend zum se-
quentiellen Einfuhrungsleitfaden sollen hier ProzeBmodelle, die
die Abfolge der Customizingaktivitaten modultibergreifend be-
schreiben, vorgestellt werden. Erst diese offenbaren das Paralle-
lisierungspotential bei der Aufgabendurchfuhrung und zeigen
notwendige CmodultibergreifendeO Voraussetzungen einzelner
Customizingaktivitaten auf. Dadurch kbnnen die in Einfuhrungs-
projekten stets knappen Ressouren effizienter gelenkt und insge-
samt die Anschaulichkeit des Customizing erhbht werden. Eine
wichtige Pramisse hierrur ist, daB der Zeitbedarf der einzelnen
Customizingaktivitaten hinreichend genau quantifiziert wird.
ProzeBmodelle kbnnen so einen Beitrag zum Projektmanage-
ment wahrend der Softwarekonfiguration leisten.
Ein Beispiel rur ein mbgliches ProzeBmodell zum Customizing ist
der in Abbildung 4.4 wiedergegebene Ausschnitt aus einer er-
eignisgesteuerten ProzeBkette zur Einrichtung des SD-Moduls,
hier der Schnittstelle zum Mahnwesen. In der vollstandigen EPK
bestehen daruber hinaus Teilabschnitte zur Einrichtung der FI-
Schnittstelle sowie weitere vertriebsspezifische Einstellungen
CStammdaten, Vorgange, Funktionen etc.).

36
.. w
 4.1 Organisations- und In!ormationssystemgestaltung

Abbildung 4.4
TeilprozeBkette zum
Customizing der
Schnittstelle SD-FI
-0 --@

-{!y--
~
~
Funktionen·>
Kontierung- >
Mahnbeteiche

Zum Vergleich enthalt Abb. 4.5 die textuelle Vorgangsbeschrei-

bung, wie sie sich im Einfuhrungsleitfaden findet. Es zeigt sich,
daB die in der EPK wiedergegebene Voraussetzung, daB Mahn-
bereiche vorher im FI-Modul angelegt werden mussen, im Ein-
fuhrungsleitfaden fehlt.

Abbildung 4.5 Mahnbereicbe zuordnen

Ausschnitt aus dem
EinfOhrungsleitfaden In diesem Menupunkt konnen Sie einzelnen Vertriebsbereichen einen
Mahnbereich zuordnen. Der so errnittelte Mahnbereich wird an die
Vertrieb-Funktionen Paktura ubergeben.
[25] Mahnbereiche ermoglichen es Ihnen, innerhalb eines Buchungskreises
unterschiedliche Mahnverfahren anzuwenden. Alle Mahnungen erfolgen
nach Mahnbereichen getrennt.

Hinweis
Der Mahnbereich wird entweder manuell in den Belegpositionen
eingegeben oder aus der hier getroffenen Zuordnung zwischen
Vertriebsbereichen und Mahnbereichen erminelt.

Aktlvititen
1. Prtifen Sie, ob Sie einem Vertriebsbereich einen Mahnbereich
zuordnen m&hten.
2. Ordnen Sie einem Vertriebsbereich ggf. einen Mahnbereich zu.
Funktion ausfuhren

Bearbeitungsstatus: noch niche gepflegt

37
4 ProzejSmodel/e bei der RlJ-Einfuhrung

Derzeit ist bezuglich des Ubergangs von den ProzeBmodellen

CFachkonzept) zu den daraus ableitbaren Customizingaktivitaten
(Implementierung) noch ein Medienbruch zu konstatieren. Die
Prozesse des Rl3-Analyzers beschreiben zwar die systemseitig
unterstutzten ProzeBalternativen, nicht aber die fUr ihre Realisie-
rung notwendigen Konfigurationsaufgaben: "Der SAP Rl3-
Analyzer hat seine Aufgabenschwerpunkte in der Organisations-
und Konzeptionsphase des EinfUhrungsprozesses. [...J In den
spateren Phasen der Detaillierung und Realisierung wird dann
im Rahmen des Customizing detailliert festgelegt, wie die Fein-
einstellungen zu machen sind" [26].
Eine von der modellbasierten Konzeption bis zur DV-tech-
nischen Umsetzung reichende Integration erfordert hingegen die
automatisierte Konfiguration der Software auf der Basis von In-
formationsmodellen, wie sie sich derzeit in der Entwicklung be-
findet [27]. Zielsetzung hierbei ist es, Customizing-relevante Mo-
dellinhalte unmittelbar in die Steuerungstabellen zu ubernehmen
und irrelevante Optionen auszublenden [20]. Ebenso ist anzu-
streben, daB die ProzeBmodelle fUr die automatische Generie-
rung von Eigenentwicklungen genutzt werden. Diese Ent-
wicklungen werden den Integrationsgrad sowie die Konsistenz
des modellbasierten Customizingprozesses deutlich erh6hen und
damit die Softwarekonfiguration beschleunigen und transparen-
ter gestalten.

4.2 ProzeBrealisierung und -anpassung

Die Phase der ProzeBrealisierung beschreibt die organisatorische
und DV-technische ProzeBausfuhrung. Zielsetzungen in dieser
Phase sind die Einhaltung der vorgegebenen ProzeBanwei-
sungen und die bedarfsgerechte, m6glichst antizipative ProzeB-
anpassung.
Es ist dabei ein wesentlicher organisatorischer Freiheitsgrad, in-
wieweit die Ablaufe konkret zur AusfUhrung vorgegeben werden
oder ob die ProzeBmodelle nur einen groben Rahmen bilden,
der lokal ausgestaltet werden kann. Die erste Alternative geht
mit einem h6heren Aufwand in der organisatorischen ProzeB-
konfiguration einher. Ihrem Vorteil - der zentral transparenten
ProzeBausfuhrung in verschiedenen Unternehmensbereichen -
steht der Nachteil gegenuber, daB eine lokale ProzeBanpassung
tendenziell unterbunden wird. Fur die zweite Alternative gehen
die umgekehrten Argumente.

38
 4.2 ProzejSrealisiernng und -anpassung

Insbesondere organisationszentrierte ProzeBmodelle, wie sie als

Ergebnis der vorangegangenen Phasen vorliegen, kbnnen ange-
sichts ihrer Anschaulichkeit in dieser Phase als Dokumentation
fur die Endanwender dienen [28]. Sie offenbaren durch die Dar-
stellung der organisatorischen Schnittstellen sowie der ablauf-
steuernden 'Business Rules' verhaltensrelevante Organisations-
anweisungen. Hierfur mussen die Referenzmodelle des R/3-
Analyzers bzw. die selbsterstellten Sollmodelle urn manuelle Ta-
tigkeiten und urn Entscheidungskriterien erganzt werden.
Wahrend die organisatorische ProzeBabwicklung durch die Pro-
zeBmodelle vorgegeben wird, kann die DV-technische ProzeB-
ausfuhrung im R/3-System bereits an einigen Stellen in einer
(textuellen) Online-Dokumentation nachvollzogen werden. Ein
Beispiel fur eine aus dem Anwendungsmenu aufrufbare ProzeB-
dokumentation stellt der AM-Benutzerleitfaden dar. Darin wer-
den beispielsweise sequentiell die Aktivitaten der Anlagenbuch-
haltung im Rahmen des Jahresabschlusses dokumentiert.
In dem MaBe, in dem derartige ProzeBerlauterungen systemseitig
vorhanden sind, kann auf die explizite Aufnahme von Erlaute-
rungen und ProzeBmodellverfeinerungen zum Nutzen einer ge-
ringeren Modellkomplexitat verzichtet werden. Damit liegt zu-
gleich ein Hinweis fur ein bedarfsgerechtes Detaillierungsniveau
der ProzeBmodellierung vor.
Die ProzeBrealisierung sollte durch ein permanentes ProzejS-
monitoring und ProzejScontrolling begleitet werden, des sen Ziele
darin bestehen, Ist-ProzeBdaten, wie ProzeBkosten oder Durch-
laufzeiten, auszuwerten und zu verdichten, diese mit ProzeB-
plandaten abzugleichen sowie fruhzeitige Hinweise fur die Pro-
zeBanpassung abzuleiten. Dabei ist Monitoring hier nicht im
technischen Sinne, sondern als organisatorisches Monitoring zu
verstehen. Damit wird die gezielte Nutzung der erfaBten Daten
fUr die permanente Optimierung und Anpassung der Organisati-
on bezeichnet [29]. So wie ProzeBmodelle in der Konzeptions-
phase die Transparenz erhbhen, so erhbht das ProzeBmonitoring
die Transparenz wahrend der Ausfuhrung. 1m Rahmen des Pro-
zejScontrollings werden die Daten des ProzeBmonitorings ver-
dichtet, zusammen mit dem dazugehbrigen ProzeBmodell eva-
luiert und Notwendigkeiten und Wege der ProzeBanpassung
konzipiert.

39
5 ZusammenJassung und Ausblick

5 Zusammenfassung und Ausblick

Der L6sungsbeitrag von ProzeBmodellen bei der R/3-Einfuhrung

ist phasendiffenziert zu sehen. Abgesehen von ihrem (derzeit
noch) ungenugenden Beitrag zum Customizing sind ProzeBmo-
delle von groBem Nutzen. Ihre Anschaulichkeit erlaubt insbe-
sondere die wichtige Einbeziehung von Mitarbeitern aus den
Fachabteilungen. Der Verwendung von ProzeBmodellen ist je-
doch stets der mit ihrem Einsatz in Form von methodischer
Schulung verbundene Aufwand sowie der fUr ihre produktive
Nutzung notwendige zeitintensive Erfahrungsgewinn gegenuber-
zustellen.
Fur die Dbertragung der hier im wesentlichen anhand der Logi-
stik skizzierten Ausfuhrungen auf das Rechnungswesen ist zu
beachten, daB die ProzeBindividualWit in der Logistik aufgrund
der Heterogenitat der ProzeBobjekte (Material, Artikel) relativ
hoch ist. Prozesse im Rechnungswesen besitzen hingegen eine
gr6Bere Branchenneutralitat und durch den Zwang zur steten
Beachtung gesetzlicher Vorgaben eine geringe ProzeBvarianz.
Dadurch ist der Funktionalbereich des Rechnungswesens noch
empfanglicher fUr Referenzmodelle als der der Logistik.

40
 Literatur

Literatur

[1) Hammer, M., Champy, J.: Business Reengineering. Die

Radikalkur filr das Unternehmen. Frankfurt am Main 1994.
(2) Dixon, R. J. et. al: Reengineering II: Mit Ausdauer ist es
machbar. Harvard Businessmanager, 17 (995) 2, S. 105-
114.
(3) Rosemann, M.: Beschreibung und Gestaltung der Produk-
tion auf der Basis Grundsatze ordnungsmaBiger ProzeB-
modellierung. In: Tagungsband Re-Engineering-KongreB.
Hrsg.: IDG. Frankfurt 1994, S. 52-84.
(4) Petri, C. A.: Kommunikation mit Automaten. Bonn 1962.
(5) Jordt, A.: Ober die Untersuchung und Darstellung von Ar-
beitsablaufen. zfo, 27 (958) 2, S. 52-55.
(6) Scheer, A.-W.: Architektur integrierter Informationssyste-
me. Grundlagen der Unternehmensmodellierung. 2. Aufl.,
Berlin u. a. 1992.
[7) Vetter, M. : Aufbau betrieblicher Informationssysteme -
mittels objektorientierter, konzeptioneller Datenmodellie-
rung. 7. Aufl., Stuttgart 1991.
(8) Date, J.: An Introduction Into Database Systems. Vol-
ume 1. Fifth Edition, Reading, Massachusetts 1991.
(9) Scheer, A.-W.: Wirtschaftsinformatik. 6. Aufl., Berlin u. a.
1995.
(10) Chen, P. P.-S.: The Entity-Relationship-Model: Towards a
Unified View of Data. ACM Transactions on Database-
Systems, 1 (976) 1, S. 9-36.
(11) Sinz, E. J.: Das Entity-Relationship-Modell (ERM) und seine
Erweiterungen. HMO, 27(990) 152, S. 17-29.
(12) Sinz, E. J.: Das Strukturierte Entity-Relationship-Modell
(ER-Modell). Angewandte Informatik, 30 (988) 5, S. 191-
202.
(13) Muller-Ettrich, G.: Pragmatische Oberlegungen zur Werk-
zeugeinfilhrung. In: Fachliche Modellierung von Informa-
tionssystemen. Hrsg.: G. Muller-Ettrich. Bonn u. a. 1993, S.
307-340.

41
Literatur

[14] Kosiol, E.: Organisation der Unternehmung. 2. Aufi.,

Wiesbaden 1976.
[15] Hoffmann, W., Kirsch, ]., Scheer, A-W.: Modellierung mit
Ereignisgesteuerten ProzeBketten. VerOffentlichungen des
Instituts fur Wirtschaftsinformatik, Heft 101, Saarbrucken
1993.
[16] Endl, R., Fritz, B.: Integration von Standardsoftware in das
unternehmensweite Datenmodeli. Information Manage-
ment, 7 (992) 3, S. 38-44.
[17] SAP AG: SAP-Informationsmodell - Modellgestutztes In-
formationsmanagement im R13-System. Walldorf 1994.
[18] Keller, G., Nuttgens, M., Scheer, A-W.: Semantische Pro-
zeBmodellierung auf der Basis "Ereignisgesteuerter Pro-
zeBketten (EPK)". Veroffentlichungen des Instituts fur
Wirtschaftsinformatik, Heft 89, Saarbrucken 1992.
[19] Keller, G., Meinhardt, S.: SAP R13-Analyzer. Geschaftspro-
zeBoptimierung auf Basis des R13-Referenzmodells. Hrsg.:
SAP AG. Walldorf 1994.
[20] Keller, G., Meinhardt, S.: DV-gestutzte Beratung bei der
SAP-Softwareeinfuhrung. HMD, 31 (994) 175, S. 74-88.
[21] Kirsch,].: Handbuch ARIS-Methoden, Version 2.1. Hrsg.:
IDS Prof. Scheer GmbH. Saarbrucken 1994.
[22] Rosemann, M., Rotthowe, T.: Der Losungsbeitrag von Pro-
zeBmodellen bei der Einfuhrung von SAP R13 im Finanz-
und Rechnungswesen. HMD, 32 (1995) 182, S. 8-25.
[23] Lewin, K.: Feldtheorie in den Sozialwissenschaften. Bern,
Stuttgart 1963.
[24] SAP AG: R13-Reference Model ReI. 2.2. Walldorf 1994.
[25] SAP AG: Einfuhrungsleitfaden R13 (IMG) - Release 2.2d.
Walldorf 1994.
[26] Keller, G., Meinhardt, S.: Business process reengineering
auf Basis des SAP R13-Referenzmodells. In: ProzeBorien-
tierte Unternehmensmodellierung. SzU, Band 53. Hrsg.:
A-W. Scheer. Wiesbaden 1994, S. 35-62, insb. S. 51.
[27] Scheer, A.-W., Hoffmann, W., Wein, R.: Customizing von
Standardsoftware mit Referenzmodellen. HMD, 31 (994)
180, S. 92-103.
[28] Schulte, R., Rosemann, M., Rotthowe, T.: Business Process
Reengineering in Theorie und Praxis. Management &
Computer, 2 (994) 2, S. 211-219.
[29] bsterle, H., Saxer, R., Huttenhain, T.: Organisatorisches
Monitoring in der Gestaltung von Geschaftsprozessen.
Wirtschaftsinformatik, 36 (994) 5, S. 465-477, insb. S. 466.

42
Wirtschaftliche R13-Einfuhrung im
Mittelstand - Einsatzmoglichkeiten
von Methoden und Tools

Dr. rer. pol. Andreas Hufgard

Geschaftsfuhrer der IBIS Prof. Thome GmbH, Wurzburg

43
1 Oberblick

1 Oberblick
Zwei entscheidende Aspekte werden in der aktuellen Main-
streamdiskussion zum Thema "GeschaftsprozeBoptimierung mit
R/3" vbllig vernachlassigt:
Wirtschaftlichkeit: Wie kann eine Einfuhrung von R/3 einfach
und schnell realisiert werden, wenn fur wesentliche Anforderun-
gen feststeht, was zu tun ist? So existieren im mittelstandischen
Unternehmen meist keine Geschaftsprozesse mit hoher Arbeits-
teilung, die aufwendig analysiert werden mussen.
Eine einmalige Optimierung gibt es nicht! Vielmehr muB ein
standiger InnovationsprozeB organisiert werden, der neue Mbg-
lichkeiten der Software- und Informationstechnologie unter Ko-
sten-Nutzen-Abwagungen und organisatorischen Anforderungen
erschlieBt und einsetzbar macht. Eine Hinleitung zu einem
"ertraglichen" Continuous Systemengineering ist notwendig, daB
anstatt aufwendiger Spriinge viele kleine schnelle Schritte zu ei-
ner verbesserten Informationsqualitat verlangt.
Nach einer Untersuchung von DTTI [Cebit 951 sind bei R/3-
Einfuhrungen in groBen Unternehmen, die bereits R/2 im Einsatz
hatten, keine wesentlich schnelleren Implementierungszeiten er-
zielt worden. Auf der anderen Seite hbrt man von Projekten, die
in 88 Tagen ein produktives System mit R/3 geschaffen haben.
Wie kann das sein? Die Software ist die gleiche!
Konkurrenten der SAP stellen meist schnelle Einfuhrungszeiten
ihres Produktes als groBen Vorteil heraus und verweisen auf das
durchschnittliche SAP-Projekt mit einem ]ahr Laufzeit und vielen
Schwierigkeiten mit komplexen Tabelleneinstellungen des R/3 .
Am Ende solcher Darstellungen fallt meist das Stichwort
"Mittelstandsfahigkeit", die R/3 fehlt.
Die Antwort auf diese These "Mittelstandsfahigkeit R/3" suchte
ein Forscherteam des Lehrstuhls fUr Betriebswirtschaftslehre und
Wirtschaftsinformatik von Prof. Thome bereits 1992 zu klaren.
Die Antworten und - daraus abgeleitet - die Methoden- und
Toolentwicklung, die zusammen mit Siemens Nixdorf entstan-
den, sind im folgenden dargestellt.
Nach einer Situationsanalyse der Informationsverarbeitung im
Mittelstand sucht dieser Beitrag einen Lbsungsvorschlag mit der
ODYSSEUS-Methode darzustellen, der bereits erfolgreich in vie-
len Projekten angewandt wird.

44
 2 Empirischer Befund der Befragung "Mittelstandsfahigkeit Rl3" ...

2 Empirischer Befund der Befragung

IIMittelstandsfahigkeit Rl3 11
Durch die Zersplitterung der Anwendungslandschaft im Mittel-
stand in Branchenlbsungen gibt es nur wenig Datenmaterial oder
auch kaum aUgemeinere Informationen zur DV-Situation des
Mittelstandes insgesamt. Lediglich von KRCMAR ist eine Studie
von 1989 zu aUgemeinen Aspekten des Informationsmanage-
ments im Mittelstand bekannt. Ein Ergebnis war, daB die Stan-
dardanwendungssoftware als i.iberdurchschnittlich wichtiges und
schwieriges Thema angesehen wird. Auch besitzt sie im Mittel-
stand eine hbhere Bedeutung als bei GroBunternehmen [vgl.
KRCM92,79ff.1.
Die Fokussierung der Betrachtung auf eher mittlere Unterneh-
men soUte wegen der grbBeren Anzahl der Unternehmen und
der hbheren Abhangigkeit von extern angebotener Stan-
dardsoftware mit Prioritat verfolgt werden.

Abbildung 1: Mittel- 1m Vergleich zu GroBunlernehmen:

stand aus Sieht der • as iS1 nur in Teilbere;chen eine M assendalen-
Informationsverar-
verarbeilung nOlwendig . d.h. as gibl Schwer-
beitung im Vergleieh
punkle i n denen hohe DV -Anforderungen
zum GroBunternehmen
beS1ehen .

• eine geringere M ilarbeilerzahl heiB1 . daJ3 as

Oberslchll ichere Qrganisalionsstrukluren gibl
und

• d iegeringere A rbeilsteilung verkurzl die

ProzeBkellen fur beS1 immle Vorgfinge.

45
2 Empirischer Befund der Befragung "Mittelstandsfahigkeit RlJ"

Abbildung 2: Mittel- 1m Ve-gleich zu Klei~riEtlErl :

stand aus Sieht der • de IV·Schwerpurkte rrit Ma!HJ1d<fftMla1Jeit~ Ioe'lmgen

Informationsverar- 'GrolJO!u1gEn- IIld t1'\1I:hEn den 6nsalz Elwa \<)t\ PC·L6-
Sl.Jr'9iIl urmOgtich,
beitung im Vergleieh
• de iitusichliche. SlEnoll!li1dge UntemenrT1El1S5truktUl
zu Kleinbetrieben
VErI..-.gt den Einsalz \<)t\ Informa!ia\$\'!I<JIlIJ1, um de
Inforrnmoosaktualitall.lld ·QUalitai schEnusleilen,
• die ku-za-en, abet YOII stkIdigen Proze'J<Elten VErlmgen den
Einsalz val intEgiEl1Er InformaliOl'lS>l8<fbeit"'9, cia 9Jr1!I
MOOi9"brUcheund DoppeiErfasaJngdie Durchlaufzeiten stak
\l9'I!IngEm WOrden I.Ild
• M.....-.daIenWJ:a-beitung, YOIl!IlrOge Strukturen und PrOZlHle
\l9'lmgen de gleiche npruchs>tolle bEtriEllsNi~s:naui che
Furktionalital wie in GroBlWiEtlErl, die cHYl all dem Wag dar
A ~on "'f~dErIIlgsgerectl Q9!IaI tEl_den mU3.

Ferner ist die Adaption von Standardsoftware oft die einzige

wirtschaftlich vertretbare Moglichkeit fUr mittelstandische Unter-
nehmen, die gesetzten Anforderungen zu erreichen. Sie mtissen
mit einem absolut geringeren Investitionsbudget und geringerer
personeller Kapazitat als GroBunternehmen die betriebliche In-
formationsverarbeitung gestalten. Die Kriterien in Abbildung 1
und 2 kennzeichnen aus Sicht der Informationsverarbeitung ein
mittleres DV-Anwenderunternehmen. Die hier aufgeftihrten
qualitativen Kriterien wenden sich gegen die Versuche, durch
Mitarbeiterzahl oder Umsatz den Mittelstand aus Sicht der Infor-
mationsverarbeitung zu bestimmen. Als einen Richtwert nach
unten sind Situationen mit 20 Anwendern eine sinnvolle GroBe,
wobei eine Teilauslagerung von Integrationsbereichen (z.B. als
Verkaufsniederlassung) durchaus kleiner sein darf. Nach oben
kann die Zahl von 100 Anwendern als Richtwert gelten, wobei
multiplizierte Funktionen an Massenarbeitsplatzen (z.B. Telefon-
verkauD oder eigenstandige Geschaftsbereiche, die Konzerne
mittelstandisch machen, das Bild verzerren. Unschwer erahnt der
geneigte Leser ein Votum, auch im Konzern die Chance zur de-
zentralen Einftihrung zu nutzen.

2.1 Branchenubergreifende Erfahrungen im

COMET -Anwenderkreis
Als besondere Gruppe im Mittelstand sind die COMET-Anwender
herauszustellen, die tiber viele Branchen verteilt, die gleiche
Softwareplattform schon seit den 70er Jahren benutzen.

46
 2.1 Branchenubergreifende Erfahrungen im COMET-Anwenderkreis .. ,

Sie stellen auf Basis des in dies em Segment in den 80er Jahren
marktfuhrenden Produktes - mit ca. 35.000 Anwendern [SN192a,
o .S.] - die groBte re!ativ homogene Gruppe von Sofwareanwen-
dern im Mitte!stand dar. COMET war in den 70er und 80er Jah-
ren von der Firma Nixdorf entwickelt worden. Auch gilt COMET
nach bisherigem Stand der Technologie als sehr anpas-
sungsfahig. Inzwischen wird COMET von der Siemens Nixdorf
Informationssysteme AG vertrieben, in die die Nixdorf AG 1990
eingegangen ist.
Marktentwicklungen und der enorme Entwicklungsaufwand ha-
ben den Zwang geschaffen, daB die SAP AG, mit der Stan-
dardsoftware R/2 Marktfuhrer fur GroBu nternehmen, und Sie-
mens Nixdorf bei der Entwicklung von R/3 als Nachfolgeprodukt
von COMET und R/2 zusammenarbeiten. Die offene Frage war:
Fur welche GroBenordnung von Unternehmen ist R/3 geeignet?
1m Jahre 1992 konnten die beiden Firmen von dem empirischen
Ansatz der Befragung "Mitte!standsfahigkeit R/3" uberzeugt wer-
den und untersti.itzten das Vorhaben. Als weitere beteiligte Or-
ganisation konnte der EDV-Anwenderkreis e.V. gewonnen wer-
den. Es hande!t sich dabei urn eine COMET-Anwendervereini-
gung mit ca. 100 Mitgliedsunternehmen.

2.1.1 Ablaut der 8etragung

Es galt, die Erfahrungen mit COMET und die Anforderungen an
die neue Software R/3, deren Eigenschaften bei den Befragten
nur vage bekannt waren, zu erfassen. Dabei muBte entschieden
werden, welche quantitativen, beobachtbaren GroBen (z.B. Mit-
arbeiter pro Abteilung) und welche nicht-beobachtbaren, quali-
tativen Variablen (z.B. Bedeutung von Standards) erfragt werden
sollten. Fri.ihzeitig fie! deswegen die Entscheidung, einen stan-
dardisierten Fragebogen zu entwerfen und kompliziertere oder
schwer ausdri.ickbare Sachverhalte (z.B. Gri.inde fur Einfuh-
rungsreihenfolge der Software) auf standardisierte mundliche
Interviews zu verlagern, fur die typische Unternehmen nach
Analyse der schriftlichen Befragung ausgesucht werden sollten.
Der Zeitpunkt der schriftlichen Befragung war September 1992.
Dem gingen drei Monate der Vorbereitung, Fragebogengestal-
tung und Pretests voraus. Fur die Auswertung wurden weitere
zwei Monate benotigt. 1m November 1992 fanden die mundli-
chen Interviews in ausgewahlten Unternehmen statt.

47
2 Empiriscber Refund der Refragung "Mittelstandsfabigkeit Rl3"

2.1.2 MeB- und Auswahlverfahren

Die vorliegenden Ergebnisse basieren auf der Auswertung der
Fragebogen von 60 Unternehmen, gut 50% derjenigen, die fur
die Untersuchung angeschrieben wurden. Diese hohe Antwort-
quote (jm Gegensatz zu den ublichen 5 - 30%) HiBt auf ein ho-
hes Interesse am Befragungsgegenstand schlieBen.
Auch aus den Strukturdaten der befragten Unternehmen lassen
sich bestimmte Eigenschaften der Stichprobe ableiten, die den
Geltungsanspruch bestimmen und eingrenzen. Die Ergebnisse
sind unter den gemachten Einschrankungen demnach aussage-
kraftig fur mittlere bis groBere COMET-Anwender zwischen 100
und 500 Mitarbeitern (entspricht ca. 20 bis 100 Anwendern). In
dies em Intervall Iiegen 75% der befragten Unternehmen, die
Grundgesamtheit durfte hier bei zweitausend bis funftausend
Iiegen [SNI92a, o .S.). Die eine Halfte der Befragten hat weniger
als 193 Mitarbeiter (Median), die anderen 50% Iiegen daruber.
Betriebe des verarbeitenden Gewerbes dominieren gegenuber
den Handelsunternehmen.
Die miindliche Befragung stand unter der Devise "Einzelheiten
nachgehen". Es wurden nach sachlichen Kriterien aus drei Kate-
gorien Unternehmen herausgesucht, die fur unterschiedliche Ge-
gebenheiten typisch erschienen. Dieses Verfahren ist ebenfalls
nicht-reprasentativ und unterliegt - in diesem Fall gewollten -
subjektiven Einflussen. Fur die Klarung der Frage nach der Mit-
telstandsfahigkeit betriebswirtschaftlicher Softwarebibliotheken
war von Interesse, welche grundsatzlichen Unterschiede in den
nach Gegensatzen ausgesuchten Fallen bestanden.
Vom Befragungsgegenstand und der -taktik her konzentrierte
sich die mundliche Befragung auf zusatzliche und tiefergehende
Fragen, urn weitere Informationen zu erhalten, die nicht schrift-
Iich abgefragt werden konnten. Ferner wurde jeweils ein Unter-
nehmensbereich naher betrachtet, urn dort die konkreten Ablau-
fe mit COMET kennenzulernen und Probleme aufzunehmen.
Die Ergebnisse der mundlichen Befragung werden gegebe-
nenfalls in Form von Fallbeispielen eingebracht.

48
 2.2 Situation in mittleren Industrie- und Handelsuntemehmen ...

2.1.3 Interviewstrategie
Der IntelViewbogen wurde auf Basis der Auswertung des schrift-
lichen Fragebogens entwickelt. Ausschlaggebend fOr die Auf-
nahme einer Frage war einerseits der erganzende und vertiefen-
de Charakter zur schriftliche Befragung, andererseits solI ten in
starkerem MaBe Anforderungen an eine neue Software aufge-
nommen und uberpriift werden. Dies geschah z.B. auf Basis
funktionaler Defizite, die ein Unternehmen in COMET sah. Diese
Anforderungen wurden dann mit der Funktionalitat von R/3 ab-
geglichen. In der Terminologie der Wirtschaftsinformatik hatten
die IntelViews demnach den Charakter von Machbarkeitsunter-
suchungen.
Klassifizieren kann man die Vorgehensweise als 'strukturiertes
IntelView'. Bei der Untersuchung eines konkreten Betriebsablau-
fes wurde jeweils ein Unternehmensbereich herausgesucht, dem
in der schriftlichen Befragung eine relativ hohe Bedeutung fOr
den Unternehmenszweck zugemessen wurde und wo in hohem
MaBe Anpassungen bzw. Individualentwicklungen vorgenom-
men worden waren.

2.2 Situation in mittleren Industrie- und Handelsunternehmen

MERTENS sieht als Hauptproblem fOr die Informationsverarbeitung
in den neunziger Jahren, daB DV-Anwendungssysteme immer
komplexer werden und damit schwieriger zu beherrschen sind
[vgl. MERT90, 731. Mit dieser Entwicklung haben sowohl die An-
wender als auch die Anbieter zu kampfen. Es ist nun Aufgabe
der Wirtschaftsinformatik und der Softwareindustrie, nach Wegen
ZU suchen, urn die Chancen der Entwicklung richtig zu nutzen
und Risiken zu vermeiden.
In der folgenden Situationsanalyse werden die sechs wichtigsten
Herausforderungen fOr den Mittelstand vorgestellt und SchluB-
folgerungen fOr Methoden und Tools gezogen.

49
 2 Empirischer Befund der Befragung ''Mittelstandsfdhigkeit RlJ"

2.2.1 Neue Generation von Anwendungssoftware

Nachdem die einfacheren Tatigkeiten, die sich als erstes fur eine
Automation anboten, bereits weitgehend auf die Anwendungs-
software tibertragen worden sind, stehen nunmehr die schwieri-
geren zur rechnergesttitzten Informationsverarbeitung an. In der
Beurteilung der erreichten Verbesserung waren die befragten
DV-Verantwortlichen zu tiber 90% der Ansicht, sehr oder ziem-
lich viele Verbesserungen erreicht zu haben; die Nicht-DV-Spe-
zialisten unter den Befragten sogar in einem noch hbheren Ma-
Be.

Abbildung 3: Angaben in % der

Verbesserungen durch EDV-EinfOhrung .. .
Sind aus Siehl der befragten Untemehmen
meislen Milarbeiler o 20 40 60 80 100

dureh die EDV-

EinfOhrung Ver-
besserungen bzw. Er- bisher
leiehlerungen im be- erreicht
Iriebliehen Ablaut ein-
gelrelen und gibl es im
belriebliehen Ablauf
trolz EDV-Einsalz
noeh m6gliehe Ver-
besserungen?

QueUe: Betragung
'Mittelslandstahigkeil
I_sehr viele EJ zlemllch viele 0 wenlge
I
R/3'

Trotz der Feststellung, daB bisher schon viele Verbesserungen

erreicht wurden, werden von den Anwendern immer noch
ziernlich viele fur mbglich gehalten. Nur ca. 15% glauben, nur
noch wenige Verbesserungsmbglichkeiten bei sich zu entdecken.
Da aile Befragten bereits EDV nutzen, kbnnen Verbesserungen
nur durch eine Ablbsung der alten Anwendung - in diesem Fall
COMET - erreicht werden.
Folgerichtig planen fast dreiviertel der befragten Unternehmen,
in den nachsten Jahren ihre betriebswirtschaftliche An-
wendungssoftware COMET zu modernisieren oder abzulbsen.

50
 2.2 Situation in mittleren Industrie- und Handelsunternehmen ...

Abbildung 4: Planen
Anleil in % der befragten
Sie ein neues EDV-
Unlemehmen
Projekt in naherer Zu-
kunft? • geplanl
I!I evenluell
Quelle: Befragung 50% o nichl geplanl
'Millelstandsfahigkeit
Rl3'

Damit daraus nicht ein Investitionsstau wird, sind die Anbieter

gefordert, marktgerechte Lbsungen anzubieten. Oft beruht die
Bereitschaft zum Wechsel auf eine 2. Softwaregeneration auf
dem gestiegenen Leidensdruck der DV-Verantwortlichen und der
Fachabteilung. Auslbser sind gestiegene Anforderungen durch
Umsatzwachstum oder Kostendruck, erhbhte Integrationsnot-
wendigkeit - auch firmenubergreifend - durch die gestiegene
Informationsflut. Ein weiterer Aspekt ist der Bedarf nach einem
Informationssystem, das Transparenz schafft und damit Kosten
und Fehler vermeiden hilft. Mehrere Jahre gute und schlechte
Erfahrungen im Umgang mit einer Anwendungssoftware haben
gewisse Anforderungen gepragt, die entscheidenden EinfluB auf
die Erwartungen an eine Nachfolgesoftware haben.
Bei den Interviews wurden auch Unternehmen angetroffen, die
sich aus organisatorischen und wirtschaftlichen Grunden mit ei-
nem Generationswechsel Zeit lassen konnten, da die derzeitige
Lbsung den Anforderungen auf absehbare Zeit gerecht wird.
Meist haben diese Betriebe sehr viel eigenes Know-How im Um-
gang mit COMET aufgebaut, und sehr hohe Investitionen und
Kreativitat sind in Anpassungen und Erganzungen geflossen, die
fur den betrieblichen Ablauf unentbehrlich geworden sind. Das
Hauptproblem der DV-Verantwortlichen in solchen Betrieben ist
das absehbare Ende des Lebenszyklus: Support und die Weiter-
entwicklung der alten Lbsung werden eingeschrankt.
Dieser externe Zwang durch die Anbieter zum Generations-
wechsel, trotz u.U. ausreichender betriebswirtschaftlicher Funk-
tionalitat,ist zuruckzufuhren auf die enge Verzahnung von Soft-
waretechnologie und betriebswirtschaftlicher Logik in alten An-
wendungen. Dadurch ist es sehr aufwendig bis unmbglich,

51
2 Empirischer Befund der Befragung ''Mittelstandsfiihigkeit Rl3"

die FunktionaliHit auf neue technologische Plattformen zu portie-

ren. Vereinfacht ausgedriickt, mussen die Anwender gleichzeitig
die alte und die neue Welt beherrschen, sich zusatzlich mit
Schnittstellenproblemen auseinandersetzen und konnen Vorteile
der neuen Technologie nur teilweise nutzen.

SchluBfolgerung fur Methoden und Tools:

Durch den bevorstehenden Generationswechsel mug die Ent-
wicklung und Einsatzmoglichkeit adaptierbarer Softwarebiblio-
theken - gerade fur den Mittelstand - verbessert werden. Der
Wille zum technologischen Wechsel, beispielsweise auf daten-
bankbasierten Losungen, ist gegeben, Erneuerungsinvestitionen
sind geplant und Verbesserungspotentiale werden gesehen.
Es mussen spezifische Migrations- und Einfiihrungswerkzeu-
ge fur den Mittelstand eingesetzt werden, die kurze Projektlauf-
zeiten ermoglichen. Gleichzeitig sollte aber vermieden werden,
einfach die alte Losung auf R/3 abzubilden. Das Potential von
R/3 mug moglichst weitgehend erschlossen werden.
Vielversprechend fur die Anwender ist auch der erwartete Wett-
bewerb der grogen Hardwarehersteller, da die modernen Soft-
warebibliotheken auf offenen Systemen vieler Hardware-
hersteller ablauffahig sind. Was den Dienstleistungswettbewerb
angeht, bieten auch unabhangige Berater und Softwarehauser ihr
Potential am Markt an.

2.2.2 Gestiegene betriebswirtschaftliche Anforderungen

Aufgabenfelder, die in der Vergangenheit noch uberschaubar
waren, wie z.B. die Logistik, werden aufgrund neuerer Entwick-
lungen zunehmend unubersichtlicher. Eine Anwendungs-
software mug immer mehr Losungsalternativen (z.B. KANBAN
oder Fortschrittszahlen) anbieten und sHindig weiterentwickelt
werden.
Bestandteil jeder Begehung der Unternehmen war die Schilde-
rung der kritischen Vorgange in bestimmten Unternehmensberei-
chen. Beispielhaft sollten dabei Einsatzsituationen von COMET
skizziert werden, urn Anforderungen und Problemen auf den
Grund zu gehen.
Kritische Funktionen in bezug auf die Softwareanwendung gibt
es in jedem Unternehmen. Sie stellen den Engpag der Abwick-
lung von Vorgangen dar. Sie sind ein Argernis, da von allen

52
 2.2 Situation in mittkren Industrie- und Handelsunternehmen ...

Beteiligten viel Zeit und Muhe auf ihre Bewaltigung bzw. Ober-
bruckung verwandt werden muB. Bei einer Softwareauswahl
und Einfuhrung wird auf ihre Verbesserung das grbBte Augen-
merk gerichtet werden.
In den Produktionsunternehmen waren die angesprochenen
Themen: Rahmenvertrage, Qualitatswesen, Produktkalkulation,
Lagerverwaltung, Materialbereitstellung, Auftragsruckmeldung
und Fertigungsleitstand. In den Handelsunternehmen ging es urn
Materialdisposition, Bestellpolitik, schnelle Auftragserfassung und
Versandabwicklung. In allen naher befragten Unternehmen wur-
de hoher Handlungsbedarf in den Bereichen Controlling und
Kostenrechnung angemeldet.
Oem gerade im Bereich der GroBunternehmen viel propagierten
Argument der "Wettbewerbsvorteile durch individuelle Lbsun-
genii im Gegensatz zur "Nivellierung durch Standardsoftware"
wurde nicht zugestimmt. Als wesentlich wichtiger wurde die
schnelle und effektive Erfullung der Anforderungen mbglichst
weitgehend mit Standards angesehen. Ein Wettbewerbsnachteil
durch Standardisierung wird verneint. Die meisten Interview-
partner wuBten, was die Konkurrenz einsetzt. Vom Marktfuhrer
in einer Marktnische bis zum Wettbewerber in einem Massen-
markt mit einer mittleren Branchenposition, war die Stichprobe
bunt gemischt.
Das beobachtete Anforderungsprofil manifestiert sich meist
durch punktuelle Extremanforderungen. Viele Debitoren, wenige
Artikel im einen Fall; viele Artikel, wenige Debitoren im anderen
Fall; hohe Anforderungen an das Qualitatswesen im dritten Fall;
spezielle Abwicklung von Rahmenvertragen im vierten Fall; Tele-
fonerfassung von Auftragen im funften Fall etc ..

SchluBfolgerungen fOr Methoden und Tools:

Die spezifische Notwendigkeit einer integrierten Informations-
verarbeitung in einem bestimmten Unternehmen leitet sich ab
aus einem gewissen betriebswirtschaftlichen Komplexitatsgrad
bezuglich der Funktionen und Ablaufe sowie aus der Notwen-
digkeit der Transparenz durch ein Informationssystem. jenseits
der Untergrenze beginnt die PC-Kategorie, wo auf Basis einfa-
cher Lbsungen vernetzte Arbeitsplatze ausreichen. Bezogen auf
UnternehmensgrbBe oder Mitarbeiterzahl verschiebt sich dem-
nach durch zunehmende Komplexitat der betriebswirtschaftli-
chen Aufgabenfelder die Untergrenze fur moderne integrierte

53
2 Empirischer Befund der Befragung ''Mittelstandsjiihigkeit R/3"

Standardsoftware. Je kleiner ein Unternehmen ist, umso mehr

mug es sich an Standards halten. Deswegen ist die kostengtinsti-
ge Adaption von Standardlosungen die einzige Chance, eine
anforderungsgerechte Losung zu erreichen. Als Gestaltungs-
instrument hat sie die Aufgabe, die Komplexitat zu reduzieren
und betriebwirtschaftliche Anforderungen realisieren zu helfen.
Ansonsten mtissen die komplexen Aufgaben mit unzureichenden
Losungen und Werkzeugen angegangen werden, die risikoreich
(z.B. mangelnder Zugangsschutz) und auch kostenintensiv (z.B.
Wartung von Individualentwicklungen) werden konnen.

2.2.3 Informationstechnischer Fortschritt

Die Fortschritte der Informationstechnik ermoglichen neuartige
und verbesserte Losungen, fordern aber ihrerseits andere Quali-
fikationen und schaffen weitere Komplexitat. 1m Fall der betrach-
teten Unternehmen heigt das, die Neuheiten von R/3 bringen
viele Vereinfachungen gegentiber der COMET-Welt, aber sie
verlangen eben eine entsprechende Einarbeitung und werfen
neue Probleme auf, die vorher unbekannt waren. Ein Beispiel
dafur sind Client-/Server-Architekturen, die mehr Flexibilitat und
Dezentralisierung erlauben, aber durch das aufwendige Zusam-
menspiel vieler Komponenten komplizierter zu konzipieren und
anders zu tiberwachen sind.
Doch die Chancen, die im technologischen Fortschritt stecken,
tiberwiegen. Denn mit einer modernen datenbankbasierten
Software wie R/3 sind Unternehmen erstmals in der Lage, ein
Informationssystem aufzubauen. Auch zunehmend geforderte
Aktualitat der Information und Wunsch nach herstellerunabhan-
gigen Standards fordern den Wunsch nach besserer Software-
technologie. Bei der Einschatzung von technologischen Innova-
tionen durch die befragten Unternehmen ergaben sich drei
Gruppen. Bei der ersten Gruppe mit 'relationaler Datenbank'
und dem Betriebssystem 'UNIX' wird die Forderung nach Of-
fenheit, Herstellerunabhangigkeit und Standards deutlich.
Gleichzeitig wird der sicheren Verwaltung der Datenbasis, die ja
den eigentlichen Wert fur das Unternehmen darstellt, die hoch-
ste Prioriilit zugemessen. Die zweite Gruppe mit 'Graphischer
Benutzeroberflache' bis zur Prozessortechnologie 'RISC' wird
in ihrer Bedeutung als mittelmagig eingeschatzt, da sie nur indi-
rekt Vorteile bringt. Abgeschlagen sind die fur firmentibergrei-
fende Kommunikation stehenden 'Postdienste' und die im

54
 2.2 Situation in mittleren lndustrie- und Handelsuntemehmen ...

Rahmen der Benutzerinteraktion autkommende 'Multimedia-

Technologie' .

Tabelle 1: Welche Bedeutung geben die Unternehmen den neuen Infor-

Bedeutung der neuen mationstechnologien? Die Antwortalternativen konnten mit
Informatonstechno-
logien
Rangzahlen gewichtet werden (mit '1' die wichtigste, mit '8'
die unwichtigste Technologie usw.).
Quelle: Befragung
'Mittelstandsfahigkeit 1. Relationale Datenbank (1,9)
Rl3' (Mittelwerte in 2. Unix (2,6)
Klammern)
3. Graphische BenutzeroberfIache (4,3)
4. Sprachen der 4. Generation (4,4)
5. Client/Server-Architektur (4,4)
6. RISC-Architektur (4,5)
7. Postdienste ISDN, DATEX-P (5,7)
8. Multimedia-Technologie (7,2)

SchluBfolgerungen fur Methoden und Tools:

Man kann davon ausgehen, daB ein mittelstandisches Unterneh-
men (von 15 bis 150 aktiven Anwendern) mit seiner noch iiber-
schaubaren Struktur und den Mitarbeitern, die sich personlich
kennen, die Einfuhrung einer modernen Softwarebibliothek und
somit den Technologiesprung wesendich schneller und wirt-
schaftlicher schaffen kann, als ein GroBunternehmen. Die Adap-
tion als Gestaltungsinstrument nutzt dabei die informations-
technische Entwicklung zur Verbesserung ihrer Werkzeuge; ins-
besondere dahingehend, sie in hoherem MaBe anwendergerecht
zu gestalten und ihre Machtigkeit zu verbessern.

2.2.4 Breit verwendbare Standardsoftware

Softwarehauser miissen Anwendungssoftware anbieten, die in
ganz unterschiedlichen Kundenbetrieben einsetzbar ist und den-
noch den Besonderheiten dieser Betriebe gerecht wird.
MERTENS geht davon aus, daB dies "... nur durch stark parame-
trierte Software.,,11 [MERT90, 73) erreicht werden kann, was die
Komplexitat steigert und die Beherrschung noch schwieriger
macht. Hier wird allgemeiner von Adaption gesprochen, weil die

55
2 Empirischer Befund der Befragung ''Mitte!standsfahigkeit RlJ"

Parametereinstellung nur eines von vielen Adaptionsverfahren

ist. 1m Rahmen der Interviews ergab sich das folgend skizzierte
Ergebnis:
Allgemein war der Eindruck bei den kleineren verarbeitenden
Betrieben, daB sie sich einem (moglichst flexiblen) Standard an-
passen wollen. Beim "groBen" Mittelstand (ca. 500 bis 1.000 Mit-
arbeiter) will man moglichst weitgehend auf Standards setzen,
wobei das Unternehmen mit der groBten DV-Abteilung (5 Mitar-
beiter) davon ausgeht, daB Erweiterungen auf jeden Fall not-
wendig werden, ein zweites groBeres Unternehmen will sich
starker an den Moglichkeiten der Software orientieren. Dies be-
statigt vordergrtindig die Darstellung in der GMD-Studie tiber
den Softwaremarkt [vgl. BUSC89, 251, wo gezeigt wird, daB die
Standardisierbarkeit der Anwendungslbsung und die Homogeni-
tat der Informationsverarbeitung mit zunehmender Unterneh-
mensgroBe abnehmen. Allerdings ist das Ursache-Wirkungs-Ver-
haitnis nicht nachweisbar. Man konnte die steigende Tendenz
von Eigenentwicklungen auch auf eine groBere DV-Abteilung
zUrtickfuhren, die urn ihre Daseinsberechtigung streitet, und
nicht auf die abnehmende Standardisierbarkeit durch steigende
UnternehmensgroBe. Betrachtet man die ausschlaggebenden
Grtinde fur Individualentwicklungen naher, werden in der GMD-
Studie das erforderliche unternehmensspezifische Know-How,
mogliche groBere Flexibilitat und Verftigbarkeit von qualifizier-
tern Personal an erster Stelle genannt. Da der Geltungsbereich
der ersten beiden Grtinde von ausgereiften und flexiblen Stan-
dardlosungen zunehmend angegriffen wird, gewinnt der dritte
an Bedeutung als Hauptursache.
Ein weiterer Eindruck war, daB ftir eine Anforderung, die sowohl
in GroBunternehmen als auch im Mittelstand auftritt, jeweils die
gleiche Softwarelosung sinnvoll ist, die dem Problem als sol-
chern gerecht wird. Diese Eindrticke fuhren zur These, daB es
keine mittelstandsorientierte Losung im Sinne einer einfacheren
Losung geben kann. Fehlende Funktionalitat muBte individuell -
und damit teuer - programmiert werden. Es ist demnach immer
besser, wenn ein mittelstandisches Unternehmen aus einer Soft-
warebibliothek auswahlen kann (siehe 3).
Yom Produktspektrum her schlugen besondere Anforderungen
in erster Linie auf die Auftrags- und Fertigungsart bzw. auf die
Behandlung von Materialien durch, was jeweils unterschiedliche
Anforderungen an das Produktions- und Materialwirtschaftsmo-
dul zur Foige hat. Von Serien- tiber Varianten- bis zur Einzelfer-
tigung waren aile Fertigungsarten auf COMET realisiert zu fin-

56
 2.2 Situation in mittleren Industrie- und Handelsunternehmen ...

den. Vielfach gab es ProzeBliicken, die durch entsprechende

Anpassungen und Erganzungen iiberbruckt worden sind. Man-
che Vorgange werden immer noch rnanuell ausgefuhrt, die sinn-
vollerweise mit Hilfe einer Softwarefunktion ausgefuhrt wOrden,
z.B. die Einlastung von Fertigungsauftragen mit einem grafischen
Leitstand. Grundsatzlich wurde die Flexibilitat der Software und
eine gewisse Funktionalitiitsreserve der Anwendungen ge-
wOnscht, urn auf neue, sich dynamisch ergebende, quantitative
und qualitative Anforderungen besser und schneller reagieren zu
konnen.
Ferner kann es eine Branchenlosung i.e.S. nur bei Verfahren ge-
ben, die nur in dieser Branche zu finden sind und wofur eine
gewisse Spezialisierung des Softwarehauses vorteilhaft ist, z.B.
Anzeigen und Abonnentenabwicklung im Verlagswesen. Anson-
sten gibt es nur gute und schlechte, flexible und starre Losungen
(siehe 3.2.3).
Da tiber die Jahre hinweg in vielen Unternehmen immer mehr
Unternehmensbereiche begonnen haben, mit DV zu arbeiten,
und die intensivere Durchdringung geplant ist, bestehen erhohte
betriebswirtschaftliche Anforderungen, und die Einfiihrung wird
dadurch ebenfalls komplexer. Gleichzeitig sind in fast jedem Un-
ternehrnen zusatzliche Funktionen individuell erganzt oder gar
der Standard modifiziert worden, was allerlei Problerne in sich
birgt.

SchluBfolgerungen fur Methoden und Tools:

Weil ein moglichst breites Angebot von Funktionen in der Soft-
warebibliothek seine Grenzen in der Verwaltung und Weiter-
entwicklung hat, konnen nur die zunehmenden Adaptions- und
Erweiterungsfahigkeiten aus dem Dilemma einen Ausweg auf-
zeigen. Auch ist eine dynamische Adaption der Software im lau-
fenden Betrieb sehr wichtig, urn etwaige Organisations-
anderungen oder neue Anforderungen schnell realisieren zu
konnen. Am einfachsten geschieht dies in Anlehnung an die
vielen Alternativen, die eine breite betriebswirtschaftliche Soft-
warebibliothek bietet, und durch Ausnutzung der funktionalen
Entwicklungsreserven der Adaptionswerkzeuge. Vorgenommene
Anpassungen rniissen unabhangig von der Weiterentwicklung
der Standardsoftware sein, urn hier Kontinuitiit zu haben. Sie
miissen auch irn nachsten Release erhalten bleiben. Das Vorge-
hen bei der Einfiihrung und Adaption muB einfacher und besser
untersrutzt werden. Man muB wissen, welche Alternativen und

57
 2 Empirischer Befund der Befragung /IMitte!standsfahigkeit Rl3/1

Adaptionsmbglichkeiten die Softwarebibliothek ermbglicht, und

welche die beste Lbsung fOr das Unternehmen darstellt.

2.2.5 Probleme der Integration und Koexistenz mit Individualentwicklungen

Viele Unternehmen bauen ihre Informationsverarbeitungssyste-
me aus Fremdsoftware unterschiedlicher Provenienz zusammen.
Dabei entstehen Probleme der technischen Integration und be-
triebswirtschaftlichen Koexistenz mit den Fremdsystemen. FOr
die untersuchten COMET-Anwender ergibt sich folgendes Bild:

Abbildung 5: Welche
andere Software isl
neben COMET im Ein-
salz? Mehrfachnen-
nungen moglich.

Quelle: Befragung
"Mittelslandsfahig-keil
R/3"

Individualent- COMET- BranchenlOsung Kelne andere

wicklung Eigenentwicldung Software

Abbildung 5 zeigt, nur 17% haben bisher auf individuelle Lbsun-

gen verzichtet. Ober 80% haben zusatzlich zu COMET Software
im Einsatz, wobei es sich zum grbBten Teil urn Eigenentwick-
lungen handelt. Es ist fraglich, ob die hohe Verbreitung von In-
dividuallbsungen dann noch wirtschaftlich sinnvoll ist, wenn ei-
ne hochwertige Standardlbsung verfugbar ist. Weiterentwick-
lungs- und Wartungskosten sind oft nicht mehr vertretbar. Zum
Beispiel in den Bereichen Auftragsbearbeitung und Materialwirt-
schaft, in denen viele Individuallbsungen im Einsatz sind (jeweils
gut 25%), muB die Devise lauten, mbglichst viel durch Standard-
anwendungssoftware zu ersetzen. Neben der aufwendigen und
fehleranfalligen erstmaligen Gestaltung von Schnittstellen zwi-
schen den Applikationen ist das Hauptproblem die notwendige
Weiterentwicklung der Standardsoftware bei jedem Release-
wechsel.

58
 2.2 Situation in mittleren Industrie- und Handelsunternehmen ...

Viele Unternehmen haben mit "wilden" Eigenentwicklungen bei

COMET schlechte Etfahrungen gemacht und sind in eine Migra-
tions-Sackgasse geraten, so daB ein gewisse Sensibilitat fur die
Erhaltung der zukiinftigen Migrationsfahigkeit auch nach Anpas-
sungen besteht.

SchluBfolgerungen fOr Methoden und Tools:

Gerade die Ablbsung von unsystematisch entwickelten Indivi-
duallbsungen ist eine wichtige Aufgabe. Die Anwender haben
viele leidige Etfahrungen mit der pflege von Indivi-
dualentwicklungen und den Schnittstellenproblemen hinter sich;
dort wo eine Software ein Alleinstellungsmerkmal ist oder ein
sehr groBes Eigenknow-how bei Speziallbsungen gefragt ist, er-
scheint eine Individuallasung noch sinnvoll, fur die es sich auch
lohnt, eine aufwendige Koexistenzschnittstelle zu realisieren.
Eine zusatzliche Anforderung an die individuellen Gestaltungs-
maglichkeiten einer betriebswirtschaftlichen Softwarebibliothek
ist demnach die maglichst einfach realisierbare Koexistenz mit
anderen Lasungen im Rahmen der Migration, insbesondere
wenn ein Altsystem nur sukzessive umgestellt werden kann.

2.2.6 Fachkriftemangel
Ein wichtiges Thema der Befragung war die Organisation der
DV-Verantwortung und die notwendige Qualifikation bei Be-
nutzern und Benutzerbetreuern. Braucht man fur eine hahere
DV-Durchdringung und trotz auf moderner Softwaretechnologie
basierenden Lasungen mehr Spezialisten? Bei Nachfrage in den
Unternehmen stellte sich heraus, daB es in der Kategorie unter
300 Mitarbeitern einen bis drei Mitarbeiter mit DV-Verantwor-
tung gab, die bisweilen auch bestimmte Sonderaufgaben und
Linienfunktionen erfullten. Umgekehrt gab es Abteilungsleiter,
die sehr gute Kenntnisse im Umgang mit der Anwen-
dungs software hatten und sich gemeinsam mit Sachbearbeitern,
die fur das Operating (z.B. TagesabschluB oder Datensicherung)
verantwortlich waren, die DV-Aufgaben teilten. Bei dem graBten
befragten Unternehmen mit ca. 700 Mitarbeitern waren es funf
Mitarbeiter, die sich urn insgesamt ca. 120 Anwender zu kiim-
mern hatten. Die Notwendigkeit, eigene Kompetenz aufzu-
bauen, beurteilten die Befragten vallig unterschiedlich. Grund-
satzlich gilt, eine vorhandene DV-Abteilung will selbst mehr
Kompetenz an sich ziehen als ein DV-Verantwortlicher, der

59
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

durch andere Aufgaben noch beansprucht ist; er ist bereit, ex-

terne Berater starker einzubeziehen.
Aus allgemeiner Sieht muB erganzt werden, daB die Verbreitung
schwer zu beherrschender Anwendungssoftware zu einer zuneh-
menden Akademisierung vieler Berufe fuhren kann, was aus ei-
ner Reihe von Grunden nicht wLinschenswert ist. Die Entwertung
der berufliehen Fahigkeiten von Praktikern, die zu einer Freiset-
zung und eventuell zu Arbeitslosigkeit fuhrt, ist aus wirtschafts-
und gesellschaftspolitischen Grunden nachteilig.

SchluBfolgerungen fur Methoden und Tools:

Deswegen muB der Adaptionsspezialist fUr die Aufgaben einge-
setzt werden, die die hbchste Bedeutung, Komplexitat und Rele-
vanz besitzen. Er muB von einfacheren Adaptionsaufgaben entla-
stet werden, die der Anwender besser selbst durchfUhrt, d .h., es
mussen Adaptionswerkzeuge fur unterschiedliche Zielgruppen
entwickelt werden.
Fur die betriebliche Anwendung bedeutet dies, die Aufgaben
werden nieht mehr, sondern in erster Linie andere sein. Die Ad-
aptionswerkzeuge mussen einerseits ausgereifter und machtiger
werden, was die Mbglichkeiten fur den Spezialisten steigert, an-
dererseits einfacher und fehlertoleranter sein, urn den Benutzer-
kreis zu erweitern. Dadurch kbnnen externe oder interne Spe-
zialisten schneller eine Lbsung realisieren und Anwender kbn-
nen mit geringerem Aufwand Werkzeuge nutzen lernen, die
einfache Adaptionen ermbglichen, z.B. Formularanpassungen
und Auswertungen.

3 ODYSSEUS· Mittelstandsorientierte
Methodenentwicklung fUr RI3
1m Gegensatz zur klassischen Istanalyse und Sollkonzeption von
individuellen Informationssystemen, die sieh den aufwendigen
Modellierungstechniken des Softwareengineerings bedienen
mussen, soUte eine Anforderungsanalyse und die Suche nach ei-
ner "guten Lbsung" auf Basis einer betriebswirtschaftliehen Soft-
warebibliothek wie Ri3 mit effektiveren Methoden und in-

60
 3 .1 Ziele der ODYSSEUS-Methode '"

telligenten Werkzeugen beginnen. Gerade mittelstandische Un-

ternehmen konnen sich aufwendige Analysen nicht leisten bzw.
sie sind fur sie in den meisten Fallen auch gar nicht notwendig.
Besser ist der Weg, Anforderungen schnell zu identifizieren und
auf einen Prototypen umzusetzen, der dann Schritt fur Schritt
verbessert werden kann.

3.1 Ziele der ODYSSEUS-Methode

Auf Basis von Ergebnissen der Befragung "Mittelstandsfahigkeit
R/3" wurden folgende Ziele und Anforderungen an Methode
und ein Werkzeug definiert:
• vereinfachte Anforderungsanalyse und Abgleich durch
Checklisten und Zuordnung vorbereiteter betriebswirtschaftli-
cher Losungen ermoglichen,
• betriebswirtschaftliche Logik der Softwarebibliothek R/3
durch grafische Checklistenfragen darstellen,
• Anpassungsmoglichkeiten von R/3 besser erkennen und aus-
nut zen,
• Konzeptions- und Beratungskosten bzw. -fehler durch regel-
basiertes und computerunterstiitztes Vorgehen vermeiden,
• Anpassungen minimieren und durch Nachpflegehinweise
richtig umsetzen,
• teure Erganzungsentwicklungen minimieren und
• dynamische Adaption zukunftiger Anforderungen ermogli-
chen.
Die Zielvorstellung ist die ODYSSEUS-Methode (Organisatorisch-
dynamische Spezifikation von Softwarebibliotheken entspre-
chend der Unternehmensstruktur). Sie reprasentiert ein speziell
fur den Mittelstand entwickeltes Verfahren mit einer phasenori-
entierten Adaptionsstrategie. Die Zielsetzung ist, den individuel-
len AnpassungsprozeB moglichst einfach, schnell und wirtschaft-
lich abzuwickeln.

61
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

3.1.1 Pramissen der ODYSSEUS·Methode

Die hierfur notwendige Vorgehensweise hat einige charakteristi-
sche Pramissen, die bestimmte Elemente der klassischer Wasser-
fallmethode teilweise ersetzt oder auf ein Minimum beschrankt.
Der Aufwand einer Istanalyse wird zunachst vernachlassigt. Es
wird unterstellt, daB der Anwender seine Istprozesse kennt und
beschreiben kann. Erkennt der Berater durch bestimmte Indika-
toren, daB dies nicht zutrifft, geht es fur einen bestimmten Be-
reich zuruck in die Istanalyse. Standardm%o_ig wird lediglich ein
strukturierter Fragebogen (Profilcheckliste) zur Istabfrage ge-
nutzt, der aber mehr informativen Gehalt fur den Berater besitzt,
der das Unternehmen nicht kennt.
Die Suche nach einem Sollkonzept wird umgekehrt durchge-
fuhrt, d.h. zunachst soli dem Angebot der Standardsoftware
Aufmerksamkeit geschenkt werden. Dafur ist ein entsprechendes
Werkzeug notwendig, das die betriebswirtschaftlichen Potentiale
und funktionalen Alternativen anforderungsspezifisch demon-
strieren kann. Eine Navigation durch die Anpassungmbg-
lichkeiten des R!3 muB ein interaktiver ProzeE sein. Zu komplex
am R!3 ist immer nur das, was der Anwender nicht gebrauchen
kann, nicht versteht oder schlecht erklart bekommt! Erst dann
wird wieder klassisch vorgegangen, wenn weitere Anforderun-
gen durch Erganzungsentwicklung abgedeckt werden mussen.
Die Realieserung beginnt fur die eindeutigen Anforderungen
unmittelbar nach dem ersten Analyseschritt. Das dabei entwickel-
te Basissystem besitzt Komponenten, die immer notwendig sind
und deswegen gar nicht erst yom Anwender erfragt wurden.
Unsicherheit oder Unscharfe bei der Analyse soli sofort durch
die konkrete Oberprufung am angepaBten Basissystem ausge-
schaltet werden. Die zweite Kategorie von Anforderungen, die
einer genaueren Diskussion bedarf und auch die dritte Kategorie
mit ihren speziellen Problemen werden parallel angegangen.
Sind die Probleme dort gelbst, werden sie ins Basissystem uber-
fuhrt. Voraussetzung dafur, daB das heuristische und iterative
Vorgehen gelingen kann, sind eine schnelle Realisierbarkeit des
Basissystems und die weitgehende Transparenz und Revidier-
barkeit von Customzingeinstellungen im R!3. Das letztere ist die
Aufgabe der SAP, die hierfur von Release zu Release starkere
Anstrengungen unternimmt. Fur das schnelle Realisieren eines
Basissystems sollen im folgenden Methodik und Tool dargestellt
werden.

62
 3 .1 Zie/e der ODYSSEUS-Metbode ...

3.1.2 Heuristischer Druchbruch zum Basissystem mit dem LIVE KIT

Komplexitat beherrschen und Vorgehen strukturieren, manife-
stiert sich in einer heuristischen Phasenorientierung der ODYS-
SEUS-Methode durch die Kombination von drei Haupt-
Analyseschritten:
1m ersten Schritt wird zunacht der Einftihrungsumfang ermittelt.
Das R/3 wird in einftihrungsrelevante Objekte zerlegt, die nach
den Kategorien Standard und Option klassifiziert sind.
1m zweiten Schritt wird Unnotiges ausgeklammert, was zu einer
Reduktion der Komplexitat der R/3-Softwarebiliothek fUhrt und
gleichzeitig die anforderungsrelevanten Teile herausarbeitet.
Denn ein System ist nur dann perfekt, wenn man nichts mehr
reduzieren kann.
1m dritten Schritt wird durch Zuordnung von vorbereiteten, typi-
schen Losungen eine schnelle "gute" Eroffnungslosung gesucht.

Abbildung 6: Heu· Schrln 1 Schrin2 ErOffnungslOsung

ristisches Prinzip der
Zerlegung In Objekte Reduktlon auls Notwendlf/f Zuordnung typologlscher
Odysseus·Methode • StandardlOptionsprlnzlp ElnIOhrungsorlentiert->IM L.,.L_os_u_ng
:;..,e_n _ _ _--J

O rganlsatlOf\-_ _ _ _...
ReduKtionschecldlste
Daten Funktlonsauswahl
• Strateg1efragen
Vorgatlge • Fachberelch
• Baslsfragen
Funktlonen • Sachgeblet • Integrattonslragen

•
Umlang ermltteln
•
Wlchtlges Ermltteln
•
Anlorderungen erfOllen

63
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

3.2 Von der ODYSSEUS-Methode zum Werkzeug LIVE KIT

Auf Basis der Erfahrungen von Siemens Nixdorf mit der Verwen-
dung von Checklisten bot sich das CHICO-Verfahren (Checklist
Input Customeroriented Output) von COMET an. In Erweiterung
zu CHICO wurden bei der Realisierung des Rl3 LIVE KIT's neue
Aufgaben und Ziele verfolgt, so daB als eine Neuentwicklung
unter WINDOWS 3.1 das Checklisten- und Konfigurationswerk-
zeug LIVE KIT entstand.

Abbildung 7: Technische Funktionen

Bereich seleklieren - • PC basiertes System fOr dezentralen
• Grafische ObertlAche mit Hmefunktionen
Fachbereichs-/Sach-
• Regelbasiertes Expertensystem
gebielsauswahl • Integration zu Rl3 (IMG , ~".' nm;7 ; nrrt "h ,A I '"
• Oatenbank liir Anforderungsdokumentation

Methodlsche Erweiterungen
• Optionale Funktionsauswahl
• CheckUstenfragen als Leitfaden
• Regelbasierte und detaillierte Reduklion
• Inlegrierte und projektorientierte Reduklion
• Simulation von unterschi edlichnEe~~n~:;::~:~iii;;i;
• Vorschll!ge, Altemativen und K,
• Konzeptionelle H i ~e bei der Suche nach
besten LOsung durch Zuordnung
• Ein·Tages·Workshops

Besondere Kennzeichen sind, neben der grafischen Oberflache,

Benutzerfreundlichkeit, Mehrsprachigkeit, Projektverwaltung,
insbesondere die Integration der ODYSSEUS-Methode in die ge-
samte Ablaufgestaltung.
Das LIVE KIT fuhrt den Kunden anhand einer grafischen Check-
liste durch die Anpassungsmoglichkeiten des Rl3. Dabei werden
die betriebswirtschaftlichen Anforderungen strukturiert erfragt
und sofort gegen Rl3 abgeglichen.

64
 3 .2 Von der ODYSSEUS-Methode zum Werkzeug llVE KIT ...

3.2.1 Profilcheckliste, optionale Funktionsauswahl und Reduktionscheckliste

Die ersten beiden Schritte haben zum Ziel, Funktionsauswahl
und Anpassungsanforderungen abzufragen und darnit eine Re-
duktion des Adaptionsaufwandes zu erreichen.
1m Rahmen einer Profllcheckliste sollen zuerst allgemeine In-
formationen tiber das jeweilige Unternehmen gesammelt wer-
den. Sinnvollerweise sollen darnit folgende Themengebiete ab-
gefragt werden:
• allgemeine Projekt- und Unternehmensinformationen,
• Informationen, die nicht skaliert abgefragt werden konnen,
sondern die Moglichkeit einer offenen Antwort bieten mtis-
sen,
• Informationen, die in allen Fachbereichen benotigt werden,
urn redundante Fragen spater in der Reduktionscheckliste zu
vermeiden und
• Fragen zu Mengengeriisten, Migration und Koexistenz.

Abbildung8:
Bereich selektieren -
Fachbereichs-/Sach-
gebietsauswahl

?
?
?
?
7
?
Finanzbuchhallung B... icht .. V",k...., '1
E.weit ... t... Hauptbuch I+A.ehivillf..1Q Beleoe 7
ronanzdi.po . ~ ion
r onanllMtt"'eehnung

65
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

Eine erste Reduktion erfolgt tiber die Auswahl einzelner Anwen-

dungskomponenten und der angebotenen Funktionalitaten in-
nerhalb der Funktionshierarchie. Dabei handelt es sich urn ein
zweistufiges Funktionsmodell von R/3 mit verpflichtenden
und optionalen "Gebieten".
In der Reduktionscheck1iste orientieren sich die Fragen an den
Anpassungsmoglichkeiten von R/3 mit dem Ziel, nicht benotigte
Anpassungen weglassen zu konnen. Beispiele: Wenn ein Unter-
nehmen nur eine zentrale Verkaufsorganisation besitzt oder mit
dem Industriekontenrahmen arbeitet, fallen sehr viele Anpas-
sungsschritte weg.
Die Fragen sind dabei einfach und verstandlich formuliert. Von
den Z.Zt. 864 Fragen werden je nach Funktionsauswahl zwischen
200 und 600 gestellt. Der Rest wird automatisch durch den Re-
gelmechanismus beantwortet. Es gibt verschiedene Fragetypen,
wobei jeweils ein sinnvoller Vorschlag fur die einfachste Mog-
lichkeit gegeben wird, Alternativen und Folgen sind erklart.

Abbildung 9:
Reduktionslrage mit
Notizlenster im LIVE
KIT

Samtliche Ergebnisse aus der Funktionsauswahl und den Re-

duktionsfragen werden im Anforderungsdictionary gespeichert
und geben so einen jederzeit auswertbaren Dberblick tiber aus-
gewahlte Bereiche und beantwortete Fragen. Die Ergebnisse
konnen dann auf Basis eines zweiten Regelwerks durch ein

66
 3.2 Von der ODYSSEUS-Methode zum Werkzeug liVE KIT ...

Konfigurationswerkzeug ausgewertet und an das R/3-

Kundensystem ilbergeben werden.
1m R/3-System werden nicht-relevante Teile des R/3-Ein-
fuhrungsleitfadens ausgeblendet. Der Umfang reduziert sich da-
durch von ca. 4600 (R/3, Version 2.2) auf eine kleinere Zahl
(40% bis 60%) von IMG-Bausteinen und somit denjenigen Cu-
stomizing-Transaktionen, die abzuarbeiten sind.

Abbildung 10:
Komponenten des Einfiihrungsleitfaden (lUG)
Rl3-Einfiihrungs-
leitfadens (IMG) I. ~" . . . .. I._ H.i . ... ""IlMI<Wt~ •
..... ~l l . f. . . . . . . . . .I _ ' ..... _ _ ~
• r. ln _

2. t..o.tooo"I . _ _ _ ...l t i l _ ...

,.",IIlIlorlll _ _ . _
I_ .I••'.. .." ._
'i. ..... 'I_tl,
...
~

•• ...
I_....,..
.... ....... .,.It'WJI..
tOIIfoI.~ . . . . . . . ~

.................
M ....
_. _ e . ..
- ~ I I. ,.. ..... ___ ... ....I u-'WI '110'" .... -*-,_
,
_ _ . .li.ot ... ~~.i a..

-
,. fI ~ lI .oIl . a."'I

...... II . . . ~' _• • , ~ .......... -0 ·. *-t . . . .·),

t . .. ,.", _.t. _
~
l ...... ~ . _'"' . . .' . ... I tu _ _
.

---
.f ,
.......
o..u..-_ ,••,_ ... .......,.J........
11 _ ... . " ." . .u"...... - . - ....
"I~

-
- _ ~~ . I '.I ..~.l fJ... .

-,_,........
- - . . ...... ~!! .
I • ..,. ""'UVOI . . _ _ ."ItI_ I i I "'. ....... ....... ' .... 1_
.
: Baustein I I
. . . . . ____ 01 .• _ .11 .010 . ....

~___
._-
. . ._ _ ,• • - .- ,M,QI.. _
. . . , . . . . . ..... ~M I!..-.T.. L-n.

IStatusinforrryation I
•
~

_ ._ , •.-.....- I.t-.' ......

__ . ~_ . ......... " '.. """""""\11. _ ~

,""1\'_

Neben dem SO ermittelten kundenindividuellen Anpassungsauf-

wand, der im gilnstigen Fall durch Dbernahme einer vorhande-
nen Einstellung wegfallt, gibt es Einstellungen, die yom Anwen-
der unabhangig in jedem Fall ilberprilft werden milssen. Diese
werden in der sogenannten "ALWAYS"-Liste verwaltet.
Dadurch ist eine anforderungsgerechte Projektierung sehr frilh-
zeitig moglich, die zusatzlich durch viele konkrete Customizing-
Hinweise (Nachpflegehinweise, reduzierter Einfilhrungsleitfaden
und Anforderungsdictionary) unterstiltzt wird. Gerade eine
Workshop-Einfuhrung mit Beteiligung der Anwender wird damit
sehr gut unterstiltzt.
Daneben kann auf Basis der Antworten eine Kalkulation des be-
notigten Dienstieistungsbedarfs fur die Anpassung von R/3 vor-
genommen werden, was eine Kaufentscheidung sicherer macht.
Der Kunde erhalt dabei Transparenz ilber die Realisierungsko-
sten bestimmter Anforderungen und kann sie seinem erwarteten
Nutzen gegenilberstellen.

67
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

3.2.2 Zuordnungscheckliste
Die Zuordnungscheckliste setzt in der zweiten Phase auf die
durch die Reduktionscheckliste als relevant ermittelten Elemente
auf. Dabei werden aus mehreren Alternativen bestehende, vorge-
fertigte betriebswirtschaftliche Lbsungen zur Auswahl angeboten.
Diese Lbsungen sind betriebwirtschaftlich definiert und kbnnen
eine oder mehrere vordefinierte Tabellen umfassen.
SAP liefert in der Standardversion bereits einige vorgefertigte
Profile aus, z.B. den Gemeinschaftskontenrahmen (GKR) und
den Industriekontenrahmen (IKR). Wenn keine oder nicht aus-
reichende Profile vorhanden sind, werden typische betriebswirt-
schaftliche Profile fur die Elemente entwickelt. In der Abbildung
11 sind die organisatorischen Alternativen der Geschaftsbe-
reichsdefinition in filnf Profile aufgeteilt:

Abbildung 11:
Zuordnungselement
Geschaftsbereiche

Es handelt sich hierbei um eine sog. Monitoring-Zuordnung, bei

der der Anwender ilberprilfen kann, ob die bisher gegebenen
Antworten auch mit seinen Anforderungen ilbereinstimmen. 1st
eine Alternative evaluiert worden, die dies nicht erfilllt, kann im
Beantwortungslauf zurilckgesprungen werden, bis das ge-
wilnschte Ergebnis dargestellt wird.

68
 3.2 Von der ODYSSEUS-Methode zum Werkzeug /JVE KIT ...

Als Resultat der Zuordnungsphase werden die entsprechenden

betriebswirtschaftlichen Profile ebenfalls tiber Regeln ausge-
wahlt.
Die Lbsungssammlung kann innerhalb eines Konzerns erweitert
oder starker detailliert werden, um Konzernstandards und
-lbsungen so einfacher wiedetverwenden zu kbnnen.

-, .... -, _......
Abbildung 12: Losungsblbllothek angepaBt fUr den Konzem
L6sungsbibliothek fur ,
lifl
••• • •• • c::!> " :'" •••
Konzerne
I,,":,"" 0 0 Z_M
...... '~l,.. .............
1"'7' I- 0 0 "":'"" X X ~
1"7"
I,,":,"" ~4 ~ ;JI:;O I~ 0
•
Kat2:~~-

•
1.6""",
"'7' • • X • G)
I"";'" e Q "":""
1"7" icht rele ant ~ I Kfnu~ 1
()
I"";,,, Frem sy em "
ProJektl6sungen

Ftir zugeordnete Profile liegen Lbsungsdokumentationen vor.

3.2.3 Effektivitit nach Komplexitiit der Anforderungen

Die Effektivitat der Methode ist, je nach Komplexitat der Anfor-
derungen, von Unternehmen zu Unternehmen unterschiedlich.
Dem Anwender, der viele komplexe Anforderungen hat, kann
auch weniger durch Reduktion "geholfen" werden, da mit stei-
gender Komplexitat der Vorteil der Reduktion abnimmt. Der
Anteil von Customizing und Erganzungsentwicklung schwankt
ebenfalls.

Abbildung 13: Ef- KORZER

fektivilal des LIVE
KIT Einsatzes

© IBIS Prof. Thome

GmbH in Kooperali-
on mil Siemens Nix-
dorf

,
,
~G~ L k-~~~~~
5_ • Zuordnung • Cuatomi2ing • EtgInzung

69
3 ODYSSEUS - Mitte/stancisorientierte Methodenentwick/ung fur R13

Abbildung 13 soU zum Ausdruck bringen, daB fur den Mittel-

stand - mit seinen weniger komplexen Anforderungen - im h6-
heren MaBe nicht relevante FunktionalWit ausgeklammert und
Standards tibernommen werden k6nnen.
Aile bisher genannten Anforderungen der ODYSSEUS-Methode
sind im LIVE KIT Version 3.0c realisiert. KommerzieU wird dieses
Werkzeug von Siemens Nixdorf eingesetzt.

3.2.4 Erfahrungen aus den LIVE KIT· Workshops

Der konkrete Ablauf des Workshops richtet sich ganz nach der
spezifischen Situation des Kunden. Nach Sammlung von aUge-
meinen Informationen tiber das Unternehmen in der Profil-
checkliste, mtissen die verantwortlichen Mitarbeiter des Unter-
nehmens an einen Tisch gebracht werden. Erfahrungen zeigen,
daB der Geschaftsfuhrer unbedingt an diesem Workshop teil-
nehmen soUte. Die Leitung dieses Workshops tibernehmen zwei
LIVE KIT-Berater ftir Logistik bzw. Rechnungswesen, die tiber
ein gewisses R/3-Uberblickswissen verftigen mtissen. Ebenso
soUte der am Workshop teilnehmende Personenkreis sich bereits
einen ersten Eindruck von R/3 gemacht haben. Dies geschieht
am besten mit den ProzeBfaUstudien der Modellfirma LIVE AG,
die ebenfaUs vom Lehrstuhl Prof. Thome, der IBIS Prof. Thome
GmbH und der Siemens Nixdorf Informationssysteme AG ge-
meinsam entwickelt werden.

Abbildung 14: LIVE

2
KIT Einsatz-Szenario IT 1. Zeltpunkt
1 PlOjekll
PIOjekt n
IIJPUI._
SoIIIalnzeptIoi'l
fl 2. Vorbereltung Re-Adap!lon
~ Ofganlsallons·

;Ar ~~
~3.
~
UVE KIT-Konzem Team

4. LIVE KIT-Workshop 31 AI.IIgabe 1---.

4 TeIInIihrrief
00- PMH
7
~ 5. Au awertung
()jajlflkalIon
L ~mog
FeecItNIck '"

~ 6. LIVE KIT-ErgebnlaprlsenlaUon 5~ 6 _I. ,:"

@ 7. Auewertuog -+- ~
~ AnIoRI«rtmgen

I
Anforderungaalmul.Uon NIIICMrageo

I=~AG I Rl3-Analyzer 0.8.

Kri"sche Prozesse

1==-1 1OrganlsaUonsarlalyse I
ErgAnzungsentwicklung

70
 3.2 Von der ODYSSEUS-Methode zum Werkzeug IJVE KIT ...

1m Normalfall sind ein bis drei Tage fur die reine Beantwortung
der Fragen ausreichend. Etwa 80% Prozent der Fragen sind in-
nerhalb von ein bis zwei Minuten zu beantworten. Ein Ftinfte!
der Themen muB ausftihrlicher erlautert werden, so daB hierfur
funf bis zehn Minuten bis zur Klarung ben6tigt werden, urn eine
JA oder NEIN-Antwort geben zu k6nnen. Bei Unsicherheit wird
dokumentiert, daB es sich zunachst urn eine vorlaufige Antwort
hande!t.
Der LIVE KIT-Berater muB darauf achten, daB keine unn6tigen
Detaildiskussionen aufkommen. Probleme, die auf sehr betriebs-
spezifischen Anforderungen beruhen, sollen identifiziert und
aufgenommen werden. Der Bedarf fur notwendige Detail- und
Organisationsanalysen wird so definiert und tiberschaubar. Die
Anzahl dieser Themen belief sich bei den bisherigen Testfirmen
auf funf bis zehn pro Kunde.
Nach Durchfuhrung des Checklistenlaufs stellten fast aIle An-
wender fest, daB sie einen besseren Uberblick und Einblick in
die M6glichkeiten von Rl3 bekommen haben. Die Komplexitat
der Funktionalitat erschien ihnen jetzt eher eine Starke als eine
Schwache zu sein.
Mit Weiterentwicklung der Ltickenanalyse werden fur die Reali-
sierungphase der Anpassungen weitere Auswertungen und
Komponenten zur Verfugung gestellt werden. Abbildung 15 gibt
einen Uberblick tiber die erzeugten Output-Dokumente:

Abbildung 15: Out- Automatisch erzeugter Output

put-Dokumente des • Antwortiibersjcht m~ Auswahl und Antworten
LIVE KIT Workshops • Reduzlerte EinfOhrungsleitfiiden in Rf.l
• Anpassungsautwand (Gewichtungsfaktoren)
• Auswertungen fur CUSlomizingeinsteliungen
• Organisatjonselemente
• Bildsteuerung Stammdaten
• ausgewilite Belege
• etc.
• Typische LOsungen

"Halb"-automatische vorlagen-baslerter Output

• Reduklionsbericht pro Fachbereich
• Management summary
• Anpassungsautwand (Zeit und Kosten)

Dokumentatlon
• Profilcheckliste zur Voroereitung
• Always Transaktionen
• Typische L6sungen

71
3 ODYSSEUS - Mittelstandsorientierte MetbodenentwicklungJur Rl3

Nach dem Workshop sollten die Anforderungen des Untemeh-

men in die folgenden drei Projektkategorien eingeordnet werden
kbnnen Csiehe Abbildung 16). Liegen Anforderungen innerhalb
des Standards oder werden sie durch vorbereitete Zuordnungslb-
sungen abgedeckt, kann direkt mit der Umsetzung begonnen
werden. Eine Customizingdiskussion ist fur soIche Anforder-
ungen notwendig, die naher spezifiziert oder aufwendiger im
R/3 einzustellen sind. In die dritte Kategorie fallen die Problem-
faIle, die Erganzungen, Schnittstellen, sonstige Sonderanalysen
oder Entscheidungen verlangen.

Abbildung 16: LIVE

KIT Anforderungska-
tegorien fUr ein Mit-
telstandsprojekt
Problem
© IBIS Prof. Thome Management
GmbH in Kooperation
mit Siemens Nixdorf t! ~Atbthts9ruppen ~f'i~>~
~"'Ni!!Ilsl% Rt>IeaSil pry
~ .ErganlUng.:m ~:": N~;
}j~nI"s~lI~n " ~: .>~

1st ein Problem gelbst, sollte es in die Kategorie 1 uberfuhrt und

im Basissystem realisiert werden. Umgekehrt haben die bereits
durchgefuhrten Realisierungen im Basissystem die Aufgabe, fur
eine fundierte Diskussion im Bereich zwei und drei zu sorgen.
Dort bereits umgesetzte Lbsungen liefem die konkreten Anknup-
fungspunkte.

3.2.5 LIVE Modelling - Einbettung in ein Vorgehensmodell

Der Gesamtablauf eines LIVE KIT-Projektes stellt sich folgender-
maBen dar:
In der Preparation-Phase wird ein systematischer, konzentrier-
ter und toolunterstutzter Wissensaustausch zwischen extemem
Berater und Anwender durchgefuhrt. Hier ist auch die LIVE AG
als dokumentierte R/3-Modellfirma wichtig. Sie sollte zum Ken-
nenlemen und Einarbeiten in die R/3-Prozesse eingesetzt wer-

72
 3.L Von aer ULJYS~EUS-Methoae zum Werkzeug LIVE KIT ...

den. In uber 200 einfach bis komplexen prozeBorientierten Fall-

studien kann sich der Anwender mit den Konventionen von R/3
anhand integrierter Ablaufe vertraut machen. 1m Modellmandan-
ten existiert ein vollstandiges betriebswirtschaftlich-konsistentes
Unternehmen, das speziell fUr die Funktionsdemonstration von
R/3 designt wurde. Die Entwickler am Lehrstuhl von Prof.
Thome haben die Inhalte und Darstellung der Modellfirma im
Rahmen des VULCAN-Projektes schon seit 1992 aufgebaut und
weiterentwickelt.
In der Analysephase (IA) stehen der nutzbare Standardurnfang,
ausgewahlte typische L6sungen und ein spezifischer Einftih-
rungsleitfaden als Diskussiongrundlage zur Verfugung. In zusatz-
lichen Workshops werden die Aufwandsschatzung fixiert und
die identifizierten Probleme naher definiert. Danach kann ein
Meilenstein fUr eine Investitionsentscheidung gesetzt sein.

Abbildung 17: Pro-

jektphasen fur ein
Mittelstandsprojekt

© IBIS Prof. Thome

GmbH in Kooperation
mit Siemens Nixdorf

In der Designphase (ID) wird bereits realisiert, zunachst an-

hand der Zuordnungsdokumentation oder auf Basis von Custo-
mizingexperimenten in der Modellfirma. Auch definierte Ergan-
zungs- und Schnittstellenentwicklungen mussen hier parallel
beginnen.
In der Konstruktionsphase (Ie) liegt der Schwerpunkt auf der
Realisierung. Das Basissystem entsteht, wird getestet, integriert
und vervollstandigt. Fur bestimmte Anforderungen werden nun
konkrete funktionale Details am echten System erst erkennbar.

73
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung jur Rl3

Es soli bewuBt Rucksprtinge geben, die aufgrund neudefinierter

Anforderungen, neuerkannter Moglichkeiten oder nichterfUlIten
Detailanforderungen in jedem Projekt vorkommen werden.
Der Roll-Out (IR) erfolgt zusammen mit dem qualitatsgesicher-
ten System, Datenmigration und Schulung. Auch werden hier die
endgultigen Ablaufe festgelegt, urn Benutzerwtinsche hier noch
einflieBen zu lassen. 1m Normalfall sollte aber hier nur noch
Feintuning notwendig sein, da Mitarbeiter aus der Fachabteilung
vorher schon in Analyse und Konstruktion Teilprozesse mitein-
ander abgestimmt haben.

3.3 Voraussetzung fur die GeschaftsprozeBgestaltung im Mittelstand:

Anpassende Referenzmodellieru ng
Gegenuber anderen Ansatzen beginnt im ODYSSEUS LIVE KIT-
SZenario eine GeschaftsprozeBmodellierung erst dann, wenn ein
Bedarf identifiziert wird. Dies kann am Anfang, im Laufe des
Projektes oder auch gar nicht der Fall sein. Grtinde hierfUr sind
die hohen Kosten und die LIVE KIT-Strategie, die vorab viele
Hilfestellungen zur Verbesserung des lstzustandes und der Pro-
zeBgestaltung liefert.
Ziel ist es, fUr die Organisationsanalyse der Geschaftsprozesse
die Ergebnisse der Reduktion und Zuordnung an Modellierungs-
und Simulationswerkzeuge zu ubergeben, urn dort kun-
denspezifische Modelle aufzubauen. Solche Modelle helfen
dann, spezifische Fragestellungen zu beantworten oder Konsi-
stenzprtifungen durchzufUhren. Beispielsweise: Welche ProzeB-
kette ist unvollstandig oder welche organisatorischen Alternati-
yen sind moglich?
Auf Basis der bisher erreichten Abdeckung der Anforderungen
wird auf Funktions- und ProzeBlucken hingewiesen. Fur Nicht-
Modellierungs-Experten sollte eine grafisch-textuelle Erklarung
vorliegen. Urn den Erganzungsaufwand zu reduzieren, kann
eventuell erneut mit Reduktion oder Zuordnung begonnen wer-
den. Die Anforderungen, die sich aus der Deckungslucke erge-
ben, mussen dann mit entsprechenden Werkzeugen zur Ergan-
zungsentwicklung projektiert werden.

74
 3.3 Voraussetzung!iir die Gescha!tsprozejSgestaltung im Mittelstand: ...

1m folgenden wird ein Konzept zur anpassenden Referenzmo-

dellierung vorgestellt, basierend auf den in der "ODYSSEUS
LIVE KIT-Losungsbibliothek" vorhandenen Referenzlosungen fur
R/3.

3.3.1 8aupline fur betriebswirtschaftliche Informationssysteme

Vereinfachende Abbildungen der Realitat, die die Systemanalyse
und den Sollentwurf von betriebswirtschaftlichen Informations-
systemen untersrutzen, werden als Referenzmodellierung be-
zeichnet. Die Relevanz der Referenzmodelle ergibt sich aus ihrer
Verwendung als Bauplan fur die Softwareentwicklung.
Sie konnen gleichermaBen als gerichteter Vorgehensplan zur
Individualentwicklung oder als Anderungsplan zur Anpassung
von Standardsoftwarebibliotheken eingesetzt werden.
Bei der Komplexitat von betrieblichen Informationssystemen ist
es ein prinzipieller Nachteil, wenn dem Referenzmodell Werk-
zeugunterstutzung fehlt und keine existierende Softwarelosung
dem Modell zugrundeliegt. Trotzdem haben "Papier"-Referenz-
modelle bei Unternehmensberatern eine gewisse praktische Be-
deutung erlangt, weil sie das Vorgehen zumindest systema-
tisieren.

3.3.1.1 Referenzmodelle zur Adaption von Softwarebibliotheken

Fur Softwarebibliotheken wie R/3 von SAP liefern betriebswirt-
schaftliche Referenzmodelle eine ubersichtliche konzeptionelle
Darstellung der Bestandteile. In Form von Grafiken werden Da-
tencluster, Funktionsgruppen oder ProzeBketten abgebildet, die
miteinander verknupft sind und aus unterschiedlichen Sichten
betrachtet werden konnen.
1m Rahmen eines grafischen Werkzeuges kann so auf Basis von
Daten-, Funktions- und ProzeBreferenzmodellen eine Auswahl-
untersrutzung ermoglicht werden. Das Problem dieser Refe-
renzmodelle ist die mangelnde Vollstandigkeit, Aktualitat und
Detailliertheit.

75
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

Auch fehlt es an der Integration in die Projektierung und einer

sinnvollen Anbindung an die Softwarebibliothek, so daB die dort
modellierten Ergebnisse auf einem sehr abstrakten Niveau blei-
ben und sowohl konzeptionell als auch technisch nicht durch
ein integriertes Adaptionskonzept und -werkzeug umgesetzt
werden k6nnen.
Auch erscheint eine fUr Entwickler und damit Informatiker aus-
gelegte Darstellungsform nicht unbedingt geeignet zu sein, um
den Anwender im KonzeptionsprozeB zu unterstUtzen. Eine zu
starke Vereinfachung eines Referenzmodelles wiederum kann zu
Aussageverlusten und damit Fehleinschatzungen fUhren. V6llig
unberilcksichtigt bleiben auch Wirtschaftlichkeitsaspekte.
Trotzdem k6nnen Referenzmodelle zumindest bei gewissen
Themen mehr Transparenz auch fUr den betriebswirtschaftlichen
Experten schaffen, der sich so sehr schnell aus unterschiedlichen
Sichten mit einem bestimmten Sachverhalt beschaftigen kann.
Dies beweist der Erfolg des von der SAP entwickelten R/3-
Analyzers.

3.3.1.2 Adaptions-Monitoring
Eine andere erfolgversprechende Einsatzm6glichkeit von intelli-
genten Referenzmodellen ist die Analyse der Ergebnisse von An-
passungen einer Standardsoftware durch einen graphischen
Monitor. Seine Aufgabe ware zum Beispiel, ein spezifisches
Kundenorganisationsmodell zu erzeugen, das im Sinne einer
Monitorfunktion dem Experten hilft, die Auswirkungen von Ta-
belleneintragen im Customizing einer Standardsoftware zu uber-
schau en und zu bewerten. Dies kann man sich auch fur Funk-
tionen und Prozesse vorstellen, wo es sicher sehr hilfreich ist,
um Transparenz und Fehler beim komplexen AnpassungsprozeB
von Standardsoftware zu vermeiden. Etwas schwieriger ist die
Analyse der Datenmodelle, da hier keine Elemente wegfallen,
sondern durch Tabelleneintrage genutzt bzw. aktiviert werden.
Grundgedanke dieser Vorgehensweise ist die iterative Suche
nach einer besseren wirtschaftlichen L6sung durch Anforde-
rungsabgleich von Potential der Softwarebibliothek und Reorga-
nisationsanforderungen CModebegriff: "Re-engineering").
Definierte Anpassungsalternativen der Softwarebibliothek wer-
den durch Anderungen in grafischen Modellen spezifiziert und

76
 3.3 Voraussetzungjiir die GeschiijtsprozejSgestaltung im Mittelstand: ...

zugeordnet. Da die ausgesuchten Losungen vorgefertigte Custo-

mizingeinstellungen sind, konnen sie uber eine "Varianten-
sruckliste" einen Prototypen automatisch auf Basis einer Softwa-
rebibliothek erzeugen. Dies ware dann eine echte parametrisierte
oder anpassende Modellierung. Erkenntnisse aus diesem ProzeB
munden wiederum in Reorganisationsvorschlagen.
Dieses zweite Konzept wird in der ODYSSEUS-Methode verfolgt.
Sie ist im LIVE KIT bereits realisiert.

3.3.1.3 Modellansichten • Typische Losungen der ODYSSEUS LIVE KIT·

Losungsbibliothek
Zwei der drei notwendigen Schritte, ein kundenindividuelles
Modell aus einem Referenzmodell abzuleiten, sind im LIVE KIT
realisiert.
Zwar ist die "GeschaftsprozeBmodellierung" mit einem Refe-
renzmodell in aller Munde, doch aus dieser Sicht mit Anpassun-
gen zu beginnen, ist ahnlich unsinnig, wie in einer den Ablauf
beschreibenden Kochanleitung nach den Zutaten zu suchen.
Besser geeignet ist die Zutatenliste, die immer am Anfang steht,
unser "gutes altes" Funktionsmodell.
In einem Funktionsmodell kann es im Prinzip nur die Adap-
tionsart der Auswahl oder Erganzung geben. Dabei darf aber
kein hierarchisches Prinzip verfolgt werden, da dies immer will-
kurlich ist und nicht durchgehalten werden kann. Besser ist es,
immer benotigte Kernfunktionen von optionalen Funktionen zu
trennen, um schnell Unnotiges ausklammern zu konnen. Auf
diese Weise kann eine Reduktion der Komplexitat in einem Re-
ferenzmodell erreicht und gleichzeitig der anforderungsrelevante
Projekturnfang bestimmt werden. Die Konsistenzsicherung dieser
Funktionsauswahl muB aber unbedingt durch einen Regelme-
chanismus sichergestellt werden.
Anpassungen in einem Datenmodell sind zwar durch Modellie-
rungswerkzeuge leicht durchzufuhren, doch problema tisch ist
dabei die Beschrankung und das Aufzeigen der vordefinierten
und realisierbaren Anpassungsmoglichkeiten einer Softwarebi-
bliothek wie R/3. So muBten - in der ERM-Semantik gesprochen
- abwahlbare Relationen, Entities und veranderbare Kardinalita-
ten besonders hervorgehoben werden. Hierfur fehlt aber noch

77
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

eine entsprechende Semantik, die dies sinnvoll unterstutzt und

insbesondere die Alternativen und Konsequenzen uberschauen
laBt. Deswegen ist in dies em Geflecht von Wechselwirkungen
eine regelbasierte Navigation mit einem Leitfaden unabdingbar.
Checklistenfragen uberprufen die Anforderungen des Kunden,
wie der Arzt bei einer Diagnose das Krankheitsbild des Patienten
Schritt fUr Schritt zu identifizieren sucht. Diese Reduk-
tionscheckliste wird durch die eingearbeitete Wissensbasis auf
relevante Fragestellungen ausgerichtet.
Fur die anpassende Modellierung von Organisationsmodellen
steht eine andere Zielsetzung im Vordergrund. 1m Rahmen von
R13-Projekten wird deutlich, daB hier ein TransferprozeB zwi-
schen betrieblichen Organisationsanforderungen und den Gestal-
tungsalternativen der Softwarebibliothek unterstutzt werden
muB.
Die Zuordnung von Modellbsungen der Softwarebibliothek zu
Anforderungen des Unternehmens ist die einfachste Mbglichkeit
einen Anforderungsabgleich mit R13 durchzufuhren. ]e nach
Sicht mussen dabei unterschiedliche Zuordnungsstrategien an-
gewandt werden. Geschieht die Organisationszuordnung streng
nach betriebswirtschaftlichen Organisationsprinzipien, wird fUr
Stammdaten eine schrittweise Evaluationsstrategie angewandt
und regelbasiert ausgewertet.

Abbildung 18: Zu- • alternative Ausprigungen aufzelgen

ordnungselement • elnlache bls aulWendlge LOsungen anbleten
Verfugbarkeits- • Zerlegung und Strukturlerung komplexer Funktlonen
In elnfache additive oder alternative Proflle
prulung - drei Modell-
16sungen

78
 3.3 VoraussetzungJur die GeschiiJtsprozejSgestaltung im Mittelstand: ...

Fur die Vorgangszuordnung sind typische Losungen dargestellt,

die Alternativen fur ProzeBelemente und -steuerung darstellen.
Neben einer einfachen Auftragsabwicklung wird zusatzlich eine
Losung mit Vorverkaufsbelegen angeboten. Aufgabe der Funkti-
onszuordnung ist eine strukturierte Darstellung bestimmter
Funktionalitaten von einfach bis komplex. So kann bspw. die
Verfugbarkeitspri.ifung im einfachsten Fall vom Lagerbestand
ausgehen und im aufwendigsten Fall auch prognostizierte Zu-
und Abgange einbeziehen Csiehe Abbildung 18). Spatestens hier
wird deutlich, daB der Weg uber das Aufzeigen der Adaptions-
moglichkeiten von der Softwarebibliothek ausgehen muB. Wenn
frei modelliert wird, kann nicht bewertet werden, ob das Ergeb-
nis realisiert werden kann oder nicht. 1m zweiten Fall handelt es
sich urn die Vorbereitung von Erganzungsentwicklungen, die
auch als solche fri.ihzeitig identifiziert werden sollten.

3.3.2 LOckenanalyse
Ein offenenes Problem, das auch im LIVE KIT noch nicht gelost
wurde, ist die Schnittstellen bzw. Li.ickenanalyse. Wo bestehen
Ubergange zu Fremdsystemen, Burowerkzeugen und zur Vor-
gangssteuerungsebene? Wie konnen bestimmte Koexistenzlosun-
gen aussehen?
Dieses Kapitel solI nun darauf ein Ausblick geben.

Abbildung 19: Ziel-

Q rganjsatioo fQcmuIa.La
bereiche der Liicken- S'lammdaten ~

ffi
analyse R/3
Datenfelder
erganzen
Struktur-
Auswahl
,Me, ~

Anpassung
R/3 ~~ o Layout
o lnhalt
GeneralOren

ABAP
Koexistenz BOrower1<.zeuge
Schnittstelle

79
3 ODYSSEUS - Mittelstandsorientierte Methodenentwicklung fur Rl3

Da auch die umfangreichste Softwarebibliothek niemals allum-

fassend sein wird, ist immer eine "Ltickenanalyse" auf Basis des
kundenspezifisch konfigurierten Referenzmodells notwendig.
"Luckenanalyse" zielt dabei auf zwei Aspekte. Die fehlende
funktionale Abdeckung muB festgestellt werden, und die Inte-
gration yom Informationsflussen soli auf Vollstandigkeit und
Schnittstellen hin untersucht werden.
Vollstandige funktionale Abdeckung bedeutet: 1st eine Detail-
funktion in der notwendigen Form vorhanden? Es gibt auch in
der betrieblichen Praxis nicht immer eindeutige Anforderungen.
Wo es solche gibt, ist es wahrscheinlich, daB sie wohl bekannt
und darnit von Anfang an klar sind. Das Benennen solcher An-
forderungen kann besser dem Anwender uberlassen werden,
wenn ihm transparent gemacht wird, was bisher bereits durch
die Softwarebibliothek abgedeckt werden kann. Die Qualitat der
"Auswertungen" aus dem Referenzmodell ist hierfur sehr wichtig.
Fur Nicht-Modellierungs-Experten sollte eine grafisch-textuelle
Erklarung vorliegen, die Funktionen und Prozesse kundenspezi-
fisch darstellt. Auch die unklaren Anforderungen konnen besser
spezifiziert werden, wenn ein Ansatzpunkt erkannt wird. Emp-
fehlenswert ist auch ein "Durchspielen" von konkreten Funktio-
nen und Prozessen in einer Modellfirma mit Beispieldaten.
Zusatzlich ist dabei notwendig, daB der Erganzungsaufwand be-
wertet werden kann. 1st es eine Kleinigkeit, oder sind fundamen-
tale Anderungen notwendig? Handelt es sich um "vorhersehbare"
Varianten, Erweiterungen oder Erganzungen zu bestehenden
Funktionen, kann auch die Werkzeugwahl (z.B. Auswertungsge-
nerator oder Burowerkzeug) unterstutzt werden? MiBverstandnis-
se vermeiden, Transparenz gewinnen und die richtige Werk-
zeugentscheidung sind die ZielgroBen der ersten Form der Luk-
kenanalyse.
Vollstandige Informationsflusse klaren solche Fragen wie: 1st die
vertriebliche ProzeBkette unvollstandig, oder welche organisato-
rischen Alternativen fUr die Ergebnisverantwortung sind noch
moglich? Durch freie ProzeBmodellierung auf Basis eines Refe-
renzmodells konnen solche Fragen nicht gelost werden. Diese
Modelle sind "passiv". Sie antworten dem Anwender nicht.

80
33 Voraussetzungjiir die GeschiijtsprozejSgestaltung im Mittetstand: ...

Es wird hier von "aktiver" gewidmeter Simulation gesprochen,

wei! auf solche Fragen nur dann Antworten gefunden werden
konnen, wenn filr jede Fragestellung ein eigenes Modell vorbe-
reitet worden ist, das "hungrig" auf kundenspezifische Inputda-
ten wartet. Die Inputdaten sind Ergebnisse der ebenfalls vorge-
dachten checklistenbasierten Reduktion und Zuordnung von
Modellosungen, die hierfilr an ein Modellierungs- und Simulati-
onswerkzeug ilbergeben werden, urn dort das kundenspezifisch
gewidmete Modell aufzubauen. In dem nun konfigurierten Mo-
dell kann die Analyse begonnen werden, ahnlich dem Rechnen
in einem Spreadsheet bei einer Was-Ware-Wenn-Analyse. Dabei
konnen aber nur die Werte betrachtet werden, die vorher als Er-
gebniswerte definiert worden sind. Auf diese Weise sind Bewer-
tungen, Konsistenzpriifungen oder Alternativensuchen, moglich.
1m VertriebsprozeBmodell wird nach "leeren Enden" der ProzeB-
kette gesucht, urn notwendige Schnittstellen aufzuzeigen. 1m Or-
ganisationsmodell konnen die Alternativen der Sparten oder der
Matrixorganisation aufgrund vorselektierter Organisationselemen-
te untersucht werden.
Die Einschrankung auf bestimmte Fragestellungen sind hem-
mend, aber unbedingt zu beachten, da sonst keine konkreten
Aussagen erzielt werden konnen. Allgemeine oder abstrakte Mo-
delle verlieren an Aussagegehalt.
In der Antike verstand ein griechischer Held den Sinn des Ora-
kelspruchs von Delphi erst, als er das Abenteuer bestanden hat-
teo
Filr die Lilckenanalyse in der Gegenwart sollte der Erkenntnis-
zeitpunkt etwas friiher liegen. ODYSSEUS steh' uns bei!

81
Literatur

Literatur

[BUSC89) Buschmann, E. et al.: Der Softwaremarkt der Bundes-

republik Deutschland. In: Gesellschaft fur Mathematik
und Datenverarbeitung [Hrsg.): GMD-Studien,
Nr. 167, Sankt Augustin, 1989

[DTI194) Deloitte Touche Tohmatsu International: Worldwide

Survey of SAP Software Usage 1994, Broschtire Lon-
don, 1994

[KRCM92) Krcmar, H.: Leise Tone im Information Management

des Mittelstandes - Ergebnisse einer Urnfrage. In: 1M
7 (992) 4, S. 79-83

[MERT90) Mertens, P.: Zugangssysteme als Weg zur Beherr-

schung komplexer DV-Anwendungen. In: Reuter, A.
[Hrsg.): GI - 20. Jahrestagung - Informatik auf dem
Weg zum Anwender, Berlin, 1990, S. 73-87

[SN192) Siemens Nixdorf Informationssysteme AG [Hrsg.l:

Vertriebsfoliensatz fur R/3-Live, Mtinchen, 1992

82
Das SAP-Rl3-Berechtigungskonzept

Diplom-Informatiker Michael Hofebauer

Fa. RATIO DATA Informationssysteme Wirtschaft

und Verwaltung GmbH, Koln

83
1 Oberblick

1 Oberblick
Grundzuge des Rl3-Berechtigungskonzepts sind die Festlegung
von komplexen Berechtigungen, der hierarchische Aufbau der
Berechtigungselemente und die Verteilung der Administrations-
aufgaben im Hinblick auf eine grbBtmbgliche Systemsicherheit.
Das Kapitel 2 definiert die Grundelemente des Berechtigungs-
konzepts . Kapitel 3 stellt die Versionen von Wertebereichen vor,
die Grundlage fur die Aufgabenverteilung bei der Vergabe von
Berechtigungen sind. SchlieBlich beschreibt Kapitel 4 die Einfuh-
rung des Rl3-Berechtigungskonzepts vor dem Hintergrund der
betrieblichen Organisationsstruktur.

2 Grundelemente des Berechtigungskonzepts

Felder und Objekte bestimmen die strukturelle Ausgangsbasis fur
die sp~itere Definition von Wertebereichen.
2.1 Berechtigungs-Feld
Ein Berechtigungsfeld ist ein Datenfeld, fUr das ein Berechti-
gungsschutz vor unerlaubten Zugriffen definiert werden kann.
Berechtigungsfelder sind durch - im Data Dictionary gespeicherte
- Datenelemente, z.B. Buchungskreis, Auftragsart oder Aktivitii-
ten, beschrieben und bezeichnen Systemelemente, z.B. Hinzufu-
gen, Andern, Anzeigen. Abb. 2.1 zeigt einen Ausschnitt der Ta-
belle TACT, welche die im System zu schutzenden AktivWiten
enthalt:
1 ,11,, 11 . ' '' ...... '' jllI I l'd I C
Abb. 2.1
Akuvmu BcdlCuwng

jllnd ... " I

jAnulgen I
O,-ucken. twchrlchten be-ilrOelt.
Spel"'ren. [nt:5p.~r.n

I.. tisch." __.. _ .. _.. _._.__ J

IAktl""l~,..n. Gener1e .. e" 1
1"~z.i-.9~n .nd.'.:'~n!ilSb~.l~. ]
rrelsanzet91!'
euen.n
1
j... tc ..... ts St.and ~nd.rn (
IPle-g .. lind Cen . Anderungsbil'l.egej
IHu.-ernst¥nde Ini.~_l"l.J:lil.r.n=t
I-::!.~~ •.~S"hl: C.n .. r-~~!.".!.!1 _~!.I'npro
Fi!'1.dau s ~hl: ZlIordnung label1e
IAU·SFu.~nn_ _ _ UMM"""""'M.=:::J

84
 23 Berecbtigung

Berechtigungsfelder sind in der Tabelle AUTI-I gespeichert. Diese

kann tiber das Data Dictionary Infosystem eingesehen bzw. tiber
die Mentipunkte "Werkzeuge, Case, Entwicklung, Berecbtigungs-
objekte, Feldpflege" aufgelistet werden. Ein Berechtigungsfeld bil-
det die kleinste Einheit im SAP-R/3-Berechtigungskonzept.

2.2 Berechtigungs-Objekt
Berechtigungsobjekt heiBt eine Zusamrnenfassung von max. 10
Berechtigungsfeldern. Ziel einer derartigen Kombination von
Feldern ist die Festlegung von Abhangigkeiten der Berechti-
gungsfelder untereinander. Ein Berechtigungsfeld kann in ver-
schiedenen Berechtigungsobjekten enthalten sein. Objekte eines
Arbeitsgebiets oder einer Anwendung sind einer sog. Berechti-
gungs-Objektklasse zugeordnet.
Berechtigungsobjekte werden in der Tabelle TOB], die zugeord-
neten Kurztexte in der Tabelle TOB]T abgelegt. Analog dazu
enthalten die Tabellen TOBC bzw. TOBCT die Objektklassen
bzw. die zugehbrigen Kurztexte. Ein Berechtigungsobjekt wird
seiner Objektklasse tiber die Tabelle TOB]C zugeordnet. Die fUr
ein Berechtigungsobjekt gtiltigen Aktivitaten sind in der Tabelle
TACTZ hinterlegt. Die im SAP-Standard enthaltenen Objektklas-
sen sowie die zugehbrigen Objekte sind tiber "Werkzeuge, Case,
Entwicklung, Berecbtigungsobjekte, Objektpflege" anzeigbar.
Berechtigungsfelder und -objekte sind nur vom Anwendungs-
entwickler tiber die o.g. Mentiverzweigungen zu erstellen und zu
pflegen. Berechtigungsobjekte sind die strukturelle Ausgangsba-
sis fUr die Definition von Berechtigungen.

2.3 Berechtigung
Eine Zuordnung von Werten zu den Feldern eines Berechti-
gungsobjekts heiBt Berechtigung. Sornit stellt eine Berechtigung
zu einem Berechtigungsobjekt eine Kombination von mbglichen
Wertebereichen der zugehbrigen Felder dar. Eine Berechti-
gungsprufung seitens des Systems beinhaltet die Prufung eines
jeden Wertebereichs und verkntipft diese Ergebnisse in einer
UND-Verkntipfung zum Endergebnis. Eine Berechtigung bezieht
sich imrner auf genau ein Berechtigungsobjekt. Nattirlich ist es
mbglich, mehrere Berechtigungen - Wertebereichsauspragungen
- zu einem Berechtigungsobjekt zu definieren. Berechtigungen
legen die Zugriffsmbglichkeiten auf die in den Berechtigungsob-
jekten aufgefUhrten Felder fest.

85
2 Grundelemente des Berecbtigungskonzepts

Organisatorisch beschreibt die Definition einer Berechtigung zu

einem Berechtigungsobjekt die Festlegung einer T:itigkeit bzgl.
der Datenfelder, die das Objekt velWaltet. Diese wird im folgen-
den objektbezogene T:itigkeit genannt.

2.4 Einrichtung von Berechtigungen

Dber die Menupunkte " Werkzeuge, Administration, Benutzerpjle-
ge, Berechtigungen" wird eine Liste zur Auswahl einer Objekt-
klasse aufbereitet.

Abb. 2.4.1 IC----------,-,-

t. r~I-,~_;;~·~,lt. ~I.;I:;. ::-:-I.- ..- - - - - - - - - - ICIC
Bc.lc~h"gung .B:carbcltcn .s.p .. lngcn Into Hutamlnel B.G.nutz:Cf'p UCgC S)lstcm un't:

mam'Q~"im'meN""""""""""""""""".~
K~ln@t"' KI~s s ~ zuge-ordnet:
U.r~lt: .te O.rpcht~gung ~ obJekte
An ~ ... g e nwl r t""e h " f= t
AnwendungsUbergrei Fende Berech tlgung s objekte
Oasis - Ad ...in:1st:,.~t:lon
Oasis - Ent..1cklungsu~ebung
8ranchllPnlU s ungttn
er-anchenUS s ungen - Kr.nkenha" s
O,..anchenlH s ungen - UI!'t"trteb U ..... lage
8UrokoftllKlni.kat i on
Controlling
DokuAentenuerwaltung
Flnanz wesen
[n s tandh .. l tung
Klassensyste"
Lageruerwalt:ung
LogiSt:lk Contro11 1 ng
Hate ... 1.al",l r tsc h aFt
Hateri.alwirt:sr:haFt: - De- s t:and sF Uhlt"ung und InulII:nt:u"
"at:.elt"ialwirtschaft: - Be-ower-tung und KontenFindung
"ate ... ialwirt:s~h~Ft: - Ei.nkauf

Nach Selektion einer Objektklasse (hier: Finanzwesen) zeigt der

in Abb. 2.4.2 dargestellte Bildschirm die in dieser Klasse enthal-
tenen Objekte.

Abb. 2.4.2 Belechtlgung D,e.rbclten ,S,prlngen In'o HIII.mlttel B~nutze,-p ' lege Sll.tem tillle

Ullii§P¥
ftut:o...at:.i sc he Zahl.ung : ftkt:ion Sbe ... echtigung FUIt" Buehung s kr else
ftuto~t1 S: Ch. Z"h~ung : Akt1on S b" ... ec.htlgung fU ... Konto ..... ten
Oank~n: lIe .... chtigung FU .. ouchungsk .... is.
O"nkil!'n: Ceneo .... lle PFleQebere,.;htigung
a11 ... n :z! Cenerelle PFl e gcbereclht1g ung
lIuchha~ t:ungsb~~~g : B.r-~chtigung FUr B~1ega .. t:~n
Duchha~ t:ung s be-l.e-g: B~r-~Cht:igung FU ... 8UC: h ung S k .. .,.i se
Du,.;hhal tung$bll:'lrg; 8t!'l""ec.ht:lgung FU ... Cesch:;jlft:sbereiche
Buehh a~t: ungsb~1eg : BerC'C:ht 1 9tJn9 FUr tconto art.n
Ouchha1 tung s b~leg : Kont.nbelt"eCht:igung FUr- Oebit:or-en
191,,1c: •. h ;;.ltuttgS b lll'lvg: Konte nberll!'c.htigung fUr .creditoren
Buehh a ~t:ung s bel.eg: KGntC'nb4'''ec ht1gung FUr S .. chkont.n
8uchhaltungsb~leg: Uor sc h1ag s Ne r- t . Be1eg ..... t:/B s eh~ :;jI nde ... n
DlI!'bit:ot": ftnwt:'ndung $ b ~ t" ee ht19I,1n9
Debitor: DlI!'rechtigung FU ... Buchungsk .... i,..
D. b1to .. : ....... clhtigung FUr Kontoanaly s e
Debit:.ot" : Kont:.enbe ... echl;1.gung
Debitor : Anderung s berechtigung FUr Konte n9 ... "pp~n
Debitor : Anderungsb ere chtigung fUr b esti .... te F e1der

86
 2.4 Einrichtung von Berechtigungen

Nach der Auswahl eines Objekts zeigt Abb. 2.4.3 aIle im System
bereits vorhandenen Standard-Berechtigungen bzgl. des selek-
tierten Objekts.

Abb. 2.4.3
Bc(cchtJgung flcarbclten ~prlngen Into Hureml"c' BJLnutzct'pUegc S.)Clltr:m .I:I'Ue

tUr Uuchungsk ... ~15~

WWiii4iZUDZl mmo D'HIO~'II""""""""""""""""""""""""1II

ALL X Al1~ O.,-eocht1.g u ngen BUChh.~tunSl
AIQ • Anze1geb .... echtigung BuChh~ltung
F _ DEB I TOREN X Berecht1.gungen e 1 n. , Deblt:or.nbuc.hhal ter5
F _KREotTOftEH X Br .. echt1.gungrn pine s Kred l to r enbuchhalters
F _ ICREOITOREH Oe .. echt::lgungen .:1nes Kredl torenbuc h halte ... s
F $ ACHKOHTEH X Be-rechtigung en ei.nes Sachkontenbuchhalters
U: FAKTUAA X SD Fakturierung
U _ NOHTAKT X $ 0 Montakte
U UERKAUF X SO Uer-koiouf
U= UERSAHO X So Uet"' s and

Ober 'Berechtigung anlegen ' wird das Bild in Abb. 2.4.4 erreicht:
Abb.2.4.4 Anlcqen neue []ere(hhgung

Ne ue Berechtigung anlegen
IBerechtlgung IIF.;.!lE.B~ : HEll !

[Welter .I IAbbrechen J
Die erstellte Berechtigung in Abb. 2.4.5 erlaubt die Aktivitaten 02
(Andem), 03 (Anzeigen), 10 (Buchen) bzgl. des Objekts Debitor
im Buchungskreis 01.
Abb.2.4.5
-
eetecbtlgung D,earbelten :i,prlngen

F:inan::t...,. s ~n
ln'o t1l1feml"el OJ:,nut-a:c r p t legc S¥.tem Hllt e

Debit:ot"' : Be ... eCht:igung F Ur Buchung s k."e'i s e