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

Inhaltsverzeichnis

Management Summary

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Grundlagen betrieblicher Anwendungssysteme
1.1 Einführung
1.1.1 Unternehmensarchitektur am Beispiel des SOM
1.1.2 Individualprogrammierung, Standardsoftware und Parametrisierung
1.1.3 Integration von Software
1.2 Aufgaben und Geschäftsprozesse in betrieblichen AwS
1.2.1 Aufgaben
1.2.2 Geschäftsprozesse
1.3 Übersicht über Architekturen von betrieblichen AwS
1.3.1 Mehrstufige Client/Server-Architekturen (C/S-Modell)
1.3.2 Relationale Datenbankmanagementsysteme (RDBMS)
1.3.3 Objektorientierte Architekturen
1.4 Das System R/3 der SAP AG
1.4.1 Client-/Server-Architektur
1.4.1.1 Technische Dienste
1.4.1.2 Betriebsarten und Logon-Gruppen
1.4.1.3 Datenbankmanagement
1.4.1.4 Präsentationssystem
1.4.2 Internetanbindung
1.4.3 Komponenten des R/3-Systems
1.4.3.1 Funktionsbezogene Komponenten
1.4.3.2 Funktionsübergreifende Komponenten
1.5 Organisationsstrukturen des R/3-Systems
1.5.1 Logistik (Logistics, LO)
1.5.1.1 Materialwirtschaft (Material Management, MM)
1.5.1.2 Vertrieb (Sales & Distribution, SD)
1.5.2 Rechnungswesen (AC, Accounting)
1.5.2.1 Externes Rechnungswesen
1.5.2.2 Internes Rechnungswesen
1.5.3 Personalwirtschaft

2 Vorgehensmodelle zur Entwicklung von AwS
2.1 Entwicklungsprozesse und Vorgehensmodelle
2.1.1 Entwicklung von Standardsoftwaresystemen
2.1.2 Rückgekoppeltes Mehr-Kreislaufsystem
2.1.3 Allgemeines Vorgehensmodell zur Einführung von Softwareprodukten
2.1.3.1 Analysephase
2.1.3.2 Entwurfsphase
2.1.3.3 Realisierungsphase
2.1.3.4 Testphase
2.1.3.5 Betriebsphase
2.1.4 Probleme im Phasenmodell
2.1.5 Erweitertes Phasenmodell
2.1.5.1 Iteratives Vorgehen
2.1.5.2 Inkrementelles Vorgehen
2.1.5.3 Partizipatives Verfahren
2.1.5.4 Evolutionäres Verfahren
2.1.6 Anpassung von Standardsoftware
2.1.6.1 Parametrisierung
2.1.6.2 Modifikation
2.1.6.3 Erweiterung
2.2 Vorgehensmodelle zur Einführung von SAP R/3
2.2.1 Einordnung der R/3-Einführung
2.2.2 Das traditionelle SAP-Vorgehensmodell
2.2.3 Die beschleunigte R/3-Einführung – AcceleratedSAP (ASAP)
2.2.4 Iteratives Prozess-Prototyping (IPP)
2.2.5 DSDM – das dynamische Vorgehensmodell

3 Die SAP Implementation Roadmap
3.1 Die Phase 1: Projektvorbereitung
3.1.1 Projektplanung erstellen
3.1.1.1 Der Projektauftrag
3.1.1.2 Das Projektmanagement
3.1.1.3 Der Projektplan, Projektbudgetplan und Projekteinsatzplan
3.1.2 Projektabläufe
3.1.2.1 Organisatorische Aufgaben
3.1.2.2 Festlegung auf die Einführungsstrategie
3.1.2.3 Systemlandschaft definieren
3.1.3 Projekt-Kickoff
3.1.4 Planung der technischen Anforderungen
3.1.5 Qualitätsprüfung Projektvorbereitung
3.2 Die Phase 2: Business Blueprint
3.2.1 Projektmanagement Business Blueprint
3.2.1.1 Veränderungsmanagement (Change Management)
3.2.2 Schulung des Projektteams Business Blueprint
3.2.3 Systemumgebung entwickeln
3.2.3.1 Änderungsaufträge
3.2.3.2 Versionsführung
3.2.3.3 Entwicklungssystem
3.2.3.4 Systemadministration
3.2.3.5 Konfiguration des Einführungsleitfadens
3.2.4 Organisationsstruktur
3.2.5 Geschäftsprozessdefinition
3.2.5.1 Erstellung der Business-Blueprint-Dokumente
3.2.5.2 Plan für Benutzerschulung und -dokumentation
3.2.6 Qualitätsprüfung Business-Blueprint-Phase
3.3 Die Phase 3: Realisierung
3.3.1 Projektmanagement Realisierung
3.3.1.1 Planung für Help Desk und Cut Over
3.3.2 Schulung des Projektteams
3.3.3 Baseline-Konfiguration und -Abnahme
3.3.4 Detail-Konfiguration und -Abnahme
3.3.5 Systemverwaltung
3.3.6 Entwicklung von Datenkonvertierungsprogrammen
3.3.7 Entwicklung von Schnittstellenprogrammen für Anwendungen
3.3.8 Entwicklung von Systemerweiterungen
3.3.9 Entwicklung von Berichten
3.3.10 Entwicklung von Formularen
3.3.11 Erarbeitung des Berechtigungskonzepts
3.3.12 Einrichtung der Archivierung
3.3.13 Abschließender Integrationstest
3.3.14 Dokumentation und Schulungsunterlagen für Benutzer
3.3.15 Qualitätsprüfung Realisierung
3.4 Die Phase 4: Produktionsvorbereitung
3.4.1 Projektmanagement Produktionsvorbereitung
3.4.2 Benutzerschulung
3.4.3 Systemmanagement
3.4.4 Detaillierte Planung Cut Over und Support
3.4.5 Cut Over
3.4.6 Qualitätsprüfung Produktionsvorbereitung
3.5 Die Phase 5: Go-Live und Support
3.5.1 Produktionssupport
3.5.2 Beenden des Projekts

4 Werkzeuge zur Einführung von SAP R/3
4.1 Überblick
4.2 Implementation Assistant
4.3 Microsoft Project
4.3.1 Einsatzbeurteilung der Projektmanagement-Software
4.3.2 Projektpläne für die R/3-Einführung
4.3.3 Nutzung von Projektplänen mit MS-Project
4.4 Question & Answer Database (Q&Adb)
4.4.1 Fragen zum Unternehmen
4.4.2 Fragen zur Prozesshierarchie
4.4.3 Problemdatenbank
4.5 Structure Modeler
4.6 Concept Check Tool
4.7 Business Navigator
4.7.1 Prozesshierarchie
4.7.2 Komponentenhierarchie

