SAP-Implementierung auf Basis des ASAP-Modells
Aus Winfwiki
| Name des Autors / der Autoren: | Stafan Knauer, Christian Pape, Mathias Spiekermann |
| Titel der Arbeit: | "SAP-Implementierung auf Basis des ASAP-Modells" |
| Hochschule und Studienort: | FOM Essen |
1 Einführung
Der Schwerpunkt der vorliegenden Fallstudie beschäftigt sich mit der Einführung der Unternehmenssoftware SAP auf Basis des ASAP-Ansatzes. Das Ziel ist die Darstellung der Differenzen des ASAP-Konzeptes zu traditionellen Projektmanagementmethoden für die SAP Einführung.
Unter ASAP, umgangssprachliches Akronym für "as soon as possible", übertragen auf die Einführung eines SAP Systems versteht die SAP AG: AccleratedSAP. Das ASAP-Vorgehensmodell soll einen schnellen Einstieg in das SAP Einführungsprojekt ermöglichen, sowie durch die Definition eines standardisierten Vorgehens Zeit, Ressourcen und letztendlich den Einsatz finanzieller Mittel möglichst niedrig halten. Zusammen mit der Hervorhebung von Vor- und Nachteilen des Ansatzes, soll dieses Ziel der SAP AG durch die Fallstudie verifiziert werden.
Der ASAP-Ansatz stellt eine festgelegte Vorgehensweise dar, welche nicht in dem Masse, wie ein Projekt auf Basis einer allgemeinen Projektmanagementmethode, auf die individuellen Anforderungen des einzelnen Unternehmens eingehen kann. Das ASAP-Vorgehensmodell basiert auf den Erfahrungen der SAP AG aus den zuvor ca. 16.000 erfolgten SAP Installationen weltweit. Trotzdem stellt sich die Frage ob eine schnelle tendenziell unflexible Vorgehensweise den Vorzug gegenüber eines länger dauernden, dafür aber stark individualisierbaren, Einführungsprojekts erhalten sollte.
Anwendung kann das ASAP-Konzept nicht nur bei der ursprünglichen Einführung finden, genauso ist eine Verwendung bei Einführung zusätzlicher SAP-Module oder Releasewechsel möglich.
1.1 Geschichte
Das ASAP-Vorgehensmodell wurde offiziell im Jahre 1996 durch die SAP America präsentiert und erstmals eingesetzt. Ausgerichtet ist ASAP auf die Einführung der SAP Standardsoftware in mittelständischen Unternehmen bis hin zu Großkonzernen.
Ab dem Jahre 1997 wurde das Konzept auch in Europa eingesetzt. ASAP löste ab diesem Zeitpunkt die verschiedenen traditionellen Formen der Unternehmenseinführung von SAP ab und ist heute die bevorzugte Implementierungslösung für die SAP Unternehmenssoftware weltweit.
Siehe [3]
1.2 Intention/Motivation
1.2.1 SAP
Die Einführung eines SAP Systems in mittelständischen Unternehmen oder Großkonzernen kann aufgrund ihrer Komplexität einen Zeitraum von mehreren Jahren in Anspruch nehmen.
Ausgehend von Kritik an der bisherigen, teilweise sehr zeit- und ressourcenintensiven, Einführungsmethode hat die SAP AG auf Basis gesammelter Erfahrungen ein Vorgehen entwickelt, welches die Einführung in einem relativ kurzen abgegrenzten Zeitraum ermöglichen soll.
Weiterhin stand die Wiederverwendbarkeit einmal gesammelter Erfahrungen im Blickpunkt bei der Entwicklung von ASAP. Die SAP AG will mit ASAP den Transfer bisheriger Erkenntnisse aus Einführungsprojekten, in Form strukturierter Arbeitsweisen, in zukünftige Projekte ermöglichen und fördern.
1.2.2 Unternehmen
Absicht dieses Abschnittes ist nicht die Motivation von Unternehmen zur Einführung von SAP zu beleuchten, sondern zu Klären wann die Entscheidung auf die Einführungsmethode ASAP fällt und wann eher traditionelle Vorgehensweisen gewählt werden.
Die Motivation der Unternehmen zum Einsatz von ASAP liegt in erster Linie in der überschaubaren Dauer des Einführungsprojektes. Je weniger Zeit zwischen der Anforderungsdefinition und dem Echtbetrieb liegt, desto eher entspricht das System zu Zeiten kürzerer Produktlebenszyklen und zunehmendem Wettbewerbsdruck den Anforderungen.
Ständig wechselnde betriebswirtschaftliche Rahmenbedingungen und Anforderungen an das System in der Einführungsphase strecken die Projektdauer und erhöhen somit stetig die Kosten, während ein Return on Investment mangels Produktivbetrieb nicht abzusehen ist.
Der geringere monetäre Aufwand bei gleichzeitiger Kostentransparenz, als Ergebnis der kürzeren Projektdauer, ist in den Augen der Unternehmen ein Argument für die Nutzung des ASAP-Ansatzes.
Weiterhin ist durch das ASAP Vorgehensmodell ein erhöhter Know-How Transfer auf die eigenen Mitarbeiter gewährleistet. Diese reduzierte Abhängigkeit von externen Beratern und das dadurch entstehende Einsparungspotential ist ein weiterer Grund zur Anreiz von ASAP seitens der Unternehmen.
2 Projektmanagementmethoden
2.1 ASAP
ASAP ist keine grundlegend neue Entwicklung der SAP AG, sondern baut auf dem zuvor genutzten traditionellen System der SAP Einführung auf. Beide Systeme sind Vertreter der Wasserfallmodelle. Ein Wasserfallmodell ist linear aufgebaut, d.h. erst wenn eine Phase abgeschlossen und abgenommen ist kann mit der nächsten begonnen werden. Das ASAP Modell nutzt nicht das erweiterte (iterative) Wasserfallmodell mit Rücksprungoption, sondern stellt durch eine abschließende Qualitätssicherung die erfolgreiche Durchführung der Phase sicher.
Bestehend aus der Roadmap, welche in aufeinanderfolgenden Schritten, sogenannten Phasen, detailliert alle im Projektverlauf durchzuführenden Aktivitäten vorgibt, ergänzt durch unterstützende Werkzeuge, Beispiele und Checklisten, basiert ASAP auf dem traditionellen SAP-Vorgehensmodell.
ASAP nutzt den CASI (Computer aided Software Implementation) Ansatz, der gesamte Prozess der Einführung kann durch Installation des ASAP-Pakets unterstützt werden. Das heißt in sämtlichen Phasen können Werkzeuge wie Beschleuniger und Checklisten Rechnergestützt genutzt werden.
Innerhalb der einzelnen Phasen von ASAP wird auf Arbeitspakete aus dem bisherigen Vorgehensmodell zurück gegriffen. Somit nutzt ASAP Erfahrungen aus den vorangegangenen SAP Installationen, fügt aber durch die Roadmap einen stark strukturierten und durchgehenden Leitfaden hinzu.
ASAP als referenzbasierte Einführungsmethode bedingt die Bereitschaft der Unternehmen ihre originär gewachsenen Geschäftsprozesse zu Gunsten der durch ASAP definierten Referenzprozesse aufzugeben. Ohne ein vorgeschaltetes Business Process Reenginiering wird die Komplexität und der Umfang reduziert mit dem Ziel einer verkürzten Projektlaufzeit.
Dem entgegen steht eine Anpassung des SAP-Systems auf die bestehenden Geschäftsprozesse im Rahmen eines traditionellen Einführungsprojektes. Dies bedingt ein umfangreiches Customizing des SAP-Systems, mit der Folge höherem Ressourcenaufwands (zeitlich wie monetär).
2.2 Traditionelles SAP-Vorgehensmodell
Das traditionelle SAP-Vorgehensmodell ist wie der Name schon vermuten lässt chronologisch vor dem ASAP-Ansatz angesiedelt. Es ist auch an das Wasserfallmodell angelehnt besteht aber aus vier Phasen, die ebenfalls linear durchlaufen werden. Die vier Phasen heißen:
- Organisation und Konzeption
- Detaillierung und Realisierung
- Produktionsvorbereitung
- Produktivbetrieb
Im Gegensatz zum ASAP Ansatz lässt das traditionelle Vorgehen den Unternehmen die freie Wahl bei der Art des Customizings. Werden beim ASAP-Ansatz die Unternehmensprozesse an die Referenzprozesse angepasst so kann bei der traditionellen SAP-Vorgehensweise auch der umgekehrte Weg eingeschlagen werden.
3 ASAP-Roadmap
3.1 Phase 1: Projektvorbereitung
3.1.1 Planung und Vorbereitung
Die Entscheidung für SAP wurde gefällt nach dem überprüft wurde ob die bestehende betriebswirtschaftliche Organisation mit SAP abgebildet wurde. Die Phase der Planung und Vorbereitung setzt diese Entscheidung voraus. Die Planung ist das gedankliche durchspielen des Projektes um das gesetzte Ziel zu erreichen.
Dazu gehören die Festlegung und Beschreibung von Zielen, die Einführungsstrategie, das Einplanen von Ressourcen, die Zeitplanung.
3.1.2 Arbeitspakete
3.1.2.1 Projektplanung
Dieses Arbeitspaket wird durch die Erstellung des Projektauftrages dominiert. In den Projektauftrag wird die Sollsituation nach Beendigung und Einführung des SAP-Systems beschrieben. Hierzu gehören die Prozesse die nach der Einführung von SAP unterstützt werden. Die Geschäftsziele und Erwartungen (Mission Statement), Projekterfolgskennzahlen, Meilensteine; Leitbild der Einführung. Zu den Erfolgskennzahlen zählen auch betriebswirtschaftliche Kennzahlen so genannte Business Driver. Diese quantifizierbaren Kennzahlen dienen in erster Linie der Messung des wirtschaftlichen Erfolges der Einführung. Das können Umschlaghäufigkeiten, Transportkosten, Prozesskosten, etc. sein.
Der Projektauftrag wird in enger Zusammenarbeit mit der Geschäftsführung erarbeitet, die Ziele dienen in erster Linie der Messbarkeit und der Motivation. Eine entsprechende Dokumentation des Projektauftrages sollte gegeben sein.
Festlegung der Einführungsstrategie(Rolloutstrategie): Hier sind die folgenden Fragen zu klären?
- Soll ein Modul oder Komplettsystem implementiert werden?
- Big Bang Strategie (alles auf einmal) oder Stufenansatz (Modulweise)
- Werksweise/Abteilungsweise/Länderweise Einführungsszenarien
- Wer soll das System Implementieren (eigen oder fremd)?
Nach Klärung dieser Fragen kann mit der weiteren Planung fortgesetzt werden.
Schaffung einer Infrastruktur für das Projektteam. Hier ist ein Projektraum mit entsprechender Ausstattung sinnvoll. Dieser Raum sollte über die nötige Hard- und Software, Netzwerkzugänge und Kommunikationseinrichtungen verfügen. Der Raum sollte frühzeitig bereit stehen um Teambildungsmaßnahmen zu unterstützen.
Projektorganisation und -struktur gehört auch zu dieser Phase, sie unterteilt sich in eine Aufbauorganisation (Wer macht was?) sowie in eine Ablauforganisation (Wie wird etwas gemacht?). Hier wird auch noch in Vollzeit und Teilzeit Projektzugehörigkeit der Teammitglieder unterschieden. Die Vollzeit Projektzugehörigkeit ist die Ausnahme, da es in der Regel für die Projektteilnehmer noch ein Tagesgeschäft gibt. Erfahrungen und Qualifikationen sind sehr wichtige Kriterien bei der Auswahl und Bestimmung der Inhaber der verschiedenen Projektrollen. Das Projektteam sollte aus unterschiedlichen Unternehmensbereichen zusammen gesetzt werden, dies fördert den Know-How Transfer und die Akzeptanz des Projektes. Die Aufbauorganisation beinhaltet folgende Rollen bzw. Gruppen, mit den zugehörigen Aufgaben der Ablauforganisation:
- Lenkungsauschuss (auch Projektauschuss oder Leitungsgremiun genannt):
Dieser setzt sich aus Mitgliedern der Geschäftsleitung, je nach Unternehmensgröße auch Mitglieder des Vorstandes und Entscheidungsträgern des Beratungsunternehmens zusammen. Projektleiter berichten über den Stand ihrer Teilprojekte an den Lenkungsauschuss. Entscheidungen über Planung und Durchführung werden von ihm getroffen. Der Lenkungsauschuss tritt auch als Schlichter bei Befugnis bzw. Meinungsunterschieden auf.
- Projektleitung:
Unternehmensmitglieder als auch externe Berater können die Projektleitung ausführen. Die Übertragung der gesamten Projektleitung auf eine Person ist dabei sehr wichtig um Kompetenz/Verantwortungsgerangel zu vermeiden. Bei Großprojekten sind zusätzlich Teilprojektleiter vorgesehen. Hauptaufgaben der Projektleitung sind die Bündelung der fachlichen und technischen Kompetenzen, Aufgabenverteilung, Controlling und Koordination.
- Projekt-Team:
Die Zusammenstellung erfolgt aufgabenorientiert, dazu gehören Mitarbeiter der Fachabteilungen, EDV, Technik, externe Berater.
- Teilprojektteam:
Sinnvoll bei großen Unternehmen um aufgabenorientierte Arbeit besser zu organisieren. Das Team hat einen Verantwortlichen, der an den Projektleiter berichtet. Eine klare Abgrenzung der Kompetenzen ist auch hier wieder unerlässlich.
- Prozessverantwortlicher:
Die bisherige Organisation orientierte sich an Aufgaben bzw. Rollen. Ein Prozess ist dadurch gekennzeichnet dass er diese Grenzen verlässt oder gar nicht von diesen abhängig ist. Es macht daher Sinn für Prozesse einen Verantwortlichen zu benennen um diese Prozesse ganzheitlich zu betreuen.
Der Projektplan ermittelt die erforderlichen Ressourcen, elementar sind hier Personal, Kosten und Zeitplanung/Meilensteine. Als Werkzeug empfiehlt SAP des PM-Tool MS-Project von Microsoft. Projektdokumentation wird auch mit Hilfe des Projektplanes gewährleistet. Diese Planung wird fortlaufend durch das gesamte Projekt fortgeführt, um jederzeit einen aktuellen Status ermitteln zu können. Diese Dokumentation ist eine Vorrausetzung für das Gelingen des gesamten Projektes. SAP stellt für diese Planung ein Tool mit dem Namen Project Estimator zur Verfügung Der Project Estimator ist ein Schätztool und soll bei der Ressourcenplanung speziell im monetären Bereich unterstützen.
Zur Schaffung einer Know-How Basis ist auch in dieser Phase die Schulung des Projekt-Teams zu planen. Erste Schulungen sollten auch schon in dieser Phase stattfinden um ein besseres Verständnis für die SAP Funktionalitäten zu schaffen. Die Ausrichtung des Systems an die Projektziele sowie das Customizing sollten den Mitarbeitern nahe gebracht werden. Der Ort der Schulung (intern oder extern) sollte ebenfalls festgelegt werden.
3.1.2.2 Projektablauf
- Definition der Projektstandards/Prozeduren:
Die Einrichtung und Festlegung der Standards und Prozeduren geben den Mitarbeitern Handlungssicherheit, da diese der Orientierung dienen. Sie vereinfachen die Kommunikation, redundante Arbeiten werden vermieden, Konsistenz sicher gestellt. Diese Standards werden an das gesamte Team kommuniziert. Bei der Festlegung der Standards ist zu beachten, dass Standards auf alle Phasen oder auch nur auf bestimmte Phasen angewendet werden. Hier sind unter anderem die externe Qualitätsprüfung, die Strategie zur Benutzung des SAP Systems, Change Management, Methoden der Projektkommunikation zu beachten.
Einführungsstandards- und Abläufe werden durch ASAP vorgegeben können aber auch individuell erstellt werden. ASAP stellt hierfür eine Reihe von Vorlagen für Dokumente und Berichte bereit. Sie können helfen bei der Umfangsänderung, Klärung offener Punkte und Teamkommunikation. Dies wird auch durch die Bereitstellung von Anleitungen und Beispielen gewährleistet. Die festzulegenden Standards sind z.B. Gesamtkonfigurationsstandards, Standards für Berechtigungen, Strategien für Benutzerschulungen, Teststrategien, Service- und Supportstrategien, Problem- und Fehlerbehandlungsverfahren.
- Definition der Systemlandschaft:
Die Aufgaben der Systeme werden festgelegt, sowie eine Identifikation. Das heißt den einzelnen Systemen werden eindeutige Namen zugewiesen. Die Transportwege zwischen den Systemen, über die das Customizing bzw. Entwicklungseinstellungen an die Systeme weiter gegeben werden, werden festgelegt. Bei Bedarf können Mandanten eingerichtet werden, was die Darstellung getrennter Unternehmen in einem SAP System ermöglicht.
3.1.2.3 KickOff Meeting
Sind die vorhergehenden Pakete vollständig abgearbeitet kann das Kickoff Meeting einberufen werden. Das Kickoff Meeting ist der offizielle Startzeitpunkt für das Projekt, es wird dem Unternehmen das Projekt vorgestellt. Dazu gehören die Ziele, sowie Aufgabenpläne und Prozesse. Teilnehmer des Meetings sind der Lenkungsausschuss, Berater, leitendes Management und die Projektleiter (interne und externe). Das Meeting dient der Motivation als auch der Organisation. Es werden Zuständigkeiten, Zeitpläne, Ziele und Rollen dargestellt. Zur Sicherstellung der unternehmensweiten Kommunikation sollte der Projektstart per Intranet, Email verbreitet werden. Nach dem Kickoff Meeting trifft sich das Projetteam zum Projektteamstandard-Meeting , hier werden die Projektstandards vorgestellt um eine einheitliche Darstellung von Informationen sicher zu stellen.
Siehe [10]
3.1.2.4 Planung der technischen Anforderungen
In diesem Arbeitspaket wird die Infrastruktur des zukünftigen SAP Systems festgelegt. Es wird anhand des Sollzustandes nach der Implementierung die erforderliche Hardware für die Entwicklungsumgebung festgelegt und eventuell beschafft. Für diese Bestimmung bietet ASAP ein Tool an, den SAP Quick Sizer. Durch das Sizing wird die nötige Hardwareausstattung des Systems bestimmt. Der SAP Quick Sizer ermittelt die benötigte CPU, Festplatte und RAM Ausstattung des Systems. Das Sizing wird beeinflusst durch:
- R/3 Version
- DB Version
- OS Version
- Hardware
- Anzahl Benutzer
- Menge an Berichte, Reports, Dialoge
- Customizing
Hier sollten zukünftige Entwicklungen, wie steigende Mitarbeiterzahlen, Erweiterungen auf neue Module und ähnliches Berücksichtigung finden. Die Hardware sollte dementsprechend erweiterbar gestaltet werden. Die Hilfe eines SAP erfahrenen Hardwarepartner kann Fehleinschätzungen vermeiden. Nach der Beschaffung ist das System mit dem SAP-Netz zu verbinden.
3.1.2.5 Qualitätsprüfung Phase 1
Das abschließende Paket Qualitätsprüfung, erfasst die vorherigen Pakete und prüft diese auf Vollständigkeit und Richtigkeit. Bei einem iterativen Vorgehen kommt dieser Überprüfung eine gewichtige Bedeutung zu. Fehler haben einen durschlagenden Effekt auf die folgenden Phasen. Die ASAP-Methodik wird auch durch diese Qualitätsprüfung am Ende jeder Phase gekennzeichnet. Die Phase schließt ab durch die Abnahme durch die Projektleitung.
Siehe [13]
3.1.3 Abgrenzung zur Standardmethode
Im Unterschied zum traditionellen SAP-Vorgehensmodell wird bei ASAP der Beginn des Projektes auf 2 Phasen ausgedehnt. Wo das traditionelle Vorgehensmodell nur einen Teil der ersten Phase für die Planung des Projektes vorsieht und spätestens in der zweiten Phase bereits mit der Realisierung begonnen wird, so sieht ASAP einen längeren Zeitraum von 2 Phasen für die grundlegende Planung vor.
Durch die in der ersten Phase weitgehend vom einzuführenden SAP System losgelöste Sichtweise, sondern stattdessen Konzentration auf die Etablierung der Projektinfrastruktur, kann späterer Zeitverlust durch Kommunikationsschwierigkeiten oder unklarer Kompetenzen vermieden werden. Definition allgemeingültiger Projektstandards, Projektabläufe oder der Rollenverteilung räumt das ASAP Vorgehensmodell elementare Bedeutung ein, dies bleibt bei Nutzung des traditionellen Vorgehensmodell hingegen den Erfahrungen des Projektleiter überlassen. Durch diese Weiterentwicklung des traditionellen Vorgehensmodells trägt ASAP der weiter steigenden Bedeutung des reinen Projektmanagementaspektes Rechnung.
3.2 Phase 2: Business Blueprint
3.2.1 Aufbau- und Ablauforganisation
Phase 2 wird charakterisiert durch Dokumentationen. In dieser Phase werden die Geschäftsprozesse, die sich in Aufbau-und Ablauforganisation wiederspiegeln durchleuchtet. Dies geschieht durch Befragungen, Workshops, Diskussionen oder Einzelgespräche. Nur bei einer detaillierten Dokumentation der bestehenden Geschäftsprozesse aus unterschiedlichen Sichten ist es möglich diese an das Referenzmodell von ASAP anzupassen. Es wird somit auch ein besseres Verständnis für die Funktionsweise des SAP Systems gebildet. Aus diesen Aktivitäten entsteht der Business Blueprint, ein Entwurf des zukünftigen SAP Systems. Er ist somit Grundlage für die weiteren Phasen und bildet das Grundgerüst des Projektes.
3.2.2 Arbeitspakete
3.2.2.1 Projektmanagement Phase 2
Hier wird festgelegt in welchen Abständen die erarbeiteten Geschäftsprozesse mit den beteiligten Abteilungen erörtert werden. Es wird auch die Art der Dokumentation festgelegt. Protokolle sind hier wichtig um den aktuellen Status festzuhalten. Diese Meetings geben auch den Projektteams eine Rückmeldung über den Fortschritt anderer Teams. Alles unter Berücksichtigung des Zeitplanes, Abweichungen können erkannt werden. Die Veröffentlichung des Projektplanes und somit der einzuhaltenden Meilensteine sind zur Orientierung der Teams zwingend erforderlich.
Der Lenkungsausschuss wird in regelmäßigen Meetings informiert, da nur dieser bei Abweichungen entsprechende Gegenmaßnahmen wie z.B. Veränderungen des Zeitplanes, Zuweisung von zusätzlichen Ressourcen gewähren kann.
Das allgemeine Projektmanagement unterstützt beim Change-Management, Bildung der Teams oder der Rollendefinitionen. Durch Anpassung der Geschäftsprozesse werden auch Anpassungen der Organisationsstruktur erfolgen. Frühzeitige Planung kann hier Widerstände und negative Einflüsse vermindern.
Siehe [16]
3.2.2.2 Schulung Projektteam
Ziel dieser Schulung ist ein Verständnis für Funktionen und Technik des SAP Systems zu schaffen. Nur wenn die Mitarbeiter das System kennen, können sie auch einen Blueprint erstellen. Es werden nur die Module geschult, die auch eingeführt werden. Die erlernten Kenntnisse werden durch den Teamleiter überprüft um einen homogenen Wissensstand zu erzielen.
Siehe [17]
3.2.2.3 Systemumgebung entwickeln
Das Entwicklungssystem wird in diesem Paket installiert und in Betrieb genommen. Die Qualitätssicherung für das Entwicklungssystem wird festgelegt und getestet. Dabei sind fünf Aktivitäten zu beachten.
- Entwurf des technischen Konzeptes: Unter Berücksichtigung der erstellten Prozesse und Funktionen wird die Infrastruktur des Systems bestehend aus Hardware, Betriebssystem, Datenbanken und Netzwerk entworfen. Die Kommunikation der Prozesse untereinander steht hier im Vordergrund, da Prozesse und Infrastruktur erst hier zusammengebracht werden. Das Konzept endet mit der Dokumentation der Systeminfrastruktur, Druckinfrastruktur und Netzwerkumgebung.
- Entwicklungsumgebung einrichten: Jetzt wird die technische Umgebung aufgebaut, Hardware wird installiert, Entwicklungsmandanten und Desktopsysteme für das Projektteam integriert, Benutzerstammsätze mit den erforderlichen Berechtigungen eingepflegt, ein Sicherungskonzept erstellt, um das System mit dem erarbeiteten Status bei Störungen wiederherstellen zu können, Druckdienste konfiguriert, sowie die Anbindung des Systems an das SAP-Net hergestellt.
- Systemlandschaft einstellen: Falls unterschiedliche Unternehmen auf ein System zugreifen können, müssen hierfür Mandanten eingerichtet werden. Es werden auch die Systemnamen aus dem Arbeitspaket (Projektabläufe Definition der Systemlandschaft) vergeben. Test des zuvor eingerichteten Entwicklungsmandanten sowie des Transportsystems finden statt.
- Systemadministration: Festlegung der Systemverwaltung, dazu wird ein Workshop für das Projektteam durchgeführt. Dieser soll die technische Systemumgebung sowie Systemwerkzeuge darstellen. Nach dem Workshop können die Prozeduren zur Systemadministration festgelegt werden, diese werden am Entwicklungssystem durchgeführt. Monitoring des Systems über ein CCMS (Computing Center Management System) kann Schwachstellen im laufenden Betrieb aufzeigen oder auch Verwaltungsaufgaben durchführen. Backupstrategien für das Entwicklungs-und Produktivsystem sind zu definieren. Test der Systemverwaltungsfunktionen und Abgleich mit dem Zustand des Entwicklungssystem um Veränderungen am Entwicklungssystem auszuschließen. Festlegung der Systemverwaltungstermine.
- Implementation Guide initialisieren: Dieser Guide hilft bei der Anpassung der Geschäftsprozesse an die ASAP-Referenzprozesse. Er dient gleichzeitig auch der Dokumentation.
3.2.2.4 Organisationsstruktur
In diesem Arbeitspaket werden die bestehende Unternehmensstrukturen und ihre Sprachwelt mit Hilfe der SAP-Ordnungsbegriffe (Buchungskreis, Verkaufsorganisationen…) nachgebildet. Dies kann in einem Workshop unter Beteiligung der Fachabteilungen erfolgen. Hier sind natürlich nur die betroffenen Unternehmensbereiche einzubeziehen. Erst wenn die SAP Sprache auf die Unternehmensstruktur angewandt wurde kann mit der Geschäftsprozessdefinition begonnen werden. Es ist wichtig dass die erstellte Struktur von allen Beteiligten verstanden und akzeptiert wurde.
Siehe [20]
3.2.2.5 Geschäftsprozessdefinition
Dieses Arbeitspaket unterteilt sich in sieben Aktivitäten:
- Geschäftsprozess Workshops vorbereiten: Da es sich um einen komplexen Bereich handelt, sind mehrere Workshops notwendig. Zu den Workshops sollten nur die erforderlichen Teilnehmer eingeladen werden, der Fokus des Workshops sollte nicht zu weit gefasst werden um effektive Workshops zu gewährleisten. Frühzeitige Einladungen und Versorgung mit den erforderlichen Materialien sind hier zielführend.
- Workshop für globale Anforderungen: Die Ermittlung globaler Parameter und Standards, hierzu zählen unter anderem ISO-Normen, Kalender, Währungen, Ländereinstellungen, sind wichtig um Konflikte zwischen den einzelnen Unternehmensbereichen zu vermeiden. Diese Standards stellen somit ein Grundgerüst für die folgenden Geschäftsprozesse dar.
- Geschäftsprozess Workshops: Sie bilden die Basis für den Business Blueprint. Inhalt sind Ermittlung von Geschäftsprozessanforderungen unter Mitwirkung einer Q&A Datenbank und dem SAP Referenzmodell. Für jeden Prozess wird ein Blueprintformular erstellt. Planung der Datenübernahme aus Altsystemen, dabei ist auf Konvertierungsprobleme zu achten. Wenn nötig, Erweiterungen für bestimmte Geschäftsprozesse definieren. Planung der anschließenden Detailanforderungsworkshops.
- Detailanforderungsworkshops: In diesen Workshops werden die Anforderungen an die Geschäftsprozesse detailliert mit dem Ziel der Vervollständigung des Blueprints.
- Es werden die Projektorganisation und die Rollen weiter konkretisiert, es kann sich z.B. ergeben, dass noch ein Geschäftsprozessverantwortlicher benötigt wird. Die Ergebnisse werden zusammengefasst um ein Rahmenkonzept zu erstellen. Der Baselineumfang wird ermittelt, d.h. die Prozesse die im Referenzmodell schon vorhanden sind und nicht angepasst werden müssen. Im Baseline-Anteil sollten sich die Unternehmensprozesse zu 80% abbilden. Die Vollständigkeit des Blueprints, als auch seine Konsistenz werden abschließend geprüft.
- Prüfung und Freigabe des Business Blueprint: In einer weiteren Sitzung wird der Blueprint von sämtlichen Teammitgliedern überprüft und freigegeben. Das Ergebnis sind die Prozessentwürfe, Unternehmensstruktur, Baseline Umfang, Technisches Konzept als auch die Systemlandschaft.
- Benutzerschulung planen: Die Benutzer sollten schon vor dem ersten Kontakt mit dem neuen System geschult werden, um Ablehnung des Systems zu vermeiden. Allerdings auch nicht zu früh um Lernverluste zu verringern. Es wird der Inhalt und Ablauf der Schulungen festgelegt.
3.2.2.6 Qualitätsprüfung Phase 2
Diese Phase wird auch wieder mit der Qualitätsprüfung und Abnahme abgeschlossen. Es wird auf Vollständigkeit und Richtigkeit des erarbeiteten Blueprint geprüft. Die Prüfung erfolgt durch den Projektleiter als auch durch eine externe Qualitätsprüfung. Der Blueprint stellt sicher dass alle Beteiligten sämtliche Elemente des Projektes in schriftlicher Form einsehen können und verstanden haben. Offene Aspekte müssen in diesem Arbeitspaket geklärt werden. Das können z.B. Änderung des Budgets, Zeitplanes oder der benötigten Ressourcen sein. Die Abnahme ist das Startsignal für die folgende Phase.
3.2.3 Abgrenzung zur Standardmethode
Phase 2 des ASAP Vorgehensmodell stellt den eigentlichen Einstieg in die Inhalte des Projektes dar und ist dadurch in weiten Teilen funktional identisch zur ersten Phase des traditionellen Vorgehensmodells. Phase 1 der ASAP Vorgehensweise ist also als der Kernpunkt der Weiterentwicklung des traditionellen Vorgehensmodells zu sehen. Weiterhin bedingt die ganzheitliche Sicht der ersten Phase auf den gesamten Projektzeitraum immanente Auswirkungen auf alle nachfolgenden Phasen.
Ausgelöst durch die ASAP Philosophie einer möglichst geringen Projektlaufzeit werden die Geschäftsprozesse eines Unternehmens den SAP Referenzprozessen angepasst, demgegenüber ermöglicht das traditionelle Vorgehensmodell die umgekehrte Vorgehensweise des Customizings der Software an die bestehenden Geschäftsprozesse. Basierend auf den Erkenntnissen vorangegangener traditioneller Implementierung war die SAP AG in der Lage ein Referenzmodell der grundlegenden, somit für die meisten Unternehmen identischen, Geschäftsprozessen zu entwickeln. Das ASAP-Modell opfert dementsprechend Flexibilität zugunsten beschleunigter Einführung. Die Entscheidung eines Unternehmens zur Anwendung des ASAP Ansatzes gründet somit auf der Bereitschaft die eigenen organisch gewachsenen Geschäftsprozesse durch externe Standardprozesse zu ersetzen.
Die weiteren Inhalte der zweiten ASAP Phase sind weitgehend deckungsgleich mit den Inhalten der ersten Phase des traditionellen Vorgehensmodells. Aber durch die im ASAP Model erst zu einen späteren Zeitpunkt avisierten Tätigkeiten wie Schulung der Projektbeteiligten oder Beschaffung eines ersten Testsystems, können die Maßnahmen bedarfsorientierter als in der frühen Phase des traditionellen Vorgehensmodell durchgeführt werden.
3.3 Phase 3: Realisierung
3.3.1 Baselineeinführung und Detailkonfiguration
In der Phase der Realisierung liegt der Schwerpunkt in der Einführung der, in der vorangegangenen Phase, definierten Prozess- und Geschäftsanforderungen. Phase 3 benötigt daher auch die meiste Zeit um die Geschäftsprozesse im System abzubilden und übergreifend Testen zu können, mit dem Ziel des Produktivbetriebes.
Die grobe Abbildung der Geschäftsprozesse, sowie deren Verknüpfungen, erfolgt in der Baseline-Konfiguration. Die feinere Abstimmung erfolgt im Anschluss im Rahmen der sogenannten Detail-Konfiguration.
Die Arbeiten am System erfolgen in Zusammenarbeit des Projektteams im Unternehmen mit externen SAP Beratern. Durch den entstehenden Know-How Transfer wird das Wissen im Projektteam gestärkt und verbleibt auch nach Abschluss des Projektes im Unternehmen.
3.3.2 Arbeitspakete
3.3.2.1 Projektmanagement Phase 3
Um einen optimalen Informationsfluss und somit ein möglichst reibungsloses vonstatten gehen des Projektes zu ermöglichen, sind auch in der Phase der Realisierung folgende Punkte zwingend durchzuführen.
- Abstimmungsmeeting:
Abstimmung des Projektstatus mit allen beteiligten Projektleitern, um ein für alle einheitliches Bild des Projektfortschritts zu zeichnen. In der Realisierungsphase ist weiterhin eine Abstimmung überschneidender oder notwendigen vorausgehenden Tätigkeiten zwischen den einzelnen Projektteams zu koordinieren.
Abschließend werden die erreichten Meilensteine oder eventuelle Abweichungen von der Projektplanung dokumentiert und die gesamte Projektplanung bei Bedarf aktualisiert und angepasst. Die aktualisierte Projektplanung mit den dokumentierten Absprachen und Änderungen dient allen Projektteams als weitergehender Leitpfaden.
- Lenkungsausschuss:
Die Versammlung der verantwortlichen Projektleiter trifft auf Basis des aktuellen Projektstatus die Entscheidungen, die im Rahmen der Projektteams nicht geklärt werden können. Übergreifende Entscheidungen wie die Erweiterung der eingesetzten Ressourcen oder Terminverschiebungen können nur durch den Lenkungsausschuss getroffen und vertreten werden.
- Ausgangsplanung Produktionssupport und Cut-Over:
Die Planung für den benötigten Support, beginnend mit dem Cut-Over zum neuen SAP System, sollten bereits zu Beginn der dritten Phase gestartet werden. Umfassend und frühzeitig muss das benötigte Personal, Infrastruktur und die Prozeduren, z.B. für den Help Desk oder den technischen Cut-Over, geplant werden, damit alles bei Bedarf bereit steht und über das benötigte Wissen zur Durchführung verfügt.
- Allgemeines Projektmanagement:
Als umfassende Instanz während der Einführung des SAP Systems unterstützt das allgemeine Projektmanagement die Arbeit der einzelnen Projektteams. In Form von teambildenden Aktivitäten oder der Abwicklung des Change Managements wird die weitere Projektplanung realisiert.
Siehe [27]
3.3.2.2 Schulung Projektteam
Zur Vermittlung weitergehender technischer und funktionaler Kenntnisse, werden in diesem Arbeitspaket Schulungen für die Mitglieder der Projektteams durchgeführt. Der Erfolg muss in Form von Tests abgeprüft werden, somit kann die Bereitschaft der Projektteams für die kommenden Aufgaben sichergestellt werden.
Siehe [28]
3.3.2.3 Baseline-Konfiguration und -Abnahme
Die Baseline-Konfiguration umfasst die Abbildung aller Geschäftsprozesse und -prozeduren im neuen SAP System, welche einen viralen Bestandteil der Wertschöpfungskette des Unternehmens darstellen. Diese Beschränkung stellt sicher, dass die wichtigsten Geschäftsprozesse schnell eingeführt werden können. Die Definition dieser Geschäftsprozesse ist bereits in Phase 2 Business Blueprint erfolgt.
Die zuerst einzuführenden Geschäftsprozesse und die Reihenfolge der Einführung werden in einem Konfigurationsplan festgelegt. Zusätzlich werden Testszenarien zur Prüfung der Baseline ausgearbeitet, die Testszenarien sind die Grundlage für einen späteren großen Testplan. Konfigurations- und Testplan ergeben zusammen den Implementation Guide, welcher Personen oder Projektteams zur Durchführung zugeordnet wird.
Zu Beginn der Implementierung der Baseline im SAP System muss die im Business Blueprint festgelegte Organisationsstruktur im System abgebildet werden. Hierzu müssen die benötigten Stammdaten wie z.B. Organisationseinheiten, Buchungskreise oder Werke angelegt werden, denn diese Strukturen und Stammdaten sind zur Implementierung der Geschäftsprozesse die Vorrausetzung.
Falls bei der weitergehenden Implementierung der primären Geschäftsprozesse Probleme bzw. Fehler im zugrunde liegenden Business Blueprint auftauchen, so muss der Business Blueprint erweitert oder korrigiert werden. Die Korrekturen sind zu Dokumentieren und umzusetzen.
Abschließend ist anhand des zuvor aufgestellten Konfigurationsplans die Vollständigkeit der Prozesse im System zu prüfen und anhand der Testpläne zu verifizieren. Wenn die Testszenarien einen konsistenten Ablauf der Geschäftsprozesse ergeben, ist die Baseline-Konfiguration für die Abnahme bereit. Die Abnahme bestätigt die Baseline-Konfiguration und somit die implementierten Geschäftsprozesse im SAP System.
3.3.2.4 Systemadministration
Die Definition und den Aufbau des Monitoring und der Verwaltung der Produktivinfrastruktur im technischen Sinne hat dieses Arbeitspaket als Ziel.
Vorbereitend für die Einrichtung und Administration des Produktivsystems in der folgenden Phase müssen Testpläne aufgestellt werden. Getestet werden unter anderem der Durchsatz sämtlicher Komponenten, die Leistung von Druckern oder Faxgeräten, etc. Zusätzlich muss durch eine tägliche Kontrolle die Betriebssicherheit des SAP Systems sichergestellt werden, hierzu zählt auch die Schaffung eines Sicherungsverfahrens (Backup- und Recovery Verfahren).
Weiterhin zählt der Abschluss von Service-Level-Agreements für das SAP System zum Umfang des Arbeitspaketes. Die Abkommen werden auf Basis von Szenarien zum teil- oder vollständigen Ausfall des Systems oder benötigter Desaster-Recovery-Verfahren eingerichtet. Ziel ist es negative Auswirkungen auf das zukünftige Produktivsystem vermeiden oder möglichst kurzfristig halten zu können.
Um das gesamte Feld der Systemadministration effizient abarbeiten zu können, müssen die Mitarbeiter in den Prozessen und den zur Verfügung stehenden Werkzeuge und Hilfsmittel ausreichend geschult werden.
- Qualitätssicherungsumgebung:
Zur Vorbereitung des Produktivbetriebes muss die benötigte Systemumgebung für die Qualitätssicherung eingerichtet werden. Hierzu zählt die technische Einrichtung der neuen Hardware genauso wie die Softwareinstallation und die Einrichtung des SAP Systems.
Das System der Qualitätssicherung ist das zweite benötigte SAP System. Alle in der Entwicklungsumgebung erzeugten, parametrierten oder programmierten Prozesse, Abläufe und ähnliches müssen den Test in der Qualitätssicherung erfolgreich absolvieren, bevor diese in das Produktivsystem übernommen werden. Durch die Instanz der Qualitätssicherung soll eine weitgehende Fehlerfreiheit des Produktivsystems sichergestellt werden. Bei auftretenden Fehlern müssen diese zuerst im Entwicklungssystem korrigiert werden, bevor sie nach einem weiterem Test in der Qualitätssicherungsumgebung ihren Weg ins Produktivsystem finden.
Um das Qualitätssicherungssystem nutzbar zu machen, muss dieses identisch zum späteren Produktivsystem konfiguriert werden. Weiterhin müssen minimal Stammdaten für für das Qualitätssicherungsteam angelegt und berechtigt werden. - Produktivumgebung:
Weiterer Bestandteil der Realisierungsphase ist neben der Installation des Qualitätssicherungssystems auch der Aufbau des endgültigen Produktivsystems. Auch hier zählt sowohl die Einrichtung der Hardware wie auch der Software zur Installation.
Da das Produktivsystem wesentlich performanter sein muss, als das Entwicklungs- oder Qualitätssicherungssytem, muss im Vorlauf eine realistische Systemkonfiguration auf Basis des zuvor entwickelten Business Blueprint und den darin dokumentierten Anforderungen erarbeitet werden. Wo das Entwicklungs- oder Qualitätssicherungssystem jeweils nur durch eine begrenzte Anzahl von Mitarbeiter genutzt wird, so muss das Produktivsystem der Belastung des Tagesgeschäftes stand halten und entsprechend dimensioniert werden.
Bei der Einrichtung des Produktivsystems müssen zusätzlich folgende Punkte berücksichtigt werden:
- Erweiterung und Sicherstellung der Verfügbarkeit der Netzwerkinfrastruktur
- Installation oder Upgrade der Hardware der Anwender
3.3.2.5 Detail-Konfiguration und -Abnahme
Zur Erweiterung der Baseline-Konfiguration wird die Detail-Konfiguration durchgeführt. Die Detail-Konfiguration umfasst alle Geschäftsprozesse die bei der Baseline-Konfiguration nicht implementiert, aber im Business Blueprint dokumentiert, worden sind. Weiterhin kann die Detail-Konfiguration die Erweiterung bestehender Prozesse umfassen.
Die Detail-Konfiguration wird in mehreren Zyklen durchgeführt, bis alle Anforderungen des Business Blueprint erfüllt sind. Jeder Zyklus kann als Meilenstein des Projektes angesehen werden, er ermöglicht es z.B. einen bestimmten Teil eines Geschäftsprozesses zu implementieren und getrennt zu testen. Folgende Aktivitäten beinhaltet jeder Zyklus:
- Konfigurationsplan für die beabsichtigten Erweiterungen aufstellen
- Erstellung eines Testplan mit Testfällen für den Detailumfang
- Aufteilung der Aktivitäten auf entsprechende Projektteams (Ressourcen)
- Konfigurationsworkshop
- Durchführung der Detail-Konfiguration
- Abnahme der Detail-Konfiguration durch Qualitätssicherung
Die Implementierung während der Zyklen wird durch den SAP Implementation Assistent unterstützt. Dieser bietet in Form von How-To's Zugriff auf das bisher durch SAP bei der Implementierung gesammeltes Wissen.
Zur Sicherstellung das alle Anforderungen an das neue SAP System auch korrekt abgedeckt werden, werden die Feinheiten in Ergänzung zum grundlegenden Business Blueprint in Form von Konfigurationsworkshops durchgeführt. Hier werden die Entscheidungen zur Behebung eventueller Diskrepanzen oder Problemen getroffen und dokumentiert.
Abschließend, nach Durchführung aller zur Detail-Konfiguration benötigten Zyklen, wird eine Gesamtabnahme der Detail-Konfiguration durchgeführt. Hier wird die Vollständigkeit und Korrektheit der Implementierung der Geschäftsprozesse bestätigt und dokumentiert. Gleichzeitig werden hierdurch die Prozesse durch alle Beteiligten als verstanden und akzeptiert angenommen.
Siehe [33]
3.3.2.6 Datenkonvertierung
Bei der Einführung eines SAP Systems besteht in aller Regel ein oder mehrere Vorgängersystem die durch das neue SAP System abgelöst werden sollen. Hierbei stellt sich das Problem der Altdatenübernahme.
In diesem Arbeitspaket werden Verfahren und Programme zur Übernahme dieser Altdaten entwickelt, getestet und validiert. Übertragen werden müssen unter anderem Stammdaten wie Produkte, Mitarbeiter, Debitoren (Kunden) oder Kreditoren (Lieferanten). Weiterhin können z.B. Bewegungsdaten wie die Bestellhistorie oder der aktuelle Lagerbestand Gegenstand einer notwendigen Altdatenübernahme sein.
Ziel sollte immer eine weitgehend automatische Übernahme sein, wenn möglich über kompatible Schnittstellen zwischen dem Altsystem und SAP, ansonsten über die Eigenentwicklung eines Konvertierungsprogramms. Wo die automatisierte Übernahme nicht möglich ist müssen Verfahren einer manuellen Übernahme entwickelt werden. Sowohl Programme als auch Verfahren sind abschließend auf ihre Qualität zu testen.
Eingebettet werden die Programme, Verfahren oder die Kombination aus beidem in einem Plan zur Datenübernahme. Durchgeführt wird die Übernahme auf dem Entwicklungssystem. Bei erfolgreicher Validierung der Übernahme durch einen Integrationstest werden die Programme und Verfahren auf das System der Qualitätssicherung und das Produktivsystem übernommen und stehen somit für Übernahme der Produktivdaten zum Echtbetrieb bereit.
Siehe [34]
3.3.2.7 Schnittstellenentwicklung
Für bestehende Systeme, welche einen Bereich im Unternehmen abdecken der nicht im Funktionsumfang von SAP enthalten ist, müssen Anwendungsschnittstellen definiert werden.
Wo möglich sollten zertifizierte Schnittstellen verwendet werden. Bei diesen standardisierten Schnittstellen ist eine Interoperabilität und Korrektheit der übertragenen Daten bereits durch den Zertifizierungsprozess sichergestellt. Wo keine entsprechenden Schnittstellen existieren müssen eigene Schnittstellenprozesse definiert und implementiert werden. Hier ist darauf zu achten das eine möglichst homogene Schnittstellenlandschaft erstellt wird, da für jede individuelle Schnittstelle Punkte wie Verwaltung und Sicherheit zu beachten sind. Alle neu erzeugten Schnittstellen sind im Vorfeld zusammen mit der jeweiligen Fachabteilung detailliert zu definieren und zu dokumentieren.
Ebenso wie bei der Datenkonvertierung werden die Schnittstellen im Entwicklungssystem implementiert, in der Qualitätssicherungsumgebung einem Integrationstest unterzogen und bei Erfolg in das Produktivsystem eingebracht.
3.3.2.8 Erweiterungen, Reports und Formulare
An Stellen wo das Angebot des Standard SAP Funktionsumfang die Anforderungen des Unternehmens nicht oder nicht ausreichend abdeckt ist Raum für individuelle Erweiterungen. Erweiterungen können kundenspezifische Erweiterungen von bestehenden SAP Funktionen sein, können aber auch gänzlich neue Programme oder Reports sein.
Erweiterungen sollten folgender Vorgehensweise unterliegen:
- Ausarbeitung einer detaillierten Definition
- Erweiterungen durch die Projekt- oder Geschäftsleitung genehmigen lassen
- Implementierung
- Testplan erarbeiten und durchführen
- Abnahme der Erweiterung durch die betroffene Fachabteilung
Der Testablauf für Erweiterungen ist ähnlich dem Test von Schnittstellen oder Programmen zur Datenkonvertierung. Nach Implementierung auf dem Entwicklungssystem Abnahme auf der Qualitätssicherungsumgebung und Transfer auf das Produktivsystem.
3.3.2.9 Berechtigungskonzept
In diesem Arbeitspaket steht die Erstellung eines tragfähigen Berechtigungskonzeptes für das SAP System im Mittelpunkt. Ein Berechtigungskonzept muss Anforderungen wie höchstmögliche Sicherheit/Datenschutz, einfache Wartbarkeit oder die Bereitstellung der minimal und maximal je Arbeitsplatz benötigten Rechte gewährleisten. Im Berechtigungskonzept sollten Zuständigkeiten auf Basis der Organisationsstruktur, also z.B. von Abteilungen bis hin zu einzelnen Mitarbeiter, abgebildet werden.
Zur bedarfsgerechten und praxisorientierten Erzeugung des Berechtigungskonzepts müssen zuvor alle Zuständigkeiten und Berechtigungen detailliert dokumentiert werden. Die Definition der Berechtigungen sollte bis auf Arbeitsplatzebene, also bis zur untersten Ebene des Organigramms, erfolgen. Diese Definition kann nur in Zusammenarbeit mit den jeweiligen Abteilungen erfolgen. Dieses Vorgehen soll sicherstellen dass alle benötigten Zugriffsberechtigungen vorhanden sind, aber gleichzeitig alle Sicherheitsanforderungen erfüllt werden. Neben der Festlegung für den Zugriff auf bestimmte Funktionen und Daten des SAP Systems, muss auch der Zugriff auf verschiedene Drucker oder Faxgeräte berücksichtigt werden.
Bei der Implementierung des Berechtigungssystems in das neue SAP System unterstützt der SAP Profilgenerator. Der Profilgenerator setzt auf durch das Berechtigungskonzept definierten Aktivitätsgruppen auf. Aktivitätsgruppen definieren alle Berechtigungen die gleichartige Aktivitäten, z.B. für bestimmte Arbeitsplätze, benötigen. Auf Basis dieser Aktivitätsgruppen erzeugt der Profilgenerator zugehörige Berechtigungsprofile in SAP.
Nach Definition und Implementierung des Berechtigungskonzepts muss dieser sensible Bereich eingehend und detailliert getestet werden. Hierzu muss für jeden Benutzer bzw. für die von ihm zu erfüllende Aufgabe ein Benutzerstammsatz erzeugt und entsprechend berechtigt werden. Nur so ist sicher zu stellen das die Ausübung aller Funktionen, Transaktion, Programme und Berichte im Rahmen der Geschäftsprozesse möglich und alle hierfür benötigten Daten zur Verfügung stehen. Gleichzeitig ist sicherzustellen das kein unautorisierter Zugriff möglich ist.
Abschließend ist das Berechtigungskonzept durch die Geschäftsleitung abnehmen zu lassen.
3.3.2.10 Archivierung
Zur Erhaltung der Leistungsfähigkeit des SAP Produktivsystems ist es unerlässlich eine Archivierungsstrategie festzulegen. Ziel ist ein Gleichgewicht aus möglichst geringem Datenbestand und der für den täglichen Betrieb online benötigten Daten, welches gleichzeitig höchstmöglichen Durchsatz und Performance des Produktivsystems gewährleistet. Ebenfalls zu Berücksichtigen sind gesetzliche Vorgaben oder die Anforderungen von Konzernrichtlinien zur Datenanalyse.
Nach Definition der Anforderungen an ein Archivierungskonzept kann dieses implementiert und getestet werden.
3.3.2.11 Integrationstest
Der Integrationstest am Ende der Realisierungsphase dient dem Test aller Komponenten des zukünftigen Produktivsystems, der Integrationstest simuliert also den Produktivbetrieb des SAP Systems. Alle in dieser Phase implementierten Komponenten wie Konvertierungsprogrammen, kundespezifische Erweiterungen oder auch das Berechtigungskonzept werden beim Integrationstest zum ersten Mal in der endgültigen Kombination getestet.
Der Inhalt des Integrationstestplans ist weitgehend bereits in den vorangegangenen Arbeitspaketen festgelegt worden. Am Ende eines jeden Arbeitspaketes wurde ein Testplan mit Testfällen erstellt, welche jetzt durchlaufen werden. Zusätzlich liegt das Augenmerk beim Integrationstest auf dem Test der im Business Blueprint definierten Geschäftsprozesse, die jetzt als ganzheitliches System durchlaufen und getestet werden können. Bei auftretenden Fehlern müssen diese behoben und die Testfälle erneut durchlaufen werden.
Zur Unterstützung des Integrationstests steht das Tool SAP CATT (Computer Aided Test Tool) zur Verfügung.
Nach Abschluss des Integrationstest wird das Qualitätssicherungssystem, auf welchem der Test durchgeführt wurde, gesperrt. So wird verhindert dass am getesteten System weitere Änderungen vorgenommen werden, dies betrifft sowohl die Parametrierung des Systems als auch alle Erweiterungen wie Programme oder Berichte. Das gesamte System steht nun bereit zur Übernahme in die Produktivumgebung.
Alle Ergebnisse des Integrationstest müssen durch die Projektleitung und die Geschäftsleitung abgenommen werden. Diese Abnahme bestätigt das das neue SAP den Anforderungen des Unternehmens entspricht.
Siehe [41]
3.3.2.12 Benutzerdokumentation und -schulung
Bis zu diesem Zeitpunkt ist das neue SAP System nur dem Projektteam bekannt. Die Fachabteilungen bzw. die zukünftigen Nutzer des Systems hatten bisher kaum Berührungspunkte mit dem neuen System. Um den Nutzern den Einstieg zu erleichtern muss in diesem Arbeitspaket eine Anwenderdokumentation und Online-Hilfe für das SAP System erstellt werden.
Schwerpunkt der Anwenderdokumentation ist die Beschreibung der unternehmensbezogenen Geschäftsprozesse und deren Durchführung im SAP System, dabei sind die individuellen Anforderungen der zukünftigen SAP Anwender im Unternehmen zu berücksichtigen. Eine allgemeine Dokumentation zur Bedienung steht seitens SAP zur Verfügung und kann in die unternehmensspezifische Dokumentation integriert werden.
Sobald die Anforderungen an die Dokumentation klar sind muss das SAP Projektteam im Rahmen eines Workshops Standards für die Dokumentation erarbeiten. So wird eine einheitliche Struktur der Dokumentation sichergestellt. Weiterhin werden hier die Verantwortlichkeiten zur Erstellung der Dokumentation vergeben.
Für die Zukunft ist eine fortlaufende Aktualisierung der Anwenderdokumentation einzuplanen.
Sobald eine grundlegende Anwenderdokumentation besteht, muss die Schulung der Endanwender vorbereitet werden. Hierzu müssen die Präsentationmaterialen zusammengestellt und bei Bedarf weitere spezielle Unterlagen für die Benutzerschulung (z.B. Übungsaufgaben) zusammengestellt werden. Auch alle Belange der Organisation wie die Reservierung von Räumlichkeiten, Zuweisungen der Dozenten und Einladungen an die Nutzer werden bereits abgearbeitet. Die letztendlich Durchführung der Anwenderschulungen findet in Phase 4 statt.
Siehe [42]
3.3.2.13 Qualitätsprüfung Phase 3
Als abschließendes Arbeitspaket der Realisierungsphase wird eine Qualitätsprüfung durchgeführt. Diese Qualitätsprüfung soll sicherstellen das alle Ziele der Phase erreicht und somit alle Anforderungen des Business Blueprint erfüllt worden sind. Alle erarbeiteten Informationen werden nochmals auf Vollständigkeit und Richtigkeit geprüft.
Nur wenn die Phase durch die Projektleitung abgenommen worden ist, kann das Projekt in die nächste Phase der Produktionsvorbereitung eintreten.
3.3.3 Abgrenzung zu Standardmethode
Phase drei des ASAP Modells ist bezogen auf die durchzuführenden Tätigkeiten nahezu identisch zur zweiten Phase des traditionellen Vorgehensmodells.
Die Weiterentwicklung liegt schwerpunktmäßig im Aspekt des originären Projektmanagements. Im Unterschied zur traditionellen Einführungsmethode beginnt ASAP die Phase mit einem Arbeitspaket zur Sicherung des Informationsflusses zwischen allen Projektbeteiligten. Dies soll Projektverzögerung aufgrund von Informationsdefiziten vorbeugen. Diese Ausrichtung trägt potentiell auftretenden Problemen bei der Anpassung der Geschäftsprozesse auf das SAP Referenzmodell Rechnung. Beispielsweise soll durch die Implementierung eines Change Management als Instanz des Projektmanagements die Auswirkungen des ASAP Ansatzes auf die Organisationsstruktur gering gehalten werden.
Die Konzentration auf das Projektmanagement an sich setzt sich bei Nutzung des ASAP Ansatzes durch alle Phasen fort. Jede Phase beginnt und endet mit einer Instanz des Projektmanagements zum Zwecke der Kontrolle und Steuerung des Gesamtprojekts. Im Gegensatz zum traditionellen Vorgehensmodell ist diese Vorgehensweise fest in der ASAP Roadmap verankert. Für Einsteiger in das Projektgeschäft ergibt sich dadurch automatisch ein regelmäßiger Überblick über den Stand des gesamten Projekts. Es besteht nicht die Gefahr des Verlustes der Übersicht wie beim traditionellen Modell der SAP Einführung, wo eigenverantwortlich für den planmäßigen Projektverlauf gesorgt werden muss. Dies ist grade für ein Einsteiger in dieses Thema eine Erleichterung, die beim traditionellen Modell nur durch die Einbeziehung erfahrener externer Berater kompensiert werden kann.
Weniger Weiterentwicklung als Optimierung der weitgehend identischen Arbeitspakete, stellt der Aspekt der sogenannten Accelerators in ASAP gegenüber dem traditionellen Vorgehensmodell dar. Unter anderem ermöglicht z.B. der SAP Profilgenerator eine beschleunigte Implementierung des Berechtigungskonzeptes. Die Accelerators bieten für wiederkehrende Tätigkeiten in Projekten Unterstützung, was in Hinblick auf die beabsichtigte kürzere Projektlaufzeit gegenüber dem traditionellen Vorgehensmodell einen Zeitvorteil verspricht.
3.4 Phase 4: Produktionsvorbereitung
3.4.1 Feinabstimmung
Die letzte Phase vor dem Echtbetrieb des neuen SAP Systems wird zur Feinabstimmung genutzt, hier werden die letzten Parametrierungen und Systemtests vorgenommen. Begleitend werden Mitarbeiter geschult und die aktuellen Geschäftsdaten ins System übernommen. Ziel ist die Übergabe des SAP Systems zur Nutzung an die Fachabteilungen.
3.4.2 Arbeitspakete
3.4.2.1 Projektmanagement Phase 4
Der kritische Faktor der termingerechten Umsetzung des Projektes in dieser Phase ist durch das Projektmanagement besonders stark zu gewichten. Aus diesem Grunde sind folgende Punkte erneut akribisch durchzuführen.
Abstimmung des Projektstatus und etwaiger Anpassung mit allen beteiligten Projektteams.
Die Abstimmung versorgt alle Projektteams mit den aktuellsten Informationen und deckt Probleme in Form von Projektabweichungen auf. Bei schwerwiegenderen Problemen, welche das Erreichen von Meilensteinen oder gar den Termin zum Go-Live gefährden, muss korrigierend eingegriffen werden. Der aktuelle Status mit Absprachen und Änderungen muss protokolliert und im Anschluss allen Beteiligten zugänglich gemacht werden. Dieser Projektplan ist die Grundlage für das weitere Handeln der Projektteams und dient der Visualisierung des Projektstatus.
- Lenkungsausschuss:
Die Versammlung der verantwortlichen Projektleiter trifft auf Basis des aktuellen Projektstatus die Entscheidungen, die im Rahmen der Projektteams nicht geklärt werden können. Übergreifende Entscheidungen wie die Erweiterung der eingesetzten Ressourcen oder Terminverschiebungen können nur durch den Lenkungsausschuss getroffen und vertreten werden.
- Allgemeines Projektmanagement:
Als umfassende Instanz während der Einführung des SAP Systems unterstützt das allgemeine Projektmanagement die Arbeit der einzelnen Projektteams. In Form von teambildenden Aktivitäten oder der Abwicklung des Change Managements wird die weitere Projektplanung realisiert.
- Anwenderdokumentation:
Zum Start des SAP Systems muss zwingend eine handhabbare Anwendungsdokumentation zur Verfügung stehen. Die Erstellung und Pflege dieser Dokumentation sind ein entscheidender Faktor für die Akzeptanz des Systems durch dessen Benutzer. In der Anwenderdokumentation sind die zur Umsetzung der Unternehmensprozesse notwendigen Arbeitsschritte, sowie die jeweiligen Zuständigkeiten dokumentiert.
Siehe [47]
3.4.2.2 Benutzerschulung
Eine allgemeine SAP Schulung, sowie eine auf die Geschäftsprozesse und die betroffenen Mitarbeiter abgestimmte Schulung soll die Einsatzfähigkeit des Systems zum Zeitpunkt des Echtbetriebes sicherstellen. Hierzu sind die Schulungen zeitnah zum GoLive zu terminieren. Die Schulung muss auf Basis von aktuellen Schulungsunterlagen durch einen besonders geschulten SAP-Spezialisten durchgeführt und abgeprüft werden. Durch die Abprüfung kann die Einsatzfähigkeit der Mitarbeiter im Rahmen des Produktiveinsatzes beurteilt und bei Bedarf weiter geschult werden.
3.4.2.3 Einrichtung Administration des Produktivsystems
Zur Gewährleistung maximaler Verfügbarkeit und Performance muss vor Produktivstart die Administration des Produktivsystems eingerichtet werden. Mit Hilfe des SAP Computing Center Management System (CCMS) kann der aktuelle Zustand des Produktivsystems überwacht, gesteuert und konfiguriert werden. In Form von Workshops und Schulungen muss das Personal im Umgang mit dem CCMS geschult, sowie auf weitere Aufgaben wie die Fehlersucher oder die Benutzerverwaltung vorbereitet werden.
3.4.2.4 Systemtests
Als wichtigstes Arbeitspaket vor dem Echtbetrieb ist abschließend ein Systemtest des gesamten Produktivsystems durchzuführen, nur so kann die Datensicherheit gewährleistet werden.
Folgende Systemtests sind spezifiziert:
- Durchsatztest:
Deckt eventuelle Verbesserungspotentiale im Bezug auf die System Performance bei Nutzung aller zur Verfügung stehender SAP Prozesse auf. - Stresstest:
Prüfung ob das Produktivsystem die gleichzeitige Ausführung alle spezifizierten Geschäftsprozesse ermöglicht. - Systemadministrationstest:
Test der erarbeiteten Systemadministrationsprozesse. - Disaster-Recovery-Plan:
Prüfung der Prozeduren für den Schadensfall. Bei Outsourcing kann in diesem Rahmen die Effektivität des externen Unternehmens geprüft werden. - Backup- und Restoreverfahren:
Test der Prozeduren zur Reaktion auf verschiedenste Datenzerstörungsszenarien wie Festplattendefekte oder versehentliches Löschen von Daten durch Anwender. - Druck- und Faxfunktion:
Die Verwaltungsprozeduren auf Basis der Unternehmensanforderungen sind zu testen. - Going-Live-Check:
Externer Check des Produktivsystems durch die SAP AG selbst. Per Fernwartung prüfen Spezialisten von SAP das System und geben Hinweise zur Systemoptimierung.
Siehe [52]
3.4.2.5 Cut-Over Planung
Die Planung zur Endgültigen Inbetriebnahme des SAP Systems bedarf zwingend der Genehmigung durch die Geschäftsleitung. Vorbereitend hierzu müssen die in der Realisierungsphase aufgestellten Cut-Over-Pläne überprüft und bestätigt werden, eine Checkliste zur Übernahme der Produktivdaten erstellt und somit die Produktionsbereitschaft festgestellt werden.
Bei der Planung des Cut-Over ist der Zeitpunkt entscheidend. Um den Aufwand möglichst gering zu halten sollte der Cut-Over mit dem Ende eines Geschäftsjahres zusammenfallen, so kann vermieden werden das Daten aus verschiedenen Systemen zum Jahresabschluss zusammengeführt werden müssen.
3.4.2.6 Produktionssupport
Parallel zur Cut-Over Planung muss der Helpdesk eingerichtet werden. Dies Umfasst die Definition von Help-Desk-Prozessen, die Schulung der entsprechenden Mitarbeiter, sowie die Benennung des Teams für den Produktionssupport in den ersten Wochen nach dem Cut-Over. Weiterhin steht die Festlegung der zukünftigen Support-Strategie an, damit externer Support für zukünftige Systemänderungen oder Release-Wechsel zur Verfügung steht.
Siehe [53]
3.4.2.7 Cut-Over
Nach Abschluss aller Vorbereitungen, technischer-, organisatorischer- oder anwendungsbezogener Art, wird die Genehmigung des Produktivstarts durch den Lenkungsausschuss erteilt. Daraufhin wird das Produktivsystem durch Übernahme der Datenbestände aus Altsystemen erzeugt und erneuten Stresstests unterzogen. Nur wenn die Stresstests erfolgreich absolviert, die Benutzerschulungen durchgeführt und die Geschäftsprozesse nochmals überprüft worden sind kann die abschließende Qualitätsprüfung vorgenommen werden. Wenn die Vollständigkeit und Richtigkeit aller Information sichergestellt ist, bestätigt das Projektmanagement die Abnahme des Systems. Zusätzlich wird ein Testat vom zuständigen Wirtschaftsprüfer für die Abnahme benötigt. Hierbei ist zu berücksichtigen dass bei der Altdatenübernahme aufgetretene Fehler zeitaufwendig manuell korrigiert werden müssen.
Das Projekt geht in die letzte Phase des GoLive.
3.4.3 Abgrenzung zur Standardmethode
Da das ASAP Modell eine Weiterentwicklung der traditionellen Einführungsmethode darstellst, sind die Inhalte der Phasen der Produktionsvorbereitungen zwischen den beiden Modellen äquivalent.
Bezeichnend für das ASAP Modell ist aber auch hier die Einrichtung eines allgemeinen Projektmanagements zu Phasenbeginn. Alle Determinanten des Projektes Zeit, Kosten und Qualität (Magisches Dreieck) werden erneut im Rahmen der Projektbeteiligten abgestimmt.
3.5 Phase 5: GoLive und Support
3.5.1 Produktionsstart und Optimierung
In dieser Phase wird das SAP System im produktiven Betrieb Überwacht und Optimiert. Optimiert wird sowohl die technische Leistungsfähigkeit des Systems, wie auch die Geschäftsprozesse. Weiterhin ist in dieser Phase ein solider Benutzer-Support eminent wichtig, um die grade zu Beginn gebündelt auftretenden Fragen der Benutzer effizient zu klären.
3.5.2 Arbeitspakete
3.5.2.1 Produktionssupport
Um die Akzeptanz des neuen SAP Systems durch die Mitarbeiter zu entwickeln und zu fördern ist ein starker Benutzer-Support von strategischer Bedeutung. Grade in den ersten Tagen und Wochen des produktiven Betriebs wird aufgrund des ungewohnten Systems und eventuell neuen Geschäftsprozessen der Bedarf an Unterstützung hoch sein. Nur wenn Support kurzfristig und effizient geleistet wird, wird das System von den Mitarbeitern positiv angenommen.
Sowohl der in den ersten Tagen auftretende kurzfristige, wie auch der langfristige Support lassen sich in 2 Kategorien aufteilen:
- interner Support:
Der interne Support ist für die betriebsbedingt auftretenden Probleme zuständig. Nur eine Schulungsmannschaft bestehend aus eigenen Mitarbeitern kennt die internen Prozessabläufe und kann problemlösend eingreifen, wo externe Berater zuerst in unbekannte Abläufe einsteigen müssen. - externer Support:
Der externe Support wird von SAP bereitgestellt und beinhaltet folgende Komponenten:
- Online Service System (OSS):
Kommunikationsnetzwerk zwischen dem Unternehmen, den SAP-Partnern und SAP selbst. Es stellt die Möglichkeit für das Unternehmen zur Verfügung Problemanfragen z.B. per Internet an SAP weiterzuleiten und den Lösungsprozess zu verfolgen. Weiterhin stehen Lösungen zu Bekannten Problemen zum Abruf bereit. - Remote Consulting Service:
Persönliche Unterstützung bei Problemen durch einen SAP Berater. Per Fernwartung kann dieser direkt im SAP System des Unternehmens gemeinsam mit dem Kunden an einer Lösung arbeiten. - EarlyWatch Service:
SAP überwacht pro aktiv alle relevanten Systemkomponenten des SAP Systems des Unternehmens. Durch diese aktive Systemdiagnose können potentielle Probleme rechtzeitig erkannt und gelöst werden.
Siehe [56]
3.5.2.2 Geschäftsprozessüberprüfung im Produktionssystem
Zu Beginn des Produktivbetriebs ist eine Überprüfung und Bestätigung der Transaktionen auf dem System zu tätigen. Hierzu sollten laufende Transaktionen über einen bestimmten Zeitraum beobachtet und die Ergebnisse aus dem SAP System mit den eigenen vergleichen. Hierdurch wird das gesamte SAP System bestätigt und kann vom Projektteam abgenommen werden.
3.5.2.3 Aktivitäten nach dem GoLive
Zu den Aktivitäten nach Aufnahme des produktiven Betriebes zählen:
- Weitere Überprüfung der Systemleistung:
Deckt sich der im Vorfeld geschätzte Ressourcenbedarf des Systems mit der Wirklichkeit. Können weitere Optimierungen die Systemleistung positiv beeinflussen. - Bedarf an weiteren Schulungen decken:
Hierzu können Follow-Up Schulungen für fortgeschrittene Nutzer oder auch die Schulung neuer Benutzer zählen. - Langfristige Supportstrategie festlegen:
Um zukünftige Release-Wartungen und -Wechsel planbar zu machen. Über einen detaillierten technischen Upgrade-Plan kann die technische Landschaft an die Gegebenheiten angepasst oder weitere Prozessanforderungen umgesetzt werden. Zu einem Update oder Upgrade gehören folgende Positionen:
- Systemwartung, Einspielen von Korrekturen und Verbesserungen an der grundlegenden SAP Software.
- Release-Wechsel, der Einsatz von neuen oder erweiterten Komponenten des SAP Systems.
- Datenbank Upgrade
- System Upgrade
- Release Customizing
- Benutzertest von neuen Versionen, Erweiterungen oder Fehlerbehebungen.
3.5.2.4 Fortlaufende Systemvorgänge
Unabhängig von Erweiterungen oder Optimierungen des SAP Systems muss auch der tägliche Betrieb des SAP Systems betreut werden, hierzu zählen Vorgänge wie:
- Datensicherung
- Überwachung der laufenden Prozesse
- Protokollierung von System- und Benutzerdaten
- Erstellung von Auswertungen
Siehe [61]
3.5.2.5 Abschluss Projekt/Review
Dieses abschließende Arbeitspaket ist eine Bestandsaufnahme und -bewertung des durchgeführten Projektes. Wenn noch offene Punkte existieren, sind diese abschließend zu lösen, weiterhin sollte eine Bewertung der in Phase 1 erarbeiteten Vorteile durch die SAP Einführung erfolgen. Mit der Abnahme des Gesamtprojektes durch das Projektteam ist das Projekt beendet.
Siehe [62]
3.5.3 Abgrenzung zur Standardmethode
Die Inhalte der jeweils abschließenden Phase des Produktivbetriebes sind, überschneidend für beide Vorgehensmodelle, gleichwertig. Einzig die Fokussierung des ASAP Ansatzes auf den Projektmanagementaspekt stellt auch in dieser Phase eine Erweiterung gegenüber dem traditionellen Vorgehensmodell dar.
Beide zentralen Ansätze, sowohl die Einführung neuer standardisierter Geschäftsprozesse, als auch die Abbildung der bestehenden Geschäftsprozesse im Rahmen des traditionellen Vorgehensweisen bedingen Einarbeitungszeit auf Seiten der Anwender. Dementsprechend ist z.B. auch die nötige Produktionsunterstützung und allgemeiner Support in beiden Fällen zu leisten.
4 Schlussbetrachtung
Die zentrale Frage auf Seiten der Unternehmen, bezüglich der SAP Einführung mit Hilfe des traditionellen Vorgehensweise oder der ASAP Methodik, ist die Abwägung zwischen der gewünschten Zielsetzung und den daraus resultierenden finanziellen Aufwendungen.
Eine kurze Projektdauer von durchschnittlich 5-9 Monaten, zusammen mit den daraus resultierenden Vorteilen wie
- Überschaubarer Zeitrahmen
- Zeitlich begrenzter Ressourcenaufwand (Mitarbeiter, Zeit, finanzielle Mittel, etc.)
- Dadurch bedingt einen schnellen und hohen ROI (Return on Investment)
- Bedarfsorientiertes SAP System, da Anforderung und Umsetzung zeitlich nahe beieinander liegen
- Kein vorhergehendes Business Process Reengineering notwendig, da die SAP Referenzprozesse implementiert werden
- Aktive kontinuierliche Weiterentwicklung des ASAP Ansatzes, aktuell unter Einbeziehung anerkannter Standards im Bereich Projektmanagement wie z.B. PMI PMBOK, durch die SAP AG.
kennzeichnen den ASAP-Ansatz. Bedeutet, der ASAP Ansatz hebt die schnelle Implementierung des Systems (Informationssystemorientierter Ansatz)in den Vordergrund. Um dieses Ziel zu erreichen erkauft sich der ASAP Ansatz auch ein paar wesentliche Nachteile wie
- Durch Implementierung der SAP Referenzprozesse ohne vorheriges Business Process Reengineering zeitgleiche Änderung der Prozesse UND des Informationssystems.
- Hierdurch steigt der Schulungsbedarf für die eigenen Mitarbeiter.
- Ebenso leidet der Ruf des neuen Systems, ohne rechtzeitiges Gegensteuern kann die Akzeptanz des neuen Systems im Unternehmen gering ausfallen.
- Verlust von Flexibilität durch die Ausrichtung auf Standards. Möglichst keine funktionalen Änderungen am System, sondern Orientierung an den SAP Standards.
- Einführung nur des Kernsystems mit Abdeckung des Geschäftsprozesse entlang der Wertschöpfungskette. Umfassendere Einführung bzw. Änderung und Optimierung erfolgen erst zu einem späteren Zeitpunkt wo das grundlegende System bereits produktiv ist.
- Weitere Aufwendungen nach Ende des ursprünglichen Projektes sind erforderlich, da nur Kernbereiche der BWL eingeführt wurden.
Demgegenüber steht das traditionelle Vorgehensmodell zur SAP Einführung, welches auch die Ausgangsbasis für das ASAP-Konzept bildete. Die traditionelle Vorgehensweise mit ihrer hohen Erfahrungsbasis aus tausenden vergangener Implementierungen hat, neben ASAP, ebenfalls ihre Daseinsberechtigung am Markt. Sie bietet Vorteile wie
- Weitreichende Flexibilität, selbstverantwortliche Festlegung der Ziele und deren Umsetzung bestimmen den Umfang der Einführung
- Vorgeschaltetes Business Process Reengineering kann Schwachstellen in der Organisationsstruktur aufdecken und somit zur gleichzeitigen Optimierung und Hinterfragung der Aufbau- und Ablauforganisation beitragen.
- Funktionale Anpassung der SAP Software auf die Unternehmensbedürfnisse, durch Customizing oder Codeänderungen, ermöglichen als probates Mittel der SAP Einführung die Abbildung der bestehenden, geänderten oder neu konzipierten Geschäftsprozesse
- Implementierung von Referenzprozessen trotzdem möglich, aber durch die erweiterten Möglichkeiten nicht zwingend erforderlich
Diese erhöhte Flexibilität in der Einführung kann das ASAP-Konzept mit seinem weitgehend festgelegten Vorgehen nicht leisten. Hohe Flexibilität geht aber auch mit tiefgreifenden Nachteilen einher, wie
- Unbegrenzte Flexibilität kann die Projektlaufzeit stark erhöhen, da ein eng gefasster Fokus auf die avisierten Ziele fehlt
- Lange Projektdauer bringt (in der Regel) einen erhöhten Finanzbedarf mit sich
- Abweichungen von der SAP Standardsoftware durch einen hohen Anteil an Customizing erhöhen den Administrationsaufwand und erschweren bzw. verteuern spätere Releasewechsel
- Hohe zeitliche Diskrepanz zwischen Zieldefinition (Projektstart) und Inbetriebnahme (Projektende) kann den Praxisnutzen, aufgrund des dynamischen Unternehmensumfelds, erheblich reduzieren. Bedeutet die anfangs gesetzten Ziele können zum Zeitpunkt des Echtbetriebs nicht mehr den aktuellen Bedürfnissen entsprechen.
Dementsprechend muss das Unternehmen auf Basis der individuell verschiedenen kritischen Erfolgsfaktoren eine Entscheidung für ASAP oder für das traditionelle Vorgehensmodell treffen. Entweder das ASAP-Konzept mit einer kurzen Projektlaufzeit und Fokus auf dem Projektmanagementaspekt und dem SAP-Referenzmodell. Oder das traditionelle Vorgehensmodell mit seiner weitreichenden Flexibilität, aber der Gefahr höherer Kosten und Projektlaufzeit.
Siehe [63]
5 Anhang
5.1 Fußnoten
- ↑ Vgl. Wenzel, Seite 249
- ↑ Vgl. Geiß/Soltysiak, Seite 27-28
- ↑ Vgl. Geiß/Soltysiak, Seite 28
- ↑ Vgl. Wenzel, Seite 250
- ↑ Vgl. Brand, Seite 23-24
- ↑ Vgl. Wenzel, Seite 252
- ↑ Vgl. Brand, Seite 27
- ↑ Vgl. Wenzel, Seite 255
- ↑ Vgl. Brand, Seite 112
- ↑ Vgl. Wenzel, Seite 256
- ↑ Vgl. Wenzel, Seite 257
- ↑ Vgl. Brand, Seite 32-35
- ↑ Vgl. Wenzel, Seite 258
- ↑ Vgl. Wenzel, Seite 258
- ↑ Vgl. Brand, Seite 36
- ↑ Vgl. Wenzel, Seite 259
- ↑ Vgl. Wenzel, Seite 260
- ↑ Vgl. Wenzel, Seite 261
- ↑ Vgl. Brand, Seite 41-42
- ↑ Vgl. Wenzel, Seite 263
- ↑ Vgl. Wenzel, Seite 263-265
- ↑ Vgl. Brand, Seite 38-39
- ↑ Vgl. Wenzel, Seite 266
- ↑ Vgl. Brand, Seite 39
- ↑ Vgl. Wenzel, Seite 266
- ↑ Vgl. CDI, Seite 350-351
- ↑ Vgl. Wenzel, Seite 267
- ↑ Vgl. Wenzel, Seite 268
- ↑ Vgl. Wenzel, Seite 268-269
- ↑ Vgl. CDI, Seite 365
- ↑ Vgl. Wenzel, Seite 270-272
- ↑ Vgl. CDI, Seite 366
- ↑ Vgl. Wenzel, Seite 272-273
- ↑ 34,0 34,1 Vgl. Wenzel, Seite 274
- ↑ Vgl. CDI, Seite 367
- ↑ Vgl. Wenzel, Seite 275-276
- ↑ Vgl. CDI, Seite 367-368
- ↑ Vgl. Wenzel, Seite 276-277
- ↑ 39,0 39,1 Vgl. CDI, Seite 368
- ↑ Vgl. Wenzel, Seite 277
- ↑ Vgl. Wenzel, Seite 278-279
- ↑ Vgl. Wenzel, Seite 279
- ↑ 43,0 43,1 Vgl. Wenzel, Seite 280
- ↑ Vgl. CDI, Seite 369
- ↑ 45,0 45,1 Vgl. CDI, Seite 351
- ↑ Vgl. CDI, Seite 370
- ↑ Vgl. Wenzel, Seite 280-281
- ↑ Vgl. Wenzel, Seite 281
- ↑ Vgl. CDI, Seite 370-371
- ↑ Vgl. Wenzel, Seite 281-282
- ↑ Vgl. CDI, Seite 371
- ↑ Vgl. Wenzel, Seite 282-283
- ↑ 53,0 53,1 Vgl. Wenzel, Seite 283
- ↑ 54,0 54,1 Vgl. CDI, Seite 372
- ↑ Vgl. Wenzel, Seite 284
- ↑ 56,0 56,1 Vgl. Wenzel, Seite 285
- ↑ Vgl. CDI, Seite 372
- ↑ Vgl. Wenzel, Seite 286
- ↑ 59,0 59,1 Vgl. CDI, Seite 373
- ↑ Vgl. Wenzel, Seite 286-288
- ↑ Vgl. Wenzel, Seite 287
- ↑ Vgl. Wenzel, Seite 288
- ↑ Vgl. Dolmetsch, Huber, Fleisch, Österle, Seite 1-8
5.2 Abbildungsverzeichnis
Abb.1.1: ASAP Logo (SAP AG) |
Abb.2.1: ASAP Roadmap (SAP AG) |
Abb.2.2: Wasserfallmodell nach Boehm (Vgl. Böhm, Seite 10) |
Abb.2.3: Traditionelles Vorgehensmodell |
Abb.3.1: ASAP Roadmap Phase 1 (SAP AG) |
Abb.3.2: ASAP Roadmap Phase 2 (SAP AG) |
Abb.3.3: ASAP Roadmap Phase 3 (SAP AG) |
Abb.3.4: ASAP Roadmap Phase 4 (SAP AG) |
Abb.3.5: Magisches Dreieck (RKW Kompetenzzentrum Stand 20.01.09) |
Abb.3.6: ASAP Roadmap Phase 5 (SAP AG) |
5.3 Literaturverzeichnis
| Brand, Hartwig (1998): | SAP R/3 Einführung mit ASAP Technische Implementierung von SAP R/3 planen und realisieren, 1. Auflage, Addison-Wesley-Longman Verlag GmbH, Bonn 1998 |
| Böhm, Rolf (1994): | Methoden und Techniken der System-Entwicklung, 5. Auflage, vdf Hochschulverlag AG, Zürich 2005 |
| Deutsche Private Akademie für Wirtschaft (CDI) (2001): | SAP R/3 Einführung Release 4.6, 1. Auflage, Addison-Wesley Verlag, München 2001 |
| Dolmetsch, R. / Huber, T. / Fleisch E. / Österle, H. (1998): | Accelerated SAP 4 Case Studies Arbeitsbericht, Version 1.0, Institut für Wirtschaftsinformatik der Universität St.Gallen, St.Gallen 1998 |
| Geiß, Marcus / Soltysiak, Roland (1998): | SAP R/3 dynamisch einführen, 1. Auflage, Addison-Wesley-Longman Verlag GmbH, Bonn 1998 |
| Quack, Karin (1998): | Wie und wann "Accelerated SAP" Erfolg verspricht, in: Computerwoche 1998, Heft Nr.41, S.65-66 |
| SAP AG (1999): | SAP AG: ASAP:Accelerated SAP |
| Wenzel, Paul (2001): | Betriebswirtschaftliche Anwendungen mit SAP R/3, 1. Auflage, Vieweg Verlag, Braunschweig/Wiesbaden 2001 |
