Final Thesis - Bis.inf.fh-brs.de

Fachhochschule
Bonn-Rhein-Sieg
University of Applied Sciences
Institut für interdisziplinäre Studien
Institute for Interdisciplinary Studies
Final Thesis
im Bachelor Studiengang
Business Information Systems
Tailoring des V-Modell XT für einen SAP Releasewechsel
von
Anita Ulenaers
Erstbetreuer: Prof. Dr. Andreas Hense
Zweitbetreuer: Prof. Dr. Andreas Gadatsch
Eingereicht am: 10.07.2007

Inhaltsverzeichnis
II
Seite
Abbildungsverzeichnis................................................................................... IV
Abkürzungsverzeichnis.................................................................................. VI
1 Einleitung ...................................................................................................1
1.1 Problemstellung der Bachelor Thesis ...................................................1
1.2 Zielsetzung der Bachelor Thesis ..........................................................3
1.3 Vorgehensweise ...................................................................................4
2 ERP Systeme..............................................................................................5
2.1 Einordnung ...........................................................................................5
2.2 Merkmale von ERP Systemen..............................................................6
2.3 SAP ERP Systeme ...............................................................................8
3 Vorgehensmodelle für einen Releasewechsel von SAP.......................11
3.1 Implementation Roadmap...................................................................11
3.2 Phasenmodell Redocumentation Scout..............................................16
4 V-Modell XT ..............................................................................................19
4.1 Ziele des V-Modell XT ........................................................................20
4.2 Grundkonzept des V-Modell XT..........................................................21
4.3 Tailoring..............................................................................................27
5 Konzeptbildung........................................................................................31
5.1 Konzept für das Modell des Auftraggebers.........................................31
5.2 Konzept für das Modell des Auftragnehmers......................................36
5.3 Konzept für das V-Modell XT für eine SAP Releasewechsel..............40
6 Vorstellung der Ergebnisse ....................................................................42
6.1 SAP Releasewechsel (AG).................................................................43
6.2 SAP Releasewechsel (AN) .................................................................48
6.3 Bekannter Fehler ................................................................................52

III
7 Das Projekt „SAP Releasewechsel“ einer oberen Bundesbehörde ....53
7.1 Vorgehensweise im Projekt „SAP Releasewechsel“...........................54
7.2 Mögliche Risiken dieses Vorgehens...................................................56
8 Schlussbetrachtung ................................................................................57
8.1 Zusammenfassung der Ergebnisse ....................................................57
8.2 Weitere Einsatzmöglichkeiten.............................................................58
8.3 Kritische Würdigung............................................................................59
Literaturverzeichnis........................................................................................60
Glossar ............................................................................................................62
Eidesstattliche Erklärung...............................................................................64

Abbildungsverzeichnis
IV
Seite
Abbildung 1: Softwarekategorien ........................................................................6
Abbildung 2: Implemenation Roadmap der SAP AG.........................................12
Abbildung 3: Phasenmodell Redocumentation Scout der IDS Scheer AG........16
Abbildung 4: Logo V-Modell XT ........................................................................19
Abbildung 5: Grundstruktur des V-Modell XT....................................................23
Abbildung 6: Klassifizierung von Projekten in Projekttypen ..............................24
Abbildung 7: Zuordnung der Projektdurchführungsstrategie.............................25
Abbildung 8: Entscheidungspunkte des Standard V-Modell XT........................26
Abbildung 9: Auswahl des Projekttyps ..............................................................28
Abbildung 10: Auswahl der Projektdurchführungsstrategie und der
Vorgehensbausteine .........................................................................................28
Abbildung 11: V-Modell XT Editor.....................................................................29
Abbildung 12: Entscheidungspunkte des Systementwicklungsprojekt (AG) .....33
Abbildung 13: Konzept Vorgehensmodell AG...................................................34
Abbildung 14: V-Modell XT für einen SAP Releasewechsel AG .......................35
Abbildung 15: Entscheidungspunkte des Systementwicklungsprojekt (AN)......37
Abbildung 16: Konzept Vorgehensmodell AN ...................................................38
Abbildung 17: V-Modell XT für einen SAP Releasewechsel AN .......................39
Abbildung 18: V-Modell XT für einen SAP Releasewechsel .............................41
Abbildung 19: Auswahl der Projekttypen im getailorten Projektassistenten......42
Abbildung 20: Register Anwendungsprofil ........................................................43
Abbildung 21: Vorgehensbausteine und Projektdurchführungsstrategie für den
Projekttyp "SAP Releasewechsel (AG)"............................................................44
Abbildung 22: Planung der Entscheidungspunkte für den Projekttyp "SAP
Releasewechsel (AG)"......................................................................................45
Abbildung 23: Projektplan zu dem Projekt "SAP Releasewechsel AG" ............46
Abbildung 24: Dokumentation des Projektes "SAP Releasewechsel (AG)" ......47
Abbildung 25: Vorgehensbausteine und Projektdurchführungsstrategie für den
Projekttyp "SAP Releasewechsel (AN)"............................................................49

V
Abbildung 26: Planung der Entscheidungspunkte für den Projekttyp "SAP
Releasewechsel (AN)" ......................................................................................49
Abbildung 27: Projektplan zu dem Projekt "SAP Releasewechsel AN".............50
Abbildung 28: Dokumentation des Projektes "SAP Releasewechsel (AN)" ......51

Abkürzungsverzeichnis
ABAP/4 Advanced Business Application Programming/4
Programmiersprache der SAP AG
AG Auftraggeber
AN Auftragnehmer
ARIS Architektur integrierter Informationssysteme
VI
ERP Enterprise Resource Planning
HTML Hypertext Markup Language
IDS Gesellschaft für integrierte Datenverarbeitungssysteme
IMKA Interministerielle Koordinierungssausschuss
IT Informationstechnologie
KBSt Koordinierungs- und Beratungsstelle der Bundesregierung
für Informationstechnik in der Bundesverwaltung
PC Personal Computer
PDF Portable Document Format
R/3 Realtime/3
ERP System der SAP AG
RBE Reverse Business Engineer
ROI Return On Investment
SAP früher für: Systeme, Anwendungen und Produkte in der Datenverarbeitung
heute: Offizieller Name des Herstellers von betrieblicher Anwendungssoftware,
sowie dessen Produkte

VII
SOA Service-orientierten-Architektur
XML Extensible Markup Language
XT extreme Tailoring

1 Einleitung
1.1 Problemstellung der Bachelor Thesis
1
In über 120 Ländern wurde ca. 91.500-mal SAP in Unternehmen installiert. 1 Bei
der Einführung dieser Systeme werden Anpassungen gemacht, um die zuvor
modellierten Soll-Geschäftsprozesse besser abzubilden. Diese Anpassungen
können zum einen aus einer Parametrisierung der Software, dem so genannten
„Customizing“, aber auch aus selbst entwickelten Add-Ons bestehen. 2
Nach einiger Zeit der Nutzung des SAP-Systems wird es erforderlich, auf ein
neues Release umzusteigen. Die Gründe dafür können verschieden sein: Es
werden neue Funktionalitäten angeboten, Prozesse des Systems wurden optimiert
und bieten Einsparpotenzial oder Fehler im vorherigen Release wurden
verbessert.
Doch spätestens in dem Moment, wenn der Wartungsvertrag für das aktuelle
Release endgültig ausläuft, gerät das Unternehmen in Zugzwang. Und genau
hier bereiten diese Anpassungen Probleme. 3
Bei einer Migration der Systeme können diese Anpassungen unter Umständen
nicht automatisch übernommen werden. Es kann auch passieren, dass sie
durch die Standardprogramme überschrieben werden oder es zu anderen
Wechselwirkungen kommen kann. 4 Somit entsteht ein erhöhter Aufwand, da
das neue System wieder manuell angepasst werden muss.
Aus diesem Grund müssen folgende Fragestellungen genau geprüft werden:
• Wie genau lassen sich die Anpassungen in das neue System integrieren?
• Sind die Anpassungen aus heutiger Sicht immer noch von Nöten?
1 Vgl. SAP (2005), www.sap.com/germany/media/mc_673/Emp-Rep_2005_D.pdf S.5.
2 Vgl. Gadatsch (2002b), S. 25.
3 Vgl. Rau (2006), S. 31-33.
4 Vgl. Appelrath / Ritter (2000), S. 67.