5 Die Fallstudie zum Customizing über den IMG
5.1 Die Case Study: Historischer Hintergrund
5.2 Der Einsatz von Fallstudien an der FH Aschaffenburg
5.2.1 Das Vorlesungskonzept an der FH Aschaffenburg
5.2.2 Die Rahmenbedingungen von R/3-Fallstudien
5.3 Die Customizing-Komponente
5.3.1 Der Implementation Guide (IMG)
5.3.2 Konfiguration des IMG
5.3.3 Projekt- und Konfigurationsüberwachung
5.3.4 Durchführung der Konfiguration
5.3.5 Transport der Konfiguration auf das Produktivsystem
5.4 Die Fallstudie „Customizing und Organisationsmanagement“
5.4.1 Gegenstand und Anwendungsgebiete der Fallstudie
5.4.2 Einstellungen am R/3-System
5.4.2.1 Neuanlage der Benutzer
5.4.2.2 Namenskonventionen
5.4.2.3 Aufheben der Datensatzsperrung
5.4.3 Unternehmen und Szenario
5.4.3.1 Das Unternehmen Zusuki Aschaffenburg AG (ZAG AG)
5.4.3.2 Die Funktionsbereiche
5.4.3.3 Das betriebswirtschaftliche Umfeld
5.4.4 Die Problem- und Aufgabenstellung
5.4.5 Abschließende Hinweise zur Durchführung der Fallstudie
5.4.5.1 Grundsätzliche Hinweise
5.4.5.2 Aus Dozentensicht
5.4.5.3 Aus Studentensicht
5.4.5.4 Prüfbarkeit von fallstudienbasierten Lehrveranstaltungen
5.4.6 Die Evaluation der Lehrveranstaltung

6 Fazit

Literatur- und Quellenverzeichnis

Anlagen

Management Summary

Diese Arbeit beschreibt die Umsetzung einer praktischen R/3-Fallstudie für den Einsatz in Forschung und Lehre, die auf theoretischen Grund­lagen aufbaut.

Das erste Kapitel bezieht sich folglich zunächst auf die Grundlagen betrieblicher Anwendungssysteme, typisiert diese im Umfeld von Informationssystemen und stellt das System R/3 der SAP AG vor diesem Hintergrund ausführlich dar.

Das zweite Kapitel vermittelt bekannte Vorgehensmodelle zur Entwicklung von Anwendungssystemen. Hierzu gehört das rückgekoppelte Mehr-Kreislaufsystem
oder das Wasserfallmodell von Boehm. Die Vorstellung von Vorgehensmodellen, wie z.B. das sog. Traditionelle SAP-Vor­gehens­modell, aber auch das Dynamische Vorgehensmodell (DSDM), die sich im Rahmen der Einführung von R/3 in Unternehmen als Standard etabliert haben, runden das Kapitel ab.

Ausführlich widmet sich die Arbeit im dritten Kapitel der SAP Implementation Roadmap. Als Teil des Programms zur beschleunigten R/3-Einführung – der sog. Methode AcceleratedSAP – stellt die Implementation Roadmap die Vorgehensweise für R/3-Einführungen der SAP AG dar. Dadurch, dass sie mit den hierarchisch aufeinander folgenden fünf Phasen Projektvorbereitung, Business Blueprint, Realisierung, Produktionsvorbereitung und Go-Live in der Lage ist, die Zeit und die Kosten einer R/3-Einführung erheblich zu reduzieren, hat die Implementation Roadmap einen Standard bei R/3-Einführungen gesetzt.

Das vierte Kapitel schlägt eine Brücke zu den unterstützenden Werkzeugen, die für die Durchführung der im dritten Kapitel vorgestellten Implementation Roadmap unverzichtbar sind. Es erläutert unter anderem Softwarewerkzeuge, wie z.B. Microsoft Project oder den mit Microsoft Visio realisierten Structure Modeler, aber auch Methoden wie den Implementation Assistant oder die Question & Answer Database. Empfehlungen und Tipps zum Einsatz der Werkzeuge sowie ein Ausblick auf das Business Referenzmodell beenden den Theorieteil.

Das fünfte und praktische Kapitel stellt zunächst die Historie der Case Study vor dem Hintergrund des Vorlesungskonzeptes der FH Aschaffenburg dar. Es erläutert die Vorgehensweisen zum Customizing des R/3-Systems über den Implementation Guide (IMG) und stellt anschließend das Szenario der FH-Fallstudie „Customizing und Organisationsmanagement im System R/3“ vor. Abschließende Hinweise für Dozenten und Studenten, sowie Anmerkungen zur Evaluation von SAP-bezogenen Lehrveranstaltungen runden die Arbeit ab.

Abbildungsverzeichnis

Bild 1: Teilsysteme des Unternehmens (Objektsystem)

Bild 2: Unternehmensarchitektur nach dem SOM

Bild 3: Datenintegration am Beispiel verschiedener anwendungsnaher Softwareprodukte

Bild 4: Struktur eines Lösungsverfahrens

Bild 5: Dreistufige SAP R/3 Client-/Server-Architektur und typische Rollen von Benutzern

Bild 6: Organisationsschema der Materialwirtschaft (ohne technische Systemebene)

Bild 7: Organisationsschema des Vertriebs (ohne technische Systemebene)

Bild 8: Organisationsschema des Rechnungswesens (ohne technische Systemebene)

Bild 9: Organisationsschema der Personalwirtschaft (ohne technische Systemebene)

Bild 10: Rückgekoppeltes Mehr-Kreislaufsystem

Bild 11: Wasserfallmodell nach Boehm

Bild 12: Beispielhafter 6-Monats-Projektplan

Bild 13: Die Arbeitspakete der Phase 1: Projektvorbereitung

Bild 14: Beispielhafte Projektorganisationsstruktur für die R/3-Einführung

Bild 15: Die Arbeitspakete der Phase 2: Business Blueprint

Bild 16: Die Arbeitspakete der Phase 3: Realisierung

Bild 17: Die Arbeitspakete der Phase 4: Produktionsvorbereitung

Bild 18: Die Arbeitspakete der Phase 5: Go-Live und Support

Bild 19: Implementation Roadmap, ihre Werkzeuge und begleitende Services

Bild 20: R/3-Vorlesungskonzept an der FH Aschaffenburg

Bild 21: Die Customizing-Fallstudie als Basis für die HR- und Logistik-Fallstudie

Bild 22: Einschränkung des Ref.-IMG auf die Unternehmens- & Projektsicht

Bild 23: Report ZSENQOFF zur Abschaltung der Sperrverwaltung

Bild 24: Stückliste des Endproduktes FH-Lamp Spezial

Tabellenverzeichnis

Tabelle 1: Ausgewählte Werkzeuge der R/3-Einführung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Grundlagen betrieblicher Anwendungssysteme

1.1 Einführung

Betriebswirtschaftlich agierende Unternehmen bilden ein Gesamtsystem zur Zielerfüllung, das sich in die Teilsysteme Betriebliches Informationssystem und Basissystem untergliedert.^[1] 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.^[2]

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.^[3]

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Teilsysteme des Unternehmens (Objektsystem)^[4]

1.1.1 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^[5], 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.^[6]

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Unternehmensarchitektur nach dem SOM^[7]

Bei der Einführung oder Parametrisierung von Enterprise Resource Planning-Standard­soft­ware-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.^[8]

