6 Die SAP-Einführung in der Praxis - Thali · Der Zugriff auf Experten von SAP in Walldorf wird...

209

Kapitel 6

Theorie und Praxis liegen oft weit auseinander, und das wahre Projektleben konfrontiert alle Beteiligten mit unvor-hergesehenen Herausforderungen. Dieses Kapitel führt Sie anhand eines Beispielprojekts durch alle Phasen einer SAP-Implementierung.

6 Die SAP-Einführung in der Praxis

Es gibt SAP-Projekte in allen Farben und Formen. Dieses Kapitelberichtet über die Einführung eines SAP-Systems in einem internati-onalen Konzern mit einer Pilotinstallation und einem anschließen-den weltweiten Roll-out. Vorweg: Trotz etlicher Hürden und Überra-schungen wird das komplexe internationale Projekt mit Bravourgemeistert und SAP erfolgreich eingeführt. Die Lösungswege inunserem Beispielprojekt sind nicht auf jedes SAP-Projekt übertrag-bar. Wir hoffen aber, Ihnen in diesem Kapitel Anregungen und Rat-schläge für Ihr eigenes SAP-Projekt geben zu können.

6.1 Globale SAP-Einführung aus der Sicht eines Pilotlandes

In diesem Abschnitt machen wir Sie zunächst mit der Ausgangssitu-ation, dem Beispielunternehmen und den wesentlichen Akteurendes Projekts bekannt. Die darauffolgenden Abschnitte folgen unserer(mittlerweile) alten Bekannten, der ASAP-Roadmap. Von der Projekt-vorbereitung bis zum Support begleiten wir (und das Beispielpro-jekt) Sie durch die einzelnen Phasen. Dabei stellen wir immer zuerstdie Dos und Don’ts der jeweiligen Phase im Allgemeinen dar, umanschließend die Umsetzung in der Praxis anhand unseres Beispielszu veranschaulichen. Wir können dabei nicht alle Facetten aller Pro-jektaktivitäten erschöpfend beschreiben – dazu gibt es spezielle tech-nische Ratgeber, auf die wir Sie an geeigneter Stelle im Kapitel hin-weisen –, sondern gehen auf die wesentlichen Knackpunkte ein.

Die SAP-Einführung in der Praxis6

210

6.1.1 Das Beispielunternehmen

Basisannahmen In unserem Beispielunternehmen, einem weltweiten Konzern derDienstleistungsbranche, ist die Entscheidung für den Einsatz einerSAP-Standardsoftware gefallen (siehe Abschnitt 1.3, »Die Entschei-dung für Software von SAP«). Die Entscheidung wurde vor allemdurch den neuen weltweiten CIO, Mr. Smith, vorangetrieben, derdie gesamte IT-Infrastruktur im Konzern auf den Prüfstand stellte.Mit der Einführung von weltweit durchgängigen, harmonisiertenProzessen und einheitlichen Datenstandards erwartet die Konzern-zentrale eine Reihe wirtschaftlicher Vorteile. Dazu gehören mehrTransparenz durch ein verbessertes Informationsmanagement, kür-zere Lieferzeiten, niedrigere Verwaltungs- und IT-Kosten, aber aucheine höhere Kundenzufriedenheit und damit die Chance auf weitereUmsatzsteigerungen und einen größeren Marktanteil. Mr. Smithweiß: Die Erfolgsquote bei globalen ERP-Projekten ist geringer alsbei klassischen ERP-Projekten. In den meisten Fällen ist die Schuldnicht bei der Technik zu suchen. Gründe für ein Scheitern sind z. B.eher kulturelle Besonderheiten und Mentalitäten, unterschiedlicheZeitzonen oder die Herausforderungen des Managements von virtu-ellen Projektteams.

Der Startpunkt:das globale

Template

Mit einem internationalen Entwicklungsteam, unterstützt von Pro-zessexperten aus diversen Ländergesellschaften, wurden die globalenProzesse und weltweiten Datenstandards beschrieben, das globaleSAP Template entwickelt und von den weltweiten und regionalenStakeholdern abgenommen. Jetzt ging es darum, das globale Tem-plate in einer Pilotinstallation vor dem weiteren Roll-out zu testen.

Um das Risiko der Erstimplementierung zu minimieren, wurde einGeschäftsbereich im Konzern für eine Pilotinstallation ausgewählt.Abbildung 6.1 zeigt die iterative Vorgehensweise, die bei dem Tem-plate-Roll-out verfolgt werden sollte. Nach der Pilotinstallation undjeder Implementierung in einem weiteren Land sollen die Erfahrun-gen und Erkenntnisse dokumentiert und an das weltweite Template-Team zur weiteren Optimierung und Effizienzsteigerung zurückge-spielt werden.

Globale SAP-Einführung aus der Sicht eines Pilotlandes 6.1

211

Abbildung 6.1 Template-Roll-out (Quelle: SAP)

Inhalt des globalen Templates

Das globale Template umfasste die Beschlüsse im Hinblick auf diefolgenden Themen:

� Welche Prozesse werden vom neuen SAP-System abgedeckt? Indiesem Zusammenhang werden das Prozessmodell, die weltwei-ten Datenstandards, vordefinierte Geschäftsszenarien, Daten-migrationsabläufe und Entwicklungen festgelegt.

� Wie soll die globale Anwendungs-Systemarchitektur beschaffensein? Hier werden Schnittstellen, Customizing, Eigenentwicklun-gen sowie Add-ons beschrieben.

� Wie wird die technische Systemarchitektur inklusive Berechti-gungskonzept sowie Änderungs- und Transportkonzept aussehen?

� Welche Maßnahmen sind im Hinblick auf die Ausbildung der Pro-jektmitarbeiter und Endanwender geplant?

� Wie soll das neue System dokumentiert werden?

� Welche Implementierungsmethode wird verwendet? Dies bein-haltet Projektleitfäden, Standards, Prozeduren, Vorlagen etc.

Die Vorteile eines Template-Roll-outs liegen auf der Hand:

� Die Implementierung kann effizienter und mit geringerem Risikoerfolgen.

� Es wird die Basis für zukünftige Anforderungen gelegt und dieAnpassungsfähigkeit bewahrt.

globaleProzesse/Standardisierung/

Harmonisierung

globales Template/Entwicklung

Pilotinstallation

Länderroll-out

Lessons Learned

Lessons Learned


212

� Im Falle von organisatorisch notwendigen Änderungen (z. B. beiFusionen oder Zukäufen) ist das System flexibel.

� Die gesammelten Erfahrungen und Erkenntnisse aus den Imple-mentierungen können von den anderen Ländern genutzt werden.

� Durch eine Standardisierung kann die Prozesstransparenz erhöhtwerden.

� Das Berichtswesen im Konzern kann durch konsistente Datenerheblich verbessert werden.

� Der Wartungsaufwand wird durch die Standardisierung der IT-In-frastruktur erheblich verringert.

Wer darf zuerst?Auswahl des

Pilotlandes

Im nächsten Schritt musste ein Pilotland für die Implementierungausgewählt werden. Die Auswahl des geeigneten Pilotlandes istbesonders wichtig und kritisch, da die Erstimplementierung mit derUmsetzung des globalen Templates ein Erfolg werden muss. DieErfahrungen aus der Pilotimplementierung werden gesammelt undstehen den Nachfolgeländern als Leitfaden für die weiteren Roll-outszur Verfügung. Von den weltweiten Entscheidungsträgern wurdevorgegeben, dass es vorzugsweise ein europäisches Land sein sollte,mit einer repräsentativen Abdeckung der verschiedenen Umsatzar-ten innerhalb des ausgewählten Geschäftsbereiches. Mehrere Länderhatten sich daraufhin um die Pilotinstallation beworben, unter ande-rem auch Deutschland. Eine wesentliche Motivation für die Bewer-bung der Länder war, durch die Auswahl zum Pilotland einen größe-ren Einfluss auf die weitere Entwicklung des globalen Templatesnehmen zu können. Eine Annahme, die sich, nachträglich betrachtet,auch teilweise erfüllt hatte.

Die folgenden Abschnitte beschreiben die Erfahrungen mit demSAP-Projekt aus der Sicht des Pilotlandes. Dabei geht es um den Pro-zess von der Entscheidung für das Pilotland bis zur Produktivsetzungund den späteren Roll-out in weitere Länder.

6.1.2 Auswahl des Pilotlandes

Das Entschei-dungskommittee

Zur Entscheidung darüber, welches Land den ersten Schritt auf demWeg zur SAP-Software machen soll, wird zunächst ein Meeting mitden internationalen Entscheidungsträgern anberaumt. Teilnehmeran der Besprechung mit dem deutschen Team sind der CIO Mr.Smith, die weltweit verantwortlichen Geschäftsbereichsmanager,

Globale SAP-Einführung aus der Sicht eines Pilotlandes 6.1

213

der lokale IT-Manager für Deutschland, Herr Brotkötter, der lokaleProzessmanager, Herr Pingel, sowie eine Vertreterin der lokalenGeschäftsführung, Frau Rosenbusch. Ziel des Meetings ist es, fol-gende Fragen zu beantworten:

� Welches sind die wichtigsten Geschäftsprozesse des Landes?

� Welche Softwarelösungen werden zum aktuellen Zeitpunktgenutzt, um diese Prozesse zu unterstützen?

� Wie ist die lokale Systemarchitektur strukturiert, und welcheSchnittstellen sind im Einsatz?

� Welches Fachwissen und welche Projekterfahrung bringen dielokalen Projektmitarbeiter mit? In welchem Umfang sind sie ver-fügbar?

Für das Meeting waren zwei Tage angesetzt. Hinterher machen sichalle Länderteams berechtigte Hoffnungen, für die Pilotauswahlinfrage zu kommen. Die mit Spannung erwartete Entscheidungwurde den Teams nach zwei Wochen mitgeteilt. Den Zuschlag fürdie Pilotinstallation bekam Deutschland aus folgenden wesentlichenGründen:

� Es gibt eine gute Übereinstimmung der global festgelegten Pro-zesse mit den laufenden Geschäftsprozessen. Der ausgewählteGeschäftsbereich ist für das Geschäft im Konzern repräsentativ.

� Der Ersatz der bestehenden IT-Infrastrukturlandschaft (Altsys-teme) mit der neuen globalen SAP-Architektur verspricht erhebli-che Einsparpotenziale bei den IT-Kosten.

� Das Länderteam hat bereits Erfahrung mit vergleichbaren großenProjekten.

� Die Geschäftsleitung, besonders Frau Rosenbusch, setzt sich fürdas Projekt ein und sagt zu, die benötigten Ressourcen bereitzu-stellen.

� Der Zugriff auf Experten von SAP in Walldorf wird als weitererzusätzlicher Vorteil gewichtet.

Global ASAP Local Roll-out Roadmap

Die Implementierungsmethode ist an die Phasen der Global ASAPLocal Roll-out Roadmap von SAP angelehnt. In dieser Roadmap wer-den zentrale globale Aktivitäten auf Unternehmensebene definiertund umgesetzt. Die beschriebenen Aktivitäten in der Roadmap sindder Leitfaden für die Pilotinstallation und die nachfolgenden Roll-


214

outs. In den nächsten Abschnitten werden wir die Inhalte der einzel-nen Phasen und ihre praktische Umsetzung genauer vorstellen.

Abbildung 6.2 zeigt die verschiedenen Phasen der Global ASAP LocalRoadmap. Die unternehmensweiten Geschäftsanforderungen, basie-rend auf der Konzernstrategie, werden mit Fachspezialisten aus ver-schiedenen Ländern, darunter auch Prozessexperten aus Deutschland,dem Pilotland, definiert. Die Unternehmens- und Organisationsstruk-turen und die einheitlichen Datenstandards sind festgelegt. Auf dieserBasis wird das globale Template entwickelt. In der Abbildung sehenSie die einzelnen Phasen und den Startpunkt des Pilotlandes.

Abbildung 6.2 Globale ASAP-Roadmap (angelehnt an SAP Global ASAP Implemen-tation Methodology, SAP SE)

Die Phasen für die Pilotimplementierung folgen generell der ASAP-Implementierungsmethode, und zwar mit der lokalen Projektvorbe-reitung, der lokalen Blueprint-Phase, der Realisierung der lokalenAnpassungen, der Produktionsvorbereitung und schließlich dem Go-Live und Support.

6.2 Die lokale Projektvorbereitung

Für die lokale Projektvorbereitung gibt es verschiedene Aufgaben-gebiete zu bewältigen. In den nächsten Abschnitten beschreiben wirzunächst die Vorgehensweise im Allgemeinen und zeigen anschlie-ßend die Umsetzung in die Praxis.

globale Projekt-

vorbereitung

globaler Business Blueprint

globaleRealisierung

Initiierung und Planung des

Gesamtprogramms

Definition derGeschäftsanforde-

rungen für dasUnternehmen

Pilot-implementierung

Wir starten hier!

Pilot-vorbereitung

Template- Roll-out,

Support und Wartung

Anpassung desTemplates für

weiteren Roll-out

Entwicklung desglobalen Templates

Die lokale Projektvorbereitung 6.2

215

6.2.1 Projektmanagement

Zunächst ist die lokale Projektorganisation mit Rollen und Verant-wortlichkeiten festzulegen. Über die folgenden Themen müssen Siesich dabei Gedanken machen:

� Projektleitung

� Projektteam

� Lenkungsausschuss

� Geschäftsprozessmanager

� Projektinfrastruktur

� Projekt-Kick-off-Meeting

Projektleitung und Projektbüro

Die Auswahl der geeigneten Projektleitung ist ein wesentlicher Bau-stein für das Gelingen des Projekts. Die Projektleitung ist eine Füh-rungsaufgabe und erfordert Managementqualitäten. Im Idealfallsollte der Projektleiter Erfahrungen mit SAP-Implementierungenund internationalen Roll-outs haben. Da eine solche »eierlegendeWollmilchsau« aber selten zu dem gewünschten Zeitpunkt zur Verfü-gung steht, werden Sie möglicherweise Kompromisse machen müs-sen. Erfahrung mit SAP-Projekten und soziale Kompetenzen wie Mit-arbeiterführung sollte der zukünftige Projektleiter aber auf alle Fällemitbringen (siehe auch Kapitel 4, »Der unterschätzte Erfolgsfaktor:Der Mensch«).

In der täglichen Projektarbeit wird der Projektleiter von einem Pro-jektbüro, einem sogenannten Projekt-Management-Office, unterstützt(siehe auch Abschnitt 5.1, »Der Helfer in allen Lebenslagen: Das Pro-ject Management Office«). Das PMO ist das Rückgrat des Projekts, undentsprechend sorgfältig müssen die Mitarbeiter ausgewählt werden.

ProjektteamDas Projektteam in Projekten mit internationalen Roll-outs sollte zumgrößeren Anteil aus Vollzeitmitarbeitern mit englischen Sprach-kenntnissen bestehen. Erstreckt sich die SAP-Einführung auf ver-schiedene Fachbereiche im Unternehmen, werden also verschiedeneKomponenten eingeführt, sind Prozessexperten aus diesen Fachbe-reichen erforderlich, z. B. aus der Auftragsbearbeitung, der Logistik,der Finanzabteilung sowie der Personalabteilung. Zusätzlich werdenIT-Experten mit technischem Fachwissen benötigt, die idealerweisedie lokale Systemarchitektur wie ihre Westentasche kennen. Sie kön-nen davon ausgehen, dass die meisten Mitarbeiter im Projekt noch


216

keine Erfahrung mit SAP-Software haben. Deshalb empfiehlt sicheine SAP-Einführung über 1–2 Wochen in der Anfangsphase.

Der Lenkungs-ausschuss

Der Lenkungsausschuss (engl. Steering Committee) besteht aus Mitglie-dern der internationalen und lokalen Geschäftsführung (meist Vor-standsebene). Des Weiteren sind die Bereichsleiter der Bereiche, diedurch das SAP-Projekt berührt werden, sowie Verantwortliche derexternen Beratungsunternehmen Teil des Lenkungsausschusses.

Es hat sich bewährt, den oder die Vorsitzenden/Vorsitzende derArbeitnehmervertretung in den Lenkungsausschuss zu holen. Wäh-rend des Projekts werden viele Entscheidungen zu treffen sein, dieauch von der Arbeitnehmervertretung abgesegnet werden müssen,z. B. Auswirkungen des Projekts auf die Belegschaft oder auchAnträge für Mehrarbeit, Wochenendarbeit.

Der Geschäfts-prozessmanager

Die Geschäftsprozesse werden in internationalen Unternehmen inaller Regel von weltweit verantwortlichen Geschäftsprozessmanagernvertreten. So gibt es z. B. Geschäftsprozessmanager für die Logistik-prozesse, Finanzprozesse, Auftragsabwicklungsprozesse etc. Im Ideal-fall gibt es auch einen Geschäftsprozessmanager, der die Gesamtver-antwortung für alle Prozesse im Unternehmen hat und von seinenTeilprozessmanagern unterstützt wird. Es wird im Projekt immerwieder Situationen geben, in denen Entscheidungen über zukünftigeProzessabläufe zu treffen sind. Sollte dabei einmal keine Einigungerreicht werden können, ist als letzte Instanz und Eskalationsstufeder Lenkungsausschuss einzubinden.

Die Projekt-infrastruktur

Ebenso von Bedeutung in der Anfangsphase des Projekts ist dieBereitstellung der Projektinfrastruktur für das Projektteam. Dazugehört die Ausstattung mit technischen Geräten wie Laptops, Dru-cker, Software, Räumlichkeiten sowie mit den erforderlichen Kom-munikationsmitteln.

Projekt-Kick-off-Meeting

Um die zukünftigen Projektmitarbeiter auf die strategischen Rah-menbedingungen des Unternehmens auszurichten, ist ein Projekt-Kick-off-Meeting mit allen Beteiligten hilfreich. In diesem Meetingwerden die Unternehmensziele und daraus abgeleitet die Ziele desProjekts nochmals verdeutlicht. Wichtig dabei ist, dass auch Mitglie-der des Lenkungsausschusses vertreten sind, um die Bedeutung desProjekts für das Unternehmen zu betonen. Auch dazugehörige allge-meine Themen wie Projekt- und Dokumentationsstandards, be-nutzte Tools, Meilensteine und Projektorganisation werden vermit-


217

telt. Um die Zusammenarbeit und das Kennenlernen von Projektmit-arbeitern zu fördern, können auch noch teambildende Maßnahmendurchgeführt werden.

6.2.2 Datenmigration und Datenqualität

Standards setzenWir haben bereits in mehreren Abschnitten einen mahnenden Zeige-finger erhoben und darauf hingewiesen, wie wichtig korrekte undweltweit standardisierte Daten für den Projektverlauf sind (sieheAbschnitt 1.4.2, »Der Weg der Daten: Datenmigration«, undAbschnitt 2.2.3, »Phase 3: Realisierung«). Für das globale Templatewerden deshalb die für den Konzern gültigen weltweiten BusinessData Standards festgelegt. Dazu gehören international gültigeStammdaten für z. B. Kunden, Lieferanten sowie im ganzen Konzerneinheitliche Produktbezeichnungen, einheitliche Kontenpläne etc.Die lokale Datenmigrationsstrategie wird entwickelt und legt fest,welche Daten von den Altsystemen in das SAP-System zu migrierensind.

6.2.3 Change Management und Ausbildung

Ängste ernst nehmen

Die Veränderungsprozesse während einer SAP-Einführung sinderheblich: Ängste und Ungewissheit bei den Mitarbeitern könnenden laufenden Geschäftsbetrieb stören. Der Erfolg einer Unterneh-menstransformation kann davon abhängen, ob diese Emotionenwahrgenommen und Bedenken ausgeräumt werden können. ZurUnterstützung dieses Prozesses werden die Methoden des ChangeManagements eingesetzt. Dazu gehören die Analyse von organisato-rischen Veränderungen, ein Kommunikationsplan, der auf die Inte-ressen der Projektbeteiligten ausgerichtet ist, die Erarbeitung vonneuen Rollen und die Ausbildung, die die Mitarbeiter in die Lageversetzt, ihre neuen Rollen wahrzunehmen.

Die im Template definierten weltweiten Geschäftsprozesse sind aufBest Practices ausgerichtet und müssen den Fachspezialisten im Pro-jekt früh vermittelt werden. Dies kann entweder über vorliegendeProzessdokumente oder noch besser in Prozessworkshops erfolgen.

Anders als bei einem traditionellen SAP-Projekt sollten Sie sich beieinem Template-Roll-out bereits in der lokalen Projektvorberei-tungsphase mit der Schulungs- und Ausbildungsstrategie beschäftigen.


218

Dabei müssen folgende Fragen beantwortet werden:

� Welche Zielgruppen müssen geschult werden und welche Voraus-setzungen müssen sie mitbringen?

� Welche Standorte sind betroffen?

� Welche technischen und infrastrukturellen Voraussetzungen sinderforderlich?

� Welche Fähigkeiten zur Benutzung des neuen Systems werdenbenötigt?

� Wo und wann soll die Ausbildung stattfinden?

� Welche Unterstützung soll es nach dem Produktionsstart geben?

� Welche Trainingsmethoden (z. B. Klassenraumschulung, Selbst-studium oder Webtraining) sollen zum Einsatz kommen?

Das Thema Schulung greifen wir in den Abschnitten 6.4.7, »Entwick-lung des Schulungsmaterials«, und Abschnitt 6.5.1, »Schulung«, wei-ter auf.

6.2.4 Infrastrukturanforderungen und -design

In der Projektvorbereitungsphase müssen Sie auch die technischen Inf-rastrukturanforderungen definieren. Die Systeme für die Entwicklungund den Test des globalen Templates werden vom Infrastrukturteamzu Beginn des Projekts bereitgestellt und sind bereits vorhanden. Fürdie Pilotinstallation sind noch folgende weitere Fragen abzuklären:

� Welche Systeme mit welcher Ausstattung werden für die Datensi-mulationen, Schulungen und die Produktivsetzung benötigt? Sinddie vorhandenen Entwicklungs- und Testsysteme für die anstehen-den Aufgaben ausreichend?

� Welche Namenskonventionen werden den Systemen zugeordnet?

� Wie sind die Transportwege und Transportprozesse zwischen deneinzelnen Systemen?

� Welche SAP-Version (welches Release) wird eingesetzt?

� Auf welchem Betriebssystem und Datenbanksystem wird die Soft-ware eingesetzt?

� Wie viele Endanwender werden das System benutzen?

� Mit welchen Wachstumsraten ist im Unternehmen zu rechnen?

� Sollen in Zukunft weitere SAP-Komponenten eingeführt werden?


219

� Muss zusätzliche Hardware beschafft werden?

� Wird für die Implementierung »ein« physisches System verwendetoder werden mehrere Instanzen geplant?

Qualitätscheck für die Projektvorbereitung

Im Qualitätscheck für die Phase der Projektvorbereitung wird die qualita-tive Erledigung aller Aufgaben überprüft und im positiven Fall freigege-ben. Der Qualitätscheck wird nach dem Abschluss jeder neuen Phasedurchgeführt. Weitere Informationen zum Thema Qualitätscheck findenSie in Abschnitt 5.4, »Qualitätssicherung«.

6.2.5 Und wie läuft es in der Praxis?

So weit, so gut. Aber wie meistert unser Beispielunternehmen dieProjektvorbereitung? Nach der Entscheidung für die Pilotinstallationund den obligatorischen Jubelreden geht es direkt mit den weiterenPlanungen los.

Zuordnung der Projektressourcen