2
• Bietet das neue SAP Release sogar neue Funktionalitäten, die alte Individualanpassungen
unnötig machen?
• In wie weit ist es möglich in den SAP Standard zurückzukehren?
Für die Umsetzung des Releasewechsels benötigt das Projektteam genaue Informationen
über diese Anpassungen. Doch stellt sich die Informationsgewinnung
problematisch dar, wenn die Dokumentationen der System-Einführung
unzulänglich sind.
Damit keine wichtigen Aspekte bei der Vorbereitung vergessen werden, wird ein
Vorgehensmodell erforderlich, das die Besonderheiten eines SAP Releasewechsels
unterstützt.
Durch die Empfehlung vom 04.11.2004 des Interministeriellen Koordinierungssausschuss
(IMKA) ist das V-Modell XT verbindlich für IT-Projekte in Bundesbehörden
einzusetzen. 5
Über 50% der Mitarbeiter in Bundesbehörden arbeiten mit SAP. 6 Diesen Mitarbeitern
steht in der Zukunft ein Releasewechsel bevor. Für die Umsetzung dieser
Releasewechsel können sie nicht auf vorhandene Vorgehensmodelle, wie
bspw. dem der SAP AG zurückgreifen, sondern sind verpflichtet das V-Modell
XT zu nutzen.
Damit diesen Projektteams dennoch eine geeignete Unterstützung durch das V-
Modell XT erhalten, ist es erforderlich das V-Modell XT an die Besonderheiten
eines SAP Releasewechsels anzupassen.
5 Vgl. KBSt (2006).
6 Mündliche Aussage des Herrn Dr. Schuster (Mitarbeiter der SAP AG und zuständig für Kunden
in Bundesbehörden) am 22.06.2007 in Bonn.

1.2 Zielsetzung der Bachelor Thesis
In dieser Bachelor Thesis soll das V-Modell XT auf die Besonderheiten eines
Releasewechsels von SAP angepasst werden.
Dafür soll eine lauffähige Version des V-Modell XT Projektassistenten erstellt
werden.
Aus dem erstellten Projektassistenten sollen ein Vorgehensmodell, eine Dokumentation
und Dokument-Vorlagen exportiert werden können, die die Besonderheiten
eines SAP Releasewechsel enthalten.
3

1.3 Vorgehensweise
Diese Arbeit wurde wie folgt gegliedert:
In Kapitel 2 werden ERP (Enterprise Resource Planning) Systeme vorgestellt
und in die verschiedenen Softwarekategorien eingeordnet. Weiterhin werden
ERP-Systeme der SAP AG kurz vorgestellt.
4
In Kapitel 3 werden die Vorgehensmodelle „Implementation Roadmap“ der SAP
AG und das „Phasemodell Redocumentation Scout“ der IDS Scheer AG vorgestellt.
Diese Vorgehensmodelle wurden bereits entwickelt, um einen Releasewechsel
einer SAP Software durchzuführen.
Eine Vorstellung des V-Modell XT, dessen Ziele, das Grundkonzept und das
Tailoring wird in Kapitel 4 gegeben.
Im fünften Kapitel wird das Konzept des neuen V-Modell XT für einen SAP Releasewechsel
erklärt. Dabei wird verdeutlicht, welche Ideen von den in Kapitel 3
vorgestellten Vorgehensmodellen in das neue V-Modell XT einfließen.
In Kapitel 6 werden die Ergebnisse vorgestellt. Dabei werden die Ergebnisse
des V-Modell XT für einen SAP Releasewechsel des Auftraggebers separat von
dem V-Modell XT für einen SAP Releasewechsel des Auftragnehmers erläutert.
Im siebten Kapitel wird das Projekt „SAP Releasewechsel“ einer oberen Bundesbehörde
vorgestellt. Dabei wird deren Vorgehensweise dargestellt und mögliche
Risiken diesen Vorgehens angemerkt.
In der Schlussbetrachtung in Kapitel 8 werden die Ergebnisse dieser Arbeit
noch einmal kurz zusammengefasst. Auch mögliche weitere Einsatzmöglichkeiten
werden in diesem Kapitel in Form von offenen Fragen diskutiert. Zum Abschluss
gibt es eine kritische Würdigung des neuen Vorgehensmodells.

2 ERP Systeme
5
In diesem Kapitel wird eine Einführung in ERP Systeme bzw. ERP Software
gegeben. Dafür wird der Begriff erklärt, eine Abgrenzung zu anderen Softwarearten
dargelegt und die Merkmale vorgestellt.
Zum Schluss wird auf die ERP Systeme der SAP AG eingegangen. Dabei werden
die Problematiken bei einem Releasewechsels dieses Systems verdeutlicht.
2.1 Einordnung
Software lässt sich zum einen in Systemsoftware, wie z.B. Betriebssysteme
oder Datenbanksysteme und zum anderen in Anwendungssysteme unterteilen.
Unter einem Anwendungssystem wird ein System verstanden, das fachliche
Aufgaben unterstützt. Da es verschiedene fachliche Aufgaben gibt, werden die
Anwendungssysteme noch einmal in Betriebliche-, Technische-, 7 Büro- und
Kommunikationssoftware unterteilt. Betriebliche Software wurde für die Unterstützung
verschiedener Arbeitsplatz-Tätigkeiten in einem Unternehmen wie z.B.
„Vertriebsabwicklung“ entwickelt. 8
Da die anderen Softwaretypen im weiteren Verlauf der Arbeit nicht von Bedeutung
sind, wird an dieser Stelle auf eine nähere Erklärung verzichtet.
Ein ERP System unterstützt Geschäftsprozesse eines Unternehmens. Diese
Geschäftsprozesse können z.B. Finanzwesen, Controlling, Vertrieb etc. sein. 9
Somit gehört eine ERP Software in die Kategorie der betrieblichen Anwendungssoftware.
Alle erwähnten Softwaresysteme können sowohl Individualentwicklungen, als
auch Standardsoftware sein. Da in dieser Arbeit, die Standardsoftware SAP der
SAP AG näher betrachtet wird, wird auf Individualentwicklungen nicht näher
eingegangen.
7 Vgl. Gadatsch (2002a), S. 3.
8 Vgl. Gadatsch (2003), S. 248-249.
9 Vgl. Gadatsch (2001), S. 71-72.

Abbildung 1: Softwarekategorien
Quelle: In Anlehnung an Gadatsch (2002a), S. 3.
2.2 Merkmale von ERP Systemen
6
Im Folgenden werden die Merkmale eines ERP Systems näher erläutert. Mit
Hilfe dieser Merkmale wird eine klare Abgrenzung zu anderen Software Systemen
deutlich.
Standardisierung
ERP Software wird für den „anonymen Markt“ 10 entwickelt. Aus diesem Grund
muss sie so entwickelt werden, dass sie die Anforderungen vieler Unternehmen
abdeckt.
Die Grundlagen der Standardisierung können verschieden sein. Beispielsweise
haben Gesetze des Steuer- und Handelsrechts zu einer Standardisierung im
externen Rechnungswesen geführt. Für das interne Rechnungswesen hingegen
führten wissenschaftliche Erkenntnisse zu einer Vereinheitlichung. 11
10 Gadatsch (2002a), S. 3.
11 Vgl. Appelrath / Ritter (2000), S. 4.

7
Dadurch, dass viele Unternehmen die Software nutzen können, verteilen sich
die Entwicklungskosten auf mehrere Anwender. Der Software-Anbieter kann
bereits nach einer geringen Anzahl an Installationen die Software günstiger anbieten,
wovon auch die nachfragenden Unternehmen profitieren. 12
Customizing
Durch das Customizing wird den nachfragenden Unternehmen die Möglichkeit
geboten, die Standardsoftware auf ihre Anforderungen anzupassen.
Die von dem Unternehmen benötigten Software-Bausteine werden dabei durch
das Setzen von Parametern ausgewählt. 13 Somit ist diese Art der Anpassungen
nur im Rahmen der vom Hersteller vorgegebenen Parametertabellen möglich. 14
Anpassungen, die darüber hinaus erwünscht sind, können mit dieser Methode
nicht realisiert werden.
Modularisierung
Durch die Modularisierung von ERP Software ist das nachfragende Unternehmen
in der Lage nur die Komponenten zu einzusetzen, die es benötigt. Somit
bleibt der Kauf eines Komplettsystems, von dem nur wenige Funktionalitäten
genutzt werden, erspart. 15
Auch für den Hersteller ist Modularisierung von Vorteil. Module sind in sich geschlossene
Software Pakete, die Schnittstellen zu anderen Modulen besitzen.
Die Komplexität bei der Entwicklung mehrerer kleinerer Module ist geringer, als
bei der Entwicklung des Gesamtsystems. Außerdem wird die Arbeitsorganisation
in der Entwicklung erleichtert, da bspw. die Module parallel programmiert
werden können. 16
Dadurch, dass die Module in sich geschlossen sind, können sie auch einzeln
vermarktet werden.
12 Vgl. Gronau (1999), S. 15.
13 Vgl. Appelrath / Ritter (2000), S. 4.
14 Vgl. Rau (2006), S. 7.
15 Vgl. Rau (2006), S. 9.
16 Vgl. Balzert (1998), S. 572-574.