Die tägliche Praxis zeigt jedoch, dass die Top-down-Vorgehensweise nicht immer praktikabel ist. Beobachtungen und Gespräche mit Mitarbeitern^[9], 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.

1.1.2 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.^[10]

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^[11] 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.^[12]

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^[13] 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.

1.1.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.^[14]

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.^[15]

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Datenintegration am Beispiel verschiedener anwendungsnaher Softwareprodukte

1.2 Aufgaben und Geschäftsprozesse in betrieblichen AwS

1.2.1 Aufgaben

Die Funktionalität und der Einsatzbereich eines betrieblichen AwS ergibt sich durch die Aufgaben eines Unternehmens. Je nach Typ der unterstützten Aufgaben lassen sich betriebliche AwS in Administrations-, Dispositions-, Planungs- und Kontrollsysteme unterscheiden.^[16]

- Administrationssysteme dienen der Rationalisierung vorhandener Abläufe. Beispielsweise vereinfacht ein Personalverwaltungssystem die Verwaltung der Mitarbeiterdaten in einem Unternehmen.
- Dispositionssysteme vereinfachen die kurzfristige betriebliche Entscheidungsfindung. Beispielhaft dienen Systeme zur Beschaffung von RHB-Stoffen, die für jedes gelagerte Teil die geeigneten Zeitpunkte und Mengen zur Nachbestellung ermitteln.
- Planungssysteme unterstützen die mittel- bis langfristige Entscheidungsfindung und haben weit reichendere Auswirkungen als Dispositionssysteme. Sie ermöglichen das Erzeugen alternativer Pläne, die zu Kontrollzwecken mit der Ist-Situation verglichen werden können.
- Kontrollsysteme dienen Fach- und Führungskräften zur Erkennung von außergewöhnlichen Planungsabweichungen. Hierzu werden Ist-Daten aus Administrationssystemen entnommen und mit Plan-Daten von Dispositions- und Planungssystemen abgeglichen.

Die zunehmende Integration der komplexen AwS verursacht bisweilen eine Unübersichtlichkeit, die nur mit Hilfe einer Zerlegung in übersichtliche fachliche Teilsysteme – sog. Anwendungskomponenten^[17] – aufgehoben werden kann. Komponenten von Standardsoftware können eingeteilt werden in:

- Funktionsbezogene Komponenten, die den betriebswirtschaftlichen Aufgaben des Unternehmens dienen.
- Funktionsübergreifende Komponenten, die allen Aufgaben zur Unterstützung dienen.
- Systemkomponenten, die der technischen Realisierung funktionsbezogener und funktionsübergreifender Komponenten dienen.

1.2.2 Geschäftsprozesse

Unter einem Geschäftsprozess ist eine Abfolge von Aktionen bzw. Interaktionen zu verstehen, die von Objekten bzw. zwischen mehreren Objekten durchgeführt werden und zur Zielerreichung des Unternehmens beitragen.^[18] Als Akteure kommen in der betrieblichen Realität meist Mitarbeiter, Kunden, Lieferanten oder auch Maschinen und AwS in Frage. Bei der Durchführung der Aktionen werden Objekte (Input) verbraucht, erstellt (Output) und transformiert. Objekte können Materialien, Produkte, Informationen oder allgemeine Dienstleistungen sein.

Innerhalb der Fallstudie wird ein Motorradscheinwerfer (Output) nach Kundenauftrag aus zwei Komponenten, nämlich einem Strahler und einer Halterung (Input), mittels diverser Montagemaschinen (Transformation) gefertigt. Objekte sind sämtliche RHB-Stoffe sowie Dienstleistungen, die für die Transformation notwendig sind.

Zur Beschreibung (Modellierung) von Geschäftsprozessen werden meist Ereignisgesteuerte Prozessketten (EPK) verwendet, die in einer grafischen Notation, einer sog. Diagrammsprache, im Rahmen der Architektur integrierter Informationssysteme (ARIS)^[19] entwickelt wurde.^[20]

Das Konzept fußt grundsätzlich auf der Idee, alle am Geschäftsprozess beteiligten Objekte zunächst in voneinander losgelösten Sichten^[21] isoliert zu beschreiben, um dadurch zum einen die Zusammenhänge zwischen den Objekten übersichtlicher darzustellen, zum anderen, um die mit einer eventuell komprimierten Darstellung verbundene Komplexität zu beherrschen. Die Darstellung erfolgt mit Hilfe von Diagrammelementen (Knoten und Kanten), die zusammengesetzt jeweils eine Folge von Ereignissen und Funktionen darstellen können.

Mit Hilfe von sog. Softwarereferenzmodellen sind zudem abstrakte Beschreib­ungen typischer Geschäftsprozesse in Unternehmen möglich, die eine Brücke zwischen der systemtechnischen Implementierungssicht (DV-Abteilung) und der betriebswirtschaftlichen Anwendungssicht (Fachabteilung) schlagen sollen. Um das traditionell vorhandene Spannungsverhältnis zwischen Fach- und DV-Abteilung möglichst zu vermeiden, wird der Versuch unternommen, Funktionen und Strukturen dieser Systeme sowohl aus einer sachlogischen als auch aus einer betriebswirtschaftlichen Perspektive zu beschreiben.^[22] Die Verwendung von Softwarereferenzmodellen ist hauptsächlich bei der Einführung von standardisierten AwS üblich, da sie den Anwender bei der Analyse der in den Systemen verfügbaren Funktionalität unterstützen kann.^[23] Selbstverständlich können Referenzmodelle auch für Workshops verwendet werden und somit als Diskussionsgrundlage für die Definition der Unternehmensstrukturen und Geschäftsprozesse dienen.

Auf Basis des bekannten SAP R/3-Referenzmodells wird im Rahmen der Fallstudie „Customizing und Organisationsmanagement im System R/3“ eine Organisationsstruktur mittels der im IDES^[24] -System bekannten und bereits bestehenden Struktur erstellt. In der Praxis dient dies dazu, den Entwicklungsaufwand möglichst gering zu halten und die Produktivität bei der Erstellung individueller Soll-Modelle zu steigern.

1.3 Übersicht über Architekturen von betrieblichen AwS

1.3.1 Mehrstufige Client/Server-Architekturen (C/S-Modell)

Betriebliche AwS als Teil betrieblicher Informationssysteme tangieren Fragen sowohl zur Software- als auch zur Rechner- und Netzwerkarchitektur, d.h. alle drei Aspekte gehören unmittelbar zusammen. Die Softwarearchitektur beinhaltet die Struktur eines AwS, die sich aus den Softwarekomponenten, den Eigenschaften dieser Komponenten und den Beziehungen zwischen diesen Komponenten zusammensetzt.^[25]

Die Entwicklung der Softwarearchitekturen betrieblicher AwS lässt sich grob als Weg von zentralen, monolithischen Großrechnern hin zu verteilten Client-/Server-Architekturen beschreiben. Das C/S-Modell beruht auf der Idee, Information nutzende (Client) und Information bereitstellende (Server) Prozesse voneinander zu trennen, um sie aus Gründen der Performanz^[26] oder der dezentralisierten Organisation verteilt auf mehreren Rechnersystemen betreiben zu können. Damit einher geht der Versuch zur Standardisierung von Schnittstellen zwischen Client- und Server-Prozessen und der zugrunde liegenden Rechnersysteme, um eine Unabhängigkeit von Soft- und Hardware-Herstellern zu erreichen.