Die Zuordnung der Ressourcen für das lokale Pilotprojektteam gestaltetsich zunächst schwieriger als erwartet. Der Plan ist, den Großteil derbenötigten Ressourcen – und zwar auch aus den Fachabteilungen –Vollzeit dem Projekt zuzuordnen. Das bedeutet, dass ein Teil der fürdas Projekt vorgesehenen Fachmitarbeiter von ihren laufenden Tätig-keiten entbunden und ersetzt werden muss. Sie können sich vorstel-len, wie laut das Wehklagen der Fachabteilungsleiter ist, die sichzunächst mit Händen und Füßen wehren. Die Diskussionen scheinenkein Ende zu nehmen. Erst die Zusage der Geschäftsführung, einen Teilder Fachmitarbeiter, die für das Projekt vorgesehen sind, mit Aushilfs-kräften für das laufende Geschäft zu ersetzen, bringt den Durchbruch.Bereits jetzt zeigt sich, wie wichtig die Unterstützung der Geschäfts-führung, besonders von Frau Rosenbusch, für das Projekt ist.

Auswahl des Projektleiters

Eine weitere große Herausforderung ist die Benennung eines kompe-tenten Projektleiters. Die Anforderungen sind hoch: Der Einfüh-rungstermin für das Projekt steht zu diesem Zeitpunkt bereits fest.Eine sorgfältige Machbarkeitsstudie und die Berücksichtigung »aller«für das Projekt relevanten Abhängigkeiten sollen erst zu einem spä-teren Zeitpunkt vorgenommen werden. Erfahrene Projektleiterhaben angesichts dieser Herkulesaufgabe abgewinkt und gehofft,dass dieser Kelch an ihnen vorübergehen möge. Um keine Zeit zuverlieren, wird zunächst ein Interims-Projektleiter eingesetzt.


220

Überarbeitungdes Einführungs-

termins

Nach Vorlage der ersten Detailpläne ist offensichtlich, dass derursprünglich geplante Einführungstermin nicht zu halten ist. EineÜberarbeitung aller Pläne mit dem Ziel, einen machbaren Einfüh-rungstermin festzulegen, ist notwendig geworden. Jetzt stellt sichheraus, dass die Projektziele zu Beginn nicht eindeutig und klarbeschrieben waren und zusätzliche Abhängigkeiten (in/out of scope)nicht berücksichtigt wurden. Inzwischen wird der Interims-Projekt-leiter plangemäß durch einen neuen Projektleiter, Herrn Meyer,ersetzt. Der Zeitpunkt ist insofern günstig, als der neue Projektleiterunbelastet in das Projekt kommt und als erste Amtshandlung einReview aller Detailpläne veranlassen kann. Auf der Basis der überar-beiteten Detailpläne wird ein neuer, realistischer, aber noch immerambitionierter Einführungstermin von Herrn Meyer und seinemProjektteam vorgeschlagen. Nach einigen schwierigen Meetings mitden Entscheidungsträgern wird schließlich der neue Terminvor-schlag akzeptiert, womit das Projekt zunächst in ruhigeres Fahrwas-ser kommt.

Eine sorgfältige Planung ist die Basis für den Erfolg!

Eine sorgfältige Planung zu Beginn ist ein wesentlicher Baustein für denErfolg eines Projekts. Folgt man Albert Einstein, ersetzt »Planung denZufall durch Irrtum«. Für IT-Projekte und Unternehmenstransformationensollte man sich aber eher an Konfuzius orientieren, der da sagt: »Es istbesser, ein einziges kleines Licht anzuzünden, als die Dunkelheit zu ver-fluchen!« Was bei der Planung besonders zu beachten ist und weitereVorgehensweisen finden Sie in Abschnitt 5.3.2, »Steuerungs- und Kon-trollprozesse durchführen«.

Ohne Infrastruktursteht das

Projekt still

Ohne eine gute Projektinfrastruktur läuft nichts! Die Idee ist, das Ent-wicklungs- und lokale Pilotprojektteam in einem Gebäude und wennmöglich auf dem gleichen Stockwerk unterzubringen. Auch die tech-nischen Voraussetzungen wie Druckerräume, Server, Laptops, Soft-ware etc. müssen zügig angeschafft werden (siehe auch Abschnitt2.1.1, »Grünes Licht: Die Projektfreigabe«). Der verantwortliche Lie-genschaftsmanager, Herr Knorre, stöhnt unter der Herausforderung,zumal alles bereits »gestern« erledigt sein soll. Ein Glück, dass derneue Projektleiter, Herr Meyer, einen guten Draht zu Herrn Knorrehat. Herr Meyer lädt Herrn Knorre zu einer Tasse Kaffee ein undkann so das wichtige Thema in einer entspannten Atmosphäre mitguten Erfolgsaussichten besprechen.


221

Auch die Unterstützung für das Projekt von Frau Rosenbusch vonder Geschäftsleitung hat sich wieder einmal positiv ausgewirkt. Nacheinigen Wochen kann das gesamte Projektteam die für das Projektvorgesehenen Räumlichkeiten beziehen. Die Entscheidung, dasgesamte Team in einem Gebäude unterzubringen, hat sich nachträg-lich sehr bewährt. Die kurzen Wege und der direkte Austausch vonMitarbeiter zu Mitarbeiter sind gerade in schwierigen Situationensehr vorteilhaft. Viele Fragen können erfahrungsgemäß am bestengeklärt werden, während die Kaffeemaschine die Bohnen mahlt.

Und Anstoß!Dann kommt der Startschuss für das Pilotteam: Ein erfahrenerChange-Management-Coach übernimmt die Leitung des zweitägigenKick-off-Meetings. Im Vordergrund steht neben allen wichtigenInformationen zu den Projektinhalten die Teambildung. Diese gelun-gene Veranstaltung ist sehr wichtig für die Vertrauensbildung inner-halb des Projektteams.

Das Management zeigt Flagge

Die Teilnahme der weltweiten und lokalen Geschäftsführer am Projekt-Kick-off unterstreicht die zentrale Bedeutung des Projekts und gibt demgesamten Team einen zusätzlichen Motivationsschub.

Run OnceFür die Implementierung des Pilotlandes und der späteren Roll-outsist »ein« weltweites System vorgesehen (Run Once), das heißt, dieDaten und Programme für alle Ländergesellschaften befinden sichauf dem gleichen Produktivsystem.

Big BangFür die Umsetzung wird nach einer sorgfältigen Abwägung ein Big-Bang-Ansatz einer stufenweisen Einführung vorgezogen, um Zeitund damit Kosten zu sparen. Beim Big-Bang-Ansatz werden alle vonder Implementierung betroffenen Geschäftsprozesse und Daten ineinem Vorgang in das Produktivsystem übernommen. Das heißt, dieAltsysteme werden in einem Rutsch abgelöst. Die Risiken diesesAnsatzes sind offensichtlich: Nachdem die Stamm- und operationa-len Bewegungsdaten in das neue System geladen und die erstenTransaktionen durchgeführt sind, ist sehr schnell der Point of noReturn erreicht. Ab diesem Zeitpunkt können die Altsysteme nichtmehr benutzt werden. Die Endanwender werden zwar geschult, sindaber in der Praxis mit den neuen Geschäftsabläufen noch nicht ver-traut. Mit welchen Maßnahmen dieses Risiko verringert werden


222

kann, behandeln wir in Abschnitt 6.5, »Finale Vorbereitungsphase/Go-Live und Support«.

Projektorgani-sation und Verant-

wortlichkeiten

Schauen wir uns nun die Projektorganisation an: Es gibt eine welt-weite und eine lokale Ebene mit einem weltweiten SAP-Entwick-lungs- und Implementierungsteam und einem lokalen Pilotteam.Zunächst ist es elementar, die Aufgabenverteilung zwischen den bei-den Teams zu regeln. Tabelle 6.1 zeigt die Aufgaben und Zuständig-keiten des weltweiten Entwicklungs- und Implementierungsteamsund des lokalen Pilotteams.

Weltweites Entwicklungs- und Implementierungsteam

Lokales Pilotteam

Entwicklung und Implementierung eines globalen Templates auf der Basis von globalen standardisierten Prozessen und weltweiten Daten-standards

� Bereitstellung von Prozess-Res-sourcen für das weltweite Ent-wicklungsteam

� Abdeckung der lokalen Prozesse und gesetzlichen Anforderungen für das Pilotland

� Management der weltweiten Sys-tem-Architekturkomponenten

� verantwortlich für weltweite Sys-temschnittstellen

� Management der lokalen und regionalen System- Architektur-komponenten

� verantwortlich für lokale und regionale Schnittstellen

Entwicklung und Umsetzung der Datenmigrationsstrategie

� Identifizierung der Datenquellen aus den Altsystemen

� Unterstützung der Datenmigrati-onsstrategie mit Ressourcen für Datenbereinigungsaktivitäten

� Beratung/Unterstützung des Pilotlandes in Change-Manage-ment-Aufgaben

� Erstellung des Schulungsmaterials

� weltweites Stakeholder-Manage-ment

Wahrnehmung der lokalen Change-Management-Aufgaben:

� Kommunikationsstrategie

� Schulungslogistik

� lokales Stakeholder-Management

verantwortlich für den Gesamtplan (weltweites Projektbüro/PMO)

verantwortlich für die lokalen Pläne (lokales Projektbüro), enge Zusam-menarbeit mit weltweitem Projekt-büro

Tabelle 6.1 Aufgaben und Zuständigkeiten des weltweiten Entwicklungs- und Implementierungsteams und lokalen Pilotteams


223

Think global: die weltweite Projekt-organisation

Die verantwortlichen IT- und Prozessmanager der Ländergesellschaf-ten werden von Anfang in das weltweite Pilot-Managementsystemeingebunden, das heißt, mit regelmäßigen Informationen versorgt.Damit soll sichergestellt werden, dass sie über den Projektstatus imPilotland jederzeit informiert waren. Gleichzeitig ist es auch einegute Vorbereitung für die nach der Pilotimplementierung geplantenRoll-outs.

Abbildung 6.3 zeigt die weltweite Projektorganisation für die Pilot-installation. Die Gesamtverantwortung für das Projekt hat der Pro-jektsponsor, der einen Projekt-Executive benennt. An den Projekt-Executive berichten das weltweite Entwicklungs- und Implementie-rungsteam und die weltweite Roll-out-Organisation. Das Pilotland istin die weltweite Roll-out-Organisation eingebunden. Die Vertreterder Ländergesellschaften sind Teil der Organisation und werdenüber den Projektverlauf informiert gehalten.

Abbildung 6.3 Weltweite Projektorganisation für Pilotinstallation

Act local: Die lokale Projekt-organisation

Abbildung 6.4 zeigt die lokale Projektorganisation im Pilotland. Dielokale Verantwortung liegt beim lokalen Sponsor (Geschäftsleitungs-ebene) bzw. den fachlichen Sponsoren für Prozesse und IT. Das welt-weite Entwicklungsteam ist in das Management-System des Pilotlan-des in einer Beratungsfunktion eingebunden. Das Pilotteam hateinen dualen Berichtsweg: einerseits in die weltweite Organisations-ebene zur Leitung des weltweiten Roll-out-Teams und andererseitsauf lokaler Ebene an die Leiter für Prozesse und IT. Die Zielerrei-

Leitung desglobalen

Entwicklungsteams

Pilotinstallationlokale und regionale Systemarchitekturlokale Prozesse/ITlokale Testunterstützung/Datenmigrationlokales Change Managementlokales PMO

globale Systemarchitektur undAbhängigkeitenglobale Prozesse/ITglobale Tests/Datenglobales Change ManagementPMO/Qualitätssicherung/Integration

Info

Lenkungs-ausschuss/

Projektsponsor/Projekt-

verantwortlicheLeitung des globalen

Roll-out-Teams/Pilotland

RegionenEuropa/Asien/

Nordamerika etc.


224

chungsgespräche für die Mitarbeiter im Pilotland finden auf lokalerEbene mit Abstimmung der internationalen Organisation statt. Nachanfänglicher Skepsis über die Praktikabilität des beschriebenen Ma-trix-Management-Systems gibt es keine nennenswerten Problemewährend des Projekts.

Abbildung 6.4 Projektorganisation im Pilotland

Nach weiteren Abstimmungsmeetings und zunehmender Detaillie-rung der Projektpläne wird dem Pilotteam und vor allem auch demlokalen Management bewusst, welche Herausforderungen und Hür-den für die Einführung des neuen Systems noch zu überwinden sind.Die Unkenrufe im Sinne von »Das funktioniert nicht, viel zu kom-plex« werden lauter.

Wer hat Einflussauf das Projekt?

Jetzt ist der geeignete Zeitpunkt für eine Stakeholder-Analyse gekom-men. Welche Interessengruppen und Schlüsselfiguren müssen imProjekt berücksichtigt werden? Wer unterstützt das Projekt und werkönnte damit ein Problem haben? Im Mittelpunkt steht die Frage,wie die verschiedenen Interessengruppen proaktiv gesteuert werdenkönnen, um Konflikte zu vermeiden. Die Analyse wird vom Projekt-team mit bewährten Methoden wie Brainstorming, Metaplantechnikund Flipchart vorgenommen (siehe auch Abschnitt 4.2, »Die Bedeu-tung des Projektleiters«).

Executive-Sponsor für das Pilotland

fachliche Sponsoren für das Pilotland (Prozesse/IT)

globalesEntwicklungsteam

Pilotteam

Prozesse DatenChange

Managementlokale IT/Test

PMO

Leitung des globalenRoll-out-Teams


225

Moderations-methode: Metaplantechnik

Mit der Metaplantechnik kann man die Diskussion in einer Gruppesehr schön in einem Bild veranschaulichen. Zunächst werden alleStakeholder im Projekt definiert und danach nach bestimmten Krite-rien zugeordnet. Im Beispielfall sind es die folgenden Kriterien:

� EinflussWelche Stellung bzw. welche Entscheidungsbefugnisse hat der Stakeholder im Unternehmen?

� WichtigkeitWer ist für den Erfolg des Projekts besonders wichtig (weil z. B.besonderes Fachwissen zur Unterstützung benötigt wird)?

� Anspruch/LegitimationWer sind die Gruppen, die das Projekt zwar nicht direkt unterstüt-zen, aber Informationsbedarf haben (z. B. der Betriebsrat)?

Aus Skeptikern Unterstützer machen

Die Ergebnisse werden in einem Kommunikations-Aktionsplan festge-halten. Der Plan zeigt, wer wann und mit welcher Intensität in dieProjektkommunikation eingebunden werden muss. Besonderes Au-genmerk gilt es dabei auf »die« Interessengruppen zu richten, diesich kritisch und skeptisch äußern und darüber hinaus noch wichtigfür das Projekt sind.

Abbildung 6.5 zeigt die verschiedenen Interessengruppen (Stakehol-der), deren Einstellung zum Projekt und daraus abgeleitet den Kom-munikationsbedarf.

Abbildung 6.5 Stakeholder-Analyse und Kommunikationsstrategie

Projekt

Sponsor Verwaltung Betriebsrat Finanzen

globaleProjektleitung Business Unit

Kunden undLieferanten

Prozesse/IT Pilotland

positiv – normale Projekt-

Updates

positiv – normale Projekt-

Updates

skeptisch – zusätzliche Updates

neutral –informiert

halten

sehr kritisch –Zwischenstatus

einplanen

skeptisch –zusätzliche Updates

sehr kritisch –Zwischenstatus einplanen

neutral – Informiert halten


226

Tabelle 6.2 zeigt den Kommunikationsplan für das Projekt, abgeleitetaus den Ergebnissen der Stakeholder-Analyse. Eine Vorlage für IhreStakeholder-Analyse finden Sie im Downloadangebot zu diesemBuch unter http://www.sap-press.de/3825.

Stakeholder/Interessen-gruppe

Einstel-lung

Wichtig-keit

Kommunikations-kanal

Frequenz Wer

Executive Sponsor Pilot

positiv wichtig Newsletter monatlich PMO

Lenkungsausschuss-meeting

monatlich PM

Projektstatusmeeting alle zwei Wochen PM

Manager Verwaltungs-funktionen

skeptisch Informati-onsbedarf

Newsletter monatlich PMO

zusätzliche Meetings monatlich PM

Betriebsrat neutral Informati-onsbedarf

Newsletter monatlich PMO

PM/PMOProjektstatus in Betriebsratssitzungen

bei Bedarf

Manager Finanzen

kritisch wichtig Newsletter monatlich PMO


monatlich PM


Weltweite Projektleitung

positiv wichtig Newsletter monatlich PMO


monatlich PM


Geschäfts-bereich Pilotland

kritisch wichtig Newsletter monatlich PMO


monatlich PM

zusätzliche Meetings monatlich PM

Kunden/Lieferanten

neutral Informati-onsbedarf

individuelle Kommunikation

bei Bedarf PM/PMO

Prozess-/IT-Management des Pilotlandes

skeptisch wichtig Newsletter monatlich PMO

Lenkungsausschuss-meetings

monatlich PM


Tabelle 6.2 Kommunikationsplan als Ergebnis der Stakeholder-Analyse (PMO = Project Management Office; PM = Projektleiter)


227

Stakeholder-Analyse früh durchführen

Führen Sie früh im Projekt eine Stakeholder-Analyse durch, um Konflikteim Projekt zu vermeiden. Definieren Sie einen Aktionsplan für Ihre Kom-munikationsstrategie.

Checkliste der lokalen Projektvor-bereitungsphase

Für den Abschluss der lokalen Projektvorbereitungsphase wurde aufManagementlevel die in Tabelle 6.3 gezeigte Checkliste zusammen-gestellt. Auch diese Checkliste finden Sie im Downloadangebot zudiesem Buch unter www.sap-press.de/3825.

Was Sie im Hinblick auf die Qualitätschecks beachten müssen, lesenSie in Abschnitt 5.4, »Qualitätssicherung«.

Lessons Learned in der Projektvorbereitung

Was waren die wichtigsten Erkenntnisse in der lokalen Projektvorberei-tungsphase?

1. Unterstützung der GeschäftsleitungDie Unterstützung der Geschäftsleitung, gerade in der Anfangsphasedes Projekts, ist extrem wichtig. Die Zuordnung der geeigneten lokalenMitarbeiter für das Projekt, die Bereitstellung der Räumlichkeiten undInfrastruktur kann dadurch zügig vorangetrieben werden. Auch dieSuche nach einem geeigneten Projektleiter kann, wenn auch mit einpaar Hürden, noch rechtzeitig für das Projekt, abgeschlossen werden.

Aufgabe Erledigt

Projektauftrag und Projektinhalte liegen vor und sind von Sponsoren freigegeben.

Projektmitarbeiter sind zugeordnet, ausgebildet und stehen dem Projekt zur Verfügung.

Abstimmung mit Fachfunktionen ist erfolgt.

Detailpläne für das Projekt liegen vor.

Informations- und Kommunikationsstruktur ist festgelegt.

Projekt-Kick-off-Meeting ist durchgeführt.

Stakeholder-Analyse ist erfolgt.

Dokumentations- und Entwicklungsstandards sind festgelegt.

Erster Qualitätscheck ist erfolgt.

Tabelle 6.3 Checkliste der lokalen Projektvorbereitungsphase


228

Ebenso bewährt sich die Einbindung zusätzlicher Ressourcen von Län-dern, die für einen späteren Roll-out vorgesehen sind. Damit kann derWissenstransfer frühzeitig sichergestellt werden.

2. Realistische TerminplanungDer Einführungstermin ist zu optimistisch und ohne weitere Detailpla-nungen auf ein Zieldatum ausgerichtet. Die Projektziele sind zu Beginnnicht eindeutig und klar beschrieben, und dadurch werden wichtigeAbhängigkeiten für das Projekt (in scope/out of scope) vernachlässigt.Einführungstermine sind, bevor sie kommuniziert werden, sorgfältigauf der Basis von genügend Detailkenntnissen auf ihre Machbarkeit zuüberprüfen. Mit einer sorgfältigen Planung legen Sie den Grundsteinfür den Erfolg des Projekts!

3. Stakeholder-AnalyseEine Stakeholder-Analyse in der Anfangsphase hilft, die Interessen derBeteiligten im Projekt zu verstehen, den Kommunikationsbedarf abzu-stimmen und die Kommunikationspläne danach auszurichten. Ebensohilft es Ihnen, die Fachfunktionen, die Sie für Ihr Projekt zur Unterstüt-zung brauchen, früh einzubinden.

6.3 Lokaler Business Blueprint

In diesem Abschnitt möchten wir Ihnen aufzeigen, welche Aktivitätenfür ein Pilotland im Rahmen eines globalen Roll-outs notwendig sind.Das globale Template ist entwickelt und von den Stakeholdern abge-nommen. In Abschnitt 2.2.2, »Phase 2: Business Blueprint«, haben wirbereits beschrieben, welche Aktivitäten in der Business-Blueprint-Phase ablaufen sollten, wenn Sie Ihr Projekt von Grund auf starten.

6.3.1 Aufgaben in der Blueprint-Phase

Folgende Aufgaben stehen nun an:

� Review des globalen Blueprints und Fit/Gap-Analyse durchführen

� lokale Anforderungen erarbeiten

� notwendige Organisations- und Prozessanpassungen ermitteln

� Systemarchitektur und Schnittstellen überprüfen

� Infrastruktur aufbauen

� Projektmitarbeiter schulen

� lokales Business-Blueprint-Dokument erstellen

� Endanwenderschulungen planen

� WRICEF-Dokumente für den lokalen Blueprint verfassen

Lokaler Business Blueprint 6.3

229

Lücken findenIm Rahmen einer Fit/Gap-Analyse ermitteln Sie, ob für die Pilotinstal-lation zusätzliche, im weltweiten Template nicht berücksichtigte Pro-zesse benötigt werden. Das heißt, Sie identifizieren Lücken (engl.Gaps) des globalen Templates. Voraussetzung dafür ist natürlich, dassSie vorab Ihre lokalen Geschäftsprozesse im Detail analysiert unddokumentiert haben. Es empfiehlt sich, sowohl die Analyse der loka-len Geschäftsprozesse als auch den Abgleich mit dem weltweitenTemplate in Workshops unter Beteiligung aller betroffenen Fach-funktionen durchzuführen.

Ermittlung lokaler Anforderungen

Sie ermitteln dann die für eine Implementierung im Land zusätzlicherforderlichen Anforderungen und evaluieren deren Integrierbarkeitin die vorgegebenen Prozess- und Systemarchitekturen. Dies giltauch für neue Anforderungen, die während der Projektlaufzeitgestellt werden. Lokalen Anforderungen können sowohl gesetzlicheBestimmungen (wie z. B. Steuergesetze oder auch Buchhaltungsvor-schriften) als auch spezifische Geschäftspraktiken zugrunde liegen.

Analyse der Organisation

Das auf Basis der SAP Best Practices erstellte globale Template bleibtnatürlich nicht ohne Auswirkung auf Ihre bestehenden Geschäftspro-zesse und Organisationen. Mit einer detaillierten Dokumentation kön-nen Sie die Veränderungen, die sich am Horizont abzeichnen, früh-zeitig mit den Vertretern der Fachabteilungen abstimmen und so eingutes Change Management gewährleisten. Wenn Sie die Betroffeneneinbinden, können Sie Widerstände gegen Veränderungen entkräften.

Systemarchitektur und Infrastruktur

Sie prüfen, ob in der Systemarchitektur zusätzliche, lokale Integra-tions- und Schnittstellenszenarien notwendig sind. Sie bauen die fürdas Pilotprojekt notwendigen Infrastrukturen auf. Es kann u. a.erforderlich sein, im Projekt zusätzliche Systeme für Entwicklung,Test oder Schulungen zu etablieren. Dies schließt entsprechendeQualitätssicherungsmaßnahmen für diese Systeme mit ein.

