Entwicklung einer Fallstudie für das Customizing von Organisationsstrukturen zur Einführung von SAP R/3

MA-Thesis / Master von Ernst Schulten

Einleitung:

Betriebswirtschaftlich agierende Unternehmen bilden ein Gesamtsystem zur Zielerfüllung, das sich in die Teilsysteme Betriebliches Informationssystem und Basissystem untergliedert. Innerhalb des Basissystems werden zumeist physisch handhabbare Objekte, wie z.B. Produkte, im Informationssystem hingegen Objekte vom Typ Information verarbeitet. Unter einem Informationssystem kann der gesamte informationsverarbeitende Teil eines Unternehmens verstanden werden, der sich nicht nur durch technische Gegebenheiten, wie z.B. Computer- und Telekommunikationsanlagen, auszeichnet, sondern auch durch soziale Interaktion, wie z.B. Kooperation/Kommunikation, bestimmt wird.

Das in der Fallstudie ‘Logistik im Industriebetrieb’ agierende mittelständische Unternehmen ist ein produzierendes Unternehmen. Sein Basissystem bezieht sich hauptsächlich auf die Produktions- und Montageabteilung, in der Motorradscheinwerfer nach Kundenauftrag hergestellt werden. Das Informationssystem kommt auf Managementebene zum Einsatz. Hier nutzt das Management u.a. ein SAP R/3-System, um die informationsverarbeitenden Aufgaben zur Zielerfüllung durchzuführen und um das Basissystem zu überwachen.

Betriebliche Anwendungssysteme (AwS) zählen nicht nur zum technischen Teil von Informationssystemen, sondern auch zu den automatisierten Aufgabenträgern eines Unternehmens. Ferner kann man Anwendungssysteme danach unterscheiden, ob sie dem betrieblichen Lenkungssystem, d.h. der Planung, der Steuerung und der Kontrolle, oder dem betrieblichen Leistungssystem, d.h. der Administration, Disposition und Durchführung, zuzuordnen sind.

Im vorliegenden Zusammenhang soll unter einem AwS immer eine konkrete Installation eines Anwendungssoftwareprodukts auf einem Rechnersystem verstanden werden, wie sie bei einem Standardsoftwareprodukt, wie z.B. bei SAP R/3, im Rahmen einer mehrstufigen Strategie – einer sog. mehrstufigen Client-/Server-Architektur – erfolgt.

Unternehmensarchitektur am Beispiel des SOM:

Wie alle anderen Teilsysteme eines Unternehmens müssen betriebliche AwS zu den zentralen und strategisch bedeutsamen Zielen eines Unternehmens, dem Objektsystem, beitragen können. Die Org./DV-Abteilung ist im Regelfall für den Aufbau und die Parametrisierung des AwS verantwortlich. Sie sieht das Objektsystem gemäß dem Semantischen Objektmodell (SOM) als dreischichtige Pyramide, deren Fundament (unterste dritte Modellebene) die Ressourcen Mitarbeiter, betriebliche AwS sowie die Maschinen und Anlagen bilden. Aus Gründen eines höheren Detaillierungswunsches und einer stärkeren Komplexitätsreduktion werden Mitarbeiter in Organisationseinheiten und Planstellen einer Aufbauorganisation eingegliedert.

Mitarbeiter, Maschinen und betriebliche AwS interagieren im Rahmen ihrer Zielerfüllung, die mittels eines Geschäftsprozessmodells auf der zweiten Modellebene formuliert werden und so die Innensicht des betrieblichen Systems darstellt. Das Geschäftsprozessmodell beschreibt die Struktur und den Ablauf von typischen Geschäftsprozessen eines Unternehmens, die durch Mitarbeiter und AwS unterstützt werden. Die Ziele, die durch das Zusammenwirken aller am Unternehmensprozess beteiligten Personen und Betriebsmittel erreicht werden sollen, werden in einem Unternehmensplan festgelegt, der auf der obersten Ebene des Modells (erste Modellebene) die Außensicht des betrieblichen Systems beschreibt.