8
Die unten aufgeführte Liste dient der Vervollständigung der ERP-Merkmale.
Diese sind für den weiteren Verlauf der Arbeit nicht relevant und darum wird auf
eine nähere Erklärung verzichtet.
• Operative Funktionalität
• Datenintegration
• Prozessintegration
• Schichtenarchitektur
• Transaktionsorientierung 17
2.3 SAP ERP Systeme
Die Unternehmen, die aktuell vor einem Releasewechsel stehen, wechseln von
dem System SAP R/3 zu SAP ERP 6.0. Aus diesem Grund wird das SAP R/3
System hier als Beispiel aufgeführt und weiter betrachtet.
SAP R/3 wurde 1992 von der SAP AG eingeführt. Als ERP System besitzt SAP
R/3 die oben genannten Merkmale.
Individualentwicklungen in R/3
Als Standardsoftware versucht auch R/3 so viele Anforderungen der nachfragenden
Unternehmen wie möglich zu unterstützen. Doch ist das bei der Vielzahl
an Unternehmen nicht komplett möglich. Auch durch das Customizing
können nicht alle Anforderungen realisiert werden.
So werden an den Stellen Erweiterungen notwendig, an denen der Geschäftsprozess
des Unternehmens nicht mehr mit der Standardsoftware abgebildet
werden kann. 18
17 Vgl. Gadatsch (2003), S. 254-257.
18 Vgl. Rau (2006), S. 24.

9
Erweiterungen werden in der SAP eigener Programmiersprache ABAP/4 entwickelt.
Gründe für den Wechsel eines SAP Releases
Angesichts des Konkurrenzdrucks ist ein Software-Hersteller in der Pflicht sein
Produkt stetig weiterzuentwickeln.
Auch SAP entwickelt seine Produkte weiter. Dabei wird die Software nicht nur
stetig verbessert, sondern es werden auch neue Funktionalitäten in die vorhandene
Software implementiert.
Die weiterentwickelte Software wird dann in einem neuen Release vermarktet.
Unter einem Release ist somit eine neue Version der Software zu verstehen.
Bei dem Kauf einer Software bzw. eines Releases schließt das Unternehmen
mit SAP einen Wartungsvertrag ab. In diesem Wartungsvertrag wird genau definiert,
welchen Support SAP gegenüber dem Unternehmen zu erbringen hat.
Dabei bezieht sich der Support nur auf das gekaufte Release und endet zu einem
vorgegebenen Datum.
Möchte das Unternehmen einen störungsfreien Betrieb ihres SAP Systems gewährleisten,
so muss es spätestens zu dem Auslaufdatum des Wartungsvertrags
auf ein neues Release wechseln.
Dieser künstlich verkürzte Systemlebenszyklus sorgt für eine regelmäßige Aktualisierung
der Software Releases im Unternehmen und zu einer Umsatzgenerierung
bei SAP. 19
Problematik Individualentwicklung bei einem Releasewechsel
Bei der Durchführung eines Releasewechsels stellen die Individualentwicklungen
das größte Hemmnis dar. Unter Umständen werden die Individualentwick-
19 Vgl. Rau (2006), S. 31-33.

10
lungen nicht automatisch in das neuen Release übernommen und es kommt zu
Anpassungsschwierigkeiten. 20
Es muss auch darauf geachtet werden, dass die Individualentwicklungen von
dem neuen Release nicht gelöscht oder überschrieben werden. Dabei kann es
auch zu Wechselwirkungen mit anderen Programmen kommen. 21
Die Individualentwicklungen können auch dazu führen, dass die Gewährleistungsansprüche
gegenüber SAP vermindert werden.
Diese Gründe zeigen, dass Individualentwicklungen schnell zu ungeplanten
Zusatzaufwendungen führen können. 22
Daher liegt es nahe den Releasewechsel zu nutzen, um so weit wie möglich in
den SAP Standard zurückzukehren und somit diese Zusatzaufwende zu vermeiden.
20 Vgl. Rau (2006), S. 34.
21 Vgl. Appelrath / Ritter (2000), S. 67.
22 Vgl. Arb, von (1997), S. 187.

3 Vorgehensmodelle für einen Releasewechsel von SAP
3.1 Implementation Roadmap
11
Die Implementation Roadmap ist die aktuelle standardisierte Vorgehensweise
für die Einführung und den Wechsel von SAP R/3 und wurde von der SAP AG
selbst entwickelt.
Dabei besteht die Implementation Roadmap aus fünf nach einander auszuführenden
Phasen:
• Projektvorbereitung
• Business Blueprint
• Realisierung
• Produktvorbereitung und
• Go Live und Support. 23
23 Vgl. Appelrath / Ritter (2000), S. 77.

12
Abbildung 2: Implemenation Roadmap der SAP AG
© SAP AG
Projektvorbereitung
Die erste Phase dient der Planung und Vorbereitung des Projektes. Hierbei
werden allgemeine Grundsätze des Projektmanagements befolgt, die in allen
Projekten erfolgen sollten, unabhängig von einer Einführung von SAP.
In dieser Phase
• werden die Ziele definiert,
• eine Einführungsstrategie festgelegt,
• der Projektplan mit den Arbeitspakten, Aktivitäten und Aufgaben definiert,
• die Projektorganisation aufgestellt und der Entscheidungsweg festgelegt,
• Standards für das Verfahren und die Dokumentation bestimmt,
• das Projektbudget festgelegt,

13
• die Anforderungen und die Zuteilung der benötigten Ressourcen definiert. 24
Business Blueprint
Ziel dieser Phase ist die Erstellung der Business Blueprints. Unter Business
Blueprints werden Entwurfsdokumente für das einzuführende System verstanden.
In den Business Blueprints werden
• die Geschäftsprozesse und Unternehmensbereiche definiert,
• eine Zuordnung der Organisationsstruktur zu den R/3-
Organisationseinheiten erstellt,
• Anforderungen an die Geschäftsprozesse festgelegt,
• Anforderungen für die Datenübernahme festgelegt und erforderliche Schnittstellen
aufgelistet.
Zusätzlich zu den Business Blueprints gibt es noch andere Arbeitspakete, die in
dieser Phase erledigt werden.
So muss bspw. eine Strategie zum Change Management erarbeitet werden.
Das Change Management ist für die Änderungen im Rahmen des Projektes
verantwortlich.
Neben den fachlichen Anforderungen an das neue System, müssen auch technische
Anforderungen definiert werden. Aus diesen Anforderungen wird dann
eine erste Test-Umgebung aufgebaut, und die Entwicklungsumgebung vorbereitet.
Ein letztes Arbeitspaket dieser Phase ist das Erstellen eines Schulungsplans für
die Endbenutzer. Damit wird sichergestellt, dass die Endbenutzer rechtzeitig auf
ihre neuen Aufgaben vorbereitet sind. 25
24 Vgl. Appelrath / Ritter (2000), S. 78.
25 Vgl. Appelrath / Ritter (2000), S. 92-105.

14
Realisierung
In der Realisierungsphase werden die Anforderungen aus der vorherigen Phase
umgesetzt. Diese Umsetzung geschieht in zwei Schritten:
1. Baseline- und Detail-Konfiguration
2. individuelle Funktionen
Unter einer Baseline-Konfiguration wird das Einrichten der Grundeinstellungen,
wie z.B. Länderspezifikationen, Währungen, etc. verstanden. Aber auch Unternehmensspezifische
Einstellungen wie Buchungskreis und Werke werden eingestellt.
In der Detail-Konfiguration werden die Geschäftsprozesse in das System integriert.
Bei der Umsetzung der individuellen Funktionen werden Systemerweiterungen,
Berichte und Formulare entwickelt, die nicht standardmäßig im SAP System
vorgesehen sind.
Zu den zwei Schritten, in denen das SAP System konfiguriert wird, müssen
noch andere Programme entwickelt werden. So werden bspw. Programme benötigt,
die die Datenübernahme automatisieren und Schnittstellen zu anderen
Systemen bzw. dem Alt-System liefern.
Vor dem abschließenden Integrationstest, muss das Berechtigungskonzept in
das SAP System implementiert werden und Schulungsdokumentationen und -
unterlagen erstellt werden. 26
Produktionsvorbereitung
Das Ziel dieser Phase ist es, das Unternehmen, wie auch das SAP System für
den produktiven Betrieb vorzubereiten.
26 Vgl. Appelrath / Ritter (2000), S. 105-120.