SchulungenUm dies alles zu erreichen, schulen Sie Ihre Projektmitarbeiter imDetail über die eingesetzten SAP-Komponenten und das globaleTemplate. Daraus abgeleitet planen Sie die erforderlichen Endanwen-derschulungen. Sie legen dabei insbesondere die Art und den Detail-lierungsgrad der Schulungen fest, die für die jeweiligen Fachaufga-ben im Unternehmen erforderlich sind.

Lokale Business-Blueprint-Dokumentation

Während des lokalen Business Blueprint werden Erweiterungen undAnpassungen der globalen Business-Prozesse und zusätzlich die loka-len Prozesse (also die Prozesse, die nicht zum globalen Template


230

gehören) definiert, erarbeitet und dokumentiert. Als Ergebnis ent-steht die umfassende Dokumentation der im Pilotland zu implemen-tierenden Lösung, bestehend aus globalem Template und lokalenErweiterungen/Anpassungen. Auch die lokalen Erweiterungen/Anpassungen werden in den in Kapitel 2 beschriebenen PDDs (Pro-cess Definition Documents) behandelt

WRICEF-Dokumente

Zusätzlich werden alle Objekte, die während der Pilotimplementie-rung zu entwickeln sind, definiert und beschrieben. Dabei entste-hen, genau wie beim Blueprint des globalen Templates, die WRICEF-Dokumente für den lokalen Blueprint. WRICEF steht für Workflows,Reports, Interfaces, Conversions, Enhancements und Forms. DieseDokumente bilden, gemeinsam mit den lokalen PDDs, die Doku-mentation für die zu implementierenden Funktionalitäten – in unse-rem Fall für die Implementierung für das Pilotland.

Zusätzlich zu den PDDs entstehen dabei entweder Anpassungen deraus dem globalen Template vorhandenen Dokumente (mit einemneuen Abschnitt für die Änderung oder etwa ein Anhang für dasDokument) oder ein neues Dokument für wirklich neue Funktionali-tät, die für das Pilotland entwickelt wird. Das gilt für alle Entwick-lungsobjekte, die für das Pilotland in der folgenden Realisierungs-phase umgesetzt werden sollen.


Das globale Prozessdesign-Template ist der Grundstein für gemeinsameweltweite Prozesse und für zukünftige Anforderungen. Der Ansatz,ein länderübergreifendes internationales Prozessteam bereits in derEntwicklung einzusetzen, ist richtig und hat sich bewährt. Auf derBasis des globalen Templates können Aufgaben wie z. B. die Planungder Ausbildungsstrategie, Infrastrukturvoraussetzungen, System-architektur und Schnittstellen sowie Change-Management-Aufgabenin der Projektvorbereitungsphase bearbeitet werden.

Das Pilotteam konzentriert sich in der Blueprint-Phase im Wesentli-chen auf die lokalen Prozessanforderungen, die wir nachfolgendbesprechen.

Analyse derIst-Prozesse

Das Prozessteam kann auf eine bereits vorhandene Dokumentation derIst-Prozesse zurückgreifen. Allerdings stellt sich schnell heraus, dassdie vorliegenden Dokumentationen oft nicht auf dem aktuellen Standsind und deshalb aktualisiert werden müssen. In einzelnen Fällen


231

fehlt die Dokumentation komplett. Die Aktualisierung aller erforder-lichen Prozessdokumente oder Neuerstellung ist ein erheblicher zu-sätzlicher Aufwand, der in den Projektplänen so nicht berücksichtigtist. Für den Abgleich mit dem globalen Template sind aktualisierteProzessdokumentationen jedoch die Voraussetzung. Besondere Pro-bleme gibt es z. B. mit der fehlenden Dokumentation für ein Provisi-onsabrechnungsprogramm. Das Programm wurde von einem Pro-grammierer entwickelt, der schon lange das Unternehmen verlassenhatte. Das Programm läuft im Betrieb weitgehend ohne Störung. Ein-fache Anpassungen werden von Zeit zu Zeit von verschiedenen Fach-kräften vorgenommen, aber auch nicht weiter dokumentiert. Die Do-kumentation muss deshalb von Grund auf neu erstellt werden, womiteinige Fachkräfte für eine Woche beschäftigt sind.

Abgleich der Ist-Prozesse

Im nächsten Schritt werden funktionsübergreifende Workshopsdurchgeführt, mit dem Ziel, die Gaps im globalen Template zu identi-fizieren und zu dokumentieren, immer mit der Vorgabe »Prioritäthat das globale Template«. Es sollen nur die gesetzlich vorgeschriebe-nen Anforderungen umgesetzt werden, wie z. B. steuerliche Beson-derheiten oder spezielle Import-Export-Regelungen. Diese Vorgabeeinzuhalten, ist für die weitere Entwicklung des globalen Templatessehr wichtig. Die Erfahrung hat aber auch gezeigt, dass genügendRaum für lokale Anpassungen eingeplant werden muss. Das könnendurchaus auch mal Anforderungen sein, die nicht gesetzliche Vorga-ben betreffen, aber für den Geschäftsbetrieb von elementarer Bedeu-tung sind, z. B. individuelle Angebotsregelungen für bestimmte Pro-duktgruppen in einem Land.

Es kommt aber immer wieder vor, dass einzelne Fachfunktionen ver-suchen, die bestehenden Ist-Prozesse beizubehalten nach demMotto: »Das haben wir schon immer so gemacht.« Und das, obwohldie Einführung der im globalen Template dokumentierten Prozesseproblemlos möglich ist. Falls in diesen Fällen keine Einigung zwi-schen Fachfunktion und Projektteam zu erzielen ist, wird der lokaleLenkungsausschuss involviert, der in der Regel zugunsten der stan-dardisierten Prozesse im globalen Template entscheidet.

Effizientes Anforderungs-management

Das weltweite Entwicklungsteam wird bereits im Pilotland mitzusätzlichen lokalen Anforderungswünschen konfrontiert, die mannicht im Plan hat. Aufgrund dieser Erfahrung und um den Prozessdes Anforderungsmanagements für zukünftige Roll-outs, die entspre-chend der Planung auch parallel stattfinden sollten, besser in den


232

Griff zu bekommen, werden zusätzliche Rollen und Verantwortlich-keiten eingeführt. So wird ein Integrationsteam für die Prozessana-lyse und eine Systemarchitektenrolle im weltweiten Entwicklungs-team eingeführt:

� IntegrationsteamDas Integrationsteam hat die Aufgabe, neue Anforderungen ausprozessualer Sicht »gesamtheitlich« zu analysieren und damitsicherzustellen, dass diese in die strategische Gesamtlösung über-nommen werden können.

� SystemarchitektenrolleDie Systemarchitektenrolle wird von IT-Experten mit SAP-Kennt-nissen übernommen. Alle Anforderungen werden daraufhin über-prüft, ob sie in die SAP-Architektur passen und ob es Schnittstel-lenprobleme mit den vorund/oder nachgelagerten Verfahrengeben könnte. Ebenso muss die Durchgängigkeit über mehrereSAP-Komponenten sichergestellt werden. Oberstes Prinzip istdabei immer die Nutzung des SAP-Standards: Anpassungen, dieüber die Möglichkeiten des Customizings hinausgehen, gilt es zuvermeiden.

Prozess- undArchitektur-

Reviews

Es werden Prozessdesign-Reviews und Architektur-Reviews eingerich-tet, um die Qualität und die Umsetzung der Entwicklungstätigkeitenzu verbessern. Die Entwicklungspläne, basierend auf den Prozess-Design-Dokumenten, werden dadurch besser strukturiert und einintegriertes technisches Design eingeführt.

Die Reviews haben die folgenden Aufgaben:

� die Prüfung und Freigabe der finalen Prozessdesign-Lösung

� die Verifikation der Anwendungslösung gegenüber den gestelltenAnforderungen

� die Gewährleistung einer einheitlichen funktionsübergreifendenProzessdesign-Lösung

� die Identifizierung von Risiken und Abhängigkeiten wie z. B. mög-liche Einflüsse auf die Konvertierung von Daten, Job-Profilen oderauch Prozess-Kontrollpunkten etc.


233

� die Prüfung möglicher Einflüsse auf die Systemarchitektur

� die formale Zustimmung des Antragstellers zur vorgeschlagenenLösung

Die Reviews finden wöchentlich in Telefonkonferenzen mit allen Part-ner-Organisationen unter der Leitung des weltweiten Entwicklungs-und Implementierungsteams statt. Damit kann sichergestellt werden,dass Änderungen am gemeinsamen globalen Template von allen ak-zeptiert werden.

In den Telefonkonferenzen sind im Durchschnitt mehr als 20 inter-nationale Teilnehmer vertreten. Entscheidend für das Gelingen istdeshalb eine sorgfältige Vorbereitung der Agenda und Disziplin beider Durchführung der Konferenz. Einige Teilnehmer schalten sichregelmäßig aus dem Home-Office zu. Um dabei Nebengeräusche imHintergrund wie Vogelgezwitscher, Hundegebell oder Geschirrklap-pern zu vermeiden, bekommt die Benutzung der Stumm-Taste desTelefons eine nicht zu unterschätzende Bedeutung.

Das System live erleben: der Prototyp

Besonders wertvoll sowohl für die Projektmitarbeiter im Pilotlandals auch für Anwender aus den betroffenen Fachabteilungen ist derZugriff auf einen Prototyp des SAP-Systems. Der Prototyp wird vomweltweiten Entwicklungs- und Implementierungsteam bereitgestellt.Dort werden ausgewählte Geschäftsprozesse im SAP-Standard abge-bildet. Die Anwender und Projektmitarbeiter können also bereitslive das SAP-System erleben, wodurch ein besseres Verständnis überdie zukünftige SAP-Lösung erreicht wird. Die Abstimmung zwischenPilotprojektteam, den Fachabteilungen und dem weltweiten Ent-wicklungs- und Implementierungsteam kann dadurch erheblicherleichtert werden.

Lokale WRICEF-Dokumente

Mit dem globalen Template, ergänzt um lokale Prozessanforderun-gen, und der SAP-Systemarchitektur inklusive aller Schnittstellensteht nun ein »implementierbarer Blueprint« für die Entwicklung inder Realisierungsphase zur Verfügung.

Checkliste der Business-Blueprint-Phase

Tabelle 6.4 zeigt die Checkliste der Blueprint-Phase, die Sie wiederim Downloadangebot zu diesem Buch unter http://www.sap-press.de/3825 finden.


234

Lessons Learned in der Blueprint-Phase

Was sind die wichtigsten Erkenntnisse in der Blueprint-Phase?

1. Akzeptanz des globalen TemplatesDas vorgegebene globale Template wird von allen Stakeholdern alsBasis für die SAP-Implementierung akzeptiert.

2. Durchdachtes AnforderungsmanagementEin diszipliniertes Anforderungsmanagement trägt dazu bei, die loka-len prozessualen Anforderungen im Rahmen zu halten. Zur Unterstüt-zung dieses Prozesses werden zwei neue Rollen definiert, das Integra-tionsteam für die Prozessanalyse und die SAP-Architektenrolle. Ebensovon Bedeutung und unterstützend sind die wöchentlichen Prozess-design-Reviews mit dem weltweiten Entwicklungs- und Implementie-rungsteam.

3. Nutzung eines PrototypsDer Prototyp trägt zu einem besseren Verständnis für das Pilotprojekt-team und die Fachfunktionen über die Arbeitsweise des neuen SAP-Systems bei und bildet Vertrauen. Wichtige Entscheidungen können soschneller getroffen werden, und damit kann Zeit gewonnen werden.

6.4 Die Realisierungsphase

In der Realisierungsphase werden über einen längeren (langen) Zeit-raum verschiedene Aktivitäten abgearbeitet. Diesen finden mitunternur einmalig statt (etwa der Aufbau der Infrastruktur), werden in

Aufgabe Erledigt

Detaillierung der lokalen Geschäftsprozess-Anforderungen im Business-Blueprint-Dokument liegt vor und wird von Projektsponsoren freigegeben.

Definition der technischen Anforderungen (SAP-Systemar-chitektur) zur Umsetzung der Geschäftsprozessanforderun-gen ist erfolgt. Schnittstellen/Interfaces und Erweiterungen sind festgelegt.

Erste Analyse möglicher Organisationsanpassungen wird durchgeführt.

Technisches Entwicklungssystem ist installiert.

Qualitätscheck wird durchgeführt (siehe Abschnitt 5.4, »Qualitätssicherung«).

Tabelle 6.4 Checkliste der Blueprint-Phase

Die Realisierungsphase 6.4

235

bestimmten Abständen wiederholt oder laufen über einen längerenZeitraum parallel zu anderen Aktivitäten. Wir werden die wichtigs-ten Aufgaben der Realisierungsphase in diesem Abschnitt kurzbeschreiben. Die wichtigsten davon werden Sie dann später im Pra-xisbeispiel wiederfinden. In den folgenden Abschnitten betrachtenwir diese Arbeitspakete genauer:

� Infrastruktur implementieren sowie die Systemlandschaft und dieIntegrationsarchitektur aufbauen

� Systemkonfiguration (Customizing) und Softwareentwicklung (Programmierung) durchführen

� testen, testen, testen

� die Datenmigration vorbereiten

� Go-Live und Transition (das ist der Übergangsprozess vom Projektin den stabilen Produktivbetrieb) vorbereiten

� die Realisierungsphase abschließen, das beinhaltet Aktivitäten wiedie Übergabe der Lösung an die Betriebsmannschaft, Dokumen-tation fertigstellen, Projekt offiziell beenden

6.4.1 Implementierung der Infrastruktur

Um die in der Blueprint-Phase entwickelten neuen Geschäftspro-zesse zum Leben zu erwecken, benötigen Sie als Erstes eines ganzdringend: die entsprechenden SAP-Systeme. Eventuell sind bereitseinige Systeme im Rahmen des Prototyps im Einsatz. Aber jetztwird es wirklich ernst. Um die nächste Teilphase, den Aufbau derInfrastruktur, einzuläuten, sind alle geplanten SAP-Systemkompo-nenten erforderlich. Die Architekten haben sich zu diesem Zeit-punkt für eine Architektur entschieden und die SAP-Systemland-schaft entworfen.

SpielsystemeIm ersten Schritt benötigen Sie die entsprechenden Entwicklungssys-teme. Bewegen Sie sich technologisch auf Neuland, sind zusätzliche»Spielsysteme« sinnvoll (auch Sandbox-System genannt – gewisserma-ßen der Sandkasten des Entwicklers). Hier können die Entwicklerund Customizer neue Lösungen nach Herzenslust ausprobieren,ohne gleich das Entwicklungssystem zu »verunreinigen«. Ausprobie-ren heißt, mit Implementierungsversuchen zu füllen.


236

Wie eine solche Architektur aussehen könnte, zeigt Abbildung 6.6.Das Bild zeigt beispielhaft das Zusammenwirken von Komponentenaus der SAP Business Suite (hier SAP ERP und SAP SRM) mit der SAP-NetWeaver-Plattform.

Abbildung 6.6 Beispiel für eine SAP-Systemarchitektur

Abbildung 6.7 zeigt die notwendige Systemlandschaft zum aktuellenZeitpunkt des Projekts. Die einzelnen Systeme dienen dabei bestimm-ten Projektaufgaben: In den Entwicklungssystemen SAP ERP, SAPSRM, SAP Enterprise Portal und SAP BW arbeiten Entwickler undCustomizer an der Lösung. Die Integrationsexperten nutzen das PI-Ent-wicklungssystem für die Erstellung der Integrationsarchitektur. OffeneFragen werden gemeinsam mit den Experten aus den Geschäftspro-zess-Teilprojekten in den Sandbox-Systemen simuliert und gelöst.

ZentraleDrehscheibe

Alle Systeme sind mit dem SAP Solution Manager verbunden. Er ist diezentrale Drehscheibe bei der Realisierung Ihres SAP-Projekts. Hierlaufen alle Konfigurationen und Entwicklungen zusammen. Über dasChange Request Management im SAP Solution Manager (mit dem char-manten Akronym ChaRM) werden über die gesamte Realisierungs-phase (und weit darüber hinaus) alle Objekte im SAP-System, diedurch Entwicklung und Customizing an Ihren Blueprint angepasstwerden, synchron und konsistent gehalten. Nur die Spielsysteme(Sandboxen) sind nicht mit dem SAP Solution Manager verbunden.

SAP ERP(SAP ERP 6.0

EHP 7)

SAP NetWeaver ApplicationServer 7.4

SAP BW(SAP BW 7.4)

SAP SRM(SAP SRM 7.0

EHP 2)

SAP SolutionManager

(SAP Solution Manager 7.1)

Prozess-/SystemintegrationSAP Process Integration 7.4

RFC RFC RFC

IDoc

RFC RFC

Extraktor

PortalSAP Enterprise Portal 7.4

SAP GUISAP GUI SAP BExWEB GUI SAP BEx





237

Abbildung 6.7 Zu implementierende Systemlandschaft

Qualitätssiche-rungs- und Schulungssysteme

Sobald Ihr Projekt etwas fortgeschritten ist, werden Ihre Expertenerste Prozesse testen wollen, und das Schulungsteam wird Beispiels-zenarien erstellen wollen. Zu diesem Zeitpunkt werden weitere Sys-teme erforderlich. Das sind die Systeme zur Qualitätssicherung (QA-Systeme zum Testen und Abnehmen) und die Schulungssysteme. Dieentsprechende Systemlandschaft sieht dann etwa so aus, wie inAbbildung 6.8 dargestellt.

Die Schulungssysteme werden dabei nur mit bestimmten Software-und Customizingobjekten und -Releaseständen beliefert, je nachAnforderung des Schulungsteams.

Jetzt wird’s produktiv

Der letzte Schritt bei der Implementierung der Systemlandschaft istder Aufbau der produktiven Systemlandschaft. Diese erfolgt bereitseinige Zeit vor dem Go-Live. Da die produktiven Server meist leis-tungsstärker als die Entwicklungs-, Test- und Schulungssysteme sind,lassen sich hier Tests für Performance, Migration und Go-Live besserdurchführen.

SAP PIEntwicklungs-

system

EP1

SAP ERPEntwicklungs-

system

EB1

SAP BWEntwicklungs-

system

EB2

SAP SRMEntwicklungs-

system

ES1

SAP ERPSandbox

SB1

SAP BWSandbox

SB2

SAP SRMSandbox

SB3

SAP SolutionManager

Entwicklungs-system

ESM


238

Abbildung 6.8 Systemlandschaft mit Test- und Schulungssystem

Die zu den vorherigen Abbildungen passende Systemlandschaftkönnte dann wie in Abbildung 6.9 aussehen. Da spätere Roll-outserneut Testsysteme benötigen, können diese gleich erhalten bleiben.

Noch mehr Systeme

Noch eine Bemerkung zur Infrastruktur des SAP Solution Managers: Dadie Einführung des SAP Solution Managers ein eigenes Projekt ist (sieheAbschnitt 8.1.6, »SAP Solution Manager«) gilt das Gleiche wie für die spä-teren produktiven SAP-Systeme auch für den SAP Solution Manager. Esgibt also mindestens ein Entwicklungssystem und einen produktiven SAPSolution Manager. Nutzen Sie den SAP Solution Manager extensiver, istein Qualitätssicherungssystem zusätzlich erforderlich.


systemEB1

SAP BWEntwicklungs-

systemEB2


systemER1

SAP PIEntwicklungs-

systemEP1

SAP SolutionManager

Entwicklungs-systemESM

SAP ERPQA-System

QB1

SAP PIQA-System

QP1

SAP SRMQA-System

QR1

SAP BWQA-System

QB2

SAP ERPSchulungs-

systemSB1

SAP BWSchulungs-

systemSB2

SAP SRMQA-System

SR1


239

Für spätere Roll-outs – die eventuell parallel realisiert werden – oderfür die Zeit nach dem ersten Go-Live ist es sinnvoll, die Systemland-schaft pro Komponente auf fünf oder gar sieben Systeme auszu-bauen.

Abbildung 6.9 Endgültige Systemlandschaft für die Pilotimplementierung

Weiterführende Literatur zur Systemlandschaft

In dem folgenden Buch finden Sie alle Informationen, die Sie zum Planen,Implementieren und Warten von Systemlandschaften benötigen: SAP-Änderungs- und Transportmanagement von Armin Kösegi und Rainer Ner-ding (SAP PRESS 2013).

Das »Adressbuch« für Ihr SAP-System

Eine Abbildung der Systemlandschaft entsteht im SAP SystemLandscape Directory im SAP Solution Manager. Hier sind neben dertechnischen Integration der einzelnen Komponenten auch die jewei-ligen installierten Softwarestände, Add-ons und Erweiterungen hin-terlegt. Abbildung 6.10 zeigt die zentrale Verwaltung aller SAP-Kom-ponenten, die am Projekt beteiligt sind, im SAP Solution Manager.


systemEB1

SAP BWEntwicklungs-

systemEB2


systemER1

SAP PIEntwicklungs-

systemEP1

SAP Solution Manager

Entwicklungs-systemESM

SAP ERPQA-System

QB1

SAP PIQA-System

QP1

SAP SRMQA-System

QR1

SAP BWQA-System

QB2

SAP ERPProduktivsystem

PB1

SAP PIProduktivsystem

PP1

SAP BWProduktivsystem

PB2

SAP SRMProduktivsystem

PR1

SAP ERPSchulungs-

systemSB1

SAP BWSchulungs-

systemSB2

SAP SRMQA-System

SR1


240

Abbildung 6.10 Systemlandschaft im SAP Solution Manager

6.4.2 Systemkonfiguration und Softwareentwicklung

Gratulation! Die Infrastruktur steht. Das heißt, dass in Ihren Ent-wicklungssystemen die folgenden grundlegenden Einstellungen vor-genommen sind:

� Die erforderliche SAP-Software ist mit den vereinbarten Release-ständen installiert.

� Die vereinbarten Support Packages sind implementiert, getestetund freigegeben.

� Die Systeme sind an das SAP-Änderungs- und -Transportwesenangeschlossen.

� Die grundlegenden Systemeinstellungen sind abgeschlossen undfreigegeben.

� Die Betriebsmannschaft ist an Bord und eingewiesen.

BW

PI

SRM

ERP

Lösungslandschaft

SAP Solution Manager –

System- landschaft

Server, Datenbank, Systeme, System-

komponenten


241

� Der Prozess für die Verteilung der Software ist klar und implemen-tiert.

� Sämtliche Arbeitsunterlagen (Namenskonventionen für Customi-zing und Entwicklung, Dokumentation der Systemlandschaft etc.)sind vorhanden, bekannt und abgenommen.

Alle Mann an Bord!Das Projektteam vergrößert sich mit dem Beginn der Realisierungs-phase stark. Die Schulung aller neuen Projektmitarbeiter über allge-meine Vorgehensweisen im Projekt und die bisher erreichten Ergeb-nisse ist daher unbedingt notwendig, um einen reibungslosen Startder Realisierungsphase zu erreichen.

Und welche Aufgaben stehen nun auf der Agenda? Das lesen Sie inden folgenden Abschnitten.

Basiskonfiguration

Grundlagen schaffen

Die Basiskonfiguration wird für jedes in der Systemlandschaft inte-grierte SAP-System einmal zu Beginn der Implementierung vorge-nommen. Hier werden SAP-spezifische Parameter gesetzt (z. B. imBetriebssystem der SAP-Server und den verwendeten Datenbanken).Zusätzlich wird die Grundlage für die Integration der SAP-Kompo-nenten untereinander und mit der übrigen IT-Welt gelegt. Damitkönnen dann später die systemübergreifenden Prozesse ohne großestechnisches Wissen implementiert und genutzt werden.