Zwischen Server- und Client-Prozessen findet man meist eine „1:n“-Beziehung vor, d.h. ein Server bedient mehrere Clients.

Während integrierte AwS eine automatische Aktionensteuerung und -durchführung selbst gewährleisten, ist der Mensch als personeller Aufgabenträger im Regelfall der Auslöser dieser Aktionen und somit nicht mehr Teil des automatisierten AwS. Im Rahmen der Aktionenauslösung agiert der Mensch als Computerbenutzer im Informationssystem seines Unternehmens und zum Zwecke der Aufgabenerfüllung. Hierbei kooperieren Mensch und AwS bei der Durchführung einer gemeinsamen Aufgabe in Form einer Mensch-Werkzeug-Beziehung. Das Lösungsverfahren der Aufgabe (vgl. Bild 4) wird hierzu aufgetrennt in eine Menge von Operationen, die auf das Aufgabenobjekt einwirken, und eine Operationensteuerung, die Auswahl und Reihenfolge der Operationen bestimmt. Die Person ist dann Auslöser der Operationensteuerung, das zugehörige AwS übernimmt die Durchführung der Operationen.

Abbildung in dieser Leseprobe nicht enthalten

Bild 4 : Struktur eines Lösungsverfahrens^[27]

Aktuelle C/S-Systeme sind vorwiegend technisch motiviert. Bei einem dreistufigen C/S-System wie z.B. u.a. bei SAP R/3, existieren Server nur für die Datenhaltung. Die Verarbeitung der geschäftsrelevanten Daten erfolgt anschließend auf der Anwendungsebene, die Präsentation und das Versenden von Nachrichten schließlich auf oberster Ebene – der Präsentationsebene – mittels einer grafischen Benutzeroberfläche^[28]. Diese heute in betrieblichen AwS verbreitete Drei-Ebenen-Architektur mit Presentation Layer, Application Layer und Persistence Layer kann um eine vierte Ebene – einem Internet Layer – ergänzt werden, um die Geschäftsabwicklung über Weitverkehrsnetze^[29] oder lokale Netze^[30] zu ermöglichen. Hierbei wird eine weitere Ebene zwischen der Anwendungs- und der Präsentationsebene eingeführt, um
nutzenden Einheiten den Zugriff mittels Web-Browsern über einen Internetserver^[31] zu ermöglichen.^[32]

Die technisch motivierten Architekturen ähneln Baumstrukturen mit verzweigten Ästen: Eine Menge für die Interaktion mit dem Benutzer verantwortlichen Clients stützt sich auf die Anwendungsebene, die eine Reihe von Anwendungsfunktionalitäten zur Verfügung stellt. Eine Reihe weiterer Anwendungsserver auf dieser Ebene übernehmen wiederum die Rolle eines Clients gegenüber einem zentralen Datenbankserver, der für die Anwendungen die benötigten Datenoperationen (Abfragen, Einfügen, Löschen, Ändern) durchführt.

1.3.2 Relationale Datenbankmanagementsysteme (RDBMS)

Sämtliche Daten, die in einem betrieblichen AwS anfallen, werden in einer oder mehreren Datenbanken gespeichert. Datenbanken stellen abgeschlossene „Datenbehälter“ dar, die von einem Datenbankmanagementsystem (DBMS) verwaltet werden. Das DBMS gewährt dem AwS auf Anwendungsebene und in Konsequenz dem Anwender auf der Präsentationsebene Zugriff auf die Daten aller verwalteten Datenbanken und sichert die syntaktische und semantische Konsistenz dieser Datenzugriffe.

In einem dem relationalen Datenmodell zugrundeliegenden System (RDBMS) werden die Daten in Tabellen, auch Relationen genannt, verwaltet. Diese Relationen bestehen aus einer Folge von Attributen^[33], die einen Namen und einen festen Wertebereich wie z.B. Datum, Dezimalzahl, Zeichenkette etc. besitzen. In den Relationen werden die Daten in Zeilen – auch Tupel genannt – abgelegt. Jede Zeile hat so viele Spalten, wie die Relation Attribute hat, und der Wert jeder Spalte stammt aus dem Wertebereich des entsprechenden Attributs.

Eine bekannte Sprache zur Definition der Datenbankschemata und zur Abfrage bzw. Manipulation von relationalen Datenbanken ist die Structured Query Language (SQL)^[34], auf die hier aber nicht eingegangen werden soll.

1.3.3 Objektorientierte Architekturen

Durch die Entwicklung des Business Frameworks und den Business Objects, sowie durch die Weiterentwicklung der grundlegendenen Programmiersprache ABAP/4 zu ABAP Objects, schlägt auch die SAP AG einen zunehmend objektorientierten Weg ein.

Mit Hilfe der Objektorientierung ist es einfacher möglich, das Produkt R/3 mit Komplementärprodukten anderer Hersteller zu koppeln, um Daten auszutauschen oder prozessübergreifend arbeiten zu können. Aus diesem Grund zeichnet sich die Tendenz ab, AwS aus kleineren, austauschbaren und auf standardisierten Architekturen kommunizierenden Komponenten aufzubauen.

Im Rahmen der Fallstudie soll ein bestehendes Personalinformationssystem mit dem zukünftigen HR-Modul des R/3-Systems ergänzt werden. Wenn beide Systeme die Objektorientierung unterstützen, ist eine Kopplung der jeweiligen Prozesse und des Datenbestandes mittels objektorientierter Methoden wie z.B. CORBA^[35] möglich.

Bei der objektorientierten Softwaretechnik geht man davon aus, dass sich alle für AwS relevanten Sachverhalte als Objekte darstellen lassen, unabhängig davon, ob es sich um Informationen zu einem Lieferanten, einem Auftrag oder einem anderen betrieblichen Gegenstand handelt. Aus Objekten lassen sich Objektsysteme (Familien von Objekten) erstellen, in denen die Objekte Beziehungen zueinander haben und miteinander agieren. Jedes Objekt trägt eine Typisierung, d.h. alle Objekte eines Typs besitzen gemeinsame Eigenschaften wie z.B. die Attribute Farbe, Höhe, Breite, Preis und gleiche Methoden, wie z.B. Material liefern, Rechnung schicken etc.^[36]

Der Nachteil der oben erwähnten dreistufigen C/S-Architektur ist, dass die gesamte Anwendungsebene aus einem oder zumindest aus einer fest vorgegebenen Anzahl von Server-Prozessen besteht. Durch objektorientierte Technologien hingegen lässt sich diese Ebene in eine Reihe von wechselseitig vernetzten Client- und Server-Objekten aufteilen, die fast beliebig auf Rechnersysteme verteilt werden können. Diese Objekte interagieren miteinander über Rechnergrenzen hinweg und können andere Objekte dazu veranlassen, ihre Methoden auszuüben. Ein besonderer Vorteil dieser Architektur ist es, dass sich der Entwickler keine Gedanken mehr darüber machen muss, auf welchem Rechner sein Objekt liegt, während er bei der klassischen dreistufigen C/S-Architektur angeben muss, auf welchem Rechner das Empfängerobjekt (z.B. ein Adressat einer Nachricht) residiert.^[37]