Bei der Einführung oder Parametrisierung von Enterprise Resource Planning-Standardsoftware-Produkten (kurz ERP-Software) orientiert sich die Org./DV-Abteilung in der Regel an einer Top-down-Vorgehensweise, da sie Ablauf- und Aufbauorganisation sowie die Beschaffung notwendiger Ressourcen an den Zielen des Unternehmensplans ausrichtet und nicht von der Maximalfunktionalität des AwS (z.B. der SAP R/3-Software) abhängig machen darf. In diesem Zusammenhang bedarf es einer besonderen und beinahe selbstverständlichen Flexibilität der ERP-Software, da diese an sich häufig ändernde wirtschaftspolitische Rahmenbedingungen und Herausforderungen angepasst werden muss.

Die tägliche Praxis zeigt jedoch, dass die Top-down-Vorgehensweise nicht immer praktikabel ist. Beobachtungen und Gespräche mit Mitarbeitern, die während der Einführung der R/3-Module CO/FI bei einem Großunternehmen in Aschaffenburg durchgeführt wurden, ergaben insbesondere organisatorische und juristische Probleme bei der Substitution von Personal durch AwS. Die vielfältige Berücksichtigung angepeilter Unternehmensziele (z.B. die Ablösung von Personal durch Maschinen) und den daraus abgeleiteten Geschäftsprozessmodellen (z.B. weitestgehend flache Hierarchien und automatisierte Prozesse), Veränderungen des augenblicklichen Zustands des Unternehmens und den weitaus flexibleren Möglichkeiten betrieblicher Standardsoftwareprodukte machen die Auswahl und Einführung von ERP-Software zu einem komplexen Vorhaben.

Individualprogrammierung, Standardsoftware und Parametrisierung:

Standardsoftwareprodukte werden in systemnahe (z.B. Betriebssysteme, Datenbankmanagementsysteme) und anwendungsnahe Produkte eingeteilt. Ferner wird eine Einteilung der anwendungsnahen Software-Produkte in individualprogrammierte oder standardmäßig erstellte Software vorgenommen. Während die Individualsoftware in einem Unternehmen speziell für einen Anwendungsfall entwickelt wird, muss Standardsoftware dagegen einen möglichst flexiblen und universellen Anwendungsbereich u.U. vieler Unternehmen abdecken.

Hohe Standardisierung wird durch zahlreiche wissenschaftliche Erkenntnisse (z.B. Normierungen) oder aufgrund von Gesetzen im Steuer- und Handelsrecht des externen Rechnungswesens erreicht. Insbesondere in den letzten Jahren führten zudem Vereinheitlichungen in den Verfahren zur Kostenarten- und -stellenrechnung zu standardisierten Berechnungen bestimmter betriebswirtschaftlicher Methoden, die dann zur Funktionsvielfalt von Standardsoftware-Produkten beitrugen. Die Aufgabe der Org./DV-Abteilungen distanzierte sich zunehmend vom eigentlichen Programmieraufwand und verlagerte den Aufwand zur umfassenden Parametrisierung des Systems in die Fachabteilungen wie z.B. in die des internen und externen Rechnungswesens. Der vor der Parametrisierung notwendige Abgleich der Anforderungen der Fachabteilungen mit den Möglichkeiten der Software macht selbst die Einführung standardisierter Software zu einem aufwändigen und teuren Prozess. Dies liegt in den meisten Fällen daran, dass die Unternehmen die zahlreichen Vor- und Nachteile verschiedener Customizing-Varianten nicht beurteilen können und somit auch nicht wissen, welche Strukturen und Prozesse des Unternehmens auf welche Art am besten mit der Standardsoftware abgebildet werden können.

Das System R/3 der SAP AG kann durch seine große Marktakzeptanz bei den anwendenden Unternehmen und durch die zunehmende Annäherung weiterer Softwareunternehmen an die Vorgaben der SAP als De-facto-Standard für betriebliche ERP-Anwendungssysteme bezeichnet werden. Da sich auch Großunternehmen, wie z.B. die Linde AG, die TRW GmbH & Co. KG, M-real etc., in unmittelbarer Nähe zur Hochschule befinden und in Teilen das System R/3 einsetzen, entschloss sich die FH Aschaffenburg zur Einführung eines ERP-Curriculums u.a. am Beispiel der Software SAP R/3.

Integration von Software:

Mitte der siebziger und Anfang der achtziger Jahre herrschten noch Insellösungen bei den betrieblichen AwS vor. Hierunter verstand man Softwareprodukte, die nur isoliert für eine bestimmte Aufgabe eingesetzt werden konnten. In den achtziger Jahren fand eine verstärkte Integration der Softwareprodukte statt, die zur sog. integrierten Informationsverarbeitung und entsprechenden ERP-Produkten wie dem R/3-System der SAP AG führte. Die Integration wurde durch Datenbanksysteme mit zentralem Datenbankmanagement erreicht, auf denen die Anwendungskomponenten aufsetzten. Auf Basis dieser Datenintegration konnte eine darauf aufbauende Funktionsintegration permanent aggregierte Daten automatisch fortschreiben.

Durch das Internet nahm nicht nur die Intensität der Integration zu, sondern zugleich auch neue Formen an, da durch die Softwareprodukte ebenfalls unternehmensübergreifende Geschäftsprozesse zwischen Geschäftspartnern unterstützt werden mussten. Spätestens hier geriet die Datenintegration an ihre Grenzen, da mehrere Unternehmen meist nicht auf ein gemeinsames Datenbanksystem aufsetzten. An dieser Stelle erfuhr die Funktionsintegration eine starke Herausforderung, da Datenbestände verteilter Unternehmen zumindest in Teilbereichen konsistent gehalten werden mussten. Mit dem Einsatz von Software, die die objektorientierte Integration unterstützte, hat sich das Integrationsproblem von Software über Unternehmensgrenzen hinweg wieder relativiert.

Inhaltsverzeichnis:

	MANAGEMENT SUMMARY	XI
	ABBILDUNGSVERZEICHNIS	XII
	TABELLENVERZEICHNIS	XIII
	ABKÜRZUNGSVERZEICHNIS	XIV