Auch die Vorbereitung und Integration der SAP-Systeme in dasBenutzernetzwerk fallen in den Bereich der Basiskonfiguration. Sowerden viele der Personen, die jetzt mit den Systemen arbeiten(Softwareentwickler, Customizer, Tester), das SAP-eigene Frontend(SAP GUI) nutzen. Das muss ebenfalls installiert, verteilt (entwederauf den PCs der Benutzer installiert oder über einen virtuellen Desk-top an den Benutzer gebracht werden) und konfiguriert werden. AmEnde der Basiskonfiguration sind die erforderlichen SAP-Systeme soweit einsatzbereit, dass die eigentliche Implementierung der Ge-schäftsprozesse starten kann.

Berechtigungen und Zugang zum System

Systemzugang kontrollieren

Damit die Experten mit dem System arbeiten können, müssen zuBeginn zuerst die Anwender und entsprechende Berechtigungen ange-legt werden. Für das Projektteam sind weitreichende Berechtigungen


242

erforderlich, sonst lässt sich das System nicht einstellen. Die nament-liche Nennung von Anwendern wird dabei aber dringend empfohlen.Somit ist die Nachvollziehbarkeit der Änderungen gegeben.

Weiterführende Literatur zu Berechtigungen

In dem folgenden Buch lesen Sie, wie Sie ein Berechtigungskonzept ent-wickeln und implementieren: SAP-Berechtigungswesen von Volker Leh-nert, Katharina Stelzner, Peter John und Anna Otto (SAP PRESS 2012).

Konfiguration

Die im Blueprint verfassten Dokumente über Geschäftsprozesse,Architektur- und Integrationsszenarien und die damit verbundenenVorgehensweisen (Namenskonventionen, Datenobjektdefinitionenetc.) sind die Grundlage für die Realisierung Ihrer SAP-Applikation.

Um das SAP-System zu konfigurieren, also im Customizing die Ein-stellungen der definierten Geschäftsprozesse vorzunehmen, gibt dieSAP-Software Ihnen Hilfsmittel an die Hand:

Änderungs-kontrolle

Zum einen ist das die organisatorische Unterstützung bei der Reali-sierung. Mit der Benutzung des SAP-eigenen Änderungs- und Trans-portwesens bzw. des neueren Tools ChaRM werden sämtliche Ände-rungen im System protokolliert und der spätere Transport inQualitätssicherungs- und Produktivsysteme ermöglicht. Mit der kon-sequenten Nutzung dieser Tools wird die Qualität Ihres SAP-Systemsgewährleistet und der Aufwand dafür im Rahmen gehalten. ZentraleInstanz dafür ist der SAP Solution Manager. Abbildung 6.11 zeigt dieInteraktion der einzelnen Projektmitarbeiter bei der Nutzung desChaRM-Prozesses. Diese verschiedenen, an der Entwicklung und amCustomizing beteiligten Projektmitarbeiter haben bestimmte Aufga-ben (Änderung anfordern, Änderung entwickeln, testen, freigeben).Diese Aufgaben werden vom ChaRM-Prozess unterstützt.

Dieser Prozess ist für Customizing und Softwareentwicklung gleich.Damit können unterschiedliche Softwarestände der SAP-Implemen-tierung definiert und durch einen konsistenten Transport später imQualitätssicherungssystem getestet werden. (Diese SAP-Softwarever-sionen werden auch Releases genannt und entsprechen dem Standder Entwicklung der SAP-Lösung zu einem bestimmten Zeitpunkt.)Nur so ist die Zusammenarbeit unterschiedlicher Projektmitarbeiteran einem SAP-Projekt über längere Zeit steuerbar.


243

Abbildung 6.11 Prozess zur Änderungskontrolle

Einführungs-leitfaden

Für die rein fachliche Implementierung der Geschäftsprozesse durchCustomizing (also dem Einstellen der SAP-Standardkonfiguration aufdie Erfordernisse Ihrer Lösung) gibt es ebenfalls ein Hilfsmittel. Dasist der Einführungsleitfaden (engl. Implementation Guide) im SAP-Sys-tem. Hier werden alle erforderlichen grundlegenden Einstellungenvom jeweiligen System vorgegeben. Sie erstellen für Ihre Lösung eineigenes entsprechendes Projekt im SAP Solution Manager und in denjeweiligen Entwicklungssystemen. Die Auswahl der jeweiligen Pro-zessgruppen beschränkt die Arbeit auf die wirklich erforderlichenEinstellungen. Ein entsprechendes Beispielprojekt in SAP sehen Siein Abbildung 6.12.

Der Prozess des Customizings wird nicht linear verlaufen. Nachdemdie grundlegenden Einstellungen in den Systemen erfolgt sind, wer-den Sie Unterstützung aus der Entwicklungsabteilung Ihres Projektsbenötigen, und das nicht nur für die Entwicklung neuer Funktionali-tät oder von Schnittstellen, nein, auch die Standardimplementierungwird Entwicklungsarbeiten erfordern, so z. B. in SAP ERP HCM, derSAP-Komponente für die Personalwirtschaft, oder bei der Anpassungvon Workflows. Auch für den einen oder anderen Report zur Aus-wertung oder zum Test der bisherigen Implementierung werdenneue Programme benötigt.

kontrollierte Transporte

SAP ERPProduktivsystem

PB1

SAP Solution Manager

Entwickler

Anforderer

Tester

Administrator

Cha

nge

Req

uest

Man

agem

ent

Anforderung aus dem Blueprint

Doku-mente

Task-Liste

Change Request

ChangeManager SAP ERP

QA-System

QB1


systemEB1

kontrollierte Transporte


244

Abbildung 6.12 Leitfaden für die Implementierung in SAP

Entwicklung

Sobald das System in Grundzügen funktioniert, also Basiskonfigura-tion und die grundlegende Konfiguration der Prozesse abgeschlossensind, werden die Softwareentwickler ihr Werk beginnen.

Organisatorische Grundlage ist hierfür ebenfalls das KTW und dazu-gehörige Tools wie ChaRM. Die Vorgehensweise ist nahezu iden-tisch. Und die fachliche Grundlage ist, genau wie beim Customizing,die Dokumentation des Business Blueprint.

WRICEF-Tabelle Die Entwicklungsobjekte als Teil der Blueprint-Dokumentation kön-nen wir aus der sogenannten WRICEF-Tabelle und den dazugehöri-gen Dokumenten übernehmen. Für die einzelnen Objekttypen erge-ben sich zum Teil unterschiedliche Aufgaben und Vorgehensweisen.

Workflows Workflows sind Teil einer jeden Implementierung. Zum einen sindsie Bestandteil der Standardfunktionalität, etwa bei Freigaben imModul HCM, Benachrichtigungen aus dem Organisationsmanage-ment oder auch bei der Überwachung des Systembetriebs. DieseWorkflows sind im System voreingestellt und werden nur aktiviertund eingestellt. Das ist eigentlich »nur« Customizing. Zusätzlich las-sen sich bei Bedarf weiterführende Workflows realisieren. Diesebenötigen oft eine zusätzliche Programmierung, etwa für den Start-punkt des Workflows oder bestimmte Aktivitäten. Workflows, auchzusätzlich implementierte, erfordern meist keine Veränderung der


245

Standardfunktionalität und sind eine Erweiterung des Standards imStandard.

ReportsReports heißen eigentlich die Programme in SAP. In diesem Zusam-menhang sind aber meist Programme zur Informationsgewinnunggemeint. Da wir in unserer Beispielarchitektur ein BI-System zum»Reporting« implementiert haben, werden wir nur sehr sporadischzusätzliche Programme dafür benötigen.

InterfacesInterfaces (also Schnittstellen) werden in jedem Projekt entwickelt.Die Spezifikation als Grundlage für die Entwicklung steht in denIDDs (Interface Definition Documents). Es gibt verschiedene Schnitt-stellen und verschiedene Wege, sie zu implementieren:

� Punkt-zu-Punkt-SchnittstellenDabei werden auf der Basis vorhandener Protokolle und Techno-logien (etwa Filetransfer, Remote Function Call (RFC), IntermediateDocument (IDoc), Application Link Enabling (ALE)) Geschäftspro-zessanforderungen über Systemgrenzen hinweg realisiert oderLegacy-Systeme angebunden. Diese Schnittstellen werden für denjeweiligen Anwendungsfall individuell entwickelt und getestet.

� Schnittstellen unter Verwendung von EAI-SystemenDiese Schnittstellen werden dagegen oft als Teil der Implementie-rung einer EAI-Software (EAI = Enterprise Application Integration)entwickelt (z. B. SAP PI, IBM WebSphere, Tibco, Seeburger). Hier-bei steht die Wiederverwendbarkeit der implementierten Schnitt-stellen im Vordergrund. Die technologische Anbindung an dieSAP-Systeme ist oft ähnlich wie bei den Punkt-zu-Punkt-Verbin-dungen.

� ESB (Enterprise Service Bus)-IntegrationenESB-Integrationen stellen den höchsten Grad der Integration dar.Hierbei werden die Schnittstellen auf Basis von Services realisiert,die im Systemverbund wiederverwendbar sind. Die Definitiondieser Schnittstellen ist entsprechend aufwendiger (es müssen dieIDDs mehrerer verschiedener Schnittstellen in eine Realisierungüberführt werden). Außerdem ist die Implementierung der ESB-Infrastruktur weitaus komplexer als bei einer »einfachen« Schnitt-stelle.

� EinmalschnittstellenZusätzlich werden noch sogenannte Einmalschnittstellen benötigt.Diese sind eigentlich nicht Teil der Beschreibung der Geschäftspro-


246

zesse, sondern ergeben sich aus den Aktivitäten zur Datenmigra-tion und dem Go-Live. Diese werden entweder speziell entwickeltoder durch entsprechende Tools bereitgestellt und angepasst (etwadie LSMW (Legacy System Migration Workbench)) der SAP.

Weiterführende Literatur zu Schnittstellen

In diesem Buch lernen Sie alles, was Sie dazu über Schnittstellen und Pro-tokolle wissen müssen: SAP-Schnittstellenprogrammierung von MichaelWegelin und Michael Englbrecht (SAP PRESS 2014).

Conversions Conversions sind ein anderer Aspekt der Datenübernahme aus denLegacy-Systemen (Altsystemen) oder auch der permanenten Anbin-dung externer Systeme. Durch unterschiedliche Datenmodelle oderunterschiedliche Definition von Datenobjekten muss eine Konvertie-rung der Formate oder auch eine geänderte Zuordnung von Datenin-halten erfolgen. Für die einmalige Übernahme von Daten bei derMigration kann das auch außerhalb der beteiligten Systeme gesche-hen. Für permanente Schnittstellen ist eine Programmierung erfor-derlich. Bei der Nutzung von EAI- oder ESB-Systemen ist auch dieRealisierung als wiederverwendbarer Service möglich.

Enhancements Enhancements (Erweiterungen, siehe auch Abschnitt 1.4.1, »Undwenn der Standard nicht reicht?«) sind Erweiterungen oder Ände-rungen der Standardfunktionalität von SAP durch Programmierung.Hier ist eine enge Zusammenarbeit von fachlichen Teams (alsodenen, die die Geschäftsprozesse realisieren) und Entwicklerteamserforderlich. SAP stellt Möglichkeiten und Werkzeuge zur Erweite-rung der Funktionalität zur Verfügung, die hier angewendet werden,etwa User-Exits, Business Add-ins (BAdIs), Enhancement Frameworkund serviceorientierte Architekturen (SOA). Neben der Abstimmungzwischen Entwicklung und Prozessimplementierung ist auch eineenge Abstimmung zwischen den verschiedenen Entwicklungsteamserforderlich. Die Entwicklungsteams für Enhancements werden auchspäter beim Test der Geschäftsprozesse involviert sein. Denn bei Pro-blemen während der Ausführung von Geschäftsprozessen ist es nichtmehr vordergründig ersichtlich, ob das Problem durch Fehler imCustomizing, bei den Daten oder bei der Programmierung der Erwei-terung entstanden ist.

Forms Forms (Formulare) gehören am Ende zu jeder SAP-Implementierung.Ob für Bestellungen, Rechnungen, Stundennachweise, beim Druck,


247

beim Faxen oder bei der Versendung von E-Mails, die Daten müssenin eine ordentliche Form gebracht werden. Das geht zwar immernoch durch Programmierung, oft werden hierfür aber auch externeTools genutzt.

Jedes Objekt wird bei der Programmierung auch gleich getestet. Die-ser Test umfasst aber nur die grundlegende Funktionalität und diefehlerlose Ausführbarkeit der Entwicklungsobjekte. Ob die Lösungauch in einem weiteren Kontext funktioniert, wird in den eigentli-chen Testzyklen überprüft.

6.4.3 Testen

Vertrauen ist gut, testen ist besser

Welche Testzyklen typischerweise zu einem SAP-Projekt gehören,haben wir in Abschnitt 2.2.3, »Phase 3: Realisierung«, vorgestellt. Indiesem Abschnitt zeigen wir Ihnen den Ablauf der Tests in der Rea-lisierungsphase etwas genauer.

Unit-TestDass während des Entwicklungsprozesses der einzelnen Objekte dieEntwicklungsteams auf die Richtigkeit ihrer Programme achten,scheint selbstverständlich. Aber in diesen Unit-Tests geht es noch ummehr. Damit später ein Rädchen der Lösung ins andere greifen kann,sind bestimmte Programmierstandards und Namenskonventioneneinzuhalten. Die Objekte werden programmiert, dokumentiert undgetestet. Am Ende gibt es die Freigabe zur Nutzung. Da mitunter einObjekt Grundlage für eine andere Programmierung ist, sind dieseTests (genau wie die Programmierung) genau zu planen.

Durch die Planung des Entwicklungs- und Testablaufs für die Unit-Tests sind zu einem bestimmten Zeitpunkt im System ganze Prozess-abläufe »fertig«. Diese Abläufe werden dann im funktionalen Testzusammenhängend überprüft. Im SAP-Kontext werden also mehrereaufeinanderfolgende Transaktionen getestet. Hier wird der Programm-ablauf, aber auch schon die Verarbeitung von Daten überprüft.

Scenario-TestIm Scenario-Test werden bereits erste Szenarien getestet, die nichtdirekt zusammenhängen, etwa die Anlage von Kunden und dieanschließende Nutzung der Kundendaten für die Auftragsanlage.Hier zeigt sich dann besonders, dass eine gute Planung der Aktivitä-ten zu einer erfolgreichen Testdurchführung beiträgt. Nichts ist zumjetzigen Zeitpunkt schlimmer, als wenn notwendige Objekte laut Pla-nung erst später realisiert werden.


248

Integrationstest Der Integrationstest geht über Systemgrenzen hinaus. Jetzt wird sichzeigen, ob die einzelnen Objekte und Szenarien auch wirklichzusammenspielen. Die Schnittstellen werden jetzt ebenfalls im Kon-text der Geschäftsprozesse getestet.

Performancetest Parallel dazu laufen die ersten Performancetests an. Die Annahme,dass man die Performance eines SAP-Systems durch das Einstellenbestimmter Parameter oder ein paar mehr CPUs oder etwas mehrRAM stark beeinflussen kann, wird hier wahrscheinlich widerlegt.Einen großen Einfluss hat die Art und Weise, wie das System de-signed ist und wie programmiert wird. Es kann also durchaus sein,dass die Programmierer noch einmal Hand anlegen müssen.

Wenn alles läuft, nach Ansicht des Testteams, werden die späterenAnwender, die Teil des Projektteams sind, das System im User-Acceptance-Test noch einmal auf Herz und Nieren prüfen. Spätestensfür diesen Test benötigen Sie Daten im System, die das Migrations-team bereitstellt (siehe Abschnitt 6.4.4, »Vorbereitung der Daten-migration«).

Testunterstützungdurch Prozess-

experten

Die Geschäftsprozessexperten sollten die notwendigen Testszena-rien mit erarbeiten. Wenn in dem neuen SAP-System z. B. der Ablaufbei der Bearbeitung von Kundenaufträgen verschiedene Ausprägun-gen haben soll, müssen diese getestet werden. Das betrifft beispiels-weise das Anlegen von Innenaufträgen, von Aufträgen für Materia-lien, Dienstleistungen, Sammelaufträge etc. Jede dieser Ausprägun-gen muss getestet werden, sonst kann es später ein böses Erwachengeben. Da sich verschiedene Testabläufe als Teil eines Zyklus wieder-holen, ist der Einsatz automatischer Testabläufe sinnvoll.

Eine sinnvolle Unterstützung zur Planung und Überwachung derTestabläufe bietet der SAP Solution Manager (wieder mal). Abbil-dung 6.13 zeigt den Statusbildschirm eines Testplans. Hier sindbestimmte, sich wiederholende Testszenarien zu sehen. Zu den ein-zelnen Szenarien wird der aktuelle Status angezeigt.

Abbildung 6.14 zeigt den Arbeitsvorrat für einen Tester, den Sie imWorkcenter Testmanagement über Tester-Arbeitsvorrat aufrufenkönnen. Damit können die einzelnen Testfälle bestimmten Mitarbei-tern im Testteam zugeordnet werden, womit eine effiziente Planungdes Testablaufs möglich ist.


249

Abbildung 6.13 Testmanagement mit SAP Solution Manager – hier Status

Abbildung 6.14 Arbeitsvorrat für einen Tester

In Kapitel 8, »Werkzeuge zur Projektunterstützung«, lernen Sie diewichtigsten Tools für das Testen genauer kennen.


250

6.4.4 Vorbereitung der Datenmigration

Ein weiterer wichtiger Baustein bei der Realisierung der SAP-Imple-mentierung ist die Übernahme von Daten aus den abzulösendenLegacy-Systemen (Altsystemen). Da es mitunter eine Vielzahl vonalten Anwendungen abzulösen gilt, muss zuerst einmal entschiedenwerden, welche Daten übernommen werden sollen.

Welche Datennehmen wir mit?

Erste Grundlage dafür ist natürlich der Bedarf an Datenobjekten unddazugehörigen Feldern und Inhalten in der neuen SAP-Anwendung.Dazu werden sich die Experten aus den fachlichen Teams, dieBetreuer der abzulösenden Systeme und die Datenexperten und Pro-grammierer aus Ihrem Team an einen Tisch setzen. Relativ einfachgestaltet sich diese Entscheidungsfindung für die Stammdaten.

� StammdatenDas sind all die Daten, die die Grundlage für die neuen Geschäfts-prozesse bilden und die sich relativ selten ändern. Dazu gehörenetwa Materialstammdaten, Kundendaten und Mitarbeiterdaten.

� BewegungsdatenEtwas komplizierter kann die Entscheidung bei den sogenanntenBewegungsdaten sein. Das sind z. B. Angebote, Bestellungen,Rechnungen etc., also Daten, die eine zeitliche Relevanz haben.Hier muss entschieden werden, für welchen Zeitraum diese Datenübernommen werden (und damit, für welchen Zeitraum in Ihrerneuen Lösung Informationen vorhanden sind, etwa die Bestellun-gen für einen bestimmten Kunden innerhalb der letzten x Jahre).

Auch der Zeitpunkt der Übernahme der Daten und des Go-Lives kön-nen eine Rolle bei der Datenübernahme spielen.

Die Daten inForm bringen

Sind die Objekte und die Altsysteme, aus denen die Daten übernom-men werden, definiert, geht es darum, die Daten so aufzubereiten,dass sie mit der neuen Datenstruktur kompatibel sind. Zusätzlichmüssen die Datenstrukturen des Legacy-Systems und SAP »gemappt«werden.

Schließlich müssen die Daten in das neue SAP-System übernommenwerden. Ein sehr hilfreiches Tool dafür ist die LSMW (Legacy SystemMigration Workbench). Wie diese einzelnen Prozessschritte in derLSMW hinterlegt sind, zeigt Abbildung 6.15. Der prinzipielle Ablaufbesteht immer aus drei Schritten:


251

1. Einlesen der extrahierten Daten aus den Legacy-Systemen in dieLSMW (und damit in das SAP-System, aber noch nicht in die end-gültigen Tabellen)

2. Umsetzung von der alten Struktur in die neue Struktur (eventuellunter Anwendung definierter Umsetzungsregeln)

3. Laden der Daten in die SAP-Tabellen

Abbildung 6.15 Datenübernahmeprozess in der LSMW

Abbildung 6.16 zeigt eine Projektübersicht in der LSMW.

Im Rahmen der Datenmigration nehmen die Datenbereinigung sowiedie Optimierung der Migrationsprogramme eine besondere Rolle ein.

Daten säubernEin wichtiger Arbeitsschritt im Rahmen der Datenmigration ist dieDatenbereinigung, also die Bereinigung der Daten aus den Altsyste-men. Oft sind diese Systeme seit Jahren im Einsatz. Einen Prozesszur Erhaltung und Verbesserung der Qualität der Daten gibt es oftauch nicht. Das Ergebnis: doppelte Einträge, weil sich jemand bei derAdresse vertippt hat, alte Einträge, die schon lange nicht mehr benö-tigt werden etc. An dieser Stelle ist es sehr sinnvoll, diese Daten zubereinigen. Das geht manuell (etwa bei kleineren Datenmengen).Manchmal hilft Excel oder eine Access-Datenbank. Es gibt aber auchprofessionelle Tools dafür (etwa den IBM Information Server), dievorinstallierte Routinen zur Datenbereinigung besitzen.

Struktur-beziehungen

Feld-zuordnungen

Umsetzungs-regeln

Altdatendirekt aus

Legacy-Systemen

Altdatenauf dem PC

Datenin dasSAP-

System einlesen

Dateneinlesen

Daten umsetzen

umgesetzte Daten

Batch-Input- Verarbeitung

Direkt-Input- Verarbeitung

IDoc-Eingangs-verarbeitung


252

Abbildung 6.16 LSMW-Projektübersicht

Optimierungder Migrations-

programme

Wie wir im nächsten Abschnitt sehen werden, ist die eigentliche Migra-tion der Daten Teil des Go-Lives unserer neuen Systemlandschaft. Unddie steht gehörig unter Zeitdruck. Diverse Arbeiten müssen in einemkurzen Zeitfenster untergebracht werden. Da macht es sehr viel Sinn,die Abarbeitung der Datenmigration sehr genau zu testen und auch denZeitbedarf durch eine Optimierung der Migrationsprogramme zu mi-nimieren. Mitunter müssen mehrere Hunderttausend bis einige Mil-lionen Datensätze übernommen, getestet und freigegeben werden.Und das in kürzester Zeit und möglichst ohne Fehler. Da ist einepenible Vorbereitung ein wichtiger Baustein des Erfolgs.

6.4.5 Planung von Go-Live und Transition

Relativ frühzeitig im Projekt sind die Aktivitäten zum Übergang vonder Landschaft der Altsysteme zur neuen SAP-Landschaft vorzuberei-ten und zu planen. Dabei ist die Reihenfolge der Aktivitäten wiefolgt:

1. Die Altsysteme werden »vom Netz« genommen. Damit könnenkeine Geschäftsvorfälle mehr in der abzulösenden Landschaftbearbeitet werden, auch nicht versehentlich.


253

2. Die erforderlichen Daten werden in die bereits vorbereitetenneuen SAP-Systeme eingespielt.

3. Die neuen Systeme werden getestet, der Erfolg der Datenüber-nahme wird geprüft und die Systeme zum Betrieb freigegeben.