15
Dafür werden die zuvor geplanten Anwenderschulungen durchgeführt. Auch
werden Einstellungen, wie die Verarbeitung der Hintergrundprozesse und die
Infrastruktur für das Drucken in das System eingepflegt.
Anschließend werden diverse Tests durchgeführt, wie z.B. Disaster Recovery
Tests, Backup-Tests, Druck- und Faxtests, aber auch Tests zum Prüfen wichtiger
Transaktionen.
Am Ende der Phase wird der Wechsel von dem Alt-System zu dem neuen SAP
System vollzogen. Dieser Wechsel wird auch Cut Over genannt. 27
Go Live und Support
In der letzten Phase wird das SAP System noch so lange vom Projektteam begleitet,
bis eine ausreichende Stabilität des Systems erreicht wird.
In der ersten Woche nach dem Produktivsetzen des Systems werden vor allem
die Benutzer bei der Arbeit mit dem System unterstützt. Sollten dabei noch
Probleme auftauchen, die eine Änderung des Systems erfordern, sollten diese
zuerst im Entwicklungssystem durchgeführt und im Qualitätssystem getestet
werden, bevor sie in das Produktivsystem eingespielt werden.
Zum Abschluss des Projektes wird in einem Lenkungsausschuss das System
übergeben und abgenommen. Damit ist das Projekt offiziell beendet und die
Projektmitarbeiter werden aus ihren Projektaufgaben entlassen. 28
27 Vgl. Appelrath / Ritter (2000), S. 120-123.
28 Vgl. Appelrath / Ritter (2000), S. 124-125.

16
3.2 Phasenmodell Redocumentation Scout
Die IDS Scheer AG bietet ein Tool namens „Redocumentation Scout“ an. Mit
diesem Tool ist es möglich „vorhandene R/3-System auf einer prozessorientierter
Basis zu redokumentieren“ 29 . Neben dem eigentlich Tool, wird auch ein
Phasenmodell angeboten, das Phasenmodell Redocumentation Scout. Dieses
Phasenmodell wird im Folgenden vorgestellt.
Abbildung 3: Phasenmodell Redocumentation Scout der IDS Scheer AG
Quelle: Rau (2006), S. 41.
Projektvorbereitung
Auch in diesem Phasenmodell dient die erste Phase zur Projektvorbereitung.
Es müssen die Ziele definiert werden, es muss ein Projektplan erstellt werden
und die beteiligten Personen müssen über das Projektvorgehen informiert werden.
Auch das erste vertraut Machen mit der notwendigen Software, muss in
dieser Phase vollzogen werden. 30
Datenextrakt
Über einen speziellen ABAP/4-Report werden die Daten aus dem produktiven
R/3 System in eine Datei geschrieben. Dieser Report liefert Daten über Trans-
29 Rau (2006), S. 39.
30 Vgl. Rau (2006), S. 41-42.

aktionen, Reports, Entwicklungen und Tabellen, die angepasst wurden, wie
auch Informationen über den Releasestand, Benutzer und organisatorische
Funktionen.
Durch den Transaktionsmonitor des R/3 Systems sollen folgende Fragen beantwortet
werden: 31
• „Welche Funktionen und Transaktionen werden im R/3-System genutzt?“
17
• „Welche Organisationseinheiten und Nutzer werden im R/3-System repräsentiert?“
• „Welche Geschäftsprozesse und Geschäftsabläufe werden durch das R/3-
System unterstützt?“ 32
Datenanalyse
Die vorher extrahierte Datei wird in dieser Phase in den Reverse Business Engineer
(RBE) von SAP importiert. Dieser analysiert die Datei und gibt Informationen
über
• welche organisatorische Einheit, welche Art von Transaktionen nutzt,
• welche Funktionen überhaupt genutzt werden,
• wie die Nutzung der Individualentwicklungen ist,
• welche Customizingeinstellungen gemacht wurden,
• welche Stammdaten genutzt werden
• und ein Vergleich zwischen unterschiedlichen Mandaten 33 , falls mehrere
vorhanden sind. 34
31 Vgl. Rau (2006), S. 42.
32 Rau (2006), S. 42.
33 Ein Mandant ist die oberste Organisationseinheit in R/3. Vgl. Appelrath / Ritter (2000), S. 48.
34 Vgl. Rau (2006), S. 43-44.

18
Direkte Überführung in Prozessmodelle
In dieser Phase werden die Analyseergebnisse des RBE in Prozessmodelle
übertragen. Dabei werden nicht nur die R/3 Standardprozesse, sondern auch
die individuellen Prozesse abgebildet. Diese Prozessmodelle dienen dann als
Basis zur Geschäftsprozessoptimierung. 35
Y-Match
Nun wird ein High Level Prozessmodell für die Geschäftsprozesse des Unternehmens
erstellt. Dabei werden das SAP Referenzmodell und die Ergebnisse
der vorherigen Phase betrachtet. Es muss geprüft werden, an welchen Stellen
das SAP System die internen Prozesse unterstützt und an welchen Stellen Anpassungen
erforderlich sind. 36
Kontinuierliche Optimierung
Die Ergebnisse der Redokumentation können auch für weitere Optimierung genutzt
werden. Dieses wird in dieser abschließenden Phase durchgeführt. 37
35 Vgl. Rau (2006), S. 44-45.
36 Vgl. Rau (2006), S. 45.
37 Vgl. Rau (2006), S. 46.

4 V-Modell XT
19
Das V-Modell XT wurde von der Koordinierungs- und Beratungsstelle der Bundesregierung
für Informationstechnik in der Bundesverwaltung (KBSt) entwickelt.
Es ist ein Vorgehensmodell zum Planen und Durchführen von IT-
Projekten. 2004 löst es das zuvor entwickelte V-Modell ’97 ab, da dieses nicht
mehr den aktuellen Stand der Informationstechnologie widerspiegelte. 38
Das V-Modell® XT ist eine durch die Bundesrepublik Deutschland geschützte
Marke.
Abbildung 4: Logo V-Modell XT
38 Vgl. KBSt (2004), Teil 1 S. 3.

4.1 Ziele des V-Modell XT
20
Minimierung der Projektrisiken
Durch eine standardisierte Vorgehensweise, die zu erledigenden Ergebnisse
mit den verantwortlichen Rollen definiert, wird die Projekttransparenz und Planbarkeit
verbessert. Somit werden Planungsabweichungen frühzeitig erkannt und
das Eintreten von Risiken kann verhindert werden
Verbesserung und Gewährleistung der Qualität
Die Standarisierung des V-Modell XT stellt sicher, dass die Ergebnisse von gewünschter
Qualität sind. Die Vereinheitlichung der Produktinhalte verbessert die
Lesbarkeit und erhöht die Verständlichkeit. Daher können die Zwischenergebnisse
frühzeitig und leichter überprüft werden.
Eindämmung der Gesamtkosten
Die Kosten für die Entwicklung, Herstellung und Pflege eines Systems lassen
sich besser kalkulieren, abschätzen und steuern.
Verbesserung der Kommunikation
Reibungsverluste zwischen Nutzern, Auftraggeber (AG), Auftragnehmer (AN)
und Entwickler werden durch eine einheitliche Beschreibung der relevanten Bestandteile
und Begrifflichkeiten reduziert. 39
39 Vgl. KBSt (2004), Teil 1 S. 4.

4.2 Grundkonzept des V-Modell XT
Das V-Modell XT legt fest „Wer“ „Wann“ „Was“ in einem Projekt zu erledigen
hat.
21
Das V-Modell XT ist für verschiedene Projektkonstellationen geeignet. Doch ist
ein Ablaufschema nicht auf jede Projektkonstellation anwendbar. Daher bietet
das V-Modell XT verschiedene Projekttypen an, die die charakteristischen Eigenschaften
von Softwareprojekten klassifizieren.
Die Projekttypen, die das V-Modell XT anbietet sind:
• Systementwicklungsprojekt (AG)
• Systementwicklungsprojekt (AN)
• Systementwicklungsprojekt (AG/AN)
• Einführung und Pflege eines organisationsspezifischen Vorgehensmodells.
Bei dem zu entwickelnden System gibt es wiederum eine Einteilung in:
• Hardware-System
• Software-System
• Komplexes System
• Eingebettetes System
• Systemintegration
Abbildung 6 veranschaulicht die Beziehungen der Projektmerkmale, Projektrollen
und Projekttypen.