1.	GRUNDLAGEN BETRIEBLICHER ANWENDUNGSSYSTEME	1
1.1	Einführung	1
1.1.1	Unternehmensarchitektur am Beispiel des SOM	2
1.1.2	Individualprogrammierung, Standardsoftware und Parametrisierung	4
1.1.3	Integration von Software	5
1.2	Aufgaben und Geschäftsprozesse in betrieblichen AwS	6
1.2.1	Aufgaben	6
1.2.2	Geschäftsprozesse	7
1.3	Übersicht über Architekturen von betrieblichen AwS	9
1.3.1	Mehrstufige Client/Server-Architekturen (C/S-Modell)	9
1.3.2	Relationale Datenbankmanagementsysteme (RDBMS)	11
1.3.3	Objektorientierte Architekturen	11
1.4	Das System R/3 der SAP AG	12
1.4.1	Client-/Server-Architektur	13
1.4.1.1	Technische Dienste	14
1.4.1.2	Betriebsarten und Logon-Gruppen	14
1.4.1.3	Datenbankmanagement	15
1.4.1.4	Präsentationssystem	15
1.4.2	Internetanbindung	16
1.4.3	Komponenten des R/3-Systems	16
1.4.3.1	Funktionsbezogene Komponenten	17
1.4.3.2	Funktionsübergreifende Komponenten	17
1.5	Organisationsstrukturen des R/3-Systems	18
1.5.1	Logistik (Logistics, LO)	18
1.5.1.1	Materialwirtschaft (Material Management, MM)	19
1.5.1.2	Vertrieb (Sales & Distribution, SD)	20
1.5.2	Rechnungswesen (AC, Accounting)	20
1.5.2.1	Externes Rechnungswesen	20
1.5.2.2	Internes Rechnungswesen	21
1.5.3	Personalwirtschaft	22
2.	VORGEHENSMODELLE ZUR ENTWICKLUNG VON AWS	24
2.1	Entwicklungsprozesse und Vorgehensmodelle	24
2.1.1	Entwicklung von Standardsoftwaresystemen	24
2.1.2	Rückgekoppeltes Mehr-Kreislaufsystem	24
2.1.3	Allgemeines Vorgehensmodell zur Einführung von Softwareprodukten	26
2.1.3.1	Analysephase	26
2.1.3.2	Entwurfsphase	26
2.1.3.3	Realisierungsphase	27
2.1.3.4	Testphase	27
2.1.3.5	Betriebsphase	27
2.1.4	Probleme im Phasenmodell	28
2.1.5	Erweitertes Phasenmodell	28
2.1.5.1	Iteratives Vorgehen	28
2.1.5.2	Inkrementelles Vorgehen	29
2.1.5.3	Partizipatives Verfahren	29
2.1.5.4	Evolutionäres Verfahren	29
2.1.6	Anpassung von Standardsoftware	29
2.1.6.1	Parametrisierung	30
2.1.6.2	Modifikation	30
2.1.6.3	Erweiterung	31
2.2	Vorgehensmodelle zur Einführung von SAP R/3	31
2.2.1	Einordnung der R/3-Einführung	31
2.2.2	Das traditionelle SAP-Vorgehensmodell	32
2.2.3	Die beschleunigte R/3-Einführung – AcceleratedSAP (ASAP)	33
2.2.4	Iteratives Prozess-Prototyping (IPP)	35
2.2.5	DSDM – das dynamische Vorgehensmodell	36
3.	DIE SAP IMPLEMENTATION ROADMAP	38
3.1	Die Phase 1: Projektvorbereitung	39
3.1.1	Projektplanung erstellen	40
3.1.1.1	Der Projektauftrag	40
3.1.1.2	Das Projektmanagement	41
3.1.1.3	Der Projektplan, Projektbudgetplan und Projekteinsatzplan	42
3.1.2	Projektabläufe	43
3.1.2.1	Organisatorische Aufgaben	43
3.1.2.2	Festlegung auf die Einführungsstrategie	44
3.1.2.3	Systemlandschaft definieren	45
3.1.3	Projekt-Kickoff	46
3.1.4	Planung der technischen Anforderungen	46
3.1.5	Qualitätsprüfung Projektvorbereitung	47
3.2	Die Phase 2: Business Blueprint	47
3.2.1	Projektmanagement Business Blueprint	48
3.2.1.1	Veränderungsmanagement (Change Management)	49
3.2.2	Schulung des Projektteams Business Blueprint	49
3.2.3	Systemumgebung entwickeln	49
3.2.3.1	Änderungsaufträge	50
3.2.3.2	Versionsführung	50
3.2.3.3	Entwicklungssystem	50
3.2.3.4	Systemadministration	51
3.2.3.5	Konfiguration des Einführungsleitfadens	51
3.2.4	Organisationsstruktur	51
3.2.5	Geschäftsprozessdefinition	53
3.2.5.1	Erstellung der Business-Blueprint-Dokumente	54
3.2.5.2	Plan für Benutzerschulung und -dokumentation	55
3.2.6	Qualitätsprüfung Business-Blueprint-Phase	55
3.3	Die Phase 3: Realisierung	55
3.3.1	Projektmanagement Realisierung	57
3.3.1.1	Planung für Help Desk und Cut Over	57
3.3.2	Schulung des Projektteams	58
3.3.3	Baseline-Konfiguration und -Abnahme	58
3.3.4	Detail-Konfiguration und -Abnahme	59
3.3.5	Systemverwaltung	59
3.3.6	Entwicklung von Datenkonvertierungsprogrammen	60
3.3.7	Entwicklung von Schnittstellenprogrammen für Anwendungen	60
3.3.8	Entwicklung von Systemerweiterungen	61
3.3.9	Entwicklung von Berichten	62
3.3.10	Entwicklung von Formularen	62
3.3.11	Erarbeitung des Berechtigungskonzepts	62
3.3.12	Einrichtung der Archivierung	63
3.3.13	Abschließender Integrationstest	64
3.3.14	Dokumentation und Schulungsunterlagen für Benutzer	64
3.3.15	Qualitätsprüfung Realisierung	65
3.4	Die Phase 4: Produktionsvorbereitung	65
3.4.1	Projektmanagement Produktionsvorbereitung	66
3.4.2	Benutzerschulung	66
3.4.3	Systemmanagement	66
3.4.4	Detaillierte Planung Cut Over und Support	67
3.4.5	Cut Over	67
3.4.6	Qualitätsprüfung Produktionsvorbereitung	68
3.5	Die Phase 5: Go-Live und Support	68
3.5.1	Produktionssupport	68
3.5.2	Beenden des Projekts	69
4.	WERKZEUGE ZUR EINFÜHRUNG VON SAP R/3	70
4.1	Überblick	70
4.2	Implementation Assistant	70
4.3	Microsoft Project	72
4.3.1	Einsatzbeurteilung der Projektmanagement-Software	72
4.3.2	Projektpläne für die R/3-Einführung	72
4.3.3	Nutzung von Projektplänen mit MS-Project	73
4.4	Question & Answer Database (Q&Adb)	73
4.4.1	Fragen zum Unternehmen	74
4.4.2	Fragen zur Prozesshierarchie	74
4.4.3	Problemdatenbank	75
4.5	Structure Modeler	75
4.6	Concept Check Tool	75
4.7	Business Navigator	76
4.7.1	Prozesshierarchie	77
4.7.2	Komponentenhierarchie	77
5.	DIE FALLSTUDIE ZUM CUSTOMIZING ÜBER DEN IMG	79
5.1	Die Case Study: Historischer Hintergrund	79
5.2	Der Einsatz von Fallstudien an der FH Aschaffenburg	80
5.2.1	Das Vorlesungskonzept an der FH Aschaffenburg	80
5.2.2	Die Rahmenbedingungen von R/3-Fallstudien	81
5.3	Die Customizing-Komponente	82
5.3.1	Der Implementation Guide (IMG)	83
5.3.2	Konfiguration des IMG	84
5.3.3	Projekt- und Konfigurationsüberwachung	84
5.3.4	Durchführung der Konfiguration	85
5.3.5	Transport der Konfiguration auf das Produktivsystem	85
5.4	Die Fallstudie ‘Customizing und Organisationsmanagement’	86
5.4.1	Gegenstand und Anwendungsgebiete der Fallstudie	86
5.4.2	Einstellungen am R/3-System	87
5.4.2.1	Neuanlage der Benutzer	87
5.4.2.2	Namenskonventionen	88
5.4.2.3	Aufheben der Datensatzsperrung	88
5.4.3	Unternehmen und Szenario	89
5.4.3.1	Das Unternehmen Zusuki Aschaffenburg AG (ZAG AG)	89
5.4.3.2	Die Funktionsbereiche	90
5.4.3.3	Das betriebswirtschaftliche Umfeld	91
5.4.4	Die Problem- und Aufgabenstellung	92
5.4.5	Abschließende Hinweise zur Durchführung der Fallstudie	93
5.4.5.1	Grundsätzliche Hinweise	93
5.4.5.2	Aus Dozentensicht	93
5.4.5.3	Aus Studentensicht	95
5.4.5.4	Prüfbarkeit von fallstudienbasierten Lehrveranstaltungen	97
5.4.6	Die Evaluation der Lehrveranstaltung	98
6.	FAZIT	99
	LITERATUR- UND QUELLENVERZEICHNIS	100
	ANLAGEN	103