Hierbei kommen zwei Aufgaben auf das Projektteam zu: der Wechselder Endanwender vom alten zum neuen System sowie der eigentli-che Go-Live.

Transition der Endanwender von Alt nach Neu

Dass ein technischer Wechsel von den alten zu den neuen Systemenstattfindet, liegt auf der Hand. Darüber hinaus muss der Übergangder Anwender auf die neue Software organisiert werden. Zuerst ein-mal muss ein geeigneter Zeitpunkt gefunden werden. Und die ver-schiedenen Aktivitäten im Rahmen des Go-Lives sind nicht in einpaar Stunden erledigt. In einem kleineren Projekt kann ein Wochen-ende ausreichend sein, doch in komplexeren Projekten kann sich dieProduktivsetzung über einen bedeutend längeren Zeitraum erstre-cken. Und während dieser Zeit kann das »Business« nicht mit demSystem arbeiten.

Das heißt, Ihre Kollegen aus den Fachabteilungen können weder mitdem alten noch mit dem neuen System arbeiten. Es können alsoweder neue Kunden angelegt noch Rechnungen geschrieben wer-den. Das kann, wenn schlecht geplant, gehörig Sand in das GetriebeIhres Unternehmens streuen und hat in jedem Fall Auswirkungenauf die Geschäftstätigkeiten. Diese Zeit will also gut geplant sein undmit den Entscheidern im Unternehmen, aber auch mit Kunden undLieferanten gut abgestimmt sein.

Planung des eigentlichen Go-Lives

Für den eigentlichen Go-Live – also den technischen Übergang vonAlt nach Neu und die Freigabe an die Bediener des neuen Systems imUnternehmen – wird jeder Arbeitsschritt minutiös geplant. Alle Akti-vitäten werden detailliert aufgeführt und geplant. Wer macht wasund wann – auf die Minute genau! Und dieser Plan wird geprobt –bis er sitzt. Nichts wäre jetzt schlimmer, als zu guter Letzt den Erfolgdes Projekts noch zu gefährden.

6.4.6 Abschluss der Realisierungsphase

Kurz vor dem Ende dieser Phase sind also alle Objekte program-miert, die Systemeinstellungen (Customizing) sind fertig. Die Migra-tion der Daten ist getestet, das Produktivsystem ist vorbereitet.


254

User-Acceptance-Test

Jetzt kommt noch ein ganz entscheidender Test: der User-Acceptance-Test (im Folgenden Acceptance-Test genannt). In diesem Test werdenzukünftige Anwender die Prozessabläufe, und zwar über Systemgren-zen hinweg, mit Daten, so wie sie zum wirklichen Go-Live vorzufindensind, getestet. Es werden nicht nur der reine Ablauf, sondern zusätzlichAntwortzeiten des Systems, die Nutzbarkeit der einzelnen Transakti-onen, das Berechtigungskonzept und das Vorhandensein aller erfor-derlichen Anwender getestet. Auch ob die später notwendige Periphe-rie (also Drucker, Scanner, Archivsysteme etc.) vorhanden und ein-satzbereit ist, wird jetzt final getestet.

Sind alle Ampeln auf »Grün«, wird der letzte und entscheidendeSchritt im Projekt, der eigentliche Go-Live, vorbereitet.


Erfolg undFrustration

wechseln sich ab

Die Komplexität des Projekts nimmt durch die Vielzahl der in derRealisierungsphase vorgesehen Aktivitäten nochmals erheblich zu.Das Projektteam hat mit einigen Problemen zu kämpfen, die auf einemangelnde Projektsteuerung und Kontrolle zurückzuführen sind. Sowird z. B. die Kontrolle für die Entwicklung von Schnittstellen vonnachgelagerten Verfahren vernachlässigt. Viel zu spät wird man dar-auf aufmerksam, und das hat Auswirkungen auf den Zeitplan derVorbereitungsaktivitäten für den Acceptance-Test. Eine disziplinierteProjektsteuerung ist Voraussetzung für den Erfolg eines komplexenSAP-Implementierungsprojekts. Die frühe Identifizierung von Pro-blemen und rechtzeitiges Gegensteuern ist eine der wichtigsten Auf-gaben der Projektsteuerung. In Abschnitt 5.3 haben wir deshalb diewichtigsten Leitlinien für eine erfolgreiche Steuerung zusammenge-fasst. Wir zeigen Ihnen, was in der Praxis häufig versäumt wird, wasdie wichtigsten Kennzahlen und Einflussfaktoren sind und wie manein erfolgreiches Risikomanagement betreibt.

Die Mitarbeiter des Pilotteams sind noch in einer Reihe von weiterenAktivitäten eingebunden, die vom weltweiten Entwicklungs- undImplementierungsteam wahrgenommen werden. Um nur ein Beispielzu nennen: So werden die lokalen Prozessexperten zur Unterstützungdes Designs von lokalen Anforderungen in das weltweite Entwick-lungs- und Implementierungsteam vorübergehend abgestellt etc.

Im folgenden Abschnitt werden wir uns mit den verbleibendenwichtigen Aufgaben wie Acceptance-Test, Datenmigration und Schu-lungs- und Ausbildungsvorbereitung beschäftigen.


255

Acceptance-Test

Jetzt wird es stressig!

Jetzt wird es stressig! Die verschiedenen Testabläufe nach der ASAP-Implementierungsmethode wurden bereits in Abschnitt 2.2.3beschrieben, wie z. B. der Unit-Test, Scenario-Test, Integrationstest,Performancetest, Acceptance-Test, Cutover-Test. Weitere Testskönnten noch ein Security-Test oder auch ein Test der Batchabläufeetc. sein. Wir beschäftigen uns in diesem Beispiel mit dem wohlwichtigsten Test im Projektverlauf, dem sogenannten User-Accep-tance-Test oder Acceptance-Test.

Das Ziel des Acceptance-Tests ist, die Geschäftsprozesse im SAP-Sys-tem inklusive aller vorund nachgelagerten Verfahren (Schnittstel-len) End to End zu testen. Zur Unterstützung der Pilotimplementie-rung und der späteren Länder-Roll-outs wird von Anfang an einweltweites Testteam aufgebaut. Die Vorgehensweise für jedes neueFolgerelease beruht damit auf einer bereits bewährten Methodik, dievon einem erfahrenen Testteam einheitlich angewandt wird.

Aufgabenteilung für die Tests

Die Aufgaben und Verantwortlichkeiten des weltweiten Testteamssowie des Pilotteams und der nachfolgenden Länder werden verteilt.

Das weltweite Testteam ist für die folgenden Aufgaben verantwort-lich:

� weltweite Testmanagementverantwortung

� Teststrategie- und Testgesamtplan

� Management der weltweiten IT-Abhängigkeiten für den Test

� zentrale Testvorbereitung und Durchführung

� Aufbau und Management der weltweiten Testumgebung

� Problemerfassung, Fehleranalyse und Fehlerkorrektur

� weltweite Testabnahme

Das Pilotteam und die Länder sind für die folgenden Aufgaben verant-wortlich:

� Testvorbereitung und Durchführung für die lokalen Anwendun-gen und Fehlerkorrektur

� Aufbau und Management der lokalen Testumgebung

� Testabnahme der lokalen Anwendungen


256

Das Teststrategiedokument

Das Teststrategiedokument beschreibt den Testplan und den Test-ablauf für ein bestimmtes Release mit folgenden Inhalten:

� Beschreibung des Testumfelds

� gemeinsames Testmanagement-System für alle Partner

� gemeinsamer Problemmanagement-Prozess

� Definition des Projektumfangs

� Testzeitplan und Meilensteine

Voraussetzungen und Test-Eintrittskriterien

Was darfgetestet werden?

Für den Beginn des Acceptance-Tests gibt es bestimmte Vorausset-zungen und Eintrittskriterien (siehe Tabelle 6.5). Die folgenden Vo-raussetzungen müssen erfüllt sein:

� Alle Partneranwendungen sind entwickelt und getestet. Die Res-sourcen zur Unterstützung des Tests stehen zur Verfügung.

� Jede Änderung der Inhalte des Tests laufen über den Anforde-rungsänderungsprozess.

� Die erforderlichen Testdaten wie Kunden, Produkte und z. B. Ver-tragsdaten und Preise sind abgestimmt und stehen für den Testbereit.

� Der Systemaufbau des Testumfelds ist abgeschlossen.

� Das Testsystem hat den letzten Stand des Entwicklungscodes.

Checklistefür das Testen

In Tabelle 6.6 finden Sie die Checkliste, mit der Sie überprüfen kön-nen, ob die Test-Eintrittskriterien erfüllt sind. Die Checkliste könnenSie sich natürlich wieder unter www.sap-press.de/3825 herunterladen.

Eintrittskriterien für den Acceptance-Test Erledigt

Das Testkonzept ist entwickelt und enthält die Definition der Testumgebung, Schnittstellen, Testvorgehensweise, Testtools und Abnahmekriterien.

Der Testplan und die Ressourcen sind verfügbar.

Tabelle 6.5 Eintrittskriterien für den Acceptance-Test


257

Testabschluss-Kriterien

Checkliste für den Testabschluss

Ebenso werden für den Abschluss der User-Acceptance-Testaktivitä-ten Kriterien festgelegt, die in der Checkliste in Tabelle 6.6 aufgelis-tet sind (herunterzuladen unter www.sap-press.de/3825).

Art und Anzahl der geplanten Testfälle sind in der Testma-trix festgelegt. Fachfunktionen werden für die Auswahl der Testfälle eingebunden. Geschäftsprozessmanager hat die Testmatrix freigegeben.

Das Test-Kick-off wird mit allen Partnern durchgeführt.

Der Integrationstest für Partneranwendungen, die Voraus-setzung für den Beginn des User-Acceptance-Tests sind, sind erfolgreich abgeschlossen. Es gibt keine offenen Fehler der Fehlerkategorie 1 und 2 (kritisch).

Die technische Infrastrukturanalyse ist abgeschlossen.

Die Unterstützungsstruktur für den Test steht fest.

Die vereinbarten Daten für den Test sind geladen.

Tools für Testmanagement und Problemmanagement sind ausgewählt und verfügbar.

Performance- und Stresstest sind Teil der Teststrategie.

Testrisiken sind dokumentiert, und Aktionspläne sind vor-handen

Eintrittskriterien für den Acceptance-Test Erledigt

Tabelle 6.5 Eintrittskriterien für den Acceptance-Test (Forts.)

Abschlusskriterien für den Acceptance-Test Erledigt

Alle Testfälle sind erfolgreich durchgeführt.

Alle Fehler der Fehlerkategorie 1 und 2 sind dokumentiert, analysiert, korrigiert, nochmals getestet und vom Urheber freigegeben.

Alle offenen Fehler der Fehlerkategorie 3 und 4 haben einen Aktionsplan.

Sign-Off von vorund nachgelagerten Verfahren liegt vor.

Sign-Off vom weltweiten Anwendungseigner der SAP-Anwendung liegt vor

Tabelle 6.6 Abschlusskriterien für den Acceptance-Test


258

Test-Meilensteine

Tabelle 6.7 beinhaltet die kritischen Test-Meilensteine, die für diePilotinstallation zur Anwendung kommen.

Test-Kommunikationsplan

Abstimmungs-bedarf beim Testen

Für den regelmäßigen Interlock mit Partnern wird ein Kommunikati-onsplan entwickelt. Die wichtigsten Abstimmungsbesprechungensind dabei die folgenden:

� interne Teststatus-Besprechungen (1 × wöchentlich)

� Status der Testdurchführung (täglich)

� Status im Anforderungsmanagement (nach Bedarf)

Aktivitäten/kritische Meilensteine

Start-Datum

Ende-Datum

Kommen-tare

Laden der Testdaten:

� Kunden

� Material

� Verträge

� Preise

Testinfrastruktur:

� Einrichten der Batches (Massenverarbeitung)

� Aufbau von Schnittstellen

� Schnittstellentest

Interlock von Teststrategie, Abhängigkeiten und Testab-deckung, Test-Masterplan

Testvorbereitung:

� Festlegung Testabdeckung

� Erstellen der Testfälle

Finales Test-Review

Testdurchführung:

� Testzyklus 1

� Testzyklus 2

� Testzyklus 3

Tabelle 6.7 Kritische Testmeilensteine


259

� Problemmanagement-Besprechung mit dem SAP-Entwicklungs-team (täglich)

� Problemmanagement-Besprechung mit Partneranwendungen (nach Bedarf)

Transportmanagement

Für die Transporte der Korrekturen im normalen Zyklus ist einTransportprozess mit genauen Zeitangaben (3 × pro Tag) vereinbart,um die laufenden täglichen Testaktivitäten nicht zu gefährden. Wäh-rend dieser Zeit dürfen keine Testfälle im SAP-System administriertwerden. Vorgelagerte Systeme sind davon nicht betroffen. Das Test-infrastrukturteam hat eine Stunde vor den geplanten Korrekturtrans-porten das weltweite Testmanagement mit einer Liste der anstehen-den Transporte zu informieren. Für eilige Transporte ist die Freigabedes weltweiten Testmanagers vorab einzuholen.

Problemmanagement

Wer jagt den Fehlerteufel?

Die Verantwortung für eine Fehlerkorrektur liegt beim Entwick-lungsteam der Anwendung, die den Fehler verursacht hat. Daszuständige Testteam für alle auftretenden Defekte analysiertzunächst alle Fehler und weist sie den verantwortlichen Entwick-lungsteams zur Korrektur zu. Tabelle 6.8 zeigt die Zuständigkeits-matrix/Verantwortlichkeiten zur Behebung von Fehlern.

Test-Fehlerkategorien

Schlimme und weniger schlimme Fehler

Die Definition der Fehlerkategorien von 1 bis 4 ist für alle Anwen-dungseigner und involvierten Testmitarbeiter bindend. Die nachfol-gende Matrix in Tabelle 6.9 zeigt die angewandten Kriterien pro Feh-lerkategorie.

Zuständigkeitsmatrix für Problem-management

Weltweites Testteam

Pilot/Länder

SAP ×

lokale/regionale Anwendungen ×

weltweite Anwendungen ×

Tabelle 6.8 Zuständigkeitsmatrix für das Problemmanagement


260

Benutzte Test-Tools

Test- und Problem-management

Zur Unterstützung der Testphasen werden ein Testmangement-Toolund ein Problemmanagement-Tool eingesetzt (siehe Abschnitt 8.3,»Werkzeuge für das Testen«).

Das Testmanagement-Tool enthält

� die Beschreibung der Testfälle und Testschritte,

� den aktuellen Status der Testdurchführung,

� die automatische Erstellung der Teststatusberichte und

� die Verbindung zum Problemmanagement-Tool.

Das Problemmanagement-Tool ist ein integriertes Toolset mit Funk-tionen für das Issue-Management (Anforderungs- und Problem-management).

Fehler-kategorie

Beschreibung Zeitvorgabe für Korrektur

FK 1 Ein Testfall kann durch ein Funktions-problem nicht administriert werden oder liefert ein falsches Ergebnis und ist kritisch. Es gibt keine Alternativen. Der Testfall kann nicht an involvierte Partneranwendungen weitergegeben werden.

24 Stunden

FK 2 Ein Testfall verursacht falsche Ergeb-nisse, ist kritisch, aber es bestehen Alternativen, um den Teststring zu Ende zu bringen.

72 Stunden

FK 3 Ein Testfall oder eine bestimmte Funktion verursacht einen Fehler, der aber nicht kritisch ist. Der Testfall kann unter Umständen weiter durch-geführt werden.

7 Tage, wenn die Kapazität vorhan-den ist.

FK 4 Ein Testfall oder eine bestimmte Funktion kann nur limitiert durchge-führt werden. Alternativen sind vor-handen. Das Problem ist nicht kritisch und könnte auch in zukünftigen Releases behoben werden.

Zum Zeitpunkt des Testabschlusses liegt ein Aktions-plan vor.

Tabelle 6.9 Fehlerkategorien im Test


261

Test und Anforderungsmanagement

Geänderte Anforderungen

Sollen im Laufe der Testdurchführung Anforderungsänderungengestellt werden, so müssen diese den normalen Anforderungsma-nagementprozess durchlaufen. Die Anforderungen müssen doku-mentiert und begründet werden. Ebenso muss der Einfluss derÄnderung auf das Projekt beschrieben werden. Die finale Entschei-dung, ob die Anforderung/Änderung angenommen wird, wird inden Prozessdesign-Reviews (siehe auch Abschnitt 6.3.2, »Und wieläuft es in der Praxis?«) entschieden.

Rollen und Verantwortlichkeiten des weltweiten Testteams

Jedem Test sein Manager

Innerhalb des weltweiten Testteams gibt es verschiedene Rollen undVerantwortlichkeiten, und zwar den Test-Release-Manager, den Test-infrastruktur-Manager und den Test-Problem-Manager.

Der Test-Release-Manager ist verantwortlich für

� die Strategie für den User-Acceptance-Test,

� den End-to-End-Meilenstein-Plan,

� die Testfallvorbereitung und Durchführung und

� die Abschlussfreigabe des User-Acceptance-Tests (Sign-off).

Der Testinfrastruktur-Manager ist verantwortlich für

� den Anwendungspartner-Interlock,

� die Verfügbarkeit der Schnittstellen zu Partneranwendungen,

� die Überwachung der Schnittstellen während der Testdurchfüh-rung und

� die Koordination der Wartungsintervalle für die Testinfrastruktur.

Der Test-Problem-Manager ist verantwortlich für

� die Koordination des Problemmanagement-Prozesses mit allenPartnern,

� die laufende Aktualisierung der Problemmanagement-Tools und

� den Fehlerkorrektur-Managementprozess während der Testdurch-führung.

Abbildung 6.17 zeigt die Aufgaben und die Testorganisation für denUser-Acceptance-Test.


262

Abbildung 6.17 User-Acceptance-Test: Aufgaben und Organisation

Wie sich herausstellt, ist für die technische Bereitstellung der Test-infrastruktur nicht genügend Zeit eingeplant: Probleme mit derBeschaffung von Anwenderberechtigungen für die Testumgebungund Schnittstellenprobleme mit nachgelagerten lokalen Verfahrenverzögern den Beginn des Tests.

Die Prozesse/Funktionen werden für den Acceptance-Test inGeschäftsszenarien abgebildet. Jedes Geschäftsszenario hat einenlogischen Ablauf von Transaktionen innerhalb des SAP-Systems undüber die Schnittstellen zu den vorund nachgelagerten Verfahren.Die Auswahl der geeigneten Testfälle wird von den Fachabteilungenvorgenommen und vom Geschäftsprozessverantwortlichen nacheiner Überprüfung genehmigt.

Personalengpässebei der

Testdurchführung

Für die Testdurchführung sind die Prozessmitarbeiter, die bereits dieBlueprint-Phase unterstützt haben, vorgesehen. Ein Teil dieser Res-sourcen wird jedoch für die Erstellung der Schulungsunterlagen undfür Datenmigrationsaufgaben eingesetzt. Engpässe sind somit vorpro-grammiert. Aus diesem Grund ist es eine gute Entscheidung, zusätzlichzu den bereits geplanten Testressourcen weitere erfahrene Endanwen-der für die Testunterstützung einzusetzen. Schulungsmaßnahmen für

Testmanager

Leitung der Tests im Pilotland

Strategie-/Master-Testplan

Problem-management

Tools/Berichte

Daten

Konfiguration/ Entwicklung

zentrales Testteam/Testfall-

bearbeitung

PMO

Testinfrastruktur


263

die Systembenutzung und die Testvorgehensweise sind die Vorausset-zung für einen produktiven Einsatz. Der User-Acceptance-Test ist eineHerkulesaufgabe und benötigt stressresistente Mitarbeiter, was bei derAuswahl der zusätzlichen Tester berücksichtigt wird.

Neben den manuellen Tests werden auch Testfälle selektiert, die fürdie Testautomatisierung geeignet sind, wie z. B. für Testfälle mit häu-figer Wiederholung (Regressionstests), Tests des Bildschirmaufbausbei verschiedenen Sprachen oder auch Testfälle, die einen hohenAufwand bei manueller Testdurchführung erfordern.

Je näher das Projekt dem Einführungstermin kommt, desto größerwird der Druck auf das Testteam. Wochenendarbeit wird in der letz-ten Phase für die Mitarbeiter zur Regel. Einmalig Wochenendarbeitorganisieren? Kein Problem für ein engagiertes Team. Wird die Aus-nahme jedoch zur Regel, sind Sie als Projektleiter und Führungskraftin der Zwickmühle: Sie wissen, dass die Mitarbeiter eine Auszeitbrauchen, sind aber andererseits in Zugzwang, den Test entspre-chend Plan zu vollenden.

In unserem Beispielfall sorgt Herr Meyer für die Verpflegung derTestmitarbeiter und plant gemeinsame Abendessen beim Lieblings-italiener des Teams. Trotzdem werfen in dieser kritischen Phase zweiwichtige Testmitarbeiter erschöpft das Handtuch und verlassen dasProjekt. Es ist ein Glücksfall, dass ein parallel laufendes Projektgerade abgeschlossen wird und zwei neue mit Testaktivitäten ver-traute Mitarbeiter kurzfristig eingesetzt werden können.

TestergebnisseIm ersten Testzyklus gibt es noch eine relativ hohe Fehlerrate.Eigentlich keine Überraschung bei Projekten dieser Größenordnung.Die Fehler liegen vor allem in der Entwicklung, im technischenUmfeld (Setup-Probleme) und in der Datenqualität. Aber es gibt auchnoch Anfangsschwierigkeiten bei den Testern, die im ersten Test-zyklus noch nicht richtig eingearbeitet sind.

7 Erfolgsfaktoren für den User-Acceptance-Test

1. Starten Sie den Test erst, wenn alle Voraussetzungen/Kriterien erfülltsind (siehe auch Tabelle 6.5).

2. Erstellen Sie ein Testkonzept und führen Sie ein Test-Kick-off-Meetingdurch.

3. Nehmen Sie sich genügend Zeit für die Erstellung von qualifiziertenTestfällen. Priorisieren Sie die Testfälle nach der Bedeutung derGeschäftsprozesse im Unternehmen.


264

4. Planen Sie für den Aufbau der technischen Testumgebung genügendZeit ein.

5. Stellen Sie einen kontinuierlichen Interlock zwischen Testern und Ent-wicklungsteam sicher.

6. Nutzen Sie integrierte bewährte Testtools wie z. B. die SAP SolutionManager Test Workbench.

7. Bereiten Sie die Testmitarbeiter auf mögliche schwierige Phasen vorund sorgen Sie trotz des hohen Stressfaktors für Abwechslung.

Zurück zur Datenqualität! Jetzt rächt sich, dass der Bereinigung vonAltdaten zu Beginn nicht die richtige Aufmerksamkeit geschenktwird. Um dem Entwicklungsteam die Möglichkeit zu geben, die kri-tischsten Fehler zu korrigieren, und um die Qualität der Daten zuverbessern, wird der Test unterbrochen.

Fehleranzahl Den Teststatus nach dem ersten Testzyklus sehen Sie in Abbildung6.18. Dort sind die Anzahl der neuen Fehler pro Woche und dieAnzahl der korrigierten Fehler dargestellt, die für den Wiederho-lungstest bereitstehen. In diesem Testzyklus treten noch mehr neueFehler auf, als abgearbeitet werden können.

Abbildung 6.18 Ergebnisse des Testzyklus 1 – Anzahl der Fehler

Fehlerkategorie Abbildung 6.19 zeigt die Zeit, die für die Fehlerkorrektur benötigtwird. Alle Fehler der Fehlerklasse 1 (schwerwiegend und der Testfallkann nicht fortgesetzt werden) sind innerhalb von 24 Stunden zukorrigieren, alle Fehler der Fehlerklasse 2 (kritisch, aber es gab Alter-nativen für die Fortsetzung des Tests) sind innerhalb von 72 Stunden