1.4 Das System R/3 der SAP AG

1992 wurde das R/3-System von der Walldorfer SAP AG am Markt eingeführt. Es war eine Reaktion auf die sich damals verändernden Märkte, die – wie bereits erwähnt – weg von proprietären, d.h. innerhalb ihrer System- und Softwarearchitektur geschlossenen Großrechner-Umgebungen, hin zu offenen Client-/Server-Architek­turen tendierten. Im Gegensatz zum Vorgängerprodukt R/2, einem nur auf Großrechnern lauffähigem System, handelt es sich bei R/3 um ein auf allen gängigen Plattformen lauffähiges Client-/Server-System.

Das System R/3 stellt eine betriebswirtschaftliche Komplettlösung dar, die alle Funktionsbereiche eines Unternehmens einschließlich wichtiger Querschnittsfunktionen abdeckt. Das System ist modular gegliedert und baut auf einem Basissystem auf, das u.a. eine vollständige Entwicklungsumgebung enthält. SAP R/3 unterstützt alle betriebswirtschaftlichen Kernbereiche wie Logistik, Rechnungswesen, Controlling und Personalwesen. Daneben stehen übergreifende Funktionen wie Workflow, Office-Funktionen, Mail oder ein optisches Belegarchiv zur Verfügung.^[38]

Das System R/3 der SAP AG lässt sich durch die im Kapitel 1.1.1 vorgestellte SOM-Methodik in zwei der drei Ebenen Unternehmensplan, Geschäftsprozessmodell und Ressourcen einteilen.

Als AwS wird R/3 grundsätzlich in die Ressourcenebene eingeordnet. Auf der Geschäftsprozessmodellebene kann es zudem als automatisierter Aufgabenträger fungieren, welches die Umsetzung des Unternehmensplans durch Unterstützung von Unternehmensstrukturen und Geschäftsprozessen verfolgt. Bei der nachfolgenden Darstellung wird ein Bottom-Up-Vorgehen gewählt, um das System von der technischen Anwendung bis hin zu den damit realisierbaren Geschäftsprozessen zu beschreiben.

1.4.1 Client-/Server-Architektur

In seiner einfachsten Konfiguration kann das R/3-System als Drei-Ebenen-Architek­tur, d.h. als Präsentations-, Anwendungs- und Datenbanksystem betrieben werden. Hierbei ist es zwar üblich, alle drei Ebenen auf unterschiedlichen Rechnern zu betreiben, jedoch ist eine minimale Variante in Form eines sog. IDES-Notebooks zu Vorführzwecken ebenso realisierbar.

Die maximale Verteilung kann durch den parallelen Betrieb mehrerer AwS erreicht werden, die auf jeweils eigenen Rechnern installiert sein können^[39], um die gesamte Systemlast auf mehreren Rechnersystemen zu verteilen.^[40]

Abbildung in dieser Leseprobe nicht enthalten

Bild 5: Dreistufige SAP R/3 Client-/Server-Architektur und typische Rollen von Benutzern

1.4.1.1 Technische Dienste

Für die Kommunikation der einzelnen Ebenen untereinander bietet die R/3-Instanz eine Anzahl unterschiedlicher technischer Dienste^[41] an, die für die Bearbeitung von Anfragen an das R/3-System benötigt werden. Zu diesen Diensten gehören u.a.:^[42]

- der Dialogservice zur Verarbeitung der Benutzereingaben,
- der Verbuchungsservice zur Verbuchung der Änderungen auf der Datenbank,
- der Enqueue-Service zur zentralen Verwaltung von Sperren auf Datenbankobjekten,
- der Hintergrund-Service zur Verarbeitung von Hintergrundprozessen und
- einige weitere Services wie Spool-, Gateway- und Message-Services.

Parallel zur R/3-Laufzeitumgebung werden diese Dienste von Workprozessen der Dialog- oder der Hintergrundverarbeitung genutzt, um eine performante Arbeit mit dem R/3-System zu ermöglichen.

1.4.1.2 Betriebsarten und Logon-Gruppen

Die Definition von Betriebsarten im R/3-System dient dazu, das Lastprofil des Rechners entsprechend den Unternehmensanforderungen zu gestalten. Beispielsweise werden tagsüber eher Workprozesse für die Betriebsart Dialogverarbeitung und nachts eher die Betriebsart für die Hintergrundprozesse benötigt.

Ebenso ist die Zuordnung von Clients der Präsentationsebene zu Anwendungsservern statisch oder dynamisch möglich, je nachdem ob von vornherein festgelegt ist, welcher Benutzer welche R/3-Instanz zu nutzen hat oder ob dynamisch jene Instanz gewählt werden soll, die noch freie Rechnerressourcen besitzt. Da der Benutzer diesen Umstand in der Regel nicht erkennen kann, entscheidet das R/3-System mit Hilfe von logischen R/3-Instanzen^[43], welcher Benutzer welcher R/3-Instanz zugeordnet wird. Dieses Verfahren wird als statisches Logon Load Balancing bezeichnet, da der Benutzer für die Dauer seiner Sitzung fest einer R/3-Instanz – und damit einem Anwendungsrechner – zugeordnet ist.

Erfahrungsgemäß sind Betriebsarten und Logon-Gruppen wesentliche Einflussgrößen für die performante Konfiguration des R/3-Systems und sollten deswegen schon im Rahmen der Einführung dieses Standard-Softwareproduktes Beachtung finden.^[44]

1.4.1.3 Datenbankmanagement

Die vorgestellten Architekturen bedingen die Installation eines zentralen Datenbanksystems, auf das alle R/3-Instanzen zurückgreifen können. Hierbei werden zwischen den einzelnen Anwendungsservern Kommunikationsverbindungen notwendig, die beim Zugriff auf die Daten des R/3-Systems bereits durch Datensatzsperrverfahren (Enqueue-Prozesse) koordiniert werden und nicht – wie vielleicht vermutet – durch das Sperrverfahren des zentralen Datenbanksystems selbst. Die Rechner, auf denen das Datenbanksystem und der Enqueue-Prozess laufen, stellen prinzipielle Schwachstellen für die Verfügbarkeit des Gesamtsystems dar. Um eine ständige Verfügbarkeit zu garantieren, müssen spezielle Ausfallstrategien entwickelt werden, auf die hier nicht näher eingegangen werden soll.^[45]

1.4.1.4 Präsentationssystem