22
Der ausgewählte Projekttyp definiert mindestens eine Projektdurchführungsstrategie.
Eine Projektdurchführungsstrategie ist eine Folge von Entscheidungspunkten
und somit der Ablaufrahmen für das Projekt.
Ein Entscheidungspunkt ist ein Meilenstein im Projektablauf, zu ihm wird der
aktuelle Stand des Projektes evaluiert.
Eine Zuordnung der Projektdurchführungsstrategien zu den Projekttypen ist in
Abbildung 7 dargestellt und eine Übersicht aller Entscheidungspunkte ist
Abbildung 8 zu entnehmen.
Zusätzlich zu der Projektdurchführungsstrategie definiert der Projekttyp auch
die Vorgehensbausteine, die während des Projektes bearbeitet werden müssen.
Zu den vorgegebenen Vorgehensbausteinen, können außerdem auch weitere
ausgewählt werden.
Um einen Mindestmaß an Projektdurchführungsqualität zu gewährleisten, gibt
es Vorgehensbaustein, die in jedem V-Modell XT konformen Projekt angewendet
werden müssen. Diese Vorgehensbausteine werden V-Modell-Kern genannt.
Diese sind:
• Projektmanagement
• Qualitätssicherung
• Konfigurationsmanagement
• Problem- und Änderungsmanagement.
Ein Vorgehensbaustein ist eine konkrete Aufgabenstellung im Projekt. Zu der
Aufgabenstellung werden die zu erarbeitenden Produkte, die Aktivitäten und die
ausführenden Rollen festgelegt. Dabei ist jeder Vorgehensbaustein in sich abgeschlossen.

23
Ein Vorgehensbaustein definiert somit das „Was“ - die zu erstellenden Produkte
- und das „Wer“ - die verantwortliche Rolle. Da zu jedem Entscheidungspunkt
eine Menge zu erledigenden Produkten definiert ist, legt die Projektdurchführungsstrategie
somit das „Wann“ fest.
Eine Übersicht über die Gesamtstruktur des V-Modell XT bietet Abbildung 5. 40
Abbildung 5: Grundstruktur des V-Modell XT
Quelle: Eigene Darstellung.
40 Vgl. KBSt (2004), Teil 1 S. 8-16.

24
Abbildung 6: Klassifizierung von Projekten in Projekttypen
Quelle: KBSt (2004), Teil 1 S. 10.

25
Abbildung 7: Zuordnung der Projektdurchführungsstrategie
Quelle: KBSt (2004), Teil 1 S. 14.

Abbildung 8: Entscheidungspunkte des Standard V-Modell XT
Quelle: KBSt (2004), Teil 1 S. 16.
26

4.3 Tailoring
27
Unter Tailoring wird das Anpassen des V-Modell XT verstanden.
Wie im Kapitel 4.2 „Grundkonzept des V-Modell XT“ beschrieben, bietet das V-
Modell XT mehrere Auswahlmöglichkeiten, die die Projektdurchführung beeinflussen.
Um diese Auswahl zu erleichtern wird der V-Modell XT Projektassistent
angeboten. Der V-Modell XT Projektassistent ist ein Softwaretool mit dessen
Hilfe das Tailoring durchgeführt werden kann.
Durch die Auswahl des Projekttyps in dem V-Modell XT Projektassistenten,
werden die nicht relevanten Teile des V-Modell XT ausgeblendet. Somit braucht
sich der Anwender nur noch mit den projektrelevanten Vorgehensbausteinen
und Projektdurchführungsstrategien auseinander setzen. 41
Abbildung 9 zeigt die Auswahl des Projekttyps mit Hilfe des V-Modell XT Projektassistenten.
In Abbildung 10 ist zu sehen, wie der V-Modell XT Projektassistent
die projektunrelevanten Merkmale ausblendet. Der Anwender kann sich
nun durch Anklicken für eine Projektdurchführungsstrategie und für zusätzliche
Vorgehensbausteine entscheiden.
Der V-Modell XT Projektassistent bietet weiterhin an, getailorte Dokumentvorlagen,
Dokumentationen und einen Projektplan zu exportieren. Durch diese vorgefertigten
Dokumente wird der Einstieg in das Projekt erleichtert.
Bei dem Export der Dokumentation werden nur die Beschreibungen exportiert,
die für das aktuelle Projekt notwendig sind. Somit muss sich der Anwender
nicht durch Beschreibungen durcharbeiten, die nicht für sein Projekt relevant
sind.
41 Vgl. KBSt (2004), Teil 1 S. 18-19.

28
Abbildung 9: Auswahl des Projekttyps
Abbildung 10: Auswahl der Projektdurchführungsstrategie
und der Vorgehensbausteine

Im V-Modell XT wird unter der Auswahl des Projekttyps, den Vorgehensbausteinen
und der Projektdurchführungsstrategie der Begriff Tailoring verstanden.
42 Dieses Tailoring unterstützt der V-Modell XT Projektassistent.
29
Werden allerdings Anpassungen benötigt, die nicht im V-Modell XT Standard
enthalten sind, ist es möglich sie über den V-Modell XT Editor hineinzutailorn.
Der V-Modell XT Editor ermöglicht das V-Modell XT über den Standard hinweg
für die spezifischen Anforderungen anzupassen. Mit diesem Editor wurde der V-
Modell XT Standard auch selbst entwickelt.
Der V-Modell XT Standard bietet mit dem Projekttyp „Einführung und Pflege
eines organisationsspezifischen Vorgehensmodells“ eine Vorgehensweise, um
das V-Modell XT an die individuellen Bedürfnisse anzupassen.
Abbildung 11: V-Modell XT Editor
42 Vgl. KBSt (2004), Teil 1 S. 18.

30
Abbildung 11 zeigt den V-Modell XT Editor. Über dem Dateibaum auf der linken
Seite wird ausgewählt was geändert bzw. hinzufügen werden soll. Über die
rechte Seite wird das ausgewählte Element mit Werten gefüllt.

5 Konzeptbildung
31
Aus den Vorgehensmodellen aus Kapitel 3 und dem V-Modell XT soll nun ein
Konzept für ein V-Modell XT für einen SAP Releasewechsel entwickelt werden.
Bei dem neuen V-Modell XT wird berücksichtigt, dass der Auftragnehmer andere
Aktivitäten zu erledigen hat, als der Auftraggeber. Aus diesem Grund werden
zwei Vorgehensmodelle, spezielle für die jeweiligen Bedürfnisse, entwickelt.
Diese zwei Vorgehensmodelle lassen sich durch gleiche Schnittstellen zu einem
Vorgehensmodell zusammenfassen.
5.1 Konzept für das Modell des Auftraggebers
Zuerst wird das Konzept für das Vorgehensmodell des Auftraggebers vorgestellt.
Ausgangspunkt für die Konzeptbildung ist der V-Modell XT Projekttyp „Systementwicklungsprojekt
(AG)“ mit den Projektmerkmalen „Systemintegration“ und
„AG mit einem AN“.
Abbildung 12 zeigt die Entscheidungspunkte des oben genannten Projekttyps.
Doch wie zu sehen ist, fehlt bei diesem Vorgehen eine genaue Analyse des
SAP Systems, wie sie im Phasenmodell Redocumentation Scout vorgestellt
wurden. Aus diesem Grund werden zwischen den Entscheidungspunkten „Projekt
definiert“ und „Anforderung festgelegt“ drei weitere Entscheidungspunkte
eingeführt, nämlich „Datenextrakt“, „Datenanalyse“ und „Direkte Überführung in
Prozessmodelle“ aus dem Phasenmodell Redocumentation Scout.
Abbildung 13 zeigt welche Entscheidungspunkte aus dem Vorgehensmodell
und welche aus dem Phasenmodell Redocumentation Scout stammen.
Im letzten Schritt werden die neuen Entscheidungspunkte noch an die Form
des V-Modell XT angepasst. Aus „Datenextrakt“ wird „Daten extrahiert“, aus
„Datenanalyse“ wird „Daten analysiert“ und zuletzt wird „Direkte Überführung in
Prozessmodelle“ zu „in Prozessmodell überführt“.

32
Abbildung 14 zeigt das fertige Konzept für das V-Modell XT für einen SAP Releasewechsel
AG mit besonderer Kennzeichnung, was speziell für den Auftraggeber
und was von Auftraggeber und Auftragnehmer erledigt werden muss.

33
Abbildung 12: Entscheidungspunkte des Systementwicklungsprojekt (AG)
Quelle: in Anlehnung an KBSt (2004), Teil 3 S. 16.

34
Abbildung 13: Konzept Vorgehensmodell AG
Quelle: Eigene Darstellung.

Abbildung 14: V-Modell XT für einen SAP Releasewechsel AG
Quelle: Eigene Darstellung.
35