Fehlerkat. 1 Fehlerkat. 2 Fehlerkat. 3+4 gesamt

87

10

2

10

20

25

15

5

23

14

neu

korrigiert

55

Anzahlder Fehler


265

zu korrigieren. Die Fehlerklasse 3 (weniger kritisch, aber es gabAlternativen) ist innerhalb von 7 Tagen zu korrigieren, vorausgesetztdie Kapazität ist vorhanden. Für alle Fehler der Fehlerklasse 4 mussein Aktionsplan für die Korrektur nach Testabschluss vorliegen. DieAbbildung zeigt auch, dass fast 90 % der Fehlerklasse 1 in der vorge-gebenen Zeit korrigiert werden, bei der Fehlerklasse 2 sind esimmerhin noch mehr als 70 %.

Abbildung 6.19 Testzyklus 1 – Fehler korrigiert in vereinbarter Zeit

FehlerursachenAbbildung 6.20 zeigt die Fehlerursachen im Testzyklus 1, die zumgroßen Anteil auf eine instabile Testinfrastruktur (z. B. nachgelagerteVerfahren sind nicht für den Test bereit), Entwicklungs- und Daten-probleme zurückzuführen sind.

Abbildung 6.20 Testzyklus 1 – Fehlerursachen

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Fehlerkat. 1 Fehlerkat. 2 Fehlerkat. 3+4

Fehlerkat. 1 in 24 Stunden

Fehlerkat. 2 in 72 Stunden

Fehlerkat. 3+4 in 7 Tagen

Korrektur innerhalb Zeitvorgaben

Korrektur außerhalb Zeitvorgaben

Fehlerursache

Testumfeld

Entwicklung

Daten

Benutzer


266

Der zweite Testzyklus startet mit einem verbesserten Software- undDatenbestand, sodass die dafür vorgesehenen Testfälle insgesamtnach Plan abgewickelt werden können.

Datenmigration

Wegducken oder ignorieren hilft hier nicht: Probleme mit den Datenoder auch der Datenqualität holen einen immer wieder während dergesamten Projektlaufzeit ein.

Daten – machenimmer Probleme,

aber es gehtnicht ohne

Nach anfänglichen Schwierigkeiten wird deshalb zur Unterstützungder Pilotimplementierung und auch der späteren Länder-Roll-outsein weltweites Datenmigrationsteam aufgebaut. Ähnlich wie beimzentralen Testteam wird für die Datenmigration und Datenbereini-gungsaktivitäten eine einheitliche standardisierte Vorgehensweiseentwickelt, die erheblich zum Gelingen des Projekts beiträgt. Abbil-dung 6.21 zeigt beispielhaft eine standardisierte Vorgehensweise fürden Ablauf und die Phasen der Migration der Kundendaten.

Abbildung 6.21 Migrationsprozess für die Kundendaten

Datenmigrations-Workbook

Analysephase Definition der

Geschäftsszenarien/Konfiguration

DesignphaseDefinition der Anforderungen

Zyklus 1…n

Change-Management-Prozess

– Definition der Sollprozesse– globale Datenstandards– SAP-System-Konfiguration– SAP-Datenfelder und

Werte definieren

– Datenfeldmapping-Template– erster Mapping-Workshop– Analyse der Quelldaten– Finaler Mapping-

Workshop mit a) Datenbereinigungsregelnb) Konvertierungsregeln

– Datenlayout für Extraktfile

– Erstellung der Daten-bereinigungs- und Kon-vertierungsprogramme

– Erstellung der Ladeprogramme– Extrakt der Quelldaten– Überprüfung der Datenqualität– Überprüfung der Konvertierung– Laden der Daten in das Zielsystem

Kundendatenmatrix SAP-SystemDatenmigrations-Workbook

ImplementierungsphaseDatenbereinigung,

Konvertierung und Laden


267

Statistische Auswertungen

Zur Überprüfung der Qualität der migrierten Daten wird ein Daten-migrationstest durchgeführt. Der Datenmigrationstest besteht auseiner Anzahl von Zyklen mit folgenden statistischen Auswertungen:

� Sind die übertragenen Daten vollständig und wie viele Daten wer-den übertragen?

� Sind die übertragenen Daten inhaltlich korrekt?

� Werden die richtigen Datenformate übertragen?

� Werden alle Pflichtfelder, die in SAP benötigt werden, übertragen?

� Wie lange ist die Übertragungszeit der Daten?

� Wie hoch ist die Fehlerrate?

FehlerrateDie Fehlerrate der ersten Datenmigrationszyklen liegt insgesamt beica. 35 % der geladenen Daten. Viel zu hoch! Die Hauptprobleme lie-gen im Bereich der Datenkonvertierung (z. B. unvollständige Kunden-adressen, fehlende Branchenkennzeichen im Kundenstamm) und beiDuplikaten. Die Anzahl der Zyklen wird deshalb so oft wiederholt,bis eine qualitativ zufriedenstellende Datenqualität erreicht wird(Fehlerrate < 1 %). Nach jedem Zyklus werden deshalb weitereDatenbereinigungsaktivitäten durchgeführt.

Datenbereinigung und nochmals Datenbereinigung

Wir kommen immer wieder darauf zurück! Eine hohe Datenqualitätist die Voraussetzung für einen erfolgreichen Test und die finaleÜbernahme der Daten in das SAP-System. Die Datenbereinigungsak-tivitäten sind im Projekt ein arbeitsintensiver Prozess, der zunächstvernachlässigt, aber dann mit genügend zusätzlichen Ressourcendurchgeführt wird. Der Aufbau einer weltweiten Unterstützungs-funktion für die Datenmigrationsaufgaben ist ein Meilenstein für dieerfolgreiche Datenmigration. So kann am Ende sichergestellt wer-den, dass bis auf wenige einzelne Ausnahmen korrekte Daten in dasProduktivsystem übernommen werden.

Abbildung 6.22 zeigt den Ablauf der Fehlerkorrektur und Datenqua-litätskontrolle am Beispiel von Kundendaten.


268

Abbildung 6.22 Datenmigration – Fehlerkorrektur und Datenqualitätskontrolle für Kundendaten

Entwicklung des Schulungsmaterials

Wie kommtdas System an?

Auf der Basis der Anforderungen aus der Ausbildungsstrategie wer-den ein detailliertes Schulungskonzept entworfen und Module,Inhalte, Kursziele, die Art und die Dauer der Ausbildungsmaßnahmenfestgelegt. Zum einen werden die Projektmitarbeiter in das neue Sys-tem eingeführt, und zum anderen werden für die Endanwender Kurseentwickelt, die sie auf ihre neuen Aufgaben vorbereiten. Für die Pro-jektmitarbeiter wird Grundlagenwissen über die verschiedenen SAP-Komponenten im Rahmen von Überblicksschulungen angeboten. DieLerninhalte sind dabei die Navigation sowie Datenstrukturen undGeschäftsprozesse der einzelnen Komponenten.

Zusätzlich zu den Überblicksschulungen werden auch Workshopsfür Teilprojekte angeboten. Aus den Projektmitarbeitern könnenspäter die Fachspezialisten oder Key-User rekrutiert werden. FürProjektmitarbeiter, für die später Aufgaben in der Systemunterstüt-zung vorgesehen sind, werden eigene fachspezifische Kurse entwi-ckelt. Die Schulungen für die Endanwender haben das Ziel, sie mitdem neuen System vertraut zu machen und sie in die Lage zu verset-zen, ihre neuen Aufgaben eigenverantwortlich auszuüben.

Die Endanwender der unterschiedlichen Standorte haben verschie-dene Aufgaben und Rollen, sodass es sich als sinnvoll erwies, dasLernmaterial weitgehend modular aufzubauen. Je nach Jobrollen

Batch-Input/Direkt- Input in das SAP-

System von DM-Team

NEIN -- Fehler -- JA

Datenqualitäts-kontrolle – DM-Team

Abnahme-protokoll –

Endanwender

Fehleranalyse – DM-Team

Fehler in SAP/fehlende Werte/Konfig.

Fehler in der

Umsetzung

techn. Fehlerin SAP

Problemlösung/Feedback Loop zu

DM-Team

Kontrolle – Endanwender


269

und Anforderungen kann jeder Anwender so ein auf ihn zugeschnit-tenes Paket erhalten. Die Erfahrung hat gezeigt, dass eine auf den tat-sächlichen Geschäftsprozessen basierende Schulung viel effizienterist als eine rein transaktionsbasierte Ausbildung, denn Endanwendermüssen die neuen Prozesse und ihre Rolle in diesen Prozessen ver-stehen. Die Übungen am System müssen daher nah an einem realenTagesablauf entwickelt werden. Dafür wird das Schulungssystemmöglichst produktionsnah mit Originaldaten aufgebaut. Ein rei-bungsloser Ablauf ist nicht nur für die Schulungsergebnisse, sondernauch für die Motivation der Schulungsteilnehmer wichtig. Jeder Teil-nehmer hat nach einer Schulungseinheit einen Evaluierungsfrage-bogen auszufüllen. Die Bewertungsfragebögen sind anonym undwerden für eine laufende Verbesserung der Schulungsmaßnahmenherangezogen.

Entwicklung eines Prototyps für die Schulung

Bevor mit der eigentlichen Entwicklung der Schulungsunterlagenbegonnen wird, wird für einige Ausbildungsmodule ein Prototyp ent-wickelt, um ein Gefühl für das »Look and Feel« zu bekommen. Bei-spielhaft werden Ausbilder- und Teilnehmerleitfäden, Simulationen,Vortragsunterlagen und Arbeitsanweisungen erstellt. Diese Vorge-hensweise hat sich schon sehr häufig in anderen Projekten bewährt,so auch in unserem konkreten Beispielfall.

Mit dem Prototyp können nachträgliche zeitaufwendige größereKorrekturen vermieden werden. Folgende Designprinzipien werdenbei der Erstellung der Schulungsunterlagen zugrunde gelegt: DasKursmaterial wird zunächst auf die Jobrollen der Endanwender aus-gerichtet und beginnt mit einer kurzen Beschreibung des End-to-End-Prozesses, gefolgt von einer weiteren Verzweigung auf das spezifischeInteressengebiet. Die Kursinhalte haben eine logische Abfolge. DieTeilnehmer werden so in die Lage versetzt, die Inhalte auf einbestimmtes für sie relevantes Thema zu beziehen. So werden z. B.Schulungen entwickelt, die in der SAP-Finanzbuchhaltung speziellfür Sachbearbeiter der Debitorenbuchhaltung relevant sind. Die Ent-wicklung des Schulungsmaterials wird von Prozessexperten beglei-tet, um die Benutzerfreundlichkeit der Unterlagen sicherzustellen.Gegen Ende der Entwicklungsphase ist ein Pilotkurs mit einer klei-nen Gruppe von Endanwendern geplant, um die Praktikabilität derUnterlagen nochmals zu testen und eventuell anfallende Änderungs-wünsche zu berücksichtigen, bevor mit dem Kurs-Roll-out begonnenwird.


270

Die einzelnen Schulungsmodule beinhalten die folgenden Kompo-nenten:

� die Ziele der Schulung

� die Inhalte

� die Voraussetzungen

� die Zielgruppe

� die Dauer der Schulung

Die Schulungsunterlagen wie z. B. Übersichten, Aufgaben oder auchReferenzkarten werden in Papierform und digital zur Verfügunggestellt.

Fazit

Der Einsatz der Projektmitarbeiter erreicht in der Realisierungsphaseihren Höhepunkt. Engpässe gibt es besonders bei den Mitarbeiternmit Prozesswissen. Diese müssen die Entwicklung, den Test, Daten-migrationsaufgaben, die Entwicklung von Schulungsunterlagen undhäufig noch ausstehende Aufgaben aus der Vorphase unterstützen.Planen Sie daher genügend Ressourcen mit qualifiziertem Prozess-wissen ein. Da es den Idealfall von unbegrenzten Ressourcen nichtgibt, werden Sie priorisieren und Kompromisse schließen müssen. Indieser Phase ist es auch besonders wichtig, Ihr Projektteam motiviertund bei Laune zu halten. Planen Sie trotz des hohen Stresslevels odergerade deswegen eine kurze Auszeit für alle Beteiligten ein. Dasmuss nichts Großes sein, schon ein kleiner Event kann Wunderbewirken.

Checkliste für dieRealisierungsphase

Tabelle 6.10 zeigt die Checkliste der Realisierungsphase (siehe auchDownloadangebot unter www.sap-press.de/3825). Zu den Qualitäts-checks siehe außerdem Abschnitt 5.4, »Qualitätssicherung«.

Aufgabe Erledigt

Programmierung/Konfiguration abgeschlossen

Organisationseinflüsse sind abgestimmt. Alle betroffenen Fachfunktionen haben den organisatorischen Änderungen zugestimmt.

Tabelle 6.10 Checkliste für die Realisierungsphase


271

Lessons Learned in der Realisierungsphase

Was sind die wichtigsten Erkenntnisse in der Realisierungsphase?

1. Ressourcenbedarf erreicht den HöhepunktDer Ressourcenbedarf erreicht in der Realisierungsphase den Peak.Viele Projektmitarbeiter stehen unter enormem Stress, und es bestehtpermanent die Gefahr, dass erfahrene Mitarbeiter das Projekt verlassenkönnten. Planen Sie deshalb zwischendurch immer eine kurze Auszeitein, z. B. einen Steh-Event und dergleichen. Planen Sie auch proaktivfür möglichen Ersatz von kritischem Skill.

2. Aufbau der Testinfrastruktur benötigt ZeitDer User-Acceptance-Test ist wohl der wichtigste Test im Projekt underfordert besondere Aufmerksamkeit und sorgfältige Planung. PlanenSie genug Zeit für den Aufbau und die Bereitstellung der technischenTestinfrastruktur ein.

User-Acceptance-Test ist abgeschlossen:

� Alle geplanten Testfälle wurden durchgeführt und sind dokumentiert.

� Alle Testfälle mit Fehlerlevel 1 und 2 (kritisch) sind doku-mentiert, analysiert, korrigiert, nochmals getestet und vom Urheber freigegeben.

� Alle Testfälle mit Fehlerlevel 3 und 4 sind dokumentiert und haben einen Aktionsplan.

� Freigabe von den Partneranwendungen über den erfolg-reichen Testabschluss liegt vor.

Schulungsunterlagen sind entwickelt, Pilotschulung ist durchgeführt, Schulungsplan und Unterrichtsmethodik ist festgelegt, Performancetest der Ausbildungssysteme ist durchgeführt.

Produktionsstart ist mit allen Beteiligten abgestimmt:

Rechenzentren, Anwendungseignern, Endanwenderorgani-sationen, Stakeholder.

Daten in Altverfahren sind bereinigt, konvertiert und stehen für die Migration bereit. Fehleranzahl < 1 % ist gegeben.

Schnittstellenprogramme sind entwickelt und getestet.

Qualitätschecks wurden durchgeführt.

Aufgabe Erledigt

Tabelle 6.10 Checkliste für die Realisierungsphase (Forts.)


272

3. Datenqualität und nochmals DatenqualitätDie Qualität der Daten beeinflusst wesentlich den Fortschritt des Pro-jekts. Führen Sie kontinuierlich Datenbereinigungsaktivitäten durch.

4. Praxisnahes Schulungsmaterial hilftErstellen Sie die Schulungs- und Ausbildungsunterlagen praxisnah anden tatsächlichen Geschäftsprozessen. Führen Sie einen Pilotkursdurch.

5. Eigenständige SchulungssystemeSetzen Sie für die Ausbildung ein SAP-Schulungssystem ein, das unab-hängig von Test- und Entwicklungssystemen ist.

Nachdem der User-Acceptance-Test bis auf wenige verbleibendeTestfälle abgeschlossen ist, kann mit den Produktionsvorbereitungenbegonnen werden.

6.5 Finale Vorbereitungsphase/Go-Live und Support

Die Hauptaufgabenpakete in der finalen Projekt-Vorbereitungsphasesind:

� Schulungen für die Anwender durchführen

� die technischen Infrastrukturaktivitäten für die Produktivsetzungund Cut-over-Management-Aktivitäten

� Daten in das Produktionssystem laden

� eine Support-Struktur (Helpdesk) aufbauen

6.5.1 Schulung

Eine erfolgreiche Schulung trägt maßgeblich zum Projekterfolg undzur Akzeptanz des neuen Systems bei den Endanwendern bei. DieSchulung findet zeitnah zum Produktionsstart statt und wird im Ideal-fall von einem erfahrenen SAP-Experten und einem Prozessfachmannaus dem Projekt, der mit den alten und neuen Prozessen vertraut ist,durchgeführt.

Die Schulungsunterlagen sind auf Basis der Anwenderdokumenta-tion entwickelt und auf den tatsächlichen Geschäftsprozessen aufge-baut. Die Räumlichkeiten stehen zur Verfügung, und das Schulungs-system ist installiert. Eine Pilotschulung ist durchgeführt, und Sie

Finale Vorbereitungsphase/Go-Live und Support 6.5

273

stellen sicher, dass die Schulungseinladungen rechtzeitig an dieAnwender rausgehen. Dann kann es losgehen.

6.5.2 Aktivitäten zur Produktivsetzung

Die Produktivsetzung (Cut-over) des SAP-Systems erfordert akribi-sches Vorgehen. Mit dem Rechenzentrum haben Sie alle Verfahrenabgestimmt. Zugriffs- und Berechtigungskonzepte für den operati-ven Betrieb sind eingerichtet. Das Projektmanagement-Team mussjetzt nochmals zur Hochform auflaufen.

Cut-over-PlanFür den Produktivstart wird ein sehr umfangreicher und detaillierterCut-over-Plan erstellt, der alle Voraussetzungen für eine erfolgreicheProduktivsetzung beinhalten muss. Der Cut-over-Plan ist die Feinpla-nung und enthält mehrere Hundert, manchmal auch Tausende Akti-vitäten, teilweise auf Stunden- und Minutenbasis. Der Plan wird lau-fend kontrolliert, abgeschlossene Aktivitäten werden dokumentiert,für den Abschluss kritischer Phasen gibt es Entscheidungs-Check-points mit dem Lenkungsausschuss oder den Stakeholdern. Ein Bei-spiel für eine Systemlandschaft ist in Abbildung 6.10 zu sehen.

Weiterführende Informationen zum Cut-over

Zum Thema Cut-over-Planung von SAP-Projekten gibt es umfangreichePublikationen mit detaillierten Vorgehensweisen und Leitfäden (z. B. Cut-over-Management in SAP-Projekten von Jürgen Remmert, SAP PRESS,2009).

Keine stille Post: ein guter Kommu-nikationsplan

Nicht zu vergessen ist das Erstellen eines Kommunikationsplans, deralle wichtigen Adressen und Telefonnummern der beteiligten Grup-pen/Mitarbeiter enthält. Für die kritische Phase der letzten Tage vorProduktivstart sollten Sie möglichst alle Projektmitarbeiter physischam selben Ort haben (gedanklich sowieso). Auch für die erstenWochen nach Produktivstart ist es empfehlenswert, diesen Ansatzzur schnellen Klärung von auftretenden Problemen beizubehalten.

Für einen letzten Test vor dem Überspielen des Programmcodes indas Produktivsystem werden vorselektierte aktuelle Geschäftsvor-gänge auf einem Konsolidierungs- oder auch Vor-Produktionssystemgetestet, mit dem Ziel, die Funktionsfähigkeit und die technische In-frastruktur des Systemumfelds sicherzustellen


274

6.5.3 Laden der Daten

So kommendie Daten

in das System

Zu diesem Zeitpunkt wissen Sie genau, welche Daten aus den Altsys-temen übernommen werden müssen. Datenbereinigungsaktionensind kontinuierlich durchgeführt worden. Extraktprogramme sindentwickelt und getestet. Das finale Laden der Daten in das Produk-tivsystem wird durch Tools unterstützt, die das Laden der Daten vari-abel entsprechend der Datenmigrationsstrategie ermöglichen. DieSequenz der Ladevorgänge kann teilweise flexibel definiert und denzu ladenden Datenvolumen angepasst werden. Eine bestimmeAbfolge der zu ladenden Daten ist jedoch zwingend, so müssen z. B.zuerst die Kundendaten und dann die dazugehörigen Aufträge gela-den werden.

Nach jedem Laden der Daten werden nochmals bestimme Merkmalegeprüft, z. B. ob die Anzahl der geladenen Datensätze korrekt im Sys-tem angekommen ist, die Summen übereinstimmen etc. Fehler sindin dieser Phase sofort zu bereinigen, entweder durch manuelle Inter-vention oder durch Korrektur mithilfe eines Programms. Im ungüns-tigsten Fall könnte es bei größeren Problemen auch zur Unterbre-chung der Go-Live-Aktivitäten kommen.

6.5.4 Aufbau einer Support-Struktur (Helpdesk)

Hilfe in der Not Der Aufbau einer Support-Struktur für den laufenden Produktivbe-trieb ist für die Akzeptanz des neuen Systems bei den Endanwenderneminent wichtig. Gerade in den ersten Wochen des Produktivbe-triebs werden noch viele Fragen, aber auch Fehler im Systembetriebauftreten können, die schnell geklärt werden müssen.

Für den internen Support stehen als erster Anlaufpunkt idealerweiseMitarbeiter der Fachabteilung zur Verfügung (Key-User), die in dasProjekt eingebunden sind und die neuen und alten Prozesse kennen.Sie sind in der Lage, einfache Fragen zur Bedienung des Systemsoder auch prozessrelevante Fragen zu beantworten, arbeiten aberweiterhin im Schwerpunkt in ihrer Fachfunktion.

Für schwierigere Fragen wendet sich der Endanwender an dasinterne Helpdesk. Das Helpdesk ist in Unterstützungslevel je nachSchwierigkeitsgrad der Problemstellung eingeteilt, und zwar in derRegel von Level 1–3, wobei Level 3 für komplexe Probleme zustän-dig ist, die nicht vom internen Helpdesk, sondern von externen SAP-


275

Experten gelöst werden können (siehe auch Abbildung 6.23: Anwen-derunterstützung/Support-Struktur).


All diese genannten Aufgaben kommen auch auf die Kollegen inunserem Beispielprojekt zu. Ob das Projekt von Erfolg gekrönt seinwird? Lesen Sie selbst …

Durchführung der Schulungen

SchulungsmandantFür die Schulung wird ein eigenes SAP-System mit einem Schulungs-mandanten, unabhängig von den Entwicklungs- und Testsystemen,aufgebaut. Das hat den Vorteil, dass das Schulungssystem von denlaufenden Transportprozessen der Entwicklungs- und Testsystemeabgekoppelt wird und damit weniger störanfällig ist. Für gleichzeitigstattfindende Schulungen werden mehrere Schulungsmandanteneingerichtet, damit sich die Kursteilnehmer nicht gegenseitig behin-dern können. Ausgangsbasis für alle Mandanten ist ein Schulungs-mastermandant, der bereits mit Stamm- und operationalen Datengeladen wird, um möglichst nah das Produktionsumfeld simulierenzu können.

Schulungs-durchführung