Auf der Präsentationsebene kommt das sog. SAPGUI, die grafische Benutzeroberfläche der SAP AG, zum Einsatz. Hierbei handelt es sich um ein fenster- und menügesteuertes Präsentationssystem, das für verschiedene Betriebssysteme, wie z.B. Windows, Linux oder Apple entwickelt wurde. In der Standardkonfiguration erlaubt das Menü den Aufruf aller Funktionen des R/3-Systems, einschließlich der Entwicklungsumgebung. Durch spezielle Konfigurationseinstellungen können in der hierarchisch angelegten Menüstruktur auch andere Menüpunkte als Ausgangspunkt festgelegt wer­den, so dass nur ausgewählte Bereiche, beispielsweise die Transaktionen der Materialwirtschaft, für den Benutzer zugänglich sind.

1.4.2 Internetanbindung

Durch den kostengünstigen Vertrieb von Produkten über das World Wide Web via E-Commerce wurde zunehmend nach Wegen gesucht, das R/3-System über das Internet zugänglich zu machen. Eine Möglichkeit zur Internetanbindung besteht durch den Einsatz eines Internet Transaction Servers (ITS), mit dem Teile der Funktionalität des R/3-Systems über eine HTML-Schnittstelle eines Web-Browsers zur Verfügung gestellt werden können.

Die Internetanbindung ist auch über Eigenentwicklungen unter Nutzung der Remote-Schnittstellen (BAPI, RFC etc.) oder über das SAPGUI in Java möglich. Der ITS verringert jedoch für einfache Problemstellungen den Entwicklungsaufwand erheblich, da die SAP AG für die Entwicklung von Anwendungen mit dem ITS bereits verschiedene vorkonfektionierte Komponenten anbietet. Technisch gesehen übernimmt der Web-Browser beim Einsatz eines ITS die Präsentationsebene in der Client-/
Server-Architektur, was aber nur durch zusätzliche webbasierte Komponenten und Änderungen der Kommunikationsprotokolle möglich ist.^[46]

Beispiel: Ein Kunde, der im Rahmen der Fallstudie in einem Online-Shop unseres Unternehmens navigiert, möchte sich erst zum Zeitpunkt des Kaufentschlusses in das System einloggen und somit die Sitzung erst beim Kauf und nicht schon – wie beim SAPGUI üblich – beim Betreten der Website eröffnen.

Unter Berücksichtigung höherer Ladezeiten sind zudem höhere Anforderungen an das graphische Erscheinungsbild der Internet-Anwendung zu stellen.

1.4.3 Komponenten des R/3-Systems

Seit dem Release 4.0 teilt die SAP AG das R/3-System in verschiedene funktionsbezogene und -übergreifende Komponenten ein, wobei diese sog. Componentization im neuen Release ECC 5.0 nicht mehr so stringent eingehalten wird. Bei den Komponenten handelt es sich – zumindest bis zum Release 4.7 – um^[47]

- die drei funktionsbezogenen Komponenten Accounting (AC, Rechnungswesen), Human Resources (HR, Personalwirtschaft) und Logistics (LO, Logistik)^[48],
- u.a. die funktionsübergreifende Komponente Cross Application Components
(CA) ^[49], sowie um
- die Systemkomponente Basis Components (BC).

Ferner werden von der SAP AG weitere Produkte wie z.B. das Business Information Warehouse (BW) und der Advanced Planner & Optimizer (APO) angeboten, die nicht mehr Teil des R/3-Systems sind, aber an dieses gekoppelt werden können.

An der FH Aschaffenburg ist das R/3-Release 4.7 Enterprise im Einsatz, welches über das HCC der Universität Magdeburg im Rahmen von Application Service Providing (ASP) gehostet wird. Hierbei greift die FH über das SAP GUI auf zwei Mandanten des Systems zu. Auf den Einsatz des Business Information Warehouse und den Advanced Planner & Optimizer, sowie auf die Einrichtung eines ITS wurde bisher verzichtet.

1.4.3.1 Funktionsbezogene Komponenten

Die Komponenten des R/3-Systems sind in einer Komponentenhierarchie angeordnet, die auch an anderen Stellen im R/3-System als Ordnungsschema genutzt wird. Diese Hierarchie enthält innerhalb der funktionsbezogenen Komponente Accounting (AC) die Module Financial Accounting (FI), Treasury (TR), Controlling (CO), Investment Management (IM), Project System (PS) und Enterprise Controlling (EC). Zur Komponente Logistik (LO) gehören die Module Vertrieb (SD), Materialwirtschaft (MM), Qualitätsmanagement (QM), Instandhaltung (PM), Produktion (PP). Zur funktionsbezogenen Komponente Personalwirtschaft (HR) gehören die Module Personaladministration (PA), Zeitwirtschaft (PT) und Personalabrechnung (PY).

1.4.3.2 Funktionsübergreifende Komponenten

Neben den eher fachlich ausgerichteten Komponenten gibt es in betrieblichen AwS auch eine Reihe von Querschnittsystemen, d.h. Systeme, die in allen funktionsbezogenen Komponenten zum Einsatz kommen. Hierzu gehören die klassischen Bürosysteme wie Text- und Tabellenverarbeitungssysteme, Workflowmanagementsysteme, Dokumentenmanagementsysteme, Groupwaresysteme, Entscheidungsunterstützungssysteme^[50] und Führungsinformationssysteme^[51]. Im R/3-System fallen die meisten dieser Systeme in die Komponente Cross Application Components (CA).

1.5 Organisationsstrukturen des R/3-Systems

Zur Einführung von SAP R/3 in Unternehmen bietet die SAP AG ein vorgefertigtes Organisationsschema an, mit dessen Hilfe die Strukturen eines Unternehmens und die Zuordnung der Geschäftsprozesse zu den R/3-Funktionalitäten abgebildet werden kann. Aus Gründen einer beschleunigten R/3-Einführung, wie sie z.B. bei der ASAP-Methode^[52] verfolgt wird, wird dieses Schema häufig nach vorgegebenen Regeln mit Beschreibungen der Organisationseinheiten eines konkreten Unternehmens besetzt. Je nach Komponente stehen dem Anwender unterschiedliche Organisationseinheitstypen^[53] zur Verfügung, denen er die konkreten Organisationseinheiten des Unternehmens zuordnen kann.

Das Organisationsschema ist hierarchisch strukturiert und an oberster Stelle steht – technisch gesehen – der Mandant, der im betriebswirtschaftlichen Konzern seine Entsprechung findet. Bei stark geographisch verteilten Unternehmen eines Konzerns wird aus datenorganisatorischen Gründen häufig ein redundanter Datenbestand auf verschiedenen Produktivmandanten vorgehalten, die über eine Funktionsintegration synchronisiert werden können.

Im Rahmen der Fallstudie wird ein fiktives Unternehmen vorgestellt, dessen betriebswirtschaftliche Strukturen auf die R/3-Funktionalitäten „gematched“ werden müssen. Die Studentinnen und Studenten haben die Aufgabe, das Unternehmensszenario auf die Organisationseinheitstypen der drei R/3-Komponenten Logistik, Rechnungswesen und Personalwirtschaft anzuwenden, um diese dann im Customizing des R/3-Systems abzubilden.

Nachfolgend werden die wichtigsten Organisationseinheitstypen der einzelnen Komponenten Logistik, Rechnungswesen und Personalwirtschaft vorgestellt.