36
5.2 Konzept für das Modell des Auftragnehmers
Ausgangspunkt für das Konzept des Modells für den Auftragnehmer ist der V-
Modell XT Projekttyp „Systementwicklungsprojekt (AN)“ mit den Projektmerkmalen
„Systemintegration“ und „AN ohne Unterauftragnehmer“ und der Projektdurchführungsstrategie
„Inkrementelle Systementwicklung (AN)“.
Abbildung 15 zeigt die Entscheidungspunkte des oben genannten Projekttyps.
Hier fällt allerdings auf, dass es zu der Implementation Roadmap keine gravierenden
Unterschiede gibt. Zwar hat die Implementation Roadmap nur eine Phase
um die „Business Blueprints“ zu entwickeln und im V-Modell XT gibt es drei
Phasen um letztendlich zu dem „Feinkonzept“ zu gelangen. Auch die Phase
„Realisierung“ der Implementation Roadmap wird im V-Modell XT in den Phasen
„Systemelemente realisiert“ und „System integriert“ aufgeteilt. Aber die eigentliche
Vorgehensweise unterscheidet sich kaum.
Es gibt allerdings eine Phase innerhalb der Implementation Roadmap, die im V-
Modell XT in dieser Form nicht vorgesehen ist. Und diese ist die Phase „Go Live
& Support“. Diese Phase muss somit in das neue V-Modell XT hineingetailort
werden.
Abbildung 16 zeigt die Überführung der Implementation Roadmap in das V-
Modell XT.
Auch hier wird der Entscheidungspunkt „Go Live & Support“ der V-Modell XT
Form angepasst und in „Go Live & Support abgeschlossen“ umbenannt.
Abbildung 17 zeigt das fertige Konzept für das V-Modell XT für einen SAP Releasewechsel
(AN) mit besonderer Kennzeichnung, was speziell für den Auftragnehmer
und was von Auftraggeber und Auftragnehmer erledigt werden
muss.

37
Abbildung 15: Entscheidungspunkte des Systementwicklungsprojekt (AN)
Quelle: in Anlehnung an KBSt (2004), Teil 3 S. 19.

38
Abbildung 16: Konzept Vorgehensmodell AN
Quelle: Eigene Darstellung.

Abbildung 17: V-Modell XT für einen SAP Releasewechsel AN
Quelle: Eigene Darstellung.
39

5.3 Konzept für das V-Modell XT für eine SAP Releasewechsel
40
Mit der Zusammenführung der Konzepte für den Auftraggeber und den Auftragnehmer
zu einem einzigen Konzept, entsteht das Konzept für das V-Modell XT
für einen SAP Releasewechsel.
Abbildung 18 zeigt das gesamt Konzept für das V-Modell XT für einen SAP Releasewechsel
mit spezieller Kennzeichnung der Aufgaben des Auftraggebers
und der Auftragnehmers.

41
Abbildung 18: V-Modell XT für einen SAP Releasewechsel
Quelle: Eigene Darstellung.

42
6 Vorstellung der Ergebnisse
Die technische Umsetzung des Konzepts geschieht mit dem V-Modell XT Editor.
Mit dessen Hilfe wird die V-Modell XT.xml 43 verändert. Wird anschließend
der V-Modell XT Projektassistenten gestartet, erkennt er diese Änderungen und
zeigt diese an.
Da Auftraggeber und Auftragnehmer getrennt betrachtet werden, ist es auch
notwendig für jeden der Beiden einen Projekttyp zur Verfügung zu stellen.
Die neuen Projekttypen sind „SAP Releasewechsel (AG)“ und „SAP Releasewechsel
(AN)“.
Abbildung 19: Auswahl der Projekttypen im getailorten Projektassistenten
43 XML = Extensible Markup Language

6.1 SAP Releasewechsel (AG)
43
Wird der Projekttyp „SAP Releasewechsel (AG)“ ausgewählt, wird sofort angezeigt,
dass das Projekt exportiert werden kann. Dies bedeutet, dass alle verpflichtenden
Einstellungen bereits gesetzt sind.
Auch die bestimmenden Projektmerkmale „Systemintegration“ und „AG mit einem
AN“ wurden bereits gesetzt. Werden diese Projektmerkmale nachträglich
verändert, wird die Auswahl des Projekttypen automatisch gelöscht. Dies bedeutet,
dass für den Projekttyp „SAP Releasewechsel (AG)“ diese Projektmerkmale
verpflichtend sind.
Im Register „Anwendungsprofil“ gibt es keine Änderungen zum Standard V-
Modell XT. Hier kann der Anwender weitere Projektmerkmale definieren.
Abbildung 20: Register Anwendungsprofil
Im nächsten Register „Vorgehensbausteine und Projektdurchführungsstrategien“
ist bereits die hineingetailorte Projektdurchführungsstrategie „Vergabe und

44
Durchführung eines Systementwicklungsprojektes für einen SAP Releasewechsel“
ausgewählt worden. Diese Projektdurchführungsstrategie ist die einzige,
die für diesen Projekttypen zur Verfügung gestellt wird. Über diese Projektdurchführungsstrategie
wird die Abfolge der Entscheidungspunkte bestimmt, die
in Abbildung 14 bereits gezeigt wurde.
Auch auf der linken Seite bei den Vorgehensbausteinen sind bereits einige
ausgewählt worden. Unter den ausgewählten Vorgehensbausteinen sind die
verpflichtenden Vorgehensbausteine des V-Modell XT Kerns, Vorgehensbausteine
für die Schnittstelle zwischen Auftraggeber und Auftragnehmer, wie
bspw. „Vertragsschluss (AG)“ oder „Lieferung und Abnahme (AG)“, aber auch
ein neuer Vorgehensbaustein „Analyse und Bewertung des SAP Systems“. Dieser
Vorgehensbaustein definiert die Aktivitäten für die Entscheidungspunkte
„Daten extrahiert“, „Daten analysiert“ und „in Prozessmodelle überführt“.
Abbildung 21: Vorgehensbausteine und Projektdurchführungsstrategie
für den Projekttyp "SAP Releasewechsel (AG)"

45
Abbildung 22: Planung der Entscheidungspunkte für den Projekttyp "SAP
Releasewechsel (AG)"
Die Vorgehensbausteine, die nicht ausgewählt wurden und inaktiv sind, sind für
diesen Projekttyp nicht relevant.
Der Anwender hat zusätzlich die Möglichkeit die optionalen Vorgehensbausteine
„Evaluierung von Fertigprodukten“, „Systemsicherheit“, „Kaufmännisches
Projektmanagement“, „Messung und Analyse“ auszuwählen.
Über den Button „Planung“ kann der Anwender die Entscheidungspunkte mit
geplanten Fertigstellungsterminen versehen. Abbildung 22 zeigt alle Entscheidungspunkte,
die für diesen Projekttyp relevant sind.
Wie bereits in Kapitel 4.3 beschrieben, können Dokumentvorlagen exportiert
werden. Zusätzlich zu den Standard V-Modell XT Produktvorlagen, gibt es nun
eine weitere Produktgruppe: „Analyse und Bewertung des SAP-Systems“. Diese
Produktgruppe ist durch den verpflichtenden Vorgehensbaustein „Analyse
und Bewertung des SAP-Systems“ hinzugekommen. Zu dieser Produktgruppe
gehören die Produkte „Datenanalyse“, „Datenextrakt“ und „Soll-Prozessmodell“.

47
Abbildung 24: Dokumentation des Projektes "SAP Releasewechsel (AG)"
Teil 1 und 2 der Dokumentation wurde nicht angepasst. In Teil 1 sind die
Grundlagen des Standard V-Modell XT beschrieben und in Teil 2 wird anhand
eines Beispiels der Ablauf im Projekt dargestellt. Diese zwei Teile dienen dazu,
dass der Anwender ein Grundverständnis über das V-Modell XT erlangt. Aus
diesem Grund ist es nicht sinnvoll diese zwei Teile zu ändern.

6.2 SAP Releasewechsel (AN)
48
Wird der Projekttyp „SAP Releasewechsel (AN)“ ausgewählt, wird sofort angezeigt,
dass das Projekt exportiert werden kann. Somit sind auch hier alle verpflichtenden
Einstellungen bereits gesetzt.
Anlog zu dem Projekttyp „SAP Releasewechsel (AG)“ sind auch hier die gesetzten
Projektmerkmale „Systemintegration“ und „AN ohne Unterauftragnehmer“
verpflichtet.
Auch bei diesem Projekttyp wurden keine Änderungen im Register „Anwendungsprofil“
vorgenommen.
Allerdings gibt es wieder einen neuen Vorgehensbaustein und eine weitere Projektdurchführungsstrategie.
Die neue Projektdurchführungsstrategie heißt „SAP
Releasewechsel (AN)“ und ist die einzig mögliche Projektdurchführungsstrategie
für diesen Projekttyp. Die Abfolge der Entscheidungspunkte, die diese Projektdurchführungsstrategie
festlegt, wurde bereits in Abbildung 17 gezeigt.
Der neue Vorgehensbaustein heißt „Go Live & Support“. Dieser Vorgehensbaustein
definiert die Aktivitäten, die für den neuen Entscheidungspunkt „Go Live &
Support abgeschlossen“, zu erledigen sind. Das Projektteam, unter der Verantwortlichkeit
des Projektleiters des Auftragnehmers, bleiben noch so lange bei
dem Auftraggeber, bis das neue SAP System eine ausreichende Stabilität erreicht
hat. Dabei unterstützen sie auch die Anwender, so dass diese sich
schnell im neuen System zurechtfinden.