Der Pilotkurs für die Endanwenderschulungen wird bereits erfolg-reich in der Realisierungsphase abgeschlossen. Die finale Schulungist für vier Wochen vor Produktivstart vorgesehen. Zusätzlich zu denUnterrichtsmodulen in Schulungsräumen wird auch Material zumSelbststudium angeboten. Dazu zählen Lerninhalte für Einführungs-kurse (z. B. SAP Navigation), die im Internet oder als E-Learning-Methode bereitgestellt werden und als Ergänzung oder auch fürWiederholungen eingesetzt werden können. Die große Anzahl derzu schulenden Endanwender hat zur Folge, dass mehrere Unter-richtseinheiten in Schulungsräumen parallel erfolgen müssen. DieAnzahl der Teilnehmer pro Klasse wird auf maximal 12 Personenbegrenzt, um den optimalen Lernerfolg zu erzielen. Die dafür benö-tigten zusätzlichen Ressourcen als Instruktor sind bereits im Schu-lungsplan berücksichtigt und in die Entwicklungsaktivitäten mit ein-gebunden. Sie werden nach dem »Train the Trainer«-Konzeptausgebildet, in dem auch methodische und didaktische Kenntnissevermittelt werden. Der erfolgreiche Ansatz ist, die Schulung mit je


276

einem erfahrenen SAP-Berater und einem Prozessexperten mitKenntnissen der alten und neuen Prozesse durchzuführen.

Einsatz einerTrainings-Sandbox

Es bewährt sich dabei auch der Einsatz einer zusätzlichen Trainings-Sandbox, die die Endanwender auch außerhalb der normalen Unter-richtseinheiten jederzeit für praktische Übungen benutzen können.Aus Kostengründen wird dieses zusätzliche Schulungssystem jedochnur für ein paar Monate nach Produktionsstart vorgehalten. JedeTrainingseinheit wird am Ende mit einem Evaluierungsprozess, dersich auf die Kursinhalte, den Instruktor und die Systemverfügbarkeitin der Schulung bezieht, abgeschlossen. Die Beurteilungen sinddurchweg positiv, sodass man davon ausgehen kann, dass die ange-strebten Lernziele insgesamt erreicht werden. Die Schulung leistetdadurch auch einen wichtigen Beitrag für eine positive Grundhal-tung der Endanwender gegenüber den Neuerungen. Neben der fach-lich-operativen Schulung, die auf Geschäftsprozesse aufgebaut ist,werden auch Schulungen für systemtechnische Prozesse im IT-Umfeld und für Mitarbeiter der zukünftigen Anwenderunterstüt-zung angeboten. Dazu gehören z. B. Aufgaben in Zusammenhangmit dem Systembetrieb und z. B. auch Tests von zusätzlichenGeschäftsprozessanforderungen.

Infrastrukturaktivitäten zur Produktivsetzung und Cut-over-Management

Die meisten Projektmitarbeiter sind in der kritischen Phase der Pro-duktionsvorbereitung an einem Ort untergebracht. Die Aktivitätenfür den Aufbau und Test der Produktionssysteme sind jedoch miteinigen Schwierigkeiten verbunden. Zunächst wird das Vor-Produk-tionssystem oder Konsolidierungssystem mit der im User-Accep-tance-Test zuletzt getesteten Programmversion sowie den Stamm-und operativen Daten geladen. Der Vor-Produktionstest ist ein Wie-derholungstest (Regressionstest) mit einer selektierten Auswahl vonTestfällen aus dem User-Acceptance-Test. Das Ziel ist, die Funktions-fähigkeit der Geschäftsprozesse und die technische Infrastruktur desSystemumfelds sicherzustellen, bevor der Programmcode in dasfinale Produktivsystem geladen wird. Durch immer wieder auftre-tende Fehler im Transportprozess muss dieser Test mehrmals wie-derholt werden. Transportprozesse müssen sehr sorgfältig geplant


277

und mit den in diesen Prozess involvierten Parteien permanent abge-stimmt werden.

Ausfallzeit minimieren

Eine weitere wichtige Forderung der Geschäftsprozessverantwort-lichen ist, die Produktionsausfallzeit während der Umstellung sogering wie möglich zu halten. In unserem konkreten Fall wird miteiner Ausfallzeit von drei Werktagen (Mittwoch bis Freitag, Produk-tivstart Montag) kalkuliert, in der keine Geschäftsprozesse administ-riert werden können. Für eilige Situationen wird aus diesem Grundein manueller Ausnahmeprozess eingeführt. Für spätere Roll-outskann die Ausfallzeit auf einen Werktag (Freitag) begrenzt werden.

Big-Bang-Implementierung

Wie bereits zu Beginn von Abschnitt 6.1, »Globale SAP-Einführungaus der Sicht eines Pilotlandes«, beschrieben, ist für die Implemen-tierung die Big-Bang-Vorgehensweise entschieden worden, bei derdie Ablösung der Altsysteme in einem Schritt erfolgt. Die Möglich-keit eines Fall-Backs ist für die erste Woche der Produktion vorgese-hen. Sollte es danach größere Probleme geben, geht es nur mehrnach »vorne«! Ausschlaggebend dafür sind die hohe Anzahl derAnwender zum Pilotstart (ca. 1.600 Endanwender) und die damitverbundene Anzahl der Geschäftsvorgänge.

Zur qualitativen Überprüfung von Transaktionen, zum schnellerenAufbau der Lernkurve für die Endanwender und zur Absicherungder Produktion werden zusätzliche Maßnahmen eingesetzt:

� Das Vieraugenprinzip für die Endanwender wird eingehalten.

� Kritische Geschäftsvorgänge werden mithilfe von Listen und Aus-wertungen auf Korrektheit geprüft.

� Ein Nachschulungskonzept für Endanwender ist vorhanden

� Die Produktionsunterstützung wird durch das Projekt- und Ent-wicklungsteam für die ersten zwei Monate nach Produktionsstartsichergestellt.

Aufbau einer Support-Struktur (Helpdesk)

Abbildung 6.23 zeigt den Aufbau der Anwenderunterstützung/Sup-port-Struktur für die Produktivphase.


278

Abbildung 6.23 Anwenderunterstützung/Support-Struktur

Der Anwenderunterstützungsprozess wird entsprechend den Vorga-ben umgesetzt. Der Endanwender kontaktiert bei einer Störungzunächst seinen Fachbereichsspezialisten bzw. Key-User. Der Fach-bereichsspezialist ist in der Lage, einfache Fragen zur Bedienung,Zugriffsberechtigungen, Druckerproblemen etc. zu beantworten. Beikomplexeren Problemen/Störungen wendet sich der Endanwenderan das interne Helpdesk (Level 1).

Helpdesk Das Helpdesk eröffnet eine Fehlermeldung (auch Ticket genannt) undklassifiziert die Störung in einem dafür vorgesehenen Tool. Das Help-desk leitet dann die Anfragen entsprechend der Klassifizierung an diezuständige Anwendungsunterstützung weiter. Störungsmeldungen,die nicht das SAP-System betreffen, werden an die verantwortlicheAnwendungsunterstützung anderer Anwendungen weitergeleitet.

Anwendungs-unterstützung

Der Koordinator der Anwendungsunterstützung (Level 2) hat die Auf-gabe, die Fragen zu den Einstellungen oder Funktionen der SAP-Anwendung zu qualifizieren. Entsprechend der Komplexität der Stö-rung kann es in diesem Prozessschritt zu Rückfragen von Level 2 zumEndanwender kommen. Die Anwendungsunterstützung Level 2prüft dann, ob es sich um eine bereits bekannte Störung oder einneues Problem handelt. Dafür steht der Anwendungsunterstützungeine Informationsdatenbank zur Verfügung, die zu Beginn der Pro-

FachbereichsspezialistEndanwenderLevel 0

HelpdeskLevel 1

Anwendungsunterstützung/InfrastrukturLevel 2

SAP-ProduktunterstützungLevel 3

Tool: telefonisch, per Fax

Fragen zur Systembedienung, Zugriffe, einfache Fragen

Fragen, die vom Level 0 nicht beantwortet werden konnten

komplexe Probleme, mit SAP-Experten zu lösen

Programmfehler, Schnittstellen-probleme, Antwortzeitverhalten (Performance), Netzwerk-Hardware-Probleme

Tool: Ticketsystem

Tool: Ticketsystem

Level 2 Level 3


279

duktivsetzung des Systems aufgebaut und laufend aktualisiert wird.Anschließend wird der Lösungsansatz für die Problemlösung an denEndanwender kommuniziert.

SAP-SupportProbleme, die von der internen Anwendungsunterstützung (Level 2)nicht gelöst werden können (eher selten), werden an den nachgela-gerten Level 3 weitergeleitet, der von SAP wahrgenommen wird.Bevor die Fehlermeldung im Tool geschlossen werden kann, prüftdas Helpdesk, ob das Problem gelöst wurde, gegebenenfalls auchdurch Rückversicherung mit dem Endanwender. Alle Daten im Toolstehen dann für statistische Auswertungen zur Verfügung, z. B. wielange dauerte die Lösung des Problems, die Anzahl der Fehlermel-dungen je nach Klassifizierung und die Dokumentation der Lösung.

Checkliste für die Produktivsetzung

Tabelle 6.11 zeigt die wichtigsten Aufgaben in der Phase der Produk-tivsetzung und die Entscheidungskriterien/Checkliste für das Go-/No-Go-Stakeholder-Meeting (siehe auch www.sap-press.de/3825).

Aufgabe Erledigt

Alle Verantwortlichkeiten für den Produktivstart sind doku-mentiert und verabschiedet. Entscheidungsträger sind fest-gelegt.

Die Anzahl und die Auswahl der Testfälle für den Produk-tivstart sind definiert.

Produktionssysteme sind aufgebaut, und der abschließende Test mit ausgewählten Testfällen verlief erfolgreich.

Alle Daten sind erfolgreich migriert, und die Ergebnisse ent-sprechen den Qualitätskriterien.

Schulungen sind abgeschlossen. Alle Endanwender haben die System-Schulung abgeschlossen.

Produktionszugriffe für Endanwender sind eingerichtet.

Jobprofile und Rollen sind zugeordnet. Es bestehen keine Autorisierungskonflikte.

Support-Struktur nach Produktivstart ist vorhanden. Das Helpdesk ist aufgebaut und einsatzfähig.

Interne/externe Kommunikationsstrategie liegt vor. Die Ankündigungsschreiben sind vorbereitet.

Tabelle 6.11 Checkliste der finalen Vorbereitungs-/Go-Live-Phase


280

Es geht looos! Nachdem alle Voraussetzungen für den Produktivstart erfüllt sindund die Freigaben aller verantwortlichen Führungskräfte vorliegen,wird als Produktionsstarttermin ein Montag nach den Monatsab-schlüssen festgelegt. Erfahrungsgemäß ist die Auslastung der Sys-teme zu diesem Zeitpunkt innerhalb eines Monats in unserem Bei-spielunternehmen am geringsten. Für die ersten zwei Monate nachProduktivstart stehen noch alle Projektmitarbeiter und Entwick-lungsteams für die Lösung von auftretenden Produktionsproblemenzur Verfügung. Danach kann das Projekt in den laufenden Betriebübergeben und beendet werden. Das Projekt wird schließlich miteiner zünftigen Party, an der auch alle Stakeholder teilnehmen, abge-schlossen. Frau Rosenbusch, die Vertreterin der lokalen Geschäfts-führung, und Mr. Smith, der weltweite CIO, haben dabei nochmalsdie Gelegenheit, besonders verdiente Projektmitarbeiter auszuzeich-nen. Die gesamten gesammelten Erfahrungen werden abschließenddokumentiert und für zukünftige Projekte festgehalten.

10 Erfolgsfaktoren für das Pilotprojekt

Schauen wir uns jetzt noch einmal zusammenfassend die kritischenErfolgsfaktoren für dieses SAP-Projekt an, die für die erfolgreiche Umset-zung des Transformationsprozesses essenziell sind:

1. Das Projekt unterstützt die UnternehmensstrategieEs ist von elementarer Bedeutung, dass das Projekt die Unternehmens-strategie und Unternehmensziele unterstützt.

Finale Go-/No-Go-Kriterien für Stakeholder-Meeting sind festgelegt:

� Alle Tests sind erfolgreich abgeschlossen (keine offenen Fehlerlevel 1 und 2).

� Die Freigabe von Geschäftsprozessverantwortlichen wurde eingeholt.

� Alle Daten wurden erfolgreich migriert.

� Schulungen sind abgeschlossen.

� Produktionszugriffe für Anwender sind eingerichtet.

� Die Unterstützung für Produktionsstart ist sichergestellt.

Aufgabe Erledigt

Tabelle 6.11 Checkliste der finalen Vorbereitungs-/Go-Live-Phase (Forts.)


281

2. Die Geschäftsleitung zeigt FlaggeDie Vision über den zu erreichenden Sollzustand wird von der Ge-schäftsleitung kommuniziert und vermittelt. Die Veränderungsprozessewerden durch eine sichtbare und engagierte Führung (Leadership)durch die Stakeholder begleitet. Das notwendige Budget und die er-forderlichen Ressourcen werden für das Projekt freigegeben.

3. Gemeinsames Verständnis über die Bedeutung des ProjektsDie Ziele des Projekts beschreiben klar, warum das Projekt wichtig istund was die Risiken wären, wenn es nicht umgesetzt wird.

4. Frühes Buy-in der involvierten OrganisationseinheitenDie breit angelegte Zusammenarbeit über Funktionsgrenzen hinwegermöglicht ein frühes Buy-in. Die involvierten Funktionen/Organisati-onseinheiten werden aktiv in den Veränderungsprozess mit einbezo-gen. Die Analyse von internen Rollen, Zuständigkeiten und Kontroll-prozessen bei den betroffenen Funktionen wird durchgeführt, um dasAusmaß der Veränderungen zu ermitteln

5. Konsequente Anwendung der Change-Management-MethodenDie Change-Management-Methoden werden konsequent angewen-det. Organisatorische Widerstände werden früh im Projekt erkanntund proaktiv angegangen. Die Kommunikationsstrategie wird gezieltund effektiv über die gesamte Projektlaufzeit umgesetzt. Eine Projekt-Homepage wird entwickelt, um die Mitarbeiter im Unternehmen aufdem Laufenden zu halten. Für die Schulungsvorbereitungen werdendie zukünftigen Endanwender frühzeitig eingebunden.

6. Disziplinierte ProjektsteuerungDie strikte Einhaltung eines disziplinierten Projekt-Managementsys-tems mit einer regelmäßigen Kontrolle und Information über den Pro-jektstatus ist ein Muss. Die Projektrisiken werden zu Beginn des Pro-jekts identifiziert und Maßnahmen zur Gegensteuerung eingeleitet.Die Projektpläne haben einen Detaillierungsgrad, der von den Projekt-mitarbeitern nachvollzogen werden kann. Nach dem Abschluss jederPhase wird ein Qualitätsreview durchgeführt. Die Entscheidungspro-zesse sind klar beschrieben und können erfolgreich angewandt wer-den. Konflikte über Funktionsgrenzen hinweg können zügig geklärtwerden.

7. Effizientes AnforderungsmanagementAchten Sie auf die Einführung eines formalen Anforderungsmanage-mentprozesses und die Festlegung von Vertretungsregeln für Entschei-dungsträger, die durch Abwesenheit nicht erreicht werden können.

8. Klare und eindeutige ProjektzieleDie Projektziele sind messbar, eindeutig, verständlich und für jedenMitarbeiter im Unternehmen nachvollziehbar.

9. Einsatz eines erfahrenen ProjektteamsDie im Projekt eingesetzten Mitarbeiter haben die erforderlichen Kom-petenzen und Erfahrungen aus Vorprojekten. Der Einführungstermin


282

wurde von den Projektmitarbeitern nach anfänglichen Schwierigkeitenund Überarbeitung der Pläne als machbar angesehen.

10. Fokus auf korrekte DatenDer Fokus liegt auf der Datenmigrationsstrategie und im Besonderenauf den laufenden Datenbereinigungsaktivitäten. Wenn auch inunserem Beispielprojekt die Datenbereinigung zu Beginn vernachläs-sigt wurde, konnten durch rechtzeitiges Gegensteuern die Qualitäts-voraussetzungen für die finale Datenmigration noch erreicht werden.

Nach Übergabe des Projekts in den laufenden Betrieb für das Pilot-land stellt sich nun die Frage, mit welchem Konzept der weitereweltweite Roll-out durchgeführt werden soll. Naheliegend ist, dafürdie erfahrenen Mitarbeiter aus dem Pilotprojekt einzusetzen undeine einheitliche Vorgehensweise vorzuschlagen, die wir im nächs-ten Abschnitt besprechen werden.

6.6 Wie geht’s weiter nach der Pilotinstallation: Das Roll-out-Konzept

Ziele des Roll-out-Konzeptes

Für die weiteren Roll-outs nach dem Pilotland gibt es gute Gründe, dieErfahrungen des Pilotprojektteams zu nutzen. Was sind die Ziele?

� Eine klare, unmissverständliche Kommunikation für die Länder-teams zur Unternehmensstrategie und den darauf basierendenProjektzielen.

� Die Einführung einer einheitlichen Vorgehensweise bzw. Imple-mentierungsmethode für den Roll-out. Die Nutzung von gemein-samen Methoden, Projektplänen, Tools und Templates (Best Practices).

� Der Einsatz eines zentralen »Roll-out-Teams« mit erfahrenen Pro-jektmitarbeitern aus dem Pilotland zur Unterstützung der Nachfol-geländer.

� Die Konsolidierung von Projektaktivitäten auf weltweiter (zentra-ler) Ebene, um einerseits eine standardisierte, auf Erfahrung basie-rende Implementierungsmethode anzuwenden und andererseitsdie lokalen Ressourcen der neu zu implementierenden Länder zuentlasten.

� Die Abstimmung der globalen Pläne mit den lokalen Plänen basie-rend auf der globalen Unternehmensstrategie.

Wie geht’s weiter nach der Pilotinstallation: Das Roll-out-Konzept 6.6

283

� Die zentrale, weltweite Kontrolle über das globale Template unddie weltweiten Datenstandards, unterstützt von einem globalenChange Board. Eine Vorgehensweise, die es erlaubt, mehrere Län-der oder Ländergruppen parallel zu implementieren. Die Auswahlder Ländergruppen sollte hauptsächlich nach organisatorischenund systemtechnischen Überlegungen erfolgen, d. h., es wurdenvorzugsweise die Länder für eine Implementierung zusammenge-fasst, die durch eine annähernd einheitliche Systemplattform inden Altverfahren unterstützt wurden und organisatorisch eineEinheit bildeten.

� Die Gewährleistung schneller Entscheidungsprozesse in einemweltweiten Roll-out-Managementsystem.

6.6.1 Die Roll-out-Methode

Die Implementierung für ein Land oder eine Ländergruppe wirdjeweils mit einem neuen Release eingeführt.

Kochbuch für das Roll-out

Den Ländern wird ein Projekthandbuch, eine Art Kochbuch, mit allenAktivitäten und Meilensteinen und Rollen und Verantwortlichkeitenzur Verfügung gestellt. Der Projektplan wird zentral vorgegeben undmit den lokalen Anforderungen ergänzt. Für die Steuerung der Plänewird ein gemeinsames einheitliches Tool eingesetzt. Die Gesamtsteu-erung des Projekts liegt in der Verantwortung des zentralen Roll-out-Teams.

Tabelle 6.12 zeigt die Aufgaben und Verantwortlichkeiten des zen-tralen Roll-out-Teams und der Länderteams.

Aufgabe Verantwortung des welt-weiten Roll-out-Teams

Verantwortung der Länderteams

Projektmanagement verantwortlich für den Gesamtplan, Koordinie-rung der weltweiten Part-ner

Verantwortlich für lokale Pläne und Auf-gaben, Koordinierung der regionalen und lokalen Partner

Prozess verantwortlich für die Durchführung von Prozess-workshops mit den Län-dern/Fit-Gap Analyse

Bereitstellung von lokaler Prozessexper-tise, Roll-out der Soll-Prozesse

Tabelle 6.12 Aufgaben und Verantwortlichkeiten des weltweiten Roll-out-Teams und der Länderteams


284

Change-Manage-ment: (Organisation, Rollen, Kommunika-tion, Schulung)

Einführung in das welt-weite Organisations-modell und die neuen Job-Rollen für die Endanwen-der, Bereitstellung von weltweitem Kommunika-tions- und Schulungsmate-rial, Beratung und Unter-stützung in allen lokalen Change-Management Auf-gaben

Bereitstellung von lokaler Expertise und Einführung der neuen Job-Rollen, Anpassung des Kommunikations- und Schulungsmaterials an lokale Anforderun-gen, Entwicklung eines lokalen Schulungsplans

Konzern-Berichts-wesen

Einführung in das neue weltweite Konzern-Berichtswesen, Beratung und Unterstützung in loka-len Roll-out-Fragen

Analyse der lokalen Anforderungen für das Konzern-Berichtswe-sen, Einführung des Konzern-Berichtswe-sens im Land.

� IT

� Lokale Anpassun-gen/Schnittstellen

Unterstützung des lokalen Roll-out-Teams in der Anforderungserstellung für lokale Anwendungen, Koordinierung der welt-weiten Partner

verantwortlich für die lokalen Anforderungen inkl. Entwicklung und Test, Koordinierung der lokalen Partner

� Test

� Vorbereitung der Testszenarien und Testdurchführung, Testmanagement, Testplan, Testinfra-struktur, Fehlerkor-rektur

verantwortlich für den User-Acceptance- und Prä-Produktionstest, Koordi-nierung der weltweiten Partneranwendungen.

Bereitstellung von lokaler Expertise für die Testvorbereitungen und Testdurchführung, verantwortlich für die Bereitstellung der loka-len Testinfrastruktur

� Produktionsvorbe-reitung

� Erstellung des Gesamtplans für Cut-over-/Go-Live-Aktivitäten

verantwortlich für den Cut-over-/Go-Live-Gesamt-plan, Koordinierung der weltweiten Partner, Unter-stützung der lokalen Län-derteams

Koordinierung der lokalen Partner und Vorbereitung aller lokalen Aktivitäten



Tabelle 6.12 Aufgaben und Verantwortlichkeiten des weltweiten Roll-out-Teams und der Länderteams (Forts.)


285

Prozess-Workshops

Zur Evaluierung der länderspezifischen Prozessanforderungen wirdden Ländern vier bis sechs Wochen vor dem ersten Prozessworkshopein Fragebogen zur Workshop-Vorbereitung zur Verfügung gestellt.Der Fragebogen enthält Fragen wie z. B.:

� Mit welchen Anwendungsprogrammen werden die laufenden Prozesse unterstützt?

� Werden die Prozesse manuell abgewickelt?

� Welche gesetzlichen Vorgaben sind zu berücksichtigen?

� In welcher Organisationsform werden die Prozesse abgewickelt?

� Wie viele Anwender sind in welchen Lokationen?

Der Workshop selbst wird mit den Fachbereichsspezialisten der Län-der, den Prozessexperten des Roll-out-Teams und den Mitarbeiterndes zentralen Datenmigrationsteams durchgeführt und dauert zweiWochen. Das Ziel der Workshops ist, die gemeinsamen weltweitenProzesse, wie im globalen Template dokumentiert und im SAP-Systemumgesetzt, möglichst nicht zu verändern und damit die länderspezi-fischen Anforderungen so gering wie möglich zu halten. Dadurchkönnen auch die Entwicklungsaufwände für zukünftige Implementie-rungen im Rahmen gehalten werden. Die Vorgehensweise ist dabeiwie folgt:

Datenmigration der Altdaten in das Ziel-system

verantwortlich für die Datenmigrationsstrategie und alle Datenmigrations-aktivitäten

Bereitstellung lokaler Expertise für alle Datenmigrationsaktivi-täten, Bereitstellung von Ressourcen für Datenbereinigungsakti-vitäten