Textprobe:

Kapitel 2, Vorgehensmodelle zur Entwicklung von AwS:

Entwicklungsprozesse und Vorgehensmodelle:

Entwicklung von Standardsoftwaresystemen:

Durch zunehmende Standardisierung in der Softwareentwicklung gingen die Unternehmen, wie bereits erwähnt, Ende der achtziger Jahren dazu über, die Software den sich ähnelnden Anforderungen verschiedener Nutzer anzupassen. Standardsoftwareprodukte wurden somit das Ergebnis der zunehmenden Abstraktion vom Einzelfall.

Inzwischen änderte sich auch die Art der Softwareentwicklung. Wurde in der Vergangenheit jedes Programm auf das anwendende Unternehmen angepasst, werden heute betriebliche AwS auf Basis von Standardsoftwareprodukten konfiguriert. Im Vordergrund steht somit auch nicht mehr die Programmierung, sondern die Auswahl, die Lizenzierung einer Softwarekopie und die ‘richtige’ Anpassung der standardisierten Software.

Die Entwicklung von AwS als Teil des gesamten betrieblichen Informationssystems verläuft in mehreren parallelisierten Entwicklungsprojekten für unterschiedliche Anwendungsbereiche wie z.B. für die Finanzbuchhaltung, die Produktion oder den Vertrieb. Typische Aufgaben und Phasen lassen sich hierbei anwendungsbereichsübergreifend definieren. Es sind die Phasen Analyse, Entwurf, Realisierung, Test und Betrieb (Produktion), die von einem phasenübergreifenden Projektmanagement gesteuert und kontrolliert werden. Die Phasen haben sich im Bereich der Softwareentwicklung von einem einfachen, auf ein Unternehmen bezogenen Prozess in ein rückgekoppeltes Mehr-Kreislaufsystem fortentwickelt.

Rückgekoppeltes Mehr-Kreislaufsystem:

Das Mehr-Kreislaufsystem besteht aus zwei Kreisläufen. Der eine Kreislauf spielt sich in den anwendenden Unternehmen ab, die aufgrund von betriebswirtschaftlichen Zielsetzungen Anforderungen an zukünftige AwS definieren. Im Rahmen des Information Engineering werden diese Anforderungen regelmäßig analysiert und fachliche Soll-Konzepte für zukünftige AwS entworfen. Nach der Auswahl eines Standardsoftwareprodukts wird detailliert erarbeitet, wie die vorgegebenen Strukturen des Produkts und die zukünftige Organisation des Unternehmens aufeinander abgestimmt werden können. Dabei muss entschieden werden, inwieweit sich die Organisation den vorgegebenen Softwarestrukturen und -verfahren anpassen soll oder zusätzliche Entwicklungen notwendig sind, um weitergehende Anforderungen des Unternehmens adäquat zu unterstützen. Letztlich wird das System implementiert (adaptiert) und genutzt (betrieben). Entstehen neue Ziele oder neue Anforderungen, so gibt es Rücksprünge in frühere Phasen, und es werden weitere Projekte initiiert.

Der zweite Kreislauf spielt sich beim Softwareunternehmen ab, das die Standardsoftware entwickelt. Ein solches Unternehmen entwickelt die Software nicht sukzessive und durch den Einbezug möglichst vieler Anwender und/oder Berater. Dazu werden in jedem Projekt (und jedem folgenden Erweiterungsprojekt) Anforderungen der Anwender analysiert und in kondensierter Form in Soll-Konzepten formuliert, Entwürfe erstellt, Implementierungen realisiert und Testbetriebe durchgeführt.

Um die Distanz zwischen Hersteller und Anwender zu reduzieren, werden ergänzende Dienstleistungen, wie z.B. EarlyWatch-Services und ergänzende Produkte (Referenzmodelle, Vorgehensmodelle) angeboten. Ferner gibt es eine Reihe von Beratungsunternehmen, die sich auf diese Problematik konzentrieren und zwischen Softwarehersteller und -anwender vermitteln.

Allgemeines Vorgehensmodell zur Einführung von Softwareprodukten:

Vorgehensmodelle entsprechen Vorgehensweisen, die sich für die Softwareentwicklung in der Vergangenheit bezüglich Kosten und Dauer als ‘belastbar’ erwiesen haben und als Basis für zahlreiche Einführungsprojekte innerhalb der Standardsoftwareentwicklung dokumentiert sind.

Bei der Einführung von Standardsoftware hat sich eine systematische Vorgehensweise durchgesetzt, die sich – in Anlehnung an Vorgehensmodelle der Informatik – in die Phasen Analyse, Entwurf, Realisierung (Implementierung), Test und Betrieb unterteilen. Dieses sog. Phasenmodell begrenzt jede Aufgabe in einer eigenen Phase durch Meilensteine (MS). Ein Meilenstein besteht aus einem Termin und einer Menge von Ergebnissen, die zu diesem Termin vorliegen müssen. Der Output einer Phase dient wiederum als Input für die nächste Phase. Als Ergebnis der letzten Phase muss das fertige Softwareprodukt vorliegen.

Analysephase:

Die Analyse beinhaltet die Untersuchung und Beschreibung des zu unterstützenden Anwendungsbereiches (Ist-Analyse) und die Ermittlung der Anforderungen an ein neues oder ergänzendes betriebliches AwS. Die Anforderungen werden entweder von Mitarbeitern des eigenen Unternehmens oder von Beratern in Form einer Anforderungsdefinition festgelegt. Danach erst erfolgt die Auswahl des AwS.

Mit Hilfe verschiedener Methoden wie z.B. der Inventur- oder der Interviewmethode lassen sich der Ist-Zustand und die Schwachstellen analysieren. Anschließend wird das Soll-Konzept erarbeitet, das die Aufgaben der Software und die Anforderungen an die Geschäftprozesse beinhaltet.

In der folgenden Durchführbarkeitsstudie wird geprüft, ob das angestrebte AwS mit einem vorgegebenen Rahmenbudget und Zeithorizont realisiert werden kann. Bei diesen Entscheidungen wird meist ein Beratungsunternehmen hinzugezogen, das neben der Planung des Projekts auch den Zeitplan und den Aufbau der Projektorganisation übernehmen kann.

Entwurfsphase:

Die in der Analysephase festgelegten Anforderungen werden bei der Einführung eines Standardsoftwareproduktes auf die Komponenten und Funktionen aufgeteilt. Hierbei muss entschieden werden, welche Anforderungen mit welchen Funktionalitäten der Software abgedeckt werden können. Dieses sog. Matching wird noch komplexer, wenn eine neue Software in ein bestehendes Informationssystem integriert werden muss. In diesem Fall sind neben der Funktionalität auch die Schnittstellen zu bestehenden Systemen von hoher Bedeutung.

Die im weiteren Verlauf vorgestellte Implementation Roadmap stellt hierbei das R/3-System in den Vordergrund des Entwurfsprozesses, da zum einen davon ausgegangen werden kann, dass das System die Anforderungen des Anwenders größtenteils erfüllt, zum anderen die gezielte Auswahl und Konfiguration der Funktionalität noch bisher unerfüllte Wünsche des Anwenders abdecken kann.

Realisierungsphase:

Die Realisierungsphase dient der Erstellung eines lauffähigen AwS, das den in der Entwurfsphase gestellten Anforderungen gerecht werden soll. Hierbei liegt der Schwerpunkt im Gegensatz zur Individualprogrammierung auf der Konfiguration und Adaption der Standardsoftware. Das Vorgehen der Realisierung konzentriert sich auf die angestrebten Geschäftsprozesse, die mit Hilfe der Softwareprodukte ausgewählt und konfiguriert werden können. Die Konfiguration wird im späteren Verlauf auch als Customizing bezeichnet.

Testphase:

Die Testphase überprüft das In- und Output-Verhalten sowie die Leistung des lauffähigen AwS. Weiterhin können bei der Funktionsüberprüfung Modultests, Integrationstests (zu anderen Modulen und AwS) und Installationstests (beim Wechsel der Rechnersysteme) unterschieden werden.

Häufig werden für den Test mehrere Installationen der Software benötigt. Die Regel sind drei Systeme: Das erste System (Entwicklungssystem) dient zur Entwicklung bzw. Installation und Konfiguration neuer Komponenten, das zweite (optionale) System (Qualitätssicherungssystem) dem Test der neuen Komponenten und das dritte System (Produktivsystem) dem eigentlichen Produktivbetrieb.

Betriebsphase:

Innerhalb dieser Phase kommt dem Managen des Betriebs besondere Bedeutung zu. Sie ist somit eigentlich nicht Teil der eigentlichen Einführung und Entwicklung des AwS. Die Produktivphase wird begleitet von Sicherheits- und Sicherungsmaßnahmen, die in der Lage sind, das System und das Zugriffsverhalten mit Hilfe von Monitoren zu überwachen. Ferner wird hier der Transport von Updates und Upgrades kontrolliert.

Probleme im Phasenmodell:

Das Modell ist ein idealisiertes Modell, welches in der Praxis kaum durchzuhalten ist. Stets sind Überlappungen und Rückschritte zwischen den Phasen denkbar, insbesondere dann, wenn festgestellt wird, dass Korrekturen in einer der letzten Phasen zu Änderungen in der ersten Phase führt.

Aus diesem Grund ergeben sich folgende Probleme:

Erst zum Ende der Testphase liegt ein lauffähiges Softwareprodukt vor. Dies führt u.U. dazu, dass das Produkt zwar den Anforderungen aus dem Pflichtenheft entspricht, aber aufgrund von Missverständnissen nicht den tatsächlichen Anforderungen des Anwenders gerecht wird.

Problemstellungen kristallisieren sich erst im Laufe des Entwicklungsprozesses zu einem produktentscheidenden Faktor.

Im Laufe der Entwicklung ändern sich u.U. die Anforderungen an das künftige Produkt. So ist es denkbar, dass Geschäftsprozesse für Softwaresystemen in vorigen Versionen des Produktes noch keine Rolle gespielt haben.

Der spätere Anwender des Produktes wird zu selten in die Entwicklung einbezogen. Dieser formuliert aber u.U. noch entscheidende Faktoren für das zukünftige Produkt.

Die vorgenannten Probleme können Erweiterungen des Phasenmodells lösen. Hierbei hat sich ein sog. Erweitertes Phasenmodell entwickelt, das in Grundzügen auch für eine R/3-Einführung bzw. -Anpassung verwendet wird.