Andreas Gadatsch

Reinhard Mayr (Hrsg.)

Best-Practice mit SAp

 Aus dem Bereich IT erfolgreich nutzen
,---------------~----------------~----------------, ...
Kostenstellenrechnung
mitSAPR/3
von Franz Klenger
und Ellen Falk-Kalms
Produktionscontrolling mit
SAp-Systemen
von JUrgen Bauer
Controlling mit SAP R/3
von Gunther Friedl, Christian Hilz
und Burkhard Pedell
Die Praxis des E-Business
von Helmut Dohmann,
Gerhard Fuchs und Karim Khakzar
Geschiftsprozesse mit
Mobile Computing
von Detlef Hartmann
Datenschutz als
Wettbewerbsvorteil
von Helmut Baumler
und Albert von Mutius
Projektkompass eLogistik
von Caroline Prenn
und Paul van Marcke
Datenschutz beim
Online-Einkauf
von Alexander RoBnagel
Integriertes
Knowledge Management
von Rolf Franken
und Andreas Gadatsch
www.vieweg-it.de
CRM-Systeme mit EAI
von Matthias Meyer
Sales and Distribution with
SAp
von Gerhard Oberniedermaier
und Tamara Sell-Jander
Marketing-Kommunikation
im Internet
von Dirk Frosch-Wilke
und Christian Raith
Handbuch Web Mining im
Marketing
von Hajo Hippner,
Melanie Merzenich
und Klaus D. Wilde
Projekt- und Investitionscon-
trolling mit SAP R/3
von Stefan Roger, Niko Dragoudakis
und Frank Morelli
Hacker, Cracker, Datenriuber
Von Peter Klau
Die Praxis des Knowledge
Management
von Andreas Heck
Best-Practice mit SAp
von Andreas Gadatsch
und Reinhard Mayr
Andreas Gadatsch
Reinhard Mayr (Hrsg.)

Best-Practice mit SAp

Strategien, Technologien und Case Studies

aI
vleweg
Die Deutsche Bibliothek - CIP-Einheitsaufnahme
Ein Titeldatensatz fUr diese Publikation ist bei
Der Deutschen Bibliothek erhaltlich.

WINDOWS , EXCEL , NT sind eingetragene Warenzeichen der Microsoft Corporation.

ORACLE ist ein eingetragenes Warenzeichen der ORACLE Corporation.
ARIS ist ein eingetragenes Warenzeichen der IDS Scheer AG, Saarbrucken.
SAP , R/2 , R/3 , ABAP / 4 , SAP Business Workflow , SAP-EDI , SAPoffice , SAPmail ,
mySAP.com , IDES sind eingetragene Warenzeichen der SAP Aktiengesellschaft. Systeme,
Anwendungen, Produkte in der Datenverarbeitung, Neurottstr. 16, D- 69190 Walldorf. Die Heraus-
geber bedanken sich fUr die freundliche Genehmingung der SAP Aktiengesellschschaft, die ge-
nannten Warenzeichen im Rahmen des vorliegenden Titels zu verwenden. Die SAP AG ist jedoch
nicht Herausgeberin des vorliegenden Titels oder sonst dafur presserechtlich verantwortlich. Fur
aile Screen-Shots (Bildschirmmasken) dieses Buches gilt der Hinweis! Copyright SAP AG.

Aile Rechte vorbehalten

Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden, 2002
Softcover reprint of the hardcover 15t edition 2002
Der Vieweg Verlag ist ein Unternehmen der Fachverlagsgruppe BertelsmannSpringer.
www.vieweg-it.de

Das Werk einschlieBlich aller seiner Teile ist urheberrechtlich geschutzt. Jede
Verwertung auBerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung des Veri ages unzulassig und strafbar. Das gilt insbesondere fUr
Vervielfaltigungen, Obersetzungen, Mikroverfilmungen und die Einspeicherung
und Verarbeitung in elektronischen Systemen.

ISBN-13: 978-3-322-89040-5 e-ISBN-13: 978-3-322-89039-9

DOl: 10.10071978-3-322-89039-9
 Vorwort

Vorwort
Mittlerweile liegen in vielen Unternehmen unterschiedlicher
Branchen und GroBenordnungen Erfahrungen in der Einfiihrung
und im Einsatz der betriebswirtschaftlichen Standardanwen-
dungssoftware SAP R/ 3 vor. Fur viele SAP-Kunden steht daher
die Frage der Nutzungsintensivierung des SAP-Systems und die
Einfiihrung weiterer SAP-Produkte im Vordergrund der strategi-
schen Planungen.
Die Einfiihrung der betriebswirtschaftlichen SAP-Software erfor-
dert strategische Weitsicht, Erfahrung, Fingerspitzengefiihl und
manchmal auch etwas Geduld. Zu losen sind komplexe strategi-
sche, betriebswirtschaftliche, technische und vor allem organisa-
torische Fragestellungen. Die stan dig weiterentwickelten Techno-
logien erlauben die sichere Verarbeitung immer groBerer Daten-
mengen, wie es vor einigen Jahren nicht fur moglich gehalten
wurde. 1m Vordergrund stehen zur Zeit Technologien zur Reali-
sierung unternehmensubergreifender Geschaftsprozesse und mo-
derner Formen des Erlernens der Nutzung der komplexen SAP-
Software (E-Learning).
Teil I 1m ersten Teil des Buches werden grundlegende Einfuhrungsstra-
Strategien tegien und erfolgreiche Anwendungsbeispiele dargestel!t.
ANDREAS GADATSCH kategorisiert in seinem Beitrag "Einsatz be-
triebswirtschaftlicher Standardanwendungssoftware" die Vielfalt
betriebswirtschaftlicher Software und zeigt deren grundsatzliche
Architektur und Einsatzmoglichkeiten auf. In einem weiteren Bei-
trag beschreibt er "Strategien zur Einfiihrung und Implementie-
rung betriebswirtschaftlicher Standardanwendungssoftware" urn
denjenigen Unternehmen eine Hilfestellung zu geben, die noch
die Aufgabe einer Standardsoftwareeinfuhrung zu bewaltigen
haben. GroBunternehmen und Konzerne fiihren haufig an meh-
reren Stellen im Unternehmen SAP-Software ein oder entwickeln
vorhandene Losungen weiter. Hierbei treten eine Reihe von or-
ganisatorischen und technischen Fragestellungen auf, die zur
Nutzung der Potenziale der SAP-Software zu klaren sind. DETLEV
FRICK beschreibt in seinem Beitrag ein "Konzern-Vorgehens-
model! fur die Implementierung von SAP R/3" . Er gibt wertvol!e
Hilfen fur das Programm-Management von SAP-Projektportfolios,
die er aus praktischen Projekten ableiten konnte. ARNO KUHN
leigt in seinem Beitrag "Chancen und Risiken einer Konzernstra-

v
VotWort

tegie zum weltweiten Einsatz von SAP R/ 3" auf, wie der TOV
Rheinland/ Berlin-Brandenburg die KonzerneinfUhrung praktisch
bewaltigt hat.
Tei! II- Techno- 1m zweiten Teil des Buches werden technologische Konzepte
!ogien vorgestellt, die zum sicheren Betrieb und zur Realisierung zwi-
schenbetrieblicher Kommunikation erforderlich sind.
ULLRICH SVENSON und HUBERT ROBENS gehen in ihrem Beitrag
"VerfUgbarkeit und Oberwachung von "mission-cricical"-Syste-
men am Beispiel SAP R/3" auf die Frage ein, wie eine Rundum-
verfUgbarkeit wichtiger Systeme als Grundlage einer kundenori-
entierten Prozessunterstutzung sichergestellt werden kann. REIN-
HARD MAYR behandelt in diesem Kontext die Frage der "HTML-
basierten Kommunikation mit SAP/R3". ANDREAS GADATSCH be-
antwortet in se inem Beitrag "Workflow-Management mit SAP
R/ 3?!" die Frage, unter welchen Randbedingungen der Einsatz ei-
nes eigenstandigen Workflow-Management-Systems oder die
Nutzung der SAP-eigenen Workflowfunktione n sinnvoll ist.
Tei! III Case Stu- Der dritte Teil des Buchs stellt anhand von Fallbeispielen aus der
dies Praxis herstellerneutral und unabhangig die Erfahrungen fuhren-
der Anwender und erfahrener Beratungshauser VOL DIRK SCHREI-
BER UND WOLFGANG HOHNEL stellen die "Wissensbasierte EinfUh-
rung von SAP mit Knowledge-Maps" als interessante Alternative
zu gangigen Methoden und Werkzeugen VOL ANDREAS KRAFT UND
ANDREAS OBERBORSCH berichten tiber die EinfUhrung des BW-
Produktes zur Realisierung eines "Konzern-Einkaufs-Informa-
tions-Systems bei RWE ". ALEXANDER GOERKE geht der hochaktuel-
len Frage der automatisierten lernenden Rechnungsverarbeitung
in SAP mit SERdistiller nach o RALF THOMAS beschreibt seine Er-
fahrungen bei der "EinfUhrung des APO zur Untersttitzung des
Supply-Chain-Management". AnschlieBend werden zwei Beitrage
zur Klarung der Einsatzmbglichkeiten des E-Learning im Rahmen
der SAP-Ausbildung prasentiert. REINHARD MAYR stellt Erfahrun-
gen der FH Kbln im Rahmen der Lehre mit "CBT-Kursen in der
ABAP/ 4-Programmierung" VOL URSULA GRAF, ALBERT HESMER und
DIETER LDNEBACH stellen ihre Erfahrungen aus erfolgreichen Kun-
denprojekten zum Thema "e-Learning mit dem SAP - iTutor" VOL
WILHELM THYGS behandelt mit der "Instandhaltungsabwicklung
mit SAP und erganzender Software" ein klassisches technisch-
betriebswirtschaftliches Thema, das fUr viele Unternehmen rele-
vant ist. STEFAN MOLLEMANN zeigt die Einsatzperspektiven des
neuen SAP-Produktes fUr das Customer Relationship-Mana-
gement (SAP CRM 3.0) auf. Der Beitrag von DANIEL RAMISCH steHt

VI
 Vorwort

schlieBlich seine Erfahrungen in der "EinfUhrung von SAP BW in

der Prozessindustrie" zur VerfUgung.
Wir hoffen Ihnen mit diesen Beitragen aus der anwendungs-
orientierten Forschung und der Unternehmens- und Beratungs-
praxis einen praktischen Nutzen bieten zu k6nnen. Unser Dank
gilt den Autoren, ohne die dieses Buch nicht m6glich gewesen
ware und freuen uns auf Ihre konstruktive Kritik.

K61n und Niederkassel im Juli 2002

Andreas Gadatsch und Reinhard Mayr

VII
 Inhaltsverzeichnis

Inhaltsverzeichnis
Tell I Strategien
ANDREAS GADATSCH ...... .... .. .. .................... .. ............. .... ......... ... .. .. ... ... ... ....... .... .... .............. 3
Einsatz betriebswirtschaftlicher Standardanwendungssoftware

ANDREAS GADATSCH ................ .... ... ............ .. .. . ............ . ...... ....... .. ........... ..... ... ........... .... ... 15
Strategien zur Einfuhrung und Implementierung betriebswirtschaftlicher
Standardanwendungssoftware

DETLEV FRICK ........ ..... ............. .. .... .... .. ......... .. ....... ... .... . ..... ........ .. .............. .. .. .. ....... . .... .... 31
Ein Konzern-Vorgehensmodell fUr die Implementierung von SAP R/ 3

ARNO KUHN .. .......... .. .. ...... ............. . ............... ..... ......... .... ......... ........ ......... ...... ........... .. .. . 49
Chancen und Risiken einer Konzernstrategie zum weltweiten Einsatz von SAP R/3

Tell n Technologien
U LLRICH SVENSON UNO HUBERT ROBENS ........... ... ... ........ ..... ........... .... .......... ...... ... . ......... . 63
VerfUgbarkeit und Uberwachung von "mission-critical"-Systemen am
Beispiel SAP R/3

REINHARD MA yR ............. ... ... . ................... . .......... ... .. ......... ... .... .. .... ... ... ..... .... .. ........ ... .... .. 83
HTML-basierte Kommunikation mit SAP / R3

ANDREAS GADATSCH ................... .... .. ........... .. .. .. ....... ... ..... ....... ...... .......... ... .. .. .. ... ... .... ... ... 95
Workflow-Management mit SAP R/3?!

Tell III Case Studies

DIRK SCHREIBER UNO WOLFGANG HbHNEL. ... .. .... .......... . .......... .... .......... ... .. ............ .... ..... 109

Wissenskarten im ERP-Umfeld von kleinen und mittelstandischen Unternehmen

IX
Inhaltsverzeichnis

A NDREAS KRAFT UND ANDREAS OBERBORSCH .... ...... .... ... .. ... .... ...... .. ..... ...... ... ...... ...... . .... .. 123

Das Konzern-Einkaufs-Informations-System (KEIS) bei RWE

ALEXANDER GOERKE .............. .... ....... .. .... ....... .... ... ..... ... .. ........ .. ....... ... ... .. ... ... .. ....... ..... ... . 139

Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistille r

RALF THOMAS .. . ................. .... ........ ...... ........ .... .......... ... ............. .... .... ...... .... ...... .. ..... ... ... 161

EinfUhrung des APO zur Unterstiitzung des SCM

REINHARD MAyR .. ........ ... ...... . ....... .... .. .... .... ... . ..... ......... .. .. .. ..... .. .. ..... .. .. ... ... ..... ..... ..... ...... 173

CBT-Kurse in der ABAP/ 4-Programmierung?

URSULA GRAF, ALBERT HESMER UN D DIETE R LO NEBACH .... .... ....... .... ...... .... .. ... .. .... ............ 189

e-Learning mit dem SAP - iTuto r

WILH ELM THyGS ... ...... ... .... .. ........ .... ......... .... ......... .. . .. ....... ... ... .. ............. . .... .......... ..... ..... 215

Instandhaltungsabwicklung mit SAP und erganzender Software

STEFAN MOLLEMANN .... ... ... ...... .... .. . .... ....... .. ... .... ... .... .. ....... ... .. .. ... ........ ... . ............... ... .. ... 231

SAP CRM 3.0

DANIEL RAMISCH ......... ... . ... ..... ..... .... ... .... .. ... .... ........ . .. ............. ... .. .. .. .... ... .. ..... ... .. ....... .. ... 237

EinfUhrung von SAP BW in der Prozessindustrie

Autorenverzeichnis ..... .. .. ......... ... .... .... ...... ... ... .... .... ...... ....... ..... ..... .... ... ............ .. ..... .253
Gesamtliteraturverzeichnis ... ...... ... .... ..... .... .... .... .. .. ... ... .. .. ... .... .. .......... .... .. .... ... .... ... 271
Schlagwortverzeichnis ........ ... ....... .. ....... ... ....... ... .... .. .... .... ... .......... .... ... .. ..... ....... ... ... 275

x
 Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung 1: Softwarekategorien .... ..... .......... ... ... ........ .. .... ... ......... ..... ...... ......... ...... ....... 3
Abbildung 2: Merkmale Betriebswirtschaftlicher Standardsoftware ..... ............. .. ... ....... 5
Abbildung 3: Applikationsarchitektur des Informationszeitalters (HUBER ET AL. 1999).7
Abbildung 4: Applikationen und Funktionsbereiche (HUBER/ALT/OSTERLE 1999) ........ 8
Abbildung 5: Beispiel fOr die EAI-Anwendung ........ .. .............. ... ... .. ........... ...... ... .. .. .... 11
Abbildung 6: Referenzarchitektur fOr Standardsoftware .......... ...... ............. ....... .......... 12
Abbildung 7: Strategien zur Einfuhrung von Standardsoftware ..... .... .... .... ...... .. ......... 16
Abbildung 8: Big-Bang Vorgehensweise .. .... ... ....... .. ..... ......... .. .. ... ............... .. ..... ......... 16
Abbildung 9: Big-Bang Vor- und Nachteile ........... ... ...... ............ ..... .. ... ... ........... .......... 17
Abbildung 10: Roll-Out (Schritt 1) ..................... ...... .. ......................... .. ........................ 18
Abbildung 11: Roll-Out (Schritt 2) ........ .......... .......... .. .. ............. ....... ................ ..... ....... 18
Abbildung 12: Roll-Out Vor- und Nachteile ............ ........ .......... ........ ......... ........... ...... . 19
Abbildung 13: Schrittweise Funktionsorientierte Einfuhrung ................ .. .................... 20
Abbildung 14: Schrittweise Funktionsorientierte EinfUhrung ...... ........ .. .... ...... .. .......... 20
Abbildung 15: Schrittweise Prozessorientierte EinfUhrung ........ ...... .. ............ ............ .. 21
Abbildung 16: Schrittweise Prozessorientierte EinfUhrung ......................... .. .. .... .. ...... . 22
Abbildung 17: Gesamtbewertung (Strategisches Portfolio) ........ ....... .... .. .. .. .. .. ............ 23
Abbildung 18: Life-Cycle-Modell fUr Standardsoftware ................................................ 24
Abbildung 19: Einsatz von Referenzprozessmodellen .... .......... .......... ... .. ...... ...... ........ 28
Abbildung 20: Einsatzfelder fOr Referenzmodelle ........................ ........ ........................ 29
Abbildung 21: Informationsmanagement im Software-life-Cycle .. ........ ..................... 32
Abbildung 22: Dberblick uber Leistungsbeziehungen im Informationsmanagement 33
Abbildung 23: SAP-Landschaft der Deutschen Telekom ............................................. 34
Abbildung 24: Vorgehensmodell der Deutschen Telekom AG (VM BASIS) ............... 36
Abbildung 25 : VMBASIS Phasenkonzept.. .... ................ .............. ...... .................. ........ .. 37
Abbildung 26: ASAP Implementation Assistant ...... ........ ...... ........ ... ............ .............. ... 38
Abbildung 27: ASAP Question & Answer Database .... ... ...... .. ........ ...... ........................ 40

XI
Abbildungsverzeichnis

Abbildung 28: Global ASAP Roadmap ............. ..... .................. .... .... ...... ..... ...... .. ....... ... . 42
Abbildung 29: Vorgehensweise beim Konzern Roll Out.. .... ... ... ....... ......... .... .. ... ... ..... 43
Abbildung 30: Vorgehensweise bei der Entwicklung von VM SAP .... ..... .. ...... ... ..... ... 44
Abbildung 31: VM SAP Roadmap ......... ... ............. ... ........................ .. ... .. .......... ......... .... 46
Abbildung 32: Globales Netzwerk des TOV Rheinland/ Berlin-Brandenburg ...... ....... 50
Abbildung 33: Enterprise Application Integration : R/ 3 und Lotus Notes .. ... ....... ..... ... 55
Abbildung 34: Projekt "Weltweite R/3-Integration der eingesetzten R/ 3-
Eigenentwicklung fur die Zertifizierungs-Unterstutzung" ........ ........ ......... ... ... ..... 56
Abbildung 35: Beispiel mit Pramissen fur das Projekt "Weltweite R/ 3-Integration der
eingesetzten R/ 3-Eigenentwicklung fur die Zertifizierungs-Unterstutzung" ..... ... 57
Abbildung 36: Sicherung der Systemverfugbarkeit durch vier ineinander greifende
Strategien .... .. .. ...... ..... .... .... ... ...... ....... ... ..... ......... ... ....... ... ................ ....... .......... .... .. 68
Abbildung 37: Beispiel einer zu uberwachenden Systemlandschaft... ...... .... ......... ..... 70
Abbildung 38: Zu uberwachende Funktionen und Komponenten .. ..... .... ... .... ... ... .. ... 70
Abbildung 39: Oberflache des 3.X Alertmonitorings ( SAP AG) .. ......... .. ... ... .. ...... .. . 74
Abbildung 40: Oberflache des 4.X Alertmonitorings ( SAP AG) .......... .. .... ....... ..... .. 75
Abbildung 41 : Alertmonitoring-Menubaum ( SAP AG) .... ....... .. .. ... .. ........ .... .... .... ..... 76
Abbildung 42: Liste aller unerledigten Alerts ( SAP AG) .. ...... .... ...... ...... ...... ... ........ . 76
Abbildung 43: Architektur .. ......... ...... ... ........ ........... .......... .... .... ... .. ... .......... ........... ...... . 78
Abbildung 44: Funktionsweise GUI XT (Nangoy, 2001) .............. .. ...... .......... ....... .... .. 85
Abbildung 45: Methode ABAP/ HTML.. .. .... .......... ..... ....... .. .. ... .... ... ....... ... .... ... ..... .. ....... 88
Abbildung 46: Methode ]ava/HTML.. ... ....... ... ... ... ...... ..... ..... ..... ........ ... .... .... .... .... ... ..... . 90
Abbildung 47: Maske Prufmerkmale .... ..... ............ .. .. ..... .. ...... ........... ... ............ .. ... ...... .. 91
Abbildung 48: Graphische Werkerunterstutzung ..... .... .......... ... ................... .. ... .. .... .. .. . 91
Abbildung 49: Graphische Benutzeroberflache ... ... .... .. ...... .... .... ....... .. .... ... .. ....... .... ... .. 92
Abbildung 50: Anzeige der Bestellung .... .... .. ...... .. .... ... .. .... ... ....... ... ........... .. .... ... ......... 93
Abbildung 51: Einsatz eigenstandiger WFMS .. ...... ... ...... ......... .. .............. ............ ....... .. 96
Abbildung 52: Einsatz ERP-integrierter WFMS .. .. ... .... .... .... ...... .... .. .. ..... .. ....... ............ .. 97
Abbildung 53: Einsatz eigenstandiger WFMS .... .. ......... .... ...... .. ... ... ......... ... ....... ... .... .. 100
Abbildung 54: Beschaffung ohne Workflow-Unterstutzung ... .... .... .... ...... .... ........... .. 102
Abbildung 55: Business Workflow gestutzte Beschaffung .... ..... ............. ....... .. ........ .. 103
Abbildung 56: Portfolio .. .... .... ... .... ... ... ... .... .... ...... ...... ... ...... .. ........ ... .... .. .... .... ... .... .. .... 104

XII
 Abbildungsverzeichnis

Abbildung 57: Grundphasen des Wissensmanagements ........... .. ... .. .... ..................... 110
Abbildung 58: Aufbau einer "Master Knowledge Map" im SAP-Umfeld [TEUFEL991114
Abbildung 59: "Master Knowledge Map" zur Kundenauftragserfassung .............. .... 116
Abbildung 60: Menustruktur und Eingabemasken zum Prozessbaustein
Kundenauftragserfassung ......... ..... .. ............. .. ... ............... .. .. .. .. .. .. .. .......... ..... ..... .. 117
Abbildung 61: Einfaches Prozessmodell zum Prozessbaustein
Kundenauftragserfassung ....... .... ........................................................................ .. 118
Abbildung 62 Intranet-Seite zur "Master Knowledge Map" Kundenauftragserfassung
.... ... ....... .......... ... ...... .... .. ............. .. .. ............... .. ............... ...... ... ................... .. ... ..... 119
Abbildung 63: Marktposition RWE (aus: Kuhnt, 2002, Folie 8) .. ...................... ......... 124
Abbildung 64: Einkaufsrelevante Fragestellung ................ ......................................... 128
Abbildung 65: Modulares Basiskonzept KEIS ..................................... .... ............. ....... 129
Abbildung 66: Architektur SAP BW (aus: Mahr, 2001, Folie 10) ... ... .. ....... .... ..... ... .... 131
Abbildung 67: Funktionsiibersicht der Warengruppenumsetzungstabellen .... ... ... ... 134
Abbildung 68: Beispielauswertung aus KEIS .......................... .... ............ .... ......... ....... 135
Abbildung 69: Ablauf der Rechnungserkennung .. ... ..... .... ... ........ .... ...... ......... ........... 141
Abbildung 70: Daten lesen - Bearbeitungsbeispiel .. ............. .. ... .. .............................. 143
Abbildung 71: Direkte SAP Anbindung .................... ... .............. ... ..... ......................... 144
Abbildung 72: Nachbearbeitungsoberflache mit Feldern und Tabellen ........ ... ..... ... 146
Abbildung 73: Lieferantenerkennung in Kopf- und FuBzeile .... .. .. .. ... ...... ....... ....... .. . 147
Abbildung 74: Integration von SAP GUI und Verifier.. ................ .... ................. ......... 150
Abbildung 75: Beispiel fUr einen Teilbaum in der Validierung .... ..... ........................ 152
Abbildung 76: Lernprozess ...... .. ... ............ .. ................ ..... ................ .. .. .. ............... ... ... . 154
Abbildung 77: Beispiel fUr eine einfache Nachbearbeitungsobertlache ....... ....... .... . 157
Abbildung 78: Bedarfsfluss und Nachschub ............. ............. .... ............ .... ................. 163
Abbildung 79: Prozessuberblick: DP-Planungslauf ........ ... .. ....... ... ... ... ... .. ...... .... ..... .. . 164
Abbildung 80: Prozessuberblick: SNP-Planung .. .. ..... .. .. .... .. ................. .... ... .. .. .......... . 166
Abbildung 81: Monatsplanung SNP ...... ............... ......... ................. .... .... ..................... 166
Abbildung 82: Nachschubsteuerung .......................................... .. ...................... .. ....... 168
Abbildung 83: Systemubergreifender Nachschub .. .... ..... .. .. .. ...... .. .... .. ..... .. .... ...... .. .... 170
Abbildung 84: Screen video .................. ............. ... ..... ...... ............ .... ................ .. .... ..... .. 182
Abbildung 85: Seitenlayout CBT .... .... ..................... .. ............ .. .. .. .. ...... .. .. ...... .. ... .. ....... 183

XIII
Abbildungsverzeichnis

Abbildung 86: ML Consulting GmbH ... .... .... ........ .... ........ ............. ... .... .. .. .... ..... .... ... ... 189
Abbildung 87: Vorgesehene Schulungskonzeption .................................... ........ ........ 193
Abbildung 88: Annahmen tiber die Wirkung von Sinnesmodalitaten und
Lernaktivitaten auf das Behalten nach Weidenmann .. .. ............ .. ............... .. ...... 194
Abbildung 89: Auswahl einzelner Lektionen ....... .. ........................ ......... .... .. .............. 194
Abbildung 90: Login ........ ... ... ... .......... ...... .... .... ..... .... ............................... .. .. .... ......... .. 195
Abbildung 91: Aufbereitung in HTML-Format/ Flash-Format.. ...... .................... .... .. ... 195
Abbildung 92: Visualisierung von Sachverhalten ( SAP AG) .................................. 196
Abbildung 93: Fragestellung und LOsung ( SAP AG) ................... ........ .... ...... ......... 196
Abbildung 94: Gesamtergebnis des Tests ( SAP AG) ..... .......................... .... ..... ...... 197
Abbildung 95: Auswahl benbtigter Anwendungen ( SAP AG) .... .. ................. ...... .. 199
Abbildung 96 : iTutor Regiefenster ( SAP AG) ...... ...... ............. ... ......... ... ................. 201
Abbildung 97: Aufzeichnung ( SAP AG) ........ ... ... ........... .. ...... .... .... ............ ... .... .. .... 202
Abbildung 98: Aufgaben-Editor ( SAP AG) .. ........... ... .. .. .. ...... ....... .. .. .. ........... .. ........ 202
Abbildung 99: Reiter ( SAP AG) .............. .. ............... .......... .................... ....... ........... 203
Abbildung 100: Aufgaben und Schritte ( SAP AG) ........ ...... ........ ...... ................. ..... 203
Abbildung 101: Aufgaben-/Schrittbeschreibung ( SAP AG) ....... .......... ........... ..... ... 204
Abbildung 102: Schritt ( SAP AG) ............................................. ..... .. ... ................ ..... 204
Abbildung 103: Interaktionsfeld ( SAP AG) .... .. .. ............. .. .. ...... ..... ............ .... .... ..... 205
Abbildung 104: Blase ( SAP AG) ..... ... ............... .. ..................... .... ......................... .. . 206
Abbildung 105: Favoriten pflegen ( SAP AG) ...................... .. ....................... .. .. .. ..... 207
Abbildung 106: Link zum einen iTutor-Film ( SAP AG) .. ...... ...... ... .. ........... ........... 208
Abbildung 107: Funktionsleiste ( SAP AG) ... ....... .. .. .. ............ .. ..... ... ........................ 208
Abbildung 108: Fehlermeldung mit Korrekturvorschlag ( SAP AG) ....... .... ............ 209
Abbildung 109: Aufgaben- und Schrittbeschreibung ( SAP AG) ........... ........... .. .... 210
Abbildung 110: Startseite des e-Learning .... .......... ................ ........... .................. .. ...... . 212
Abbildung 111: Diskussionsforum ............... ..................... .. ..................... .. ...... ......... .. 213
Abbildung 112: Sachtleben Chemie ............ .... ............. .................... .................. ......... 216
Abbildung 113: Einsatz der EDV bei Sachtleben .... ....... ...................... ........... ....... ..... 218
Abbildung 114: Auftragsabwicklung SAP-PM, terminierte Wartungsauftrage ........... 219
Abbildung 115: Workflow basierte Materialdisposition .... .... .................................. ... 221

XIV
 A bbildungsverzeichnis

Abbildung 116: Stammsatzinfo / optimale Ablaufprognose ............ ... .. ... .. .......... .... .. 222
Abbildung 117: Auftragsabwicklung mit AVISOR . ........ ..... .. .. ...... .. ..... .... ...... .... ... .. .. .. 224
Abbildung 118: Informations-Richtlinie .... ... ........ ... .. ........... .... ........ .. ... ..... .. ...... ... .. .... 225
Abbildung 119: Stand heute der Anlagendokumentation / Dokumentenmanagement
...... ... ...... ......................... .... ... .......... ... ............. .... .... ............... .. ...... .. .. .. .......... .. .... 226
Abbildung 120: Objektsicht ... ...... .......... ..... ... ............ ...... .. ............... ..... ... ............. .. ... . 229
Abbildung 121 : dreistufiges SAP BW Konzept.. ...... ......... .... .... .... .... .... ... ...... .... ..... ... . 241
Abbildung 122: OLAP Prozess .... ..... ........ ...... .... ...................... ...... .... .... .. .. ... ... .... ........ 246
Abbildung 123: Funktionsleiste des BEx Analyzers (Makro) ...... .. ..... .. ... ................ ... 250

xv
 Tei! r Strategien

Tell I:

Strategien

1
 Andreas Gadatsch

Einsatz betriebswirtschaftlicher Standardanwendungssoftware

Andreas Gadatsch

1 Kategorien betrieblicher Informationssysteme

Software- Betriebswirtschaftliche Standardanwendungssoftware wird zu-
Begriffe nehmend als Gestaltungselement der Unternehmens- und Pro-
zessorganisation aufgefasst und eingesetzt. Der Begriff Software
liisst sich in Systemsoftware und Anwendungssoftware unterglie-
demo Zur Systemsoftware geharen insbesondere das Betriebssys-
tern und das Datenbankmanagementsystem.
Anwendungs- Anwendungssoftware wird schwerpunktmiiBig zur Lasung fachli-
software cher Aufgaben, wie z.B. der Finanzbuchhaltung oder der Ab-
wicklung der Korrespondenz eingesetzt. Sie kann vom Anwen-
der selbst entwickelt Ondividualsoftware) oder als Standardsoft-
ware gekauft und eingesetzt werden.

Software

Systemsoftware Anwendungssoftware

Betriebssystem Standardsoftware

Datenbanksystem
BetriebswirtschaftIiche
Standardsoftware

Technische
Standardsoftware

Individualsoftware

Abbildung 1: Softwarekategorien

3
Einsatz betriebswirtscha!tlicher Standardanwendungssoftware

2 Merkmale betriebswirtschaftlicher Standard software

Definition Betriebswirtschaftliche Standardsoftware wird fur den anonymen
Markt vorgefertigt und enthalt neben der Software im engeren
Sinne auch Zusatzleistungen wie Systemdokumentation, EinfUh-
rungsberatung, Anwenderschulung und Untersti.itzung bei der
Installation und Wartung des Systems. Daneben wird in der Re-
gel ein Update-Service fUr die stetige Weiterentwicklung und
Anpassung des Systems an die gesetzlichen Erfordernisse ange-
boten. Derzeit lasst sich die am Markt verfUgbare Standardan-
wendungssoftware grob in zwei Kategorien einteilen:
Komplettlosungen fur aile oder wenigstens die we-
sentlichen kaufmannischen Anwendungsgebiete eines
Unternehmens insbesondere die Bereiche Finanzen, Lo-
gistik, Personal, Fertigung, Vertrieb),
Einzelne Anwendungen fur ausgewahlte Teilaufgaben
(z.B. Personalabrechnung, Computer-Aided-Design, Ge-
schaftsprozessmodellierung, Supply-Chain-Management,
Customer Relationship Management).
Teilweise kann Standardsoftware bei entsprechenden Anwender-
kenntnissen unmittelbar nach dem Kauf und der Installation ein-
gesetzt werden. Dies ist z.B. bei Textverarbeitungsprogrammen
der Fall. Komplexere Anwendungen wie z.B. eine Produktions-
planung oder eine Vertriebsabwicklung bedurfen dagegen einer
planmaf$igen EinfUhrung mit umfangreichen Anpassungsarbeiten
an die Erfordernisse des Unternehmens.
Customizing Mit der Anschaffung einer betriebswirtschaftlichen Standardan-
wendungssoftware steht dem Unternehmen noch kein ablauffa-
higes Softwaresystem zur VerfUgung, da noch keine Anpassung
der Software an die Anforderungen des Unternehmens erfolgt ist.
Unter Customizing kbnnen aile Tatigkeiten verstanden werden,
die notwendig sind, urn eine Standardsoftware bei der Einfuh-
rung und im Rahmen der Wartung und Weiterentwicklung auf
die unternehmensspezifischen Anforderungen auszurichten (vgl.
BRINKMANN/ZEILINGER, 2000, S. 77). Das Ziel des Customizing be-
steht also darin, ein im jeweiligen Unternehmen ablauffahiges
Softwaresystem einzurichten, ohne den Softwarecode der Stan-
dardanwendungssoftware zu verandern. Customizing-Einstel-
lungen kbnnen in mehrere Kategorien unterteilt werden:
Technische Einstellungen (z.B. Berechtigungen der Be-
nutzer, Druckeradressen, FeldBingen, Maskenaufbau),

4
 Andreas Gadatsch

Grundlegende fachliche Einstellungen (z.B. Landesversi-

on, Sprache, Hauswahrung, Fabrikkalender, Nummern-
kreise fUr Stammdaten, Buchungsbelege, Vertriebsauftra-
ge u.a.m.),
Unternehmensorganisation (z.B. Unternehmen, Werke ,
Niederlassungen),
Struktur der Stammdaten (z.B. Materialstammdaten,
Kundenstammdaten),
Funktionalitat der zu unterstutzenden Geschaftsprozesse
(z.B. im Auftragsbearbeitung im Vertrieb, Planung von
Produktionsauftragen in der Fertigung, Gehaltsabrech-
nung im Personalwesen, Abschreibungsmethoden in der
Anlagenbuchhaltung) ,
Berichtswesen (z.B. Layout von Kostenstellenberichten
im Controlling),
Schnittstellen (z.B. Datenstruktur einer Lagerbestandsda-
tenbank, deren Daten aus einem Altsystem in die Stan-
dardanwendungssoftware ubernommen werden sollen).
Das Customizing wird mit speziellen Softwarewerkzeugen
durchgefUhrt, die Bestandteil der Standardsoftware sind und sehr
komplex sein kbnnen. Das System SAP R/ 3 verfugt beispielswei-
se tiber ein Werkzeug, dass etwa 2.500 Fragen enthalt, mit deren
Beantwortung der Anwender die Software an seine individuellen
Belange anpasst (vgl. THOME , R., 1999, S. 572). Hierbei wird die
Software nicht modifiziert, d. h. der Softwarecode verandert,
sondern an die Anforderungen des Kunden angepasst. Die
Merkmale betriebswirtschaftlicher Standardanwendungssoftware
sind in Abbildung 2 zusammengestellt.
Vorgefertigte Software fur den anonymen Markt
Funktionsumfang fUr grbfSeren Anwenderkreis geeignet
Individuelle Anpassung erfolgt ohne Programmierung
(Customizing, Parametrisierung)
Auswahl benbtigter Komponenten durch modularen Auf-
bau oder Menustrukturen
Offene Architektur unter Verwendung tiblicher Standards
Einbindung anderer Software i. d. R. mbglich
Abbildung 2: Merkmale Betriebswirtschaftlicher Standardsoftware

5
Einsatz betriebswirtscha!tlicher Standardanwendungssoftware

3 Informationssystem-Architekturen
Die Bedeutung von Informationssystem-Architekturen (auch als
General-Bebauungsplan bezeichnet) wurden schon relativ fruh
erkannt (vgl. z.B. den Beitrag von KRCMAR, H., 1990) und sind im
Hinblick auf die Implementierung von Standardsoftware, wie et-
wa dem SAP-R!3-System von hoher Bedeutung.
Eine leistungsfahige Computerunterstutzung ist mittlerweile als
Schlusselfaktor fUr den Erfolg eines Unternehmens anerkannt.
Oblicherweise setzen mittlere und groBe Unternehmen Hard-
und Softwarekomponenten unterschiedlicher Hersteller ein und
kombinieren auch selbst entwickelte Software mit Fremdbe-
schaffter Standardsoftware (z.B. ERP-Systeme). Diese Vorge-
hensweise erfordert eine sinnvolle und ab einer bestimmte Un-
ternehmensgraBe auch Computerunterstlitzte Planung einer Ge-
samtarchitektur, damit die Bausteine zu einem sinnvollen Gebil-
de zusammengefasst werden kannen. Andernfalls drohen bei der
Integration von Anwendungen unterschiedlicher Hersteller Inter-
aktionsprobleme der beteiligten Softwarekomponenten, da die
zu unterstutzenden Geschaftsprozesse sich nicht an Software-
grenzen halten und durchgangig unterstutzt werden mussen.
Wesentliche Aufgaben, die in diesem Zusammenhang zu lasen
sind, seien hier kurz skizziert:
Entwicklung einer Unternehmensweiten Informationssys-
tem-Architektur (Sollarchitektur), der Auskunft uber vor-
handene und geplante Anwendungen und deren Schnitt-
stellen eines Unternehmens gibt,
Entwicklung und Umsetzung eines General-Bebauungs-
planes im Sinnes eines Masterplanes und Leitfaden fUr
die Entwicklungs- und Standardsoftware-EinfUhrungs-
projekte,
Steuerung der Entwicklungs- und Standardsoftwareein-
fuhrungsprojekte im Hinblick auf die Einhaltung der
Sollarchitektur.
Die Anforderungen an eine Unternehmensarchitektur betreffen
die Flexibilitat im Hinblick auf die Einbindung beJiebiger Kom-
ponenten, den Einsatz von Hard- und Software- sowie organisa-
torischen Standards, urn Softwarebausteine unterschiedlicher
Hersteller zu kombinieren, Hardwarebausteine verschiedener An-
bieter zu koppeln und das reibungslose organisatorische Zu-
sammenspiel aller Beteiligten sicherzustellen und die operative

6
 Andreas Gadatsch

ToolunterstUtzung zum Management der eingebundenen An-

wendungen.
Beispiel einer Ein Beispiel fUr eine herstellerneutrale und generell einsetzbare
herstellerneutra- Geschaftsarchitektur haben HUBER, T.; ALT, R.; OSTERLE, H. (999)
len Geschdftsar- vorgestellt. Sie gehen hierbei von einem Paradigmenwechsel von
chitektur der Industriegesellschaft hin zur Informationsgesellschaft aus , der
sich auch in veranderten Anforderungen an eine derartige Archi-
tektur niederschlagt. Wesentliche Merkmale der Informationsge-
sellschaft sind z.B. flache und vernetzte Organisationsstrukturen,
Bereichsubergreifende Ablaufoptimierungen und parallel ablau-
fende Prozesse sowie einen ganzheitliche, d . h. mit moglichst
wenigen Bearbeiterwechseln auskommende Sachbearbeitung.
Das Architekturkonzept (vgl. HUBER, T.; ALT, R.; OSTERLE, H .,
1999, S. 46) ist in Abbildung 3 in etwas abgewandelter Form dar-
gestellt.

U nternehmens-Standards

EIS Executive Information System

KM Knowledge-Management

APS (SCM) SFA

Advanced Planning Electronjc
ales Force
Systems (Supply Chain Commerce Automation
Management)

DW Data Warehou e

Master Data Management

Abbildung 3: Applikationsarchitektur des Informationszeitalters

(H UBER ET AL. 1999)

Aufbauend auf Standards, die yom Unternehmen fUr Geschafts-

prozesse und Daten zu erarbeiten und vorzugeben sind, werden
Architekturkomponenten zur Prozessunterstutzung definiert.
Die Architekturkomponenten decken durch unterschiedliche Ap-
plikationen verschiedene Funktionsbereiche des Unternehmens

7
Einsatz betriebswirtscha!tlicher Standardanwendungssoftware

abo Sie sind in Abbildung 4 dargestellt Cvgl. HUBER, T.; ALT, R.;
OSTERLE, H., 1999, S. 47)

Applikationen c(])
c c
(])
o
E
(])
Ol
ctI
~a.
C a.
ctI
~

Abbildung 4: Applikationen und Funktionsbereiche (H u-

BER/ ALTI OSTERLE 1999)

ERP-Systeme ERP-Systeme bilden den Kern der Architektur, da sie fur die
wesentliche innerbetrieblichen Geschaftsprozesse eines Unter-
nehmens unterstutzend eingesetzt werden kbnnen.
Data Data Warehouse-Applikationen dienen der Bereitstellung kon-
Warehouse- sistenter Informationen fUr das Management, die aus unterschied-
Applikationen lichen Applikationen stammen.

8
 Andreas Gadatsch

Advanced Planning- and Scheduling-Applikationen dienen

APS-
der Planung von Produktionsprozessen und der Bereitstellung
Applikationen
der erforderlichen Materialien uber die gesamte Beschaffungsket-
te hinweg.
Electronic Electronic Commerce Applikationen unterstutzen die Ge-
Commerce Ap- schaftsprozesse mit Geschiiftspartner uber das Medium Internet
plikationen und bieten neue Formen der Interaktion mit dem Kunden (z.B.
Internet-Shops, elektronische Marktpliitze).
Sales Force Au- Sales Force Automation Applikationen werden auch als
tomation Appli- Customer Relationship Management Applikationen bezeichnet.
kationen Sie unterstutzen das ganzheitliche Computeruntersti.itzte Mana-
gement der Kundenbeziehungen. Hierunter fallen insbesondere
Softwaresysteme fUr die Marketing und Verkaufsunterstutzung.
Knowledge- Applikationen fUr das Knowledge-Management dienen Ziel-
Management gruppenorientierten der Gewinnung, Speicherung und Verteilung
Applikationen von Wissen. Hierzu ziihlen im weitesten Sinne auch Workflow-
Management-Systeme, da sie Information uber Prozesswissen (als
Workflow-Modelle) enthalten und fur die Ausfuhrung sowie uber
Analysekomponenten fur detaillierte Einzelanalysen bereitstellen.
Executive In- Executive Information Systeme dienen der Unterstutzung der
formation Sys- Planungs- und Kontrollprozesse des Managements. Sie bauen auf
teme Data Warehouse Applikationen auf und nutzen deren Datenbasis
fur Analysen.
Master Data Das Master Data Management dient der Standardisierung von
Management Daten im Unternehmen. Beispiele fur zu standardisierende Daten
sind Stammdaten wie Kunden- oder Produktdaten, da diese im
Regelfall in mehreren Applikationen erfasst, geandert oder fUr In-
formationszwecke benbtigt werden. Aufgabe der Standardisie-
rung ist es, die Unternehmensweit bedeutsamen Daten zu defi-
nieren, fur einzelne Sichten (z.B . Vertriebssicht der Kundendaten,
Buchhaltungssicht der Kundendaten) die jeweils verantwortli-
chen Organisationseinheiten zu identifizieren und ihnen die
Kompetenz und Werkzeuge fur die Verwaltung der Strukturen
und Inhalte zu ubertragen.
Beispiel Ohne ein unternehmensweites Master Data Management entste-
Deutsche Tele- hen ungewollte Redundanzen. Neben groBen Konzernen wie
komAG z.B. Henkel (vgl. HUBER, T.; ALT, R.; OSTERLE, H., 1999, S. 48)
fUhrte z.B. die Deutsche Telekom als Anbieter und Nachfrager
von IT-Dienstleistungen weitreichende Projekte zum Datenma-
nagement durch Cvgl. FLEISCH ET AL, 1998, S. 100). Ein Beispiel fur
eine unternehmensspezifische Geschiiftsarchitektur ist die Infor-

9
Einsatz betriebswirtscha!tlicher Standardanwendungssoftware

mationssystemarchitektur der Deutschen Telekom (vgl. FLEISCH ET

AL., 1998). Ausgehend von der Geschaftsstrategie des Unterneh-
mens wurde mit Hilfe der Methode Promet eBN eine Geschafts-
architektur entwickelt. Inhalte des Ansatzes sind mehrere Bau-
steine, die unterschiedliche Aspekte der Telekom-Architektur be-
schreiben und insbesondere die Anforderungen der eingesetzten
SAP-Software berucksichtigen (vgl. FLEISCH ET AL, 1998, S. 97 t}
SAP-Organisationsmodell (regelt die zentralen Einstel-
lungen im SAP-Organisationsmodell, die von allen Pro-
jekten beim Customizing berucksichtigt werden mussen)
SAP-Konzernkern (Pre-Customizing, d.h. zentrale Vor-
einstellungen des Customizing fUr aile Konzerneinheiten,
die uber das Organisationsmodell hinausgehen)
Migrationsplanung (SAP-Masterplan des Konzerns, regelt
z.B. die ubergreifende Release-Strategie fUr Upgrades)
Datenmanagement (Kerninformationsobjekte, d. h. Da-
tenobjekte mit Konzernweiter Relevanz)
Ohne auf diese Elemente detailliert einzugehen, seien an dieser
Stelle einige wichtige Fragen aufgefUhrt, die durch die Beschrei-
bung der Elemente beantwortet werden.
Wie werden generelle und konzernweit relevante orga-
nisatorische Anforderungen def Telekom in das Custo-
mizing der SAP-Software umgesetzt, so dass diese abge-
deckt werden (z.B. Abbildung der Tochtergesellschaften
in Buchungskreisen, Geschaftsbereichen usw.)?
Wie kbnnen gemeinsame Einstellungen in den SAP-
Systemen des Konzerns identifiziert, uberschneidungsfrei
dezentral entwickelt und fortgeschrieben werden?
Wie kann eine langfristige Migrationsplanung der Ist-
Architektur in Richtung der Soll-Architektur gemalS Ge-
schaftsarchitektur erfolgen?
Wo ist bei der Auspragung des Customizing Koordinati-
onsbedarf zwischen Projektteams, wo sind Freiraume,
die ausgefUllt werden kbnnen?
EAI=Enterprise Die Integration unterschiedlicher im Unternehmen bereits vO[-
Application In- handener selbst entwickelten Softwarekomponenten und Stan-
tegration dardsoftwareprodukten von unterschiedlichen Herstellern wird in
den letzten Jahren auch verstarkt unter dem Kurzel EAI (Enter-
prise Application Integration) diskutiert.

10
 Andreas Gadatsch

Der Begriff EAI wurde von der Gartner Group gepragt (vgl. POH-
LAND, S. , 2000, S. 40). Mittlerweile bieten einige Anbieter entspre-
chende Softwarewerkzeuge an, die der Middleware zuzuordnen
sind. Die Werkzeuge bieten standardisierte Schnittstellen zu vie-
len marktgangigen Standardsoftwarepaketen (wie z.B. SAP R/3)
und Entwicklungsumgebungen und erlauben so eine technische
Integration unterschiedlicher Softwarebausteine.
Beispiel Ein Beispiel fUr eine EAI-Anwendung ist in Abbildung 5 darge-
stellt. Es zeigt das automatisierte Zusammenspiel mehrerer Soft-
warebausteinen, die insgesamt einen Geschaftsprozess der Auf-
tragsbearbeitung abbilden (vgl. WINKELER, ET AL., 2001, s. 12).

Bonittit - Auftrags- Auftrags-

Priifllng Bearbeitung bestliligllng
(Forte) (C++) (Java)

EAI

Allftrags- Rechnungs-
cingang wesen
(HTML) (SAP)

Abbildung 5: Beispiel fur die EAI-Anwendung

4 Referenzarchitektur fur betriebliche Standardsoftware

1m folgenden wird eine herstellerneutrale Referenzarchitektur
vorgestellt, in welche auch die in diesem Sammelband vorgestell-
ten Produkte der SAP AG eingeordnet werden kbnnen. Den
Kern der Architektur bilden Business-Anwendungen mit den be-
triebswirtschaftlichen Komponenten fUr das Enterprise-Resource-
Planning, Supply-Chain-Management, Customer-Relationship-
Management sowie das Funktionsubergreifende Workflow-Mana-
gement. Hinzu kommt eine Komponente fUr das Data-
Warehousing, welche die Bereitstellung von Informationen zur
Aufgabe hat. Diese Komponenten stellen betriebswirtschaftliche

11
Einsatz betriebswirtscha!tlicher Standardanwendungssoftware

Grundfunktionen fur die inner- und zwischenbetriebliche Pro-

zessunterstlitzung und die Datenanalyse bereit. ERP, SCM und
CRM-Systeme unterstutzen jeweils spezifische Prozessfelder,
wahrend das Workflow-Management Komponentenubergreifen-
de Prozesse unterstutzt. Business-Anwendungen werden erganzt
durch Komponenten fUr arbeitsplatzneutrale Buro-Anwendungen
(z.B. Textverarbeitung, Tabellenkalkulation) sowie Kom-
munikations-Anwendungen zur Sicherstellung der Arbeitsplatz-
ubergreifenden Kommunikation (z.B. E-Mail, Elektronische Ka-
lender). Die bisher vorgestellten Architekturkomponenten wer-
den eingerahmt durch eine Electronic-Commerce-Komponente,
die Anwendungen fUr den Elektronischen Handel (MarktpIatze),
elektronische Beschaffung (E-Procurement) und Vertrieb (E-
Shops) sowie Portale zur Informationsverteilung. Die Electronic-
Commerce-Komponente stellt die Integration der ubrigen Kom-
ponenten mit dem Internet sicher.

Elektronische Marktpliitze (Marketplaces)

I BuslnessAnwendungen I
Data-Warehouse und Analyse-Tools

Supply-Chain- Enterprise Resource Customer Relations-

Management Planning bip Management

Workflow-Management

Texlvcrarbeilung Indiv. Dalcnhahung E-Mail Archiv

Tabellenkalkulation Gralik Teler.. www

Prliscnlmion Kalcnder

Btiro.Anwendungen KommunikatlonsAnwendungen

Portale
ElectronicCommerceAnwendungen

Abbildung 6: Referenzarchitektur fUr Standardsoftware

12
 Andreas Gadatsch

6 Literatur
Brinkmann, S.; Zeilinger, A.: Finanzwesen mit SAP Rl3, Be-
triebswirtschajtliches Customizingwissen jur SAP Rl3-FI,
Bonn, 2000.
FLEISCH, E.; POHLAND, S. ; SCHELHAS, K.-H; OSTERLE, H: Entwick-
lung einer Injormationssystemarchitektur. In: HMD Praxis der
Wirtschajtsinjormatik, Heft 202, 1998,5. 85-101.
Gadatsch, A.: Management von Geschdjtsprozessen, Braun-
schweig/Wiesbaden, 2. Aufl., 2002.
HUBER, T.; An; R.; OSTERLE, H. Die Applikationsarchitektur des In-
jormationszeitalters, Arbeitsbericht BE HSKG / CCiBN / 09, U-
niversitdt St. Gallen, 26. Mai 1999, St. Gallen, 1999.
KRCklAR, H : Bedeutung und Ziele von Informationssystem-
Architekturen. In: Wirtschajtsinjormatik, 32. Jg ., Heft 5, 1990,
S.395-402.
POHLAND, 5.: Globale Unternehmensarchitekturen, Methode zur
Verteilung von Injormationssystemen. Berlin, 2000, zugl. Diss,
Univ. St. Gallen .
THOME, R.: Werkzeuge zur Adaption individueller Injormations-
systeme aus Standard-Anwendungssoftware. In: WISU, Hejt 4,
1999, S.568-578.
WINKELER, T.; RAUPACH, E., WESTPHAL, L.: Enterprise Application In-
tegration als Pflicht vor der Business Kur. In: Injormation
Management & Consulting, 16 .Jg., Heft 1, 2001, S. 7-16.

13
 Andreas Gadatsch

Strategien zur EinfOhrung und Implementierung betriebswirtschaft-

licher Standardanwendungssottware

Andreas Gadatsch

1 EinfOhrung
Die Einfuhrung einer betriebswirtschaftlichen Standardanwen-
dungssoftware wie z.B. SAP R/ 3 ist eine langfristig wirkende In-
vestition, die sorgfaltig vorbereitet und durchgefUhrt werden
muss. Generell gibt es zwei grundlegende Vorgehensweisen: Die
"Big-Bang-Strategie" und die "Sukzessiv-Strategie".
Big-Bang Die Big-Bang-Strategie kann auf das Gesamtunternehmen oder
oder bei dezentralen Organisationsformen sukzessive nach der Festle-
Sukzessiv- gung eines Mastersystems, fur dezentrale Einheiten (z.B. Lander
Strategie? oder regionale Niederlassungen) als so genannter Roll-Out
durchgefUhrt werden.
Bei der Sukzessiv-Strategie sind Kriterien fUr die Definition der
Schrittfolge zu definieren. Dblicherweise unterscheidet man die
Abteilungsbezogene bzw. Funktionsorientierte UmsteliUng und
die Marktorientierte bzw. Prozessbezogene Umstellung des Sys-
tems. In Abbildung 7 sind die Grundstrategien einschlieBlich
weiterer Differenzierungen dargestellt.

15
Strategien zur Einfuhrung und Implementierung betriebswirtschaftlicher ...

[ Big-Bang-Strategien I
Big-Bang

oVolisUindigc Ablosung des

I
AIt~yslcms zum Stichtag
oFunktions- odcr Abtcilu ngsweise
Ablosung de ' Ah y tem '
oBei piel: Ablo ung der Material-
wirt.chart durch SAP R/3)
RollOut
(Iokaler Big Bang)
oUntcrnehmcn mit dczentra lcr
I
Organisalion cntwickcln zuniichsl
cill zcntralc Mastcrsystcm
oAll>ch lieBcnd erfolgt cill Roil-OUI
sukzessiv als lokalcr Big-Bang
ukzes . ive Ablo5ung durch Umstel-
lung voll;tandiger Prozesskctlen
oBebpiel: Erst AblOsung der Ersatz-
gc,chtifts. dann eugeschtifl fUr
Ge charl~- bzw. Pri v3lkunden

I I
Schritlwei e funktions- Schrittweise proze s-
orientierte Einfiihrung orientierte Einftihrung

~ Sukzessiv-Strategien :

Abbildung 7: Strategien zur Einfilhrung von Standardsoftware

2 Big Bang
Unter einem Big-Bang ist in diesem Zusammenhang die voll-
standige Ablosung eines Altsystems durch ein neues Standard-
softwaresystem zum Stich tag zu verstehen.
Mit der Aktivierung des neuen Systems wird die "Alt-Welt" voll-
standig abgeschaltet. Die Vorgehensweise der Big-Bang-Strategie
ist in Abbildung 8 dargestellt.

Ausgangssituation I Migrationsergebnis I

Venrieb

:::.c:2~ .... Venrieb

Abbildung 8: Big-Bang Vorgehensweise

Die Big-Bang-Strategie ist eine theoretisch optimale Lasung, da

keinerlei Schnittstellenprobleme auftreten und von Beginn an ei-
ne integrierte Softwarelosung zur Verfilgung steht. Es fallen auch

16
 Andreas Gadatsch

keine Ubergangsprobleme mit Doppelarbeiten im Alt- und Neu-

system an und es besteht auch keine Gefahr von Dateninkon-
sistenzen, da strikt nach Alten Daten vor dem Stichtag und Neu-
en Daten nach dem Stich tag unterschieden werden kann.
Nachteile Der schwerwiegendste Nachteil dieses Vorgehens ist das extrem
Big-Bang hohe Projektrisiko, bei Totalausfall des neuen Systems die Un-
ternehmung in Ihrer Existenz gefahrdet sein kann . Beispiele aus
der Praxis zeigen, das dies durchaus auftreten kann. Urn die Pro-
jektrisiken uberhaupt in den Griff zu bekommen, sind umfang-
reiche Tests und Ruckfall-Szenarien notwendig.
Hohe Anjorde- Ein Big-Bang stellt sehr hohe Anforderungen an das Projektma-
rnngen an nagement und fordert einen konzentrierten Einsatz der Personal-
Projektmana- ressourcen CFach- und IT-Abteilung und meist auch der externen
gement Berater) innerhalb eines sehr eng definierten Zeitrahmens.

Vorteile
Thcorcl;sch oplimalc USsung
Keine Schnitl\lcllenprobl eml'uiL.
-Keine Gcfahr von Inkon!O:jiilcn1.en
(" late Trennung : Alte D:uenl euc Dillen)
Keinc Doppcl.rbeilen. d. kcine Obcrgong,phllSC
Intc:griene System bei SYlOtel'llMrut \-erfUgbat
achteile
' <Xlrem !lobe, ProJc~lri'iko durth hOOe Prujc~c
komple,i'oc (Gefnhr dcs Toe.luu,full,)
' sehr hoot Anfonlerungen an d. ?rajeklmonogemenc
crforden umfangrciche Tc Is und Rikkrallstmtcgicn
maximalc Re..\SOUrccnbcln\tung durch glcichlCiligc
EinbinduTlg alter Bereiche (FA und ITl

Abbildung 9: Big-Bang Vor- und Nachteile

Praxis beispiel
BEISPIEL: ERFOLGREICHE BIG-BANG-EINFOHRUNG

Ein Beispiel fOr eine erfolgreiche Big Bang-EinfOhrung ist in FRANK ET

Al. (1997) zu finden, welche die EinfOhrung von SAP R/3 im Ge-
schaftsgebiet "Automatisierungstechnik" der Siemens AG beschreiben.
Die GrOnde fOr die vom Unternehmen als riskante unternehmerische
Entscheidung erachtete Big-Bang-EinfOhrung lagen im zu hohen Zeit-
bedarf fOr die Alternative einer Funktionsorientierten EinfOhrung (Zeit-
bedarf 4 Jahre anstelle von 14 Monaten). Ein weiterer Aspekt war die
damit verbundene schnellere VerfOgbarkeit des gebundenen Perso-
nals. Da man sich in diesem Praxisbeispiel der bevorstehenden Risi-
ken sehr bewusst wahr, wurden umfangreiche SicherungsmaBnahmen
zur Risikoreduzierung eingeleitet (z.B. Lasttests).

17
Strategien zur Einfuhrung und Implementierung betriebswirtschaftlicher ...

3 RolIOut
Urn die Nachteile einer Big-Bang-Lbsung abzumildern besteht bei
Unternehmen mit dezentraler Organisation (z.B. regionalen Nie-
derlassungen, Standorte in mehreren Landern) die M6glichkeit,
zunachst ein Mastersystem zu definieren (vgl. Abbildung 10) und
es dann sukzessive auszurollen, d .h. auf die regionalen Einheiten
zu verteilen, dort ggf. noch anzupassen und es dann produktiv
einzusetzen (vgl. Abbildung 11).

I I

e. 0
Ausgangssituation Mastersystem

nBu PCl""'ooal

l.og" "k PPS VCnricb .

Abbildung 10: Roll-Out (Schritt 1)

Meistens wird an den lokalen Standorten dann ein lokaler Big-

Bang durchgefUhrt.

1. Roll-Out I 2. Roll-Out I

~O

__7
0
? -?
~ ~ ~
(~ ":j
~
"
~
~~~ ~~~

Abbildung 11: Roll-Out (Schritt 2)

Geringere Pro- Die Verfolgung einer Roll-Out-Strategie fUhrt deutlich geringere

jektrisiken Projektrisiken nach sich, da die Erfahrungen der ersten Projekte
fur Folgeprojekte genutzt werden k6nnen und bei Problemen

18
 Andreas Gadatsch

nur Teile des Unternehmens (z.B. eine Niederlassung) betroffen

sind. Der Ressourceneinsatz kann zudem zeitlich deutlich ent-
zerrt werden .
Roll-Out nicht Nachteilig sind zunachst die erforderlichen Voraussetzungen, die
immer m6glich diesen Losungsansatz nicht in jedem Anwendungsfall erlauben.
Notwendig sind eine dezentrale Organisation mit einem uber-
schaubaren Komplexitatsgrad. Sind die lokalen Organisationen
so groB, dass auch hier kein lokaler Big-Bang durchgefiihrt wer-
den kann, so muss auf die Sukzessiv-Strategie ausgewichen wer-
den. Weitere Nachteile sind darin zu sehen , das erst nach Ab-
schluss des gesamten Roll-Outs, der sich je nach GroBe des Un-
ternehmens uber Jahre hinziehen kann , ein integriertes System
zur Verfiigung steht.

Vorteile Nachteile
-geri llgcrc\ Projcklrisiko al belm globalel1 Big Bang nur bci dczenlnder Orgnni i.lltol'll'l'l~gli(:h!
Erfahrungen der Pilotprojel:te L.6nnen genUll.t y.,trden norden umfafl!ireiche KoordiniJlion
leilli~h entuntcr Re~\Ourccnejn~l1. - inlc:gricnes S),Mem erM nath At&.hlu6 Roll-Out
Mn<Ci'~I''iY''lemgute Au...,gang~b. " I " rur Foigeproje:kte oVerdichlUngen rur 7..cnlrale Ausy.enungen notlkcndig
-crfoolen hohc MA Mobililiil (RolIQuITeam"

Abbildung 12: Roll-Out Vor- und Nachteile

4 Schrittweise Funktionsorientierte EinfOhrung

Haufig wird in der Praxis die Schrittfolge nach funktionalen oder
Abteilungsbezogenen Kriterien durchgefuhrt. Begriffe wie "Buch-
haltungssystem", "Lagerverwaltungssystem" oder "Vertriebs-
system" durften vielen Mitarbeitern aus eigener Praxis bekannt
sein . Die Begriffe stammen aus der funktionalen Arbeitsteilung
und dokumentieren die dahinter stehende Idee von Funktions-
unterstutzenden IV-Systemen. Zudem bieten noch viele Herstel-
ler von ERP-Systemen Funktionsorientierte Lizenzen an, d. h. die
Kosten steigen bei Inanspruchnahme von funktionalen Bestand-
teilen der Produkte. Nicht genutzte Funktionen fuhren zu keinen
Kosten.
Funktionsorien- Die Funktionsorientierte schrittweise Vorgehensweise lost suk-
tierte schrittwei- zessive einzelne Funktionsblocke aus dem Altsystem durch die
se Vorgehens- neue ERP-Software ab und verbindet die beiden "Welten" Dber-
weise gangsweise durch Schnittstellen.

19
Strategien zur Einjuhrung und Implementierung betriebswirtschajtlicher ...

Au gnngssituution I I. l\ligrationsschritt I 2.l\ligrotionssehritt

Abbildung 13: Schrittweise Funktionsorientierte EinfUhrung

Kurze Einzel- Vorteilhaft gegenuber Big-Bang-Strategien ist die kurzere Einzel-

projekt-Laufzeit projektlaufzeit, da das Gesamtprojekt in mehrere unabhangige
Teilprojekte zerlegt werden kann. Die Einzelprojekte sind einfa-
cher zu handhaben, damit sinkt das Gesamtprojektrisiko.
Auf der anderen Seite der Bilanz stehen im wesentlichen
Nachteile, die durch das Schnittstellenproblem induziert werden.
Der Aufwand fUr die Implementierung der Schnittstellen ist e-
norm. Fur die Dbergangszeit, die durchaus mehrere Jahre betra-
gen kann, steht kein integriertes Gesamtsystem zur VerfUgung.
Dort, wo keine Schnittstellen implementiert werden (kbnnen),
entsteht ein hoher manueller Aufwand durch die betroffenen
Mitarbeiter. Zudem besteht die Gefahr von Inkonsistenzen durch
Daten-Redundanzen, da die "Alt-Welt" und das neue ERP-System
mit Daten versorgt werden mussen.

Vorteile
-gerioge Pl'ojeklnor,iko
"ObeN:hauhare und ..managbare" Einl..elprojeklC
Re\\ourrenein\ftl/ l.tillirh enl/..tM gemiiB Pmjeklpl3n
Konlinuicrli he Beln umg der MlIurbcilCr (FA + In
Erfnhrungcn der Teilprojekle k6nnen ge nuI71 ~erden
Nachteile
-crhcblicher Au(wand flIr temporflre. chniHstcllen
Manucllc:r Aufwand wO kcinc Schniuli;ltl1en 'o'omandcn
Doppol.rtleiten durc:h MA in d r Obe'llnngsph.sc
-GerMr "on tnkon,i'ilenJcn durch DatcnRedundanlcn
Kein integrienes S)'~lem wfihrend der bcrgan~ph~

Abbildung 14: Schrittweise Funktionsorientierte EinfUhrung

5 Schrittweise Prozessorientierte EinfOhrung

Die Prozessorientierung hat sich seit den 1990er Jahren als Para-
digma der Unternehmensgestaltung durchgesetzt und in vielen
Unternehmen etabliert.
Alternativ zur traditionellen funktionalen Vorgehensweise zur
EinfUhrung von Standardsoftware bietet sich daher eine diesem
Paradigma folgende Strategie an. Die einzelnen Schritte der Mi-

20
 Andreas Gadatsch

gration werden hierbei nach Marktorientierten Gesichtspunkten

vorgenommen. D. h. es werden einzelne Prozessketten vollstan-
dig aus dem Altsystem herausgelbst und sofort durchgangig
durch das neue ERP-System unterstlitzt. Meist stellt man zunachst
die Primarprozesse sukzessiv urn und plant die Querschnittpro-
zesse (Rechnungswesen/ Personal) en block am Anfang oder En-
de des Projektes.
Voraussetzung Voraussetzung fUr eine derartige Vorgehensweise ist, dass sich
die Einzelprozesse auch organisatorisch herauslbsen lassen mus-
sen und getrennt betrieben werden kbnnen.

....
Au gangssituation 1. Migrations-Schritt 2. Migrations-Schritt

~ I'ro"ess I l'rOlC I
(z. B. G""chiifl.

- ..
~ (z. B. Gcschiifls
kunden) kundcn)
C ::. Prozess 2
~
til
;>,
:.- (7.. B. Prival-
kundcn)
til

:;;: : Prozess 3 I'rozcss 3

(7.. B. Versand
rrOlCSS
(z.
3
B. Versand
~ B. Vcrsand-
(7..
handcl) handel) handcl)

Prozess I
(2. B. GcschiiflS-
kundcn)
Pmzes. 2 PrOle," 2
(t. B. Prival- (z. B. Privm-
kllndcn) kunden)

Abbildung 15 : Schrittweise Prozessorientierte Einfuhrung

Grundsatzlich gelten bei dieser Vorgehensweise die gleichen

Vorteile, wie bei der Funktionsorientierte EinfUhrung von Stan-
dardsoftware. Allerdings ist das Projektrisiko wesentlich geringer,
da die Teilprozesse autark sind und die Reihenfolge der Einzel-
projekte nach dem Risiko fUr das Unternehmen gesteuert werden
kbnnen. So kbnnen z.B. zunachst weniger kritische Prozesse
umgestellt werden. Spater kbnnen , wenn Erfahrungen vorliegen
und die Projektmannschaft "fit" ist, andere Prozesse nachgezogen
werden. So bietet es sich im Regelfall an, erst das Ersatzgeschaft
und danach das Neugeschaft umzustellen. Hierdurch ist gewahr-
leistet, das Erfahrung nicht mit dem Kerngeschaft, dem Verkauf
neuer Produkte, sondern mit dem Nachgelagerten Ersatzteilge-
schaft gesammelt werden kbnnen.

21
Strategien zur EinJuhrung und Implementierung betriebswirtschajtlicher ...

Auch der Aufwand fur die ProjektdurchfUhrung ist geringer, da

AuJwand Jur
wegen der durchgangigen Prozessunterstutzung weniger Schnitt-
die DurchJuh-
stellen zu versorgen sind. 1m Regelfall tauchen noch Schnittstel-
rung
len zu Querschnittsprozessen wie Rechnungswesen und Personal
und evtl. gemeinsam genutzte Stammdaten (z.B. Materialstamm,
Kundenstamm) auf. Zudem sind die Schnittstellen fUr die Dauer
der Systemumstellung konstanter, als bei der Funktionsorientier-
ten Umstellung.
Grundsatzlich gelten die Nachteile der Funktionsorientierten Um-
stellung. Daruber hinaus sind keine weitere negativen Aspekte
zu verzeichnen, allenfalls sind gewisse Redundanzen bei der
Stammdatenhaltung hinzunehmen.

Vorteile achteile
- wie rl.ll1l..tiOll ' rielnicne Einfil hrung. 1..u~;l1t1Jich : wie runltiomorientiene Einfilhrung
ogeringeres Proje~lriM\r..O da Teilprnzcssc 3ut:ul.. :sind -ggf. Redundanzcll in dcr Stmnmdmcnhaltung
'/un5th,ll6nnen unLrili...che Prolc,~ dutthg~ng.ig um
gc u:lh werden (I. , B. cr.-I ~"17- . dann NeugeM:"h!1ft)
' gcringcrer Aufwrl11<1 filr Schnill'iilellen. da i. d. R.
nur Quc~chm ltsprol.cso;;e und Slamffidalcn bcuurrcn

Abbildung 16: Schrittweise Prozessorientierte EinfUhrung

Gesamt- Das strategische Portfolio in Abbildung 17 ordnet die vorgestell-

bewertung ten Handlungsalternativen nach den besonders wichtigen Ent-
scheidungskriterien "Projektrisiko" und "Aufwand" in eine Portfo-
lio-Darstellung ein. Hierbei wird der Aufwand fur die Realisie-
rung und Demontage der Schnittstellen in den Vordergrund ge-
stellt, da er das wesentlichste Unterscheidungsmerkmal darstellt.
Werden die wesentlichen Aspekte gegenuberstellt, so sprechen
fUr das sukzessive Prozessorientierte Vorgehen viele Vorteile, a-
ber kaum fUr die Existenz des Unternehmens nennenswerte
Nachteile. Grundsatzlich ist jedoch eine Fallbezogene Prufung
der Entscheidungsgrundlage erforderlich, da die vielfaltigen Vor-
aussetzungen zu erfUllen sind und auch exogene Entscheidungs-
parameter, wie z.B. Zeitdruck, unternehmenspolitische Vorgaben
u. a. m. zu berucksichtigen sind.

22
 Andreas Gadatsch

Big-
Bang

Projekll'isikO Roll-
out
chrill\\'.
Fu nklion
chrilh,. oricnticrl

I Prates,
orie"ti..t

($chnillSlellen-)Aufwand I
Abbildung 17: Gesamtbewertung CStrategisches Portfolio)

6 Life-Cycle-Modell zur StandardsoftwareeinfOhrung

Phasenmodel1e bzw. Life-Cycle-Model1e werden bereits seit lan-
gerem fUr die Steuerung komplexer Entwicklungsvorhaben ein-
gesetzt. Auch die Einfiihrung von betriebswirtschaftlicher Stan-
dardanwendungssoftware lasst sich als Life-Cycle-Model1 darste1-
len Cvgl. Abbildung 18). Die drei Teilzyklen Fachkonzept, Reali-
sierung sowie EinfUhrung und Betrieb bilden einen mehrfach
vernetzten Kreislauf, der ausgehend von einem Abgleich der Ge-
schaftsprozesse mit der Unternehmensstrategie bis hin zur opera-
tiven Nutzung des Softwaresystems fiihrt. Nach einem kurzen
Dberblick iiber den Standardanwendungssoftware-Life-Cycle er-
folgt eine detaillierte Behandlung der einzelnen Teilzyklen.

23
N
..".. ~
~
~~.
;::
~
'"!
b,

~
;::,
> <::i-
v ~
g
0:: ~
c ;::
::l Betrieb und ~ .~ ;::
ao ~w artung Geschaftsprozess ~
.......
00
t"'""
analyse t?
S (
~
n ChUl~g Abnahme ~ Geschafts- tt>
'< ;::
n
I....
(D r Geschaftsprozess stra~egie- ~.
~ IntelITationstest ) modellierung entwlcklung
o ~
0-
~
~ ~
~ Einzeltest ~ :::I.
..,2? ( \ Referenzprozess tt>
(f) ~
EJ 3. Einfiihrung modellbasierte ~
::l Entwicklung von ~.
0- und Betrieb Sollkon Vi
..,I'>' C')

0- Schnittstellen <::i-
[JJ
o undAdd Ons ~
~
~ ;:;.
~ <::i-
..,I'>' " ' -Customi i n g / 1. Fachkonzept tt>
(1) '"!
der Sollprozesse

2. Realisierung
 Andreas Gadatsch

Der erste Zyklus umfasst den Abgleich der Ist-Geschaftsprozesse

1. Teilzyklus:
mit den Vorgaben aus der Geschaftsstrategie. Eine Entscheidung
Fachkonzept
fUr den Einsatz von Standardanwendungssoftware erfordert im
Regelfall eine Ausrichtung der Unternehmensstrategie an den
M6glichkeiten der zum Einsatz kommenden Standardsoftware.
Somit bestehen erhebliche Wechselwirkungen zwischen der Un-
ternehmensstrategie und den fachlich-technischen M6glichkeiten
der zum Einsatz kommenden Standardsoftware. Die Auswahlent-
scheidung der Standardsoftware ist daher diesem Life-Cycle-
Modell vorgelagert und im Rahmen einer Einsatzuntersuchung
durchzufUhren.
Die Sollkonzeption der zukunftigen Geschaftsprozesse erfolgt auf
der Basis von Referenzprozessmodellen, die in der Regel durch
die Standardsoftwarehersteller bereitgestellt werden. Auf dieser
Grundlage werden die Sollgeschaftsprozesse modelliert und an-
schlielSend nochmals mit den Vorgaben der Unternehmensstrate-
gie verglichen. Die Firma SAP stellt beispielsweise ihre Referenz-
prozesse in Form von eEPK (erweiterte Ereignisgesteuerten Pro-
zessketten) zur VerfUgung.
Das Ergebnis des ersten Teilzyklus sind Sollprozesse, die auf den
M6glichkeiten der Standardanwendungssoftware aufbauen und
ggf. fachliche Vorgaben fUr die Nachgelagerte Entwicklung von
Add Ons, also Software zur Realisierung von Zusatzanforderun-
gen, Altdatentibernahme und Schnittstellen zu bereits eingesetz-
ten weiteren Informationssystemen .
2. Teilzyklus: 1m zweiten Teilzyklus, der Realisierung erfolgt zunachst ein um-
Realisieru ng fassendes "Customizing" der Standardanwendungssoftware. Dies
bedeutet, dass die zuvor modellierten Soll-Geschaftsprozesse ti-
ber Einstellungen in Form von Tabelleneintragen in der Stan-
dardsoftware verankert werden. Da meist zwischen den M6g-
lichkeiten der Geschaftsprozessgestaltung, welche die Standard-
software bietet und den Vorgaben der Sollprozessmodellierung
noch Lucken verbleiben, sind zusatzliche Softwarekomponenten,
so genannte Add Ons, auf Basis der Soll-Prozesse zu realisieren .
Diese Entwicklungsprojekte k6nnen grundsatzlich wie Individu-
alentwicklungsprojekte behandelt werden. Hinzu kommt die Re-
alisierung von Schnittstellen zwischen den sonstigen Datenlie-
fernden oder -empfangenden Informationssystemen des Unter-
nehmens. Den Abschluss des zweiten Teilzyklus bilden die zahl-
reichen Einzeltests der durch Customizing realisierten Standard-
Funktionen, der selbst entwickelten Add Ons sowie der Schnitt-
stellenprogramme. Ggf. leiten sich aus den Tests noch Dberarbei-

25
Strategien zur EinJuhrung und Implementierung betriebswirtschaJtlicher ...

tungen der Customizing-Einstellungen bzw. selbst entwickelten

Programme ab o
3. Teilzyklus: 1m dritten Teilzyklus erfolgt zunachst ein Integrationstest der be-
EinJuhrung und reitgestellten Komponenten. Insbesondere sind hier Bereichs-
Betrieb ubergreifende Geschaftsprozesse zu uberprlifen. Nach der Ab-
nahme des Systems sind ggf. noch (Teil-)Korrekturen der Custo-
mizing-Einstellungen bzw. Eigenentwicklungen vorzunehmen
oder Schulungen durchzufUhren. Die Schulung erfolgt auf der
Grundlage der Soli-Prozesse, d. h. aus dem meist yom Hersteller
bereitgestellten Standardschulungsmaterialien sind unterneh-
mensspezifische Schulungsdokumente zu erstellen. Nach erfolg-
ter Schulung und Aktivierung des Systems kann der produktive
Betrieb des Systems aufgenommen werden.
1m Betrieb auftretende Stbrungen, Erweiterungswunsche der
Anwender und yom Hersteller angebotene aktualisierte Soft-
wareversionen fUhren zur Wartung des Systems, d . h. zu einem
erneuten Durchlauf des gesamten Zyklus.

7 Einsatz von Referenzprozessmodellen

ReJerenzpro- Die EinfUhrung und Weiterentwicklung von Standardanwen-
zessmodellba- dungssoftware beinhaltet immer wiederkehrende Fragestellungen
siertes Sollkon- und Tatigkeiten, die in verschiedenen Unternehmen in gleicher
zeption oder sehr ahnlicher Form anzutreffen sind. Einige dieser Fragen
seien hier exemplarisch aufgefuhrt:
Welche Geschaftsprozesse unterstutzt die ausgewahlte
Standardanwendungssoftware?
Welche yom Unternehmen gewunschten Aufgaben wer-
den durch die Software abgedeckt?
Wie kann die Standardsoftware konfiguriert werden, urn
die Anforderungen des Unternehmens zu erfUlIen?
Neben dem Vorgehensmodell im Sinne einer "Arbeitsanleitung"
und Schrittfolge der durchzufuhrenden Tatigkeiten sind auch in-
haltliche Angaben uber den Funktionsumfang der Standardsoft-
ware erforderlich. Referenzmodelle beschreiben Erfahrungswis-
sen, welches im Rahmen der Sollkonzeption eines Informations-
systems als Grundlage fUr das Reengineering der Geschaftspro-
zesse dienen kbnnen. Sie kbnnen aus der Praxis aus bereits
durchgefUhrten EinfUhrungsprojekten (sog. Best Practice Cases)
oder auch aus theoretischen Oberlegungen heraus erstellt wer-
den Cvgl. SCHEER 1998b, S. 61).

26
 Andreas Gadatsch

Hersteller betrieblicher Standardanwendungssoftware stellen

i.d.R. zum tei! sehr umfangreiche und komplexe Referenzmodel-
Ie fur Ihre Produkte bereit, ggf. sogar nach Branchen und be-
trieblichen Einsatzbereichen differenziert.
Inhalte und Referenzmodelle beinhalten zumindest Geschaftsprozessmodelle
Zielsetzung von und zum Teil auch Funktions-, Daten und Organisationsmodelle.
ReJerenzmodel- Funktionsmodelle beschreiben in Form von Funktionsbaumen
len die durch das Standardanwendungssystem abgedeckte Funkti-
onshierarchie. Datenmodelle zeigen die fur die Ausfuhrung von
Geschaftsprozessen erforderlichen Informationen und Daten und
deren Abhangigkeiten meist in Form von Entity-Relationship-
Modellen. Organisationsmodelle beschreiben m6gliche Ausges-
taltungsformen der fur die Ausfuhrung der Geschaftsprozesse
aufzubauenden Unternehmensorganisation in Form von Organi-
grammen. Die Zielsetzung der Referenzmodelle besteht in der
Abbildung der betrieblichen Realitat in einer standardisierten und
fur Dritte nachvollziehbaren konsistenten Form (vgl. AICHELE ET
AL., 1994, s. 253),

Auf der Grundlage der Referenzmodelle , die als Ausgangsbasis

fur die Sollkonzeption dienen, werden unter Beachtung der un-
ternehmensspezifischen Belange die Fallbezogenen Sollge-
schaftsprozesse modelliert. Sie mussen anschlielSend mit den Zie-
len Unternehmensstrategie verglichen werden, bevor eine Um-
setzung erfolgen kann .

BEISPIEL SAP-REFERENZMODELLE

Die Firma SAP AG stellt beispielsweise ihre sehr umfangreichen Refe-

renzprozesse in Form von eEPK (erweiterte Ereignisgesteuerten Pro-
zessketten) so zur VerfOgung, dass der Kunden Ober verschiedene
Modellierungswerkzeuge hierauf zugreifen und diese an seine Belange
anpassen kann .

Die Abbi!dung 19 zeigt die Verwendung von Referenzprozess-

modellen im Rahmen des Customizing einer Standardanwen-
dungssoftware. Durch die Deaktivierung nicht ben6tigter Pro-
zessschritte oder die Erganzung zusatzlich erforderlicher Schritte
wird das Referenzmodell zu einem unternehmensspezifischen
Prozess umgestaltet.

27
Strategien zur Einfilhrung und Implementierung betriebswirtschaftlicher ...

Referenz- Unternehmens-
Prozessmodell spezifischer
Prozess
C> I

...
I C> I

0 ...
I

t
I
0 I

6~
Y
rO~

0
...
I
~o9 I
y
6--~o I
0
V
c:::J
Abbildung 19: Einsatz von Referenzprozessmodellen

Der Einsatz von Referenzprozessmodellen im Rahmen der Aus-

wahl und Implementierung von Standardanwendungssoftware ist
in der Praxis bereits etabliert (vgl. Abbildung 20) .
1m Rahmen der dem Life-Cycle vorgelagerten Softwareauswahl
k6nnen die von den Herstellern bereitgestellten Referenzmodelle
im Sinne ausfiihrlicher fachlicher Produktbeschreibungen ver-
wendet werden urn die unterschiedlichen Softwarel6sungen mit
einander zu vergleichen. Wahrend der Fachkonzeption dienen
die Referenzmodelle als Ausgangsbasis fur die Erstellung der
Sollprozesse. Wahrend der Realisierung des geplanten Systems
k6nnen die Referenzmodelle in Verbindung mit den Sollprozes-
sen als Grundlage fur das Customizing der Standardsoftware
eingesetzt werden. Die Einfuhrung und der Betrieb der Software
werden dadurch unterstutzt, dass Schulungsunterlagen und Be-
nutzerdokumentationen durch Referenzmodelle erganzt werden
k6nnen. Durch die gemeinsame Prozessbeschreibungssprache
wird die Kommunikation zwischen den Projektmitarbeitern und
Endbenutzern verbessert.

28
 Andreas Gadatsch

Life-Cyde- Einsatzbereich Nutzen

Phase
Vorstudie Strukturierter Her- Einheitliche Vergleichsba-
Software- steller- und Pro- sis
auswahl duktvei]Qeich
Fachkonzept Ausgangslosung fUr Zeitersparnis im Rahmen
die Sollkonzeption der Sollkonzeption und
Nutzung von Best-
Practise-Losun.s.en
Realisierung Fachliche Grundla- Durchgangiger Methoden-
ge fUr die System- einsatz ohne Reibungsver-
konfiguration luste zwischen den Pro-
CCustomizing) jektphasen
Einfuhrung Anwenderschulun- Zeitersparnis und gemein-
und Betrieb gen / Schulungs- same "Prozessbeschrei-
unterlagen bungssprache"
Abbildung 20: Einsatzfelder ftir Referenzmodelle

Kritik am Ein- Kritisch ist bei der Referenzmodellbasierten Vorgehensweise an-

satz von Refe- zumerken, dass das Unternehmen die Restrukturierung der Ge-
renzmodellen schaftsprozesse im wesentlichen an den M6glichkeiten der Stan-
dardanwendungssoftware ausrichtet und das Business Reengi-
neering geringere Freiheitsgrade umfasst, als dies bei EinfUhrung
von Individualsoftware der Fall ware. Die Qualitat der konzipier-
ten Sollgeschaftsprozesse und damit der zukunftigen Leistungs-
fahigkeit des Unternehmens hangt somit sehr stark von der Qua-
litat der zugrunde gelegten Referenzmodelle ab.

10 Literatur
AICHELE, Cli.; ELSNER, TH.; THEWES, K.-].: Optimierung von logistik-
prozessen aUf Basis von Referenzmodellen. In: M&C Manage-
ment & Computer, 2.jg., 1994, Heft 4, S. 253-258.
FRANK, A., SCHMIDT, TH., SCHRODEL, 0 .: Business Reengineering als
Wegbereiter einer eifolgreichen Standardsoftware-Einfuhrung.
In: HMD, Heft 198, November 1997, S. 41-50.
GADA TSCH, A.: Management von Geschdftsprozessen, Braun-
schweiglWiesbaden, 2. Aufl., 2002.
SCHEER, A.-W.: ARIS - Modellierungsmethoden, Meta m odelle, An-
wendungen, Berlin, et al., 3. Aufl., 1998a.

29
Strategien zur Einjuhrung und Implementierung betriebswirtschajtlicher ...

SCHEER, A.-W.: ARIS - Yom GeschaJtsprozejS zum Anwendungssys-

tern, 3. Aujl., Berlin et al., 1998b.

30
 Detlev Frick

Ein Konzern-Vorgehensmodell fur die Implementierung von SAP R/3

Detlev Frick

Abstract.
Der Artikel beschreibt das Konzern-Vorgehensmodell fUr die
Implementierung der ERP-Software SAP-R!3 der Deutschen Tele-
kom.

1 EinfOhrung
Phasen- bzw. Vorgehensmodelle werden im Software-Engi-
neering ublicherweise dazu eingesetzt, den Prozess eines Soft-
ware-Entwicklungsprojektes systematisch zu gliedern Cvgl. [5]'
S.17). Sie zerlegen hierzu das Entwicklungsziel eines Software-
projektes in weniger komplexe Phasenziele. Fur die EinfUhrung
von betriebswirtschaftlicher Standardsoftware, wie z. B. SAP R/ 3
wurden ebenfalls Vorgehensmodelle entwickelt. Die SAP AG hat
mit ihren Produkten ASAP (AcceleratedSAP) und Global ASAP
zwei toolbasierte Vorgehensmodelle fUr die EinfUhrung ihrer
Standardsoftware SAP R/ 3 vorgelegt. Sie sind Bestandteil des Life
Cycle-Ansatzes ValueSAP der SAP AG. Diese Vorgehensmodelle
entsprechen jedoch nicht vollstandig den Anforderungen interna-
tional agierender GroBanwender, wie der Deutschen Telekom,
da konzernspezifische Standards nicht erfUllt werden. Die Be-
sonderheiten einer groBen Anzahl von parallel entwickelnden
Projekte in unterschiedlichen Projektphasen werden auch nicht
abgebildet.
Beispiel Durch eine konzernspezifische Anpassung lassen sich jedoch
Deutsche Tele- diese Vorgehensmodelle auf die Belange eines GroBkonzerns
kom zuschneiden. Dieser Beitrag stellt die Anforderungen an ein der-
artiges Vorgehensmodell vor und zeigt die Umsetzung an hand
des Beispiels der Deutschen Telekom AG auf. Dort wurde ein
Vorgehensmodell fUr die Implementierung von SAP R/ 3 auf der

31
Ein Konzern- Vorgehensmodell fur die lmplementierung von SAP Rl3

Basis von ASAP, Global ASAP und den vorhandenen Konzern-

standards erstellt.

2 Informations- und SAP-Management bei der Deutschen

Telekom AG

2.1 Informationsmanagement
Das Informationsmanagement der Deutschen Telekom AG orien-
tiert sich an einem dreistufigen Prozessmodell der Softwarepla-
nung, Entwicklung und Betrieb. Fur die Hauptprozesse des In-
formationsmanagements, der
Strategie, Planung und Projektierung,
Entwicklung und EinfUhrung,
Produktion und Service
sind unter der FederfUhrung des Informationsmanagements ei-
genstandige Konzerneinheiten verantwortlich (vgl. Abbildung
21).

Strategie Entwicklung
Planung und und
Projektierung Einfuhrung Service

TRUST verantwortung

Zentralbereich IFM

I
I
I
I
I
I
I
I
L

Konzerneinheiten (OT AG und Beteiligungsgesellschaften)

Abbildung 21: Informationsmanagement im Software-Life-Cycle

32
 Detlev Frick

ZB Intormallonsmanagemenl IS-Strategie,
InfoSystemplanung
Aul1raggeber c:>- . TRP Tech. Rahmenpl. Erarbeiten
der
(Konzern IV) Konzerndaten-Mgmt IS-Slralegle
Arbeitsplatzssysteme und
SAP Management IS-Planungen

Informationsmanagement:
Deulsche Telekorn Konzem Rahmenvorgaben IV Servlcegesellschal1en
Konslstenzslcherung
IS-Beratung
DTAG

Aul1rage Entwicklung
BTG'n ~ EinfOhrung
Systeme I Dlenstleistungen
Informations Instandhaltu~
systemplanung 1 Sysle rn

o Beauftragung
t
Aul1rage , olT-Beratung
oBelrieb
o Nutzung Oiensllel.lungen oService

Abbildung 22: Dberblick uber Leistungsbeziehungen im Informa-

tionsmanagement

1m Zentralbereich Informationsmanagement werden konzernwei-

te Planungsleistungen erbracht, wie z. B. die IS-Strategie, die In-
formationssystem-Gesamtplanung oder das SAP-Management
(vgl. Abbildung 22). Auf der Grundlage dieser Ergebnisse und
unter Zugrundelegung der Standards bzw. Rahmenvorgaben des
Informationsmanagements erfolgt die Durchfuhrung der Soft-
wareentwicklung sowie der Betrieb und die Nutzung durch die
Kunden im Konzern Deutsche Telekom.

2.2 SAPManagement
Der Einsatz betriebswirtschaftlicher Standardsoftware reicht bei
der Deutschen Telekom zuruck bis in das Jahr 1985. Damals er-
folgte die Implementierung moderner Kostenrechnungsverfahren
auf der Grundlage des Moduls RK der Standardsoftware SAP RI2.
Heute hat neben dem Betrieb der weltweit grbBten SAP RI2-
Installation, deren Migration nach SAP R/ 3 in diesem Jahr (2002)
durchgefuhrt wird, der Einsatz von SAP R/3 eine hohe Prioritat
bei der Deutschen Telekom AG . Derzeit sind eine Vielzahl von
R/ 3 Projekten in Planung, Entwicklung oder im produktiven Ein-
satz (insgesamt ca. 450 SAP R/ 3-Systeme). Auch die neuen Pro-
duktlinien, wie etwa mySAP BI (Business Intelligence) oder die
Branchenlbsung IS-T (Industry Solution Telecommunication)
werden produktiv eingesetzt bzw. pilotiert. In vielen Tochterge-
sellschaften der Deutschen Telekom AG werden umfangreiche
betriebswirtschaftliche Ablaufe mit SAP R/ 3 untersti.itzt, so zum

33
Ein Konzern- Vorgehensmodell fur die lmplementierung von SAP Rl3

Beispiel bei der T-Mobile GmbH oder der DeTelmmobilien

GmbH.
Die Abbildung 23 gibt einen groben Dberblick uber die weltweit
beispiellose Komplexitat und GroBe der SAP-Projektlandschaft
der Deutschen Telekom AG. Die Koordination der vielfaltigen
SAP-Aktivitaten des Konzerns ist die Aufgabe des SAP-
Managements, einer hierfUr eingerichteten Projektgruppe. Neben
der Bereitstellung von Methoden und Standards, wie etwa dem
SAP-Vorgehensmodell, werden vor aHem SAP-Projekte mit kon-
zernweitem Bezug durchgefUhrt. Ein Beispiel ist der Aufbau und
Betrieb eines Referenz-Servers fUr Customizing-Templates oder
die Evaluierung der IS-T Branchenlosung.

PROM Venrieb lind AlIflragslcnkung Rl2-System

Privat und Oeschtifl,kunden (AWI-" INTEL
Venricb und AuftrllgslcnkuT1g
Bereich Rundfunk (OMS)

. Controlling
oLogistik
n
U
(SINTEL) oR/3 Master
T-Data

AlIslandSl&hler

Abbildung 23: SAP-Landschaft der Deutschen Telekom

Die konzernweite SAP R/ 3-EinfUhrung wird yom SAP-

Management begleitet durch eine Konzern-Informationssystem-
architektur, die methodengestutzt auf der Grundlage von PRO-
MET eBN entwickelt wurde (vgl. [2]). Der zweite Schritt in der
methodischen Unterstutzung der SAP-Projekte des Konzerns be-
steht nun in der Entwicklung und Bereitstellung eines SAP-
Vorgehensmodells (VM SAP), das im folgenden beschriebe n
wird.

34
 Detlev Frick

3 Vorgehensmodelle

3.1 Problemstellung
Die Deutsche Telekom AG setzt seit vielen Jahren filr ihre Ent-
wicklungsprojekte ein eigenstandiges Vorgehensmodell, das VM
Basis, ein Cvgl. dazu den Abschnitt 3.2). Dieses Vorgehensmodell
ist jedoch filr Individualentwicklungen konzipiert worden und
berilcksichtigt nicht die Besonderheiten bei der Einfilhrung von
Standardsoftware. In diesem Vorgehensmodell werden jedoch
wichtige konzernweite Vorgaben definiert, wie z.B. eine einheit-
liche Dokumentationsstruktur und die Ergebnisse der einzelnen
Projektphasen . Die Organisationseinheiten im Konzern Deutsche
Telekom AG, die sich mit der Einfilhrung von SAP R/ 3 beschafti-
gen, wie z.B. die T-Systems Nova und das ZIP CZentrum filr IV-
Systeme und Prozesse im Unternehmensbereich Netzinfrastruk-
tur), haben daher Ansatze eigener Vorgehensmodelle geschaffen
CProduktionsprozess der T-Systems Nova bzw. Projektleitfaden
im ZIP). Diese unterschiedlichen Modellansatze sind jedoch nicht
konsistent und Berilcksichtigen meist nicht das umfangreiche Er-
fahrungswissen der SAP AG . Es war daher notwendig geworden,
dass die SAP-Projekte im Konzern auf ein einheitlichen und mo-
dernes Vorgehensmodell zurilckgefilhrt werden.

3.2 Das Vorgehensmodell der Deutschen Telekom fOr Software-

Entwicklung (VM BASIS)
Filr die Entwicklung und Instandhaltung von Individualsoftware
hat die Deutsche Telekom ein nach DIN ISO-9001 zertifiziertes
Vorgehensmodell entwickelt und im Einsatz (vgl. [4]). Die Phasen
des Vorgehensmodells sind in Abbildung 24 dargestellt.

35
Ein Konzern- Vorgehensmodell fur die Implementierung von SAP Rl3

Informationssystem-Planung
VorDroiekt
Au~ag Genehmigter
HTP
1 JEinfiihrungsprojekt
Ke~~~M , -__________- ,
Entwicklungsprojekt
I
I Fachliches
Feinkonzept
L
1-"~ I"
I DV-technisches I c:::::::::::J" Planung:

I JJ"
'Organisation

I :V~~::~~~:e
Realisierung '-----r-.
'Schulung
Infrastruktur

I Systemtest mit
Abnahme
I [ lI .1"
__

----- ----
~Ilware

I Gesamtintegrationstesi@fL :::~
Freigabe-
I t-'rooeoetneo I
verfahren
Elnruhrung In der Flache I I
~rmationssy~

Wlrkbetneb

Abbildung 24: Vorgehensmodell der Deutschen Telekom AG

(VM BASIS)

Das Vorgehensmodell der Deutschen Telekom AG beschreibt die

Planung, Entwicklung und Einfiihrung von Software und orien-
tiert sich am klassischen Life-Cycle-Modell des Software-Engi-
neering. Es orientiert sich zusatzlich an der gedanklichen Tren-
nung des Software-Entwicklungsprojektes und dem Software-
Produkt (= Softwaresystem). VM BASIS unterscheidet hierbei
zwei organisatorische Ebenen:
1. Die dispositive Ebene der Informationssystemplanung
der Konzernzentrale
2. Die operative Ebene der Entwicklungsarbeiten, die in
mehreren unabhangigen Entwicklungszentren oder Ex-
tern durchgeftihrt wird.
Die Abwicklung eines Software-Projektes ist durch einen Wech-
sel zwischen operativer und dispositiver Ebene je Phase gekenn-
zeichnet (vgl. Abbildung 25). Die dispositive Ebene gibt die je-
weils nachsten Phasen frei. Lediglich die eigentliche Eot-
wicklungsarbeit wird nicht mehr durch Entscheidungsschritte un-
terbrochen, sondern durch Projektreviews kontrollierend beglei-
tet.

36
 Detlev Frick

-..
operative Ebene

Vorprojekt plantn
I disposith e Ebene

Phuse I
Projeklierung Vorprojtkt bt'~lUnruS.!tn I

I
Phase 2 t.osungSalltmati,'cn
enlwkkeln Grund.'i8tunt..o;chl!idung
Vorl>rojekl h~rbc.imhrcn

I
Uisu n.gsa1~tm2ti 'f
konkrtti.!;it.'rt'.n Realproje kte
beaunralten

Phasen 3-5
Enlwicklung
"~achli cht!S Fcinkon:ttpt
II 1\ l e il tn~t ei n rnicws

I
UVl tdm.bcht'..\
J'hase 3 Fachlichcs Feinkonzcpt Frinkomepi
un<!
Phase 4 0 lechni~ches fcinkon7.cpt
]'ha.,e 5 DVRealisieMl"2
OVRealbierun~ 'TojcklkontroUe
t
Phuse 6
Syslemlcsl und Abnahme II Ahnnhme
Freigubf [i nruhrun ~

Phase 7 I Probf:belricb
F"rtlgall< WIri<Il<.rjeb
Einfiihrung
WirkMlrieb llurne.hml1l

Abbildung 25: VMBASIS Phasenkonzept

3.3 Vorgehensmodelle fOr die Implementierung von SAP R/3

(ASAP und Global ASAP)
Die Vorgehensmodelle ASAP (AcceleratedSAP) und Global ASAP
sind Produkte der Fa. SAP AG, die den Kunden und SAP Part-
nem im Rahmen des Life Cycle-Modells ValueSAP kostenlos zur
Verfugung gestellt werden. Sie enthalten das umfangreiche Erfah-
rungswissen der Berater der Fa. SAP AG und ihrer Partner.

3.3.1 ASAP (Accelerated SAP)

Das Ziel von ASAP ist die schnelle Verfugbarkeit eines Produkti-
onssystems. Der methodische Ansatz von ASAP beruht auf dem
Continuous System Engineering:
Es erfolgt nur eine sehr eingeschrankte Istaufnahme. Der
Schwerpunkt liegt auf der Definition des Sollkonzepts
(Business Blueprint). Das Sollkonzept enthalt neben den
fachlichen Vorgaben samtliche technischen Annahmen
fUr die Systemsrealisierung.
Fur die benbtigen Funktionen (Prozesse) werden die
von der Firma SAP AG zur VerfUgung gestellten Best Bu-
siness Practices zugrunde gelegt und angepasst. Das ge-

37
Ein Konzem- Vorgehensmodell fur die Implementierung von SAP Rl3

samte SAP-Referenzmodell ist im Prozessmodell abgebil-

det.
Es wird zunachst ein System mit ca. 80% des Leistungs-
umfangs CBaseline-Umfang) angestrebt, das dann konti-
nuierlich vervollstandigt und ausgebaut wird 0-4 Integ-
rationszyklen) .

'YAASJ.P I~~

~ ProJektziele und Erfolgskennzahlen

- -. ,~~

. ' ~J~

"' ~l~""" festlegen

' PI",~o.dAlr'l""'~
.,: 1._-
1c..... ~~Rw Verwendung
I "-.-4eo.n.~,,-, I
IAJ..... ...,~~CIwtler
" ","..tS.ioO~
z...., .. eMs.,AI..f~ab. 1$1 H. d" dUlc.h dJt Elf'lhlhl'l.ll'ig IU 'fTflC~t'ld~ UnctR'4hrMti'StI.I.
I O"'PI. . ~.tIJC:nrdc....fUIII ,.,12.9.n lI'td :u dok.wnetlLtt.n , ~ d en .lfln.a.ndvon Erf.;,lgi eMlat'l,lI qlJatll""", I
I Un:t.oct~l"'I..cICO\Mfttng
gemtn.n wttd", ~Of\nM
I ".."..-.dS<M6..teP"ICIIKITum' ...-.g
Oe''elop(rdU .... TI~.ndD~f'~
CGrd.cIJ.d.tllt~
t ,.....I.WIraoJ ........ httdM,n M d,n .-b.chIuB bHlU'Iw.t'l E~LiI't9sphU'n oM. ~"""'.I"""
I (ft"~ .,.P'Jtn\l'dOet*Nn
Vtrgtt.ch dt ", .ac.hl..-hen ljlol.hi"IjJ~~ nW d.n 1m 91.1"" .... ' ..nuhl .. l1Iff1
AcweIotJtllj.... ~
,
'-Oltff\
: ~-:s~ E~n bull""""" erg.b,.."e
~J.4rJf E"ttC~n ';tin Lttwffttn i.e B.,. ;urlI] utId UriIet''5lutz''''9
~ . . *tnsdltn~

.""""'-
o~~~ 0."41 1.1. so!ltf'" au e~~:'fMlnI dn Pro;eJ;1 J1ha1'l"btdl unci dtf lIifIIlrnelimtofl'llftiung

......-.....
....oelSpf'gtfn
11.-Il'\1'\0
Voraehen5W@lse

-6.. . R
.
60'lM'~1,JOCIII
- . ~.III&I"

'-
~;;;:.:r:_
==~_~_~~__=_:_=== ..
_:_:_=~=~~~.~ 01 _ _ _ .....
I ...

r
,...
_. 1 -- .-- ---
~'~------------------------------------~I

Abbildung 26: ASAP Implementation Assistant

ASAP ist ein toolbasiertes Vorgehensmodell, d .h. es besteht aus

folgenden Bestandteilen:

38
 Detlev Frick

ASAP Implementation Assistant als Navigationstool fur

die ImplementationRoadmap (Vgl. Abbildung 26, linkes
oberes Fenster). Enthalten sind eine Knowledge Corner
(Bibliothek von nutzlichen Dokumenten fUr EinfUh-
rungsprojekte) und Business Process Procedures (vorbe-
reitete Benutzerdokumentationen fUr die einzelnen
Transaktionen). Das zugrunde Phasenmodell ist folgen-
dermalSen strukturiert:
Ebene 1: Phase: Die Implementation-Roadmap gliedert sich in fUnf
verschiedene Phasen, die jeweils einen wichtigen
Meilenstein des EinfUhrungsprojekts darstellen:
1. Projektvorbereitung
2. Business Blueprint
3. Realisierung
4. Produktionsvorbereitung
5. Go live & Support.
Ebene 2: Jede Phase der Implementation-Roadmap beinhaltet
Arbeitspaket eine Reihe von Arbeitspaketen, deren Ausfuhrung zur
Erreichung der Ziele der jeweiligen Phase beitragen.
Ein Arbeitspaket setzt sich aus Aktivitaten und Aufga-
ben zusammen.

Ebene 3: Jedes Arbeitspaket besteht aus verschiedenen Aktivi-

Aktivitdt taten. Aktivitaten beinhalten die Aufgaben, die von
einem oder mehreren Projektteammitgliedern zur
Umsetzung der festgelegten Ziele bearbeitet werden
mussen. Auf dieser Ebene finden Sie Beschleuniger in
Form von Anleitungen, How-To' s, Vorlagen sowie
Beispiele zu samtlichen Themen, die fUr die EinfUh-
rung der SAP-Software von Bedeutung sind (Frage-
bogen, Projektformulare, Checklisten, Anleitungen,
Musterprojektplane). In der Registerkarte Rollen im
Anlagenbereich finden Sie genaue Informationen zu
den Mitarbeitern des Projektteams, die sich an der
AusfUhrung der jeweiligen Aktivitat beteiligen sollten.

Ebene 4: Jede Aktivitat umfasst mehrere Aufgaben. Die Schrit-

Aufgabe te, die zur AusfUhrung einer Aufgabe benotigt wer-
den, werden in diesen Dokumenten der Implementa-
tion-Roadmap genau beschrieben . Aufgaben werden
von den Mitgliedern des Projektteams ausgefUhrt.

39
Ein Konzern- Vorgehensmodell fur die Implementierung von SAP Rl3

Auch auf dieser Ebene finden Sie Beschleuniger. In

der Registerkarte RoUen sind wieder die notwendigen
RoUen aufgefUhrt.
~.ir ...., ~ ..... ~.:;"Jdlt l! ~ HIlI

~ "JeaJIIi1J91f ~...2If!I Jilli 101:11 !;lI.!.I.Q1 MJ

flie,:y. t.
""_1 r~Or'1I fedrl~~ l ~I
FIoIQiIIIIt! 1

~Ht.It~.,~",LI!lI.I 'jwj
~ !r~ AN#i h ..__z~ .V'f:
"'IIS'" .&0 0 H!ChII. ....
a~II' f't(Ct"fUtIt 13 0 H ~/'IJIL...
TI--YO"Wl 18 tidi 16
~:Ioero 0 He" N.chft'~
;1 0 Nd1 Ht;h.
o "di . . N...,'"
Hd1 ..... N~_

Hdilft HI7II~

-
H<>< .;l

..... <
C,,"'-"
.:.

~.:t< ~

.."..

N_ c_
IIII~ o.""""",

'lli'''-
S
Dl
,-.. C-.....,

,,-
bo_

~ I
0001 Ik;lt
t. .. t ......1 _~
Zlgtc;h)r'l","~worOcn'l:? "'" ~

? u......,~"'r, ..... f of., f ..a ...

.~ts.2002 l~ U "' ...... bl~ :

Abbildung 27: ASAP Question & Answer Database

Die ASAP Q&A Database (vgl. Abbildung 27) unterstutzt

die Entwicklung und Dokumentation des Sollkonzepts
(Blueprint), in dem das gesamte Rl3-Referenzmodell in
einer strukturierter Form zur Verfugung gestellt wird, urn
Informationen zu jedem einzelnen Prozess zu sammeln
(Fragen), zu beschreiben (Blueprint-Formular) und zu-
geh6rigen R/3-Transaktionen zu erfahren bzw. der Base-
line oder den Entwicklungszyklen zu zuordnen. Dabei
wird der Projektumfang definiert. Zu den einzelnen Pro-
zessen lassen u.a. die eEPK-Diagramme (erweiterte Er-
eignis-Prozess-Ketten) anzeigen, wenn entsprechende
Viewer/ModeUer installiert wurden.
Aus den Informationen, die wahrend der Blueprint-Phase in der
Q&Adb gesammelt wurden lassen sich folgende Reports (Excel
Arbeitsmappen) generieren:

40
 Detlev Frick

Die Business Process Master List (BPML) reprasentiert die

Business-Prozesse und Transaktionen, welche in der Bu-
siness Blueprint-Phase in den Projektumfang genommen
wurden. Anhand der BML k6nnen samtliche Konfigura-
tions- und Testaktivitaten in den verschiedenen Zyklen
der Realiserungsphase gesteuert und uberwacht werden.
Die Development List (DL) enthalt alle Strukturelemente,
fUr die in der Realisierungsphase Reports und/ oder
Schnittstellen entwickelt werden mussen. Anhand der DL
werden diese Entwicklungsaktivitaten gesteuert und die
notwendigen Entwicklungsdokumentationen (funktio-
nale und technische Spezifikationen) bereitgestellt.
Die Organization Structure List (OSL) enthalt alle Struk-
turelemente, die in der Realisierungsphase im Organisa-
tionsmodell des R13-Sytems konfiguriert werden mussen.
Die Authorization List (AL) unterstlitzt bei der Ent-
wicklungs des Berechtigungskonzepts. Mit ihrer Hilfe
werden die ben6tigten Rollen im Produktionsystem fest-
gelegt und den Rollen die erlaubten Transaktionen zu-
geordnet.
Die Issues-DB fUr das Management und die Dokumenta-
tion von Projektproblemen.
ASAP gibt es seit gut vier Jahren. Seitdem wurde es in hunderten
verschiedener Projekte in der ganzen Welt eingesetzt, und uber
10.000 Berater der SAP und ihrer Partnerunternehmen sind in der
Anwendung von ASAP ausgebildet worden. Ganz im Geiste von
TeamSAP benutzen zahlreiche SAP-Partner ASAP inzwischen
entweder als ihr Standardverfahren oder haben es in ihre eigene
Methode integriert.
ASAP ist ASAP ist mittlerweile sicherlich als ausgereift zu bezeichnen und
ausgereift sehr vielseitig in seinen Funktionen, so dass es sich alle SAP-
Projekte eignet. Ganz gleich, ob die komplette Roadmap bearbei-
tet wird oder nur einige der Beschleuniger eingesetzt werden.
Insgesamt k6nnen die Projekte auf jeden Fall eine deutliche
Zeitersparnis verbuchen. Gleichzeitig wird sichergestellt, dass ei-
ne qualitativ hochwertige und jederzeit wiederholbare Systemin-
stallation vorgenommen. Mehrere Projekte in mittelstandischen
Unternehmen untersuchte das unabhangige Institut fUr Wirt-

41
Ein Konzern-Vorgehensmodell fur die Implementierung von SAP Rl3

schaftsinformatik OWl) der Universitat St. Gallen und erhielt

durchweg positive Einschatzungen (vgl. [1)).

3.3.2 Global ASAP

Wahrend ASAP fUr die EinfUhrung eine Rl3-Systems in einen 10-
kalen Projekt gedacht, ist der Fokus von Global ASAP der Kon-
zern-Roll Out. 1m Mittelpunkt stehen also Fragestellungen, wie
z.B. verteilte R/ 3-System-Architekturen in global agierenden Un-
ternehmen, unterschiedliche Landesgesetzgebungen , konzern-
weite Standards, globale Beschaftsprozesse usw.
Telekom Ent- Ein global agierender Konzern , wie die Deutsche Telekom, muss
wicklungs- und sich bei der konzernweiten SAP R/ 3-lmplentierungsstrategie LO-
Customizing- sungen fur diese Problemstellungen aufzeigen. Die rund 150 R/3-
System Produktionssysteme mussen koordiniert und die systemubergrei-
fenden Geschaftsprozesse mussen optimal untersti.itzt werden .
Beim Aufbau des Telekom Entwicklungs- und Customizing-
systems (TEC) wird daher als Vorgehensmodell Global ASAP
eingesetzt.

,,~ l
:: MolaletlGlKe &
'" Support
,,~l
_<> BUAm'
.. Blueprillt

Rollout Roadmap

Abbildung 28: Global ASAP Roadmap

Abbildung 28 zeigt die Global ASAP Roadmap. In der Phase 1

wird die globale R/ 3-Strategie definiert (u .a. auch die verteilten
Rl3-Systemarchitektur). AuBerdem wird das Template-Projekt
aufgesetzt. Die Phase 2 dient im wesentlichen zur Definition des
globalen Sollkonzepts (global business process model). An-
schlieBend werden die benbtigen globalen Templates konfigu-

42
 Detlev Frick

riert und getestet. Aus dieser Phase heraus wird auch der Roll
Out der globalen Templates in die lokalen Projekte durchgefUhrt.
Die folgende Abbildung 29 zeigt diese Vorgehensweise als Gra-
fik.

Global implementations - global template >

Maintenance and Support

Abbildung 29: Vorgehensweise beim Konzern Roll Out

4 Entwicklung eines konzernspezifischen Vorgehensmodells

(VM SAP)
Konzern- 1m Konzern Deutsche Telekom existierte bisher neben dem be-
standards fur reits beschriebenen VM Basis kein einheitliches Vorgehens-
SAP-Projekte modell fUr Rl3-Projekte. Das zentrale Informationsmanagement
hat daher den Auftrag erhalten, ein R/3-Vorgehensmodell zu
entwickeln, dass zuklinftig als Konzernstandard dienen solI. Bei
einer Untersuchung der bisherigen Ansatze fUr R/3-Vorgehens-
mode lIe ist relativ schnell klar geworden, dass der ASAP-Ansatz
zugrunde gelegt werden sollte. Da die Vorgaben der bisherigen
Vorgehensmodelle nicht verloren gehen durften, musste eine
Synthese mit den vorhandenen Vorgehensmodellen angestrebt
werden (vgl. Abbildung 30).

43
Ein Konzem- Vorgehensmodell fur die Implementierung von SAP Rl3

D'J'AO SAP

SW-Produktionsprozess ASAP
T-Systems Nova

VM- SAP

Abbildung 30: Vorgehensweise bei der Entwicklung von VM SAP

4.1 Zielsetzungen und Nutzenerwartungen

Es sollte ein Vorgehensmodell bereitgestellt werden, das
die Konzernvorgaben bzw. -standards bereits mit dem
Vorgehensmodell bereitgestellt.
auf den Dokumentationsstrukturen des VM BASIS ba-
siert.
einen direkten Zugriff auf die Entwicklungsumgebung
ermbglicht.
eine Erweiterungsmbglichkeit von Inhalten der Roadmap
bietet und projektspezifisch angepasst werden kann .
zentral verfUgbar ist (ASAP-Server).
die Releasefahigkeit gewahrleistet.

Mit diesen Zielsetzungen gingen folgende Nutzenerwartungen

einher. Das VM SAP gewahrleistet namlich
die Reduktion der EinfUhrungszeit bei Neu-Projekten
durch Nutzung der bereits implementierten Hilfsmittel.
die Selbstandigkeit der Projekte (Roadmap liegt fruhzei-
tig vor).
die Nutzung externer Reviews (Program Review z. B.
durch die SAP).

44
 Detlev Frick

die Wiederverwendbarkeit von Projektinhalten und ein-

heitliche Abbildung von Projektwissen (notwendig fUr
Knowledge Management).
die Reduktion von EinfUhrungskosten bei Neu-Projekten.
die Mbglichkeit Projektkennzahlen bereitzustellen.
die Mbglichkeit den Produktionsprozess zu zertifizieren.

4.2 VM SAPEntwicklung
Ein Entwicklungsprojekt wurde im Juli 1999 aufgesetzt. Nach der
Analyse der im Konzern benutzten Vorgehensmodelle wurden
fUr die wichtigsten Vorgabedokumente identifiziert, um als so
genannte T-Beschleuniger in ASAP eingebaut zu werden. Um die
Dokumente auf einer Metaebene beschreiben zu kbnnen wurden
Steckbriefe erstellt. Ein Steckbrief
beschreibt die Herkunft des Beschleunigers.
stellt die Referenz des Beschleuniger zur VM SAP-
Aktivitat her.
enthalt Kriterien, ob eine Anpassung des Beschleunigers
fUr VM SAP erforderlich ist.
enthalt einen Hinweis auf die Bedeutung und Einstufung
des Beschleunigers.
enthalt die Dateiformate des Beschleunigers, deren Aus-
pragung mit Check-In-Vermerken.
enthalt Benutzerhinweise fUr den Beschleuniger.

Auf der Basis der Steckbriefe konnten die Vorgabedokumenten

der verschiedenen Vorgehensmodelle konsolidiert werden. Fur
jede einzelne Auspragung wurde der entsprechende T-
Beschleuniger entwickelt und in ein einheitlichen Layout ge-
bracht. Mitte November 1999 wurde der VM SAP-Prototyp mit
den T-Beschleuniger vorgestellt. Neben den vorhanden ASAP-Be-
schleunigern sind nun T-Beschleuniger bei den entsprechenden
Aktivitaten nutzbar (vgl. Abbildung 31).
Der Prototyp wurde im Laufe des Jahres 2000 zu einem produk-
tiven System weiterentwickelt. Die Test und Abnahmeaktivitaten
sind abgeschlossen worden und das System steht zur Produkti-

45
Ein Konzern- Vorgehensmodell fur die Implementierung von SAP Rl3

onsaufnahme bereit. Bei einem zentralen Dienstleiter der Deut-

schen Telekom, namlich der DeTeCSM ist ein ASAP-Server einge-
richtet worden, der zentral von den Projekten genutzt werden
kann. Fur die Ablage der Projektdokumente sind entsprechende
Strukturen aufgebaut worden und stehen den Projekten zur Ver-
fUgung . Zur zentralen Administration der Projektmitarbeiter wur-
den entsprechende organisatorische MaBnahmen getroffen.
Die T-Beschleuniger wurden zu sog. T-Packs zusammengefasst
und in verschiedene ASAP-Versionen mit unterschiedlichen
Roadmaps und Flavors eingespielt. Zur Automatisierung der Ein-
spielung dieser T-Packs wurden SQL-Scripte erstellt, die uber ei-
ne Excel-Tabelle gesteuert werden.
In einigen SAP-Projekten konnten bereits Erfahrungen mit die-
sem neuen Vorgehensmodell gesammelt werden. Diese waren
bisher uberwiegend positiv. Die im Abschnitt 4.1 genannten Pro-
jektziele konnten erreicht werden. Durch eine standige Auswer-
tung der Projekterfahrungen uber strukturierte Interviews werden

l
Verbesserungsbereiche ermittelt und im Projekt umgesetzt.

\P
~ \1

ROADMAP

.\Hln ...
Blu.p.ln,

o().

Abbildung 31: VM SAP Roadmap

4.3 Weitere Projektschritte

Das VM SAP ist mit den T-Beschleunigern auf einem zentralen
Server verfugbar. Seit Anfang 2000 haben bereits die ersten SAP-
Projekte mit diesem Prototypen gearbeitet und wichtige Erkennt-
nisse fUr die weitere Entwicklung geliefert.

46
 Detlev Frick

In bestimmten Themenbereichen bietet ASAP nicht die notwen-

dige Unterstiitzung um den hohen Qualitatsanforderungen der
Deutschen Telekom gerecht zu werden. Hier mussten eigene Be-
schleuniger erstellt werden bzw. ist noch Handlungsbedarf fUr
die Zukunft.
Insbesondere das Konfigurationsmanagement ist bisher in den
Systemen der Fa. SAP nicht im erforderlichen Umfang ausge-
pragt. Das SAP Change and Transport System (CTS) Iiefert zwar
bereits eine Fiille an Informationen zu den durchgefUhrten Akti-
onen. Fur einen groBen, weltweit agierenden Konzern ist es aber
unabdingbar, dass samtliche Transporte in das Produktionssys-
tem liickenlos iiber aile Stufen auf die auslosenden Problemmel-
dungen der Fachabteilungen zuruck verfolgbar sind. Eine solche
li.ickenlose Dokumentation aller Aktionen incl. der Freigaben
werden von klassischen Konfigurationsmanagementsystemen,
wie z.B. Continnuus, produziert. Leider konnen diese Konfigura-
tionsmanagementsysteme nicht auf die R13-Tabellen des CTS
zugreifen. Fiir die Deutsche Telekom wurde daher ein R/ 3-
AddOn entwickelt, das diese Aufgaben erfUlIt. Dieses System
muss noch sinnvoll mit dem VM SAP verkniipft werden.
Die allgemeinen Richtlinien des Konzerns Deutsche Telekom zu
den Themenbereichen Datenschutz und Sicherheit miissen dar-
tiber hinaus noch adaquat in dem Vorgehensmodell abgebildet
werden.

5 Ausblick
Nachdem im Projekt VM SAP gezeigt wurde, dass sich ASAP
konzernspezifisch anpassen lasst, muss nun das VM SAP bei den
Konzerntochtern etabliert werden. Dazu ist ein formaler Be-
schluss notwendig, der das VM SAP als Konzernstandard vor-
schreibt. Die notwendigen Abstimmungen und Diskussionen
sind Ende 2000 im Konzern-CIO-Kreis geftihrt worden. Die CIO's
der Beteiligungsgesellschaften und des Konzerns Deutsche Tele-
kom haben sich auf das VM SAP verstandigt. Durch die Einftih-
rung dieses konzernweiten Vorgehensmodells werden Kosten-
einsparungen von mindestens 4 Mio. DM erwartet.
Nach der erfolgreichen EinfUhrung des VM SAP muss im nachs-
ten Schritt sicherlich iiber eine konzernspezifische Anpassung
von Global ASAP nachgedacht werden.

47
Ein Konzern- Vorgehensmodell fur die Implementierung von SAP R13

6 Literaturverzeichnis
1. Dolmetsch, R.; Huber, T.; Fleisch, E.; Osterle, H: Accelerated
SAP, 4 Case Studies, Arbeitsbericht, Institut fur Wirtschaftsin-
formatik, Universitdt St. Gallen, Hochschule fur Wirtschafts-,
Rechts- und Sozialwissenschaften (HSG), St. Gallen, 1998.
2. Fleisch, E.; Pohland, 5.; Schelhas, K.-H; Osterle, H: Entwick-
lung einer Informationssystemarchitektur. In: HMD Praxis der
Wirtschaftsinformatik, Heft 202, 1998, 5. 85-1OJ.
3 . Gadatsch, A.; Humpert, K-D.; Weis, T.: Doppelstrategie fur die
Deutsche Telekom, Rl3-Einsatz schwerpunktmdjSig im kauf-
mdnnisch administrativen Bereich, SAP-Info Special, Heft 1,
1997, 5. 22-25.
4. Ganser, A. (Hrsg.): Vorgehensmodell der Deutschen Telekom,
Entwicklung ind Instandhaltung von komplexen Softwaresys-
temen, Munchen, Wien, 1996.
5. Pomberger, G.; Blaschek, G.: Software Engineering, Prototy-
ping und objektorientierte Software-Entwicklung, Munchen,
Wien, 1993.

48
 Arno Kuhn

Chancen und Risiken einer Konzernstrategie zum weltweiten Ein-

satz von SAP R/3 (ein Erfahrungsbericht)

Arno Kuhn

1 Einleitung
Die weiter zunehmende Globalisierung der Industrie definiert
neue Anforderungen an IT-unterstutzte Geschaftsprozesse: funk-
tionale Komplexitat und Grad der Yernetzung nehmen erheblich
zu. Standardisierung "mehr denn je", ist hier ein Lbsungsprinzip,
auch bei der Anwendungsentwicklung selbst. Die Notwendigkeit
zur Integration von Unternehmensanwendungen (EAI), die fle-
xible und schnelle Anpassung von konzerninternen sowie unter-
nehmensubergreifenden, kollaborativen Prozessen an die sich
schnell verandernden Organisations- und Markterfordernisse sind
wirtschaftlich nur mit "homogenen Anwendungsarchitekturen" zu
gewahrleisten.
Marktgangige Standardsoftwaresysteme bieten heute hierfUr auf
Basis verschiedener Hardware- und Betriebssystemplattformen
attraktive L6sungen fUr den internationalen Einsatz an. Die in
diesem Zusammenhang zu treffenden Unternehmensentschei-
dungen sind von strategischer Bedeutung.
Der Yortrag greift diese Problematik auf und berichtet uber die
"SAP-Strategie" in der Unternehmensgruppe TDY Rhein-
land/ Berlin-Brandenburg. Er zeigt die Chancen und Risiken am
Beispiel einiger der dort durchgefUhrten weltweiten SAP-Projekte
aus organisatorischer und technologischer Sieht.

2 Die Unternehmensgruppe TOV Rheinland/Berlin-Branden-

burg (TOV RBB)
Mit rund 8000 Mitarbeitern ist der TDy RBB mit Hauptsitz in
K6ln in uber 80 Gesellschaften weltweit vertreten. 2500 dieser
Mitarbeiter sind direkt vor art in 150 Auslandsstlitzpunkten und

49
Chancen und Risiken einer Konzernstrategie zum weltweiten Einsatz von SAP Rl3

mehr als 40 Uindern prasent, verbunden in einem globalen

Netzwerk.

Abbildung 32: Globales Netzwerk des TUY Rheinland/ Berlin-

Brandenburg

Der hiermit erzielte Konzernumsatz konnte stetig gesteigert wer-

den und betrug fUr das Geschaftsjahr 2001 bereits ca. 650 Mio
Euro. Er setzt sich zusammen aus uberwiegend freiwirtschaftli-
chen Dienstleistungen in verschiedenen Geschaftsfeldern. Neben
den traditionellen Tatigkeiten aus der uber 130 Jahre alten TUY-
Tradition, wie Anlagen- und Kraftfahrzeugtechnik, zertifizieren
heute TUY-Experten Produkte fUr den internationalen Warenaus-
tausch, sie beraten Unternehmen, die auf den Wachstumsmark-
ten der Welt FuB fassen wollen, fuhren Schulungen und Quali-
tatsaudits durch und sind bei sicherheitstechnischen Entwicklun-
gen weltweit gefragte Berater. Auf dem Weg zu dem Ziel, ein in-
ternational fuhrender Dienstleister fur dokumentierte Sicherheit
und Qualitat zu werden, wurden wichtige Meilensteine erreicht.
Der TUY RBB steht im Wettbewerb, letzte Monopole der so ge-
nannten "staatsentlastenden Aufgaben" fallen ebenfalls in Kurze.
Hieraus lassen sich die wichtigen Anforderungen hinsichtlich in-
formationstechnologischer Unterstutzung, fDr deren ErfUliung der
zentrale Service-Bereich fur Informationstechnik und Informati-
onsverarbeitung in Zusammenarbeit mit weiteren IT-Abteilungen
in Asien und Nordamerika verantwortlich ist, ableiten.
Ein erganzendes CIO-Board (CIO=Chief Information Officer) u-
bernimmt auf Konzernebene zusatzlich die Aufgabe der weltwei-
ten Standardisierung, der Definition von Richtlinien sowie der

50
 Arno Kuhn

Gesamtkoordinierung und definiert somit den IT-Rahmen fur die

Umsetzung aller Anforderungen im Gesamtkonzern.

3 Wesentliche IT-Anforderungen des TOV RBB

Der sich rasch vollziehende und derzeit besonders durch Wachs-
tum im Ausland gekennzeichnete Wandel in der Unternehmens-
organisation mit einem stetig auszuweitenden Dienstleistungsan-
gebot, aber auch die Situation zunehmenden Wettbewerbs-
drucks, erzwingen permanente Erganzungen in den Geschafts-
prozessketten. Die definierten Hauptzielsetzungen liegen derzeit
in der verbesserten Unterstutzung der Sachverstandigen, Ingeni-
euren, Beratern usw ., unmittelbar bei der Leistungserbringung
selbst, also direkt im Bereich der Service- und Kundenprozesse.
Anstelle der fruher eher funktionsorientierten , muss nunmehr
forciert eine prozessorientierte Sicht mit der wichtigen Perspekti-
ve unternehmensubergreifender Integration treten, um die ge-
planten Optimierungen zu erreichen. So ist z.B. der direkte
Zugriff auf technische Objektdaten yom Kunden zum TDv und
umgekehrt eine Forderung zur Verbesserung eines PrOf-l und
Wartungsmanagements bei GrolSkunden. Die Prozessvernetzung
unter Einbeziehung der Geschaftspartner wird zum Wettbewerbs-
faktor. Die Nutzung neuen technischer Innovationen, u.a. mobi-
ler Kleingerate, Handhelds und des Internets sind zur Unterstlit-
zung eines "rnobilen Service" einzubeziehen.
Bei der Umsetzung dieser Anforderungen stellt sich in den Pro-
jekten die Frage nach der Vorgehensweise und geeigneten An-
wendungsplattforrnen. Neben Funktionalitat und "moderner
Technik" muss insbesondere auch die Flexibilitat hinsichtlich der
Notwendigkeit zur laufenden Anpassung aufgrund organisatori-
scher MalSnahrnen sowie insbesondere sich schnell verandernder
Markbedingungen vor empfunden werden.

4 Losungsstrategie der Unternehmens-IT

Eine wichtige Pramisse fUr die Entwicklung des IT-Personals ist,
Kernkompetenzen auch mit dem Schwerpunkt Geschaftsprozess
bezogenen Know how's im Unternehmen aufzubauen und be-
reitzuhalten. Gerade aus Sicht der vorgenannten Zielsetzungen,
die Unternehmensprozesse zusarnrnen mit den fachlich zustandi-
gen Instanzen laufend fortzuentwickeln , ist dies von Bedeutung.
Der Zwang zur Wirtschaftlichkeit bedingt hierzu eine stringente
IT-Strategie mit dem Zie! weitgehend homogener Anwendungs-

51
Chancen und Risiken einer Konzernslrategie zum wellwei/en Einsalz von SAP Rl3

plattformen. Die IT des TOy RBB setzt hier auf Konzernstan-

dards, die yom Konzern CIO-Board abgestimmt und vorgegeben,
seit Jahren konsequent umgesetzt werden.
Die wesentlichen Aspekte sind:
Weitgehende Konzern-Standards fUr die technischen
Plattformen einschl. Hardware, Betriebssoftware, Kom-
munikation und technischer Infrastruktur.
Tool-Strategie fur die Anwendungsentwicklung mit "SAP"
im Mittelpunkt dieser Strategie. Hierbei werden alle stra-
tegischen Anwendungen mit "Breitennutzung im Kon-
zern" mittels Standard oder mit Standard-integrierter In-
dividualentwicklung auf Basis der SAP-Entwicklungs-
werkzeuge (ABAP-DW usw.) realisiert. Gerade weil die
TOY-spezifischen Geschaftsprozesse auch absehbar nicht
vollstandig mit Standardsoftware abgebildet werden
k6nnen und teilweise mit Blick auf die fur den Wettbe-
werb besonders wichtigen Prozesse auch nicht immer
unbedingt sollen, ist diese seit Jahren ganz konsequent
praktizierte MaBnahme entscheidend fUr den Erfolg. Ne-
ben "SAP" reduziert sich die Tool-Strategie auf die weite-
re Nutzung von Lotus Notes (Wissensmanagement
einschl. Dokumentenverarbeitung und Kommunikation)
sowie Microsoft fur die weit verbreiteten Office-An-
wendungen. Lotus Notes und Microsoft-Tools werden
zusatzlich im Segment der nicht strategischen Anwen-
dungen sowie bei speziellen Anforderungen der SAP-
erganzenden Desk-Top-Integration eingesetzt.
SAP R/ 3 als Client-/ Server-System ist ein technisch zent-
ralisiertes System. Datenbank- und Applikationsschichten
sind praktisch nicht beliebig "verteilbar". Auch aus die-
sem Grunde wurde in der TOY RBB-Gruppe eine techni-
sche SAP-Zentralisierung "an wenigen Stellen" umge-
setzt.

5 SAP als "strategisches Tool" zur Anwendungsentwicklung

Es existieren drei R/ 3-Systemlandschaften (derzeit Release 4.6C),
in K6ln als Zentralinstanz mit separaten Systemen fur
Entwicklung, Qualitatssicherung und Produktion fur Eu-
ropa,

52
 Arno Kuhn

in Yokohama mit separaten Systemen fUr landesspezifi-

sche Erganzungs-Entwicklung und Produktion fUr Ge-
samtasien,
in Newtown (USA) mit ebenfalls separaten Systemen fUr
erganzende Entwicklung und Produktion (Amerika).
Die Systeme sind weltweit tiber GUI-Zugriff nach Bedarf verfUg-
bar. Die systemseitige Integration erfolgt technisch mittels RFC-
Kopplung (in Ausnahmen tiber ALE).
Die Entwicklungen werden weltweit koordiniert. So kommen auf
allen Systemen identische Anwendungsstrukturen mit konzern-
weit festgelegten Mandanten- , Gesellschafts-, Buchungskreisnum-
mern usw. zur Anwendung. Auch wichtige Stammdaten wie
Kontenrahmen oder Kundendatenstrukturen sind weltweit nor-
miert.
Die Option einer zuktinftigen systemtechnischen Zusammenfas-
sung der heute getrennt betriebenen Systeme bleibt somit erhal-
ten. Auch die Schnittstellen lassen sich in diesem Umfeld leichter
betreiben. Spezielle Verfahren regeln die Rool-Out-Problematik
unter Nutzung von SAP-Standardtools zum Transport-Mana-
gement von der Zentralinstanz hin zu den abhangigen Auslands-
instanzen. Etwaige landesspezifische Erganzungen werden nach
speziellen Regeln als "gekapselte Erganzungen" durchgefUhrt.
Diese konnen nur eingeschrankt erfolgen. So sind lokal Daten-
bank verandernde Programmierungen prinzipiell untersagt. Wird
eine Anderung am "Kernsystem" gewtinscht, so muss diese auf
der Kainer Entwicklungsinstanz realisiert werden. Hierzu kannen
nach Abstimmung mit der Zentralinstanz auch Anwendungsent-
wickler entfernter Lokationen beteiligt werden ("virtuelle Projekt-
teams"). Eine Qualitatssicherung wird dann vor Roll Out durch
die Zentralinstanz sichergestellt. So partizipieren aile Gesellschaf-
ten weltweit an der Fortentwicklung der SAP-basierten Anwen-
dungen.
Hinsichtlich der generellen Individualentwicklung im SAP-
Kontext ergeben sich vielfache Nutzenaspekte:
Jede Eigenentwicklung wird zum integralen Bestandteil
von SAP-R/3. Die Nutzung des SAP-Standard-Rahmens
ist hierbei zwingend gegeben. Haufig ftihren so in der
Anforderungsspezifikation nicht enthaltene, durch die
SAP-Struktur aber gegebene Funktionalitaten zu spateren
Nutzenvorteilen (z.B. spater geforderte Dbersetzung in
Fremdsprachen, Nutzung von Wahrungsrechnung, usw.).

53
Chancen und Risiken einer Konzernstrategie zum weltweiten Einsatz von SAP Rl3

Die Eigenentwicklung kann auf eine Hille fertiger

Komponenten aufsetzen C"SAP-Baukasten") und ist
einfach mit vorhandenen Funktionen (Transaktionen,
Reports, FunktionsbaLlsteine, BAPl's, usw.) zu ver-
fflMBtA~:Entwicklungswerkzeuge unterstlitzen prafessio-
nelle und koordinierte Anwendungsentwicklung. Dies
wird so auch fUr die Individualentwicklung im TDv RBB
genutzt.
Alle Eigenentwicklungen partizipieren an der techni-
schen Entwicklung des Hauses "SAP", auch klinftig im
Hinblick auf die Nutzungen von neuen SAP-Tech-
nologien.
Die Benutzung durch die Anwender erfolgt immer nach
dem SAP-Standard. Somit entstehen keine neuen Auf-
wendungen fUr die Schulung. SAP-Neuentwicklungen
werden ebenfalls fUr die Eigenentwicklungen nutzbar
(z.B. Brawser-Oberflachen, Web-Anbindung, neue Funk-
tionen). Die jeweilige Entwicklung kann so konzentriert
auf die eigentlichen Anwenderanforderungen effizienter
erfolgen.

6 Nutzen/Chancen der Konzernstrategie

Standardisierte Anwendungsstrukturen haben dazu gefuhrt, dass
durch den erreichten Grad an weltweiter Vereinheitlichung, z.B.
bei der angewandten betriebswirtschaftlichen Methodik sowie
der Ablauforganisation, in hohem Mage eine Austauschbarkeit
von Mitarbeitern gegeben ist. Dies ist insbesondere bei den stark
wachsenden Gesellschaften im Ausland von Vorteil (haufige
Fluktuation). Durch den Zugriff auf die SAP-Systeme von jedem
Standort aus sind Unterstutzungen auch ohne Personal-
Umsetzungen mbglich. Gegenuber dem vorherigen Status mit
weltweit verschieden Teilsystemen in den Gesellschaften liegt
hier eine erhebliche Verbesserung. Auch die Kommunikation
wird nunmehr durch gleiche Begriffe mit definierten Inhalten
stark gefbrdert (und das liber verschiedene Sprachen).
Entwicklungen sind prinzipiell weltweit nutzbar. Auch die teil-
weise erforderliche Integration mit "Non-SAP" gelingt liber die
Anwendung standardisierter Interface-Technik relativ schnell.
Der Nutzung der SAP-"Okologie" ist zuklinftig von grager Be-
deutung. Durch die starke Verbreitung von SAP-Software auch

54
 Arno Kuhn

bei unseren Kunden kann die Anforderung kollaborativer Pro-

zesse mit weniger Aufwand realisiert werden (und dies ebenfalls
wieder aile SAP-basierten Eigenentwicklungen einschliefSend).

6.1 Beispiel 1
Das nachfolgende Praxisbeispiel (vgl. Abbildung 33) beschreibt
die vollzogene Integration von R/ 3 mit Lotus Notes-Anwen-
dungen, die mit der vorhandenen Standard-Schnittstellentechnik
realisiert wurde:

R/3 System:

ERP
SzenarioA ::> Lotus Notes;
Vertriebsinfo.
Projektverfolg.

und

ADD ON's <: SzenarioB

Lotus Notes;

Workgroup

Abbildung 33: Enterprise Application Integration: R/3 und Lotus

Notes

SzenarioA Szenario A wurde mittels SAP Remote Function Call (RFC) und
Lotus Script Extension (LSX) realisiert. Es werden hierbei auf Ba-
sis eigenentwickelter Funktionsbausteine umfangreiche anwen-
dungsbezogene "Datenreplikationen" fUr die teilweise auch Off-
line eingesetzten Lotus Notes Systeme ermbglicht.
Szenario B Szenario 13 bindet eine Workgroup-Anwendung ebenfalls uber
LSX an R/3 an. Die ursprunglich auf Basis Call Transaction ent-
wickelte Integration wurde im Zusammenhang mit einem Re-
leasewechsel auf die Technik BAPI (Business Application Pro-
gramming Interface) umgestellt. Hierbei konnten Standardbau-
steine auch im Zusammenhang mit Eigenentwicklungen einge-
setzt werden. Eine Mbglichkeit, die nur durch die starke Stan-
dardorientierung gegeben war.
Anmerkung: Die LSX-Unterstutzung hiuft aus. Die Umstellung auf
Lotus Enterprise Integration (LEI) ist geplant.

6.2 Beispiel 2
Ein weiteres Praxisbeispiel (vgl. Abbildung 34) zeigt, wie der
TUV-Geschaftsbereichs fUr Zertifizierung, der seine Gesellschaf-
ten mit einer R/3-Eigenentwicklung auf den verschiedenen R/ 3-
Systemen in Europa, Asien und Amerika unterstutzt, nunmehr

55
Chancen und Risiken einer Konzernstrategie zum weltweiten Einsatz von SAP Rl3

eine Integration dieser Anwendungen anstrebt. Diese Integration

war im Projekt der Eigenentwicklung nicht absehbar. Auf Grund-
lage die IT-Strategie (gleiche Anwendungsstrukturen, Standard-
orientierung auch bei Eigenentwicklung, usw., wie dargestellt),
wird tiber RFC-Technik nun eine Erweiterung zur systemtiber-
greifenden und weltweiten Information mit Zertifizierungsdaten
zusatzlich realisiert.
Die Pramissen des Projekts sind in Abbildung 35 aufgefUhrt. Sie
sollen hier die grundlegenden Anwendungsprobleme nur be i-
spielhaft beschreiben. Ftir den Ausbau der Anwendung sind kei-
ne neuen technischen Voraussetzungen erforderlich.

Company n Company q

Al3 Newtown

Company z

Abbildung 34: Projekt "Weltweite Rl3-Integration der eingesetz-

ten R/3-Eigenentwicklung fUr die Zertifizierungs-
Untersttitzung"

tiber den Zugriff zu einem beliebigen Rl3 k6nnen direkt auch

relevante Zertifizierungsdaten der tibrigen Rl3-Systeme selektiert
und in konsolidierten Informationssichten dargestellt werden.

56
 Arno Kuhn

Project- Rules:
vResults in "Iogin language"
vProgram based internal communication in "E"
vSpecial authorization objects necessary
v no "background -processing"

v "Server- selection" in addition (with information, if server is

down)
v'Option: Web- based information routing

Abbildung 35: Beispiel mit Pramissen fUr das Projekt "Weltweite

R/ 3-Integration der eingesetzten R/ 3-Eigenent-
wicklung fUr die Zertifizierungs-Unterstiitzung"

7 Probleme/Risiken der starken SAP-Orientierung

Die Abhangigkeit von der "SAP" ist groB. Auch bei der einge-
schatzten Zukunftssicherheit im Vergleich zu anderen Playern
am Markt bleibt ein Risiko, denn die Abkehr von "SAP" wurde
ganz erhebliche Investitionen erfordern und ware bei dem der-
zeitigen Status der TOV-Anwendungen nur in Teilschritten und
"uber Jahre" m6glich.
Derzeit fUhrt die Produktpolitik der "SAP" zu Verunsicherung.
"SAP" braucht Wachstum und ist auch aus diesem Grunde zu
immer kurzfristigeren Produktanderungen als bisher in der "rei-
nen" R/ 2- und Rl3-Vergangenheit gezwungen. Die Transparenz
kann so schnell verloren gehen.
"SAP" ist mit seiner anerkannt hohen Funktionalitat augerst
komplex. Auch permanente Entwicklung von unterstiitzenden
Tools zur Beherrschung dieser Komplexitat relativieren die Prob-
lematik bisher nur. Es werden in der Projektarbeit spezialisierte
Fachkrafte mit relativ hohem Marktwert ben6tigt.
Ebenso erfordert das permanente Change-Management erhebli-
che Aufwendungen. Die zusatzliche Einbindung neuer SAP-
Produkte (z.B. mySAP.com), u.a . mit spezieller SAP-Middleware,
sowie die notwendige Rl3-Integration Cabsehbar mit dem Pro-
dukt R/3 Enterprise) wird hier eher weiter komplizieren.

57
Chancen und Risiken einer Konzernstrategie zum weltweiten Einsatz von SAP Rl3

Die starke SAP-Orientierung kann psychologisch bei den an der

Projektdurchfuhrung beteiligten Personen und Entscheidungstra-
gern zu einer zu engen "SAP-Sicht" fUhren. Die Gefahr des Ober-
sehens anderer guter Lbsungen des Softwaremarktes, selbst in
Teilbereichen, besteht.

8 Zusammenfassende Bewertung
Die IT-Strategie in der Unternehmensgruppe TOV RBB setzt ganz
wesentlich auf Standardisierung durch Einsatz von SAP-Software.
Sie wird wie dargestellt insofern besonders konsequent ange-
wandt, als auch strategische Eigenentwicklungen mittels SAP-
Methodik und -Software realisiert werden. Diese seit Jahren um-
gesetzte "Tool-Strategie" hat weitgehend homogene Anwen-
dungssystemen ergeben. Sie hat fUr die diversen Geschaftsfel-
der/ -prozesse zu erheblichen Optimierungen und hbherer Wirt-
schaftlichkeit gefUhrt. Zusatzlich konnte auch eine Reduzierung
der laufenden Kosten fUr die Anwendungsbetreuung/ -wartung
erreicht werden. Auch fUr die Projektarbeit selbst ist in diesem
Umfeld eine deutliche Produktivitatssteigerung anzufUhren.
Kritisch anzumerken ist, dass die dargestellte starke Standardori-
entierung nicht immer die bestmbgliche Lbsung erreicht und den
anfordernden Fachbereichen und Gesellschaften Kompromissbe-
reitschaft abfordert Cauch ggf. nur die "zweitbeste Lbsung" ak-
zeptieren).
Die positiven Erfahrungen fUhren zur Ausweitung der SAP-
Strategie und Nutzung weiterer neuer SAP-Produkte Cu.a. CRM
und Web Application Server geplant), auch unter angemessener
Berucksichtigung der genannten Risiken. Eine moderne und
wirtschaftliche IT-Unterstutzung ist ohne an Standards orientierte
StrategiemaBnahmen mit dem fUr den Markt notwendigen Tem-
po zur Erneuerung und Veranderung nicht mehr mbglich. Nur
Mut zu einer Strategieentscheidung!

58
 ArnoKuhn

9 Literatur
BUXMANN, P.; KONIG, W.: Zwischenbetriebliche Kooperation auf
Basis von SAP-Systemen - Perspektiven fur Logistik und Servi-
cemanagement, Berlin - Heidelberg 2000.
HEUP, T.: Prozessbezogene Integration von ERP- und Groupware-
systemen am Beispiel SAP R13 und Lotus Notes, Diplomarbeit
an der FH K61n, Fachbereich Informatik, 552000.
HOFF1IIANN, A.; ZICI-I, A.: Unternehmensstrategie nach dem E-
Business-Hype, Bonn 2000.

59
 Teil II: Technoiogien

TellO

Technologien

61
 Ullrich Svenson und Hubert Robens

VerfOgbarkeit und Oberwachung von "mission-critical"-Systemen

am Beispiel SAP R/3

Ullrich Svenson und Hubert Robens

1 Einleitung
Abhiingigkeit Moderne, effiziente Unternehmen sind mehr denn je auf die
der Unterneh- standige VerfUgbarkeit ihrer Informationstechnologie angewie-
men von Sys- sen.
temveifugbar- Das Rl3-System der deutschen SAP AG hat sich weltweit als fUh-
keit rende LOsung betriebswirtschaftlicher Standardsoftware durchge-
setzt. Am Beispiel des R/3 -Systems kann die Abhangigkeit ver-
schiedener Unternehmen von ihrer Informationstechnologie auf-
gezeigt werden. Zentrale Frage ist hierbei, fUr welche Unterneh-
mensfunktionen das R/3-System eingesetzt wird.
Beispiele der Exemplarisch seien hier Einsatzmbglichkeiten eines R/3-Systems,
Abhiingigkeit aufgelistet nach steigendem Anspruch an die VerfUgbarkeit, dar-
gestellt:
Personalabrechnungssystem einer Konzernzentra-
Ie.
Der wesentliche Einsatz des R/3 besteht hier in der mo-
natlichen Lohn- und Gehaltsabrechnung. Eine kritische
Ausfallsituation entsteht nur, wenn das System zum Mo-
natswechsel mehrere Tage am StOck nicht zur Verfugung
steht.
Online Shop im Internet
Wahrend der Systemausfallzeit kbnnen Kunden keine
neuen Auftrage uber das Internet anlegen . Einige Kun-
den werden ihre Bestellung spater nach Ende des Sys-
temausfalls anlegen, andere die alternativen Bestellmbg-
lichkeiten per Post, Fax oder Telefon nutzen. Wieder
andere Kunden werden stattdessen einen anderen Liefe-
ranten wahlen, der online verfUgbar ist, so dass der Auf-
trag verloren geht.

63
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP Rl3

Rezepturen in der Fruchtsaftherstellung

Da auf Grund stets unterschiedlicher Qualitit der Roh-
stoffe in der Fruchtsaftherstellung die mitunter komplexe
Rezeptur des gewunschten Endprodukts fUr jede einzel-
ne Charge neu errechnet werden muss, fUhrt ein Ausfall
des Computersystems hier binnen kurzester Zeit zum
Produktionsstillstand.
Lagerverwaltung, Lieferausgang, Logistik in der
Automobilzulieferindustrie
Hier sind durch einen Ausfall des R/ 3 wichtige Unter-
nehmensfunktionen betroffen. Wenn z.B. Frachtpapiere
mit Barcode gedruckt werden mussen, kann der Versand
diese Tatigkeiten kaum manuell ausfUhren. Gerade in
der Automobilindustrie kann das Ausbleiben von Waren
eines Zulieferers im Extremfall zum Stillstand der Pro-
duktionsanlagen fUhren, wie etwa 1998 im Kainer Ford-
Werk geschehen, als die Firma Kiekert, Lieferant der
SchlieBanlagen von Mondeo und Fiesta, von Software-
problemen betroffen war.
Instandhaltung, Ersatzteillagerverwaltung am
Hochofen
Bei einer Lagerung von Ersatzteilen in einem groBen, au-
tomatisierten Hochregallager kbnnen bei Ausfall des
Softwaresystems bestimmte dringend benbtigte Teile
nicht ohne Systemunterstutzung gefunden werden. 1m
schlimmsten Fall kbnnten dadurch wichtige Instandhal-
tungsarbeiten, z.B. am Hochofen, verzbgert werden, so
dass es zum Stillstand der Anlagen kommen kbnnte.
Es gilt nun abzuschatzen, welcher Schaden dem jeweiligen Un-
ternehmen durch einen Ausfall des R/3-Systems entstunde. Hier
ist jeweils eine Einzelfallprufung nbtig. Der minimale Schaden ist
jedoch die nachzuholende Arbeitszeit, urn die wahrend der Sys-
tem-Downzeit auf Papier notierten Informationen in das System
einzugeben. Den maximalen Schaden wird in der Regel der Still-
stand der Produktionsanlagen oder eine Vertragsstrafe wegen
nicht termingerechter Lieferung ("just in time") darstellen.
A bschatzung Eine einfache Beispielrechnung zeigt, wie der Unternehmenser-
des Schadens folg von def VerfUgbarkeit solcher Softwarelbsungen abhangt,
durch System- die von den Mitarbeitern benbtigt werden, urn ihre Arbeit zu
ausfall bewaltigen.

64
 Ullrich Svenson und Hubert Robens

Die Kernzeit eines Unternehmens betrage werktaglich 6:00 bis

20:00. Die angenommene Systemverftigbarkeit liege bei 99,00%
99,00% VerWgbarkeit bedeuten
Ausfall jeden Tag von 9 Min
Ausfall einmal pro Woche von 45 Min
Ausfall pro Monat von 3 Std
Ausfall pro Jahr von 36 Std oder ca. 2,5 Arbeitstage
Beispiel: Eine Verbesserung der Verftigbarkeit urn 0,05%, d.h. 1,8 Std. be-
0, 05% Verfiig- deutet bei 1000 Mitarbeitern mit internem Stundensatz von 30
barkeit ent- Euro in unserer Bespielrechnung eine Einsparung von 54 .000 Eu-
spricht 54.000 roo
Euro Diese Beispielrechnung der Verbesserung der Verftigbarkeit von
99,00% auf 99,05% lasst die Dimension des Problems direkt er-
kennen, obgleich hier nur mir dem internen Stundensatz der
Mitarbeiter gerechnet wurde und weitere Faktoren wie der Scha-
den an Kundenbeziehungen vbllig auBer Acht gelassen wurden.
Aus dieser Abschatzung des Gefahrenpotenzials erwachst die
Forderung nach permanentem Monitoring dieser Systeme und
einer weitgehend automatisierten Reaktion im Fehlerfall, urn
Ausfalle der betrieblichen IT-Infrastruktur zu minimieren.

2 Strategien zur Erhohung der IT-SystemverfOgbarkeit

Die IT-Systemverfugbarkeit kann durch verschiedene Strategien
erhbht werden. Diese im folgenden aufgefuhrten vier Strategien,
namlich vertraglich, organisatorisch, technisch reaktiv und tech-
nisch proaktiv, stehen dabei nicht in Konkurrenz zu einander,
sondern erganzen sich auf verschiedenen Ebenen.
Einige der genannten Punkte mussen yom IT-Dienstleister in Ei-
genregie gemanagt werden, ohne dass der IT-Anforderer in die
Details involviert ist. Trotzdem ist das Wissen urn diese MaB-
nahmen wichtig zur Beurteilung der Leistungsfahigkeit des
Dienstleisters. Dabei ist besonders zu beachten, dass ein IT-
System per Definition nur dann zur Verftigung steht, wenn der
Endanwender mit dem System performant arbeiten kann. Somit
ist hier ganzheitlich die gesamte Systemumgebung von den End-
geraten, uber das Netzwerk (WAN, LAN) und die Server bis zur
Applikation zu betrachten .

65
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP Rl3

Zwischen dem IT-Dienstleister und dem IT-Anforderer sollten

vertragliche
genau spezifizierte Leistungspakete definiert werden . Dies ist
Strategie
wichtig in Bezug auf die zu erbringenden Leistungen, aber auch
auf deren Qualitat. Aus Sicht der SystemverfUgbarkeit ist beson-
ders auf folgende Punkte zu achten :
genaue Spezifikation der betreffenden Komponenten
(Hardware , Software, Netz),
Betriebszeiten (z .B. 7*24 Std),
mittlere VerfUgbarkeit innerhalb und auBerhalb der
Kernarbeitszeit,
Antwortzeitverhalten, zur Ermittelung des Antwortzeit-
verhaltens sollten Programme und Transaktionen heran-
gezogen werden, deren Antwortzeit nicht von der Selek-
tion oder Parametrisierung des Benutzers abhangen.
(z.B. 0,8 sec),
maximale Ausfallzeit, Time Back to Service' (z.B. 90
min),
Servicezeiten (z.B. 6:00 bis 23:00) mit Aussage bis wann
ein qualifizierter Ri.ickruf erfolgt (z.B. 30 min),
Eskalationsprozedur (wer wird wann durch wen infor-
miert),
Wartungsfenster (z.B. jeder achte Sonntag 10:00 bis
18:00),
Reporting aller aufgefUhrten Vertragsinhalte,
Rechnungsminderung und Haftung,
AuBerordentliches Ki.indigungsrecht.
Die vertraglichen Vereinbarungen sollten nicht nur im Outsour-
cing Verhaltnis verwendet werden, sondern auch gegeni.iber ei-
nem internen IT-Dienstleister. Auch dieser muss sich an seiner
Qualitat messen lassen .
Neben dem IT-Dienstleister ist nati.irlich auch der Softwareliefe-
rant fUr die Verfi.igbarkeit von Systemen verantwortlich. Deshalb
muss geregelt sein, wann und in welcher Zeit dieser zur Lasung
von Softwareproblemen zur Verfi.igung steht.
organisatorische Wichtig fur die VerfUgbarkeit ist das Vorhandensein von qualifi-
Strategie ziertem Personal. Dies gilt sowohl fUr die hardwarenahen Sys-
temteile (Rechner, Betriebssystem, LAN, WAN), fUr das R/3 Ba-

66
 Ullrich Svenson und Hubert Robens

sissystem und die Datenbank als auch fUr die Anwendungs-

betreuung. Ein System steht auch dann nicht zur VerfUgung,
wenn z.B. aufgrund von falschem Customizing ein Buchungsstop
ausgesprochen werden muss. Hier sind insbesondere die folgen-
de Themen zu regeln:
regelmalSige FortbildungsmalSnahmen,
Vertretung bei Urlaub und Krankheit,
Rufbereitschaft (z.B. 7*24 Std.) einschlielSlich Fernzugriff
(meist mittels ISDN), urn die Fahrtzeit ins Biiro einzuspa-
ren ,
Standards der Administrationsarbeit und verteiltes Wis-
sen, urn einen moglichst breiten Personalstamm zur Ver-
fiigung zu haben.
technisch reak- Damit der Ausfall einer einzelnen Systemkomponente nicht zum
tive Strategie Ausfall des gesamten Systems fUhrt, haben fast aile Hersteller von
Serverlosungen fUr unternehmenskritische Bereiche inzwischen
redundant ausgelegte Systemkomponenten im Angebot, welehe
so genannte "Single Points of Failure" vermeiden. 1m Fall einer
Fehlfunktion in soleh einer redundant ausgelegten Komponente
iibernimmt die bereitstehende Reservekomponente innerhalb
kurzer Zeit die Funktion der ausgefallenen .
Beispiele soleher redundant ausgelegter Systeme sind:
Clusterlosungen, bei denen jeweils ein kompletter Server
die Funktion eines anderen iibernimmt, z.B. HACMP von
IBM oder MSCS von Microsoft.
Standby Recovery Datenbanken, die einen wenige Stun-
den in der Vergangenheit zuriickliegenden Zustand des
Systems wiederspiegeln. 1m Fehlerfall der Originaldaten-
bank wird die Standby Recovery Datenbank bis kurz vor
die Fehlersituation recovert und iibernimmt dann den
Platz des Originals.
Unterbrechungsfreie Stromversorgung (USV) durch dop-
pelte Netzteile, mehrere Stromleitungen oder Akkus.
Redundant ausgelegte Netzwerke im LAN und WAN.
technisch pro- Monitoring durch qualifizierte Administratoren und geeignete
aktive Strategie Monitoringsoftware sollen entstehende Problemsituationen er-
kennen und auflosen, bevor es zum Ausfall von unternehmens-
kritischen Systemkomponenten kommt.

67
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP Rl3

Dieses technisch proaktive Monitoring wird irn weiteren Verlauf

des Kapitels beschrieben.

Sicherung der Systemverfugbarkeit

vertraglich I

I technisch proaktiv
organisatorisch

Abbildung 36: Sicherung der Systernverfugbarkeit durch vier in-

einander greifende Strategien

3 Ziele des Monitorings

Das proaktive Monitoring eines Softwaresysterns hat zur Haupt-
aufgabe, dafilr zu Sorgen die Systernverfilgbarkeit weitestgehend
zu optirnieren. Zu diesern Zweck wird einerseits der qualifizierte,
aufrnerksarne Systernadrninistrator benotigt, andererseits aber
auch spezielle Monitoringsoftware, die rund urn die Uhr ein au-
tornatisiertes Monitoring errnoglicht.
automatisiertes Hier sind irn Wesentlichen vier Kernziele des autornatisierten
Monitoring Monitoring zu nennen:
durch spezielle Autornatisiertes Monitoring schlieBt rnenschliches Versa-
Monitoringso!t- gen weitgehend aus.
ware
Auftretende Problerne sollen sofort an die zustandige
Stelle weitergerneldet werden.
Entstehende Problerne sollen irn Anfangsstadiurn gernel-
det werden, noch bevor es zurn Ausfall von unterneh-
rnenskritischen Systernkornponenten kornrnt, so dass ge-
nugend Zeit bleibt, die Fehlersituation abzuwenden.
Auf ausgewahlte Fehler soli direkt eine autornatisierte
Reaktion erfolgen, ohne dass ein rnanuelles Eingreifen
der Systernadrninistration notig ist.

68
 Ullrich Svenson und Hubert Robens

Jedes Monitoringkonzept muss sich an diesen Kriterien messen

lassen.

4 Problemindikatoren
Abhangig von der zu uberwachenden Software gibt es beim Mo-
nitoring verschiedene, jeweils spezifische Indikatoren fur Prob-
leme. Einige haufig wiederkehrende Problemindikatoren sind in
der folgenden Liste zusammengestellt:

FiiUgrad von Filesystemen

Betriebssystem: / var, C:
Rl3-System: / usr/ sap/ PRD/ SYS/ global
Datenbank: / oracle/ PRD/ saparch
Schnittstellen: / usr/sap/ PRD/ EDI
Existenz und Anzahl von Prozessen
Betriebssystem: lpd
Rl3-System: disp+work.exe
Schnittstellen: EDIscript.ksh
FiiUgrad von Datenbank-Tablespaces
Antwortzeit des Rl3-Systems im Dialog

Beispiel einer zu Solche typischen Problemindikatoren seien nun am konkreten

iiberwachenden Beispiel einer mittelstandischen Firma dargestellt.
Systemland- Das Unternehmen hat einen Standort, an dem Produktion und
schaft Verwaltung gemeinsam arbeiten. 300 PCs sind dort uber ein LAN
vernetzt. Die relevanten Serversysteme sind ein Rl3 und ein Alt-
system namens Legacy, beide laufen auf Basis der Datenbank
Oracle und einem Unix Betriebssystem. Daruber hinaus gibt es
einen Faxserver und eine EDI-Schnittstelle zu verschiedenen
Kunden.

69
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP R/3

Abbildung 37: Beispiel einer zu uberwachenden Systemland-

schaft

Foigende Funktionen und Komponenten sollten nun uberwacht

werden:
Netz: Verbindung zwischen Servern und Frontend-PCs, all-
gemeine Netzlast
Unix: Paging, CPU-Last, Fullgrad Filesysteme, Fullgrad Swap-
space
Oracle: Alertiog, Backups, Archivverzeichnis, Pufferqualitat,
Fullgrad Tablespaces
R/ 3 Syslog, Dialogantwortzeit, Batchjobs, Schnittstellen,
Pufferqualitat
Legacy Applikationslog, GroBe der Druckdatei
Fax: Log, RFC-Verbindung, SAP connect
ED!: Fullgrad Schnittstellenverzeichnis, Alter der altesten Da-
tei, ftp
Abbildung 38: Zu uberwachende Funktionen und Komponenten

5 Zentrales Monitoring und organisatorische Aspekte

zentrale Melde- Je umfangreicher die zu uberwachende IT -Infrastruktur, urn so
stelle fur Alerts wichtiger ist es fUr die Systemadministration, dass aile auftreten-
den Alerts von der Monitoringsoftware an eine zentrale Stelle
gemeldet werden, damit nicht mehrere Monitoringsysteme paral-
lel uberwacht werden mussen.
Verteilung der Andererseits ist es wichtig, die von der Monitoringsoftware ge-
Alerts nach Ka- meldeten Alerts in verschiedene Kategorien unterteilen zu kon-
tegorien nen, urn sie zustandigen Personen oder Gruppen zuordnen zu
konnen. So konnen die eingehenden Alertmeldungen z.B. unter-
teilt nach Netz, Datenbank oder R/3 weitergeleitet werden. Ein
anderer denkbarer Fall ware die Aufteilung der Alerts nach Kun-

70
 Ullrich Svenson und Hubert Robens

den eines Rechenzentrums, so dass aile Problemmeldungen zu

den Systemen von Kunde A einer Arbeitsgruppe libermittelt
werden, die Alerts zu Kunde B jedoch einer anderen Arbeits-
gruppe.
Problemveifol- Nicht identisch zu, aber haufig Hand-in-Hand mit Monitoringlb-
gung sungen arbeiten Tools zur Problemverfolgung, so genannte
Trouble Ticket Systeme. Sie sollen Problemsituationen mit Zeit-
stempeln und der Angabe der beteiligten Personen dokumentie-
ren und die Kommunikation zwischen allen an der Problemlb-
sung Arbeitenden verbessern. Insbesondere ergibt sich hier die
Mbglichkeit, vordefinierte Eskalationsprozeduren zu hinterlegen,
falls ein Problem nicht in einer vorgegebenen Zeit gelbst werden
kann.
Ais positiver Nebeneffekt solcher Trouble Ticket Systeme kann
ein regelmaBiges Reporting betrieben werden, welches es
ermbglicht, Starken und Schwachen der eigenen IT-Organisation
bei der Problembehebung zu erkennen. Weiter kbnnen aus den
gelbsten Problemsituationen der Vergangenheit Prognosen fUr
zuklinftiges Problemmanagement erstellt werden, die Z.B. die
Basis fUr vertragliche Vereinbarungen zur VerfUgbarkeit bilden
kbnnen.

6 Anbieter von Monitoringsoftware

Diverse Softwarehersteller bieten spezialisierte Monitoringsoftwa-
re zur Uberwachung von Systemlandschaften an. Exemplarisch
seien hier die folgenden fUnf Monitoringlbsungen genannt, die
auch SAP-Softwarekomponenten iiberwachen kbnnen und am
Markt weit verbreitet sind.
Anbieter von BMC Patrol, www.bmc.com.
Monitoringl6su
Tivoli, www .tivoli.com.
ngen
Candle, www.candle.com.
Realtech TheGuard!, www.realtech.de.
Computer Associates Unicenter Management for SAP
www.ca.com.
All diese Monitoringtools greifen auf die von SAP an speziellen
Schnittstellen (MIB, XMI, XMB) iibergebenen Daten zu, welche
Auskunft liber den Zustand des R/3 geben. Darliber hinaus iiber-
wachen sie Teile des Betriebssystems wie Filesystemfiillgrad oder
CPU-Verbrauch. In diesem Kernbereich des R/3-Monitorings sind

71
Verfugbarkeit und Oberu;achung von "mission-critical"-Systemen am Beispiel SAP Rl3

die Unterschiede zwischen den Monitoringlosungen der genann-

ten Anbieter also gering.
Auswahlkrite- Ais Auswahlkriterien fUr das geeignete Produkt dienen daher
rien der Monito- Preis, Anbindbarkeit an eine zentrale Monitoringstation, Einstell-
ringlosung barkeit/Customizing, zentrale Administration, Zuverlassigkeit und
mogliche Synergieeffekte durch die Dberwachung anderer Soft-
warekomponenten mittels der selben Monitoringoberflache.

7 Alternativer Ansatz: Usersimulation

Prinzip der Usersimulationstools nutzen die Standardoberflache eines Sys-
Usersimulation tems, in genau der selben Weise, wie sie auch die Enduser se-
hen, und fuhren darauf Programme und Transaktionen durch
wie es auch die Benutzer tun. Dabei werden Antwortzeit und
auftretende Fehlermeldungen uberwacht. Z.B. konnte im 90-
Sekunden-Takt eine Bestellung an die Firma "NoExist GmbH"
aufgegeben werden. Wenn die Transaktion nicht in weniger als
beispielsweise 30 Sekunden durchlaufen wird, gibt es eine Alert-
meldung.
Gelegentlich auftretende Netzwerkprobleme eines kleinen tiber
WAN angebundenen Standorts konnten so effektiv uberwacht
werden.
Solche Methoden der Usersimulation bieten im librigen eine gute
Mbglichkeit, die tatsachliche SystemverfUgbarkeit aus Sicht der
Endanwender zu ermitteln. Eine auf dieser Basis gewonnene Sta-
tistik eignet sich auch hervorragend als vertraglich vereinbarter
Indikator der allgemeinen SystemverfUgbarkeit
Bei Usersimulation wird implizit immer das Zusammenspiel aller
beteiligten Komponenten getestet, so dass auch Probleme ent-
deckt werden, die man bei der separaten Oberwachung einzel-
ner Komponenten nur schwer erkennen wurde.
Vorteile und Der groJSe Vorteil der Methode der Usersimulation ist, dass man
Nachteile der in jedem Fall die Enduserperspektive eines Problems bekommt.
Usersim ulation Alle fur die Enduser in den Fachabteilungen relevanten Kompo-
nenten werden gleichzeitig uberwacht. Insbesondere bekommt
man die realen Antwortzeiten eines Systems, wie sie yom Benut-
zer erlebt werden.
Ein nicht zu unterschatzender Nachteil dieser Monitoringmethode
ist jedoch, dass die technischen Details von Problemen haufig
nicht direkt zu erkennen sind. Usersimulation ermittelt im Regel-
fall nur, dass ein Problem besteht, stellt aber keine Hintergrund-

72
 Ullrich Svenson und Hubert Robens

informationen uber die Ursache des Problems zur Verfiigung.

Proaktives Monitoring ist dadurch erschwert. Z.B. wird ein lang-
sam vollaufendes Filesystem so nicht erkannt, sondern lost erst
dann eine Meldung aus, wenn es bereits ubergelaufen ist.
Die Methoden des automatisierten Monitorings und der Usersi-
mulation erganzen sich somit und konnen zusammengenommen
eine sehr effektive Systemuberwachung bilden.
AbschlieBend seien hier noch zwei kommerziell erhaltliche Soft-
warepakete zur Usersimulation genannt:
Gedos Chief, www.gedos-software.de.
Mercury QuickTest & Topaz,
www.mercuryinteractive.com.

8 Monitoring mit Tools des ERPStandards

Komplexe Softwaresysteme besitzen heute fast ausnahmslos ein-
gebaute Monitoringfunktionen. Herstellerabhangig werden hier
nur sehr einfache Funktionen wie Applikationslogs auf Filesys-
temebene angeboten oder auch verbesserte Monitoring-
funktionen wie z.B. eine Integration der Software in das Win NT
Eventlog oder die Oracle V$Tabellen. Wir widmen uns im fol-
genden der Monitoringinfrastruktur des SAP R/3-Systems.
Konzept des Rl3 Das grundsatzliche Konzept des SAP R/3-Systemmonitorings be-
Alertmonito- steht darin, dass alle zu uberwachenden Komponenten Alertmel-
rings der SAP dungen an eine zentrale Dberwachungsstelle senden. Diese A-
lerts sind nach Ihrer Wichtigkeit als "gelber Alert" oder "roter A-
lert" gekennzeichnet. Dabei bleibt ein Alert solange bestehen, bis
er von einem Administrator guittiert wird. Bis der Alert guittiert
ist, wird die zugehorige Systemkomponente als mit dem Alert
"belegt" betrachtet und in der entsprechenden Alertfarbe, d.h.
gelb oder rot dargestellt.
Die Monitoringtools des Rl3-Systems gibt es in zwei Ausfiihrun-
gen:
Die alte Version 3.X, die aber bis Rl3 Version 4.5 weiter
genutzt werden kann und sich immer noch groBer Be-
liebtheit erfreut.
Die neue Version 4.X, die ab R/3 Version 4.6 das alte
Monitoring endgultig ablost.

73
Veifugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP R/3

8.1 Alte Version 3.X, Transaktion 'RZ03'

Das R/ 3 wird in 11 Kategorien eingeteilt. Fur jede Kategorie gibt
es eine Statuszeile, die uber angefallene Alertmeldungen infor-
miert. Ein Doppelklick auf eine Zeile zeigt die Details des Alerts
Cvgl. Abbildung 39).

--------~-- ------------------------------------ ~
(~
})"6)
.....m .
or\,r..... ~.

CtIH " ~Jt""OJ ace"" ..

r'ff1C11r "'. P{I
.. t1.rl ,.
~. Ctrora am ttn 'll. ft'ret')" oet,,ru .~" kU:U''', l
lIt'lIPi!1'1"4 n[n
1,... It'. Iio<tfU

- k.t.,et.,h-------
Ot~ _nor ..l 1ft"'"
lh.. h Y[ll lW U "tt
HLlIJiII' ko)l)l U ..
.", ,~ ,c:r t
""n J" .'''' .
V/'ftS!tYD ~H~nl'l IS'IK"tO
'~LDIl
(_teI

ha r~J "9I"''''~

DuO il![U
.ft:.lW f ;:) h '.,.., ~~.at'~'~I'" "fill :'11 &11.

Abbildung 39: Oberflache des 3.X Alertmonitorings ( SAP AG)

In dieser alten Version 3.X, des R/ 3-Monitorings, auch CCMS-

Monitoring genannt, wird das Monitoring separat pro SAP-System
durchgefuhrt. Zwar kbnnen mehrere R/3-Instanzen gemeinsam
uberwacht werden, die oben aufgestellte Forderung, dass aile
auftretenden Alerts von der Monitoringsoftware an eine zentrale
Stelle gemeldet werden, damit nicht mehrere Monitoringsysteme
parallel uberwacht werden mussen, bleibt aber unerfUllt.
Zur L6sung dieses Problems bieten sich verschiedene Vorge-
hensweisen an:
Parallele manuelle Dberwachung aller R/ 3-Systeme
(DEV, QAS, PRD)
Einsatz von zusatzlichen Dberwachungstools eines Dritt-
anbieters (Candle, CA, BMC, ... )
Konfiguration des 3.X CCMS-Monitoring so dass Alerts
als Email/SMS an zentrale Stelle geschickt werden (DV-
ORG).

74
 Ullrich Svenson und Hubert Robens

8.2 Neue Version 4.X, Transaktion 'RZ20'

Die einzelnen Komponenten des R/ 3 sind hierbei nicht langer in
vorgegebene Kategorien eingeteilt. Stattdessen kbnnen aile
Komponenten und somit aile Alerts in hierarchischen Baumstruk-
turen geordnet werden. Die Baumstruktur ist dabei frei konfigu-
rierbar. SAP liefert einige solcher Strukturen als Beispiele mit
dem R/3-System aus. Letztlich sollte die Systemuberwachungs-
gruppe sich aber einen Monitoringbaum zusammensteUen, der
den speziellen Erfordernissen des Unternehmens gerecht wird.

:)1 .... 1 e>.ltll ~'''_ .'.tn 1\V r"r (r rar"' '''I I~~. II Cle Itl 0
1),11 ~ I. 0
:u ~1Il W I
..:t..e&1.: ~
lulrtu'- ..j""~l ).t " G
;)4'~"IOL"'riWlIJ)U<; 0
2)4\' '' 'QL'' '''''_~ J4 _16 0
ntlO IOJ IOL"' .... ,_ZJ.l_'f 0
1'W\~.' 0
:)4' Ml ...11'_" 0
:J.4I-..e'_lJIJ)' 0
nU~'_ZJ~_n 0
~)4\tO'\"H'J'4_'. 0
n:~~:-~!~;~~.r .t'."
2).1 1""';r0Ul'l4
80

Abbildung 40: Oberflache des 4.x Alertmonitorings ( SAP AG)

Die einzelnen Baumknoten lassen sich aufklicken, urn den Blick

auf die unter einem Baumknoten zusammengefassten Kompo-
nenten freizugeben (vgl. Abbildung 41).

75
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP Rl3

t"' l1U

nt ...1 . . 1 1'.: I""'lor h. blur*r I M 11 'IIC III 0

:n"".a-. lJlI.tJ HJIS a

:n4 ' ~06' JJ '_ll Q
ZJA1..,.,MtJUJ5 0
l J.t' ..".' _l U.r. 0
_ IJ4 , .,..!MIJU_U 0
1)4\' rlt" (o,11r;111.t\'M 0
1'J,t ,t.(~ or ......~ 0

Abbildung 41: Alertmonitoring-Menubaum ( SAP AG)

Ein Doppelklick auf einen Knoten im Baum fUhrt zu einer Liste

aller ihm untergeordneten Alerts. Ein Doppelklick auf den obers-
ten Knoten der Baumhierarchie, d .h. den Wurzelknoten, liefert
somit eine Liste aller unerledigten Alerts.

.:.

~~
M ~~~~~
~ . ~
.~
~,~
. ~
~ ~~
~.~~~ ____________________________________________ ___
~_.m (~ ~.1 tvI

Abbildung 42: Liste aller unerledigten Alerts ( SAP AG)

76
 Ullrich Svenson und Hubert Robens

In der neuen Version 4.X des CCMS-Monitorings kann die Dber-

wachung systemiibergreifend durchgefUhrt werden. Die gesamte
IT-Landschaft im Umfeld einer oder mehrerer R/ 3-Systemfamilien
(DEV, QAS, PRD) hisst sich somit zentral iiberwachen, inklusive
peripherer Komponenten wie Filesysteme oder LAN.
Customizing der Gleichzeitig ermbglicht der Bau spezieller Monitoringbaume, die
Oberjldche jeweils nur ausgewahlte Aspekte der Gesamtsituation darstellen,
eine Unterteilung der potentiellen Problemsituationen, urn sie
den zustandigen Gruppen direkt zuordnen zu kbnnen. Damit
kbnnen zur Dberwachung einer Systemlandschaft mit 20 Syste-
men z.B. drei Monitorbaume geschaffen werden, die jeweils den
Datenbankaspekt, den Netzwerkaspekt und schlieBlich den R/ 3-
Basis-Aspekt abbilden.
Auch in diesem Umfeld des 4.X CCMS-Monitorings ist es mbg-
lich, R/ 3 so zu konfigurieren, dass Alerts als Email/ SMS an zu-
standige Stellen geschickt werden (DV-ORG).
SAP Monitoring- In diesem Kontext des neuen 4.X Monitorings muss erwahnt
Agenten im werden, dass die SAP in zwischen die Mbglichkeit bietet, auch
SAP-Umjeld das Umfeld von SAP-Systemen in das R/ 3-Monitoring einzubin-
den. So kann z.B. ein SAP Monitoringagent als separater Prozess
einen Fileserver uberwachen, der zwar nicht direkt zum R/3-
System gehbrt, aber trotzdem fUr die Funktion der gesamten IT-
Landschaft wichtig ist.
Mit Hilfe dieser Agentenprogramme wird der Nutzen des Monito-
rings aus dem R/3 CCMS heraus betrachtlich erweitert.
Neuerdings bietet SAP auch Agenten, die auf andere Software-
komponenten spezialisiert sind und deren Status an einen R/ 3-
Monitor melden; so z.B. fUr den Internet Transaction Server oder
EM C-Plattensysteme.

9 Oberwachung einer komplexen Systemlandschaft am

Beispiel der Vodafone Information Systems GmbH (VIS)
VIS hat 1998 mit der automatischen Dberwachung seiner SAP
R/3-Systemlandschaften begonnen. Dieses Monitoring erstreckt
sich derzeit auf 140 R/3-Systeme der Versionen 3.11 bis 4.6C auf
Basis von Oracle und SAPDB sowie Solaris und HP-UX.
Als zentrale Dberwachungskonsole wird Tivoli verwendet. Aile
Alerts der verschiedensten IT-Komponenten werden hier ge-
sammelt und korreliert. Die zentrale Konsole wird rund urn die
Uhr von einem allgemeinen First Level Support (FLS) betreut.

77
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP R13

Tagsiiber stehen iiber entsprechend konfigurierte, dezentrale Ti-

voli-Konsolen die fUr jede Arbeitsgruppe relevanten Alerts den
qualifizierten Administratoren des Second Level Support (SLS) di-
rekt am eigenen PC zur VerfUgung, so dass ohne zeitliche Ver-
zogerung mit der Problembehebung begonnen werden kann.
Nachts informiert der FLS der zentralen Tivoli-Konsole den Ruf-
bereitschaft habenden Administrator des SLS iiber auftretende
Alerts, falls der FLS das Problem nicht seIber beheben kann. Der
SLS greift dann remote auf die betroffenen Systeme zu.

ITivoli Enterprise Console I

I Ereignisquellen I

ARS: REMEDY/ACTION
REQUEST SYSTEM

Abbildung 43: Architektur

Technisch gesehen werden die unterschiedlichen IT-Kompo-

nenten mit entsprechenden Agentenprogrammen iiberwacht.
Diese liefem auftretende Alerts an die zentrale Tivoli-Konsole.
Fiir die R/3-Systeme iibemimmt diese Aufgabe das Monitoring-
tool von Candle. Dieses Tool zeichnet sich insbesondere aus
durch:
Zentrale Administrierbarkeit Czentrale Erstellung und
Verteilung der Alertsituationen).
Einfache Handhabbarkeit von sehr vielen Systemen.
Sehr flexible Einstellbarkeit (z.B. einen Alert auslosen,
wenn die durchschnittliche Antwortzeit einer bestimmten
R/3-Transaktion innerhalb der letzten 15 Minuten iiber

78
 Ullrich Svenson und Hubert Robens

350 msec liegt, aber nur falls diese Transaktion mindes-

ten 20mal aufgerufen wurde).
Anbindung an die Tivolizentrale.
Ais Problemverfolgungssystem wird ARS (Action Request System)
von Remedy verwendet. Jeder kritische Alert wird automatisch
von Tivoli an das ARS weitergeleitet und erzeugt dort ein Trou-
ble-Ticket.
Neben den kritischen und fatalen Alerts wird auch mit "minor a-
lerts" gearbeitet. Diese dienen dazu, die manuelle Oberwachung
der Systeme zu reduzieren. Wenn z.B. der Flillungsgrad eines
Tablespace liber 90% und der gesamte Freiplatz des Tablespaces
unter 4 GB liegt, so erscheint ein "minor alert" . Nun erweitern
die Betreuer des Systems den entsprechenden Tablespace.
Um das Oberwachungsszenario durch eine End-to-End Oberwa-
chung zu vervollstandigen, wurde eine Testinstallation des Tool
TOPAS von Mercury durchgefUhrt. Direkt beim Anwender vor
Ort kann damit aile 5 Minuten die Simulation einer einfachen
R/3-Transaktion durchgeflihrt werden. Bei Problemen werden
entsprechende Alerts zur Tivolizentrale geschickt. So wird eine
Oberwachung durchgeflihrt, die genau der Arbeitsweise des
Endanwenders entspricht. Falls dieser nicht arbeiten kann, z.B.
wegen Netz- oder SAProuter-Problemen, so wird dies von der
Simulation direkt festgestellt. Ober dieses Tool kann auch in ein-
facher Weise ein Report liber das Antwortzeitverhalten aus An-
wendersicht und die SystemverfUgbarkeit erstellt werden.
Informationen Weitere Informationen hierzu und zum SAP Hosting der VIS fin-
den sich unter: www. vodafone-is. del sap

10 Vergleich interner und externer Monitoringtools

Vergleicht man nun die Mbglichkeiten, welche von internen und
externen Monitoringtools geboten werden, um den reibungslo-
sen Betrieb der IT-Systeme eines Unternehmens sicherzustellen,
so findet man sowohl Argumente, die flir die eine Seite spre-
chen, als auch Argumente flir die andere Seite. Welche
Argumente letztlich das grbBere Gewicht besitzen und zur
Entscheidung fUr eine bestimmte Form des Managements des
Systemmonitorings fUhren, kann nur im Einzelfall entschieden
werden.

79
Verfugbarkeit und Oberwachung von "mission-critical"-Systemen am Beispiel SAP Rl3

Argumente fUr externe Tools:

bessere Integration einer Insellandschaft,
bessere, ergonomischere Oberflachen, langere Erfahrung
mit Alerthandling,
Schnittstellen an andere Monitoring/Trouble-Ticket Sys-
teme.
Argumente fur interne Tools:
Preis zum Kauf der Software/Lizenzgebuhren entfallt,
keine weiteren Systeme, die installiert und se1bst admi-
nistriert werden mussen,
deutlich geringerer Implementierungsaufwand,
besseres Know-How der Systemspezifika.

11 Ausblick
Monitoring 1m Rahmen von E-Commerce, EDI, ALE, XML, Internet, my-
unternehmens- sap.com, firmenubergreifenden Workflows entlang der Wert-
ubergreifender schbpfungsketten und "allgemeiner Globalisierung" ist damit zu
Geschiifts- rechnen, dass in der Zukunft immer mehr verschiedene IT-
prozesse Systeme auf unterschiedlichen Maschinen in Netzen verschiede-
ner Firmen in starker Verzahnung an einem gemeinsamen Ge-
schaftsprozess beteiligt sein werden. Urn diese Geschaftsprozesse
zu monitoren wird vermutlich mehr applikationsspezifisches
Know-How benbtigt, als beim traditionellen Monitoring in der
EDV. Wahrscheinlich werden sich die beteiligten Firmen dabei
nicht zu einer zentral uberwachten IT-Landschaft zusammen-
schliel$en, sondern jeweils ihren eigenen Bereich monitoren. Als
Werkzeug der Dberwachung dieser ubergreifenden Geschafts-
prozesse bietet sich somit der Austausch von Statusmeldungen
uber die ausgetauschten Nutzdaten zum jeweiligen spezifischen
Prozess an. Dies kbnnte in Analogie zu Statusmeldungen ge-
schehen, die man bereits aus dem Umfeld von EDI, Idocs und
ALE kennt. Diese Entwicklung kbnnte die Rolle interner Monito-
ringtools aufwerten, da dort eine bessere Integration der Busi-
nesslogik existiert.

80
 Ullrich Svenson und Hubert Robens

12 Zusammenfassung
Moderne, effiziente Unternehmen sind mehr denn je auf die
standige Verfugbarkeit ihrer Informationsteehnologie angewie-
sen.
Es lohnt sieh, in der eigenen Firma Dberlegungen anzustellen,
wie teuer der Ausfall der IT-Infrastruktur werden kann.
Entseheidet man sich fUr eine softwarebasierte Monitoringlbsung,
so gilt es interne und externe Dberwaehungstools kritiseh zu
vergleichen. Fur externe Tools sprieht in der Regel ihre bessere
Integration einer Insellandsehaft versehiedenster Systeme. Fur in-
terne Tools sprieht der geringere Aufwand und das implizit ein-
gebaute Know-How uber die Spezifika des Systems.
1m konkreten Fall einer SAP R/ 3, bzw. mysap.eom Umgebung
sollte man zum externen Monitoring greifen, falls die SAP nur
einen Baustein unter vielen in der betriebliehen IT stellt.
Wenn die SAP-Systeme hingegen den grbBten Teil der benbtig-
ten Funktionalitat der gesamten IT ausmaehen, sollte man den
internen Monitoringtools den Vorzug geben .

8 Literatur
Svenson, u.: Vortrag FH K61n, SAP meets Industry, K61n, 30. No-
vember 2001.
SAP White Paper: "Connection of External System Management
Tools to the Rl3 CCMS - XMB ", http://service.sap.coml
SAP Online Dokumentation: SAP AG MatNr. 500 456 31,
http://help.sap.coml

81
 Reinhard Mayr

HTMLbasierte Kommunikation mit SAP/R3

Reinhard Mayr

1 Einleitung
Vor dem Hintergrund der Flexibilisierung der Industrie werden
standortunabhangige Kommunikationslbsungen immer wichtiger.
HTML mit den zugehbrigen Browsern (Netscape, Internet Explo-
rer) bietet heute auf fast jeder Hardware und unter nahezu jedem
Betriebssystem eine attraktive, interaktive Clientumgebung. Das
Internet als Transportmedium mit seinen Verschlusse!ungstechni-
ken ist geeignet, auch sicherheitskritische Informationen zu uber-
tragen, wie es uns aus unseren Homebanking-Anwendungen
vertraut ist.
Browsereinsatz Es stellt sich die Frage: Kann man den SAP IR3-Client durch eine
Browseranwendung unter HTML zumindest teilweise ersetzen?
Die ersten Gehversuche def FH Kbln auf diesem Gebiet zeigen
die Machbarkeit! 1m Rahmen der Zusammenarbeit mit der Deutz
AG in Kbln und def Sachtleben Chemie GmbH wurden in den
letzten Jahren unterschiedliche Module entwickelt, die direkt aus
dem SAP/R3-System HTML-Code generieren. Das HTML-File
kann von einem beliebigen Standardbrowser verarbeitet werden.
Auch der Ruckweg, also der Maskeneintrag von Daten unter
HTML und die Ruckubertragung der Daten in das SAP IR3-
System, ist unter Java problemlos mbglich.

2 Benutzerorientierte BedienoberfUichen
Das SAP IR3-System ist in allen Bereichen ein sehr machtiges
Werkzeug und dies spiegelt sich insbesondere in seiner komple-
xen Benutzeroberf1ache wider. Fur einen Anwender der nur ge-
legentlich mit dem System umgeht, z.B. ein Werker oder ein
Monteur der einmal wbchentlich Daten eintragen muss, ist die
Bedienoberflache durch die umfangreichen Menustrukturen und
Maskenfolgen zu komplex und es schleichen sich zwangslaufig

83
HTML-basierte Kommunikation mit SAPIR3

Bedienfehler ein. Dies fUhrt dann zu einem inkonsistenten und

unvollstandigen Datenbestand in der Datenbank.
Benutzer- Generell unterscheidet man bei IT-Anwendungssystemen Benut-
gruppen nach zer mit unterschiedlichem Wissensstand:
Wissensstand
Beginner,
Usual,
Advanced.
Entsprechend soUte man auf diese Benutzergruppen mit einem
an den Wissensstand angepassten Benutzerinterface reagieren .
Dies ist aber in der Regel fUr den SystemhersteUer zu aufwendig
und so wird im Systemdesign normalerweise nur der Advanced
User beri.icksichtigt. Die anderen Benutzergruppen gehen meist
leer aus.
SAP hat sich zwischenzeitlich der Problematik angenommen und
eine Abhilfe geschaffen, die eine benutzerorientierte Anpassung
der Standard-Bedienoberfhche erlaubt. Seit dem Release 4.0 bie-
tet SAP/ R3 das Werkzeug GUI XT und User-Exits an. Mit der
Kombination der Methoden kann man in gewissem Mage eine
anwendergerechte Maskengestaltung pro Benutzergruppe erzeu-
gen.
Seit dem Release 4.6B ist diese Methode integraler Bestandteil
von SAP/R3.

84
 Reinhard Mayr

GUI XT
S~npt

I'
-_.../-------.,
- - - - - - - - - --
7
---------------------------------- ------- -----
r-
E]
~ GIJI XT 1 01
~
lit 1\ 1 -I
I
=~

-V c:J
SAP GUI DatenslTom
N
- ~~~~~~~
I
~
,+ < < < < <
C:::::J< < < < < ( < <
Prasentabonsebene
I
~
0000000 ~
_______________________ _______ ____ _____ _________ ~'p!d~ajJQlJ.s!=Qe_n!? ____ _
SAP R/3 System

Abbildung 44: Funktionsweise GUI XT CNangoy, 2001)

Die von SAP vorgeschlagene Vorgehensweise der benutzerorien-

tierten Gestaltung von Bedienoberflachen erfordert das Erlernen
einer zusatzlichen XT-Scriptsprache und die Einarbeitung in das
spezielle XT-Designer-Tool zur Gestaltung von Oberflachen. Die
verfugbaren Entitaten der Sprache sind angelehnt an die unter
SAPIR3-Screendesigner verftigbaren Elemente und damit bei wei-
tern nicht so umfangreich wie die Elemente der HTML-Sprache
(vgl. Nangoy, 2001).

3 HTMLTechnologie
Ein unschatzbarer Vorteil der HTML-Technologie liegt in ihrem
Bekanntheitsgrad, d.h. jedes Kind kann heute mit einem Inter-
netbrowser umgehen.
Auch die graphischen Entwurfswerkzeuge zur Seitengestaltung,
wie Makromedia Dreamweaver oder Adobe GoLive, sind zumin-
dest in Hochschulkreisen bestens bekannt. Die Anwendung der
Tools ist leicht erlernbar (e-learning), einfach in der Anwendung
und insbesondere ausgereift und robust. Eine Beschaftigung mit
den HTML-Codes entfallt, da aile Sprachelemente im Design-Tool
graphisch unterstutzt werden. Auch komplexe Inhalte einer Seite

85
HTML-basierte Kommunikation mit SAPIR3

sind daher schnell aufzubauen. Ein weiterer Vorteil der Einarbei-

tung in die HTML-Entwurfstools ist, dass es sich nicht urn eine
proprietare Technologie handelt. Das erarbeitete Wissen ist damit
auch flexibel fUr beliebige Internetanwendungen einsetzbar.
Die Browserumgebungen (Netscape, Microsoft IE, etc.) sind auf
allen gangigen Betriebssystemplattformen vorhanden und kos-
tenfrei verfUgbar, so dass selbst in einer heterogenen Hard- und
Softwarelandschaft jeder seine bevorzugte Browserumgebung zur
Darstellung der Inhalte wahlen kann. Die HTML-Inhalte basieren
auf einer neutralen Definitionssprache in ASCII und sind damit
ebenfalls plattformunabhangig.
Was leistet nun HTML und seine Erweiterungen Qavascript, Java-
Applets, Java-Servlets) bzw. was kann man damit machen?
Zunachst bietet Standard-HTML alles was heute zu einer moder-
nen graphischen Benutzeroberflache gehort :
Ausgabe von Text, Bild, Graphik, Animation, Audio und
Video,
Eingabe uber Maskenfelder und Multiple-Choice-Menu,
Steuerung uber Menu, Button, Clickboxes und Radiobut-
tons.
Ober die o.g. Erweiterungen ist eine Dynamisierung der einzel-
nen Komponenten der Sprache erreichbar, bis hin zu einer se-
mantischen Prilfung von Eingabeinhalten bereits auf der Client-
Seite. Eine unter HTML definierte Benutzeroberflache hat damit
nicht nur den Charme, dass sie bei weitem mehr bietet als die
SAP/ R3-Bedienoberflache, sie kann auch sehr einfach anwender-
gerecht gestaltet werden. Auch hier fallt der Vorteil der schnellen
Gestaltung einer Benutzeroberflache ilber Design-Tools eindeutig
zugunsten von HTML aus. Aile heutigen Browser ermoglichen
die Obertragung von Daten in verschlOsselter Form, so dass auch
sensible Informationen einer Anwendung problemlos uber-
tragbar sind.

4 Realisierungstechniken
Die Workbench des SAP/ R3 Systems ist zusammen mit der Pro-
grammiersprache ABAP/ 4 ein sehr machtiges Werkzeug zur Ge-
nerierung von Anwenderprogrammen unter SAP I R3 . Insbesonde-
re die hoheren Funktionen und Methoden der Sprache erlauben
eine Kommunikation mit Fremdsystemen. SAP stellt mit der

86
 Reinhard Mayr

Workbench eine sehr umfangreiche Bibliothek von Funktions-

bausteinen zur VerfUgung, die die Entwicklungsarbeit extrem
vereinfacht und beschleunigt. Seit der Erfindung der BAPl's ist
auch eine Kommunikation zwischen objektorientierten Sprach-
umgebungen wie Java oder Delphi und SAP/R3 mbglich.
Wir haben uns in unserer Entwicklung auf Java festgelegt, denn
hier ist die Systemgestaltung aufgrund der umfangreichen Klas-
senbibliotheken und der bereits vordefinierten Klassen zur
HTML-Kommunikation vergleichsweise einfach. Eine Kommuni-
kation mit relationalen Datenbanken uber ODBC und die Integ-
ration von C++ Programmen ist seit Java 1.2 ebenfalls integraler
Bestandteil von Java ebenso wie Multitasking und Multithreading.

5 Kommunikation zwischen SAP/R3 und einem HTML

Browser (Fels, 2000; Nagov, 2001; Weber, 2002)
Die Problematik bei der Integration zweier unterschiedlicher Sys-
teme ist generell gekennzeichnet durch Datenkommunikation auf
einem LAN. Daten kbnnen je nach Funktionalitat der angebote-
nen Schnittstellen per Filetransfer oder per direktem Datenaus-
tausch auf der Basis z.B. einer Pipe ausgetauscht werden.
Betrachten wir zunachst SAP/ R3 . SAP/ R3 bietet zwei Methoden-
klassen zur Kommunikation an:
ABAP/ 4-orientierte Methoden und
BAPI-orientierte Methoden.
Die klassischen ABAP-Methoden sind "fileorientierte" Methoden.
Sie erlauben entsprechend das Schreiben von Files auf unter-
schiedliche Clientsysteme (WS_DOWNLOAD), mit der Mbglich-
keit, direkt ein Applikationssystem zu starten. FUr Microsoft-
Office sind sogar spezielle Funktionsbausteine zur Kommu-
nikation vorhanden. Auch fUr den Empfang von Filedaten halt
ABAP/4 Methoden bereit (z.B . BATCHINPUT).
Die neuere Vorgehensweise zur Kommunikation mit anderen
Systemen ist die BAPI-Methode (Business Applikation Program-
ming Interface). BAPl's kbnnen heute in die objektorientierten
Programmiersprachen JAVA und Delphi einge-bettet werden. Es
gibt seitens SAP bereits eine umfangreiche Bibliothek von
Schnittstellen-BAPI's (Lesen/ Schreiben) fUr eine Vielzahl von Da-
tenobjekten. Leider noch nicht fUr aile, so dass man ggf. ge-
zwungen ist, eigene BAPl's zu entwickeln. Auch hier gibt es ent-
sprechende Werkzeuge.

87
HTML-basierte Kommunikation mit SAPiR3

HTML-Clients (Browser) empfangen HTML-Files zur Darstellung

der Inhalte. Der HTML-Code liegt in ASCII vor und fUr jedes gra-
phische Element existiert ein entsprechendes Sprachkonstrukt,
das ciientseitig durch den Browser interpretiert wird. Fur das
Senden von Daten halt HTML unterschiedliche Methoden bereit.
Zu nennen ware etwa die etwas altere CGI-Methode (Common
Gateway Interface) unter Perl oder die direkte Kommunikation
mit einem Java-Server (Java-Servlet). Insbesondere die letztere
Methode gestaltet sich vergleichsweise einfach, halt doch Java
eine HTTP-Klasse mit zugehorigen Methoden zur Kommunikati-
on bereit.
Zur Realisierung der bidirektionalen Kommunikation zwischen
dem HTML-Client und dem SAPIR3-Server bieten sich zwei Me-
thoden an, die nachfolgend genauer beschrieben werden :
ABAP IHTML und
Java/ HTML.

HTML Externes
Tool HTML

Browser
Client

1
~ SAP Form
r - - - + HTML.Extender r-----'
'".",0","
SAP Form

JAVA
Servlet .)

Abbildung 45: Methode ABAP/ HTML

Die erste Methode (ABAP I HTML) ist sehr eng mit dem SAP IR3-
System verknupft, handelt es sich doch im wesentlichen um ein
ABAPI 4-Anwenderprogramm.
Templates Ausgehend von einem mit einem HTML-Design-Tool (GoLive)
erstellten Template wird das entstandene HTML-File zeilenweise
in eine interne SAP/ R3-Tabelle eingelesen. Die noch fehlenden
Daten aus der SAP/ R3-Datenbank werden erganzt, d.h. auf die
vorgesehenen Stellen im Template eingetragen. AnschlieBend
ubertragt der Funktionsbaustein WS_DOWNLOAD das erganzte

88
 Reinhard Mayr

HTML-Dokument an den Browser-Client. Der Rtickweg, d.h. der

Empfang von Daten aus einem HTML-Formular gestaltet sich et-
was schwieriger, da HTML keine direkte Datenrtickgabe an das
SAP/ R3-System erlaubt. Hier kommt nun die HTML-Java-
Integration zum Einsatz. Es gibt in der HTML-Sprache eine Mbg-
lichkeit, Daten aus einer Eingabemaske mit dem <Post>-Tag di-
rekt an ein Java-Objekt (HttpServlet-Class) auf einen Java-Server
zu tibertragen. Die "doPost"-Methode des Servlets, die hier spe-
ziell fOr die Generierung eines strukturierten Files abgewandelt
wurde, schreibt die Daten strukturiert auf den Empfangsbereich
des SAP / R3-Systems.
Wie merkt nun SAP / R3 , dass hier Daten angekommen sind? Es
wurde ein Watchdog mit der ABAP-Methode "Batch-Input tiber
Mappen" entwickelt, der in einem vorgegebenen Takt den In-
putbereich scannt und dann entsprechend das File findet. Die
Daten werden von einem ABAP-Fileinterpreter analog der syn-
taktischen Struktur der Filesprache verarbeitet und gelangen tiber
OPEN_SQL in die SAP/ R3-Datenbank. Das Datenfile wird nach
erfolgreicher Ubernahme der Daten aus dem Inputbereich ge-
lbscht / 3/ .
javaiHTML Bei der zweiten Methode (Java/ HTML) handelt es sich urn eine
reine Java-Applikation, die tiber die neue BAPI-Schnittstelle mit
dem SAP/ R3-System kommuniziert. Auch hier ist das tiber ein
Tool generierte HTML-Formular Voraussetzung fOr die Verarbei-
tung. Vergleichbar zur Methode ABAP/ HTML wird das eingele-
sene Formular mit den zugehbrigen Daten aus dem SAP / R3-
System versorgt, wobei im Unterschied zur ersten Methode die
Daten per BAPI ausgelesen werden. Die Datenintegration erfolgt
wieder tiber die im Template vorgesehenen Felder. Uber Java
wird dann vergleichbar zum WS_DOWNLOAD der Browser mit
dem erweiterten HTML-Dokument gestartet. Da wir uns aber jetzt
unter Java befinden, ist die Rtickkommunikation, d.h. der Emp-
fang der Daten aus dem HTML-Dokument bereits standardmalSig
in Java vorgesehen (HttpServlet-Class). Mit der doPost-Standard-
methode dieser Klasse kann man die HTML-Felddaten empfan-
gen und weiterverarbeiten . Der Eintrag erfolgt entsprechend ih-
rer Semantik tiber ein BAPI in das SAP / R3-System.
Vergleicht man die beiden Methoden, so stellt man unmittelbar
fest , dass sich mit der Benutzung der SAP/ R3-BAPI-Schnittstelle
unter Java die Kommunikation wesentlich vereinfacht. Java, mit
seinen umfangreichen Objektklassen speziell fOr HTML, ver-
knupft Browser und Java-Programm entsprechend eng. Ein

89
HTML-basierte Kommunikation mit SAPIR3

Watchdog entfaUt bei der zweiten Methode ganzlich und auch

die Erfindung einer "Filesprache" fur ein strukturiertes Datenfile
und der Dateninterpreter sind obsolet. Insgesamt ist die zweite
Methode mit weniger Aufwand verbunden, wenn auch die Sys-
temumgebung Java und die Benutzung der BAPI's anfangs etwas
gewbhnungsbedurftig sind.

HTML
Tool

Extcrnes
HTML

JAVA
Browser
S PForm ~ Extended
lient
Programm
+ Input.Oaten I
Abbildung 46: Methode Java/HTML

6 Die BDE-Anwendung
1m Rahmen der Kooperation mit def Deutz AG in Kbln steUte
sich unter anderem die Frage nach einer HTML-gestutzten BDE.
Fur den Anwender (Werker) soUte eine einfache und leicht be-
dienbare graphische Benutzerfuhrung unter HTML realisiert wer-
den. Die Realisierung erfolgte auf der Basis der Methode A-
BAP IHTML. Die dargestellten Daten stammen aus dem SAP IR3-
System.
Abbildung 47 zeigt eine typische BDE-Eingabemaske, in der uber
einige Clickboxes und das Eingabefeld "Personalnummer" ein
Eintrag vorzunehmen ist. Der blaue Button fuhrt dann zu einer
weiteren Maske (Abbildung 48) in der die mbglichen Montage-
fehler und die korrekte Montage graphisch dargestellt sind.

90
 Reinhard Mayr

*
Q~'"
P,ufme,kmale Deutl AG . Net.cape
l!ea,beten An~cl-t laehe Corrm.riclltc. Hille
II!I~ f3

.? J::
t . Lerezeichen I; ~~~~~~~~

Priifmerkmale
Merkmalnummer Prilfme rkmaltelL't M erkmalwert
00 10 Schrauben fixlert? r

Merkmahlummer I'riifmerionaltelL't Merkmalwert

0020 Drelunoment IO? r

Merkmalnwnmer Priifmerkmaltext M erkmalwert

UberprUfeo die
0030 r
Olrucklaufiel\ung
i.."~Phh'-""1"
/ ' " \NI"'7f un,

12 4 .03 . 2001 108 : 3 4: 00

TRAGEN SIE IHRE PERSONALID Em 1 Abschicken

Dok'-'!lent 0De,,,, telt

Abbildung 47: Maske Prufmerkmale

Bltte ObcrprOfen Sic nochmal den Sitz von der

Ii
DEUTZ
Olruckloufleitung

Abbildung 48: Graphische Werkerunterstutzung

91
HTML-basierte Kommunikation mit SAPIR3

7 Das Demo-Bestellsystem
Das Demo-Bestellsystem wurde anhand der Java/ HTML-Methode
an der Fachhochschule im Rahmen einer Machbarkeitsstudie
entwickelt und implementiert. Das primare Kriterium zur Gestal-
tung der Benutzeroberflache war es, eine mbglichst einfache und
plausible BenutzerfUhrung mit umfangreicher graphischer Unter-
stOtzung zu gewahrleisten. Das Layout (2-Frame-Design) ent-
spricht gangigen Benutzeroberflachen, wie sie heute auch im In-
ternet anzutreffen sind (www.apple.de, www.amazon.de). Als
Entwicklungsumgebung wurde Adobe GoLive gewahlt.

Fachhochschule Koln
DEMO-Bestellsystem

Artikclbestellung

Bestellnummer
14111

Lefe'iIlIt
4611
"'uller Fahlleuglelle GmbH
KOln
ee1Z(to~or St, 2

Ar1Iktlnummer
1611.gelll IArllt"t Flnden I
Ar1IkelbtU.tMung
IGeltiebegOhaeu

Aru;ahI de, Ted . EinuJp'ClS. El/IUl,umme

IID~ =~

Abbildung 49: Graphische Benutzeroberflache

Die BedienerfUhrung umfasst aile notwendigen FunktionaliWen,

die ein Einkaufer benbtigt, urn eine Bestellung aufzubau en:
AnmeldunglAbmeldung (Identifikation des Einkaufers),
Bestellkopf (Auswahl des Lieferanten),
Bestellposition(Artikelauswahl mit graphischer Unterstiit-
zung) und
Anzeige (graphische Bestellanzeige).

92
 Reinhard Mayr

Fachhochschule Koln
DEMO-Bestell ystem

Abmeldun9 ~SI.lIkopf

Artikelbc 'enung

Bestellnwnmer
Iml
L..ferant
4811
Muller fahrzeuglelle om~H
KGin
Betzdorler S~ 2

I R"do.e 0 lollu"9 A".elgen I

Po. Amkelnummer Amahl Berrase

f1 14811.g0111 r
Amkelbemchnung:
IOelliebegehS u

Pos Amk.lnurnmer Anzahl

[2 14811-kuehl fiO
AmkelbezclchnUll8
IKYhlmodul

Po, Amkelnummer Anzahl

(3 1491H.h1P fiO

Gesamrberr08-

Abbildung 50: Anzeige der Bestellung

Durch die Identifizierung des Einkiufers ist automatisch festge-

legt, welche Artikelgruppen er bei welchen Lieferanten bestellen
darf. Entsprechend werden ihm auch nur seine Lieferanten in ei-
nem Popup-Menu angeboten. Die Artikelanzeige wird graphisch
unterstutzt C3D-CAD-Modelle in Abbildung 49, Abbildung 50).

8 Fazit
Bei den meisten Betriebssystemen gehort heute ein Internet-
browser mit zum System und ist ohne zusatzliche Lizenzkosten

93
HTML-basierte Kommunikation mit SAPIR3

erhaltlich, d.h . es ist kein zusatzlicher Client fur SAP/ R3 notwen-

dig. Die Benutzerfuhrung kann anwendergerecht, orientiert an
den Bedurfnissen der unterschiedlichen Bedienergruppen, auf-
gebaut werden. Die HTML-Orientierung hat den Vor2Og der In-
tegration von beliebigen graphischen Objekten in die Benutzer-
obertlache und garantiert damit ein Hochstmass an Information.
Der Anwender kann bereits zum Zeitpunkt des Logon seiner
Gruppe zugeordnet werden und damit ist das Customizing be-
zuglich der Masken bereits geregelt. Er sieht nur diejenigen
HTML-Seiten, die fUr seine Gruppe freigegeben sind. Die Ein-
fachheit der HTML-Maskenbedienung spricht fUr sich. Sie sorgt
dafur, dass auch der gelegentliche Nutzer des Systems seine Da-
teneintragungen vollstandig durchfuhren kann. Damit bleibt die
Datenbasis konsistent und die Frustrationsschwelle des Bedieners
wird deutlich herabgesetzt.
Da SAP die gleich bleibende Funktionalitat der BAPl's auch bei
Releasewechseln garantiert, ist die Investition, die durch die 20-
satzliche Java-Kommunikationsapplikation und die gruppen-
orientierten HTML-Benutzeroberfhchen notwendig wird, ge-
siehert. Beispielhafte Anwendungen aus unterschiedlichen An-
wendungsbereichen zeigen, dass die Methode universell einsetz-
bar ist.

9 Literatur
Fels, T.: Erstellung eines Vorgehenskonzeptes zur Evaluierung ei-
ner graphischen Werkeifuhrung unter SAP Rl3, Diplomarbeit
2000
Schlicht, M.: Anwendergerechte Gestaltung von Benutzerobeif!a-
chen in SAP Rl3, Diplomarbeit 2001
Nangoy, R.: HTML-basierte Betriebsdatenermittlung fur SAP Rl3,
Diplomarbeit 2001
Weber, A.: javaIBAPI-Anwendungen, Diplomarbeit 2002

94
 Andreas Gadatsch

Workflow-Management mit SAP R/3?!

=======

Andreas Gadatsch

1 Ausgangslage
ERP-Systeme (ERP = Enterprise Ressource Planning) wie SAP R/ 3
werden zur Untersttitzung vorwiegend innerbetrieblicher Auf-
gaben wie Logistik, Vertrieb, Produktion, Finanzen und Control-
ling eingesetzt. Zur Prozess-Steuerung finden zunehmend Work-
flow-Management-Systeme (WFMS) Einsatz ..
Seit einiger Zeit bieten die Hersteller etablierter ERP-Systeme
Workflow-Module als Bestandteil ihrer Software an. Viele An-
wender mit heterogenen IT -Architekturen, stehen nun vor der
Frage zu kLiren, in welchen Fallen der Einsatz eines zusatzlichen
WFMS bzw. der Einsatz der Workflow-Module des ERP-Systems
sinnvoll ist.

2 Grundlagen
Workflow-Management-Systeme (WFMS) unterstutzen die Model-
lierung, Simulation, AusfUhrung und Dberwachung von Workf-
lows.
Abbildung 51 zeigt die Prinzipdarstellung einer Integration von
ERP-Systemen und anderen Applikationen mit einem WFMS.
Dargestellt ist ein WFMS, welches zur Integration eines im Un-
ternehmen selbst entwickelten Vertriebssystems, eines ERP-
Systems und der eingesetzten Textverarbeitung eingesetzt wird.
Die Prozess-Steuerung erfolgt tiber das WFMS, die AusfUhrung
durch die dargestellten Applikationen.

95
Workflow-Management mit SAP Rl3?!

...---- - - ---tWorkflowae ttitzte Vertriebsabwickl una~--------'

WFMS- ERP-
Client / WebClient Client

ERP-
Module
Verar-
beitung

PC-
DBMS

WFMS

Abbildung 51: Einsatz eigenstindiger WFMS

Ein ERP-System unterstutzt mehrere betriebswirtschaftliche Ap-

plikationen, die durch eine gemeinsame Datenbasis integriert
sind. Typische Applikationen sind Finanzwesen und Controlling,
Produktionsplanung - und Steuerung, Einkauf und Logistik, Ver-
trieb und Versand sowie Personal. 1m Vordergrund steht die in-
terne Prozessunterstutzung, weniger die Unterstutzung zwi-
schenbetrieblicher Geschaftsprozesse. In den letzten Jahren war
die EinfUhrung von ERP-Systemen haufig der Auslbser fUr BPR-
Projekte. Erfolgreiche BPR-MaBnahmen fUhren i.d.R. zu Prozess-
orientierten Organisationen. Viele ERP-Systeme sind jedoch his-
torisch bedingt funktional gepragt. Prozessorientierte Organisati-
onskonzepte lassen sich jedoch nur schwer mit Funktionsorien-
tierten ERP-Systemen realisieren. Die Abbildung der Prozess-
Organisation fUhrt in der Praxis nicht selten zu einem System-
bruch. Dber zusatzliche Konstrukte und Technologien mussen
Geschaftsprozesse modelliert und aufwendig im System imple-
mentiert bzw. abgebildet werden. Integrierte Workflow-Module
sollen diesen "Effekt" der ERP-Systeme ausgleichen, indem Sie es
erlauben, uber Modulgrenzen hinweg Prozesse zu modellieren,
ggf. zu simulieren und letztlich auszufUhren.

96
 Andreas Gadatsch

Die Abbildung 52 zeigt einen Architekturansatz fUr ERP-

integrierte WFMS . Es ist erkennbar, dass die Prozess-Steuerung
(Workflow-Funktionen) und die Ausfuhrungsfunktionen (ERP-
System) auf allen Ebenen des Client-Server-Ansatzes verschmol-
zen sind. Es gibt einen gemeinen Workflow- und Applikations-
Client, der fUr aile Funktionen verwendet werden kann. Ein in-
tegriertes Datenbank-Verwaltungssystem stellt die erforderlichen
Daten fUr aile Funktionen redundanzfrei zur VerfUgung. Weiter-
hin ist erkennbar, dass die Integration bei der Einbindung exter-
ner Applikationen, also z. B. von Individualentwicklungen endet.
D. h., sobald nicht aile fUr eine Prozesskette erforderlichen
Schritte innerhalb des ERP-Systems abgebildet werden konnen,
stellt sich wiederum die gleiche Problematik, wie beim Einsatz
eigensrandiger Workflow-Management-Systeme. Eine Reihe von
ERP-Herstellern haben bereits Workflow-Module in ihre Produkte
zu integriert, wenngleich die Funktionalitat der Workflow-
Komponenten nicht immer die von etablierten WFMS erreicht.
Die Funktionen Modellierung, AusfUhrung, Dberwachung und
Analyse werden in der Regel bereitgestellt, eine Workflow-
Simulation ist in der Regel jedoch nicht moglich.

'"oc: _
Jntcgricrter Worknow
'=
.. ..c
u Applikations
und Cl ients
j~ ApplikationsClient
+r--il~j

r Workflow-Modellierung, Simulation, Au fiiJlrung

r r I
Vcr L PPS Lo Fi Con
trich gistik ......, nan j""'" Irol - sonal
zen ling

Intcgricrtes DBMS
(ModclLicrung " Simulation Stamm und
Ausfiihrungsdaten )

ERP.integriertes WF IS Ext. App.

Abbildung 52: Einsatz ERP-integrierter WFMS

Der immer haufiger zum Einsatz kommende SAP-Business

Workflow ist in das SAP-System als Integrationsschicht oberhalb

97
Workflow-Management mit SAP Rl3?!

der "normalen" Funktionsmodule wie Rechnungswesen, Logistik

und Personal integriert. Er untersttitzt bis auf die Simulation aile
wesentlichen Funktionen eines WFMS, d. h. Modellierung, Aus-
fUhrung, Uberwachung und Analyse von Geschaftsprozessen.
Das SAP-Workflow-Modul nutzt hierbei SAP-Transaktionen und
Funktionen ohne diese jedoch zu verandern und setzt sie zu
neuen, noch nicht im SAP-System vorgesehenen Geschaftspro-
zessmodellen zusammen. Die Nutzung ist eine zusatzliche Opti-
on. Durch Nutzung des SAP-Organisationsmanagements kbnnen
bereits vorhandene Organisationsdaten genutzt werden. Das
Workflow-Modul stellt eine ganze Reihe von Komponenten zur
Verfligung, mit denen die Workflow-Funktionalitat im SAP-
System abgebildet wird. Der Workflow-Builder ist der Editor, mit
dem Workflows modelliert werden kbnnen. Workflow Wizards
untersttitzen die Workflow-Moduellierung fUr spezielle, haufig
benbtigte Workflows, wie z. B. Genehmigungsverfahren oder
Umlaufzettel. Einen Uberblick liber die Wizards liefert der Wi-
zard Explorer. Der Business Object Builder ist das Werkzeug zur
Einbindung von Aufgaben, die durch SAP-Transaktionen und
Reports durchgefUhrt werden kbnnen. Der Business Workflow-
Explorer ermbglicht die Navigation durch die verfUgbaren
Workflow-Modelle. Das Werkzeug des Endbenutzer ist ein spe-
zieller Client, der Business Workplace.

3 Welche Szenarien sprechen fOr eigenstandige WFMS?

Der Einsatz eigenstandiger WFMS weist eine Reihe von Vorteilen
hinsichtlich der Flexibilitat der IT-Strategie und der Integration
von Applikationen auf. Zur Frage der Flexibilitat der IT-Strategie
ergeben sich positive Aspekte hinsichtlich der Frage der Abhan-
gigkeit zum ERP-Hersteller aber auch negative Aspekte hinsicht-
lich finanzieller Aspekte.
Zunachst einmal besteht keine Abhangigkeit zu einem einzigen
(ERP-) Anbieter, da ERP-Bausteine von mehreren Herstellern
verwendet werden kbnnen und durch das WFMS integriert wer-
den. Eingebundene ERP-Systeme oder Eigenentwicklungen kbn-
nen prinzipiell ausgetauscht werden, ohne das ein Einfluss auf
den Workflow besteht, sofern die Funktionsbausteine kompatible
Leistungen erzeugen. Da zusatzliche Benutzeroberflachen, z. T.
fUr das ganze Unternehmen, erforderlich werden, ist jedoch mit
zusatzlichem Schulungsaufwand fUr IT-Personal und Anwender
bei der EinfUhrung des WFMS zu rechnen. Wichtig ist, das nun

98
 Andreas Gadatsch

eine gewisse Abhangigkeit ftir die Prozess-Steuerung vom

WFMS-Hersteller entsteht, wahrend die Verantwortung der Funk-
tionsausftihrung durch mehrere Anbieter getragen wird. Hinzu
kommt zusatzlicher Aufwand fOr Lizenzen und ggf. Hardware.
Die einfache Integration verschiedener Komponenten ist der
Hauptgrund, der ftir den Einsatz von eigenstandigen WFMS
spricht. Er bringt Vorteile hinsichtlich der Integration, der Doku-
mentation sowie der Benutzerakzeptanz: Prozesse, die durch
mehrere Applikationen untersttitzt werden, konnen auf der be-
triebswirtschaftlichen Ebene zu einem Gesamtprozess integriert
werden, da die Integration unterschiedlicher Applikationen (Ei-
genentwicklungen, weitere ERP-Systeme, Mail, Dokumentenma-
nagement- und Archivierungssysteme) explizit vorgesehen ist.
Gerade in groBen Unternehmen existieren Forderungen, Prozes-
se unternehmensweit einheitlich zu dokumentieren. Der Einsatz
von WFMS stellt einheitliche Workflow-Modelle i.iber alle Appli-
kationen hinweg sicher. WFMS bieten als Middleware-Plattform
dauerhaft eine einheitlicher Benutzeroberflache, in die nach Be-
darf Applikationen integriert werden konnen. Die zwangsweise
redundante Datenhaltung sowie ein erhohter Know-How Bedarf
in der IT sind die wesentlichen Nachteile von eigenstandigen
WFMS.
In Abbildung 53 ist ein zwischenbetrieblicher Geschaftsprozess
aus der Vertriebs!ogistik dargestellt, der sich tiber mehrere Ge-
schaftspartner und Applikationssysteme hinweg vollzieht. Dieses
Fallbeispiel ist ein typisches Szenario ftir eine sinnvolle Integrati-
on mehrerer Applikationen durch ein eigenstandiges WFMS.
Beginnend bei einem externen Call-Center werden tiber einen
Web-Client eingehende Kundenauftrage bearbeitet. Das Kun-
denmanagement erfolgt mittels einer CRM-Software, z. B. von
Siebel. Unternehmensintern erfolgt die Auftragsabwicklung mit-
tels eines ERP-Systems (z. B. SAP R/ 3), die eigentliche Leistungs-
erbringung i.iber eine Eigen-Entwicklung. Die Auslieferung wird
durch einen externen Logistik-Dienstleister wahrgenommen, der
wiederum SAP als ERP-System einsetzt. Die Steuerung des voll-
standigen zwischenbetrieblichen Geschaftsprozesses ist Aufgabe
eines web-basierten Prozess-Management-Systems, dessen Funk-
tionalitat tiber die eines klassischen WFMS hinausgeht. Unter-
schiede sind insbesondere in der Web-Anbindung und der tiber-
betrieblichen Prozessintegration zu sehen, ftir die Modellierungs-
und Ausftihrungsmechanismen gefunden werden mi.issen.

99
Workflow-Management mit SAP Rl3?!

Versand /

---
Extern' Call-Center

I
I

= ,
Individual-
Software

Bei piel einer zwi chenbetrieblichen Proze integration

Extemer Inlemer
Pro7~ssschritt Proze hriu

Abbildung 53: Einsatz eigenstandiger WFMS

4 Welche Szenarien sprechen fOr ERP-integrierte WFMS?

Die Vorteile des Einsatzes von ERP-Workflow-Modulen sind im
wesentlichen in kostengi.instigeren Lizenzmodellen und der Da-
ten- und Prozessintegration zu sehen . I.d.R. fallen keine oder nur
geringe Zusatzkosten fi.ir Lizenzen oder Hardware an, ggf. ist a-
ber ein Upgrade des Systems erforderlich Es ist davon auszuge-
hen, das der Kunden von einer synchronen Releaseplanung des
Herstellers profitieren kann, da ERP und WFMS gemeinsam wei-
terentwickelt werden. Da systeminterne Schnittstellen verwendet
werden, sind keine Datenredundanzen vorhanden, der klassische
ERP-Effekt wird auf das Workflow-Management i.ibertragen. Die
ggf. schon vorhandene Abhangigkeit zum ERP-Hersteller steigt
durch Ausdehnung der Abhangigkeit auf die Prozess-Steuerung
noch an, denn die Releaseproblematik wird verstarkt. Dies gilt
insbesondere dann, wenn der Herstellen proprietare interne
Schnittstellen zwischen Anwendungs- und Workflow-Modulen
verwendet. Weiterhin ist der Funktionsumfang haufig noch nicht
mit etablierten WFMS vergleichbar (z. B. Simulation). Hinsichtlich
der Integration ist folgendes festzuhalten: Der Einsatz von ERP-
Workflow-Modulen ist mit einem geringeren Einfi.ihrungs- und

100
 Andreas Gadatsch

Integrationsaufwand verbunden, da zum einen schon das grund-

satzliche System-Know-How vorhanden ist, vorhandene Organi-
sationsdaten genutzt werden konnen und die Workflow-Module
sukzessive eingefUhrt werden konnen . Die Daten- und Prozess-
integration von Geschaftsprozessen ist groBer, wenn sofern sie
iiberwiegend durch das ERP-System unterstiitzt werden konnen.
Die Akzeptanz der Anwender ist groBer, da keine neue Benut-
zeroberflachen erforderlich sind. Als Nachteil ist insbesondere
die i. d. R. problematischere Einbindung von Dritt-Produkten
insb. weiteren ERP-Systemen zu erwahnen.
Ein typisches Beispiel fiir den Einsatz ERP-Integrierter WFMS
sind die so genannten "Beschaffungs-Workflows", d. h. Ge-
schaftsprozesse zur Beschaffung von z.B. Nicht-Lager-Materialien.
Derartige Prozesse kommen sehr haufig in vielen Unternehmen
in groBer Zahl und Auspragung vor. Sie werden zwar in der Re-
gel bereits durch ERP-Systeme unterstiitzt, haufig wird jedoch der
Vorgelagerte Genehmigungsprozess nicht einbezogen. Am Bei-
spiel des SAP-Business Workflow lasst sich einfach zeigen, wie
mit vergleichsweise geringem Aufwand eine Prozessbeschleuni-
gung und qualitative Verbesserung realisieren lasst. Derartige Be-
schaffungs-Workflows sind haufig folgendermaBen strukturiert
Cvgl. Abbildung 54):
Die Erkennung des Bedarfes erfolgt dezentral in ver-
schiedenen Organisationseinheiten
Der Bedarf wird auf einem Genehmigungsformular fi-
xiert und durch den Kostenstellenleiter gegengezeichnet
Abhangig von den Genehmigungsvorschriften miissen
ggf. weitere, teilweise mehrere Unterschriften "besorgt"
werden, was nicht selten bei Zeitdruck durch personli-
che Besuche der Anforderer durchgefUhrt wird.
Das Anforderungsformular wird anschlieBend vom Ein-
kauf in eine SAP-Bestellanforderung oder direkt in eine
SAP-Bestellung umgesetzt. Hierbei auftretenden Riickfra-
gen, haufig ausgelost durch die "erbarmungslose" Plau-
sibilWitspriifung des SAP-Systems fiihren zu Zeitverzoge-
rungen in der Beschaffung.
AnschlieBend wird der normale SAP-Beschaffungs-
prozess durchlaufen.

101
Workflow-Management mit SAP Rl3?!

"Konventionelle Abwicklung" I

B tell- Einkaufl Waren- Rechnung -

eingang prufun~
I

Nachteile: 1. Zeilaufwendiger Papiergestiitzler Genehmigungsprozcss ohne Piau i-Priirung

2. Milarbciler miisscn Gcnchmigungsrcgclung im Detail kennen und einhalten
3. Keinc maschinclle Information iiber latus des Genehmigungsprozes es

Abbildung 54: Beschaffung ohne Workflow-Unterstutzung

Die Nachteile dieses Verfahrens liegen auf der Hand: Der um-
standliche Genehmigungsprozess fuhrt zu Zeitverlusten. Zudem
mtissen die Mitarbeiter selbstandig die Einhaltung der Genehmi-
gungsvorschriften sicherstellen, was bei GrolSunternehmen zu
Rtickfragen oder auch Nichtbeachtung fUhren kann . Erst ab der
Erfassung der Bestellanforderung oder Bestellung besteht eine
elektronische Moglichkeit der Statusabfrage tiber den Beschaf-
fungsvorgang, der Vorgelagerte Genehmigungsprozess ist nicht
eingeschlossen. Durch geringe organisatorische Anderungen und
Einsatz des im SAP-System enthaltenen Business Workflows las-
sen sich qualitative und zeitliche Verbesserungen des Beschaf-
fungsprozesses erzielen. Ein Beispiel ist in Abbildung 55 darge-
stellt. Es umfasst folgende Prozess-Schritte:
Der Beschaffungsprozess wird schon bei der Identifizie-
rung des Bedarfes elektronisch unterstUtzt, indem der
Anforderer seinen Bedarf per Bestellanforderung in SAP
erfasst.
Die Daten der Bestellanforderung werden durch einen
Workflow maschinell ausgewertet, indem zunachst die
richtige Genehmigungsinstanz ermittelt wird.

102
 Andreas Gadatsch

Der betreffende Mitarbeiter (Kostenstellenleiter, Be-

reichsleiter, GeschaftsfUhrer), oder bei Abwesenheit sein
Stellvertreter, erhalten den Vorgang per E-Mail zur Ge-
nehmigung
Nach erfolgter Genehmigung erhalt der Anforderer per
E-Mail eine Nachricht, dass seine Bestellanforderung ge-
nehmigt wurde.
AnschlielSend erfolgt wiederum der normale SAP-Ablauf
der Beschaffung.

"Workflow-gestiitzte Abwick]ung" I

Bestell- Genehmi- Einkaufl Waren- Rechnung -

gung eingang priifung /

orteile: I. Piau ipriifung schon bei Erfas~ung der Beslellanforderung durch Anforderer
2.' -Modul crmitlell maschinell ggf. erforderliche Gcnehmigungs-Instanzen
3. ollslandige Slalusinformation iiber den ge amtcn Beschafrungsprozess

Abbildung 55: Business Workflow gestiitzte Beschaffung

Die Vorteile des Ansatzes liegen neben der beschleunigten Pro-

zessdurchfUhrung in der friihzeitigen SAP-Plausibilitatspriifung
durch den Anforderer und der maschinellen Sicherstellung der
Geoehmigungsprozeduren. Zudem kann der Anforderer von Be-
ginn an jederzeit den Status seiner Bestellung hinweg abrufen.

5 Fazit
Die Frage der richtigen Entscheidung hangt im wesentlichen von
der gewunschten Flexibilitat der IT-Strategie und von der ange-
strebten Heterogenitat der IT-Landschaft .Das in Abbildung 56

103
Workflow-Management mit SAP Rl3?!

dargestellte Portfolio zeigt auf, welche Standardstrategien grund-

satzlich verfolgt werden k6nnen. Werden die Kernprozesse eines
Unternehmens im wesentlichen durch mehrere ERP- bzw. Stan-
dardsoftwaresysteme unterstutzt, die durch Eigenentwicklungen
erganzt werden , ist grundsatzlich ein eigenstandiges WFMS zur
Prozess-Steuerung vorteilhaft. Dies gilt umso mehr, je starker
Flexibilitatsaspekte hinzukommen, d.h. Wunsche nach Hersteller-
Unabhangigkeit oder eine starke dezentrale Verantwortung im
IT-Bereich durch z.B. autonome Konzerneinheiten eKE). Auch
Forderungen nach ERP-neutralen Prozessmodellen zur Doku-
mentation der Geschaftsprozesse fallen hier hinein. Werden da-
gegen die Kernprozesse durch ein ERP-System unterstutzt und al-
lenfalls in Randbereichen durch wenige Individualentwicklungen
unterstutzt, so kann auf das ERP-interne Workflow-Management-
System zuruckgegriffen werden. Dies kann auch in Einzelfallen
in abgegrenzten Prozessfeldern (z. B. Beschaffungsprozess fur C-
Materialien) parallel zu einem eigenstandigen WFMS praktiziert
werden. Die "ERP-Strategie" wird verstarkt durch Flexibilitatsas-
pekte wie z. B. einer strategischen Einprodukt-Ausrichtung des
Unternehmens, wie dies z. B. haufig im SAP-Umfeld anzutreffen
ist, da dann das ERP-System als dominierender Faktor der IT-
Strategie angesehen wird .

Eigcn-
stiindige
WFMS

ERP-
Intcgriertcs
WFM

:~----------------~---------------~
HeterogenWit dcr IT-Landschaft I
KenlprozC\5e werden dutch ein Kemprozes e werden durch mchrere
ER PSYSlem unter<lOvt ERPSystemei landard",nware unte"tOm
Wen ~e Individuulcntwid:lungen 1ehrere Individunlcnlwickluogen

Abbildung 56: Portfolio

104
 Andreas Gadatsch

6 Literatur
GADA TSCH, A.: Management von Geschdjtsprozessen, Braun-
schweig/Wiesbaden, 2. Aufl., 2002.
GADA TSCH, A.: Finanzbuchhaltung und Gemeinkostencontrolling
mit SAP. Methodische Grundlagen und Fallbeispiele mit SAP
Rl3@, Braunschweig/Wiesbaden, 2001.

105
 Teil III Case-Studies

Tell HI

Case Studies

107
 Dirk Schreiber und Wolfgang Hahnel

Wissenskarten im ERP-Umfeld von kleinen

und mittelstandischen Unternehmen

Dirk Schreiber und Wolfgang Hohnel

1 Einleitung
Aufgrund der zunehmenden Globalisierung stehen Unternehmen
in nahezu allen Wirtschaftsbereichen unter einem erhohten Wett-
bewerbsdruck. Die Unternehmen begegnen dem steigenden
Druck des Wettbewerbs durch die Entwicklung von Geschafts-
prozessen, die sich konsequent an den existierenden und zu-
kunftigen Bedurfnissen des Marktes orientieren. Diese erhohte
Kundenorientierung spiegeJt sich wider in einer Optimierung der
Kernprozesse der Unternehmen. Die damit verbundene Reorga-
nisation der Prozesse kann beispie!sweise auf eine schnellere
Auftragsabwicklung, auf kurzere Innovations- und Produktle-
benszyklen oder auf verbesserte Serviceprozesse abzielen. In
diesem Zusammenhang gilt es heute als erwiesen, dass der ge-
eignete Umgang mit dem Wissen der Unternehmen ein kritischer
Erfolgsfaktor ist [MERTINS2001).Dies gilt nicht nur fUr Dienstleis-
tungsunternehmen, deren Leistungsprozesse auf die Produktion
und Anwendung von Wissen fokussiert sind. Auch in klassischen
Produktionsunternehmen spieJt die Ressource "Wissen" aufgrund
der gestiegenen Komplexitat von Produkten und Produktionsver-
fahren eine zentrale Rolle. Dabei ist das Wissen uber die betrieb-
lichen Prozesse und die diese unterstutzenden ERP-Systeme von
zentraler Bedeutung. Wissenskarten werden zusammen mit vie-
len anderen Instrumenten eingesetzt, urn den Anforderungen der
komplexen Aufgabe Wissensmanagement Rechnung zu tragen .
Sie dienen als Wegweiser, um auf vorhandenes Wissen der Un-
ternehmung hinzuweisen. Vor allem fUr Unternehmensberatun-
gen und GroBunternehmen ist die Anwendung von Wissenskar-
ten untersucht und als Erfolg versprechend eingeschatzt worden
(beispielsweise [BACH98), [MORTON98), [NOHR99]).
Bisher wenig untersucht ist dagegen, inwieweit Wissenskarten
auch speziell fUr das Management des Prozesswissens in kleinen

109
Wissenskarten im ERP-Umjeld von kleinen und mittelstiindischen Unternehmen

und mittelstandischen Unternehmen (KMU) der Fertigungsindust-

rie eingesetzt werden kann, das sich grbBtenteils in dem entspre-
chenden ERP-System widerspiegelt. Diese Frage steht im Zent-
rum des vorliegenden Beitrags, der wie folgt aufgebaut ist:
Nach dieser Einleitung wird in Kapitel 2 zunachst das dieser Ar-
beit zu Grunde liegende Verstandnis von Wissensmanagement
skizziert. In Kapitel 3 wird ein kurzer Dberblick zum Instrument
Wissenskarten gegeben. Dabei wird auf das in [TEUFEL99] vor-
gestellte und auf der Mind-Mapping-Methode basierende Kon-
zept detaillierter eingegangen . In Kapitel 4 wird an hand eines
KMU der metallverarbeitenden Industrie gezeigt, wie diese Wis-
senskarten-Variante als Instrument fur das Wissensmanagement
im Rahmen der Einfuhrung und dem Betrieb eines ERP-Systems
eingesetzt werden kann. Mit einem zusammenfassenden Ausblick
in Kapitel 5 endet dieser Beitrag.

2 Wissensmanagement
Zum Wissensmanagement (Knowledge Management) zahlen aus
einer ganzheitlichen Sieht aile strategischen und operativen,
steuernden und uberwachenden, technischen, kulturellen und
personalrelevanten MaBnahmen zur Erstellung und Nutzung von
Informationen mit Wert [NEUMANN98]. Auf strategischer Ebene
steht die Formulierung von Wissenszielen im Vordergrund. Auf
operativer Ebene hat sich ein Phasenmodell, wie in Abbildung
57 illustriert, in Wissenschaft und Praxis etabliert (beispielsweise
[HEISIG20011, [PROBST99]).

Wissensidentifikation und Wissenstransparenz

Grundphasen
des
Wis. en -

Wissens Wissens-
-generierungl verteilungl
-erwerb nutzung

Abbildung 57: Grundphasen des Wissensmanagements

110
 Dirk Schreiber und Wolfgang Hahnel

Die einzelnen Ansatze differieren in Zahl und Benennung der

Bausteine, doch lassen sich die in Abbildung 57 genannten
Kernelemente stets wiederfinden:
Wissensgenerierung und Wissenserwerb bedeutet
vor allem die Bereitstellung von impliziten Wissen sowie
die Verknupfung des bereits vorhandenen Wissens zur
Erzeugung neuen Wissens.
Wissensidentifikation und Wissenstransparenz be-
handelt primar die Frage der Ablage des Wissens, so
dass es von den Mitarbeitern als existent wahrgenom-
men wird.
Wissensverteilung und Wissensnutzung umfasst den
Austausch von Wissen innerhalb eines Unternehmens
sowie die aktive Anwendung von Wissen in Produkte
und Dienstleistungen.

Wissensmanagement behandelt in der oben dargestellten Grund-

konzeption aile unternehmensrelevanten Wissensarten und -
quellen. 1m weiteren Verlauf dieses Beitrages wird auf das unter-
nehmerische Prozesswissen fokussiert, da es durch die vermehrte
Prozessorientierung der Organisation und durch den Einsatz von
prozessorientierten Enterprise Ressource Planning Systemen ge-
rade fUr kleine und mittelstandische Produktionsunternehmen
von zentraler Bedeutung ist [LEHNEROOb).

3 Wissenskarten

3.1 Grundlagen von Wissenskarten

Wissenskarten - auch Knowledge Maps genannt - verweisen auf
vorhandenes Wissen . Sie sind Dbersichten von Wissenstragern, -
bestanden, -quellen und -strukturen, die sich auf Experten und
Teamwissen, Wissensentwicklungsstationen sowie organisationa-
Ie Fahigkeiten und Ablaufe beziehen kannen [NOHROO).
Dabei kann zum einen auf interne oder externe Mitarbeiter refe-
renziert werden, um implizites Wissen, das "in den Kapfen" der
genannten Mitarbeiter gespeichert ist, nutzbar zu machen. Zu
diesem Zweck erstellte Wissenskarten werden auch als Wis-
sentragerkarten bezeichnet. Zum anderen kannen Wissenskarten
auch auf interne oder extern en Quellen wie Dokumente, Daten-
banken etc. verweisen, um kodifiziertes bzw. explizites Wissen

111
Wissenskarten im ERP-Umfeld von kleinen und mittelstiindischen Unternehmen

verfugbar zu machen. Diese sogenannten Wissensbestandskarten

erganzen ublicherweise die zuvor beschriebenen Wissenstrager-
karten. Neben diesen Grundarten von Wissenskarten existieren
weitere Typen, die beispielsweise in [PROBST99] beschrieben
sind.
Wissenskarten lassen sich durch mehrere Eigenschaften be-
schreiben. Sie sind:
Metainfonnationssysteme, da sie den Weg zum Wis-
sen liefern, aber selbst kein inhaltliches Wissen enthal-
ten,
grafische Darstellungen von Wissen. Analog einer
Landkarte, die raumliche Beziehungen bildhaft darstellt,
liefern Wissenskarten eine Topologie zur Systematisie-
rung von Wissen,
hypennedia-basiert und
informationstechnologisch unterstutzt durch ein Intra-
net oder durch eine Einbindung in ein Workflow- oder
Groupwaresystem.

Wissenskarten erfUllen in den oben vorgestellten Grundbaustei-

nen des Wissensmanagements folgende Funktionen [NOHROO]:
Sie informieren uber Wissensli.icken eines Unternehmens
und dienen damit als Trigger zur Generierung bzw. Be-
schaffung von Wissen.
Sie machen das in einer Organisation ben6tigte/ver-
fUgbare Wissen transparent.
Sie bieten eine Unterstutzung bei Such- und Findevor-
gangen und bilden damit die Basis zur Ermittlung der
ben6tigten Kompetenzen.
Sie unterstutzen im Rahmen der betrieblichen Ge-
schaftsprozesse bei der Zuordnung von Aufga-
ben/ Funktionen und Aufgabentragern

3.2 "Master Knowledge Maps" - prozessfokussierte

Wissenskarten auf Basis der "Mind Mapping Methode"
Neben der zuvor im Grundlagenteil vorgestellten Bedeutung von
"Knowledge Maps" als Synonym fUr Wissenskarten, existiert auch

112
 Dirk Schreiber und Wolfgang Hahnel

noch eine in [TEUFEL991 verwendete, enger gefasste Definition

von "Knowledge Maps". Danach sind "Knowledge Maps" das Er-
gebnis der Anwendung der Methode des "Mind Mappings" auf
betriebswirtschaftliches Wissen bezuglich einen bestimmten
Sachgebiets. Die Grundidee des "Mind Mappings" liegt in der
textuellen und grafisehe Darstellung von Wissen. Dadureh be-
rueksichtigt es den mensehliehen Aufbau des Gehirns, indem es
dureh den Textanteil die linke Gehirnhalfte aktiviert und uber
die grafisehe Visualisierung die rechte Gehirnhalfte ansprieht. Als
Vater des "Mind Mappings" gilt Tony Buzan. Neben seinen eige-
nen Verbffentlichungen (beispielsweise [BUZAN971 gibt es insbe-
sondere in Hinbliek auf den softwaregestutzten Einsatz des
"Mind Mappings" eine Vielzahl weiterer Literatur wie beispiels-
weise [HERZOG20011. Aufgrund der Anwendung der Methode
des "Mind Mapping" sind "Knowledge Maps" grafiseh orientiert,
hypermedia-basiert und informationsteehnologiseh unterstutzt.
Allerdings stellen sie direktes Prozesswissen zur VerfUgung und
sind daher keine Meta-1nformationssysteme.
"Master Knowledge Maps" heifSen in [TEUFEL991 vorgestellte
Wissenskarten, die ebenfalls auf der Anwendung der Methode
des "Mind Mappings" basieren und insofern aueh die oben ge-
nann ten Eigensehaften aufweisen . Sie stellen dar, wo und wie
betriebliehes (Teil)-Prozesswissen dokumentiert und verteilt
wird. Sie besehreiben nieht das Prozesswissen an sieh, sondern
Wissen uber das Prozesswissen und sind daher Metainformati-
onssysteme. Eine "Master Knowledge Map" besitzt eine unmittel-
bare Prozessorientierung, da sie sieh stets auf einen Prozessbau-
stein bezieht und aile zur Darstellung, Erlauterung, Dokumenta-
tion und Sehulung erforderliche Wissensquellen zusammenfuhrt.
"Master Knowledge Maps" haben ihr Anwendungsfeld bisher vor
allem im Rahmen von SAP Rl3-Projekten in GrofSunternehmen,
wie das in Abbildung 3 dargestellte Beispiel illustriert, das in vie-
len Verzweigungen explizit auf das SAP/R3-System Bezug nimmt.
1m Vergleieh zu GrofSunternehmen mit SAP/ R3-Systemen sind in
KMU die Aspekte der Prozessintegration, der Prozessablauflogik
und der Test-Szenarien von geringerer Bedeutung. Daher wird
zur Erklarung dieser Bereiche auf [TEUFEL991 verwiesen. Die ub-
rigen Aspekte (Hauptaste) werden in Kapitel 4 behandelt, in dem
aufgezeigt wird, inwieweit "Master Knowledge Maps" aueh fur
kleine und mittelstandisehe Produktionsunternehmen anwendbar
sind.

113
.......
.......
..I>- ~
~

~
;::t
(\)
:;:l
.

C>- ~
SAPR/3MenOplad 0 ';i:l
8 u Anwendungsmenii < SAP.R/3.Eingabemaske(n) ...
~g: ~ ~
o:=
~::l
~
$:S::
;i1)'Q
CV1
. 6:;:l
~oo
tTl ..
Test ~
s>- (t)
\Dc ;:;.
~6" .., (\)
c
.. :;:l
(1)
~
s SAP :;:l
(1) Cl RJ3.Cuslomlzing I'l..
..., ~ Elnslellungen 7
~
k.., ~
(Jl
1;;-
...,(D ~,
:;:l
~ I'l..
::l ~.
o C'l
~ ~
(\)
~ :;:l
0-
I)'Q
(1) ~
~
..,~ \'1iJ\.I::J 1l1!;;l::'::' VU/,",!\It: ..

'"0
3
~
5 ~
(\)
s
(J) :;:l
Graphische Darstellung dar Ablauflogik '"
>- Funkllonen eines ProzeBbaustein
"?
 Dirk Schreiber und Wolfgang Hahnel

4 Wissensmanagement mit "Master Knowledge Maps" in

einem KMU der metallverarbeitenden Industrie

4.1 Ausgangssituation und Anforderungsprofil des KMU

Bei dem im folgenden betrachteten Unternehmen handelt es sich
urn ein metallverarbeitendes Industrieunternehmen, das u.a. fol-
gende typische Eigenschaften eines KMU besitzt 1 :
Es hat ca. 100 Mitarbeitern und wird durch einen geschaftsfOh-
renden Gesellschafter geleitet. Organisatorisch ist es tiber viele
Jahre trotz der geringen GroBe von einer starken Funktionsorien-
tierung gepragt gewesen. Entsprechend existierte sowohl fachlich
als auch organisatorisch in den Kopfen der Mitarbeiter ein star-
kes Abteilungsdenken . 1m Rahmen der prozessorientierten Ein-
fOhrung eines ERP-Systems ist sowohl von Seiten der Geschafts-
fOhrung als auch von Seiten der Mitarbeiter erkannt worden, dass
sich der Wissenstand der Mitarbeiter nicht mehr nur auf abtei-
lungsinterne Ablaufe beschranken darf, damit die gesamtbetrieb-
lichen Prozesse reibungslos ablaufen konnen. Daher ist schon
wahrend der EinfOhrung des ERP-Systems eine Konzeption fOr
ein Wissensmanagement gefordert worden, das die in Abb. 1 ge-
nann ten Aspekte des Wissensmanagements sowohl informations-
technologisch als auch organisatorisch untersttitzt. Dabei sollte
vor allem auf das im Rahmen des ERP-Projektes erarbeitete Pro-
zesswissen Bezug genommen werden Die Konzeption sollte zu-
dem in Teilschritten realisierbar sein, urn im Rahmen der finan-
ziellen Mittel der Unternehmung zu bleiben. AuBerdem sollten
die begrenzten zeitlichen Kapazitaten der Mitarbeiter berticksich-
tigt werden, urn eine Dberforderung und die damit verbunden
Gefahr eines nicht erfolgreichen Projekts zu verringern . In die-
sem Zusammenhang sollte die eingesetzten Instrumente fOr den
Mitarbeiter besonders einfach und intuitiv anwendbar sein.
Den sich aus dem angeftihrten Projektumfeld ergebenden Anfor-
derungen wird durch die Konzeption und den Einsatz von Wis-
senskarten in der Variante der "Master Knowledge Maps" Rech-
nung getragen.

1 Eine ausfiihrliche Behandlung der typischen Eigenschaften von KMU

wird beispielsweise in [MULLER95) vorgestellt.

115
Wissenskarten im ERP-Umfeld von kleinen und mittelstandischen Unternehmen

4.2 Grundkonzeption einer "Master Knowledge Map" fOr KMU

Die fUr das Unternehmen entwickelte Grundkonzeption einer
"Master Knowledge Map" ist in Abbildung 59 fUr die Kundenauf-
tragserfassung exemplarisch dargestellt.

Abbildung 59: "Master Knowledge Map" zur Kundenauftrags-

erfassung
Anwendungs- Ein Prozessbaustein korrespondiert zum einen mit einem konkre-
menii (1) ten Menupfad; zum anderen lasst sich einem Prozessbaustein in
def Regel mindestens eine Eingabemaske zuordnen, wie in
Abbildung 60 gezeigt ist.

116
 Dirk Schreiber und Wolfgang Hahnel

"l'V"dnm 1!l1ilE!

-'

Komtr't!113n u".,.~,. ... I 3

Slit!!'!-M Inl l Ir----------------------~
ku:(f8riMJ'ls.:h'.9nnln
biS"dHO'RrTermn
~

r-- gerret,:ur'Q
rr-
I
I
L......"<,. roo 'fOiOO lu "'dlr.:"~"-'nj'-.n-"LIJ''-.~- III LS E RQ

0,0,_ I 3J ,DO -

Abbildung 60: Menustruktur und Eingabemasken zum Prozess-

baustein Kundenauftragserfassung

Dokumentation Zu den wesentlichen Dokumentationsquellen des Prozesswissens

(2) zahlen die vom ERP-Anbieter zur Verfiigung gestellten Standard-
dokumentation zum ERP-System sowie die zugehorigen Pro-
zessmodelle. Diese Dokumente werden in der Regel unter An-
wendung von Modellierungswerkzeugen erstellt. Beispielsweise
unterstutzt der "infor:modeler" unmittelbar das ERP-System in-
for:com. Fur den Prozessmodellbaustein Kundenauftragserfas-
sung ist in Abbildung 61 die grafische Darstellung sowie ein
Ausschnitt der textuellen Beschreibung illustriert. 1m SAP-Umfeld
gelangt zu diesem Zweck in der Regel das ARIS-Tool-Set zur
Anwendung.
Dariiber hinaus sind die unternehmensspezifischen Dokumente
wie die Ergebnisse der Prozessanalyse, die Benutzerhandbucher
sowie das QS-Handbuch von besonderem Interesse.

117
Wissenskarten im ERP-Umfeld von kleinen und mittelstandischen Unternehmen

rin__f...:.o_r _..::.D::.H:...::
. .: Ec.R'--_
:. : _ _ _ _ _ _ _ _ _ _ _ _ _---i 0 n,dlt"OOMIItI
o InAlbtlt

Kundenauftrage erlassen o ,.~

Abbildung 61: Einfaches Prozessmodell zum Prozessbaustein

Kundenauftragserfassung

Schulungsmate- Zu den Schulungsmaterialien gehbren nicht nur die vom ERP-

rial (3) Hersteller angebotenen Lernhilfen wie Schulungsmanuals und
CBT-Anwendungen, sondern auch die vom Unternehmen selb-
standig erarbeiteten Unteriagen zur Schulung der Mitarbeiter.
Berechtigungen Es scheint im Hinblick auf das Berechtigungskonzept ausrei-
(4) chend zu sein, zwischen den Endanwendern und der Gruppe
der Systembetreuer zu unterscheiden.
Customizing- Mit den Customizing-Parametern der kbnnen aus systemtechni-
Einstellungen scher und anwendungsorientierter Sicht wesentliche Einstellun-
(5) gen zum Abgleich des ERP-Systems mit den Unternehmenspro-
zessen vorgenommen werden kbnnen.
Technische An- Dieser Zweig verweist zum einen auf die relevanten Datenbank-
gaben (6) strukturen des ERP-Systems sowie die Datenstrukturen externer
Programme Chier beispielsweise datenbankgestutzte Individual-
software zur Materialdisposition in Einkauf und Arbeitsvorberei-
tung). Zum anderen wird auf die in Eigenfertigung entstandenen
Individualprogramme, die durchgefuhrten ERP-Anpassungen und
die Schnittstellen zwischen ERP-System und Individualprogram-
men verwiesen.

4.3 Informationstechnologische Umsetzung

Wie zuvor bereits angedeutet, bietet sich eine softwaregestutzte
Erstellung der "Master Knowledge Maps" an. Neben den vielen
Mbglichkeiten der grafischen Gestaltung und einem einfachen
Anderungsmanagement ermbglicht die Verwendung des Tools
"Mind Managers" die automatisierte Erstellung von Web-Seiten

118
 Dirk Schreiber und Wolfgang Hahnel

auf Basis des "Master Knowledge Maps", die dann iiber das Int-
ranet den Mitarbeitern zur Verfiigung gestellt werden konnen
[HERZOG200l]. In Abbildung 62 ist die dem Fallbeispiel entspre-
chende Web-Seite beispielhaft dargestellt.

Master-Knowledge-Map Kundenaufiragserfassung

I_.~ ..
- ....... ~-I
~.I""

.,

~~-
\ ...-
.......................

Abbildung 62 Intranet-Seite zur "Master Knowledge Map" Kun-

denauftragserfassung

5 Zusammenfassender Ausblick
Ausgehend von einem ganzheitlichen Verstandnis von Wissens-
management wurde gezeigt, dass Wissenskarten in Form von so
genannten "Master Knowledge Maps" ein zentrales Instrument
zur Verwaltung und Dokumentation von Prozesswissen darstel-
len konnen. Dabei wurde nicht, wie in der Literatur bisher iiblich
auf GroBunternehmen Bezug genommen, sondern ein Schwer-
punkt auf KMU in der Fertigungsindustrie gelegt.
Die bisherigen Erfahrungen im Fallbeispiel zeigen, dass die Mit-
arbeiter die Konzeption der Wissenskarten grundsatzlich akzep-
tieren. Dies ist aus Sicht der Mitarbeiter nicht zuletzt auf die ein-
fache und intuitive Methode des Mind Mappings und des zuge-
horigen Softwaretools zuriickzufiihren. Es gibt mehr Verstandnis
iiber die Ablaufe in anderen Abteilungen, so dass die abteilungs-
iibergreifende Zusammenarbeit gefordert wird. Schon jetzt haben
sich in Ansatzen die Einsatzgebiete der Mitarbeiter vergroBert,

119
Wissenskarten im ERP-Umjeld von kleinen und mittelstandischen Unternehmen

was gerade fUr KMU die Flexibilitat in der Personalplanung signi-

fikant erhbhen kann. Diese Vorteile lassen sich sowohl fUr die
Fachabteilungen als auch fUr die EDV-Abteilung konstatieren,
wobei fUr letztere das formal dokumentierte Wissen uber die Ab-
laufe eine ideale Erganzung des notwendigen Pflichtenheftes
darstellt, beziehungsweise den Verzicht eines solchen rechtferti-
gen kann. Die positive Entwicklung vorausgesetzt, wird es in ei-
nem nachsten Schritt urn eine starkere Integration des Wissens-
managements in die Kernprozesse des Unternehmens gehen.
Dies muss einher gehen mit einer stetigen Personal- und Organi-
sationsentwicklung, die Wissensmanagement als Teil der Unter-
nehmenskultur etabliert.
Urn jedoch Aussagen treffen zu kbnnen , inwieweit "Master
Knowledge Maps" einen nachhaltigen Schritt fUr das mittel standi-
sche Unternehmen in Richtung Wissensmanagement darstellen,
ist es noch zu fruh, da sich die genannten mbglichen Probleme
beim Einsatz von Wissenskarten teilweise erst im Zeitablauf
spurbar bemerkt machen.
Bisher wurde Wert auf die Erst-Erfassung und einheitliche Do-
kumentation des Wissens gelegt; in weiteren Stufen der Instru-
mentalisierung der Wissenskarten ist ein besonderes Augenmerk
auf die Pflege und Wartung der Karten als aktive Leitungs-
Aufgabe zu legen, sowie die Konsistenz und Vergleichbarkeit der
Wissenskarten zu organisieren. Es wird erwartet, dass die Koor-
dination der Wissensdokumentation aufgrund des gewahlten
Werkzeuges vereinfacht wird, vor allem im Vergleich zu den
klassischen Dokumentationsmethoden mittels einer Textverarbei-
tung.

6 Literaturverzeichnis

(BACH98] Bach, N. ; Homp, Ch. : Objekte und Instrumente des Wis-

sensmanagements, in ZjO 6/1997, S. 340-347.
(BUZAN97] Buzan, T.; Buzan, B.: Das Mind-map-Buch, Lands-
berg am Lech 1997.
fDA VENPORT98] Davenport, T.h:; Prusak, L.: Wenn ihr Unter-
nehmen wujSte, was es alles weiss ... : das Praxisbuch zum
Wiessensmanagement. Landsberg/Lech, 1998.
(EPPLER99J Prasentation Knowledge Maping, 1999

120
 Dirk Schreiber und Wolfgang Hahnel

[HEISIG2001] Heisig, P. : Business Process Oriented Knowledge

Management, in Mertens, K , Heisig, P., Vorbeck, j. (Eds):
Knowledge Management - Best Practices in Europe -;
Springer Verlag 2001, S. 13 -36.
[HERZOG2001] Herzog, D.;jeschke, H: Mind Manager 4, EJJekti-
ver arbeiten und lernen mit Mind Mapping, Munchen
2001.
[LEHNEROOa] Lehner, F ; Remus, u.: Prozessmanagement im Mit-
telstand als Ausgangspunkt fur die Einfuhrung des Wis-
sensmanagements, in: Modellierung betrieblicher Informa-
tionssysteme, Proceedings der MobIS-Fachtagung 2000, S.
179- 204.
[LEHNEROOb] Lehner, F: Organisational Memory. Konzepte und
Systeme fur das organisatorische Lernen und das Wis-
sensmanagement, Munchen 2000.
[MERTINS2001] Mertens, K, Heisig, P., Vorbeck, j. (Eds): Knowl-
edge Management - Best Practices in Europe -; Springer
Verlag 2001
MORTON98] Morton, C: Intranets: Some Problems and Solutions,
in: Managing Information, 1998, H.5, S. 26-27.
[MULLER95] Muller, CA: Strategische Fuhrung europdischer mit-
telstdndischer Unternehmen, Lang 1995, S.32-56.
[NEUMANN98] Neumann, St.; Plugge, B.; Finerty, F: The Art of
Knowledge -Potential aus Wissen schapfen, in: Informati-
on Management, 13.jahrgang 1998, Nr. 1 S. 66-74.
[NOHR99] Nohr, H: Das Projekt OurKnowledge, Wissensmana-
gement in einem kleinen Beratungsunternehmen, HBI ak-
tuell, Heft 2, Stuttgart, 1999, S. 16 - 19.
[NOHROO] Nohr, H: Wissen und Wissensprozesse visualisieren,
Arbeitspapiere Wissensmanagement, Stuttgart 2000, ISSN
1616-53 49.
[PROBST99] Probst, G.; Raub, S.; Romhardt, K : Wissen managen:
Wie Unternehmen ihre wertvollste Ressource optimal nut-
zen, Wiesbaden (3.Aujl.), 1999.
[TEUFEL99] Teufel, T.; Rohricht, j.; Willems, P.: SAP Rl3 ProzejS-
analyse mit Knowledge Maps, Munchen 1999.

121
 Andreas Kraft und Andreas OherbOrsch

Oas Konzern-Einkaufs-Informations-System (KEIS) bei RWE

===

Andreas Kraft und Andreas Oberborsch

1 Der RWE Konzern

1.1 Oberblick
Der RWE-Konzern, im Jahre 1898 gegrundet, blickt heute auf ei-
ne wechselvolle Geschichte zuruck. In den letzen beiden Jahr-
zehnten hat sich der, einstig auf die reine Stromerzeugung kon-
zentrierte, Konzern zu einem weltweit agierenden Multi-Utility
Anbieter gewandelt.
Kerngeschiifts- In den vier, das Multi-Utility Geschaft beschreibenden Kernge-
felder schaftsfeldern Strom, Naturgas, Wasser & Abwasser und Abfall &
Recycling, hat RWE europaweit fiihrende Marktpositionen inne.
Ailein bei der Stromversorgung beliefert das Unternehmen mehr
als 10 Millionen Privathausalte, 50.000 Industrie- und Gewerbe-
kunden sowie uber 100 weiterverteilende Energieversorger. Mit
insgesamt 34 Millionen Kunden ist RWE auBerdem der weltweit
drittgrbBte Anbieter fur Wasser- und Abwasserdienstleistungen.
Die strategische StoBrichtung in den letzen beiden Jahren war
der Auf- und Ausbau dieser Marktpositionen durch Zukauf und
Integration von externen Unternehmen. So sind hier als groBe
Akquisitionen die Thames Water pic. , American Water Works
und Transgas zu nennen.

123
Das Konzern-EinkauJs-InJormations-System (KEIS) bei RWE

Abbildung 63: Markrposirion RWE (aus: Kuhnr, 2002, Folie 8)

1m Nichr-Kerngeschafr, den so genannren Finanzbeteilungen,

wurden gezielt Desinvestitionen betrieben. So wurde das Down-
srream-Geschafr der DEA in ein Joint Venture mit Shell einge-
bracht. Die Finanzbeteilung HOCHTIEF wird im Geschaftsjahr
2002 dekonsolidiert und stehr ebenfalls wie die Finanzbeteili-
gung Heidelberger Druckmaschinen, mit dem sparesren Realisie-
rungsdatum Ende 2003, auf der Verkauflisre.
Umsatz Der Umsatz des RWE-Konzerns belief sich im Geschaftsjahr
2000/ 2001 auf 62,9 Mrd. bei 169.979 in tiber 1.600 rechtlich ei-
genstandigen Unternehmenseinheiten beschaftigren Mitarbeitern .
Enrsprechend hererogen gestaltet sich die Systemlandschafr mit
SAP R/3, das als gemeinsames betriebswirtschaftliches Standard-
softwaresystem festgelegt worden ist.

1.2 Marktumfeld
Das Marktumfeld, in dem der RWE-Konzern in den letzten Jahr-
zehnten agierte, war gepragt durch Gebietsmonopole, basierend
auf dem 6ffentlichen Versorgungsauftrag. Ein ausk6mmliches
Wirtschafren war somir sichergestellt.

124
 Andreas Kraft und Andreas Oberb6rsch

In den letzten Jahren sind Liberalisierungsvorhaben durch die

europaische Legislative auf den Weg gebracht worden, die eine
Oberfuhrung der Monopolmarkte in Wettbewerbsmarkte 20m
Zie! haben.
Liberalisierung So ist als einschneidendes Datum der l.Aprii 1999 20 nennen,
seit dem der deutsche Strommarkt 20 100% liberalisiert ist. Dies
bedeutet in der Konsequenz, dass jeder Stromkunde, ob kleiner
Privatverbraucher oder GroBkonzern, seinen Lieferanten ohne
Restriktionen wahlen kann.
Dieses Ereignis hat 20 hohem Wettbewerbsdruck in der Energie-
branche gefuhrt. Zum einen auBert sich das in Fusionen der gro-
Ben Marktteilnehmer, wie der Fusion von VIAG und Veba 20
EON oder der Fusion von RWE und YEW. Zum andern stehen
bei den Anbietern aile internen Wertschbpfungsketten auf dem
Effizienzprufstand.

2 Einkauf und Materialwirtschaft im RWE Konzern

2.1 Organisation und Aufgaben

1m Rahmen der Fusion zwischen RWE und YEW im Jahr 2000
hat eine Neuausrichtung der materialwirtschaftlichen Aktivitaten
stattgefunden. Der neue RWE-Konzern hat eine Dienstleistungs-
gesellschaft, die RWE Systems AG mit Sitz in Dortmund, gegrun-
det, die neben einer Vielzahl von ubergreifenden Dienstleistun-
gen auch die materialwirtschaftlichen Aufgaben ubernommen
hat.
Diese bestehen zum einen in der operativen Einkaufsabwicklung
fur die Gesellschaften im Stromgeschaft, wie RWE Power AG,
RWE Net AG und RWE Plus AG, 20m anderen in dem von der
RWE Holding ubernommenen Auftrag, die Einkaufsaktivitaten
strategisch uber den gesamte RWE-Konzern zu koordinieren und
20 optimieren.

2.2 Ansatze zur Einkaufsoptimierung

1m Rahmen der Dynamisierung des Wettbewerbsumfe!des des
RWE-Konzerns und der daraus resultierenden Effizienzprufung
der internen Wertschbpfungsketten ist die Optimierung und Ko-
ordinierung des Auftritts des gesamten RWE-Konzerns am Be-
schaffungsmarkt als eine Potential versprechende MaBnahme i-
dentifiziert worden.

125
Das Konzern-Einkaufs-Informations-System (KEIS) bei RWE

Die sich daran anschlieBende Operationalisierung zur Hebung

des Potentials hat unter anderem die folgenden vier Hebel als fur
den RWE-Konzern wertschbpfend identifiziert:
Biindelung Die Bundelung von Bedarfen, z.B. durch Einsatz von standardi-
sierten Betriebsmitteln, ermbglicht das Ausschreiben und Ver-
handeln von grbBeren Mengen mit entsprechendem Einstands-
preissenkungspotential.
Reduzierung Die Reduzierung von Lieferanten bietet zum einen die Mbglich-
der keit der gebundelten Platzierung von Bedarfen, lasst auf der an-
Lieferantenan- deren Seite Mbglichkeiten zu, den Lieferanten prozessoptimal in
die interne Wertschbpfungskette (Supply-Chain) einzubinden.
Durch Reduzierung des Betreuungsaufwands von Lieferanten er-
geben sich zusatzliche Prozesskostenvorteile.
Gegengeschdfte Lassen sich mit vertretbarem Aufwand Gegengeschaftsbe-
ziehungen erkennen, kann hierauf die bestehende Kunden-
I Lieferantenbeziehung mit Cross-Selling-Aktivitaten intensiver
genutzt werden.
Lieferantenent- Die konzernweite Identifikation von Lieferanten bietet die Mbg-
wicklung lichkeit Qualitatslieferanten zu erkennen und langfristige Partner-
schafen durch LieferantenentwicklungsmaBnahmen zu etablieren.

2.3 Rahmenbedingungen
Beschaffungs- Wie im Kapitel 1.1 aufgezeigt, ist der RWE-Konzern, bedingt
koordination durch die Vielzahl der Gesellschaften, heterogen strukturiert und
regional aufgestellt. Bei der nun im Naheren beschriebenen stra-
tegischen Aufgabe der RWE Systems AG, eine konzernweite Be-
schaffungskoordinierung und -optimierung zu realisieren, ist mit
folgenden beispielhaft umrissenen Rahmenbedingungen zu
kampfen:
Die Einkaufsverantwortlichen konnten weder bei der
Beantwortung von strategischen Fragestellungen, noch
bei der konkreten Verhandlungsvorbereitung, auf eine
einheitliche und strukturierte Datenbasis zuruckgreifen,
die einen integrierten Blick auf die eigenen und die
Konzernaktivitaten aufzeigt.
Ein konzernubergreifendes Informationssystem stand
nicht zur Verfligung. Auswertungen auf Konzernebene
konnten nur mit extrem hohen manuellen Aufwand er-
stellt werden

126
 Andreas Kraft und Andreas Oberborsch

Die Ermittlung und Bereitstellung von Kennzahlen zur

Einkaufssteuerung erforderte entsprechende manuelles
Vorgehen.
Eine Transparenz von Einkaufsdaten war nicht gegeben,
besonders im Hinblick auf eine Erkennung von Gegen-
geschaftsbeziehungen, die den Fall beschreiben, dass ein
Lieferant von RWE zugleich Kunde bei RWE ist.
Unter diesen Rahmenbedingungen war es nicht mbglich, weder
den Einkaufsverantwortlichen, noch Vorstanden ad-hoc Frage-
stellungen tiber Lieferantenbeziehungen in einem vertretbaren
Zeitraum zu beantworten.
1m Abgleich der Rahmenbedingungen zu den beschriebenen An-
satzen zur Einkaufsoptimierung wird deutlich, das fUr samtliche
identifizierten Ansatze die notwendige konzernweite Transparenz
fehlt. So hat der RWE-Konzern im Jahr 1998 begonnen das trans-
parenzschaffende Konzern -Einka ufs-Informations-System (KEIS)
zu konzipieren und zu realisieren.

3 Oas Konzern-Einkaufs-Informations-System (KEIS)

3.1 Zielsetzung
Kernzielsetzung dieses Informationssystems war die Schaffung
von Transparenz. 1m Rahmen von Workshops wurden folgende
Dimensionen erarbeitet, in denen einkaufsrelevante Fragestellun-
gen durch das Informationssystem ad-hoc beantwortet werden
sollen:
Organisations- MaBgebliche Dimensionen sind hier die Legaleinheiten der Kon-
struktur zerngesellschaften sowie die Strukturen in den SAP Systemen,
wie Einkaufsorganisation bzw. Lieferwerk.
Volumina Ziel dieser Dimension war es, den Beschaffungsvorgang aus
zwei Blickwinkeln abzubilden. Zum einen aus der Sicht des Be-
schaffungswesens (SAP Modul Materials Management MM) und
zum anderen aus der Sicht des Rechnungswesens (SAP Modul
Fl). Durch den Ausweis der Bestellvolumina sowie Rechnungs-
volumina kbnnen Vorgange erkannt werden, die ohne Beteili-
gung des Einkaufs, dem sog. Maverick Buying, abgewickelt wer-
den.
Liejeranten Bei dieser Dimension sollte die Mbglichkeit geschaffen werden,
einzelne Lieferanten ganzheitlich analysieren zu kbnnen. Bestell-
und Rechnungsvolumen sollten auf der Ebene der Lieferantenge-

127
Das Konzern-EinkauJs-InJormations-System (KEIS) bei RWE

sellschaft aber auch auf der Lieferantenkonzernebene bereitge-

stellt werden.
Warengruppen Hier liegt die Warengruppensystematik des RWE-Konzerns zu
Grunde . Gleichzeitig sollten Auswertungen nach den Waren-
gruppensystematiken der Quellsysteme mbglich sein.
Zeitraum Zielsetzung war es hier, Sonderfalle, wie Rumpfgeschaftsjahre
oder unterjahrige Geschaftsjahre problemlos abzubilden. Als
kleinste Einheit wurde ein Kalendermonat definiert.
Ein Beispiel fUr eine solche Fragestellung, die durch das Informa-
tionssystem beantwortet werden soll, wird in folgender Grafik vi-
sualisiert:

Konzerngesellschaften RWE Rheinbraun

Volumina Einkaufsvolumen

Lieferanten Siemens

Warengruppen Fernsprechanlagen

Zeitaume 2000

Welche Konzerngesellschaft beschafft wieviel bei welchen

Lieferanten in welcher Warengruppe in welchem Zeitraum ?

Abbildung 64: Einkaufsrelevante Fragestellung

1m Kern soll das System die Frage "Welche Konzerngesellschaft

beschafft wie viel, bei welchen Lieferanten, in welcher Waren-
gruppe, in welchem Zeitraum ?" umfassend beantworten. Durch
Kombination und Einschrankungen dieser Dimensionen stellt das
KEIS zielgerichtet Informationen bereit, die zur Untersttitzung ei-
nes strategischen Einkaufs zwingend notwendig sind.
InJormation Daruber hinaus wird das Ziel verfolgt, den Informations- und
und Wissens- Wissensaustausch im Konzern uber einkaufsrelevante Fragestel-
austausch lungen zu intensivieren . Es wird so die Grundlage gelegt fur eine
konzernweite optimierte Einkaufskoordination und -steuerung.
Die in der Vergangenheit gemachte Beobachtung, dass ein Liefe-

128
 Andreas Kraft und Andreas Oberb6rsch

rant mit verschiedenen Konzerngesellschaften die gleiche Leis-

tung zu verschiedenen Preisen auf Basis von verschiedenen Ver-
tragen erbringt, wird mit Hilfe des Informationssystems erkannt
und fUhrt zu einer kurzfristigen Verbesserung von Konditionen.
Mit dem Ziel, die Vertriebsorganisation bei der Erkennung von
Gegengeschaftsbeziehungen zu unterstutzen, wurde die Zieldefi-
nition abgeschlossen.

3.2 Basiskonzept
Bei der Konzipierung des KEIS hat sich RWE fUr ein modulares
Konzept entschieden, urn auf zukunftige Anforderungen flexibel
reagieren zu kbnnen . In der folgenden Grafik wird das Basis-
konzept dargestellt:

Abbildung 65: Modulares Basiskonzept KEIS

Das Basiskonzept KEIS besteht aus den im folgenden beschrie-

benen sieben Modulen:
Konzerninterne Hierunter ist ein konzerninternes Beschaffungsverzeichnis zu
Bezugsquellen verstehen, in dem die konzerninternen Lieferanten mit ihren
Leistungen und Produkten aufgefUhrt sind.
Rahmenverein- Die Verknupfung zu einer Konzern-Rahmenvertragsdatenbank ist
barungen: hier realisiert. In diese Datenbank werden konzernweit gultige
Rahmenvertrage eingestellt und zum Abruf vorgehalten.
Externe Daten- Hierunter ist der Zugriff auf externe Datenbanken mit beschaf-
banken fungsmarktrelevanten Daten, wie z.B. Zeitschriften-Archive oder
Finanzinformationen zu verstehen.

129
Das Konzern-Einkaufs-Informations-System (KEIS) bei RWE

Hier ist das Ziel, Kundendatenbanken des Vertriebs mit Lieferan-

Gegengeschdjte
tendatenbanken des Einkaufs zu verkniipfen urn so Gegenge-
schaftsbeziehungen ausfindig machen und bewerten zu k6nnen.
Beschaffungs- In diesem Modul soli eine konzernweite Wissenslandkarte auf-
verantwortliche gebaut werden, in der Einkaufer ihre Kollegen mit gleichen Wir-
kungskreis in anderen Konzerngesellschaften ausfindig mach en
k6nnen.
Lieferanten Hierunter sind aile M6glichkeiten der lieferantenbezogenen Ana-
lysen gefasst.
Warengruppen Unter diesem Modul sind aile M6glichkeiten der warengruppen-
bezogenen Analysen zusammengefasst.
Der Fokus der weiteren Betrachtung liegt auf der Beschreibung
der Realisierung der Module "Lieferanten" und "Warengruppen".

3.3 Plattform
Urn eine konzerniibergreifende Lieferanten-/ Warengruppenana-
lyse zu erm6glichen musste ein Plattform gefunden werden, wel-
ches es erm6glicht, Daten aus einer Vielzahl von Quellsystemen
konsistent zu konsolidieren und zusammenzufiihren. Ebenso
muss dieses System hoch performant arbeiten, da die erwartete
Datenmenge 1 Mio . Datensatze weit iibersteigt. Des Weiteren
soil ten Analysefunktionen, wie Drill down (Autl6sen von aggre-
gierten Daten nach einer Dimension) oder Slice and Dice (der
Austausch von Betrachtungsdimensionen) zur Verfiigung stehen.
Systemauswahl Aus dieser grob skizzierten Anforderungsdefinition sind Soft-
wareprodukte der Kategorie Data-Warehouse in die engere Aus-
wahl gekommen. RWE hat sich hierbei fUr das Business Informa-
tion Warehouse (BW) der SAP entschieden, da die Mehrzahl der
anzuschlie8enden Quellsysteme SAP R/ 3-Systeme sind. Mit dieser
Auswahl konnten Schnittstellenprobleme minimiert werden.
Die SAP bietet mit dem Produkt SAP BW eine komplette Soft-
warel6sung fUr den Betrieb eines Data-Warehouses an. In der
folgenden Architekturiibersicht sind die einzelnen Komponenten
im Zusammenhang dargestellt:

130
 Andreas Kraft und Andreas Oberborsch

I
User Access

Data Transformation
and Management

SAP, Legacy and 3rd party data

Abbildung 66: Architektur SAP BW (aus: Mahr, 2001, Folie 10)

Architektur des Die Architektur des SAP BW Iasst sich in drei Ebenen unterteilen .
SAPBW Die erste Ebene ist die Ebene der Quellsysteme, d.h. der operati-
ven Transaktionssysteme. Hier werden die Daten generiert, die
in das Data-Warehouse geladen werden sollen. 1m Fall KEIS sind
dies die Bestellbelege des SAP Moduls MM und die Buchungsbe-
lege des Moduls FI. Die zweite Ebene beschreibt die Datenhal-
tung des Data-Warehouses mit den entsprechenden administrati-
ven Tools. Die dritte Ebene ist die Prasentationsebene mit dem
Nutzerzugriff.
ETL-Prozess Der Betrieb eines Data-Warehouse gliedert sich in zwei Stufen.
Die erste Stufe ist der so genannte ETL-Prozess (Extract, Trans-
form, Load) mit dem das Data-Warehouse gefUllt wird. Hiermit
ist der Extraktionsprozess aus den Quellsystemen beschrieben,
an den sich die Tranformations- und Aggregationsstufen an-
schlielSen, bevor die so auf Konsistenz gepriiften Daten in die n-
dimensionalen Datenwurfel (Info-Cubes) geladen werden.
Zur Unterstlitzung des ETL-Prozesses gibt es eine Vielzahl von
Drittanbietersoftware (z.B. von Acta oder Informatica). 1m Rah-
men von KEIS hat sich RWE entschieden, die standardmalSig von
der SAP mit dem BW ausgelieferten Tools einzusetzen, da die zu
extrahierenden Quellsysteme grolStenteils SAP R/ 3-Systeme sind.

131
Das Konzern-EinkauJs-InJormations-System (KEIS) bei RWE

Mit dem SAP BW wird der ETL-Prozess mit den Tools Staging
Engine, dem Meta Data Manager und der Administrator Work-
bench unterstutzt.
Staging Engine Die Staging Engine (Datenbereitstellungssystem) hat im Kern die
Aufgabe, die aus den Quellsystemen gelieferten Daten automati-
siert zu ordnen und zu transformieren. Mit Hilfe von Zeitregeln
fordert das Datenbereitstellungssystem den Datenauszug aus den
Quellsystemen an. Diese so extrahierten Produktivdaten durch-
laufen eine Reihe von Verdichtungs-, Zuordnungs- und Trans-
formationsschritten, ehe sie in die zentralen Datenbehalter des
SAP BW, den InfoCubes, integriert werden.
Meta Data Ma- Mit dem Meta Data Manager kann der Administrator InfoCube-
nager Definitionen und technische Metadaten (z.B. verbundene Quell-
systeme mit ihren InfoSources) sowie Geschaftsregeln fUr Info-
Cube Aktualisierungen anlegen und pflegen.
Administrator In der Administrator Workbench sind verschiedene Werkzeuge
Workbench zusammengefaBt, mit denen der Administrator des SAP BW aile
Aufgaben, die bei der Erstellung und dem laufenden Betrieb des
Business Information Warehouses anfallen, unter der SAP-GUI
(Graphical User Interface) Oberflache erJedigen kann.
Neben diesen Funktionen wird innerhalb der Administrator
Workbench auch die Nutzer- und Berechtigungsverwaltung so-
wie die Pfiege von Berichtskatalogen abgewickelt.
In der zweiten Stufe der Abfragdefinition (Querydefinition) kon-
nen die in die Info-Cubes geladenen Daten durch den Nutzer
analysiert werden.
Business Als Analyseoberfiache steht dem Nutzer mit dem Business Explo-
Explorer rer Analyzer eine um Analysefunktionen erweiterte MS-Excel-
Oberfiache zur Verfugung.
Unter dieser Oberflache werden die Queries definiert. Diese
werden an den OLAP-Prozessor (Online Analytical Processing)
des SAP BW geschickt, der die entsprechenden Abfragen auf den
Info-Cubes vornimmt. Das Abfragergebnis wird von dem OLAP-
Prozessor an die Obertlache zuruckgemeldet und in MS-Excel
Tabellenform dargestellt. Mit den erweiterten Funktionen der Ex-
cel-Oberflache kann das Abfrageergebnis weiter bearbeitet wer-
den. So konnen z.B. die Daten weiter detailliert (Drill down)
werden, oder bestimmte Dimensionen hinzugefugt oder einge-
schrankt werden, um die Daten aus einer anderen Perspektive
betrachten zu konne (Slice & Dice).

132
 Andreas Kraft und Andreas Oberb6rsch

Dartiber hinaus kbnnen die yom SAP BW gelieferten Daten mit

dem gewohnten Funktionsumfang von MS-Excel bearbeitet
werden.
Erganzend steht Nutzern, die ein Standardberichtswesen mit ein-
geschrankter Analysefunktionalitat verlangen, wie Ftihrungskrafte
und Vorstande, mit dem Business Explorer Browser eine intuitiv
bedienbare OberfJache zur VerfUgung.
Web Reporting Neben diesen beiden NutzeroberfIachen, die eine Client Installa-
tion des SAP GUI voraussetzen, bietet SAP fUr das BW ein Web-
Reporting an. Hier besteht die Mbglichkeit, die im Business Ex-
plorer Analyzer erstellten Berichte im Web-Reporting zu verbf-
fentlichen. Technologisch ist hier eine Installation des SAP ITS
(Internet Transaction Server) notwendig. So besteht die Mbglich-
keit, aus den Web-Reports heraus die OLAP-Funktionalitaten,
wie z.B. Drill down, zur VerfUgung zu stellen.
RWE hat im Rahmen eines First Customer Shipments Anfang
1999 begonnen, das Konzern-Einkaufs-Informations-System auf-
zubauen.

4 Erfolgsfaktoren fOr KEIS

Zwei grundlegende Herausforderungen mussten tiberwunden
werden urn eine konzernweite Analyse der Einkaufsdaten zu er-
mbglichen.
Zum einen musste ein Weg gefunden werden, die in den ver-
schiedenen Quellsystemen vorhandenen unterschiedlichen Wa-
rengruppensystematiken auf Konzernebene zusammenzufUhren.
Die Warengruppenphilosophien der einzelnen Konzerngesell-
schaften unterscheiden sich sowohl in Auspragung der Detailtie-
fe (Anzahl der Warengruppen von knapp tiber 100 bis weit tiber
1000) als auch in Struktur und Semantik.
Konzernwaren- Als Lbsung wurde ein Konzernwarengruppenschltissel definiert,
gruppenschlUs- dem die einzelnen Warengruppen der Quellsysteme zugeordnet
set wurden. 1m KEIS besteht aber weiterhin die Mbglichkeit, neben
der Analyse tiber den Konzernwarengruppenschltissel, auf Ebene
der Warengruppenschltissel der Quellsysteme, Auswertungen zu
erstellen.

133
Das Konzem-EinkauJs-InJormations-System (KEIS) bei RWE

KEis - Warengruppen
I
Baumaterial Bauholz Holz Kantholz
I
Baumaterial Rundholz
Baumaterial Schalbretter

- Umsetzungstabellen =[)
I 1\ I I U
I Warengruppen der Konzern-Gesellschaften I
I JJ I I I
Abbildung 67: Funktionsiibersicht der Warengruppenumset-
zungstabellen

LieJeranten- Zum anderen musste ein Weg gefunden werden, die Lieferanten-
identifikation stammdaten der Quellsysteme zusammenzufiihren. Innerhalb der
IT-Systeme der RWE Konzerngesellschaften wurden Lieferanten
nicht selten mehrmals, teilweise auch mit unterschiedlichsten
Schreibweisen, gefiihrt. Hier ist aus der Praxis zu berichten, dass
schon in den einzelnen Quellsystemen in wahrnehmbarem Um-
fang Doubletten vorhanden sind. Bei der Konsolidierung einer
Vielzahl von Quellsystemen potenziert sich diese Problematik.
Des Weiteren sind die Lieferantennummern, die in den Quellsys-
temen unabhangig vergeben werden, nicht kompatibel zueinan-
der.
Datenanreiche- Zur Bewaltigung dieser Herausforderung werden die vom SAP
rung Business Information Warehouse verwalteten Stammdaten samt-
licher RWE Lieferanten regelmaBig mit der weltweit grbBten Un-
ternehmensdatenbank des externen Dienstleisters Dun & Brad-
street, die mehr als 62 Millionen Adressen umfasst abgeglichen.
Hierbei kommt die so genannte D-U-N-S Nummer (Data Univer-
sal Numbering System) als eindeutiger Schliissel , unter dem sich
konzernweite Auswertungen generieren lassen, zum Einsatz. Ein
neunstelliger Zahlencode, der von Dun & Bradstreet entwickelt
wurde, fungiert als unverwechselbarer Indikator. So lassen sich
Doppeleintrage schnell identifizieren. Dariiber hinaus enthalten
die angereicherten Daten Informationen zu Umsatz, Mitarbeiter-
zahlen und anderen unternehmensdemographischen Angaben.

134
 Andreas Kraft und Andreas Oberb6rsch

Die Datenrationalisierung durch D&B bewirkt, dass aile Berei-

che, Abteilungen und Funktionsgruppen innerhalb der RWE eine
gemeinsame Informationsplattform nutzen. Lieferantenstammda-
ten werden aus den verschiedensten Quellen in ein Standard-
format konvertiert.

5 Erfahrungen mit KEIS

Mit dem Aufbau eines Data-Warehouses und der Umsetzung der
Erfolgsfaktoren ist in Detailarbeit der Kern des KEIS entstanden.
In Abbildung 68 ist eine Beispielauswertung zu sehen, die den
konzernweiten Umsatz eines Lieferanten nach Warengruppen,
aufgeteilt nach Konzerngesellschaften, aufzeigt.

K a Ie nd . ria hr
l< aUl ru /Mo na l Januar2000 .. 0ez omb,r2000
F Ohr G o.(Bu K,.,
D U NS G lob ,' Ultam,,, ( L lel er ' nI) L I.'.tlntXYZ
DUN S -Nt (Llef. "nl ,
OuS ys
L1a fa rlln l
K . ,,,ua tUln
W . fo ng ru pp . (Ko nz.,")
Akllvllr B IIw.'I(n.uo) l n Eu ro
KEI$W.rtngruppan I
Akth'.rS tellwert(neUo, l n Euro
W . ,o og ru pp a (Ko n u , n ) F u tlrG o. (BuK rs) t"---G lllc:nln 3 G llachaU4
Iv K E IS I KEI$.W.rongruppot\ 2'""'1:717 .0" 0 . 20 E'"UR " .991---:905 .76 E UR
,1,1
[>
[>
AAOO
B AOO I B II U$to It,/F, r Ug b t,lI,
C hem le/Patroeh em I. / P harm 81: Clut lka
11 781 , 73 E UR
20 . 250 , 73 EUR
.1 888 ,43 E UR

V CAGO Enorglt'ochnlk 5 .990 . 310 , 1 4 EUR 849069 ,41 EU R

'il C 800 Elilktro t echnl$che Grundblluioll, 2 .0 5 8178 ,72 SUR 7936 ,42 EUR
C 8 00 Ell!klro l ee::hnlsehe Grundb .. utelle t-
D C801 Ell!ktron lache Bauelemente 43 ,608 ,S7 EUR 4224 ,00 EuR

1 [> C 8 28 Schaller , 669 .759 ,45 EUR 1 . 1 20 ,00 SuR

J
.t;. ce08 K .. belg a rn Itu re n 4 .965 ,51 EUR 364 ,70 eUR
I> CC 18 Le Ilu n aaverb Inder 43 .297 . 11 EUR 263 ,32 Eu R
I>
1>
eC32
CC51 -- F nile itu n a a/S Ie 110 nab. u r:e u 9
S e h rin kelG ehAu /K la.en/D o . e nIT .feln
j-
82 ,352 ,87 EUR
- -
[> CC 59 E rdu n 9 a /811Izae::hulzm ate rl, 1
!> C 000 Ene rg lee rz eu a u ng/ verte lIun a 3763205 ,12 EUR 799 .873 . '4 EUR
!> C E 00 E nerg 58an w en du ng 67 .170 ,42 EUR 3S 429 .39 EUR
C Z01 allgemeine MII.erlanen zur E lektrOlee::hnlk 100214 .28 EUR 5830 ,.6 EUR
t- [> OAOO IV /N.e h rlchl. n.fP r oz . B Ie IIt.e:: h n III 7 .863 .753 .5. EUR 967 _439 . 16 EUR
[> ... 00 M .B/O b'rwachu n ga/R e& eltech n III 1.423322 .34 EUR I 124 _280 .01 E UR
[> F AOO U.ae::hl n enbau 4 _503 .2 4 EUR 261 ,40 EUR
[> GAOO 80 ro -/A rb el 45 Ie:: h erhella. u .alallu n9 ' 4 _3 ' " ,59 EUR 19 .4 3 EUR
IAOO R oh. tofl./H a Ib :r:eu" a / Lelim at. rl.1
~ TAOO Fr. m d lela t o w .F rem dll. f.u . I.I.lu n" e n 6 . 'OS _97 1.89 EUR 182 1 _976 .25 E UR
I> WAOO Profekte t- 279 .772 .00 EUR ' 88 _971 ,67 E U~
[> XXOO Ungekll,tenehlend. Zuordnung.n

Abbildung 68: Beispielauswertung aus KEIS

Seit Produktivsetzung des Systems im 3.0uartal 1999 hat RWE

gute Erfahrungen mit dem KEIS gemacht. Schon bei der Identifi-
kation von Einsparpotentialen hat sich das KEIS als sehr hilfreich
erwiesen . Bei der daraus resultierenden DurchfUhrung von kon-

135
Das Konzern-Einkau!s-In!ormations-System (KEIS) bei RWE

zerniibergreifenden Beschaffungsprojekten ist das KEIS somit ei-

ne unverzichtbare Datenquelle geworden.
Lieferanten- Das zunehmend an Bedeutung gewinnende Lieferantenmanage-
management ment kann ohne Harmonisierung der Lieferantenstammsatze nur
mit einem enormen manuellen Aufwand betrieben werden. Auch
hier liefert das KEIS zeitnah die erforderliche Datenbasis.
SchlieBlich unterstiitzt das KEIS den Einkaufscontrollingprozess
und den Aufbau eines konzerniibergreifenden Einkaufsbericht-
wesen.

6 Ausblick
1m Rahmen der Nutzung des Konzern-Einkaufs-Informations-
Systems haben sich folgende Themenstellungen ergeben, die in
den nachsten Monaten angegangen werden.
Datenqualitat In der taglichen Arbeit mit KEIS wird, besonders durch die hohe
in Quellsyste- Aggregationsstufe der Einkaufsdaten, offensichtlich, dass die Wa-
men rengruppenzuordnung in der operativen Arbeit nicht mit der
Sorgfalt vorgenommen werden, wie dies wunschenswert ist.
MaBnahmen zur Sensibilisierung der Einkaufer laufen.
Bisher sind im KEIS ca. 80 % des Einkaufsvolumens des RWE
Konzerns abgebildet. In den nachsten Monaten wird der Roll-out
Prozess in den Konzern so weit abgeschlossen, dass alle in SAP
R/ 3 verfiigbaren Einkaufsbelegdaten in KEIS eingespielt sind.
Integration De- Der Abgleich mit den Debitorendaten zur Erkennung von Ge-
bitoren gengeschaftssituationen ist unterminiert. 1m Augenblick wird ein
Pilotprojekt mit einer Vertriebsniederlassung implementiert, in
der die Kreditoren und Debitorendaten zwischen Vertrieb und
Einkauf ad-hoc auf Dateibasis ausgetauscht werden. In dies em
Piloten soli liberpruft werden, welche Potentiale dem Konzern
durch den Einsatz der Informationen entstehen konnen und ob
vor diesem Hintergrund die aufwendige Kopplung der Systeme
wirtschaftlich sinnvoll ist.
Web Reporting Durch Einsatz des ITS (Internet Transaction Server) von SAP im
RWE Konzern wird der Zugriff auf das KEIS mit der Internet-
Technologie moglich. Eine Webreporting-Site befindet sich im
Aufbau.
Automatisie- Der ETL-Prozess ist im Hinblick auf die Quellsysteme sowie den
rung ETL- eigentlichen Ladeprozess in das KEIS sehr hoch standardisiert
Prozess und automatisiert. Die dazwischengeschaltete Identifikation der

136
 Andreas Kraft und Andreas Oberb6rsch

Lieferantendaten durch den Dienstleister Dun & Bradstreet bein-

haltet jedoch mehrfache Medienbruche. Ansatze zur Optimierung
dieses Prozessteils sind in Arbeit.
Aktuell wird ebenfalls daran gearbeitet, die Konzernhierarchien
der Lieferanten im KEIS abzubilden.

7 Fazit
Der Aufbau eines Einkaufinformationssystems auf Basis eines
Data-Warehouses mit konzernweitem Fokus ist eine Aufgabe, die
viel Zeit in Anspruch genommen hat und ein hohes finanzielles
Engagement voraussetzt.
Wenn RWE zum jetzigen Zeitpunkt eine Zwischenbilanz ziehen
kann, so ist festzustellen, dass hier ein Instrument geschaffen
worden ist, mit dem effektiv konzernweite Einkaufsoptimierung
betrieben wird und Wirtschaftlichkeitsvorteile gegenuber dem
Wettbewerb erzielt werden kbnnen.

8 Literaturverzeichnis
CHAMONI P.; GWCHOWSKI P.: Analytische Informationssysteme, Ber-
lin - Heidelberg - New York, 1999
MAASSEN M.: SAP-BW Einsatz bei RWE, Pri;isentation SAP Utilitys
KongrejS, 24.11.1999, Dusseldorf
MAHR T.: Business Information Warehouse Implementation Con-
siderations, Saphire 2001, Philadelphia
KUHNT D.: Core Business Drives Growth. Analyst and Investor
Conference, 26.Mi;irz 2002, Essen
SAP AG: SAP Customer Success Story RWE, Walldorf, 2001

137
 Alexander Goerke

Automatisierte lernende Rechnungsverarbeitung in SAP

mit SERdistiller

Alexander Goerke

1 Aufgabe
Die Verwendung eines leistungsfahigen hoch entwickelten ERP
Systems fur die interne Organisation eines Unternehmens ist heu-
te ein Muss urn die zunehmend komplexer und schneller wer-
denden Prozesse im Bereich Einkauf und Warenwirtschaft bewal-
tigen zu kbnnen. Durch die EinfUhrung von SAP werden diese
Prozesse in hohem MaBe strukturiert und nachvollziehbar. Ein-
mal in elektronischer Form im SAP Datenbestand vorhanden, las-
sen sich fast beliebige Abfragen mit diesen Daten generieren. 1m
Rechnungswesen wird der Prozess durch die -meist elektronisch
angelegte- Bestellung ausgelbst und durch die eingehende ge-
buchte Rechnung terminiert.
Rechnungsprn- Traditionell wird der Prozess der Rechnungsprufung durch den
Jungsprozess Papierbeleg gesteuert; mit allen Nachteilen, die dieses Verfahren
mit sich bringt:
Kein gleichzeitiger Zugriff auf Daten, da immer nur ein
Mitarbeiter den Beleg haben kann,
Hohe Kosten fUr Transport und Lagerung,
Mangelnde Transparenz.
Einsatz Heute besteht die Mbglichkeit, diesen muhsamen und teuren
automatischer Prozess weitgehend zu automatisieren. Durch Einsatz eines mo-
Rechnungsleser derne Rechnungslesers kann die repetitive Arbeit der Erfassung
von Daten in Rechnungen ersetzt werden und die Qualitat der
Daten gesteigert werden. Es kbnnen auch zusatzliche Daten fUr
die Verbuchung gewonnen werden, die bisher aus Kostengrun-
den nicht erfasst und nicht kontrolliert wurden.
Die Methoden die dafUr zur VerfUgung stehen und Beispiele von
Anwendungen eines automatischen Rechnungslesers im SAP
Umfeld sind Gegenstand diese Kapitels.

139
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

2 Grundlegendes zum Prozess der elektronischen Dokumen-

tenverarbeitung

2.1 EinfOhrung
Papier als Informationstrager hat eine jahrhundertealte Historie
und eine nicht zu leugnende Erfolgsgeschichte hinter sich. Die
wesentlichen Vorteile des Papiers sind auch heute im Zeitalter
der elektronischen Medien nicht von der Hand zu weisen: Einfa-
che Informationsspeicherung Cschreiben und drucken), etablierte
Transportmechanismen (Post und Fax), garantierte Kompatibilitat
mit dem Lesemedium. Deshalb wird das Papier als Informations-
speicher zwar recht bald vollstandig durch elektronische Archive
und Knowledge-Managementsysteme abgelbst werden, jedoch
fUr den Transport von Informationen noch lange als einfachstes
und sicherstes Medium erhalten bleiben.
Elektronische Die Voraussetzung, dass auch der Dokumenteingang vollstandig
Dokumentenbea elektronisch verarbeitet werden kann ist jedoch die Umwandlung
rbeitung des Papierdokumentes und der Informationen, die dieses Doku-
ment enthalt in eine elektronisch verarbeitbare Form (Bytes).
Zunachst liegt ja die Information auf einem analogen Medium,
dem Papierdokument, vor. Hauptaufgabe eines jeglichen Sys-
tems, das die RechnungsprUfung automatisieren soli ist die Be-
reitstellung der notwendigen Information in digitaler Form.
Medienbruch Man spricht auch davon, dass der "Medienbruch zwischen Papier
zwischen Papier und Daten" uberbruckt werden solI. Dieser Prozess ist in mehre-
und Daten re Teilschritte unterteilt, wie in Abbildung 69 dargestellt.

140
 Alexander Goerke

Scanning Erkennung OCR , automatische

Klassifikation und
Extraktion der
Rechnungskopfdaten
und Einzelpositionen
aufgrund gelernter
Vorlagen und Ablaute

Extrahierte Dokumente
Daten
EICtJ"'-liomelgeb I
AecIn.r1gsr'UTllllej r 434041
Aecmung.dalum ., 07.01 2OCO
S....ellrurmer ., 0000015
Netto r 13.592.00
MWSt r 2174.72
Brutto r 15.766.72

DocumentS

Abbildung 69: Ablauf der Rechnungserkennung

Schwarze Punk- Es geht also durchaus nicht nur urn die Erstellung eines elektro-
te in Daten nischen Abbildes des Papierbelegs durch Scannen. Damit ist
umwandeln noch nicht viel gewonnen, da dieses Abbild immer noch nicht
mit den zugrunde liegenden Vereinbarungen, die zum Lesen ge-
troffen wurden, interpretiert ist. Es geht darum die "schwarzen
Punkte" in einen gultigen Code von Buchstaben und Linien zu
libersetzen, und diese dann zu sinnvollen Wbrtern zusammenzu-
fassen und in ihren jeweiligen Kontexten als Daten zu interpre-
tieren.

2.2 Scannen und Erkennen

Die Umwandlung der eingehenden Papierrechnungen in digitale
Bilder erfolgt durch moderner Hochleistungsscanner. Diese
Scanner unterscheiden sich von den bekannten Heimgeraten
sowohl durch den Durchsatz als auch die Qualitat der Scan-
Ergebnisse. Jegliche Information, die beim Scannen verloren
geht, wirkt sich dramatisch auf das Endergebnis aus. Rechnun-
gen sind in der Regel von minderer Qualitat was die Papierglite
und die Druckqualitat mit Matrixdruck und schwachen Kontras-
ten anbetrifft. Kommt dazu noch eine fantasievolle farbliche Ges-
taltung des Briefbogens, steigen die Anforderungen an die Bild-

141
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

vorverarbeitung stark an. Deshalb sollten fUr die Rechnungsver-

arbeitung auf jeden Fall Scanner mit hochwertiger Bildvorver-
arbeitung auf Graustufen- oder Farbbasis zum Einsatz kommen.
An dieser Stelle darf nicht gespart werden, denn damit erhohen
sich die Kosten im weiteren Prozess. DafUr stehen sowohl hoch-
volumige Scanner zur VerfUgung (Kodak) als auch Software-
losungen, die fUr kleinere Volumina die Bildvorverarbeitung in
den PC verlagern und handelsubliche kleiner Scanner unterstut-
zen (Kofax SVRS). Neben der Lesbarkeit der Zeichen fUr die OCR
ist auch die sp~itere Lesbarkeit im Archiv, die laut GOD (Grund-
satze der OrdnungsgemaBen Datenverarbeitung) absolut gewahr-
leistet sein muss, ein zwingendes Argument, auf diesen Punkt zu
achten.
OCR Den nachsten Schritt nach dem Scannen nennt man OCR (Opti-
cal Character Recognition) durch den eine Menge von Zeichen
auf dem Dokument erkannt werden. Erst der darauf folgende
macht das eigentliche intelligente System aus, das letztlich die In-
formation aus dem Papierdokument extrahiert. Die Information
wird in jedem dieser Schritte mehr und mehr verdichtet, kon-
zentriert oder destilliert, so dass von der unstrukturierten Bitin-
formation des gescannten Bildes genau die wesentliche interpre-
tierbare Nutzinformation der Daten ubrig bleibt.

2.3 Daten lesen und prufen

Aus den Zeichen werden Worter gebildet und diese in einen
sinnvollen Kontext gebracht. Je nach dem in welchem Kontext
eine Datum steht, hat es eine unterschiedliche Bedeutung, ist
entweder ein Erstellungsdatum, ein Lieferdatum oder ein Rech-
nungsdatum. Diesen Schritt, der die eigentlichen Daten gewinnt,
nennt man Extraktion.
Zum Beispiel steht ein Betrag immer in einem gewissen Kontext,
der aufgrund von impliziten Vereinbarungen beschreibt, was die-
se Zahl bedeutet. Diese Zuordnung ist nicht eindeutig und sehr
unterschiedlich. Es kann also nicht davon ausgegangen werden,
dass ein Betrag vor dem das Wort "Gesamtwert" steht immer den
Brutto- bzw. immer den Nettobetrag bedeutet. Erst der gesamte
Kontext der Felder gibt den Sinn, den sich ein menschlicher Le-
ser aus der Erfahrung erschlieBen kann.

142
 Alexander Goerke

Zwlschensumme : 145,60
Verpackung 0,00 Nettobetrag 145,60
Versand 0,00 16% Mwst. Betrag 23,30
Versicherung 0,00 Gesa m tbetrag 168, 90
unasbedinaunaen: Zahlbar sofort Netto ohne AbzUQ I

Gesamtll/ert DM108.00
Document
Mehrwcrtsteuer 16%DM 7,28
Knowledge
Rechnungsbetrag 125,28 Base

Abbildung 70: Daten lesen - Bearbeitungsbeispiel

Simulation des Deshalb mussen genau hier zwingend intelligente, lernende Ver-
Lesevermogens fahren eingesetzt werden, denn eigentlich wird hier das mensch-
liche Lesevermogen simuliert. So wie der Mensch irgendwann
gelernt hat, eine Rechnung zu interpretieren und die richtigen
Daten auf dem Dokument zu finden, muss auch die Software
lernen, wie die Extraktion durchzufUhren ist. Man konnte der
Ansicht sein, dass das uber ein Regelwerk abzubilden ist, aile in
es hat sich gezeigt, dass durch die Komplexitat und Verschie-
denheit der Rechnungsformate ein Regelwerk weder konvergiert
noch beherrschbar und wartbar ist. Dem lernenden Prozess der
Rechnungsverarbeitung und die zugrunde liegenden Prinzipien
ist ein eigener Abschnitt gewidmet.
Validierung Nachdem die Daten in extrahierter Form zur Verfugung stehen,
werden sie in verschiedenster Weise validiert um eine hohe Qua-
litiit zu erreichen:
Formatprufungen,
Bereichsprufungen,
Querprufungen zwischen verschiedenen Feldern, wie
zum Beispiel Summenbildungen,
Abgleich mit Stammdaten und Tabellen,
Abgleich mit Bewegungsdaten.
Die Datenabgleiche sollten zweckmiiBigerweise direkt mit den
Daten aus dem SAP System stattfinden, damit keine doppelte Da-
tenhaltung erforderlich wird. Es empfiehlt sich allerdings fur ho-

143
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

he Volumina von Dokumenten eine zweigleisige Strategie, urn

die Belastung des SAP Systems mbglichst gering zu halten. Durch
eine tagliche Bereitstellung der SAP Stammdaten in einer exter-
nen SQL-Datenbank kbnnen diese Daten schnell, effizient und
ohne Netzbelastung gepri.ift werden. Nur bei Rechnungen, die
durch diesen Bestand nicht validiert werden kbnnen, wird direkt
auf die SAP Schnittstelle zugegriffen, urn diese Rechnung verar-
beiten zu kbnnen. Mit einem sehr hohen Prozentsatz kann davon
ausgegangen werden, dass zwischen Bestellung und Rechnungs-
stellung mindesten ein Tag liegt, so dass ein tagliches -be-
ziehungsweise nachtliches - inkrementelles Update der externen
Datenbank die aktuellsten Daten zur Verfi.igung stellt.

Extrahierte Daten
ExiI aktionsergeb. I
Rechnun!;lsnummel -r 434041
Rechnun.IJSdatum r 07.01 .2000
Bestellnummer -r 0000015
Netto -r 13. 592,00 , C""

-r 2174}2
~,

MWSt
Brutto -r 15.766,72

SAP MM/FI

R/3 Verbuchung
Eingabe via
CaliTransaction

Verifier -Sachbearbeiterplatz
erhalt Datensatz mit Warnungen
und "R/3 Fehlern"

Abbildung 71: Direkte SAP Anbindung

2.4 Manuell nachbearbeiten und Tabellen verarbeiten

Verifier Die nicht automatisch validierbaren und damit buchbaren Rech-
nungen werden an Nachbearbeitungsstationen, so genannte Veri-
fier, weitergeleitet. Diese sind hoch spezialisierte, auf die Verar-

144
 Alexander Goerke

beitung von elektronischen Dokumenten optimierte Clients, die

eine effektive Bearbeitung ohne groBe Wartezeiten ermbglichen.
Der Benutzer wird direkt zum jeweiligen Fehler gefuhrt und mit
einer aussagekraftigen Fehlermeldung informiert. In der Regel
genugt schon eine kleine Korrektur eines Feldes urn das ganze
Dokument sofort gultig zu machen, der Buchung zuzuleiten und
sofort das nachste fehlerhafte Feld auf dem nachsten Dokument
anzuzeigen. Die Verifjer-Verarbeitung (vgl. Abbildung 72) kann
in folgenden Punkten individuell konfiguriert werden:
Beliebige Gestaltung der Anordnung der Felder,
HinzufUgen von Schaltflachen und Funktionstasten,
Datenbankanbindungen fUr das Anzeigen von Listen,
Steuerung des Ablaufes durch Aussteuerung von Doku-
menten und individuelle Festlegung des Workflows,
Programmierung von individuellen Prufungen und Ab-
gleichen durch eine integrierte VBA Schnittstelle. Genau-
so wie bei der VBA Programmierung in Microsoft Pro-
dukten kann das Verhalten individuell angepasst wer-
den, ohne das Produkt zu verandern .
Fur die Tabellenbearbeitung enthalt die Bearbeitungsoberflache
ein hochoptimiertes Tabellenfeld, das jegliche Unterstutzung fUr
die rasche Erfassung und Prufung der Einzeipositionen bietet.
Ein GroBteil der Dokumente wird direkt automatisch richtig gele-
sen und die Daten bereitgestellt. Jedoch gerade der kleine Rest,
der trotzdem noch Erkennungsfehler enthalt bereitet noch Auf-
wand, der mbglichst minimiert werden sollte. Bei den Einzelfel-
dern ist es bereits mbglich durch Markieren der entsprechenden
Region im angezeigten Image die Erfassung zu beschleunigen.
Zudem kann diese Information fur das selbstandige Lemen
durch das System verwendet werden wie weiter unten ausge-
fUhrt wird. Fur die rasche Korrektur von Tabellenerkennungsfeh-
lern werden folgende fortgeschrittene Funktionen angeboten:
Validierung der Tabelle in sich (Zeilensummen, Spalten-
summen, Stammdatenabgleiche etc.) urn ein mbglichst
gutes und sicheres Ergebnis zu erhaiten,
Tausch von Spalten per Kontextmenu bei Fehlzuord-
nungen, wenn zum Beispiel die Positionsspalte und die
Mengenspaite vertausch wurden,
Einfugen und Lbschen von Zeilen,

145
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

Zusammenfassen und Aufspalten von Zeilen und Spalten

per Kontextmenii,
Auswahl von Alternativvorschlagen, die das System fUr
die Tabellensegmentierung anbietet,
Markierung eines Spalte im angezeigten Beleg und au-
tomatische Erkennung und Dbertragung dieser Spalte in
den angezeigten Datensatz.

~====~----~~

.-.--
--
: 7 2819
IS . 01. ]COO
f""",==",...---
""1'''';;;''''';;;;--- l1J.
_
. .. I _ .... ,

.- -
0000030 ""1ifiOOO=";;;----
......
1.100 . 1

16L. 12 II<...
. . U 1"6.1 11

,... ta
IlOjD moo

1 'tI .""' ~ uk1rtt~ZU)'~

"
"
, I 1I1"I<III .. lt... I'1 J".n.lstlfI rlllt D(CT.11C 4ofi"'co '....)00
us Rdgtl'5~ ..,. .... \134. lSEOltll1il 1Ql00 reoo

.., . . .. 1\
.1 .. ' .... .

- ...... _-._ .. -._----_._--------------._------------

c

Ie Artl.ke l -BclC' ... chnulI!] f.-I

Vd,..t~ ~kku 1.... , H';.III:ty 2230 T 4SIJ

H..tyen1.iK E'uro-Phone XL" ISot' r.H t OECT' -
TK-Anlage~ os:a

__
S-R:>bot ... cs Mcdom Cour le :- "'34-,
)6.6CC b,~I"
-.. ---.-- _. . . ..- - .
.--.--.-..--
Pottion'n BIIII1411I.11''''.I'I''I""r CICIOOo]l) nI(:ht In OM~'b.n'k gl1uncIan!BIlU411 kMMloIhrtn'
1i....,.~,....,.'lOmlI"~)I .... ",-,,_11 ,..."

Abbildung 72 : Nachbearbeitungsoberflache mit Feldern und Ta-

bellen

Mit diesen Funktionen ist es mbglich, die Einzelpositionen auch

dann schnell und effizient zu erfassen, wenn die automatische
Erkennung der Tabelle nicht funktioniert.

2.5 Klassifizieren und Lieferanten erkennen

Zuordnung von Ein wesentlicher Punkt in der Automatisierung der Rechungser-
Rechnungsemp- fassung ist die Zuordnung zu einem Rechnungsempfanger und
jangern und - zu einem Rechnungsersteller. Wahrend die Rechnungsempfanger
erstellern in der Regel nicht sehr zahlreich sind und einfach iiber Adresse

146
 Alexander Goerke

und andere Kennzeichen erkannt werden konnen, handelt es

sich bei den Erstellern meistens um eine Zahl von 2.000 bis
20.000 Lieferanten, die identifiziert werden sollen. Ober die in
den Stammdaten gespeicherten Informationen des Lieferanten,
wie Name, Adressen, Bankverbindung, HRB Nummer und Ge-
schaftsftihrer lasst sich ein Lieferant mit 980/0-iger Sicherheit iden-
tifizieren wenn er bekannt ist. Das Erfassungssystem sollte auch
in der Lage sein, unbekannte Lieferanten zu identifizieren und
die Daten fUr das Update in SAP zur VerfUgung zu stellen und
Abweichungen der Daten wie der gespeicherten HRB zu melden.

~ SERLIi .. tdler [lfl'YoI'leDerno_Verlf.",,)..Jp]

~ .:3~~Iilt!l .[> 1J;

I~ ~ f"5 ~ ~I -' -' -' ~ .J 0 0 ~
""K1"",,,_on;--F..,.oklot.....,,I_--:-:-""':l k""".............. 1311311llUJ
[3 Invoic@O@mo_V@fi
G Rfl.!l::hnuntJp.n
AII,nue,
Be.h
Compul", 200 I
._"_
r.~. 'wJ
j......... _ .,_
.. ....
COnlac
Drv
......... ..... . . .
,
Rob ~. 4' '.. .
Rubon
Schull

- ....
c UJl'O ......

Xodax .....
t ..t ..- .. _ "''''II

,.. ... ...,,-.."".....,,.,

It ill t." ~" r!

..

Abbildung 73: Lieferantenerkennung in Kopf- und FulSzeile.

147
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

Eine weitere Methode besteht darin, die Rechnung mit der re-
dundanten Information in Kopf- und FuBzeilen als so genanntes
Template (Vorlage) zu lernen und zu klassifizieren. Das hat den
Vorteil, dass auch die Extraktionsmuster viel praziser gelernt und
die gewunschten Daten mit 100% gelesen werden kbnnen. Es
besteht kein Problem darin, mehrere 1000 Lieferanten wahrend
der Bearbeitung automatisch zu trainieren und fUr die weitere
Verarbeitung zu verwenden. Stellt der Lieferant sein Layout um,
wird dieses einfach als weitere Variation dieses Lieferanten ge-
lernt. Mit dieser Methode erreicht man in der Praxis eine 95%-ige
Klassifikationsrate.
In der Regel wird man die 2000 haufigsten Lieferanten als
Template vorab lernen und damit schon etwa 90% der Rech-
nungseingange abbilden. Diese werden hervorragend erkannt,
wenn die Dokumentenqualitat in Ordnung ist.

2.6 Buchen und archivieren

Nach den vorangegangenen Schritten stehen die Daten letztend-
lich im elektronischen Format, vollstandig validiert und korrigiert
zur VerfUgung. Diese Daten sind zum einen an das Buchungssys-
tem SAP weiterzugeben und zum anderen elektronisch zu archi-
vieren. Innerhalb des SAP Systems wird eine Verknupfung uber
die Archivelink-Schnittstelle zwischen Buchungssatz und archi-
viertem Beleg hergestellt, so dass jederzeit auf das Originalfaksi-
mile zugegriffen werden kann. Als Archiv stehen eine ganze Rei-
he von DMS-Systemen zur Verfugung, die diese Schnittstelle be-
dienen und Faksimile und Daten revisionssicher und jederzeit
reproduzierbar speichern .
Fur die Obergabe an SAP gibt es zwei Mbglichkeiten:
Obergabe offline nach der Erfassung im Batch-Modus,
Obergabe und Buchung online direkt wahrend der Er-
fassung.
1m Offline-Modus werden die gesamten Daten erfasst, validiert
und in den SAP Workflow eingestellt. Die eigentliche Buchung
und die Abklarung offener Fragen wird direkt uber die SAP-Gui
durch die entsprechenden Sachbearbeiter ausgefUhrt. Die Sach-
bearbeiter kbnnen sich die Originalbelege jederzeit uber das Ar-
chiv anzeigen lassen.

148
 Alexander Goerke

1m Online Modus wird wahrend der Nachbearbeitung eine direk-

te Verbindung zu SAP aufgebaut. Dieses Verfahren soli im nachs-
ten Kapitel beschrieben werden.

3 Integration in SAP
Die Integration in SAP dient verschiedenen Zwecken. Zunachst
natOrlich zur letztendlichen Dbergabe des Buchungssatzes an
SAP . In der anderen Richtung zum Abgleich und Validierung der
eingehenden Rechnungsbelege mit den SAP Stammdaten und -
soweit die Bestellung aus SAP ausgefUhrt wurde - mit den Be-
wegungsdaten.
Call Als Schnittstelle zu SAP wird dabei entweder die Batch-Input
Transaction Schnittstelle tiber Call Transaction verwendet, die hauptsachlich
bei alteren Systemen zum Einsatz kommt 4.60) oder die BAPI
Schnittstelle, die nun verfugbar ist.
Zugrif[ aUf SAP Der Zugriff auf SAP erfolgt sowohl bei der Batchverarbeitung der
Belege im Hintergrund als auch bei der Nachbearbeitung. Hier
kbnnen ja Daten verandert werden und mussen wieder geprUft
werden. Oft genugt die Korrektur eines einzigen Feldes, wie ei-
ner fehlerhaften Steuer, um den gesamten Beleg buchen zu kbn-
nen.
Vorteile der di- Die Vorteile der direkten SAP Integration und der Verwendung
rekten SAP In- des Verifiers gegenuber einer losgelbsten Validierung der Daten
tegration sind:
Extrahierte Daten werden mit Original-SAP-Daten ge-
prUft und erganzt,
SAP Daten kommen aus Direktzugriff auf SAP Tabellen,
Aus Performance Grunden werden die Daten in einer
Datenkopie auf einer SQL Datenbank gehalten,
Alle bestehenden SAP Validierungen werden verwendet,
Erkennungsfehler (z.B. Abweiehung von Stammdaten
werden sofort erkannt),
Eventuelle Sperrungen und Sondereintrage werden be-
rucksiehtigt,
Fehler des Lieferanten werden sofort erkannt und kbn-
nen effizient korrigiert werden,
Nur aus SAP-Sieht korrekte Rechnungen werden ver-
bucht,

149
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

Effiziente NacherfassungsarbeitspHitze erhohen Durch-

satz und Qualitat zusatzlich,
Nicht sofort klarbare Rechnungen werden auf Sonderar-
beitsplatze ausgesteuert,
Fur schwierige Faile kann direkt die SAP G UI mit dem
entsprechenden Buchungssatz geoffnet werden ohne
dass dieser gesucht werden muss.
Mit dieser Methodik werden die Vorteile der schnellen effizien-
ten, image-basierenden Bearbeitung der Dokumente im Verifier
verknupft mit der Konsistenz des Regelwerks in SAP und der nur
einmaligen Datenhaltung.
Insbesondere durch den letzten Punkt der Liste kann der gesam-
te Leistungsumfang von SAP fur Sonderfalle integriert und ein-
fach genutzt werden, ohne dass einen Belastung durch automa-
tisch durchgebuchten Routinefalle entsteht. Der Sachbearbeiter
ist entlastet und kann sich seinen eigentlichen Aufgaben wid-
men. Kann der Beleg nicht im Verifier endgultig bearbeitet wer-
de , offnet sich auf Knopfdruck die SAP GUI mit der richtigen
Transaktion und voreingestellten Daten. Die weitere Bearbeitung
erfolgt dann wie gewohnt ins direkt oder durch Anlegen eines
Workitems fUr die weitere Bearbeitung und Prufung in SAP ..
Sach bearbeiter
Verifier Arbeitsplatz

Eingabe via R/3

81 oder SAPI

SAPRl3
Archive
Link
I==
Archivierung mit
Anzeigen des SAP GUls zur
Sachbearbeitung oder Bestatigung
vor der Buchung ist aus Verifier
heraus moglich

Abbildung 74: Integration von SAP GUI und Verifier

150
 Alexander Goerke

Durch den Zugriff auf die Bestelldaten in MM wird die fehlerfreie

Erfassung von Positionsdaten erst mbglich. Hier erfolgt ein mehr-
stufiger Abgleich mit einer automatischen Suche nach den Be-
ste11positionen auf verschiedenen Bestellungen, Priifung von
Doppelberechnung und Vergleich mit den Bestellkonditionen.
Selbst fehlerhaft gelesene oder ausgeste11te Rechnungen kbnnen
durch einen fehlertoleranten , Mehrstufigen Abgleich einer Bestel-
lung zugeordnet werden, ohne dass eine manue11e Suche not-
wendig wird.
Als Beispiel fUr eine der vielen Prufungen sol1 die Validierung
und Suche nach der Beste11nummer angefUhrt sei. Erst im aller-
letzten Schritt, der nahezu niemals eintritt, muss die Beste11ung
manu ell gesucht werden:

151
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

Bestellnummer
Validierung

no

I
yes
Bestellnummer
ungOltig no

yes

Aile ollenen
Beslellungen des
Lieferanten der letzlen
n Wochen laden

>1

Suche aile
Bestellnummern der Liste
auf dem Dokument

yes

Uste der
Bestellnummem nach
Lieferadresse fillem

Bestellnummem nach
Nettobetrag fillem

manuelle Korreklur

Abbildung 75: Beispiel fUr einen Teilbaum in der Validierung

152
 Alexander Goerke

4 Lernendes System
Neuronale Das Auslesen von Rechnungen stellt einen repetitiven kognitiven
Netzwerke Prozess dar. Damit wird ausgedruckt, dass sich im Gehirn des
Menschen immer wieder ahnliche Erkennungsvorgange abspie-
len. Da Rechnungen so gestaltet wurden, dass Menschen diese
gut lesen kbnnen , ist es mbglich, diesen Prozess durch eine ler-
nende Software abzubilden. Dazu wird die Technologie der neu-
ronalen Netzwerke verwendet. Neuronale Netzwerke sind eine
Nachbildung des menschlichen Gehirns, allerdings in wesentlich
geringerer Komplexitat. Es ist uns gelungen die bekannten Prob-
Ierne der neuronalen Netzwerke, die hauptsachlich in der Ge-
schwindigkeit und der Konvergenz lagen durch die Software
SERbrainware zu Ibsen. Diese ist die Grundlage des lernenden,
mittlerweile patentierten Verfahrens in SERdistiller.
Grundprinzip Das Prinzip ist ganz einfach: Angenommen ein System ist noch
nicht trainiert. Eine Rechnung wird gescannt und naturlich nicht
erkannt. Am Nachbearbeitungsplatz werden die Felder, zum Bei-
spiel Betrag, manuell erfasst. Dazu kann unter Umstanden auch
der entsprechende Bereich im Beleg am Bildschirm markiert
werden. Das System speichert jetzt nicht nur den Wert dieses Be-
trages sondern auch den Kontext. Das ist die Umgebung in der
dieser Wert steht. Neben Wortern, die in der Nahe stehen sind
das auch Abstande zu diesen Wbrtern, relative Positionen von
anderen Zahlen, Linien und ahnliches. Im Prinzip in gleicher
Weise wie der Mensch die Bedeutung einer Zahl auf einer Rech-
nung erkennt. Dieser Kontext wird nun sofort gelernt. Mit dem
nachsten Beleg, der aufgerufen wird, kann der Kontext ange-
wandt werden. Ist dies zufallig ein ahnlicher Beleg yom selben
Lieferanten, kann der Kontext im Umkehrschluss sofort reprodu-
ziert werden und der Wert automatisch gelesen werden. Die er-
arbeiteten Lernmengen werden der zentralen Batchverarbeitung
zugefuhrt, so dass beim nachste Batch aile Dokumente mit den
neuen gelernten Erfahrungen erkannt werden. Hier besteht noch
die Moglichkeit des Eingriffs durch einen Supervisor (=Lehrer),
der die neuen Beispiele freigeben kann. Durch ausgefeilte AIgo-
rithmen wird verhindert, dass falsche Beispiele in die Lernmenge
gelangen.

153
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

Lernen
Document
Knowledge
Base

-
Extraction
Server

Analyse ..
z.B. < 20 %

..
- Klassifikation
- Extraktion
Korrigieren und
- Validierung
Lernen
z.B. > 80 % extrahierte
Daten

. se<:,' , .
Abbildung 76: Lernprozess

Die gel ern ten Beispiele werden sowohl fUr den individuellen Be-
legtyp als aueh allgemein fUr Reehnungen gespeiehert. Andert
sieh das Layout eines Lieferanten, wird dieses einfaeh dazuge-
lernt. Wenn ein Layout aus der Lernmenge uber hlngere Zeit
nieht verwendet wird, kann es aueh "vergessen" werden um die
Lernmenge nieht unnbtig zu belasten.
Selbstandiger Mit dieser Methode baut sieh das System in der Anfangsphase
Aufbau selbst auf und halt sieh dann kontinuierlieh aktuell. Theoretiseh
kbnnte somit eine 100%-ige Erkennungsrate erreieht werden,
dureh Versehmutzungen, OCR-Probleme und ahnliehes werden
momentan allerdings in der Praxis zwischen 80% und 95% Fel-
derkennungsrate erreieht.
Interessanterweise mussen nieht unbedingt die Layouts pro Liefe-
rant gelernt werden. Aueh beim Lernen von Kontexten fUr all-
gemeine Reehnungen konvergiert das System. Das kommt daher
dass die Syntax des Reehnungsaufbaus mit einer genugenden
Anzahl von Beispielen fast vollstandig vorliegt. Mit 2000 gelern-
ten untersehiedliehen Reehnungsvorlagen erzielt das System auf
unbekannten Reehnungen eine Erkennungsrate von deutlieh u-
ber 50%. Es ist also aueh mbglieh, dureh Bereitstellung dieser
Lernmenge, mit einem bereits trainierten System zu beginnen.

154
 Alexander Goerke

Tabellen werden in ahnlicher Weise gelernt wie Felder. Zunachst

wird eine automatischer Tabellenalgorithmus basierend auf Kan-
ten, Dberschriften und hinterlegten Eigenschaften von Tabellen
verwendet. 1m allgemeinen gelingt damit das Lesen der Tabellen
schon recht gut. Insbesondere bei einzeiligen Tabellen kann es
nbtig sein diese zu lernen . Durch Markieren der Zeile lernt das
System die Charakteristika der Tabelle dieses Lieferanten und
kann sie beim nachsten Auftreten zuverlassig reproduzieren.

5 Anwendungsbeispiele
In den vorigen Abschnitten wurden die theoretischen Konzepte
des Rechnungslesers beschrieben. Tatsachlich befindet sich diese
Anwendung schon vielfach im Praxiseinsatz. 1m folgenden wer-
den einige typische existierende Anwendungsbeispiele beschrie-
ben.

5.1 Automatische Rechnungserfassung bei Zentralregulierer

mit hohem Volumen
Ein sehr schbnes Beispiel fur die schnelle und gewinnbringende
Anwendung der automatischen Rechnungserfassung ist ein vor
zwei Jahren realisiertes Projekt bei eine Zentralregulierer, der
den Einkauf und die Regulierung von Rechnungen fUr eine gro-
Be Anzahl von angeschlossenen Gesellschaften ubernimmt. Da-
bei ist es zunachst unerheblich , ob diese Gesellschaften unab-
hangig sind und die Leistung des Zentralregulierers als Dienst-
leistung beziehen, oder ob es sich urn eine zentralisierte Leistung
in einem Unternehmensverbund handelt. In diesem Fall war die
Aufgabe, fUr einen Einzelhandler mit mehreren 100 Filialen den
zentralen Rechnungseingang abzubilden.
Die zentrale Rechnungsstelle erhalt taglich 4500-8000 Rechnun-
gen von mehr als 2000 Lieferanten, die das Sortiment der Filialen
beliefern. Fur jede Rechnung besteht ein Bestellbezug, da aile
Bestellungen uber das SAP System abgewickelt werden. 1m Ein-
satz befindet sich SAP R/3 4.5B mit den Modulen FI/CO auf einer
AIX IBM RS/ 6000 Plattform. Die Rechnungen mussen auf jeden
Fall taggleich, das heiBt bis spatestens 16:00 erfasst sein urn jegli-
chen Skontovorteil ausnutzen zu kbnnen.
Vor der EinfUhrung des automatischen Rechnungslesers wurden
die Rechnungen manuell sortiert, die relevanten Felder in der
Vorbereitung markiert und manuell erfasst. Besondere Heraus-
forderungen entstehen dabei durch abweichende Mehrwertsteu-

155
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

ersatze, Rechnungen von Auslandslieferanten und Gutschriften.

Die Verarbeitung von einseitigen und mehrseitigen Rechnungen
wurde dadurch optimiert, dass manu ell die letzte Seite der Rech-
nung, die den Endbetrag enthalt, an die erste Position sortiert
wurde. 1m Anschluss an die manuelle Erfassung der 4 Kopffel-
dern Bestellnummer, Rechnungsnummer, Rechnungsdatum und
Betrag erfolgte die Verfilmung der Belege fur die Langzeitarchi-
vierung und die anschlieBende Vernichtung. Aus Kostengrunden
wurden keinen weiteren Betrage wie Fracht und Verpackung
nicht erfasst, sondern nur der Endbetrag; man verlieB sich auf
die richtige Berechnung durch den Kunden .
Mit der Einfilhrung des automatischen Rechnungslesers SERdistil-
ler wurde dieser Prozess deutlich optimiert:
Zunachst werden die Belege gescannt und mit einer eindeutigen
Nummer versehen. Danach wird im Prinzip das Papier nicht
mehr gebraucht und kann bis zur endgultigen Entsorgung zwi-
schengelagert werden. Durch Einsatz eines Hochleistungsscan-
ners KODAK 7500 kbnnen die Rechnungen mit einer Geschwin-
digkeit von netto ca. 100 Seiten pro Minute eingescannt werden.
Bei einem maximalen Volumen von 8.000 Rechnungen mit im
Schnitt zwei Seiten ist die Umwandlung des Papiers in elektro-
nisch handhabbare Daten in weniger als 3 Stunden abgeschlos-
sen. Parallel dazu beginnt schon die automatische Verarbeitung
def gescannten Belege in insgesamt 4 Prozessen, die auf einem
Server im Rechenzentrum ablaufen.
Wie in den vOfigen Kapiteln beschrieben werden dabei aufgrund
der gelernten Muster die Daten aus den Rechnungen extrahiert
und in einer Datenbank zur Verfilgung gestellt. Nicht korrekt er-
kannte Rechnungen werden uber das Netzwerk elektronisch den
jetzt auf die Anzahl 2 reduzierten Korrekturstationen zur Dber-
prufung und Validierung ubergeben. Urn mbglichst nahe an die
bisherige optimierte Verarbeitung zu kommen wurde zuvor e-
lektronisch die letzte Seite der Rechnung an die erste Position
kopiert. Bei der anschlielSenden Archivierung wird das Doku-
ment dann wieder original hergestellt. Die Korrekturstationen
(Verifier) sind optimiert auf die schnelle, ergonomische und si-
chere Bearbeitung von Dokumenten mit reiner Tastatursteue-
rung. Die Abbildung 77 zeigt den prinzipiellen Aufbau einer ein-
fachen Korrekturmaske:

156
 Alexander Goerke

AnKtt OH _ , ...

Cat" ~

.:3 . ~ 4f
UNG
I~ ~ m 1

...... ...,.,....."'"
434041 ~ In...RdJ'Jtu 8~ 192lOl4 2O'MO ~.II.'! I
R_" 0Dnd: .u1~ pcdmoo
I l(rC::f~-dIll~ nb "'a ~ HlII1IbUl':; ik!q''''' 4J40011
27.01.2000 ~1012000
7.,3hll.lft inC): 30 T ..~ ~:n O",IUI'U U7 ltl20QU
eHl ~

0000086 ~OOOO8O
Ko.'\l'"
Sxhb~.1I"_:
1146?1
Lonl
Ue:ICI tr. PletnrI9t Td ().~l J 411...

640,00 ~ Ihrc8eArll\i1'l\:~ OOOOOIS

t.Cw"Sl(nPlen'W'IJ:I:
roo ARTIKl;:l,.J'\"R

102,40 \lr
~ TlILEllELE IOINU!'IO M
I~~ "(II! "'~hlb<:~r

~"""IinI'l""'...,1 l.U "IllmO II 1<(,/',1 II"'!. SILld. .I.3%'1))

15.7(.6,72 i,mm 2.0 mmLpJ 19'" 121)11 ,\ ltlF 'luck l:ilr~.t)J

\ twSr f\cIRIl:
---------------------
~bt:tr3~-

lli4.n B.766.n

l);\.,\ U .7tJ6.7l

- WII(U Ltc"t".,ctI"" u.~ UoIP'CIri ff(QIi,fa In f::j dWu~OIII;or:h.,.L I\D ;,It.n~nu I I CUVII ~ ~ tf
I'flft.mlllfldrr ronnlfillfl ot'lrtlL n .. ~ \n , I lnC04h .1II11l1 I'ljll"",,", ~,,. r'~ '" CGfIUC ~ c;r.,*t d.d Mtillmrnl 0
.... :cl't.rau. It1IIIfld.c:bi~~LII~cr~l Go ......mtbeCl 1lC'f

~~ j ~t., !.e:(IM~1 ... ~,...

M~~ .....*"Chon ~ca..: P'i,t.:w ..........
........ ~~A!IsIxt: tWN':!tIIO'lHI~ l). ')' ''~., ~m'O'II . 1I1dIt1,

15.766,72
11576672
Brutto Berechnete Brutto.umme von 74240 nicht korrekt ! Rechnungen

Abbildung 77 : Beispiel fUr eine einfache Nachbearbeitungsober-

fhche

Nach der Erfassung erfolgt die direkte Ubergabe an SAP zur

Rechnungsfreigabe und die elektronische Archivierung.
Das System wurde nach der initialen Einrichtung der PrUfungen
und Schnittstellen vom Anwender selbst trainiert. Durch standi-
ges Feedback der erfassten Daten in die Menge der Lernbeispiele
CAutoinvoice-Verfahren) bleibt das System standig aktuell und
optimiert sich immer weiter. Etwa 1000 Lieferanten werden in
spezialisierten Unterkategorien eingeordnet, gelernt und verar-
beitet, womit ein GroBte il des Volumens des Rechnungseingangs
abgedeckt wird; der Rest wird in einer allgemeinen Rechnungs-
klasse gelesen. Durch die standige Optimierung konnte bis heute
eine Automatisierungsgrad von 80-85 % auf Feldebene erreicht

157
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

werden. Das heiBt konkret, dass nur noch ca. 15% der Felder
noch einmal angezeigt und kontrolliert werden mussen.
Der groBe Vorteil des Systems besteht aber daruber hinaus, dass
weitere Felder wie Verpackungskosten, Versand, Skonti, Valuta
und verschiedene Mehrwertsteuersatze einfach und automatisch
mitgelesen werden. Damit kann eine viel prazisere Kontrolle der
Lieferbedingungen pro Lieferant erfolgen und gegebenenfalls die
zuviel berechneten Kosten subtrahiert werden . Alleine daraus er-
gibt sich schon ein betrachtliches Einsparvolumen, das das Sys-
tem heute schon amortisiert hat.

5.2 Rechnungserfassung mit Positionsdaten

Die Positionsdaten auf def Rechnung werden dann gebraucht
wenn organisatorisch auch die Warenwirtschaft uber das Be-
stellwesen und den Rechnungseingang gesteuert wird. Ein An-
bindung an SAP MM erfordert die Obergabe der gesamten Tabel-
Ie der Einzeldaten auf dem Dokument.
Bei einem groBen Hersteller im Anlagenbaubereich gehen taglich
etwa 500 Rechnungen von Lieferanten ein, die Komponenten fUr
die Produktion liefem. Diese Rechnungen wurden bisher mit
groBem Aufwand manuell geprUft. Die Einzelpositionen wurden
direkt in SAP aufgrund der Bestelldaten abgehakt. Da eine Rech-
nungen Bestellpositionen von mehreren Bestellungen enthalten
konnte, die zunachst gesucht werden mussten, war der Aufwand
entsprechend hoch mit einer Bearbeitungszeit von etwa 15 Minu-
ten pro Rechnung. Erschwerend kam dazu, dass auch DIN und
andere Normnummem aus den Bestelltexten erfasst und mit den
berechneten Waren verglichen werden mussten. Urn Valuta und
Skonti zu wahren war eine taggleiche Bearbeitung erwunscht.
Durch die EinfUhrung des automatischen Rechnungslesers konn-
te die Situation wesentlich entspannt werden. Durch den festen
Lieferantenstamm konnte die Definition der entsprechenden
Klassen sehr schnell abgeschlossen werden. Nach einer Grunder-
stellung des Projektes durch den Hersteller wurden die weiteren
Lieferanten durch Mitarbeiter des Kunden selbst trainiert. Nach 3
Monaten konnte das System in Produktion gehen.
Die Aufgabe des Auslesens von DIN-Nummem aus den Betreff-
zeilen war nicht im Standardprodukt enthalten. Durch entspre-
chende VBA Skriptcodes, die auch vom Kunden selbst weiterge-
pflegt werden kbnnen, gelang es auch diese Problematik zufrie-
denstellend zu Ibsen. Somit ist eine standige Oberprufung der

158
 Alexander Goerke

QualWit der gelieferten Ware und der Einhaitung von Normen

moglich.
Heute arbeiten in der eigentlichen Rechnungserfassung und -
priifung noch 5 Mitarbeiter.

5.3 Dezentrale Rechnungsprufung bei Pharmaunternehmen

Ein international tatiges Pharmaunternehmen hat ein "Shared
Service Centre" fiir die Rechnungsverarbeitung aufgebaut um
Kosten zu sparen. Das Zentrum befindet sich in einer Region Eu-
ropas mit niedrigen LOhnen. Die Belege fallen jedoch dezentral
and und auch die Sachbearbeiter fUr die Rechnungsfreizeichnung
sind in den Standorten verteilt. Hier wurde eine Losung zur
Rechnungsfreizeichnung in Lotus Notes realisiert.
Eingehende Rechnungen werden durch kleine dezentrale Scan-
ner zum Beispiel in Norwegen gescannt und per Datenleitung an
das zentrale Rechenzentrum in Madrid iibertragen. Dort erfolgt
die Erkennung mit dem Rechnungsleser SERdistiller und die Va-
lidierung der Daten. Zu korrigierende Belege werden ausgesteu-
ert und in einem dezentralen Zentrum nachbearbeitet. Der
Zugriff erfolgt dabei iiber Windows Terminal Server, so dass das
Programm weiterhin auf einem Rechner im Rechenzentrum lauft
und die Bearbeiter vollen Zugriff auf die SAP Validierung haben.
Nach Abschluss der Erfassung werden die Dokumente iiber Lo-
tus Notes an die entsprechende Rechnungspriifungsstelle geleitet.
Dabei folgt das System Regeln fUr die Rechnungspriifung, die in
Lotus Notes festgelegt sind. Der Workflow dazu wurde yom
Kunden beigestellt. Nach erfolgter Rechnungsfreizeichnung wird
der Datensatz direkt gebucht und freigegeben
Damit spart sich das Unternehmen den aufwendigen Versand der
Papierrechnungen an die Zentrale und den papiergebundenen
Ablauf der Freizeichnung. Fristen konnen besser eingehaiten und
kontrolliert werden. Ein Eskalationsmechanismus stellt sicher,
dass jede Rechnung rechtzeitig abgezeichnet wird. Durch die au-
tomatisierte Erfassung werden die Daten schnell und in hoher
Qualitat zur VerfUgung gestellt.

6 Fazit
Die beschriebenen Technologien sind seit etwa zwei Jahren so-
weit, dass sie gewinnbringend in der Praxis eingesetzt werden
konnen. Seitdem wurden zum Beispiel von dem Rechnungsleser
SERdistiller schon iiber 60 Installationen in Europa und USA

159
Automatisierte lernende Rechnungsverarbeitung in SAP mit SERdistiller

durchgefUhrt. Da sich die Technologie standig verbessert, ist da-

mit zu rechnen, dass diese Art von Software tiber kurz oder lang
zu einem festen Bestandteil jeder Rechnungsstelle wird. Je we iter
die Normierung der elektronischen Austauschmedien voran-
schreitet, desto unwichtiger wird zwar diese Technik. Jedoch
zeigt sich heute, dass der ROI derart kurz ist, teilweise unter ei-
nem Jahr, dass sich selbst eine Investition im Hinblick auf eine in
wenigen Jahren eventuell realisierte Teilelektronifizierung des
Rechnungsaustauschs lohnt.
Die Hersteller arbeiten intensiv an einer weiteren Steigerung der
Qualitat und einem mehr und mehr automatischen Lernverfah-
ren, dass das Know-How der Sachbearbeiter einfach reproduzie-
ren kann. Damit sinkt der Aufwand zur Implementierung und
das System wird auch bei kleinen Rechnungseingangsmengen
und Restmengen, die nicht elektronisch verarbeitet werden, inte-
ressant. Zum Schluss sollte der Medienbruch zwischen Papier
und elektronischen Daten vollstandig geschlossen sein, so dass
Daten auf Papier genauso einfach gehandhabt werden kbnnen,
wie Daten auf elektronischen Datentragern.

160
 RalfThomas

EinfOhrung des APO zur UnterstOtzung des SCM

Ralf Thomas

1 Einleitung
In vielen Unternehmen nimmt die Komplexitat durch die Globa-
lisierung zu, wenn die globalen Absatzmarkte durch einen regio-
nalen und dezentralen Vertrieb beliefert werden sollen und sich
die Produktion an zentralen Standorten befindet. Da die Opti-
mierung vieler, einzelner Prozesse innerhalb der Unternehmen
weitestgehend ausgereizt ist, wird nach Mbglichkeiten der Opti-
mierung der Schnittstellen zwischen den Prozessen sowie der
Optimierung der kompletten Lieferkette gesucht. Hierfiir bietet
das SCM (Supply Chain Management) neue organisatorische An-
satze, die aus informationstechnologischer Sicht mit SAP-APO
(Advanced Planner and Optimizer, einer Komponente der my
SAP SCM Lbsung) unterstiitzt und abgebildet werden kbnnen.
1m Rahmen einer "First-Customer-" APO-Einfiihrung in einem
chemischen Industriekonzerns wurde mit den APO-Modulen DP
(Demand Planning) und SNP (Supply Network Planning) die Ab-
satzplanung sowie die Nachschubsteuerung fUr einen weltweit
agierenden Unternehmensbereich erfolgreich abgebildet. Die
Planung des Absatzes und des Nachschubs wird somit zentral auf
einem System durchgefUhrt. Die erzeugten Auftrage werden nach
der Planung an die dezentralen, heterogenen ERP-Systeme (En-
terprise Resource Planning) verteilt und kbnnen in den einzelnen
Standorten bearbeitet werden.
Derzeit wird dieses Projekt auf andere Unternehmensbereiche
ausgeweitet, wobei zusatzliche Anforderung durch die Einbin-
dung von Kunden entstehen. Damit wird der Schritt vom inter-
nen SCM zum unternehmensiibergreifenden SCM vollzogen .

2 Ziele und Aufgaben

Das Hauptziel des Projekts war die Einfiihrung einer Software,
die das Marketing, den Vertrieb und die Produktion bei der Aus-

161
Einfiihrung des APO zur Unterstiitzung des SCM

sage uber zukunftige Absatze und Bedarfe an Verkaufsprodukten

unterstlitzt, um moglichst fruhzeitig auf Ober- und/ oder Unterde-
ckung reagieren zu konnen. Da der Vertrieb aus einem weltwei-
ten Netzwerk von Regionalen Verteilzentren (RVZ) zusammen-
setzt ist, die von unterschiedlichen Lieferwerken versorgt wer-
den, reicht eine einfache Softwarelosung nicht aus, um diese
Aufgaben zu bewaltigen. Die Auswahl fiel somit auf den APO,
einer Softwarelosung der SAP AG, auch aus dem Grund der In-
tegration mit SAP R/3, da in vielen Bereichen des Unternehmens
R/ 3 eingesetzt wird und auch zukunftig R/ 3 eigenentwickelte
Systeme ablosen soli.
Neben diesem Hauptziel galt es, vorhandene Altsysteme mit dem
APO abzulosen. Die Absatzplanung wurde mit einer Eigenent-
wicklung durchgefUhrt und sollte nun mit dem Modul APO-DP
(Demand Planning) abgelost werden. Fur die Netzwerkplanung
war eine Standardlosung der Firma Manugistics Inc. im Einsatz.
Diese Standardsoftware wurde durch das Modul APO-SNP (Sup-
ply Network Planning) ersetzt. Der grolSte Vorteil bestand auch
hier in der Integration, da sich die beiden Module DP und SNP
in ein und der selben Lbsung befinden und somit Schnittstellen
uberflussig machen und Planungen ubergreifend durchgefUhrt
werden konnen.
Konzernweite Auch galt die EinfUhrung des APO im gesamten Konzern als Pi-
APO- lot. Es war somit notwendig, Know How aufzubauen, und den
Einfiihrung Roll-Out in weitere Unternehmensbereiche zu berucksichtigen
und, soweit moglich, vorzubereiten. Hierbei war die Abstimmung
mit laufenden Projekten von grolSter Wichtigkeit, um neben dem
abgebildeten Modell auch zukunftige Prozesse mit moglichst ge-
ringem Aufwand in den APO integrieren zu konnen .
Eine der Hauptaufgaben bestand in der Integration des APO in
die vorhandene, heterogene Infrastruktur. Soweit nicht vorhan-
den mussten Schnittstellen zu externen Systemen entwickelt
werden, wobei naturlich auch fUr Standardschnittstellen die Si-
cherheit und die Konsistenzerhaltung der Daten im Vordergrund
stand .

3 ProzessOberblick
In dem Projekt wurden im wesentlichen zwei Prozesse im APO
abgebildet, zum einen die Absatzplanung, zum anderen die
Netzwerkplanung.

162
 RalfThomas

1m ersten Prozess werden zukilnftige Bedarfe an Fertigprodukten

Fertigprodukt-
erzeugt. Da der Verkauf zum groBen Teil ilber die Regionalen
bedarjserm itt-
Verteilzentren gesteuert wird, milssen auch hier die Bedarfe ab-
lung
gesetzt werden. ( Der Prozess der Direktbelieferung aus den Lie-
ferwerken wurde ebenfalls abgebildet, soli hier aber der Ein-
fachheit halber nicht weiter eriautert werden.)
Lokations- 1m zweiten Prozess werden diese Bedarfe sowie die Bedarfsde-
netzwerk cker (Nachschilbe) durch das Werksnetzwerk oder auch Lokati-
onsnetzwerk verteilt.
Abbildung 78 zeigt einen groben Dberblick der im APO abgebil-
deten Planungsprozesse.

APO-DP
Prognosen
Kundenauftriige
Regionale
Verteil-
zenlren
(RVZ)

APO-SNP

APO-PP/DS
(geplant)
Bedart

1- Nachschub J
Abbildung 78: Bedarfsfluss und Nachschub

1m Einzelnen handelt es sich urn folgende Prozess-Schritte:

Auf den regionalen Verteilzentren werden durch Kundenauftrage
und Prognosen Bedarfe erzeugt.Als Bedarfsdecker auf den RVZs
dienen Bestande und geplante Nachschilbe .
Bedarjsweiter- Die nicht gedeckten Bedarfe auf den RVZs werden an die Lie-
gabe ferwerke weitergegeben. Diese Bedarfsweitergabe wird durch
Erzeugung von nicht bestatigten Nachschubauftragen (sog. Um-
lagerungsbestellanforderungen) erreicht. Als Bedarfsdecker auf
den Lieferwerken dienen Bestande und geplante Produktionszu-
sagen.

163
Einfiihmng des APO zur Unterstiitzung des SCM

Nicht gedeckte Bedarfe auf den Lieferwerken k6nnen nun von

der Produktion zugesagt werden.
Riickvertei!ung AnschlieBend erfolgt eine Ruckverteilung der Produktionszusa-
gen von den Lieferwerken auf die RVZs, d.h. die nicht bestatig-
ten Nachschubauftrage werden bestatigt.
Diese bestatigten Nachschubauftrage werden dann an die Auf-
tragsverwaltungssysteme (z.B. R/ 3) ubermittelt und stoBen hier
physisch den Nachschub an.
Dieser grobe Prozessuberblick soli nun in den folgenden Ab-
schnitten weiter detailliert werden.

4 Prozess Demand Planning

Die Absatzplanung wird monatlich rollierend durchgefuhrt, d.h.
es wird jeden Monat geplant, wobei der Planungshorizont immer
einen Monat weiter geschoben wird und die Planzahlen der
schon geplanten Monate bei der neuen Planung angepasst wer-
den. Abbildung 79 zeigt den DP-Planungslauf.

Abbildung 79: Prozessuberblick: DP-Planungslauf

Das Business Warehouse (SAP-BW, eine weitere Komponente

der mySAP SCM L6sung) stellt taglich vortagsaktuelle 1st-Daten
bereit. Diese beinhalten Informationen uber offene und abge-
schlossene Kundenauftrage, die auf definierten Merkmalskombi-
nationen (Land, Region, Kunde, Artikel,,,.) aggregiert bzw. dis-
aggregiert werden k6nnen .

164
 RalfThomas

Auf Grund dieser Vergangenheitswerte errechnet das System mit

einer maschinellen Prognose Vorschlagswerte fUr die kommen-
den sechs Monate. Die so prognostizierten Planzahlen k6nnen
anschliefSend analysiert und manu ell geandert werden.
Die Planzahlen werden lokationsunabhangig erfasst, d.h. es ist
nur bekannt, welche Kunden bestimmte Produkte voraussichtlich
beziehen, nicht aber welche Lokationen diese Produkte liefern
werden. Die Information der liefernden Lokation ist aber fUr die
Netzwerkplanung absolute Voraussetzung. Es wird also nach der
Absatzplanung ein so genanntes "Lokationsmapping" durchge-
filhrt. Dabei wird anhand der Merkmalskombinationen (Land,
Region, Kunde, Artikel, .. .) die Lokation ermitteit, auf die der Be-
darf abgesetzt werden kann, bzw. die den Bedarf befriedigen
soli.
Nach der Lokationszuordnung wird die Planung an SNP ilberge-
ben. Die SNP-Prozesse werden im Absatz 5 Prozess Supply Net-
work Planning naher eriautert.
Nachdem die SNP-Planungsprozesse durchgefilhrt wurden, wer-
den die bestatigten Bedarfszahlen zurilck an das DP ilbergeben
und bilden den bestatigten Absatzplan.
Dieser bestatigte Absatzplan wird zur Bildung von Kontingenten
und somit fUr Lieferzusagen verwendet. Das globale ATP (global
Available to Promise / globale VerfUgbarkeitspri.ifung; der Einsatz
von ATP befand sich noch in der Projektphase und soli in Zu-
kunft eingesetzt werden) kann dann beim Anlegen von Kunden-
auftragen auf die gebildeten Kontingente zugreifen und dem
Vertriebsmitarbeiter direkt mitteilen, wann und in welcher Menge
das geforderte Produkt ausgeliefert werden kann.

5 Prozess Supply Network Planning

Ausgehend vom Absatzplan des Vertriebs ermittelt das Supply
Network Planning einen zulassigen Plan zur Deckung der ge-
schatzten Absatzmengen.
Die geplanten Absatzmengen fUr die nachsten 6 Monate dienen
somit als Basis fUr die Distributions- und Produktionsgrobpla-
nung im SNP. Die monatlichen Planmengen aus dem DP werden
filr das SNP auf ArtikellLokationsebene auf Tage verteilt.
Das SNP ilbernimmt zwei Aufgaben. Die Monatsplanung dient
zur Ermittlung eines bestatigten Absatzplans. In der Nach-
schubsteuerung werden dann aufsetzend auf dem bestatigten

165
Einfiihrung des APO zur Unterstiitzung des SCM

Absatzplan Nachschubvorschlage erzeugt und an die Auftrags-

verwaltungssysteme verteilt. Die beide Planungen werden in ge-
trennten Planversionen gehalten.

Vertrieb und
Marketing /\
Neuer Absatzplan Ubergabe an AVSJ I8glch
R/3
Logistlk /
Nettobedarfsrechnung Logl.tlk UberprUlung, Anpassung,
Netzwerl< Nach sch ubplanung Ander ung der
UmI.gerung uf~age
Marketing! Logistlkl
I I
Loglstlk
Produk11on DeploymentLaur
Bestitlgung LAuft tAgich
Produktionsbesprechung
Netzwerk
AbWllplanung
12.19. Arb.n.lag I I
Logistlk Lokatlonsheurl.t Ik
Loglstlk
Oeployment-Lauf Bestiitlgung NeHobodarfsrechnung LAulllAglich
Netzwerk Netzwelk
/ I
Vertrieb un Marketing
20. Arbeilslag 20. Arben. lag
Btiitlgler Abs.tzplan
Monatsplanung Monal +1 b ls +6 : Nacl'Ischubsleuel"ung aktueller Mona! ..

Abbildung 80: Prozessuberblick: SNP-Planung

5.1 Monatsplanung
Die Monatsplanung erfolgt in der Planversion 001 fUr einen Zeit-
raum von 6 Monaten in die Zukunft. Aile Planungslaufe in der
Monatsplanung werden zu einem festgelegten Termin in einem
monatlichen Planungsrhythmus durchgefuhrt. Abbildung 81 zeigt
den Ablauf der Monatsplanung.

l
Demand Planning
Unbestiitigter
Absatzplan
I
+-
Absatzplanung
Konligentierung
Bestiitigles
Kontingenl RVZ

SNP
SNP
Nettobedarfs-
Riickverteilung
rechnung
Nelzwerk

+ t
Netz we rk
Nellobedarf Artikel Bestiitigter Abfiillplan
Abfiillplanung Abfiillplanung
Bruttobedarf Vertellung auf
Artikelgruppe Artikel

Vorschlag I . ---.J
t Bestiitigte
Produklion ~ Produklions-
besprechung
Produklion

Abbildung 81: Monatsplanung SNP

166
 RalfThomas

Der unbestatigte Absatzplan yom DP erzeugt Vorplanprimarbe-

darfe an Verkaufsprodukten (Artikeln) auf den RVZs. Die Netz-
werkheuristik verteilt die Bedarfe mit Hilfe von Nachschubauf-
tragen (oder auch Umlagerungsbestellanforderungen) auf die Lie-
ferwerke, in denen die Artikel produziert werden. Diese Nach-
schubauftrage bilden mit weiteren Abgangen den Bruttobedarf.
Unter Berucksichtigung des Bestands und den geplanten und
festen Zugangen kann dann der Nettobedarf an Artikeln auf den
Lieferwerken festgelegt werden. Dieser Nettobedarf an Artikeln
wird zur Berechnung des Bruttobedarfs an Artikelgruppen ver-
wendet. Hierbei ist zu beachten , dass Artikel verpackte Ware
und Artikelgruppen unverpackte Ware CProdukte, die produziert
werden) darstellen. Die Mengen an zu produzierenden Artikel-
gruppen werden nicht, wie ublich, uber eine Stucklistenauflb-
sung ermittelt, sondern Uber die Merkmalszuordnung von Arti-
kelgruppe zum Artikel. Dies ist mbglich, da zwischen diesen
Produkten eine 1 zu 1 - Beziehung besteht, d.h. 1 kg Artikel ist
gleich 1 kg Artikelgruppe.
Der Bruttobedarf an Artikelgruppe ergibt somit den Vorschlag
der zu produzierenden Menge. In der Produktionsbesprechung
wird dieser Vorschlag ausgewertet und uberprUft, welche Pro-
duktionszusagen gegeben werden kbnnen. AnschlieBend werden
in der AbfUliplanung die Produktionsmengen in geforderter oder
minimierter Menge bestatigt, indem die Produktionszahlen in das
System eingegeben werden (zum Projektstart war kein Produkti-
onsplanungssystem angeschlossen und es fand auch keine Pro-
duktionsplanung im APO statt, war aber fUr die Zukunft ge-
plant). Eine RUckverteilung der Produktionszusagen an
Artikelgruppen auf die Artikel bilden den bestatigten AbfUliplan.
Da nun bekannt ist, welche Mengen an Artikel zu einem be-
stimmten Termin zur VerfUgung stehen werden, kbnnen diese
Mengen an die RVZs zurUckverteilt werden. Dies geschieht durch
einen Deployment-Lauf, der die zu Beginn erzeugten Nach-
schubauftrage bestatigt.
Die bestatigten Nachschubmengen auf den RVZs werden dann
zuruck an DP ubergeben und bilden den bestatigten Absatzplan .

5.3 Nachschubsteuerung
Die Nachschubsteuerung erfolgt taglich fUr einen Monat in der
aktiven Version 000. Die aktive Version ist mit den angeschlos-
senen Auftragsverwaltungssystemen verbunden. Aile Planungs-

167
Einfiihrnng des APO zur Unterstiitzung des SCM

laufe werden jede Nacht in Batchlaufen durchgefuhrt. Abbildung

82 zeigt den Ablauf def Nachschubsteuerung.

Demand Planning
Absatzplanung
Kontigentierung
Bestatigter Absatzplan

SNP
Nettobedarfsrechnung
Netzwerk

SNP
Nachschubvorschlag
Manuelle Anpassung
Auftrage Auftrage
I
f t
AVS R/3
RVZ I Lieferwerk RVZ I Lieferwerk

Abbildung 82: Nachschubsteuerung

Die bestatigten Vorplanprimarbedarfe werden vom DP an die

RVZs der aktiven Version 000 des SNP ubergeben. Die Netz-
werkheuristik verteilt diese Bedarfe durch Erzeugen von Nach-
schubauftragen auf die entsprechenden Lieferwerke . Da die Pro-
duktion die Bestande an Artikeln auf den Lieferwerken erhoht
hat, konnen diese Bestande an die RVZs verteilt werden. Der
Deploymentlauf ubernimmt diese Verteilung, indem die Nach-
schubauftrage bestatigt werden.
Die bestatigten Nachschubauftrage konnen dann noch manu ell
angepasst und an die ERP-Systeme ( Enterprise Resource Plan-
ning; hier AVS und R/ 3) freigegeben werden . Hier stoBen sie
den Nachschub physisch an.

6 SystemObergreifender Nachschub
Nachschubauftrage werden im APO als sog. Umlagerungsbestell-
anforderungen bzw. -bestellungen abgebildet CBestellanforde-

168
 RalfTbomas

rungen sind geplante Zugangselemente, Bestellungen sind feste

Zugangselemente).
Bei der Ubergabe der Nachschubauftrage an das R/3 werden im
Standard ebenfalls Umlagerungsbestellungen erzeugt.
Der Konzern wird aber durch mehrere R/3-Systeme und ein ei-
genentwickeltes Auftragsverwaltungssystem (AVS) abgebildet
und systemubergreifende Umlagerungsbestellungen sind im
Standard nicht m6glich. Urn Nachschube zu decken, mussen da-
her Normalbestellungen erzeugt werden, die durch Kundenauf-
trage beliefert werden. Nun ist sicherzustellen, dass die Konsis-
tenz zwischen den einzelnen Systemen gewahrt bleibt und der
Bedarf auf der liefernden Lokation im APO stets vorhanden ist,
sei es durch einen Bestellabruf oder durch einen Kundenauftrag.
Diese Konsistenz bildet die Vorraussetzung fUr eine "korrekte"
Tagesplanung im SNP.
Da dieser Prozess nicht mit Standardmitteln erreicht werden
konnte, wurde durch Zusatzentwicklungen in den einzelnen Sys-
temen die fehlende Funktionalitat bereitgestellt.
Schnittstellen Als Schnittstellen zwischen den Systemen dienen:
APO -> R/ 3: CIF (Core Interface, Standardschnittstelle
zwischen R/3 und APO).
R/3 -> AVS: eigenentwickelte Schnittstelle mit Zugriff auf
BAPIs im R/3 (BAPI: Business Application Programming
Interface, RFC-fahige Standardfunktionsbausteine).
AVS -> APO: eigenentwickelte Schnittstelle mit Zugriff
auf BAPIs im APO.

Abbildung 83 zeigt den Prozess des systemubergreifenden Nach-

schubs.

169
Einfuhrung des APO zur Unterstutzung des SCM

APO
RVZ

UB~NB Synchronisation

AVS

NB KA

RVZ: Regionoles Verteltzentrum

85: Besleflbeleg
NS: Normolbestelfung "bont
us: Umlogerungsbeslelfung 'bont
Sont: Besleflontorderung
KA: Kundenouftrog
AVS: Auftrogsverwoltungssystem

Abbildung 83: Systemubergreifender Nachschub

Die im APO von der Lokationsheuristik erzeugten Umlagerungs-
bestellanforderungen werden an die Rl3-Systeme des Vertriebs
verteilt. Dabei werden die Umlagerungsbestellanforderungen in
Normalbestellanforderungen umgesetzt (Punkt 1).
Der Unterschied zwischen einem Umlagerungsbestellbeleg und
einem Normalbestellbeleg definiert sich wie folgt:
Umlagerungsbestellbeleg -> wird von Lokation / Werk
beliefert
Normalbestellbeleg -> wird von Lieferant beliefert
Die Bestellanforderung wird in R/3 in eine Bestellung umgesetzt
und an den APO zurUckgegeben. Dabei wird die Normalbestel-
lung aus dem R/ 3 wieder in eine Umlagerungsbestellung umge-
wandelt, damit der Bedarf (in Form eines Bestellabrufs) auf dem
Lieferwerk vorhanden bleibt (Punkt 2).

170
 RalfThomas

Die Normalbeste11ung wird gleichzeitig an das Lieferwerk im AVS

gesendet. Hier wird ein Kundenauftrag generiert, der die Bestel-
lung vom RVZ beliefern so11 (Punkt 3).
Das AVS ubermittelt den Kundenauftrag an den APO (erfolgt tag-
lich einmal). Dabei wird der Beste11abruf auf dem Lieferwerk ge-
16scht. Ais Bedarfselement dient jetzt der Kundenauftrag (Punkt
4).

7 Fazit
Die Supply Chain vom Kundenbedarf bis zum Produktionsbedarf
konnte mit diesem Projekt im APO erfolgreich abgebildet wer-
den. Naturlich ist die Supply Chain bei der Produktion nicht zu
Ende. Neue Projekte beschaftigen sich aus diesem Grund mit der
EinfUhrung weiterer APO-Module.
Zu nennen ware hier z.B. die EinfUhrung des PP/ DS, der Pro-
duktions- und Feinplanung. Mit diesem Modul kann auch die
Produktionsplanung im APO (mit APS: Advanced Planning Sys-
tem) erfolgen, die gegenuber der Planung im R/3 mit dem MRP-
II-Konzept (Manufacturing Resource Planning) qualitative Vortei-
Ie bringt, denn PP IDS kann , aufsetzend auf die vom SNP erzeug-
ten Bedarfe, fur die Produktion machbare sowie optimierte Plane
erste11en.
Mit einem anderen Projekt wird die globale VerfUgbarkeitspru-
fung (global ATP; Available to Promise) eingefUhrt (s. auch Ab-
satz "Prozess Demand Planning"). Anhand von Regeln kann das
ATP dem Vertrieb jederzeit und weltweit eine Aussage uber die
VerfUgbarkeit und die Lieferzeit eines Verkaufsprodukts geben.
Auch werden die abgebildeten Prozesse des DP und des SNP in
weitere Unternehmensbereiche des Konzerns ausgeweitet, wobei
in einem Unternehmensbereich zusatzlich ein so genanntes VMI-
Szenario (Vendor Managed Inventory) umgesetzt werden so11.
Dabei werden einem (Haupt-)Kunden die eigenen Bestandszah-
len zur Verfugung gestellt und der Kunde kann dann auf dieser
Grundlage eine Absatzplanung fUr den Lieferanten erstellen. Mit
diesem Szenario wird der Schritt vom internen SCM zum exter-
nen SCM vollzogen.
Zum Abschluss sei noch ein Blick in die Zukunft gewagt. Da
derzeit abzusehen ist, dass die Hard- und Software-Ressourcen
eines einzelnen APOs fur den ganzen Konzern nicht ausreichen,

171
CBT-Kurse in der ABAPl4-Programmierung

werden jetzt schon Konzepte tiber verteilte APO-Landschaften

erarbeitet.

8 Glossar
APO Advanced Planner and Optimizer
APS Advanced Planning System
ATP Available to Promise
AVS eigenentwickeltes Auftragsverwaltungssystem
BAPI Business Application Programming Interface
BW Business Warehouse
CIF Core Interface
DP Demand Planning
ERP Enterprise Resource Planning
KA Kundenauftrag
MRP II Manufacturing Resource Planning
NB Normalbestellbeleg
PP!DS Production Planning and Detail Scheduling
RVZ Regionales Verteilzentrum
SCM Supply Chain Management
SNP Supply Network Planning
UB Umlagerungsbestellbeleg
VMI Vendor Managed Inventory

SAP, R/3, R/2, SAP APO, SAP Business Information Warehouse,

BAPI sind Marken oder eingetragene Marken der SAP AG

172
 Reinhard Mayr

CBT-Kurse in der ABAP/4-Programmierung

Reinhard Mayr

1 Einleitung
Seit Jahren werden die Mittel fUr Personal in der Ausbildung so-
wohl in der Hochschule als auch in der Industrie kontinuierlich
reduziert. Das Motto heiBt: "Mit weniger Personal mehr Ausbil-
dung schaffen!". Diese an sich widersinnige Anforderung kann
nur aufgefangen werden, indem man den konventionellen Weg
der Ausbildung mit Trainern und Hilfstrainern verlasst und zu-
satzliche automatisierte Lehr- und Lernformen einbezieht.
Betrachtet man die Verbffentlichungen der letzten Jahre zu die-
sem Thema, so begegnet man Begriffen wie CBT (Computer Ba-
sed Training), WET (Web Based Training), OT (Online Training)
oder ACSCL (Asynchronous Computer Supported Collaborative
Learning). All diesen Methoden ist gemein, dass das Lehren und
Lemen mehr oder minder automatisiert erfolgen soli! Die Frage
ist: Welche Methode ist woftir anwendbar und welche Lernerfol-
ge kann man damit erzielen?
Die Literatur gibt hinsichtlich der Lernerfolge, die mit hyperme-
dialen Lernsystemen erreicht werden kbnnen keine eindeutige
Antwort I I /. Studien beztiglich der Lemerfolge widersprechen
sich zum Teil und somit scheidet eine allgemeingtiltige Betrach-
tung, die konventionelle Lehrmethoden mit e-learning-Methoden
vergleicht, aus. Unsere spezielle CBT-Kurserfahrung in der Pro-
grammierung von ABAP/ 4-Anwendungen mbchten wir als An-
schau ungsbeispiel vorstellen.
In der Hochschule setzen wir schon seit Jahren CBT's bei der
Ausbildung unserer Tutoren erfolgreich ein, z.B. ftir die Einarbei-
tung in kommerzielle Softwareprodukte wie Adobe GoLive oder
Macromedia Dreamweaver, etc .. Die Studierenden (meist Hilfsas-
sistenten der DV) kommen gut damit zurecht und der Lernerfolg
ist gut, was die meist anschlieBenden Projekte beweisen. Es lag
also die Frage nahe, in einem ersten Schritt eigene bewahrte

173
CBT-Kurse in der ABAPl4-Programmierung

konventionelle Lehrkonzepte und -inhalte in ein CBT/WBT-

Konzept umzusetzen.
Ausgewahlt wurde der Programmierkurs "ABAP/4-Basis", der in
der konventionellen Ausbildung im Rahmen eines Praktikums
stattfindet und einen Stundenumfang von 60 h hat. Als Eingangs-
voraussetzungen fur den Kurs gelten gute Kenntnisse einer ho-
heren Programmiersprache (C-Kurs) und Kenntnisse im Aufstel-
len und Programmieren eines Anwendermodells fUr relationale
Datenbanken (Access oder FoxPro) .
Der Kurs vermittelt ausgewahlte Sprachkonzepte und -konstrukte
von ABAP/ 4 in einem ganzheitlichen Ansatz. An der Aufgabe
"Artikelbestellung" erfolgt die Programmierung von SAP-
Dynprofolgen zur Eingabe und Manipulation von Personen, Lie-
feranten, Artikeln und Bestellungen.
Die notwendige Betreuungskapazitat fur einen konventionellen
Kurs mit 15 Teilnehmern betragt wahrend der Kurszeit : 1 Pro-
fessor, 1 Assistent und 2 Tutoren. Nach unserer langjahrigen Er-
fahrung binden ca. 5-6 Teilnehmer einen Betreuer im konventio-
nellen Computerkurs, unabhangig von der Art des Trainings.

2 Entwicklung eines CBT-Konzeptes

Betrachtet man die angebotenen kommerziellen CBT's im Com-
puterbereich so fallen mehrere Dinge auf:
Bindung der Bedienoberflache an eine spezielle
HW/ SW-Landschaft (nur Wintel-PC oder nur Mac)
Funktionsorientierung der Lektionen im Sinne einer
Handbucherweiterung, kein didaktisches Konzept
Lektionen ohne audio-visuelle Unterstutzung bis hin zu
Lehrvideos
keine Lernkontrolle, manchmal Multiple Choice.
Es ist immer wieder verwunderlich, dass sich trotz mangelhaftem
didaktischem Konzept und nur rudimentarer Lernkontrolle mit
einem CBT Lernerfolge erzielen lassen. Denn dass dies moglich
ist, zeigen die Tutoren immer wieder. Es ist offensichtlich nur ei-
ne Frage des Engagements, der Zie!orientierung und der Hartna-
ckigkeit, urn auch mit einem mitte!maBigen Medium zum Erfolg
zu kommen.
Unsere Voraussetzung fUr die Erstellung eines CBT-Kurses waren
gleich zu Beginn besser, da es sich urn einen bereits bewahrten

174
 Reinhard Mayr

und mehrfach erprobten konventionellen Kurs mit ganzheitli-

chern didaktischem Konzept handelte. Allenfalls die Frage, wie
die derzeit lehrenden und betreuenden Tatigkeiten durch ein
anderes geeignetes Medium zu ersetzen sind, steht zur Diskussi-
on. Hier orientieren wir uns zunachst an den Tatigkeiten der
Kursbetreuer.
Was waren die haufigsten Fragestellungen der Teilnehmer im
konventionellen ABAP/ 4-Kurs und wo benotigten sie die meiste
Unterstutzung?
Hier die haufigsten Antworten:
Dberblick in der Softwarearchitektur verloren!
Wie soli das Ergebnis der Teilfunktion genau aussehen?
Befehlssyntax der ABAP 14-Sprache vergessen (meist O-
pen SQL, PAl , PBO)!
Faden verloren (zum Stand der Lektion)!
Handling der ABAP/ 4-Workbench vergessen oder feh-
lerhaft!
Standardprogrammierfehler (semantische Fehler)!
Betrachtet man das Feedback der Kursteilnehmer, so wird unmit-
telbar klar, dass hier unterschiedliche Lerngeschwindigkeiten und
unterschiedliche Merkfahigkeiten eine Rolle spielen. Diese An-
forderungen sind in einer automatisierten Lernumgebung sehr
vie! besser zu erfUlIen als in einer konventionellen Veranstaltung,
da die individuelle Wiederholung der audiovisuellen Sequenzen
beliebig oft moglich ist. Der Missbrauch der Tutoren als Merkma-
schine entfallt.
Ein kleiner Wermutstropfen im CBT-Konzept ist die Unterstut-
zung bei semantischen Fehlern in der Programmierung. Diese
Fehler bedurfen individueller Betreuung durch einen Tutor und
konnen daher durch keinen Automatismus ersetzt werden. Hier
sind zusatzliche organisatorische MaBnahmen gefragt!
Doch zuruck zu den eigentiichen Lehrinhalten. 1m Vordergrund
des CBT stehen die Lehreinheiten des Kurses ABAP/ 4-Basis und
dessen konventionelle Prasentation:
Einfuhrung der ABAP/ 4-Sprachkonzepte,
Konventioneller Vortrag mit Powerpoint-Folienfolge,
Einfuhrung in die Workbench,

175
CBT-Kurse in der ABAPl4-Programmierung

Demonstration am System,
Vorfiihren/ nachahmen,
Einftihrung in den Screenpainter,
Demonstration am System,
Vorftihren/ nachahmen,
Einfiihrung in den Mentipainter,
Demonstration am System,
Vorftihren/ nachahmen,
Erklarung der Aufgabenstellung,
Zeigen der fertigen Endanwendung,
Erklarung des Datenmodells,
Vorstellung der Namenskonventionen,
Einftihrung Domanen, Datenelemente und Tabellen,
Erklarung des Prozessmodells,
Zeigen der Maskenlayouts,
Erklarung der PBO-, PAI-Prinzipien an der Tafel,
Erklarung der Softwarearchitektur,
Modulhierarchie als Graphik,
Funktionsnetz als Graphik,
Erklarung der Lerneinheiten des gestuften Konzeptes,
Ziel der Lerneinheit,
Vorgehensweise in der Lerneinheit,
Zeigen der finalen Teillbsung,
Lernkontrolle.
Betrachtet man die obigen Aufgaben etwas genauer, so stellt
man fest, dass die meisten Lehraufgaben unmittelbar in ein mul-
timediales Medium umsetzbar sind. So ist z.B. die Demonstration
von Interaktionen am Computer durch Bildschirmvideos (Captu-
red Video) und zusatzliche Sprachausgabe ersetzbar. Folienpra-
sentationen kbnnen mit derselben Methode automatisiert wer-
den. Aufgabenbeschreibungen oder Erklarungen mit den zuge-
hbrigen Graphiken sind als Text und Graphik darstellbar. Tafel-
arbeit kann tiber den Zwischenschritt "Powerpoint-Folie" durch

176
 Reinhard Mayr

ein Bildschirmvideo mit Sprachausgabe ersetzt werden. Lediglich

das Gesamtkonzept der ABAP/4-Sprache mit allen syntaktischen
Elementen wird als audiovisuelle Sequenz zu aufwendig und zu
umfangreich. Es konnen also nur die absolut notwendigen
Sprachelemente, orientiert an den Lektionen, umgesetzt werden .
Die Lernkontrolle ubernehmen im konventionellen Kurs die Tu-
toren, indem sie die Funktionalitat der Programmierung am Bild-
schirm uberprlifen. Hier muss ein CBT-Konzept auf die Disziplin
der Teilnehmer vertrauen . Es gilt die eigenen Programmierer-
gebnisse mit der Funktionalitat der Musterlosung im Screenvideo
zu vergleichen.

3 Internetbrowser als CBTBedienoberflache

Wie bereits erwahnt, werden die meisten erwerbbaren CBT's mit
Autorenwerkzeugen erzeugt und sind damit meist an eine spe-
zielle HW/SW-Umgebung gebunden. Dies ist in sofern unglUck-
lich, als jeweils eine lokale Installation der Schulungs-CD vorge-
nommen werden muss. Auf der anderen Seite ist das Vorgehens-
konzept seitens der Hersteller von CBT's verstandlich, erwirbt
man doch mit einer CD nur eine Schulungslizenz. Eine Kopie
darf in der Regel nur zu Sicherungszwecken erstellt werden.
In der Hochschule verfolgen wir einen anderen Ansatz:
moglichst viele Teilnehmer mussen an unterschiedlichen
Standorten in der Hochschule auf aile Kursinhalte
zugreifen konnen, wobei es keine Rolle spielen darf, auf
welcher Hardware/Software-Umgebung sich der Teil-
nehmer befindet,
die Bedienoberflache der Schulungsumgebung sollte
moglichst einfach sein,
die aus kommerziellen CBT's bekannten multimedialen
Elemente mlissen integrierbar sein,
Teilnehmer mussen auch zu Hause die Trainingslektio-
nen durcharbeiten konnen CRemote-ZugrifO.
Damit ist klar, dass nur ein universell verfUgbares, multimediales
Werkzeug in Frage kommt. Gewahlt wurde ein Internetbrowser
als Bedienumgebung.
Der unschatzbare Vorteil der Internetbrowser liegt im Bekannt-
heitsgrad, d.h. jedes Kind kann heute mit einem Internetbrowser
umgehen.

177
CBT-Kurse in der ABAPl4-Programmierung

Auch die graphischen Entwurfswerkzeuge zur Seitengestaltung,

wie z.B. Adobe GoLive, werden in der Hochschule eingesetzt.
Die Anwendung der Tools ist leicht erlernbar (CBT), einfach in
der Anwendung und insbesondere ausgereift und robust. Fur die
Erstellung von Videoclips gibt es verschiedene lizenzfreie Werk-
zeuge. Sie erlauben die Aufnahme von Videosequenzen mit Ton
direkt yom Bildschirm, d. h. man kann die Interaktion mit dem
Cursor zeigen und gleichzeitig zugeharige Kommentare auf-
zeichnen. Es entsteht ein Videoclip im avi-Format, das mit einem
Seitengestaltungswerkzeug in die HTML-Seiten integriert werden
kann.
Die Vorgehensweise zur Erstellung einer Lernumgebung gleicht
damit dem Entwurf und der Implementierung einer Internet-Site .
Als erster Schritt auf dem Weg zur CBT auf HTML-Basis ist das
Framelayout und die Seitengraphik zu entwerfen. Die graphische
Gestaltung der Menus mit ihren Untermenus ist festzulegen und
die Rohtexte, Bilder, Graphiken, Animationen und Videos sind
entsprechend vorzubereiten. Standard-HTML bietet alles was
heute zu einer modernen graphischen Benutzeroberflache ge-
hart:
Ausgabe von Text, Bild, Graphik, Animation, Audio und
Video,
Eingabe uber Maskenfelder und Multiple-Choice-Menu,
Steuerung uber Menu , Buttons, Clickboxes und Radio-
buttons.
Dber Java-Skript-Erweiterungen ist ein dynamisches Ver-
halten der einzelnen Seiteninhalte erreichbar.

4 Voraussetzung fur die inhaltliche Umsetzung "ABAP/4-

BASIS" auf eBT
Die Basis fur die Umsetzung des ABAB/ 4-Kurses bildet das
schriftlich ausgearbeitete Lehrkonzept. In diesem Lehrkonzept ist
zunachst die Gesamtaufgabe definiert und das Lernziel fur den
Kurs festgelegt.

178
 Reinhard Mayr

AKTION KOMMENTAR
ErWuLcrung des Sinnes e ines ER-Modells Der l3egrirr ER- Modell sollte den Stu-
als schematische Darstellung informati - denten aus der Vorlesung bereits gelau-
onstcchnischcr ZusaI11I11enh~ingc fig sein und \vird an dieser Stelle>; ie-
derholend erw~ihnL.
Vorstellung der CASE- ethode <lIs Den 5tudenten soli erg~inzend zur or-
Werheug zur Analyse und Darstellung lesung ein Wcrkzeug vorgestcllt wer-
solcher Zusammenhange den, mit dem Sie ein ER- Modell allf-
stcllcn k6nnen.
ErWlIlerllng des 13egriffs Entity am Hei- Dies stelll eine kllrze Wiede rholung
spiel ciner Person unci ciner Adres e von Inhalten der Datenbank- orlesung
dar.
Allgemeine ErWuterung des 13egriffs Re- Den Studenten soli der l3egriff
lationship am 13eispiel der I3eziehllng
Helationship cI enfalls in Ged~ichlnis
"wohnt in zwischen einer Person und
zuri.ick gerufen \ erden.
ihrer Adresse
Genauere I3etrachtung des Helationship- Erganzung der Datenbank- Vorlesung
I3egriffes durch Darstellllng der 13ezie- clurch den Sachverl1alt der optionalen
hungstypen: oder zwingendcn 13eziehllng.
1:1
1:n
m:n
optional unci zwingend
Erlallterllng des I3egriffs Attrihllt am Bei- Der I3egriff des Attrihutes sollte den
spiel des Entity Person Studenten hereit gelallfig sein und
wird an die cr relle wiederl10lend er-
Antede, Vorname , acl1name
wahnl.

Tabelle 1: Ausschnitte aus der Verlaufsplanung ER-Modell/2/

Die Dekomposition der Aufgabe in Strukturblbcke (Lektionen)

mit zugehbrenden Zielen erfolgt analog zu einer BuchgJiederung.
Jede Lektion besteht wiederum aus einer Reihe von Teilaufgaben
mit Teilzielen. Die Bearbeitungsdauer jeder Teilaufgabe ist zeit-
lich fixiert und kann zwischen 20 und 90 Minuten liegen. Das
Vorgehenskonzept zur Vermittlung des Lehrstoffes einer Teilauf-
gabe ist in einem padagogischen Vorgehensschema (Verlaufs-
planung) detailliert beschrieben CTabelle 1).

179
CBT-Kurse in der ABAPl4-Programmierung

4 Realisierungsteam und Organisation

Das Team zur Realisierung des CBT bestand aus vier Mitarbeitern
mit unterschiedlichem Know-how. Zunachst sind aile Teammit-
glieder in ABAP/ 4-Basis und ABAP/ 4-Advanced ausgebildet und
zertifiziert, d.h. sie haben beide konventionellen Kurse durchlau-
fen und wissen worum es geht. Ausgezeichnete Kenntnisse in
Seitengestaltungstools und diversen Graphiktools zum Entwurf
von Blockbildern, Netzwerken und Animation sind bei den zum
Team gehbrenden Internetbetreuern vorhanden. Die Arbeit mit
dem Tool "Snagit" zur Erzeugung der Screenvideos war die spe-
zielle Umgebung des "Nachrichtensprechers" . Hier ist bei der
Vertonung der Bildschirmsequenzen darauf zu achten, dass die
Stimme in der Wiedergabe auch hingerfristig einen angenehmen
Eindruck hinterlasst. Nicht jede Stimme ist zur Vertonung geeig-
net, was die Stimm- und Reaktionstests bei willkurlich ausge-
wahlten Testpersonen aus der Studentenschaft bewiesen.
1m Realisierungsteam testeten zwei Teammitarbeiter jede der
CBT-Lektionen auf Machbarkeit (Alpha-Test). Die Lektionen
wurden so lange bearbeitet bis ein optimales Ergebnis erzielt
wurde (Alpha-Freigabe). Zusatzlich zum Realisierungsteam wa-
ren externe Testpersonen (Beta-Tester ohne ABAP/ 4-Kenntnisse)
mit Programmier- und Datenbankkenntnissen eingesetzt, die je-
de einzelne Lektion des CBT nach der Alpha-Freigabe durchar-
beiteten und die beschriebenen Aufgaben realisierten. Gleichzei-
tig diente diese kritische Testmannschaft der Qualitatssicherung
der Lektionen (Syntax und Semantik) und bediente die Feed-
backschleife zur Optimierung der Lektionen. Die Resultate aus
Alpha- und Betatest wurden zur Musterlbsung verarbeitet.

5 Umsetzung in HTML
Die Anforderungen an ein Benutzerinterface fUr ein CBT sind
sehr vielfaltig. Die Hauptforderung ist zunachst einmal eine ein-
heitliche Struktur fUr aile Lektionen. Die Bedienung sollte leicht
und intuitiv erfolgen, was naturlich durch die Benutzung einer
Weboberflache begunstigt wird. Hinsichtlich der Darstellung der
Inhalte gelten die allgemeinen Prasentationsregeln des Internet:
Texte mit einfacher gro1Ser Schrift, fetter Satz,
Bilder und Graphiken plakativ und leicht interpretierbar,
Videosequenzen kurz und einpragsam,

180
 Reinhard Mayr

Animationen sparsam und zielorientiert,

Seiteninhalte ganz sichtbar Cmbglichst ohne "Scrolling").
Da das schriftliche Lehrkonzept die Struktur des CBT bestimmt,
ist zunachst die Frage zu stellen, ob die konventionellen Lektio-
nen mit den Teilaufgaben klein genug sind, um direkt in Lektio-
nen des CBT umgesetzt werden zu kbnnen. Hier ist jeder Ver-
laufsplan einer Lehreinheit zu analysieren. Es muss ggf. eine Ent-
scheidung fur ein Splitting getroffen werden, d.h. das Lehrkon-
zept erhalt neue Teilaufgaben mit neuen Teilzielen und Vorge-
henskonzepten. Diese Arbeit muss sehr sorgfaltig durchgefUhrt
werden, da eine strukturelle Anderung im Konzept bei der Reali-
sierung der Bedienoberflache meist eine Anderungswelle in be-
reits realisierten Lektionen hervorruft. Die schriftliche Fixierung
des Lektionenkonzeptes beendet die erste Phase.
Die einzelnen Teilaufgaben sind jetzt inhaltlich festgelegt und die
mediale Aufbereitung kann erfolgen:
Erstellung der Lehrtexte CRohtext),
Aufgabenbeschreibung CRohtext),
Erstellung der unterstiitzenden Graphiken Cnach einheit-
lichem Graphikschema),
Erstellung von Animationen (Animated Gif),
SAP-Screenshots,
Erstellung der Drehbucher fUr die Screenvideos,
Erstellung von verwandten Programmierbespielen als
Guide.
Auf der Basis der Definition der Teilaufgaben kann ebenfalls
sukzessive mit der Realisierung in SAP R/3 begonnen werden,
denn die Screenshots und Bildschirmvideos Cvgl. Abbildung 84)
kbnnen nur am aktiven System gewonnen werden.
Parallel zur Aufbereitung der multimedialen Elemente erfolgt das
graphische Design der HTML-Bedienoberflache. Gewahlt wurde
ein Layout mit 2 Frames und einem zweistufigen Menu (vgl.
Abbildung 85).

181
CBT-Kurse in der ABAPl4-Programmierung

x ......

- ..
- - - ~- -- -- - - - - - ---

Abbildung 84: Screenvideo

Wie man in der Menustruktur in Bild 3 erkennt, enthalt der Kurs

die theoretischen Einfiihrungen in die Aufgabe sowie die Be-
schreibung der organisatorischen Randbedingungen . Auch das
Data Dictionary und eine Anleitung zur Programmierung sind
Bestandteil des CBT.
Eine Besonderheit im Layout ist der Index. Er gibt zu jeder Lekti-
on die zu den Menubuttons gehbrenden semantischen Langbe-
schreibungen bekannt. Aufgrund des Platzbedarfes ist es leider
nicht mbglich die beschreibenden Langtexte in das Steuermenu
zu integrieren. Der leuchtend gestaltete Pfad zeigt die Verknup-
fung zwischen Lektion und Teilaufgabe. Einer der Haupteinwan-
de der Teilnehmer in den konventionellen Kursen war der Ver-
lust des Dberblicks in der Softwarearchitektur. Hier schafft das
CBT Abhilfe durch eine Funktionsgraphik, die den gerade zu be-
arbeitenden Teilumfang markiert CAbbildung 85, gruner Frame)
und auch aile anderen Bereiche Crealisierte und zukunftige)
zeigt. Der Teilnehmer weilS also zu jedem Zeitpunkt, wo er sich
befindet. Der "Kamerabutton" Vorschau steuert das Screenvideo
mit der zu erzeugenden Teill6sung an. Das Video ist Vorgabe
und Lernkontrolle zugleich.
Insgesamt umfasst der CBT-Kurs 14 Lektionen mit einem Ge-
samtumfang von 150 MB multimedialen Daten. Der CBT-Kurs ist
auf eine Bearbeitungszeit von ca. 80 h ausgelegt. Motivierte
Studierende bewaltigen den Kurs auch in 60 h.

182
 Reinhard Mayr

o "t ....pe: RBRP /4-TutorI81 - LetHon I - Rnlegen <ler Ruswahlm"ske 08

Sto..... itv Slop Stop

... bNtlO6 .~ lm, -lllr.-ICP/D..H~p.2Qf"oW.,./NlW'4 Tutort.IIt..Ubr~200IIl~'iotIl"'OllL..kllonl_(,.~ ...t_O',htm

~ 1'"'9'1 8J 1.....1
Elnrohrung Data Dictionary Programmlerung Lektlon 2 Lektlon J

Index A02 A03 A04 AOS A06 A07 A08 A09 A 10 A 11 A 12

Funf1,onen acsgefUnn ~dprneue Ma.kpn geornetWllldPn E,nem Oynprc WIl,don Immer auen Pin Gl,~Slatus (IIIMUlelste) uno "In :lUI-T'tel
(lAa.kenutersth"ft) ZlJgeordneL

NaChdem die PJJSW3~lmaSWe .rSlall! u~d Deartlellel WIlrden lSI, SOil inrI H,ne elne, Ilansaf~Dn aas ~,o~,amm lOm erslen ~lal aJSQeluh~werden
Dazu isle. orordell'th dass d,e Fun"1icn l'rog,amm beenden' ploglamm'ertwud. dam,: d,e Dlaloganwendung ",'ederve,lassenVierden kann

r - --- -- - -- - - - - - -- - -- ---I
I Dynpro 11110 :
Dynpromap SAPMYXXl AnmBklung I

; ::-~::::::::::::.-.-::: j {~_,I
-- --------------------
I'~ Oll"pro "'OB !<I r- ,.. - :--------------------.!
Art.Ie. ,,waHen I '; 0YIIPIU 2010

;... ~
, '
- AUWMhl

..
Oynpro 4110 Au.".".."1 :

'~-~::;~~~-::~f;::::j~~~~~ !
Li.,.... n1IIIn"'...,...Hen

Art~I"'il!nllMn.en

-- .. ~~!~! ...~~~~...... .t ; ,t -:; I Selitdll.-.gml ufYWIlHm "

~~~~;:~~~~:~.l ~ rt~~~~~~~~~~?:
P~fW)Qffl "",rwelten

P ......mandRn
~-.-_::-.-_-_:-_-.-_-_-_-_-_:-.i :: 1,.:::.: f::::.

I Beendm ~ IL-.

;....: : '--
---4 :

Abbildung 85: Seitenlayout CBT

6 DurchfOhrung des CBTKurses

Auch CBT-Kurse bedurfen der Kursvorbereitung. Voraussetzung
fUr unseren Kurs sind vernetzte, multimediale Labor-PC's/ 233
MHz/ 128 MB/ 20 GB mit Win2000, Ethernet 10 Mb und
Soundkarte . Das ist in der Regel ausreichend fUr die benbtigte
Performance. Zusatzlich benbtigt man je PC eine SAPGUI-
Installation, einen Internetbrowser und eine Applikation zur
Betrachtung von Videoclips ( z,B. Microsoft Media Player).

183
CBT-Kurse in der ABAPl4-Programmierung

Die EntwicklerschlUssei sind bereitzustellen und es ist auch zu

checken, ob sie funktionieren, d .h. die SAPGUI-Installationen
und das Logon mUssen UberprUft werden . Die Zugriffe der
Browser auf den CBT-Server sind zu gewahrleisten und das alles
sollte auch noch im Zusammenspiel SAPGUI, Browser, Videobet-
rachtertool und Soundkarte funktionieren, denn das ist die benb-
tigte Arbeitsumgebung fUr jeden Kursteilnehmer. Natiirlich soll-
ten die Teilnehmer die Kopfhbrer nicht vergessen.
In unserer Kick-Off-Veranstaltung findet die Vergabe der Ent-
wicklerschlUssel und der individuellen Passworte fUr das Netz
statt.
Das erste Logon in das SAP-System sowie der Browserstart mit
dem CBT erfolgen in einer Demo Uber Beamer. Hier wird Nach-
ahmung im Teilnehmerkreis angeregt und die Tutoren helfen bei
Anfangsschwierigkeiten. Die Vorstellung der zu lbsenden Aufga-
be, sowie eine Demonstration einer beispielhaften Aufgabenlb-
sung gehbrt ebenfalls dazu, obwohl dies natiirlich auch im CBT
selbst unter EinfUhrung als Videoclip zu finden ware. Die Benut-
zung der unterschiedlichen Medien des CBT werden eingeUbt.
Danach Shutdown der Maschine und erneuter Start, diesmal oh-
ne Betreuung. Die Exploration des CBT durch den Teilnehmer
unter Tutorenanleitung bildet den Abschluss der betreuten Ein-
heit.
Erklarungen zu den organisatorischen Fragestellungen wie: wb-
chentliche Sprechstunden, Laborbffnungszeiten, Laufzeit (in der
Regel 8 Wochen) und Abnahmetermin schliefSen das auf 90 min
terminierte Kickoff-Meeting abo Danach ist das freie CB-Training
erbffnet.

7 Abnahme der Gesamtlosung

In der Abnahmeveranstaltung wird zunachst die Funktionalitat
der individuellen Aufgabenlbsung Uberpriift. Tauchen bereits
hier Fehler Cfehlerhafte Programmreaktionen) auf, so wird ein
Nachbesserungszeitraum vereinbart, nach dem eine erneute
Funktionalitatspriifung erfolgt. 1st auch hier das Ergebnis fehler-
haft, so wird die Prufung abgebrochen .
In allen anderen Fallen erhalt der Kandidat eine Zusatzaufgabe,
die vor Ort am System zu Ibsen ist und in der Regel einen Ar-
beitsumfang von 1-2 h umfasst. 1st auch diese Aufgabe fehlerfrei
gelbst, so erhalt er das ABAP/ 4-Zertifikat der Hochschule.

184
 Reinhard Mayr

8 Konventioneller Kurs versus CBT-Kurs

Der CBT-Kurs "ABAP/ 4-Basis" hat inzwischen vier mal stattge-
funden, insgesamt haben ca. 20 Personen die Abnahme ge-
schafft. Acht Personen schlossen auch den weiterfUhrenden CBT-
Kurs "ABAP/ 4-Advanced" erfolgreich abo Die Erfolgsquote der
CBT-Kurse ist insgesamt etwas niedriger als bei den konventio-
nell betreuten Veranstaltungen . Nur etwa 40-60% der Starter
durchlaufen auch eine erfolgreiche Abnahme. Dies ist im Ver-
gleich zu 80-95% bei einem konventionellen Kurs relativ niedrig.
Die Befragung der Abbrecher ergab im wesentlichen folgende
Erkenntnis:
ohne feste Kurszeiten existiert zu wenig Leistungsdruck,
ohne Termindruck nicht genugend Eigenmotivation den
Kurs durchzuhalten,
Leistungsanforderungen zu hoch,
zu geringe Grundkenntnisse,
Aufgaben nicht hinreichend erkEirt.
Insbesondere die drei letztgenannten Punkte kbnnen auch bei
der konventionellen Veranstaltung auftreten, wobei hier die
Chance besteht, durch entsprechende Tutorenanleitung Ver-
standnisschwierigkeiten zu Uberwinden. Eine mogliche Erklarung
dafUr, warum ein konventioneller Kurs eine hohere Erfolgsquote
hat, ist die Tatsache, dass auch noch der Schwachste durch
Betreuung zum Ziel gefuhrt wird.
Betrachtet man den wirtschaftlichen Aspekt der beiden Kursar-
ten , so stehen sich zwei Kostenblocke gegenuber:
Kosten fUr Erstellung, Test, QS des CBT und Kursdurch-
fUhrung CBT
Kosten konventionelle Schulung.
Vergleicht man die aufgewendeten Zeiten zur Bereitstellung des
CBT (fur ein bereits existierendes LehrkonzeptO, so sind etwa
1000-2000 Mh fur die multimediale Aufbereitung in Anrechnung
zu bringen, je nach Intensitat des Medieneinsatzes und Aufwan-
digkeit der HTML-Darstellung. Die Kick-Off-Veranstaltung und
die CBT-Betreuung erfordern nur ca. 15 Mh unabhangig von der
Teilnehmerzahl. Sie sind also zu vernachEissigen.
Ein konventioneller Kurs mit 15 Teilnehmern bindet ca. 250 Mh
in der Betreuung, d.h. rein wirtschaftlich gesehen muss der CBT-

185
CBT-Kurse in der ABAPl4-Programmierung

Kurs 4-8 mal abgehalten werden, damit der Aufwand einen Sinn
macht. Fur uns in der Hochschule ist diese Frage jedoch irrele-
vant, da die Ausarbeitung der CBT's in der Regel uber mehrere
Diplomarbeiten oder Projekte erstellt wird und die Kapazitat der
Assistenten und Tutoren meist schon durch die DV-Standard-
kurse CMS-Office, C, FoxPro, etc.) verbraucht ist. Unsere Alterna-
tiven sind daher klar und eindeutig:
entweder CBT's oder
kein zusatzliches Lehrangebot fUr die Studierenden.
Dber die geringere Erfolgsquote haben wir uns Gedanken ge-
macht. Es ist nach den bisherigen Erfahrungen nicht empfeh-
lenswert, einen CBT-Kurs ohne jegliche Betreuung ablaufen zu
lassen. Durch ein straffes organisatorisches Konzept konnen die
folgenden Hauptpunkte , die zu einem Kursabbruch fuhren, ver-
mieden werden:
Dberprufung der Eingangsvoraussetzungen in einem
Test,
klarer Endtermin mit Abnahme und Zertifizierung,
wochentliche Leistungsvorgabe CHausaufgaben),
wochentliche Dberprufung der Leistungsvorgabe,
wochentliche Sprechstunde (Wochenmitte).
Betrachtet man die zusatzlichen zeitlichen Aufwendungen fur die
obigen MaBnahmen, die mit ca. 20-30 Mh tiber die Kurslaufzeit
zu Buche schlagen, so erhoht sich der Gesamtaufwand fur einen
CBT-Kurs auf max. 50 Mh. Dieser Aufwand ist aber noch immer
vergleichsweise gering gegentiber 250 Mh in der konventionellen
Lehrveranstaltung. Es zeigt sich, dass mit dieser Organisation
zwar nicht aile Kosten vermieden werden konnen, aber mogli-
cherweise rtickt die CBT- Erfolgsquote in die Nahe der Quote ei-
ner konventionellen Schulung. Ob dies den gewtinschten Erfolg
beschert, befindet sich derzeit noch in der Erprobung.

9 Fazit
Die Anwendung von CBT's in der Ausbildung spart enorme Per-
sonal-Ressourcen ein und eroffnet neue Ausbildungsbereiche,
die unter normalen Gegebenheiten nicht anbietbar waren. Auch
die Verbreitung der Kursangebote uber das deutsche Hochschul-
netz ist erklartes Zie!, damit sich der Aufwand entsprechend
rechnet. Langfristig soli auch die Industrie partizipieren konnen.

186
 Reinhard Mayr

Trotz der zunachst bescheidenen Lernerfolgsquote ist der Autor

der Ansicht, dass es zu CBT's in der Hochschule und auch in der
Industrie auf lange Sicht keine wirtschaftliche Alternative gibt, da
die Ausbildungskosten bei der konventionellen externen oder in-
ternen Weiterbildung zu hoch sind. Dies deckt sich im ubrigen
auch mit einer Marktuntersuchung der IDC (International Data
Corporation) / 4/ . In Zukunft wird ein GroBteil der Ausbildung
in US-Unternehmen uber CBT's stattfinden, urn den Kostenblock
in der Aus- und Weiterbildung zu minimieren. Entsprechend fin-
det man heute im Internet kommerzielle CBT's uber interessante
Themen fast ausschlieBlich von US-Firmen, zum Teil zu horren-
den Preisen.
CBT-Kurse geharen heute in Industrie, Handel, Banken und Ver-
sicherungen, insbesondere bei groBen Unternehmen, zu den
Standardmethoden in der Ausbildung (o.v. 2001). Die Befragung
der "e-Iearner" in der Stu die von Prof. HarhofflUniversitat Mun-
chen hinsichtlich des CBT-Lernerfolges ergab ein indifferentes
Bild: ]eweils ein Drittel war mit der CBT-Methode zufrieden, un-
zufrieden oder ohne Begeisterung; anders ausgedruckt, 66% der
Teilnehmer kamen mit dem Medium nicht zurecht. Das ist im Er-
gebnis noch schlechter als es die Resultate in unseren Hoch-
schulkursen ausweisen. Das bestatigt aus meiner Sicht zweierlei:
Zum einen sind wahrscheinlich die didaktischen Konzepte noch
immer mangelhaft und zum anderen ist der "Unterhaltungswert"
der CBT's fUr den Anwender nicht groB genug, urn konsequent
zu trainieren (man muss mit SpaB lernen kannen) . Ruckfragen
bei Kainer Versicherungen ergaben, dass auch sie zwischenzeit-
lich von reinen CBT's absehen und mehr und mehr auf "Trainer
Guided CBT" , also auf CBT mit Betreuung setzen .
Problem hiiufi- Problema tisch bei CBT's fUr Anwendungssysteme im Computer-
ger Release- bereich sind die haufigen Releasewechsel auch bezuglich der
wechsel Benutzeroberflachen (SAPGUI 4.5 zu 4.6, etc.). Damit wird ins-
besondere bei den Screen videos jedes Mal eine neue Aufzeich-
nung erforderlich und auch die Screenshots mussen zum Tei! er-
setzt werden, d.h. zu den hohen Erstellungskosten kommen
auch noch hohe Wartungskosten.
Da dies aber die einzige Chance in der Hochschule ist, das Lehr-
angebot urn attraktive Lehrinhalte zu erweitern, werden wir das
Thema weiter forcieren. Geplant sind fUr 2002 weitere CBT's aus
dem Computerbereich, z.B. fur ,Java/ BAPI", "Linux-Client" und
"Linux-Server". Wenn Sie wollen , schauen Sie doch mal vorbei
unter www .s-ak.fl1-koeln.de . dort finden sie diverse Demo-CBT's.

187
CBT-Kurse in der ABAPl4-Programmierung

10 Literatur
DORR, A. E1' AL.: HTML-basierte Lernumgebung ABAPI4, Projektdo-
kumentation, FH K61n, Fachbereich Produktionstechnik 2001
O. v.: CBT-Lernen ohne Lehrer?, Internetartikel
www.informationweek.de.Ausgabe24.11. Nov. 1999
o. v.: e-Iearning in der Weiterbildung - ein Benchmarking deut-
scher Unternehmen, Kurz!assung einer Stu die unter Leitung
von Prof Harho.f!IUniversitiit Munchen, Internet www.inno-
tee. de, Stand 27.06.2001
SCHUL'vlEIS1'ER, R.: Grundlagen hypermedialer Lernsysteme, Tbeo-
rie-Didaktik-Design, 2.Aufiage, Oldenbourg Verlag 1997
SCHULTE, H.: Entwicklung eines Lehrkonzeptes zur dynamischen
Programmierung unter ABAPI4, Diplomarbeit 1998

188
 Ursula Graf, Albert Hesmer und Dieter LUnebach

e-Learning mit dem SAP - iTutor

=========================
Ursula Graf , Albert Hesmer und Dieter Lunebach

1 Einleitung

1.1 ML Consulting GmbH

Die ML Gruppe ist eine DV-Unternehmensberatung und umfasst
funf operative Gesellschaften mit Hauptsitz in Koln , Niederlas-
sungen in Berlin, Munchen und Sofia.

Funt Unternehmen - ein Gedanke

Planmg Real ls<tlon Service LOsung

ML
ged.rl..",ItS .. ~ndef)- IT 8i Id<rlIP' EfflZ.ftnz
Konzeption . spozi6s<>~. koozepl iteigerung diS
PrQil:e5soptQIIC:- IT Tr.inino. Plod..J<lions:
rung In d!, IT ouall6%fe rung Dd(umentation t.!Mors
QUoiIM~'ilung "U~n;.oh"
C nwlting

ML
Techoologie Eo Qj$iness Betreuung und SldI,,"ellung
I>o .. ~ng und Projtklo fij I Wirtereti tn.llkt
kon:npllon von Industrte, widc:lmgltwer oritnhrter
Ind"""eJ en H.tnde:lund DV systotM DV AbIa",.
~enckJnoefi Dlen.tle~tunQ
i s)' II.' I11'

~
9!ts1..... und In<lilld~11 ~treuun(l Elnslllzl>erd.
NeboNer\c konzipkuh Ihllr Syslom. u"d
l>o~rl"nJtvs . Systtm. und IT.Umgobung Nottnotk.,
Beraung und r~<toJo..ke Tdg \;I"Id Nu:ht
Pllnung

ML
BlI"n~'s
BUSlness- &
Plcrz~sber.1\Jng
Korullpt von
Kornpl~ &
Implemenl.tion
von L<:i!g. fij,
lDljlStk.Auto
motvt. Chetnte
Bttrtuung&
Wonero_lg.
Ihr.r BuslMSS
LOsG &Pt<>
BU$in!S!
P.irtnel fij, Jilt!
Pt(lZt$se 11','6
Urt~rl"l4!h.rnens
BrAncf'l~nM5$O. &PubUcSoctor zesse
" lluliu ,

ML
Pc nal
Plofild""nltlon
,on
Org.mr.ltJon.n
und
Ind~iduollo
Pflr$on .. ~ ul')(!
O'Q.lnknons~
IntHid.:Jun;
PelS(lnlt$od'lii!:
PrQZ"iSS'
CO.lcl'wng.
Manogemon\-
IAoIMelte
tArt.bt., ood
tu,,,fl&)clble
OrganlS .. IIDn
Mftarbell:P:rn re:\ti5MS
C, n\ult.II1I'

Abbildung 86: ML Consulting GmbH

189
e-Learning mit dem SAP - iTutor

Dber 160 hochqualifizierte Mitarbeiter sowie Partnerschaften mit

marktfUhrende Unternehmen (SAP, HP, Cisco, Optical Access,
Microsoft) stellen den selbst aufgelegten hohen Qualititsstandard
sicher. Zahlreiche Kunden in unterschiedlichen Branchen (Logis-
tik , Chemie, Telco, Public Sektor, Consumer Produkte, Industrie,
Automotive) profitierten nachweislich vom hohen Abdeckungs-
grad der IT-Services . Innerhalb dieser Gruppe sieht sich die 1989
gegrundete ML Consulting GmbH als Anbieter von Komplett-
losungen im IT-Bildungsbereich. Das detaillierte Leistungsgebot
der jeweiligen Gesellschaft ist der Internetprasenz
http://www.mlconsulting.de zu entnehmen.

1.2 1st-Situation und Ausblick

Der Schwerpunkt des Unternehmensbereichs SAP liegt in der
Qualifizierung und Betreuung unserer Kunden bei der Einfuh-
rung bzw. Migration der Software SAP R/ 3.
In der Vergangenheit wurden die Schulungskonzeptionen,-doku-
mentationen sowie die DurchfUhrung der prozessorientierten
Schulungen durch die ML Consulting GmbH auf den kundenei-
genen Systemen durchgefUhrt. Es handelte sich hierbei aus-
schliefSlich um Prasenzschulungen .
Systemkenntnis- Da die Anwender zum Zeitpunkt der EinfUhrung einer neuen
se und Akzep- Software nicht uber die erforderlichen Systemkenntnisse verfil-
tanz aujbauen gen, ist es wichtig, zum einen diese Fahigkeiten zu vermitteln ,
zum andern aber auch die Akzeptanz der IT-Anwendung zu er-
hohen. In der Praxis ist es haufig der Fall, dass sich nicht nur der
technische Ablauf eines Arbeitsprozesses andert, sondern auch
neue Aufgaben hinzu kommen. Die Angst vor technischen Neue-
rungen, die Sorge um den Arbeitsplatz und nicht zuletzt der
Wegfall von Arbeitsplatzen schaffen ein negatives Klima, dem
unsere Berater entgegenwirken mussen. Durch die fachspezifi-
sche Ausbildung sowie didaktisch-padagogisches Geschick wer-
den diese Angste abgebaut.
e-Learning als Eine neue Herausforderung stellt fUr uns die Durchfuhrung der
Herausforde- Qualifizierung unter Einbeziehung elektronischer Tools dar. Aile
rung reden uber e-Learning, nur wie wird es eingesetzt, wie andert
sich dadurch eine Schulungskonzeption?
Nach ausfUhrlichen Untersuchungen war klar, dass es nicht die
eine Losung gibt, sondern mehrere, die genau auf die Bedurfnis-
se des Kunden zugeschnitten sind. Dies bedeutet, dass wir bei
allen Projekten prufen, inwieweit die Kosten durch den Einsatz

190
 Ursula Graf, Albert Hesmer und Dieter Liinebach

von e-Learning minimiert werden kbnnen und welche Voraus-

setzungen kundenseitig vorliegen.
Priisenzschu- In dem nachfolgend dargestellten Praxisbeispiel wird deutlich,
lungen unver- dass wir nicht auf Prasenzschulungen verzichten kbnnen und
zichtbar wollen. Da bei unseren Kunden die Software SAP R/ 3 eingeftihrt
wurde, nutzten wir fUr di~ e-Learning-Komponente den iTutor.
Bereits in der Grundschulung wurden die Teilnehmer mit e-
Learning vertraut gemacht, urn die Nachbereitung damit durchzu-
fuhren. Die Vorbereitung auf die vertiefenden Schulungen erfolg-
te auf die gleiche Weise. Somit konnte der Wissenstransfer zeit-
nah erfolgen.

1.3. Was ist e-Learning?

Beim e-Learning handelt es sich urn eine elektronisch gestutzte
Lernform. Die Anwender erhalten die Lerninhalte z.B. tiber das
Internet zur Verfugung gestellt und kbnnen zudem die elektroni-
schen Dienste wie E-Mail, Chat und Diskussionsforen zum Aus-
tausch von Fragen und Erfahrungen mit anderen Teilnehmern
nutzen.
Vorteile des e- Das Internet kennt keine Btirozeiten, es ist 24 Stunden
Learning am Tag erreichbar.
Der Anwender wird erreicht, wenn er bereit ist, zu ler-
nen.
Die laufenden Kosten sind relativ gering. (Keine Reise-
kosten, Miete fur Schulungsraum, Dozenten etc.)
Die Anwender erhalten Information, Lernmaterial etc.
aktuell und schnell.
Die elektronischen Medien, wie Internet und/oder CD,
lassen eine Vielzahl von Visualisierungsmbglichkeiten
zu . (Programme, Bilder, Ton, Video, Application Sha-
ring).
Nachteile des e- Erforderliche Hardware- und Softwareausstattung, insbe-
Learning sondere bei einer Nutzung des e-Learnings vom Wohn-
ort der Anwender aus.
Wenn mit Visualisierungsmaterial gearbeitet wird, ist ei-
ne entsprechende schnelle Verbindung zwischen Server
und Client erforderlich. Ansonsten ist die Auswahl des
Visualisierungsmaterials eingeschrankt.
Technisches Verstandnis der Teilnehmer erforderlich.

191
e-Learning mit dem SAP - iTutor

2 EinfOhrung in die Thematik

Als Schwerpunkt wird nachfolgend der Einsatz von e-Learning
bei einem mittelstandigen Unternehmen, mit Nutzung des SAP-
Tools iTutor als Moglichkeit fUr die interaktive Simulation von
Bildschirmablaufen vorgestellt. Es wurde die SAP - iTutor Versi-
on 6100.131.0.406 verwendet.

2.1 Szenario
2.1.1 Unternehmen
Das Unternehmen ist einer der fUhrenden Anbieter von Dienst-
leistungen in seiner Branche. Das umfangreiche Angebot des Un-
ternehmens wird erganzt durch die Beratung bei der EinfUhrung
von entsprechenden Managementsystemen. Es werden For-
schungsprojekte durchgefuhrt sowie Seminare zu den fachlichen
Schwerpunktthemen angeboten . Das Dienstleistungsspektrum
wird kontinuierlich erweitert.
Nahezu 200.000 Unternehmen und Behorden mit uber 3 Millio-
nen Beschaftigten werden betreut. Die Dienstleistungen werden
in AuBenstellen bundesweit angeboten und durchgefuhrt.

2.1.2 Anwender
Das Unternehmen beschaftigt fUr seine AuftragserfUliung ca. 2000
hoch qualifizierte Mitarbeiter. In der Anwendung von IT-
Systemen ist der Mitarbeiterkreis recht heterogen.

2.1.3 Anforderung an die Schulungskonzeption

Die Mitarbeiter sollen - aufgrund ihres hohen Arbeitsaufkom-
mens - hochstens 2 Tage an Prasenzschulungen teilnehmen.
Durch die hohe Zahl der Mitarbeiter fanden die Schulungen rol-
lierend statt, daher wurde bereits einige Zeit vor der Einfuhrung
des SAP Rl3-System ein Tag Grundschulung am SAP R/ 3-System
durchgefUhrt. Fur die einzelnen Zielgruppen im Unternehmen
soli kurz vor "Go-live" der zweite Schulungstag in einer vertie-
fenden Schulung stattfinden .
Die Zeit zwischen der Grundschulung und der zielbezogenen
Schulung ist mit unterstutzenden Selbstlerneinheiten zu fUllen.
Hier ist die Vor- und Nachbereitung und damit eine Vertiefung
def grund- und zielbezogenen Ausbildung vOfgesehen.

192
 Ursula Graf, Albert Hesmer und Dieter Liinebach

Grundschulung Grund chulung Zielbezogene Zielbezogene Ziclbezogcnc

Ausbildung Au bildung Au bildung
al Nacilbereilllllg Vorbereilllllg Nachbereilllllg
al al al als
Prasenz chulung e-Lcarning e-Learning Priisenzschulung e-Learning

Abbildung 87: Vorgesehene Schulungskonzeption

2.1.4 Losungsansatz
Die Vor- und Nachbereitung uber zu verteilende Skripts wurden
im wesentlichen aus den folgenden Grunden ausgeschlossen:
Hohe Mitarbeiterzahl und deren bundesweiten Augen-
stell en, welches zu einem verhaltnismagig hohen Logis-
tikaufwand (Erstellungskosten, Distributionskosten etc.)
fUhrt.
Mangelnde Aktualitat der erstellten Dokumentationen.
Prognostizierte, nicht Erfolg versprechende Lernergeb-
nisse.
Web-Site Da aile Augenstellen tiber einen Internetzugang verfUgen, wurde
e-Learning vorgeschlagen, die Vor- und Nachbereitung tiber das Internet
anzubieten. Hierzu wurde dann - individuell fur das Unterneh-
men - eine "Web-Site" e-Learning erstellt.
Es wurde davon ausgegangen, dass tiber das Medium In-
ternet eine hbhere Lernbereitschaft besteht.
Mit vergleichbar geringem Aufwand kbnnen die Lernin-
halte jederzeit aktualisiert werden.
Visualisierung von Sachverhalten
Direktes Feedback durch Tests nach den einzelnen
Lerneinheiten .
Diskussionsforum zum Austausch von Wissen (Know-
ledge-Management)
Insbesondere interaktive Simulation von Bildschirmarbeiten las-
sen, aufgrund der Annahmen uber die Wirkung von Sinnes-
modalitaten und Lernaktivitaten, auf das Behalten einen best-
mbglichen Lernerfolg erwarten CAbbildung 88).

193
 e-Learning mit dem SAP - iTutor

Tu n

Nacherzahlen

Lesen und Horen

c-Lc'lrn ing mil AP -iTul or
ermoglicht nicht nur Le-
Sehen sen unci Schen, sondern
allch die DlIrchflihrung.
Horen

Lesen

0% 20% 40% 60% 80% 100%

Abbildung 88: Annahmen tiber die Wirkung von Sinnesmodalita-
ten und Lemaktivitaten auf das Behalten nach Wei-
denmann

Die einzelnen Lektionen wurden so aufgebaut, dass diese in ca.

15 Minuten zu bearbeiten sind. So ist eine langere Sitzung nicht
erforderlich, welches die Motivation zum Lemen verstarken wird.

Abbildung 89: Auswahl einzelner Lektionen

Zugang Jeder Anwender bekam ein eigenen Zugang, der aus Benutzer-
name + Kennwort bestand (Abbildung 90).

194
 Ursula GraJ, Albert Hesmer und Dieter Lunebach

, " , .'

Bltte melden Sle slch mit der Ihnen lur VerfUgung gestellten Kombln~tjon ous 8enutlerkennung und Kennwort lin:

I
Benutzerkennung: Imllel

Kennwort: I....e!
Anmelden

Abbildung 90: Login

2.2 e-Learning-Gestaltung
2.2.1 Aufbereitung in Textform
In den Prasenzschulungen wurden Dokumentationen (Skripts)
verteilt. Die Lerninhalte in diesen Dokumentation wurden fUr das
e-Learning ins HTML- bzw. "Flash"-Format aufbereitet (Abbildung
91).

Urn Sich bei SAP R/3 anzurnelden, brauchen Sle:

Eine Mandantennummer

Einen Benutzernamen

Ein erstes Kennwort (Initialkennwort)

I hr pers()nli ches Kennwort (dies werden Sie nachher anleQen)

Einen Sprachschl(lssel (EN fur Enghsch, DE fur Deutsch)

Hin\ll2~:
F,.agQn SIQ Ih"Qn Sy-stQmAdmlnl$tr'.ator n.illch dlir Mand ... ntlinnumm~'1 dlim Blfiiln'Jt::ernoimen un d dem erst"iil:n Keonwort.

Abbildung 91: Aufbereitung in HTML-Format/Flash-Format

2.2.2 Visualisierung von Sachverhalten

Zusatzlich zur Aufbereitung der Texte wurden Sachverhalte visu-
alisiert, urn den Lernerfolg zu steigern CAbbiidung 92).

195
e-Learning mit dem SAP - iTutor

fur diJi. Abmcldcn ..u~ den SAP P..13 S'fsoom Jitohon rr hr ra tlbollChke lten lur V .. rfuQunQ
wahlen Sia System- alJs der wenuleisre und dann '"'AbrreldAn'" iUS dam M AU

Klicken 5,1 auf das Symbol 0 n der S,,"stemiunkoonsleiste odor

1Clid-en SI auf das WmdOl#ll's ~S\lmbol''S(hhQ1on'' recht'S obon "da!" r"'e u t?i"lte:

B.oIor diS letzte SAP Fenster oe!chlossln wl'd~ w rd die naehstlhenc:e \Yarn melduno angezetQt

In dl8sem AbTl@lde-l=enster klicksn SIB auf "'Ja",

Oaraut n w,"d das SAP R/3 Sys ~m 08schlDiSE!n, nd ~ Ie kehren ZU Windows

lUroO'

Abbildung 92: Visualisierung von Sachverhalten ( SAP AG)

2.2.3 Permanentes Feedback durch Tests

Nach den einzelnen Lektionen wurde den Teilnehmern ein Test
angeboten. Dieser Test ermoglicht dem Anwender ein perma-
nentes Feedback zu seinem Wissensstand.
Nach der Fragestellung und deren Beantwortung wird dem An-
wender die Lbsung angezeigt (Abbildung 93).

l.OuIg,.h)l1 ... 1
....... $AI til ay.- ,... ....,

~tAl'lOGOII4"'"
t,......l.,.-,~
..... 0nI0t0II, ~ ........
.
../ ~ .tAOG~.,.....
s~~ ....
a. "''''~D''''..,.ri
~
......... 10

II taI"~5Ni1t"~'" ltW1M.1IIUIgIft 1II __ 00s.c:t... ~IW,~ ..IWIIEfiII,.l "'~

II ',....~...~... l WMau 1 1J ~""balrl.UJ>Il'*I_!IIrI
' ......

.10._ H: _ ___ ___.. ~

~.
" 1
1M;

Abbildung 93: Fragestellung und Lbsung ( SAP AG)

196
 Ursula Graf, Albert Hesmer und Dieter Lunebach

Fur jede richtige Antwort erhalt der Anwender 2 Punkte, fUr fal-
sche Antworten werden 2 Punkte abgezogen.
Dann wird die nachste Frage zur Beantwortung angezeigt
(Abbildung 93).
Teilnehmer- Am Ende des Tests wird das erzielte Gesamtergebnis angezeigt.
Empfehlung Dazu erhalt der Anwender eine Empfehlung, ob er den Lernin-
halt erneut bearbeiten so lite oder ob er zum nachsten Kapitel
fortschreiten kann (Abbildung 94).

Ihr Ergebnls de. SAP E-Leamlng-Te.ts laylet

Anzahl dcr Fregcn: 7

mroCimAkI PunklZllh~ 58

tirrtiidllu PunklLahi.
Differe", 18
40 ~
Ergebn,. In P"""nl: sa %

w1ederhole

Abbildung 94: Gesamtergebnis des Tests ( SAP AG)

2.2.4 Hilfefunktion bei der tag lichen Arbeit

Dem SAP-Anwender steht als Hilfefunktion das Glossar, die SAP-
Bibliothek bzw. die Hilfe zur Anwendung zur VerfUgung.
Mit dem e-Learning steht dem Anwender daruber hinaus eine
weitere, fur seinen Arbeitsplatz zielorientierte Hilfe zur VerfU-
gung. Zu der M6glichkeit, der Textbezogenen Hilfe, kann der
Anwender sich die einzelnen Arbeitsschritte uber den im nachs-
ten Abschnitt vorgestellten iTutor zeigen lassen.

2.3 Interaktive Simulation von Bildschirmablaufen

2.3.1 Der SAPiTutor
Fur die interaktive Simulation von Bildschirmablaufen des SAP
R/ 3 - Systems wurde das SAP-Tool iTutorverwendet.

197
e-Learning mit dem SAP - iTutor

Der iTutor ist ein Werkzeug zum Aufzeichnen, Bearbeiten und

Abspielen von interaktiven Selbstlemeinheiten. Bei den mit dem
iTutor erstellten simulierten Arbeitsablaufen hat der Benutzer die
Mbglichkeit, durch Selbsteingaben das SAP R/ 3 - System kennen
zu lemen. Auf Wunsch wird der Anwender dabei durch eine a-
nimierte Figur (Agenten) und Sprachausgabe unterstutzt.
Eine Installation des SAP Rl3-Systems ist dabei nicht erforderlich.
Der Anwender hat somit die Mbglichkeit, die Bedienung des SAP
R/3 - Systems bereits vor der Installation kennen zu lernen.
Der Zeitpunkt und die Intensitat des Lernens bestimmt der An-
wender selbst. Die Mbglichkeit, den iTutor nach seinen persbnli-
chen Bedurfnissen einzusetzen , ist eine wesentliche GrbBe fUr
den optimalen Lernerfolg.
Der iTutor wird mit den Microsoft Betriebssystemen verwendet
und besteht aus 3 Komponenten: Recorder, Editor und Player.
Recorder Mit dem Recorder werden die einzelne Arbeitsschritte im System
aufgezeichnet. Pro Interaktion werden zwei Bildschirmabgriffe
aufgezeichnet, einer zeigt den Bildschirm vor, der andere nach
der Interaktion an . Diese Aufzeichnung ist das Basis-Material fUr
die weitere Bearbeitung.
Editor Mit dem Editor werden die mit dem Recorder aufgenommenen
Arbeitsschritte weiter bearbeitet. Zu den hinzugefUgten interakti-
yen Aktionsfelder kbnnen aufgezeichnete Arbeitsschritte ge-
lbscht, erganzt, gedruckt oder exportiert werden .
Player Mit dem Player werden die mit dem Recorder aufgenommenen
und dem Editor bearbeiteten Arbeitsschritte abgespielt. Es ist
nicht notwendig, dass die entsprechende Anwendung installiert
ist. Die vorgegebenen Arbeitsschritte der zu erlernenden SAP -
Transaktion wird durch den Anwender ausgefuhrt. Nach korrek-
ter Ausubung der Interaktion wird der nachste Bildschirmabgriff
angezeigt, dies vermittelt dem Anwender das GefUhl, er bewege
sich in dem SAP R/3-System.
Mit dem Player erhalt der Anwender auch die Mbglichkeit, das
Tutorial zu drucken.

2.3.2 Hinweise
Fur die Erstellung der Tutorials werden aile drei Komponenten
des iTutor benbtigt. Fur den Anwender genugt hingegen der
Player.

198
 Ursula Graf, Albert Hesmer und Dieter Liinebach

Um ein reibungsloses Abspielen der Tutorials zu gewahrleisten,

sollte der Microsoft Internet Explorer benutzt werden. Erfolgt ein
Download der Tutorials aus dem Internet, werden diese Dateien
uber den iTutor-Player per Streaming abgespielt.

2.4 Praktische EinfUhrung in den iTutor

2.4.1 Aufzeichnung
2.4.1.1 Vorbereitung der Aufzeichnung
Bevor die Aufzeichnung durchgefiihrt wird, mussen einige Vor-
bereitungen getroffen werden.
Man muss wissen, welche Anwendungen fUr den aufzuzeich-
nenden Ablauf benbtigt oder auch automatisch gebffnet werden.
(z.B. Es wird die Druckausgabe eines SAP-Inhaltes in Microsoft -
Word aufgezeichnet, wobei Microsoft - Word automatisch star-
tet.)

2.4.1.2 Durchfuhrung der Aufzeichnung

Alle Anwendungen, die zur Aufzeichnung benbtigt werden, sind
manuell zu starten. Der Recorder wird gestartet und alle gebffne-
ten Anwendungen werden im Fenster Laufende Anwendungen
angezeigt. Alle Anwendungen, die zur Aufzeichnung benbtigt
werden, sind im Fenster Aufzuzeichnende Anwendungen zu u-
bernehmen. Es ist darauf zu achten, dass aile die Anwendungen
ubernommen werden, die bei den aufzuzeichnenden Anwen-
dungen benbtigt werden.
E-. SAJlITutot Recorder :~~

c_
(;I 4.t_t..4uII\.a.r.gn.."JI

:- [10 5........

Abbildung 95 : Auswahl benbtigter Anwendungen ( SAP AG)

Bei der dann folgenden Aufzeichnung ist zu beachten, dass die

Datenmenge der Datei recht klein zu halten ist (max. 500 KB).
Die Datenmenge kann durch folgende MaBnahmen gering gehal-
ten werden:

199
e-Learning mit dem SAP - iTutor

Die GroBe des jeweiligen Fenster ist moglichst klein zu

halten.
Die Anzahl der aufgezeichneten Schritte ist zu begren-
zen.
Teilung der abspielbaren Dateien (z.B. Erstellung einer
Bestellanforderung - Teil 1, Teil 2, Teil 3 ... ).
Einstellen der Bildschirmauflosung wahrencl der Auf-
zeichnung auf 800 x 600 Pixel.

HINWEIS

Die Benutzung des Agenten bewirkt keine erh6hte Datenmenge

in der Aufzeichnung.

Der iTutor zeichnet nun aile Schritte die durchgefUhrt werclen

auf und fUgt automatisch Texte in einer Sprechblase des Agenten
hinzu. Der Text kann spater im Editor angepasst werden.
Die aufzuzeichnenden Anwendungen reagieren deutlich langsa-
mer als gewohnt (komprimieren und sichern der Bildschirmauf-
zeichnungen). Die Aufzeichnung wird nach allen erforderlichen
durchgefUhrten Schritten beendet unci unter dem zuvor festge-
legten Namen mit der Datenerweiterung ".sim" abgespeichert.
Dieses Format ist bereits optimiert und komprimiert, sodass ein
weiteres Komprimieren (z.B. liber ZIP-Verfahren) keinen nen-
nenswerten Erfolg bringt.

2.4.1.3 Beurteilung
Urn eine moglichst saubere Aufzeichnung zu erstellen, welche
den spateren Editieraufwand gering halt, sollte man zuvor die
aufzuzeichnenden Wege im R/ 3 "live " System durchspielen und
den optimalen Weg sowie Daten fUr die Aufzeichnung festlegen.
Zusatzliche Wege und damit Bildschirmaufzeichnungen erhohen
schnell die Datenmenge, machen aber die Navigation im System
durchsichtiger (verstandlicher). Solche zusatzlichen Schritte kon-
nen bei der spateren Aufbereitung im Editor jederzeit wieder ge-
Ibscht werden, falls Sie fUr die verstandliche Gestaltung der Auf-

200
 Ursula Grai, Albert Hesmer und Dieter Liinebach

zeichnung nicht benotigt werden. Man spart sich so evtl. eine

erneute Aufzeichnung mit den gleichen Daten.

2.4.2 Editieren
2.4.2.1 Vorstellung der einzelnen Fenster

~.d...J~ Der iTutor - Editor arbeitet

Datei Bearb. Blldabgrlff OptloFlen Hfe
mit der Windows Fenstertech-
~III ~
nik. Sie konnen die drei Fens-
ter Regieienster, Auigaben-
AtJg..ben unci ~chriUe Editor und das Auizeich-
de nungifenster gleichzeitig Off-
$ ell neuen F~voltlten anleyen nen und zwischen den Fens-
~ 1. KlICk aoi ''Anlegen''
00 2. K1,=k aU "Fa\IOI~en" tern funktionell springen bzw.
~ 3 KlICk aoi"Hnzufiigen" verschieben.
[!) 4 Wel et
S ell neue TlansaittKln enrligen Nach dem Offnen Ihrer Auf-
[!) 5. Kl'=k aU "Fa\IOI~en" zeichnung sehen Sie im Regie-
~ 6. Klick ad"T r..... aktion einfug
~ 7 [v~2J iller T~st~l... eongebe
fenster die einzelnen Schritte
~ B KI,=k aU 'Weiter" der zuvor aufgezeichneten Ak-
e Favor~en versctleben tionen (Abbildung 96) .
ija
~
9 Klrck aU "VC!$chleben"
10. Kick auf '1Otchen"
AtJgaberolyp

Lege" Sie auf".,rsdli.eu~ Weise Ihre

personliclte" r""",ri1e"IE.l.
Trage.. Si.e allCh ew WEB-Ams als
..... ril eDt.

Abbildung 96: iTutor Regiefenster ( SAP AG)

Vom Regiefenster aus werden alle weiteren Befehle und Funkti-

onen uber das Menu oder entsprechende Icons aufgerufen.
Ebenfalls werden hier allgemeine Einstellungen und Optionen
festgelegt. Durch Anklicken der durchnummerierten Schritte Off-
net sich der jeweilige aufgezeichnete Bildschirmabgriff, auf dem
bereits Interaktionen dargestellt werden (Abbildung 97).

201
e-Learning mit dem SAP - iTutor

SAP Easy Accen

~ ~ .Q~ ""de ~.nO ~

...J 1-:'110 ~r
v ...l S~ '''9nD
t.. -..JOlJIO
~ --l 14~"k
~ ...J R~tM;jn , s..tl;n8n
~ W Ptl'1Onal
~ ~ InfD~'~'cml)
tI ...JWll!lrmuQ8

Abbildung 97: Aufzeichnung ( SAP AG)

Durch Doppelklicken auf einen Schritt in der Schrittaufzahlung

Offnet sich der Aufgaben-Editor (Abbildung 98).

HI.

Abbildung 98: Aufgaben-Editor ( SAP AG)

202
 Ursula GraJ, Albert Hesmer und Dieter Liinebach

Der AuJgaben - Editor ist in drei weitere Reiter unterteilt. Hier

werden die genauen Interaktionen fUr den User uberarbeitet und
festgelegt.

I
Schritt I interaktionsfeld Blase I

Abbildung 99: Reiter ( SAP AG)

Dem Anwender kann hinreichend Unterstutzung geboten wer-

den, indem zu jedem Knoten eine Aufgabenbeschreibung und zu
jedem Schritt eine erlauternde Schrittbeschreibung erstellt wird
Abbildung 100). Diese stehen dem Anwender beim Abspielen
des Tutorials immer zur VerfUgung .

'"
.. . :
Date; ae",b. eddab\lriff Optionen HLlFe

~1iII 1 ~
III r ~I ~!!=!!~S
Aufljaben und Schritte
- j ell D." Bildrumpf
r
=J elB!ll!D
Ii!) 1 . Klicken auf 'Zusatze"
iii 2. Khck aur "EinsteUun"",,"
(j1 3 _ Klicken Sie hler
~ 4 . Klick BUr 'Weite,"
~ 5. Khck !lur "Bulton"
ill
6. K1,ck !luI "Sutton"

Abbildung 100: Aufgaben und Schritte ( SAP AG)

Das Fenster der Aufgaben-/ Schrittbeschreibung Offnet sich und

kann nach bekannter MS-Word-Funktionalitat mit Text bearbeitet
und grafisch aufbereitet werden. Die Aufgaben-/ Schrittbeschrei-
bung kann z.B. den Inhalt der Sprechblase durch weitere techni-
sche und grafische Informationen erganzen (Abbildung 101).

203
e-Learning mit dem SAP - iTutor

Innes New ROlMn

Zur Oberpriifung der "Eingab.zn" khcken s auf "En1u" e

Abbildung 101: Aufgaben-/ Schrittbeschreibung ( SAP AG)

Das Fenster der Aufgaben-/Schrittbeschreibung muss vor der Be-

arbeitung der nachsten Schritte erst geschlossen werden.

2.4.2.2 Aufzeichnung editieren

1m Aufgaben-Editor werden die Interaktionen fur den User bear-
beitet. Es wird festgelegt welche Aktionen auf dem Bildschirm
moglich sind, urn einen weiteren Ablauf in der Aufzeichnung zu
ermoglichen und somit die Dbung nachzuvollziehen. Unter dem
Reiter "Schritt" wird u.a. die Kurzbezeichnung des Schrittes ge-
pflegt (Abbildung 102).

li;I<:k",," _ _ -

Abbildung 102: Schritt ( SAP AG)

204
 Ursula Graj, Albert Hesmer und Dieter Lunebach

Der Button "Bezeichnung" verzweigt in die Schrittbeschreibung.

Hier werden die User - Informationen erstellt. Der "Typ" eines
Schrittes (Klick, Doppelklick, Text erfassen, u.a.) legt die Art der
Interaktion fest, die dem User zur VerfUgung gestellt wird.
Mit den Radio-Buttons "Angezeigter Bildabgriff" legen Sie fest,
welcher Bildschirm dargestellt werden soli:
Aufzeichnung vor der Interaktion und
Aufzeichnung nach der Interaktion.
Von hieraus besteht auch die Moglichkeit die Bildabgriffe zu ex-
portieren, zu importieren bzw. mit einer Bildbearbeitung zu be-
arbeiten.
Unter dem Reiter "lnteraktionsfeld" werden die genauen Interak-
tionsfelder und deren Werte zum zugehorigen Schritt festgelegt
(Abbildung 103).

r
r

Naithtt. Sdvt!
IN"""'I.. Schnll"F~ 3
Ve1<l'i.4)lung

r S_~IE".'
r ,A1IbI_lESel

Abbildung 103: Interaktionsfeld ( SAP AG)

Bei einem Interaktionsfeld vom Typ "Text Erfassung" kann z.B.

ein genau festgelegter Text hinterlegt werden, ohne dessen kor-
rekte Eingabe nicht auf den nachsten Schritt gesprungen wird.
Bei einer Falscheingabe wird vom iTutor-Player eine entspre-
chende Korrekturmeldung ausgegeben.
Die weiteren Felder legen die nachste Schrittfolge und die ge-
wunschte Tastenkombination (TAB, Enter, Funktionstaste, u.a.)

205
e-Learning mit dem SAP - iTutor

fest. Der User muss diese Tasten betatigen urn eine Schrittfolge
auszul6sen. Der Reiter "Blase" wird ben6tigt urn den Text der
Sprechblase fUr den Agenten festzulegen (Abbildung 104). Hier
kann auch die Blasen- und Schriftfarbe gepflegt werden. Die Po-
sition des Agenten wird mit der Maus direkt auf dem eigentli-
chen Aufzeiehnungsfenster positioniert.

""'ken S.. bolo .... 1

Abbildung 104: Blase ( SAP AG)

Die wichtigsten Funktionen der Bearbeitung (kopieren, aus-

schneiden, einfUgen, l6schen, Drag a. Drop, etc.) k6nnen Sie im
"Regiefenster" anwenden urn Ihre Aufzeichnung zu bearbeiten.
Hierbei besteht auch die M6glichkeit Schritte aus- und einzu-
blenden urn diese fUr eine spatere Verwendung bereitzuhalten.
Einzelne Schritte lassen sich auch zu ubergeordneten Aufgaben
zusammenfassen. Dies erm6glicht dem User eine bessere Ein-
sieht in die Dbungen.

206
 Ursula Graf, Albert Hesmer und Dieter Lunebach

m iTutor Editor: 4-1 ~-=.1JJ~

D~ei Bearb. Bldabgriff Optionen Hllfe
----I
~ r;I ...
l; ~'J ~=-== t!f!

neuen Favortiten anlegen

ill. Klick auf "Anlegen"
[J 2. Klick. al.lf "F avoriten"
00 3. Klick auf' Hnzufiigen"
~ 4.Weiter
r= ED neue Transaktion eirfugen
@') 5. Klick auf "Favoriten"
~ 6. Klick auf "T ransaktion einliig
iI 7. [va02] uber Tastatur elngebe
~ 8. Klick auf ' We~er"
- e FIIvoriten verschieben
iI 9. Klick auf "verschieben"
~ 10. Klick auf "Ii:ischen" ~

Aligabentyp
Iv" ~
Aufg.!lbenbeschreibung
Le;e Sie aufverschiedene Weise Dtre
personlichen Favorlten rest.
Tragen Sie auch eOte WEB-Ad.resse a1s
Fawritein.

Abbildung 105: Favoriten pflegen ( SAP AG)

2.4.2.3 Beurteilung
Die Vielzahl der Editiermoglichkeiten erlauben es dem Entwick-
ler eine Aufzeichnung (z.B. eine komplette Transaktion) realis-
tisch nachzubilden.
Bei konsequentem Einsatz aller Moglichkeiten des iTutors erhiiit
man eine Dbung, die dem User eine optimale Umgebung dar-
steHt, ohne sich in einem Live System zu befinden.

207
e-Learning mit dem SAP - iTutor

Der Editieraufwand nach einer Aufzeichnung ist allet'dings nicht

zu unterschatzen, da erst durch die hinzugefUgten Informationen
fUr den User eine Lernumgebung geschaffen wird.

. 2.4.3 Abspielen
Beim e-Learning wurden passend zu den Lerninhalten die Tuto-
rials angeordnet. Zum Abspielen genugt ein Klick auf den Link
dieser Tutorials. (Abbildung 21).
Alternativ k6nnen die Tutorials im Download-Bereich des e-
Learnings aufgerufen werden.

In der nun folgenden

praktischen Ubunq kbnnen Sis
den Anmeldevorgang
nachvollziehen.

Abbildung 106: Link zum einen iTutor-Film ( SAP AG)

Der iTutor-Player wird automatisch gebffnet und die iTutor-Datei
abgespielt. Dber eine Funktionsleiste kann der Anwender das
Tutorial bedienen und individuell einstellen (Abbildung 107).
B ITutorPlayer: http://ell.mlconsultlOg.def elml/ conte.

Abbildung 107: Funktionsleiste ( SAP AG)

2.4.3.1 Demo Modus

Urn einen raschen Dberblick zu gewinnen kann das Tutorial im
Demo Modus abgespielt werden. Es brauchen keine Eingaben
gemacht zu werden . Das Tutorial lauft wie ein Film abo

2.4.3.2 Interaktiv
Urn die Anwendung zu eriernen, sollten die einzelnen Arbeits-
schritte durchgefUhrt werden. Dazu wird das Tutorial mit Interak-
tionen abgespielt. Interaktionsfelder weisen auf Bildschirmberei-
che hin, in dem der Anwender eine Aktion ausfUhren soli (z.B.
Doppelklick, Texteingabe). Wurde eine geforderte Interaktion
korrekt durchgefUhrt, wird dem Anwender der nachste Bild-
schirmabgriff angezeigt. War die Eingabe falsch, wird der An-
wender darauf hingewiesen (Abbildung 108).

208
 Ursula Graj, Albert Hesmer und Dieter Lunebach

CO - - -- - - (;] :l:1'i [-
.E~lIlIt;P ~J'stp'll tliliP

e
SAPR13
---------------- Ii] I[]
'1euss Ke nnwort

Mandant 599
D
Benutzer I!I
Kennwor1

Sprache

Abbildung 108: Fehlermeldung mit Korrekturvorschlag ( SAP

AG)

Neben der Bedienung (6ffnen, drucken etc.) kann der Anwender

selbst bestimmen, ob er einzelne Funktion wie den Agenten
und/oder die Sprachausgabe nutzt; jedoch kann der Agent mit
Sprechblase nur angezeigt werden, wenn der Autor des Tutorials
dies im Editor vorgesehen hat.
Wahrend der Ausfuhrung wird dem Anwender auf der rechten
Seite des Bildschirms die Aufgabenbeschreibung angezeigt. Hier
wird ihm die durchzufUhrende Aufgabe beschrieben .
Als weitere Information werden ihm die einzelnen Schritte, die
im Tutorial durchzufi.ihren sind, angezeigt. Der aktuelle Schritt
wird dabei farblich unterlegt.
Ferner wird jeder einzelne auszufUhrende Schritt in der Schrittbe-
schreibung geschildert (Abbildung 109).

209
e-Learning mit dem SAP - iTutor

rAutgabenbeschreibung
Melden S ie sich bitte bei ...
SAP R/3 an .
DafOr ben6tigen Sie:

I eine Mandantennummer (3-

st ellig)
einen Benutzernamen
ein erst es Kennwort
(In itia l kennwort)
Ihr personliches Kennwort
(dies werden Sie nachher
anlegen)
einen SprachenschlOssel ~

Schritte im Tutorial
1 . Markierung "SAPlogon-pad" ....
2. Aktivierung "SAPlogon-pad'
3. SAP Server starten
4 . Feld Mandant anwiihlen
5 . /l"landant eingeben
6. Benutzernamen eingeben
7. Kennwort eingeben
8. Sprache eingeben
9. Klicken Sie hier
10. Kenn",.oort eingeben
11. Kennwort erneut eingeber~
~ I I ~

Schrittbeschreibung
St&rten Sie das SAP RB
System vom Windows
Desktop, indem Sie auf das
SAPltHIOn-lhld Symbol
klicken.

Abbildung 109: Aufgaben- und Schrittbeschreibung ( SAP AG)

210
 Ursula Graj, Albert Hesmer und Dieter Liinebach

2.4.3.3 Beurteilung
Der iTutor Player ist einfach in der Bedienung und erm6glicht
dem Anwender eine Vielzahl von individuellen Einstellungen. Es
werden die zu erlernenden Prozesse (je nach Komplexitat der
Aufzeichnung) Schritt fUr Schritt angezeigt. Durch die Interaktivi-
tat befindet sich der Anwender nahezu "im Prozess" . Es wird
standig die Aufgabenbeschreibung, die einzelnen Schritte im Tu-
torial und eine ausfUhrliche Einzelschrittbeschreibung als Hilfe
angezeigt. Versucht er interaktive Schritte auszufUhren, die der
Autor nicht vorgesehen hat, bekommt er Hilfe zur korrekte Aus-
fUhrung. Die interaktiven Felder werden (wenn eingestellt) um-
rahmt und der Agent zeigt auf diese Felder, sodass er sich zu-
recht findet. Wird die Dbung mehrmals durchgefuhrt, kann der
Anwender auf diese Hilfen verzichten und wird dadurch mehr
gefordert. Der iTutor-Player ist auch fUr den ungeubten IT-
Anwender problemlos bedienbar.

2.5 Erfahrungsbericht
Bei den SAP R/ 3 - Grundschulungen wurde ca. 1 Stunde flir die
Vorstellung und Bedienung des e-Learning aufgewendet. Bei den
zielbezogenen Prasenzschulungen wurden die Anwender dann
urn ein Feedback zum e-Learning gebeten.
Haufiger wurde das Zeitproblem angesprochen. Die allgemeine
Bereitschaft zum e-Learning wurde bekundet, jedoch aufgrund
des hohen Arbeitsaufkommen konnte eine Vor- und Nachberei-
tung in vielen Fallen nicht erfolgen. Wissensvorsprung hatte der
Personenkreis, der e-Learning auch von zu Hause aus nutzte.
Die Nutzung des Internets verbreitete sich in den letzen Jahren
bzw. Monaten erheblich. Dies machte sich auch bei den Anwen-
dern bemerkbar. Da das e-Learning auf dem Prinzip einer "nor-
malen" Web-Site beruht und die Bedienung weitgehend in stink-
tiv erfolgt, gab es bei der Handhabung erwartungsgemafS wenig
Probleme.

211
e-Learning mit dem SAP - iTutor

I(
d
.ck . ..... .
~,,"'t IU'
, ..,."

O un,dwI."
L,,.1l In de u~. "'. .
.".cHI ....
Klbtft a.. F '9~ ,um .L.elWn."9~
Od e, _ aHl Oo1..merUo' cr.~ ,.,
9"11'I 9'A.. I I 910:.4-. . .K n\lf\~ 04tt lnr..1 ' ''01'11'
01"1'1 ~I ("' . "~ . btt.....+.. ,..." d., U r .. , ...
1(". " .. I iii, W. . .

Die .~tu .. r, n t r-u..,.. .. , ct.", ... """"

", .. " ..... 6'.,. ~ .. IV- " nUl ... ~O!. I,Im 4 .,
"Ofl'lP ~'I'I "~" '9 ;i,I ."ft. ..
T_,- ( 17.0 1 lOU}
ttt,dlt'llr .,'1,4'f ~

Herdid1 wa.ont~ (27.01.2001)

He,;I"" W .....~ "'. I'I ... ~

Abbildung 110: Startseite des e-Learning

Einige Bedienungsprobleme tauchten bei den Anwendern auf,

die bisher keine Erfahrung mit dem Internet hatten.
Da auf den e-Learning-Seiten auch "Flash"-Inhalte verwendet
wurden, musste teilweise eine Browsererweiterung "Flash-Plug-
In" Cauch Flash-Player genannt) in der Version 5 installiert wer-
den. Dies bereitete manchem Anwender Probleme, welche je-
doch relativ leicht mit Hilfe der eingerichteten "Hot-Line" besei-
tigt werden konnten.
Erklarungsbedarf ergab sich, analog zu dem o.a. Personenkreis,
bei der Nutzung des Diskussionsforums. Die Einweisungszeit
blieb jedoch relativ gering. Wahrend der Vorstellung und U-
bungsphase wurde das Diskussionsforum rege genutzt, spater al-
lerdings nur von einem geringen Personenkreis frequentiert.

212
 Ursula Gra!, Albert Hesmer und Dieter Lunebach

Tnns:..l(tlonseode fur die Entellung elner 83nt (ht. r ""'"rt.r 0. 0' 0 2.12 "00- 0')
D.r .nn mi, d~n T, . "" . Io.t.oos-cod. 'lIr dl9 E'fWIVIl9 II! " . , a.of mltt.1"nl
antwortco

Aw: Tr4nsoktionstode fur die Erstellung einer Bonf (AAon'tlTl 01 D ~ .02. 1110 0 112)
Ich lll
"'-~"

Aw: Trdnsaktionscode fur die Erstellung einer Banf (Anon,..,, 08n5.02, 11'1031 16)
De , Tr.)n"u kt lon :l:code I. u~tr M ! 5 U I.

Abbildung 111: Diskussionsforum

Weitaus mehr Probleme hatten die Anwender beim bffnen und

Bedienen des iTutor.
Wahrend des e-Learnings gelangt man durch Links zu den iTu-
tor-Dateien. Wie bereits beschrieben, muss auf dem Client-
Rechner zum Abspielen der Tutorials der iTutor-Player installiert
sein.
Die Installation des Players erfolgte unkompliziert, jedoch lieBen
sich die Tutorials oft nicht abspielen. Zum einen benotigten
manche Rechner einen zusatzlichen Patch zum iTutor-Player.
Dieser wurde dann mittels Download zur VerfUgung gestellt. Die
Probleme waren auf den installierten Browsertyp zuruckzufuh-
reno Die besten Ergebnisse wurden mit dem Microsoft Internet
Explorer ab Version 4.0 erreicht. Andere Browsertypen wie z.B.
der Netscape waren nicht "Streaming-fahig".
Streaming Wahrend die Anwendung auf den Rechner geladen wird, kann
diese bereits abgespielt werden.
Das eigentliche Tutorial wurde relativ positiv bewertet. Als Lern-
und Hilfsmittel sehr fbrderlich, wurde nur die Bedienung kriti-
siert. Der Anwender erwartete volle SAP-Funktionalitat z.B. ver-
suchten manche die SAP -Hilfefunktionen aufzurufen oder den
Windows Desktop zu bedienen. Dies konnte naturlich nicht
funktionieren, da iTutor-Simulationen nach einem festgelegten
Ablauf wiedergegeben werden und nicht das System zur VerfU-
gung gestellt wird.

213
e-Learning mit dem SAP - iTutor

Diese Bedienungsprobleme werden nach kurzer Eingew6h-

nungszeit verschwinden.
Erfolgskritisch ist, dass m6gliche Hardware- und/ oder Software-
probleme durch den im Unternehmen zustandigen Administrator
vor Bereitstellung eines e-Learning-Systems gepri.ift und ggf. be-
seitigt werden. Diese vorbereitenden Aufgaben wirken sich
sonst, insbesondere bei den ungetibten PC-Anwendern, negativ
auf die Akzeptanz aus und gefahrden die Lernbereitschaft oder
sogar die Lernm6glichkeit und damit den globalen Lernerfolg.

2.5 Fazit
Durch die sinnvolle Kombination von herk6mmlichen Prasenz-
schulungen und e-Learning-Komponenten wurde erreicht, dass
die Seminarteilnehmer den Unterrichtsstoff nicht nur einmalig
aufnehmen, sondern den Lehrstoff tiber Simulationen aktiv und
schrittweise nachbereiten konnten. Dies fiihrte zu mehr Sicher-
heit und Akzeptanz am Arbeitsplatz.
Mit der Offnung des Internets zur privaten Nutzung verftigen ei-
ne Vielzahl von Nutzern tiber entsprechende Vorkenntnisse. Die-
se Basis erlaubt in Zukunft einen noch h6heren Anteil der ent-
sprechenden Tools in der IT-Qualifizierung von Mitarbeitern.
In weiteren Projekten werden wir unsere Erfahrungen einbringen
und unsere Konzeption entsprechend weiterentwickeln.

3 Quellenverzeichnis

UN! GIESSEN :
http://www.psychol.unigiesen.de/abteil/paedglo/osinet/paedago
glinstrukt/CUUmultlern.htm
SAP: SAP Online Help, 01/07/20, iTutor 13

214
 Wilhelm Thygs

Instandhaltungsabwicklung mit SAP und erganzender Software

Wilhelm Thygs

1 Das Unternehmen
Sachtleben ist ein fiihrender Hersteller hochwertiger Chemiepro-
dukte mit einer einzigartigen Palette von weilSen Pigmenten und
Fullstoffen. Die Hauptprodukte sind Titandioxid (Ti02) sowie
das Zinksulfid - Pigment ZnS.
Daruber hinaus ist das Unternehmen, dass heute zur mg chemi-
cal group Dynamit Nobel gehort, in den Bereichen Pharma, Ba-
rium- und Feinchemikalien sowie in der Wasserchemie tatig
(http:// www.sachtleben.de). Des weiteren produziert Sachtleben
Schwefelsaure und Eisenerzkonzentrat. Das Unternehmen stellt
mit etwa 1.300 Mitarbeitern mehr als 1 Mio. Tonnen Guter pro
Jahr her. 1m Geschaftsjahr 1999/ 2000 erwirtschaftete es dabei ei-
nen Umsatz von ca. 344 Mio. EURO.
In den vergangenen Jahren wurde die Produktion von Titandi-
oxid auf eine jahrliche Produktion von 100.000 Tonnen gestei-
gert.
Die Firma Sachtleben Chemie ist seit uber 100 Jahren am Duis-
burger Standort tatig (Abbildung 112). Ein grolSer Teil der Anla-
gen stammt aus den 60er Jahren. Eine Herausforderung ist die
kontinuierliche Produktion, d .h. 24 Stunden an 365 Tagen. Hier-
zu ist ein sehr grolSes Wissen "vor Ort" notwendig.

215
Instandhaltungsabwicklung mit SAP und erganzender Software

Abbildung 112: Sachtleben Chemie

2 SC Instandhaltungsorganisation
Die graBen Praduktionsbereiche verfUgen jeweils uber eine ei-
gene Ingenieurgruppe und eine dezentrale mechanische Werk-
statt.
Die dezentralen Ingenieure fuhren die verfahrenstechnischen
Planungen fUr Neu- und Umbauten in ihrem Betrieb durch. Bei
Betriebsstorungen im Tagesgeschaft greifen sie auf die eigenen
Betriebschlossergruppen, bzw. die zentralen Fachgruppen zu-
ruck.
Zentral verfUgen wir ebenfalls uber eine mechanische Werkstatt
mit ent-sprechender Ausstattung (eigene Kunststoff- und Gum-
mierungsgruppe , Dreherei und Pumpenreparatur etc.) sowie
Fachwerkstatten fur Elektra-, Mess- und Regeltechnik und die
notwendigen Baugewerke.
Ferner sind zentrale Ingenieurgruppen fur die Planung der EMR-
und Bautechnik, der Konstruktion, Normung und Betriebsbe-
treuung der Kleinanlagen tatig sowie die Gewerkegruppen vor-
handen, die zum Kerngeschaft notwendig sind. Die zentralen

216
 Wilhelm Tbygs

WerksHitten stellen eine Gruppe von Schichthandwerkern mit

zwei Betriebsschlossern, zwei Elektrikern und einem Mess- und
Regelmechaniker fUr den Schichtdienst an 365 Tagen.
Fur die Bearbeitung aller notwendigen IH-Aufgaben werden ca.
80 eigene Mitarbeiter dezentral und 180 zentrale Mitarbeiter be-
n6tigt. Des weiteren werden zur weiteren Unterstutzung ca.100
bis 150 Fremdmitarbeiter in der Instandhaltung und je nach In-
vestitionsvolumen noch zusatzlich 80 bis 200 Fremdmitarbeiter
eingesetzt. 1m vergangenen Jahr waren es arbeitstaglich ca. 250
Fremdmitarbeiter im Durchschnitt, urn aile notwendigen techni-
schen Aufgaben zu bewaltigen.
Die eigenen Mitarbeiter sind mit der St6rungsbeseitigung der lfd.
Wartung und Inspektion sowie der permanenten Anlagenopti-
mierung beauftragt. Fremdmitarbeiter werden besonders bei Pro-
jekten (Reparatur sowie Investitionen) und bei Spezialreparatu-
ren eingesetzt. Auch ein Teil der regelmafsig durchgefUhrten
Wartung und Inspektion wird durch Fremdfirmen durchgefUhrt.

3 Einsatz von EDV bei SC

Beim Einsatz der heutigen Softwaretools muss man auf die Histo-
rie schauen. Seit April 2001 verfUgt Sachtleben in allen wesentli-
chen Geschaftsprozessen uber die SAP R/ 3Software.
Seit 1998 Ein- In der Instandhaltung wird seit 1998 bereits die R3 Software ver-
satz von SAP wendet, jedoch bis April 2001 noch in einem Koexistenz Szena-
Rl3 in der In- rio zu der SAP - R2 Software im Finanz- und Controllingbereich.
standhaltung Diverse Softwaretools werden heute in Erganzung zu SAP R/3
eingesetzt (Bild 2). Zum einen, weil sie bereits vor der SAP R/ 3
EinfUhrung erfolgreich angewendet wurden und noch keine
Notwendigkeit einer Umstellung bestand, zum anderen, weil es
sich urn eine Spezialsoftware handelt, deren Funktionalitat der-
zeit nicht durch die SAP Standardsoftware im gewunschten Rah-
men abgedeckt werden kann.

217
Instandhaltungsabwicklung mit SAP und ergdnzender Software

IPS
VMIS
Reisekosten
AEB
Assist 4
Barcoding
DTA

Invest-
LlMS Planung

Abbildung 113: Einsatz der EDV bei Sachtleben

4 Auftragsabwicklung der Instandhaltung mit SAP

Die Auftragsbearbeitung von Instandhaltungsauftragen erfolgt
heute mit dem SAP R/ 3(1 Software Modul PM (Plant Maintenance).
Die betrieblichen Anlagen sind entsprechend nach technischen
Platzen und weiteren Systemanforderungen strukturiert.
Auftrage werden an den verschieden Arbeitsplatzen innerhalb
des Werkes, z.B. in den Messwarten erzeugt und direkt in der
zustandigen Werkstatt oder bei der Planungsgruppe ausgedruckt.
Es besteht der Grundsatz: nur wenn eine Leistung in Form eines
Auftrages bestellt wurde, begibt sich ein Handwerker in die An-
lage. Es werden pro Monat ca. 2.000 Auftrage bearbeitet. Diese
sind nach ihrem Verwendungszweck durch die Auftragsart (IS =
Instandsetzung, US = Unfallschutz etc. ..) strukturiert.

218
 Wilhelm Thygs

Zusatzlich zu den durch Anwendern ausgestellten Auftragen gibt

es automatisch erzeugte Auftrage aus der Wartungsplanung
CAbbiidung 114).
Der Automatismus wird mit Hilfe von Strategien, Arbeits- und
Wartungsplanen sowie der Terminierungsfunktion erzielt. / 1 /

Auftragsabwicklung SAP PM
Terminierte Wartungsauftdige

Yt!iI
War1ungsplllnung
Start

nstandh8ltun 9 S.

~- ... ~ """ltrag mil Into

Wartungspl81'1ung
Termlnlenmg . .-~
~.~-,

~)
WI
Verantwollilcher
~~
u

Arbelt.platz
Ins1andhultungs ~
Planergruppe ~

Abbildung 114: Auftragsabwicklung SAP-PM, terminierte War-

tungsauftrage

Die vom System automatisch erzeugten Auftrage mit den not-

wendigen Informationen werden dem ausfUhrenden Arbeitsplatz
zur VerfUgung gestellt und die Arbeiten ausgefuhrt.
Wichtig ist, dass nach Auftragsfertigstellung die Auftragsruckmel-
dung durch den "verantwortlichen Arbeitsplatz" erfolgt.
Aufgrund der Ruckmeldung Ctechnischer Abschluss) des Auftra-
ges erfolgt yom System der Vergleich des Abschlussdatums und
des Plandatums und es legt den neuen PrUftermin fest.
Abweichungen werden entsprechend der Vorgaben berucksich-
tigt.

219
Instandhaltungsabwicklung mit SAP und erganzender Software

Liegt das Abschlussdatum der Uberpriifung, Z.B. eines Druckbe-

halters hinter dem Plandatum, so erfolgt die Neufestlegung nicht
aufgrund des tatsachlichen Priifungsdatums, sondern bezogen
auf das Plandatum. Durch eine verspatete Uberpriifung, kann
wie heute beim TUV-Termin Ihres Pkws, keine Priifterminverlan-
gerung erreicht werden.
Ais Beispiele fUr erganzende Softwaretools mbchte ich hier auf
einige Komponenten naher eingehen:
Bestandsmanagement von Ersatzteilen und Verbrauchs-
material mit add*ONE,
Fremdleistungsabwicklung mit AVISOR,
Anlagendokumentation, Dokumentenmanagement (Cen-
tra 2000) .

4.1 Bestandsmanagement von Ersatzteilen und

Verbrauchsmaterial mit add*ONE
In Erganzung zu SAP R/ 3setzen wir ein zusatzliches Software-
tool zum Bestandsmanagement ein. Es handelt sich urn das Pro-
dukt add*ONE der Firma Inform (http://www.inform-ac.com).
Die zentrale Aufgabe dieses Programms besteht darin, Ersatzteile
und Verbrauchsmaterialien in benbtigter Menge rechtzeitig zur
VerfUgung zu stellen.
Die dazu benbtigte Lagerbevorratung ist im Bestandswert und
Personalaufwand zu minimieren. In einer Nachverarbeitung wer-
den die benbtigten Daten aus SAP (unserem fUhrenden System)
in Form eines Download in add*ONE iibernommen. Uber eine
online-Schnittstelle werden die Ergebnisse der Disposition (Be-
stellanforderungen) zuriick nach SAP gespielt.
Das eingesetzte System bietet eine flexible Workflow-Unter-
stiitzung sowie eine graphische Dispositionsunterstiitzung.
Das System beriicksichtigt das Verbrauchsverhalten (Saisonie-
rung), Bestandsgrenzen, Rundungsmengen und Lagerkosten.
Es kann zwischen verschiedenen iibergeordneten Strategien un-
terschieden werden. Erstens kann der Bestand oder Aufwand
minimiert oder die Liquiditat optimiert werden. Zweitens kbn-
nen an dieser Stelle auch das ausgewogene Optimum zu ihrer
Strategie zusammenfassen.

220
 Wilhelm Tbygs

Mit dieser wahlbaren Strategie wird die Disposition unterstlitzt

und gelangt im weiteren Ober die Hilfen der Prognoserechnun-
gen zu einem optimalen Dispositionsergebnis .
Eine besondere Bedeutung hat fOr mich die graphische Daten-
aufbereitung und der zugehorige Workflow zur Disposition.
Aufgrund einer Matrixdarstellung, Dispositionskreuztabelle
Abbildung 115) erkennt der Disponent direkt anhand der Farbe
(je dunkler desto kritischer), ob ein Handlungsbedarf vorliegt.
Dber die jeweiligen Schaltfelder der Kreuztabelle wird der Dispo-
nent auf die Materialien aufmerksam gemacht, die zu disponie-
ren, bzw. die aufgrund von Lieferengpassen und Terminverzug
zu kontrollieren sind.
Er erhalt automatisch optimierte Vorschlage (Abbildung 116), die
er bestatigen oder auch durch eigene Entscheidungen ersetzen
kann.
)-

~k
I

P.!'='
_

I
~..,._
,,.....-._

.-- . .
[._

'- -
Vertikale Achse
::::.~ ... D:': ::'''~_ ,_ ...
I _ _ '" _ _ _ _

_t!-..- ~
Disponent
.. -
...
, --r i
,. Materialart

SonderbeschaffungsschlOssel
, . r fo- JI
"
- ..
-
;.! ... r-r-'- - - .- Horizontale Achse
~ - Fehlbestande A - C
~

" ;1~
P
Bestellen
M f-- t- -f0- Lieferverzug
~I
Uberbestande

._.--.J~~~~----,
'.
.l , Bedarfsverzug
Anderungsvorschlage
Gesperrt
_ -""11.00#''- 1111-..: ~..... ~ J:="I~
, Artikel mit Status

Abbildung 115: Workflow basierte Materialdisposition

221
Instandhaltungsabwicklung mit SAP und erganzender Software

iii1illU' xl

r o;
:2("(:
Dfltol l
::.":0
II
'"n
1('

\0 \0 ""
' ....s
. " ' I l ... ~;r
50 :'"
("I"iOO ,- ''''
JJI
-:I>
~'"
... _~:r 19'6 ),!O
JJ2 .II
",.

." .,.,
"ll

I~
,;,; -'
nrc;
~

~
, ,,. ,...
'"51 I I 1 I , I

" ,
lIlll 5 7 '3 I' ., 21 2' 15
. j'oI;~. f ill .-tjAt .... rg.b.. 'ano;.tzJ$:'T'Ig ~r.E.o:t.lI'IJ .~~t~)I.( . ::.c~".t=!l.~L . "" h;l'~ _t Dv..sz

_~ ,.... ",.rn I 1t Vc iJ!I ..~ ....1.-,.. ,... lit

ra S'. I I.~.'1T .. ei~~.d'\ II" .WO N" OBl'-.t. .. 7J.A()U"~:d.'~lJ ~$)PAI) . 0 lJI~

Abbildung 116: Stammsatzinfo / optima Ie Ablaufprognose

4.2 Fremdleistungsabwicklung mit AVISOR

Unternehmen stellen sich immer wieder die Frage ihrer Kern-
kompetenz, bundeln und reduzieren ihre eigenen Anteile in vie-
le Geschaftsprozesse .
Besonders bei der Abwicklung von Investitionen und auch in der
Instandhaltung sind verstarkt Reduzierungen der eigenen Mitar-
be iter und verstarkter Zukauf von Fremdleistungen zu beobach-
ten.
In der Regel wird ein Tei! der Fremdleistungen in Form von Ein-
zelbestellungen zum Festpreis eingekauft.
Ein groBer Tei! zugekaufter Leistungen wird in vie len Unterneh-
men uber Hinger laufende Rahmenvertrage / Werkvertrage (bei
uns ca. 25 %) zu fest vereinbarten Preisen abgerechnet.

222
 Wilhelm Thygs

Hierzu bilden Leistungsverzeichnisse die entsprechende Basis. Es

wird nicht die Zeitdauer einer Arbeit, sondern die erbrachte Leis-
tung bezahlt.
Zwischen den beteiligten Unternehmen, Auftraggeber und Auf-
tragnehmer wird ein entsprechender Rahmenvertrag (Werkver-
trag) mit abgestimmtem LV (Leistungsverzeichnis) abgeschlossen.
Zu diesen Basisbedingungen des Vertrages werden in Foige
durch den Auftraggeber Einzelabrufe getatigt. Der Auftragnehmer
fuhrt die Leistungen aus, erstellt das AufmalS seiner erbrachten
Leistung und reicht dieses, nach erfolgter Anerkennung durch
den Auftraggeber, mit seiner Rechnung ein .
Diese bewahrte herkommliche Verfahrensweise unterstutzt die
Abwicklungssoftware AVISOR der Firma awato GmbH in Dor-
magen (http ://www . awato.de) EDV-technisch (Abbildung 117)
wie folgt:
Auftraggeber und Auftragnehmer verfligen uber je ein eigenes
PC-System mit der AVISOR-Software und mit dem LV (Rahmen-
vertrag) als Basis.
Der Auftraggeber erstellt Einzelauftrage im System und stellt die-
se in Form einer Diskette oder elektronischer Datenubertragung
dem Auftragnehmer zur Verfugung.
Der Auftragnehmer nimmt den Auftrag an und Whrt ihn entspre-
chend aus. Nach der Leistungserbringung wird durch den
Auftragnehmer ein AufmalS erstellt und wiederum dem
Auftraggeber in elektronischer Form uberspielt oder mittels einer
Diskette zur VerWgung gestellt.
Bei der elektronischen Dbernahme der Massen errechnet das
Auftraggebersystem eigenstandig die Preise und Whrt somit be-
reits eine Kontrolle der spateren Rechnungsdaten durch .
Durch die Abnahme und Quittierung der Massen des Aufmasses
erfolgt die Anerkennung des Aufmasses durch den Auftraggeber.
Durch eine weitere Abnahme, z.E. durch den zustandigen
Fremdfirmenkoordinator, wird das im Unternehmen ubliche 4 -
Augenprinzip gewahrleistet.
Nach dieser zweiten Freigabe erfolgt der Transfer der Summen-
daten nach SAP. Die Freigabe der automatischen Zahlung wird
dann im Rahmen eines Zahlungslaufes durch die Finanzabteilung
(Gutschriftverfahren) ausgefuhrt.

223
Instandhaltungsabwicklung mit SAP und ergiinzender Software

Auftragsabwicklung

AG
---' Auftrag auslosen ~
Werkvertrag J ----
(Rahmenvertrag) I Auftrag Obernahmer~

Nach Zeit u.Aufwand

1
I Auftrag ausfGhren I Nach LV
AN
Erbringung der Leistung
~
1_ _ _- Anfertigen des AufmaBes

Ubernahme des AufmaBes /

I-------=-.:..:..~~----l
AG Abnahme und Bestatigen der Massen
"erste Unterschrift"

Abbildung 117: Auftragsabwicklung mit AVISOR.

Die klassische Rechnungsstellung durch den Auftragnehmer und

eine entsprechende Rechnungspri.ifung beim Auftraggeber entfal-
len.
Das Fremdleistungsabrechnungssystem AVISOR steHt ein revisi-
onssicheres Abrechnungsverfahren dar und ersetzt die Detail-
rechnungspri.ifung.
Es fi.ihrt zu einer gewerkei.ibergreifenden einheitlichen Abwick-
lung und Dokumentation mit einer zeitnahen Kostenerfassung.
Durch die SAP-Anbindung wird ein automatischer Ablauf mit ei-
ner entsprechenden Arbeitserleichterung durch das Gutschriftver-
fahren erreicht. In der Technik kommt es zu einen gewissen
Mehraufwand, z.B. durch Klarung bei Unstimmigkeiten .
Besonders wichtig ist die Erstellung der LV's mit der dazugehori-
gen Praxis know how.
In naher Zukunft werden bei einigen Gewerken graphische
Vorsysteme zur Dateni.ibernahme integriert. Hier wird derzeit im
Pilot-Projekt die automatische Sti.icklisten- und AufmassersteHung
aus einer Rohrleitungsisometrie getestet, die mit einem vorgela-
gerten CAD-System erstellt wurde.

224
 Wilhelm Thygs

4.3 Anlagendokumentation, Dokumentenmanagement

Welches Wissen uber die zu betreibenden oder reparierenden
Anlagen und Maschinen haben die Mitarbeiter an der Anlage 0-
der die reparierenden Handwerker? Welche Dokurnentationen
stehen ihnen jederzeit zur VerfUgung?
Was nutzen die 20 Ordner Anlagendokurnentation, wenn sie
beirn Betriebs-Fachingenieur irn Schrank stehen?
Haufig haben wir nur gute Dokurnentationen uber den Bau einer
Anlage
(2 Jahre Bauzeit), die aber nicht fUr den Betrieb und die Wartung
einer Anlage OS bis X Jahre) zugeschnitten sind.
Schnelle und zielgerichtete Inforrnationen reduzieren Anlagen-
stillstande und sind sornit fUr den wirtschaftlichen Erfolg eines
Unternehrnens entscheidend (Abbildung 118).
Dies setzt gut ausgebildete Mitarbeiter und eine entsprechende
Systernunterstutzung bei der Anlagendokurnentation voraus.

FOr den zukOnftigen wirtschaftlichen Erfolg

eines Unternehmens ist nicht die Masse der
Informationen entscheidend, sondern ihre
zeitgerechte und zielgerichtete Bereitstellung.

Abbildung 118: Inforrnations-Richtlinie

Urn die notwendigen schnellen Wissensspeicher (Wissensbasis)

aufzubauen, rnussen wir fruh beginnen Daten und Inforrnationen
entsprechend zu speichern.
Ferner rnussen diese Inforrnationen auswertbar sein und fUr aile
Mitarbeiter zuganglich gernacht werden. Zu beach ten ist auch,
dass den Unternehrnen, z.B. Uber Vorruhestand etc., vie! an Wis-
sen und nicht rnehr ruckholbare Erfahrung verloren geht, wenn
es nicht uber Wissensspeicher gesichert wurde.

225
Instandhaltungsabwicklung mit SAP und ergiinzender Software

Zum Handling von Dokumentationen unterschiedlicher Fachge-

biete gibt es viele moderne Werkzeuge. Diese sind jedoch haufig
stark unterschiedlich und konnen nur von Mitarbeitern mit gro-
Ber Erfahrung bedient werden. Gleiche Arbeitsplatze und Struk-
turen bei solchen Systemen ermoglichen eine einfache Handha-
bung und gewahrleisten einen maximalen Nutzen fur das Unter-
nehmen.
Unser Ziel ist eine maximale Systemintegration, eine einfache
Handhabung, die eine "vor Ort"-Handhabung ermoglicht. Es ist
immer notwendig vorhandene Systeme einzubinden. Medienbri.i-
che soli ten hierbei nicht auftreten.
Unser EDM System Centra 2000, der Firma Auto-trol Technologie
(http://www.auto-trol.com). ist seit September 1996 auf DB Ser-
ver mit Win NT in Betrieb und wird unter NT Clients und Unix
Clients zur Zeit mit 150 Installationen eingesetzt.
Unser Zeichnungsarchiv mit 35.000 Zeichnungseintragen steht
online zur Verfugung und auf ca. 8.000 digitale Zeichnungen
kann direkt zugegriffen werden. Aktuelle Apparateinformationen,
Werksnormen etc., konnen sofort nach Veroffentlichung an den
unterschiedlichen Arbeitsplatzen eingesehen werden (Abbildung
119). Die vorhandenen Apparatedaten wurden mit den entspre-
chenden Zeichnungen verknupft.

Stand heute
~ Archiv fOr z.B. P&I, Orthographie, 3D-Modell

~
..
Arbeitsanweisung, Isometrie,

Abbildung 119: Stand heute der Anlagendokumentation I Doku-

mentenmanagement

226
 Wilhelm Thygs

Direkt aus dem SAP-System kann per Mausklick ins Dokumen-

tenmanagementsystem gesprungen werden. Aus der PM-Auf-
tragsebene gelangt man direkt uber die implementierte Navigati-
on zu allen Zeichnungen des jeweiligen Anlagenkennzeichens
und von dort wieder zuruck. Entsprechende Navigationsunter-
stutzungen werden zur VerfUgung gestellt.
Die Praxis hat uns jedoch gezeigt, dass dieser Weg durch die
Handwerker noch nicht angenommen wird. Der Grund liegt in
den nicht ausreichend zur Verfugung gestellten Informationen,
die fUr seine unmittelbaren Instandhaltungstatigkeiten benotigt
werden. Eine weitere grolSe Schwierigkeit ist die Vielfalt und
Komplexitat der Systeme und Bedienungen, die bei nicht so hau-
figer Anwendung auftreten.

5 Wissensbasierte Instandhaltung
Bei der EDV-technischen Betrachtung einer Instandsetzungs-
malSnahme wird der Auftrag in der Regel als Kostensammler be-
trachtet. Weniger wird der Focus auf das Instandhaltungsobjekt
selbst gerichtet. Der Handwerker oder Anlagenbetreuer sieht in
erster Linie seine notwendigen Tatigkeiten "vor Ort" am Instand-
haltungsobjekt und alles was damit direkt zusammenhangt.
Sein Ziel ist eine optimale Reparatur mit einem kurzen Anlagen-
stillstand zu erreichen. Er ben6tigt fUr seine Arbeit, die Sicht auf
das zu reparierende Bauteil mit allen ihm zur Verfugung stehen-
den Informationen fur die jeweilige Aufgabenstellung CScha-
densbild).
Heute stehen in den haufigsten Fallen nur Teilinformationen zur
Verfugung. Fehlende Unterlagen bzw. Entscheidungshilfen sind
in der Regel fur die AusfUhrenden auch nicht einfach und sofort
zu erhalten. Dies ist jedoch unter wirtschaftlichen Zwangen in
Zukunft unbedingt erforderlich.
Ein guter Vergleich lasst sich sic her zur Medizin herstellen . Ein
Chirurg, der einen neuen unbekannten Patienten operieren soli,
benotigt eine gute Dbersicht uber die Krankheitsgeschichte, eine
Anamnese des Patienten und parallel eine Menge zusatzlicher
Untersuchungen, Rontgenbilder etc., bevor er seinen Eingriff op-
timal durchfUhren kann .
In der Instandhaltung und Fehlerdiagnostik von komplexen An-
lagen stellt sich die Situation und def Bedarf ahnlich dar.

227
Instandhaltungsabwicklung mit SAP und erganzender Software

Die zu erwartenden Kosten bestimmen in den meisten Fallen die

zu praktizierende Instandhaltung. Das Wissen uber c1en techni-
schen Zustand der Anlagen ist vergleichbar mit der Krankenge-
schichte des Patienten und ist die Basis fur eine effektive In-
standhaltung.
Die Auswahl der IH - Strategie hangt zusatzlich noch von der
Frage ab, soll vor einer Starung und Ausfall der Anlage (Kompo-
nente) oder nach der Starung instandgesetzt werden. / 3 /
Die Objektsicht und Zusammenfassung aller zur VerfUgung ste-
henden Informationen allein reichen nicht aus. Fur den zukunfti-
gen wirtschaftlichen Erfolg eines Unternehmens ist es, wie schon
erwahnt, zwingencl erforderlich, die Information zeit- und zielge-
richtet und aufbereitet als direkte Entscheidungshilfe zur VerfU-
gung zu haben.
In der Vergangenheit war das Wissen auf viele Mitarbeiter in ei-
nem Unternehmen verteilt. Mit zunehmender Komplexitat wur-
den EDV-technische Hilfsmittel zur Unterstutzung (EDM / PDM
System etc.) eingesetzt. Parallel ist in den Unternehmen die An-
zahl der Mitarbeiter stark reduziert worden. Der im Unternehmen
verbleibende Mitarbeiter ubernimmt zwangslaufig immer mehr
Aufgaben. Fur die Instanclhaltungsmitarbeiter bedeutet dies, dass
sie eine Vielzahl unterschiedlicher Softwaresysteme und Soft-
waretools beherrschen mlissen, um die Tagesaufgaben heute
und in Zukunft lasen zu kannen.

228
 Wilhelm Tbygs

e Plane & Daten

Verfahren schemata.
R&I.
Objektsicht

Prozef3daten
,f:reiten. Schwingungen.
nzwcrte. Ziihler.
chahplllne .. oren ....

Beschaffun hnische Dokumentation

men, Anleitungen.
leJZeichnungen.
Kataloge, ...

IH-Informationen
Lcbenslauf. Phine. Schadens-
hiiufigkeit, IH- Koste n.
Reparatur-Aufzeichnungen, ...

Abbildung 120: Objektsicht

Es ist eine zwangslaufige Schlussfolgerung, die Daten unter-

schiedlicher Systeme zu bundeln und "neu" unter einer Objekt-
sieht zu entscheidungsfahigen Informationen fUr die Instandhal-
tung aufzubereiten (Abbildung 120).
Moderne Instandhaltungsmanagement-Systeme (IMS-Systeme)
bieten bereits eine Menge dieser FunktionalWiten. Bei einem zu-
satzlichen Einsatz eines solchen Systems wird fUr die Handwer-
ker Komplexitat nur noch weiter gesteigert.
Fur mich stellt sich die Frage: Wissen wir was unser SAP System
schon weiB ? Welche verwertbaren Informationen sind in Form
von Daten etc. bereits heute schon vorhanden und bedurfen nur
einer entsprechenden Aufbereitung.
Erst nach intensiver Aufbereitung der bereits vorhandenen Da-
ten, sollte man durch Schaffung der notwendigen Schnittstellen,
die vorhandenen EDV-Systeme untereinander verbinden . Des
weiteren ist die Frage zu beantworten, ob fUr die angestrebten
Losungen ein weiteres System erforderlich ist oder ob hier SAP-
PM seinem Namen "Plant Maintenance" gerecht werden kann
und in der Instandhaltung eine ahnliche Fuhrungsrolle, wie in
der allgemeinen Betriebsfuhrung ubernehmen kann.
Sollte dieser Weg mittels SAP begangen werden, so muss zwin-
gend auf die Anforderungen der "vor Ort"-Instandhalter Ruck-
sicht genommen werden.

229
Instandhaltungsabwicklung mit SAP und erganzender Software

FOr den gelegentlichen Anwender ergibt sich heute im Standard-

system die Problematik, dass sich die Komplexit:it des Systems
als unObersiehtlich und schwer handhabbar darstellt.
Der daraus resultierende Widerwille mit dem System zu arbeiten,
kann durch die Bereitstellung einer anwendergerechten Benut-
zeroberfhche entgegengewirkt werden. / 1 /
Die graphische Oberthche soUte ahnlich wie in der Materialdis-
position aufgebaut werden und den einzelnen Benutzerrollen die
entsprechende Unterstiitzung erm6glichen, auch wenn er nur
unregelmaJSig das System nutzt. Hier muss der Softwarehersteller
weiterhin verstarkt Weiterentwicklung durchfOhren.
Urn den hier aufgezeigten Weg zu beschreiten, ergibt sich aus
meiner Sieht eine sinnvolle Zusammenarbeit zwischen uns, der
Industrie und der Hochschule, hier im besonderen der FH K61n,
urn die vielen Basisuntersuchungen und Schnittstellenprogram-
mierungen durchzufOhren .
Dies lasst auf eine weitere gute Zusammenarbeit hoffen .

6 Literatur
/ 1 / M. Schlicht, Anwendergerechte Gestaltung von Benutzerober-
jliichen in SAP Rl3 Diplomarbeit 2001
/ 2 / U. Wehner, Konzept zur Optimierung der Arbeits- u. War-
tungsplanung mit SAP Rl3 Diplomarbeit 2001
/3/ Professor Dr.- Ing . A. Sturm, Wissensbasierte Betriebsfiihrung
und Instandhaltung von Energieversorgungsanlagen, VGB
Kraftwerks- Technik 6/99

230
 Stefan M611emann

SAPCRM 3.0

Stefan Mollemann

1 Highlights und Lowlights oder warum wird CRM (Customer

Relationship Management heute immer wichtiger ?
Wo bisher der Schwerpunkt auf die Effizienzsteigerung der in-
ternen Prozesse in den Unternehmen gesetzt wurde, reicht dies
heute nicht mehr aus. Nach augen gerichtete Magnahmen wie
der Erhalt, die Ausdehnung, die Verbesserung der Kundenbezie-
hungen sowie die Erweiterung der Absatzkanale sind in den Mit-
telpunkt geruckt und zur Steigerung des Unternehmenserfolges
unumganglich.
Produkte werden in vielen Branchen immer austauschbarer, wo-
durch Wege zur Differenzierung des eigenen Unternehmens zum
Wettbewerb gefunden werden mussen. Des weiteren zwingen
Globalisierung und 6ffnung der Markte zu erh6hter Kundenbin-
dung und Erweiterung der Absatzkanale.
Hera usfo rde- Die Herausforderung des Customer Relationship Management
rung des CRM (CRM) besteht nun darin, bestehende Prozesse zu verandern und
dennoch Kunden- und Lieferantenbeziehungen mit einzubinden.
Eine Integration dieser unterschiedlichen Prozesse ist sehr kom-
plex und damit bedarf es einer klaren und eindeutigen Formulie-
rung der Ziele, urn damit die Implementierung der eher nach
augen gerichteten und der internen Geschaftsprozesse zu ver-
wirklichen.

2 Customer Lifecycle Management

Die Geschaftsbeziehung wird heute leider immer noch von vie-
len Firmen aus einer verkurzten, zeitpunktbezogenen Perspekti-
ve gesehen. Der gesamte Kundenlebenszyklus ist fur uns rele-
vant. Die Phasen des Lebenszyklus sind, Customer Engagement,
Business Transaction, Order Fullfillment und Customer Service
und Sie k6nnen innerhalb des Lebenszyklus mehrfach durchlau-

231
SAPCRM3.0

fen werden. Das Research-Unternehmen META Group stellt dazu

fest, dass CRM letztendlich nichts anderes ist als ein systemati-
scher Ansatz zum Customer Lifecyc1e Management, also zur sys-
tematischen Interaktion von Unternehmen mit Kunden Uber aile
vier phasen der Geschaftsbeziehung hinweg [META 19991.
Marktanalyse Das Markforschungsinstitut Gartner Group [Nelson 2000] hat Un-
zuCRM tersuchungen durchgefUhrt, deren Fokus es war, die maBgebJi-
chen Entscheidungen herauszufiltern, die dazu fUhren , dass eine
CRM-LOsung zum Einsatz kommt.
Diese Punkte waren :
- Umsatzsteigerung,
- Steigerung der Profitabilitat,
- Verbesserung der Kundenloyalitat,
- Erringen von Wettbewerbsvorteilen,
- Kostensenkung,
-Zugriff auf neue Kontaktkanale zum Kunden.
Am Anfang steht damit immer die Frage nach der LOsung! Wel-
che Software ist die beste fUr mich und mein Unternehmen?
Welche Geschaftsprozesse machte ich realisieren und wie sieht
meine Systemlandschaft aus? Neben der schon etablierten CRM-
Software Siebel 2002 gibt es seit kurzer Zeit einen zweiten gro-
Ben Stern am CRM-Himmel. Die Rede ist von mySAP CRM 3.0. In
kurzen pragnanten Aussagen machte ich Ihnen die Philosophie
und die Funktionen dieser Software naher bringen.
Nun ist es so, dass jede CRM Lasung ihre eigenen Schwerpunkte
beinhaltet und bedarfsbezogen analysiert werden muss.
In unserem Fall stand die Forderung nach einer umfassenden In-
tegration im Vordergrund. Somit wurde die CRM-LOsung von SAP
reaJisiert, welche die oben genannten Punkte in einem ein-
heitlichen LOsungskonzept widerspiegelt. Durch ein reibungs-
loses Zusammenspie1 vieler einzelnen Komponenten wurde die
erforderliche Integration samtiicher, einbezogener Geschaftspro-
zesse, die nachstehend beispielhaft aufgefUhrt sind, gewahr-
leistet.

3 Stammdaten
Hinter diesem Bereich verbergen sich aile Informationen tiber
Geschaftspartner, Produkte und Preise. FUr diejenigen von Ih-

232
 Stefan M611emann

nen, die SAP Rl3 kennen, ist auch hier schon der erste wichtige
Punkt dieses Artikels erreicht.
Anderungen bei Die Geschiiftspartner und ihre Struktur haben sich grundlegend
Geschaftspart- geandert. So kann man einem Geschiiftspartner mehrere Rollen
nern und Struk- zuordnen (z.B. Interessent, Mitarbeiter, Bieter, Lieferant). Diese
turen Rollen kbnnen beliebig erweitert werden . Zudem kann man zu
jedem Geschiiftspartner Beziehungen pflegen. Das bedeutet, dass
ich einen Netzplan tiber die Beziehungen meiner Geschaftspart-
ner erzeugen kann, urn einen schnellen Uberblick zu bekom-
men. 1m Bereich Produkte gibt es ebenfalls einige Highlights. So
ist es mir mbglich, den Aufbau der Bildschirmoberflache per Edi-
tor durch Drag & Drop so zu gestalten, wie Sie es gerne hatten.
Das hat den Vorteil, dass Sie ein kundenindividuelles Design in
kurzer Zeit erstellen kbnnen. Nattirlich lasst sich der Material-
stamm urn Datenbankfelder erweitern, aber hier stbBt man
schnell an die Grenzen des "Drag & Drop". Deshalb mtissen wir
hier unsere Programmierer urn Hilfe bitten.

4 Marketing
Kampagnen Der Bereich Marketing kann mit vielen Funktionen Punkte sam-
meln. So ist es dort unter anderem mbglich, einen Marketingplan
mit vielen Kampagnen anzulegen, Zielgruppen zuzuordnen und
im Nachgang zu monitoren.
Templates Urn mbglichst effizient und schnell zu arbeiten hat man die Mbg-
lichkeit, Templates zu erstellen und immer wieder zu benutzen.
Die Zielgruppe wird tiber der Segment Builder per "Drag &
Drop" kreiert. Die im Geschiiftspartnerstamm hinterlegten Marke-
tingprofile helfen, die Zielgruppe so zu bestimmen, dass die
Kampagne einen groBen Erfolg verspricht. Urn die Kontaktauf-
nahme zum Kunden so zu gestalten, wie es der Umworbene
gerne hatte, gibt es im Bereich Geschiiftspartner die "Standard
Kommunikationsart". Diese entscheidet dartiber, ob der Kunde
tiber das Call Center angerufen wird, ob er einen Brief per Post
oder eine Email bekommt. Das sind nur einige wenige Kontakt-
mbglichkeiten. SAP CRM bietet Ihnen noch wesentlich mehr an.

5 Aktivitaten
Der Bereich Aktivitaten umfasst das gesamte Spektrum der Mbg-
lichkeiten. Aktivitaten kbnnen z.B. ausgehende Emails, Telefon-
anrufe oder auch eingegangene Briefe sein. Durch diese Funkti-
on werden alle zum Kunden mbglichen Kontakte dokumentiert

233
SAPCRMJ.O

und zur weiteren Verarbeitung in das System eingestellt. Natiir-

lich konnen diese Aktivitaten aus dem Bereich Marketing gene-
riert werden, so dass ein AuiSendienstmitarbeiter diese Aktivitat
automatisch bekommt. Die Bearbeitung wird gemonitort und
kann uber das analytische CRM ausgewertet werden. Die Kun-
dengesamtsicht kann z.B. im CIC (Customer Interaktion Center)
angezeigt werden.

6 Auftragsabwicklung
Neue Funktionen der Auftragsabwicklung sind die Bereiche Lead
und Opportunity.
Leads Leads sind die potenziellen Kunden von morgen oder die Kun-
den von heute, die man fur eine anderes Produktsortiment inte-
ressieren mochte. Mogliche Leads sind z.B.
ein Besitzer eines Kompaktklasse-Wagens, der eine Pro-
befahrt mit einem Mittelkasse-Modell vereinbart,
der Strom-Kunde eines Versorgungsunternehmens, der
via Internet ein Angebot fUr Wasserlieferungen wunscht,
der Bankkunde, der eine Vermogensberatung wunscht.
opportunities Die Opportunities hingegen sind qualifizierte Verkaufschancen,
also eine uberprufte Moglichkeit fur ein Unternehmen, Produkte
oder Dienstleistungen zu verkaufen. Opportunities konnen aus
Leads abgeleitet oder direkt vom Vertriebsmitarbeiter angelegt
werden. Inhalt einer Opportunity kann sein :
Beschreibung des Kaufinteressenten,
Budget des Kaufinteressenten,
Potenzieller Umsatz,
Geschatzte Auftragswahrscheinlichkeit.
Lead oder Opportunities konnen die Datenbasis fUr ein Angebot
oder einen Auftrag bilden. Nach Erstellung dieses Auftrages kon-
nen wir das System verlassen und die Lieferfunktionen eines SAP
R/ 3 benutzen (Option). Das ist einer der wesentlichen Punkte im
Prozess. Die Verzahnung mit SAP Anwendungen ist sehr hoch.
Das kann ein Vorteil sein, wenn man SAP R/3 hat, aber auch ein
Nachteil, wenn man ein anderes ERP System im Einsatz hat.

234
 Stefan M611emann

7 Mobile Szenarien
Die von der Firma SAP AG bereitgestellte Softwareumgebung fUr
die Mobilen Szenarien beinhaltet die Funktionen und Prozesse,
um den Kunden uber den gesamten Lebenszyklus zu betreuen.
Angefangen von einer Sales-LOsung bis hin zum Field-Service
kann mit dieser Software jede Anforderung realisiert werden. Ba-
sis ist eine Kommunikationsschnittstelle in das CRM Online.
Middleware Durch eine Middleware werden die Daten ausgetauscht, so dass,
wie schon beschrieben, alle Informationen im Online-System
verwaltet werden k6nnen. Die AuBendienstmitarbeiter haben
immer die M6glichkeit ATP-Checks durchzufUhren und k6nnen
konkret Aussagen uber die Installbase tatigen, da sie alle Infor-
mationen zum Kunden verfugbar haben.

8 Internet Sales
Der von der SAP implementierte Webshop unterscheidet sich
nicht von vielen anderen L6sungen. Es werden Produktkataloge
zur Verfugung gestellt. Einfache Navigation und Plattformunab-
hangigkeit sind selbstverstandlich. Das Design ist individuell an-
passbar und auch die Abfolge der Webseiten ist frei zu definie-
reno Einen Unterschied gibt es aber! Eine sehr starke und kom-
fortable Suchmaschine ist im Webshop implementiert. Ober
Auswahlboxen k6nnen dem Kunden Merkmals-Auspragungen
angezeigt werden. Daraus resultiert dann eine kundenindividuel-
Ie Produktliste. Webintelligente Produktberater wie z.B. eConsul-
tant k6nnen ohne Probleme eingebunden werden. Zudem sind
B2B Szenarien m6glich.

9 Customer Interaktion Center (CIC)

Genesys Die aktuelle Version von SAP CIC stellt einen Meilenstein dar, da
der Call-Center-Agent erstmalig in einen durchgangigen Ge-
schaftsprozess involviert ist. Er kann uber alle verfugbaren Kana-
Ie yom Kunden kontaktiert werden. Somit zeigt sich die Durch-
lassigkeit im Zusammenspiel der Technologien. Auf der Basis der
Software Genesys ist das CIC entwickelt worden und ist sowohl
serverseitig als auch in der Anwendung stark integriert.
Zusatzoptionen Optional kann hier auf die SAP Software SAPcomm oder
SAPphone zuruckgegriffen werden.

235
SAPCRM 3.0

Die Entscheidung zu SAP CRM wurde somit nicht durch einen

detaillierten Vergleich zu anderen CRM-Losungsanbietern getrof-
fen, sondern durch eine ganzheitliche Betrachtung der Unter-
nehmensprozesse und der daraus erwarteten Integrationsfahig-
keit der Gesamtlosung.

10 Literaturverzeichnis
META Group and IMT Strategies, Customer Relationship Man-
agement Study, 22 September 1999.
Nelson,S.: Customer Service is the most important CRM Function,
Gartner Group, 9 November 2000.

236
 Daniel Ramisch

Einfuhrung von SAP BW in der Prozessindustrie

Daniel Ramisch

Einleitung
Zur Abbildung der Geschaftsprozesse in Unternehmen wurden in
den letzten Jahren vorrangig Investitionen in neue Hard- und
Software getatigt, die den Ablauf in allen Industriezweigen
schlanker, effizienter und damit kostengunstiger steuern sollten.
Durch die EinfUhrung des SAP Systems erhofft man sich nun die-
se Vorteile, wohl auch mit dem Gedanken, hier eine Komplettlb-
sung fUr aile Unternehmensbereiche zu erhalten. Effizienz und
Flexibilitat der unternehmenseigenen Prozesse stehen hier im
Vordergrund des Interesses. Trotzdem laufen aus unterschiedli-
chen internen Grunden Altsysteme beispielsweise fUr Historie-
oder Personaldaten parallel zum SAP R/ 3.
Dynamisches In einer von zunehmender Dynamik und Flexibilitat gepragten
Umjeld Geschaftswelt sind schnelle und richtige Entscheidungen von
immer grbBerer Relevanz. Der Vorsprung gegenuber den Mitbe-
werbern schmilzt heute ohne entsprechend genaue Informatio-
nen uber unternehmenseigene Geschaftsablaufe enorm. Der Be-
darf an hoher Transparenz im Unternehmen ruckt zunehmend in
den Vordergrund. Die Information avanciert mehr und mehr zur
bedeutendsten Saule der Wirtschaft.
Wachstum der Dem gegenuber jedoch wachst die IT-Infrastruktur in vielen Un-
IT ternehmen auf ein schwer zu uberschauendes MaB mit den typi-
schen Problemen:
Wenig oder keine Kompatibilitat unter den IT-Systemen,
Datenredundanzen,
Hoher pflege- und Wartungsaufwand von Alt- und Neu-
systemen,
Muhsame Informationssuche und -auswertung,
Sinkende Reaktionsgeschwindigkeit bei Entscheidungen.

237
Einfuhrung von SAP BW in der Prozessindustrie

Diese Divergenz wird immer haufiger von Entscheidungstragern

erkannt. Die Suche nach Auswegen riickt zunehmend in den
Vordergrund. Entscheidern mussen in den dynamischen und
komplexen Markten wirksame Systeme fUr ein erfolgreiches Ma-
nagement an die Hand gegeben werden (vgl. KEMPER, 2002). Vie-
le notwendigen Informationen stehen innerhalb des Unterneh-
mens grundsatzlich zur VerfUgung. Die Schwierigkeit besteht je-
doch darin , diese Informationen zu lokalisieren und qualitativ
hochwertig abzubilden. Dem unternehmensweiten Informati-
onsmanagement fallt dabei eine entscheidende Rolle zu (vgl.
BUCK-EMDEN/ GALIMOV, 1995).
zentrale Aufga- Das fUhrt uns zu der zentralen Aufgabenstellung innerhalb der
benstellung unternehmerischen Transparenz: Die Information zur rich-
tigen Zeit in der richtigen Qualitiit am richtigen Ort.

2 Reporting in SAP R/3 und Non-SAP Systemen

SAP R/ 3 bietet mit seinen Informationssystemen LIS2 und EIS3
standardisierte Moglichkeiten der Informationsabbildung. Die
Erweiterungsmoglichkeiten zu den Standards sind aber eher be-
grenzt. Die SAP R/ 3 internen Auswertungstools werden zudem
auch nicht mehr weiterentwickelt, sollen entsprechend der SAP
Philosophie durch das Produkt BW abgelost werden. Dies ent-
spricht dem Wandel innerhalb der IT-Losungen zur Manage-
mentunterstutzung bis zur heutigen Zeit.
ABAPI4jur Es ist im weiteren uber die Programmierung in ABAP/ 4 moglich,
Auswertungen relevante Daten, die fur die Auswertung und damit fUr die Ent-
scheidungsfindung wichtig sind, darzustellen. Dies bedeutet aber
fUr das Unternehmen einen nicht unerheblichen zeitlichen Mehr-
aufwand, zumal bei vielen Informationen die Darstellungsweise
dieser Reports schnell unubersichtlich wirkt.
Peiformance- Eines der kritischsten Elemente des Reportings in SAP R/ 3 stellt
reduktion durch allerdings die stark abnehmende Performance im Produktivsys-
Reporting tern dar. Es wird nicht nur durch die Prozesssteuerung im Tages-
geschaft belastet, hinzu kommen ebenfalls die Reportingzugriffe
zur Informationsanalyse. Dadurch konnen sich samtliche Vor-

2 LIS = Logistic Information System; Komponente zur Prozessinformati-

on innerhalb SAP R/ 3
3 EIS = Executive Information System

238
 Daniel Ramisch

gange im SAP Rl3 so sehr verzbgern, dass ein effizientes Arbei-

ten zu StoBzeiten nahezu unmbglich wird.
Ablosung von Die uber SAP R/3 abgelbsten Prozesssteuerungssysteme (Altsys-
A ltsystem en teme) werden in der Industrie zumeist fUr eine zuvor festgelegte
Ubergangszeit parallel zum SAP Rl3-System vorgehalten. So wird
gewahrleistet, dass prognoserelevante Vorjahresdaten noch uber
herkbmmliche Weise ohne Anbindung an SAP R/ 3 zu erreichen
sind. Ais Beispiel seien hier Vorjahresbelegdaten oder Vorjahres-
umsatze genannt. Daraus entstehen zahlreiche isolierte Einzel-
systeme. Als Konsequenz ergeben sich Schnittstellenprobleme
bei der Verknupfung der Systeme untereinander. Die Erfahrung
zeigt, dass dies sind bei vielen Firmen mit gewachsener IT-
Infrastruktur unvermeidbar ist.
Um Entscheidungskriterien fUr zukunftige Unternehmensentwick-
lung zu erhalten, sind aktuelle Daten aus dem SAP R/ 3 diesen
Vorjahresdaten gegenuberzustellen. Dazu werden die Daten
meist umstandlich in Flat Files 4 abgelegt, um sie anschliefSend
den SAP R/3 Werten gegenuberzustellen (z.B. uber MS Excel).
Erst danach kann eine Auswertung erfolgen. Dieses Vorgehen ist
langwierig und liefert lediglich Informationen zum Zeitpunkt der
Flat File Erstellung. Die Information ist also schon in dem Au-
genblick veraltet, in dem sie fUr Auswertungszwecke aufbereitet
wird. Die Problematik ist offensichtlich. Als Abhilfe werden Da-
ten aus unterschiedlichen Systemen muhevoll, teilweise in Klein-
arbeit per Hand in eine Tabellenstruktur ubertragen, damit Da-
tenvergleiche mbglich werden . Das kostet Zeit, und die Fehlerra-
te beim Ubertragen ist sehr hoch.
System itbergrei- Selbst beim Einsatz neuerer integrierter ERP-Software 5 bleiben
fender Infor- viele Probleme ungelbst, da diese Systeme primar auf die Unter-
mationsabgleich stutzung wertschbpfender Prozesse ausgerichtet sind (vgl. KEM-
PER, 2000). Wunschenswert ist daher ein systemubergreifender
Informationsabgleich, der samtliche ERP-Systeme umfasst und
aktuelle Daten liefern kann. Die Grundlage dafur stellt eine sepa-
rate und konsistente Datenbasis dar. Dies macht nicht nur den
Mitarbeitererfolg aus, es bedeutet gleichzeitig den Erfolg des Ma-

4 Flat Files = ASCII - Dateien, deren Inhalte externer Software zur Ver-
fiigung gestellt wird
5 ERP = Enterprise Ressource Planning System; Software zur Steuerung
von GeschaftsabHiufen innerhalb Unternehmen

239
Einfuhrnng von SAP BW in der Prozessindustrie

nagements. Der bisherige Inseleffekt zwischen SAP R/3 und Non-

SAP-Systemen lauft diesem Wunsch informativ genau entgegen.

3 SAP BW als Data Warehouse Losung der SAP

Anfordernngen Bei den angesprochenen Situationen ist ein sinnvoller Automa-
anSAPBW tismus zur Beherrschung der Anforderungen notwendig. Die An-
forderungen an ein iibergreifendes Mittel zur Abbildung und Ge-
geniiberstellung analyserelevanter unternehmerischer Daten sind
demzufolge definiert als:
Schneller und permanenter Zugriff auf entscheidungsre-
levante Informationen,
Hbchstmbgliche Aktualitat und umfassende Vollstandig-
keit,
Effiziente und flexible AnalysembgJichkeiten.
Die Lbsung der SAP AG definiert sich als ein Data-Warehouse,
das Daten aus beJiebigen Quellsystemen kombiniert und sie ge-
geneinander stellt. Die Berechnung und Aufbereitung der Daten
vor der Weiterleitung an die Analyse sind mbglich. Eine einheit-
liche Oberflache kombiniert samtliche auswertungsrelevanten E-
lemente und stellt sie in einer fUr den Anwender iibersichtlichen
Form dar. Dariiber hinaus setzt eine solche Oberflache nur ge-
ringe DV-Kenntnisse des Anwenders voraus.

Als Konsequenz aus den Anforderungen ergeben sich fiir das

SAP Data Warehouse, SAP Business Information Warehouse
(BW), folgende Punkte (vgl. SAP, 2000):

Bereithaltung aller relevanten Informationen,

Zugriff auf Informationen aus beliebigen Quellsystemen
iiber einen eindeutigen Einstiegspunkt,
Informationen hoher Qualitat und Giite,
Abbildung aller Geschaftsprozesse,
Unterstiitzung komplexer Analysen und Darstellungen,
Hohe Performance von Produktiv- und Reportingsystem.
Das BW-System realisiert diese Anforderungen iiber ein komplett
von allen Quellsystemen entkoppeltes Data Warehouse. In der
Informationsbasis, dem eigentlichen BW, werden die reportingre-

240
 Daniel Ramisch

levanten Daten redundant zu den Quellsystemen in InfoCubes6

bzw. ODS7 vorgehalten, urn eine Trennung zwischen Produktiv-
system und Reportingtool zu gewahrleisten. Dies soli eine gute
Performance beider Arbeitsmittel sicherstellen. In der Informati-
onsbasis werden die Daten berechnet und verdichtet, urn sie
letztendlich im Analysewerkzeug abzubilden. Ais Standard arbei-
tet SAP hier mit MS Excel zusammen, ein Excel Sheet dient hier
also als Informationstrager (BEx AnalyzerS).

Analysewerkzeug I REx
Information aulbereitung Analyzer

t
lnformationsba i I
Data Warehouse
Technologie

t
DatenQuellen I S P
operative Vorsysteme non SAP

Abbildung 121: dreistufiges SAP BW Konzept

6 InfoCube = Datenspeicher im BW; in ihnen werden reportingreIevante

Daten aggregiert und verdichtet fUr Auswertungen vorgehalten
7 ODS = Operational Data Store; Datenspeicher im BW, hier werden
Daten auf Belegebene vorgehalten, die im nachsten Schritt modifiziert in
die InfoCubes fortgeschrieben oder direkt fUr Auswertungen weiterge-
nutzt werden k6nnen
8 BEx Analyzer = Business Explorer Analyzer; Standardauswertungstool
des SAP BW, Kombination aus einem MS Excel Sheet und einem BW
Makro; hier werden Informationen filr den Anwender prasentiert

241
Einjuhrung von SAP BW in der Prozessindustrie

Als Zusatz zum BW liefert SAP den Business Content9 mit aus ,
eine vorkonfigurierte, standardisierte Systemlandschaft, die den
Implementierungsaufwand moglichst gering halten solI.

4 Entscheidungskriterien und Implementierung

Vor der Einflihrung von SAP BW ist als wichtiges Entscheidungs-
kriterium die Analyse der eigenen Informationsbedarfe notwen-
dig. Der Kosten - Nutzen Aspekt steht dabei im Vordergrund des
Interesses. Es lohnt sich aus Kostenaspekten fur ein Unterneh-
men mittlerer GroBe selten, SAP BW als Reportingtool einzuset-
zen, wenn eine uberschaubare Informationsmenge auf lediglich
einer Datenbank abgelegt ist. SAP BW ist zwar auch in der Lage,
auf Basis eines Non-SAP-Systems Auswertungen abzubilden, al-
lerdings ist dann die Frage zu stellen, ob die bisherigen Auswer-
tungsmechanismen nicht ausreichen. Dann namlich konnen Ver-
gleichsreports innerhalb der klassischen SAP R/ 3 - Anwendun-
gen zur Analyse weitergenutzt und verbessert werden. Die Kos-
ten waren damit wei taus geringer, als dies bei einem zusatzli-
chen Data Warehouse der Fall ware.

Datenquellen Die wichtigste Datenquelle des SAP BW bildet das SAP R/ 3-

System. Beim Einsatz von SAP BW mit Non-SAP-Systemen als
Datenquelle ist daher nicht zu unterschatzen, dass Schnittstellen-
anpassungen ressourcenintensiv sind. Dafur aufgesetzte Techno-
logien sind hochkomplex und heutzutage im Bereich JA VA-
Entwicklung angesiedelt (EBI = Enterprise Business Integration).
Die hohe Komplexitat auf der Seite der Quelldatensysteme wird
haufig durch die Heterogenitat der Systeme erzeugt und durch
die Schwerfalligkeit bei der Ablosung der Altsysteme noch ver-
starkt (vgl. MAUR, 2002). Um samtliche Datenressourcen im SAP
BW zur Verfugung zu haben, bedeutet es einen erheblichen
Aufwand bei der Entwicklung und dem Betrieb einer entspre-
chen den Informationslogistik, verbunden mit immensen Kosten
bei der Integration von angepassten SAP R/3 - Daten.
SAP BW hat zwar uber den mitgelieferten, kostenfreien Business
Content vordefinierte Schnittstellen konfiguriert, allerdings ist die

9 Vorkonfigurierte, standardisierte Datenmodelle zur schnellen, effizien-

ten Einftihrung von SAP BW; beinhaltet sind Rollen, InfoCubes, ODS
und Extraktoren

242
 Daniel Ramisch

Zuordnung der Schnittstellen liberwiegend auf SAP Rl3 bezogen.

Bei den speziellen Definitionen der Unternehmen wie beispiels-
weise Tabellen- oder Feldbezeichnungen ist hier Detailarbeit zu
leisten.
Business 1st die Entscheidung fUr eine Reportinglandschaft mit SAP BW
Content getroffen, so erspart der Business Content mit seinen Vordefiniti-
onen (Rollen 10 , Arbeitsmappen ll , Queries l2 , Data Sources 13 etc.)
viel Implementierungsaufwand. Allerdings sind die unterneh-
mensspeziellen, rollenbasierenden Anforderungen gerade mit
Hinblick auf Prozesse, Geschaftsbereiche und Berechtigungskon-
zepte meist sehr speziell, so dass hier ebenfalls mit Anpassungs-
aufwand gerechnet werden muss. Kein Unternehmen lasst sich
in eine Schablone pressen, deshalb ist der Business Content
zweckmaBig nur als Grundlage fUr Erweiterungen im Sinne der
unternehmensspezifischen Anforderungen nlitzlich.
Bei der Anforderungsdefinition fUr das SAP BW ist ein klares,
libersichtliches Konzept mit Grafiken und Rollendefinitionen li-
ber aile Geschaftsprozesse hinweg unverzichtbar. Aile Beteiligten
soli ten zu Beginn den Dberblick darliber gewinnen kbnnen, wo
Berlihrungspunkte in der Implementierung entstehen.

AlS BEISPIEL FUR OlESEN PROZESS SOll FOlGENOER

ABlAUF GELTEN:

Ein InfoCube kann fOr Materialbewegungen von zwei unterschiedlichen

Business Units Ober Queries genutzt werden. Dieser InfoCube wird mit
Daten aus einem SAP Produktivsystem versorgt. Business Unit 1 be-
notigt fOr seine Auswertungen lediglich kumulierte monatliche Ergeb-
nisse, Business Unit 2 hat seine Informationsbasis wochenaktuell vor-
gesehen. So wird der Datenladeprozess im Hintergrund nur monatlich
als Hintergrundjob den Inhalt des InfoCubes aktualisieren. Ohne Hin-
weis erhalt nun Business Unit 2 zu jeder Woche gleiche Ergebnisse,
weder wochentliche Wareneingange noch entsprechende wochentli-

10 Kombination von anwenderspeziellen Auswertungen, berechtigungs-

relevant
11 Zusammenfassung von Auswertungen im BEX Analyzer

12 Basis einer Auswertung

13 technische Verbindung von Quellsystem und BW System, hieruber
werden Daten in das BW geleitet

243
Einfuhrung von SAP BW in der Prozessindustrie

che Ausgange werden verbucht. Ohne Absprache wird die Suche nach
der Ursache dieser nicht vorhandenen Buchungen im BW vie I Zeit in
Anspruch nehmen.

Es wird deutlich, dass gerade dort, wo auf Datenspeicher (ODS,

Info- und MultiCubes l4 ) mehrere Queries aufgesetzt sind, Kom-
munikation untereinander erfolgen muss, sonst enthalten die Be-
richte unstimmige Werte, die nicht unmittelbar auffallen, dadurch
zu fehlerhaften Informationsauswertungen fuhren.
lmplementie- Wahrend der Implementierungsphase ist auf ein ausgewogenes
rungsphase Projektteam zu achten, das schon von Anfang an aus externen
Beratern und internen Mitarbeitern bestehen sollte . Daraus ent-
steht ein Synergieeffekt, es bewirkt automatisch einen Austausch
von BW - Fachkenntnis vom Berater auf der einen, und von Pro-
zess- bzw. Unternehmensstrukturkenntnis der internen Mitarbei-
ter auf der anderen Seite. Durch diese Vorgehensweise wird der
Know-how-Transfer sichergestellt. Zudem ist der interne Mitar-
beiter nach dem Go-Live l5 soweit mit der Technik vertraut, dass
er als Ansprechpartner dienen und gemeinsam mit dem Berater
auch die Schulung der Endanwender ubernehmen kann.
Berechtigungs- Ein weiteres Element bei der SAP BW EinfUhrung ist das Berech-
konzept tigungskonzept. Zugriffe auf Reports innerhalb des BW werden
tiber ein Berechtigungskonzept abgewickelt, denn beispielsweise
auf Geschaftsleitungsauswertungen uber das Budget im Ge-
schaftsjahr oder auf Personalbudgetplanungen darf nur ein aus-
gesuchter Kreis Zugriff haben. Schnell entsteht der Gedanke, die-
se Berechtigungskriterien unmittelbar an die InfoCubes zu hef-
ten. Dann muss aber sichergestellt sein, dass die auf diesen Info-
Cubes erstellten Queries nur fUr den vorgesehenen Anwender-
kreis gelten. Bei dieser Vorgehensweise ist Vorsicht geboten,
denn SAP BW wird nach dem Go-Live erfahrungsgemaB stets urn
neue Queries und InfoCubes erweitert. Inhalte der InfoCubes
werden dann auch von anderen Anwendern mit unterschiedli-
chen Berechtigungen verwendet. Dann muss ein neuer InfoCube
mit teilweise identischem Inhalt aufgebaut werden, was zusatzli-

14 MultiCube = Kombination zweier oder mehrer InfoCubes

15 Go-Live = Zeitpunkt, an dem das konfigurierte, eingestellte (BW-
)System fUr das Tagesgeschaft im Unternehmen zuganglich gemacht
wird

244
 Daniel Ramisch

chen Aufwand und Speicherplatz in Anspruch nimmt. Zudem

wird die BW - Struktur zunehmend unubersichtlich.

Berechtigungs- Bei der Berechtigungspflege ist es aus diesen Grunden sicherlich

pflege sinnvoller, Berechtigungen an die Rollendefinition zu heften. So
steht der Inhalt aller InfoCubes grundsatzlich allen Anwendern
zur Verfugung, uber die jeweilige Rolle werden dann jeweils nur
die Rechte auf einzelne Queries vergeben. Durch diese Methode
entsteht mehr Flexibilitat, die Datenredundanz im BW reduziert
sich, der Pflegeaufwand von Datenspeicher und Data Sources
sinkt. Ware dann ein Anwender uber seine Berechtigung im Ver-
lauf seiner Arbeit eingeschrankt, kann er leicht zusatzliche Rollen
und damit erweiterte Berechtigungen erhalten.
Namenskonven- Ein weiterer Punkt sind die Namenskonvention in SAP R/3, SAP
tion BW und den Non-SAP-Systemen. Muhsam haben sich die An-
wender bei Einfuhrung des SAP R/ 3-Systems an neue Benen-
nungen gewbhnt. Nun tritt diese Eingewbhnungsphase ebenfalls
mit Einfuhrung des SAP BW wieder in Erscheinung. Ungleich
schwerer wird es dem Anwender dadurch gemacht, dass im SAP
BW auch Konventionen aus Non-SAP-Systemen und evtl. noch
AP016 aufeinandertreffen. Dies kann ohne Erklarung zu enor-
men Problemen fuhren . Die Daten der Auswertung befinden sich
im BEx Analyzer, die Bedeutung ist aber meist unklar. Hier ist
schon wahrend der Implementierungsphase des SAP BW eine
Art Dbersetzungstabelle (Glossar) notwendig, die SAP R/ 3 bzw.
Non-SAP Daten werden den Namenskonventionen aus dem SAP
BW gegenubergestellt. Dies erleichtert die Arbeit mit SAP BW
nach dem Go-Live.
Glossar Es ist sinnvoll, das Glossar innerhalb des Implementierungspro-
zesses zu erstellen, denn so lite es im Nachhinein aus einem Fertig
gepflegten System heraus erzeugt werden, ist die Dbersicht ge-
ringer, wodurch sich auch der zeitliche Aufwand erhbht. Doku-
mentation der Customizingschritte und Glossar der Namens-
konventionen sollten in Kombination miteinander angefertigt
werden.
Obwohl SAP BW uber die redundante Datenstruktur zwischen
Produktivsystem und BW Reportingtool eine Performanceverbes-
serung des SAP R/3 sicherstellt, ist die Performance im BW Sys-
tem selbst schnell in einem nur noch schwer akzeptablen Be-

16 APO = Advanced Planner and Optimizer; SAP Add-On zu SAP Rl3

245
Einfuhrung von SAP BW in der Prozessindustrie

reich angelangt. Bei einem heterogenen Datenmodell von ODS,

InfoCubes und MultiCubes zur Abbildung von Geschaftsprozes-
sen wird die Antwortzeit des BW zur Auswertung einer Query
inakzeptabel. Da der OLAp17 Prozess bei jeder Veranderung der
Ansicht von MS Excel zuri.ick auf die Datenspeicher im SAP BW
zuri.ickgreift, ist das Reporting in manchen Fallen aulSerst mi.ih-
sam und zeitraubend.

Business Explorer

I Query DelioWon J I Analyzcr I

Microsoft Excel

I OLAP Engine
I
~ ,",.co,", ODS

Business Information Warehouse Server

Abbildung 122: OLAP Prozess

Zur LOsung sind grundsatzlich zwei Gesichtspunkte zu betrach-

ten:
1. Performanceverbesserung durch geeignete Hardware-
voraussetzungen bestenfalls zu Beginn des BW Projek-
tes . Dazu zahlen ein Multiprozessorsystem mit hoher
CPU-Speed, ausreichend Arbeitsspeicher und Festplatten
mit schneller Zugriffszeit und ausreichend Speicherplatz.
2. Diese Investition wird sich bereits kurzfristig durch gute
Performance rentieren. Mittel- bis langfristig werden BW-
Systeme schnell wachsen, daher ist mit der Wahl eines

17 OLAP = On Line Analytical Processing; BW Prozess zur Datenbereit-

steHung im BEx Analyzer

246
 Daniel Ramisch

effizienten, groBzugig dimensionierten Hardwaresystems

eine hohe Auswertungsgeschwindigkeit langfristig si-
chergestellt.
3. Aggregation von InfoCubes schon wahrend der Imple-
mentie-rungs-, Support- und Systemtestphase des Projek-
tes in Zusammenarbeit mit den Anwendern. Viele stan-
dardisierte Reports verlangen im meist gleiche Stamm-
und Bewegungsdaten. Damit bei jedem Reportaufruf
diese Daten nicht immer erneut uber den OLAP-Prozess
zusammengestellt werden mussen, ist es hier ratsam,
standig wiederkehrende Datenselektionen von vorne-
herein zu aggregieren. Dadurch werden Zugriffsge-
schwindigkeiten und Bearbeitungszeiten optimiert.

5 Go-Live und Service

Informationsmechanismen wie beispielsweise Auswertungen auf
Datenbanken oder Excel-Sheets, die fUr lange Zeit als Entschei-
dungsbasis herangezogen wurden, werden mit der EinfUhrung
von SAP BW als Standard Reportingtool abgelbst. Diese Umstel-
lung ist anwenderbezogen schwer zu realisieren. Das neue, stan-
dardisierte Data Warehouse wird anwendungstechnisch noch
nicht uberblickt, die Vorteile sind zu Beginn nur schwer zu er-
kennen .
So macht es wenig Sinn, die abzulbsenden Informationsmecha-
nismen unmittelbar nach dem Go-Live abzuschalten. Die Gefahr
bei dieser Vorgehensweise wird durch folgende Punkte transpa-
rent:
Systemoptimierung und spezielle Anpassungen im SAP
BW nehmen nach dem Go-Live noch Zeit in Anspruch,
in dieser Zeit muss das Tagesgeschaft aber weiter abge-
wickelt werden kbnnen.
In der Umstellungsphase mussen dem Anwender beide
Informationsmechanismen zur Verfugung bleiben, damit
eine Eingewbhnung in SAP BW reibungslos sicher-
gestellt werden kann.
Es empfiehlt sich, die abzulbsende Informationsbasis einen vor-
her festgelegten Zeitraum lang parallel zu SAP BW laufen zu las-
sen. Bei einfUhrungsbedingten Engpassen im SAP BW kann auf
die originaren Informationsmechanismen zuruckgegriffen wer-
den . Zudem wird eine gleitende Umstellung positiv aufgenom-

247
Einfiihrung von SAP BW in der Prozessindustrie

men, da der Anwender seine langjahrige Informationsbasis erst

nach und nach verlasst.
Die angesprochene Vorgehensweise sorgt fUr eine reibungslose
Umstellung der Auswertungsmethodik bei dem neuen Tool.
Go-Live Nach dem Go-Live ri.icken Service und Support in den Vorder-
grund. Eine weitere Zusammenarbeit mit externer Beratung bie-
tet den Vorteil, ilber Releasewechsel und die damit verbundenen
Neuerungen und Erweiterungen informiert zu sein. Eine enge
Verzahnung von externem und internem Mitarbeiter unterstiltzt
das Data Warehouse mit Hinblick auf neue Features in Kombina-
tion mit neuen Anforderungen an ein wachsendes Reportingtool.
Durch eine enge Bindung von Service und Support an die An-
wenderseite wird sichergestellt, dass Veranderungen und Erwei-
terungen seitens der Entwicklung den Zielen der Anwender ent-
sprechen. Anforderungen aus dem Tagesgeschaft kbnnen umge-
kehrt direkt an das Entwicklungsteam weitergeleitet werden, urn
eine kurze Bearbeitungsdauer und hohe Effizienz einzuhalten.

6 Schulungskonzepte
Benutzerakzep- Bei Anwenderschulungen oder Coachingmassnahmen ist darauf
tanz zu achten, Interesse am neuen Auswertungssystem zu erzeugen.
Dies ist manchmal mit unvorhersehbaren Schwierigkeiten ver-
bunden. Einige Anwender haben abgeloste Informationsmecha-
nismen selbst entwickelt oder im Hinblick auf unternehmensspe-
zifische Anforderungen hin optimiert. Dieser Anwenderkreis ist
erfahrungsgemaB nur schwer von dem standardisierten SAP BW
zu uberzeugen.
Eine soleh ablehnende Haltung gilt es zu durchbrechen. Die
Voraussetzung, das zu erreichen, ist ein fehlerfreies Schulungs-
system und aktuellste Daten. 1m Informations- und Auswer-
tungsbereich sind richtige, aktuelle Daten ein unmittelbares Ent-
scheidungskriterium, da Anwender aus dem Tagesgeschaft her-
aus am besten wissen, welehe Werte richtig sind. Daran wird in-
nerhalb der Schulung die Qualitat des SAP BW unmittelbar be-
messen. So ist vor dem Schulungstermin sicherzustellen, dass zu
prasentierende Queries qualitativ hochwertige Daten vorweisen
kbnnen. Dann ist Interesse und hohe Akzeptanz sichergestellt.
Die Schulung sollte entsprechend der Rolle der zu schulenden
Endanwender erfolgen. Dadurch kann der Inhalt der Schulung
auf die Auswertungen zugeschnitten werden, die Teilnehmer

248
 Daniel Ramisch

konnen sicher sein, auf aile Reports benutzerrrechtlich zugelas-

sen zu sein.
Wahrend der Schulung ist mehr Wert auf Nutzung und Bediener-
freundlichkeit des Systems zu legen als auf den technischen Auf-
bau des SAP BW. Die Teilnehmer mussen ihr Tagesgeschaft mit
dem neuen Tool durchfOhren, deshalb ist ihnen auch daran ge-
legen, dies zugig in Angriff zu nehmen.
Einsatz von Bei der SchulungsdurchfOhrung hat es sich als auBerst nutzlich
Key-Usern erwiesen, Key-User in Kombination mit Beratern gemeinsam
vortragen zu lassen . Der Key-User ubernimmt dabei den fachli-
chen, unternehmerischen Hintergrund, da er sich mit speziellen
Gegebenheiten im Unternehmen gut auskennt und unterneh-
mensspezielle Fragestellungen beantworten kann. Gleichzeitig
kann der Berater auf technische Aspekte eingehen, auf Bedie-
nungselemente hinweisen, Experteneinstellungen und zusatzli-
che Features anbieten, die den Umgang erleichtern und Daten
besser aufbereiten.
Urn den Teilnehmern nach dem Coaching das Arbeiten mit dem
SAP BW zusatzlich zu erleichtern, sollen innerhalb der Schulung
Ansprechpartner genannt werden, die in der Startphase des Data
Warehouse zur Seite gestellt werden konnen.

7 Arbeiten mit SAP BW

Nutzung von Beim tag lichen Umgang mit SAP BW ist fur Key-User und End-
vorhandenem anwender die Benutzeroberflache in MS Excel (BEx Analyzer)
Know-how sehr nutzlich. Der Anwender erhait mit SAP BW keine unbe-
kannte Arbeitsumgebung, vielmehr kann er mit dem BEx Analy-
zer sofort auf sein Wissen beim Umgang mit MS Excel zuruck-
greifen.
Durch die bei der Implementierung eingestellten Rollenzugriffs-
rechte hat der Anwender Zugriff auf seine relevanten standardi-
sierten Reports, die er innerhalb Excel auf Queryebene dyna-
misch anpassen kann. Diese Anpassungsmoglichkeit wird ihm
uber die so genannte BW-Funktionalitiit ermoglicht, die uber
ein BW Makro zur VerfOgung gestellt wird.

249
Einfiihrung von SAP BW in der Prozessindustrie

SAP BUSIness Explorer I:l

Abbildung 123: Funktionsleiste des BEx Analyzers (Makro)

BEx Analyzer Innerhalb MS Excel kbnnen Auswertungen, die fUr das Tagesge-
schaft notwendig sind, unter dem "Favoriten" - Ordner abgelegt
werden. Dies ist fUr modifizierte Standardauswertungen eine gute
Mbglichkeit, sofortigen Zugriff auf wichtige Reports zu erhalten,
ohne sich muhsam durch Verzeichnisbaume arbeiten zu mussen.
Leider ist es innerhalb des BEx Analyzers nicht mbglich, diese
Favoritenordner anzulegen oder abzuandern. Von dort ist Ie dig-
lich ein Aufruf der Favoriten mbglich . Fur den Anlege- / Ande-
rungsschritt wird der BEx Browser18 benbtigt.
Wichtig im Umgang mit den Daten im BEx Analyzer ist auch,
dass sie zumeist nicht zeitpunktgenau ubermittelt werden. Der
Datenabgleich bzw. die Aktualisierung wird uber ein Update zu
Voreingestellten Tages-, Wochen- oder Monatszeitraumen voll-
zogen. Dies geschieht als Hintergrundjob meist nachts, wenn das
Produktivsystem yom Tagesgeschaft entlastet ist. Somit gibt es
keine absolute Aktualitat der Daten.

FOr zeitpunktgenaues Reporting existiert im BW die Mbglichkeit

eines "Drill through", eines Reportings auf Datenbankebene des

18 BEx Browser = Business Explorer Browser; in SAP BW enthaltenes

Programm zum Starten des BEx Analyzers und Anlegen von Favoriten-
ordnern, entfernt vergleichbar mit einem Internet Browser

250
 Daniel Ramisch

Quellsystems. Diese Vorgehensweise ist nur in Ausnahmefallen

nutzlich, da Nachteile in Bezug 20 Performance von SAP R/3 und
SAP BW zu erwarten sind.

8 Fazit
In einer wachsenden DV Struktur birgt der Einsatz eines Data
Warehouse in Unternehmen erhebliche bkonomische und strate-
gische Vorteile, da die Information einen immer hbheren Stel-
lenwert 20m Unternehmenserfolg beitragt.
SAP BW tragt durch die Entkopplung von Informations- und
Produktivsystem unmittelbar lOr Performanceverbesserung des
Produktivsystems bei und vereinigt Daten verschiedenster Quell-
systeme in einer Oberflache. Die damit einhergehende Zeiter-
sparnis des Datensammelns und Gegenuberstellens reduziert sich
auf ein Minimum und erhalt die Flexibilitat des Unternehmens.
Durch erhbhte Flexibilitat, die von Marktseite yom Unternehmen
erwartet werden, sind Ad-hoc-Analysen und auf aktuellsten Da-
ten basierende Planungen fur den Absatz und Produktion essen-
tiell. Hier gibt SAP BW mit seinen flexiblen Navigationsmbglich-
keiten innerhalb des BEx Analyzers gute Ansatzpunkte zur
schnellen, tagesgenauen Informationszusammenstellung, wenn-
gleich auch die OLAP - Zeiten innerhalb des BW verbesse-
rungswurdig erscheinen.
Auf Unternehmerseite stellt sich in der heutigen wirtschaftlichen
Situation nicht mehr die Frage, ob ein Data Warehouse sinnvoll
ist oder nicht, sondern eher die, ab wann ein solches Tool ein-
gesetzt werden solI. 1st die IT-Infrastruktur so komplex gewor-
den, dass Informationssuche, Gegenuberstellung und Auswer-
tung die Flexibilitat der Unternehmung veriangsamen, ist spates-
tens dann die Entscheidung fUr ein Data Warehouse zu fallen .
Durch die einfache Darstellungsweise in MS Excel hat sich das
SAP BW einen Vorsprung gegenuber anderen Anbietern ver-
schafft. Dadurch sinkt die Einarbeitungszeit in das Auswertungs-
tool auf ein akzeptables Mag, das Tagesgeschaft ruckt in den
Vordergrund.
Bei einem hohen, standardisierten Nutzungsanteil von SAP R/3
als Datenbasis kann der Implementierungsaufwand von SAP BW
auch uber den Business Content vergleichsweise gering gehalten
werden und damit kurzfristig fUr den unternehmerischen Erfolg
sorgen. Der Anpassungsaufwand erhbht sich jedoch zusehends,

251
Einfuhrung von SAP BW in der Prozessindustrie

je hoher der Stellenwert einer Integration von Non-SAP Systemen

wird.
1st vor der SAP BW EinfUhrung ein gut strukturiertes Konzept
vorhanden, das auch Hardwaregegebenheiten und Datenmodelle
unternehmensspeziell abbildet, so ist eine akzeptable Ein-
flihrungszeit zu erreichen.
Somit stellt das SAP BW im Hinblick auf die heutigen wirtschaft-
lichen Veranderungen eine sinnvolle Alternative zu den bisheri-
gen Reportingmoglichkeiten im Unternehmen dar, wenn man
den Aufwand zu dessen Einsatz abzuschatzen versteht.

9 Literaturverzeichnis
BUCK-EMDEN; R./GALIMOV, j.: Die Client/Server-Technologie des SAP
Systems R13, Addison-Wesley Verlag 1995.
KEMPER, H. G.: Business Intelligence - ein Wegweiser, Com-
puterwoche 44/2002.
SAP: SAP Business Information Warehouse im Oberblick, White
Paper 2000.
VON MAUR, E.: SAP BW - bei Standardgr6jSen eine Wahl, Com-
puterwoche 44/2002

252
 Autorenverzeichnis

Autorenverzeichnis

Detlev Frick

T-Systems International GmbH

SAP Consulting und Dokumentenmanagementsysteme
Service Line Systems integration
Entwicklungszentrum Rhein-Ruhr
Hausadresse: Ruhrallee 307-309, 45136 Essen
Postanschrift: Postfach 10 11 07, 45011 Essen

Tel.: +49-201 -807-2389

Detlev Jrick@t-systems.com
http://www.t-systems.com

Dr. Detlev Frick war er aIs wissenschaftlicher Mitarbeiter an der

Ruhr Universitat Bochum tiitig. Anschlie8end sammelte er Erfah-
rungen aIs IT-Berater. Bei der Deutschen Telekom war er einige
Jahre als Projektleiter in der Softwareentwicklung beschiiftigt. 1m
konzernweiten Informationsmanagement war er fUr den Bereich
der Methoden und Standards verantwortlich. Derzeit leitet er eine
SAP-Beratergruppe bei der T-Systems Nova in Essen.

253
Autorenverzeichnis

Andreas Gadatsch

Fachhochschule Bonn-Rhein-Sieg
Grantham-Allee 20, 53757 Sankt Augustin

www.fh-bonn-rhein-sieg.de

Prof. Dr. rer. pol. Andreas Gadatsch, Jahrgang 1962, studierte

nach einer Ausbildung zum Industriekaufmann zunachst Be-
triebswirtschaftslehre an der Fachhochschule Kaln. AnschlieBend
studierte er nebenberuflich Wirtschaftswissenschaften an der
FernUniversitat Hagen und promovierte dort als externer Dokto-
rand am Lehrstuhl fUr Wirtschaftsinformatik.
Er war von 1986-2000 in verschiedenen Unternehmen CMaschi-
nen- und Anlagenbau, Beratung, Telekommunikation) tatig. Zu-
letzt war er Leiter Arbeitsplatzsystem-Management und IT-
Sicherheit im zentralen Informationsmanagement der Deutschen
Telekom AG.
Zum WS 2000/2001 nahm er einen Ruf auf eine Professur fur be-
triebswirtschaftliche Organisation und Datenverarbeitung an der
Fachhochschule Kaln an. Zum SS 2002 folgte er einem Ruf auf
eine Professur fUr Betriebswirtschaftslehre, insb. Wirtschaftsin-
formatik an die Fachhochschule Bonn-Rhein-5ieg, 5t. Augustin.
Die aktuellen Lehr- und Arbeitsgebiete sind Betriebswirtschaftli-
che 5tandardsoftware, Geschaftsprozess-, Workflow- und Wis-
sensmanagement, IT-Controlling und Informationsmanagement.

254
 Autorenverzeich nis

Alexander Goerke

SER Technology Deutschland GmbH

Stegenerstr. 17 A, 79199 Kirchzarten

www.ser.de

Dr. Alexander Goerke, studierte Physik an der Universitat Frei-

burg und promovierte dort auch zu einem Thema aus der Mole-
kiHsimulation. Er wechselte dann in die Softwarebranche und
beschaftigte sich seit 1991 mit dem Thema der elektronischen
Dokumentenverarbeitung, insbesondere der automatischen Er-
kennung von Dokumenten. Er entwickelte mit seinem Team ein
Formularlesesystem fUr Banken bei dem Unternehmen ip-
Systeme, wechselte dann als Entwicklungsleiter zu Parsytec in
Aachen Cheute Docutec) . Danach wurde er Entwicklungsleiter
bei dem osterreichischen Unternehmen improx wo der erste
Freiformleser entstand.
Seit 1999 ist Dr. Goerke Bereichsleiter bei der SER Technology
GmbH, die als Teil der SER Systems AG ein fuhrender Hersteller
von DMS und KM-Systemen ist. Er ist dort verantwortlich fur die
Produkte SERdistiller, SERcapture und SERdistiller. Anschrift: SER
Technology GmbH, Stegenerstr 17a, 19199 Kirchzarten,

255
Autorenverzeichnis

UrsulaGraf

ML Consulting GmbH
Max-Planck-Str. 39
D 50859 K6ln

http:// www.mlconsulting.de

Frau Ursula Graf , Personalfachkauffrau, Jahrgang 1950 ist seit 20

Jahren mit dem Thema Bildung vertraut. Wiihrend ihrer Tiitigkeit
als SAP-Dozentin, der Mitarbeit in Ptiifungsausschilssen der IHK
K6ln sowie als Lehrbeauftragte an der FH K61n, wurde Frau Graf
mit den Problemen der Aus- und Weiterbildung im IT-Umfeld
konfrontiert und erarbeitete Schulungskonzeptionen unter Einbe-
ziehung der IT-gesteuerten Tools, z.B. SAP R/ 3.

Seit 2 Jahren leitet sie den Bereich SAP innerhalb der ML Consul-
ting GmbH .

256
 Autorenverzeichnis

Albert Hesmer

ML Consulting GmbH
Max-Planck-Str. 39
D 50859 K61n

http://www.m1consulting.de

Als Entwickler und Berater verfugt Herr Hesmer, Jahrgang 1964,

uber eine langjahrige Erfahrung in der Informationstechnologie.
Er ist ABAP/ 4 Workbench 2000 zertifiziert.
Unter seiner Projektmitarbeit und -leitung konnte eine Vielzahl
von Projekten erfolgreich abgeschlossen werden.
1m Bereich der SAP R/ 3 Entwicklung, Schulung und dem Aufbau
von E-Learning Systemen setzt er u.a. den SAP iTutor ein.
Durch seine Erfahrung als Dozent ist er in der Lage, gezielt die
Bedurfnisse der Anwender im E-Learning umzusetzen.

257
Autorenverzeichnis

WoUgang Hohnel

IBM Deutschland GmbH

www.ibm.de

Diplom Betriebswirt (BA) Wolfgang Hahnel ist als IT Architekt

bei der IBM Deutschland und als Lehrbeauftragter an der Fach-
hochschule Bonn-Rhein-Sieg tatig. Sein aktuelles Aufgabenfeld
umfasst den Aufbau und das Management von Unternehmens-
modellen, die Konzeptionierung von Data Warehouse Lasungen,
so wie die Gestaltung von graBen fachlichen Geschaftsanwen-
dungssystemen in der Finanzdienstleistungsindustrie.

258
 Autorenverzeichnis

Andreas Kraft

RWE Systems AG
Flamingoweg 1, 44139 Dortmund

www.rwesystems.de

Dipl. Kfm. Andreas Kraft, geb. 1963 in Witten, ist Mitarbeiter der
RWE Systems AG in Dortmund.
Nach der Ausbildung zum Bankkaufmann und dem Studium der
Wirtschaftswissenschaften in Dortmund arbeitet er seit 1993 in
den Bereichen Logistik, Einkauf und Materialwirtschaftscontrol-
ling.
Seine Tatigkeitsschwerpunkte lagen im Aufbau eines Lagerwirt-
schaftsinformationssystems, in der Realisierung von Beschaf-
fungsprojekten im Rahmen des Supply Chain Managements und
in der Implementierung des Materialwirtschaftscontrollings.
Heute leitet er die Abteilung Materialwirtschaftscontrolling

259
Autorenverzeichnis

Arno Kiihn

TDy Rheinland Holding AG

51105 Kaln, Am Grauen Stein

WWW.TUY.com

Dipl.-Betriebswirt Arno Kuhn, Jg. 1949, nach Ausbildung zum

1ndustriekaufmann Studium der Betriebswirtschaftslehre an der
FH Niederrhein sowie Wirtschaftspadagogik und 1nforma-
tik/ Organisationslehre an der Universitat Kaln.

Langjahrige Erfahrung als Projektleiter und Abteilungsleiter An-

wendungsentwicklung bei der Unternehmensgruppe TDy Rhein-
land/ Berlin-Brandenburg. Lehrbeauftragter am Fachbereich 1n-
formatik der FH Bonn-Rhein-Sieg mit den Schwerpunkten "Archi-
tektur und Anwendung von Standardsoftware" sowie Geschafts-
prozessoptimierung" .

260
 Autorenverzeichnis

Dieter Liinebach

ML Consulting GmbH
Max-Planck-Str. 39
D 50859 K6ln

http://www.mlconsulting.de

Herr Dieter Ltinebach, Jahrgang 1968, ist staatlich gepriiften Be-

triebswirt. Wahrend seiner Ausbildung bei der Rheinische Aka-
demie in K6ln bildete er sich in den Bereichen Unternehmens-
analyse und Controlling weiter. 2001 absolvierte er die Fortbil-
dung zum SAP-Berater und Trainer.
Er war von 1986 bis heute in verschiedenen Unternehmen
CGroB- und Einzelhandel, Offentlicher Dienst, Consulting) tatig.
Zur Zeit ist er als SAP-Berater und Trainer, bei dem Unterneh-
men ML Consulting in K61n, tatig.
In seiner aktuellen Projekttatigkeit wurde ein e-Learning-Portal
fUr ca. 2000 Mitarbeiter eines bundesdeutschen Unternehmens
eingerichtet.

261
Autorenverzeichnis

Reinhard Mayr

Fachhochschule K61n
Betzdorfer Str. 2, 50679 K61n

www.fh-koeln.de

Prof. Dr.-Ing. Reinhard Mayr, Jahrgang 1947, studierte nach einer

Ausbildung zum Maschinenschlosser zunachst Maschinen-
bau/Konstruktion an der FH Paderborn und anschliefSend Ma-
thematik und Informatik an der Technischen Universitat Berlin.
Ab 1996 Assistent am Institut fur Werkzeugmaschinen und Ferti-
gungstechnik der TUB. In dieser Zeit Leiter der 3D-CAD For-
schung am Institut. Promotion 1979.

1979 Griindung der System Consult GmbH in Berlin. 1980 Wech-

sel in die Firma. Zunachst Tatigkeit als Entwicklungsleiter fUr
CAD-Applikationssoftware. Ab 1981 Prokurist und Seniorberater
fUr CAD-Einsatz in der Automobilindustrie. 1990 Wechsel zur
VW-Gedas GmbH in Berlin Cheute gedas GmbH) mit Tatigkeiten
als Entwicklungs- und Vertriebsleiter fUr PDM-Systeme.

Zum Sommersemester 1995 nahm er den Ruf an die Fachhoch-

schule K61n mit dem Lehrgebiet Datenverarbeitung im Fachbe-
reich Produktionstechnik an.

Die aktuellen Lehr- und Arbeitsgebiete sind Computer und

Netzwerke, Ingenieursysteme und Kommunikationsstandards,
Geschaftsprozesse der Produktion, sowie ERP-Systeme und Soft-
wareentwicklung.

262
 Autorenverzeich nis

Stefan Mollemann

T-Systems International GmbH

Ruhrallee 307-309, 45136 Essen

www.t-systems.com

Herr Stefan M611emann sammelte seine ersten Erfahrungen mit

der Standardsoftware SAP im Konzern Deutsche Telekom, als er
fur das Auftragsabwicklungssystem AWI-T Konzepte und Anfor-
derungen formulierte. 1m Anschluss daran wechselte er fi.ir ein
Jahr in die Individualentwicklung. Daran anschlieBend folgte ei-
ne halbjahrige SAP-Ausbildung in der Schweiz . Seit etwa zwei
Jahren leitet er verschiedenste SAP-Projekte (SD/ MM / CRM).

263
Autorenverzeichnis

Andreas Oberborsch

Deutsche Telekom AG
Kavalleriesand 3, 64295 Darmstadt

www.telekom.de

Dip!. Kfm. (FH) Andreas Oberborsch, geb. 1975 in Remscheid,

war Mitarbeiter der RWE Systems AG in Dortmund.

Nach praktischen Tatigkeiten im Rahmen des Studiums am Fach-

bereich Wirtschaft der FH-Koln in operativen und strategischen
Einkaufsfunktionen, bei der den OBI Bau & Heimwerkermarkten
und der Henkel KGaA folgte die Diplomarbeit mit dem Thema
"Konzeption eines Executive-Information-System fi.ir den Funkti-
onsbereich Einkauf am Beispiel des Konzern-Einkaufs-Infor-
mations-Systems (KEIS) des RWE-Konzerns, basierend auf dem
'Business Information Warehouse' der SAP AGI!.

Sein Tatigkeitsschwerpunkte bei der RWE Systems AG lagen im

Bereich der Vermarktung von Materialwirtschaftsdienstleistungen.
Heute arbeitet er bei der Deutschen Telekom AG im Zentralbe-
reich Billing Services als SAP-Projektleiter.

264
 Autorenverzeichnis

Daniel Rarnisch

Diplom-Ingenieur Daniel Ramisch ist Consultant SAP Automotive

/ SAP Business Information Warehouse.

265
Autorenverzeichnis

Hubert Robens

Vodafone Information Systems

Rehhecke 50, 40885 Ratingen

www.vodafone-is.de

Dipl. Informatiker Hubert Robens, geb. 1962 in Neuss, studierte

nach dem Abitur Informatik an der Technischen Hochschule Aa-
chen.
Ab 1991 entwickelte er bei der Firma ComConsult in Aachen ei-
ne Software zur Dokumentation von Netzwerken (LAN, WAN).
Er war insbesondere als Spezialist fUr das Datenbankdesign zu-
stindig.
1996 wechselte er zur Vodafone Information Systems Cdamals
noch Mannesmann Datenverarbeitung) in den Bereich des SAP
Hostings. Dort ist er zur Zeit Stellvertreter des Abteilungsleiters
und fUr die Betreuung von mehreren Rl3-Systemlandschaften zu-
standig.

266
 Autorenverzeichnis

Dirk Schreiber

Fachhochschule Bonn-Rhein-Sieg
Grantham Allee 20, 53757 St. Augustin

www.fh-bonn-rhein-sieg.de

prof. Dr. rer. pol. Dirk Schreiber ist Professor fUr das Fachgebiet
Wirtschaftsinformatik an der Fachhochschule Bonn-Rhein-Sieg.

Zuvor war er mehrere Jahre als IT-Berater, Projektmanager und

Abteilungsleiter in der mittelstandischen Industrie sowie bei ei-
nem Unternehmen der Finanzdienstleistungsbranche tatig.

Seine Lehr- und Arbeitsgebiete sind Daten- und Geschaftspro-

zess-Management sowie der Einsatz von betriebswirtschaftlicher
Standardsoftware, insbesondere in mittelstandischen Unterneh-
men.

267
Autorenverzeichnis

Ullrich Svenson

DV-ORG Team GmbH

Monschauer Str. 44, 41061 M6nchengladbach

www.dv-org.de

Dip!. Phys. Ullrich Svenson, geb.1968 in G6ttingen studierte nach

dem Abitur Physik und Informatik an der University of Delaware
und der Universitat G6ttingen.
1994 SAP Basisberater bei Unternehmensberatung Zuendel &
Partner, Mitglied im Technical Core Competence Center der SAP
in Walldorf, seit 1996 bei Unternehmensberatung DV-ORG Team,
derzeit als Leiter des Geschaftsbereichs SAP-Basisberatung und
ABAP-Entwicklung'.

268
 Autorenverzeichnis

RalfThomas

SYSTOR Software Beratung GmbH

Max-Planck-StralSe 39 B, 50858 K61n

www.ssb-gmbh.de

Dipl.-Ing. Ralf Thomas, geb . 1973 in Wermelskirchen, studierte

nach Schule und Lehre als Werkzeugmechaniker an der FH K61n
Maschinenbau Fachrichtung Fertigungstechnik. In der Zeit ver-
schieden Praktika in IT-Bereichen und Programmierung sowie
ein Praxissemester in Irland mit Thema der Einbindung des ge-
richteten Materialflusses in den Fertigungsprozess.

Ab 1999 SAP-Berater bei der SYSTOR Software Beratung GmbH

K61n Cehemals Schumann Software Beratung GmbH). Tatigkeiten
in den Bereichen PP, Entwicklung, und APO in den Brachen Au-
tomotiv, Fertigungsindustrie und Chemische Industrie.

269
Autorenverzeichnis

Wilhelm Thygs

Sachtleben Chemie GmbH

Postfach 17 04 54, D-47184 Duisburg

www.sachtleben.de

Wilhelm Thygs, geb. 1953 in Nordkirchen, studierte nach Schule

und Lehre an der FH - Dortmund "Elektrische Energietechnik"
und an der TU - Berlin "Allgemeine Elektrotechnik" mit dem
Schwerpunkt der Automatisierungstechnik.
Nach dem Studium begann er 1972 als Planungsingenieur bei der
Cerestar Deutschland GmbH in Krefeld, wo er 1981 die Leitung
der Werkstatten fUr Elektro- Mess- und Regeltechnik ubernahm.
Seit 1989 ist er bei der Sachtleben Chemie GmbH in Duisburg ta-
tig und heute fur die zentrale Ingenieur- und Verfahrenstechnik
verantwortlich.

270
 Gesamtliteraturverzeichnis

Gesamtliteraturverzeichnis
Aichele, Ch.; Elsner, Th.; Thewes, K-J.: Optimierung von logistik-
prozessen aUf Basis von Referenzmodellen. In: M&C Manage-
ment & Computer, 2.Jg., 1994, Heft 4, S. 253-258.
Bach, N.; Homp, Ch.: Objekte und Instrumente des Wissensmana-
gements, in ZfO 611997, S.340-347.
Brinkmann, S.; Zeilinger, A.: Finanzwesen mit SAP Rl3, Betriebs-
wirtschaftliches Customizingwissen fur SAP Rl3-FI, Bonn,
2000.
Buck-Emden; R./Galimov, j.: Die Clientl Server-Technologie des
SAP Systems Rl3, Addison- Wesley Verlag 1995.
Buxmann, P.; Konig, W.: Zwischenbetriebliche Kooperation auf
Basis von SAP-Systemen - Perspektiven fur Logistik und Servi-
cemanagement, Berlin - Heidelberg 2000.
Buzan, T; Buzan, B .: Das Mind-map-Buch, Landsberg am Lech
1997.
Chamoni P.; Gluchowski P.: Analytische Informationssysteme,
Berlin - Heidelberg - New York, 1999.
Davenport, Th :; Prusak, 1.: Wenn ihr Unternehmen wujSte, was
es alles weiss ... : das Praxisbuch zum Wiessensmanagement.
Landsberg/Lech, 1998.
Dolmetsch, R.; Huber, T; Fleisch, E.; Osterle, H: Accelerated SAP,
4 Case Studies, Arbeitsbericht, Institut fur Wirtschaftsinforma-
tik, Universitdt St. Gallen, Hochschule fur Wirtschafts-, Rechts-
und Sozialwissenschaften (HSG), St.Gallen, 1998.
Dorr, A. et al.: HTML-basierte Lernumgebung ABAPI4, Projektdo-
kumentation, FH Koln, Fachbereich Produktionstechnik 2001.
Eppler: Prdsentation Knowledge Mapping, 1999
Fels, T: Erstellung eines Vorgehenskonzeptes zur Evaluierung ei-
ner graphischen Werkerfuhrung unter SAP Rl3, Diplomarbeit
2000
Fleisch, E.; Pohland, S.; Schelhas, K-H; Osterle, H: Entwicklung
einer Informationssystemarchitektur. In: HMD Praxis der
Wirtschaftsinformatik, Heft 202, 1998, S. 85-1OJ.
Fleisch, E.; Pohland, S.; Sch elh as, K-H.; Osterle, H.: Entwicklung
einer Informationssystemarchitektur. In: HMD Praxis der
Wirtschaftsinformatik, Heft 202, 1998, S. 85-1OJ.
Frank, A., Schmidt, Th., Schrodel, 0 .: Business Reengineering als
Wegbereiter einer erfolgreichen Standardsoftware-Einfuhrung.
In: HMD, Heft 198, November 1997, S. 41-50.

271
Gesamtliteraturverzeichnis

Gadatsch, A.: Business Intelligence, Integration von Data Ware-

housing und Wissensmanagement. In: Erfolgreiche Computer-
praxis, Gruppe 60nline-Dienste, Heft 5,2001, S. 169-174.
Gadatsch, A.: IT-gestutztes Prozess-Management im Controlling.
In: Freidank, C.-Ch. (Hrsg.J; Mayer, E.: Controlling Konzepte.
Werkzeuge und Strategien fur die Zukunft, 5. Auflage, Wies-
baden, 2001.
Gadatsch, A.: Management von Geschiiftsprozessen, Methoden
und Werkzeuge fur die IT-Praxis. Eine Einfuhrung fur Stu-
denten und Praktiker, Braunschweig und Wiesbaden, 2. Aufl.
2002.
Gadatsch, A.: Finanzbuchhaltung und Gemeinkostencontrolling
mit SAP. Methodische Grundlagen und Fallbeispiele mit SAP
Rl3@, Braunschweig!Wiesbaden, 2001.
Gadatsch, A.; Humpert, K-D.; Weis, T.: Doppelstrategie fur die
Deutsche Telekom, Rl3-Einsatz schwerpunktmiijSig im kauf-
miinnisch administrativen Bereich, SAP-Info Special, Heft 1,
1997, S. 22-25.
Ganser, A. (Hrsg.J: Vorgehensmodell der Deutschen Telekom,
Entwicklung ind Instandhaltung von komplexen Softwaresys-
temen, Munchen, Wien, 1996.
Gehring, H, Gadatsch, A.: Ein Rahmenkonzept fur die ProzejS-
modellierung. In: Information Management & Consulting,
Heft 4, 1999, S. 69-74.
Heisig, P.: Business Process Oriented Knowledge Management, in
Mertens, K., Heisig, P., Vorbeck, ]. (Eds): Knowledge Manage-
ment - Best Practices in Europe -; Springer Verlag 2001, S. 13
-36.
Herzog, D.; Jeschke, H: Mind Manager 4, Effektiver arbeiten und
lernen mit Mind Mapping, Munchen 2001.
Heup, T.: Prozessbezogene Integration von ERP- und Groupware-
systemen am Beispiel SAP Rl3 und Lotus Notes, Diplomarbeit,
FH K6ln, Fachbereich Informatik, SS 2000.
Hoffmann, A.; Zich, A.: Unternehmensstrategie nach dem E-
Business-Hype, Bonn 2000.
Huber, T.; Alt, R.; Osterle, H. Die Applikationsarchitektur des In-
form atio nszeitalters, Arbeitsbericht BE HSKG / CCiBN / 09, U-
niversitiit St. Gallen, 26. Mai 1999, St. Gallen, 1999.
Kemper, H G.: Business Intelligence - ein Wegweiser, Computer-
woche 44/2002.
Krcmar, H: Bedeutung und Ziele von Informationssystem-
Architekturen. In: Wirtschaftsinformatik, 32. Jg., Heft 5, 1990,
S. 395-402.

272
 Gesamtliteraturverzeichnis

Kuhnt D.: Core Business Drives Growth. Analyst and Investor

Conference, 26.Miirz 2002, Essen.
Lehner, F.: Organisational Memory. Konzepte und Systeme fur
das organisatorische Lernen und das Wissensmanagement,
Munchen 2000.
Lehner, F.; Remus, u.: Prozessmanagement im Mittelstand als
Ausgangspunkt fur die Einfuhrung des Wissensmanagements,
in: Modellierung betrieblicher Informationssysteme, Procee-
dings der MobIS-Fachtagung 2000,5. 179- 204.
Maassen M.: SAP-BW Einsatz bei RWE, Priisentation SAP Utilitys
KongrejS, 24.11.1999, Dusseldorf
Mahr T.: Business Information Warehouse Implementation Con-
siderations, Saphire 2001, Philadelphia.
Mertens, K., Heisig, P., Vorbeck, J. (Eds): Knowledge Management
- Best Practices in Europe -; Springer Verlag 2001
Morton, G.: Intra nets: Some Problems and Solutions, in: Manag-
ing Information, 1998, H.5, S. 26-27.
Muller, C.A: Strategische Fuhrung europiiischer mittelstiindischer
Unternehmen, Lang 1995, S. 32-56.
Nangoy, R.: HTML-basierte Betriebsdatenermittlung fur SAP Rl3,
Diplomarbeit 2001
Neumann, St.; Plugge, B.; Finerty, F.: The Art of Knowledge -
Potential aus Wissen sch6pfen, in: Information Management,
13. Jahrgang 1998, Nr. 1 S. 66-74.
Nohr, H.: Das Projekt OurKnowledge, Wissensmanagement in ei-
nem kleinen Beratungsunternehmen, HBI aktuell, Heft 2,
Stuttgart, 1999, S. 16 - 19.
Nohr, H.: Wissen und Wissensprozesse visualisieren, Arbeitspapie-
re Wissensmanagement, Stuttgart 2000, ISSN 1616-5349.
o. v.: CBT-Lernen ohne Lehrer?, Internetartikel
www.informationweek.de.Ausgabe24.11. Nov. 1999.
o. v.: e-learning in der Weiterbildung - ein Benchmarking deut-
scher Unternehmen, Kurzfassung einer Stu die unter Leitung
von Prof Harho1f!Universitiit Munchen, Internet www.inno-
tec.de, Stand 27.06.2001.
Pohland, 5.: Globale Unternehmensarchitekturen, Methode zur
Verteilung von Informationssystemen. Berlin, 2000, zugl. Diss,
Univ. St. Gallen.
Pomberger, G.; Blaschek, G.: Software Engineering, Prototyping
und objektorientierte Software-Entwicklung, Munchen, Wien,
1993.

273
Gesamtliteraturverzeichnis

Probst, G.; Raub, S.; Romhardt, K.: Wissen managen: Wie Unter-
nehmen ihre wertvollste Ressource optimal nutzen, Wiesbaden
(j.Aujl.), 1999.
SAP AG:SAP Customer Success Story RWE, Walldorf, 2001.
SAP White Paper: "Connection of External System Management
Tools to the Rl3 CCMS - XMB- ", http./Iservice.sap.coml.
SAP Online Dokumentation: SAP AG MatNr. 500 456 31,
http'/Ihelp.sap.coml
SAP: SAP Business Information Warehouse im Oberblick, White
Paper 2000.
Scheer, A.-W: ARIS - Modellierungsmethoden, Meta m odelle, An-
wendungen, Berlin, et al., 3. Aujl., 1998a.
Scheer, A.- W.: ARIS - Vom GeschiiftsprozejS zum Anwendungssys-
tem, 3. Aujl., Berlin et al., 1998b.
Schlicht, M.: Anwendergerechte Gestaltung von Benutzerobeif!ii-
chen in SAP Rl3, Diplomarbeit 2001
Schulmeister, R.: Grundlagen hypermedialer Lernsysteme, Theo-
rie-Didaktik-Design, 2.AujZage, Oldenbourg Verlag 1997.
Schulte, H: Entwicklung eines Lehrkonzeptes zur dynamischen
Programmierung unter ABAPI4, Diplomarbeit 1998.
Sturm, A.: Wissensbasierte Betriebsfuhrung und Instandhaltung
von Energieversorgungsanlagen, VGB Kraftwerks - Technik
6199.
Svenson, u.: Vortrag FH K61n, SAP meets Industry, K61n, 30. No-
vember 2001.
Teufel, T.; R6hricht, j.; Willems, P.: SAP Rl3 ProzejSanalyse mit
Knowledge Maps, Munchen 1999.
Thome, R.: Werkzeuge zur Adaption individueller Informations-
systeme aus Standard-Anwendungssoftware. In: WISU, Heft 4,
1999, S. 568-578.
von Maur, E.: SAP BW - bei Standardgr6jSen eine Wahl, Compu-
terwoche 4412002.
Weber, A.: javaIBAPI-Anwendungen, Diplomarbeit 2002
Wehner, j.: Konzept zur Optimierung der Arbeits- u. Wartungs-
planung mit SAP Rl3' Diplomarbeit, FH K61n, 2001.
Winkeler, T.; Raupach, E., Westphal, L.: Enterprise Application In-
tegration als Pjlicht vor der Business Kur. In: Information
Management & Consulting, 16 .jg., Heft 1, 2001, S. 7-16.

274

Schlagwortverzeichnis
A Standardsoftware 4
Absatzplanung 164
Abweichungen 219
ACSCL 173
Add Ons 25
Administrator Workbench 132
Adobe GoLive 85, 173
Advanced Planning 9
Alertlog 70
Alerts 75
Anwendungssoftware 3
APO 167
APO-Einfiihrung 161
Applikationslog 70
Architekturkomponenten 7
Archivelink -Schnittstelle 148
Asynchronous Computer
Supported Collaborative
Learning 173
AufmaB 223
AufmaBersteliung 224
Autoinvoice-Verfahren 157
auto mati scher Rechnungsleser
139
Available to Promise 165
AVISOR 223
B Customer Lifecycle
BAPI 55
BAPI-Schnittstelle 89
Batch"Input Schnittstelle 149
Batchjobs 70
Bedarfselement 171
Bereichspriifungen 143
Berichtswesen 5
Schlagwortverzeichnis
Bestellanforderung 170
Betriebswirtschaftliche
BEx Analyzer 250
Big-Bang 16
Big-Bang-Strategie 16
Bildvorverarbeitung 142
Business Application
Programming Interface 55
Business Explorer Analyzer
132
c
CAD-System 224
Call Center 233
Call Transaction 149
Call-Center-Agent 235
Captured Video 176
CASE 179
CBT 173
CCMS-Monitoring 74
CGI-Methode 88
Chief Information Officer 50
CIO 50
Common Gateway Interface 88
Computer Based Training 173
CPU-Last 70
CRM 231
Customer Engagement 231
Management 232
Customer Relationship
Management 231
Customizing 5
275
Schlagwortverzeichnis

D Detlev 253
Fullfillment 231
Data Warehouse 8 Funktionsorientierte Einftihrung
Datenabgleiche 143 19
Datenmanagement 10
Demand Planning 161
Deployment 167
G
Deploymentlauf 168
Gadatsch
Desk-Top-Integration 52
Andreas 254
Dialogantwortzeit 70
General-Bebauungsplan 6
Domanen 176
Goerke
Dynamit Nobel 215
Alexander 255
Go-Live 244
E Graf
Ursula 256
eConsultant 235
eEPK 25,27
Einsatzfelder ftir
H
Referenzmodelle 29
Hauswahrung 5
e-Iearning 85
Hesmer
e-Learning 190
Albert 257
Enterprise Application
Hahnel
Integration 10
Wolfgang 258
Enterprise Ressource Planning)
Hot-Line 212
95
HTML 83
ER- Modell 179
HTTP-Klasse 88
ERP-Systeme 6, 95
erweiterte Ereignisgesteuerte
Prozesskette 25, 27 I
Eskalationsprozedur 66
Executive Information Systeme IMS-Systeme 229
9 InfoCube 243
Informationssystem-
Architekturen 6
F
Installbase 235
Instandhaltungsmanagement-
Fabrikkalender 5
Systeme 229
Fachhochschule Kaln 254
IT -Strategie 104
Filesprache 89
IT -Systemverftigbarkeit 65
Flash 195
iTutor 191
Flash-Player 212
iTutor-Film 208
Formatprtifungen 143
Frick

276
 Schlagwortverzeichnis

J Meta Data Manager 132

Middleware 235
Java-Applets 86 Migrationsplanung 10
Javascript 86 ML Consulting 190
Java-Servlet 88 Mollemann
Stefan 263
Monitoringbaum 75
K Monitoringkonzept 69
Monitoringsoftware 68
KEIS 127 MultiCubes 244
Kofax SVRS 142 Multithreading 87
Konzern-Einkaufs-Informations- mysap.com 80
System 127
Kraft
Andreas 259 N
Kuhn
Arno 260 Nachschubauftrage 168
Kundenauftrag 171 Nachschubsteuerung 167
Ktindigungsrecht 66 Normalbestellung 171
Nummernkreise 5

L
o
Lead 234
LEI 55 Oberborsch
Leistungsverzeichnis 223 Andreas 264
Life-Cycle-Modell 23 Object Builder 98
lokaler Big-Bang 18 OCR 142
Lokationsheuristik 170 Offline-Modus 148
Lotus Enterprise Integration 55 OLAP 246
Liinebach OLAP-Prozessor 132
Dieter 261 Online Analytical Processing
132
Online Modus 149
M Online Training 173
Opportunities 234
Makromedia Dreamweaver 85 Opportunity 234
Manugistics 162 Optical Character Recognition
Maskenlayout 176 142
Master Data Management 9 OT 173
Mayr
Reinhard 262
Medienbruch 140
Menupainter 176

277
Schlagwortverzeichnis

p SAP Hosting 79
SAPcomm 235
Paging 70 SAP connect 70
PAI-Prinzipien 176 SAP-Konzernkern 10
Papierrechnung 141 SAP-Organisationsmodell 10
Plant Maintenance 229 Scan 141
Prozess Demand Planning 171 Scannen 141
Prozessorientierte Einfi.ihrung Schnittstellen 5
22 Schreiber
Pufferqualitat 70 Dirk 267
Screenpainter 176
Segment Builder 233
Q SERbrainware 153
SERdistiller 153
Queries 243 Siebel 232
Querpri.ifungen 143 Single Points of Failure 67
Slice and Dice 130
Snagit 180
R
SNP 165
Ramisch Sollarchitektur 6
Daniel 265 Sprache 5
Rechnungsstellung 224 Staging Engine 132
Referenzarchitektur 11 Standardanwendungssoftware-
Referenzmodelle 27 Life-Cycle 23
Referenzprozessmodellen 28 Standardsoftware 4
Remote Function Call 55 Streaming 199
RFC 55 Supply Network Planning 165
RFC-Yerbindung 70 Svenson
Robens Ullrich 268
Hubert 266 Syslog 70
Roll-Out 19 Systemsoftware 3
Roll-Out-Strategie 18
Ri.ickmeldung 219 T
RWE 123
Template 88, 148
s Thomas
Ralf 269
Sachtleben 215 Thygs
Saisonierung 220 Wilhelm 270
Sales Force Automation 9 TDy 49
Sales-LOsung 235 TDy Rheinland/Berlin-
SAP BW 130 Brandenburg 50

278
 Schlagwortverzeichnis

u Watchdog 89,90
WET 173
Umlagerungsbestellanforderung Web Based Training 173
en 167 WFMS-Hersteller 99
Unternehmensorganisation 5 Workbench 86, 175
Workflow-Builder 98
WorkflOW-Explorer 98
v Workflow-Unterstutzung 220

Vendor Managed Inventory

171 x
Verfligbarkeit 65
Verifier 144 XT-Designer-Tool 85
Verifier-Verarbeitung 145 XT -Scriptsprache 85

w z
Wartungsfenster 66 Zentralregulierer 155
Wartungsplanung 219

279
 Controlling mit SAP R/3

Gunther Friedl/Christian Hilz/Burkhard Pedell

Controlling mit SAP R/3
Eine praxisorientierte EinfUhrung mit umfassender Fallstudie
und beispielhaften Controlling-Anwendungen
2002. XX, 283 S. mit 93 Abb. Br. 34,90 ISBN 3-528-05791-2
Inhalt: Uberblick tiber Controlling mit SAP R/3 - Fallstudien - Kosten-
stellenrechnung - Produktkalkulation und Kostentragerrechnung-
Ergebnis- und Marktsegmentrechnung - Konzeptionelle Entwicklungen
des Controlling und neuere Entwicklungen von SAp (SEM, BW) -
Vorbereitende Tatigkeiten im Customizing

Franz Klenger/Ellen Falk-Kalms

Kostenstellenrechnung mit SAP R/3
Mit Testbeispiel und Customizing fUr Studenten und Praktiker
3., vollst. tiberarb. und erw. Aufl. 2002. XVI, 485 S. mit 140 Abb. Br.
39,00 ISBN 3-528-25676-1
"AIs Mitarbeiter der SAP AG mochte ich Sie zu dem (..) Buch begliickwunschen. Es
ware toll, wenn es mehr Bucher dieser Art zum Selbststudium auf dem Markt gabe.
Was mir an dem Buch (. .. ) so gefallen hat, war die didaktische Aufbereitung und die
Moglichkeit, anhand eines Beispieles den kompletten ControlJing-Zyklus selbst nach-
zuvolIziehen. " Mag. Christian Tauber, SAP Osterreich

Andreas Gadatsch
Finanzbuchhaltung und Gemeinkosten-Controlling
mit SAp
Methodische Grundlagen und Fallbeispiele mit SAP Rj3
2001. XXII, 268 S. mit 273 Abb. Br. 29,00 ISBN 3-528-05775-0

II
vleweg
Abraham-Lincoln-StraBe 46
65189 Wiesbaden
Fax 0611.7878-400
www.vieweg.de
Stand 15.3.2002. Anderungen vorbehalten.
Erhiiltlich im Buchhandel oder im Verlag.