Anwenderunter-stützung/Support-Struktur

Einführung der lokalen Länderteams in die welt-weite Support-Struktur

Anpassung der lokalen Unterstützungsstruktu-ren an das weltweite Modell



Tabelle 6.12 Aufgaben und Verantwortlichkeiten des weltweiten Roll-out-Teams und der Länderteams (Forts.)


286

1. Zunächst werden die Ist-Prozesse der neu zu implementierendenLänder identifiziert und besprochen. Grundlage dafür sind Pro-zessdokumentationen und Interviews mit den lokalen Fachbe-reichsexperten.

2. Im zweiten Schritt erfolgt der Abgleich mit dem globalen Templateund der im Pilotland implementierten SAP-Lösung.

3. Auf der Basis der Ist- und Sollprozesse wird die zukünftige Lösungmit dem Ziel dokumentiert, Entwicklungsaufwände möglichst zuvermeiden. Es gibt aber immer wieder heftige Diskussionen, obdie von den Ländern gestellten Prozessanforderungen gerechtfer-tigt sind oder nicht. Die Beweispflicht liegt dabei bei den Ländern.Für diese Fälle hat sich das Roll-out-Managementsystem mitschnellen Entscheidungsprozessen bewährt. Für lokale Anforde-rungen, die berechtigt sind, aber zu hohe Entwicklungsaufwändeverursachen, wurden halbmaschinelle bzw. manuelle Prozessab-läufe vereinbart.

4. Schließlich werden die umzusetzenden Anforderungen bereits imWorkshop so dokumentiert und aufbereitet (systemspezifisch),dass die Entwicklungsteams mit der Programmierung sofortbeginnen können.

6.6.2 Das Roll-out-Managementsystem

Das Managementsystem für das Roll-out ist ein Matrix-Management-system mit einer weltweiten und länderspezifischen Ebene. AlleAktivitäten, die man zentral durchführen kann, werden vom welt-weiten Roll-out-Team bzw. dem weltweiten Test- und Datenmigrati-onsteam wahrgenommen.

Rollen und Verant-wortlichkeiten

Abbildung 6.24 zeigt die Rollen und Aufgaben der beteiligten Teamsim Roll-out-Managementsystem: das zentrale Entwicklungs- und Infra-strukturteam, das zentrale Test- und Datenmigrationsteam und daszentrale Roll-out-Team. Auf lokaler Ebene sind die Implementie-rungsteams der Post-Pilotländer.

Auf zentraler weltweiter Ebene werden alle Entwicklungs-, Test- undDatenmigrationsaktivitäten gesteuert und durchgeführt. Die lokalenProjektpläne müssen mit dem Gesamtplan des weltweiten Roll-out-Teams abgestimmt werden.


287

Abbildung 6.24 Roll-out-Managementsystem

Die Aufgabe der Länder ist es, die erforderliche lokale Expertise fürdie diversen Aktivitäten mit erfahrenen Mitarbeitern bereitzustellen.Die Schnittstelle zum weltweiten Entwicklungsteam läuft ausschließ-lich über das weltweite Roll-out-Team. Alle weltweiten Unterstüt-zungsfunktionen (Entwicklung, Test, Daten, Roll-out) haben einenfachlichen Berichtsweg an den weltweiten Sponsor, die Landesteamsan das weltweite Roll-out-Team und die lokalen Geschäftsführer. DieKommunikation zu weltweiten Partnern im Projekt läuft über daszentrale Roll-out-Team, die Kommunikation zu den regionalen/loka-len Partnern über das Landesteam.

Auf einer Linie: gleicher Informationsstand

In einem internationalen Projekt mit Projektteams, die unterschied-liche Rollen und Aufgaben in verschiedenen Geografien wahrneh-men, muss ein aktueller Informationsstand für alle Beteiligtengewährleistet sein. Aber Achtung! Zu viele Besprechungen und Tele-fonkonferenzen binden wertvolle Zeit für Vorbereitung und Teil-nahme der Projektmitarbeiter. Fehlende oder unvollständige Infor-mationen führen andererseits zu Doppelarbeit, Überlappungen undletztendlich zu verlorener Projektzeit. Hier gilt es die richtige Balancezu finden, nach dem Motto »so viel als nötig, so wenig wie möglich«.Klingt leicht, ist aber in einem komplexen internationalen Projekteine Herausforderung! Wie es umgesetzt wird, sehen Sie in der nach-folgenden Zusammenstellung.

Rollen/Verantwortlichkeiten

globalesTestsystem

globalesEntwicklungs-/Infrastruktur-team

globalesDaten-migrationsteam

globales Roll-out-TeamInterface zu Sponsor u. weltw.

Partner/PMO/Prozess/Training/Komm.

globaler Sponsor

globalePartner

regionale und lokale Partner

Region/Landesteam: Schnitt-stelle zu regionalen und lokalen

Partnern/Expertise in lokalen Prozessen und Systemen,

Umsetzung lokaler Aktivitäten/PMO


288

� Meetings des LenkungsausschussesDie Mitglieder des Lenkungsausschusses treffen sich zu monatli-chen Meetings. Verantwortlich für die Meetings ist das zentraleRoll-out-Team. Auf der Agenda stehen die folgenden Tagesord-nungspunkte:

– Übersicht Zeitleiste des Projektplans

– erreichte Ziele seit dem letzten Meeting/Status Aktionsplan

– Status der Abhängigkeiten zu anderen Partnern/offene Themen

– weltweite/lokale Meilensteinübersicht

– Status von Entwicklung, Test und Datenmigration

– Probleme/Risiken/Themen, die eine Entscheidung erfordern

– nächste anstehende Planaktivitäten

� Weltweite Projektstatus-BesprechungenWöchentlich finden weltweite Projektstatus-Besprechungen derGesamtpläne (aller am Projekt beteiligten Partner) statt. Die Vor-bereitung erfolgt vom weltweiten PMO, die Leitung hat der welt-weite Projektsponsor.

� Lokale Projektstatus-BesprechungEbenfalls wöchentlich gibt es Projektstatus-Besprechungen derlokalen Projektteams mit dem weltweiten Roll-out-Team zur Vor-bereitung auf die weltweiten Projektstatus-Besprechungen. DieVorbereitung erfolgt vom lokalen PMO.

� Prozessdesign-Reviews und Solution-Design-ReviewsNach Bedarf finden Prozessdesign-Reviews und Solution-Design-Reviews statt, um die Freigabe zu einer Entwicklungslösung vonden Länderteams und involvierten Partnerfunktionen einzuholen.

� SystemarchitekturmeetingsDiese Abstimmungsbesprechungen finden monatlich oder nachBedarf statt, um Veränderungen oder Abweichungen zu identifi-zieren.

� QualitätschecksNach Abschluss von Projektphasen und zur Vorbereitung der Pro-duktivphase erfolgt der Qualitätscheck. Die Leitung liegt beimweltweiten Sponsor, die Vorbereitung und Durchführung wirdvom zentralen Roll-out-Team übernommen.


289


Wie gelingt die Umsetzung in die Praxis?

In diesem Abschnitt wollen wir beschreiben, wie die Umsetzung desRoll-out-Konzepts in die tägliche Praxis gelingt. Zunächst kurzzusammengefasst die kritischen Herausforderungen für einen Roll-out von neuen Prozessen und Systemen in weitere Länder bzw. Län-dergruppen:

� Die Verfügbarkeit von kritischem Skill ist in kleineren Länder-gruppen schwierig umzusetzen. Die Kenntnisse über die neuenProzesse und Systeme sind beim weltweiten Roll-out-Team. Fürdie Analyse der lokalen Ist-Situation ist man auf lokale Fachspezi-alisten angewiesen.

� Die Komplexität der integrierten Gesamtlösung. Die Änderungenbetreffen verschiedene Prozesse, Systeme und Organisationsein-heiten und erfordern die Mitarbeit von verschiedenen Fachberei-chen in den Ländern.

� Die Vorgabe einer schnellen Umsetzung stellt ebenfalls eine kriti-sche Herausforderung dar.

Zeit ist Geld!Der Einsatz von lokalen Fachspezialisten kann nur durch die weiterekontinuierliche Unterstützung der Stakeholder im Projekt sicherge-stellt werden. Ebenso hilfreich ist das bereits bewährte weltweiteProjektmanagementsystem mit einem weltweit agierenden Projekt-sponsor, der auch nach der Pilotinstallation die Gesamtverantwor-tung für die weiteren Roll-outs übernimmt.

Wichtig! Das Projekt hat im Konzern nach wie vor oberste Priorität.

Organisation der Projekt-Kick-offs

Der Projekt-Kick-off für eine neue Länderimplementierung ist vierWochen vor dem eigentlichen Projektstart geplant. Für die Durch-führung ist das weltweite Roll-out-Team verantwortlich. Daran neh-men die weltweiten und lokalen Projektsponsoren, der lokale Pro-jektleiter und der Leiter des weltweiten Roll-out-Teams mit einigenseiner Fachspezialisten teil. Inhaltlich geht es um folgende Themen:

� Überblick über die neuen weltweiten Prozesse und Systeme

� organisatorische Auswirkungen des Projekts auf die lokalen Fach-bereiche

� Erkenntnisse und Erfahrungen aus der Pilotinstallation und dennachfolgenden Länderimplementierungen


290

� weltweites Roll-out-Managementsystem und Vorschlag für lokalesProjektmanagementsystem

� Aufgabe und Verantwortlichkeiten der weltweiten Unterstüt-zungsfunktionen (Roll-out, Test, Daten, Entwicklung)

� Ziele und Inhalte des Projekthandbuches (Kochbuch)

� lokaler Ressourcenbedarf an Fachspezialisten für den Roll-out

� Übersicht über die Projektbudgets und deren Kontrolle

� weltweiter Projektplan mit Meilensteinen als Basis für die lokalenPläne

Gleichzeitig werden die Vorbereitungen für die lokalen länderspezi-fischen Prozessworkshops (siehe Abschnitt 6.6.1, »Die Roll-out-Me-thode«) getroffen. Der Prozess-Fragebogen wird den Ländern bereitsim Projekt-Kick-off-Meeting oder vorher zur Verfügung gestellt. Ne-ben der Benennung des lokalen Projektleiters ist die Zuordnung vonlokalen Prozessfachspezialisten zur Unterstützung der geplanten Pro-zessworkshops zunächst die dringlichste Aufgabe.

Roll-out-Anforderungs-

prozess

Der Entwicklungsprozess für die Umsetzung von neuen Anforderun-gen aus den Prozessworkshops ist in Abbildung 6.25 dargestellt. DieAnforderung wird zunächst von Fachspezialisten für Prozessegesamtheitlich analysiert, ob die Anforderung in die strategischeGesamtlösung übernommen werden kann. Ist dies der Fall, prüfenSAP-Architekten die Durchgängigkeit über verschiedene Moduleund klären, ob es eventuell Schnittstellenprobleme mit vor- odernachgelagerten Verfahren geben könnte. Wird die Anforderunggenehmigt, kann die Umsetzung entweder durch Customizing oderim ungünstigeren Fall durch Programmierung gelöst werden. NachErledigung sind die Prozess- und Endanwenderdokumente zu aktua-lisieren und eine Endabnahme durch die Fachspezialisten für Pro-zesse sicherzustellen.

Wird eine Anforderung abgelehnt, besteht die Möglichkeit, den Vor-gang innerhalb des Projektmanagementsystems über das weltweitePMO zu eskalieren. Finale Entscheidungen werden vom weltweitenLenkungsausschuss (Steering Committee) getroffen.

Roll-out-Timeline Basierend auf den Erfahrungen mit der Pilotinstallation wird die Pro-jektlaufzeit für den Roll-out eines Landes bzw. einer Ländergruppemit zehn Monaten angenommen. Eine herausfordernde Zeitvorgabe,die jedoch bis auf wenige Ausnahmen eingehalten werden kann.


291

Abbildung 6.25 Ablauf des Entwicklungsprozesses

Abbildung 6.26 zeigt die Hauptaktivitäten der Roll-outs über die ver-schiedenen Projektphasen.

Abbildung 6.26 Post-Pilot Roll-out-Timeline

Kulturelle Unterschiede beachten!

Der Projektstart verläuft für die meisten Länder ohne große Pro-bleme. Dass auch auf kulturelle Besonderheiten Rücksicht genom-men werden muss, wird bei den ersten Roll-outs in den außereuro-

Ermittlung der Anforderungen

Anforderungs-analyse

Review des Anforderungsdesigns

SAP-Architektur-Review

Customizing

Programm-spezifikationen Entwicklung

Überprüfung desProgrammcodes

Komponententest

Update der Prozessdokumente/ Endanwenderanweisungen

Endabnahme der Anforderungen

Fachspezialisten für die Prozesse

Entwicklungsteam

Freigabe des Programmcodes/

Update derEntwicklungsdok.

Planung und Vorbereitung 1–2 Blueprint 2–4 Realisierung 4–7

Produktions-vorbereitung

8–9

Go-Live und Support 10

Projektmanagement

Anpassung des Prozess-Templates

Customizing/Entwicklung/Schnitt-stellen/Systemintegrationstest/Schulungsmaterial entwickelt

Datenbereinigung

Datenkonvertierung/Laden

Schulung abgeschlossen,

Produktionssystem getestet, Helpdesk,

Go-Live; Genehmigung

Go-Live/Übergabe Helpdesk


292

päischen Raum offensichtlich. Entsprechend dem Roll-out-Konzeptwerden nach dem Projekt-Kick-off die weiteren Abstimmungenzunächst telefonisch vorgenommen. Die zur Verfügung gestelltenProjektpläne müssen in den ersten Wochen vom lokalen Pilotteammit den lokalen Aktivitäten ergänzt werden. Für diese Abstimmungsind zwei Mal pro Woche Telefonkonferenzen vorgesehen. Die zwi-schen weltweiten und lokalen Teams abgestimmten Projektdetail-pläne sollen nach vier Wochen vorliegen.

Die ersten Telefonkonferenzen verlaufen ohne große Rückfragen.Nach drei Wochen sollen die ersten lokalen Teilprojektpläne vorlie-gen. Erst zu diesem Zeitpunkt wird im weltweiten Roll-out-Teamfestgestellt, dass auf lokaler Länderebene keine weiteren Aktivitätenerfolgt waren. Die Gründe sind einerseits auf Sprachbarrieren – dieProjektsprache ist Englisch – und andererseits auf die Zurückhaltungder Mitarbeiter im lokalen Länderteam zurückzuführen, die keineFragen gestellt hatten. Um keine weitere Zeit zu verlieren, werdendeshalb zwei Mitarbeiter aus dem zentralen Roll-out-Team zum Län-derteam vor Ort für die folgenden vier Wochen entsandt. So könnenFragen und Unklarheiten im persönlichen Gespräch sofort beant-wortet werden. Nachträglich gesehen ist diese Entscheidung einwichtiger Schritt für das Gelingen des Roll-out-Projekts und die wei-tere vertrauensvolle Zusammenarbeit.

Qualitäts-Review Nach dem Ende der Blueprint-Phase ist ein Qualitäts-Review geplant.Dabei werden die kritischen Aktivitäten der einzelnen Teilpläneüberprüft. Zu jedem Teilplan gibt es einen Fragenkatalog, der vomlokalen Länderteam vorab zu beantworten ist. Der Review selbst fin-det im Land mit dem lokalen Management und Länderteam, demweltweiten Projektsponsor, den weltweiten Unterstützungsfunktio-nen (Test, Daten, Entwicklung) und dem zentralen Roll-out-Teamstatt. Er ist für zwei Tage angesetzt und wird vom zentralen Roll-out-Team organisiert. Der Review der Teilpläne umfasste die folgendenAufgaben:

� Projektmanagement

– Überblick über Budget/Ressourcen

– Übersicht über den Planstatus und die Planverfolgung

– Vorstellung des lokalen Projektmanagementsystems (Bespre-chungsfrequenz, Einbindung von lokalen Partnerfunktionen)

– Einhaltung der Dokumentationsrichtlinien


293

� Prozess

– Wie ist der Prozessanforderungsstatus/welche kritischen Pro-zesse sind noch offen?

– Wie ist der Interlock zu Partnerfunktionen?

– Übersicht über den Implementierungsplan der neuen Prozess-kontrollpunkte

– Wie ist der Aktualisierungsstatus der lokalen durch das Projektbeeinflussten Projektdokumentation?

– Sind für den Test der lokalen Prozesse erfahrene Ressourceneingeplant?

� IT

– Wie ist der Status der lokalen IT-Abhängigkeiten, die Vorausset-zung für den User-Acceptance-Test sind?

– Sind weitere IT-Infrastrukturmaßnahmen geplant (Laptops,PCs, Drucker etc.) und wie ist der Status?

� Test

– Wie ist der Status der lokalen Testvorbereitungen?

– Sind die lokalen Testressourcen sichergestellt?

– Sind die lokalen Partnerfunktionen eingebunden?

� Schulung

– Sind die Ressourcen für Schulungsmaßnahmen vorhanden?

– Sind die Schulungsteilnehmer identifiziert und informiert?

– Sind lokale Anpassungen des weltweiten Schulungsmaterialsnotwendig?

– Sind die logistischen Voraussetzungen für die Schulungsmaß-nahmen erfüllt?

� Job-Rollen

– Wie sieht der lokale Implementierungsplan für neue Job-Rollen aus?

– Sind betroffene lokale Organisationen informiert?

� Kommunikation

– Sind die Stakeholder identifiziert und informiert?

– Ist die lokale Managementunterstützung für das Projekt sicher-gestellt?


294

– Sind die internen Fachbereiche informiert?

– Übersicht über den lokalen Kommunikationsplan

– Sind externe Partner identifiziert, die vom Projekt betroffensind, und wie werden diese informiert?

� Daten

– Sind die lokalen Ressourcen für Datenmigrationsaufgaben vor-handen?

– Wie ist der Status der lokalen Datenbereinigungsaktionen?

Das Ergebnis und daraus ableitend die Empfehlungen und Aktionendes Qualitäts-Reviews wird dem lokalen und weltweiten Manage-ment in einem Bericht mitgeteilt. Die Nachverfolgung der Aktionenerfolgt über die wöchentlichen Projektstatusmeetings. Nach Ab-schluss des User-Acceptance-Tests und vor Beginn der Produktions-vorbereitungen findet ein weiterer Review vor Ort statt. Inhaltlichstehen die Abschlussaktivitäten der Realisierungsphase und diegeplanten Aktivitäten der Produktionsvorbereitungsphase im Fokus.

Fachspezialistenvor Ort

Die guten Erfahrungen, die mit der Entsendung von Fachspezialistenaus dem weltweiten Roll-out-Team zum Landesteam vor Ortgemacht werden, helfen auch im User-Acceptance-Test. Ein erfahre-ner Testmitarbeiter unterstützt das lokale Team während der gesam-ten Testphase vor Ort. Damit können auch die Probleme mit denunterschiedlichen Zeitzonen zum Teil abgefangen werden, d. h.,Stillstand im Projekt kann in den meisten Fällen vermieden werden.Fragen, die vom zentralen Testmitarbeiter vor Ort nicht sofort beant-wortet werden können, werden am nächsten Werktag in telefoni-schen Abstimmungsmeetings geklärt. Für bereits implementierteLänder werden einheitliche Test-Regressionsszenarien eingesetzt,die vom zentralen Testteam administriert bzw. mit der Unterstüt-zung von automatisierten Testtools abgewickelt werden. Nacherfolgreichem Abschluss des User-Acceptance-Tests können die SAP-Transportaufträge in die Produktivumgebung und das Schulungssys-tem freigegeben werden. Ein weiterer letzter Test wird dann auf demVorproduktionssystem mit einigen ausgewählten Geschäftsvorfällendurchgeführt. Danach kann mit dem Laden der Daten für das neueLand begonnen werden.

Schulung für neueLänder

Parallel dazu laufen die Schulungen für die Endanwender. Die für diePilotinstallation erstellten Schulungsunterlagen werden auf länder-


295

spezifische Anforderungen angepasst, um lokale Prozesse abzubilden.Für den Klassenunterricht wird ein lokaler Projektmitarbeiter ausdem Länderteam nach dem bereits bewährten »Train the Trainer«-Konzept vorbereitet. Begleitet wird er von einem erfahrenen Traineraus der Pilotinstallation, der für Rückfragen zur Verfügung steht. DieSchulung erfolgt in lokaler Landessprache, das Schulungsmaterialselbst liegt in englischer Sprache vor und wird nicht übersetzt. Wieschon bei der Pilotinstallation werden auch Online-Schulungsmodulefür weitere Benutzergruppen angeboten. Dieses erfolgreiche Konzeptwird auch für alle weiteren Roll-outs beibehalten.

ProduktivsetzungDie Produktivsetzung für jedes neue Land bzw. eine Ländergruppeerfordert die Zustimmung der lokalen und weltweiten Stakeholderin einem abschließenden Go/No-Go-Meeting. Voraussetzung dafürist die erfolgreiche Abarbeitung aller Kriterien aus der Go-Live-Checkliste (siehe Abschnitt 6.5, »Finale Vorbereitungsphase/Go-Liveund Support« und dort insbesondere Tabelle 6.11, »Checkliste derfinalen Vorbereitungs-/Go-Live-Phase«). Für die Bearbeitung vonProduktionsproblemen nach der Go-Live-Phase sind zusätzlich fürdie ersten vier Wochen nach Produktionsstart zwei Mitarbeiter vorOrt zur Unterstützung der Länderteams vorgesehen.

Vorteile der Roll-out-Methode

Die gewählte Vorgehensweise hatte die folgenden Vorteile:

1. Die Standardisierung der Aktivitäten in zentralen Teams erreicht sehrschnell eine hohe Produktivität, reduziert die Gesamtkosten des Pro-jekts und ermöglicht einen schnellen Roll-out.

2. Die zentralen Teams arbeiten in unterschiedlichen Zeitzonen nach demFollow-the-Sun-Prinzip. Auf diese Weise können auftretende Pro-bleme zügig gelöst werden.

3. Ressourcenengpässe in kleineren Ländern, die Probleme mit der kriti-schen Masse haben, können durch die Unterstützung der zentralenTeams (Test, Daten, Roll-out) aufgefangen werden.

4. Die gewählte Vorgehensweise zur Identifizierung von lokalen Prozess-anforderungen (Vorbereitung und Durchführung der Workshops) trägterheblich zur Reduzierung der Entwicklungsaufwände bei.

5. Mehrere Länder oder Ländergruppen können gleichzeitig produktivgesetzt werden.

6. Durch die standardisierte einheitliche Vorgehensweise kann die Pro-duktionsstabilität während der Länderimplementierungen gehaltenwerden.


296

Die Erfahrungen aus der Pilotinstallation und den darauffolgendenweltweiten Roll-outs zeigen klar, wie essenziell eine sorgfältige Pla-nung, Steuerung und Qualitätssicherung für den Erfolg eines Pro-jekts ist. Wie Sie in diesem Sinne den Grundstein legen, haben Sie inKapitel 5 erfahren.

Wenn Sie wissen wollen, wer oder was Sie bei Ihrem Projekt unter-stützt, dann lesen Sie in den folgenden beiden Kapiteln weiter: Densinnvollen Einsatz von externen Ressourcen behandeln wir in Kapi-tel 7 und die Benutzung von hilfreichen Software-Werkzeugen inKapitel 8.

6 Die SAP-Einführung in der Praxis - Thali · Der Zugriff auf Experten von SAP in Walldorf wird...

Documents

Transcript of 6 Die SAP-Einführung in der Praxis - Thali · Der Zugriff auf Experten von SAP in Walldorf wird...