Abbildung 25: Vorgehensbausteine und Projektdurchführungsstrategie
für den Projekttyp "SAP Releasewechsel (AN)"
49
Abbildung 26: Planung der Entscheidungspunkte für den Projekttyp "SAP
Releasewechsel (AN)"

50
Auch hier kann der Anwender über den Button „Planung“ die Entscheidungspunkte
mit geplanten Fertigstellungsterminen versehen. Abbildung 26 zeigt alle
Entscheidungspunkte, die für diesen Projekttyp relevant sind.
Bei diesem Projekttyp ist zusätzlich zu den Standard-Produkten, nur das Produkt
„Support“ hinzugekommen. Da bei diesem Produkt kein formales Dokument
erstellt werden muss, gibt es bei diesem Projekttyp auch keine zusätzliche
Dokumentvorlage. Durch die Exportfunktion des V-Modell XT Projektassistenten
werden somit nur die Standard-Dokumentvorlagen exportiert.
Dennoch muss dieses Produkt bearbeitet werden. Über die Projektplan-Export-
Funktion, wird dem Anwender angezeigt, wann es bearbeitet werden soll.
Abbildung 27: Projektplan zu dem Projekt "SAP Releasewechsel AN"

51
Ebenfalls bei diesem Export der Dokumentation, werden nur die Beschreibungen
exportiert, die für dieses Projekt relevant sind. Und auch dieses Mal wurden
die Teile 1 und 2 der Dokumentation aus den vorher genannten Gründen nicht
verändert.
Abbildung 28: Dokumentation des Projektes "SAP Releasewechsel (AN)"

6.3 Bekannter Fehler
52
Die Dokumentation für die getailorten Projekte kann sowohl per HTML (Hypertext
Markup Language), als auch per PDF (Portable Document Format) exportiert
werden. Die Export-Funktion via HTML funktioniert ohne Probleme. Allerdings
funktioniert die Export-Funktion via PDF im Teil 3 nicht. Und somit auch
nicht beim Komplett-Export.
Dieses kann durch kleine Inkonsistenzen bei der Anpassung der V-Modell-
XT.xml herführen. Die aktuelle V-Modell XT Editor Version 3.2 unterstützt bis
her noch nicht das Auffinden dieser Inkonsistenzen. Diese Funktion soll in der
nächsten Version implementiert werden. 44
44 Vgl. Sihling (2007).

53
7 Das Projekt „SAP Releasewechsel“ einer oberen Bundesbehörde
Im Folgenden wird das Projekt „SAP Releasewechsel“ einer oberen Bundesbehörde
vorgestellt.
Diese Bundesbehörde besitzt neben einer Zentrale mehrere Außenstellen, die
sich in ganz Deutschland verteilen.
Das Projekt „SAP Releasewechsel“ wird in der Zentrale der Bundesbehörde
durchgeführt.
Auf Grund der Kündigung des Wartungsvertrages der aktuellen Version R/3
4.6c seitens der SAP AG, ist diese Bundesbehörde auf einen Releasewechsel
auf die Version SAP ERP 6.0 angewiesen.
Der Releasewechsel auf die neue Software soll zusätzlich die erhöhten organisatorischen
und technischen Ansprüche an die IT-Landschaft der Bundesbehörde
gerecht werden. Daher ist der Aufbau einer einheitlichen Serviceorientierten-Architektur
(SOA), die das SAP System mit der übrigen IT-
Landschaft verbindet, geplant.
Weiterhin soll bei diesem Releasewechsel eine Rückführung in den SAP Standard
erfolgen. Nur die Softwareanpassungen, die nicht durch SAP ERP 6.0 unterstützt
werden, sollen in das neue System migriert werden.

54
7.1 Vorgehensweise im Projekt „SAP Releasewechsel“
Da das Projekt „SAP Releasewechsel“ bereits begonnen hatte, bevor das neue
V-Modell XT für einen SAP Releasewechsel entwickelt wurde, gibt es dort ein
anderes Vorgehen.
Die Basis dieses Vorgehens ist das Standard V-Modell XT. Das Standard V-
Modell XT sieht das erste klein V (Daten extrahiert, Daten analysiert, ins Prozessmodell
überführt) nicht vor. Somit wird vor dem Entscheidungspunkt „Anforderung
definiert“ keine Ist-SAP-System-Analyse durchgeführt.
Diese Ist-Analyse wird in diesem Projekt Teil der Ausschreibung sein, und ist
somit vom Auftragnehmer zu erstellen.
Zusätzlich gibt es noch weitere Gründe, weshalb die Ist-Analyse nicht vom Auftraggeber
selbst erledigt wird.
Zum einen kann es passieren, dass die Dokumentation der SAP-Einführung,
bzw. des letzten Releasewechsels nicht aussagekräftig genug ist. Und kann
somit nicht als Grundlage für eine Ist-Analyse dienen. Weiterhin ist es möglich,
dass das benötigte Know-how fehlt, um ein Reverse Engineering 45 durchzuführen.
Auch der zeitliche Ablauf kann ein Grund sein, dass auf eine Ist-Analyse verzichtet
wird. So kann es bspw. passieren, dass das im Haushalt zugesicherte
Budget gestrichen wird, sollte das Projekt nicht innerhalb des laufenden Jahres
zu einer Ausschreibung kommen. Dieser Grund führt somit zu einem Komplett-
Abbruch des Projektes.
Es besteht in der Praxis auch die Möglichkeit diese Ist-Analyse in einer separaten
Ausschreibung durch einen Auftragnehmer durchführen zu lassen. Der
Nachteil an dieser Variante ist der, dass sich dieser Auftragnehmer an der eigentlichen
Ausschreibung für die Umsetzung nicht mehr beteiligen darf. Dadurch
wird bereits im Vorfeld ein möglicher kompetenter Auftraggeber ausge-
45
„Beim Reverse Engineering“ ist das vorhandene Software-System der Ausgangspunkt der
Analyse. Balzert (1998), S. 595.

55
schlossen. Des Weiteren kann es bei dieser Variante zu unerwünscht langen
Projektlaufzeiten kommen, da zwei Ausschreibungen vorbereitet und ausgewertet
werden müssen.
Da in diesem Projekt somit nicht vorher bekannt ist, welche Anpassungen gemacht
wurden, muss eine andere Vorgehensweise gewählt werden, um dennoch
den Releasewechsel durchzuführen.
Diese Vorgehensweise ist in diesem Projekt wie folgt geplant:
In einem Testsystem wird über die alte SAP-Version die neue Version drüberinstalliert.
Stoppt die Installation aufgrund einer nicht kompatiblen Anpassung,
wird sich diese Anpassung notiert und die Installation weiter geführt.
Am Ende existiert eine Liste der Anpassungen des alten SAP-Systems, die
nicht von dem neuen SAP-System übernommen werden konnten. Anschließend
müssen die Anpassungen so verändert werden, dass das neue SAP-System
die Anpassungen akzeptiert. Dieser Vorgang wird so oft wiederholt, bis der Installationsvorgang
ohne Fehlermeldungen durchläuft.
Diese Installation geht dann nach einer Test-Phase in den produktiven Einsatz.
Erst im zweiten Schritt wird geprüft, welche Anpassung des alten SAP-Systems
nicht mehr benötigt werden und somit durch Standard-Funktionen ersetzt werden
können. Auch fachliche Neu-Anforderungen werden erst in diesem zweiten
Schritt implementiert.

56
7.2 Mögliche Risiken dieses Vorgehens
Durch dieses Vorgehen entstehen weitere Risiken, die zu beachten sind.
Da im Vorfeld nicht beschrieben werden kann, wie viele Anpassungen in dem
alten SAP Release vorhanden sind, ist der Auftragnehmer nicht in der Lage eine
vollständige Kalkulation der Aufwende durchzuführen. Dem entsprechend
muss er sein Angebot aus Erfahrungswerten mitteln. Doch es bekommt der jenige
den Zuschlag für die Ausschreibung, der das wirtschaftlichste Angebot bietet,
auch wenn dieser Preis nicht mit den Aufwenden übereinstimmt.
Übersteigen die Kosten des Auftragnehmers der Angebotssumme, wird er versuchen
über den Angebotspreis hinaus Geld zu bekommen. Somit kann nicht
genau gesagt werden, dass das günstigste Angebot ausgewählt wurde.
Durch diese unkalkulierbaren Aufwendungen übersteigen die Kosten schnell
das eingeplante Budget. So ist es möglich, dass das Budget, das für den zweiten
Schritt geplant war, schon für den ersten Schritt ausgegeben werden muss.
Und die fachlich benötigten Änderungen können nicht durchgeführt werden.
Er schlimmerer Fall ist es, wenn weitere Aufwendungen erforderlich sind, aber
das vom Auftraggeber eingeplante und genehmigte Budget ist verbraucht.
Bleibt das neue System dann in der unfertigen Fassung? In diesem Fall wurde
Geld ausgegeben, ohne ein neues System zu bekommen.
Durch das Vorgehen in den oben genannten zwei Schritten, kann es passieren,
dass im ersten Schritt Geld für Anpassungen ausgegeben wird. Im zweiten
Schritt wird dann festgestellt, dass diese Anpassungen nicht mehr benötigt werden.
Dadurch sind unnötige Kosten entstanden.
Ein Ziel des V-Modell XT ist es Kosten zu minimieren und die Kosten transparent
zu halten. Dieses Ziel kann bei einer derartigen Vorgehensweise nicht gewährleistet
werden.

