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

F :D € flJ :H( Y untl!!'l~nl!!' h "'l! n s s rez J. fi. s Ch'" Be ... . Fu e ... Oebi.t:o ...... nbuchh
I 00 . D• • • • • • • • : .. 8 : 80 ungc s 1Che ...

11'1.1
Uf't I f '

iAkt:iuit::it
02 - 83 • .,.
BUC:hungskt" ... is
01

87
2 Grnndelemente des Berechtigungskonzepts

Abb. 2.4.5 verdeutlicht die Beziehung zwischen der Struktur Be-

rechtigungsobjekt mit den zugehbrigen Berechtigungsfeldern
und der fur diese Struktur definierten Wertebereichsauspragung,
die Berechtigung. Berechtigungen lassen sich nicht direkt einem
Benutzer zuweisen; dies geschieht tiber die Berechtigungsprofile.

2.5 Berechtigungsprofil
Ein Berechtigungs-Einzelprofil ist eine Liste von Berechtigungs-
objekten, wobei jedem Objekt mindestens eine Berechtigung zu-
geordnet ist. Existieren mehrere Berechtigungen zu einem Ob-
jekt, dann werden diese vom System in einer ODER-
Verknupfung gepriift. Eine Berechtigung bzgl. eines Objekts
kann in verschiedenen Berechtigungs-Einzelprofilen enthalten
sein.
Eine Zusammenfassung von Berechtigungs-Einzelprofilen heiBt
Berechtigungs-Sammelprofil. Sammelprofile kbnnen ihrerseits
wiederum geschachtelt werden, d .h . diese enthalten Einzelpro-
file und/ oder Sammelprofile. Unterschiedliche Sammelprofile
kbnnen dasselbe Einzel- bzw. Sammelprofil beinhalten. 1m fol-
genden wird nicht mehr zwischen den Begriffen Einzelprofil und
Sammelprofil unterschieden. Diese werden in der Bezeichnung
Berechtigungsprofil zusammengefaBt.
Die organisatorische Bedeutung eines Berechtigungsprofils ist
die Abbildung einer Tatigkeitsbeschreibung als Summe der im
profil enthaltenen objektbezogenen Tatigkeiten.

2.6 Einrichtung von Berechtigungsprofilen

Abb. 2.6.1 zeigt die Einstiegsmaske fur die Erstellung eines Pro-
fils. Hier wird der Profilname und der Typ des profils eingetra-
gen.
Abb. 2.6.1

Ne ues Profil anleg. n

IWeiler ,IIAbbrechcn, l

88
 2 .8 Benutzerstamm

SchlieBlich sind die Objekte und die zugehorigen Berechtigun-

gen auf dem Bild in Abb. 2.6.2 einzutragen.
Abb. 2.6.2 ...
erotll Jlcarbchcn ~prlngen Info
1'",1010 1,Ihllili
Ultfem.ttel B.c.nutzcrpnegl: S~tem Hille
n
IPr olil
Text
Anderung

· Bc .. tc h cnd au . den Bcrcchtlgungen .- - - - - . - ---------------------..-...-..~.~,.,~~ ............~ ___..__ .__ .__ _

a~:·:·!.·::~·; ·~:;~·;!:·~. :·~ ';~~:~~~·;~:~~~u.n;~k·r· ~i'~'~ ""'-'-""""--""'-"""""" · ····'·'·'·'·'·,·,·;I~.

1 m
fI
.....
:. ~-:·~-i.~.~.~~;'
...

1...... ..,........,.................................... 0000 ........................................ J I.... ..__.. __ ...j

I, . . ... 00 ;1 .00.00 __ ';
L
I ::: . . ::·.·. . :::::. ~~.·:. :.:~~. :. ·.. . .. . ".:.:.:.. :::::...,. .':.:' .:.:.:. .: . JjlI·:. .. ........ 0000'
. m.m . m .m . . . . .m __

I.. . . m.m.J L ... m.m.m.m ...... "._~ ~!

I ............................ 00 ...00.0000 ...... ____ ....... 00.00,;1
I "

2.7 SAP-Namenskonvention
Der SAP-Standard bietet eine groBe Anzahl von Objekten, Be-
rechtigungen und Profilen. Diese sind nach folgender Namens-
konvention strukturiert: Stelle 1 identifiziert das SAP-Arbeits-
gebiet, z.E. A: Anlagenbuchhaltung, F:Finanzwesen, K: Kosten-
rechnung, usw .. Auf den Positionen 3-6 wird das Berechtigungs-
objekt oder der Arbeitsbereich codiert. Der Unterstrich wird als
Trennzeichen auf den Stellen 2 und 7 verwendet. Die Positionen
8-10 dienen zur weiteren freien Beschreibung des zugrundelie-
genden Berechtigungselements. Da Systemaktualisierungen bzw.
Releasewechsel Anderungen von Standardprofilen und - berech-
tigungen zur Folge haben konnen, sind die fur eine Verwendung
bestimmten Berechtigungselemente unter anderen Namen zu
kopieren.

2.8 Benutzerstamm
Die Speicherung der benutzerspezifischen Stammdaten erfolgt in
sog. Benutzerstammen. Benutzerspezifische Daten sind der Be-
nutzertyp (Dialog, BDC, Batch, CPIC), Passwort, Festwerte
(Startmenti, Datumsformate, Dezirnaiformate, Spoolsteuerung),
anwendungsspezifische Festwerte, Parameter (Buchungskreis,
Belegart etc.) sowie die Benutzergruppe.

89
3 Versionenkonzept und Administration

Die Zugriffsmoglichkeiten eines Benutzers im System sind durch

die Liste der Berechtigungsprofile in seinem Benutzerstamm be-
stimmt. Ein Berechtigungsprofil kann verschiedenen Benutzer-
stammen zugeordnet werden.
Organisatorisch beschreibt ein Benutzerstamm den Arbeitsplatz
seines Benutzers als Summe der im Stamm enthaltenen auszu-
fuhrenden Tatigkeiten. SAP interpretiert ein Berechtigungsprofil
als Arbeitsplatzbeschreibung im Gegensatz zu dem hier verwen-
deten Begriff Tatigkeit. Daraus folgt jedoch, daB ein Benutzer
mehrere Arbeitsplatze besitzen kann. Abb. 2.8.1 zeigt die Erfas-
sungsmaske fur die Berechtigungsprofile des Benutzers Muster.

Abb.2.8.1
OCQut:ze r Dearbelttn ~rlngcn Into HIIt_mlnel B.c.nutzerpUege S:!Iletem Hille

Bcn utzcr I~.~.I!;~._ .. .. ,.. ,.. ..1

Anderung I .... JI 1.....-. .m .....J I.~_~ .; .~~.; _~~~ ,unge-s.1.:; ,
1- Gru nd daten ------.•.•.•.- ..•.•.•...•.-----......... - .....---..- ...----------... !" BenutOl:e rtyp - .. ---------..- -....--.-.-.. ..

I ~~~:I.::~;:::. r:==::; , t ..._...._........,) ! ~ ~~~Og

! GUI11g von I ..... ; i 0 Batch
! I.. !
. __ ___. . . . . ._. ___. . . . . ._________. . L____. _______________. _____________. .__. _._. __
GDIUg bill 0 CptC

~~.~.~.~~~.~_~~_~~~n:.=:~.,., ~
I_ ...
r' Berec:l\l lgungaproU l e ............... ,.... ,.,.,., ........--.-.-.--..... ---.. -----.......-------...........-~----........- ............~~..~~..-..,-,-,-.-~,-.-.-.-..

I P rom SPro t r;---l l

! 1!':..;.~.~.~.~.r..~ .~~I:t, j r::J ~n.~~r..~.,.~.~~.~.~.~p.!:~~.~J.~.!;.~.~.~....~!.':~.~.... f.':I,~.r. ,..~~~~tor'nbu ~ hh.a .~ .~ ~.r._._.
! IF AHu;aCIE:H i r-l FJ-B.e .r:-.C:ht'1g~.r~9.• .n ....t:~.r: . ~~nlPn II~Cl:'h~lt.r ;auf Anlagen

i
[ IF_ SACHMD HTEH]
: mmmm~:
r-l
R .................................
FJ-Berecht:1gungen FUr e 1 ne-n Sachkontenbuchhaltet"'

Ii I : R i-..-...-.....~......~...~....=. ~~~=.....~.....~.....~.....~..... ~~~~~

.. J ·11 =............ .....-....-... -...-....-... -.. -.....U\I

Berechtigungen, Profile und Benutzerstamme sind mandanten-

bezogen.

3 Versionenkonzept und Administration

Kapitel 3 betrachtet das Versionenkonzept von Berechtigungen

und Profilen. Dieses ist eine Voraussetzung fur die spatere Auf-
teilung von Administrationsaufgaben im Rahmen der Berechti-
gungsvergabe.

90
 3.2 Administration

3.1 Versionenkonzept
Berechtigungen und Profile werden in einer sog. Pflegeversion
erstellt bzw. geandert. Priifungen des Systems erfolgen nicht ge-
gen die Pflegeversion. Daher sind pflegearbeiten yom laufenden
produktiven Systembetrieb entkoppelt und beeintrachtigen die-
sen nicht. Durch den Vorgang der Aktivierung einer Pflegeversi-
on wird diese auf die Aktivversion kopiert und die Pflegeversion
gelbscht. Das System priift ausschlieBlich gegen die Aktivversion
einer Berechtigung oder eines Profils.
Aufgrund der Tatsache, daB verschiedene Benutzerstamme die-
selben Profile sowie unterschiedliche Profile diesel ben Berechti-
gungen enthalten kbnnen, sind bei Anderungen an Berechtigun-
gen und Profilen Priifungen bzgl. der A.nderungsabsicht von be-
troffenen Benutzerstammen nbtig.

3.2 Administration
Zusammen mit der Pflege von Benutzerstammen folgt aus dem
Versionenkonzept u.a. die Aufgabendreiteilung:
1. Erstellung und Anderung von Berechtigungs- und profil-
pflegeversionen
2. Aktivierung der Pflegeversionen
3. Eintragen von aktiven Berechtigungsprofilen in Benutzer-
stamme
Urn eine maximale Systemsicherheit zu garantieren, mtissen die
o.g. Verantwortungsbereiche von drei Personen, dem Berechti-
gungs-, Aktivierungs- und Benutzeradministrator verwaltet wer-
den. Tabelle 3.2.1 zeigt diejenigen Berechtigungsobjekte fur die
Administration von Berechtigungen, Profilen und Benutzer-
stammen:

Tabelle 3.2.1
OBJEKTE

FEIDER S USER AUT S USER PRO S USER GRP

Objektname OBJECf

Berechtigungsname AUm

Profilname PROFILE

Benutzergruppe CLASS

Aktivitat ACIVf ACIVf ACIVf

91
3 Versionenkonzept und Administration

Das Berechtigungsobjekt S_USER_AUI erlaubt Einschrankungen

der zu bearbeitenden Berechtigungen bzgl. der Berechtigungs-
namen, Objekte und Aktivitaten. Die Pflege von Profilen kann
tiber S_USER_PRO bzgl. der Profilnamen und Aktivitaten einge-
schrankt werden. S_USER_GRP ermoglicht Einschrankungen
der Benutzerpflege auf bestimmte Benutzergruppen und Aktivita-
ten. Benutzer, die keiner Benutzergruppe zugeordnet sind, kon-
nen von jedem Benutzeradrninistrator gepflegt werden.
Tabelle 3.2.2 vergleicht die Aktivitaten der Adrninistratoren bzgl.
der obigen Berechtigungsobjekte:

Tabelle 3.2.2
OBJEKTE Berechtig.- Aktivierungs- Benutzer-
Administrator Administrator Administrator
S_USER_AUT zuHissige zulassige
OBJECf Ber.-Objekte, Ber. -Objekte,
AUTH Ber.-Namen, Ber.-Namen,
ACTVT Aktivitaten: Aktivitaten:
Anlegen
Andern
Anzeigen Anzeigen
Loschen Loschen
Aktivieren
And.-Belege And.-Belege
Eintr. in profil
S_USER]RO zulassige zulassige zulassige
PROFILE Profilnamen, Profilnamen, Profilnamen,
ACTVT Aktivitaten: Aktivitaten: Aktivitaten:
Anlegen
Andern
Anzeigen Anzeigen
Loschen Loschen
Aktivieren
And.-Belege And.-Belege
Eintr. in Benut-
zerstamm
S_USER_GRP zulassige
CLASS Benutzergrp.
ACTVT Anlegen
Andern
Anzeigen
Loschen

92
 3.3 Systemhilfen

Ein Berechtigungsadministrator bearbeitet ausschlieBlich Ptlege-

versionen von Berechtigungen und Profilen. Er kann diese we-
der aktivieren noch Aktivversionen lbschen. Fur Anderungen an
Berechtigungen und Profilen ist der Aktivierungs- und Benutzer-
verwalter nicht berechtigt. Fur die Gewahrleistung der System-
sicherheit sind die folgenden Punkte zu beachten:
• Fur Berechtigungs- und Aktivierungsadministratoren ist die
Bearbeitung von Berechtigungen bzgl. der Objekte S _USER_
AUT, S_USER_PRO, S_USER_GRP sowie der Berechtigungs-
und Profilnamen S_USER* auszuschlieBen.
• Die Administratoren mussen der Benutzergruppe SUPER zu-
geordnet werden.
• Der Benutzeradministrator darf keine Benutzer der Gruppe
SUPER ptlegen und keine Profile mit Namen S_USER* zu-
ordnen.
• Berechtigungen fUr die Verweigerung des Systemzutritts eines
Benutzers CSperren), die Anderung von Kennwortern und die
Anzeige von Anderungsbelegen zu Benutzerstammsatzen
sollten dem Superuser Cvgl. Kap. 3.4) vorbehalten sein.

3.3 Systemhilfen
Das System bietet mit dem Informationssystem, der Historien-
verwaltung und dem Berechtigungstrace eine effektive Untersrut-
zung bei der Bearbeitung der im Rahmen der Berechtigungsver-
gabe anfallenden Aufgaben.
Das Informationssystem liefert Auswertungsmoglichkeiten bzgl.
der Objekte, Berechtigungen, Profile und Benutzer. Weiterhin
sind die im Standard enthaltenen Berechtigungselemente aus-
fUhrlich dokumentiert. Die Historienverwaltung ermoglicht die
Anzeige und Archivierung von Anderungsbelegen bzgl. Berech-
tigungen, Profilen und Benutzerstammen. Abb. 3.3.1 zeigt die
Anderungen bzgl. der Profilliste des Benutzers Muster.
Der Berechtigungstrace erstellt eine Aufzeichnung samtlicher Be-
rechtigungsobjekte eines Dialogvorgangs, fur die das System Be-
rechtigungsprufungen durchfUhrt. Die Transaktion SU53 ermittelt
das einer Berechtigungsprufung aktuell zugrundeliegende Ob-
jekt, fUr das ein Fehler aufgrund einer nicht vorhandenen Be-

93
3 Versionenkonzept una Aaministration

rechtigung aufgetreten ist. Voraussetzung hierfur ist der Trans-

aktionsaufruf in der Benutzersitzung, in welcher der Fehler auf-
getreten ist. Desweiteren ist der Wert des Systemprofilparameters
"auth!check_value_write_on " auf einen Wert groBer Null zu
pflegen.

Abb.3.3.1 ~ A.llt. '0111'1 I" I," ,. III .. "I ",,· , s:lfC

Historienverwaltung HUSTER

!bfi
HOFEBAUER 11 ••3.1995 1.:.1:2 •
••• B~nut~~~ angelegt ._.
_ -_ Hlnzuglll!'fUgte E1ntt"~ge •••
F:OEBITOREH F_ AHLAGE H F_SACHMOHTEH
HOFEOAlUER 11 • •3.199$ 1.:21: ... 1
••-. G~l.Hschtll! E1 n t ... ~gr - --
F SACHKOHTEH
.;-. Hlnzug.fUgte E1n t t"~ge •••
F _SAKO_AHZ

3.4 SAP* und Superuser

Die Verantwortungsbereiche der im Rahmen des Berechtigungs-
konzepts genannten Administratoren sind dem des Systemver-
walters oder Superusers untergeordnet.
SAP* ist ein im System fest installierter Benutzer ohne Benut-
zerstamm mit dem Kennwort PASS. Solange fur dies en Benutzer
kein Stammsatz definiert ist, fuhrt das System keine Priifungen
der Zugriffe auf vorhandene Berechtigungen durch. Folglich
besitzt SAP* aile Berechtigungen. SAP empfiehlt die Definition
eines Benutzerstamms fur SAP* mit leerer Profilliste und der Be-
nutzergruppe SUPER. Der Benutzer SAP* unterliegt somit einer
Kennwortpriifung und besitzt keine Berechtigungen. Die Zuord-
nung von SAP* zur Benutzergruppe SUPER verhindert, daB die-
ser leichtfertig geloscht werden kann.
Ein mit allen Berechtigungen ausgestatteter zentraler Systemver-
w alter ersetzt den Benutzer SAP*. SAP rat zur Verwendung der
Standardprofile S _USER_ALL, SAP _ALL und SAP _NEW bei der
Einrichtung eines derartigen Superusers.

94
 4.1 Konzepteinjuhnmg im Basisbereich

Das Profil S_USER_ALL beinhaltet uneingeschrankte Berechti-

gungen fur Aktivitaten bzgl. der Bearbeitung von Benutzem,
Profilen und Berechtigungen.
SAP_ALL enthalt aIle Berechtigungen fur die im System vorhan-
denen Berechtigungsobjekte ausgenommen der Berechtigungen
fur
• die pflege von Benutzem der Gruppe SUPER,
• die Bearbeitung von Berechtigungen bzgl. der S_USER-
Objekte sowie
• die Pflege von S_USER-Profilen.
SAP_NEW stellt aIle Berechtigungen fur bisher ungeschutzte
Objekte zur Verfiigung, fur die nach einer System-Aktualisierung
bzw. einem Releasewechsel Berechtigungsprlifungen existieren.
Damit SAP_ALL-Berechtigte von der Pflege ihres eigenen Benut-
zerstamms ausgeschlossen sind, mussen diese der Benutzergrup-
pe SUPER zugeordnet werden.

4 Einfuhrung des Rl3-Berechtigungskonzepts

Aus der Interpretation, daB ein profil eine Tatigkeit sowie ein
Benutzerstamm einen Arbeitsplatz beschreibt, folgt die Einfuh-
rung des Berechtigungskonzepts vor dem Hintergrund der be-
trieblichen Organisationsstruktur. Diese kann in die Bereiche
System und Fachabteilung aufgeteilt werden.

4.1 Konzepteinfiihrung im Basisbereich

SAP bietet flinf StandardproIDe an, die charakteristische Basis-
Tatigkeiten beschreiben:
1. S_ASYSTEM wird fur die zentrale Systemverwaltung be-
nutzt und entspricht allen Basisberechtigungen inkl. des in
Kapitel 0 beschriebenen Profils S_USER_ALL.
2. S_AADMIN besitzt aIle Berechtigungen der SAP-Basis aus-
genommen der Berechtigungen fur die Entwicklungsumge-
bung, der pflege von Benutzem mit Benutzergruppe SUPER
und der Bearbeitung von S_A"-Profilen.

95
4 Einfuhrung des Rl3-Berechtigungskonzepts

3. S_A.CUSTOMIZ enthalt die Berechtigungen fUr Customi-

zing-Funktionen im Basisbereich.
4. S_A.DEVELOP beinhaltet die Berechtigungen fUr die SAP-
Entwicklungsumgebung.
5. S_A.USER besitzt stark eingeschrankte Basisberechtigungen
fUr den SAP-Endbenutzer. Dazu gehoren u.a. das Abspielen
und Analysieren von Batch-Input-Mappen, die Tabellenan-
zeige mit SM31, die Anzeige und Einplanung von Auftragen
fUr die Hintergrundverarbeitung, die Anzeige des Feiertags-
und Fabrikkalenders, die AusfUhrung von ABAP-
Programmen, die Listausgabe auf Druckerdestinationen,
SAP-Mail sowie die Anzeige von Vorgangstypen im
Workflow.
Die folgenden Tatigkeiten ermoglichen Anderungen bzw. Mani-
pulationen an der konsistenten Arbeitsweise des SAP-Systems
und dtirfen daher nicht als Berechtigungen in einem Produktiv-
system vergeben werden.
Diese Tatigkeiten sind:
• das Editieren von ABAP/ 4-Programmen,
• das Ersetzen von Werten beim ABAP/4-Debugging,
• Screen-Painter-Aktivitaten,
• die Pflege von Data-Dictionary-Objekten,
• die Pflege der Tabelle TSTC.
Dber die Mentipunkte "Werkzeuge, Administration, Benutzer-
pflege, Berechtigung" laBt sich eine Liste der im System verfUgba-
ren Basis-Berechtigungsobjekte erstellen. Nach der Selektion ei-
nes Berechtigungsobjekts kann tiber die Punkte "Hilfsmittel, Do-
kumentation" die Objektdokumentation angezeigt werden. Da-
her wird an dieser Stelle auf eine erschopfende Beschreibung
der vorhandenen Basis-Berechtigungsobjekte verzichtet. Zuge-
horige Standardberechtigungen und Profile, die Berechtigungen
bzgl. des betreffenden Basisobjekts enthalten, sind tiber das In-
fosystem oder die Namenskonvention ermittelbar.

96
 4.2 Konzepteinjuhnmg im Anwendungsbereich

4.2 Konzepteinfuhrung im Anwendungsbereich

Wahrend Basisberechtigungen fur die SystemveIWaltung nur ei-
nen kleinen Benutzerkreis betreffen und die in Frage kommen-
den Basisberechtigungen fur den Endbenutzer in einer Fachab-
teilung sehr eingeschrankt sind, stehen dieser Tatsache komple-
xere Beziehungen zwischen den Objekten des Anwendungsbe-
reichs und den Mitarbeitern der Fachabteilungen gegenuber.
1. Zunachst muB die Unternehmensorganisation hinsichtlich
der in den Fachabteilungen veIWendeten zu schutzenden
betrieblichen Objekten, z.B. Debitoren, Kostenstellen, Ma-
terialklassen, und der auf den Objekten ausgeubten Tatig-
keiten analysiert werden.
2. Den betrieblichen Objekten sind Standardberechtigungsob-
jekte zuzuordnen. Hilfreich ist hier die von SAP vorgenom-
mene Einteilung der Objekte in Klassen hinsichtlich der
Anwendung bzw. des Arbeitsgebiets sowie die zugehbrige
Objektdokumentation. Desweiteren mussen die betriebli-
chen objektbezogenen Tatigkeiten auf die fur ein Berechti-
gungsobjekt definierten Aktivitaten gemaB Tabelle TACTZ
abgebildet werden.
3. Dber das Infosystem bzw. die Namenskonvention kann eine
Auswahl von zugehbrigen Standardprofilen mit den unter
Punkt 2 erarbeiteten anwendungsspezifischen Berechti-
gungsobjekten getroffen werden. GemaB Kapitel 2.7 sind
diese Berechtigungsprofile zu kopieren und hinsichtlich der
unternehmensspezifischen Bedingungen anzupassen.
4. Kundenspezifische Berechtigungsobjekte mussen fur dieje-
nigen betrieblichen Objekte definiert werden, fur die keine
Berechtigungsobjekte im Standard existieren. Dies geschieht
uber "Werkzeuge, Case, Entwicklung, Berechtigungsobjekte".
Die Priifungen mussen im Programm mit dem ABAP/ 4-
Befehl AU7HORI1Y-CHECK OBJECT codiert werden.
5. Den Arbeitsplatzen der Benutzer entsprechend, sind die
entwickelten unternehmensspezifischen Profile in die Be-
nutzerstamme einzupflegen.
6. Die Einfuhrung des R/3-Berechtigungskonzepts ist mit ei-
nem Test unter produktiven Bedingungen abzuschlieBen.

97
4 Einfuhrung des Rl3-Berechtigungskonzepts

4.3 Einfuhrungsleitfaden • Bereich Finanzwesen

Der Einftihrungsleitfaden bietet bei der Einftihrung von SAP-R/3
eine wertvolle Untersttitzung. Dieses Kapitel zeigt am Beispiel
des Bereichs Finanzwesen, welche Hilfen der Leitfaden bei der
Berechtigungskonzept-Einfuhrung zur Verfugung stellt.
Ober die Mentipunkte " Werkzeuge, Customizing, Einfuhrungsleit-
faden, Gesamtversion" kann der Bereich Finanzwesen selektiert
werden.

Abb. 4.3.1
1"HIHhi'iWWCiiiMti'A'_HM""iiOM"i"

FinanzweslI!'n

Cont"O~11ng

Tre.illl5ury

Zentra1e Funk~~onen

P"oduktlon!iiuor b ~rel t: u ng

Produ k tlonsan lauf

Ober die Selektion "Finanzwesen, Buchhaltung " hiBt sich die in

Abb. 4.3.2 dargestellte Struktur auflisten. Zu jedem Feld
'Benutzerpjlege', 'Berechtigungen pjlegen', 'Profile pjlegen ' bietet
das System eine weiterftihrende Dokumentation an. Dies zeigt
Abb. 4.3.3 nach der Feld-Selektion 'Berechtigungen pjlegen '.
Desweiteren ermbglicht die Auswahl der Funktionen auf dem in
Abb. 4.3.2 dargestellten Bildschirmbild die Verzweigung in die
zugehbrige Pflegetransaktion. Diese wurden in den Kapiteln 2.4
und 2.6 beschrieben.

98
 4.3 Einfuhrungsleitfaden - Bereich Finanzwesen

Abb. 4.3.2 S truldut Bear-balten

',to,,"t"''''''''I''''''' '''' ''''''' ' ' ' '
SJl"lngen SJch. HIH_mlttel Sxe tern tlllfe
a
09u .:: ...... :.1I:uog

>P,.ojt!'kt:u~F~ng IIIUChh.1t:ung

oU_F ilttldl

>8uchungskre:1.s

ar a n c hen deF t n! ..... n • •:11.",.,011":11

.....
ottltarb.lte ....

!iih;.\n3iii!i
s~c hbe .... bP i t:e ... ku ..
oO.nut:z .... p ' l .g.,

Die Dokumentation zum Feld 'Berechtigungen pflegen ' (Abb.

4.3.3) enthalt u.a. eine Liste der Berechtigungsobjekte, die bei
den Funktionen der Anwendungen gepriift werden.

Abb. 4.3.3 f.VI' •• to,..t ."... ....... a

E::l n .. UiiiDiliiiiW4h deF1n1erll'n 51*. 1ftde. S:1.e FU ... e:l.n ausgel1eFert:es

B..... cht:l~ung50bj.kt d1* z ul~ ss 1gen be~r1eb s w1rt se haFtl1chen ObJekte (z . B.
Buehungskrl!!':l.s ad!!' ... C:e sc h li1f:: t::sber.ich) unci d 1e z U~~ 5s111. n
Be .... be1.t::ung s Funkt: l on . n ( ~. 8 . 0II01.g.,ft. !lnd.,r-n. lH$chen) auF2!:»hlen _ Zu
je d • • 1II . . . . Cht:iSlUn5l50bj.kt; kHnnen S 1. .. .i._r ~hrrrr IBrr-rcht1gungen
(II. Flnt ..... " _

H i n wels

Si.r kHntll!~' 1'I d1.1!' iindeorung van Dl!'bit:orl!'n - und K .. e dit:o .. enst:oiI~s .. t:zfOe~de .. n ~i.t:
HJ.1F. d ..... a * r * cht=igung s obj~kt=~ ·'Debit:o,. : iinderungsbe,.eCht:lgung FU ....
b~ $ t:1. .... t:e Fe1der " und ·'K.redlt:or : ifnderungsbereCht:lgung fOU .. best:1.~t:e
FI!'~der" sc hUt: ze n . Nel.che Uo .... u sset:z ung.n doil z u ... fU11t: se1. n ~U ssen . lesen
S:1.e 1 ... Ab sc hn1t:t: Fe~dberecht:19unSien fUr Oltblt:Qr ltn I,m., F'ltl.Clblt ... ltcht:ig",ngltn
t=Ur " ... dito... n .

Berecht::lgung s ob j ekt:e

DJ. e fo1!1en(l lt 1..1.:101;., ::r:e1. gt! . _.1c"' . Ber ec ht=::lgung s objek t:e bet. dl!'n e:ln:l!eJ.nen
F' unk t=1. uf1*n dl!'r Anweondung gl!'p"UFt: . . ,.dl!'n .

f"unkt:i.onen ~u • • • Gt:rtrcht:J.gungsabJ ekt!

Deb!! t=ar e n st:.a IUlld A t:en

Nach Auswahl eines Berechtigungsobjekts zeigt das System die

zugeordnete Objekt-Dokumentation.

99
5 SchlujSbemerkung

Abb. 4.3.4 ...

a .. u .t.,ln J:I., .,-b.,U.,... S pr-Il'l oa n
.".. '.. '10 . . "'11 . . . . "'."
S)t&tI!lM tt"te
C
oe b lt;:n r : An ..e ndun!J ~ b e l" el':.hti.gung

Op,Fl r'l1t:i.ulI

HJ.t d1~ si!' '' O~,..cht:i.gung s obj.kt: 1.g.n ste Fl!'st::. 1ItrH!'1che IAk t:i v tt:~t::e n FUr'
D i!' b :lt: a .... n s t:.II~s~t:z • .... 1.11 ubl: si. nd . D1es . . . . . eCht:igung kHnn e n s1. get ... nnt:
n .c h de-n Anwendungen FinanZbUChh.l.t:ung (Fl) und Ue ,.It.- i.eb ( S D) "eFi nie ... en
So1.1. e1n Hi t ... belt:IIP" die St;.~at:.n I'U .. beldllt Anwwndl,l"gwn b ...... Ib.J.t;""
dU .. '-. ". bentJt:lgt: vr die- 8r ... ~eht1.gul"lg FUr brldi!' An we-ndung .t>n_

D,as Obj e kt:: 1st:: ..ut: dl!'n beiden F.J.d .... n ··Akt::lu lt::'t:· · und
··An ~ndung5be"'.Cht:1gung·· d. fl ni .... t: •
., . Ak t:1 u 1t;~U;
H 1 .....;I,.1;; b~ :<; t::I._n S:l r • .-.l.l':. h e Ak t::l v 1.t:K e n erl..IIubt: ~l "d .
Htlg111':.he w. ... t:i!':
81 - Anl.egl!'n
82 - ainel.,.n
83 - Anzeige n
85 - sper r e n/ E n t5Pc rr cn
86 - LHse hvor ... rkUn!i1 Sl wt a: en
•• - Anderungsbe1e!ilv ~na:e1gC'n
- - 11 11. Ak t;1 ", 1t;lat:.,n

5 SchluBbemerkung

Der hierarchische Aufbau der Berechtigungselemente, das Ver-

sionenkonzept sowie die Mbglichkeit der Delegation von Admi-
nistrationsaufgaben im Hinblick auf eine grbBtmbgliche System-
sicherheit sind die wesentlichen Merkmale des SAP-R/3-
Berechtigungskonzepts.
Den auszuftihrenden Tatigkeiten innerhalb eines Unternehmens
stehen systemseitig Wertebereiche bzgl. der den betrieblichen
Sachverhalten entsprechenden Berechtigungsobjekten gegen-
tiber. Diese finden tiber Berechtigungsprofile ihren Niederschlag
im Benutzerstarnm des SAP-Anwenders.
Obige Tatsachen bedingen eine detaillierte Analyse der in einem
Unternehmen vorhandenen Tatigkeitsbereiche und die Einfuh-
rung des Berechtigungskonzepts vor dem Hintergrund der be-
trieblichen Organisationsstruktur.

100
SAP Business Workflow zur Steuerung
von Geschaftsprozessen

Dipl-Inf. (FH) Edgar Bahmann

Fa. iXOS Software GmbH, Grasbrunn (bei Munchen)

Prof. Dr. rer. pol. Paul Wenzel

Fachhochschule fUr Technik, Wirtschaft und Gestaltung,

Konstanz

101
1 Uberblick

1 Oberblick

Die Begriffe Workflow und Workflow-Systeme werden derzeit

haufig als Schlagworte gebraucht, obwohl das Thema Workflow
(Vorgangsverarbeitung) bereits in den letzten Jahren zum Ge-
genstand von Diskussionen in Informatik und Betriebswirt-
schaftslehre geworden ist. Die Definitionenvielfalt vermittelt ei-
nen Eindruck der zu erwartenden Funktionalitaten einer Soft-
ware fur dieses Aufgabenfeld.

1.1 Begriffliche Klarung

Vorgangsverar- Der Begriff Vorgangsverarbeitung ist aquivalent zum eng-
beitung/Workflow lischsprachigen Begriff Workflow: Vorgangsverarbeitung bein-
haltet die Optimierung von Geschaftsprozessen. Besondere Be-
deutung hat die Verarbeitung, Weiterleitung und Archivierung
von Dokumenten fur Geschaftsvorgange innerhalb eines Unter-
nehmens mittels eines elektronischen Systems (Vorgangs-
verarbeitungssystem) .
"Vorgangsverarbeitung ist eine aktive, selbstandig arbeitende,
uberwachende, kontrollierende und entscheidende Software, die
dem Anwender Routineaufgaben abnimmt, standig wiederkeh-
rende Vorgange abwickelt und die Verbindung schafft zwischen
Textverarbeitungssystemen, Tabellenkalkulation, Masken und
Datenbanken. Die Zielsetzung ist: weg von der Arbeitseinteilung,
hin zur ganzheitlichen Bearbeitung, Kontrolle und Steuerung
von Geschaftsvorfallen."l
Geschiil!sprozeB Ein GroBteil der Geschaftsprozesse wird durch eingehende
Papierdokumente ausgelost. Geschaftsprozesse bestehen aus
einzelnen Vorgangsschritten. Die einzelnen Vorgangsschritte
konnen "atomare" Aktionen oder Aktivitaten sein (hoher Detai-

1 Schulze, J.: Integrierte Vorgangsverarbeitung - aktueller denn je. In: Office Ma-
nageme nt, FBO-Fachverlag, Baden-Baden, 11/ 93 , S. 98

102
 1.1 BegriJ/liche Kliinmg

lierungsgrad), aber auch umfangreiche Teilaufgaben umfassen

(niedriger Detailierungsgrad). 2
Der Vorgang definiert die Reihenfolge der einzelnen Vorgangs-
schritte. Fur die Vorgangsschritte kann ein Bearbeiter die maxi-
male Dauer und Aktionen beim Oberschreiten dieser Dauer so-
wie gegebenenfalls Vor- und Nachbedingungen festlegen. Bei
der Implementierung von Vorgangsverarbeitungssystemen und
der Modellierung von Geschaftsprozessen wird auch die Be-
zeichnung Vorgangstyp verwandt. Die zur Laufzeit erzeugten
Auspragungen eines Vorgangstyps werden dann als Vorgange
bezeichnet.
Business Process Vnter Business Process Reengineering versteht man die um-
Reengineering fassende Neustrukturierung der internen und externen Ge-
schaftsprozesse. Der Ablauf der Leistungserstellung und die
damit verbundene Zustandigkeit und Verantwortung wird neu
organisiert. Die einzelnen Geschaftsprozesse werden analysiert
und optimiert.
Dokumenten-
managementsystem Der Begriff Dokumentenmanagementsystem (DMS) steht im
engen Zusammenhang mit der Vorgangsverarbeitung. Es existiert
eine groBe Begriffsvielfalt: Die Definitionen reichen einerseits
von einem Recherchesystem fur Dokumente, die auf Magnet-
oder optischen Platten archiviert sind, bis zu Systemen, die den
kompletten Lebenszyklus eines Dokuments, von der Entstehung
und Ablage bis zur Recherche und Anzeige, verwalten.
Oft handelt es sich urn verschiedene Komponenten (Archiv- und
Ablagesystem, Recherchesystem, Indizierungssystem, Erfassungs-
system, Formatkonvertierungs-, Ausgabe- und Drucksystem), die
integriert als DMS bezeichnet werden. In einer erweiterten Form
umfaBt ein DMS auch Mittel der Informationsintegration
(Burokommunikationssysteme, Daten von Anwendungen, exter-
ne Dokumente), der Dokumentenverteilung (elektronische Post,
FAX, Drucker) und Einstellungsmoglichkeiten fur die Dokumen-
tenspeicherung (Ablagehierarchien, Aufbewahrungsfristen).
Workgroup Workgroup computing bedeutet die Anwendung von Infor-
computing matikmitteln, urn Aufgaben innerhalb von Teams besser,
schneller oder einfacher bearbeiten zu konnen. Workgroup

2 vgl. Heilmann, H.: Workflow Management: Integration von Organisation und

Informationsverarbeitung. In: Heilmann, H. u.a. [Hrsg.J: HMD Handbuch der
modemen Datenverarbeitung, Band 176, ForkeJ Verlag, Heidelberg, 1994,
S. 14

103
1 Oberblick

computing unterstutzt eine weitgehend unstrukturierte Bearbei-

tung von Prozessen. Die Programme in diesem Bereich erlauben
den Austausch von Nachrichten (z.B. Mail-Programme, gemein-
same Terminkalender oder Programme zum Versenden von Do-
kumenten mit entsprechenden .Anderungen oder Anmerkungen),
die gemeinsame Bearbeitung von Dokumenten oder die Team-
arbeit uber raumliche Grenzen oder Zeitverschiebungen
(Zeitzonen), bei internationalen Projekten, hinweg.
Papierloses Buro Das Konzept des Papierlosen Buros (paperless office) basiert
auf der Idee, die Papierflut zu verringern, indem auf die Ver-
wendung von papiergebundenen Akten verzichtet wird; stattdes-
sen soil en aile Dokumente in elektronischer Form vorliegen.
Elektronische Dokumente kbnnen von mehreren Bearbeitern
gleichzeitig bearbeitet werden; Transportzeiten und Zeiten zur
Ablage sowie zum Auffinden von Akten entfallen durch geeigne-
te Indizierung und durch Einsatz von Attributen bei der Ablage
ganzlich. Erwahnenswert ist der Einsatz von elektronischem Da-
EDI - Electronic Data tenaustausch zwischen Geschaftspartnern (EDI Electronic Data
Interchange Interchange mit dem Standard EDIFACT), der in der Zukunft
von immer grbBerer Bedeutung sein wird. Derzeit uberwiegt al-
lerdings noch die traditionelle Methode des papiergebundenen
Nachrichtenwesens zwischen den einzelnen Unternehmen.

1.2 Merkmale von Vorgangsverarbeitungssystemen

Vorgangsverarbeitungssysteme (WS) mussen verschiedene
Rechnerinfrastrukturen und Systemplattformen integrieren kbn-
nen. Standardsoftware und die fur die Belange eines Unterneh-
mens individuell erstellte Software muB weiter verwendbar sein
und gegebenenfalls in ein Vorgangsverarbeitungssystem einge-
bunden werden kbnnen. Es muB mbglich sein, aile im Ge-
schaftsverkehr eingesetzten Medien als Auslbser von Vorgangen
zu definieren; dies sind z.B. EDI-Nachrichten, elektronische
Formulare oder Belege, die fur die Vorgangsverarbeitung elek-
tronisch archiviert werden mussen. Die Software soli nach defi-
nierten Regeln Arbeitsablaufe steuern und uberwachen.
Die Funktionalitat derartiger Software laBt sich in zwei Hauptka-
tegorien einteilen: Funktionen zur Laufzeit des Systems und
Funktionen zur Administration.

104
 1.2 Merkmale von Vorgangsverarbeitungssystemen

Funktionen zur Ad- Die Funktionen zur Administration umfassen sowohl die
ministration erstmalige Entwicklung (Definition) eines Vorgangstyps und aIle
damit verbundenen Tatigkeiten und Anforderungen an die Soft-
ware als auch die Auswertung von abgearbeiteten Vorgangen
und die Verbesserung und Anpassung der eingesetzten Vor-
gangstypen. Zur Modellierung und Definition von Geschaftspro-
zessen in Form von Vorgangstypen sollte ein grafischer Editor
existieren, desweiteren Werkzeuge zur Erstellung von Bild-
schirmrnasken und Formularen, die im Verlaufe der Bearbeitung
eines Vorgangs eingesetzt werden. Die modellierten Geschafts-
prozesse soIl ten mittels eines Simulations tools getestet werden
kbnnen. Fur die Zuordnung von Vorgangsschritten zu Bearbei-
tern und fur die Vergabe von Berechtigungen ist es erforderlich,
Zugriff auf das Organisationsmodell der an einem Vorgang be-
teiligten Abteilung/Unternehmung zu haben.
Berechtigungen Die Vergabe von Berechtigungen ist notwendig, da der Zugriff
auf Vorgange nur in Abhangigkeit von den im Organisationsmo-
dell festgelegten Rechten erfolgen soIl. Weiterhin ist im Verlauf
von bestimrnten Vorgangen die Vergabe einer Genehmigung
erforderlich. Eine Behandlung von Fehlern und Sonderfallen, die
zur Laufzeit auftreten, ist schon bei der Modellierung von Ge-
schaftsprozessen zu betrachten, Z.B. eine Eskalation der Zustan-
digkeit bei einer Terminuberschreitung. Neben diesen kalkulier-
baren Problemen kbnnen Umstande eintreten, die die manuelle
Vorgangssteuerung durch einen Administrator erfordern, d.h. die
Behandlung eines laufenden Vorgangs muB beeinfluBbar sein.
Auf jeden Fall ist fur den Administrator die Statusabfrage, nach
einem bestimrnten Vorgang und dessen Bearbeitungshistorie, zu
ermbglichen. Es kann auch sinnvoll sein, diese Funktion dem
Anwender zur Verfiigung zu stellen.
Fur die Definition von Vorgangen sind folgende Werkzeuge,
Modelle und Eigenschaften zu betrachten:
o Untersttitzung der Modellierung von Geschaftsprozessen im
System (Vorgangstypen) mit einem grafischen Editor
o Beliebige KontrollfluBmittel (Regeln, Warteschritte usw.)
o Integration von Standardsoftware
o Integration von Individualsoftware
o Tool zur Erzeugung von Formularen
o Tool zur Maskengenerierung
o Simulationswerkzeuge, Plausibilitatsprtifung

105
1 Oberblick

(J Integration eines Archivsystems

a Integration von elektronisch ubermittelten Nachrichten
a Verknupfung von Ablauf- und Aufbauorganisation
a Berechtigungskonzept fur die Bearbeitung von Vorgangen
(mit Gruppen und RoUen)
a Berechtigungskonzept fur die Sichtung, Weiterleitung, Ge-
nehmigung von Vorgangen
Fur die Auswertung von Vorgangen, die mit dem Vorgangsver-
arbeitungssystem bearbeitet wurden, sind folgende Werkzeuge
moglich:
a Standardanalysen (Laufzeiten, Anzahl)
a Kapazitats- und Kostenberechnungen
a Optimierung der Ablaufe
Lauizeitverhalten Das Laufzeitverhalten betrifft die automatische Zuweisung von
Vorgangen zu Bearbeitern bzw. die Existenz eines elektroni-
schen Gruppenpostkorbes, der die existierenden Vorgange ent-
halt und aus dem die Sachbearbeiter die von ihnen zu bearbei-
tenden Vorgange entnehmen. Eine Regelung fUr Abwesenheiten
und Funktionen zur Wiedervorlage oder das Erganzen eines
Workflowobjekts urn weitere Dokumente oder Nachrichten sind
notwendig. Das Vorgangsverarbeitungssystem und die im Veri auf
der Bearbeitung eingesetzten Werkzeuge soUten in einer einheit-
lichen Benutzeroberflache integriert sein.
Die nachfolgenden Funktionen betreffen das Laufzeitverhalten
und die fur den Anwender sichtbare und nutzbare Funktionalitat:
a Steuerung der Eingangspost
a Automatische Verteilung und Transport von Vorgangen,
Dokumenten und Informationen zum Sachbearbeiter
a Elektronischer Eingangskorb
a Gruppenpostkorb
a Vertreterfunktion
(J Automatische Wiedervorlage

106
 1.3 Chancen und Risiken

o Vorgangsbegleitende Notizfunktion
o Integration aller velWendeten Anwendungen in eine ein-
heitliche Benutzeroberflache
o Elektronische mehrstufige Genehmigung und Freigabe
o Druckausgabesteuerung
Neben diesen Funktionen fur die eigentliche Bearbeitung von
Vorgangen sind auch Funktionen fur die Bearbeitungssteuerung
zur Laufzeit erforderlich:
o Arbeitsvorratsubersicht
o Bearbeitungsstatus
o Vorgangshistorie
1.3 Chancen und Risiken
Die Steigerung der Wirtschaftlichkeit, mittels einer Verringerung
Liege- und Trans- von unproduktiven Liege- und Transportzeiten, kann als eine
portzeiten
bedeutende Zielsetzung in der Umsetzung von Rationalisie-
rungsmaBnahmen angesehen werden. Die durch diese Zeiten
bedingten Kosten sollen entfallen. Vorgange mussen in einem
zeitlich begrenzten Rahmen abgeschlossen werden.
Wahrend bei der traditionellen Bearbeitung von Vorgangen
papiergebundene oftrnals eine papiergebundene Akte angelegt wird, die zwi-
Akten schen verschiedenen Bearbeitem bewegt wird und immer nur an
einer Stelle verfugbar ist, ermoglicht die elektronische Vorgangs-
verarbeitung eine neue Arbeitsweise ohne Transportzeiten; au-
Berdem konnen mehrere Anwender auf ein Dokument gleich-
zeitig zugreifen. Durch das elektronische Archivieren entfallen
Zeiten zum Auffinden eines archivierten Schriftsrucks. Wenn eine
zentrale Poststelle aIle eingehenden Schriftstucke erfaBt und die-
se mit dem entsprechenden Vorgang verbunden werden, kann
die Idee des papierlosen Buros velWirklicht werden.
Ein weiterer Grund fur die Kostenreduktion beim Einsatz der
Vorgangsverarbeitung liegt darin, daB die Geschaftsprozesse mit
den meisten papiergesrutzten Bearbeitungsschritten und kom-

107
1 Oberblick

plexen Interaktionen zwischen verschiedenen Anwendern meist

auch die teuersten sind. 3
Business Process Durch Einsatz traditioneller Methoden kann bereits eine Verbes-
Reengineering serung von 50% des Potentials, das im Business Process Re-
engineering liegt, erreicht werden. Fi.ir die Ausschbpfung des
vollen Potentials ist die Automatisierung dieser Methoden erfor-
derlich. 4
schnellere Neben der Kostenreduktion soll der Einsatz einer Vorgangsver-
Reaktionszeiten arbeitungssoftware auch zu schnelleren Reaktionszeiten auf
Kundenanfragen fUhren und somit dazu beitragen, daB Unter-
nehmen die Belange der Kunden besser erfi.illen kbnnen
Customer Focus (Customer Focus). Die Ausrichtung des Unternehmens hin zum
Kunden (Customer Focus) kann zu Wettbewerbsvorteilen gegen-
i.iber anderen Unternehmen und zu einer Starkung der Markt-
position fi.ihren.
In groBen Unternehmen werden fi.ir den normalen Geschaftsbe-
trieb oft mehrere tausend, verbundener Anwendungen einge-
setzt. Viele von diesen verbundenen Anwendungen stellen Ge-
schaftspraktiken oder Geschaftsablaufe dar, die fUr das Ge-
schaftswesen relevant sind. Oft ist das Wissen i.iber das Zusam-
menspiel dieser Anwendungen verlorengegangen, da die Doku-
mentation unzureichend war oder Informationen nur mi.indlich
weitergegeben wurden.
Die wichtigste Rolle fUr Workflow-Management-Software wird
die Integration von separaten Anwendungen sein. Der Schwer-
punkt wird in der Verbindung von Vorgangen liegen, die der-
zeit noch durch traditionell papiergebundene Arbeitsweise erle-
digt werden. Diese Geschaftsvorgange sind vollstandig bekannt
und verstanden, aber niemals integriert worden. Besondere Be-
deutung kommt Systemen des Bestelleingangs oder des Ein-
kaufwesens zu, da diese zwar sehr klar strukturierbar sind, teil-
weise aber dennoch recht komplex sind (z.B. Ermitteln des rich-
tigen individuellen Rabatts oder Liefertermins abhangig yom Ge-
schaftspartner) und die relative Anzahl dieser Vorgange sehr
groB ist.

3 vgl. Wiedmann G./Schafer M.: Imaging Trends. In: Office Management, FBO-
Fachverlag, Baden-Baden, 11/ 93, S. 9
4 vgl. Hsu M./Howard M.: Work-Flow and Legacy Systems. In: Byte, McGraw-
Hill Inc, New York, July 1994, s. 110

108
 1.3 Chancen und Risiken

Arbeitsorganisation Die Einfuhrung der Vorgangsverarbeitung erfordert die Veriin-

derung der Arbeitsorganisation. Dadurch, daB das Arbeits-
spektrum des einzelnen elWeitert wird und Verantwortung an
Teams gegeben wird, innerhalb deren jedes Teammitglied aIle
Arbeiten ausruhren kann, wird die Arbeit interessanter. Fur ein
soIches Arbeiten brauchen die Anwender eine unternehmens-
weite Organisationssicht.
Der Arbeitsstll wandelt sich hin zu einem interaktiven, kom-
munikativen, flexiblen und schnell agierenden und reagierenden
Verhalten unter Einsatz des Mediums Computer. Die Frage stellt
sich, inwieweit der heutige Sachbearbeiter rur eine derartige Ar-
beitsweise ausgebildet und lernbereit ist. Die Akzeptanz eines
soIchen Systems ist schwierig vorauszusehen, und der erforderli-
che Aufwand rur entsprechende FortbildungsmaBnahmen ist be-
achtlich.
Ein weiteres Problem entsteht durch das Entfallen einfacher
Tatigkeiten, wie Botengange und Archivierungsaufgaben, und
der Einsatz der bis dahin mit diesen Aufgaben betrauten Mitar-
beitern.
Bei einem Einsatz eines WS besteht eine hochgradige Abhan-
gigkeit von der Verfugbarkeit und Zuverlassigkeit der Computer-
systeme, da bei einem Systemausfall kein Arbeiten mehr moglich
ware. Die Anforderungen an das Computersystem selbst sind
sehr hoch, denn rur die Sachbearbeiterplatze mussen leistungs-
fahige Systeme der neuesten Generation mit sehr groBen Monito-
ren (17" bis 21") eingesetzt werden.
glasemer Da aIle Vorgange yom System protokolliert werden, ist damit
Mitarbeiter auch eine ObelWachung des einzelnen Mitarbeiters moglich
(''g/aserner Mitarbeiter''J. Dies kann zu Angsten und StreB ruhren,
wodurch die Leistungen tangiert werden konnten.

109
2 Einfuhrung von Vorgangsverarbeitungssystemen

2 Einfuhrung von Vorgangsverarbeitungssystemen

2.1 Voraussetzungen
Um Vorgangsverarbeitungssysteme implementieren und einset-
zen zu kbnnen, sind einige Voraussetzungen zu erfullen bzw. zu
schaffen. Diese beziehen sich sowohl auf die technische Infra-
struktur als auch auf die Existenz von know-how.
optische Abhiingig von der Kategorie der Vorgangsverarbeitungssoftware
Archivierung und der Rechnerumgebung sind verschiedene systemtechnische
Voraussetzungen bereitzustellen; z.B. muB beim Einsatz von
Standalone-PCs eine Netzwerk-Infrastruktur geschaffen werden.
Beim Einsatz von optischer Archivierung im Rahmen eines
Vorgangsverarbeitungssystems mussen weitere Gesichtspunkte
beachtet werden. Da die Datenmengen fur eingescannte Origi-
naldokumente sehr groB sind, sind die Performanceanforde-
rungen an das Netzwerk sehr hoch. Die Obertragungszeit eines
archivierten Dokuments kann neben der eigentlichen Archiv-
Retrievalzeit auch in einem Hochleistungsnetz mehrere Sekun-
den dauern. Bei der Erstellung eines Netzwerkes muB auf eine
entsprechend gunstige Konfiguration geachtet werden, z.B.
durch die Einteilung in verschiedene Segmente. Dies betrifft ins-
besondere Systeme, die konzernweit eingesetzt werden kbnnen.
Modellierung von Bei einer Anbindung eines PC-Netzes an einen Host mussen
Geschaftsprozessen Schnittstellen zwischen den Host-Applikationen und WF-
Systemen definiert und Kommunikationsmechanismen zur Ver-
fugung gestellt werden. Know-how und personelle Infrastruktur
im Bereich der Modellierung von Geschaftsprozessen sowie
in der Administration von Archiv- und Workflowsystemen mus-
sen aufgebaut werden. Nach Mbglichkeit soUte ein systemtrans-
parentes Log-in-verfahren fur die Benutzer entwickelt werden,
um zu vermeiden, daB sich die Anwender neben der Anmeldung
am Netzwerk und am Host auch noch an einem weiteren System
(WF-System) anmelden mussen; dies kbnnte zu Akzeptanzpro-
blemen fuhren.

110
 2.2 Metbodiscbes Vorgeben

Neben diesen allgemeinen Vorarbeiten muB ein Vorgangsverar-

beitungsystem ausgewahlt werden, das eine hinreichende Funk-
tionalitat und Machtigkeit besitzt, urn die Erfordernisse des Un-
ternehmens zu erfullen.

2.2 Methodisches Vorgehen

2.2.1 Organisatorisehe Sieht

Zur Einfuhrung eines Workflow-Mangement-Systems bietet sich
ein methodisches Vorgehen mit einer Einteilung in drei Phasen
an. Es ist schwierig, genaue Angaben uber die Aufwande und
erforderlichen Zeiten fur die einzelnen Phasen zu machen.

Abb.2.1
Vorgehensweise bei Geschaftsprozesse Infrasouktur
EinfOhrung eines
Vorgangsverarbei- AnalySt Analyst-Vorarbeiten
lungssyslems AnalySt duOtschiftsproztsse AnalySt du Hardware Umgebung

PzOCtSS Rtdtsign Evalue.tion- Ausbildung

Rtstrukturiuungund Optiroiuung Auswahl tinu Softwart
Bildung von Know How
Pus onalfortbildung

,
Rtalisiuung Rtalisiuung
Auswahl und Impltn\entiuung Impltn\entiuung du H8IdW8It
Impltn\entiuung duSoftw8It

Analyse Ziel der Analyse ist die Modellierung der organisatorischen Ist-
Situation des Unternehmens; dies umfaBt:
Cl Analyse der Autbauorganisation des Unternehmens (Die
Darstellung erfolgt in Form eines Organigramms.)
Cl Analyse der Ablauforganisation (Hier werden die einzel-
nen Prozesse identifiziert und ihre Abhangigkeiten unter-
einander in einem ProzeBdiagramm dargestellt. Die fur das
Unternehmen relevanten Geschaftsprozesse fur das ProzeB-
Reengineering werden herausgestellt.)
Cl Analyse der Informationsfliisse (der verschiedenen
Funktionsbereiche im Unternehmen)

111
2 Einfuhrung von Vorgangsverarbeitungssystemen

ProzeB Redesign ProzeS Redesign stellt die optimierte Gestaltung der Geschiifts-
prozesse dar. Es ist hierzu erforderlich, die betroffenen Ftih-
rungskrafte der Fachabteilungen, die Organisatoren und Infor-
mationsverarbeitungsexperten im Rahmen eines Reorganisa-
tionsprojektes zu integrieren. Weiterhin werden die Anderungen
mit den Anwendern abgesprochen, urn notwendige Veranderun-
gen aus deren Sieht einzubeziehen. Es wird tiberpruft, welche
Teilprozesse und Arbeitsschritte zur Leistungserstellung ben6tigt
werden.
1m Rahmen der Einftihrung der Standardsoftware SAP-R!3 wird,
z.B. in einem ProzeS Reengineering, mittels ProzeBauswahlma-
tritzen eine Auswahl aus dem gesamten Leistungsspektrum des
R!3 getroffen und den Prozessen der 1st-Analyse R!3 zugeordnet.
Die ausgewahlten Prozesse werden den spezifischen Anforde-
rungen des Unternehmens angepaBt, d.h. fehlende Funktionen
werden u.u. erganzt. Besitzt der ausgewahlte ProzeB Funktio-
nalitaten, die im Ist-ProzeB nicht vorhanden sind, und tragen
diese Funktionalitaten nicht zur Verbesserung des Prozesses bei,
so werden diese entfernt. 5
Realisierung Wegen der hohen Komplexitat der Einftihrung neuer ProzeB-
strukturen ist ein systematisehes Vorgehen unabdinglich. Neue
Prozesse werden organisatorisch und techniseh im Rahmen von
Testinstallationen erprobt. Die Prozesse mtissen kontinuierlieh
angepaBt und weiter verbessert werden. Die Schulung und Ein-
beziehung der Anwender ist in dieser Phase ebenfalls erforder-
lich.

2.2.2 Technische Sicht

Neben diesen organisatorischen Arbeiten, die die Geschaftspro-
zesse betreffen, sind auch Arbeiten im Bereich der Infrastruktur
durehzufUhren. Diese sind teilweise in Form von Vorarbeiten
(siehe Kap. 2.1 Voraussetzungen fUr die Einftihrung von Vor-
gangsverarbeitungsystemen) durchzuftihren, k6nnen aber auch
teilweise parallel zu den Arbeiten in der ProzeBorganisation ab-
laufen.

5 vgl. Meinhardt, S.: Wege zur Geschaftsprozessoptimierung. In: SAPinfo, SAP

AG [Hrsg.], Walldorf, Marz 1994, S. 13

112
 2.3 Kategorien von Sojtwarepaketen

In einer Analysephase werden Anforderungen an die Hardware

ermittelt und, mit den Ergebnissen aus der Analyse der Ge-
schaftsprozesse, die Anforderungen an die Software spezifiziert.
In einer Evaluationsphase wird die Vorgangsverarbeitungssoft-
ware ausgewahlt (falls sie nicht in Form eines integrierten Pa-
kets, wie z.B. innerhalb R/3, zur Verfiigung steht). Die Auswahl
einer geeigneten Software erfolgt entsprechend den in der Ana-
lyse und im ProzeB Redesign ermittelten Anforderungen. In der
Realisierungsphase wird die technische Infrastruktur zur Umset-
zung der neu strukturierten Geschaftsprozesse geschaffen.

2.3 Kategorien von Softwarepaketen

1m Workflow Umfeld gibt es verschiedenartige Software, die sich
hinsichtlich ihrer Funktionalitiiten wesentlich voneinander unter-
scheiden. Man kann eine Einteilung in funf Klassen vornehmen:

2.3.1 Diagramm oder Zeichnungstools

Es handelt sich bei diesen Programmen urn relativ einfache
Software zum Zeichnen von graphischen Darstellungen fur Ar-
beitsablaufe, Prozesse, Organisationsstrukturen, Aufbauorganisa-
tionen oder Informationsflussen. Diese Software kann nur zu
Organisationszwecken oder zur Prasentation eingesetzt werden,
nicht aber im Sinne der eigentlichen Vorgangsverarbeitung. Mit
ihrer Hilfe k6nnen auch neue Prozesse entwickelt werden, oder
es kann im Vorfeld von Umstrukturierungen getestet werden,
wie neue Prozesse mit bereits existierenden Prozessen, Anwen-
dungen oder Systemplattformen harmonieren.

2.3.2 Traditionelle Workflow Tools

Mit Software dieser Kategorie k6nnen betriebliche Vorgange
analysiert und modelliert werden. Diese Software entstand in der
Zeit der ersten digitalen Bildverarbeitungssysteme. Workflow
und Bildverarbeitungskomponente sind eng miteinander gekop-
pelt. Durch diese enge Verflechtung ist allerdings der Einsatzbe-
reich derartiger Programme beschrankt. Sie lassen sich zwar zum
Dokumentmanagement einsetzen, nicht aber zur eigentlichen
Strukturierung oder Organisation von Geschaftsprozessen.

113
2 Einfuhrnng von Vorgangsverarbeitungssystemen

2.3.3 CASE Tools und Software Engineering Tools

Software-System- Produkte dieser Klasse werden im wesentlichen zur Erstellung

Design von Software eingesetzt, wobei die Umsetzung und Realisierung
von Anwenderanforderungen im Vordergrund steht. Der wich-
tigste Anwendungsbereich dieser Software liegt im Software-
System-Design und in der Systementwicklung. Mit dieser Soft-
ware kann eine intensive Analyse und Modellierung als Grund-
lage fur ein Softwaresystem durchgefilhrt werden, womit der
Software-Erstellungszyklus unterstiltzt wird. Der Ansatz dieser
Software liegt nicht allein in der Modellierung von betrieblichen
Ablaufen und deren Umsetzung, sondern in der Optimierung
des Softwareerstellungszyklus (mit optimaler Qualitatserzeu-
gung).

2.3.4 Workgroup Programme

Unter Workgroup Software versteht man Programme zur Kom-
munikation (z.B. Mailtools, Nachrichtensysteme), gemeinsame
Terminkalender oder beispielsweise Programme zum gemeinsa-
men Bearbeiten von Dokumenten.

2.3_5 Klassische Workflow Tools

Diese Programme werden auch als "Reine Workflow Tools" be-
zeichnet. Die Software dieser .Kategorie beinhaltet gewbhnlich
eine visuelle Methode, um Geschaftsprozesse darzustellen. Darin
integriert werden Informationsflilsse zwischen Personen und
Abteilungen. Es gibt Software, die das erstellte Modell verwen-
det, um verschiedene Ideen zur Verbesserung von Geschaftspro-
zessen durchzuspielen und zu testen. Aus dem Modell kann
dann auch ein Programmcode erzeugt werden. Mit einem sol-
chen Programm kbnnen bestehende Anwendungen teilweise
auch auf verschiedenen Plattformen integriert werden.
Die Workflow Software steuert den Ablauf von betrieblichen
Vorgangen; sie kann dabei auch dynamisch, auf Basis von ver-
schiedenen Voreinstellungen auf verschiedene Situationen, die
bei der Bearbeitung eines Vorgangs auftreten kbnnen, reagie-
ren. 6

6 vgl. May, T.: Know Your Workflow Tools. In: Byte, July 1994, McGraw-Hili
Inc., New York, S. 103 ff

114
 2.3 Kategorien von SoJtwarepaketen

Ein voiles Workflow Management System (siehe hierzu Anla-

ge: Workflow Produktiibersicht) untersrutzt die Entwicklung,
die Ausruhrung und Analyse von vielschichtigen Geschiiftsvor-
gangen, die mehrere Anwender betreffen. Es steuert den FluB
der Arbeit im System. Ein Vorgang ist eine zusammengesetzte
Arbeitseinheit, die sich aus modularen Arbeitsschritten oder wie-
derum aus geschachtelten Vorgangen (in dies em FaIle als Teil-
prozesse des ubergeordneten Vorgangs) zusammensetzt. Diese
Arbeitsschritte werden in einem Process Repository gespeichert.
Das Workflow System ist darur zustandig, daB einzelne Vorgange
zuverlassig und kontinuierlich ausgeruhrt werden, bis sie ord-
nungsgemaB abgeschlossen sind. Das System behandelt Anwen-
deranfragen nach dem Status eines Vorgangs, der jederzeit ab-
rufbar sein sollte, aber auch nach Status und zur Analyse des
Systems.

3 Workflow und Optische Archivierung

In Vorgangsverarbeitungssystemen kbnnen Vorgange durch ein-

gehende Originalbelege ausgelbst werden. Es kbnnte nun ein
Bildschirmformular angezeigt werden, in das die entsprechenden
Daten eingegeben werden. Eine ablauftechnisch wesentlich bes-
sere Lbsung ist es, den Originalbeleg zu erfassen und dadurch
einen Vorgang auszulbsen. Darnit entfaIlt die manuelle Daten-
eingabe, wodurch eine schnellere und kostengunstigere Bearbei-
tung mbglich wird. In der folgenden Abb. 3.1 wird der generelle
Ablauf des Erfassens und der Ablage eines Originalbeleges dar-
gestellt: 7

7 vgl. iXOS Software GmbH, Kurs "Einsatz von Archivsystemen", Munchen, 1993

115
3 Workflow und Optiscbe Arcbivierung

Abb. 3.1
Verteiltes
Archivsyslem Daienbank. F=1f--1!!iIII.....- Juk.ebox

archiYieren

erfassen I scannen
recherchierenI
CI1zeigen

indexieren bzw.
altribulieren

In einer Client- Server Architektur kbnnen Belege an einem Ar-

beitsplatz gescannt und erfaBt werden. Sie werden anschlieBend
indiziert, urn bei einer spateren Recherche wiedergefunden zu
werden. Die Ablage (Speicherung) kann mittels eines zentralen
Archivservers - unter Einsatz einer Datenbank verschiedenartiger
Medien (z.B. WORM) - erfolgen, wobei ein Netzwerk die Kom-
munikation ermbglicht. Abgelegte Dokumente kbnnen von be-
liebigen Arbeitsplatzen tiber das LAN recherchiert, angezeigt und
ausgedruckt werden.

3.1 Integration eines Archivsystems

Das folgende Beispiel zeigt die Integration eines Archivsystems
in ein Vorgangsverabeitungssystem am Beispiel SAP-R/3: 8

8 vgl. iXOS Software GmbH, Kurs "Einsatz von Archivsysteme n" , MGnchen; und
vgl. Gulbins, ]./Seyfried, M.!Strack-Zimmermann, H.: Elektronische Archivie-
rungssysteme, Springer Verlag, Berlin/ He idelberg, 1993, S. 297 ff

116
 3.1 Integration eines Arcbivsystems

Abb. 3.2
UNIX, WINDOW S NT
Integration Archiv-
system in Anwen-
dungsprogramm mit
Workflow

Workflow, Buchen, etc.

Clients
UNIX Windows,W.
UNIX

Erfassen lridexie ren, Recherchieren

und Anzelgen

Workflow-Objekt ErfaBte Belege werden einer vordefinierten Dokumentenart und

einem Bearbeiter zugeordnet und erzeugen einen Vorgang
(Workflow-Objekt). Das Workflow-Objekt wird in den Postein-
gang des Bearbeiters gestellt und kann von dort aus weiterverar-
beitet werden. (Details zur Vorgangsverarbeitung in SAP-R/3
werden in Kapitel 4 behandelt.)
Die elektronische Dokument- und Schriftgutverwaltung ist eine
Voraussetzung fur diese neue Form der Vorgangsverarbeitung.
In den nachsten Jahren werden Imaging Systeme zum integralen
Bestandteil von Informationssystemen im Buro werden. Damit
k6nnen dann beispielsweise handgeschriebene Papierdokumen-
te oder Skizzen eingescannt und mit Anmerkungen weitergeleitet
werden. Workflow wird dann voraussichtlich auf dem Massen-
markt in Erscheinung treten.9

9 vgl. Wiedmann, G./Schafer, M.: Imaging Trends. In: Office Management,

11/1993, FBO-Fachveriag, Baden-Baden, S. 9

117
3 Wor141ow und Optische Archivierung

3.2 Marktkonsequenzen
Der Markt fur Dokumentenmanagementsysteme wird in den
nachsten Jahren weiter stark wachsen. In der nahen Zukunft
wird die ganzheitliche Bearbeitung von Vorgangen mit
Workflow Systemen wesentlich an Bedeutung gewinnen. Dies
bedeutet auch, daB Vorgange durch das Erfassen eines Original-
belegs ausgelbst werden kbnnen. Es ist daher sinnvoU, Doku-
mentenmanagementsysteme in Vorgangsverarbeitungssysteme
einzubinden bzw. die benbtigten SchnittsteUen bereitzusteUen.
Betrachtet man die Bedeutung der Vorgangsverarbeitung fur den
Anbieter eines Archivsystems, so ist festzusteUen, daB die An-
wender einerseits eine Integration von Archivsystemen in ihre
Vorgangsverarbeitungssysteme teilweise schon heute wtinschen;
andererseits bei der Beschaffung eines reinen Archivsystems die
Integrationsmbglichkeit in ein evtl. spater zum Einsatz kommen-
den Vorgangssteuerungssystems bei der Kaufentscheidung erwa-
gen.
Die meisten Anwender eines Vorgangssteuerungssystems werden
sich bei einer Kaufentscheidung fur ein integriertes Archivsystem
entscheiden, das entweder direkt yom Hersteller angeboten wird
oder des sen Integration problernlos erfolgen kann. In dies em
Zusammenhang ist es sehr sinnvoU, im Rahmen von Testinstalla-
tionen das Zusammenwirken eines Archivsystems mit den ver-
schiedenen Vorgangssteuerungssystemen zu erproben und zu
dokumentieren. Ein weiterfuhrender Schritt ware die direkte Ko-
operation mit einem Hersteller eines Vorgangsverarbeitungsy-
stems.
Fur die ferne Zukunft ist der Bedarf fur optische Archivierung
differenzierter zu betrachten, denn mit der fortschreitenden
Entwicklung im Bereich des elektronischen Datenaustausches
verliert die Archivierung von Papierdokumenten weiter an Be-
deutung.
1m Vergleich zu den USA verIauft in Deutschland und Europa
die Marktentwicklung fur Archivsysteme derzeit noch sehr lang-
sam. Die Entwicklung auf dem "EDI-Markt" soUte genau beob-
achtet werden. Von Bedeutung ist die Entwicklung von Funktio-
nalitat im Bereich von COLD (Computer Output on Laser Disk),
bei dem z.B. Drucklisten auf CD-ROM erzeugt werden kbnnen.

118
 4.1 Grnndlagen

Zur Verbindung von EDI und Workflow laBt sich sagen, daB es
bereits heute moglich ist, abhangig von eingehenden EDI-
Dokumenten Geschaftsprozesse auszulosen. Dies ist zum Bei-
spiel in der Funktionalitat von SAP Business Workflow enthalten.

4 Vorgangsverarbeitung im System SAP-Rl3

4.1 Grundlagen
1m betrieblichen Standardsoftwarepaket SAP-R/3 ist die Anwen-
dung "SAP-Business-Worktlow" enthalten. Diese Anwendung
ist ein Workflow-Management-System fur Vorgange innerhalb
einer Konzernsstruktur.
1m Hause SAP werden Workflows wie folgt definiert: 10
"SAP faBt unter dem Namen "Business Workflow" zwei Integrati-
onstechniken zusammen:
O die Anwendungsintegration auf Basis einer integrierten
Datenbank und
o Techniken der arbeitsplatzverbindenden Vorgangs-
steuerung, bei der Datenobjekte mit anderen Dokumenten
verbunden und im ArbeitsfluB weitergereicht werden. Dies
schlieBt den ublichen dokumentenbasierten Workflow aus
Image-Management und E-mail-Systemen ein."
Das SAP-System bietet Funktionalitat, urn eingehende Nachrich-
ten und Informationen weiterzuverarbeiten. Fur die klassische
(papiergebundene) Form von eingehenden Dokumenten wird
die Vorgangsverarbeitung durch den Einsatz von optischen Ar-
chivsystemen und dem Prinzip des friihen Erfassens realisiert.
Fur eingehende EDI-Nachrichten existiert eine weitgehend sy-
stemgestutzte Verarbeitung.

10 Tschira, K.lZencke, P.: Geschaftsprozessoptimierung mit dem SAP-System

R/3. In: SAPinfo, SAP AG [Hrsg.J, Walldorf, 3/ 94, S. 6

119
4 Vorgangsverarbeitung im System SAP-R/3

Vorgangstypen- Zur Definitionszeit bietet das System Funktionen zur Vorgangs-

definition definition. 1m wesentlichen ist das ein Verfahren zur Vorgangs-
typendefinition. Bei der Vorgangstypendef'mition wird ein
Netz mbglicher Zustande festgelegt. Ein Vorgang kann vom
Startzustand aus verschiedene andere Zustande durchlaufen, bis
er schlieBlich den Endzustand erreicht. Bearbeiter ftir bestimmte
Aktionen kbnnen angegeben werden. Aus einem Vorgang her-
aus ist es mbglich, andere Vorgange zu erzeugen. Die eigent-
liche Definition der Tatigkeit bei der Verarbeitung, d.h. welche
Transaktion zur Verarbeitung benbtigt wird, kann bei der De-
finition einer eingehenden Dokumentenart angegeben werden.
Zur Definition von Vorgangen wird die Custornizing-
Komponente des R/3-Systems eingesetzt, wodurch einzelne Vor-
gange unternehmensindividuell modelliert werden kbnnen.
Bestehendes Kon- Das bestehende Workflowkonzept ermbglicht die durchgangige
zept Bearbeitung von komplexen Geschaftsprozessen. Ftir die Bear-
beitung von eingehenden Originaldokumenten existieren vor-
def'mierte Vorgangstypen, die einen automatisierten Ablauf
der Verarbeitung ermbglichen. Vorgange kbnnen darnit erzeugt,
angezeigt, weitergeleitet, in der Office-Ablage gehalten und ver-
arbeitet werden. Bei der Verarbeitung von Vorgangen, die durch
einen Originalbeleg erzeugt wurden, wird dieser automatisch
angezeigt und, in Abhangigkeit von der zugeordneten Dokumen-
tenart, die entsprechende Transaktion zur Verarbeitung aufgeru-
fen.
Vorgange kbnnen auch durch das Eintreffen elektronischer
Nachrichten (EDI) ausgelbst werden. Derartige Nachrichten kbn-
nen vom System weitgehend selbstandig weiterverarbeitet wer-
den. Es existieren Funktionen zur Administration und Statusab-
frage von Vorgangen. Damit kbnnen die einzelnen Verarbei-
tungsschritte eines Vorgangs kontrolliert und verfolgt werden. 1m
Rahmen der Nachrichtensteuerung kann das System beim Vor-
liegen bestimmter Ereignisse selbstandig Meldungen erzeugen
und in verschiedener Form (Mail, Fax, Druckausgabe) ausgeben.
Die Office-Komponente ermbglicht auBerdem das Erstellen und
Versenden von Nachrichten, die u.U. besondere Eigenschaften
besitzen kbnnen, z.B. Wartestellung auf eine Rtickantwort
(Adhoc-Workflow).

120
 4.2 Grundelemente der Dokumentenverarbeitung

4.2 Grundelemente der Dokumentenverarbeitung

1m Bereich Dokumentenverarbeitung besteht eine enge Verl1ech-
tung zwischen Vorgangstyp, Dokumentenart und der mit der
Dokumentart verknupften Transaktion.

Abb.4.2.1
Komponenten der
Vorgangs-
bearbeitung
(bei NCI-Doku-
menten)

Die Vorgangsverarbeitung lauft nicht in linearen Schritten ab,

sondem kann abhangig von den Ereignissen, die wahrend der
Bearbeitung auftreten, verschiedene Zustande annehmen: 11

Abb.4.2.2
Zyklischer Ablauf der
Vorgangs-
bearbeitung

11 vgl. SAP AG [Hrsg.l: SAP-Business-Workflow 2.1

121
4 Vorgangsverarbeitung im System SAP-R/3

4.3 Beispiel fOr dokumentenbasierten Workflow

Das folgende Beispiel zeigt einen Vorgang, der mit dem SAP-
Business-Workflow realisiert wurde. Eine eingehende Rechnung,
die als Papierdokument im Unternehmen eintrifft, wird erfaBt
(fruhes Erfassen) und durchhiuft verschiedene Schritte der Bear-
beitung, bis der Vorgang als erledigt gekennzeichnet wird und
aus dem Posteingang des Bearbeiters geloscht wird.
Der Vorgang wird zunachst als ereignisgesteuerte ProzeBkette
modelliert; anschlieBend werden die Bearbeitungsschritte mit
zugehoriger Bildschirmmaske erklart:

Abb.4.3.1
Ereignisgesteuerte
<it~g >
ProzeBkette: einge-
hende Rechnung Cr$u:J

,....------I@~-----:
<~.;~ <=l~Q;>
(~=:.moit'
<;sif>

122
 4.3 Beispiel fur dokumentenbasierten Worliflow

Die einzelnen Verarbeitungsschritte:

Abb.4.3.2
Zuordnen eines Be-
arbeiters zum Origi- . ~ lit..... :qdIt f"*" ~

nalbeleg ....,QLliI .."" QLliI ~~ Ie.. 1I1£J li T I

.
,....f:...
-
....::~.-....­

--
I~ [J eJ]I J ~ ~~IJ

........
~ 1II . . z....., -ree-!t-o.t-M•
In:--.
=....
."......,. Iilre• .I.......

....
~r-I- --
jb n ..........
---
ItH:. . . . . . . F._
SJECElI ............ !
~11I:;du-rtr ..
fltIdth z_ ...... u nowt ..
jIIIIlOrf:n.1HhfII .., ... .. tMIptIorl _ LI:

rlll .... Fl~.

I. ~U""'n.pls """"""
jiiMClkl..,..... I &~U....
!Fete .... .. t..-wlb.,..

Die oben dargestellte Bildschirmmaske erreicht man uber f01-

gende Schritte:
1.) Buro Q Opt.Archivierung Q Frithes Erfassen
2.) Auswahl Archivdemo (Auswahl einer Voreinstellung von
Dokumentenarten aus einem Menu)
3.) Auswahl der Dokumentenart "iXOS Eingehende Rechnung"
aus der Liste der im Customizing definierten Dokumentenar-
ten.
Dargestellt ist eine Szene des Erfassens in einer Poststelle. Ein
Origina1beleg wurde mit einem Archivsystem erfaBt und wird am
Bildschirm angezeigt, urn die weitere Verarbeitung festzu1egen.
Mit der Office-Komponente erf01gt die Zuordnung des Origina1-
dokuments zum entspechenden SAP-Dokumententyp. Der vom
System vorgesch1agene Bearbeiter kann abgeandert und eine
Notiz hinzugefugt werden. Nach dem Bestatigen der Eingaben
mit "Weiter" wird das entsprechende Workflow-Objekt erzeugt
und in den Office-Eingang des entsprechenden Sachbearbeiters
gestellt.

123
4 Vorgangsverarbeitung im System !JAP-R/3

Das Ereignis "Rechnung ist in Buroeingang gestellt" ist einge-

treten (siehe auch hierzu: Abb. 4.3.1 Ereignisgesteuerte ProzeB-
kette)
Bild 4.3.3
BOroeingang mil ein- 1-1
Q.tumltftt Moll
EIog_BAH...... NE
[IooU...... 811'11 S)<oIoOl
III""
.. I
gegangenem liPlIlIIl'.
I[!] o I¢'I 0 Ixl IQJ!J 1-'-1- '-1
Bu"~he.

--
Workflow-Objekl 0
IAn..lgo.II ____ 11 vOrorkll.. 11WI.4....d ....·_11 EI·.··. II"""'-.11 Pen.~ IIAIlI. "".... 1
Typ Dobae .....
!:J IiilllllU... _ _ 11£_ DE" ,•
Gt IE. EE VNWVEX
.
• ,, •
F ...... 10.1......
r Iiil llllUS _ _.-.-1_ 10 .... . ..
r Iiil 11m. II£I ...............SIIIC lic- •• , •
r
r
Iiil
Iiil
I£i .. n ......L£XP()ISI'.
II18s ..._.-.-1_ ~-
~ • 1
••
r Iiil 111<0$ 1E1 ..............._
~- • 1
•

I SkHwedt.... I EI..... ~I •
DCI2(U)
.
hs9012 OVR 16,4]

Damit erfolgt ein Wechsel der Perspektive, die Bildschirmmas-

ken stellen nun den Arbeitsplatz eines Sachbearbeiters dar. Der
Sachbearbeiter wird von der Existenz eines Vorgangs in Kenntnis
gesetzt. Er kann den Vorgang nun sichten und bearbeiten.

1m Beispiel markiert der Sachbearbeiter den Vorgang in seinem

Office Eingang und wahlt " Verarbeiten "; dadurch wird der Vie-
wer gestartet und der Originalbeleg tiber die ArchiveLink-
Schnittstelle angezeigt:

124
 4.3 Beispiel fur dokumentenbasierten Workflow

Originalbeleg anzeigen:

Abb.4.3.4
Originalbeleg-/
Auswahlbildschirm
-- - .......
""" m
r-------'
-...,.

!!I
I~AEa.uNODE"'f.DOlC

IIiJ [J~~~ .... - - -. -.I

.
....
111, ,..-
"'-J [- ...J [-~I-J [[-J [-J[""'-JI .......... I
fiiL IIUS
r -
~
GL IE.

··.·
f:f: vw WVEX

·••• ·
[ltCllWJM IlCIIIMI • • , .. . . .
I'iLr IUS . . . . . . . '~I ... ~.
r rwr ' lies HnUtlTE. . .aSIMI ~.
r ~ Jii •• lllMllUlPIMISU ~. 1
r fiiR IllleS .......u~I.JiI ~. 1
r IWL IIUS KISEln" • • Ilw. ~. 1

~' E::~
2.Weh" o..-c....

;~
lu.s l'l ........ . IIC. . . . . . I
~
I!!!i!!!!"", 1........ 11 ,"......·11-..1 1- - 11--1
I'~ I-

... -- ---
E_ .
-
r.---,
•
002 "'IOU ~lS:6

Der Originalbeleg wird angezeigt, und ein Auswahlbildschirm

mit mehreren Optionen erscheint. Der Bearbeiter kann den an-
gezeigten Originalbeleg nun priifen und gegebenenfalls den
Vorgang an einen anderen Bearbeiter weiterleiten, den Original-
beleg einem anderen Vorgang zuordnen, einen weiteren Vor-
gang, der mit dem Originalbeleg verbunden ist, anlegen oder die
Bearbeitung abbrechen. In der Regel wird der Bearbeiter den
Beleg bearbeiten wollen und wahlt " Verarbeiten".

Danach erfolgt Start der Transaktion zur Verarbeitung:

125
4 Vorgangsverarbeitung im System SAP-R/3

Abb. 4.3.5
Transaktion zur Ver-
arbeitung einer ein-
gehenden Rechnung

Die zur Verarbeitung benbtigte Transaktion wird vom System

gestartet. Der Sachbearbeiter fuhrt die Buchung durch, wobei er
die Daten vom angezeigten Originalbeleg ubernimmt.

Beenden des Vorgangs:

Abb.4.3.6
Schritte nach
der Verarbeitung
~

o.t.:,~
.. 8e.~. lUI ~

~~
•
-
w,.11....
•••~
• til-.:

T. . _
M . . . ., GLAE.IEENWVElC
,. IWi' IIXOS (I . . .OM IKe:. . . . KIll r .. .... ~a ,.
r fiii'
Ilxn lnOtI..csaHSC_"KM ~I 1.
,. ~ I IUS .[lA.. .n~u~ ~.
r fiii' iii MITlew:UlKMSU ~. t.
r ~ I IUS 8£W:. ._YMlC.-£IKJI

r fiil 1111S UIK:l"'ii=:;:;;::;:::7:.~z-j~,="=o=.",=.=••=,,,,:;:;:::;;;:===-

I pus .1 . . . . . . . . . .~ ..... l . . .'t:

- .
SIcM-a. ... ,...... r.-I
8Nol!1C1OOOO11J . . . . 1m tklWMIOI ;ID

126
 4.3 Beispiel fur dokumentenbasierten Workflow

Nach der Buchung erscheint ein Auswahlbildschirm. Hier besteht

nochrnals die Moglichkeit, den Vorgang weiterzuleiten oder ei-
nen weiteren Vorgang zu starten. 1m Beispiel wahlt der Bearbei-
ter " Vorgang ist erledigt".

Behandlung des erledigten Vorgangs:

Abb.4.3.6
Weilere Behandlung
des Vorgangs
TV' OMwn~1
r IWl Ilxts £liC E"'" IEt_. K_ r ..... .
fWL lutts 11II1(IIIlCUfG( "UI(M
r fiil IIUS II(ISUflrO£lnullfC
r Iiil Ii••• I IIMtlU' OSn
r ~ nun .Uil ( .....S.IG~[I.["
r IWI AkIIM MI-""""t.

I"w •..., 'a [1II,MI, Usc ....

Ein erledigter Vorgang kann entweder im Office-Eingang gehal-

ten werden, z.B. urn in einer Mappe abgelegt zu werden, oder er
kann als letzter Schritt der Vorgangsverarbeitung aus dem Ein-
gang geloscht werden.

127
4 Vorgangsverarbeitung im System SAP-R/3

Notizfunktion:

Abb. 4.3.7 .- - ~.

-[--
S~JKJEAEa..lllQDEYDf.DOQ.l

Originaldokument mit
Notizen
VI·
140; . ,
li.n.1 1141~
. 15.11.1*
-- .~

I- I , I
I.-I , I
, I
~
~w±=_!:::;'=':,=
..=_::;;=....:::;;_:;.~.
1 I
1 I
1 I

-
===-
-
=

1 .
[»f
.
hdIIU CNR. ll!e

Dariiber hinaus konnen erfaBte Originaldokumente durch den

integrierten Notizeditor mit Nachrichten und Anmerkungen ver-
sehen werden. Erstellte und gespeicherte Notizen konnen nicht
geloscht werden, wodurch eine konsistente Dokumentation ge-
sichert wird.

4.4 Optimierung von Geschaftsprozessen

4.4.1 Verarbeitung der Originalbelege

Neben der Optimierung des Ablaufs bei der Vorgangsbearbei-
tung bietet auch die eigentliche Verarbeitung der Originalbelege
durch einen Sachbearbeiter Potential zur Verbesserung.

128
 4.4 Optimiernng von Geschd!tsprozessen

Beim Verarbeiten eines Dokuments - d.h. die Funktionalitat

"Verarbeiten" wird yom Sachbearbeiter wahrend des Pro-
grammablaufs gewahlt - wird die mit dem Dokumenttyp ver-
kni.ipfte Transaktion aufgerufen. Die gewi.inschten Transaktionen
erfordern aIlerdings noch recht umfangreiche Eingaben durch
den Anwender.
Durch eine Vorsortiemng der zu verarbeitenden Dokumente
kann eine gewisse Vereinfachung der Eingaben erreicht werden
(mit der Funktion ,pallen"). Da zu einer Vorsortierung zuerst
aIle Vorgange (Dokumente) im Eingangskorb gesichtet werden
mi.iBten, ist es sinnvoll, ein soIches Verfahren zu wahlen. Die
Zeit zum Sichten wi.irde die eingesparte Zeit beim Verarbeiten
aufwiegen.
Denkbar ware es, fur bestimmte eingehende Dokumente einen
eigenen speziellen Dokumenttyp zu definieren, der dann mit ei-
ner Transaktion verkni.ipft wird, die schon entsprechende Vor-
einstellungen besitzt (z.B. Buchungskreis, Geschaftsjahr), die
somit nicht immer wieder neu eingegeben werden mi.issen.
Diese Mbglichkeit ist besonders dann sinnvoll, wenn ein Unter-
nehmen eine vie1zahl gleichartiger Eingangsbelege zu verarbei-
ten hat.
In einer Analyse kbnnen die wichtigsten wiederkehrenden Ein-
gangsbe1ege identifiziert werden. Fi.ir diese Eingangsbe1ege kann
anschlieBend die urspri.ingliche Dokumentenart durch eine spe-
zielle Dokumentenart (Zuordnung erfolgt: Eingangsbe/eg Q Do-
kumentenart, Dokumentenart Q Transaktion) ersetzt werden.
Diese wird mit einer spezifischen Transaktion verkni.ipft, die der
urspri.inglichen ahnlich ist, aber gewisse Voreinstellungen besitzt.

4.4.2 Szenario: Automatische Postverteilung von erfaBten

Originalbelegen

Beispiel fUr die Op- In einem grbBeren Unternehmen sollen eingehende Rechnungen
timierungs- an den jeweils zustandigen Sachbearbeiter weitergeleitet werden.
moglichkeiten bei Die Zusrandigkeit hangt yom Wirtschaftsgut ab, das geliefert
Verarbeitung von wurde. Fi.ir dieses Szenario wird "Frnhes Etfassen" eingesetzt,
Originalbelegen
d.h. in einer zentralen Poststelle werden die Originaldokumente
erfaBt und als Workflowobjekte (Originalbild mit zugeordneter
Transaktion zur Verarbeitung) weitergeleitet.

129
4 Vorgangsverarbeitung im System SAP-R/3

Beirn zustandigen Sachbearbeiter erscheinen die Workflow-Ob-

jekte in seinern elektronischen Posteingang.
Wenn es sich bei dern zu erfassenden Dokurnent urn eine Ein-
gangsrechnung handelt, wahlt der Bearbeiter in der Poststelle
die Voreinstellung "Eingangsrechnungen nach Sparten U.

Zuordnung der SAP·Dokumentart zum Originaldokument:

Abb.4.4.1
Zuordnung der 00-
kumentenart
.
I£1ll -
F. . . 1:"'••..: E

I'mJ [~J
••.ca

. . . . . . . . . . . . ~ . . . . .aQMInI . . . . . . . . .

....... Ii"
•• _ ~I r-
..... JOt.,....... ~ •. - •.- k trl .n:st. I
S r=:t=J 1"""""'............ 1

Aus der Liste wahlt der Bearbeiter die der Originalrechnung ent-
sprechende Dokurnentenart aus, und es erscheint ein Fenster, in
dern - neben anderen Vorgaben - der voreingestellte Bearbeiter
fur den entsprechenden Rechnungstyp eingetragen ist. Die rnbg-
lichen Auswahlfelder kbnnen wie folgt gefullt werden:
CJ Prioritdt: Die Vorgangsprioritat kann angegeben werden.

CJ Notizfunktion: Der Vorgang kann mit einer Notiz versehen

werden, die den Vorgang genauer beschreibt.

130
 4.4 Optimiernng von Geschiijtsprozessen

Vorgehensweise zur Definition dieser Voreinstellungen

Urn das dargestellte Beispiel zu realisieren, sind vier Schritte er-
forderlich:
1.) Dokumentenarten global definieren
2.) Dokumentenarten NCI12 (Non Coded Information) definie-
ren
3.) Verknilpfungen definieren
4.) Neue Voreinstellung erzeugen
In den Schritten 1.), 2.) und 3.) werden die Dokumentenarten
erzeugt und die Einstellungen fur das Archiv vorgenommen.

Abb. 4.4.2
Dokumentenarten fOr
verschiedene Ein-
gangsrech-
nungen

Dargestellt sind die im Customizing neu erzeugten Dokumenten-

arten.

12 NCi-Dokumente enthalten Pixeldarstellungen von informationen, wie man

sie beim Einscannen von Originaldokumenten erhalt oder wie sie beim
Empfang von FAX-Nachrichten anfallen.

131
4 Vorgangsverarbeitung im System SAP-R/3

4.4.3 Voreinstellungen fur das "Fruhe Erfassen"

Wird eine neue Voreinstellung erzeugt, kann aus dem angezeig-
ten Menu Csiehe Abb. 4.4.3) eine existierende Voreinstellung
gewahlt und unter anderem Namen gesichert werden oder durch
die Auswahl "Abbruch" und anschlieBendem "Anlegen" eine
Voreinstellung vollstandig neu erzeugt werden.
Die Obernahme der Dokumentenarten aus der Gesamtliste der
existierenden Dokumentenarten fur die neue Voreinstellung er-
folgt durch Auswahl aus einem Menu, das wie folgt erreicht
wird:
Werkzeuge ~ Administration ~ Verwaltung ~ Vorgangstechnik
~ Optisches Archiv ~ Frnhes Eifassen

oder uber Transaktion " \SOA3":

Abb.4.4.3
-- "' . -..... -- ,. ~-.: ..,

-- .-
~ ~ ~J SJI) [ JIII[ J
Zur Verfiigung ste-
1- 11- ..... 1
hende
Dokumentenarten

"'-Z . . . . . ~

ifiiiMi'U1C.... ..., a.c........, . .

1<_-
I . ... I
~ IK . . . . I .· M.- "t.rb."At.
j[1........ 1Irc. . . . . .illlllltltrllll
ti_

~1 ...... t1. .
~tr_t
~tF_t~

,.....,.._ .......,...
~U.""'l_
jit;liftlb'-'l~'"

11...... 1,..,.
II-.... '.tdl .........
jIlea. . . • ten...
~"f5HJ'"

~re<3 E?J

..., ,,,,
""
Die Dokumentenarten "Eingehende Rechnung R.-H.- Betriebsst. '~
"Eingehende Rechnung Buromaterial" und "Eingehende Rech-
nung Speditionen " werden mit Doppelklick markiert und uber-
nommen.

132
 4.5 Bewertung des Workflows in SAP-R/3

4.5 Bewertung des Workflows in SAp·Rl3

Das System SAP-R/3 (ReI. 2.1F/2.2A) ermoglicht die durchgangi-
ge Bearbeitung von Geschaftsprozessen und stellt Mittel zur au-
tomatisierten Vorgangsverarbeitung zur Verfugung. Es laBt sich
in vier Hauptbereiche gliedem:
1.) dokumentenbasierter Workflow
2.) Nachrichtensteuerung
3.) EDI (Auslosen von Vorgangen durch den Eingang von
elektronischen Dokumenten)
4.) Adhoc Workflow
Routing Fur die verschiedenen Bereiche gibt es unterschiedlich starke
Methoden zur automatisierten Bearbeitung. Fur den dokumen-
tenbasierten Workflow werden Minel angeboten, mit denen
Originaldokumente erfaBt und bearbeitet werden konnen. Es
konnen allerdings nur Vorgange definiert werden, die eine ge-
ringe Komplexitat aufweisen. In dem FaIle, daB ein eingehendes
Dokument nur einen Bearbeitungsschrin (neben dem Erfassen
und Versenden) durchlaufen muB, reicht die angebotene Funk-
tionalitat aus. Man konnte die Vorgangsverarbeitung in diesem
Bereich auch als Routing mit automatischem Applikations-
start bezeichnen.
Die Behandlung von Vorgangen zur Laufzeit ist komfortabel. Die
Werkzeuge zum Erzeugen von Vorgangen, durch Erfassen uber
die Buro-Komponente sowie zum Weiterleiten (Versenden) sind
fur den Anwender einfach zu bedienen. Es existieren auBerdem
Funktionen, urn Vorgange in der Ablage zu halten (urn spater
ohne langes Suchen darauf zugreifen zu konnen) oder sie auto-
matisch wiedervorzulegen.
tIber SAP-Office kann ein Vertreter angegeben werden, an den
im FaIle der Abwesenheit neben der Office-Mail auch Vorgange
weitergeleitet werden. Der Anwender kann zu einem Vorgang
verschiedene Statusinformationen abrufen, z.B. das Datum und
die Zeit der letzten Bearbeitung. Ein Mechanismus zur Vergabe
und Kontrolle von Bearbeitungsfristen existiert jedoch
nicht.

133
4 Vorgangsverarbeitung im System SAP-R/3

Es existieren keine Kollen oder Gruppen; deshalb kann ein

Vorgang sowohl beim Erfassen als auch beim Weiterleiten nur
an einzelne Personen gesandt werden. Der Anwender kann zu
einem Vorgang verschiedene Statusinformationen abrufen, z.B.
das Datum und die Zeit der letzten Bearbeitung.
Transportzeiten fUr Die Vorgangsverarbeitung ist so in das System integriert, daB der
Papierdokumente Anwender (Bearbeiter) in seiner Tatigkeit unterstutzt wird und
werden minimiert mit ihr ohne langen Schulungsaufwand arbeiten kann.
Transportzeiten fUr Papierdokumente werden minimiert.
Die Integration des Dokumentenverwaltungssystems ist ebenfalls
kornfortabel gelbst; denn bei Vorgangen, denen Originale zu-
grunde liegen, kbnnen diese jederzeit aus der Anwendung her-
aus aufgerufen werden.
systeminterner Ein- Vorgange mussen von einem Administrator definiert werden;
fiihrungsleitfaden d .h. fur eingehende Originaldokumente mussen Dokumenten-
reicht nicht aus arten geschaffen werden, die mit einem Vorgangstyp verknupft
werden. Diese Einstellungen werden im Customizing des SAP-
Systems gepflegt. Die Einarbeitung in diesen Bereich des Cu-
stomizing und das damit verbundene Verstehen der Zusammen-
hange erfordern einen groSen zeitlichen Aufwand. Es ist not-
wendig, daB eine weiterreichende Dokumentation, als sie derzeit
dem "normalen" Anwender zuganglich ist, geschaffen wird. Auch
der systeminterne Einfiihmngsleitfaden reicht hierfiir nicht
aus.
kein grafischer Editor Ein groBer Nachteil ist, daB sich Vorgange im aktuellen Release-
stand des SAP-Systems nlcht mit einem graflschen Editor, wie
er in Programmen zur Erstellung von FluBdiagrammen verwen-
det wird, sondern nur fiber aufbereitete Tabellen pflegen las-
sen.
Nach der Einarbeitungsphase lassen sich neue Dokumenten-
arten, neue oder abgewandelte Vorgangstypen und Einstellun-
gen fur das Erfassen mit relativ geringem Aufwand durchfuhren.
Derzeit gibt es nur sehr wenige groBe Unternehmen, die opti-
sche Archivierung im Produktivbetrieb einsetzen. Die Tendenz
zum Einsatz von optischer Archivierung ist aber stark stei-
gend; dadurch wird auch die Bedeutung des dokumentenbasier-
ten Workflow in SAP-R/3 entsprechend steigen. Urn die Vor-
gangsverarbeitung einsetzen zu kbnnen, sind allerdings auch
organisatorische Umstrukurlerungen erforderlich. FUr den
dokumentenbasierten Workflow bedeutet dies beispielsweise
Durchfuhrung einer zentralen Erfassung.

134
 4.5 Bewertung des Workjlows in SAP-R/3

Nachrichten- Die Nachrichtensteuerung ist im Umfeld der Vorgangsverarbei-

steuerung tung ebenfalls von Bedeutung, da sie es erm6glicht, auf be-
stimmte Zustande, d.h. bestimmte Datenkonstellationen, zu rea-
gieren. Output in Form einer Office-Mail als Druckausgabe oder
auf anderen Medien kann automatisch erzeugt werden. Obwohl
die Nachrichtensteuerung nicht als Vorgangsverarbeitungssystem
betrachtet werden kann, da sie nicht komplette Vorgange um-
fagt, sondern immer nur einzelne Teilschritte eines Vorgangs
betrachtet, stellt die Nachrichtensteuerung ein machtiges Instru-
mentarium dar, und sie unterstiltzt die Bearbeitung von Vorgan-
gen.
Electronic Data In- Electronic Data Interchange (EDI) ist eine weitere Komponen-
terchange (EDI) te im umfeld der Vorgangsverarbeitung in Rl3. Eingehende
elektronische Nachrichten 16sen ahnlich wie beim Erfassen eines
Originalbelegs Vorgange aus. Filr diese Vorgange existieren eine
Vielzahl von Funktionsbausteinen, die eine weitgehend au-
tomatisierte Bearbeitung dieser Vorgange erm6glichen, z.B. im
Bestellungseingang. Der Anwender ist von diesen Vorgangen
nur am Rande betroffen.
Office-Komponente Das SAP-System besitzt mit der Office-Komponente Werkzeu-
ge, die als ,,Adhoc Workflow" bezeichnet werden k6nnen. Dabei
werden auch einige Features von Workgroup-Programmen an-
geboten. Die Office-Komponente besitzt eine durchaus gute
Funktionalitiit.
Das SAP-System bietet einige sehr machtige Werkzeuge zur ein-
facheren, effizienteren und korrekteren Bearbeitung von Ge-
schaftsprozessen.
Die Methoden sind allerdings nicht in einem Mage integriert,
und die Bearbeitung ist nicht so stark automatisiert, dag man
von einem Vorgangssteuerungssystem sprechen k6nnte.

135
5 Ausblick: SAP Business Workflow

5 Ausblick: SAP Business Workflow

Die Vorgangsverarbeitung in der Version 3.0 wurde hinsichtlich

Laufzeitsystem, Informationssystem und Definitionswerkzeugen
wesentlich erweitert und verbessert. SAP tragt mit der Weiter-
entwicklung des Workflows der wachsenden Bedeutung dieser
Thematik Rechnung. Der Workflow in Version 3.0 ist grundsatz-
lich verschieden yom Workflow in den vorhergehenden Versio-
nen, wobei die mit den bisherigen Mitteln realisierten Workflows
weiterhin unterstiitzt werden.
In der Version 3.0 stehen - ab ca. Herbst '95 - folgende Schritte
und KontrolltluSelemente zur Steuerung von Geschaftspro-
zessen zur Verftigung: 13
(J Aktivitiiten
Eine Aktivitat beinhaltet die Ausftihrung einer Objektme-
thode. Dadurch werden implizit ein Transaktionsaufruf, der
Aufruf eines Funktionsbausteins, aber auch manuelle Aktio-
nen wie das Anrufen eines Kunden oder die Textverarbei-
tung mit PC-Software realisiert. Diese Aktivitaten werden
aIle yom Workflow-System gesteuert. Die Ausftihrung von
externen Aktivitaten (Beispiel: TelefonanruD muB nach der
Erledigung dem System zUri.ickgemeldet werden.

(J Subworkflows
Mehrere einzelne Workflow-Schritte konnen zu einem Sub-
workflow zusammengefaBt werden, der bei weiteren
Workflow-Definitionen wiederverwendet werden kann.

(J Warteschritt
Die Definition eines Warteschrittes ermoglicht es, die Bear-
beitung eines Vorgangs anzuhalten, bis ein definiertes Er-
eignis eingetreten ist. Abhangig von Bedingungen konnen
Verzweigungen definiert werden.

13 vgl. Berthold, A.: SAP Business Workflow 3.0. How to get started - Defini-
tionswerkzeuge, SAP AG [Hrsg.J, S. 5

136
 5 Ausblick: SAP Business Workflow

Q TenmWnuberwachung
Fur einen Verarbeitungsschritt kann eine bestimmte maxi-
male Bearbeitungszeit, innerhalb derer der Schritt abge-
schloss en sein muB, angegeben werden. Wird diese Bear-
beitungszeit uberschritten, so wird eine definierte Aktion
angestoBen (z.B. die Benachrichtigung des Vorgesetzten).
Q Mehrfachbedingung
Die Mehrfachbedingung ist eines der Mittel zur dynami-
schen Behandlung von Geschaftsprozessen, in Abhangigkeit
von der Datenkonstellation zur Laufzeit. Die Mehrfachbe-
dingung ist mit einer programmiertechnischen CASE-
Struktur vergleichbar.
Q Konttollkonunando
Q Ereigniserzeuger
Dies ist ein Schritt im Verlauf der Vorgangsverarbeitung, in
dem ein neues Ereignis explizit erzeugt wird.
Q Manuelle Entscheidung
Hier wird der weitere Verlauf der Vorgangsverarbeitung
durch eine Interaktion mit dem Anwender entschieden oder
beeinfiuBt. Mbgliche Eingaben kbnnen eine Auswahl der
weiteren Verarbeitung betreffen. Anderungen von Termi-
nen, Prioritaten und Zustandigkeiten sind Administratorauf-
gaben!
objektorienlierter Dem neuen System liegt ein objektorientierter Ansatz zugrun-
Ansalz de. Damit ist es mbglich, Informationen als Objekte, die Attribute
(Eigenschaften) besitzen, darzustellen. Auf die Objekte werden
Methoden definiert, mit denen Zugriffe und Operationen ermbg-
licht werden. Objekte kbnnen Elemente des SAP-Systems sein
(Rechnungsbelege, archivierte Dokumente, Materialdaten), aber
auch aus der PC-Umgebung stammen (OLE-Elemente, Word-
Texte, Excel-Spreadsheets).
HR-Organisa- Die auf die Objekte definierten Methoden stellen elementare
lionsmodeli Aufgaben dar, die als Tatigkeiten ausgefuhrt werden. Eine Auf-
gabe urnfaBt typischerweise eine Transaktion; sie ist immer mit
einer Planstelle, einem zustandigen Bearbeiter oder einer Rolle,
die im HR-Organisationsmodell definiert ist, verknupft. Damit
wird die Verantwortung fur die Bearbeitung einer Aufgabe fest-
gelegt.

137
5 Ausblick: SAP Business Workflow

Durch die Verkniipfung von Aufgaben, die als Methoden auf

Objekte definiert sind, mit dem HR-OrganisationsmodeIl ist es in
jedem FaIle erforderlich, diese Komponente des SAP-Systems fur
den Einsatz von Vorgangsverarbeitung zu implementieren.

Abb.5.1
Zusammenhang von
Objekten, Aufgaben
und Zustandigkeit
::rr:::: ........
'i}.... I&"~: :
::::::::::::::::::::::::::: ::::::::::::::::
!halt€. ::
:::::::: .. !a'-
.. ::::::::
~ ",,:

Beim Kauf eines SAP-Systems werden elmge Objekte mitge-

liefert. Der Anwender kann selbst weitere Objekte definieren
oder die mitgelieferten Objekte seinen Bediirfnissen anpassen.
Die Pfiege der Zuordnung von Aufgaben zum HR-Organisations-
model! ist in jedem Fal!e erforderlich.
Container AIle Definitions- und Ausfiihrungskomponenten basieren auf ei-
ner gemeinsamen Datenstruktur, die als Container bezeichnet
wird. Diese einheitliche Datenstruktur ermoglicht es, Informatio-
nen zwischen den einzelnen Komponenten des WF-Systems
sowie ZWischen dem WF-System und SAP-Anwendungen auszu-
tauschen und zu transportieren.
Rollen Vorgangen konnen bei der Definition einer Aufgabe Rollen zu-
geordnet werden (z.B. Kundensachbearbeiter). Ein beliebiger
Bearbeiter, der dieser Rolle zugeteilt wurde, kann diese Aufgabe
bearbeiten. Der zustandige Bearbeiter wird erst zur Bearbei-
tungszeit des Vorgangs ermittelt. Damit ist gewahrleistet, daB der
Bearbeiter verfugbar ist. Mit dies em Verfahren ist das Problem
der Vertretung und Nachfolge im FaIle von Abwesenheit eben-
falls gelost.

138
 5 Ausblick: SAP Business Worliflow

Ereignisse Als Reaktion auf ein Ereignis konnen Workflows gestartet wer-
den. Fur jedes Ereignis muB ein Ereignistyp definiert sein. Es
stehen vordefinierte Ereignistypen zur Verfiigung, sie konnen
aber auch selbst definiert werden. Uber Ereignisse wird eine
Kopplung zwischen verschiedenen Anwendungen ermoglicht,
indem Daten von der erzeugenden zur verbrauchenden Anwen-
dung transportiert werden.
Ereigniserzeugung Die Ereignisse werden in den einzelnen SAP-Anwendungs-
programmen ausgelost, d.h. das Auslosen eines Ereignisses wird
dort direkt hineinprogrammiert. Dies hat den Vorteil, daB eine
volle Integration von Anwendungsprogramm und Vorgangsver-
arbeitung besteht. Allerdings kann es bei einem Releasewechsel
zu Problemen fuhren, wenn Anwender die Auslosung eines Er-
eignisses in ein Anwendungsprogramm hineinprogrammieren, da
diese dann nachgezogen werden mtissen.
Ereignisverbrauch Ereignisse haben einen Erzeuger und einen oder mehrere Ver-
braucher, z.B. Vorgange, die aktiviert werden (Funktions-
baustein). Wird ein Ereignis erzeugt, so wird tiberpriift, ob zu
dies em Zeitpunkt ein Verbraucher existiert. Falls mehrere Ver-
braucher existieren, werden diese aIle aktiviert. Ereignisse mus-
sen zum Zeitpunkt ihrer Entstehung verbraucht werden; sie kon-
nen nicht auf eine spatere Verarbeitung warten. Gibt es zu ei-
nem Ereignis keinen Verbraucher, so wird es geloscht.
Ein GeschaftsprozeB wird durch eine Folge von Aktivitaten ab-
gebildet. Die Aktivitaten konnen durch Schritte wie Bedingun-
gen, Kontrollkommandos, manuelle Entscheidung, Ereigniser-
zeuger u.a. miteinander verbunden sein.
Eine Aktivitat enthalt als wichtigste Information die Referenz auf
die Aufgabe (d.h. die eigentliche Tatigkeit), aber auch Angaben
tiber die Rolle, Termine und Verantwortung bei Nichtededigung.
Workflow-Definition Hier findet die eigentliche Abbildung und Modellierung von Ge-
schaftsprozessen statt. Es steht ein Workflow-Editor zur Verfii-
gung, mit dem die Struktur eines Vorgangs in Form eines
Baumdiagramms, aber auch in grafischer Form als FluBdiagramm
entwickelt oder dargestellt werden kann.

139
5 Ausblick: SAP Business Workflow

Mit den gegebenen KontrollfluBelementen ist es mbglich, Vor-

gange zu definieren, in deren Verlauf mehrere Tatigkeiten paral-
lel bearbeitet werden oder die in Abhangigkeit von Zustanden
verschiedene Bearbeitungswege durchlaufen. Bei derartig aufge-
spalteten Vorgangen werden die einzelnen Pfade aber trotzdem
wieder auf einen gemeinsamen pfad zusammengefiihrt, urn die
Beendigung des Vorgangs zu ermbglichen.
Workflow zur Laulzeit Das zentrale Element der Workflow-Ausfiihrung zur Laufzeit ist
der Workitem-Manager. Ein Vorgang setzt sich aus einer Foige
von Workitems zusammen. Der Workitem-Manager veIWaltet
Eskalation diese und fiihrt dabei TerminubeIWachung mit Eskalation
durch; hierbei tritt er als Ereignisverbraucher auf. Eskalation be-
deutet, daB Workitems deren Bearbeitungsfrist nicht eingehalten
wird, eine spezielle Behandlung erfahren, ublicheIWeise Delega-
tion an einen Vorgesetzten. AuBerdem kann der Workitem-
Manager Hintergrundprozesse starten, und er veIWaltet die
Worklist. Die Worklist ist mit einem Gruppenpostkorb ver-
gleichbar und enthalt, optisch aufbereitet, die einzelnen Work-
items. Zu bearbeitende Vorgange werden darin angezeigt, wobei
individuelle Such- und Sortierkriterien angegeben werden kbn-
nen. Der Bearbeiter kann aus der Worklist Vorgange zur Bear-
beitung auswahlen.
Statuskontrolle Es soll Funktionen zur Statuskontrolle von Workflows geben.
Zum gegenwartigen Zeitpunkt ist unklar, wie detailliert diese
Funktionalitat sein wird. Denkbar sind Abfragen, wie "In wel-
chern Status der Bearbeitung befindet sich ein Objekt gerade?",
" Welcher Bearbeiter hat welche Vorgiinge zu erledigen?" oder ein
Protokoll zur Abarbeitung eines Vorgangs.
Beispiel Das folgende Beispiel zeigt abschlieBend den Zusammenhang
der verschiedenen Komponenten der Vorgangsverarbeitung in
Version 3.0 mit Darstellung von Ereigniserzeugern und Verbrau-
chern am Beispiel eines eingehenden Originalbeleges: 14

14 vgl. Berthold, A.: SAP-Business-Workflow. How to get started - Definitions-

werkze uge 3.0, Vers 1.6, SAP AG IHrsg.l, S. 12

140
 5 Ausblick: SAP Business Workflow

Abb. 5.2
Vorgangsverar-
beitung in SAP-Rl3, Emruger Verb'raIllclcheJ
Vers. 3.0

SAP Business Workflow 3.0 stellt im Vergleich zu fruheren Re-

leases ein wesentlich verbessertes Vorgangsverarbeitungs-
system dar. Es wurde vollstandig neu entwickelt und besitzt ei-
ne Funktionalitat, die mit dem Umfang der reinen Workflow-
Tools vergleichbar ist. Die zugrundeliegende objektorientierte
Methodologie ist sehr sorgfaltig ausgearbeitet und entspricht dem
derzeitigen Entwicklungsstand der Workflow-Technologie.
Mit dem Workflow k6nnen nun auch komplexe Geschaftspro-
zesse modelliert und abgearbeitet werden, da nun aIle wesentli-
chen KontroIlfluBelemente zur Verfugung stehen.

141
6 5cb IUfSbetracb tung

6 SchluBbetrachtung
Workflow- Die Entwicklung auf dem Markt fur Vorgangsverarbeitungssyte-
Management- me ist bei weitem noch nicht abgeschlossen. Die Hersteller ver-
Coalition (WMC)
folgen verschiedene Ausrichtungen und Ansatze. Um die Ent-
wicklung von Workflow-Software zu koordinieren und um Stan-
dards zu setzen, wurde die Worktlow-Management-CoaIition
CWMC) gegri.indet, deren Mitglieder sich aus den Entwicklern
und Anwendern dieser Software zusammensetzt. Von der WMC
gehen wichtige Initiativen zur Standardisierung derartiger Soft-
ware aus. Da es aber bei der Entwicklung der heutigen Produkte
noch keine Richtlinien gab und auBerdem die unterschiedliche
Herkunft der Anbieter und die damit verbundenen unterschiedli-
chen Ausrichtungen existieren, mussen Vorgangsverarbeitungs-
systeme differenziert und nach den an sie gestellten Anforderun-
gen betrachtet werden.
Es gibt Hersteller Csiehe hierzu Anlage: Worktlow Pro-
duktiibersicht), die bereits auf einige taus end verkaufte Lizen-
zen und namhafte Referenzen verweisen kbnnen. Vor allem im
internationalen Bereich gibt es bereits zahlreiche Installationen.
In Deutschland gibt es erst wenige Unternehmen, die ein Vor-
gangsverarbeitungssystem einsetzen; diese sind fast ausnahmlos
im Finanzdienstleistungsbereich angesiedelt. Durch die hohe
Strukturierbarkeit der Vorgange in diesem Sektor und gleichzeitig
bestehende hohe Investitionsbereitschaft scheint diese Sparte be-
sonders geeignet fur die Einfuhrung solcher Systeme.
Die heutigen Systeme sind relativ starr, d .h. eine dynamische
Behandlung von Vorgangen ist meist nicht mbglich. Die Behand-
lung von. Sonderfallen bereitet oft Schwierigkeiten oder ist mit
hohem administrativen Aufwand verbunden. Andererseits existie-
ren bereits Konzepte, die einfache Vorgange steuerbar machen
und vor allem effizient und schnell zuganglich sind. Es ist ab-
sehbar, daB in Zukunft funktionelle und leistungsfahige Pro-
gramme zur Verfugung stehen werden, die einen sehr groBen
Anteil der Anforderungen abdecken. Mit solchen Softwarelbsun-
gen lassen sich Kosten senken, und es werden erhebliche or-
ganisatorische Probleme bewaItigt. Der Arbeitsablauf und die
Arbeitsweise des einzelnen werden sich maBgeblich verandern.

142
 6 Scbluflbetracbtung

Qualifikation Dies stellt andere Anforderungen an die Qualiflkation eines

eines Sachbearbei- Sachbearbeiters, als dies bei dem traditionellen papierbegleiteten
ters
Bearbeiten eines Vorgangs der Fall ist.

Betrachtet man die klassischen Konzepte eines Vorgangsverar-

beitungssystems, so besitzt die VVS im SAP-System zum derzeiti-
gen Releasestand nur eine sehr eingeschrankte Funktionalitat.
Das SAP-System zeichnet sich dadurch aus, daB Gescbaftspro-
zesse integriert iiber mehrere Module und mehrere organisa-
torische Einheiten hinweg bearbeitet werden kbnnen. Mit dem
Mittel der Nachrichtensteuerung kbnnen weite Teilbereiche
bei der Bearbeitung eines Geschaftsprozesses automatisiert wer-
den. Fur die Behandlung von eingehenden elektronischen
Nachrichten steht ebenfalls Funktionalitat zur Verfugung. Ausge-
zeichnet sind die Bearbeitungsmbglichkeiten fur eingehende
Originaldokumente. Auf eine Bearbeitung eines Papierdoku-
ments kann vollstiindig verzichtet werden, da nach dem Er-
fassen des Papierdokuments dieses in elektronischer Form jeder-
zeit angezeigt und weitergereicht werden kann. Fur eingehende
Originaldokumente steht ein einstufiges Verarbeitungskonzept
zur Verfugung, wodurch automatisch die zur Verarbeitung benb-
tigte Transaktion aufgerufen wird. Fur die Zukunft wird es im
SAP-System eine durchgangige Vorgangsbearbeitung geben. Fur
diese Version werden auch urnfangreiche Entwicklungs- und
Administrationswerkzeuge zur Verfugung stehen.
Der Vorgangsverarbeitung in SAP-R/3 liegt ein anderes Konzept
zugrunde, als das der klassischen Workflow-Tools. Die Starke
dieser Tools liegt in der flexiblen Gestaltung von Gescbafts-
prozessen und Integration von externen Komponenten. Die
Starke des SAP Business Workflow liegt in der durchgangigen
Bearbeitung von Geschaftsprozessen, wobei diese zu einem ge-
ringeren Grade automatisiert sind als bei den klassischen Tools.
1m Release 3.0 des SAP-Systems wird es mbglich sein, diese Au-
tomatisierung durchzufuhren. Es ist zu erwarten, daB das System
dann eine weit bessere Funktionalitat und einen weit grbBeren
Nutzen besitzt als klassische Vorgangsverarbeitungssysteme und
die Vorgangsverarbeitung im jetzigen Releasestand. Die Starken
des SAP Business Workflows werden im objektorientierten
Ansatz, in der durchgangen Begriffsdefinition, den grafischen
Definitionswerkzeugen, KontrollfluBelementen, Administrations-
werkzeugen und in der hohen Integration liegen.

143
Literaturverzeich nis

Literaturverzeichn is

Bucher:
Chen, P. P.: The Entity-Relationship Model - Towards a Unified
View of Data, ACM Trans. on Database Systems, 1/1976,
Neuauflage in M. Stonebraker: Readings in Database Sy-
stems, Morgan Kaufmann, San Mateo, Kalifornien, USA,
1988
Gulbins, J./ Seyfried, M./ Strack-Zimmermann, H.: Elektroni-
sche Archivierungssysteme, Springer Verlag, Berlin-Hei-
delberg, 1993
Scheer, A.W.: Architektur integrierter Informationssysteme,
Springer verlag, Berlin-Heidelberg, 1994
Scheer, A.W.: Referenzmodelle industrieller Geschaftsprozesse,
4. Auflage, Springer Verlag, Berlin:Heidelberg, 1994

Zeitschriften:
AlC: Staffware - Die optimierte Lasung zur Beschleunigung von
Verwaltungsablaufen
Heilmann, H.: Workflow Management: Integration von Organi-
sation und Informationsverarbeitung, Heilmann, H. u .a.
[Hrsg.): HMD Handbuch der modernen Datenverarbeitung,
Band 176, Forkel Verlag, Heidelberg, 1994
Hsu, M./ Howard M.: Work-Flow and Legacy Systems. In: Byte,
July 1994, McGraw-Hill Inc., New York
May, T.: Know Your Workflow Tools. In: Byte, July 1994,
McGraw-Hill Inc., New York
Meinhardt, S.: Wege zur Geschaftsprozessoptimierung, SAPinfo,
SAP AG [Hrsg.J, Walldorf, Marz 1994
Wiedman, G./ Schafer M.: Imaging Trends. In: Office Manage-
ment, 11/1993, FBO-Fachverlag, Baden-Baden
Schulze, J.: Integrierte Vorgangsverarbeitung - aktueller denn je.
In: Office Management, 11/1993, FBO-Fachverlag, Baden-
Baden

144
 Literaturverzeichnis

Sonstige Quellen:
Berthold, A.: SAP Business Workflow 3.0 How to get started -
Definitionswerkzeuge, SAP AG [Hrsg.l, Walldorf, 199?
Gesellschaft fur integrierte Datenverarbeitungssysteme
mbH: ARIS [Hrsg.]: Einheit aus Theorie, Methodik, Werk-
zeug und Erfahrung, Business Reengineering mit dem
ARIS Toolset, Saarbrucken, 199?
Karl, R./ Deiters, W.: Stu die Workflow Management; Group-
ware Computing, dsk Beratungs-GmbH, Pfaffenhofen,
1994
iXOS Software GmbH [Hrsg.]: "Kurs Einsatz von Archivsyste-
men", Munchen, 199?
SAP AG [Hrsg.]: Dokumentation SAP Business Workflow 2.1,
Walldorf, 199?
SAP AG [Hrsg.]: Dokumentations-CD, Vers o 2.0, Walldorf
SAP AG [Hrsg.]: EinfUhrungsleitfaden und erweiterte Hilfe fur
R/3, ReI. 2.1F/ 2.2A, Walldorf, 1994
SAP AG [Hrsg.]: WF-Archivelink Schnittstelle zu optischen Archi-
ven, (SAP-Bestellnr.: 50006613), Walldorf, ]uli 1994
Tschira, K./Zencke, P.: Geschaftsprozessoptirnierung mit dem
SAP-System R/3, SAP AG [Hrsg.] : SAPinfo, Walldorf, 3/ 94

Weiterfiihrende Literatur:
Dinkhoff, G. u.a.: Business Process Modeling in the Workflow
Management Environment in Proceedings of the 13th In-
ternational Conference on the Entity-Relationship Ap-
proach, Manchester, (UK), Springer Verlag, 1994, S. 46 -63
Gruhn, v.: Communication Support in the Workflow Manage-
ment Environment in Connectivity ' 94 - Workflow Mana-
gement - Challenges, Paradigms and Products, Olden-
bourg verlag, 1994, S.187--200
Kirn, S. u.a.: Flexible Organisationen durch Workflow Manage-
ment? Oder: Zum Problem der Modellierung von Ge-
schaftsprozessen. In: Einfuhrung von CSCW-Systemen in
Organisationen, Tagungsband der D-CSCW 1994, Vieweg
verlag, 1994, S.13 -27

145
Anlage

Reinwald, B.: Workflow-Management in verteilten Systemen,

Teubner-verlag, 1993
SAP AG [Hrsg.]: Vortragsdokumentation zu SAP- Technologie-
Tage/Basis-Kongress, Walldorf, 1994

Workflow Produldubersicht
Die folgende Obersicht soli die wichtigsten Workflow-
Management Programme (hinsichtlich gegenwartiger Marktstel-
lung und Funktionalitat) mit den entsprechenden Herstellern
aufzeigen und dokumentiert gleichzeitig die bestehende Ange-
botsvielfalt:

AlC und Staffware: STAFFWARE

AIC Software und Consulting GmbH
Otto Vogler StraBe 5a
65843 Sulzbach/Ts

BULL: Flowpath
BULLAg
Theodor-Heuss-StraBe 60-66
51149 Kbln

COl: COl BusinessFlow

COl GmbH
IndustriestraBe 1-3
91074 Herzogenaurach

debis: Viewstar
debis Systemhaus GmbH
Fasanenweg 9
70771 Leinfelden Echterdingen

DEC: LinkWorks
Digital Equipment GbmH
HeidelbergerstraBe 5-7
68502 Viernheim

146
 Workflow Produktubersicht

FileNet: Visual Workflow

File Net GmbH
Dietrich Bonhoefer StraBe 4
61350 Bad Homburg

mM: FlowMark
IBM Deutschland Informationssysteme GmbH
LyonerstraBe 13a
60494 Frankfurt

kiihn &weyh: M/Workflow

kuhn & weyh Software GmbH
LinnestraBe 1-3
79110 Freiburg

Ley: COSA
Software Ley GmbH
VenloerstraBe 85
50259 Pulheim

llON:LEU
UNI TECH CENTER
UniversitatsstraBe 140
44799 Bochum

Olivetty: mIsys
Olivetti GmbH
Lyoner StraBe 34
60528 Frankfurt

SNI: WorkParty
Siemens-Nixdorf Informationssysteme AG
Lyoner StraBe 27
60528 Frankfurt

IABG: ProMInanD
Industrieanlagenbetriebsgesellschaft mbH
EinsteinstraBe 20
85503 Ottobrunn

147
Anlage

ICL: TeamOFFICE
leL Technology GmbH
Vogelsanger Weg 91
40470 Dusseldorf

UNISYS: Infolmage
Unisys Deutschland
Am Unisys Park1
65843 Sulzbach/TS

DIaLOGIKa: multiDESK
AlbertstraBe-Pascalschacht
66125 Saarbrucken/Dudweiler

WANG: OPEN/workflow
WANG Deutschland GmbH
Martin-Behaim-StraBe 22
63263 Neu-Isenburg

148
Optische Archivierung und Dokument-
Management in SAP-Rl3

JOrgen Gulbins

Fa. iXOS Software GmbH, Grasbrunn (bei MOnchen)

149
1 Vberblick

1 Oberblick

Sowohl im kommerziellen Rl3-Umfeld als auch dort, wo Rl3-

Systeme Schnittstellen zu technischen Anwendungen wie PPS,
CAD und ahnlichen Feldern besitzen, fallt eine immer gr6Ber
werdende Anzahl von Belegen und Dokumenten an, die bisher
fast ausschlieBlich als Papier vorliegen. Sie mtissen vielfach aus
betriebswirtschaftlichen oder steuerrechtlichen Grunden, fur
Qualitatsnachweise oder ganz pragmatisch aus anderen Grunden
der Betriebsftihrung tiber iangere Zeit aufbewahrt werden.
Die Ablage, die Organisation sowie der Zugriff auf solche Pa-
pierdokumente wird bei groBer Anzahl aufwendig hinsichtlich:
• Raum- und Lagerkosten,
• des Transports (Transport- und Liegezeiten sowie der Auf-
wand fur die Verteilung),
• der Such- und Zugriffszeiten,
• des Verlegens oder des Verlorengehens solcher Papierdo-
kumente.
• Zusatzlich entsteht haufig der Wunsch, gleichzeitig mehr-
fach und auch aus entfernten Lokationen darauf zugreifen
zu k6nnen.
Hier ergibt sich massiv der Bedarf, diese Papierdokumente zu
erfassen und als elektronische Dokumente zu speichern und zu
handhaben.
Ein solcher Ansatz vermeidet den Medienbruch zwischen papier-
und rechnerbasierten Dokumenten, gestattet eine wesentlich
raumsparendere Aufbewahrung, eine automatisierte Ablage, die
effiziente, rechnerbasierte Suche nach solchen Dokumenten so-
wie den schnellen und gleichzeitigen Zugriff auch mehrerer Per-
sonen auf diese elektronischen Dokumente. Die Liegezeiten sol-
cher elektronischer Dokumente sind ktirzer, und der Transport
und Versand (per elektronischer Post oder FAX) ist schneller und
billiger als der von Papier.

150
 2 Das ArchiveLink-Konzept

2 Das ArchiveLink-Konzept

Als sich zunehmend der Bedarf nach einer Untersti..itzung opti-

scher Archive durch R/3 abzeichnete, initiierte die SAP die Kon-
zeption einer allgemeingultigen Schnittstelle zwischen R/3-
Modulen und optischen Archiven. Die Konzeption wurde 1993
konkretisiert und in Zusammenarbeit mit der Firma iXOS reali-
siert. Dazu wurde auf der einen Seite eine Programmschnittstelle
(ein API) fur R/3-Applikationen geschaffen, welche die R/3-
Anwendung zum Ansprechen von Archiven nutzen kann, ohne
daB sie dabei die Unterschiede verschiedener angeschlossener
Archive berticksichtigen muB. Die zweite Schnittstelle definiert
ein Interface, an dem sich optische Archive an R/3 ankoppeln
kbnnen, ohne daB der Anbieter allzutief in die Internas von R/3
einsteigen muB. Sie isoliert den ArchivanschluB weitgehend von
R/3-Erweiterungen und neuen R/3-Versionen.
Zu diesem als ArchiveLink bezeichneten System gehbren auch
die Viewer zur Anzeige archivierter Dokumente. Die hier von
der SAP mitgelieferten Anzeigemodule sind speziell auf die SAP-
Dokumente (siehe weiter unten) ausgelegt. Sie sind im Standard-
fall deshalb bei allen angeschlossenen Archiven (zumindest fur
die SAP-Dokumente) identisch.

Bild 1-1: • •
R/3 • • Archiv -
·
Die Schnittstellen von ArchiveLink
ArchiveLink Anwendung
I
system ,
I

•
•
•
II I
Erfassungs-
Dokumenten-
I
• system
• anze ige
•
·
(,Scanne rsyst. )
• .t

App likations- Arch iv -

schnittstelie Schn ittste lie

Mit dem ArchiveLink-API wurde von der SAP die Archivierung

von Dokumenten in eine Reihe wesentlicher R/3-Module inte-
griert. Dies wird von R/3-Release zu R/3-Release ausgebaut. Mit
R/3 Release 3 ist die Untersti..itzung, z.B. in Modulen wie FI, CO,
SD, Office, HR, MM/ PPS und PP gegeben.

151
2 Das ArchiveLink-Konzept

Daneben kann ArchiveLink als wesentliche Komponente des R/3

Dokumentenvetwaltungssystems angesehen werden - dem Mo-
dul DVS.
Die erstmals mit R/3 Release 2.1 freigegebene ArchiveLink-
Schnittstelle kann auch yom Kunden in eigenen in R/3 mit ABAP
erstellten Anwendungen oder entsprechenden kundenspezifi-
schen Etweiterungen von R/3-Modulen eingesetzt werden.
ArchiveLink wird durch die Funktion einer Vorgangssteuerung
bzw. eines R/3-internen Workflow-Systems erganzt. Diese er-
laubt es, Dokumente in elektronischer Form aufgaben- bzw. ge-
schaftsprozeBorientiert durch das Unternehmen zu leiten. Damit
steht ein wesentlicher Baustein zum sogenannten Business Re-
Engineering zur Verfugung. Das mit R/3 Release 3 gegenuber
Version2 nochmals deutlich etweiterte Workflow-System gestattet
dann eine sehr feine Steuerung dokumentenorientierter Be-
triebsablaufe und ebenso eine terminliche Kontrolle von Vor-
gangen.
Auswahl zwischen Zahlreiche Anbieter von Archivsystemen bieten bereits den An-
mehreren Anbietern schluB ihrer optischen Ablagesysteme sowie ihrer Scanner-
Erfassungssysteme an ArchiveLink an. Hierzu zaWen z.B. Digital,
FileNet, HP, IBM, iXOS und SNI; auch fUr R/3 auf SUN-Systemen
steht ein ArchiveLink-AnschluB zur verfugung. Weitere Anbieter
haben ihre Unterstutzung zugesagt oder zwischenzeitlich reali-
siert. Damit steht dem R/3-Anwender eine an seine Systemum-
gebung und seine Anwendungsbedurfnisse angepaBte Auswahl
von Archiv-L6sungen zur VerfUgung.
zertifizierte Seit Mitte 1994 zertifiziert die SAP nach entsprechenden Tests der
AnschlUsse Realisierung solche AnscWusse und gibt dem Kunden damit fur
die zertifizierten Produkte eine erh6hte Funktions- und Investi-
tionssicherheit.

2.1 Rl3-Dokumente im Archiv

R/3 kennt eine Vielzahl unterschiedlicher R/3-0bjekte, darunter
auch viele R/3-Dokumente. Fur die Archivierung wurden weitere
Dokumenttypen eingefuhrt darunter ein Faksimile-
Dokumententyp fUr Dokumente, die von Papier eingescannt
oder per FAX-System empfangen wurden. In der bisherigen Ar-
chiveLink-Realisierung k6nnen folgende Dokumente archiviert
werden:

152
 2.2 Dokumentenubernahme

• Eingehende Originalbelege
(z.B. eingehende Rechnungen, Lieferscheine, Bestellungen,
Briefe, Reklamationen, eingehende Faxe).
Diese werden als Faksimiledokumente (Rasterbilder,
Images) im TIFF-Format abgelegt.
• Ausgehende Belege
(z.B. in Rl3 erzeugte Rechnungen, Bestellungen, Angebote,
Auftragsbestatigungen, Briefe, Materiallisten, Warenbegleit-
scheine ... )
Diese werden als CI-Daten im SAP-OTF-Format abgelegt.l
• Drucldisten
(z.B. Einzelpostenjournal, kumulierte Kontenschreibung,
klassische Kontenschreibung, Belegjournale, Auftragstiber-
sichten, Lifo-Bewertungen, PPS-Stiicklisten, Lohnkonten ... )
Sie werden in einem erweiterten SAP-ALF-Format gespei-
chert.
• Beliebige weitere Daten (Dateien)
k6nnen tiber das Rl3-Dokumentenverwaltungssystem DVS
erfaBt, attributiert und verwaltet werden.
Bis zur Rl3 Version 2.2 waren die sogenannten Reorg-Dateien.
von der Archivierung ausgeschlossen. Hierbei handelt es sich um
logische Datenbank-Abztige (z.B. von abgeschlossenen Bu-
chungsvorgangen), die ausgelagert werden, um den Datenbank-
urnfang des Rl3-Systems zu reduzieren. Diese Reorg-Dateien
sind in der Regel sehr urnfangreich und sequentiell aufgebaut.
Mit Release 3 bietet Rl3 auch hierfur die M6glichkeit der Archi-
vierung tiber ArchiveLink. Rl3 bietet dazu eine neue einfache
Verwaltung solcher Reorg-Dateien. Es bleibt jedoch zu priifen,
ob diese nicht schneller und wirtschaftlicher auf Streamer oder
Band gespeichert werden.

2.2 Dokumentenubernahme
Die Erfassung von Dokumenten tiber Scanner ist - verglichen
mit einer elektronischen Obernahme - relativ arbeits- und spei-
cherintensiv. ArchiveLink beschrankt sich deshalb auf die Pa-
pierdokumente, die von extern ankommen. Da eine elektroni-
sche TexterkennungiTextumwandlung in der Regel nicht
wirtschaftlich ist, werden so erfaBte Dokumente als sogenannte

Diese Begriffe werden spater erklart.

153
2 Das ArchiveLink-Konzept

NCI-Dokumente (Non Coded In/ormation), d.h. als Rasterbilder

(Images), gespeichert.
Dokumente und zu archivierende Informationen, die in R13 er-
zeugt werden - hierzu gehoren z.B. ausgehende Briefe, Bestel-
lungen, Anschreiben, Auftragsbestatigungen, Lieferscheine, faBt
man in einem modifizierten Drucklauf ab und speichert sie im
CI-Format (Coded In/ormation), d.h. in einem strukturierten
Rechnerformat. Fur ausgehende Briefe und ahnliches wird dabei
das SAP-OTF-Format verwendet (ein an PostScript angelehntes
Seitenbeschreibungsformat), wahrend die typischen Drucklisten
in SAP-ALF-Format abgelegt werden. Beide Formate erlauben
eine wesentlich kompaktere Speicherung als das NCI-Format von
Images (etwa 10-20 Mal kompakter). In beiden Formen (OTF
und ALF) entfallt naturlich auch das - verglichen mit der Direkt-
ubernahme - arbeits- und zeitintensive Scannen mit anschlie-
Bend notwendiger Qualitatsprufung der erfaBten Dokumente.
R13-Applikationen, welche die Archivierung solcher R13-
erzeugten Dokumente unterstutzen, bieten die Archivierungs-
funktion in der Regel in erweiterten Druck- oder Report-
Dialogen an.

2.3 R/3-fremde Dokumente

In vielen Fallen fallen in einem Unternehmen neben den R13-
Belegen auch solche Dokumente an, die keine oder nur eine
schwache Verknupfung zu R13-0bjekten besitzen, die jedoch
ebenfalls archiviert und administriert werden solien. Hierzu zah-
len z.B. Vertrage, PC-Dokumente aus Word, Excel oder andere
auf einem PC oder einer UNIX-Workstation laufenden Applika-
tionsdateien, technische Zeichnungen, externe Stticklisten oder
ahnliches. Fur solche Dokumente bieten sich zwei Losungen an:
Die spezielle 1. Man setzt hierzu eine yom Archiv-Anbieter geschaffene do-
Archivlosung kumentenspezifische Losung ein. Diese laBt sich sehr stark
auf Art und Organisation der Dokumente abstimmen, und
man nutzt lediglich die gleichen Erfassungs- und Ablagesy-
sterne wie das R13-Archiv. Der Vorteil liegt hier in einer
potentiell optimalen Anpassung der Losung an die speziel-
len Anforderungen. Der Nachteil besteht in der Regel in
deutlich hoheren Kosten fUr die zusatzlichen Module und
Anpassungen und in dem Umstand, daB damit eine weitere
Bedienung und Oberf1ache erlernt werden muB.

154
 2.4 A rchiViernngsstufen

Der DVS-Ansatz
2. Man setzt hierzu das Rl3-Modul DVS ein. Dessen Fokus ist
zwar zunachst auf technische Dokumente ausgerichtet; DVS
laSt sich jedoch in wei ten Grenzen auch an andere Doku-
mente anpassen.
Wahrend das tibrige ArchiveLink-System weitgehend auf Rl3-
Objekte bzw. Rl3-Dokumente ausgelegt ist und zunachst nur fur
diese Anzeigemodule vorsieht, lassen sich in DVS auch fremde
Dateien einbinden. Zu jedem Dokumententyp werden hier (in
Rl3-Tabe11en) Informationen hinterlegt, die definieren, welches
Programm zur Anzeige und Bearbeitung aktiviert werden solI.
Auf dieses Weise untersttitzt DVS z.B. die Archivierung von
Word- oder AmiPro-Dateien oder beliebigen anderen PC-
Applikationsdateien. SolI ein solches Dokument wieder ange-
zeigt werden, so aktiviert DVS dazu automatisch z.B. das ent-
sprechende Textprogramm. Dabei unterscheidet DVS zwischen
einer Anzeige, einer Bearbeitung und einem Abruf als Datei (urn
sie etwa separat zu verschicken oder losgelbst zu bearbeiten).
Bearbeitete Dokumente werden von DVS automatisch als neue
Dokumente betrachtet und entweder als ein komplett neues Do-
kument angelegt oder als neuere Version des zuvor abgerufenen
Dokuments registriert.
Einfacher noch, jedoch mit der Einschrankung auf Images und
eingehende FAX-Dokumente, ist die Archivierung und spatere
Recherche mit SAP-Office mbglich. Hier stehen die von anderen
Office-Objekten her bekannten Mbglichkeiten der Attributierung
und Recherche zur Verfugung.

2.4 Archivierungsstufen
Die nachfolgende Graphik 1-2 zeigt die typische Zugriffshaufig-
keit auf Dokumente tiber der Zeitachse.

Zugriffshiiufigkeit
Abbildung 1-2:
Tyische Zugriffs-
hiiufigkeit auf Doku-
mente Ober die Zeit

Zeit

155
2 Das ArchiveLink-Konzept

So wird der Zugriff nach der Erfassung zum Zwecke der Bearbei-
tung, zur Klarung von Unstimmigkeiten und Ruckfragen zu-
nachst relativ hoch sein, bei kommerziellen Dokumenten even-
tuell nochmals eine gewisse Spitze beim Monats- oder
JahresabschluB erleben und danach schnell abnehmen.
Das ArchiveLink-Konzept berucksichtigt dort, wo Massenbelege
auftreten (z.B. bei FI, CO, SD, MM, PPS) diese Zugriffshaufigkeit
durch ein zweistufiges Archivierungs-/Retrieval-Konzept und lost
damit das Problem der uber die Zeit stark anwachsenden Daten-
banken bei groBen Belegmengen.
Die Aktivphase Die erste Stufe deckt die Phase ab, in der mit hoher Wahr-
scheinlichkeit auf das Dokument zugegriffen wird. In ihr sind die
Dokumente (z.B. Rechnungsbelege in FI) schnell und kornforta-
bel uber die normalen Suchmechanismen der entsprechenden
Applikation (in unserem Beispiel FI) zu finden. Der Anwender
braucht hierzu auch wenig neu zu lemen, da dies bereits Teil
seiner Standardarbeit mit der Applikation darstellt. Die Recher-
chemoglichkeiten werden hier von der Rl3-Applikation und
nicht yom Archivsystem gestellt.
Die Langzeit- Die zweite Stufe tritt ein, wenn die Zugriffshaufigkeit sinkt und
phase der norma Ie Bearbeitungszeitraum eines Dokuments abgeschlos-
sen ist - das Dokument jedoch, wie z.B. im Buchhaltungsbereich
ublich, aus Grunden des Steuer- und Wirtschaftsrechts noch
weiter aufbewahrt werden muB. Hier erfolgt in Rl3 im Standard-
fall die Auslagerung der Datenbankbestande abgeschlossener
Vorgange in Reorg-Dateien, die man auf Band legt. Damit fehlen
jedoch die Daten, welche zur bisher benutzten Recherche erfor-
derlich sind.
Vor der Auslagerung (dem Reorg-Laut) wird bei ArchiveLink
deshalb eine (a pplikationsspezifische) Archiv-Druckliste erzeugt,
die weitgehend analog zu den bereits bekannten Papier-
Drucklisten ist. In ihr sind in kompaktifizierter Form (z.B. in
Form einer kumulierten Kontenschreibung) die Buchungsdaten
eines Zeitraums enthalten. 1m Gegensatz zur Papierdruckliste
enthalt jedoch die Archivform (verdeckt und zunachst in der An-
zeige nicht sichtbar) Verweise auf die archivierten Belege zu ei-
nem Vorgang sowie zusatzliche Indexinformationen.
Die Listen selbst werden in einer einfachen Drucklistenverwal-
tung gehalten und konnen dort gesucht und zur Anzeige ge-
bracht werden. Nun lassen sich - entsprechend aufbereitete
Drucklisten vorausgesetzt - in der Druckliste Vorgange suchen

156
 2.4 A rchiViernngsstufen

und aus dem angezeigten Vorgang heraus die dazugehbrigen

Belege anzeigen. In dieser Phase fungiert also die archivierte
Druckliste neben ihrer Funktion als elektronische Druckliste zu-
satzlich als Rechercheinstrument fur die Belege ausgelagerter
(reorganisierter) Datenbestande.
Dadurch, daB diese Drucklisten zusammen mit Suchindizes ab-
gespeichert werden, laBt sich in solchen elektronischen Druckli-
sten sehr viel gezielter und schneller nach einzelnen Vorgangen
(z.B. Buchungen) suchen als in den teilweise sehr umfangrei-
chen und untibersichtlichen Papierlisten. Mbchte man zu einem
gefundenen Buchungsvorgang dann die dazugehbrigen Origi-
nalbelege sehen, so aktiviert man durch einen Doppelklick auf
das Buchungsobjekt deren Anzeige. Aus der Anzeige heraus
wiederum ist auch ein Ausdrucken oder Versenden per FAX
mbglich.

3 Erfassungsszenarien

Eine der wesentlichen und relativ kostenintensiven Schritte bei

papierbasierten Dokumenten ist die Erfassung - d.h. das Scan-
nen, Klassifizieren und die Eingabe von Merkmalen, die spater
zur Suche herangezogen werden (soweit diese nicht bereits in
Rl3 verfugbar sind). Wie und zu welchem Zeitpunkt dies zu ge-
schehen hat, ist ein wesentlicher Planungspunkt bei der Einfuh-
rung von Archivsystemen.
Da etablierte ArbeitsabIaufe, Personalstruktur, DV-Struktur und
andere betriebliche Gegebenheiten von Unternehmen zu Unter-
nehmen stark variieren kbnnen, paBt ein einziges Organisations-
verfahren hier nicht auf aIle Betriebssituationen gleich gut. SAP-
ArchiveLink tragt dem Rechnung, indem es unterschiedliche Er-
fassungsszenarien untersttitzt, die sich im wesentlichen in drei
Verfahren untergliedern lassen. Der organisatorische Umstel-
lungsaufwand bei der Einftihrung eines solchen Systems nimmt
in der Reihenfolge der beschriebenen Verfahren zu:

157
3 Eifassungsszenarien

• Spates Erfassen
Bei diesem Szenario wandert das Papier auf dem konven-
tionellen Weg zur Sachbearbeitung. Dort erfolgt die Bu-
chung yom Papier. Danach gelangt das Papier zum Scan-
nen.

• Erfassen bei der Bearoeitung

Hier erhalt der Bearbeiter wie zuvor das Papier auf dem
konventionellen Weg, scannt es zunachst ein und begutach-
tet es danach (z.B. in einer elektronischen Akte) und fuhrt
die Bearbeitung durch - sofern es mit der Ablage zunachst
nicht getan ist. Alternativ kann er zunachst das Papier bear-
beiten, urn es anschlieBend einzuscannen. Erfassung und
Bearbeitung erfolgen hier also zusammenhangend.

• Friihes Erfassen
Hierbei werden eingehende Originalbelege moglichst fruh
erfaBt (eingescannt) - in der Regel bereits in der Poststelle.
Auf elektronischem Weg bzw. per R/3-Vorgangsbear-
beitung gelangen sie dann zur Sachbearbeitung, wo sie im
elektronischen Eingangskorb des Sachbearbeiters erschei-
nen. Aktiviert der Bearbeiter den Eintrag, so wird damit ei-
nerseits das Dokument auf dem Bildschirm angezeigt und
zugleich die dazugehorige Verarbeitungstransaktion akti-
viert. Hierbei geschieht die Bearbeitung vollstandig am
Bildschirm. Nach der erfolgreichen Verarbeitung loscht R/3
das Dokument aus dem Auftragskorb.
Jedes dieser Verfahren hat seine spezifischen Vor- und Nachteile
und typische Einsatzgebiete. Die Verfahren sollen deshalb
nachfolgend etwas ausfuhrlicher betrachtet werden.

3.1 Erfassungsszenario: "Spates Erfassen"

Beim Szenario "Spates Erfassen" erfolgt das Scannen nach der
Bearbeitung eines Dokuments. Am Beispiel einer eingehenden
Rechnung ware dies, nachdem die Rechnung konventionell yom
Papier hemnter gebucht wurde. Das Papier wandert nach der
Bearbeitung zu einer zentralen Erfassungsstelle und wird dort

158
 3.1 E1jassungsszenario: "Spates E1jassen"

eingescannt und danach den SAP-Belegen zugeordnet. Hierzu

untersttitzt ArchiveLink zwei unterschiedliche Versionen:
• unter Verwendung eines Barcodes zur Dokumentenidentifi-
kation oder
• unter Verwendung der SAP-Belegnummer, die man manu ell
auf das gebuchte Dokument tibertragt.

3.1.1 Ablaut beim spaten Erfassen

Die Eingangspost wird in beiden Fallen in Papierform zum
Sachbearbeiter verteilt. Dieser fuhrt die Bearbeitung (z.B. Bu-
chung) vom Papier durch.
ohne Barcode Beim Verbuchen wird die SAP-Belegnummer von R13 angezeigt
und manuell auf dem Originalbeleg (dem Papier) vermerkt.
mit Barcode
Der Beleg hat zuvor (entweder im Posteingang oder beim Sach-
bearbeiter) einen Barcode erhalten (nur jeweils die erste Seite
eines mehrseitigen Dokuments).

Abbildung 1-3: ohne Barcode mit Barcode

Ablaulschema
beim "spalen Er- Posteingang Barcode aufbringen
lassen"

Transport zum Scan-

nen

159
3 Eifassungsszenarien

In der SAP-Applikation erscheint (durch entsprechende Vorein-

stellung) bei jedem Buchen ein spezielles Pop-Up-Fenster. Hier
hinein wird die Barcode-Nummer tiber einen an der Tastatur an-
geschlossenen Barcodestift oder eine Barcode-Lesepistole tiber-
tragen oder einfach manuell eingegeben. Die Applikation tragt
diese Barcodenummer zusammen mit der SAP-Belegnummer
und der Art der Applikation in eine Barcodetabelle ein. Sie er-
moglicht spater die automatisierte Zuordnung des archivierten
Dokuments zur Buchung bzw. zum SAP-Beleg.
be ide Verfahren Die Originalbelege wandern danach zum (in der Regel zentra-
len) Scannen. Der Beleg wird eingescannt, auf ausreichende
Scan-Qualitat gepruft und die Dokumententrennung durchge-
fUhrt (d.h., soweit notwendig, die einzelnen Seiten eines mehr-
seitigen Dokuments zu einem Dokument gruppiert).
Erfassung Der Erfasser stellt in R13 eine anwendungsspezifische Erfas-
ohne Barcode sungsmaske (Erfassungstransaktion) ein. Dies ist nur einmal pro
Anwendungsbereich bzw. Dokumentenstapel notwendig, setzt
jedoch voraus, daB die Belege bereits nach Belegart wie Rech-
nungen, Bestellungen, Lieferscheine usw. vorsortiert sind. Eine
solche Sortierung ergibt sich fast automatisch, da die Dokumente
gesammelt aus den verschiedenen Bearbeitungsbereichen ange-
liefert werden. 1st diese Vorsortierung nicht gegeben, so ist
eventuell ein Erfassungsmaskenwechsel von Beleg zu Beleg er-
forderlich.
In die Erfassungsmaske gibt man nun die Belegnummer ein. Die
Erfassungstransaktion aktiviert damit ein Pruffenster, welches
(applikationsspezifisch) die wesentlichen Daten des SAP-Belegs
anzeigt. Dies ermoglicht eine nochmalige Prufung.
Durch die Bestatigung wird:

• das Dokument archiviert,

• die Zuordnung (Buchung zu Dokumenten-Identifikation) in
der zentralen Verkntipfungstabelle durchgefUhrt,
• das Dokument aus der Erfassungswarteschlange entfernt und
• das nachste Dokument angezeigt.
Danach wird die Bearbeitung mit dem nachsten Beleg fortge-
setzt, bis aile Dokumente verarbeitet sind oder man die Bearbei-
tung beendet.

160
 3.1 Erfassungsszenario: "Spates Erfassen"

Durch eine spezielle Funktion im Erfassungssystem wird die au-

Erfassung
mit Barcode tomatische Barcodeerkennung aktiviert. Bei erkanntem Barcode
archiviert die Erfassungsapplikation das Dokument und schickt
seine Identifikation zusammen mit der Barcodenummer in eine
Batch-Queue zur automatischen Zuordnung.
Ein Batch-ProzeB arbeitet danach die Vorgangsobjekte aus dem
speziellen Auftragsstapel ab und ordnet die Dokumente (ohne
weiteren Eingriff des Anwenders) den entsprechenden SAP-
Belegen zu. Tritt bei der Zuordnung ein Fehler auf - beispiels-
weise, weil die Barcodenummer nicht in der Rl3-internen Bar-
codeliste vorhanden ist oder die SAP-Belegnummer nicht mehr
existiert - so wird automatisch ein neuer Vorgang erzeugt, der
das Dokument an einen fur den Fehlerfall festgelegten Adressa-
ten schickt. Dieser kann das Dokument dann begutachten und
entweder direkt bearbeiten, indem er dazu die entsprechende
Rl3-Transaktion aufruft oder an einen zustandigen Bearbeiter
weiterleiten.

3.1.2 Vor- und Nachteile des spaten Erfassens

Der Vorteil dieses Verfahrens besteht darin, daB der Arbeits- und
PapierfluB weitgehend wie bisher in den Unternehmen ublich
ablaufen kann. Organisatorische Umstellungen mit ihren zeitli-
chen und psychologischen Problemen sind hierbei geringer als
in den beiden anderen Erfassungsszenarien.
Ein anderer Vorteilliegt darin, daB Papiere (z.B. eine Rechnung)
vor ihrer Erfassung noch Priifungen unterzogen und abgezeich-
net werden kbnnen. Diese Abzeichnungen (Stempel, Unterschrif-
ten, Korrekturen) werden hier miterfaBt. Hierzu benbtigt das
Szenario des >spaten Erfassens> die Mbglichkeit elektronischer
Stempel (Abzeichnungen, Unterschriften und Annotationen).
Die Arbeitsplatze der Sachbearbeiter erfordern keine spezielle
Ausstattung (z.B. keine groBen, hochauflbsenden Bildschirme).
Solche Arbeitsplatze sind jedoch spater beim Abruf der Doku-
mente erforderlich - kbnnen aber zumeist auf spezielle, dafur
ausgelegte Kontrollarbeitsplatze beschrankt werden.
Das Verfahren nutzt nicht das volle Potential von lmage-
Systemen, das z.B. in einer elektronischen Verteilung von Do-
kumenten bestehen kann. Die Wahrscheinlichkeit fur ein Verlo-
rengehen und eine Beschadigung der Papiere auf dem Trans-

161
3 Erfassungsszenarien

port zwischen Posteingang und Bearbeiter und von diesem zur

nachgeschalteten Erfassung ist hier deutlich hoher als im Szena-
rio ·Pruhes Erfassen·. Die Zugriffsmoglichkeiten auf das elektroni-
sche Abbild eines Dokuments liegen spater als in den beiden
nachfolgend diskutierten Szenarien.

3.2 Szenario: "Gleichzeitiges Erfassen"

Bei diesem Szenario erfolgt die Erfassung der Dokumente am
Bearbeitungsplatz, d.h. hierbei erfaBt der Bearbeiter selbst, be-
gutachtet die Bildqualitat, fUhrt eventuell notwendige Bildbear-
beitungsschritte aus (soweit die entsprechende Applikation dies
sinnvoll erscheinen laBt und gestattet) und archiviert schlieBlich
das Dokument.

3.2.1 Ablaut bei der Erfassung zum Bearbeitungszeitpunld

1. Einscannen Das Dokument wird uber den Scanner erfaBt und im Scanfenster
dargestellt. Hier muB es, wie in den anderen Szenarien auch, auf
Vollstandigkeit und Erfassungsqualitat kontrolliert werden.
2. Vorlagen- Hiernach finden eventuell notwendige Vorlagenbearbeitungen
bearbeitung statt. Dies ist bei der Erfassung technischer Dokumente (z.B.
Werkstattzeichnungen) haufig notwendig - bei Belegen im
kaufmannischen Bereich naturlich unzulassig. Art und Urnfang
der Bearbeitungsfunktionen sind deshalb erfassungs- und doku-
mentenspezifisch. Diese werden auch nicht von ArchiveLink
selbst zur verfugung gestellt, sondern kommen yom Archiv-
Anbieter und sind somit auch anbieterspezifisch.
3. R/3-Doku-ment Daneben hat der Anwender seine R/3-Applikation aktiviert. 1m
anlegen Applikationsfenster wird ein neues Dokument mit seinen
Grundmerkmalen (z.B. dem Dokumententyp) angelegt.
4. Attributieren Danach sind die Attribute zum Dokument (z.B. bei technischen
Dokumenten im DVS oder bei Einzeldokumenten, z.B. in SAP-
Office) zu erfassen. Dies ist applikationsspezifisch und kann
mehrere Einzelschritte urnfassen.
5. Archivieren Durch die applikationsspezifische Punktion Ablegen oder Archi-
vieren wird das Dokument im Archiv abgelegt und seine Doku-
mentenidentifikation an die Applikation ubergeben. Hiermit wird
(im Standardfall) auch das aktuelle Dokument aus dem Erfas-
sungsstapel entfernt und das nachste Dokument angezeigt.

162
 3.2 Szenario; "Gleichzeifiges Eifassen"

3.2.2 Argumente zum direkten Erfassen

Dieses Verfahren ist in der Regel nicht fur eine Massenbearbei-
tung geeignet, wird aber fur die Erfassung und sofortige Attribu-
tierung von technischen Zeichnungen, Vertragen oder anderen
Dokumenten eingesetzt. Es macht dort Sinn, wo die Erfassung,
Nachbearbeitung oder Attributierung von Dokumenten aufwen-
dig ist und, z.B. wie bei technischen Zeichnungen oder bei der
Dbernahme von einzelnen Dokumenten bzw. Dateien, praktisch
keine eigentliche Rl3-Bearbeitung stattfindet.
Bei einigen Dokumenten (z.B. Vertragen, Werkstattlisten usw.)
kann die Attributierung aufwendig sein und spezielle Sach-
kenntnis voraussetzen, die nur der Sachbearbeiter selbst besitzt.
Das Verfahren ist daneben zuweilen vorteilhaft, urn fehlgeleitete
Belege oder nachtraglich entstehende Belege in das System zu
bringen oder urn nur eine kleine Anzahl von Dokumenten zu
erfassen, wie es z.B. im Office-Modul zur Dbernahme einiger
eingehender Briefe oder Offerten sein kClllnte.
Als nachteilig erweist sich, daB jeder Bearbeitungsplatz einen
relativ teuren Scanner benotigt und dieser durch die nachfolgen-
den Arbeiten haufig nicht optimal ausgenutzt wird. Auch muB
der Arbeitsplatzrechner des Scanneranschlusses wegen groBer
ausgebaut sein als beim friihen und spaten Erfassen.
Bei der Verarbeitung groBer Dokumentenmengen ist der standi-
ge Wechsel zwischen Dokumentenerfassung und Dokumenten-
verarbeitung (scannen, priifen, Vorlageneinzug des Scanners
fullen, buchen oder attributieren) fur den ArbeitsfluB und damit
fur die Effizienz storend.
Aus dies em Grund wird dieses Verfahren nur von den Rl3-
Applikationen unterstiltzt, bei denen in der Regel nach dem
Scannen und vor dem Ablegen im Archiv weitere Dokumenten-
bearbeitungen erforderlich sind oder bei denen zu einem Zeit-
punkt jeweils nur eine kleine Anzahl von Seiten und Dokumen-
ten erfaBt werden (z.B. im Personalwesen die Erfassung von
Bewerberunterlagen).

163
3 Erjassungsszenarien

3.3 Szenario "Fruhes Erfassen"

Beim "Fruhen Erfassen" werden papierbasierte Informationen zu
einem mbglichst fruhen Zeitpunkt eingescannt und auf elektro-
nischem Weg zur Bearbeitung weitergeleitet. Die Erfassung er-
folgt dabei praktischerweise in einer zentralen Poststelle, in der
z.B. die Post gebffnet, vorsortiert, vorbereitet und erfaBt - sprich:
eingescannt und klassifiziert - wird und wo unter Umstanden be-
reits einige Attribute (Suchmerkmale) aufgenommen werden.
Da beim "Fruhen Erfassen" typisch groBe Dokumentenmengen
zu verarbeiten sind, ist hierzu ein effizientes Klassifizierungs-
und Verteilverfahren erforderlich. Dies wurde fur ArchiveLink
mit einer speziellen Vorgangskomponente geschaffen. Ab Rl3
Release 3 ist diese mit erweiterten Werkzeugen versehen, flexi-
bier und in weiten Bereichen programmierbar.

3.3.1 Schematischer Ablaut

Die nachfolgende Graphik zeigt den typischen Arbeits- und In-
formationsfluB beim "Fruhen Erfassen" . Da sich beim Einsatz von
Workflow-Verfahren viele unterschiedliche Ablaufe ergeben
kbnnen, ist das Schema wiederum als nur eine - wenn auch ty-
pische - Variante zu betrachten.
1. Einscannen Die zu erfassenden Seiten werden eingescannt, auf Qualitat und
Vollstandigkeit gepruft und in Dokumente gruppiert.
2. Belegart wahlen Die erfassende Person stellt sich zunachst ein Erfassungsverfah-
ren ein. Dies ist bei vorsortierten Belegen nur einmal pro Be-
legstapel bzw. Belegart erforderlich. Mit dem Verfahren wird die
Belegart ausgewahlt (z.B. eingehende Rechnungen, Reklamatio-
nen, Bestellungen oder ahnliches) und damit zugleich eine Vor-
gangsart - d .h. welcher Workflow fur die Bearbeitung des Belegs
aktiviert wird.

164
 3.3 Szenario "Fnlhes Eifassen"

Abbildung 1-4:
Schernatischer
Ablauf beirn .Friihen
Erfassen" r------=--i 8elegart auswahlen
®.------...,

® erneut klassifizieren
Erfassen

Bearbeiten
Auftrag aus dem
Eingangskorb
entnehmen

Andern
®

®
, ...... .. .......................................... ...... ,
nein • eventuell weitere :
'--_ _ _ _-r-_ _.....,t---¥...... ~~~~~~~t.u.~~~~... .-
ja
. ... ... ... ... ... ... ......... ... . . .. ........................ ,
: Auftrag wird aus dem :
: Eingangskorb entfernt :

Nun werden die einzelnen eingescannten Dokumente klassifi-

3. Beleg
klassifizieren ziert - im Idealfall nur durch die Bestatigung voreingestellter
Werte. Hier ist bei vorsortierten Belegen auch ein Stapellauf
m6glich.

Abbildung 1·5:
Erfassungsrnaske
beirn DokUlll8ntart . . . . Bingang8rechnung
.Friihen Erfassen"
Prioritlt ..... . 4

165
3 Eifassungsszenarien

Hiermit wird ein Workflow-Objekt bzw. ein Vorgang erzeugt,

welcher von der SAP-Vorgangssteuerung per Electronic Mail in
den Eingangskorb des zustandigen Sachbearbeiters gelangt. Der
elektronische Beleg wird damit zugleich im Archiv abgelegt.

Bild 1-6:
Das Aktivieren des
Eintrags im Eingangs-
korb initiiert die An-
zeige des 8elegs.
Danach kann festge- Fa. Otto Eisen KG
legt werden, was Zeilllgstr.12
damit 8000 MUnchen
geschehen soli. RQChnungsNr. 1023
Datum 20.08. 1993

Pos Be.zelctlng. Betrag

1'VP

Il!!£
-
Tit.e l

D~'

Il~

D~

Der Sachbearbeiter findet den Vorgang in seinem Eingangskorb

4. Entnahme aus (s. Bild 1-6 die mittlere Maske). Nimmt er ihn zur Bearbeitung
dem Eingangs-
korb heraus, so wird damit automatisch der Beleg zu dem Vorgang
angezeigt.

166
 3 .4 Mehrjachzuweisungen

5. Bearbeilen oder In einer Dialogbox entscheidet er nun, ob er den Vorgang wirk-

weilerleilen?
lich bearbeiten, weiterleiten oder erneut klassifizieren mbchte.

6. Bearbeilen
Wiihlt er die Bearbeitung, so wird automatisch die fur den Beleg
in der Vorgangssteuerung vorgesehene Bearbeitungstransaktion
aktiviert. In dieser erfolgt nun die Bearbeitung (z.B. die Bu-
chung) des Belegs.
Mit der erfolgreichen Bearbeitung wird der erfaBte Originalbeleg
uber eine interne Verknupfungstabelle dem SAP-Beleg zugeord-
net.
7. Beenden? Eine weitere Abfrage gestattet, die Bearbeitung des Belegs zu
beenden oder erneut eine Klassifizierung oder Weiterleitung des
Belegs fur weitere Bearbeitungsschritte vorzunehmen. Dies ist
z.B. dann sinnvoll, wenn mehrere Rechnungen auf einem Beleg
vorhanden sind.

3.3.2 Vor- und Nachteile des "Friihen Erfassens"

Wesentlicher Vorteil des "Fruhen Erfassens" ist die Mbglichkeit,
die Dokumente zentral und damit effizient und kostengunstig zu
scannen und elektronisch zu verteilen. Dies erzielt sowohl Zeit-
als auch Kostenvorteile. Daruber hinaus ist dies der konsequen-
teste Weg in eine elektronisch gesteuerte Vorgangsbearbeitung,
da hier das elektronische Dokument yom Rechner gesteuert wird
und kontrolliert mehrere Bearbeitungsschritte durchlaufen kann.
Ais Nachteil erweist sich, daB die Sachbearbeiter groBe,
hochauflbsende Bildschirme sowie entsprechend ausgerustete
Rechner mit schnellen Graphikkarten benbtigen. Dies bedingt
bei einer grbBeren Anzahl von Arbeitspliitzen entsprechend ho-
he Investitionen.

3.4 Mehrfachzuweisungen
Insbesondere im kommerziellen Umfeld kommt es hiiufig vor,
daB ein eingescanntes Dokument sowohl Beziehungen zu meh-
reren Buchungsobjekten besitzt, als auch daB zu einem Bu-
chungsvorgang mehrere Belege gehbren. Man denke im ersten
Fall z.B. an die Situation, daB auf einer eingehenden Rechnung
die Forderungen mehrerer Bestellungen stehen.

167
3 Erjassungsszenarien

Der zweite Fall liegt z.B. vor, wenn zu einer Bestellung das ei-
gentliche Bestellpapier, Bestatigungen, mehrere Rechnungen,
Lieferscheine oder ahnliche Papiere vorhanden sind. ArchiveLink
untersttitzt solche Mehrfachzuordnungen. Ein bereits archiviertes
und zugeordnetes Dokument la15t sich auch nachtraglich noch an
weitere R/3-0bjekte kntipfen.
Fehlzuordnungen konnen von einem entsprechend privilegierten
Verwalter tiber das ArchiveLink-Verwaltungssystem korrigiert
werden.

3.5 Drucklisten
Das Ergebnis eines Reports sind in R/3 vielfach sogenannte
Drncklisten. Sie stellen einen nach bestimmten Kriterien zusam-
mengefa15ten Auszug aus einer R/3-Datenbank dar. Viele R/3-
Applikationen bieten einen oder mehrere solcher Reports. Der
Anwender kann sich ebenso eigene weitere Reports erstellen.
Beispiele fUr solche Drucklisten sind:
• Kumulierte Kontenschreibungen
• Kumulierte Lagerbestande
• Chargenverwendungsnachweise
• Bilanzbewertungen
• Kostenstellenberichte
Diese Drucklisten konnen in R/3 auf Papier ausgegeben, tiber
eine COM-Ausgabe auf Mikrofilm verfilmt oder mittels Archive-
Link auf optischen Platten archiviert werden. Der Vorteil der Ar-
chivierung liegt
• gegentiber der sehr voluminosen Papierausgabe in einer
sehr viel kompakteren Speicherung,
• gegentiber der Papierausgabe oder Mikroverfilmung in ei-
ner schnelleren Verftigbarkeit (der Druck- bzw. der Verfil-
mungsproze15 entfallt),
• in einem schnelleren Zugriff von mehreren Stellen aus,
• in der Moglichkeit der elektronischen Suche in der Liste On
Form von indizierter Suche oder von Freitextsuche),
• in einer einfachen, konsistenten und kornfortablen Verwal-
tung der Drucklisten rnittels R/3 .

168
 3.5 Drncklisten

Die Erzeugung und das Archivieren der verschiedenen Druckli-

sten erfolgt applikationsspezifisch. Fur eine indizierte Suche in
der Druckliste muB bei deren Erstellung die Applikation eine In-
dexinformation rnitausgeben.
Bei entsprechend aufbereiteten Drucklisten kbnnen Cab R/3-
Release 3.0) direkt aus der Druckliste heraus durch einen Dop-
pelklick auf einen Beleg-Eintrag die zu dies em Beleg gehbrigen
Eingangs- und Ausgangsbelege angezeigt werden.

Abbildung 1·7:
Drucklisten-anzeige.
In ihr kann geblattert
werden, eine Frei-
textsuche oder eine
indizierte Suche
erfolgen.

4 Archivkonfigurationen

Applikationsserver Die Systemarchitektur von R/3 sieht einen zentralen R/3-Server-

Cluster vor, in dem ein Rechner die Datenbankverwaltung
ubernimmt. Die weiteren Rechner in dies em Cluster dienen als
Applikationsserver, auf denen die Anwendungen, wie z.B. die
Finanzbuchhaltung, Materialwirtschaft und Personalwesen, ablau-
fen . In kleinen Konfigurationen kann der Cluster auch nur aus
einem Rechner bestehen. Bei den Applikationsservern handelt es
sich urn UNIX- oder leistungsfahige NT-Systeme.

169
4 Archivkonfigurationen

Priisentationsserver An diese Applikationsserver sind in einer nachsten logischen

Ebene die Rl3-Client-Arbeitsplatze angeschlossen, auf denen die
graphische Rl3-Benutzeroberflache ablauft. Diese eigentlichen
Rl3-Benutzer-Arbeitsplatze werden auch als Prasentationsseroer
bezeichnet. Waren hier in den ersten Rl3-Jahren noch vielfach
UNIX-Arbeitsplatze zu finden, so dominieren inzwischen Win-
dows- und Windows-NT-Arbeitsplatze. ArchiveLink unterstiitzt
das volle Spektrum an Clients Cbisher mit Ausnahme von OS/2).
Das Programm zur Darstellung und Verwaltung der Benutzer-
oberflache, welches das fur den Benutzer sichtbare Interface
zum Rl3-System darstellt, wird als SAP-GUI bezeichnet. An die-
ses Modul ist der ArchiveLink-Viewer angebunden. Seine Aufga-
be ist der Abruf der Dokumente aus dem Archiv und deren An-
zeige. Die Auftrage ftir die Anzeige werden z.B. aus der
Finanzbuchhaltung tiber interne Kommunikation an den SAPGUI
gegeben. Dieser leitet den Auftrag tiber Standardkommunikati-
onspfade an den Viewer weiter.

RJ3-Applikationsserver Archivserver
Abbildung 1-6:
Schema einer
Archivkonliguration
mitRl3

RJ3·Datenbank
RJ3·Anwendung

LAN

Cli ent-Arbe~splatzrechner

/
Ri3-Archlv-Client Rl3-Archiv-Client

Viewer = Anzeige- Die Anzeige erfolgt dokumentenorientiert. So lassen sich bei

module eingescannten Dokumenten Ausschnitte in unterschiedlichen
VergrbBerungsstufen anzeigen, und das Anzeigedokument kann
gedreht werden.

170
 4 Archivkonftgurationen

Fur Drucklisten steht, wie erwahnt, eine Freitextsuche sowie ei-

ne indizierte Suche uber den Viewer zur Verfiigung. Bei allen
mehrseitigen Dokumenten kann geblattert werden. Auch das
Drucken sowie das Versenden eines Dokuments tiber einen
FAX-AnschluB wird aus dem Viewer heraus angestoBen.
Annotationen ArchiveLink bietet die Moglichkeit, an ein archiviertes Dokument
Kommentare (Annotationen) anzuhangen. Dabei werden auto-
matisch sowohl Uhrzeit und Datum als auch der Benutzer ver-
merkt. Annotationen lassen sich nachtraglich nur neu hinzufu-
gen, vorhandene jedoch nicht loschen oder verandern. Auch das
Rl3 System kann Annotationen zu einem Dokument erzeugen.
Archivserver Als weitere wesentliche Komponente der Konfiguration existiert
ein Archivserver, der die Dokumente auf optischen Platten ver-
waltet und in der Archivdatenbank die Verwaltung der Doku-
mentenschltissel zu archivspezifischen Attributen vornimmt. Ar-
chivelink laBt ebenso mehrere Archivserver zu.
Erfassungsplatze Zusatzlich gibt es archivspezifische Erfassungsplatze bzw. Scan-
ner-Arbeitsplatze, die fur die Erfassung der NCI-Dokumente ver-
wendet werden. Art, Auspragung und das Leistungsspektrum
dieser Systeme kann in weiten Bereichen variieren und ist wie
der Archivserver anbieterabhangig und nicht Teil von Archive-
Link. Lediglich die Schnittstellen dazu sind im ArchiveLink-
Konzept festgelegt.
Bei diesen ScannerarbeitspIatzen ist im Standardfall ebenfalls ei-
ne Kopplung zu SAP-GUI vorhanden, so daB die Verbindung
zwischen SAP-spezifischen Attributen und dem Archiv vorge-
nommen werden kann.
Man wird hier in Zukunft jedoch auch stark batch-orientierte
Ubergabeschnittstellen erwarten dtirfen. Sie solI ten es erlauben,
daB die Scannererfassung (nach einer Vorsortierung der Belege)
mit sehr schnellen Scannern erfolgt, die Qualitatskontrolle der
Images in los gel osten separaten Arbeitsschritten geschieht und
bereits tiber Barcodes oder OCR-Verfahren einige oder aIle be-
notigten Attribute aus der Vorlage ermittelt werden. Die so vor-
bereiteten elektronischen Dokumente konnen dann per Work-
flow automatisiert in die Sachbearbeitung gelangen.

171
4 ArchivkonJigurationen

4.1 Verteilte Archive und Remote-Zugriffe

Das ArchiveLink-Konzept sieht vor, daB mehrere logisch oder
physikalisch getrennte Archive eingesetzt werden. So liegt es na-
he, Dokumente mit unterschiedlichen Aufbewahrungszeiten
auch auf unterschiedlichen optischen Platten abzulegen. Auch
mbchte man haufig die Daten unterschiedlicher Mandanten oder
kommerzielle und technische Daten auf unterschiedliche Platten
verteilen. Moderne Archive erlauben hierzu eine Art Pool-
Bildung, bei der die optischen platten beim Einbringen in das
Archiv bestimmten Pools zugeordnet werden kbnnen und ein
Plattenpool eine Art logisches Archiv darstellt.
ArchiveLink gestattet applikations- und dokumententypspezi-
fisch Zielarchive anzugeben, so daB beim Ablegen automatisch
das korrekte Archiv angesprochen wird. Zu jedem Dokument
speichert ArchiveLink sowohl die Archiv-Identifikation als auch
die Dokumentenidentifikation innerhalb des Archivs.
Die Archive durfen in dem Konzept auch brtlich verteilt aufge-
stellt sein. So ist z.B. denkbar, daB in einem Konzern zwar meh-
rere getrennte R/3-Installationen existieren, das Archivsystem je-
doch zentral aufgestellt wird oder bei der Ablage nach
Dokumenten(typen) unterschieden wird, die auf einem lokalen
und solchen, die auf einem zentralen Archiv liegen sollen. In der
bisherigen ArchiveLink-Realisierung gilt jedoch noch die Ein-
schrankung, daB fur Dokumente, die aus der R/3-Applikation
heraus erzeugt werden (also ausgehende Belege und Druckli-
sten), ein NFS-Zugriff (und damit faktisch eine LAN-Verbindung)
zwischen dem Applikationsserver und dem Archivsystem beste-
hen muB.

4.2 Remote Zugriffe

Bei R/3-Systemen trifft man haufig die Situation an, daB von Ar-
beitsplatzsystemen aus remote, d.h. uber DFD-Leitungen auf ein
zentrales R/3-System zugegriffen wird. Werden ausreichend
schnelle Netzverbindungen verwendet, so laBt sich bei einge-
scannten Dokumenten in Formaten von A3 oder kleiner sowie
auf ausgehende Belege ausreichend effizient zugreifen.

172
 4.2 Remote Zugriffe

Setzt man z.B. eine 64 KBaud ISDN-Leitung voraus, so erhalt

man bei den etwa 50 bis 60 kByte groBen Dokumentenseiten
eines eingescannten Belegs eine Verzogerung von etwa 8 bis 10
Sekunden Cgegentiber einem LAN-AnschluB) fur die erste Seite.
Da die weiteren Seiten bereits im Hintergrund tibertragen wer-
den, wahrend man die erste Seite begutachtet, wirkt sich bei den
nachfolgenden Seiten die Verzogerung noch wesentlich geringer
aus.
Berechnet man die Netzverzogerungen fur groBformatige Doku-
mente, beispielsweise bei technischen Zeichnungen, die von
DVS verwaltet werden, so ergeben sich Cjeweils fur die erste
Seite) bei der Anzeige etwa die Werte, die Tabelle 1-1 auffuhrt.
Dort ist fur die Gesamtzeit angenommen, daB kein Plattenwech-
sel in der Jukebox erforderlich ist und daB die volle Bandbreite
des 64 KBaud-ISDN-Netzes zur Verftigung steht.
CI-Dokumente Causgehende Briefe, Drucklisten ... ) mit ihren
deutlich geringeren Datenvolumen pro Seite erfahren eine we-
sentlich geringere Verzogerung, die etwa bei 1-2 Sekunden liegt.
Da die Viewer - eine lokale Platte am Arbeitsplatzsystem vor-
ausgesetzt - einmal tibertragene Seiten in einem lokalen Platten-
Cache halten, fallt danach beim Rtickwartsblattern die Verzoge-
rung durch das Netz weg, und die Seiten werden praktisch sofort
angezeigt.

Tabelle 1·1: Format mittlere Verzagerung bel insgesamt tiber Netz

Verzogerungen und GroSe je Seite 64 KBaud ISDN- (ohne Plattenwechse1)
Zugriffszeilen Ober iibertragung:
eine
64 Kbaud ISDN- A4 56 KB 10 Sek. 13 Sek.
Verbindung A3 110 KB 19 Sek. 25 Sek.
A2 216 KB 36 Sek. 42 Sek.
Al 420 KB 70 Sek. 80 Sek.
AO 820 KB 136 Sek. 160 Sek.

Drucklisten - und diese konnen sehr urnfangreich werden und

mehrere Megabyte besitzen - tibertragt der ArchiveLink-Viewer
nur in Ausschnitten. Wird in ihnen gesucht, so erfolgt die Suche
nicht lokal, sondern im Archivsystem, und nur die Trefferseite
wird zur Anzeige tiber das Netz geschickt.

173
5 Zusammenfassung

5 Zusammenfassung

Die Einfuhrung von Archivsystemen in einer R/3-Umgebung

wirft sowohl eine Reihe organisatorischer, wie auch eine Reihe
technischer Fragen auf. Diese beginnen bei der qualifizierten
Erfassung des Mengengerusts anfallender Dokumente und Spei-
chervolumina, erstrecken sich uber die Analyse der Dokumen-
tenarten, Qualitaten, notwendigen Aufbereitungsschritte und set-
zen sich fort bei der Festlegung geeigneter Erfassungs-szenarien
und deren Organisation. Auch die Auswahl der geeigneten
Scanner-, Bildschirm- und Jukebox-Technik geh6rt dazu. Es gilt
ebenso festzulegen, was Problem-Dokumente sind (solche die
nicht gescannt werden k6nnen) und was mit ihnen zu gesche-
hen hat.
Insbesondere beim Einsatz von Szenarien des fruhen Erfassens
gilt es, neue Arbeitsablaufe zu konzipieren und alte Verfahren
kritisch auf Sinn und Effizienz zu uberprufen.
All dies kann mit Hilfe eines unternehmensexternen Beraters
haufig besser und schneller erfolgen und setzt archiv-spezi-
fisches Know-How voraus. Es empfiehlt sich hier deshalb - wie
in vielen anderen R/3-Bereichen auch - sich bei der Erstein-
fUhrung qualifiziert beraten zu lassen. Das Beratungsspektrum
kann - abhangig von den eigenen Erfahrungen - von einer Ana-
lyse und Erstberatung bis hin zu einer Einfuhrungsbegleitung
und speziellen Adaption der Systeme an die betrieblichen An-
forderungen reichen.
Mit zunehmender Bildschirmarbeit steigen die Anforderungen
an die eingesetzten Bildschirme hinsichtlich Bildqualitat, Aufl6-
sung und Biidschirmgr6Be. Verstarkt gilt dies, wenn mit Mehr-
fenstertechnik und insbesondere wenn mit Images (einge-
scannten Belegen) gearbeitet wird. Hier gilt es also in den sau-
ren Apfel zu beiBen und entsprechend hochwertige Bildschirme
bereitzustellen - die Verfugbarkeit sehr guter und inzwischen
auch preiswerter groBformatiger Schirme kommt dem entgegen.
So sollten in dem beschriebenen Umfeld keine Bildschirme zum
Einsatz kommen, die kleiner als 17" sind und nicht mindestens
eine Aufl6sung von 1024x768 Bildpunkten aufweisen.

174
 5 ZusammenJassung

Fur die Scannerarbeitsplatze und dort, wo viel mit Images gear-

beitet wird, empfehlen sich eher 19" und 21" Bildschirme mit
1280x1024 oder sogar hoheren Auflosungen - die Bildschirm-
qualitat hat dort sehr direkte Einflusse auf die Arbeitseffizienz
und Arbeitsqualitat.
Der Einsatz von ArchiveLink zur Erfassung und Archivierung von
R/3-orientierten Belegen bietet eine ganze Reihe wesentlicher
Vorteile. Durch die Erfassung der auf Papier eingehenden Belege
mittels Scanner sowie die Ubernahme von in R/3 erzeugten Be-
legen und Drucklisten wird eine integrierte, einheitliche Verar-
beitung und sehr effiziente Bearbeitung ermoglicht. Auch wenn
damit noch nicht das papierlose Buro vollsrandig erreicht wer-
den mag, so ist es doch ein wesentlicher Schritt dazu.
Dokumente konnen hiermit zusammenhangend und ohne Me-
dienbruch verteilt, transportiert, gesucht und abgerufen werden;
Mehrfachzugriffe auch von anderen Lokationen aus werden
moglich. Lange Liegezeiten, Suchzeiten, ein Verlegen von Unter-
lagen, deren Nichtverfugbarkeit durch eine langerlaufende Bear-
beitung oder abwesende Sachbearbeiter werden weitgehend
eliminiert, Lagerkosten wesentlich reduziert und insgesamt der
DurchfluB von Dokumenten deutlich beschleunigt und damit
Arbeitsablaufe optimiert. Die Summe dieser Faktoren fuhrt in der
Regel zu einem relativ kurzen Return-of-Investrnent-Intervall.

175
 Integration von Fremdprodukten in Rl3 -
Vorteile der funktionalen Kopplung

Dipl.-Inf. Stephan Schilling

Fa. icons information & communication network systems gmbH,

Ennepetal

176
 1. Einleitung

1 Uberblick
Die SAP AG hat auf der CeBIT '94 verschiedene Integrations-
schnittstellen zur Anbindung von Desktop-Anwendungen vorge-
stellt. 1m Desktop-Bereich unterstutzt die SAP im System Rl3 die
Microsoft-Standards OLE und ODBC. Daruber hinaus werden in
einem Software Development-Kit Techniken zur Verfugung ge-
stellt, die eine direkte, funktionale Kopplung mit dem System
ermaglichen. In einer solchen Lasung wird auf der Programm-
Programm-Ebene kommuniziert. Damit werden die bisherigen
Maglichkeiten des Download und des Dateitransfers weit uber-
troffen.
Mit den Techniken solI eine Integration vorhandener Desktop-
Anwendungen ermaglicht werden, urn die Geschaftsprozesse
des Kunden homogener und schlanker zu gestalten. Beispiels-
weise ist nun eine aktive Einbindung von Standardwerkzeugen,
wie MS-Excel oder MS-WinWord, an beliebiger Stelle im Rl3-
System maglich.
Auch Softwarehauser haben uber diese Schnittstelle die Maglich-
keit, ihre Standardanwendungen an das System Rl3 anzubinden.
Dies ist sicherlich ein Mehrwert fur das Softwarehaus, aber auch
fur die SAP AG, da sich damit der Nutzen der Rl3-
Kundenzielgruppen erweitern JafSt. Urn diese Softwarehauser zu
fOrdern, hat daher die SAP AG zusammen mit der ASPRI Trading
GmbH, einem Unternehmen der PRISMA-Gruppe, das Desktop
Integration Center (DICE) gegrundet. Dber dieses Center unter-
sWtzt die SAP AG autorisierte Desktop-Integratoren bei Entwick-
lung, Marketing und Vertrieb solcher Lasungen.
icons ist seit August '94 einer der ersten autorisierten Partner
und machte seine Erfahrungen in einer solchen Anwendungs-
umgebung am konkreten Beispiel vorstellen.
Zunachst werden die Grunde fUr Desktop-Integration und De-
zentralisierung dargestellt. Nach der Vorstellung einer konkreten
Aufgabenstellung wird der Ansatz zur Lasung skizziert. Das ein-
zubindende System wird per funktionaler Kopplung an das Rl3
angeschlossen. Die dazu notwendigen Schritte werden darge-
stellt. Die Starken und Schwachen dieser Integration werden
herausgearbeitet.

177
2 Anwenaungsgebiete fur Desktop-Integration

2 Anwendungsgebiete fur Desktop-Integration

2.1 Individuelle Frontends

Individuelle Frontends sind meist Einzelplatzanwendungen, ba-
sierend auf einer grafischen OberfHiche (MS-Windows, Motif,
Macintosh oder PM). Diese Anwendungen sind meist branchen-
oder auch kundenspezifisch designed und implementiert. Damit
sind Datenerfassungsmasken und Auswertungen mbglich, ohne
daB der Anwender eine Rl3-Ausbildung benbtigt. Dies senkt den
Schulungsaufwand und erhbht vor allem auch die Akzeptanz der
DV in den hbheren Hierarchiestufen.
Eine weitere Anwendungsmbglichkeit solcher individueller
Frontends kann darin bestehen, im Frontend eine schnelle Da-
tenerfassung bei haufig genutzten Rl3-Transaktionen zu errei-
chen. Die erfaBten Daten werden dann zu einem spateren Zeit-
punkt an Rl3 tibertragen und dort verbucht. Dabei ist fUr einen
reibungslosen Ablauf allerdings zu beachten, daB mbglichst viele
der fUr die Datenintegritat notwendigen Verprobungen auf dem
Frontend ausgeftihrt werden kbnnen.
SchlieBlich lassen sich tiber solche individuellen Frontends auch
weitere Technologien einbinden. Beispielsweise kann das Rl3-
Frontend so urn die Mbglichkeiten des CSTA (Computer Suppor-
ted Telephony Application) erweitert werden. Kundendaten am
Schirm und Incoming- wie Outgoing-Calls kbnnen so integriert
werden.

2.2 Offline Applications

Nicht jeder Anwender des Rl3-Systems hat permanent eine Rl3-
Workstation im Zugriff. Einige Geschaftsprozesse laufen optima-
lerweise auf Notebooks respektive Laptops abo Beispielsweise
trifft dies fUr die im AuBendienst einer Firma tatigen Mitarbeiter
zu. Die AuBendienststeuerung ist das Anwendungsbeispiel fUr
die Offline-Applikationen. Der AuBendienstier ist am wertvoll-
sten im Dienst am Kunden.

178
 2.3 Desktop Tool Integration

Die Zeit im Buro sollte also moglichst minimal gehalten werden.

Besuchsberichte, Reisekostenabrechnungen etc. sollten nicht erst
im Buro, sondern wahrend der AuBendiensnatigkeit, beispiels-
weise abends im Hotel, erfaBt werden. Die zeitnahe Erfassung
dieser Daten erhoht zudem auch die Qualitat der Information.
icons hat als Projektpartner der SAP AG eine Reisekostenvorer-
fassung (RKV) auf Basis von MS-Access entwickelt, die genau
diese Funktionalitat ermoglicht. Diese Offline-Applikation ist
vom Design her nahezu identisch mit der HR-Komponente. Zur
Initialisierung werden auf das Notebook die entsprechenden Be-
nutzerdaten (Infotypen der Entitat Mitarbeiter) ink!. der Verpro-
bungstabellen, wie Spesenberechtigungen etc., geladen. Der Mit-
arbeiter kann seine Reisen, Belege, Kostenaufteilungen etc. offli-
ne erfassen. Beim nachsten Aufenthalt im Biiro wird dann das
Notebook in das Rl3-Netz integriert. Dazu ist lediglich die
TCP/IP-Protokollsoftware auf dem Notebook erforderlich; das
SAPGUI-Frontend wird nicht benotigt. Das Notebook meldet sich
am Applikationsserver an, iibertragt die Daten und erhalt direkt
die Riickmeldung iiber den Verarbeitungsstatus der Daten im
Rl3-System. Ebenso ist eine WAN-Verbindung (ISDN, X.25 ... )
uber das ppp-protokoll innerhalb von TCP/IP moglich.
Die Offline-Applikation 'Reisekostenvorerfassung' wird zur de-
taillierten technischen Darstellung im folgenden genutzt.

2.3 Desktop Tool Integration

Microsoft Windows hat sich als Standard im Bereich der
Desktop-Oberflachen etabliert. Applikationen aus dem Bereich
der Biirokommunikation, wie Textverarbeitung, Kalkulation oder
Groupware, basieren auf dies em Industriestandard und zeichnen
sich durch urnfassende Funktionalitat, hohen Benutzerkornfort
und groBe Flexibilitat aus. Beispielsweise ist die Serienbrietkom-
ponente des Produktes Word fiir Windows wesentlich leistungs-
starker als die SAP-eigene Komponente SAP-Script. Die Forde-
rung vieler Anwender, diese Systeme in die betriebswirtschaftli-
chen Prozesse miteinzubinden, ist daher nur allzu verstandlich.
Minels der dokumentierten Schnittstellen ist eine Einbettung von
MS-Office oder Lotus-Smartsuite-Produkten moglich und zum
Teil bereits realisiert.

179
3 Schnittstellenvarianten

Auch die Auswertung der R/3-Daten mit Datenbank-Toois ist

dieser Kategorie zuzuordnen. Beispielsweise kbnnen Auswer-
tungen direkt tiber den SQL*ReportWriter von ORACLE gefahren
werden. Dies setzt allerdings gute Kenntnisse des SAP-
Datenmodells voraus.

2.4 Fremdanwendungen
Ein weiterer Einsatzbereich der Schnittstellen ist die Integration
mit anderen MultiUser-Anwendungen auf weiteren Servern in
der Anwendungsumgebung. So kbnnen kunden- oder branchen-
spezifische Funktionalitaten das betriebswirtschaftliche Spektrum
von R/3 erweitern.
Ein typischer Anwendungsfall ist die Einfuhrungsproblematik
von R/3 in eine vorhandene Umgebung. Die Einftihrung wird
meist schrittweise erfolgen, und nicht aIle bereits vorhandenen
Applikationen kbnnen durch R/3 abgedeckt werden. Anderer-
seits besteht aber eine hohe Verflechtung der Altdaten mit den
betriebswirtschaftlichen Daten im R/3. Vorhandene Applikatio-
nen, die neben dem R/3-System existent bleiben soIlen, kbnnen
mittels der funktionalen Kopplung in die neuen Ablaufe bruch-
frei integriert werden.

3 Schnittstellenvarianten

Die folgende Grafik erlautert die Architektur der zwei Schnittstel-

lenvarianten:

1. des direkten SQL-Zugriffs und

2. des Remote-Function-Calls

180
 3.2 RFC-CAILs

Abbildung 3.1:
Architektur der
Schnittstellen-
varianten (Quelle:
SAP)

--- SAP Standard

Customer specific

Microsoft Standard

3.1 OOSC I Native SQl

In alteren SAP-Releases war diese Mbglichkeit des Zugriffs nur
beschrankt einsatzfahig, da aus Performancegriinden teilweise
Informationen geclustert in Long-Feldern abgelegt waren. 1m
Release 2.2, welches im Herbst 94 ausgeliefert wurde, geht der
Trend allerdings dahin, alle Anwendungsdaten transparent abzu-
legen. Damit ist ein direkter Zugriff auf die Daten entweder tiber
ODBC oder Native-SQL des Datenbankherstellers mbglich Csiehe
Abbildung 3.1)
Diese Schnittstelle sollte nicht tiberbewertet werden, da sie eini-
gen Einschrankungen unterliegt. SAP selbst gibt die Empfehlung,
keine Updates mittels SQL durchzuftihren; ein sehr detailliertes
Verstandnis des Datenmodells, ca. 4000 Tabellen, ist unbedingt
erforderlich.

3.2 RFC-CAlls
Der Remote-Function-Call ist eine Variante der Programm-
Programm-Kommunikation. SAP-seitig existiert ein Set von vor-
gefertigten Funktionsbausteinen Csiehe Abbildung 3.1: Standard
Business Function Library), das einmal aktiviert als Schnittstelle
zu den R/3-Modulen agiert. Diese Standard-Funktionsbibliothek
kann durch die individuelle Realisierung von Funktionsbaustei-

181
3 Schnittstellenvarianten

nen erweitert werden (siehe Abbildung 3.1: customer specific

function modules). Diese Erweiterungen erfolgen mittels der R/3-
Ent-wicklungsumgebung. FOr jeden vorhandenen Funktionsbau-
stein kann im SAP-System mittels Generatortechnologie eine DLL
erzeugt werden. Diese DLL enthalt die Aufruffunktionen fur die
Funktionsbausteine auf dem Applikationsserver. Desweiteren
existiert eine Standard-DLL mit vorgefertigten Autorisierungs-
funktionen fOr die Anmeldung und Abmeldung an das System;
das Autorisierungskonzept von R/3 wird voll unterstOtzt. Mehrfa-
che RFC-Aufrufe sind mbglich.
Das Arbeitsplatzprogramm, beispielsweise die RKV unter MS-
Access, ladt diese DLLs und ruft die Funktionen in einer definier-
ten Ablauffolge auf. Dber den Aufruf von Funktionsbausteinen
kann dann der Datenaustausch in be ide Richtungen erfolgen.
Auf dem Applikationsserver kann entweder eine Batch-Input
Mappe angelegt und befollt oder eine Transaktion gestartet wer-
den. Datenaustauschstruktur ist ein allokierter Bereich im Haupt-
speicher, auf den die DLL und die Desktop-Anwendung mit vor-
gefertigten Funktionen (ebenfalls Elemente der Standard-DLL)
gemeinsam zugreifen kbnnen. Innerhalb des Funktionsbausteins
werden die Daten in ABAP-Variablen zwischengespeichert.
Das R/3 System bietet eine effektive Mbglichkeit an, aus ABAP-
Funktionen/Funktionsbausteinen DLLs zu generieren. Hierzu ist
es lediglich erforderlich, aus der R/3-Umgebung die Transaktion
SE37 aufzurufen. Es werden einige Parameter (RFC-Fahigkeit,
Funktionsbaustein ... ) erfragt und die benbtigte DLL generiert.
Der Datentransfermodus "Call-Transaction" bietet hierbei sicher-
lich die kornfortablere Schnittstelle, da Daten im R/3-System so-
fort ausgewertet werden (z.B. Reisen werden direkt angelegt,
und die vergebenen Reisenummern kbnnen zuruckgegeben
werden).
Das Generieren von Batch-Input-Mappen kann in manchen Fal-
len aus organisatorischen Grunden von Vorteil sein. Dieser Mo-
dus erlaubt eine hbhere Kontrolle der Daten, die in das R/3-
System Obertragen werden. Der Nachteil liegt hierbei im erhbh-
ten Arbeitsaufwand beim zentralen Sachbearbeiter, der letztend-
lich die angelegten Mappen abspielen muB (und, z.B. im FaIle
der RKV, den Antragsteller auf Fehler aufmerksam machen muB).

182
 4.1 Konkrete Aufgabenstellung

Die Generierung von Programmcodes auf der SAP-Seite erfolgt

also bezogen auf ausgewahlte Funktionsbausteine, da pro Bau-
stein die spezifische Aufrufschnittstelle versorgt werden muB.
Die Generierung schlieBt den automatischen Transport des
Codes auf den PC ein, es handelt sich also urn eine Cross-
Generierung. Zur Zeit erfolgt das Coding in C.
Der Generiervorgang ist template-gesteuert. Durch Definition
weiterer Templates kbnnen die Anwendungsmbglichkeiten des
Generators erweitert werden, beispielsweise auf weitere Pro-
grammiersprachen.
Bei Notwendigkeit des schreibenden Zugriffs auf der SAP-Seite
sollte der RFC als Integrationsmechanismus genutzt werden.
Durch den Einsatz von Funktionsbausteinen auf dem Applikati-
onsserver wird die Konsistenz der SAP-Objekte in jedem Fall
gewahrleistet. Desweiteren ist eher eine Aufwartskompatibilitat
gegeben als bei direktem SQL-Zugriff.

4 EntwicklungsschriHe zur Integration

In Kapitel 4 wird die Variante des RFC-Calls weiter detailliert und

mit einigen Code-Auszugen illustriert.
Welche Schritte sind nun notwendig, urn eine Integration zu R/3
zu implementieren?

4.1 Konkrete Aufgabenstellung

Gefordert ist das folgende Szenario: Entwicklung einer Reiseko-
stenvorerfassung, mit der offline, vom R/3-System aus, eine Er-
fassung von Reisedaten mbglich ist. 1m einzelnen sind dies:

• die Reise-Rahmendaten, wie Ziel, Beginn- und Endtermin,

Fahrtkilometer, zuzuordnende Kostenstelle etc.
• Belegdaten in verschiedenen Wahrungen
• Zwischenziele
• Abzugsdaten
• Kostenaufteilungen fUr Belege, Kilometer und Reisedaten

183
4 Entwicklungsscbritte zur Integration

Die Reisen sollen mbglichst weitgehend auf dem Laptop ver-

probt werden gegen:

• Anwenderrechte
• Oberschneidungen zu anderen Reisen
• Spesenberechtigungen
• Wahrungsdaten
• Kostenstellen
Nach dem Transfer der Reisedaten sollte die Kontrolle tiber die
Reise, also auch das Recht zur Nachbesserung, auf der R/3-Seite
verbleiben.

4.2 Losungskonzept
Als Entwicklungswerkzeug fUr die Offline-Datenerfassung wird
in diesem Fall MS-Access aus folgenden Grunden gewahlt: MS-
Access ist im Exclusiv-Betrieb eine akzeptable Datenhaltungs-
komponente. Die OberfIachen-Gestaltung kann vbllig "Win-
dows-like" erfolgen und damit auch stark an die R/3-0ber-
flachenstandards angelehnt werden. Die notwendigen DLL-
Aufrufe kbnnen aus Access-Basic heraus erfolgen. Zudem ist MS-
Access als Endbenutzerwerkzeug vie len potentiellen Nutzern be-
reits heute bekannt. Nachteilig wirken sich in der Implementie-
rungsphase die verschiedenen am Markt befindlichen Basic-
Dialekte der Firma Microsoft aus.
Auf der Desktop-Seite wird 1: 1 zum Datenmodell unter R/3 der
Reisekostenteil modelliert. Damit entstehen beim Transfer keine
Probleme der Datentransformation auf differente Strukturen.
Die Lbsung wird mittels der RFC-Technologie implementiert, da
der schreibende Zugriff auf die R/3-Daten geplant ist. In der fol-
genden Grafik 4.1 ist die oben bereits beschriebene Architektur
fUr dieses Beispiel konkretisiert dargestellt.

184
 4.2 L6sungskonzept

Abbildung 4.1:
RFC-Architektur PC

Funktlonsmodule

Interne Tabellen
RFC

ItCreate
R/cOpen, RfcClose
ItDelete
ItGelline
ltAppIine generierte Funktlonen

~ LT_Inil, Trip_Creale

Hauptspelcher: interne Tabellen I

I
I I
~

I SAP RI3
J
ASAP Funktlonsbausteln

LT_INIT
Trip_Create

In der Abbildung 4.1 werden die unterschiedlichen Funktionali-

taten des RFC zu Funktionsgruppen zusammengefaBt und in se-
paraten Rahmen dargestellt. Auf der Client-Seite entspricht dies
einzelnen • .DLL-Dateien, wahrend sich auf der SelVerseite ABAP-
Funktionen befinden.
Zunachst ist hierbei die Gruppe der Funktionen zu erwahnen,
die den Verbindungsauf- und -abbau zum R/3-Host regeln. Sie
wird hier 'RFe' genannt.
Der Datenaustausch erfolgt tiber interne Tabellen, deren Pfiege
tiber die Routinen der Funktionsgruppe 'interne Tabellen' erfolgt.
Die 'generierten Funktionen' sind Aufrufe der 'ABAP-Funk-
tionsbausteine'. Eine charakteristische ABAP-Routine wird im
folgenden Listing am Beispiel der Funktion TRIP_CREATE dar-
gestellt.

185
4 Entwicklungsschritte zur Integration

Das Beispiel zeigt auf, wie die ABAP-Funktion in Abhangigkeit

von den Aufrufpararnetern weitere Funktionen fUr das Anlegen
von Batch-Inputrnappen oder zurn direkten Generieren von Rei-
sen aufruft und eine Fehlerbearbeitung durchfilhrt:

FUNCTION TRIP CREATE.

CASE BDCMODE.
WHEN 'B'. 'Batch Input'

PERFORM BDC OPEN GROUP

USING CLIENT GROUP KEEP USER
SUBRC.

CASE SUBRC.
WHEN O.
LOOP AT REISE.
PERFORM PERNR- REINR- IN IT
TABLES TREISE.

PERFORM PROI - PERNR- REINR

TABLES TABZUG BELEG TKMVER TKOSTB
TKOSTR.TVORSC TREISE TZIELE
TZWECK.

PERFORM BDC INSERT

USING SUBRC.

CASE SUBRC.
WHEN O.
WHEN 2I.
RAISE I INTERNAL ERROR.
ENDCASE.

END LOOP .

PERFORM BDC - CLOSE- GROUP

USING SUBRC.

WHEN II.
RAISE 0- CLIENT- INVALID.
ENDCASE.

186
 4.2 L6sungskonzept

WHEN 'C'. 'Call Transaction'

LOOP AT TREISE.

PERFORM PERNR- REINR- INIT

TABLES TREISE.

PERFORM PROl - PERNR- REINR

TABLES TABZUG BELEG TKMVER TKOSTB TKOSTR
TVORSC TREISE TZIELE TZWECK.

PERFORM CALL TCODE

USING DCODE UPDAT SUBRC.

PERFORM WRITEMESSAGE "FUllen der Returnwert

TABLES TREISE TMESSG "-Tabelle
USING SUBRC SY-LANGU SY-MSGID SY-MSGTY
SY-MSGNO SY-MSGVl SY-MSGV2 SY-MSGV3
SY-MSGV4.
ENDLOOP .

WHEN OTHERS.
RAISE BDC MODE INVALID.
ENDCASE.

ENDFUNCTI ON.

Ftir den Zugriff auf den R/3-Host ist zu entscheiden, ob die

Desktop-Benutzer als Sammelaccounts unter R/3 behandelt wer-
den oder ob pro Desktop-Benutzer auch ein SAP-Benutzer ein-
getragen ist. Sammelbenutzer konnten sich beispielsweise zu-
satzlich tiber ihre Personalnummer Cvgl. Stammsatz Mitarbeiter)
im System identifizieren. Nur in der zweiten Variante kann die
Herkunft eines Datensatzes sicher nachvollzogen werden.

187
4 Entwicklungsschritte zur Integration

4.3 Softwareentwicklung

4.3.1 Desktop
Auf dem Desktop ist die Applikation unter MS-Access zu entwik-
keln. Diese beinhaltet mehrere Masken, die die einzelnen Info-
typen des RK-Stamms beinhalten. Die folgende Abbildung zeigt
die Maske fur den graBen Teil der Reiserahmendaten

Abbildung 4.2:
Maske der Reise-
rahmendaten

Die Abbildung 4.3 zeigt die Code-Struktur fUr den Transfer einer
Reise. Die Aufrufe der SAP-seitig vorgenerierten DLL-Funktionen
kann dabei nicht direkt aus der Makra-Sprache von MS-Access
erfolgen, sondern ist in Access Basic zu realisieren.

188
 4.3 Sojtwareentwicklung

Abbildung 4.3:
Codestruktur RFC-Vorbereltung

=
'lRslxllel ItCresie(Reise, Recon:lllqe)

,
Aufbau der intemen 1RanIIe2 =1tCrUe(Feh1er, Recon:lllqe)
Tabellen

ZeilenHarole =ItAppUne('lRslxllel)
ggf. FOlien der CopyTorr (Zei1enHBlldle, ReiaedsIen)
intemen Tabellen

B&

Ve~=

,
Verblndungsaufbau RfcOpen (DesIinatioIl, Hostmme, Sysnr, G81ews,y,
zu SAP R/3 Client, User, Psaaword, Uquage,I.ogHag)

,
Trip_Crnat.(VerbiMlqahandle, TnnsfermodU!l,
Aufruf des ASAP -
Client. 'lRslxllel, 1HInIIe2, ... )
Funktlonsbaustein

Verblndungsabbau

-~- ....,
ZeilenHsolle = ItGetline('ffiandIe2, Zelle)

,
Rlkkgabe = CopyFromlT (ZellenHarole)
Auswerten der
FehJerbebslldhq (Rlkkgabe)
intemen Tabellen ..

I tDeleb! ('IHInIlel)
LOschen der I tDeleb! ('IHInIle2)
intemen Tabellen ..

4.3.2 Backend
Auf dem R/3-ApplikationsseIVer wurde in diesem Projekt von
der SAP ein eigener Funktionsbaustein entwickelt. Dieser bein-
haltet die Funktionen zur Datenbereitstellung und zur Datenauf-
nahme vom Desktop.

189
 4 Entwicklungsschritte zur Integration

Die Funktionsbausteine mussen in der Funktionsbibliothek inte-

griert sein. Bei Entwicklung eigener Bausteine muB diese Inte-
gration selbst vorgenommen und bei jedem Einspielen eines
neuen Releases oder PutLeveis nachgefahren werden.

4.3.3 Middleware
Als Middleware kommen die SAP-seitig vorgenerierten DLL-
Funktionen zum Einsatz. Diese konnen ohne weitere Anpassun-
gen eingesetzt werden. Damit wird auch die vollstandige Autori-
sierung des Desktop-Anwenders als SAP-Benutzer gewahrleistet.

Abbildung 4.4:
Maske Anwenderdaten

Die abgebildete Maske der Anwenderdaten splittet sich in 3 Be-

reiche. Der obere Teil ermoglicht die Eingabe eines PaBwortes
fur die Desktoplosung selbst Cunabhangig yom R/3-System). Der
mittlere Datenblock bildet die Parameter fur den Verbindungs-
aufbau zum R/3-System. Hierbei werden Client, User, Zielsystem,
Mode, Hostname, Systernnummer, Sprache und Gatewaydaten
gepflegt. Das PaBwort selbst wird hier aus Sicherheitsgrunden
nicht abgelegt - es muB fur jeden Connect eingegeben werden.
1m abschlieBenden Datenblock kann der Anwender wahlen,
welchen Transfermodus er verwenden mochte. Wird Batch-Input
gewahlt, so besteht die Moglichkeit, den Namen der anzulegen-
den Mappe vorzugeben.

190
 4.3 SoJtwareentwicklung

4.3.4 Testing, Dokumentation

Insbesondere sollte im Testverfahren das Verhalten des Systems
bei grolSen zu transferierenden Datenmengen gepruft werden,
denn das Speichermanagement beim Datenaustausch ist ein sehr
komplexer Bereich.

4.3.5 Zertifizierung
1m FaIle einer Produktentwicklung empfiehlt es sich, die entwik-
kelte Losung vom DICE zertifizieren zu lassen. Innerhalb dieser
Zertifizierung wird die technische Integration gepruft, es wird
also nur die Integration, nicht die Qualitat der Gesamtlosung
zertifiziert. Die Zertifizierung erfolgt bezogen auf eine bestimmte
Systemkonfiguration und ein SAP-Release, in ganz speziellen
Fallen sogar nur auf Putlevel-Ebene.

5 Starken und Probleme des Ansatzes

Vor der Diskussion der technischen Problematiken soIl zunachst

die Betrachtung der Anwendungseite stehen: Ober den RFC-
Ansatz ist eine volle Integration von Desktop-Losungen moglich.
Auch der schreibende Zugriff verursacht keine Konsistenzpro-
bleme innerhalb von Rl3. 1m Vergleich zu den bisherigen Mog-
lichkeiten des Dateitransfers erhalt der Desktop-Anwender eine
direkte Rtickmeldung tiber den Verarbeitungsstand der Daten.
Bezogen auf die Funktionsbreite der Kopplung bleiben, nach
Einschatzung von icons, keine Wtinsche offen.
Allerdings mulS fur jede Anwendungssituation die Frage der
Redundanz geklart werden. Da gerade im Fall von Offline-
Applikationen redundant und nicht auf den Rl3-Daten direkt ge-
arbeitet wird, besteht in jedem Fall Klarungsbedarf, welche Da-
ten als Masterdaten gewertet werden. In den allermeisten Situa-
tionen werden dies wohl die Rl3-Daten seinj einmal transferierte
Desktop-Daten sind dann gegen Manipulation zu schtitzen.

191
5 Starken und Problerne des Ansatzes

Nun zu den technischen Gesichtspunkten: Die Kopplung erfolgt

tiber TCP/ IP. Die Middleware ftir den Connect in Form der vor-
generierten DLL kann ohne Veranderungen eingesetzt werden.
Die Funktionen haben allerdings sehr breite Parameterleisten,
deren Versorgung exakt stimmen muB, da sonst evtl. nicht nach-
vollziehbare Folgefehler auftreten. Leider ist der Hauptspeicher-
bedarf ftir den Transfer nicht vorauszuberechnen. Es sollte also
mit einer defensiven Strategie gearbeitet werden: eher mehrere
Calls mit kleinen Datenvolumen.
Die Kopplung erfolgt sehr performant, damit ist auch ein Zugang
tiber WAN Cbspw. SLIP) realisierbar.
Zusammenfassend kann gesagt werden, daB es sich bei der RFC-
Integration urn eine technisch ausgereifte Konzeption handelt.
Zur Zeit kann zwar noch auf wenig praktische Erfahrungen
verwiesen werden, aber es ist ein Nutzen dieser Technologie in
vielfaltigen Einsatzbereichen zu erwarten.

192
Integration heterogener Systeme:
Kopplung COPICS-MRP und SAP-Rl3-
Einkauf

Dipl-Inf. (FH) Karl-Heinz Reutter

Fa. TANGRAM, Gesellschaft fur Informations- und Kommunika-

tionsmanagement mbH, Gartringen

Prof. Dr.-Ing. Herbert Glockle

Fachhochschule fOr Technik und Wirtschaft, Reutlingen

193
1 Vberblick

1 Uberblick

Der Generationswechsel in der Architektur der Standardsoftware

von der Mainframe- zur Client-Server-Welt zwingt viele Unter-
nehmen, diesen Weg mitzugehen, unabhangig davon, ob sie
sich der Kostenvorteile oder eines zusatzlichen Nutzens wirklich
sicher sind. Wenn marktpragende Systeme, wie z.B. SAP-R/3,
eindeutig ais die neue strategische Linie der Softwarehersteller
erkennbar sind, so mulS sich der Nutzer fragen, wie er vorgehen
mulS, urn in seinem Hause eine nahezu komplett neue Daten-
verarbeitung aufzubauen und wie er dabei trotzdem den Iaufen-
den Tagesbetrieb aufrechterhalten kann.
Abwarten ist keine zulassige Strategie, da eine statische und
veraltete Software die Iaufende Neugestaltung der Geschaftspro-
zesse Ietztlich nicht mittragen kann und zum Hemmschuh wird.
Der Druck auf die DV-Abteilung wi.irde nur grblSer, und wertvol-
Ie, nutzbare Zeit ginge verloren.
Der ErneuerungsprozelS ist so urnfassend, wie dies in fruheren
Jahren noch nie in so kurzer Zeit der Fall war. Die Hardwarear-
chitektur mulS neu gestaltet werden, ein wesentlicher Schwer-
punkt liegt auf dem Einsatz von Netzwerken, die Betriebssyste-
me sind neu und deutlich anders in der Handhabung ais die der
GrolSrechnersysteme, und nicht zuIetzt setzt sich die graphische
Benutzeroberflache auf dem PC durch. Zu allem DberflulS und
oft zum Leidwesen der DV-Abteilung, IiilSt der PC dem Benutzer
neue Freiheiten, die dieser auch ausfuhrlich nutzt.
Das Produkt COPICS hat im Bereich der Bedarfsermittlung, d.h.
in seinem Modul MRP, einige Starken. Das Einkaufsmodul bIeibt
jedoch in seiner Funktionalitat hinter dem zuruck, was SAP in
seinem Modul MM-Einkauf bietet. Der dringende Wunsch nach
erweiterter Funktionalitat in dies em Bereich und die Erkenntnis,
daIS die notwendige Neuorientierung so schnell wie mbglich an-
gegangen werden mulS, war im vorliegenden Fall der Ausibser,
urn in eine kontrollierte, schrittweise Abibsestrategie einzustei-
gen, die weder die Projektverantwortlichen, noch die Benutzer
der Systeme und auch nicht die Finanzkraft des Unternehmens
ti berfordert.

194
 2 StuJenkonzept

Durch die Entwieklung sollte gezeigt werden, wie die Kompo-

nente Materialwirtschaft des SAP-R/3-Systems mit Hilfe einer
mbglichst einfachen und mit geringem Aufwand zu realisieren-
den Lbsung an IBM COPICS angekoppelt werden kann.

2 Stufenkonzept
Ein Stufenkonzept bietet zunachst den Vorteil eines begrenzten
Risikos. Es bringt aber den Nachteil von temporaren Schnittstel-
len mit sieh, die sieh von Schritt zu Schritt verschieben und da-
bei jedesmal neu aufgebaut werden mi.issen. Dies verursacht
Aufwand und Kosten.
Die Wahl der riehtigen Stu fen ist eine wiehtige konzeptionelle
Vorarbeit. Sind die Schritte zu klein, so ergeben sich Schwierig-
keiten, da Anwender mbglicherweise ihre Informationen zur
Abwicklung ihrer Geschaftsprozesse aus mehreren Systemen zu-
sammenstellen mi.issen und dies, entsprechend des Projektfort-
schritts, immer wieder in neuer Form. Sind die Schritte zu groB,
so wird der Sinn eines Stufenkonzepts, der in einem i.iberschau-
baren Risiko liegt, nieht erreieht. Die Mbglichkeit, die nutzbaren
Krafte auf relativ wenige Aufgaben zu konzentrieren, geht verlo-
ren.
Insbesondere sollte der erste Schritt beim Aufbruch in die Client-
Server- und in die SAP-R/3-Welt geeignet sein, Erfahrungen zu
sammeln. Erfahrungen einerseits im Umgang mit den neuen Sy-
stemen und zum anderen bei der Einfi.ihrung einer neuen Or-
ganisation, mit der diese Systemwelt ebenso sieher betrieben
werden kann, wie dies bisher beim Mainframe der Fall war.

195
3 L6sungsansatz fur die Systemkopplung COPICS und SAP-R/3

3 Losungsansatz fur die Systemkopplung COPICS

und SAP-Rl3
1m Rahmen des ersten Schritts, wenn die Mainframe-Architektur
erstmalig im Unternehmen auf die Client-Server-Architektur trifft,
sind neben den Applikationsschnittstellen auch die Hardware-
und Kommunikationsschnittstellen zu realisieren. Bleibt man bei
der Erneuerung dem Hardwarehersteller treu, so kann man hier
in aller Regel auf vorhandene Lbsungen zUrUckgreifen, da Tools
zur Kopplung der Rechner verfUgbar sind. Die Aufgabe, diese
Verbindung auf der Ebene der Basiskommunikation zu parame-
trisieren, war im hier vorliegenden Beispiel [1) mit verhaltnisma-
Big wenig Aufwand zu Ibsen. Das SAP-System wurde auf einer
RS-6000/520 installiert, und die Kopplung zum IBM-Hostsystem,
das unter dem Betriebsystem VSE/ MVS lauft, wtirde uber das
Produkt AIX 3270 Host Connection Programm/6000 hergestellt.
Bedeutend schwieriger ist die Definition und Realisierung der
Applikationsschnittstelle zwischen dem SAP-System und COPICS.
Zielsetzung war es, das Modul Einkauf des SAP-Systems zu inte-
grieren, ohne die Funktionalitat der COPICS Bedarfsplanung
MRP zu beeintrachtigen. Die Kopplung sollte so gestaltet sein,
daB weder der Materialdisponent, noch der Einkaufer Einschran-
kungen in ihrer Tatigkeit hinnehmen mussen.
Eine wichtige Forderung fur die Anbindung war, daB die rele-
vanten Erweiterungen des SAP-R/3-Systems so strukturiert sein
mussen, daB keine Veranderungen im Standard des SAP-Systems
notwendig sind, die die Releasefahigkeit gefahrden kbnnen.
Nachfolgend sind einige Fragen aufgefuhrt, die im Rahmen der
Entwicklungsarbeiten zur Applikationsschnittstelle geklart wer-
den muBten:
• Welche Informationen mussen zur Einkaufsabwicklung zwi-
schen den Systemen rnindestens ausgetauscht werden? Mus-
sen hierzu Daten in beiden Systemen parallel abgebildet
und gepflegt werden?
• Sind Schnittstellen in beiden Systemen fUr externen Daten-
austausch vorhanden, und wie kbnnen sie evtl. genutzt
werden?

196
3 L6sungsansatz fur die Systemkopplung COPICS und SAP-R/3

Die Auswahl der Kommunikationsm6glichkeiten zwischen bei-

den Systemen ist durch ihre vorhandenen Schnittstellen festge-
legt. Das SAP R/3-System enthalt eine Reihe von Kommunika-
tionsschnittstellen [2) und unterstOtzt mehrere Protokolle. Dazu
zahlen zum Beispiel die Batch-Input-Schnittstelle oder die Kom-
munikationsschnittstellen CPI-C, RPC und EDI. Das RPC-
Protokoll erm6glicht die synchrone KontrollfluB- und Daten-
ilbergabe in Form von Prozeduraufrufen zwischen Programmen
in unterschiedlichen AdreBraumen.
Der Mechanismus ist vergleichbar mit Aufrufen von Unterproze-
duren in Programmen. Die beteiligten Programme laufen im all-
gemeinen auf unterschiedlichen physikalischen Rechnern. Mit
EDI ist der elektronische Austausch von strukturierten Daten
zwischen verschiedenen EDI-fahigen Anwendungen m6glich.
Diese Protokolle setzen ein Pendant im jeweils anderen System
voraus. Das System IBM COPICS enthalt aber keine der oben
genannten Schnittstellen zum protokollgestiltzten Informations-
austausch. Erganzend hierzu sind keine allgemeingilltigen
Schnittstellen zum direkten Im- oder Export externer Daten vor-
handen.
Urn der Forderung einer einfachen L6sung gerecht zu werden,
war der kleinste Nenner fur die Kommunikation zwischen bei-
den Systemen, der Austausch von Informationen ilber file-
transfer. Jeder Kommunikation liegen Regeln zugrunde. 1m
Hinblick auf den Datenaustausch zwischen beiden Systemen
sind also sowohl der protokollarische Ablauf des Dateiaustau-
sches, als auch der Inhalt der Datensatze, d.h. die auszutau-
schenden Datenstrukturen festzulegen. Zu den Regeln des pro-
tokollarischen Ablaufs geh6rt auch die Definition der Zeitpunkte,
zu denen Informationen zwischen beiden Systemen ausgetauscht
werden k6nnen.
Der Informationsaustausch ilber Dateien fuhrt dazu, daB Anwei-
sungen zur Steuerung des jeweils anderen Systems nur innerhalb
der Datensatze mitObergeben werden k6nnen. Daher wurden
Vorgangscodes definiert, die eine bestimmte Verarbeitung der
Datensatze im jeweils anderen System ausl6sen. Diese sind in
Abbildung 1 dargestellt und haben folgende Bedeutung:

197
3 L6sungsansatz fur die Systemkopplung COPICS und SAP-R/3

Abbildung 1
Nachrichten-
austausch zwischen COPICS SAP-R/3
COPICS und SAP-
Rl3 MAP Einkauf

AN - Bestellanforderung

BF - Bestellfrelgabe

BA - BesteilAnderung

BS - Bestellstornierung

WP - Warenelngang geplant
WU - Wareneingang ungeplant

AU - AOckJleferung

• AN - Bestellanforderung - Aufforderung der IBM COPICS-

Materialbedarfsplanung an den SAP-Einkauf, eine Ware
oder Dienstleistung zu bestellen.

AQckmeldungen vom SAP Rl3 Einkauf an IBM COPICS MRP:

• BA - Bestellanderung - Ruckmeldung einer Anderung der
BesteHmenge oder des geplanten Lieferdatums der Bestel-
lung.
• BF - Bestellfreigabe - Ruckmeldung der Freigabe der Bestel-
lung durch den Einkauf des Rl3-Systems.
• BS - Bestellstorno - Ruckmeldung der Stornierung einer Be-
steHung / Bestellposition im Rl3-System.
• wp/ WU - Wareneingang geplant / - ungeplant - Ruckmel-
dung eines Wareneingangs von bestellten Materialien.
• RU - Rucklieferung - Ruckmeldung einer Warenruckliefe-
rung an einen Lieferanten.

198
3 L6sungsansatz fur die Systemkopplung COPICS und SAP-R/3

In beiden Systemen mtissen folglich Schnittstellen zum Ein- und

Auslesen der auszutauschenden Dateien implementiert werden.
Das SAP Rl3-System sieht zum Einlesen externer Daten ein vor-
definiertes Verfahren, die Batch-Input-Schnittstelle vor. Zum
Einlesen der von IBM COPICS bereitgestellten Informationen in
das Modul SAP Rl3 Einkauf mulS ftir das Rl3-System ein Pro-
gramm geschrieben werden, das tiber diese Batch-Input-
Schnittstelle die auszutauschenden Daten importiert.
Auch fUr die Aufbereitung der Informationen, die vom SAP-Rl3
nach IBM COPICS tHeISen, mulS das SAP Rl3-System urn ein
weiteres Programm erganzt werden. Da im IBM COPICS nur
bestimmte Daten und Informationen aus dem Modul SAP Rl3-
Einkauf von Bedeutung sind, mulS dieses Programm die Selekti-
on und deren Bereitstellung ftir das IBM COPICS-System ermbg-
lichen.
Das System IBM COPICS verfUgt seinerseits nicht tiber parame-
trisierbare Schnittstellen. Deshalb wurden auch im System CO-
PICS neue Transaktionen zur Erstellung der Schnittstellendateien
und Programme zum Einlesen der erhaltenen Daten geschrieben.
1m Rahmen dieser Darstellung wird jedoch auf eine detaillierte
Beschreibung dieser Programme verzichtet und der Schwerpunkt
auf die SAP-Seite gelegt.

199
4 DatentransJer IBM COPICS nach SAP-R/3

4 Datentransfer IBM COPICS nach SAP-Rl3

Die Komponente Materialbedarfsplanung (MRP) des Systems IBM

COPICS ermittelt aufgrund von Kundenauftragen, Materialbe-
darfsvorhersagen und weiterer Daten, die fur eine geplante Peri-
ode bereitzustellenden Materialbedarfe. Die Materialbedarfe die-
nen als Grundlage fur geplante Fertigungs- bzw. Beschaffungs-
auftrage. Beschaffungsauftrage werden in der Regel durch einen
Materialdisponenten fur die Beschaffung durch den Einkauf er-
offnet. AIle notwendigen Informationen uber das zu beschaffen-
de Material, die erforderliche Menge und den gewi.inschten Be-
reitstellungsterrnin entnimmt der Einkauf den eroffneten Beschaf-
fungsauftragen.
Ein Schnittstellenprogramm ermoglicht das Auslesen der fur den
SAP R/3 Einkauf eroffneten Beschaffungsauftrage. Mit Hilfe einer
im IBM COPICS-System neu implementierten Transaktion erhalt
der Materialdisponent eine Liste derjenigen Auftrage, die er fur
den SAP R/3 Einkauf eroffnet. Anstatt die eroffneten Auftrage
intern im System weiterzuverarbeiten, sammelt die Transaktion
diese Daten in einer Schnittstellen-Datenbank. Die so bereitge-
stell ten Beschaffungsauftrage stehen nun zur Dbertragung an das
SAP R/3-System bereit. Die Dbertragung nimmt ein Programm
vor, das als UNIX-Shell-Script im Rechner des SAP R/3-Systems
(UNIX-Rechner) realisiert ist und yom UNIX-Rechner automatisch
zu vorher festgelegten Zeitpunkten gestartet wird. Dieses Pro-
gramm transferiert die bereitgestellten Beschaffungsauftrage in
zwei Schritten zum SAP R/3-System: Zuerst wird eine Ver-
bindung uber ein Netzwerk zum Host-Rechner des IBM COPICS-
Systems hergestellt und danach ein Host-Programm gestartet. Das
Host-Programm entnimmt nun aIle Datensatze der IBM COPICS-
Schnittstellen-Datenbank und speichert diese nach einer Format-
konvertierung in einer Zwischendatei im Host-Rechner abo Nach
dem Erzeugen der Zwischendatei kann diese durch das ver-
wendete Kommunikationswerkzeug zum UNIX-Rechner ubertra-
gen und dort gespeichert werden. Das angesprochene UNIX-
Shell-Script steuert den gesamten DbertragungsprozeB, meldet
sich nach erfolgreicher Dbertragung yom Host-Rechner ab und
fuhrt entsprechende MaBnahmen bei fehlerhafter Dber-

200
 4.1 Die BATCH-INP[ff-Schnittstelle

tragung durch, wie z.B. die Wiederholung des Dbertragungsvor-

gangs.
Bei der Dbertragung vom System IBM COPICS zum System SAP
R/3 sind alle Datensatze durch den Vorgangscode ' AN'
CBestellanforderung) gekennzeichnet. ]eder Datensatz enthalt
neben dies em Vorgangscode Informationen tiber das zu beschaf-
fende Material CSachnummer), die geplante Liefermenge
CBestellmenge) und den geplanten Liefertermin CBestelltermin).
Zur Beschreibung des zu beschaffenden Materials muB zumin-
dest ein Teil des Materialstamms in beiden Systemen parallel ab-
gebildet sein. Urn in beiden Systemen das gleiche Material tiber
einen Schltissel identifizieren zu k6nnen, werden bestimmte
Merkmale, wie z.B. der Nummernkreis oder die Klassifizierung,
in beiden Systemen identisch gepflegt.

Abbildung2
Schema der Daten-
ubernahme in das
SAP Rl3-System.

Das SAP R/3-System sieht zum Einlesen externer Daten ein vor-
definiertes Verfahren, die Batch-Input-Schnittstelle vor. Wie in
Abbildung 2 dargestellt, muBte zum Einlesen der tibertragenen
Beschaffungsauftrage in das Modul SAP R/3-Einkauf ein eigenes,
in ABAP/4 [3] geschriebenes Benutzerprogramm entwickelt wer-
den, das diese Schnittstelle verwendet. Es liest alle Satze der ge-
speicherten Datei satzweise tiber Batch-Input in das SAP R/3-
System ein. Dabei simuliert das Programm die Online-
Dateneingabe von Bestellanforderungen fur den Einkauf und
wandelt somit die freigegebenen IBM COPICS-Beschaffungs-
auftrage in R/3-Bestellanforderungen urn. Die eingespielten Be-
stellanforderungen dienen als Grundlage zur Bestellabwicklung
mit Hilfe des SAP R/3-Einkaufs.

4.1 Die BATCH·INPUT·Schnittstelle

Das SAP R/3-System sieht die Schnittstellenkomponente Batch-
Input zum Einspielen groBer Mengen externer Daten vor. Der
Mechanismus erlaubt es, externe Daten korrekt in die internen

201
4 DatentransJer IBM COPICS nach SAP-R/3

Tabellen einzuspielen. Batch-Input fuhrt automatisch Transak-

tionsaufrufe im System aus und simuliert mit Hilfe der eingelese-
nen Daten die Online-Eingaben eines Benutzers.
Ein spezifisches, von einem Benutzer realisiertes ABAP/ 4-
Programm liest in der Regel externe Daten aus einer sequentiel-
len Datei ein und stellt daraus die Transaktionsaufrufe und Da-
ten zusammen, aus denen eine sogenannte Batch-Input-Mappe
bestehen solI. Eine Batch-Input-Mappe besteht aus mehreren
Transaktionsaufrufen, die durch das Benutzerprogramm mit Da-
ten versehen wurden. Wenn eine Mappe Daten aus einer exter-
nen Quelle enthalt, bereitet das Benutzerprogramm diese Daten
auf, um den Anforderungen der entsprechenden Eingabefelder
der Dynpro 1 gerecht zu werden. Das heiBt, die Daten werden an
das Format angepaBt, das fUr die Eingabefelder der Dynpro
maBgeblich ist. Dabei mussen Daten fur aile MuBfelder der
Transaktion bereitgestellt werden.
Eine Mappe simuliert die Online-Eingabe von Daten und Trans-
aktionscodes. Dabei werden in der Regel dieselben Verfahren
wie im Dialogbetrieb eingesetzt. Die uber eine Mappe in die
Bildschirrnfelder eingegebenen Daten sind denselben Konsi-
stenzprufungen wie im Dialogbetrieb unterworfen. AuBerdem
werden Batch-Input-Mappen den systemseitigen Benutzerbe-
rechtigungsprufungen unterzogen.
Die wichtigsten Aspekte der Mappenschnittstelle sind:
• Asynchrone Verarbeitung,
• Datenubergabe fUr mehrere Transaktionen und
• synchrone Datenbankaktualisierung.
Wahrend der Verarbeitung wird so lange keine neue Transaktion
gestartet, bis die Daten aus der vorigen Transaktion auf der Da-
tenbank gespeichert wurden. Fur jede Mappe erzeugt das System
ein Verarbeitungsprotokoll.
Nachdem das Benutzerprogramm Batch-Input-Mappen erzeugt
hat, stehen die Mappen fUr die weitere Bearbeitung zur Verfu-
gung. Mit Hilfe der Funktion 'System Q Dienste Q Batcb-
Input Q Bearbeiten' kann ein Benutzer Batch-Input-Mappen
abspielen, 16schen, korrigieren, sperren und freigeben.

Dynpro: Entspricht weitestgehend einer Bildschirmmaske

202
 4 .1 Die BATCH-INPUT-Schnittstelle

Beim Abspielen einer Mappe werden Transaktionen ausgefuhrt

und Daten in das SAP R13-System CDatenbanktabellen) einge-
spielt. Das System stellt drei Bearbeitungsarten zur Verfiigung:

Mappen unsichtbar abspielen (Batch·Verarbeitung der Mappen)

Die Batch-Input-Mappen werden dem Batch-System zur soforti-
gen Verarbeitung ubergeben. Die Mappen mussen im Batch-
System freigegeben werden. Nach der Verarbeitung wird eine
Mappe folgendermaBen behandelt:
• Das System loscht eine erfolgreich abgespielte Mappe aus
der Mappenubersicht.
• 1st die Option KEEP fur die Mappe eingestellt, bleibt die
Mappe in der Mappenubersicht stehen und erhalt den Status
'Bearbeite t '.
• Wenn eine Transaktion in der Mappe eine Fehlermeldung
erhalt, wird diese Transaktion abgebrochen und aIle ubri-
gen Transaktionen abgeschlossen. Die Mappe bleibt in der
Mappenubersicht stehen und erhalt den Status 'Fehlerhaft '.

Mappen sichtbar abspielen

In dieser Bearbeitungsart werden die Batch-Input-Mappen inter-
aktiv abgespielt. Fehlerhafte Transaktionen konnen auch inter-
aktiv korrigiert und nicht ausgefuhrte Transaktionen stufenweise
durchgearbeitet werden.

Nur Fehler anzeigen

Die Batch-Input-Mappen werden auch hier interaktiv gestartet.
Transaktionen, die keine Fehler enthalten, laufen in dieser Bear-
beitungsart nicht-interaktiv abo
In den meisten Systemen werden Mappen nicht-interaktiv gestar-
tet. Das Benutzerprogramm, das die Batch-Input-Mappen er-
zeugt, kann die Mappen entweder sofort selbst abspielen lassen
oder in das SAP R13-Speichermedium Queue (Warteschlange)
stellen. Parallel dazu ist es moglich, das ABAP/ 4-Programm
RSBDCSUB in regelmaBigen Zeitabstanden auszufuhren. Das
Programm plant Mappen zur sofortigen Hintergrundverarbeitung
ein.
Das Anlegen von Batch-Input-Mappen wird uber Funktionsbau-
steine und eine Datenstruktur realisiert. Folgende Schritte sind
zur Erzeugung der Mappen erforderlich:

203
4 Datentransfer IBM COPICS nach SAP-R/3

1. bffnen der Batch-Input-Mappe mit dem Funktionsbaustein

BDC_OPEN_GROUP.
2. Fur jede in der Mappe enthaltene Transaktion:
2a. Versorgen der Struktur BDCDATA mit Werten
fur aIle gewiinschten Felder in der Transaktion.
2b. Obergeben der Transaktion an die Mappe mit
BDC_INSERT.
3. SchlieBen der Batch-Input-Mappe mit
BDC_CLOSE_GROUP.

Struktur BDCDATA
Die Batch-Input-Struktur (Tabelle) BDCDATA [4] ist mit Daten-
werten zu versorgen, die in bestimmte Eingabefelder eines Dyn-
pro eingegeben werden. Mit dieser Struktur werden Bildschirm-
eingaben an die gewiinschte Transaktion oder den gewiinschten
Dialog ubergeben. Die Struktur sollte in einem Benutzerpro-
gramm, das Batch-Input verwenden mochte, folgendermaBen
angegeben werden:
DATA: BEGIN OF BDCDATA OCCURS O.
INCLUDE STRUCTURE BDCDATA.
END OF BDCDATA.
Die OCCURS-Klausel gibt an, daB ein Puffer fur die Tabelle
BDCDATA im Speicher angelegt werden solI.
Ein Benutzerprogramm muB fUr jedes Feld eines Dynpro, das mit
Eingabedaten belegt werden soli, einen Datensatz in die Tabelle
BDCDATA einfugen. Urn einem Datenfeld einen Wert zuordnen
zu konnen, muB der Name und die Lange des Datenfeldes be-
kannt sein. Der Feldname ist mit <TABELLENNAME>-
<FELDNAME> anzugeben. (Fur die Tabelle 'RM06B' und das
Feld 'EEIND' - Lieferdatum der Bestellung - lautet z.B. der
ABAP/4-Feldname 'RM06B-EEIND') . Aile erforderlichen Felder
(MuBfeider) des Bildes mussen mit Werten versorgt und genauso
formatiert werden, wie sie ein Benutzer am Bildschirm eingibt.
Der erste Satz in der Tabelle BDCDATA muB Informationen ent-
halten, die das vorhandene Bildschirmbild identifizieren: Pro-
grammname, Bildnummer und eine Kennung fUr den Bildanfang
(Start-ol-screen indicator).

204
 4.2 Fortschreibung der Beschaffungsauftrage

Hier ist ein Beispiel fur den ersten BDCDATA-Satz eines Bild-
schirmbildes dargestellt:

BDCDATA-PROGRAM = 'SAPMM06B'.
BDCDATA-DYNPRO = '0100'.
BDCDATA-DYNBEGIN = 'x'.
APPEND BDCDATA.

Urn ein Feld mit Werten zu versorgen, mussen folgende Anga-

ben gemacht werden:
BDCDATA-FNAM = 'EBAN-BSART'.
BDCDATA-FVAL = 'NB'.
APPEND BDCDATA.

4.2 Fortschreibung der Beschaffungsauftrage

Die gesamte Beschaffungstatigkeit erfolgt mit Hilfe des Systems
SAP R/3. Die in das SAP R/3-System eingespielten IBM COPICS-
Beschaffungsauftrage werden dadurch fortgeschrieben und ge-
pflegt.
Auf der anderen Seite muB das IBM COPICS-System dieses Ge-
schehen registrieren. Dies geschieht durch standige Ruckmel-
dungen uber die Entwicklung der Beschaffungstatigkeit im SAP
R/3-System. Diese Ruckmeldungen beziehen sich in erster Linie
auf aile Wareneingange bzw. Rucklieferungen von Materialien,
die durch COPICS zur Beschaffung in Auftrag gegeben wurden.
Weiterhin sind fur die Materialbedarfsplanung im IBM COPICS-
System aile Anderungen in der Bestellschreibung des R/3-
Systems von Bedeutung. Die Anderungen betreffen die geplante
Liefermenge und den geplanten Liefertermin des zu beschaffen-
den Materials, aber auch die Freigabe und die Stornierung eines
Beschaffungsauftrags.
Die Ruckmeldungen stellen eine Beziehung zwischen einem of-
fenen Beschaffungsauftrag im IBM COPICS-System und einer
Bestellung im SAP R/3 Einkauf her und aktualisieren die Daten
des offenen Beschaffungsauftrags. Die Verknupfung der Bestel-
lung im R/3-System mit dem IBM COPICS-Beschaffungsauftrag
wird dadurch erreicht, daB die IBM COPICS-Auftragsnummer
durch die Nummer des erzeugten R/3-Bestellbelegs ersetzt wird.

205
5 Ruckmeldungen von SAP-R/3 nach IBM COPICS

Dies geschieht im Rl3-System bei der Umwandlung der aus dem

COPICS eingespielten Bestellanforderungen in eine Rl3-
Bestellung. Dber diesen Vorgang erhalt das IBM COPICS-System
eine Nachricht, indem eine Rtickmeldung mit dem Vorgangscode
, BE' - Bestellfreigabe erstellt wird. Das Auslosen der Bestellung
im SAP Rl3 Einkauf bedeutet also gleichzeitig die Freigabe des
Beschaffungsauftrags im IBM COPICS-System. Alle weiteren Ak-
tivitaten bzw. Fortschreibungen, die sich auf eine Bestellung im
SAP Rl3-System beziehen, konnen dadurch dem IBM COPICS-
System tiber die Nummer der Bestellung rnitgeteilt werden.
Jegliche Anderung in den bestellrelevanten Daten eines Rl3-
Bestellbelegs lost eine aquivalente Anderung im IBM COPICS-
Beschaffungsauftrag aus und bewirkt wiederum Aktivitaten der
IBM COPICS Materialbedarfsplanung. Die Dberwachung bzw.
das Protokollieren der Bestellentwicklung im SAP Rl3-System
tibernimmt ein eigens entwickeltes, zeitgesteuertes ABAP/4-
Benutzerprogramm mit dem Namen YRANDlOO. Die Anderun-
gen der bestellrelevanten Daten werden nach einem Lauf dieses
Programms in einer Dbertragungsdatei gesammelt und anschlie-
Bend durch einen eigenstandigen ProzeB zum Host-Rechner
tibertragen und dart in das IBM COPICS-System eingespielt. Die
Vorgangscodes in den Datensatzen der Dbertragungsdatei dienen
als Steueranweisungen und legen sornit die Verarbeitung des
Datensatzes in der IBM COPICS Materialbedarfsplanung fest. Der
Vorgangscode bestimmt zugleich den Aufbau des zugehorigen
Datensatzes.

5 Rlickmeldungen von SAP-Rl3 nach IBM COPICS

Die Entwicklung der Bestelltatigkeit und alle Aktivitaten, die sich

im SAP Rl3-System auf eine Bestellung beziehen, werden durch
das Benutzerprogramm YRANDIOO protokolliert. Die zeitliche
Steuerung des Programms erlaubt ein automatisches Registrieren
der Bestellanderungen. Als Basis werden die Anderungsbelege
genutzt.

206
 5.1 Andernngsbe/ege

5.1 Anderungsbelege
Da betriebswirtschaftliche Objekte haufigen Anderungen unter-
Iiegen, ist es oft sinnvoll oder sogar notwendig, diese nachvoll-
ziehen zu konnen. Die Protokollierung der Anderungen erfolgt
im SAP Rl3-System durch Anderungsbelege. Beispielsweise
werden Anderungsbelege im Einkauf oder in der Finanzbuchhal-
tung eingesetzt. In der Finanzbuchhaltung kann dadurch die
Revisionsfahigkeit erreicht werden.
Ais Ausgangsbasis fUr das Protokollieren der bestellrelevanten
Daten im Modul Einkauf verwendet das angesprochene Benut-
zerprogramm diese Anderungsbelege. Das Programm hat die
Aufgabe, nur diejenigen Anderungen aus den Bestelldaten zu
filtern, die sich auf die IBM COPICS-Beschaffungsauftrage bezie-
hen.
Anderungsbelege werden im SAP Rl3-System fur ein betriebs-
wirtschaftliches Objekt als Anderungsbelegobjekt definiert. Jedes
Anderungsbelegobjekt ist im SAP Rl3-System durch einen Namen
gekennzeichnet und speichert Anderungen zu einem betriebs-
wirtschaftlichen Objekt abo Fur das betriebswirtschaftliche Objekt
'Bestellung' legt das System beispielsweise ein Anderungsbe-
legobjekt 'EINKBELEG' an, da eine Bestellung ein Einkaufsbe-
leg ist. Zur eindeutigen Identifikation erhalt das betriebswirt-
schaftliche Objekt im Anderungsbelegobjekt eine Objekt-ID. Die
Objekt-ID ist z.B. die Nummer des Bestellbelegs einer Bestel-
lung. Die Anderungen, die yom System oder durch einen Benut-
zer in einem Bestellbeleg vorgenommen wurden, konnen uber
die Objekt-ID in dem entsprechenden Anderungsbelegobjekt
'EINBELEG' angesprochen und bearbeitet werden.
Aile Aufgaben zur Protokollierung der Anderungen werden von
SAP Rl3-Funktionsbausteinen ubernommen, wie z.B. das Erstel-
len, Lesen oder Andern von Anderungsbelegen. Die Funktions-
bausteine errnitteln die Anderungen fur aIle Tabellenfelder, die
im Data Dictionary als anderungsrelevant gekennzeichnet sind.
Die bei Anderungen zugrundeliegenden Tabellen werden in die
Definition eines Anderungsbelegobjekts aufgenommen.
Transaktionen legen die Protokolldaten von Anderungen in zwei
Tabellen abo Entsprechend den Einkaufsbelegen des Systems,
existiert je eine Tabelle fUr den Belegkopf und eine Tabelle fUr
die Belegpositionen der Anderungsbelege.

207
5 Ruckmeldungen von SAP-R/3 nach IBM COPICS

Fur die Bearbeitung der Anderungsbelegtabellen stellt das SAP

Rl3-System zahlreiche Funktionsbausteine zur Verfugung. Zum
Beispiel selektiert ein Abfrageprogramm mit Hilfe des Bausteins
CHANGEDOCUMENT_READ_HEADERS zuerst die Kopfinforma-
tionen der relevanten Anderungsbelege heraus und ubergibt die
so gewonnenen Belege dem Funktionsbaustein CHANGEDOCU-
MENT_READ_POSmONS. Dieser Baustein bereitet die Belegpo-
sitionen fUr die gewOnschten Auswertungen vor. In Abhangigkeit
des Verwendungszwecks der so erhaltenen Belege kbnnen die
Daten mit dem Baustein CHANGEDOCUMENT_PREPARE_ POS
zum Drucken vorbereitet werden.

5.2 Erstellung und Obertragung der Ruckmeldungen

Die durch das Programm gewonnenen Daten werden in einer
externen Datei fur Ruckmeldungen gespeichert. Das Programm
arbeitet stufenweise: Zunachst werden wichtige Daten der im
System neu erstellten Bestellungen abgespeichert. Neben der
Sachnummer des Materials oder der Nummer des Bestellbelegs,
fUgt das Benutzerprogramm aulSerdem den Vorgangscode 'BF' -
Bestellfreigabe - den Daten in der Ruckmeldedatei hinzu.
Die Anderungen der bestellrelevanten Daten in einem Bestellbe-
leg lassen sich uber die beschriebenen Anderungsbelege abfra-
gen. Das Benutzerprogramm schreibt nun aile zwischen zwei
Programrnlaufen aufgetretenen Bestellanderungen in die Ruck-
meldedatei und ordnet ihnen den Vorgangscode 'BA' - Bestell-
anderung - zu. Fur die Stornierung einer Bestellposition gilt ent-
sprechendes, mit dem Unterschied, daIS der Vorgangscode 'BS ' -
Bestellstorno - geschrieben wird.
Fur jeden Wareneingang und jede Warenrucksendung erstellt das
SAP Rl3-System einen Materialbeleg. Die Materialbelege geben
unter anderem die gelieferte Menge, das Lieferdatum und die
Bewegungsart (z.B. Wareneingang ins Lager, Rucksendung, Wa-
reneingang in den Sperrbestand usw.) an. Parallel hierzu schrei-
ben die Funktionen im Modul BestandsfUhrung des SAP Rl3-
Systems die Historie der Beschaffung bei Warenzu- bzw. Waren-
abgangen fort. Das Programm YRANDIOO liest nun aile Fort-
schreibungen dieser Warenbewegungen und schreibt die zwi-
schen zwei Programmlaufen neu gebuchten Warenzu- bzw. Wa-
renabgange in die Ruckmeldedatei.

208
 5.1 Andernngsbe/ege

Die Vorgangscodes 'WU' (Wareneingang ungeplant), 'WP'

(Wareneingang geplant) und 'R U' (Riicksendung) werden dabei
entsprechend den Warenbewegungen in die geschriebenen Da-
tensatze eingefiigt.
Nachdem die Ubertragungsdatei durch das Benutzerprogramm
erstellt wurde, kann sie zum Host-Rechner des IBM COPICS-
Systems iibertragen und die Datensatze in die Schnittstellen-
Datenbank eingelesen werden. Ein UNIX-Shell-Programm steuert
die Ubertragung zum Host. Zuerst stellt das UNIX-Shell-Script ei-
ne Verbindung zum Host-Rechner her und iibertragt mit Hilfe
des eingesetzten Kommunikationswerkzeugs die Ubertragungs-
datei. AnschlieBend startet das UNIX-Shell-Script ein Host-
Programm, das die Datensatze in die Schnittstellen-Datenbank
des IBM COPICS-Systems einspielt. Das Verbuchen der einge-
spielten Datensatze aus der Schnittstellen-Datenbank in die Da-
tenbanken der IBM COPICS Materialbedarfsplanung kann ent-
weder in einem Batch-Lauf erfolgen oder yom Materialdisponen-
ten selbst vorgenommen und iiberwacht werden.
Der Vorgangscode einer Riickmeldung bestimmt den Ablauf und
die Auswirkungen der Verbuchungsvorgange im Modul IBM
COPICS Materialbedarfsplanung. Das Zuordnen einer SAP Rl3-
Bestellung zu einem offenen Beschaffungsauftrag wird verbucht,
indem lediglich die Auftragsnummer des IBM COPICS-
Beschaffungsauftrags durch die iibergebene Nummer der Rl3-
Bestellung ersetzt wird. Die Stornierung einer Bestellung hat das
L6schen des Beschaffungsauftrages zur Folge. Zusatzlich muB
eine Meldung zur Neuplanung der Sachnummer erzeugt werden .
.A.nderungen der Bestelldaten aktualisieren die Daten im zuge-
ordneten Beschaffungsauftrag. Die Auswirkungen der Auf-
tragsanderungen werden bei der Materialbedarfsplanung be-
ri.icksichtigt. Wareneingange bzw. Riicklieferungen wirken sich
unmittelbar auf die im IBM COPICS gefuhrten Bestande aus. Der
AbschluB des Beschaffungsauftrags wird schlieBlich durch die
Gesamtlieferung der angeforderten Materialien erreicht.

209
6 Nachbetrachtung zur L6sung

6 Nachbetrachtung zur Losung

Die schrittweise Einfuhrung der Standardsoftware SAP Rl3 in die

Unternehmen der Fertigungsindustrie kann die hier vorgestellte
Kopplung des Moduls SAP Rl3 Einkauf an IBM COPICS Ma-
terialbedarfsplanung ermbglichen. Der Vorteil der schrittweisen
Installation des SAP Rl3 liegt darin, daB durch den produktiven
Einsatz eines Teils des Systems ein Erfahrungspotential im Un-
ternehmen aufgebaut werden kann. Dieses Potential wtirde zum
Beispiel Erfahrungen im Umgang mit dem SAP Rl3-System, Ent-
scheidungshilfen beim Customizing oder eine weiterfuhrende
Strategie zur Abbildung der Organisationsstruktur des Unterneh-
mens beinhalten. Dies ist ein nicht zu unterschatzender vorteil-
hafter Faktor bei der Installation weiterer SAP Rl3-Module und
der Schulung der Mitarbeiter.
Die hier vorgestellte Lbsung ist dadurch gekennzeichnet, daB
vorhandene Standardkomponenten sowohl bei der Obermittlung
von Informationen zwischen beiden Systemen, als auch im SAP
Rl3-System genutzt werden kbnnen. Unumganglich sind aber die
programmierten Erweiterungen in beiden Systemen, die Infor-
mationen aufbereiten und entsprechende Schnittstellen fUr den
Austausch der Informationen schaffen.
Herkbmmliche bzw. nicht protokollgestutzte Techniken zum Im-
port von Daten in ein komplexeres System verwenden haufig
das direkte Schreiben der Datensatze in die Datenbanktabellen.
Liegt dem System beispielsweise ein relationales Datenbankmo-
dell zugrunde, muB dann der Programmierer fur die Konsistenz
der importieren Daten in der Datenbank selbst Sorge tragen. Die
in der hier vorgestellten Lbsung verwendete Batch-Input-
Schnittstelle des SAP Rl3-Systems bietet im Gegensatz hierzu ei-
nige nicht zu unterschatzende Vorteile:
• Batch-Input simuliert beim Einspielen der Daten die Online-
Eingaben eines Benutzers. Die importierten Daten werden
dadurch allen systemseitigen Prtifungen unterzogen. So ist
z.B. gewahrleistet, daB aile MuBfeider belegt sind und aus
den importierten Daten nicht gefUllte Datenbankfelder mit
korrekten Standardbelegungen besetzt werden. AuBerdem
werden aile Plausibilitatsprtifungen durchgefuhrt.

210
 5.1 Andernngsbelege

• Die Schnittstelle kapselt weitgehend die Abhangigkeiten

zugrundeliegender Datenbanktabellen. Die Verarbeitungs-
programme der Dynpro bereiten automatisch die Daten der
abhangigen Tabellen auf. Der Aufwand zur Programmie-
rung von graBeren Datenimporten wird dadurch wesentlich
verringert.
Die Abfrage der Anderungsbelege ermaglicht die Aufbereitung
der geanderten Einkaufsdaten im SAP R/3-System. 1m System
werden nahezu aIle wichtigen Anderungen der Datenbestande
uber Anderungsbelege protokolliert. Dadurch entfallt die Not-
wendigkeit, bestehende Systemprogramme mit zusatzlicher
Funktionalitat zu versehen oder direkt auf interne Tabellen zu-
greifen zu mussen. In Benutzerprogrammen werden diese Ande-
rungsbelege uber Funktionsbausteine abgefragt und entspre-
chend den Anforderungen aufbereitet. 1m Gegensatz zur direk-
ten Programmierung der System programme stellt die Abfrage der
Anderungsbelege eine Unabhangigkeit der Benutzerprogramme
von Anderungen in Systemprogrammen her. Dadurch wird die
Releasefahigkeit des Systems erhalten. Ein Entwickler ist jedoch
zum einen von der vorgegebenen Funktionalitat der Anderungs-
erfassung und zum anderen yom Umfang der Bereiche abhangig,
in denen Anderungsbelege eingesetzt werden.
Suboptimal ist die Obertragung der auszutauschenden Daten
zwischen den Systemen IBM COPICS und SAP R/3 bzw. zwi-
schen dem Host- und UNIX-Rechner. Da die Obertragungsvor-
gange, sowohl yom als auch zum Host-Rechner in mehreren
voneinander abhangigen Schritten ablaufen, kann die Sicherheit
protokollgestutzter Obertragungstechniken nicht erreicht werden.
Techniken, wie zum Beispiel ED! oder RPC, mussen fur den
Host-Rechner teuer erkauft bzw. entsprechend in den eingesetz-
ten Systemen nachgebildet werden. ]edoch gewahrleistet der in
der Lasung vorgestellte Ablauf und das verwendete Standard-
produkt zur Host-Kommunikation, eine automatisierte Abwick-
lung der Datenubertragung zwischen beiden Systemen.
Durch die Kopplung des Systems SAP-R/3 Materialwirtschaftl
Einkauf an IBM COPICS Materialbedarfsplanung laBt sich der
Zyklus genereller Aktivitaten zur externen Beschaffung von Wa-
ren und Dienstleistungen mit Hilfe zweier unabhangiger Infor-
mationssysteme abwickeln.

211
Literaturverzeichnis

Die hier vorgestellte Losung erreicht das Ziel, mittels eines mog-
lichst einfach zu realisierenden Verfahrens und unter Verwen-
dung von Standardkomponenten die schrittweise Einfuhrung des
SAP R/3-Systems in Unternehmen der Fertigungsindustrie zu er-
moglichen.

Literaturverzeichnis

[1) Reutter, K-H.: Kopplung des Systems SAP-R/3 Materialwirt-

schaft/Einkauf an IBM COPICS Materialbedarfsplanung, Di-
plomarbeit, Fachhochschule fur Wirtschaft und Technik
Reutlingen, 1994.
[2) SAP AG Walldorf: BC - Systemverwaltung, Benutzerhand-
buch, Release 2.1, Februar 1994.
[3) SAP AG Walldorf: BC - ABAP/4: Spezielle Techniken, Be-
nutzerhandbuch, Release 2.1, Januar 1994.
[4) SAP AG Walldorf: BC - SAP Data Dictionary, Benutzerhand-
buch, Auflage 1, Release 2.0, Juli 1992.

212
Konzeption und Umsetzung einer System-
architektur fur die Produktionssteuerung in der
ProzeBindustrie

Dr. Peter Loos

Institut fOr Wirtschaftsinformatik (IWi) an der Universitat des

Saarlandes, Saarbrucken

213
1 Oberblick

1 Uberblick

Fertigungsnahe Systeme zur Planung und Steuerung der Produk-

tionslogistik sind bereits seit einigen Jahren in Form von Ferti-
gungsleitstanden in der stuckorientierten Fertigung erfolgreich im
Einsatz. In der prozeBorientierten Industrie besteht dagegen
meist eine konzeptionelle und systemtechnische Lucke zwischen
lang- und mittelfristiger Planung einerseits und der ProzeBauto-
mation andererseits. Aus dies em Grund wurden in dem Projekt
CAPISCE Module fUr die Produktionssteuerung unter besonderer
Berucksichtigung der Anforderungen der ProzeBindustrie ent-
wickelt. Der Beitrag gibt einen Dberblick uber typische Anforde-
rungen an Logistikinformationssysteme in der ProzeBindustrie
und beschreibt die Umsetzung in dem Projekt CAPISCE anhand
der Ausgangsbedingungen, der Modulkonzeption und deren
Implementierung und Integration in Rl3. Insbesondere wird da-
bei auf den Integrationsgedanken im Sinne einer durchgangigen
GeschaftsprozeBuntersttitzung eingegangen. Eine kurze Darstel-
lung der ersten Pilotinstallationen schlieBt den Beitrag.

2 Charakterisierung der ProzeBindustrie

1m Gegensatz zur diskreten Produktion der sttickorientierten

Fertigung, bei der die Herstellung von Teilen in unterschied-
lichen LosgrbBen im Vordergrund steht und die das typische
Anwendungsgebiet fUr Computer Integrated Manufacturing (CIM)
ist, stehen bei der ProzeBindustrie verfahrenstechnische Um-
wandlungsprozesse ungeformter Rohstoffe und Endprodukte im
Vordergrund. Zu der ProzeBindustrie gehbren z. B. die Branchen
Chemie und Pharma, Nahrungs- und GenuBmittel, Gummi oder
Papier. Aufgrund der Herstellungsverfahren ergeben sich spezi-
elle Anforderungen an die unterstutzenden Informationssysteme
fUr Logistik und Produktion, die im folgenden anhand einiger
Kriterien verdeutlicht werden [4,9,11,181:

214
 2 Charakterisierung der ProzejSindustrie

• Physische und chemische Eigenschaften der zu verarbeiten-

den Stoffe und Endprodukte mtissen in der Materialwirt-
schaft berticksichtigt werden, z.B. schwankende Qualitat bei
mineralischen, pflanzlichen oder tierischen Rohstoffen der
Urproduktion, teilweise begrenzte Haltbarkeit von Materia-
lien oder spezielle Lagerbedingungen und -restriktionen.
• In der ProzeBindustrie fallen wahrend des Herstellungspro-
zesses haufig Kuppelprodukte in einem nur bedingt beein-
fluBbaren Verhaitnis an. Dies gilt insbesondere fOr die Ur-
produktion. Die Kuppelprodukte solcher analytischen
Stoffumwandlungsprozesse, die sowohl Haupt-, Neben- als
auch Abfallprodukte sein kbnnen sowie zyklische Material-
fltisse, z.B. bei Katalysatoren, fOhren zu einem komplexen
inner- und tiberbetrieblichen Stoffverbund mit entsprechen-
den Auswirkungen auf die Produktionsplanung und Mate-
rialdisposition.
• Umweltschutzbestimmungen und Gefahrenstoffverordnun-
gen haben einen direkten EinfluB auf die Produktionspla-
nung und die Durchftihrung von Logistikprozessen. So
kann sich z. B. die gleichzeitige Produktion oder Lagerung
zweier bestimmter Produkte ausschlieBen.
• Haufig sind Funktionen fOr die Berechnung von Input-Out-
put-Beziehungen oder Produktionszeiten nicht-linear (z.B.
nicht-lineare Substitution von Rohstoffen) oder enthaiten
nicht-deterministische Parameter (z.B. WettereinfluB auf
ProduktionsprozeB) .
• Bedingt durch die physischen Eigenschaften der Materialien
muB haufig mit unterschiedlichen Einheiten gerechnet wer-
den, z.B. mit Gewicht, Volumen, Konzentration, produk-
tionsstunden oder Ansatzmenge.
• In noch starkerem MaBe als bei der diskreten Fertigung
mtissen die Daten der Produktion protokolliert und archi-
viert werden. Dies betrifft nicht nur die Qualitat der Er-
zeugnisse, sondem auch die Qualitat der Rohstoffe und die
Protokolle des Herstellungsprozesses.
Kontinuierliche und Je nach Art der Stoffausbringung kann zwischen einer konti-
chargenweise nuierlichen oder diskontinuierlichen Produktion unterschieden
Produktion werden. Die kontinuierliche Produktion zeichnet sich durch ei-
nen gleichfbrmigen Materialstrom in speziellen Anlagenkonfi-
gurationen aus. Kontinuierliche Prozesse sind typisch fOr die

215
3 Das Projekt CAP/SCE

Massenfertigung der Grundstoffindustrie, z.B. Mineralblver-

arbeitung. Bei der diskontinuierlichen Produktion wird dagegen
eine bestimmte Menge eines Materials verfahrenstechnisch her-
gestellt. Eine solche Menge wird als Partie, Charge oder Batch
bezeichnet, weshalb hier auch von Chargenproduktion gespro-
chen wird (allerdings wird haufig auch bei kontinuierlichen und
diskreten Prozessen die Produktionsmenge einer definierten Pe-
riode als Charge bezeichneO. Chargenproduktion ist typisch fur
die Bereiche Feinchemikalien und Pharma. Da bei diskontinu-
ierlicher Fertigung die Produkte tendenziell durch die Kunden-
nahe starkeren Schwankungen unterworfen sind und deshalb
meist Mehrzweck- und Mehrproduktanlagen eingesetzt werden,
ergibt sich wie bei der diskreten Fertigung die Notwendigkeit,
die Produktion flexibel an kurzfristige Anforderungen auszurich-
ten, was eine ebenso kurzfristige Produktionsplanung und
-steuerung notwendig macht. Nicht selten findet man auch eine
hybride Form, bei der die ersten Schritte kontinuierlich, die fol-
genden Schritte diskontinuierlich ablaufen.

3 Das Projekt CAPISCE

Wahrend die Logistik- und Produktionsplanungsprozesse der

stuckorientierten Fertigung schon lange Gegenstand der anwen-
dungsorientierten Forschung und Entwicklung sind, besteht in
der prozeBorientierten Industrie dagegen haufig eine konzeptio-
nelle und systemtechnische Lucke zwischen lang- und mittelfri-
stiger Planung einerseits und ProzeBautomation andererseits.

Projektziel und Das Projekt CAPISCE (Computer Architecture for Production In-
-organisation formation Systems in a Competitive Environment) hat sich des-
halb zum Ziel gesetzt, eine Architektur und darauf aufbauend
Softwaremodule fur die kurzfristige Produktionssteuerung zu
entwickeln. Eine wichtige Pramisse ist dabei die Integration der
lang- und mittelfristigen Planung und der ProzeBautomation im
Sinne einer ganzheitlichen GeschaftsprozeBuntersttitzung. Das
Konsortium des Projektes CAPISCE, das von der Europaischen
Union im Rahmen des ESPRIT-Programmes gefbrdert wurde,
besteht aus den Partnern Digital Equipment (Warrington, Eng-
land), IDS Prof. Scheer (Saarbrucken), IWi (Universitat des Saar-

216
 3 Das Projekt GAP/SGE

landes), SAP (Walldorf) und Zeneca (Manchester, England).

Wahrend die Partner Digital Equipment, IDS und SAP neben der
Konzeption ftir die Realisierung der Software zustandig sind,
ftihrt Zeneca als Anwender die Pilotinstallationen in seinen eng-
lischen und schottischen Werken durch (dies erklart auch die
englischsprachigen Begriffe des Projektes, die zur besseren Ver-
standlichkeit hier teilweise mitaufgenommen wurden). Als wis-
senschaftliche Begleitung arbeitet das IWi an der Konzeption
und erstellt Studien und prototypische Implementierungen zu
ausgewahlten Fragestellungen (z.B. [1,8]).

Abb.3.1
Ebenenkonzepl

BetriebsleHebene

ProzeBleitebene

Feldebene

Einordnung in ein In dem fur die chemische Industrie aufgestellten Ebenenkonzept

Ebenenkonzepl (3) lafst sich der Schwerpunkt der Arbeiten in CAPISCE auf den
Ebenen Betriebsleitebene und, soweit sie dispositive und logisti-
sche Funktionen innerhalb eines Betriebes betreffen, produk-
tionsleitebene einordnen (vgl. Abbildung 3.1). Die werks- oder
unternehmensweite Planung war nicht primares Ziel des Projek-
tes. Nach dem Ebenenkonzept ist die Unternehmensleitebene
neben den kaufmannischen Funktionen auch fur die strategische
Planung zustandig. Die Produktionsleitebene hat die Aufgabe
der mittelfristigen Planung sowie der Koordination der einzelnen
Betriebe. Die ProzeBleitebene und die Feldebene tibernehmen
die Aufgabe der Automatisierung und der Ausfuhrung der Pro-
zeBschritte (2). Teilweise findet man, vor aHem in der amerikani-
schen Literatur, den Begriff MES (Management Exection System)
fur die Informationssysteme der Funktionen der Betriebs- und
Produktionsleitebene.

217
4 Die Anwendungsmodulkonzeption

Einordnung in das Abbildung 3.2 zeigt in Anlehnung an das Y-CIM-Modell (17) die
CIP-Konzepl Informationssysteme fi.ir die Produktion in der verfahrens-
technischen Industrie (8), die als Computer Integrated Processing
(CIP) bezeichnet werden [14]. Die grau hinterlegte Schattierung
zeigt die Relevanz der jeweiligen Funktion fi.ir in CAPISCE ent-
wickelten Module.

Abb.3.2
CIP-Modell Primlrbelriebsv.irt· Primlr tedlo1sche
sd1a1tiiche Furidianen Furi<Iiooen

§. ProzeBsteuenJl9
~
a..
ProclJkIicns5Ie
~ lager· und Transport·
j BelrietirdatenerfassL
ood KonUoie
steuerung

V~ng

Ch.geodoIci.r1Ier4 U)
~oIe :::Ii
::J
Versandsteuerung UlTll¥llltkorodle

4 Die Anwendungsmodulkonzeption

Die Anwendungskonzeption fi.ir die Produktionssteuerung auf

Betriebsebene umfaBt mehrere als SPINE (Strategic Production
Information Environment) bezeichnete Module. Sie beinhaltet
die Module Ressourcenverwaltung (Resource Management), Re-
zeptverwaltung (Recipe Management), Bestandsfi.ihrung (Inven-
tory Management), ProzeBplanung (Scheduling) und ProzeB-
management (Process Management). Weiterhin sind die Schnitt-
stellen fi.ir die Verbindung zu den unternehmensweiten Pla-
nungssystemen (Links to Business Systems) , zu LIM-Systemen
(Links to LIMS) sowie zur ProzeBautomatisierung (PDAS - Pro-

218
 4.1 Ressourcenve1Waltung

cess Data Acquisition SeIVer) beriicksichtigt [10]. Abbildung 4.1

zeigt die einzelnen Module im Zusammenhang. Aufgrund der
Bedeutung der Integration wurde besonderen Wert auf eine
einfache Einbindung der ProzeBautomatisierung gelegt. Deshalb
wurden bei dem Entwurf der Systemstrukturen bestehende
Empfehlungen fur die Gestaltung von Automatisierungssystemen
beriicksichtigt, insbesondere die Empfehlung der NAMUR [13]
sowie der Normierungsentwurf des SP88-Gremiums der ISA [6].

Abb.4.1
CAPISCE Module

,...--------t ------------.
ProzeBsteuerung/Automatisierungstechnik
I
4.1 Ressourcenverwaltung
Das Modul Ressourcenverwaltung hat die Aufgabe, aIle in einem
Betrieb vorhandenen Produktionsressourcen zu verwalten und
die fur die Aufgaben der Produktionsplanung und -steuerung
notwendigen Informationen uber die Produktionsfaktoren zur
Verfugung zu stellen. Die Hauptressourcen sind dabei i. d. R. die
Produktionsanlagen, wie Kessel, Tanks, Mischer, Trockner etc.;
es k6nnen aber auch andere Ressourcenkategorien, wie Perso-
nal, Transporteinrichtungen, Energien (Gas, Wasser, Strom,
Dampf, Chlor) oder Entsorgungseinrichtungen betrachtet wer-
den. Sinnvoll ist die Verwaltung einer Ressource, wenn sie Ka-

219
4 Die Anwendungsmodulkonzeption

pazitatsrestriktionen besitzt und aus Sicht der Produktionspla-

nung und -steuerung bewirtschaftet werden muB.
Urn sowohl die in den Empfehlungen beinhalteten hierarchi-
schen Gliederungen der Ressource Produktionsanlagen (bei [13]
wird vom Werk uber Anlagenkomplex, Anlage, Teilanlage bis
Anlagenteile, bei [6] von Enterprise uber Site, Area, Process Cell,
Unit, Equipment Module bis Control Module detailliert) als auch
unternehmensspezifische Systematiken abbilden zu kbnnen, sind
verschiedene Konzepte implementiert worden, die eine indivi-
duelle Anpassung gestatten:
Ressourcen- • Die Ressourcenarten gestatten eine prinzipielle Unterschei-
klassifizierung dung der oben genannten Kategorien, wie Anlagen, Perso-
nal etc ..
• Mehrere gleichartige Ressourcen einer Ressourcenart kbn-
nen mit Hilfe von Klassen verwaltet werden. Bei der Klas-
sendefinition werden Auspragungen bestimmter Eigenschaf-
ten definiert, die fUr aile Ressourcen der Klasse gleich sind.
So kann z. B. fUr eine Gruppe gleichartiger Kessel eine
Klasse KSL definiert werden. Fur jeden Kessel wird eine In-
stanz KSLn angelegt und auf die Klasse KSL referenziert.
• Mit den Ressourcenhierarchien kann eine NAMUR- oder
SP88-konforme Gliederung abgebildet werden. Damit kbn-
nen z. B. verdichtete Kapazitatszahlen ermittelt werden.
• Mit Ressourcennetzen kbnnen logische Beziehungen zwi-
schen den einzelnen Ressourcen dargestellt werden. Damit
kbnnen z. B. die Verrohrung und die Transportmbglichkei-
ten zwischen Anlagen abgebildet und fUr die Planung der
Anlagenreihenfolge eines Auftrages genutzt werden.
• Mit einem Klassifikationsschema, wie es auch bei Sachmerk-
malsleisten fUr Materialien genutzt wird, kbnnen Merkmale
uber die Fahigkeiten und mbgliche Verwendung von Res-
sourcen festgelegt werden.
Die Ressourcenverwaltung umfaBt auch Kapazitatsmanagement-
funktionen , mit denen das Kapazitatsangebot verwaltet wird. Die
zeitliche VerfUgbarkeit von Ressourcen wird uber Schichtpro-
gramme festgelegt, die die Definition der einzelnen Schichten
mit Beginn, Ende und Pausenregelung enthalten. Schichtpro-
gramme werden zeitabhangig den Ressourcen zugeordnet. Be-
zuglich der Kapazitatsarten weist das System folgende Konzepte
auf:

220
 4.2 Rezeptverwaltung

Ressourcen- • Ressourcen k6nnen mehrere Kapazitaten besitzen. So kann

kapazitiiten eine Anlage sowohl durch ein maximales Volumen als auch
durch ein maximales FiiIlgewicht begrenzt sein, eine Ent-
sorgungseinrichtung kann sowohl eine maximale Tageska-
pazitat als auch eine relativ geringere maximale Monats-
kapazitat besitzen, oder fur eine Personalressource k6nnen
neben dem Arbeitszeitmodell die zulassigen Arbeitsplatz-
konzentrationen von Gefahrenstoffen zur vorbeugenden
Oberpriifung als Kontaminationsobergrenzen abgebildet
werden.
• Kapazitaten k6nnen exklusiv oder gemeinsam belegt wer-
den. Exklusive Verwendung von Ressourcen ist typisch fur
Anlagen, da diese i. d. R. nur von einer Charge gleichzeitig
belegt werden k6nnen. Ein Mitarbeiter kann dagegen
gleichzeitig mehrere Chargen in unterschiedlichen Anlagen
fahren.
• Eine Kapazitat kann fur mehrere Ressourcen gleichzeitig
genutzt werden. SoIche Poolkapazitaten sind typisch fur
zentrale Servicefunktionen wie Dampf, Strom, Wasser oder
fiir von mehreren Anlagen gemeinsam genutzte Vorrichtun-
gen wie Belade- oder Entladeeinrichtungen.

4.2 Rezeptverwaltung
Rezepte beschreiben den HersteIlungsprozeB von Produkten und
sind deshalb mit den Arbeitsplanen in der stiickorientierten Fer-
tigung vergleichbar. Dariiber hinaus enthalten Rezepte auch aIle
notwendigen Eingangsstoffe, Zwischenprodukte und Endproduk-
te und weisen damit Merkmale der Stiicklisten auf. Urn eine all-
gemeingiiltige Beschreibung von Prozessen zu gewahrleisten,
miissen Rezepte in generischen Strukturen definiert werden, mit
denen leicht unterschiedliche Bediirfnisse abgedeckt werden
k6nnen. Die hierzu von der NAMUR und von dem SP88-
Gremium erstellten Empfehlungen sind zwar nicht deckungs-
gleich, folgen aber dem gleichen Grundkonzept.
Rezeptgenerationen So werden in beiden Empfehlungen verschiedene Rezeptgenera-
tionen unterschieden, urn der Entstehung der Rezepturdaten
Rechnung tragen zu k6nnen. Diese reichen von einer allgemei-
nen bis zu einer konkreten Beschreibung. NAMUR differenziert
zwischen dem Urrezept als allgemeine, anlagenunabhangige Be-
schreibung, dem Grundrezept als anlagen- und produktions-
mengenabhangige Beschreibung sowie dem Steuerrezept als
konkrete Anweisung fiir eine bestimmte Charge [131.

221
4 Die Anwendungsmodulkonzeption

In dem SP88-Entwurf werden in ahnlicher Weise die Generation

General Recipe, Site Recipe, Master Recipe und Control Recipe
unterschieden [6].
Rezeptstrukturierung Neben den Generationen werden fur die Verfahrensbeschrei-
bung auch die Bestandteile der Rezepturen nach ihrer Granulari-
tat unterschieden. So teilt sich das Verfahren eines Rezeptes nach
der NAMUR-Empfehlung in mehrere Teilrezepte fUr die Be-
schreibung eines Verfahrensabschnittes, z. B. Sulfonierung. Diese
kbnnen wieder aus mehreren Operationen bestehen, die die
kleinsten selbstandig ausfUhrbaren Einheiten bilden, z. B. Dosie-
ren H 2S04 , Operationen setzen sich wiederum aus unterschiedli-
chen Funktionen zusammen, z. B. Temperieren auf 140°C.
Funktionen werden in automatisierten Systemen durch Pro-
gramme realisiert, die anlagenspezifisch implementiert und aus
Rezepten heraus referenziert und parametrisiert werden. Auch in
der Detaillierung folgt der SP88-Entwurf einem analogen Kon-
zept. Die Bestandteile der Verfahrensanweisungen sind hier in
Unit Procedure, Operation und Phase unterschieden.
Aufgrund des Einsatzbereiches des Systems werden von den ge-
nannten Generationen nur das Grundrezept und das Steuerre-
zept berucksichtigt, die hier als Planungsrezept (Master Recipe)
und Steuerrezept (Control Recipe) bezeichnet werden. Daruber
hinaus ist ein wei teres Rezeptobjekt eingefugt worden, das als
ProzeBauftrag (Process Order) bezeichnet wird. Abbildung 4.2
zeigt einen Vergleich zwischen den Verfahrensbeschreibungen
nach der NAMUR-Empfehlung und den CAPISCE-Rezepten.
Das Planungsrezept stimmt weitgehend mit dem Grundrezept
uberein. Als Stammdatum werden im Planungsrezept alle not-
wendigen Informationen uber den HerstellungsprozeB in auf-
tragsneutraler Form verwaltet. Die Informationen lassen sich in
Rezeptkopf, Verfahren, Ressourcenbedarfe, Materialien und Si-
cherheitsangaben unterteilen.
Rezeptkopf Der Rezeptkopf verwaltet alle allgemeinen Angaben uber Re-
zeptverwendung (z. B. Produktions-, Reinigungs-, Umrust-, An-
fahr-, Testrezept), BatchgrbBe, Status, Textbeschreibung, Ande-
rungshistorie und sonstige Verwaltungsdaten.
Verfahren Die Verfahrensbeschreibung besteht aus den Elementen Vorgang
(Operation), Phase (Phase) und ProzeBvorgaben (Process In-
structions) (vgl. Abbildung 4.2). Vorgange und Phasen zusam-
men stellen ein zweistufiges Konzept zur Strukturierung von
Prozessen dar. Sie sind ahnlich in ihrem Aufbau und in ihren

222
 4.2 Rezeptverwaltung

Attributen. So besitzen beide zeitverbrauchende Elemente, wie

Bearbeitungszeiten. Ein typisches Beispiel sind Phasen, wie Be-
laden, Dosieren, Nachreaktion, Abkuhlen, Entladen fur einen
Sulfonierungsvorgang. Die Phasen sind immer eindeutig einem
Vorgang zugeordnet. Die zeitlichen Abhangigkeiten kbnnen mit
Hilfe von Anordnungsbeziehungen sowohl zwischen Vorgangen,
zwischen Phasen als auch zwischen Phasen und Vorgangen er-
folgen . Dabei stehen die aus der Netzplantechnik bekannten
Beziehungsarten Anfang-Anfang, Anfang-Ende, Ende-Ende oder
Ende-Anfang zur Verftigung. Damit kann beispielsweise eine
zeitliche Synchronisation zwischen der Entladephase des ersten
Vorganges und der Beladephase des zweiten Vorganges herge-
stellt werden.

Abb.4.2 Rezeptgenerationen )
Vergleich NAMUR- und
CAPISCE-Rezept-
strukturen Uftt"pt I
I ~I Q"' ....... 'I I I .... ~.,I I
l ....I"t It r,n,r"ftd.
ItIIPt
II ToIII'."'· ]
'."'pl '

I ChI.loch., II LoIlto<h •. II ,"

I'teh", Q ' .. n4l~
0p.'ltfo" __ t'
--" Grnd·
. ...r.tion
I ••• ,,·
o,.r.l:Io"
]

Gruncltvni lfo n II , s........ "O~

' I... ~" ••·

tell,t

w
o
en
c:
c:r:
o

Ptoul·
n f•• be

223
4 Die Anwendungsmodulkonzeption

Umsetzung Jede Phase kann durch beliebig viele ProzeBvorgaben detailliert

Grundfunktionen- werden. ProzeBvorgaben werden rezeptunabhangig verwaltet
konzept
und dienen als Vorlage bei der Erstellung von Rezepten. Es
kbnnen unterschiedliche Arten von ProzeBvorgaben definiert
werden:
• ProzeBparameter dienen zur Definition von Anweisungen.
1m Fall eines manuellen Prozesses sind ProzeBparameter
meist Texte ftir den Anlagenfahrer. Bei automatisierten Pro-
zessen dienen sie zur Oberrnittlung von Informationen an
das ProzeBleitsystem.
• Mit ProzeBdatenanforderung wird festgelegt, daB das Sy-
stem Istdaten tiber einen laufenden ProzeB benbtigt. Bei
Kopplung mit einem ProzeBleitsystem werden hierrnit die
Informationen definiert, die im Normalfall aus der ProzeB-
leitebene in die Produktionssteuerung flieBen. Ftir manuelle
Fahrweise wird definiert, welche Werte der Anlagenfahrer
wahrend des Prozesses erfassen solI.
• ProzeBdatenabos dienen zur Festlegung, unter welchen un-
geplanten Ereignissen Istdaten tiber den ProzeB zu melden
sind; z. B. falls die Temperatur hbher als 143 0 C steigt, soli
der Druck und der pH-Wert gemeldet werden.
• Mit Berechnungsformeln kbnnen rezeptspezifische Formeln
an das ProzeBleitsystem tibermittelt werden, das in Abhan-
gigkeit der Ergebnisse unterschiedliche Aktionen durchftih-
ren kann.
• Prtifergebnisanforderungen dienen zur Definition von Prtif-
werten, die ftir einen ProzeB erhoben werden sollen.
Es kbnnen zu jeder Art beliebig viele ProzeBvorgaben definiert
werden, die von beliebig vielen Rezepten genutzt werden. Zu-
satzlich ist es mbglich, neue Arten im System selbst zu generie-
ren. Mit dem Konzept der ProzeBvorgaben kann in eleganter
Weise das Grundfunktionenkonzept der NAMUR-Empfehlung ab-
gebildet werden.
Ressourcen- Die ftir die Durchftihrung eines Prozesses notwendigen Ressour-
zuordnung cen, welche in der Ressourcenverwaltung definiert werden, kbn-
nen sowohl den Vorgangen als auch den Phasen zugeordnet
werden. Zusatzlich kann dem Rezeptkopf eine Ressource zuge-
wiesen werden. Die sogenannte Primarressource wird ftir die ge-
samte Dauer eines Schrittes belegt. Als Primarressource wird man
meist die Anlage wahlen. Weiterhin kbnnen Sekundarressourcen
ftir zusatzliche Bedarfe zugeordnet werden.

224
 4.2 Rezeptverwaltung

Die Zuordnung kann sich sowohl auf eine bestimmte Ressource

als auch auf eine Ressourcenklasse innerhalb einer Ressourcenart
beziehen. Anstelle einer direkten Ressourcenzuordnung k6nnen
auch Anforderungen an die Ressourcen festgelegt werden, ftir
die das bereits oben erwahnte Klassifikationsschema gilt. So
kann die konkrete Ressource fur einen Bedarf tiber das Matchen
von Anforderung und Eihigkeit gefunden werden. Dies stellt die
flexibelste Art der Verbindung von Rezepten und Ressourcen
dar.
Material Die Materialliste enthalt aile ftir ein Rezept notwendigen Mate-
im Rezepl rialien sowie deren Menge oder Verhaltnis. Materialien k6nnen
in ein Rezept eingehen (Rohstoffe), k6nnen erzeugt werden
(Endprodukte, Kuppelprodukte, Abfallstoffe), k6nnen eingehen
und wieder ausgehen (Katalysatoren) oder k6nnen erzeugt und
wieder verbraucht werden (IntraprozeBmaterialien). Intrapro-
zeBmaterialien existieren nur zwischen zwei ProzeBschritten,
sollen aber, z. B. aufgrund von sicherheitstechnischen Fragen,
explizit im Rezept dokumentiert werden. Da sie unabhangig von
einer sonstigen Verwendung auftreten k6nnen, ben6tigen sie
keine Materialstamminformationen. Ftir die Verrechnung von
Materialmengen k6nnen Formeln hinterlegt werden, so daB z. B.
eine Ausbringungsmenge vom Wirkstoffgehalt des Rohstoffes
und vom Luftdruck abhangig sein kann. Die einzelnen Positio-
nen der Materialliste werden entweder auf Rezeptebene, auf
Vorgangsebene oder auf Phasenebene dem ProzeB zugeordnet.
Gefahrenhinweise Zu den Rezepten k6nnen Sicherheitsangaben mit gesundheits-,
sicherheits- oder umweltrelevanten Hinweisen hinterlegt werden.
Sie k6nnen als Gefahrenhinweise bei der Produktion, Handha-
bung, Transport, Abfallbeseitigung oder Lagerung dienen.
Auftragsbezug Wahrend die Planungsrezepte Stammdaten darstellen, handelt es
sich bei den ProzeBauftragen und bei den Steuerrezepten urn
auftragsabhangige Rezepte. ProzeBauftrage dienen zur Durchftih-
rung samtlicher dispositiver Funktionen innerhalb des Systems,
wahrend die Steuerrezepte als Schnittstelle zur ProzeBausfuhrung
genutzt werden. Durch diese Zweiteilung kann besser auf die
unterschiedlichen Anforderungen der Funktionen eingegangen
werden.
Ein ProzeBauftrag ist ein Bewegungsdatum, das ftir die Herstel-
lung einer konkreten Charge gebildet wird. Dazu wird, entspre-
chend den Produktionsanforderungen, fur jede Charge ein Pro-

225
4 Die Anwendungsmodulkonzeption

zeBauftrag als Kopie eines Planungsrezeptes angelegt und eroff-

net. Zusatzlich enthalt ein ProzeBauftrag Datenfelder ftir aile
Funktionen, die im Rahmen der Auftragsbearbeitung notwendig
sind, wie Rezept- und Chargenidentifikation, geplante und reali-
sierte Werte ftir Mengen, Termine, Zeiten, Kosten, Kontierung,
Materialverbrauche etc.. Nach Eroffnung des ProzeBauftrages
kann dieser abgeandert werden, so daB auch von den Vorgaben
des Planungsrezeptes abgewichen werden kann. Der Aufbau des
Steuerrezeptes wird im Kapitel tiber das ProzeBmanagement er-
lautert.

4.3 Bestandsfuhrung
Die Bestandsftihrung der Produktionssteuerung hat die Aufgabe,
die sich im Betrieb befindlichen Materialien zu kontrollieren. Da
aus Sicht eines Betriebes keine eigenstandige Materialdisposition
notwendig ist, kann die betriebsinterne Bestandsftihrung als eine
spezielle, detaillierte Sicht auf die werks- oder unternehmenswei-
te Bestandsftihrung betrachtet werden. Zu den Funktionen der
betriebsinternen Bestandsftihrung gehoren Lagerverwaltung auf
Lagerplatzebene mit chargen- und qualitatsgenauer Bestandsftih-
rung, Verwaltung von beschrankten, freien und gesperrten Be-
standen, Verfallsdatenti berwachung, Verftigbarkeitsprtifungen,
Reservierungen, Chargenverfolgung etc ..

4.4 ProzeBplanung
Die aus den Produktionsanforderungen und den Planungsrezep-
ten erzeugten ProzeBauftrage werden in der ProzeBplanung den
Ressourcen unter Berticksichtigung des Kapazitatsangebotes und
der bereits verplanten Kapazitat zeitlich zugeordnet. Die Termi-
nierung kann der MRP II-Philisophie folgend in zwei Schritten
durchgeftihrt werden [121.
Kampagnenplanung Bei der Kampagnenplanung wird die Abfolge der Kampagnen
auf den Anlagen festgelegt. Eine Kampagne wird als die unmit-
telbare Folge von Chargen mit produktionstechnisch gleichem
Rezept eines Produktes oder sehr ahnlicher Produkte verstanden,
bei der zwischen den einzelnen Chargen keine speziellen Reini-
gungs- oder Umrtistvorgange durchzuftihren sind. Ziel ist dabei
die Minimierung des Rtist- und Einrichtungsaufwands der Anla-
ge. Die Kampagnenplanung findet deshalb auf der aggregierten
Ebene des Rezeptkopfes und der zugeordneten Ressource statt.

226
 4.4 Prozefiplanung

Ergebnis der Kampagnenplanung ist die Anzahl der ProzeBauf-

trage bzw. Chargen pro Kampagne, die Reihenfolge sowie Start-
und Endtermine fur die ProzeBauftrage.
Planung einer Bei der Detailplanung erfolgt eine exakte Terminierung aller
Charge Vorgange und Phasen der ProzeBauftrage unter BeIi.icksichtigung
sowohl der Primar- als auch der Sekundarressourcen. Eine De-
tailplanung kann auch ohne vorherige Kampagnenplanung er-
folgen.

Abb.4.3
CAPISCE-Plantafel

Die Durchfuhrung und Visualisierung der Planung erfolgt inter-

aktiv mit Hilfe einer Plantafe1 mit Ganttdarstellung, wie sie auch
bei Leitstandsystemen fur die diskrete Fertigung genutzt wird
Cvgl. Abbildung 4.3). Dabei sind neben Funktionen fur manuelle
und automatische Planung, Vorwarts-, Ruckwarts- und Mitte1-
punktsterminierung, OberpIi.ifung der Materialverfugbarkeit etc.
zusatzliche, prozeBindustriespezifische Funktionen zu erfulIen,
wie
• die Darstellung der Vorgangs- und Phasenebene,
• die automatische BeIi.icksichtigung von Reinigungsrezeptu-
ren bei Produktwechse1,
• die BeIi.icksichtigung der moglichen und tatsachlichen Ver-
rohrung der Produktionsanlagen,

227
4 Die Anwendungsmodulkonzeption

• die Berucksichtigung von Probeentnahmen und Laborpru-

fungen,
• die Berucksichtigung von maximal en und nicht-linearen
ProzeB- und Obergangszeiten oder
• die Berucksichtigung von Umweltbedingungen oder sonsti-
ger Restriktionen fUr die Produktion.
Nach der Planung der ProzeBauftrage werden diese fUr die Pro-
zeBdurchfuhrung freigegeben und an das ProzeBmanagement
weitergeleitet. Bei der Planung wird die aktuelle ProzeBsituation
berucksichtigt. Dafur werden realisierte Istdaten der ProzeBauf-
trage aufgenommen und in Form von Planungsanpassungen ver-
arbeitet. Damit dient die Plantafeldarstellung auch dem Monito-
ring des Auftragsfortschrittes.

4.5 ProzeBmanagement
Die Oberwachung der ProzeBdurchfuhrung wird vom ProzeB-
management wahrgenommen. Nach der Freigabe werden aus
dem ProzeBauftrag ein oder mehrere Steuerrezepte erzeugt. 1m
Gegensatz zu den Normierungsempfehlungen besteht somit die
Moglichkeit, daB ein Planungsrezept (bzw. Grundrezept oder
Master Recipe) fUr die Durchfuhrung auch auf mehrere Steuer-
rezepte abgebildet wird. Der Sinn liegt darin, daB Planungsre-
zepte aus Sicht der Disposition gebildet werden und somit Fra-
gen der Belegungsplanung, Stucklistenstrukturierung oder Kalku-
!ation im Vordergrund stehen, wahrend die Steuerrezepte aus
Sicht der ProzeBstrukturierung, Anlagenkonfigurierung oder Au-
tomatisierung gebildet werden.
Sleuerrezepl- Das ProzeBmanagement erstellt aus allen Phasen eines ProzeB-
generierung auftrages, die die gleiche Empfangerkennung aufweisen, ein
Steuerrezept (vgl. Abbildung 4.4). Daraus folgt, daB nur dann ein
Steuerrezept gebildet werden kann, wenn aile Vorgange der zu
einem Steuerrezept gehorenden Phasen freigegeben werden. Mit
der Empfangerkennung wird das Ziel des Steuerrezeptes festge-
legt. Dies ist bei manueller Fahrweise der Anlagenbediener, bei
automatisierten Systemen ist es die ProzeBsteuerung.
Fur manuelle Fahrweise wird von dem ProzeBmanagement ein
Bildschirmdialog angeboten, bei der das Steuerrezept in Form
einer Herstellanweisung (Process Instruction Sheet) dargestellt
wird. Zusatzlich besteht die Moglichkeit, die Herstellanweisung
als Arbeitspapier zu drucken. Die Herstellanweisung wird ent-
sprechend der ProzeBvorgaben des ProzeBauftrages (bzw. des

228
 4.5 Prozeflmanagement

ursachlichen Planungsrezeptes) aufgebaut. So kbnnen mit Hilfe

von ProzeBparametern Textbausteine am Bildschirm angezeigt
und mit Hilfe von ProzeBdatenanforderungen Istdaten oder Un-
terschriften von der Tastatur abgefragt werden.

Abb.4.4 Rezeptstruktur
Sleuerrezepl-
generierung

I-+-~
' Steuerrezept 1

Steuerrezept 2

Planung Ausfuhrung

Bei Einsatz von ProzeBleitsystemen werden die Steuerrezepte in

einer definierten Schnittstelle den externen Systemen zur Verfu-
gung gestellt. Mit den ProzeBparametern kbnnen z. B. Steuer-
funktionen, die sich auf die Ausfuhrung von technischen Funk-
tionen der Anlagenteile beziehen, entsprechend der NAMUR-
Empfehlung abgebildet und durch unterschiedliche Variablen
rezeptspezifisch angepaBt werden.
ProzeBruck- Das ProzeBmanagement nirnmt auch die Meldungen der laufen-
meldungen den Prozesse entgegen. Die unterschiedlichen Arten der Mel-
dungen werden analog zu den ProzeBvorgaben definiert. So ist
z. B. fur jede in den ProzeBanforderungen verlangte Informa-tion
ein entsprechender ProzeBmeldungstyp zu definieren.

229
4 Die Anwendungsmodulkonzeption

Das ProzeBmanagement uberpriift die Meldungen und leitet sie

uber eine Dispatchfunktion an den oder die fUr den Meldungs-
typ konfigurierten Empfanger weiter, die sie dann verarbeiten,
z.B. die Ressourcenverwaltung, die Rezeptverwaltung, die Pro-
zeBplanung, die ProzeBdokumentation, die Kopplung zu LIMS
oder das Mailsystem fUr Benutzernachrichten. Dabei ist es uner-
heblich, ob die Meldungen durch den Bildschirmdialog fUr Her-
stellanweisungen oder uber die Schnittstelle zu externen Syste-
men erzeugt wurden.
Monitorfunktionen gestatten die Kontrolle der eingegangenen
ProzeBmeldungen sowie der Bearbeitungszustande der laufen-
den Steuerrezepte.

4.6 Verbindung zur ProzeBautomatisierung

1st in einem Betrieb ein ProzeBleitsystem im Einsatz, so kann
zwischen dies em und dem ProzeBmanagement uber eine bereit-
gestellte Schnittstelle direkt eine Verbindung hergestellt werden.
Haufig ist aber kein einheitliches ProzeBleitsystem im Einsatz,
sondern es existiert eine heterogene Landschaft unterschiedlicher
Regier, Steuerungen, SPS und Terminals verschiedener Hersteller
und Intelligenz. Deshalb wurde das Modul PDAS (Process Data
Acquisition Server) entwickelt, das aus Sicht der Produktions-
steuerung eine einheitliche Schnittstelle zur VerfUgung stellt. Die
Aufgaben des PDAS-Moduls sind die Umsetzung zwischen den
unterschiedlichen Gerateformaten und den ProzeBmeldungsfor-
maten, die Verteilung und der Transport der Daten, die Echtzeit-
aufnahmen und Konsistenzpriifung von Daten sowie das Filtern
und Verdichten von Informationen. PDAS besteht aus mehreren
Bausteinen, z. B. dem Dynamic Configurator zur Speicherung
der Konfigurationen, dem Event Synthesizer fur Datenverdich-
tung und -transport und der Application Toolbox mit Werkzeu-
gen zur ProzeBvisualisierung.

4.7 Verbindung zu LlMS

Neben den logistischen Qualitatsmanagementfunktionen, die den
MaterialfluB vom Wareneingang bis zum Versand untersrutzen,
sind in der ProzeBindustrie spezielle Systeme fUr qualitatssi-
chernde Labors im Einsatz, die als Labormanagement- und
-informationssysteme (LIMS) bezeichnet werden [5]. Die Labors
sind fUr die Analyse von Rohstoff-, Zwischenprodukt- und End-
produktproben zustandig. Die Ergebnisse der Analyse kbnnen
den ProduktionsprozeB in erheblichem MaBe beeinflussen.

230
 4.8 Dokumentation und Auswerlung

So kbnnen von den Analysewerten einer IntraprozeBkontrolle

die weiteren Verfahrensschritte, die Produktionsdauern oder der
Materialeinsatz abhangen. Fur die Kopplung von LIMS werden
die gleichen Mechanismen wie fUr die Anbindung der ProzeB-
leitebene genutzt, d. h. ProzeBvorgaben, insbesondere Priifer-
gebnisanforderung, und ProzeBmeldungen.

4.8 Dokumentation und Auswertung

Das Modul hat einerseits die Aufgabe, Hilfsmittel fUr die Erzeu-
gung von Reports und Auswertungen uber die durchgefuhrten
Prozesse bereitzustellen, z. B. Ermittlung der Anlagenperfor-
mance. Hierzu werden allgemein ubliche Standardauswertungen
angeboten. Wichtig ist jedoch die Mbglichkeit, daB sich der An-
wender mit Endbenutzerwerkzeugen relativ einfach aus den zur
verfugung stehenden Daten selbstandig individuelle Auswertun-
gen zusammenstellen kann. Dazu kbnnen tiber Selektionsbild-
schirme Informationen aus Stammdaten (Planungsrezept, Res-
sourcen etc.) und ProzeBablaufe (ProzeBauftrage, ProzeBmel-
dungen) extrahiert und nach Ubergabe an Windows-Programme,
wie Excel und Access, dort aufbereitet und prasentiert werden.
Chargenprotokoll Als Dokumentationsaufgabe ist insbesondere die Bereitstellung
der Informationen fur elektronische Chargenprotokolle hervor-
zuheben. Chargenprotokolle sind notwendig, urn der allgemein
anerkannten und geforderten GMP (Good Manufacturing
Practice) der amerikanischen FDA (Food and Drug Administra-
tion) zu genugen. DafUr werden alle relevanten Werte und Er-
gebnisse der Prozesse (wie Material- und Ressourcenverbrauche,
Gutmengen, Qualitatsinformationen der Analysen und elektroni-
sche Unterschriften) der verantwortlichen Anlagenfahrer mit
Zeitstempel aufgezeichnet und zusammen mit den ProzeBauftra-
gen einschlieBlich der Informationen des Planungsrezeptes ge-
speichert. Fur die geforderte langfristige Aufbewahrung steht ei-
ne Schnittstelle zu einem optischen Archiv mit WORM-Technik
zur Verfiigung.

231
5 System integration

5 Systemintegration

Durch den vOlWiegend dispositiven Charakter der CAPISCE-

Funktionen sind die Anwendungsmodule transaktionsorientiert,
d.h. es ubelWiegen Dialoganwendungen (z. B. Datenpflege, Ad-
hoc-Auswertungen, interaktive Planung) und automatisierte,
zeitunkritische AbIaufe (z. B. Generierung von ProzeBauftragen
und Steuerrezepte, Verarbeitung von ProzeBmeldungen). Damit
konnten die Module mit der gleichen Systemtechnik wie andere
Anwendungen von R/3 realisiert werden, d.h. die Module sind in
ABAP/4 auf R/3-Basis entwickelt. Aus Sicht der bestehenden R/3-
Logistikanwendungen kbnnen die CAPISCE-Module als ElWeite-
rung und Anpassung an die Besonderheiten der ProzeBindustrie
betrachtet werden [15]. Es wurden nicht aile CAPISCE-Module
neu entwickelt, sondern auf die fur den Einsatz bei diskreter
Fertigung existierenden PP-Module zUrUckgegriffen.
Bezug zu anderen R/3- So ist die RessourcenvelWaltung eine ElWeiterung des Moduls
Modulen ArbeitspIatze, die Bestandsfuhrung ist urn chargenrelevante In-
formationen elWeitert worden. Die RezeptvelWaltung basiert auf
den Modulen Arbeitsphine und Fertigungsauftrage. Die Pla-
nungsrezeptkbpfe und die Vorgange sind mit den gleichen Ta-
bellen realisiert wie die Arbeitsplane. Dies war mbglich, da die
Anforderungen der RezeptvelWaltung in einem nicht unerhebli-
chen MaBe die Arbeitsplangestaltung beeinfluBt haben. Ein Pro-
zeBauftrag ist, wie ein Fertigungsauftrag, eine spezielle Belegart,
fur den der Auftragstyp PV vorgesehen ist. Fur die Umsetzung
der ProzeBvorgaben wurden aber neue Tabellen und Masken
benbtigt. Die Terminierungsfunktionen und die graphische Dar-
stellung der Plantafel des ProzeBplanungsmoduls wurde gemein-
sam mit den Funktionen fur das Shop Floor Control-Modul ent-
wickelt, wobei die Erfahrungen der DASS-Leitstandsentwicklung
eingeflossen sind. Neben der Ganttdarstellung konnten auch fur
das Management der Ressourcenstrukturen und der Anordnungs-
beziehungen in den Rezepten graphisch-interaktive VelWaltungs-
funktionen, wie in (8) vorgeschlagen, realisiert werden.

232
 5 System integration

Das ProzeBmanagement ist dagegen eine Neuentwicklung. Die

Schnittstelle PI-PCS gestattet die Verbindung zu der ProzeBleit-
ebene. Fur Auswertungen mit Windows-Programmen wird die
OLE-Schnittstelle des R/3-Systems genutzt.
Rl3-lnlegralion Bei der Verwendung bestehender PP-Bausteine hat in erster Li-
nie nicht die Reduzierung des Entwicklungsaufwandes im Vor-
dergrund gestanden, sondern vielmehr die Anbindung zu den
anderen Logistik- und Finanzmodulen. Beispielsweise fuhren die
gemeinsamen Strukturen von Arbeitsplan und Planungsrezept
bzw. Fertigungsauftrag und ProzeBauftrag dazu, daB ProzeBauf-
trage nicht nur terminiert und an ProzeBleitsysteme weitergeleitet
werden kbnnen, sondern auch aIle anderen Funktionen der Fer-
tigungsauftragsabwicklung zur Verfugung stehen, z.B. die Kalku-
lation. Auch bei der Namensgebung fur Systemobjekte und -ab-
laufe sind die allgemeinen Richtlinien zu Begriffsdefinitionen im
R/3-System berticksichtigt. Dies hat zwar den Nachteil, daB die
Begrifflichkeiten nicht vollstandig deckungsgleich mit den Nor-
mierungsempfehlungen sind Cz.B. unterschiedliche Bedeutung
der Begriffe Operation, Charge oder Funktion). Das wird aller-
dings durch den Vorteil der durchgangigen Begriffsgestaltung
uber den gesamten LogistikprozeB kompensiert, was auch den
integrativen Charakter der Konzeption verdeutlicht. Zusammen
mit anderen R/3-Anwendungen kann mit den CAPISCE-Modulen
die Unternehmensleitebene, die Produktionsleitebene und die
Betriebsleitebene, entsprechend Abbildung 3.1, abgedeckt wer-
den.
ARIS-Informalions- Fur die Modulkonzeption und zur Beschreibung der logischen
modelle Systemfunktionalitat wurden Informationsmodelle erarbeitet, die
in Form von GeschaftsprozeBmodellen und Datenmodellen do-
kumentiert sind. Sie sind im R/3-Analyzer und im ARIS-Toolset,
die auf der Architektur integrierter Informationssysteme [16,171
basieren, hinterlegt und bilden einen Bestandteil der R/3-
Referenzmodelle [7).
PP-PI Mit Release 3.0 von R/3 sind die CAPISCE-Module unter der Be-
zeichnung PP-PI allgemein verfugbar [151, wobei noch nicht aIle
Module voll den oben beschriebenen Funktionsumfang aufwei-
sen, insbesondere nicht die ProzeBplanung. Aufgrund der Be-
triebsstruktur der Pilotinstallationen wurden bei der Implemen-
tierung vorrangig die Anforderungen der chemischen Chargen-
fertigung berticksichtigt. Fur die Weiterentwicklung von PP-PI ist
neben dem Ausbau der ProzeBplanungsfunktionalitat auch mit
einer starkeren Untersttitzung spezifischer Anforderungen

233
 6 Pitotinstallationen

der kontinuierlichen Produktion sowie anderer Branchen, wie

Pharma-, Nahrungs- und GenuBmittelindustrie, zu rechnen.
PDAS- Das Modul PDAS als echtzeitorientierte Anwendung ist nicht Be-
Implementierung standteil des R/3-Systems. Es wurde von Digital Equipment auf
Basis des Systems BASEstar entwickelt und ist auf den Betriebs-
systemen UNIX (OSF/1 und andere), Windows NT und
OpenVMS verfugbar.

6 Pilotinstallationen

Obwohl Zeneca zu einem der ersten SAP-Anwender gehbrt

(Zeneca ist aus einem Teil des ICI-Konzerns entstanden), sind in
den im Projekt involvierten Unternehmensbereichen nur die
SAP-Finanzsysteme im Einsatz. Fur den logistischen Bereich
werden ein eigenentwickeltes MRP II-System sowie verschiedene
kleinere , meist isolierte Systeme (z.B. ein Short-Term Scheduler)
angewandt. Auf der ProzeBausfUhrungsebene werden neben ma-
nuell betriebenen Anlagen verschiedene Automatisierungssyste-
me eingesetzt. Zenecas Ziel ist die durchgangige Untersttitzung
aller Ebenen. Dazu werden die CAPISCE-Module als Integra-
tionsinstrument genutzt. AnschlieBend sollen sukzessive weitere
SAP-Module eingefUhrt werden, urn den gesamten Logistikbe-
reich abzudecken. Das in Abbildung 4.1 dargestellte Kopp-
lungsmodul zu den unternehmensweiten Planungssystemen ist
daher auch eine Zeneca-spezifische Lbsung, urn dort die CA-
PISCE-Bausteine in die bestehenden DV-Systeme einzubinden.
Bei Einsatz der anderen SAP-Logistikmodule ist der Kopplungs-
baustein nicht notwendig.
Erste Installationen Als Pilotinstallationen wurden die beiden Betriebe Fine Chemi-
cals 1 (FC!) in Huddersfield (England) und Procion in Grange-
mouth (Schottland) gewahlt. In FC1 werden ZWischenprodukte
fur Farben und Agrochemikalien hergestellt. Der Betrieb ist nur
teilweise automatisiert und wird vornehrnlich manu ell gefahren.
In Procion werden Textilfarben in stark automatisierten Prozes-
sen hergestellt. Da noch nicht aIle Module produktiv arbeiten,
kann zur Zeit noch keine genaue Aussage uber den betrieb-
lichen Nutzen der Installationen getroffen werden. Nach dem
jetzigen Stand wird von Zeneca aber folgender Nutzen erwartet:

234
 Literaturverzeichnis

Nutzenpotentiale • In der Reduzierung von Lagerbestanden, von Nacharbeiten

aufgrund Qualitatsproblemen sowie des administrativen
Overheads wird das groBte Potential gesehen.
• Auch die Verringerung notwendiger Vorlauflaufzeiten und
unerwarteter ProzeBereignisse wird als Nutzen erwartet.
• In geringerem Urnfang sind ebenfalls positive Effekte be-
zuglich Energie- und Materialausbeute, Abfallaufkommen,
Kapazitatsnutzung und Anlagenverfugbarkeit geplant.
Zwei weitere Installationen, die in Kurze in beiden Standorten
durchgefuhrt werden, belegen die richtige Konzeption des Sy-
stems.

Literaturverzeichnis
[1] Allweyer, Th.; Loos, P.; Scheer, A.-W.: An Empirical Study
on Scheduling in the Process Industries, in: Scheer, A.-W.
(Hrsg.), Veroffentlichungen des Instituts fur Wirtschafts-
informatik, Heft 109, Saarbrucken, JuH 1994.
[2] Bertsch, 1.; Geibig, K.-F.; Weber, J.: Betriebswirtschaftlicher
Nutzen moderner ProzeBleittechnik in der Chemischen In-
dustrie, in: atp Automatisierungstechnische Praxis,
31(989)1, S. 5-11.
[3] Eckelmann, W.; Geibig, K.-F.: Produktionsnahe Informati-
onsverarbeitung - Basis fur CIP, in: CIM Management,
5(989)5, S. 4-9.
[4] Hofmann, M.: PPS - nichts fur die chemische Industrie?, in:
io Management, 61(1992)1, S. 30-33.
[5] Horner, E.; KIur, H.-P.; Kuhle, J.: Trends in der LIMS-
Entwicklung, in: GIT Fachz. Lab., 38(1994)6, S. 695-696.
[6] ISA-dS88.01 (International Society for Measurement and
ControD, Batch Control, Part 1: Models and Terminology,
Draft 12, 1994.
[7] Keller, G.; Meinhardt, S.: SAP Rl3-Analyzer - Optimierung
von Geschaftsprozessen auf Basis des Rl3-Referenzmodel-
les, SAP AG (Hrsg.), Walldorf 1994.
[8] Loos, P. : Konzeption einer graphischen Rezeptverwaltung
und deren Integration in eine CIP-Umgebung, in: Scheer,
A.-W. (Hrsg.), Veroffentlichungen des Instituts fur Wirt-
schaftsinformatik, Heft 102, Saarbrticken, Juni 1993.

235
Literaturverzeichnis

(9) Loos, P.: Produktionsplanung und -steuerung in der chemi-

schen Industrie, in: Scheer, A.-W. (Hrsg.), Beitrage zur Ta-
gung der Wissenschaftlichen Kommission Produktions-
wirtschaft, Saarbri.icken 1993, S. 121-135.
(10) Loos, P.; Scheer, A.-W.: CAPISCE - A System Architecture for
Production Management in Process Industries, in: World
Batch Forum 1994 (Tagungsband, Phoenix AZ, 7.-9. Marz
1994), S. 18.1-18.8.
(11) Luber, A.: How to Identify a True Process Industry Solution,
in: Production and Inventory Management, 12(1992)2, S.
16-17.
(12) Martin, F. c.: Planning Production Campaigns, in: Producti-
on and Inventory Management Journal, 30(1989)2, S. 1-5.
(13) NAMUR-Empfehlung (Normenarbeitsgemeinschaft fur MeB-
und Regelungstechnik in der Chemischen Industrie) NE33,
Anforderungen an Systeme zur Rezeptfahrweise, Mai 1992.
(14) Polke, M.: CIP in der Verfahrensindustrie, in: CIM Manage-
ment, 5(1989)5, S. 34-35.
(15) SAP AG (Hrsg.): Produktionsplanung fur die ProzeBindu-
strie, PP500 Vorlaufige Version, R/3 System, Release 3.0,
November 1994.
(16) Scheer, A.-W. : ARIS Toolset: A Software Product is Born, in:
Information Systems, 19(1994)8, S. 609-626.
(17) Scheer, A.-W.: Wirtschaftsinformatik - Referenzmodelle fur
industrielle Geschaftsprozesse, 6. A., Springer Verlag Berlin
et al. 1995.
(18) Schurbuscher, D.; Metzner, W.; Lempp, P. : Besondere An-
forderungen an die Produktionsplanung und -steuerung in
der chemischen und pharmazeutischen Industrie, in: Chem.-
Ing.-Tech., 64(1992)4, S. 333-341.

236
Bericht uber das Projekt
"Einheitliche Anlagenabwicklung Ver-
trieb" (EAV) am Beispiel des
"Internationalen Fachbereichs Hochspan-
nungstechnik"
der AEG Daimler Benz Industrie

Thea G. Sulzmann

DV-Organisation Vertriebsregionen der AEG Daimler Benz

Industrie, Frankfurt

237
1 Oberblick

1 Uberblick

Die AEG Daimler Benz Industrie arbeitet derzeit an dem Projekt

"Einheitliche Anlagenabwicklung Vertrieb" auf der Basis der
Standardsoftware SAP R/3.

1.1 Projektziel
Ziel des Projektes ist es, mit einem einheitlichen Verfahren die
Anforderungen im Anlagengeschaft, unter der Pramisse einer
konsistenten und redundanzfreien Datenhaltung, abzudecken.
Da das Rechnungs- und Finanzwesen derzeit dv-technisch aus-
reichend unterstutzt wird, beginnt der Einstieg in SAP R/3 mit
dem Projektmanagement anhand des Moduls PS. Dabei kommen
den Besonderheiten unseres Anlagengeschaftes und den Anfor-
derungen an ein dv-gesti.itztes System zur Abwicklung und Bear-
beitung von Auftragen bzw. Projekten besondere Beachtung zu.
Die Methoden und die Vorgehensweise im Projekt sowie die
Dokumentation der Anforderungen unseres Anlagengeschaftes
und deren Umsetzung in SAP R/3 sind entscheidende Faktoren
fur eine erfolgreiche Einfuhrung.

1.2 Zum Unternehmen

Die AEG Daimler-Benz Industrie ist eine weltweit tatige Anbiete-
rin von integrierten Systemlbsungen in zukunftsorientierten
Technologiebereichen.
Wir haben uns zum Ziel gesetzt, in den Markten fur Bahn-
systeme, Mikroelektronik, Dieselantriebe, Energietechnik
und Automatisierungstechnik in strategischen Schwerpunkt-
segmenten eine fuhrende Rolle einzunehmen.
Die AEG Daimler-Benz Industrie ist weltweit in 87 Landem mit
insgesamt 308 Standorten vertreten; in Deutschland mit 73, in
Europa mit 107 und im ubrigen Ausland mit weiteren 128 Stand-
orten.

238
 1.2 Zum Untemehmen

1m Geschaftsjahr 1994 wurde ein Umsatz von 10,3 Mrd. DM bei

nahezu 44.800 Mitarbeitern erreicht. Davon entfalJen 55,2% auf
Deutschland, 15,7% auf EU ohne Deutschland, 10,1% auf das
ubrige Europa, 13,3% auf Amerika, 4,5% auf Asien und Australi-
en sowie auf Afrika 1,2%.
Das Geschaftsfeld Energietechnik zahlt heute mit
- Hochspannungstechnik,
- Mittelspannungstechnik,
- Transformatoren,
- Netztechnik,
- Komponenten und elektrischen Maschinen
zu den weltweit tatigen Systemanbietern fur schlusselfertige
Energieversorgungssysteme.
In diesem Geschaftsfeld wurde 1994 ein Umsatz von 2.517 Mio.
DM, bei 13.487 Beschaftigten erzielt, wovon der Auslandsanteil
43% einnimmt. Die AEG Daimler-Benz Industrie wird diese
Kompetenz in Zukunft weiter ausbauen.
Hochspannungsanlagen sind wichtige Bindeglieder zur Ubertra-
gung elektrischer Energie vom Kraftwerk zum Verbraucher. Da-
bei werden Verbindungen zwischen Transformatoren und Lei-
tungen uber Hochspannungs-Leistungsschalter zu- oder abge-
schaltet. Die AEG Daimler Benz Industrie baut und liefert Anla-
gen mit Leistungsschalter fur Nennspannungen von 52 - 245 KV.

2 Projektmanagement als Ausgangsbasis

Das Rechnungswesen wird derzeit bereits durch bestehende Sy-
sterne ausreichend unterstiitzt, so daB hier noch kein unmittel-
barer Handlungsbedarf hinsichtlich des SAP R/3 Einsatzes be-
steht. 1m Bereich Logistik werden unterschiedliche Systeme ge-
nutzt, die in Hard- und Software divergieren und nicht durch-

239
2 Projektmanagement als Ausgangsbasis

gangig sind. Hier besteht ein groBer Bedarf an einer einheitli-

chen und integrationsfahigen Lbsung fur die Untersti.itzung der
Anlagenabwicklung mit konsistentem Datenbestand. Deshalb
konzentriert sich das Projekt EAV im Anfangsstadium auf die
Projekt-abwicklung. Das Ziel ist jedoch die Gesamtintegration
mit Einbeziehung des Rechnungswesens. Die Anlagenabwick-
lung des "Internationalen Fachbereichs Hochspannungstechnik"
ist reprasentativ fur das Anlagengeschaft der AEG Daimler-Benz
Industrie. Somit orientieren wir uns in diesem Pilotprojekt an
den Anforderungen dieses Fachbereichs und richten die Auspra-
gung im SAP R/3-System an dessen Geschaftsablaufen aus.
Das Modul PS ist ohne Teilfunktionen (siehe Abbildung 1) aus
den Modulen FI, CO, SD und MM nicht lebensfahig.

PS - Projektmanagement (Project System)

FI - Finanzwesen (Financial Accounting)

CO - Kosten-/Leistungsrechnung (Controlling)

SD - Vertrieb (Sales & Distribution)

MM - Materialwirtschaft (Material Management)

Abbildung 1
Modul PS im System-
umfeld

240
 3.1 Besonderbeiten und Anfordernngen

Da die Einftihrung von PS nur dann sinnvoll ist, wenn danach

R!3 in seiner Gesamtfunktionalitat eingesetzt wird, sind aIle R!3-
Module fur eine Kompletteinfuhrung auszupragen, urn damit die
bisherigen Altsysteme zu ersetzen. Nur so kann ein integriertes
System mit konsistenten Daten entstehen. Zu den derzeit beste-
henden Altsystemen sind deshalb auch keine permanenten
Schnittstellen vorgesehen, so daB fur die Obergangszeit der
Feldversuche Doppeleingaben notwendig sein werden.
Urn PS produktiv einzusetzen, mtissen wir die Funktionen in Fl,
CO, SD und MM komplett ausgepragt und die Datenbestande
aus den Altsystemen mit temporaren Schnittstellen tibernommen
haben.

3 An lagengeschaft

3.1 Besonderheiten und Anforderungen

Durch eigenes Engineering werden aus Produkten und Leistun-
gen technologische Anlagen fur den Kunden produziert und in-
stalliert. Dabei werden meistens unterschiedliche Anforderungen
an die technische Konfiguration der Anlagen gestellt; es handelt
sich also urn Projekte mit Einmalcharakter, im Gegensatz zum
Seriengeschaft. Hier bestehen deshalb gewisse Risiken, die des-
halb eine spezifische Projektorganisation erfordern. Urn so mehr
gewinnt das Thema Projekt-Controlling an Bedeutung. Darin
werden die Vorhaben nach Gesamt- und Teilvorhaben sowie
Arbeitspakete hinsichtlich Plan, SolI, 1st und deren Abweichun-
gen betrachtet.
Jedem Kundenauftrag liegt ein Angebot zugrunde. Wenn wir
wissen wollen, wie die Anforderungen der Projektabwicklung in
diesem Anlagengeschaft in SAP R!3 zu realisieren sind, ist die
Ausgangssituation ftir uns von groBer Bedeutung. Daraus erge-
ben sich eine Ftille von Fragen.

241
3 Anlagengeschaft

• Welche Teile bzw. Komponenten und Leistungen bilden die

Struktur einer Anlage?
• Wie entsteht ein Angebot?
• Wie ist die Vorgehensweise bei der Kalkulation?
• Mit welchen Tools wird ein Angebot erstellt?
• Wie ist das Zusammenspiel dieser unterschiedlichen Systeme?
• Welche Schnittstellen sind wichtig und sinnvoll?

3.2 Die technischen Strukturen einer Anlage

1m "Internationalen Fachbereich Hochspannungstechnik" werden
zur Erstellung von Angeboten Anlagen nach unterschiedlichen
Anlagenteilen/Techniken und Leistungen strukturiert. Dazu wird
ein sogenanntes Anlagen-Struktur-System, kurz "ASS" genannt,
angewendet. In dies em System werden Beziige gemaB der un-
terschiedlichen Techniken, Leistungen wie Projektierung bis hin
zu den Vertriebssondereinzelkosten gegliedert.
Die jeweiligen Beziige und Leistungen werden zudem nach dem
Verwandtschaftsgrad der Herkunft:

• eigener Fachbereich (FB),

• fremder Fachbereich (FB)
• sowie konzernverbundene Unternehmen
• und Fremdlieferanten

lmterschieden.
Geschaftsbereiche (GB) sind in Fachbereiche (FB) unterteilt.
Beim fremden Fachbereich handelt es sich urn den FB eines an-
deren GB; d.h. jeder Technik bzw. Leistung wird durch dieses
Anlagen-Struktur-System eine eindeutige Nummer zugeordnet.

3.3 Die Angebotskalkulation

Wir unterscheiden grundsatzlich zwischen zwei Arten der Ange-
botserstellung. Zum einen gibt es ein vorgegebenes Leistungs-
verzeichnis, das mit Preisen versehen an den Kunden abgegeben
wird. Aufbau und Detaillierungsgrad entsprechen den Vorgaben
des Kunden bzw. des Planungsbiiros.

242
 3.4 Zusammenspiel der vorbandenen DV-Systeme

Zum anderen kann dem Angebot eine technische Beschreibung

zugrunde liegen. Das Angebot enthalt einen Preis fur die kom-
pIette Anlage, ggf. auch fur in sich geschlossene Anlagenteile. In
beiden Fallen wird in der internen Kalkulation die Struktur nach
ASS beriicksichtigt.
Fur die Erstellung solcher Angebote stehen unterschiedliche
AEG-eigene DV-Toois zur Verfugung, die den jeweils speziellen
Anforderungen gerecht werden. Darin kbnnen - anhand der
technischen Beschreibung bzw. des Leistungsverzeichnisses - die
Kosten der einzelnen Positionen errnittelt und kalkuliert werden.
Ggf. werden die Anlagen vorher in separaten technischen Pro-
jektierungstools konfiguriert und die Daten als Kalkulations-
grundlage in das Angebotstool ubernommen.
Beim "International en Fachbereich Hochspannungstechnik" er-
folgt derzeit die interne Gesamtkalkulation der Angebote mit ei-
nem separaten Kalkulationstool MS-EXCEL. In dies em Kalkula-
tionstool werden die Positionen nach ASS und entsprechend
dem Verwandtschaftsgrad der Bezuge und Leistungen verdichtet
und kalkuliert. Die vorangegangene Nebenrechnung zur Koste-
nerrnittlung der Positionen ist dafur die Basis.

3.4 Zusammenspiel der vorhandenen DV·Systeme

Fur die urnfangreichen und vielfaltigen Anforderungen des Anla-
gengeschaftes gibt es derzeit kein multifunktionales System, das
aile Anforderungen der Anlagenabwicklung urnfassend dv-
gesti.itzt abdeckt. Aile Projektdaten sollten in einer Datenbank
gefuhrt werden. Da die Fulle der Daten sehr unterschiedliche
Charaktereigenschaften aufweist, ist dies derzeit nicht realisier-
bar. Wir setzen deshalb dazu mehrere Systeme ein. Urn dabei
Doppeleingaben und redundante Datenhaltung zu vermeiden,
mussen diese rniteinander verbunden sein. Dazu entwickeln wir
derzeit als Kernsystem das Projektdatenbanksystem PRODAS
(siehe Abbildung 2). Darin befinden sich die Kerndaten aller
Projekte und die Verbindungshinweise zu den Umsystemen.

243
3 AntagengescbiiJt

Abbildung 2
Projektdatenbank-
Das Projektdatenbank-System als
System Plattform

Beispielsweise befinden sich die Daten der Konstruktionszeich-

nungen in dem CAD-System "Ruplan" (Rechneruntersttitzte Pla-
nung). Die Daten der Angebotskalkulation sind in MS-EXCEL
bzw. Elaplan- A. Die Dokumentationen sowie der gesamte
Schriftverkehr zu einem Projekt befindet sich in WINWORD, die
Daten der Projektabwicklung in SAP Rl3.
Unmittelbar nach dem ersten Projektkontakt des Akquisiteurs
beim Kunden erfolgt die Erfassung des Projektes in PRODAS, in
dem Teilsystem Vertriebsmeldewesen. Das Projekt erhalt eine
eindeutige Projektnummer, von der eine Stelle den Status des
Projektes kennzeichnet. 1st der Status "Anfrage" erreicht, kann
das Angebot erstellt werden.
]edes Projekt fUr sich betrachtet ist zwar immer ein Unikat, hat
jedoch u.U. Ahnlichkeiten mit vorangegangenen Projekten. Bei
der Erstellung von Angeboten fOr soiche Projekte konnen in
PRODAS Ober sogenannte Ahnlichkeitsmerkmale Referenzprojek-
te gesucht werden und ggf. fOr die Auslegung der Technik, der
Kalkulation und der Strukturierung benutzt werden.
Basierend auf der internen Kalkulation in MS-EXCEL bzw.
Elaplan-A konnen die Angebotsdaten fOr die Abwicklung des
Projektes in das SAP Rl3-System Obernommen werden. Dazu
werden die Daten aus diesen vorgelagerten Kalkulationssyste-
men Ober die Standardschnittstelle gemaB GAEB (Gemeinsamer
AusschuB Elektronik im Bauwesen) bereitgestellt und per Batch-

244
 4.1 Projektabwicklung und Strnktur

Input in das SAP-System tibernommen. Dber die Standard-

schnittstelle nach GAEB kann auch mit den Planungsbtiros bzw.
dem Kunden Datenaustausch fur Anfragen und Angebotsabga-
ben betrieben werden.

4 Umsetzung in SAP Rl3

4.1 Projektabwicklung und Struktur

Die Eroffnung eines Auftrages in SAP Rl3 wird per Batch-Input
in drei Schritten durchgefuhrt:
1. Anlegen des Kundenauftrages in SD.
2. Anlegen des internen Auftrages in PS.
3. Dbernahme der Kalkulationswerte aus dem Angebot.
1m SD wird tiber die Schnittstelle zum vorgelagerten Angebots-
system der Kundenauftrag eroffnet. Die Fakturierung der Kun-
denrechnung erfolgt aus dem SD-Auftrag heraus. In dem darun-
terliegenden Element des Hauptauftrages werden als Grundlage
zur Fakturierung an den Kunden die Erlose in Summen abgelegt.
Dazu konnen ab Release 3.0 Zahlungsplane als Abbildung der
zu erwartenden Zahlungen hinterlegt werden.

Abbildung3
Auftragser6ffnung per Auftragser6ffnung per Batch-Input
Batch-Input

SD PS

ASS 033 Projekt.

WASS 670 BeZ.fLeist!

245
4 Umsetzung in SAP Rl3

In PS wird die Projektdefinition Csiehe Abbildung 3) angelegt;

dieser wird der interne Hauptauftrag als sogenanntes Auftrags-
PSP-Element unterstellt. Zu jeder im Angebot vorhandenen ASS-
Nr. wird ein entsprechendes PSP-Element angelegt und einstufig
als Positionselement unter das interne Auftrags-PSP-Element ge-
hangt.
Die Nummernvergabe fur die PSP-Elemente erfolgt manuell. Alle
zu einem Projekt gehorenden Elemente haben am Anfang der
PSP-Elementnummer die eindeutige Projektnummer aus PRO-
DAS. Dadurch konnen die Elemente optisch mit dem Projekt
identifiziert werden. Der darunterliegende Hauptauftrag bzw.
Nachtrag wird durch eine zweistellige Zahlnummer definiert. Die
einstufig darunter liegenden PSP-Elemente der jeweiligen ASS
werden durch eine weitere, dreistellige Zahlnummer definiert.
Diese automatische Anordnung und die daraus resultierende
Hierarchie entspricht nicht unbedingt der gewiinschten Abwick-
lungsstruktur des Projektes. Deshalb konnen Umsortierungen der
PSP-Elemente vorgenommen werden.
Zur Unterteilung und Gruppierung mehrerer PSP-Elemente kon-
nen sogenannte Hierarchieknoten in Form von neuen PSP-
Elementen eingefUgt und ggf. der Inhalt von einem bestehenden
PSP-Element in neue PSP-Elemente aufgeteilt und zugeordnet
werden. In den jeweiligen Hierarchieknoten werden die Daten
der darunterliegenden PSP-Elemente verdichtet dargestellt. So
laIst sich nach den Anforderungen an die Projektorganisation
und den Vorstellungen des Projektleiters bzw. -verantwortlichen
jede beliebige Struktur realisieren.
Im dritten Schritt der Datenubernahme erfolgt die jahresbezoge-
ne Kostenplanung. Bei der Datenubernahme werden die kalku-
lierten Werte aus dem Angebot den Positions-PSP CASS-Nr.) un-
ter Berucksichtigung der jeweiligen Kostenart als Kosten fUr das
laufende Jahr zugeordnet. Bei einer mehrjahrigen Laufzeit eines
Projektes konnen die Kosten Csiehe Abbildung 4) eines PSP-
Elementes erwartungsgerecht auf die Jahre verteilt werden.

246
 4.2 Projektkontroll-Termine

Abbildung4
Kostenplanung der Jahresbezogene Kostenplanung der PSP
PSP

Fur diese detaillierte Planung nach Kostenarten werden je nach

Charakter der ASS-Nr.
- Bezuge und Leistungen, je nach Verwandtschaftsgrad,
- Projektierungsleistung sowohl Vertrieb als auch Technik und
- Gernein- und Vertriebssondereinzelkosten (GMK und VSEK)
in KopielVorlagen als Referenzkalkulation eines PSP-Elernentes
benutzt.

4.2 Projektkontroll-Termine
Jedern PSP-Elernent werden Anfangs- und Endterrnine zugewie-
sen. Daraus HiBt sich eine grobe Terrninsituation ableiten. Urn
jedoch eine detailliertere Terrninkontrolle durchzufuhren, sind
sowohl Balken-, Terrnin- und NetzpHine zu erstellen. D.h. urn
den Leistungsumfang eines PSP zu erfullen, sind rneistens rneh-
rere unterschiedliche Vorgange notwendig. Deshalb kbnnen, be-
zogen auf ein PSP-Elernent, Vorgange gebildet, zugeordnet und
bewertet werden.
Zur Darstellung als Netzplan ist die Verknupfung der Vorgange
und deren Abhangigkeiten zueinander notwendig.

247
4 Umsetzung in SAP Rl3

Da zum Zeitpunkt der Angebotskalkulation noch keine techni-

sche Detailprojektierung durchgefuhrt wurde, sind nun die Kon-
struktion und der Autbau der Anlage zu definieren. Die dafur
erforderlichen technischen Berechnungen und Unterlagen sind
zu erstellen. Die Fertigung bzw. Lieferung ist zu beauftragen,
grbBtmbgliche Transporteinheiten sind zusammenzustellen und
zum Versand zu bringen. Das Auslandsgeschaft verlangt hierfur
besondere Abwicklungsmodalitaten, wie Freigabeprozeduren,
Fracht-, Zollabwicklung, Transportversicherungen etc .. Vor der
Auslieferung werden aile Produkte einer urnfangreichen mecha-
nischen und elektrischen Prtifung unterzogen. All diese Vorgan-
ge sind mit Aufwand, Dauer, Terminen und Arbeitsplatzen zu
behaften.
Daraus entsteht ein aussagefahiger Netzplan, der dazu beitragt,
das Projekt zeitlich zu koordinieren und damit termingerecht ab-
zuwickeln. Die arbeitsplatzbezogene Betrachtung des Netzplanes
eines oder mehrerer Projekte kann fur die Kapazitatsplanung ge-
nutzt werden.
Urn eine rationelle Netzplanerstellung zu ermbglichen, werden
sogenannte Standardnetzplane erstellt, die als Bausteine fur Ge-
samtnetzplane herangezogen werden kbnnen.
Nach der sogenannten "Technischen Orderklarung" (TOK) kann
vorgangsbezogen die Bedarfsanforderung (BANF) erstellt und
deren Umsetzung in eine Bestellung an die Fertigung bzw. den
Lieferanten erfolgen. Der Bestellurnfang und die technischen
Daten kbnnen aus den Projektierungsunterlagen bzw. Dokumen-
tationen der jeweiligen Systeme tiber PRODAS tibernomrnen
werden.

4.3 Projektkontroll-Kosten
Neben den Terminen werden die Vorgange auch mit den jewei-
ligen Kosten des Bestellurnfangs beplant. Bei der Buchung der
Lieferantenrechnung werden die 1st-Kosten verdichtet auf dem
PSP-Element den Plankosten gegentibergestellt.

248
 43 Projektkontroll-Kosten

Abbildung5
Obligo und
Istkosten
Obligo und Istkosten

Vorkalkulation Budgec BudgetlFreigabe (3.0) Verfilgt

Auf den PSP-Elementen werden zu den jeweiligen Budgets die

verfugten Mittel verdiehtet dargestellt. Die verfugten Mittel (siehe
Abbildung 5) ergeben sieh aus den 1st-Kosten und den Obligos
aller zugeordneten Auftrage bzw. Vorgange. Das Delta zwischen
Budget und den verfugten Mitteln entspricht dem noch verfugba-
ren Teil. Bei der Verfugung von Mitteln kann das Erreichen der
Budgetgrenze signalisiert werden.
Die Gegenuberstellung der zur Verfugung stehenden Mittel und
der 1st-Kosten ermoglieht eine effiziente Projektkontrolle. Der
Abgleieh des technischen Projektfortschrittes bzw. Fertigstel-
lungsgrades mit den verfugten und den noch zur Verfugung ste-
henden Mitteln ermoglicht daruber hinaus eine Bewertung des
aktuellen Projektstatus.
Die jeweiligen Kalkulationsstande lassen sieh z.B. als Auftrags-
eingangskalkulation und als Zwischenkalkulation ablegen, so
daB dadurch kontinuierlich die Entwieklung des Projektes ver-
folgt werden kann. Ein stichtagsbezogener Soll-Ist-Vergleieh er-
moglicht eine Darstellung der Projektentwieklung und des Er-
gebnisses.
Die Betrachtung aus der Sieht des Untemehmens-Controlling ist
dagegen funktionsbezogen, z.B. Beschaffung, Konstruktion, Pro-
duktion, Montage. Hier bilden Werte, wie Sachanlagen, Forde-
rungen und Bestande, Gegenstand der Betrachtung.

249
5 Vorgehensweise

5 Vorgehensweise

5.1 Oas Projektteam und die Methodik

Fur die Umsetzung des Projektes ist ein Kernteam eingesetzt.
Das Kernteam besteht aus Mitarbeitern, die

• zu 100% fur das Projekt zur verfugung stehen,

• Erfahrung aus den jeweiligen Bereichen mitbringen,
• die Zusammenhange der ubergreifenden Geschaftsablaufe
kennen
• und die in der Lage sind, prozessorientiert Ablaufe zu
designen.

Diesem Kernteam stehen Mitarbeiter aus den jeweiligen Berei-

chen als Untersttitzung zur verfugung. Das bringt nicht nur den
Vorteil des Informationstransfers von der Anwenderseite in das
Projekt, sondern tragt auch ZUr Identifikation mit dem Projekt
beL Dies ist besonders wichtig fur die Unterstutzung im Feldver-
such und die spatere Anwendung. Man spricht in dies em Falle
von sogenannten Keyusern .
Diese fungieren als Ansprechpartner und Know-how-Trager, die
auBerdem die Akzeptanz bei den Anwendern fordern.
Daruber hinaus wird auch auf die Erfahrung externer Berater zu-
ruckgegriffen und das dort bereits vorhandene Know-how ge-
nutzt, besonders hinsichtlich der Methodik und der Verfahren in
der Phase der Dokumentation der Geschaftsprozesse und dem
damit verbunden Reengeneering, das bei der Abbildung der
Ablaufe eine ganz besondere Rolle spielt.
Urn den Gesamturnfang der mit PS abzudeckenden Anforderun-
gen zu definieren, wurde beschlossen, eine sogenannte "Vision"
als betriebswirtschaftliches Grobkonzept zu erstellen, das gleich-
zeitig als roter Faden fur die Umsetzung dient. Eine anschlieBen-
de Machbarkeitsprufung zeigt, daB die grundsatzlichen Funktio-
nen der Anforderungen realisierbar sind.

250
 5.2 Der Projektplan als Richtschnur

Urn den Wunsch zu erftillen, in mbglichst kurzer Zeit Ergebnisse

vorzeigen zu kbnnen, ist eine Umsetzung in drei Phasen be-
schloss en worden. Dadurch kbnnen die Teilergebnisse den An-
wendern schnell zur VerfUgung und die Funktionalitat in Feld-
versuchen stabilisiert werden.
Die Phase I ist die Basis fUr die Funktionsanforderungen der
Phasen II und III. Darin ist die Auftragserbffnung bzw. Ober-
nahme, Umsetzung der Kundenstruktur in die Projektstruktur
sowie die Erlbsabgrenzung ·mit der Erlbs- und Kostenkontrolle
enthalten. Die Phase II enthalt im wesentlichen die interne Auf-
tragsabwicklung mit den Termin- und Netzplanen sowie das Er-
zeugen der Bestellanforderungen. Die Phase III beschaftigt sich
mit der Prognose, dem Berichtswesen und der Abrechnung mit
der Nachkalkulation. Als Grundlage fUr die Durchftihrung dient
ein Projektplan.

5.2 Der Projektplan als Richtschnur

1m Projektplan sind die Inhalte der drei Phasen sowie die pro-
jektrelevanten und -begleitenden MaBnahmen definiert, ebenso
die Teilschritte zur Umsetzung dieser Phasen und die daraus re-
sultierenden Aufgabensteliungen, die den zu bildenden Arbeits-
gruppen zugeordnet werden. Zur Grundung der Arbeitsgruppen
und Obertragung der Aufgaben ist vorgesehen, das Kernteam
und die Anwendervertreter (Keyuser) in einer Kick-Off-Veran-
staltung tiber die geplante Vorgehensweise umfassend zu infor-
mieren.
Die Anforderungen solien mit den vorhandenen Standardfunk-
tionen SAP R/3 realisiert werden, so daB keine Systemmodifika-
tion/-erweiterungen in Form eigener ABAP/4-Programmierung
erforderlich sind.
Urn die bestehenden Standardfunktionen kennenzulernen und
zu verstehen, sind aile Teammitglieder im Umgang mit SAP R/3
PS zu schulen. Basierend auf dem Visionsmandanten sollen da-
fUr realitatsnahe Daten eines Echtauftrages genutzt werden.
Die Dokumentation soli im ARIS-Toolset erfolgen. Dazu ist das
Kernteam im Umgang mit dem ARIS-Toolset zu schulen.

251
5 Vorgehensweise

Abbildung6
Projelctplan Projektplan

•
Release 3.0

Feldversuch der Phasen 1 - 3

1m Projektplan Csiehe Abbildung 6) sind sowohl interne als auch

externe Quality Checks vorgesehen, die je nach Projektfortschritt
durchgeftihrt werden. Hierbei sollen die internen Checks mit da-
zu beitragen, daB die Ergebnisse den gesetzten Anforderungen
entsprechen und dem Qualitatsanspruch gerecht werden. Sie
dienen gleichzeitig der Terminkontrolle fOr die Arbeitsgruppen
innerhalb des Projektteams. Die externen Checks sollen zur Be-
richterstattung gegentiber der Gesamtprojektleitung und des dar-
tiber angesiedelten DV-Lenkungsausschusses dienen.
Den jeweiligen Realisierungsphasen schlieBen sich die Feldver-
suche an. Darin werden von den im Projektteam vertretenen
Anwendern Daten von Echtauftragen zur Verftigung gestellt und
die Abwicklung des Auftrages je nach Projektstand nachvollzo-
gen. Damit sollen die realisierten Funktionen an Echtsituationen
gemessen und erprobt werden.
Die vorgenannten Aktivitaten werden auf Basis des Releasestan-
des 2.2 realisiert. Die Komplettauspragung aller Anforderungen
hinsichtlich FI, CO und MM fOr die Gesamteinfuhrung von R13
soli dann auf Basis 3.0 erfolgen.

252
 6.1 Das Fachkonzept mit den Geschajtprozessen

6 Die Umsetzung

6.1 Oas Fachkonzept mit den Geschaftprozessen

Als erstes steht die Analyse der Geschaftsablaufe im Vorder-
grund. 1m ARIS-Toolset haben wir als Ausgangsbasis eine Pro-
zessauswahlmatrix Csiehe Abbildung 8) erstellt. Darin sind die
Geschaftsprozesse und Szenarien abgebildet.
Die Geschaftsprozesse sind nach Logistik, Rechnungswesen und
Berichtswesen gegliedert. Die Szenarien unterscheiden die unter-
schiedlichen Auftragsarten. Wir sind zu der Erkenntnis gekom-
men, daB in einem Turnkey-Auftrag die meisten tibrigen Auf-
tragsarten enthalten sind, so daB wir uns zunachst bei der Vertie-
fung der Prozesse auf dieses Szenario konzentriert haben.

Prozessauswahlmatrix
Abbildung 7 im ARIS-Tooiset
Prozessauswahl-
matrix im ARIS-
Toolset
HAU.eI:
PROZESSE

Pro HauptprozeB haben wir eine ereignisgesteuerte Prozess-

Kette erstellt, die je nach dem gewtinschten bzw. erforderlichen
Detaillierungsgrad in weiteren Prozessketten vertieft wurden.

253
6 Die Umsetzung

Darin sind die Ereignisse in Verbindung mit den darauf folgen-

den Funktionen und den wiederum daraus resultierenden Er-
eignissen dargestellt. Die Darstellung der Geschaftsablaufe in
Prozessketten (siehe Abbildung 8) orientiert sich nicht an der
jeweiligen Organisationsstruktur des Unternehmens, sondern
gestaltet sich tibergreifend.

Abbildung8
Vorgangsketten
V organgs ketten d"lagramm (VDK)

Zu den jeweiligen Elementen wurde die Beschreibung der Ab-

laufe als Text hinterlegt. Die Moglichkeit dieser Beschreibung ist
jedoch in der Funktionalitat eingeschrankt und besonders hin-
sichtlich der Kapazitat pro Element begrenzt, so daB wir uns hier
auf eine tibergeordnete, stichwortartige Beschreibung beschran-
ken. Betriebswirschaftliche Hintergrunde erfordern jedoch u.u.
eine urnfangreichere und detailliertere Beschreibung als dieses
dadurch moglich ist. Hier bietet sich die Verbindungsmoglichkeit
zu externen Textsystemen an; d.h. tiber diese Funktion konnen
Textdokumente in WINWORD direkt mit dem Element verbun-
den werden, so daB aus der Beschreibung in ARlS und der er-
weiterten Beschreibung in WINWORD eine urnfangreiche 00-
kumentation entsteht, die das Fachkonzept darstellt.

254
 6.2 Yom Fachkonzept in die Rl3-Anwendung und die Dokumentation

6.2 Vom Fachkonzept in die Rl3-Anwendung und die Dokumen-

tation
Je weiter man sich von der Oberflache des Fachkonzeptes in die
Tiefe der Anwendung bewegt, urn so naher kommt man an die
Rl3-Funktionen. Die weitere Vertiefung der Prozessablaufe wird
als Vorgangs-Ketten-Diagramm dokumentiert. Hier werden die
Ereignisse und Funktionen bis hin zur Rl3-Transaktion aufgeteilt
und mit den Bildschirmmasken verbunden dargestellt.

Abbildung 9
Dokumentation mit
Verbindung zum 00- Dokumentation im VDK Projektdefiniton anlegen
kument
mit Verbindung zum
Dokument in
WINWORD

P,ojoktbezolchnung
Tert6lnga be mlt Zuutztext Obet
Funklion La ngt.xt

Auch hier werden die Funktionen und Anwendungen in den mit

den Elementen verbundenen Dokumenten in WINWORD be-
schrieben. In den Funktionen sind die grundsatzlichen Definitio-
nen und betriebswirtschaftlichen Zusammenhange beschrieben.
Zu dem Objekt "Masken" sind die SAP Rl3-Bildschirmmaske
selbst als Screens hot sowie deren Handhabung und Eintragun-
gen definiert und erlautert. Diese Beschreibung dient als Doku-
mentation der Funktionen im SAP Rl3-System und spater als
Grundlage fUr die Erstellung des Anwenderhandbuchs.

255
6 Die Umsetzung

Analog zu den Funktionen werden im Customizing die dafur

erforderlichen EinsteIlungen vorgenommen. Die genaue Doku-
mentation des durchgefuhrten Customizings dient zur NachvoIl-
ziehbarkeit ftir die Pflege und die weitere Auspragung des Man-
danten. Hier wird als Navigationshilfe der Funktionsbaum des
Customizings verwendet, den die Fa. IDS Prof. Scheer zur Verfu-
gung steIlt. Auch hier gilt das gleiche Prinzip der Verbindung zu
den Dokumenten in WINWORD. Als Dokumentenname wird
auch hier der Transaktionscode verwendet. Die Zuordnungen
sind in der Funktion des Customizing-Funktionsbaumes definiert
eingetragen. Der Vorteil besteht darin, daB beim Zugriff auf die-
selbe EinsteIlungsmaske (eindeutiger Transaktionscode), aus
unterschiedlichen Mentipfaden heraus, die gleiche Beschreibung
herangezogen wird.
Die Datenhaltung der Beschreibungen ist auf einem Netz-
werkserver abgelegt. In jedem Element sind die Angaben zum
Dokument, wie der Programmaufruf von WINWORD und die
Laufwerksangabe verbunden mit dem Namen des Dokuments
(Transaktionscode der Funktion des Customizing Funktionsbau-
mes), fest eingetragen, so daB immer diese eine Version gepflegt
wird. Wird es jedoch erforderlich, die Daten dieser Dokumenta-
tion auf einem anderen Datentrager zu halten, mtiBten aIle Ein-
tragungen im Hinweis auf den Datentrager geandert werden.
Hier haben wir uns mit Hilfe eines kleinen Aufrufprogrammes
Flexibilitat geschaffen. Die Eintragung haben wir durch das spe-
zieIle Aufrufprogramm ersetzt, das sich die Laufwerksangabe aus
einer Datei holt und mit dem Transaktionscode aus dem Funk-
tionsbaum erganzt. Eine einmalige Anderung der Laufwerksan-
gabe in dieser Programmdatei hat zur Folge, daB nun aIle Do-
kumente auf dem jeweils darin eingetragenen Datentrager ge-
sucht werden.

6.3 Der Feldversuch

Der Fertigstellung von Funktionen der jeweiligen Entwicklungs-
phasen folgen die Feldversuche. Die im sogenannten Entwick-
lungsmandanten eingesteIlten Funktionen aus den VKDs sind mit
dem erweiterten Kernteam und den Keyusern abgestimmt und
mit Untersttitzung der externen Berater vorgenommen wor-
den. Urn die Anwendbarkeit und die Ergebnisse unter realisti-
schen Bedingungen abzuprtifen, bearbeiten die Keyuser mit den

256
 6.4 Der Know-how-Transfer

bereits realisierten Funktionen Echtauftrage in einem Feldver-

suchsmandanten. Dazu wird in der Startphase zunachst der
Entwicklungsmandant in den Feldversuchsmandant kopiert. Die
Keyuser arbeiten sich anhand der Anwenderdokumentation
durch die Funktionspalette und wickeln ihren Auftrag abo Die
dabei festgestellten Funktionsanderungen kennen umgehend im
Entwicklungsmandanten eingearbeitet und getestet werden. Sie
werden anschlieBend im Feldversuchsmandanten nachvollzogen.
Da in dem Entwicklungsmandanten u.u. Funktionen eingestellt
werden, die nicht mehr riickgangig gemacht werden kennen,
wird nach einem Funktionsabgleich der freigegebenen Funktio-
nen beider Mandanten der Feldversuchsmandant in den Entwick-
lungsmandanten kopiert. Dadurch werden eventuell nicht zu-
riicksetzbare Testeinstellungen im Entwicklungsmandanten uber-
schrieben.

6.4 Der Know-how-Transfer

Zu einem unserer wesentlichen Ziele gehert der Know-how-
Transfer des Customizings. Durch eine enge Zusammenarbeit mit
den externen Partnern wollen wir erreichen, daB unsere Pro-
jektrnitarbeiter im Kernteam das Know-how erwerben, das spater
fur die selbstandige Betreuung der Rl3-Anwender und die weite-
re Auspragung von Funktionen im Mandanten notwendig ist.
Unser Pilotprojekt konzentriert sich vorerst auf den
"Internationalen Fachbereich Hochspannungstechnik" als Teil
des Geschaftsfeldes Energieverteilung, aber unsere Zielvorstel-
lung geht dariiber hinaus. Urn das Gesamtkonzept der
"Einheitlichen Anlagenabwicklung Vertrieb" zu verwirklichen,
stellen wir uns vor, das System auch in weiteren Fachbereichen
und in den zugeordneten Vertriebsniederlassungen einzufuhren.

257
 Wellpappeproduktion - ein Fall fur
branchenunabhangige Standardsoftware?

Prof. Dr. Alfred Taudes,

Dr. Martin Lukanowicz, Peter Schneider

Wirtschaftsuniversitat Wien,
Abteilung fur Industrielle Informationsverarbeitung,
Wien, Austria

258
 2 Wellpappeproduktion

1 Oberblick

Die Wellpappeproduktion erfolgt in variantenreicher Einzelferti-

gung mit einem kontinuierlichen Spektrum der Merkmalauspra-
gungen und enthalt Elemente einer FlieBfertigung. Aufgrund die-
ser Spezifika war der Anpassungsaufwand von PPS-Komponen-
ten von branchenubergreifenden Standardpaketen wie SAP in
dieser Branche sehr hoch, und das "Feld" wurde von Eigen-
oder Branchenl6sungen dominiert. Eine Erleichterung bieten hier
die in den neuesten Releases von branchenunabhangigen Stan-
dardpaketen angebotenen Srucklistenkonfiguratoren. In dies em
Beitrag evaluieren wir die dadurch gebotenen neuen M6glichkei-
ten fur die Wellpappebranche und skizzieren die aus Sicht der
Autoren wichtigsten Problemfelder einer Standardsoftwareeinfuh-
rung in dieser Branche.

2 Wellpappeproduktion - Produkteigenschaften,
Produktionsablauf und Wettbewerbsfaktoren
Gegenstand der Wellpappeproduktion ist die Erzeugung von
FEFCO
ein- oder mehrteiligen Verpackungen aus Wellpappe. Der Ver-
packungsaufbau kann durch ein FEFCO-Standarddesign1 oder
eine kundenspezifische Konstruktion (CAD-System) festgelegt
sein, wobei die Attribute Lange und Breite (RohmaBe: Lr x B)
der als Ausgangsbasis fur das Produkt dienenden Wellpappetafel
aus der FEFCO-Zeichnung via Formeln definiert werden. Auch
bei einer Standardkonstruktion ist zu beachten, daB durch die
FEFCO-Zeichnung nur die Form (faltbar, VerschluBart etc.) des
Kartons determiniert wird, jedoch Abmessungen [Lange (L),
Breite (B), H6he (H)), die Wellpappestruktur, eine eventuelle
Bedruckung oder Zusatzteile, wie Handgriffe oder AufreiBban-
der (meist Zukaufteile), je Auftrag festgelegt werden. Abb. 1 und
2 zeigen Beispiele von FEFCO-Designs sowie die designspezifi-
schen Formeln zur Bestimmung der auftragsspezifischen Attri-
bute.

1 internationaler Code fur Versandverpackungen [2)

259
2 Weltpappeproduktion - Produkteigenschaften,

Abbildung 1:
FEFCOeiner
Faltschachtel
(Code 0201)

Die RohmaBe fur die Wellpappetafel werden mittels der Formeln

L, = 2*L + 2*B + k und B, = H + 2*1/2*B berechnet, wobei k die
Breite der Klebelasche bezeichnet.

Abbildung 2: I I I I I I I I
FEFCOeiner I I I I I I I I
Deckelschachtel I:r: I I I I I I I
I I I I I I I I
(Code 0350); I I I I I I I I
die Garnitur besteht
aus drei Teilen. ! ! I I I I
! I

Die RohmaBe L,} und B,} bzw. L'2 und B'2 werden fur die Well-
pappetafeln mittels der Formeln L,} = 8*V(sqrt(2)+ l)+k und
B,} = H fur den Mantel sowie L'2 = B'2 = L + 2*h fur den Boden
und Deckel des Kartons ermittelt.
Wellpappetafel Eine Wellpappetafel, das Ausgangsmaterial einer Wellpappever-
packung, besteht aus mindestens drei Lagen Rohpapier mit u.U.
unterschiedlichen Rohpapiersorten, wobeizwei Papierlagen als
"Decke" (gerade Bahn) und eine als "Welle" bezeichnet wird.
Fur Wellen existieren verschiedene Wellenprofile, welche den
sogenannten Einzugsfaktor bestimmen, d.h. ist der Einzugsfaktor
1.4, wird fur eine Wellpappetafel der Lange / Rohpapier in der
Menge 1.4*/ benbtigt. Die einzelnen Lagen Rohpapier werden
mittels den Kundenanforderungen entsprechenden Leimen ver-
klebt, wobei die aufzubringende Leimmenge yom Wellenprofil
abhiingig ist.

260
 2 We/lpappeproduktion

Auf Kundenwunsch kbnnen unterschiedliche Wellpappelagen

einer zusatzlichen Veredelung unterzogen werden, wie z.B. voll-
fJachige Einfarbung, Aufbringen einer Wachsschicht usw. (fur
eine Darstellung dieser Sachverhalte in einem ER-Diagramm vgl.
Abb.3).
variantenreicher Spatestens jetzt laBt sich die mbgliche Variantenvielzahl erahnen
Einzelfertiger - ein Wellpappeproduzent ist daher ein variantenreicher Einzel-
fertiger, wobei die Varianten beztiglich einzelner Attribute konti-
nuierlich sind, d.h. durch Formeln festgelegt werden.

Abbildung 3:
ER-Diagramm

Wellpappeanlage Der Produktionsablauf von Wellpappeverpackungen gliedert sich

(WPA) grob in 2 Abschnitte (siehe [3]): im ersten werden aus Roh-
papierrollen tiber eine "Wellpappeanlage (WPA)" verschiedene
Sorten von Wellpappetafeln, deren Abmessungen durch die
oben vorgestellten Formeln auftragsspezifisch festgelegt sind, er-
zeugt. In dies em Produktionsschritt ist eine Planungsproble-
matik zu Ibsen, die z.B. auch in der Papierindustrie auftritt: In
einem Maschinenlauf kbnnen die ersten Arbeitsgange von meh-
reren Auftragen kombiniert werden, wobei das Ziel ist, den an-

261
2 We/lpappeproduktion - Produkteigenschaften,

fallenden Verschnitt an Rohpapier bei moglichst geringer Pro-

duktionsdauer und geringem Wechsel von Rohpapierrollen zu
minimieren. Dadurch ist es teilweise notwendig, die "Qualitat"
eines Auftrages "hochzuziehen", d .h. ein Auftrag wird aus einem
hoherwertigerem Rohpapier produziert, als yom Kunden ge-
wiinscht.
Verschnilt- Das Ergebnis dieses Planungsschrittes ist eine "Verschnittoptimie-
optimierung rung", die angibt, welche Auftrage zu einem Los zusammenge-
faBt werden und wie deren Anordnung auf der Papierbreite
aussieht. Dieser Planungsschritt wird dadurch erleichtert, daB in
den Lieferbedingungen der Branche auch ein gewisser Prozent-
satz Uberlieferung erlaubt ist. DV-technisch kann er isoliert yom
Obrigen Informationssystem, z.B. auf einem "Verschnittleit-
standsrechner", implementiert werden, auf den die zu verpla-
nenden Auftrage geladen und von dem die eine gewahlte Vari-
ante beschreibenden Daten an das PPS zuruckgeliefert werden.
Inline-Maschine Danach werden die so erzeugten Wellpappetafeln je nach De-
sign gerillt, geschlitzt, gestanzt, bedruckt etc .. Dies geschieht an
nachgelagerten Maschinen, die fOr jeweils einen Auftrag einen
oder mehrere dieser Bearbeitungsschritte durchfOhren konnen.
Ein Beispiel ist eine sog. "Inline-Maschine", die in einem Ar-
beitsschritt drucken, schlitzen, rillen und verschlieBen kann. In
dies em Produktionsabschnitt stellt sich daher das dynamische
Maschinenbelegungsproblem Csiehe [4]) in der fOr Einzelfertiger
"klassischen" Form, wobei allerdings meist die Anzahl der vor-
handenen Maschinen und weiteren Arbeitsgange gering ist. Ge-
lost wird dieses Problem Oblicherweise durch die in Standard-
PPS in der Regel verfOgbare Einlastung mittels retrograder Ter-
minierung nach der Prioritatsregel "fruhester Liefertermin".
Just-in-Time- Wellpappeverpackung ist ein technisch relativ simples und -
Anlieferung insbesondere durch die FEFCO-Standardisierung - weitgehend
homogenes Gut. Einen gewissen Schutz vor reinem Preiswett-
bewerb bieten allerdings die im Vergleich zu den Produktkosten
hohen Transportkosten, die eine Belieferung nur im Radius von
200-300 km ab Werk rentabel machen. Dementsprechend versu-
chen Wellpappehersteller sich durch Add-on-Dienstleistungen
yom Mitbewerb zu differenzieren. Neben einer Beratung des
Kunden zur Erreichung eines "optimalen" Verpackungsdesigns
gehort dazu eine Just-in-Time-Anlieferung Csiehe [8]) synchron
zum Produktionsvorgang des zu verpackenden Guts.

262
 3.1 Die Variantenproblematik

Wichtige Organisationsziele sind daher z.B. Lieferfrist 1 Tag ab

Auftragserteilung oder 98% On-Time Delivery. Bei der Errei-
chung dieser Ziele spielen naturgemaB computergestiitzte Infor-
mationssysteme eine wesentliche Rolle. Insbesondere folgende
Anforderungen sind dabei sehr wichtig:
• schnell durchfuhrbare, aber - aufgrund des Preiswettbe-
werbs - hinreichend genaue Kalkulation;
• genaue Disposition: der Lagerkostenanteil ist betrachtlich,
und bei der Papierindustrie sind 6-8 Wochen Lieferfrist kei-
ne Seltenheit;
• sichere Terminierung.

3 Informationssysteme in der Wellpappeproduktion

3.1 Die Variantenproblematik

Aus den obigen Ausftihrungen ergibt sich, daB eine befriedigen-
de Lasung der Variantenproblematik der "Schltissel" zum er-
folgreichen PPS-Einsatz in der Wellpappebranche ist. Bislang set-
zen branchenubergreifende PPS-Systeme auf Stticklistenstruktu-
ren, wie diese z.B. in [4) beschrieben sind, auf:
Baukastenstiicklisten (einstufige Stiicklisten) wei sen die Zu-
sammensetzung eines Teils aus Teilen der nachsttieferen
Stufe aus. Die typische Baukastenstiickliste zeigt die Be-
standteile (Baugruppen) eines Endprodukts. Die aufgefuhr-
ten Teile stehen auf einer Fertigungsstufe und werden in
dieser Stiickliste nicht in ihre Komponenten zerlegt. Diese
Art von Stiicklisten sind z.B. in SAP R/3® Standard, d.h eine
Erzeugnis-Baumstruktur muB mittels vieler Stiicklisten ab-
gebildet werden (vgl. [6]).
Stmkturstiicklisten (mehrstufige Stiicklisten) lassen im Gegen-
satz zu Baukastenstticklisten auch die Zusammensetzung
eines Produkts auf tieferen Stufen erkennen. Sie bilden die

263
3 Informationssysteme in der We/lpappeproduktion

gesamte Erzeugnis-Baumstruktur in Listenform abo Diese Art

von Sti.icklisten sind z.B. in Strassle PSK2000® Standard
(vgl. [7]), sie kbnnen jedoch algorithmisch aus einer Bauka-
stensti.ickliste gewonnen werden.
Mengenstiicklisten weisen zwar aIle Teile aus, die in ein Pro-
dukt eingehen, zeigen jedoch nicht mehr die hierarchische
Erzeugnisstruktur. Wenn ein Teil in der Erzeugnisstruktur
mehrfach vorkommt, werden Mengen summiert.
Varianten-Stucklisten In vielen Untemehmen werden Erzeugnisse nicht nur in einer
bis in aIle Einzelheiten festgelegten Auspragung hergestellt, son-
dem in unterschiedlichen Varianten. Als Varianten werden Teile
bezeichnet, die Abwandlungen eines Grundtyps darstellen. Bei
einer einwelligen Pappe (Rollpappe) kann etwa Rohpapier ver-
schiedener Festigkeit, eine spezielle Klebung oder ein bestimm-
tes Wellenprofil die Variante bestimmen. Wellpappe wird jedoch
auch mit bis zu sieben Lagen Rohpapier erzeugt. Variantenferti-
gung ist heute in vielen Branchen an der Tagesordnung, da mit
zunehmender Kundenorientierung auf den Markten immer star-
ker auf individuelle Wi.insche eingegangen werden muB. Bei
den Varianten werden in der Praxis und Literatur (siehe [4])
mehrere Arten unterschieden:
Strukturvariante: Mehrere unterschiedliche Auspragungen ei-
nes Teils sind mbglich, und eine davon geht in das End-
produkt ein (z.B. gewbhnlicher Leim versus wasserfester
Leim).
Mengenvariante: Ein Teil geht in unterschiedlicher Anzahl bzw.
Menge in das Endprodukt ein (z.B. kein/ein AufreiBstreifen
bzw. Leim- und Rohpapiermenge in Abhangigkeit yom
WellenprofiD.
MuS-Variante: Mehrere unterschiedliche Auspragungen eines
Teils sind mbglich, und eine davon muB in das Endprodukt
eingehen (z.B. mindestens eine Decke und eine Welle).
Kann-Variante: Ein Teil kann zu einer Basisauspragung eines
Produktes hinzukommen (z.B. ein AufreiBstreifen).
Dispositive Variante: Die Varianten-Auspragung ist nur fur die
innerbetriebliche Disposition von Bedeutung, ohne daB ex-
plizit ein unterschiedliches Endprodukt entsteht (z.B. das
obenerwahnte "Hochziehen" der verwendeten Rohpapier-
sorten bei der Verschnittoptimierung).

264
 3.1 Die Variantenproblematik

Die Begriffe der obengenannten Arten von Varianten tiberlappen

sich teilweise: So sind MuB-Varianten auch Strukturvarianten,
Kann-Varianten sind Strukturvarianten oder Mengenvarianten,
Dispositive Varianten sind Strukturvarianten, die jedoch nicht
dem Kunden gegentiber ausgewiesen werden.
slalische Varianten von Erzeugnisstrukturen konnen auf unterschiedliche
Varianlendarslellung
Weise reprasentiert werden, grundsatzlich kann dies statisch
oder dynamisch erfolgen. Statisch bedeutet, daB aIle moglichen
Auspragungen einer Variante in der Datenbasis gehalten werden.
Bei der statischen Variantendarstellung gibt es folgende
Moglichkeiten:
1. Jede Variante wird wie ein eigenstandiges Teil behandelt.
Das bedeutet sehr hohe Redundanzen bei der Datenhaltung
der Strukturbeziehungen, d.h. viele Beziehungen werden im
relationalen DatenmodeH mehrfach abgespeichert.
2. Jede Variante wird wie ein eigenstandiges Teil behandelt,
jedoch werden die in allen Varianten gleichen Teile zu ei-
ner fiktiven Baugruppe ("Gleichteil-Baugruppe" bzw. im
Strassle PSK2000®-Terminus "Pseudo-Teile") zusarnmenge-
faBt. Diese fiktive Baugruppe wird in der Datenbank nur
einmal gehalten bzw. bei Verwendung in ihre Bestandteile
aufgelost.
3. Jede Variante wird wie ein eigenstandiges Teil behandelt,
jedoch legt man eine Variante als sogenannten Grundtyp
an. Bei den anderen Varianten werden die Abweichungen
von diesem Grundtyp notiert ("Plus-Minus-Stticklisten").
4. Varianten werden nicht als eigenstandiges Teil, sondem als
"variantenfamilie" behandelt. In der Strukturbeziehung
werden mittels eines Tupels die notigen Mengenangaben zu
den einzelnen Varianten gehalten. In der Literatur werden
Variantenfamilien auch als "Mehrfach-", "Komplex-" oder
"Typenstticklisten" bezeichnet.
dynamische Der statischen Beschreibung der Varianten steht die dynami-
Varianlengenerierung sche Generierung der Strukturbeziehung im Bedarfsfalle ge-
gentiber. Dieser Ansatz bietet sich vor aHem fur variantenreiche
Einzelfertigung an, da oft erst nach Spezifikation durch den
Kunden das genaue Endprodukt festgelegt werden kann. Bei ei-
ner groBen Vielzahl von kombinierbaren Teilen - wie im oben
beschriebenen Fall der WeHpappeerzeugung - verbietet

265
3 Infonnationssysteme in der Wellpappeproduktion

schon die Kombinatorik die Speicherung aller mbglichen denk-

baren Erzeugnisvarianten.
Ein Weg zur Lbsung der kombinatorischen Vielfalt besteht darin,
die unterschiedlichen Auspragungen nur bei Baugruppen und
Einzelteilen zu fuhren. Endproduktvarianten werden als Varian-
tenfamilie behandelt und durch Auspragungen unterschiedlicher
Merkmale beschrieben. Eine konkrete Variante (Erzeugnisstruk-
turbeziehung) wird dann durch die Teilenummer des jeweiligen
oberen und unteren Teils und durch das Vorhandensein be-
stimmter Merkmalsauspragungen identifiziert. Beim Aufbau die-
ser komplexen Strukturbeziehungen soil der Anwender durch
Stucklistenkonfiguratoren Unterstutzung bekommen.

3.2 StUcklistenkonfiguratoren -
neue Werkzeuge zur Bewaltigung der Variantenproblematik
Ausgehend von der in Release 2.1 G von SAP R/3® bestehenden
Mbglichkeit der Klassifizierung beliebiger Elemente (Materialien,
Arbeitsplane usw.) des R/3-Systems ist in Release 2.2 ein Varian-
tenkonfigurator vorhanden. Dieser soil die Verwaltung der Vari-
anten von Endprodukten, die jedoch aile auf einen gemeinsa-
men Stamm zUrUckgefuhrt werden kbnnen, erleichtern und die
unnbtige Aufblahung der Grunddatenbestande - die bisher ub-
licherweise mehrfach Cje Variante) abgelegt wurden - ver-
meiden. Durch diesen Konfigurator kbnnen Struktur- und Men-
genvarianten spezifiziert werden.
Merkmalsaus- Release 2.2 von PSK2000® der Firma Strassle bietet das Konzept
pragungen nur auf der Variantenstuckliste mit Steuerung uber Merkmale und Merk-
oberster Ebene malsauspragungen, jedoch kbnnen Merkmalsauspragungen nur
auf oberster Ebene (bei Endprodukten) angegeben werden. Das
sich daraus ergebende Problem soil anhand eines Beispiels ver-
anschaulicht werden: Wird z.B. das Merkmal "Getriebeuberset-
zung" in einer tieferliegenden Baukastensti.ickliste dazu benutzt,
urn unterschiedliche Zahnrader fur eine bestimmte Variante
(Merkmalsauspragung 3:8) zu selektieren, kann nur eine Getrie-
beart (namlich die mit der Ubersetzung 3:8) im Endprodukt
Verwendung finden. Wenn nun ein neues Endprodukt zwei Ge-
triebe benbtigt, mussen der Grunddatensatz fur Merkmale uber-
arbeitet, das Merkmal "Getriebeubersetzung" durch zwei neue
Merkmale "Getriebeubersetzung 1" und "Getriebeubersetzung 2"
ersetzt und aile Variantenstucklisten korrigiert werden. Kommt

266
 3.2 Stucklistenkonjiguratoren -

eine neues Endprodukt mit drei Getrieben auf den Markt ... Die
L6sung dieses Dilemmas besteht darin, daB in der Software die
M6glichkeit einer Spezifizierung von Merkmalsauspragungen
auch auf unteren Ebenen geschaffen wird.
Wertzuweisung Eine weitaus wiinschenwertere Alternative ist jedoch die Wert-
zwischen Merkmalen zuweisung (mittels algebraischer Ausdriicke) zwischen Merkma-
len und ihren Auspragungen bzw. Merkmalsauspragungen und
Datenfeldern, wie sie in SAP R/3® ab ReI. 2.2 zur Verfugung ge-
stellt wird. Auch andere Anbieter von Standardsoftware haben
dieses Konzept bereits implementiert bzw. arbeiten daran 2.
Die M6glichkeit, Merkmalsauspragungen als Variablen in alge-
braischen Ausdriicken (Formeln) zu verwenden, ist in unserem
Anwendungskontext notwendig, da so RohmaBe fur Varianten
von Wellpappetafeln, wie sie z.B. bei Abbildung 1 und 2 ange-
geben wurden, oder der Rohpapiereinsatz mittels der Einzugs-
faktoren berechnet werden k6nnen.
Beziehungswissen Der in SAP-R/3® Relase 2.2 vorhandene Variantenkonfigurator
bietet die M6glichkeit der Variantenauswahl mittels sogenannten
"Beziehungswissens" . Stiicklistenkomponenten k6nnen durch
folgende Beziehungsarten gewahlt bzw. beeinfiuBt werden:
vorbedingungen entscheiden dariiber, ob eine Komponente
uberhaupt in einer Variantenkonfiguration vorkommen
kann. 1st die Vorbedingung erfullt, so kann die Kompo-
nente ubernommen werden; der Anwender hat die Freiheit
diesen Vorschlag zu akzeptieren oder abzulehnen.
Auswahlbedingungen bestimmen, daB eine Komponente -
bei Gultigkeit der Bedingung - in die Konfiguration uber-
nommen werden muB.
Aktionen k6nnen Datenfelder, wie z.B. Mengen, in Abhangig-
keit von Variantenmerkmalsauspragungen durch Formeln
festgelegen.
Eigenentwicklung In Formeln k6nnen Vergleichs- und Logische-Operatoren fur
oder Bedingungen und Grundrechnungsoperatoren und Funktionen
Branchenlosung (z.B. trigonometrische) fur Berechnungen verwendet werden.

2 Forrnelauswertung ist in der Software Baan Triton ReI. 3.01B bereits imple-
mentiert (vgl. [1]); laut Herrn Jabbusch von Fa. Strassle ist eine entsprechen-
de Funktionalitat fur PSK2000® in Vorbereitung.

267
4 Einfuhrung von branchenunabhangiger Standardsoftware

1st eine durch Formeln determinierte Variantenkonfiguration

nicht mbglich, so muBte diese handisch je Auftrag erfolgen. Dies
ist jedoch aus Zeitgriinden nicht mbglich (vgl. oben), so daB
branchenubergreifende Standardsoftware bislang der Well pap-
pebranche nicht zuganglich war. Man findet daher heute in
Wellpappeunternehmen zumeist entweder in den spaten 70er
und friihen 80er Jahren konzeptionell entstandene, in der Regel
auf proprietaren "Hostkonzepten" basierte und nichtintegrierte
Eigenentwicklungen oder Branchenlbsungen vor. Letztere haben
naturgemaB ihren Schwerpunkt in den oben beschriebenen Be-
sonderheiten der Branche, weisen aber ublicherweise Schwa-
chen bei der Gesamtabdeckung der PPS-Funktionalitat, bei der
FirmengrbBe der Anbieter, die durch die relative "Kleinheit" der
Branche bedingt beschrankt ist und in der Softwaretechnologie
(veraltete Datenverwaltungs- und/oder Oberflachenkonzepte,
mangelnde Multi-Plattformunterstutzung usw.) auf.

4 EinfUhrung von bra1chenunabtmgiger S1mdardsoftware

in der Wellpappeproduktion
Mangel gangiger Diese Mangel der gangigen DV-Landschaft im Wellpappeunter-
DV-Landschaft nehmen sind urn so gravierender als die sich immer schneller
verandernden Marktbedingungen, das geanderte Kundenverhal-
ten, die rasch steigenden Rohstoffkosten, die bffnung nach Ost-
europa und die Erweiterung des Europaischen Marktes von den
einzelnen Wellpappeherstellern ein hohes MaB an Flexibilitat
und schnelles Reagieren auf wechselnde Marktanforderungen
verlangen. Die in Kapitel 2.2. aufgezeigten neuen Parametrie-
rungsmbglichkeiten von branchenunabhangiger Standardsoft-
ware haben daher einige Wellpappeunternehmen bewogen, ihre
neuen Informationssysteme mit diesen Werkzeugen aufzubauen
(vgl. dazu auch [1]).
Probleme mit dem Erste Erfahrungen dabei zeigen, daB bei derartigen Projekten
neuen Werkzeug immer wieder Probleme beim Umgang mit dem neuen Werk-
zeug auftreten. Aus Erfahrung der Autoren wichtige Problemkrei-
se sind:

268
 3.2 StucklistenkonJiguratoren -

A-priori-Absprechen der grundsitzlichen Eignung von branchenunab-

hingiger Standardsoftware:
Fur einen erfolgreichen Einsatz von branchenunabhangiger
Standardsoftware sind Kenntnisse der Branchensituation,
der Konzepte von Standard-PPS-Systemen und deren 1so-
morphismen notwendig. Das Problem der Branchenfach-
sprache 3 erschwert die Erarbeitung dieses Wissens: Es er-
fordert einiges an Oberlegung, urn zu erkennen, daB ein
FEFCO-Design einen Arbeitsplan beschreibt, wobei im er-
sten Arbeitsgang immer an der WPA eine WeUpappetafel
erzeugt wird, und daB eine WeUpappetafel eine Sti.ickliste
mit Komponenten bestehend aus WeUpappeprofil, Leim
und Additive ist, wobei Mengenvarianten durch die FEFCO-
Formel festgelegt werden. Eine lediglich oberflachliche Be-
trachtung von Standard-PPS fuhrt daher oft zu Aussagen
wie: "Wir haben keine Sti.icklisten, die sind etwas fur Ma-
schinenbauer" .
Falsche Erwartungen an Standardsoftware
Bislang sind die Anwender in Wellpappeunternehmen ge-
wohnt, entweder ein maBgeschneidertes System zu be-
kommen, mit dem sofort gearbeitet werden kann, oder ihre
Anforderung der eigenen 1S-Abteilung laufend zur Pro-
grammierung zu geben. Beides ist bei branchenunabhangi-
ger Standardsoftware nicht der Fall. Ein "nacktes", nicht pa-
rametriertes Vorsetzen der Software erzeugt aus den obigen
Gri.inden Ablehnung; eine 1mplementierung, die auch er-
folgreich sein soU, erfordert ein entsprechendes Projektma-
nagement.
Mingel bei der Projektorganisation
Dies ist oft Neuland fur die Beteiligten. Haufig gemachte
Fehler sind bier z.B.:
• Der Anwender wird ohne Parametrierung mit der bran-
chenubergreifenden Lbsung konfrontiert Cvgl. oben).
• Der korrekte Projektablauf wird nicht eingehalten: Der
Schritt Systemauswahl wird etwa vor die Konzeption ge-
setzt.

3 Dies ist etwa im Gegensatz zum Finanzbereich, dessen Terminologie zum

GroBteil branchenneutral in Rechtsvorschriften definiert ist, ein allgemeines
Problem der Produktion, in der Branchen-, Untemehmens- oder sagar
Werkstermini die Regel sind.

269
4 Einfuhrnng von branchenunabhangiger Standardsoftware

• Projektleitung und -verantwortung fur fachliche Konzep-

tion liegt in Verantwortung der DV-Abteilung. Durch den
(leider) oft zu beobachtenden geringen Wissensstand
uber Geschaftsprozesse der DV-Verantwortlichen fuhren
solche Lbsungsansatze oft in die falsche Richtung (dies
zahlt It. (5) generell zu haufig gemachten Fehlern bei
CIM-Projekten).
Eine den Erfahrungen der Autoren nach adaquate Vorgehens-
weise, die helfen soli, solche Fehler zu vermeiden, sieht folgen-
dermaBen aus:
Zieldefinition Am Anfang steht eine Zieldefinition. Diese dient zur Kontrolle
des Vorhabens und als Leitlinie bei der Bewertung von System-
anforderungen bei Softwareauswahl und/oder Anpassungen. Sie
sollte hierarchisch erfolgen und auf unterer Ebene moglichst
quantitativ bewertbar sein (z.B. Erreichen von 98% On-Time De-
livery). Neben DV-Zielen sollen auch die notwendigen Orga-
nisations- und Schulungsziele erfaBt werden.
hierarchische Eine hierarchische Projektaufbauorganisation soli eine klare
Projektaufbau- Trennung in eine "operative" und eine "entscheidende/koordi-
organisation nierende" Ebene ermbglichen. Die notwendige Entscheidungs-
findung fUr jede Ebene ist durch entsprechende Verantwortung
und Kompetenz geregelt. Abbildung 4 zeigt eine geeignete Auf-
bauorganisation.

Abbildung 4:
Aufbauorganisation

I I
I I
: 1----------1 : 1---------- 1
L--1'- _________ JI L--1'-_________ -11
1
1
: 1---------- 1
---1'-_________ J1

270
 4 Einfuhrung von branchenunabhiingiger Standardsoftware i

Projektlenkungs- Der ProjektlenkungsausschuB CPLA) sorgt als oberste Entschei-

ausschul3 dungsinstanz fur die Unterstiitzung und Kontrolle des Gesamt-
projekts. Er besteht grundsatzlich aus Mitgliedern der Geschafts-
lei tung und dem Leiter des Controlling. Eine der wichtigsten
Aufgaben des PLA ist die Definition der strategischen Projekt-
ziele; er tritt in der Regel einmal pro Quartal zusammen.
Projektleitung Die Projektleitung und das Projektmanagement sind fur die Erar-
beitung und Koordinierung der Teilprojektziele durch die Ar-
beitsgruppen verantwortlich. Weiter obliegt ihnen die Fort-
schrittskontrolle und Konsolidierung der Teilprojekte.
Arbeitsgruppen Die Arbeitsgruppen setzen sich aus Mitarbeitern der einzelnen
Fachabteilungen zusammen. Sie sind fur die Erarbeitung des
fachlichen Inhalts des Grobkonzepts und die Vorgaben fur das
Pflichtenheft verantwortlich. Die yom PLA vorgegebenen strate-
gischen Projektziele werden von den Arbeitsgruppen auf der
Ebene der einzelnen Geschaftsprozesse beriicksichtigt und sind,
in Verbindung mit bisherigen Erfahrungen und wellpappespezifi-
schem Wissen, Grundlage fur das Design der neuen Informati-
onssystemorganisation. Bei mehreren Werken sollte in jeder Ar-
beitsgruppe ein Vertreter aus jedem Werk teilnehmen.
Informations- Die DV- bzw. Informationswirtschaftsabteilung ist fur die Sicher-
wirfschaftsabteilung stellung der Systemkonformitat, die Implementierung der einzel-
nen Teilprojekte sowie die Datenubernahme aus dem alten Sy-
stem verantwortlich. Mitarbeiter sind in allen Gremien der Pro-
jektorganisation vertreten. Nach Auswahl einer Softwarelbsung
sind auch die Vertreter des Softwarehauses in der Projektorgani-
sation vertreten. AuBerdem ist es zweckmaBig, externe Berater
im ProjektlenkungsausschuB und im Bedarfsfall auch in Teilpro-
jekten einzubinden.
Projektablauf Die einzelnen Teilprojekte laufen in folgenden funf Schritten ab:

1_ 1st-Analyse
• Dokumentation der Ist-Geschaftsprozesse CAblaufmodell)
• K1assifizierung der strategischenlkritischen Geschaftspro-
zesse
• Starken-Schwachen-Analyse

271
4 Einfuhrung von branchenunabhangiger Standardsoftware

2. Zieldef"mition
• Abgrenzung der Ziele nach Unternehmenszielen, Be-
reichszielen und integrierenden Zielen
• Aufbau einer Hierarchie mit Haupt- und Unterzielen
• Klassifizierung nach Standardzielen und Innovations-
zielen
• Prazisierung der Umsetzung der Ziele

3. Konzeption
• Erarbeiten eines Fach(Grob)konzepts (Funktionen, Ab-
laufe, Datenbeschreibungen)
• Erstellen eines detaillierten IS-Modells
• Erstellen von Prototypen fur optimierte Geschiiftpro-
zesse
• Kosten-Nutzen-Analyse der MaBnahmen und erwartete
Ergebnisse

4. Auswahl
• der System- und Anwendungssoftware
• AbschluB der Vertrage mit Hard- und Softwareliefe-
ranten

5. Realisierung
• Erstellen eines Pflichtenheftes (Feinspezifikation)
• Anpassen der Software
• Integration von Fremdsystemen
• Schulung der "Superuser"
• Testen der einzelnen Teill6sungen
• Schulung der Anwender
• EinfUhrung
• Nachbesserungen

272
 5 Zusammenfassung

5 Zusammenfassung

Erste Erfahrungen mit dieser Vorgangsweise zeigen, daB so auch

brancheni.ibergreifende Standard-PPS in der Wellpappeproduk-
tion erfolgreich eingefUhrt werden kannen. Notwendig dazu
sind:
• von seiten der Standardsoftwareanbieter ein entsprechend
machtiger Sti.icklistengenerator,

• ein branchenspezifisches Softwarepaket zur Verschnittopti-

mierung und eine auf das neue Werkzeug "brancheni.iber-
greifende Standardsoftware" abgestimmte Vorgehensweise bei
der EinfUhrung.
Partnerlosung Eine wesentliche Erleichterung des Einfi.ihrungsprozesses fUr den
Anwender, die auch schon von emlgen Standardsoft-
wareanbietern erkannt wurde, kannte eine Partnerlasung auf
seiten der Anbieter mit sich bringen: Anstatt zu versuchen, mit
inadaquaten Mitteln Gesamtlasungen zu realisieren, kannen sich
Branchenspezialisten in Partnerschaft mit Standardsoftwareanbie-
tern auf die Parametrierung der Standardsoftware, das Anbieten
einer abgestimmten Verschnittoptimierung und das Erarbeiten
der organisatorischen Lasung konzentrieren und so den Analy-
se-, Parametrierungs- und Koordinationsaufwand der Anwender
erheblich senken.

273
Literaturverzeichnis

Literaturverzeichnis

[1] Emrich H.: ECA EDV-Konzept 2000, in J. Becker/P. Loos:

Proceedings CIM-Branchenlbsungen, Munster 1993
[2] FEFCO: Internationaler Code fUr Versandverpackungen,
Paris 1990
[3] Forum Wellpappe: Wellpappe-Fibel, Wien 1993
[4] Kurbel K.: Produktionsplanung und -steuerung, Methodi-
sche Grundlagen von PPS-Systemen und EIWeiterungen. In:
A. Endres/H. Krallmann/P. Schnupp [Hrsg.l: Handbuch der
Informatik, Oldenbourg Verlag, Munchen 1993
[5] Mandl Ch.: Computerintegrations-Projekte - Die Logik des
MiBlingens, Proceedings ADV-KongrelS 1993, Wien 1993
[6] SAP AG: Produktionsplanung - System R/3, Walldorf 1993
[7] Strassle: Materialwirtschaft - Leistungsbeschreibung
PSK2000, Leonberg 5/93
[8] Wildemann H.: Das Just-in-Time-Konzept - Produktion
und Beschaffung auf Abruf, 2. Auflage, gfmt, Munchen 1990

274
Paneuropaisches Informationsmanage-
ment mit SAP-Rl3

Dipl.-Wirtsch.-Ing. Dr. Siegbert Kern

Fa. RUBBERMAID GmbH, Dietzenbach

275
1 Vberblick

1 Uberblick
Das Zusammenwachsen von Europa zu einem gemeinsamen
Wirtschaftsraum fuhrt zunehmend zu einer Europaisierung der
Unternehmen. Dies gilt fur GroBunternehmen gleichermaBen
wie fur mittlere Unternehmen. Eine Europaisierung treibt euro-
paische, amerikanische und asiatische Gesellschaften mit gleich
starker Intensitat voran.
Der europaische Wirtschaftsraum wird von den Unternehmen als
ganzes betrachtet, ohne Rucksicht auf die Landesgrenzen. Die
Verkaufs-, Distributions-, Einkaufs- und Produktionsaktivitaten
innerhalb Europas werden darauf neu abgestimmt. Die Unter-
nehmensstrukturen werden an den veranderten Bedingungen,
wie zollfreiem Waren- und Dienstleistungsverkehr, angleichen-
den Qualitatsstandards, europaweit operierenden Geschaftspart-
nern, unterschiedlichen Kostenstrukturen uSW., ausgerichtet. Ent-
scheidungen uber die Standortwahl und die Verteilung der Un-
ternehmensfunktionen, die sich bisher auf einzelne Lander oder
Markte konzentrierten, werden nun unter Einbezug von Europa
getroffen. Das fuhrt beispielsweise dazu, daB die Produktions-
statten eines Unternehmens in ganz Europa verteilt werden; der
Einkauf von Rohstoffen, Rohlingen und Einbauteilen bzw.
-systemen kann europaweit erfolgen. Neben einem zentralen La-
ger k6nnen kleinere Satellitenlager eingerichtet werden, aus de-
nen wachstumsstarke Regionen versorgt werden. Europaische
Kunden k6nnen sowohl direkt von den Produktionstatten, ei-
nem zentralen Lager oder einem Satellitenlager aus beliefert
werden. Die Auftragsabwicklung fur wachstumsstarke Regionen
k6nnen dezentralisiert und fur wachstumschwache Regionen
zentralisiert werden. Unternehmensfunktionen k6nnen raumlich
voneinander getrennt und in unterschiedlichen Landern Europas
angesiedelt sein. Gleichzeitig ist es aber wichtig, daB die Ver-
kaufs-, Einkaufs-, Bestands- Produktions-, Ertrags- und Kosten-
informationen uber eine oder aber auch mehrere Organisations-
einheiten wieder zusammengefuhrt werden mUssen, urn das
Unternehmen paneuropaisch steuern zu k6nnen.

276
 2 Paneuropaische Gescha!tsprozesse und Fuhrnngsstrnkturen

Eine weitere Entwicklung, die es zu beachten gilt, ist die Kon-

zentration der Unternehmen auf ihre Kernbereiche. Das bedeutet
einerseits, Unternehmensaktivitaten, die nichts mit dem Kernge-
schaft zu tun haben, werden verauBert oder eingestellt. Anderer-
seits wird die Fertigungstiefe zunehmend reduziert, indem aus-
schlieBlich Schhisselprodukte, -technologien oder -dienstlei-
stungen selbst hergestellt und die restlichen Einzelteile oder
Baugruppen bzw. Dienstleistungen moglichst als Ganzes von
Zulieferern zugekauft werden. Es ergeben sich hieraus engere
und weitreichendere Zulieferbeziehungen als bisher.
Hierdurch entsteht ein gewaltiger paneuropaischer Kommunika-
tions- und Informationsbedarf, der neue Anforderungen an die
Integrationsfahigkeit, Flexibilitat und Leistungsfahigkeit der dazu
notwendigen Informationssysteme stellt.

2 Paneurop8ische Gesch8ftsprozes undFuhrungsstruldu18l

Um zukiinftig wettbewerbsfahig zu bleiben, sind nicht nur
GroBunternehmen, sondern auch mittlere Unternehmen ge-
zwungen, sich immer starker zu internationalisieren. Gleichzeitig
entwickeln sich die landerspezifischen Markte, wie z.B. USA,
Deutschland etc., verstarkt zu Wirtschaftsraumen, wie z.B. Nord-
amerkanische Handelszone, Europaische Union, Asiatische Han-
delszone. Darin wird nicht nur ein freier Handel von Waren und
Dienstleistungen ohne Zollschranken, sondern gleichermaBen
eine Vereinheitlichung der Rahmenbedingungen und Standards,
wie Z.B. Gesetze, Qualitatsstandards, ProduktbemaBungen etc.,
angestrebt. Durch die Internationalisierung und die freien Han-
delszonen sind die Unternehmen gezwungen, eine globale
Marktbetrachtung vorzunehmen. Hieraus erwachsen veranderte
Geschaftsprozesse und Fiihrungsstrukturen, die aile Unterneh-
mensfunktionen betreffen. Die wird - bezogen auf den europai-
schen Wirtschaftsraum - an einigen Beispielen erlautert.
Aus dem Unternehmensbereich Verkauf werden zwei Beispiele
angefiihrt, an denen sichtbar wird, wie sich die Globalisierung
der Unternehmen in Europa auswirken kann.

277
2 Paneuropaische Geschajtsprozesse undFiihrungsstrukturen

Eine Vermarktung gleicher oder ahnlicher Produkte innerhalb

Europas, insbesondere innerhalb der Europaischen Union macht
es notwendig, die Preispolitik auch europaweit abzustimmen
und den veranderten wirtschaftlichen Rahmenbedingungen stan-
dig anzupassen. Ein Kunde, der groBere Mengen eines Produk-
tes von einem Hersteller einkauft, wird europaweit die Preise
vergleichen, da es innerhalb der EU zunehmend gleichgultig ist,
ob die Ware z.B. aus Deutschland, Frankreich oder Halien bezo-
gen wird.
Die Vertriebskanale und Vertriebsaktivitaten mussen den euro-
pais chen Strukturen angepaBt werden. So kommt es immer hau-
figer vor, daB ein Kunde nicht nur in einem Land, sondern in
anderen europaischen Landern ebenfalls Kunde ist.
Hieraus ergibt sich die Notwendigkeit, die Vertriebsaktivitaten in
verschiedenen Landern aufeinander abzustimmen. Dies kann
neben Preisen auch Rabatte, Lieferbedingungen, Werbung, Pro-
motionaktionen usw. betreffen. Es wird zunehmend erforderlich,
Kundeninformationen uber diese Kunden europaweit zur Verfu-
gung zu stellen.
Daruber hinaus findet vor allem in groBen Unternehmen eine
Divisionalisierung statt, d.h. innerhalb eines Unternehmens wer-
den die Vertriebsaktivitaten bis hin zu gesamten Unternehmens-
aktivitaten nach Produktgruppen orientiert, gebundelt und zu-
sammengefaBt. Gleichzeitig sollen aber auch die Verkaufsstatisti-
ken in der Gesamtheit und aufgegliedert nach Divisionen, Pro-
duktgruppen bis zum einzelnen Produkt moglichst Online vor-
liegen.
Auch in der Logistik ergeben sich veranderte Geschaftsprozesse
und Fuhrungsstrukturen.
Das nachfolgende Beispiel bezieht sich auf die Organisation der
Auftragsabwicklung und Lagerhaltung in paneuropaischen Un-
ternehmen. In Abhangigkeit der Umsatze in den einzelnen Lan-
dern Europas kann die Auftragsabwicklung zentral oder de zen-
tral organisiert werden. Das bedeutet, die Auftragsabwicklung
kann innerhalb verschiedener Lander oder aber zentral in einem
Land in Europa angesiedelt sein. Gleichzeitig existieren aber in
diesen Landern rechtlich selbstandige Unternehmen. In gleicher
Weise steHt sich fur die Unternehmen die Frage, ob ein zentrales
Lager, mehrere dezentrale Lager oder Mischformen sinnvoH sind.

278
2 Paneuropdische Geschd!tsprozesse und Fuhrungsstrukturen

Hierbei sind in Abhangigkeit der gesetzlichen und steuerlichen

Rahmenbedingungen die Fragen zu klaren, welche Gesellschaf-
ten Eigentumer der Ware sind und wie der Warenverkauf intern
zwischen den Landesgesellschaften verrechnet wird. Ein paneu-
ropaisches Informationssystem muB in der Lage sein, verschie-
dene Organisationen der Auftragsabwicklung und der Lagerhal-
tung wirtschaftlich zu unterstiitzen. D.h. interner Informations-
austausch und Verrechnungen sollten weitestgehend automati-
siert werden.
Wie im Verkauf, so wird auch der Einkauf nicht mehr nur im ei-
genen Land, sondern europaweit Rohstoffe, Rohlinge, Einzeltei-
Ie, Systeme und Handelswaren beschaffen. Dem Einkauf mussen
Produkt- und Lieferanteninformationen europaweit in verschie-
denen Sprachen, Wahrungen und MaBeinheiten zur Verfiigung
gestellt werden, urn mbglichst optimal uber Landergrenzen hin-
weg eine Lieferantenauswahl treffen zu kbnnen.
Sowohl fur den Verkauf als auch fur den Einkauf wird zukunftig
der automatischen Dbermittiung von Auftragen, Auftragsbestati-
gungen, Rechnungen, Gutschriften, Lastschriften, Versandinfor-
mationen usw. zu den Kunden, den Lieferanten und zwischen
den einzelnen Standorten von Unternehmen europaweit wesent-
liche Bedeutung zukommen. Ein paneuropaisches Informations-
system muB in der Lage sein, auf Basis von Standards sowohl
innerbetrieblich als auch mit Kunden und Lieferanten einen au-
tomatischen Austausch von Geschaftsbelegen vorzunehmen. Mit
EDI (Electronic Data Interchange) steht eine internationale Stan-
dardschnittstelle fur den automatischen Datenaustausch von Ge-
schaftbelegen zur Verfugung und mit EDIFACT ein international
vorgegebener Standard fur die Formate der EDI-Nachrichten.
Fur die Produktion hat eine Europaisierung vor allem bei mehre-
ren Produktionsstandorten innerhalb Europas Relevanz. Sofern
redundante Produktionsmittel an unterschiedlichen Standorten
zur Verfiigung stehen, kbnnen Produktionsauftrage generell oder
gegebenenfalls bei Engpassen europaweit eingeplant werden.
Das gleiche kann auch fur Werkzeuge und Vorrichtungen gelten,
insbesondere in der Kunststoffindustrie. Ein paneuropaisches
Informationssystem muB in der Lage sein, eine Produk-
tionsplanung und Werkzeugplanung standort- und unterneh-
mensubergreifend vorzunehmen.

279
2 Paneuropdische Geschd!tsprozesse undFuhrungsstrukturen

Bei europaweit agierenden Unternehmen handelt es sich meist

um ein Netzwerk von rechtlich selbstandigen Unternehmen mit
eigenem buchhalterischen AbschluB CBilanz, G+V) nach lander-
spezifischen Gesetzen. Hier kann es nun vorkommen, daB in-
nerhalb rechtlich selbstandiger GeseIlschaften in Europa buch-
halterisch getrennte Divisionen existieren. Hieraus ergibt sich die
Anforderung einerseits landerspezifische Abschlilsse zu ersteIlen,
anderseits filr eine Division einen europaweiten AbschluB anzu-
fertigen und daraus den europaischen GesamtabschluB abzulei-
ten. Dies steIlt hohe Anforderungen an die Konsolidierungsfunk-
tionen eines Informationssystems, das auch lokale rechtliche
Aspekte in der Konsolidierung berilcksichtigt.
Filr das Management und das Controlling ist nicht nur aus fi-
nanzbuchhalterischer Sicht europaweite Konsolidierung von Be-
deutung, sondern ebenso wichtig ist es, aIle anderen Informatio-
nen nach unterschiedlichen Kriterien lokal und europaweit in
einem System moglichst aktuell und automatisch zusammenzu-
fassen .
Dazu zahlen:

• Verkaufszahlen
• Verbrauchsdaten
• Bestandsdaten
• Finanzdaten
• Kostendaten

Das bedeutet, an jedem Standort milssen die gewilnschten In-

formationen in beliebigem Detaillierungsgrad abgerufen werden.
Eine wesentliche Voraussetzung dafur ist, daB aIle Unterneh-
mensteile mit einheitlichen Stammdaten, wie Organisationsdaten
Cz.B. Landerschlilssel, Verkaufsgebiete), Artikelstamm, Lieferan-
tenstamm, Kontenplan und Kostenstellenplan usw., arbeiten.

280
 3 L6sungsm6glichkeiten mit SAP-R/3

3 Losungsmoglichkeiten mit SAP-Rl3

1m vorhergehenden Kapitel wurden Geschaftsprozesse und Ftih-

rungsstrukturen, wie sie in einem europaweit agierenden Unter-
nehmen vorkommen konnen, exemplarisch aufgezeigt. 1m wei-
teren wird aufgezeigt, welche Losungsmoglichkeiten es fur eine
optimale europaweite DV-Untersttitzung gibt und welche gene-
rellen und speziellen Anforderungen von SAP-R/3 in Bezug auf
ein paneuropaischen Informationssystem erftillt werden.
Grundsatzlich sind zwei Ansatze zur Implementierung eines
paneuropaischen Informationssystems zu berticksichtigen (siehe
hierzu Abbildung 1). Auf der einen Seite steht ein zentraler An-
satz mit einem DV-System, das zentral an einem Standort in Eu-
ropa installiert wird und aIle anderen Standorte eines Unterneh-
mens tiber Kommunikationsleitungen mit dem zentralen DV-
System verbindet.

Abbildung 1:
Zenlrale, dezenlrale
und gemischle
Archilekluren

Demgegentiber steht ein dezentraler Ansatz, in dem das gleiche

DV-System an verschiedenen Standorten implementiert wird und
die DV-Systeme tiber Kommunikationsleitungen miteinander
verbunden werden. Beide Basisansatze haben spezifische Vor-
und Nachteile (siehe Tabelle 1).

281
3 L6sungsm6glichkeiten mit SAP-R/3

Tabelle 1:
Vor- und Nachteile zentraler Ansatz dezentraler Ansatz
des zentralen und Vorteile Nachteile Vorteile Nachteile
dezentralen Ansatzes
• redundanz- • hohe Kom- • geringe • redun-
freie und munikations- Kommu- dante
zentrale kosten nikations- Daten-
Datenhal- • es muB sehr kosten haltung
tung leistungs- • weniger • redun-
(Stamm- fahige und Rechner- dante
und Bewe- teure Hard- leistung Software-
gungs- ware einge- erforder- funk-
daten) setzt werden lich tionen
• redundanz- • schlechtes • bessere • es mus-
freie Soft- Anwortzeit- Anwort- sen meh-
warefunk- verhalten bei zeiten rere
tionen Online-Aus- des DV- DV-
• es muB nur wertungen Systems Systeme
ein DV- • gerninderte • hohere gewartet
System AusfaU- Ausfall- und be-
gewartet sicherheit sicher- treut
werden heit werden

Aus der GegenubersteUung der Vor- und Nachteile beider Ba-

sisansatze wird deutlich, daIS der Vorteil des einen Ansatzes der
Nachteil des anderen Ansatzes ist, und im umgekehrten FaUe gilt
das gleiche. Deshalb ist eine Mischung beider Ansatze denkbar,
die moglichst die Vorteile beider Basisansatze beinhaltet. Die
Verbindung beider Basisansatze soUte zum einen den wesent-
lichen Vorteil einer redundanzfreien Datenhaltung, vor allem der
Stammdaten, beinhalten und zum anderen geringere Anforde-
rungen an die Kommunikationsleistungen einer dezentralen Lo-
sung stellen. Soleh ein gemischter Ansatz konnte ein zentrales
DV-System beinhalten, das zentral die Stammdaten und Bewe-
gungsdaten, die fUr aIle Standorte von Bedeutung sind, verwal-
tet. In gleicher Form gilt dies auch fUr die Softwarefunktionen.
Die Funktionen, die fur aIle Standorte von Bedeutung sind oder
die zur Konsolidierung von Daten notwendig sind, sollten auf
dem zentralen DV-System gehalten werden. Daruber hinaus er-
halt jeder Standort ein eigenes DV-System auf dem standortspe-
zifische Stamm- und Bewegungsdaten verwaltet werden, die un-
abhangig von den anderen Standorten sind.

282
 3 L6sungsm6g1ichkeiten mit SAP-Rl3

Die Funktionen, die nur von einem Standort benotigt werden,

die standortspezifisch angepaBt wurden oder vie! Rechenzeit be-
notigen, werden auf dem dezentralen DV-System vorgehalten.
Die dreistufige Client-Server-Architektur des Rl3-Systems mit ei-
ner Datenbankebene, Anwendungsebene und Prasentations-
ebene hat als Basis einen zentralen Datenbankserver, auf den
aile Applikationsserver der Anwendungsebene zugreifen. Die
Funktionen des Rl3-Systems, hinterlegt in Anwendungspro-
grammen, konnen auf verschiedene Applikationsserver verteilt
werden. Das Rl3-System erlaubt es, gleiche Anwendungssoft-
ware auf mehreren Applikationsservern zu installieren. Auf dem
Arbeitsplatzrechner befindet sich die Prasentationsebene mit der
grafischen Benutzeroberflache. Der Benutzer kommuniziert tiber
die Prasentationsebene mit dem Rl3-System. Der Arbeitsplatz-
rechner ist tiber ein Netzwerk mit einem Applikationsserver ver-
bunden. Der Vergleich dieser Grundstruktur mit den vorgenann-
ten Systemansatzen macht folgendes deudich:
1. Ein zentraler Ansatz ist mit dem Rl3-System problemlos
moglich, da die Grundstruktur von Rl3 bereits eine zentrale
Datenhaltung vorsieht.
2. Ein rein dezentraler Ansatz ist mit dem Rl3-System denkbar.
Se!bstverstandlich kann das gleiche Rl3-System an verschie-
denen Standorten eines Unternehmens implementiert wer-
den. Zwar bietet das Rl3-System verschiedene Schnittstellen
fur den maschinellen Datenaustausch, wie Batch Input, EDI
oder CPI-C an, jedoch werden im Standard keine Pro-
grammpakete angeboten, die es erlauben, automatisch
Stamm- und Bewegungsdaten der einzelnen Systeme ge-
geneinander auf den neuesten Stand zu bringen.
3. Ftir einen gemischten Ansatz feWen dem Rl3-System derzeit
noch einige Voraussetzungen. Dies gilt vor all em fur die
Verteilung des Rl3-Datenbestandes auf verschiedene Stand-
orte bzw. Rechner, wobei es in diesem Fall wesendich auf
das verwendete Datenbanksystem ankommt, das eine sol-
che Verteilung ermoglichen muB.
Neben diesen strukturellen Anforderungen gibt es noch weitere
allgemeine Anforderungen fur ein paneuropaisches Informati-
ons-system, wie Mandantenfahigkeit, Mehrsprachigkeit, Verarbei-
tung verschiedener Wahrungen, Verwaltung und verarbeitung

283
3 L6sungsm6glichkeiten mit SAP-Rl3

mehrerer Lager und die Berticksichtigung landesspezifischer Ge-

setzgebungen, die selbstverstandlich yom R/3-System erftillt
werden.
AuBerdem kommt es im hohen MaBe darauf an, inwieweit die
Organisationsstrukturen eines paneuropaischen Unternehmens
von einem Informationssystem, bezogen auf Funktionen und
Datenstrukturen, abgebildet werden kbnnen und wie der interne
und externe Informationsaustausch weitestgehend automatisier-
bar ist.
Der Aufbau des R/3-Systems in Mandant und Buchungskreis er-
laubt es, innerhalb eines Mandanten rechtlich selbstandige Un-
ternehmen mit eigener Bilanz und Gewinn- & Verlustrechnung
(G+V) in einem Buchungskreis zu ftihren. In gleicher Form kbn-
nen auch Firmenbereiche, die zwar nicht rechtlich selbstandig
sind, aber als eigenstandige Sparte in einem Unternehmen gel-
ten, in einem Buchungskreis geftihrt werden.
Die Funktionen und Datenstrukturen des R/3-Systems erlauben
es, tiber mehrere Stufen eine buchhalterische Konsolidierung
vorzunehmen. Hierdurch ist es mbglich, die SpartenJDivisionen
getrennt in verschiedenen Buchungskreisen zu fUhren. Die Kon-
solidierung kann zum einen nach gleichen SpartenJDivisionen
und zum anderen nach rechtlich selbstandigen Unternehmen
durchgeftihrt werden. In gleicher Form kbnnen in weiteren Stu-
fen nach anderen Gesichtspunkten konsolidierte Bilanzen oder
G&Vs erstellt werden (z.B. nach regionalen Kriterien). Eine Kon-
solidierung nach unterschiedlichen Gesichtspunkten bzw. Krite-
rien verdeutlicht die Abbildung 2:

284
 3 L6sungsm6glicbkeiten mit SAP-R/3

Abbildung 2:
Finanzkonsolidie-
rung nach unter-
r-t . . "~.
Untemehmen 1+2+31
schiedlichen Ge-
sichtspunkten ---i Konsolidierun~r
Untemchmen 1+

I~u' l ~ I
Untemellmen 1 Untemellmen 2 Untemellmen 3

0I>1t'100 01>1 ';011

2
SpaW, 1
0I>1 s100
3 s~ I ~'I~1
0I~s100 0I~s100 OI~OO
I I~ I ~ I ~
I
I 1
Konsolid i.rung
SpanelDivision 11
I
I Konsolidierung I
1SpanelDivision 21
I Konsolidierung I
I SpanelDivision 3 I

Eine zentrale Rolle fUr ein paneuropaisches Informationssystem

spielt die Organisation und VeIWaltung der Stammdaten. Eine
Zuordnung von Unternehmen, Sparten und Divisionen zu Bu-
chungskreisen zum Zwecke der Konsolidierung bedingt, daB
diese Buchungskreise auch mit den gleichen Stammdaten und
Stammdatenstrukturen arbeiten. Dies gilt vor allem fUr die Arti-
kel-, Kunden- und Lieferantenstammdaten; dariiber hinaus fur
die Produktgruppenstruktur, die Struktur der Vertriebsorganisa-
tion und der Einkaufsorganisation Csiehe hierzu Abbildung 3).
Erst wenn gewahrleistet ist, daB aBe Unternehmen bzw. Unter-
nehmensteile mit der gleichen Codierung der Produktgruppen-
hierarchie, der Kundengruppenhierarchie, der Vertriebswege, der
Verkauferhierarchie, Lieferantengruppenhierarchie, der Lander-
und Wahrungsschlussel usw. arbeiten, ist es mbglich, divisions-
und unternehmensubergreifend Bewegungsdaten automatisiert
zusammenzufassen.

285
3 L6sungsm6glichkeiten mit SAP-R/3

Abbildung 3: Ein- Unternhemenl Unternhemenl Unternhemenl

heitliche Stammdaten
Spartel Spartel Spartel
und Stamm-
Division Division Division
datenstrukturen fOr
aile Unternehmen- I 2 N
steile

Produkte
Kunden
Verlrie bsorganisalion
Einkaufsorganisalion
Logislikorganisalion
Kontenplan

Beispielhaft zeigt Abbildung 4, wie eine Produktgruppenhierar-

chie oder Kundengruppenhierarchie aussehen kCinnte:

Abbildung 4:
Beispiel einer hierar-
chischen Produkt-
gruppen- und Kun-
dengruppenstruktur

Einheitliche Starnrndaten fUr alle Unternehrnensteile schaffen we-

sentliche organisatorische Voraussetzungen, urn eine europawei-
te Preis- und Einkaufspolitik durchzusetzen. Die Preise kbnnen
allen Standorten, fUr jeden Kunden, in jeder lokaler Wahrung zur
VerfUgung gestellt werden. Preisanderungen kbnnen abgestirnrnt
vollzogen werden und stehen allen Unternehrnensteilen sofort
zur VerfUgung. Der Vertrieb kann schneller auf Marktverande-
rungen reagieren und effizienter arbeiten.

286
 3 L6sungsm6glichkeiten mit SAP-R/3

Die gleichen Vorteile elWachsen dem Einkauf, wenn aile mit der
gleichen Artikeleodierung arbeiten und die Lieferanteninforma-
tionen vollstandig transparent sind.
Die Datenstrukturen des R/3-Systems erlauben es, die gleichen
Stammdaten und Stammdatenstrukturen innerhalb eines Mandan-
ten fur verschiedene Buchungskreise CUnternehmen bzw. Unter-
nehmensteile) zu nutzen. Die standardisierten Auswertungsfunk-
tionen des R/3-Systems beinhalten eine flexible Zusammenfuh-
rung und Verdichtung der Bewegungsdaten innerhalb eines Bu-
chungskreises, aber auch uber mehrere Buchungskreise hinweg.
Das bedeutet, innerhalb der vom R/3-System vorgegebenen Or-
ganisationsstrukturen, wie Vertriebs-, Einkauf-, Produkt- und
Werks-/Lagerorganisation, bestehen viele Moglichkeiten fur die
Abbildung eines paneuropaischen Unternehmens. Jedoch sind
diese Organisationsstrukturen weitestgehend im R/3-System fi-
xiert und konnen angewandt, aber nicht verandert werden, wes-
halb die Flexibilitat eingeschrankt ist.
Die Kunden- und Lieferantenbeziehungen konnen innerhalb ei-
nes europaweit agierenden Unternehmens sehr komplex sein.
Abbildung 5 zeigt ein Beispiel mit einem zentralen Lager, von
dem aus der europaische Markt beliefert wird. Der Vertrieb so-
wie die Produktion ist dezentral organisiert, d.h. es gibt in ver-
schiedenen europaischen Landern Vertriebs- und/oder Produk-
tionsstandorte. Die Kunden der einzelnen Lander bestellen ihre
Ware bei den dezentralen Vertriebsstandorten. Von hier aus wird
der Kundenauftrag als Bestellung an die Landesgesellschaft wei-
tergeleitet, die Eigentumer des Lagers ist. Die Lagergesellschaft
bestellt wiederum die Ware bei def Produktion oder von exter-
nen Lieferanten. Yom zentralen Lager wird die Ware direkt zum
Kunden geliefert. Die Produktionsstandorte liefern teilweise di-
rekt an den Kunden oder zum zentralen Lager. Urn soleh eine
Organisation moglichst effizient zu unterstutzen, sind zwei
Funktionsbausteine von wesentlicher Bedeutung: die automa-
tische interne und externe Auftragsabwicklung und eine unter-
nehmensubergreifende Material- und Kapazitatsplanung.
Die externe Auftragsabwicklung, einerseits zum Kunden und an-
dererseits zum Lieferanten, ist im R/3-System durch eine EDI-
Schnittstelle gelost, die den internationalen Standards entspricht.
Die interne Auftragsabwicklung bedingt, daB das R/3-System
zum einen aus einem Kundenauftrag eine Bestellung erzeugen
kann und zum anderen die Bestellung automatisch zu einem

287
3 L6sungsm6glichkeiten mit SAP-R/3

zweiten Buchungskreis weitergeleitet wird. Der empfangende

Buchungskreis wandelt die Bestellung wiederum in einen Kun-
denauftrag urn. In umgekehrter Richtung muB der BelegfluB fur
Auftragsbestatigung, Lieferscheine und Rechnungen erfolgen. In
den erweiterten Funktionen des Rl3-Modules Sales and Distribu-
tion wird der buchungskreisubergreifende LagelVerkauf angebo-
ten. Diese Funktion erlaubt es, eine Auftragsabwicklung in der
geschilderten Form im Rl3-System abzubilden.
Fur die Materialplanung bedeutet eine soIche Organisation, daB
die Prognosedaten und Verbrauchsdaten der Vertriebs- und Pro-
duktionsstandorte zentral gesammelt werden mussen, urn den
Materialbedarf moglichst exakt zu bestimmen. Dies ist eine we-
sentliche Voraussetzung fUr eine optimale BestandsfUhrung und
Kapazitatsplanung. Falls die einzelnen Produktionsstandorte
ganz oder in Teilen substituierbar sind, bedarf es auch einer
unternehmensweiten Kapazitatsplanung, urn die Ressourcen eu-
ropaweit moglichst wirtschaftlich zu nutzen. Die relevanten Or-
ganisationsebenen des Rl3-Systems fUr die Material- und Kapazi-
tatsplanung sind Mandant, Buchungskreis, Bewertungsebene und
Werke. Einem Buchungskreis konnen mehrere Bewertungsebe-
nen eindeutig zugeordnet werden. Ebenso konnen mehrere
Werke eindeutig einer Bewertungsebene zugeordnet werden.
Fur die Werke einer Bewertungsebene ist eine ubergeordnete
Material- und KapazWitsplanung moglich. Eine Materialplanung
auf Mandanten- bzw. Konzernebene erlaubt das Rl3-System der-
zeit nicht.

288
 4 Ausblick

Abbildung5:
Beispiel fOr eine pan-
europaische Auf-
tragsabwicklung

4 Ausblick
Die Bildung eines europaisehen Wirtsehaftsraums mit der Ver-
sehmelzung von nationalen zu globalen Markten erfordert von
den Unternehmen gleiehermaBen den Weehsel von national em
zu internationalem Handeln. Dies bezieht sieh nieht nur auf die
Vertriebsaktivitaten, sondern gleiehermaBen aueh auf die Pro-
duktion, den Einkauf und die LageIWirtsehaft. Die Informations-
systeme mi.issen sieh dieser Entwieklung anpassen. Mit dem R/3-
System steht ein ausgereiftes Informationssystem zur Verfilgung,
das diesen Anforderungen zum groBen Teil gereeht werden
kann. Wie dieser Beitrag aber aueh zeigt, sind sowohl von seiten
der Softwarearehitektur als aueh von seiten der Datenstrukturen
und der Funktionalitat zu viele Mangel vorhanden, urn ein pa-
neuropaisehes Unternehmen lOOO/Oig zu unterstiltzen.
Weiterhin wird deutlieh, daB es nieht nur leistungsstarker Hard-
ware- und Netzwerkteehnologien fur ein europaweites bzw.
weltweites Kommunikationsnetz bedarf, sondern eine leistungs-
fahige und flexible Anwendungssoftware ebenso wiehtig ist.

289
 SAP-Ausbildung im Wandel

Dipl.-Inf. Ulrich Bartels

Fa. CLS InterService, Gesellschaft fUr Unternehmensberatung

und Informationsverarbeitung mbH, Bonn

Christoph Siebeck

Selbstandiger EDV-Fachjournalist, Bochum

290
 2 Die klassische Ausbildungsmethode - Seminare

1 Anforderungen an die Anwenderschulung

Moderne Anwendungssoftware wird auf der einen Seite immer
leistungsstarker, auf der anderen Seite aber auch immer komple-
xer. Ohne urnfangreiche und fachlich fundierte Ausbildung sind
die Anwender mit dem Programm in der Regel tiberfordert. Die
Moglichkeiten der Software bleiben weitgehend ungenutzt. Die
Konsequenz: Die kostenintensive Umstellung auf elektronische
Datenverarbeitung bringt nicht den erwarteten Wettbewerbsvor-
teil.
Lange Zeit wurde die zwingend notwendige Schulung der Mitar-
beiter "nebenbei" erledigt. Das Anwendungsprogramm wurde
angeschafft, installiert und die Schulung dann von einem ver-
meintlichen "Experten" erledigt - sei es aus dem eigenen Haus
oder als externer Dienstleister. Aus Kostengrtinden wurde die
Ausbildung auf das absolute Minimum beschrankt. Der Rest er-
gab sich dann oft in der taglichen Praxis - oder eben nicht.
Heute laSt sich diese Form der "Schulung" nicht mehr durchfiih-
reno Bereits herkomrnliche Standardsoftware, wie Textverarbei-
tung oder Tabellenkalkulation sind fur solche "Crashkurse" viel
zu urnfangreich, ganz zu schweigen von komplexen Softwaresy-
stemen wie SAP Rl3. Mag bei einer Textverarbeitung eine ge-
scheiterte Anwenderschulung unangenehm und teuer sein, kon-
nen Unwissen, Halbwissen oder Fehlbedienungen beim Rl3-
System die Handlungsf:ihigkeit eines ganzen Unternehmens ge-
fahrden .
Ohne fachlich fundierte und methodisch-didaktisch sinnvolle
Ausbildung der Anwender ist daher die Einftihrung von SAP Rl3
von vornherein zum Scheitern verurteilt.
Besonderheiten der Die heutige Schulungssituation im Bereich der elektronischen
Schulungs- Datenverarbeitung weist einige Besonderheiten auf:
situation
1. Kaum noch ein Untemehmensbereich arbeitet ohne Com-
puteruntersttitzung. Die Zahl der zu schulenden Anwender
hat stark zugenommen.
2. Die Anwendungsprogramme werden immer komplexer.
Damit steigen auf der einen Seite die Anforderungen an die

291
2 Die klassische Ausbildungsmethode- Seminare

Auszubildenden, auf der andere Seite wird der Schulungs-

urnfang immer groBer.
3. Die Softwarehersteller bringen immer schneller neue Ver-
sionen auf den Markt, die eine erweiterte Funktionalitat
aufweisen. ]ede neue Version fuhrt damit auch zu einer
neuen Schulung.
4. Die Einfuhrung der elektronischen Datenverarbeitung muB
in vergleichsweise kurzer Zeit erfolgen. Kein Unternehmen
kann sich heute mehrere Monate Umstellung leisten. Das
System muB so schnell wie moglich in den Produktivbetrieb
gehen.
Schulungen mussen also fUr viele Personen, auf hohem Niveau,
in kurzen Abstanden und in moglichst kurzer Zeit durchgefuhrt
werden. Der Ausbildungsbereich ist damit auch zu einem erheb-
lichen Kostenfaktor geworden. Die Ausbildung muB nicht nur
erfolgreich, sondern gleichzeitig auch kostengunstig sein.

2 Die klassische Ausbildungsmethode - Seminare

Grundsatzlich bieten sich fur das Lernen zwei klassische Metho-
den an:

• die Vermittlung durch ein Seminar oder ahnliches und

• das Selbststudium durch Bucher oder andere Printmedien.
Selbslsludium Das Selbststudium Wit bei der Anwenderschulung fur das Rl3-
System von vornherein aus, da die Inhalte vie I zu komplex fUr
eine ausschlieBlich theoretische Vermittlung sind und eine ef-
fektive Lernkontrolle fehlt.

Seminare Bleibt die Vermittlung durch ein Seminar. Hier gibt es verschie-
dene Moglichkeiten:

• externe Schulungen
Bei externen Schulung trifft haufig eine heterogene Lern-
gruppe zusammen. Die Teilnehmer verfUgen uber unter-

292
 2 Die klassische Ausbildungsmethode - Seminare

schiedliches VOlWissen und kommen aus unterschiedlichen

Unternehmen, vielleieht sogar aus unterschiedlichen Abtei-
lungen. In der Regel beschranken sieh externe Seminare da-
her auf Standards, die die individuelle Arbeitssituation des
einzelnen und auch die umfangreiehen Customizing-
Moglichkeiten des R/3-Systems nieht berucksiehtigen. Haufig
mussen Nachschulungen durchgefuhrt werden, die noch
einmal auf die unternehmenstypischen Besonderheiten und
das Arbeitsumfeld des Teilnehmers eingehen.

• interne Schulungen durch eigene oder externe Dozenten

Interne Schulungen bieten den Vorteil, daB sie auf die Ar-
beitssituation der Teilnehmer und die individuellen Anpas-
sungen des R/3-Systems maBgeschneidert werden konnen.
Die Ausbildungsinhalte spiegeln exakt das wieder, was im
Arbeitsalltag gefordert wird. Allerdings werden hierfur ein
Schulungsraum mit entsprechender Ausrustung und hoch
qualifizierte Dozenten benotigt, die sieh ihr Fachwissen ent-
sprechend honorieren lassen.

Vorteile von Semina- ]edes Seminar - egal, ob intern oder extern durchgefuhrt - weist
ren einige typische Vor- und Nachteile auf. Zuerst die Vorteile:

• Das Lernen in der Gruppe kann die Lernleistungen erhohen.

1m Idealfall untersrutzen sieh die Teilnehmer gegenseitig und
tauschen ihre Erfahrungen aus.
• Die Teilnehmer konnen im bestimmten Rahmen die inhaltli-
chen Schwerpunkte mitbestimmen - vorausgesetzt, der Do-
zent hat die notigen Kenntnisse. Diese aktive Mitbestimmung
fordert das Interesse und auch die Motivation.
• Die Schulung kann durch unterschiedliche Medien und Me-
thoden abwechslungsreieh gestaltet werden. Damit steigt die
Aufmerksamkeit und die Lern- und Behaltensleistung der
Teilnehmer.
• Der Dozent kann bei MiBverstandnissen sofort korrigierend
eingreifen oder einzelne Teilnehmer gezielt unterstutzen.

293
2 Die klassische Ausbildungsmethode- Seminare

Nachteile von Semi- Diesen Vorteilen stehen allerdings auch Nachteile gegenilber:
naren

• Der Erfolg der Ausbildung wird in sehr hohem MalSe durch

den Dozenten bestimmt. Gute Dozenten sind erfahrungsge-
malS schwierig zu finden . Gefordert sind sowohl urnfassende
fachliche Kenntnisse, als auch eine fundierte padagogische
Ausbildung. Ein Fachexperte, der die Teilnehmer mit stun-
denlangen Vortragen ilberfordert, niltzt genau so wenig wie
ein ausgezeichneter Padagoge, der keine fachlichen Fragen
beantworten kann. Da die Nachfrage zur Zeit sehr hoch ist,
sind gute Dozenten oft langfristig ausgebucht.
• Der Lernerfolg hangt von der Tagesform der Teilnehmer und
des Dozenten abo Ein Teilnehmer, der eine unruhige Nacht
verbracht hat, lalSt sehr schnell in der Aufmerksamkeit nacho
Mbglicherweise verpalSt er ganz den AnschlulS und wartet nur
noch auf das Ende der Schulung.
• Die Teilnehmer entscheiden nicht selbst, wann und wieviel
sie lernen. Jeder Schulungstag hat ein mehr oder weniger fe-
stes Programm, das von den Teilnehmern absolviert werden
mulS - gleichgilltig, ob sie gerade aufnahmebereit sind oder
nicht. Der LernprozelS ist mehr oder weniger erzwungen. Be-
sonders bei mehrtagigen Seminaren lalSt die Aufmerksamkeit
und Leistungsfahigkeit der Teilnehmer gegen Ende sehr stark
nacho
• Die Situation im Seminar kann unangenehme Erinnerungen
an die Schulzeit wecken. Erwachsene haben immer eine be-
sondere Lerngeschichte, die auch durch die Schulausbildung
mitgepriigt wird. Die Erinnerungen sind nicht immer ange-
nehm. So kann zum Beispiel ein direktes Nachfragen des Do-
zenten zu hohem StrelS und Leistungsdruck filhren, der emo-
tiona Ie Lernblockaden beim Teilnehmer erzeugt. Haufig fin-
den sich bei Teilnehmern auch Angste; bei Fehlern oder
"dummen Fragen" von den anderen Teilnehmern werden sie
belachelt. Die positiven Effekte des Gruppenlernens kbnnen
- je nach Lerngeschichte und Persbnlichkeit des Teilnehmers
- genau ins Gegenteil kippen .
• Die Inhalte einer Schulung lassen sich nur sehr eingeschrankt
individualisieren. Besonders bei externen Seminaren ist die
Lerngruppe oft sehr heterogen - sowohl von den Berufsbil-
dern als auch von den Vorerfahrungen. Die Folge: Der eine
Teilnehmer ist mit der Schulung vbllig ilberfordert, ein ande-
rer Teilnehmer findet das Seminar langweilig. Selbst bei glei-

294
 2 Die klassische Ausbildungsmethode - Seminare

chen Voraussetzungen der Teilnehrner treten uber kurz oder

lang Schwierigkeiten auf, da das Lerntempo haufig sehr un-
terschiedlich ist. Entweder mussen die schnellen Lerner auf
die langsamen warten, oder die langsamen Lerner verlieren
den AnschluB.
• Die Schulung ist mit hohen Kosten verbunden. Neben den
reinen Schulungskosten kommen noch die Kosten fur den
Arbeitsausfall sowie gegebenenfalls die Anreise und Ober-
nachtung dazu. Urn Kosten zu senken, wird daher gelegent-
lich nur ein Mitarbeiter einer Abteilung zur Schulung ge-
schickt, der seine Kenntnisse dann an seine Kollegen weiter-
geben soIl. In der Praxis scheitert dieses Verfahren allerdings
regelmaBig. Haufig reicht das neu erworbene Wissen des
Teilnehmers nur fur die Vermittlung elementarer Grundlagen
aus, komplexere Vorgange oder Funktionen werden erst gar
nicht erlautert. Zusatzlich entsteht durch die Vermischung
von Produktivarbeit und Ausbildung hoher Zeitdruck, der
letztendlich zu unbefriedigenden Ergebnissen fuhrt. Weder
die Ausbildung noch die eigentliche Arbeit werden angemes-
sen durchgefuhrt.
Seminare erfordern auBerdem einen hohen organisatorischen
Aufwand. So muB bei externen Schulungen der vorgegebene
Termin in die betrieblichen Ablaufe eingepaBt werden und ge-
gebenenfalls fur die Dauer der Schulung eine Ersatzarbeitskraft
beschafft werden. Bei internen Schulungen muB sowohl ein ge-
eigneter Dozent als auch ein entsprechender Schulungsraum zur
Verfugung stehen. Kurzfristige Anderungen sind kaum moglich.
Falls ein oder mehrere Teilnehrner an dem Schulungstermin
nicht abkommlich sind, wird das Seminar trotzdem stattfinden -
eben ohne den oder die Teilnehmer.
Seminare, die Wissen kompakt an mehreren Tagen vermitteln,
reichen fur eine praktischen Einsatz im Unternehmen meistens
nicht aus. Die Annahme, ein Anwender Ierne in drei oder funf
Tagen die notigen Kenntnisse, urn zum Beispiel die Kostenstel-
len- und Kostenartenrechnung im Modul 'CO-CCA' des Con-
trollings selbstandig durchzufuhren, ist illusorisch. Selbst eine
zehntagige Schulung wird nicht ausreichen.
Transfer des Haufig beginnt das eigentliche Lernen erst nach dem Seminar am
Gelernten Arbeitsplatz. Was in der Schulung in einer speziell geschaffen-
en, kunstlich konstruierten Lernumgebung noch problernlos

295
 2 Die klassische Ausbildungsmethode- Seminare

funktionierte, bereitet in der taglichen Praxis oft groBe Schwie-

rigkeiten: Der Transfer des Gelernten in den Arbeitsalltag gelingt
nur muhsam oder unter Umstanden gar nicht.
Selbst "aite Hasen", die umfangreiche Erfahrungen mit dem Rl3-
System haben, stoBen immer wieder auf Probleme, die sich nicht
sofort lasen lassen. Anfanger fuhlen sich haufig durch den
enormen Leistungsumfang und die Komplexitat des Rl3-Systems
verunsichert. Reagiert dann die Software nicht exakt so wie in
der Schulung, sondern meldet maglicherweise noch einen bis
dahin nie aufgetretenen Fehler, entstehen Angste und Frustratio-
nen. An eine effektive Arbeit ist nicht mehr zu denken.
Viele DV-Anwenderschulungen fUhren zu ahnlichen Ergebnissen
wie eine Fahrschulausbildung: Solange der Fahrlehrer auf dem
Beifahrersitz Platz nimmt, fUhlt sich der Fahrschuler sicher und
souveran. Die erste Alleinfahrt ist dann fur die allermeisten Fuh-
rerscheinneulinge mit Angst und Unsicherheit verbunden. Der
StraBenverkehr erscheint auf einmal unubersichtlich und voller
Tucken, die Bedienung des Autos kompliziert. Erst nach einigen
erfolgreichen Versuchen kommt dann die alte Sicherheit zurUck.
DV-Anwenderschulungen kannen aufgrund der knappen Zeit in
der Regel nur in die Bearbeitung von Standardvorgangen einfuh-
ren. In der Praxis sieht es aber oft ganz anders aus. Ein einfaches
Beispiel:
Beispiel Die Sachbearbeiterin Frau Muller aus der Buchhaitung hat bereits
mehrere Schulungen zum Rl3-System besucht - unter anderem
auch ein Seminar zur Belegbearbeitung im FI-Finanzwesen. In
der Schulung haben samtliche Arbeitsschritte problemlos funk-
tioniert. Frau Muller fUhit sich im Umgang mit der Anwendung
relativ sicher.
1m Unternehmen gibt es bereits in der ersten Woche ein Pro-
blem: Bei der Verbuchung muB ein Konto angesprochen wer-
den, das noch nicht vorhanden ist. Dieser Fall ist in der Schu-
lung nie vorgekommen, Frau Muller sitzt ratlos vor ihrem Rech-
ner. Sie ruft den Abteilungsleiter an und bittet urn Rat. Der kann
ihr zwar den richtigen Ansprechpartner nennen, ist aber verar-
gert, da die Schulungen sehr teuer und fur sein Empfinden
nutzlos waren.
methodisch·didak· Neben diesen Schwierigkeiten, die durch die spezielle Seminarsi-
tische Defizite tuation entstehen, zeigen sich auch immer deutlicher metho-
disch-didaktische Defizite in der Anwenderschulung.

296
 2 Die ktassiscbe Ausbitaungsmetboae - Seminare

Obwohl bereits seit vielen Jahren DV-Schulungen durchgefuhrt

werden, weiB eigentlich niemand so recht, wie nun eine erfolg-
reiche Anwenderschulung grundsatzlich aussehen soUte. Eine
durchgangige Didaktik des Computerunterrichts ist - wenn
uberhaupt - nur in Ansatzen vorhanden. Die Praxis sieht dann -
etwas ubertrieben - allzuoft so aus:
Der Dozent steht vor den Teilnehmern und fuhrt mit einem Vor-
trag in das Thema ein. Die Teilnehmer sitzen an ihren Obungs-
geraten und warten eigentlich nur darauf, daB sie endlich prak-
tisch arbeiten durfen. Dauert der Vortrag des Dozenten zu lange,
beginnen garantiert irgendwann die ersten Teilnehmer mit dem
Computer herumzuspielen. Hier muB der Dozent dann seinen
Vortrag unterbrechen und urn etwas Geduld bitten.
Dann werden die einzelnen Befehle und Arbeitsschritte hinter-
einander vom Dozenten an die Tafel geschrieben, die Teilneh-
mer fuhren sie entsprechend schrittweise aus. 1m Schulungsalltag
fuhrt diese Technik regelmaBig zu Schwierigkeiten. Das Tempo
der Teilnehmer ist eigentlich nie einheitlich. Der eine Teilneh-
mer ist sehr schnell fertig und wartet dann ungeduldig auf den
nachsten Arbeitsschritt; ein anderer Teilnehmer kommt nicht mit
und muB den Dozenten urn Hilfe bitten. Nimmt dieser seine
Aufgabe ernst, gibt er Hilfestellung und zusatzliche Erlauterung.
Die anderen Teilnehmer warten solange. Das Ergebnis dieser
"Methode": Die Lerngruppe wird in lauter Einzellerner gesprengt,
die sich aUe mit einer anderen Funktion beschaftigen und indi-
vidueUe Hilfe vom Dozenten erwarten. Bei den hohen Teilneh-
merzahlen muB dieser Anspruch fast immer scheitern.
Ein weiterer Nachteil dieser "Schrittmethode": Ein Arbeitsschritt
wird in lauter kleine Bestandteile zerlegt, die spater im prakti-
schen Einsatz vom Teilnehmer muhsam wieder rekonstruiert
werden mussen. Eine ganzheitliche und durchgangige Vorstel-
lung faUt aus Zeitgrunden meistens aus.
Auch in einem weiteren Punkt gehen Schulung und Arbeitspra-
xis haufig auseinander. Ein Programm wird anhand einzelner
Funktionen vorgestellt. Die Lerninhalte werden mehr durch die
logische Struktur des Programms bestimmt, als durch die Aufga-
ben, die der Teilnehmer im Arbeitsalltag lasen muB.

297
2 Die klassische Ausbildungsmethode - Seminare

Ein Beispiel:
Beispiel In einem R/3-Kurs zur Belegbearbeitung im FI erlautert der Do-
zent an einem einzigen Beispiel wie Netto- und Bruttobuchun-
gen durchgefuhrt werden und wie die Schnellerfassungsmaske
aufgerufen wird. Nachdem er diese unterschiedlichen Techniken
vorgestellt hat, erfahren die Teilnehmer, wie sie einen Beleg bu-
chen.
In der Praxis findet sich soleh eine Arbeitsweise nicht wieder.
Hier werden die Belegdaten erfaBt, dann erfolgt die Buchung.
Eine gleichzeitige Buchung eines Beleges im Netto- oder Brutto-
verfahren ist gar nicht mbglich. Auch die Schnellerfassungsmaske
wird wahrscheinlich nie fUr eine einzige Buchung eingesetzt. Die
ausschlieBliche Aufbereitung der Lerninhalte nach der logischen
Struktur des Programms eignet sich lediglich fur Anwender, die
bereits uber umfangreiches Grundlagenwissen verfUgen und in
einem nachsten Schritt Detailwissen erwerben sollen.
handlungs- oder pro- Sehr viel effektiver als dieses funktionsorientierte Vorgehen ist
zeBorientiertes Vor- eine handlungs- oder prozeBorientierte Methode. Die Teilneh-
gehen mer lernen die einzelnen Schritte genauso kennen, wie sie in der
Praxis benbtigt werden - also zum Beispiel: Erfassungsbild auf-
rufen, Daten eingeben, Buchung durchfuhren, Erfassungsbild
verlassen. Abweichende Verfahren - zum Beispiel Netto- und
Bruttobuchung - werden dann in einem weiteren, inhaltlich ge-
schlossenen Schritt vorgestellt. Der Teilnehmer kann die Inhalte
insgesamt aufnehmen und wird von der - unter Umstanden -
sehr muhsamen Puzzleaufgabe in der praktischen Arbeit entla-
stet.
Das Seminar als klassisches Instrument der Anwenderschulung
stbBt durch diese Probleme immer mehr an Grenzen. Zwar lieBe
sich der eine oder andere MiBstand durch eine methodisch-
didaktische Ausbildung der Dozenten vermeiden oder zumindest
verringern, bei dem zur Zeit sehr hohen Schulungsbedarf fehlt
aber sowohl die Zeit als auch das Interesse der Ausbilder.
Kurz gesagt: DV-Anwenderschulungen als Seminare sind sehr
kostenintensiv und bringen haufig nicht die gewi.inschten und
benbtigten Ergebnisse.

298
 3 Die alternative Ausbildungsmethode - CBT

3 Die alternative Ausbildungsmethode - CeT

Eine Alternative zu der herkommlichen DV-Anwenderschulung
in Seminaren bietet das Computer Based Training - kurz CBT.
Statt ein Seminar zu besuchen, arbeitet der Teilnehmer entweder
allein oder in einer Lerngruppe die Inhalte am Computer durch.
Die Idee, den Computer zu Ausbildungszwecken einzusetzen, ist
recht alt. Bereits in den 60er Jahren findet man die ersten Versu-
che, die nach dem sehr simplen Strickmuster: Frage - Antwort -
Bewertung - nachste Frage arbeiteten. Der Schuler konnte ledig-
lich die Geschwindigkeit dieses Frage-Antwort-Spiels bestimmen,
weitere Moglichkeiten gab es nicht.
Mullimedia- Heutige CBT-Programme haben mit diesen "Lern-Dinosauriernu
Techniken nur noch das Medium Computer gemeinsam. In erster Linie wer-
den Multimedia-Techniken eingesetzt, die Bild, Ton und Inter-
aktion kombinieren. In Simulationen kann der Teilnehmer den
Umgang mit dem System uben. Dabei sind sowohl die Arbeits-
techniken als auch die Reaktionen der Software dem tatsach-
lichen System sehr ahnlich.
Beispiel fOr ein R/3- Ein typisches Lernprogramm fur das R/3-System sieht z.B. so aus
Lernprogramm (MultiMedia Teach Line "Belegbearbeitung im flu):
In einem Eingangsbildschirm listet das Programm die Lektionen
des Kurses auf - z.B. "Bin/ache Belege erfassen", "Besondere Be-
lege erfassen" oder "Belege bearbeiten ".

Abbildung 3.1
Eingangsbildschirm

299
3 Die alternative Ausbildungsmethode - CBT

Der Teilnehmer kann unabhangig von der vorgeschlagenen Rei-

henfolge eine beliebige Lektion auswahlen. Unter den einzelnen
Lektionen werden dann die Kapitel aufgelistet - ftir die Lektion
"Ein/ache Belege erfassen" z.B. "Der Buchungsvorgang '~
"Eingangsrechnungen " oder "Gutschrift ". Auch hier kann der
Teilnehmer selbst entscheiden, welches Kapitel er bearbeiten
will.
Abbildung 3.2
Aulteilung in Lektio-
nen und Kapitel

Zu Beginn eines Kapitels erhalt der Teilnehmer zunachst Infor-

mationen tiber die Inhalte, Lernziele und die Bearbeitungsdauer.

Abbildung 3.3
Inhalte und Lernziele

Das konkrete Vorgehen zur Lbsung einer Aufgabe wird mit

nachgebildeten Bildschirmen des Rl3-Systems erklart. Der Teil-
nehmer erfahrt von einem Sprecher, welche Funktionen die ein-
zelnen Felder haben und welche Daten eingegeben werden

300
 3 Die alternative Ausbildungsmethode - CET

mussen. Besonderheiten werden noch einmal durch grafische

Elemente - z.B. Textfelder oder Rahmen - hervorgehoben. Nach
der Erklarung gibt der Teilnehmer dann selbstandig Daten in ei-
ner Interaktion ein und gelangt zum nachsten Bildschirm.

Abbildung 3.4
Interaktion mit nacho
gebildeten Rl3-
Bildschirmen

Neben den Interaktionen, die bereits eine Lernkontrolle darstel-

len, wird das neu erworbene Wissen nach jeder Lektion noch
einmal gesondert uberpriift. Dabei erhalt der Teilnehmer auch
Aufgaben, in denen er komplette Arbeitsschritte - z.B. das Erfas-
sen einer Eingangsrechnung - selbstandig 16sen muB. Zusatzlich
erfolgt am Ende des Kurses ein AbschluBtest, in dem der Teil-
nehmer ein Zertifikat erwerben kann. Der Schwierigkeitsgrad
dieses abschlieBenden Tests kann von der Systemverwaltung an-
gepaBt werden. Auf Wunsch kann der Teilnehmer sein Wissen
auch in einem Spiel uberpriifen.

Abbildung 3.5
Spielerische UberprO·
lung des Wissens

301
3 Die alternative Ausbildungsmethode - CBT

Der Kurs kann jederzeit unterbrocheI?- werden. Der Bearbei-

tungsstand wird dabei auf Wunsch gespeichert. Der Teilnehmer
kann damit sowohl die Lerninhalte als auch den Lernumfang
selbst bestimrnen.
Zusatzlich zum eigentlichen Kurs bietet das Programrn ein Lexi-
kon, das sowohl Fachbegriffe als auch die wichtigsten Verfahren
erlautert. Das Lexikon laBt sich auch isoliert verwenden.
Vorteile des CBT Multimedia-CBT-Programme verbinden viele Vorteile der
klassischen Methoden zur Wissensvermittlung:

• Der Teilnehmer lernt, wann und wieviel er will. Das Lern-

tempo richtet sich nach seinen Gewohnheiten, nicht nach
denen anderer Teilnehmer. Die Differenzierung der Lern-
inhalte erfolgt durch den Teilnehmer selbst. Er kann fUr ihn
uninteressante oder bereits bekannte Abschnitte tiberspringen
und bearbeitet nur die persbnlich relevanten Themen. Durch
dieses selbstbestimmte Lernen ist die individuelle
Bedeutung des Stoffes und damit auch die Aufmerksamkeit
sichergestellt. AuBerdem kann die Schulung auf viele kleine
Lerneinheiten verteilt werden, deren Lange sich nach der
Aufnahmefahigkeit des Teilnehmers und auch nach betrieb-
lichen Erfordernissen anpassen laBt.
• Computer werden von den meisten Menschen als objektiv
und unbestechlich empfunden. Fehler werden nicht bffent-
lich, so entfallt auch die mbglicherweise vorhandene Angst
vor MiBerfolg oder einer Blamage. Unangenehme Erinnerun-
gen an die Schulzeit kommen beim Lernen mit Computern
kaum auf. Das Lernen erfolgt deutlich entspannter. Die
"unpersbnliche Lernmaschine" - haufiger Kritikpunkt bei frti-
heren CBT-Programmen - tritt bei Multimedia-Systemen in
den Hintergrund. Der Computer wird eher als Lernpartner
empfunden.
• Durch die Interaktionen wird der Teilnehmer zur AktivWit ge-
zwungen. Dadurch verbessern sich die Lern- und Behaltens-
leistungen. Bei der Simulation des Anwendungsprogramrns
wird auf diese Weise auBerdem der Transfer in die Praxis er-
leichtert.
• Der parallele Einsatz unterschiedlicher Sinneskanale ftihrt zu
deutlich hbheren Lernleistungen. So liegt die Behaltenslei-
stung fUr Informationen, die lediglich gehbrt oder gelesen
werden, bei knapp 30 Prozent. Kombiniert man dagegen die

302
 3 Die alternative Ausbildungsmethode- CET

beiden Kan~ile, steigt die Behaltensleistung bereits auf 50 Pro-

zent. Werden dann dem Teilnehmer noch Mbglichkeiten ge-
geben, selbst einzugreifen, liegt die Behaltensleistung bereits
bei 90 Prozent.
• Die integrierten Ubungen ermbglichen eine effektive Lern-
kontrolle und eine differenzierte Ruckmeldung uber den
Lernfortschritt. Der Teilnehmer kann jederzeit selbst beurtei-
len, wie gut er den Stoff beherrscht und bei Bedarf gezielt
Themen wiederholen.
Diese Vorteile kbnnen die Schulungszeiten deutlich verkurzen
und gleichzeitig die Lernerfolge steigern. AuBerdem sind CBT-
Programme im Vergleich zu herkbmmlichen Verfahren oft deut-
lich kostengunstiger. Ein Beispiel:
Beispiel zur Ein CBT-Programm zum Thema "Dialogfunktionen im SAP-R/3"
Wirtschaftlichkeil kostet als Mehrplatzlizenz beispielsweise 10.000 DM. Dazu
kommen noch die nbtigen Aufrtistungen fur die Lernstationen -
z.B. mit Soundkarte, Kopfhbrern und CD-ROM-Laufwerk. Diese
Zusatzkosten belaufen sich pro Gerat auf knapp 500 DM. Insge-
samt werden in dem Unternehmen fUnf Lernstationen eingerich-
tet. Zusatzlich muB noch ein SelVer mit einer grbBeren Festplatte
ausgertistet werden. Hierfur entstehen weitere Kosten von
2.000 DM. Die Gesamtkosten betragen damit fUnd 14.500 DM.
Insgesamt sollen 40 Mitarbeiter die Schulung absolvieren. Die
durchschnittliche Bearbeitungsdauer fUr den Kurs betragt 2 Tage.
Pro Mitarbeiter und Schulungstag belaufen sich die Kosten damit
auf knapp 180 DM.
Bei einem Seminar dagegen sind Kosten von 1.000 DM pro Teil-
nehmer und Schulungstag keine Seltenheit. Dazu kommen dann
unter Umstanden noch die Anreise- und Ubernachtungskosten.
Je hbher das Schulungsvolumen, desto wirtschaftlicher wird der
Einsatz von CBT-Programmen. Werden in dem obigen Beispiel
100 Mitarbeiter geschult, reduzieren sich die Kosten pro Teil-
nehmer und Schulungstag auf knapp 72 DM. Bei einem Seminar
dagegen bleiben die Kosten pro Teilnehmer immer gleich - egal,
ob nun ein Mitarbeiter geschult wird oder 200. Je nachdem, wie
hoch die Kosten fur eine Anwenderschulung durch ein Seminar
liegen, kann bereits bei funf bis zehn Teilnehmern durch ein
CBT-Programm eine Kostensenkung erzielt werden. AuBerdem
sind die Investitionen in die Hard- und Software von dauerhafter
Natur.

303
3 Die alternative Ausbildungsmethode - CET

So kbnnen die Kurse ohne weitere Kosten auch fUr Nachschu-

lungen eingesetzt werden. Stellt sich im praktischen Einsatz her-
aus, daB der Mitarbeiter ein Thema noch nicht richtig beherrscht,
kann er die entsprechenden Lektionen ohne groBen organisato-
rischen Aufwand noch einmal an der Lernstation bearbeiten. Bei
Folgeschulungen sinken die Kosten pro Tag und Teilnehmer
noch einmal, da die nbtige Hardware nur einmal angeschafft
werden muB.
Angenommen, das Unternehmen aus dem obigen Beispiel fuhrt
als Folgeschulung den Kurs "Stammdatenpflege im FI" durch.
Die Anschaffungskosten fUr den Kurs belaufen sich ebenfalls auf
10.000 DM, die durchschnittliche Bearbeitungszeit betragt drei
Tage. Die Gesamtkosten fUr die beiden Kurse und die Hardware
liegen dann bei 24 .500 DM fUr funf Schulungstage und 40 Teil-
nehmer. Pro Tag und Teilnehmer belaufen sich die Kosten dann
auf circa 122 DM. Werden die Kosten fUr die Hardwareerweite-
rung herausgerechnet, betragen die reinen Schulungskosten so-
gar nur 100 DM pro Tag und Teilnehmer.
Ein weiterer Vorteil: Nach der Anschaffung kann der Kurs auch
fUr Schulungen an anderen Standorten eingesetzt werden. Statt
die Mitarbeiter auf die Reise zu schicken, werden einfach die
Datentrager versandt. Falls an dem anderen Standort bereits eine
entsprechend ausgerustete Lernstation vorhanden ist, fallen kei-
ne weiteren Kosten an.
CBT ist also nicht nur kostengunstiger als herkbmmliche Schu-
lungen, sondern auch wesentlich flexibler. Wann die Ausbildung
durchgefUhrt wird, kann kurzfristig festgesetzt werden.
Nachteile Allerdings weist CBT auch einige typische Nachteile auf:
des CBT

• Die Lerninhalte sind unveranderlich. Wenn ein Teilnehmer

mehr wissen mbchte, als das Programm vermittelt, muB er
sich entweder mit der Dokumentation des Anwendungspro-
gramms auseinandersetzen oder einen menschlichen Exper-
ten befragen. Der Teilnehmer kann lediglich die Auswahl der
Themen beeinflussen, aber nur in den seltensten Fallen Fra-
gen an das Programm stellen. Selbst wenn diese Mbglichkeit
besteht - z.B. bei der sehr aufwendigen Koppelung mit ei-
nem Expertensystem - ist die Antwort nicht immer brauchbar.

304
 3 Die alternative Ausbildungsmethode- CET

• Die Lerninhalte kbnnen bei Standardprogrammen nicht an

die Erfordernisse des Unternehmens angepaBt werden. In
dies em Punkt mtissen CBT-Programme mit den gleichen
Schwierigkeiten kampfen wie eine herkbmmliche Standard-
schulung. Wird das Rl3-System in einem Unternehmen tiber
das Customizing angepaBt, stimmen die Inhalte des CBT-
Programms oft nicht mehr mit dem System am Arbeitsplatz
tiberein. Einen Ausweg bieten hier entweder sehr teuee Indi-
vidualentwicklungen oder aber CBT-Programme, die sich
tiber Schnittstellen urn benutzerdefinierte Inhalte erweitern
lassen.
• Die Simulation des Anwendungsprogramms ist .nie ganz rea-
lis tisch. Urn den Anspruch einer wirklich exakten Nachbil-
dung zu erftillen, mtiBte das gesamte Rl3-System nachpro-
grammiert werden. Zwangslaufig beschranken sich die Reak-
tionen des CBT-Programms auf einige Aspekte bzw. erzwin-
gen bestimmte Eingaben. Ein exploratives Lernen ist damit
unmbglich, aus Sicherheitsgri.inden aber beim Rl3-System
wohl auch nicht angebracht.
• Lernen beschrankt sich nicht nue auf die Vermittlung von
Faktenwissen, sondern beinhaltet auch soziale Kompetenzen
oder z.B. die Vermittlung von Entscheidungsfahigkeit. Lernen
am Computer zielt fast ausschlieBlich auf den kognitiven Be-
reich. Die Versuche, Verhaltenstraining am Computer duech-
zufuhren, sind ohne menschliche Rtickmeldung von vorn-
herein zum Scheitern verurteilt. Bei der DV-
Anwenderschulung tritt dieser Aspekt allerdings in den Hin-
tergrund, da hier fast nue Struktur- und Faktenwissen benbtigt
wird.
• Multimedia-CBT-Programme stellen sehr hohe Anforde-
rungen an das Entwicklungsteam. Neben Fachexperten und
Padagogen werden auBerdem noch Programmierer und Gra-
fiker benbtigt. Ein Programm, das schon in der Bedienung
die gesamte Aufmerksamkeit des Anwenders erfordert, wird
kaum zusatzliches Wissen vermitteln kbnnen. AuBerdem wird
bei einigen Multimedia-Programmen immer noch der techni-
sche Aspekt tiberbetont. Ein Programm, das einen komplizier-
ten Sachverhalt tiber eine Videosequenz mit einem vortra-
genden Dozenten vermitteln will, hat seinen Zweck genauso
verfehlt wie ein Programm, das jede richtige Antwort des Ler-
nenden mit einem langen Fanfarenkonzert euphorisch feiert.

305
4 Rahmenbedingungen fur den CBT-Einsatz

CBT CBT ist deshalb kein vollwertiger Ersatz fur die klassische An-
als Alternative wenderschulung in Seminaren, sondern eine kostengunstige Al-
ternative, urn Grundlagenwissen zu verrnitteln. In der Praxis
werden daher Seminare und CBT haufig nebeneinander einge-
setzt: Der Teilnehmer eignet sich zuerst an der Lernstation das
notige Grundlagenwissen an, Spezialkenntnisse werden dann in
Serninaren oder Workshops vermittelt. So werden die typischen
Vorteile der beiden Methoden optimal kombiniert.
CBT bietet auBerdem die Moglichkeit, den hohen Schulungsbe-
darf, besonders fur komplexe Systeme wie R/3, in angemessener
Zeit zu bewaltigen. Obwohl die Anbieter fur SAP R/3-Schu-
lungen immer mehr zunehmen, reichen die vorhandenen Ka-
pazitaten nicht aus, urn die enorme Nachfrage kurzfristig zu be-
friedigen . CBT-Programme konnen die Dozenten von Grundla-
genschulungen entlasten und so das vorhandene Know-how fur
maBgeschneiderte, kundenindividuelle Schulungen freistellen.

4 Rahmenbedingungen fUr den CBT-Einsatz

Der CBT-Einsatz ist kein technisches Problem, sondern muB vor

allem unter padagogischen Gesichtspunkten betrachtet werden.
Die Beschaffung der Hard- und Software allein bietet keine au-
tomatische Garantie fur den Erfolg der Schulung.
Generell mussen folgende Punkte uberpri.ift werden:

• 1st eBT tatsachlich ein geeignetes Mittel fUr die Schulung

oder nur das kostengiinstigste?
Bei der Verrnittlung sozialer, handwerklicher oder kommuni-
kativer Fahigkeiten kann CBT zwangslaufig nie ausschlieBlich
eingesetzt werden. Der Computer ist in solchen Bereichen
aber gut fur die Verrnittlung von eher theoretischen Grundla-
gen geeignet. Ein CBT-Einsatz allein aus wirtschaftlichen Ge-
sichtspunkten kann den Erfolg der gesamten Schulung in
Frage stellen.

306
 4 Rahmenbedingungen fur den Einsatz von CBT

• In welcher Form soil das CBT durchgefiihrt werden?

Grundsatzlich gibt es drei Mbglichkeiten:
1. Autonomes Lemen
Dem Teilnehmer werden die Lemstation, der Kurs und alle
weiteren erforderlichen Materialien zur Verfugung gestellt.
Der Kurs muB in einer vorgegebenen Zeit absolviert werden.
Wie der Teilnehmer diese Zeitvorgaben erfullt, bleibt dabei
ihm selbst tiberlassen. Das autonome Lemen setzt diszipli-
nierte und hochmotivierte Mitarbeiter voraus und sollte nur
bei einer kleinen Zahl von Teilnehmem durchgefuhrt wer-
den. Neben der Anwenderschulung eignet es sich sehr gut,
urn Entscheidem einen Oberblick und Einftihrung in ein
Thema zu geben - zum Beispiel tiber die Leistungsfahigkeit
eines R13-Moduls .
2. Betreutes Selbstlemen
Bei dies em Verfahren steht dem Teilnehmer ein Tutor zur
Seite, der mit ihm den zeitlichen Rahmen und den Urnfang
der Ausbildung bespricht. Die Leminhalte arbeitet der Teil-
nehmer dann selbstandig an einer Lemstation durch - tibli-
cherweise im Untemehmen wahrend der Arbeitszeit.
3. Betreutes Lernen in Gruppen
Hier werden grbBere Lemgruppen zusammengestellt, die sich
zu festgelegten Terminen mit dem Thema beschaftigen. ]eder
Teilnehmer arbeitet im Schulungsraum allein mit dem CBT-
Programm. Der Kurs wird bei dieser Form tiblicherweise auf
einem Server installiert. Bei Bedarf steht ein Ansprechpartner
zur Verfugung, der auch mehrere Lemgruppen gleichzeitig
betreuen kann. Dieses Verfahren verbindet kurze Schulungs-
zeiten mit selbstbestimmtem Lemen. Es wird vor allem bei
einer groBen Zahl an Teilnehmem eingesetzt.
• Ist ein fester Ansprechpartner fUr die Tellnehmer vorge-
sehen?
Der Teilnehmer darf nicht das Geftihl haben, in einer sterilen
"Lemmaschinerie" allein gelassen zu werden. Bei Proble-
men - seien sie inhaltlicher oder technischer Natur - muB er
wissen, an wen er sich wenden kann. Diese Vorgabe gilt fur
alle Einsatzformen des CBT - egal, ob autonomes Lemen
oder betreutes Lemen in der Gruppe. Lediglich die Prasenz
und der Urnfang der Untersrutzung unterscheiden sich.

307
5 Mindestanfordenmgen an ein CBT-Programm

• Sind die Teilnehmer fUr die Arbeit mit dem Computer

ausreichend motiviert?
Vor aUem bei Teilnehmern, die noch nie mit einem CBT-
Programm gearbeitet haben, soUte darauf geachtet werden,
daB die Motivation stimmt und Angste erst gar nicht aufkom-
men. Vor der Schulung so Ute mit den Teilnehmern gespro-
chen werden, wobei insbesondere die Punkte des selbstbe-
stimmten Lernens und der Eigenverantwortung hervorgeho-
ben werden. Auf keinen Fall sollten Argumente, wie "Das ist
das billigste und funktioniert sehr gut!" benutzt werden. Der
Teilnehmer muB seine personlichen Vorteile beim Selbststu-
dium erkennen.

• Kann der Teilnehmer mit der Lernstation und dem Pro-

gramm umgehen?
Dieser Punkt ist vor all em beim autonomen und selbstbe-
stimmtem Lernen wichtig. Der Teilnehmer muB zumindest
wissen, wie er das CBT-Programm startet und die wichtigsten
Steuerungsfunktionen beherrschen.

5 Mindestanforderungen an ein CBT-Programm

Das CBT-Programm selbst muB einer grundlichen Prtifung unter-

zogen werden. Multimedia bedeutet nicht automatisch einen ho-
hen Lernerfolg. Nur technisch, methodisch-didaktische und in-
haltlich stimmige Programme fuhren zum gewtinschten Erfolg.
Schlechte Lernprogramme - leider immer noch haufig zu finden
- bewirken haufig genau das Gegenteil: Der Teilnehmer verliert
die Lust am Lemen.
Bevor die Entscheidung fur ein spezielles CBT-Programm faUt,
soUte man sich yom Anbieter eine Demo zeigen lassen, die im
Hinblick auf folgende Mindestanforderungen uberprtift werden
sollte:

308
 5 Mindestanfordernngen an ein CBT-Programm

• 1st das Programm inhaltlich korrekt?

Diese Anforderung sollte eigentlich selbstverstandlich sein,
wird aber nicht von jedem Programm erfullt. Es ist darauf zu
achten, daB der Hersteller ein Update des Lernprogramms fur
Releasewechsel des R/3-Systems anbietet. Ein veraltetes Lern-
programm sollte erst gar nicht eingesetzt werden.

• Sind die Zie1gruppe und Lerninhalte des Programm ein-

deutig def'miert?
CBT kann genausowenig wie ein Seminar samtliche mbgli-
chen Zielgruppen berucksichtigen. Ohne eindeutige Festle-
gung finden sich in dem Programm unter Umstanden viele
Themen, die aber nur sehr oberllachlich behandelt werden.

• Werden die Inhalte angemessen vermittelt?

Die technischen Mbglichkeiten dOIfen nicht Selbstzweck
werden. Optische und akustische Gags sorgen vielleicht beim
ersten Mal fOr Unterhaltung beim Teilnehmer, lenken aber
letztendlich nur abo Ein Sound- und Farbengewitter wird allzu
gerne genutzt, urn inhaltliche oder methodische Mangel zu
verstecken. Zu einfach sollte es aber auch nicht sein. Ein
Programm, das den Teilnehmer nur mit langen Lesetexten
traktiert, bringt gegenOber einem weitaus preiswerteren Buch
nur einen Vorteil: Die Seiten werden automatisch umgeblat-
tert.

• Sind die Inhalte praxisorientiert ausgewahlt?

Inhalte, die yom Teilnehmer nicht praktisch eingesetzt wer-
den kbnnen oder fur die alltagliche Arbeit keine Bedeutung
haben, sind nur hinderlicher Ballast. Das Programm sollte
sich weder mit Aligemeinplatzen aufhalten noch ausschlieB-
lich spezielle Problernlbsungen vorschlagen, sondern hand-
lungsorientiert wichtige Grundlagen fur ein Thema vorstellen.
So interessiert einen Anwender, wie er einen Vorgang mit
dem R/3-System bearbeiten kann, nicht wie das R/3-System
die dabei anfallenden Daten speichert und organisiert. Ein
Sachbearbeiter, der nie Berechtigungen an Anwender vergibt,
braucht auch keine langen Erklarungen zu dem Thema. Ein
kurzer Hinweis auf die Funktion von Berechtigungen reicht
vbllig aus.

309
5 Mindestanfordernngen an ein CBT-Programm

Fur den Inhalt gilt deshalb: Weniger ist oft mehr! Es zahlt
nicht die inhaltliche Vollstandigkeit, sondern der Bezug zur
Praxis.

• Arbeitet das Programm stabil?

Ein gutes Lernprogramm muB Bedienungsfehler sicher abfan-
gen. Der Teilnehmer benatigt seine volle Konzentration fur
die Inhalte, nicht fUr die Bedienung des Programms.

• LaSt das Programm dem Teilnehmer Freiheiten?

Die Lerninhalte und das Lerntempo soli der Teilnehmer be-
stimmen, nicht das Programm. Der Teilnehmer muB im Pro-
gramm beliebig hin- und herspringen und es jederzeit unter-
brechen kannen. Bei Interaktionen muB das Programm auch
falsche Eingaben zulassen und erst nach der Eingabe helfend
eingreifen. Wird jedes falsche Zeichen bemangelt, sind die
Lernerfolge wesentlich geringer.

• Wie reagiert das CBT-System auf Fehler des Teilnehmers?

Bei Fehlern darf nicht einfach nur eine Meldung "Falsch!" er-
scheinen, sondern auch ein Hinweis, was genau falsch ge-
macht wurde. Das Programm muB dem Teilnehmer auBer-
dem nach mehreren falschen Versuchen die richtige Lasung
zeigen. Andernfalls landet der Teilnehmer in einer Sackgasse!

• Sind die ErkIarungen des Programms verstiindlich?

Die inhaltliche Darstellung und die Sprache muB an die Ziel-
gruppe angepaBt werden. Fur Rl3-Einsteiger mussen wichtige
SAP-eigene Begriffe erlautert werden. Nicht jeder weiB, was
mit Begriffen wie "Sonderhauptbuchvorgang" oder
"Buchungskreis" gemeint ist.

• 1st eine Lernkontrolle vorhanden?

Ohne Lernkontrolle sind keine konkreten Aussagen uber den
Leistungsstand des Teilnehmers maglich. Ideal fur die Pla-
nung der Personalentwicklung sind zum Beispiel gedruckte
Zertifikate, die nicht nur allein die Teilnahme, sondern auch
die Leistung beschreiben. So lassen sich gezielt Nachschulun-
gen ansetzen.

310
 5 Mindestanfordernngen an ein CBT-Programm

• Sind die Aufgaben zur Lernkontrolle eindeutig und ab-

wechslungsreich?
Wenn Antworten vorgegeben werden - z.B. bei Multiple-
Choice-Fragen - mussen sie zur Frage passen. Ein Beispiel fur
eine unsinnige Aufgabe:
Wissen Sie, wann aus einer Anzahlungsanforderung eine
normale Buchung im Finanzwesen wird?
a) nach der Erstellung der Anzahlungsanforderung
b) nach der Verrechnung
c) nach der Erfassung der SchluBrechnung.
Die Frage HiBt keine der aufgefuhrten Antworten zu, sondern
kann nur mit Ja oder Nein beantwortet werden.
Die eingesetzten Techniken zur Lernkontrolle sollten mbg-
lichst abwechslungsreich sein. Ein stereotypes Anklicken von
Lbsungen fuhrt schnell zu nachlassender Aufmerksamkeit.
Ideal sind eingestreute Simulationsaufgaben, in denen der
Teilnehmer komplette Vorgange bearbeiten muB.

Dokumentation Einen guten Hinweis auf die Qualitat eines CBT-Programms

bietet oft bereits die mitgelieferte Dokumentation. Hier sollten
mindestens folgende Punkte dargestellt werden:

• Wer gehbrt zur Zielgruppe des Programms?

• Welche Voraussetzungen benbtigt der Teilnehmer?
• Wie lange dauert die Bearbeitung?
• Welche Hard- und Software wird zusatzlich benbtigt?
• Wie lauten die Lernziele des Kurses (Grob- und Feinziele)?
• Wie wird der Kurs bedient (am besten mit einem Beispiel)?

Eine gut gemachte Dokumentation ist oft ein Zeichen, daB sich
der Hersteller Muhe gemacht hat; eine entsprechende Qualitat
hat dann in der Regel auch der eigentliche Kurs .

311
6 Die Rlj-Schulung der Zukunft

6 Die R/3-Schulung der Zukunft

CBT und Multimedia sind nur ein Schritt, die R/3-

Anwenderschulung effektiver und kostengunstiger zu gestalten.
Heute werden CBT und die klassischen Schulungen durch Do-
zenten bei vielen Unternehmen zu einem ineinander verzahnten
Ausbildungsverfahren kombiniert. CBT deckt vor allem den
Grundlagenbereich ab, die Vermittlung von Spezialwissen erfolgt
nach wie vor uber einen Dozenten.
Kundenorientierung Dabei stehen immer mehr die einzelnen Kunden im Mittelpunkt
der Ausbildung. Viele Anbieter klassischer Schulungen verzich-
ten bereits auf vorgefertige Standardprogramme; sie stellen viel-
mehr einen Rahmen zur Verfilgung, der mit Inhalten gefilllt
wird, die die betriebliche Situationen des einzelnen Kunden op-
timal abdecken.
Integration von Auch CBT bietet diese Anpassung an kundenspezifische Beson-
beliebigen derheiten. Bereits heute sind Kurse auf dem Markt, die indivi-
Objekten in CST duelle Erweiterungen durch den Kunden erlauben. Das CBT-
Programm bietet die Grundlagen an; uber spezielle Schnittstellen
werden kundenspezifische Inhalte, die mit gangiger Stan-
dardsoftware erstellt werden kbnnen, in den Kurs integriert. Die
Einbindung beschrankt sich dabei nicht nur auf Texte oder Gra-
fiken, sondern umfaBt auch Sprache oder Video-Sequenzen. Fur
den Teilnehmer bleiben diese Erweiterungen im Idealfall vbllig
unsichtbar. Er bewegt sich durch einen einheitlich gestalteten
Kurs.
Damit fallt ein haufiger Kritikpunkt am CBT - zu starre und
schematische Inhalte - weg. Statt teurer Eigenentwicklungen, die
haufig mit groBen Schwierigkeiten verbunden sind, kann der
Kunde auf praxiserprobte Standards zUrUckgreifen und sie nach
seinen eigenen Vorstellungen und Erfordernissen mit relativ ge-
ringem Aufwand ausbauen.
Modularisierung CBT-Systeme der Zukunft werden noch einen Schritt weiter ge-
hen. Die Lerninhalte werden sehr stark modularisiert und kbn-
nen entweder von einem Tutor oder dem Anwender selbst in
beliebiger Form zusammengestellt werden. Kombiniert man die
Schnittstellen zu externen Anwendungen und verfolgt eine star-
ke Modularisierung, entsteht ein Programm, das sowohl die

312
 6 Die Rl3-Scbulung der Zukunft

kundenspezifischen Besonderheiten als auch die individuellen

Vorerfahrungen des einzelnen Teilnehmers optimal unterstiitzt.
Ausbildungs- und Anders als heutige Ausbildungsformen wird die Ausbildung der
Betreuungszentrum Zukunft nicht mehr geographisch gebunden sein. Ein Dozent
oder auch ein CBT-System bietet die Informationen zentral an,
die Teilnehmer werden dann mit dies em Ausbildungszentrum
tiber Datenautobahnen verbunden. Auch die Ausbildungsbe-
treuung kann zentral erfolgen. Der Teilnehmer bearbeitet in sei-
nem Unternehmen das CBT-Programm und kann jederzeit tiber
den Bildschirm Kontakt zu seinem Tutor aufnehmen, der in ei-
nem Ausbildungszentrum sitzt. Der Tutor schaltet sich mit in das
Programm ein und gibt gezielte Untersttitzung.
Vom Trainer In der Zukunft wird sich die Rolle des Dozenten immer weiter
zum Lernberater yom "Trainer" zum "Lernberater" verandern. Statt den Teilneh-
mern selbst die Inhalte zu vermitteln, widmet sich der Berater
gezielt den individuellen Fragen und Problemen des einzelnen
Teilnehmers und der kundenindividuellen Anpassung der Schu-
lungsinhalte. Auf diese Weise maximiert er den Lernerfolg des
einzelnen.
Integration in die Das Lernen selbst wird in absehbarer Zeit nicht mehr isoliert von
Produktivarbeit der Produktivarbeit erfolgen, sondern integriert. So kann das
R13-System beispielsweise urn eine kontextsensitive Lernkompo-
nente erweitert werden, die dem Anwender exakt die Fahigkei-
ten und Fertigkeiten vermittelt, die er zur Lbsung eines Problems
benbtigt. Soleh ein Modell - zur Zeit noch Zukunftsmusik - kann
dann so aussehen:
Der Anwender meldet sich beim R/3-System an. An dem PaB-
wort erkennt das System, daB es sich urn einen Neuling handelt
und schlagt ihm eine kurze Vorstellung des R/3-Aufbaus und der
Funktionsweise vor. Danach teilt der Anwender dem System mit,
welehe Aufgabe er Ibsen mbchte. Das R/3-System erlautert zu-
nachst die wesentlichen Schritte und zeigt die Wirkungen des
einzelnen Vorgangs fur das gesamte Unternehmen auf. Anschlie-
Bend kann der Anwender selbst versuchen, die Aufgabe durch-
zufuhren. Dabei tiberwacht R/3 die Eingaben und greift bei Be-
darf mit Erlauterungen und Hinweisen korrigierend ein.
Die Schulung erfolgt bei soleh einem Modell unter absolut rea-
listischen Bedingungen. Gleichzeitig lernt der Teilnehmer die
Vorgange prozeBorientiert und in ihrer Gesamtheit kennen.

313
6 Die Rl3-Schulung der ZukunJt

Mittelpunkt der Schulung ist der Anwender und seine individuel-

len Schwierigkeiten und nicht mehr das Programm und der
Computer. Ein Dozent tritt dann nicht mehr direkt in Erschei-
nung, sondern nur noch als Fachexperte, der Know-how fUr das
Lernsystem liefert.

314
Projektausschnitte Integration SAP-Rl3
Planung und Konzeption fur Schulung
(Aus-, Fort- und Weiterbildung)

Stefanie Franken/Dipl.-lng. Nils H. Jorgensen

Fa. NETG
Applied Learning GmbH, Willich

315
1 Uberblick

1 Oberblick

Wer die betriebswirtschaftliehe Software SAP Rl3 einfuhren will,

betritt in vielen Punkten Neuland. Bei der Einfuhrung von SAP-
Rl3 wird mit einer Menge "Unbekannter" gearbeitet. Fast aile
Unternehmensbereiehe sind betroffen. Ein wesentlicher Erfolgs-
faktor bei der Optimierung des Integrationsprozesses von SAP-
Rl3-basierenden DV-Strukturen ist die Vorgehensweise und Be-
trachtung der Ausbildungs- und SchulungsmaBnahmen der
Endanwender (Mitarbeiter), die in ihrer taglichen aufgabenbezo-
genen Arbeitsweise mit der neuen Umgebung und Anwen-
dungsoberflache konfrontiert werden.
Urn das gewi.inschte Ergebnis zu erzielen, werden innerhalb der
Projekteinheiten logische Geschaftsprozesse diskutiert und in der
Systemumgebung mittels Customizing und Modifikationen ab-
gebildet. 1m Ausbildungsanteil ist der Faktor "Mensch" ein
schwer kalkulierbarer Faktor. Durch innovative Ausbildungs-
maBnahmen und vor allem durch Motivation der Mitarbeiter wird
das richtige Trainings-Angebot der Garant zur wirtschaftlichen
Absicherung der Gesamtinvestition. Weiterqualifikation der Mit-
arbeiter ist als strategisches Mittel zur Wettbewerbsfahigkeit an-
erkannt und absolut notwendig. Entscheidend dafur ist die
mittlerweile erreiehte Qualitat und methodische und technische
Umsetzung dieser TrainingsmaBnahmen.
Die Einfuhrung von SAP Rl3 erfordert ein urnfassendes Projekt-
Management. Die wesentlichen Kosten (Beratung, Software,
Hardware etc.) sind ublicherweise aus betriebswirtschaftlicher
Sieht bei der Budgetierung von SAP-Rl3-Projekten beri.icksiehtigt.
Haufig werden jedoch die Trainings- und Ausbildungsanteile
(mangels Erfahrung) deutlich falsch bewertet und sorgen wah-
rend des Projektverlaufes immer wieder fur Dberraschungen.

316
 2 Betrachtungsweise der SAP-Rl3-Schulung

2 Betrachtungsweise der SAP-Rl3-Schulung

Die weitaus meisten im Wettbewerb stehenden Unternehmen

haben innerhalb der letzten 10 Jahre massive Anderungen in ih-
ren Hierarchiestrukturen vorgenommen.
Wenn vor 10 Jahren noch eine klare "Spitzenfuhrung" zu erken-
nen war, so wird heute in den meisten Unternehmen eine breite
"Basisftihrung" realisiert. Durch die damit moglichen schnelleren
Reaktionen HiBt sich das direkte Tagesgeschiift effizienter gestal-
ten. Vorbedingung und Grundlage ist der reibungslose Informa-
tionsfiuB zwischen allen beteiligten Unternehmenseinheiten.
Das Ausbildungsverfahren bei der Integration von SAP-R/3 muB
prinzipiell das Vorhandensein dieser Unternehmensstrukturen
berucksichtigen.

Abbildung 2.1
SAP R Betrcx:hfungsweise

Grdlsdle
D

SV1lemp1dtlorm
a lenl/Sarvar /

ilia
SV1Iarndc:rT'iniB:::'·
L:-:-_~__projakl-Gruppen
Enlwlcldung Konventionelle
Projekt-Betra:htung

Kaum ein Unternehmen, das sich mit der Einftihrung von SAP-
R/3 beschaftigt, fangt historisch bei "Null" an. Bestehende DV-
Systeme, Hardware-Plattform, Anwendungslosungen und nattir-
lich die Unternehmensaufgabe sind Bestandteile der Ausgangssi-
tuation.

317
3 SAP-Rl3-Basisanfordernngen in der Ausbildung

Wenn nach althergebrachten Betrachtungen der Fokus lediglich

auf die Kernbestandteile der neuen Anwendungslosung SAP-R/3
(Module) lag, so ist ein Umdenken in die globale Betrachtung
dringend notwendig. In der Umstellungsphase werden verschie-
dene Abteilungen plotzlich mit komplett neuen, nicht vergleich-
baren Situationen konfrontiert, wie z.B.:
Endanwender yom Terminal zum intelligenten PC / grafi-
sche Benutzeroberflache
DV-Entwickler von einfachen Datenmodellen zur relationa-
len Datenbank
DV-Administration von HOST-Systemen zum Client/ Server
Konzept.
]ede nicht beachtete Komponente birgt ein Risiko. Aus dieser
Betrachtungsweise heraus wird die Vorgehensweise der Ge-
schaftsprozeiSoptimierung, bei Implementierung von SAP R/3,
richtigerweise auf einzelne Projektgruppen mit unterschiedlichen
Schwerpunkten aufgeteilt. Daran angelehnt kann mit einer Be-
darfsanalyse fUr Schulung und Ausbildung ein sinnvolles Basis-
konzept erstellt werden, das als firmenspezifische
Ausgangsplanung dient. Der gewLinschte Erfolg stellt sich dann
ein, wenn im Ausbildungsbereich die Grundanforderungen be-
riicksichtigt sind und sinnvolle MaiSnahmen ergriffen werden.

3 SAP-Rl3-Basisanforderungen in der Ausbildung

Zu Beginn der SAP-R/3 Einfuhrung wird die Integrationsstrate-

gie festgelegt ("parallel oder stufenweise"). Von Anfang an steht
ein Zeitlimit fest, an des sen Ende die Produktivphase beginnt.
An diesen Rahmendaten sollten sich die AusbiidungsmaiSnahmen
oder Methoden orientieren. Ziel ist die Optimierung des Integra-
tionsprozesses. Unnotige Zeitverschiebungen konnen durch
sorgfaltige vorherige Analyse des Schulungsbedarfs vermieden
werden.

318
 3.2 Schulungsbedaif

3.1 Oas Anforderungsprofil

Die SAP R/3 Einfiihrung wird generell von SAP-Logopartnern
oder der SAP selbst begleitet. 1m Mittelpunkt steht die betriebli-
che ProzeBoptimierung zur Anpassung der Softwarelosung an
die unternehmensspezifischen Anforderungen. Die Berater ste-
hen bei der Konzeption und Bildung von Projekteinheiten zur
Seite. Auch in Schulungs- und AusbiidungsmaBnahmen sind die-
se oft erste Ansprechpartner.
Schulung, als fester Bestandteil des Integrationsprozesses, stellt
eine fixe GroBe des Gesamtprojektes SAP-R/3 dar. Der Aufwand
und Urnfang werden mit festen Faktoren ermittelt und anhand
von Eckdaten zur Erstellung eines Schulungsplanes genutzt:
Anzahl der Projekteinheiten / Projekt-Management
AufgabeniZielsetzung der Projekteinheiten
Anzahl der Mitarbeiter pro Projekteinheiten
Anzahl der betroffenen Endanwender pro Projekt-
Management
Integrationsmodell (parallel oder stufenweise)
Zeitvorgabe pro Projekteinheit
Verfugbarkeit von Mitarbeitern fur tagliche Ausbildung
ohne Produktivitatsverluste
Festlegung des notwendigen Basiswissens
Ausbildungsvolumen / notwendiger Bedarf anhand der glo-
balen Betrachtungsweise
Intensitat der AusbiidungsmaBnahmen
nur Information 40%
Basiswissen 60%
Anwendungsschulung 80%
Intensivschulung 100%
Budget (separate Budgetierung)
Sind alle Eckdaten einmal erfaBt, ist ein Basisplan fur Ausbil-
dungsaktivitaten einfach zu ermitteln. Die Vorgehensweise in der
Schulungsmethode ist entscheidend fur den Investitionsaufwand
in Volumen und Kosten.

3.2 Schulungsbedarf
Wird die Betrachtungsweise aus Abbildung 1.1 zugrunde gelegt,
werden die direkt betroffenen Bereiche nach dem Anforderungs-

319
3 SAP-Rl3-Basisanforderungen in der Ausbildung

profil aufgelistet. Notwendige Informationen tiber Ausgangs-

situation, Urnfang, Aufgabenstellung und Ziele sollten aus den
einzelnen Projektgruppen durch die Projektleiter und Mitglieder
gesammelt werden. Zustandige Organisationen im Unternehmen
(soweit vorhanden) fUr Mitarbeiter-Qualifikationen oder Perso-
nalentwicklung sollten tiber die anstehenden AusbiidungsmaB-
nahmen informiert sein. Nicht selten werden Synergien aktiv, die
besonders die Budgetierungen positiv beeinflussen.

Beispiel:
Ein Unternehmen, das bisher in der "Mainframe-Umgebung"
unter SAP-R!2 arbeitet, mbchte stufenweise operative Bereiche in
Eigenregie in die SAP-R!3-Umgebung migrieren.
Das erste Pilotprojekt wird in einem Unternehmenszweig im rei-
nen Handels- und Dienstleistungsbereich ohne Produktions-
anteil durchgefUhrt. Ziel ist, die SAP-R!3-Module parallel in 12
Monaten, weitestgehend im Standard einzufUhren. Zur Beratung
steht ein qualifizierter SAP-Partner zur Seite, mit dem bereits -
neben der GeschaftsprozeBoptimierung - die Projekteinheiten
und deren Aufgaben definiert wurden. Die geplante Hardware-
Plattform wird ein UNIX-basierendes Client/ Server Konzept mit
grafischer Benutzeroberflache im End-User-Bereich sein. Bei der
Projektierung sind folgende Projekteinheiten gebildet:

Tabelle 1: HR 2 Projektmitglieder
Projekteinheiten 5 Endanwender
Fl/CO 4 Projektmitglieder
10 Endanwender
SO 6 Projektmitglieder
15 Endanwender
MM 5 Projektrnitglieder
15 Endanwender
ov 5 Systementwickler

AIle Projektgruppen werden aufgrund der parallelen Einftihrung

gleichzeitig aktiv, so daB fUr jede Einheit 12 Monate Einftih-
rungszeit zur Verftigung steht. Das Budget fUr Ausbildungs-
maBnahmen ist im Gesamtprojekt mit 7% festgesetzt. Das Ge-
samtvolumen wurde auf DM 2 Mio. geschatzt.
Die Endanwender arbeiten aktuell - fUr Mainframe klassisch - an
unintelligenten Ein-/ Ausgabe-Terminals.

320
 3 .2 Schulungsbedarj

Folgendes Anforderungsprof"ll ergibt sich aus o .g. Beispiel:

Tabelle2:
Analyse des Anforde- Anzahl 5 Projektgruppen
rungsprofils Projekteinheiten
Aufgaben modulspezifisch
Zielsetzung Tagesgeschaft
arbeitsprozeBorientiert
Anzahl 17 Projektmitglieder
Projektmitglieder
Anz. Endanwender 45 Endanwender
Integrationsmodell .parallel"
Projektlaufzeit 12 Monate
Verrugbare HR 10 % (1)
Mitarbeiter pro Tag ohne FI I CO 20 % (3)
Produktivitats- SO 15 % (3)
verlust MM 10 % (2)
(Produktivitatstoleranz 1 OV 10 %(0,5)
in %)
GESAMT 9,5
Basiswissen rur SAP R/3 Strukturen
Projektmitglieder Modulkenntnisse
IT-Kenntnisse
Basiswissen rur PC-Kenntnisse
Endanwender grafische Benutzeroberflache/ Maus
SAP-R/3-Gundkenntnisse
SAP-R/3-modulspezifisches Wissen
•Tagesgeschaft"
Anwendungen (z.B. Tabellenkalk.)
Basiswissen rur DV- SAP-R/3-Grundkenntnisse
Entwicklung und - SAP R/3 Strukturen
Administration Relationale Datenbanken
Programmierung mit ABAP I 4
Client/Server-Konzept
UNIX-Betriebsystem, SQL
Budget OM 140.00,00

1 Produktivitiitstoleranz gibt die Anzahl der Mitarbeiter an, die aus dem
aktuellen Tagesgeschaft einer Abteilung abgezogen werden kbnnen ohne ei-
nen Produktivitatsverlust zu verursachen.

321
4 Rlj-Ausbildungsmethoden u. -Mafinahmen

4 Rl3-Ausbildungsmethoden u. -MaBnahmen

1st das Anforderungsprofil erstellt und der grundsatzliche Bedarf

klar, tritt die Frage nach den Schulungsmbglichkeiten und nach
der richtigen unternehmensspezifischen Vorgehensweise in Re-
lation zur Kostensituation auf.

4.1 "Live-Training"
Die klassische Variante der Ausbildung, das Live-Training oder
die "Face to Face"-Schulung, stehen bei der Orientierung immer
an erster Stelle. Bei der Umsetzung in die SAP-R/3 Umgebung
wird das Live-Training regeimaBig in bezug auf den Nutzen und
das tatsachlich gelieferte Ergebnis in Frage gestellt. Oftmals be-
weist sich dieser Weg zwar als der einfachste und bequemste,
daflir aber als der teuerste. Hier ist das Angebotsspektrum sehr
groB. Eine qualifizierte Beratung von seiten der Berater ist in der
Regel nicht zu erwarten, da auch der Schulungsanteil als Live-
Training in deren Dienstleistungsspektrum fallt.
Das Live-Training hat seine Daseinsberechtigung in einem aus-
gewogenen Verhaltnis zu alternativen Ausbildungsmethoden.
Nur das Live-Training kann bei der Implementierung von An-
wendungslbsungen, wie SAP-R/3 mit Firmenspezifika (Custo-
mizing / Modifikation), dem Mitarbeiter die vorgenommenen
Anderungen und individuellen Anpassungen bieten. Flexibel
kann der Dozent sich an die laufenden Anforderungen aus dem
IntegrationsprozeB problemlos anpassen und auf tatsachlich an-
stehenden Trainingsbedarf eingehen.
Alternative Ausbildungsmethoden werden heute in einer Vielzahl
angeboten. Der Erfolg und die Akzeptanz bei Mitarbeitern besta-
tigen viele Unternehmen in ihren SchulungsmaBnahmen.

4.2 "Computer Based Training" (CBT)

Wurde in den vergangenen Jahren tiber Sinn und Unsinn, Nut-
zen und Kosten beim Einsatz von Computerlernprogrammen
nachhaltig gestritten, so ist man sich heute damber einig, daB

322
 4.2 "Computer Based Training" (CBT)

"Computer Based Training" (CBn alle herkammlichen Lernme-

thoden schlagt. 2
Die innovative Methode des "Computer Based Training" (CBT)
birgt fUr Endanwender wesentliche Vorteile:
- angepaBtes Lernverhalten
- individuelles Lerntempo
Padagogisch gut gemachte CBT-Programme wirken sich durch
den mutimedialen EinfluB von Text, Grafik, Animation
(interaktiv) und Ton positiv auf die Lernveranlagungen eines
Anwenders aus:
• visuell (sehen)
• auditiv (haren)
• haptisch (beriihrungs-, bewegungsorientiert)
Die Verwendung von digitalen und analogen Elementen in den
CBT-Programmen vereinfachen die Informationsaufnahme und
bringen so komplexe Zusammenhange in eine leicht verstandli-
che Form. Daraus resultiert eine schnellere Aufnahme und hohe
Auswertung (bis zu 70%) des Lernstoffs.
CBT-Programme fUr SAP-Rl3-Endanwender-Schulungen werden
bereits auf Basis von CD-ROM in Vielfalt angeboten. Die Ein-
arbeitung in das klassische Tagesgeschaft des Anwenders erfolgt
direkt in der Original-SAP-Oberflache und erleichtert dem An-
wender die direkte Obertragung in die Echtzeitverarbeitung.
Ahnlich den SAP-Strukturen werden im modularen Aufbau CD-
ROM Kurse angeboten, die den Anforderungen der Arbeitspro-
zesse gerecht werden.
Unternehmen, die CBT-Programme bei SchulungsmaBnahmen
zum Einsatz bringen, wissen deren Vorteile zu schatzen:
- hahere Lernerfolge
- weniger Zeitaufwand
- kostengunstiger
- einfacher verfiigbar als Dozenten
- prozeBorientiert einsetzbar
- hohe Akzeptanz / weniger Oberzeugungsaufwand
- motivierte Mitarbeiter

2 vgl. Heizmann, U.: Computer '95-Beruf '95, Das aktuelle PC-Jahrbuch auf Dis-
kette, Haufe Verlag, 1995

323
4 Rlj-Ausbildungsmethoden u . -MajSnahmen

Dabei ist zu berucksichtigen, daB firmenspezifische Anpassungen

in vorgegebenen Standardmodellen nicht abgebildet werden.
Diese Tatsache steht fur eine sinnvolle Kombination von Live-
Training und CBT.

4.3 "Lernen durch Anwendung"

Eine konventionelle Methode zur Ausbildung der Endanwender,
"einfach daransetzen und sehen was geht", hat sich bis heute aus
verstandlichen Grunden nicht durchgesetzt.
Der gewtinschte Erfolg ist im Vergleich zum Live-Training und
CBT nicht einmal mit 25% zu bewerten. Ohne klare Zielvorgabe
und Aufgabenstellung muB der Anwender sich selber in der
Echtzeitverarbeitung an die einzelnen Aufgaben in seinem Ar-
beitsprozeB herantasten.
In der komplexen Anwendungslbsung SAP-R/3 wtirde diese Art
von Schulung, in Anlehnung an fehlendes Basiswissen zur Ar-
beitsweise von relationalen Datenbanken, verheerende Auswir-
kungen haben, die jede Investition in die Qualifikation von
Mitarbeitem rechtfertigt.
Die Methode "Lemen durch Anwendung" ist eine sinnvolle Er-
ganzung, urn Erlemtes aus Live-Training und CBT in der Echt-
zeitverarbeitung am Arbeitsplatz umzusetzen und die erlemten
Fahigkeiten regelmaBig anzuwenden und zu stabilisieren.

4.4 "Lernstoff durch Lesen"

Diese Lemmethode erfordert diszipliniertes Verhalten und eine
hohe Eigenmotivation durch den Mitarbeiter. Durchaus kann, je
nach Mitarbeiterprofil, eine solche Eigeninitiative angebracht
sein, sie trifft aber auf die breite Masse der Zielgruppe nur in
wenigen Fallen zu.
Durch die uberaus komplexen Programmstrukturen von SAP-R/3
stellt das Lemen durch Lesen schon eine relative Anforderung
dar und setzt ein gewisses Basiswissen allein im Terrninologie-
Verstandnis voraus. Der Lemerfolg und die damit verknupften
Lemziele lassen sich nur zweifel haft nachvollziehen.

324
 5 .1 "Medium & Workshop "-Konzept

5 Sicherung der AusbiidungsmaBnahmen

Angebotene Ausbildungsvielfalt heiBt nicht, daB nur eine der

o .g. Vorgehensweisen in Anspruch genommen wird. Vielmehr
sollte ein Konzept angewandt werden, das als innovative Me-
thode alle Vorteile von Computer Based Training (CBT) , Live-
Training und Lemen durch Anwendung verbindet, ohne deren
Nachteile wirksam werden zu lassen.

5.1 "Medium & Workshop"-Konzept

Davon ausgehend, daB SAP-Basiswissen und die spezielle fach-
spezifische tagliche Routinearbeit des einzelnen Mitarbeiters als
"Tagesgeschaft" in der SAP-R/3-Umgebung zu schulen ist und
firmenspezifische Anteile erganzt werden sollen, sieht das Kon-
zept fUr die DurchfUhrung der SchulungsmaBnahme eine Dreitei-
lung vor. In einem Eingangsserninar ("Kick off") werden die
Teilnehmer motiviert und uber die Ziele aufgeklart. Es wird die
Lemgruppe zusammengestellt und das soziale Umfeld geschaf-
fen .

Abbildung 5.1
fv'EDIU M& WO<KSHCY

KickOff FdlONLP
Waksh:p
o

0.
Sta1J:toe fEHD:II<
MjI\dIcn
&1. O.61o:rr!zJrg
&16Je'U"g
Te:n-Erl.
DEtdI-Acn
o ~ &1 , M:dftkdlam
Ob.rgJlEdi-Zet

O~ •
o • III
o
C81 • rdlirg
I
o
Ur1e'stU2U"gdJdl Fl'qEkl-LEifB IT rdrs
fEHD:II<.QI;p'o:d'e 'Nvg:JJ'
2-4 SId
m:x 4 hp'o91zU"g
6-8 SId

AuiJdiv

325
5 Sicherung der Ausbildungsmafinahmen

Diese Phase dient auBerdem dazu, das jeweilige Lernniveau der

Teilnehmer festzustellen und entsprechende Schritte und Strate-
gien fur sie abzuleiten. In dem folgenden CBT-Anteil des Work-
shops arbeiten aile Teilnehmer individuell nach ihren Vorausset-
zungen und entsprechend ihrem Lerntempo. Der Trainer oder
Kursleiter soli im Idealfall erreichbar sein und die Lernenden je-
derzeit betreuen konnen. In gewissen Abstanden sind sogenann-
te Check up-Gesprache zu empfehlen. Sie dienen der Kontrolle,
der zusatzlichen Motivation und geben das GefUhl, betreut zu
sein. Am Ende dieser Phase sind aile Teilnehmer auf einem ver-
gleichbar hohen Niveau, da die Methode CBT sicherstellt, daB
uber 80% der Lernenden uber 70% der Lernziele erreichen.
Die nun folgende Workshop-Phase C"Follow up") dient dazu, auf
dem Gelernten aufzubauen, es anzuwenden, firmenspezifische
Besonderheiten zu behandeln, wichtige Fragen zu klaren und
generell den Transfer fUr die Praxis anzubahnen. Der Trainer
kann hier sehr gezielt Feedback geben und ist genau uber den
jeweiligen Stand der Teilnehmer orientiert.
Vorteile des Medium & Workshop-Konzeptes sind einfach abzu-
leiten :
- gunstige Kostenrelation zum reinen Live-Training3
- hoher Nutzungsgrad durch motivierenden Aufbau
- firmenangepaBte AusbildungsmaBnahme
- strategische ProzeBoptimierung
- einfache Umsetzbarkeit
- kontrollierbare Ergebnisse
- 80% Zielerreichung
- hohe Reproduzierbarkeit

5.2 Konfiguration - "Medium & Workshop"

Die Ausarbeitung der Bedarfsdeckung erfolgt anhand der Basis-
daten aus dem Anforderungsprofil. Die EinfluBfaktoren Teilneh-
merzahl in Relation zur Projektlaufzeit sowie ausgewahlte CBT-
Kurse (Dauer) und Workshop-Anteile ergeben ausgewertet den
Schulungsbedarf (Mindestanzahl Lernsitzungen und Lernstatio-
nen).

3 siehe hierzu: Koste nvergleich der AusbildungsmaBnahmen CKapitel 5)

326
 5.2 Konfiguration - "Medium & Workshop "

Die Eckdaten fur den Ausbildungsplan sind die durchschnittliche

Lernzeit pro Anwender und Sitzung, max. Anzahl der Sitzungen
pro Station und Arbeitstag sowie die Definition der Intensitat der
Lernziele.
Die Rahmenbedingungen zu jedem einzelnen Projekt ergeben
den Bedarf an Lernstationen. Je nach Art des Integrationsmodells
(parallel oder stufenweise) werden die vorgegebenen Projekt-
Laufzeiten mit dem Bedarf an Lernsitzungen pro Lernstation ab-
geglichen.
Die jeweiligen Workshop-Anteile als Live-Training ergeben sich
aus den definierten Zielen der Projektgruppen. Die Ermittlung
der Workshop-Anteile hangt von den Grundlagen der einzelnen
Projektteams abo Max. Teilnehmerzahl pro Workshop (Kick Off
und Follow Up) und Dauer richten sich nach der Aufgabe und
der Zielsetzung der Projektgruppe. Unter MaBgabe, daB die SAP-
R/3-Module weitestgehend im Standard eingesetzt werden, wird
eine durchschnittliche praxisgerechte Mindestanforderung zu-
grunde gelegt:

- Kick Off 2 Stunden

- Follow Up 6 Stunden
- Max. Teilnehmer 15 Anwender

Tabelle3:
Beispiel-Konfi- Projektgruppe HR FI CO SD MM
guration zu Punk! Projektleiter 2 2 2 6 5
3.2:
Endanwender 5 8 2 15 15
CBT-Kurs-Dauer 10 Std. 10 Std. 10 Std. 10 Std. 10 Std.
Intensitat 800Al 800/0 80% 800/0 800/0
"Anwender-Schulung"
Effektiv-Stunden pro Kurs 8 Std. 8 Std. 8 Std. 8 Std. 8 Std.

Sitzung pro Endanwen- 4 4 4 4 4

der (max. 2 Std.)
Gesamt-Sitzungen 28 40 14 84 80
Mitarbeiter/Projektgruppe
Kick Off 2 Std. 2 Std. 2 Std. 2 Std. 2 Std.

Workshop 6 Std. 6 Std. 6 Std. 6 Std. 6 Std.

Produktivitatstoleranz 100/0 15% 15% 100/0 10%
Endanwd. verfugb. Sldltg!. 4 Std. 9,6 Std. 2,4 Std. 12 Std. 12 Std.

327
5 Sicherung der AusbildungsmajSnahmen

Tabelle4: Projektzeitraum 12 Monate 192 Arbeitstage4

Projektzeitrahmen
Arbeitstag 8 Std.
Gesamtstunden 246 Sitzungen
CBT-Sitzungen
bei 1 Lernstation 8 Std.-Tag 4 Sitzungen
Gesamt Tage 246/4 61,5 Tage
Live-Training:
- rur Endanwender 40 Std. 5 Tage
- rur Projektmitglied a 3 Tage 51 Tage
Gesamt Schulungs-Tage 138,OTage
Zeitkapazitilt + 54 Tage

5.3 Verteilung "Medium & Workshop"

Aus der Betraehtungsweise (siehe Abbildung 1.1) lassen sieh,
projiziert auf den gesamten IntegrationsprozeB von SAP-R/3 , die
relativen Sehulungsanforderungen in drei Gruppen einteilen:

- Endanwender im Tagesgesehaft SAP-R/3

(basis-/faehspezifisehes Wissen)
- Front-End-Anwendungen und User-Sehulungen
- DV-Entwieklung und System-Administration

Die Verteilung der Komponenten Medium-Anteil und Live-

Training wird in der Obersichtsdarstellung deutlieh:

4 effektive Arbeitstage: 12 Monate je 20 Arbeitstage multipliziert mit Faktor 1,25

CKrankheits-/ Fehl- und Urlaubstage)

328
 5 .4 Die Realisiernng "Medium & Workshop"

Abbildung 5.2
SAP R/3 Meclum& Wor

Gl'ln:lcgan
Dldoga
(FI, CO, JI.M, HR)
(SD,MM,PP,PM,QM)

WINDOWS
MSEXCEL 5.0
MSWlnWord6.0
Oln /Sa'wr
ORAaE/7
ABAP/4
SQL
UNIXac. ..

5.4 Die Realisierung "Medium & Workshop"

Ausbildung mit CBT
Schulung und Ausbildung wird direkt "vor Ort" im Unternehmen
umgesetzt. Fi.ir Computer Based Training wird eine eigene raum-
Hche Lernsituation, quasi ein Lernzentrum, geschaffen, in dem
die Mitarbeiter getrennt von der normalen Arbeitsatmosphare
entspannt und frei von Storungen lernen. Die Projektleiter erstel-
len anhand der Basiskonfiguration und nach Prioritaten einen
Ausbildungsplan fur die einzelnen Abteilungen bzw. Arbeitspro-
zesse, in dem die Lernschritte aus dem CBT-Medium erfaBt wer-
den.
Untersuchungen zum Thema mediengesttitztes Lernen5 haben
ergeben, daB ein dauerhafter Lernerfolg unwahrscheinHch ist,
wenn das Training direkt am Arbeitsplatz durchgefuhrt wird.
Unabhangig davon kann in besonderen Situationen die Verfug-
barkeit am Arbeitsplatz wiederum sehr sinnvoll genutzt werden,
wenn Ubungen direkt in der "Echtzeitverarbeitung" nachvollzo-
gen werden, z.B. "Tabellenkalkulation" .

5 vgl. Brinker, T./Fischer, St./Schrooer, A. : Lemen im SelbstIemzentrum der

Volkswagen AG. In: Arbeiten aus dem Seminar fur Padagogik, Technische
Universitat Braunschweig, Bericht 3/ 93

329
5 Sichernng der AusbildungsmajSnahmen

Live-Training (Kick Off & Follow Up)

Der Live-Trainings-Part wird durch die vorhandene Unterneh-
menssituation wesentlich mitbestimmt. Daraus lassen sich ver-
schiedene Konzepte ableiten:
Train the Trainer Das "Train the Trainer-Konzept" wird realisiert, wenn der
"Projektleiter oder Tearnleiter" den Live-Training-Part selbst
ubernimmt. Grundlage fUr den Projektleiter ist die intensive Ei-
genschulung mit den fUr seine Projektgruppe und Endanwender
notwendigen CBT-Programmen. Daraus resultiert ein Workshop-
Konzept, das Inhalt und Umfang des Kick-Off- und Follow-up-
Workshops bestimmt.
externe Unterstut- Dozenten oder Trainer, die direkt oder indirekt mit dem Integra-
zung tionsprozeB von SAP-R!3 vertraut sind, stehen extern untersrut-
zend bereit. Optimal sind Trainer, die bereits als begleitende
SAP-Berater tatig sind. Die Auswahl der Dozenten beschrankt
sich hier in der Regel immens. Grund dafUr ist die mangelnde
Bereitschaft von seiten der Dozenten, auf Basis von CBT-
Programmen erganzende Schulungen durchzufUhren. Auch hier
dient als Grundlage fUr den Trainer die intensive Eigenschulung
mit notwendigen CBT-Programmen.
Tip: Fragen Sie hierzu den CBT-Anbieter. Er wird in der Regel
Dozenten in Kooperation empfehlen.

5.5 Indikation und Ziele "Medium &Workshop"

Geht man davon aus, daB konventionelle Methoden in Ausbil-
dung und Schulung angewandt werden, so ist die Frage nach
tatsachlich meBbarem Erfolg durchaus berechtigt. 1st der Endan-
wender zum SchluB in der Lage, seine Arbeitsprozesse einfach in
der neuen Umgebung umzusetzen, wird die Investi-tion in die
Ausbildung vermeintlich bestatigt. Fraglich bleibt, nach welchem
MaBstab gemessen wird bzw. welche MeBlatte bei der Definition
des zu messenden Erfolgs zugrunde gelegt wurde.
Aussagefaruge Ergebnisse werden durch eine klare Definition
und Zielsetzung am Projektstart ermoglicht. Die Zielsetzung dient
als Grundlage, die richtigen SchulungsmaBnahmen einzuleiten
und auf den benotigten Zeitrahmen abzustecken. Die Wirkung
der unterschiedlichen Methoden lassen sich anhand der Abbil-
dung 5.3 ablesen.

330
 5.5 Indikation und Ziele "Medium & Workshop "

Abbildung 5.3 SAP R/3 Indkdion / Zise

- - - Uve • • •• · MedI.,
" l ernzl el
Dalnilioo

In der Abbildung 4.3 wird deutlich, daB die Lernmethoden von

Live-Training und CBT im synergetischen Effekt fur kurzfristig
gesteckte Ziele das beste Ergebnis liefern. 1m CBT-Training wer-
den in kiirzester Zeit Lernziele erreicht. Die Schulung wird durch
indiziertes Live-Training punktuell mit firmenspezifischen Details
erganzt. Dabei wird die Qualitat wesentlich verbessert. Die
Auswirkung des Wissensverlustes, der im natiirlichen Zeitverhal-
ten unvermeidlich eintritt ("kritische Periode"), kann durch Kon-
tinuitat und generelle Verfugbarkeit der CBT-Medien abgefangen
werden. Der Wissensstand bleibt auf einem sehr hohen Level
und verbessert in der Unternehmensstruktur die Personalflexibili-
tat.

331
6 Kostenvergleich der Ausbildungsmethoden

6 Kostenvergleich der Ausbildungsmethoden

Ein zentrales Thema im Zusammenhang von Ausbildung und

Schulung bei der Implementierung und Einftihrung von SAP-R/3
stellt das Verhaltnis der Kosten zum Gesamtprojekt dar.
Die Verteilung des Budgets ftir SchulungsmaBnahmen erfolgt
erfahrungsgemaB durch einen fixen prozentualen Anteil auf das
geschatzte Gesamtvolumen fur die Einftihrung von SAP-R/3. Da-
bei werden die Aufwendungen fur die Schulung anhand der An-
zahl User und Projektmitglieder ermittelt. Als Grundlage dient
die bisher angewandte Praxis des Live-Trainings.
In einem Kostenvergleich hat die Firma Siemens die bewahrten
Methoden des Live-Trainings und des CBT gegentibergestellt und
erhebliche Kostenersparnis festgestellt:
Ein zweitagiger Schulungskurs kostet 900 Mark und wird ftir 300
Teilnehmer an zehn Unternehmensstandorten durchgeftihrt. 6

Tabelle5: Kosten des herkommlichen Trainings:

Kalkulation eines 270.000 DM
Kurspreis:
Live-Trainings und
CBT Arbeitszeitausfall: 336.000 DM
Reisekosten: 60.000 DM

Gesamt: 666.000 DM
Kosten des CBT-Verfahrens:
Produktionskosten: 250.000 DM
CBT-Lieferung: 12.000 DM
Arbeitszeitausfall: 147.000 DM

Gesamt: 409.000 DM

Erspamis: 257.00000

6 vgl. Heizmann, U.: Computer '95-Beruf '95, Das aktuelle PC-Jahrbuch auf Dis-
kette, Haufe Verlag, 1995

332
 5.5 Indikation und Ziele "Medium & Workshop"

1m Siemens-Beispiel wird eine Kosteneinsparung bis zu 39 Pro-

zent erreicht. Selbst das Marktforschungsinstitut IDe legt fur den
Bereich der EDV-Schulung beispielsweise Kostenerspamisse von
bis zu 90 Prozent zugrunde.
Jede Einsparung ist untemehmenswirksam. Bei einem direkten
Vergleich zwischen "Live-Training" und "Medium & Workshop"
relativiert sich die Differenz des Kostenaufwands durch den
sinnvollen synergetischen Effekt in der Anwendung beider Me-
thoden im "Medium & Workshop"-Konzept.

Abbildung 6.1 SAP R/3 Kosten-Verg eidl

TDM
___ live-Tr (j_nln_
9 __ T~~ __ CBT-Mecien TDM Mecium
20- - - -- &-- - . 20
1oJmuI1., DM 19.00000

-ff- ~!~':O,,;..OO --.. --.. ---.------.--. HI ---.-- __ Workshop._ 18

~ 0 N.. SPtM'\ An"
-.:-.. 4 MlfaDeiI. '16- --- -- - ·16 -- iimiiliiit"liiiI5.iiliii.iio" 16
OOM 2&1.00

~ ~!~'~n8OO ·14--- .- . --- ---. - ---- .. ---- -14 ~E'~:::::&I.OO 142

.. . .. 4UN.S"""""
"" MllaDelhr 60M 2&1.00
·l 2 mll~.~ID~M5IEI·5000!OO3.. H2. ON. S"""", AA-. I\bfctvt
·~..........
8" OM 3.&10.00 -10·1-""'......."""'...................-1 10
..... Llve-Trdner
'-"""!lI!"-'''"""". ·8·· ...... - .......... ---- ........ -- ·8
N ~~I~=hr 60M 2&1.00
.. 'oM 7:000:00-........... 6 · . 0 ...... -- .......... 6
OM 9500.00
9' - ~~;;'~r .... --- - 4 - -:if 4 - ~:'~~o;~.= --. 4
'": ON .. Sp&I8\ Mr. 'lito 4 Mlfabolt..-
~.. ~~~~~ '-- iioiiOi'-- "" '2'''' .prD.MADM ..125.oo ......
04~ .
2

Die Gegenuberstellung in Abbildung 6.1 basiert auf einem 4-

tagigen Training, das neben den aktiven Kosten und notwendi-
gen Einzelleistungen auch den unterschiedlichen Zeitbedarf der
Methoden darstellt.

Fakten: Auf breit angelegten Studien uber Ausbildung und Schulung bei
der Einfuhrung von SAP-R/3 kann bei den derzeitigen Installa-
tionszahlen nicht zUrUckgegriffen werden.
Zur Schatzung des Schulungsaufwandes werden Erfahrungswerte
und Durchschnittsangaben aus bereits abgeschlossenen Projek-
ten herangezogen:

333
6 Kostenvergleich der Ausbildungsmethoden

Tabelle 6: live-Training MED IDM & WORKSHOP

Schiilzung des
Schulungs- Schulungsaufwand
aufwandes pro Projektmltglied:
15 Tage 4 Tage (extern)
(extern oder intern) 7 Tage CBT
Schulungsaufwand
pro Anwender:
2 Tage Basiswissen 8 Std. Basis CBT
5 Tage fachspezifisch 32 Std. fachspezifisch CBT
(durcb Projektleiter oder Trainer) Workshop-Betreuung
(durcb ?rojektleiter oder Trainer)

6.1 Kosten fUr Live-Training

Unter Verwendung des konkreten Beispiels unter Punkt 2.2 stellt
sich ein direkter Kostenvergleich wie folgt dar:
pro Projektmitglied:

15 Tage Schulung "extern" je Projektmitglied

(pro Tag DM 500,00)
DM
7.500,00

Ausfallzeit-Kosten je Projektmitglied
(pro Tag DM 300,00)
DM
4.500,00

pro Endanwender:

2 Tage Basis / 5 Tage fachspezifisch

durch Projektleiter "IN HOUSE" (max. 15 Teiln.)
Ausfallzeit fUr internen Trainer
DM 2.100,00

Ausfallzeit-Kosten je Endanwender
(pro Tag DM 300,00)
DM
2.100,00

(Grundlage Jur AusJalizeit-Berechnung ist ein Brutto-Jahres-

Einkommen von DM 72.000,-)

334
 6.2 Kosten fur "Medium & Workshop"

Tabelle7: Projekt- Proj.- Kosten- End- USER Kosten %

Schulung der gesamt- mit- Schulung an- Schulung Gesamt von
Endanwender durch kosten glied Projekt wender durch Gesamt
Live-Training durch Mitglieder Proj.-Ltr. Invest.
Projektmitglieder (17' 15' 500) (3' 2.100)
nach dem "Train the
2Mio 17 127.500 45 6.300 133.800 7%
Trainer-Konzept"

Kosten-Produktiv-Zeit der Mitarbeiter

(7 Tg. Endanwender 115 Tg. ProjektmitgJied a 300,-) 171.000

GESAMT 304_800

6.2 Kosten fur "Medium & Workshop"

pro Projektmitglied:

6 Tage Schulung "CBT-Medien"

4 Tage Schulung "extern" je Projektmitglied
(pro Tag DM 500,00) DM 2.000,00

Ausfallzeit-Kosten je Projektmitglied
(pro Tag DM 300,00) DM 3.000,00

pro Endanwender:
1 Tag Basis / 4 Tage fachspezifisch "CBT-Medien"

Workshop
(Kick Off 2 Std / Follow Up 6 Std.) durch externen Trainer
(pro Tag max. 15 Teiln.) DM 2.500,00

Ausfallzeit-Kosten je Endanwender
(pro Tag DM 300,00) DM 1.500,00

SAP-R/3 Medien-Bibliothek komplett DM 50.000,00

Equipment (2 Lernstationen) DM 10.000,00

(Grund/age fur Ausfallzeit-Berechnung ist ein Brutto-jahres-

Einkommen von DM 72.000,-)

335
6 Kostenvergleich der Ausbildungsmethoden

Tabelle8: Projekt- Proj .- Kosten Workshop Medien Kosten %

Workshop fUr gesamt- mit- Schul. Anteil & Gesamt Ges.-
Endanwender durch kosten glied Projekt- Endan- Equipm. lnv.
externe Trainer mitglied wender
bei
externen
Trainer
(17' 4' 500) (3"2.500)
2 Mio 17 34.000 7.500 60.000 101.500 5%

Kosten-Produktiv-Zeit der Mitarbeiter

(Endanwender 45"51 ProjektmtgJied 17"10 - a 300,-) 118.500

GESAMT 220.000

6,3 Kostenvergleich

Tabelle9: Ausbildung Live-Training Medium Differenz

Kostenvergleich Live- DM &
Training und Medium
& Workshop Workshop
DM
Projekt-Mitgl. 127.500,00 34.000,00 -93.500,00
Endanwender 6.300,00 7.500,00 + 1.200,00
Medien & 0 60.000,00 + 60.000,00
Equipment
Ausfallzeiten 171.000,00 118.500,00 - 52.500,00
(8,5 %) (6 %) (30%
GESAMT 304.800,00 220.000,00 - 84.700,00
in% 28%

Erliiuterung:
Die gunstige Bewertung des "Medium & Workshop"-Konzeptes
beruht auf der Tatsache, daB der Zeitvorteil bei CBT in den
Ausfallzeiten fUr Mitarbeiter Auswirkungen zeigt.

336
 7 Fazit

7 Fazit

Die erfolgreiche Einftihrung von SAP-basierenden DV-Struk-

turen ist gewahrleistet, wenn die Durchfuhrung des Tagesge-
schafts der einzelnen Arbeitsprozesse tatsachlich den Moglichkei-
ten der SAP-R/3-Anwendung entspricht. Ausbildung und
Schulung der Endanwender, mit Sicht auf die funktionellen Ar-
beitsablaufe, ist in der Komplexitat bei der Integration von SAP-
R/3 ein entscheidender Faktor.
Die Angebotsvielfalt der heutigen AusbildungsmaBnahmen fOr
Projekte wie die Einftihrung von SAP-R/3 bedeutet nicht, daB
sich eine Methode durch die andere ausschlieBt oder ertibrigt.
Ein stabiles Fundament zur GeschiiftsprozeBoptirnierung mit
SAP-R/3 ist die Nutzung aller Vorteile der angebotenen Ausbil-
dungsmaBnahmen, ohne ihre Nachteile wirksam werden zu las-
sen.
Die meBbaren Erfolge im Tagesgeschaft durch die Kombination
der Ausbildungsmethoden werden positiv verstarkt durch die
Optirnierung des Integrationsprozesses. Motivierte Mitarbeiter,
geringere Ausbildungskosten, ktirzere Schulungszeiten, effek-
tivere Nutzung bei weniger Ausfallzeit sind die Pluspunkte fur
die Sicherstellung der Investition in Mitarbeiter und Technologie
sowie fOr die Stabilisierung der Wettbewerbsfahigkeit.

337
Autorenverzeichnis

Autorenverzeichnis

Autor: Priv.-Doz. Dr. oec. HSG Thomas A. Gutzwiller

Beitrag: "Implementierung von Geschaftsprozessen mittels SAP-R/3: Un-
moglichkeit oder Konigsweg?" S. 1-13
Studien: Studium der Betriebswirtschaftslehre an der Universitat St. Gallen
(HSG) mit AbschluB als lie. oec. HSG. Promotion an der HSG mit
AbschluB Dr. oee. HSG und Ausarbeitung der Habilitationsschrift.
Berufliche
Tatigkeit: Geschaftsfilhrender Partner der IMG Information Management
Gesellschaft, St. Gallen/ Munchen/Vaduz/ Breslau.
Wiss. Aktivitaten: Privatdozent fur Betriebswirtschaftslehre an der Universitat (HSG)
St. Gallen fur Wirtschafts-, Rechts- und Sozialwissenschaften.

Autoren: Dipl.-Kfm. Michael Rosemann

Thomas Rotthowe, MBA
Dipl.-Kfm. Reinhard Schutte
Beitrag: "Modellbasierte Organisations- und Informationssystemgestaltung
unter Verwendung der Rl3-Referenzmodelle"; S. 14-42

Studien: Die drei Autoren studierten Betriebswirtschaftslehre an der Uni-

versitat Munster; Herr Rotthowe zusatzlich in Los Angeles.

Berufliche
Tatigkeiten: Sie sind wiss. Mitarbeiter am Institut fur Wirtschaftsinformatik der
Westfalischen Wilhelms-Universitat, Munster. Direktor: Prof. Dr.
Jorg Becker mit dem Lehrstuhl fur Wirtschaftsinformatik und In-
formations management.
Wiss. Aktivitaten: SAP-R/2 und R/3 in Forschung und Lehre. Der Lehrstuhl ist
Mitglied im SAP-Hochschul-Arbeitskreis und in einigen Praxispro-
jekten an der SAP-Einfuhrung beteiligt. Dabei zeichnen sich die
Projekte durch eine uberdurchschnittliche Verwendung von In-
formationsmodellen aus.

338
 Autorenverzeichnis

Autor: Dr. rer. pol. Andreas Hufgard

Beitrag: "Wirtschaftliche R/3-Einfuhrung im Mittelstand - Einsatzmbglich-
keiten von Methoden und Tools"; S. 43-82
Studien: Dipl.-Kaufmann und wiss. Mitarbeiter an der Universitat Wtirz-
burg, Lehrstuhl Prof. Dr. Thome

Berufliche
Tatigkeit: Geschaftsfuhrer der IBIS Prof. Thome GmbH in Wtirzburg. Die
IBIS Prof. Thome GmbH wickelt Forschungsprojekte mit Auftrag-
scharakter in Zusammenarbeit mit dem Lehrstuhl Prof. Dr.
Thome abo

Aufgrund von intensiven Kontakten mit den Firmen SNI und SAP
kennt Herr Hufgard wichtige Fakten tiber das Potential und die
Entwicklungsplanung der R/3-Softwarebibliothek. Ferner" kann er
mehrjahrige Erfahrung zum Thema Adaption und Einftihrung
von R/3 vorweisen.
Wiss. Aktivitaten: Dr. Hufgard promovierte zum Thema "Betriebswirtschaftliche
Softwarebibliotheken und Adaption". Er ist stellvertretender
Sprecher der Fachgruppe 5.0.4 Software und Servicemarkt der
"Gesellschaft fur Informatik e .V. (GO" und Mitglied des Vorstan-
des des "Wirtschaftsinformatik-Verbandes fur Forschung und
Praxis e.V. in Europa (WIV)".

Autor: Dipl.-Inf. Michael Hofebauer

Beitrag: "Das SAP-R/3-Berechtigungskonzept"; S. 83-100

Studien: Studium der Informatik an der math.-naturwissenschaftlichen Fa-

kultat der Rheinischen-Friedrich-Wilhelms-Universitat, Bonn, zum
Dipl.-Informatiker.
Berufliche
Tatigkeit: Berater fur SAP-Basis, SAP-RM-MAT (Materialwirtschaft) und ARIS
in der Fa. RATIODATA Informationssysteme, Wirtschaft und
Verwaltung GmbH, Kbln.
Wiss. Aktivitaten: Mitarbeiter in verschiedenen yom BMFT gefbrderten For-
schungsprojekten der Gesellschaft fur Mathematik und Datenver-
arbeitung in Sankt Augustin mbH.

339
Autorenverzeichnis

Autor: Dipl.-Inf. (FH) Edgar Bahmann

Beitrag: "SAP Business Workflow zur Steuerung von Geschafts-
prozessen"; S. 101-148

Studien: Wirtschaftsinformatikstudien an der Fachhochschule fur Technik,

Wirtschaft und Gestaltung, Konstanz sowie an der University of
NottinghamlGB. Diplomarbeit zum Thema "Workflow im SAP-
R/3-Umfeld" .
Berufliche
Tatigkeit: Technischer Berater im R/3 NTC, dem SAP-Competence-Center
fur R/3 auf Windows NT der Fa. iXOS Software GmbH, Gras-
brunn bei Munchen.

Er beschaftigt sich mit der Zertifizierung von Windows NT-

Plattformen.

Autor: Prof. Dr. rer. pol. Paul Wenzel

Beitrag: "SAP Business Workflow zur Steuerung von Geschafts-
prozessen"; S. 101-148

Studien: Studium der Betriebswirtschaftslehre an der Fachhochschule fur

Wirtschaft, Pforzheim, zum Dipl.-Betriebswirt (FH) sowie Uni-
versitatsstudien zum Dipl.-Kfm., Dipl.-Hdl. und Promotion zum
Dr. rer. pol. an der Johann Wolfgang Goethe-Universitat Frank-
furt.
Berufliche
Tatigkeit: Mitglied des Fachbereichs Informatik/Wirtschaftsinformatik an
der Fachhochschule fur Technik, Wirtschaft und Gestaltung,
Konstanz. Mitglied im Kooperations-Arbeitskreis "SAP-R/3 in
Hochschule und Wirtschaft" .

Vormals Hauptabteilungsleiter und Sonderbeauftragter fUr EDV-

Rationalisierungen des Vorstandes einer deutschen Industriehol-
ding.
Wiss. Aktivitaten: Autor zahlreicher Fachveroffentlichungen im Umfeld Standard-
Software und Informationsmanagement. Mitglied im SAP-
Arbeitskreis Hochschulen e.V., WaUdorf und im VULCAN e .V. an
der Universitat Wurzburg.

Forschungsprojekt zur Entwicklung multimedialer Lehrwerke im

Bereich der aUg.!angewandten Betriebswirtschaftslehre.

340
 Autorenverzeichnis

Autor: Jurgen Gulbins

Beitrag: "Optische Archivierung und Dokument-Management in SAP-
R/3"; S. 149-175

Studien: Informatikstudium und wiss. Mitarbeiter an der TU-Karlsruhe

Berufliche
Tatigkeit: Produktmanager fUr UNIX und anschlieBend Leiter der UNIX-
Entwicklung bei der Firma PCS und Leitung der CADMUS-
Archivsystementwicklung. Koordinator fUr die Implementierung
der SAP-ArchivLink-Schnittstelle und Berater fUr Archive und
Vorgangssteuerung bei der Firma IXOS Software GmbH, Gras-
brunn (bei Mtinchen).
Wiss. Aktivitaten: Autor von Fachbtichern, u.a . Elektronische Archivierungs-
systeme, UNIX, FrameMaker, Typographie und Archivsysteme.

Autor: Stephan Schilling

Beitrag: "Integration von Fremdprodukten in R/3 - Vorteile der funktiona-
len Kopplung"; S. 176-192

Studien: Informatikstudium, Schwerpunkte Datenbank- und Software-

Technologien, an der Universitat Dortmund
Berufliche
Tatigkeit: GeschaftsfUhrer der Firma icons information & communication
network systems gmbh, Ennepetal. Fa. icons ist autorisierter
Desktop-Integrationspartner der SAP AG und hat ein Produkt im
Bereich Desktop-Integration entwickelt.

Autor: Dipl.-Inf. (FH) Karl-Heinz Reutter

Beitrag: "Integration heterogener Systeme: Kopplung COPICS-MPR und
SAP-R/3-Einkauf"; S. 193-212

Studien: Wirtschaftsinformatik an der Fachhochschule Reutlingen

Berufliche
Tatigkeit: Systemanalytiker bei der Fa. TANGRAM, Gesellschaft fUr Infor-
mations- und Kommunikationsmanagement mbH, Gartringen.
BefaBt mit Systemintegrationsaufgaben im SAP-R/3-Umfeld.

341
Autorenverzeichnis

Autor: Prof. Dr.-Ing. Herbert Glockle

Beitrag: "Integration heterogener Systeme: Kopplung COPICS-MPR und
SAP-R/3-Einkauf"; S. 193-212

Studien: Maschinenwesen an der UniversitiH Stuttgart, Promotion an der

Universitat Hannover.
Berufliche
Tatigkeit: Mitglied des Fachbereichs Wirtschaftsinformatik an der Fach-
hochschule filr Technik und Wirtschaft, Reutlingen. Verantwort-
lich filr die SAP-R/3-Aktivitaten des Fachbereichs.
Mehr als zehnjahrige Berufspraxis als Unternehmensberater ftir
Organisations- und Logistiksysteme und als Abteilungsleiter in
der Softwarebranche.

Autor: Dr. Peter Laos

Beitrag: "Konzeption und Umsetzung einer Systemarchitektur ftir die
Produktionssteuerung in der ProzeBindustrie"; S. 213-236

Studien: Studium der Betriebswirtschaftslehre, Promotion tiber das Thema

"Datenstrukturierung in der Fertigung - Ein methodischer Model-
lierungsansatz filr die Gestaltung von Fertigungsinforma-
tionssystemen" .

Berufliche
Tatigkeit: Wiss. Assistent am Institut filr Wirtschaftsinformatik - IWi
CDirektor: Prof. Dr. A.-W. Scheer), an der Universitat des Saar-
landes, Saarbrucken.

Projektleiter des IWi im ESPRIT-Projekt CAPISCE Cneben SAP

und IWi sind die Partner DEC, IDS und ZENECA beteiligt); im
Projekt werden auf R/3-Basis Softwaremodule filr die kurzfristige
Produktionssteuerung in der ProzeBindustrie entwickelt; diese
werden als PP-PI in R/3, Release 3.0, integriert.
Zuvor Entwicklungsleiter der Fa. IDS prof. Scheer GmbH, Saar-
brucken. Zustandig filr die Entwicklung des Leitstandes FI-2.
Wiss. Aktivitaten: Informationsmanagement, Unternehmensmodellierung, betriebli-
che Informationssysteme in der industriellen Produktion und im
betrieblichen Einsatz von Datenbanken.

342
 Autorenverzeichnis

Autor: Theo G. Sulzmann

Beitrag: "Einheitliche Anlagenabwicklung Vertrieb" (EAV) am Beispiel
des "Internationalen Fachbereichs Hochspannungstechnik" der
AEG Daimler Benz Industrie"; S. 237-257
Berufliche
Tatigkeit: DV-Organisation Vertriebsregionen der AEG Daimler Benz Indu-
strie, Frankfurt.
Schulung, Information und Systemintegration sowie Planung und
Einfilhrung von Hard- und Softwaresystemen.

Autor: Peter Schneider

Beitrag: "Wellpappeproduktion - ein Fall fi.ir branchenunabhangige Stan-
dardsoftware?" S. 258-274
Berufliche
Tatigkeit: Leiter des Verkaufsinnendienstes und IT-Projektmanagement der
Fa. Duropack Wellpappe Gesellschaft mbH

Autor: Mag. Dr. Martin Lukanowicz

Beitrag: "Wellpappeproduktion - ein Fall fi.ir branchenunabhangige Stan-
dardsoftware?" S. 258-274

Studien: Studium der Betriebswirtschaftslehre an der Wirtschafts-

universitat Wien

Berufliche
Tatigkeit: Universitatsassistent am Institut filr Informationsverarbeitung und
Informationswirtschaft!Abt. filr Industrielle Informationsverarbei-
tung der Wirtschaftsuniversitat Wien
Wiss. Aktivitaten: Lehruntersti.itzung in SAP-bezogenen Lehrveranstaltung an der
Wirtschaftsuniversitat Wien

Autor: o. Univ.-Prof. Mag. Dr. Alfred Taudes

Beitrag: "Wellpappeproduktion - ein Fall filr branchenunabhangige Stan-
dardsoftware?" S. 258-274

343
Autorenverzeichnis

Studien: Studium der Betriebswirtschaftslehre an der Wirtschafts-

universitat Wien sowie der Betriebs- und Wirtschaftsinformatik
an der Universitat Wien
Berufliche
Tatigkeit: o. Univ.-Prof. und Leiter der Abteilung fur Industrielle Informati-
onsverarbeitung des Instituts fur Informationsverarbeitung und
Informationswirtschaft der Wirtschaftsuniversitat Wien
Wiss. Aktivitaten: R/2, RK-Einfuhrung bei der SDP AG, Wien, erster Lehrstuhl in
Osterreich, der SAP-R/3 einsetzt.

Autor: Dr. Siegbert Kern

Beitrag: "Paneuropaisches Informationsmanagement mit SAP-R/3";
S. 275-289
Studien: Studium zum Dipl.-Wirtsch.-Ing. an der Universitat Karlsruhe.
Promotion an der Universitat des Saarlandes, Saarbrucken, zum
AbschluB Dr. rer. oec. am Institut fur Wirtschaftsinformatik - IWi
(Direktor: Prof. Dr. A.-W. Scheer).
Berufliche
Tatigkeit: Leiter Managementinformationsysteme (MIS) der Fa. RUBBER-
MAID GmbH, Dietzenbach.
Wiss. Aktivitaten: Veroffentlichung zum Thema "Koordination dezentraler Produk-
tionseinheiten. In: Corsten, H. [Hrsg.): Handbuch Produktions-
management, Gabler-Verlag, Wiesbaden, 1994

Autor: Dipl.-Inf. Ulrich Bartels

Beitrag: "SAP-Ausbildung im Wandel"; S. 290-314

Studien: Studium der Informatik; Nebenfach: Mathematik.

Berufliche
Tatigkeit: Geschaftsfuhrer der Fa. CLS InterService Gesellschaft fur Unter-
nehmensberatung und Informationsverarbeitung mbH, Bonn.
Tatigkeitsschwerpunkte: betriebswirtschaftliche Beratung, lang-
jahrige SAP-Beratung und Projektleitung.

344
 Autorenverzeichnis

Autor: Christoph Siebeck

Beitrag: "SAP-Ausbildung im Wandel"; S. 290-314

Studien: Padagogik-Studium mit 1. Staatsexamen.

Berufliche
Tatigkeit: Selbstandiger EDV-Fachjournalist
Wiss. Aktivitaten: Drehbuchautor fur R/3-Lernsoftware

Autorin: Stefanie Franken

Beitrag: "Projektausschnitte Integration SAP-R/3 Planung und Konzep-
tion fUr Schulung (Aus-, Fort- und Weiterbildung)"; S. 315-337
Berufliche
Tatigkeit: Product-Managerin im Pharma-Sektor - Ophthalmologie. Ver-
triebsbeauftragte DV-Spezial-Anwendungslosungen. Marketing-
Assistentin fur DV-Systemlosungen "Handel und Dienstleistun-
gen". Vertriebl Marketing DV-Systemlosungen im Urnfeld IBM
"Handel". Product-Managerin SAP-R/3 Trainings-Angebot bei
NETG Applied-Learning GmbH, Willich.

Autor: Dipl.-Ing. Nils H. Jorgensen

Beitrag: "Projektausschnitte Integration SAP-R/3 Planung und Konzeption
fur Schulung (Aus-, Fort- und Weiterbildung)"; S. 315-336
Studien: Ingenieurstudium in Stockholm (Schweden)

Berufliche
Tatigkeit: Grunder des ersten Education-Centers Europa. European Marke-
ting Director Education Sciences Ltd., Dusseldorf. Director der
Poly-Media GmbH, Hamburg. Geschaftsfuhrer der NETG Applied
Learning GmbH, willich. SAP-R/3-Berater bei PLOENZKE AG.

345
Stichwortverzeichnis

Stichwortverzeichnis

Batch-Queue 161
A Batch-Verarbeitung 203
Batchverfahren 7
ABAP-Funktionen 185
Baukastensti.icklisten 263
ABAP/4 12; 201; 232
BDCDATA 204
Ablauforganisation 111
Benutzeradministrator 92
Abwicklungsebene 5
Benutzerkreis 97
Adaptions-Monitoring 76
Benutzerstamm 89
Adaptionsverfahren 56
Berechtigungen 105
Adaptionswerkzeuge 57
Berechtigungs-Einzelprofile 88
Adhoc Workflow 133
Berechtigungsadministrator 93
administrative Basissysteme 10
Berechtigungselemente 89
Anderungsbelege 207
Berechtigungsfeld 84
Aquipollenzen 21
Berechtigungsobjekt 85
aggregierender Beziehungstyp 22
Berechtigungsprofil 88
Akquisitionsgesprach 5
Beschreibungsebenen 17
Aktivierungsadministrator 93
Beschreibungssicht 17
Aktivversion 91
betriebswirtschaftliche Informa-
ALF-Format 153
tionssysteme 75
ALWAYS-Liste 67
betriebswirtschaftliche Lbsungen 68
Analysephase (IA) 73
betriebswirtschaftliche Objekte 207
Anforderungsprofil 321
betriebswirtschaftliche Profile 69
Anwendungsintegration 119
Beziehungstypen 21
Arbeitsorganisation 109
Biirokommunikationsprodukte 7
Arbeitsstil 109
Building Blocks 7
Architektur integrierter Infor-
Business Process Redesign 2; 8; 9; 11
mationssysteme 17
Business Process Re-
ARIS-Architektur 19; 25
engineering 15; 103
Artikelcodierung 287
Business Reengineering 15; 152
Aufbauorganisation 111
Ausbildungskosten 337
Ausbildungsma~nahmen
Autonomes Lemen
320
307
c
Call-Transaction 182
CAPISCE Module 214
B CAPISCE-Funktionen 232
CASE-Struktur 137
Background-Transaktionen 5; 8
CASE-Technologie 10
Barcode 159
CBT-Programme 299; 323
Barcodeerkennung 161
CBT-Systeme 310
Barcodenummer 160
CD-ROM 323
Basic-Dialekte 184
Chargenproduktion 216
Basisberechtigungen 95
Chargenprotokolle 231
Basischarakteristikum 16
CHICO-Verfahren 64
Basisfunktionalitat 11
CI-Dokumente l73
Batch-Input-Mappe 182; 202
CI-Format 154

346
 Stichwortverzeichnis

Client- Server Architektur 54; 116; 283 Electronic Mail 166

COMET 46 Elementarfunktionen 19
Computer Based Training 299; 323 Entitaten 18
Computer Integrated Processing 218 Entity-Relationship-Modellierung 18
Computer Output on Laser Disk 118 Entitytypen 21
Computer Supported Telephony Entwicklungswerkzeuge 11
Application 178 Ereignis 139
Container 138 ereignisgesteuerte ProzeB-
Continuous Systemengineering 44 kette 20; 26; 122
COPICS 194 Ereignisse 26
CPI-C 283 Erfassungsszenarien 157
Customer Focus 108 Erfassungstransaktion 160
customer specific function modules182 ERM 18; 21
Customizing 31; 36; 210 Eskalation 140
Customizing-Fahigkeiten 11 Evaluationsphase 113
Customizingdiskussion 72

F
D
Fachkonzept 17
DASS-Leitstandsentwicklung 232 FEFCO-Standarddesign 259
Data Dictionary 84 Follow-Up- Workshops 330
Datenbankverwaltung 169 Frontends 178
Datenintegritat 178 Friihes Erfassen 129; 158
Datenmodell 16; 18; 77 Fiihrungsstrukturen 281
Datensicht 19 Funktions-Zuordnungs-Diagramm 27
Desktop-Integration 177 Funktionsdekompositions-
Detaillierungsniveau 39 diagramme 18; 24
Dezentralisierung 54 Funktionsmodell 77
DICE 191 Funktionsmodellierung 18
Didaktik 297
Dispositive Variante 264
DLL-Aufrufe 184 G
DLL-Dateien 185
Ganttdarstellung 232
DLL-Funktionen 188
Geschaftsprozesse
Dokumentationsfunktion 20
5; 16; 102; 136; 178; 278; 316
Dokumentenart 117
GeschaftsprozeBmodellierung 74
Dokumentenmanagement-
GeschaftsprozeBoptimierung 320
systeme 103; 118
Geschaftsstrategie 4
Dokumentenverwaltungssystem 152
Geschaftsvorfall 7
DV-Unterstiitzungsgrad 15
Geschaftsvorfallsmodellierung 11
Dynamic Data Exchange 8
Geschaftsvorgange 102
dynamische Generierung 265
Gestaltungsaufgabe 16
Dynpro 202
glasemer Mitarbeiter 109
Gleichzeitiges Erfassen 162
E
EDI Electronic Data Inter- H
change 104; 135; 279
Hauptprozesse 24
EDI-Nachrichten 104
hierarchischer Beziehungstyp 22
EDIFACT 104
Homonymen 21
Einfuhrungsleitfaden 98

347
Stichwortverzeichnis

HR-Organisationsmodell 137 Lemkontrolle 310

Host-Kommunikation 211 Lemmethode 324; 331
Liege- und Transportzeiten 107
LIM-Systeme 218
I LIMS 230
Links to Business Systems 218
Implementation 9
LIVE AG 70
Implementationsansatz 11
LIVE KIT 63
Implementierungsdetail 11
Live-Training 322; 326
ImplementierungsprozeB 10
Logistikplanungsprozesse 216
lndividualentwicklungen 54
LUckenanalyse 80
InformationsfluBsicht 27
Informationssystem 4; 10; 54
Integrations-Strategie 7 M
Integrationsprozesse 318; 328
Integrationsstrategie 318 Mainframe-Architektur 196
Intelligent Character Recognition 8 Makro-Prozesse 5
Inventory Management 218 Management Commitment 3
ISO 9000-Normreihe 3 mediengestiitztes Lemen 329
1st-Geschaftsprozesse 271 Medium & Workshop"-Konzept 325
Mcngenstiicklisten 264
Mcngenvariante 264
J Middleware 190
Migrations- und Einfuhrungs-
Jukebox 173
werkzeuge 52
Mikro-Prozesse 5
K Mikroverfilmung 168
Mittelstandsfahigkeit 44; 61
Kampagnenplanung 226 modellbasierte Integration 20
KANBAN 52 Modelldatenbank 28
Kann-Variante 264 Modellierung 7
Kapazitatsmanagementfunktionen 220 Modellierung von Geschafts-
Kardinalitaten 22 prozessen 105; 110
Kick-Off-Workshops 330 Modifikationen 11
Koexistenzschnittstelle 59 Monitoring 228
konditional-referentieller Bezic- moving 31; 32
hungstyp 23 MRP II-System 234
Konfigurationsphase 31 Multimedia 312
Konsolidierung 285 MultiMedia Teach Line 299
Konstruktionsphase (IC) 73 Multimedia-CBT-Programme 302; 305
KontrollfluBelemente 136 Multimedia-Technologie 55
Kosten-Nutzen-Analyse 272 MultiUser-Anwendungen 180
Kostenreduktion 107 MuB-Variante 264
Kostenvergleich 334; 336

N
L
Nachrichtensteuerung 135; 143
Laufzeitverhalten 106 Namenskonvention 96
Leistungscbene 5 NAMUR 221
Lemen durch Anwendung 324 Native-SQL 181
Lemerfolg 324 NCI-Dokumente 154
NCI-Format 154

348
 Stichwortverzeichnis

NFS-Zugriff 172 Projektaufbauorganisation 270

Non Coded Information 131 ProjektlenkungsausschuB 271
Notizeditor 128 Projektmanagement 36
Projektmanagementprinzipien 12
PROMET®BPR 3
0 PROMET®SSW 4
prototypische Implementierungen 217
Objekt-ID 207
ProzeB 16
Objektbezogenheit 16
ProzeB Redesign 112
objektorientierte Werkzeuge 10
ProzeB Reengineering 112
objektorientierter Ansatz 137; 143
ProzeB-Prototyping 11
Objekttypen 21
ProzeB-Reifeschema 3
OCCURS-K1ausel 204
ProzeB-Reifeskala 3
ODBC 181
ProzeBabwicklung 8
ODYSSEUS-Methode 44; 61
ProzeBauftrag 225; 228
Office-Komponente 123
ProzeBauswahlmatrizen 24; 29
Offline-Applikationen 178
ProzeBautomation 216
OLE-Schnittstelle 233
ProzeBcontrolling 39
Online-Dokumentation 39
ProzeBdatenanforderung 224
Optimierung 44
ProzeBdokumentation 39
optische Archivierung 110
ProzeBentwicklung 10
optische Platten 168
ProzeBimplementation 12
Organigramme 19
ProzeBindustrie 214
Organisationsmodell 78
ProzeBkette 3; 5; 6; 27
Organisationssicht 19; 25
ProzeBkunde 5
organisatorisches Monitoring 39
ProzeBleitsysteme 229; 233
OTF-Format 153
ProzeBmanagement 226; 228
Outgoing Calls 178
ProzeBmeldungsformate 230
ProzeBmodell 16; 36
P ProzeBmodellierung 80
ProzeBmodellverfeinerungen 39
Paneuropaische Geschaftsprozesse 277 ProzeBmonitoring 31; 39
paneuropaischer Kommunikations- ProzeBoptimierung 319
und Informationsbedarf 277 prozeBorientierte Reorganisation 15
paneuropaisches Informations- ProzeBorientierung 12
system 281 ProzeBparameter 224
Papierloses Buro 104 ProzeBplanung 226
Parametrisierungsmoglichkeiten 9 ProzeBplanungsfunktionalitat 233
PDAS 234 ProzeBrealisierung und -anpassung 31
Performanceanforderungen 110 ProzeBsicht 17; 19
Petri-Netze 20 ProzeBvisualisierung 230
Pfiegeversion 91 ProzeBvorgaben 224
Pilotinstallation 214 PSK2000®-Terminus 265
PPP-Protokoll 179 PutLeveis 190
Preperation-Phase 72
Problemdekomposition 17
Process Change Management 31 R
Produktionsleitebene 217
R13-Analyzer 28; 76
Produktionsplanungsprozesse 216
R13-Analyzer-ProzeB 32
Produktionssteuerung 216; 226
R13-Archiv 154
Profilcheckliste 62
R13-Berechtigungskonzept 97
Projekt CAPISCE 214

349
Stichwortverzeichnis

R/3-Dokumente 152 Semantisches Netzwerk 6

R/3-Einfuhrungsleitfaden 67 Seminar 292
R/3-Modellfirma 72 SERM 18
R/3-0bjekte 152 SERM-Methode 21
R/3-Referenzmodelle 233 Short-Term Scheduler 234
Reaktionszeiten 108 Software-Engineering 2
Recipe Management 218 Software-System-Design 114
Redesign-Projekt 12 Softwarebibliotheken 58; 75
Reduktionscheckliste 66 Softwareerstellungszyklus 114
referentieller Beziehungstyp 23 SP88-Gremium 221
Referenzmodelle 17; 28 Spates Erfassen 158
refreezing 31; 32 SQL·ReportWriter 180
regionale Markte 4 SQL-Zugriff 180
Re isekostenvorerfassung 179 Standard Business Function Library181
Relationships 18 Standard-Berechtigungen 87
Remote Zugriffe 172 Standard-DLL 182
Remote-Function-Call 180; 181 Standardanwendungssoftware 9
Reorganisation 9; 15 Standardberechtigungsobjekte 97
Resource Management 218 Standardprofile 95
Ressourcenverwaltung 220 Starken-Schwachen-Analyse 271
Ressourcenzuordnung 225 Start-of-screen indicator 204
RFC 183 Statuskontrolle 140
RFC-Aufrufe 182 Strategic Production Information
RFC-Technologie 184 Environment 218
RISC 54 Strategieentwicklung 10
Roll-Out OR) 74 strategische/kritische Geschafts-
Rollen 138 prozesse 271
Routing 133 strategisches Geschaftsfeld 5
RPC-Protokoll 197 StrukturstUcklisten 263
Strukturvariante 264
Stufenkonzept 195
S Subworkflow 136
Superuser 94
Sammelaccounts 187
Synergiegewinne 7
SAP-Applikationsrautendiagramm 24
Szenarioprozesse 24
SAP-Business-Workflow 119
SAP-Dokumentart 130
SAP-Dokumente 151 T
SAP-GUI 171
SAP-Office 133 TCP/ IP-Protokollsoftware 179
SAP-R/3-Berechtigungskonzept 85 temporar-referentieller Beziehungs-
SAP-SERM 21 typ 24
Scannererfassung 171 TIFF-Format 153
Scheduling 218 Train the Trainer-Konzept 330
Schrittmethode 297 Transaktion 9; 120
Schulung 291 TransformationsprozeB 3
Schulungsbedarf 319
Schulungskurs 332
Schulungsumfang 292 U
Screen-Scrapping 8
Obertragungsvorgang 201
Segmente 4
unfreezing 31; 32
Selbststudium 292
UNIX 54

350
 Stichwortverzeichnis

UNIX-Shell-Script 200; 209

Unternehmensmodell 29 W
Unternehmensstrategie 4
WAN-Verbindung 179
Was-Ware-Wenn-Analyse 81
Wirtschaftlichkeit 44
Workflow 102
Workflow-Editor 139
V Workflow-Management-Coalition 142
Workflow-Management-Systeme 8; 115
Variantenkonfiguration 268 Workflow-Objekt 117; 129
Verkniipfungsoperatoren 26 Workgroup computing 103
Versionenkonzept 90; 100 Workitem-Manager 140
VertriebsprozeBmodell 81 Worklist 140
Vorgangsbeschreibung 37 WORM-Technik 231
Vorgangscode 209
Vorgangstyp 103
Vorgangstypendefinition 120
y
Vorgangsverarbeitung 102
Y-CIM-Modell 218
Vorgangsverarbeitungssystem 104
VULCAN-Projekt 73
Z
Zuordnungscheckliste 68
Zertifizierung 191

351
SAP, Arbeit,
Management
(AT)
Durch systematische Arbeits-
gestaltung zum Projekterfolg
von AFOS
1996. 228 Seiten. Kartoniert.
ISBN 3-528-05536-7
Uber die Autoren: Die Autoren stammen aus den
drei Instituten BIT e. v., FORBA e. V. und FORBIT
e. V., die sich fOr die DurchfOhrung des Projekts
"Gestaltungsm6glichkeiten integrierter Standard-
software aus arbeitsorientierter Sicht am Beispiel
der Softwareprodukte R/2 und R/3 von SAP" zu
der Projektgemeinschaft AFOS zusammenge-
schlossen haben. Das Projekt wurde vom Ministe-
rium fOr Arbeit, Gesundheit und Soziales der Lan-
desregierung Nordrhein-Westfalen gef6rdert.
Verlag Vieweg . Posnach 1546 .65005 Wiesbaden
--~--~~-----------------------------~.weg
Aus dem Inhalt: Besonderheiten der SAP-Prod uk-
te - Auswirkungen auf die Arbeitsorganisation -
Leitbilder der Arbeitsgestaltung - Technisch-or-
ganisatorische Ansatzpunkte der Arbeitsgestal-
tung - Gestaltung als Prozef3
Dieses Buch im praktischen Magazinformat infor-
miert Ober die technischen Besonderheiten der
SAP-Systeme und gibt Hinweise darauf, welche
Konsequenzen sich ergeben hinsichtlich der Or-
ganisation und Arbeitsgestaltung im Unterneh-
men. Es erliiutert die organisatorischen Auswir-
kungen von SAP-Software vor dem Hintergrund
der technischen Grundkonzepte. Dabei geht es
den Autoren urn eine bewuf3te Gestaltung auch
der sozialen Dimensionen der Systemanwendun-
gen, ausgehend von klar formulierten Leitbildern
der Arbeitsgestaltung. Ais Hilfe fOr die praktische
Umsetzung von Leitbildern stell en die Verfasser
unter dem Titel "Stellschrauben" die technischen
Ansatzpunkte der SAP-Systeme dar, die fOr ar-
beitsorientierte Technikgestaltung genutzt wer-
den k6nnen . BezOglich des EinfOhrungsprojekts
wird dargestellt, zu welchem Zeitpunkt, anliif3lich
welcher Arbeitsschritte im Vorgehensmodell und
durch welche Steil en oder Personen arbeitsorien-
tierte Inhalte sinnvoli eingebracht werden k6nnen.
Dabei wird auch ausfOhrlich auf die zu beachten-
den Vorschriften und Normen sowie auf die Betei-
ligung der Arbeitnehmervertretung eingegangen.
~
Praxis des
Workflow-
Managements
Grundlagen, Vorgehen,
Beispiele
von Hubert Qsterle und
Petra Vogler (Hrsg.)
1996. X, 362 Seiten. Gebunden.
ISBN 3-528-05532-4
Uber die Herausgeber: Prof. Dr. Hubert
6sterle ist gescMftsfOhrender Direktor
des Instituts fOr Wirtschaftsinformatik an
der Universitat St. Gallen und Partner der
IMG Information Management Gesellschaft.
Er lehrt und forscht im Bereich des Busi-
ness Engineering. Dr. Petra Vogler leitet
das Kompetenzzentrum "ProzeB- und Sy-
stemintegration" am Institut fOr Wirtschafts-
informatik und ist Dozentin an der Univer-
sitat St. Gallen.
__ ____ ________________________________
~ ~
Verlag Vieweg · Postlach 1546 · 65005 Wiesbaden
Aus dem Inhalt: Grundlagen - Von der
GescMftsstrategie Ober den GescMfts-
prozeB zum Informationssystem - Work-
flow-Modellierung - Vorgehensmodell zur
EinfOhrung von Workflow-Managementsy-
stemen - Workflow-Mangementsysteme
und Standard software - Benchmarking mit
Workflow-Managementsystemen - Evalua-
tion von Workflow-Managementsystemen
- Chancen und Risiken
Workflow-Management kann die Kosten,
die Durchlaufzeit und die Sicherheit von
Verwaltungsablaufen um GroBenordnun-
gen reduzieren. Voraussetzung ist aller-
dings, daB Workflowprojekte aile relevan-
ten Aspekte bearbeiten . Diese reichen von
der Spezifikation des Workflow Ober die
Auswahl von Workflow-Managementsyste-
men und die Integration von Legacy-
Systemen oder die Vorgehensweise bei
der EinfOhrung bis hin zum Management
der Workflow-AusfOhrung .
II
V1.~
Betriebswirt· Aus dem Inhalt: Eine betriebliche Standard-
16sung macht sich einen Namen - EinfOh-

schaftliche rung in Unternehmen und Produktpalette -

Customizing des R/3-Systems (BC) - Fi-

Anwendungen
nanzbuchhaltung (FI) - Anlagen buchhaltung
(AM) - Kostenrechnung & Controlling (CO)-
Materialwirtschaft und Einkauf (MM) - PPS
des Produktionsplanung und -steuerung (MM/
PP) - Materialstamm und Lagerverwaltung
integrierten (MM) - Verbrauchsgesteuerte Disposition
und Bestandsiuhrung (MM) - Absatz- und

Systems Produktionsplanung (MM)- Vertriebssystem

(SO).

SAP·R/3 Bei dem Buch handelt es sich um ein praxis-

von Paul Wenzel (Hrsg.)
1995. XlV, 644 Seiten mit
Diskette. Gebunden.
ISBN 3-528-05509-X
Ober den Herausgeber: Prof. Dr. Paul Wen-
zel ist Hochschullehrer fOr Wirtschaftsinior-
matik an der Fachhochschule Konstanz. Das
Buch wurde unter Einbeziehung mehrerer
Mitarbeiter entwickelt.
orientiertes Standardwerk zum Thema SAP-
R/3. Es bietet umfassend und ubersichtlich
kompetente Informationen zu nahezu allen
Bereichen betrieblicher Anwendung des er-
folgreichen Produktes aus der Walldorfer
Softwareschmiede. Die verschiedenen Mo-
dule des integrierten Systems werden je-
weils im Zusammenhang mit konkreten An-
wendungen und Projekterfahrungen vorge-
stellt. Es geht u. a. um Finanzbuchhaltung ,
Kostenrechnung und Controlling, Instand-
haltung, Qualitatsmanagement, Vertriebsin-
iormationssysteme, Business-Workflow und
Office Communication. Die Inhalte des Wer-
kes wurden an der FH Konstanz unter Lei-
tung von Prof. Wenzel entwickelt. Das Buch
ist das Ergebnis einer praxisorientierten Wirt-
schaftsinformatik.

Verlag Vieweg . Posnach 1546 .65005 Wiesbaden ~

--~----~-------------------------------~.weg