1.5.1 Logistik (Logistics, LO)

Aus Sicht der Logistik werden die Organisationseinheiten des Unternehmens zunächst in Werke untergliedert. Unter einem Werk können Produktionsstätten, Betriebsstätten oder auch Niederlassungen verstanden werden. In einem Werk können Materialien produziert (Modul PP) oder Waren und Dienstleistungen (Module MM und PM) bereitgestellt werden. Werke werden immer einem Buchungskreis zugeordnet. Da der Organisationstyp Werk sowohl in der Materialwirtschaft, der Produktion und dem Vertrieb als auch in der Instandhaltung genutzt wird, müssen die u.U. gegensätzlichen Ziele dieser Bereiche aufeinander abgestimmt werden. Aus Sicht der Materialwirtschaft wird ein Werk z.B. als eine bestandsführende Einheit, aus Sicht des Vertriebs als übergreifende Einheit mehrerer Verkaufsorganisationen und Versandstellen und aus Sicht der Instandhaltung als Betriebsstätte, in der Instandhaltungsmaßnahmen geplant und vorbereitet werden, verstanden.

Beim Vertrieb eines weitgefächerten Produktspektrums bietet das R/3-System die Möglichkeit, Produkte in Gruppen (sog. Sparten) zu organisieren. Sparten dienen u.a. der Zuordnung von Materialien zu Geschäftsbereichen.

1.5.1.1 Materialwirtschaft (Material Management, MM)

In der Materialwirtschaft gibt es u.a. für die Aufgabenbereiche Einkauf und Lager zwei weitere Organisationseinheitstypen. Lagerorte sind konkrete Orte (mit Adresse) eines Unternehmens, an denen Bestände mengenmäßig geführt werden können.

Einkaufsorganisationen sind für die Beschaffung von Materialien (inkl. Verträge, Konditionen usw.) und Dienstleistungen zuständig. Eine Einkaufsorganisation kann mehreren Buchungskreisen (zentraler Einkauf für Konzern) oder einem einzelnen (eigener Einkauf für jedes Unternehmen) zugeordnet werden.

Abbildung in dieser Leseprobe nicht enthalten

Bild 6: Organisationsschema der Materialwirtschaft (ohne technische Systemebene)^[54]

1.5.1.2 Vertrieb (Sales & Distribution, SD)

Für den Verkauf werden analog zu den Organisationseinheiten der Materialwirtschaft Verkaufsorganisationen definiert. Eine Verkaufsorganisation ist verantwortlich für den Vertrieb bestimmter Produkte und Dienstleistungen innerhalb eines Werkes. Der Vertriebsweg kennzeichnet den Weg, auf dem verkaufsfähige Materialien oder Dienstleistungen zum Kunden gelangen. Typische Beispiele für Vertriebswege sind der Großhandel, der Direktverkauf oder der Verkauf über das Internet. Durch die Kombination von Verkaufsorganisationen, Vertriebswegen und Sparten lassen sich Vertriebsbereiche (z.B. Vertrieb Nord, Großhandel etc.) definieren. Sie werden für die Preissteuerung sowie die gezielte Auswertung von Vertriebsdaten (z.B. Umsatzanalysen) benötigt.

Abbildung in dieser Leseprobe nicht enthalten

Bild 7: Organisationsschema des Vertriebs (ohne technische Systemebene)^[55]

1.5.2 Rechnungswesen (AC, Accounting)

1.5.2.1 Externes Rechnungswesen

Die kleinste Organisationseinheit, für die nach der Handelsgesetzgebung ein Einzelabschluss zu erstellen ist, wird im R/3-System als Gesellschaft bezeichnet. Steuerrechtlich bedingte Unternehmenseinheiten werden in R/3 als Buchungskreise abgebildet. Eine Gesellschaft besteht aus einem oder mehreren Buchungskreisen. Ein Buchungskreis ist die kleinste Organisationseinheit des externen Rechnungswesens, für die eine vollständige, in sich abgeschlossene Buchhaltung abgebildet werden kann, und ermöglicht die Erstellung eines Einzelabschlusses mit Bilanz sowie Gewinn- und Verlustrechnung. Nationale Unternehmen oder Betriebsstätten eines international agierenden Unternehmens werden in der Regel als Buchungskreise abgebildet.

Orthogonal zu den rechtlich bedingten Organisationseinheiten liegen die aus Markt- oder Produktsicht notwendigen Organisationseinheiten (Segmente wie Divisionen, Sparten, Geschäftsfelder etc.). Dafür bietet das R/3-System u.a. den Organisationstyp Geschäftsbereich an. Geschäftsbereiche dienen in erster Linie der buchungs­kreisübergreifenden, konzerninternen Strukturierung des Unternehmens mit dem Ziel externer segmentbezogener Berichterstattung. Dadurch können u.a. interne Bilanzen sowie Gewinn- und Verlustrechnungen erstellt werden.

1.5.2.2 Internes Rechnungswesen

Aus Sicht des internen Rechnungswesens muss definiert werden, auf welcher Ebene die Kostenrechnung angesiedelt werden soll. Dies wird über die Zuordnung von einem oder mehreren Buchungskreisen zu Kostenrechnungskreisen ermöglicht. Ein Kostenrechnungskreis ist eine Organisationseinheit des Unternehmens bzw. Konzerns, für die eine vollständige, in sich abgeschlossene Kostenrechnung durchgeführt werden kann. Generell kann man zwischen einer zentral (alle Buchungskreise sind Bestandteil eines Kostenrechnungskreises) und einer lokal organisierten Kostenrechnung für jeden Buchungskreis unterscheiden. Im ersten Fall müssen alle Buchungskreise den gleichen operativen Kontenplan nutzen. Bei der Einführung je eines Kostenrechnungskreises pro Buchungskreis sind die Freiheiten bei der Gestaltung der Kostenrechnung zwar vielfältiger, jedoch lassen sich kostenbezogene Aussagen über einen Buchungskreis hinweg kaum oder nur nach aufwendigen Operationen treffen.

Abbildung in dieser Leseprobe nicht enthalten

Bild 8: Organisationsschema des Rechnungswesens (ohne technische Systemebene)^[56]

1.5.3 Personalwirtschaft

Aus der Sicht des noch jungen Moduls der Personalwirtschaft ergeben sich relativ wenige Organisationseinheitstypen. Auf der obersten Ebene existiert hier nur der Personalbereich, der einen nach personal-administrativen, zeitwirtschaftlichen und abrechnungsorganisatorischen Gesichtspunkten abgegrenzten Unternehmensbereich darstellt und somit dem Buchungskreis zugeordnet ist. Der Grund für eine Zuordnung des Personalbereiches zum Buchungskreis ist im externen Rechnungswesen begründet. So werden Personalaufwendungen innerhalb einer in sich geschlossenen Buchhaltung bilanziert, eine kostenrechnerische Auswertung ist dennoch über die Kostenrechnungskreise möglich, da die Buchungskreise meist einem zentralen Kostenrechnungskreis zugeordnet sind.