8 Schlussbetrachtung
57
8.1 Zusammenfassung der Ergebnisse
Im Rahmen dieser Arbeit wurde das V-Modell XT an die Besonderheiten eines
SAP Releasewechsels angepasst.
Dabei wurde die V-Modell-XT.xml mit dem V-Modell XT Editor getailor’, so dass
eine lauffähige Version des V-Modell XT Projektassistenten entstand, die die
Besonderheiten eines SAP Releasewechsels unterstützt.
Aus dieser Version des V-Modell XT Projektassistenten lassen sich zwei Vorgehensmodelle
für einen SAP Releasewechsel, Dokumentvorlagen und eine
Dokumentation exportieren.
Das neue V-Modell XT enthält nun zwei neue Projekttypen. Der eine Projekttyp
unterstützt die Arbeiten des Auftraggebers bei einem SAP Releasewechsel, der
andere Projekttyp die des Auftragnehmers. Durch diese Trennung sind nur die
Arbeiten zu erledigen, die für ihre Rolle relevant sind.
Auf der Auftraggeberseite sind mehr Anpassungen erforderlich gewesen, als
auf der Auftragnehmerseite. Das Vorgehensmodell des Auftragnehmers wurde
nur um eine Phase erweitert, hingegen das Vorgehensmodell des Auftraggebers
eine Erweiterung von drei weiteren Phasen mit drei weiteren Produkten
benötigte.

8.2 Weitere Einsatzmöglichkeiten
58
Das angepasste Vorgehensmodell wurde speziell für einen Releasewechsel
eines SAP-Systems entwickelt. Doch in wie weit ist es für einen Releasewechsel
anderer Software nutzbar? Beziehungsweise welche Änderungen sind erforderlich
um es allgemein für Releasewechsel von Software einzusetzen?
Welche Anpassungen sind erforderlich, dass dieses Modell selbst für die Einführung
einer Software nutzbar ist?
Das Standard V-Modell XT sieht einen Projekttyp „Einführung und Pflege eines
organisationsspezifischen Vorgehensmodells“ vor. Mit diesem Projekttyp kann
das V-Modell XT an Besonderheiten einer Organisation angepasst werden.
Macht es dann auch Sinn, dass V-Modell XT für einen SAP Releasewechsel an
eine Organisation anzupassen?
Seitens der KBSt wird das Standard V-Modell XT stetig weiterentwickelt. In wie
weit ist das V-Modell XT für einen SAP Releasewechsel mit einer neuen V-
Modell XT Version nutzbar? Ist eine einfache Migration möglich, oder erfordert
es erheblichen Aufwand das V-Modell XT für einen SAP Releasewechsel mit
dieser neuen Standard Version zu vereinen?

8.3 Kritische Würdigung
59
Dieses Vorgehensmodell dient dem Projektteam und dem Projektleiter als Leitfaden
das Projekt eines SAP Releasewechsels durchzuführen. Es liefert allerdings
keine fertigten Produkte. Diese Aktivitäten müssen immer noch von dem
Projektteam bearbeitet werden.
Das Vorgehensmodell soll die Vorgehensweise eine SAP Releasewechsels
transparent machen und damit Komplexität reduzieren, doch es verhindert
nicht, dass ein solcher Releasewechsel sehr zeit- und kostenintensiv ist. Durch
seine strukturierte Vorgehensweise kann aber dennoch das Auftreten unkalkulierbarer
Kosten verhindert werden.
Die in der Literatur empfohlen Vorgehensweisen und damit auch das daraus
entwickelte V-Modell XT für einen SAP Releasewechsel, lassen sich unter bestimmten
Voraussetzungen nur schwer in der Praxis anwenden. Entschließt
sich aber der Projektleiter gegen einer solchen Vorgehensweise, muss er mit
erheblichen zeitlichen und finanziellen Risiken rechnen. Und es stellt sich die
Frage, ob es nicht dennoch sinnvoller wäre nach den Vorgaben der Vorgehensmodelle
vorzugehen.

Literaturverzeichnis
60
Appelrath, Hans-Jürgen / Ritter, Jörg (2000),
R/3-Einführung, Methoden und Werkzeuge,
Berlin et al., 2000.
Arb, Reto C., von (1997),
Vorgehensweisen und Erfahrungen bei der Einführung von Enterprise-
Management-Systemen dargestellt am Beispiel von SAP R/3,
Bern, 1997,
http://www.digital-publications.ch/vonarb/vonarb.zip,
Stand 06.07.2007.
Balzert, Helmut (1998),
Lehrbuch der Software-Technik,
Heidelberg, Berlin, 1998.
Gadatsch, Andreas (2001),
Management von Geschäftsprozessen,
Braunschweig, Wiesbaden, 2001.
Gadatsch, Andreas (2002a),
Einsatz betriebswirtschaftlicher Standardanwendungssoftware,
in: Andreas Gadatsch / Reinhard Mayr (Hrsg.): Best-Practice mit SAP®,
Braunschweig, Wiesbaden, 2002, S. 3-14.
Gadatsch, Andreas (2002b),
Strategien zur Einführung und Implementierung betriebswirtschaftlicher Standardanwendungssoftware,
in: Andreas Gadatsch / Reinhard Mayr (Hrsg.): Best-Practice mit SAP®,
Braunschweig, Wiesbaden, 2002, S. 15-30.
Gadatsch, Andreas (2003),
Grundkurs Geschäftsprozess-Management,
3. Auflage, Wiesbaden, 2003.
Gronau, Norbert (1999),
Management von Produktion und Logistik mit SAP® R/3®,
3. Auflage, München, Wien, 1999.
KBSt (2004),
V-Modell® XT,
http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.2/Dokumentation/pdf/V-Modell-
XT-Komplett.pdf,
2004, Stand 06.07.2007.

KBSt (2006),
Empfehlung des V-Modell XT durch die KBSt,
http://www.kbst.bund.de/cln_047/nn_837404/SharedDocs/Hintergrundinfoskbst/2005/empfehlung-des-v-modell-xt-durch-die-kbst.html,
2006, Stand 06.07.2007.
61
Rau, Hans-Joachim (2006),
Restandardisierung von SAP R/3-Systemen,
Saarbrücken, 2006.
SAP (2005),
Gemeinsam die Zukunft gestalten,
http://www.sap.com/germany/company/press/pdf/Emp_Rep_2005_D.pdf,
2005, Stand 06.07.2007.
Sihling, Marc (2007),
PDF Export nach XML-Veränderung mit dem Editor,
http://www.kbst.bund.de/kbst_forum/showthread.php?t=924,
2007, Stand 06.07.2007.

Glossar
Add-On Programmierte Softwarekomponente, die nicht zum
Standardprodukt gehört
Baseline-
Konfiguration
62
Einrichten von Grundeinstellungen im SAP
Business Blueprint Entwurfsdokument für ein einzuführendes SAP System
Change Management Projektteam, dass für Änderungen im Projekt verantwortlich
ist
Customizing Anpassen einer Software mittels Setzen von Parametern
ohne Programmierung
Cut Over Wechsel von dem Alt-System zum neuen SAP System
Entscheidungspunkt Evaluationspunkt des Projektes
Migration Wechsel von Software
Projektdurchführungsstrategie
Abfolge von Entscheidungspunkten
Release Version einer Software
SAP Hersteller von betrieblicher Anwendungssoftware, sowie
dessen Produkte
Support Problemorientierte Beratungsdienstleistung
Tailoring Anpassung des V-Modell XT
V-Modell XT Vorgehensmodell für IT-Projekte
V-Modell XT Editor Software-Tool, das Anpassungen über den V-Modell
XT Standard hinaus erlaubt

V-Modell XT Projektassistenten
63
Software-Tool, das die Nutzung des V-Modell XT unterstützt
Vorgehensbaustein Definiert die Aufgabenstellung im V-Modell XT Projekt

Eidesstattliche Erklärung
Name: Anita Ulenaers
64
Adresse: Breslauer Str. 41, 53840 Troisdorf
Erklärung
Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbst angefertigt
habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken
sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Unterschrift Sankt Augustin, den 10.07.2007