Ferner existiert noch der Personalteilbereich, der dem Personalbereich zugeordnet ist. Der Personalteilbereich untergliedert einen Personalbereich nach funktionalen Gesichtspunkten. Beispielsweise könnte ein Konzern die Personalbereiche Frankfurt, New York und Amsterdam noch jeweils in die Personalteilbereiche Rechenzentrum, Vertrieb, Marketing etc. unterteilen, um unterschiedlichen Arbeitszeitmodellen auf Länderebene gerecht zu werden.

Abschließend werden personalbezogene Regelungen mit Hilfe der Mitarbeitergruppe und dem Mitarbeiterkreis festgelegt. So ist es beispielsweise möglich, eine Mitarbeitergruppe Aktive in die Mitarbeiterkreise Bewerber und Partner zu unterteilen.

Abbildung in dieser Leseprobe nicht enthalten

Bild 9: Organisationsschema der Personalwirtschaft (ohne technische Systemebene)^[57]

2 Vorgehensmodelle zur Entwicklung von AwS

2.1 Entwicklungsprozesse und Vorgehensmodelle

2.1.1 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.^[58]

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.

2.1.2 Rückgekoppeltes Mehr-Kreislaufsystem

Das Mehr-Kreislaufsystem besteht aus zwei Kreisläufen.^[59] 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.

[...]

^[1] Vgl. Ferstl 1998, Seite 1 ff.

^[2] Vgl. Schulten 2005, Seite 2 f.

^[3] Vgl. Kapitel 1.3

^[4] Vgl. Ferstl 1998, Seite 4

^[5] Vgl. Bild 2, Seite 3

^[6] Vgl. Ferstl 1998, Seite 180

^[7] Vgl. Ferstl 1998, Seite 181

^[8] Vgl. Buck-Emden 1996, Seite 180

^[9] Die Gespräche und die Beobachtungen wurden zu Beginn des Jahres 2005 bei einer der FH benachbarten Firma durchgeführt. Studentinnen und Studenten der FH Aschaffenburg waren im Rahmen ihres Pflichtpraktikums an der R/3-Einführung im Unternehmen beteiligt und berichteten in einem Anerkenntnisgespräch ausführlich.

^[10] Vgl. Pasckert 1999, Seite 46 f.

^[11] Parametrisierung meint die Einstellung von softwarespezifischen „Schaltern“, die die gesamte Programmvielfalt eines Standardsoftware-Produktes auf die vom jeweiligen Unternehmen benötige Funktionalität reduziert. Diese wird in einem umfassenden Customizing-Projekt (Vgl. Kapitel 3) modulbezogen durchgeführt.

^[12] Vgl. Preßmar 1998, Seite 48

^[13] Complementary Software Partner

^[14] Vgl. Buck-Emden 1996, Seite 11 f.

^[15] Vgl. Schmelzer 2004, Seite 50 f.

^[16] Vgl. Mertens 2004, Seite 1

^[17] Syn. Module

^[18] Vgl. Schmelzer 2004, Seite 45 ff.

^[19] Vgl. Scheer 1998, Seite 93 ff.

^[20] Für eine detaillierte Betrachtung der Thematik „Modellierung in Ereignisgesteuerten Prozessketten“ sei auf die Vorlesung von Herrn Prof. Hager der FH Liechtenstein verwiesen.

^[21] Die Sichten lassen sich in die Organisationssicht, Datensicht, Funktionssicht, Prozessicht und Leistungssicht unterscheiden.

^[22] Vgl. Preßmar 1998, Seite 60

^[23] Zwei Hilfestellungen sind das Mapping (d.h. der Abgleich der eigenen, unternehmensspezifischen Geschäftsprozesse und Organisationsstrukturen mit den vom System angebotenen Prozessen und Strukturen) und das Redlining (d.h. Selektion der für ein Unternehmen geeigneten, im Referenzmodell dokumentierten Prozesse im Hinblick auf das Customizing des Systems)

^[24] IDES (Internet Demonstration and Evaluation System): Modellunternehmen zur Durchführung von Beispielgeschäftsprozessen, zur Demonstration, für Schulungen und Tests.

^[25] Vgl. Buck-Emden 1996, Seite 27 f.

^[26] Die Performanz des C/S-Systems ist vom System-Administrator oder Anwender durch die Messung der Antwortzeiten feststellbar.

^[27] Vgl. Ferstl 1998, Seite 187

^[28] Syn. GUI (Graphical User Interface)

^[29] Syn. WAN (Wide Area Network)

^[30] Syn. LAN (Local Area Network)

^[31] Eine XML-Anbindung kann mittels eines Internet Transaction Servers und eines Web-Servers erfolgen.

^[32] Vgl. Hagemann 2003, Seite 22 f.

^[33] Syn. Felder; vgl. auch Will 1998, Seite 41 f.

^[34] Vgl. Meier 1998, Seite 5 ff.

^[35] CORBA: Common Object Request Broker Architecture der Object Management Group

^[36] Vgl. Buck-Emden 1996, Seite 84-86

^[37] Vgl. Gadatsch 2003, Seite 128

^[38] Vgl. Gadatsch 2003, Seite 258

^[39] Ein R/3-System besteht in diesem Fall aus mehreren R/3-Instanzen.

^[40] Vgl. Buck-Emden 1996, Seite 116

^[41] Syn. Logische Services

^[42] Vgl. Buck-Emden 1996, Seite 117

^[43] Syn. Logon-Gruppen

^[44] Vgl. Buck-Emden 1996, Seite 130 ff.

^[45] Vgl. Buck-Emden 1996, Seite 138 ff.

^[46] Vgl. Hildebrand 2000, Seite 171 ff.

^[47] Eine detaillierte Einführung in die Komponenten und Module des R/3-Systems erhalten Sie über die Vorlesung „Einführung in SAP R/3“ von Herrn Ernst Schulten, Lehrbeauftragter an der FH Aschaffenburg

^[48] Vgl. Buck-Emden 1996, Seite 195-209

^[49] Vgl. Buck-Emden 1996, Seite 210-213

^[50] Syn. Decision Support Systeme

^[51] Syn. Executive Information Systeme

^[52] ASAP ist eine Methode für die beschleunigte R/3-Einführung. ASAP steht für Accelerated SAP („beschleunigtes SAP“) und impliziert mit dem Akronym ASAP auch eine schnellstmögliche („as soon as possible“) Einführung. Vgl. hierzu Kapitel 2.2.3

^[53] Ein konkretes Unternehmen kann – je nach Größe – auf unterschiedliche SAP-Organisationseinheitstypen zurückgreifen, um sich selbst zu modellieren. Diese sind der Konzern, die Gesellschaft, der Buchungskreis, die Produktionsstätte, das Warenlager, das Einkäuferteam etc.

^[54] Vgl. Weidner 2005, Seite 38

^[55] Vgl. Weidner 2005, Seite 36

^[56] Vgl. Weidner 2005, Seite 34 f.

^[57] Vgl. Weidner 2005, Seite 37

^[58] Vgl. Schwarz 2000, Seite

^[59] Vgl. Domschke 2004, Seite 17