Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Themenüberblick
2 Grundlagen von Enterprise Resource Planning Systemen
2.1 Begriffsdefinition und -einordnung
2.1.1 Unterstützung von Geschäftsprozessen
2.1.2 Betriebswirtschaftliche Standardsoftware
2.1.3 Administrations- und Dispositionssystem
2.1.4 Integriertes Informationssystem
2.1.5 Abgrenzung zu verwandten Begriffen
2.2 Grundsätzlicher Aufbau
2.2.1 Drei-Schicht-Architektur
2.2.2 Unterteilung in Module
2.3 Möglichkeiten der Anpassung
2.3.1 Notwendigkeit von Anpassungsmöglichkeiten . .
2.3.2 Customizing und Schaltung von Modulen
2.3.3 Branchenlösungen
2.3.4 Anpassungsprogrammierung
2.4 Entwicklung von ERP-Software
2.4.1 Orientierung an allgemeinen Vorgehensmodellen
2.4.2 Entwicklung im Mehr-Kreislaufsystem
2.4.3 Unterschied zwischen System- und Anwendungsentwicklung
2.4.4 Organisation der Softwarelogistik
3 Grundlagen von Entwurfsmustern
3.1 Entwurfsmuster im Überblick
3.1.1 Erprobte Lösungen von Entwurfsproblemen
3.1.2 Resultat praktischer Erfahrungen
3.1.3 Konstruktion von Softwareentwürfen mit Entwurfsmustern .
3.1.4 Unabhängigkeit von Methoden und Programmiersprachen
3.1.5 Ursprung in der Architektur
3.2 Intentionen von Entwurfsmustern
3.2.1 Geschwindigkeit und Qualität des Entwurfsprozesses erhöhen
3.2.2 Nicht funktionale Softwarequalität berücksichtigen
3.2.3 Gemeinsames Vokabular zur effizienten Kommunikation
3.2.4 Dokumentation der Entwicklungen
3.3 Strukturierung durch Mustersysteme und Mustersprachen
3.3.1 Mustersysteme für unterschiedliche Anwendungsgebiete
3.3.2 Möglichkeiten der Beschreibung
3.3.3 Unterteilung in Kategorien
3.4 Arbeiten mit Entwurfsmustern
3.4.1 Verwendung bestehender Entwurfsmuster
3.4.2 Suchen neuer und Überarbeiten bestehender Entwurfsmuster
4 Geeignete Entwurfsmuster für ERP-Systeme
4.1 Entstehung des Mustersystems
4.1.1 Erarbeitung der Entwurfsmuster
4.1.2 Verwendete Kategorien
4.1.3 Verwendetes Beschreibungsschema
4.2 Entwurfsmuster für die Systementwicklung
4.2.1 Flexibilität
4.2.2 Datenbankzugriffe
4.2.3 Schnittstellen
4.3 Entwurfsmuster für die Anwendungsentwicklung .
4.3.1 Flexibilität
4.3.2 Datenbankzugriffe
4.3.3 Benutzeroberfläche
4.3.4 Business-Logik abbilden
4.3.5 Verarbeitung großer Datenmengen
5 Der Nutzen von Entwurfsmustern für ERP-Systeme
5.1 Moderater Nutzen bei der Neuentwicklung
5.2 Profit bei der Wartung und späteren Anpassungen
5.3 Unterstützung durch Softwarehersteller
5.4 Hilfe bei der Kommunikation
5.5 Ausbildung neuer Entwickler
6 Ausblick
A Literaturverzeichnis
B Internetverzeichnis
C Eidesstattliche Erklärung
2.1 Softwarekategorien
2.2 Kategorien betrieblicher Anwendungssysteme
2.3 Unterschiedliche Client/Server-Konfigurationen
2.4 User-Exits und Modifikationen im Standardquellcode .
2.5 Mögliche Softwaretransportwege
2.6 Systemlandschaft eines großen ERP-Herstellers
3.1 Kategorien zur Klassifikation von Entwurfsmustern .
3.2 Der Lebenszyklus eines Entwurfsmusters
4.1 Klassifikation der Muster für ERP-Systeme
4.2 Struktur des Entwurfsmusters Abstract Factory
4.3 Komponenten des Entwurfsmusters Factory Method
4.4 Aufbau des Musters Class Replacement
4.5 Ablaufstruktur bei einem Implicit Lock
4.6 Beispiel der Realisierung eines Table Data Gateway .
4.7 Beispiel eines Active Record
4.8 Komponenten des Entwurfsmusters Data Mapper
4.9 Tabellen und Klassen bei einer Single Table Inheritance
4.10 Tabellen und Klassen des Entwurfsmusters Class Table Inheritance
4.11 Tabellen und Klassen im Fall einer Concrete Table Inheritance . .
4.12 Struktur des Entwurfsmusters Facade
4.13 Aufbau des Entwurfsmusters Singleton
4.14 Komponenten des Entwurfsmusters Strategy
4.15 Struktur des Entwurfsmusters Command
4.16 Komponenten des Entwurfsmusters Business Process Command
4.17 Möglicher Ablauf bei einem Optimistic Offline Lock
4.18 Beispiel eines Ablaufes bei einem Pessimistic Offline Lock
4.19 Struktur des Entwurfsmusters Coarse-Grained Lock
4.20 Komponentenarten des Entwurfsmusters Model-View-Controller
4.21 Struktur des Entwurfsmusters Observer
4.22 Möglicher Aufbau des Entwurfsmusters Decorator
4.23 Struktur des Entwurfsmusters Keyed Attribute Retrieval
4.24 Beispiele für das Entwurfsmuster Whole Value
4.25 Mögliche Klassen zur Realisierung eines Cached Aggregate
4.26 Beispiel einer Unit of Work
Abbildung in dieser Leseprobe nicht enthalten
Kapitel 1
Moderne Unternehmen orientieren sich zunehmend an ihren Geschäftsprozessen. D. h. die einzelnen Funktionsbereiche eines Unternehmens, wie Einkauf, Materialwirtschaft, Produktion, Vertrieb, etc., werden nicht mehr isoliert, sondern als Ganzes betrachtet.
In diesem Zusammenhang rücken seit einigen Jahren Enterprise Resource Planning Systeme (ERP) in den Mittelpunkt des Interesses. ERP-Systeme sind umfassende integrierte Informationssysteme, welche Anwendungen zur Unterstützung sämtlicher Funktionsbereiche eines Unternehmens beinhal- ten. Sie eignen sich deshalb, um sämtliche Geschäftsprozesse und Geschäftsregeln eines Unternehmens abzubilden.1
Zur Entwicklung eines derartigen integrierten Informationssystems ist interdisziplinäres Know-how erforderlich. Es werden sowohl umfassende betriebswirtschaftliche, als auch fundierte technische Kenntnisse benötigt. Die Entwicklung eines ERP-Systems ist somit eine komplexe Aufgabe, die viel Erfahrung im Bereich der Softwareentwicklung erfordert.2
In diesem Zusammenhang ist es wichtig, neue Ideen aus dem Bereich der Softwareentwicklung auf ihre Tauglichkeit für die Entwicklung von ERP-Systemen zu prüfen.
Entwurfsmuster sind ein relativ junges Konzept der Softwareentwicklung. Inspiriert von einem Vorbild aus dem Bereich der Architektur, wird mit Entwurfsmustern versucht, Erfahrungen bei der Entwicklung von Software zu dokumentieren. Auf diesem Wege sollen viele Softwareentwickler von den Erfahrungen Einzelner profitieren.3
Ziel dieser Arbeit ist es, zu betrachten, welchen Einfluss das Konzept der Entwurfsmuster auf die Entwicklung von ERP-Systemen hat. Es soll erarbeitet werden, ob sich die von Entwurfsmustern dokumentierten Erfahrungen in ERP-Systemen widerspiegeln und welchen Nutzen Entwurfsmuster dadurch für ERP-Systeme haben oder in Zukunft haben könnten. Zu diesem Zweck gliedert sich die restliche Arbeit wie folgt:
Zunächst werden in Kapitel 2 die erforderlichen Grundlagen von ERP-Systemen beschrieben. Dabei wird der Begriff ERP-System definiert und von anderen Begriffen abgegrenzt. Außerdem wird auf spezielle Anforderungen an ERP-Systeme eingegangen sowie die Entwicklung von Software für ERPSysteme näher beleuchtet.
In Kapitel 3 wird dann in das Thema der Entwurfsmuster eingeführt. Auch hier wird zunächst der Begriff Entwurfsmuster definiert und seine Entwicklung betrachtet. Anschließend werden die mit Entwurfsmustern verbundenen Intentionen erläutert, sowie auf Möglichkeiten der Organisation und der Arbeit mit Entwurfsmustern eingegangen.
Nachdem die beiden Themen auf diese Weise zunächst isoliert betrachtet wurden, werden sie in Ka- pitel 4 zusammengeführt. In diesem Kapitel werden beispielhaft Entwurfsmuster beschrieben, welche bei der Entwicklung von ERP-Systemen Anwendung finden können. Zur besseren Übersichtlichkeit werden die einzelnen Entwurfsmuster dazu in einem so genannten Mustersystem organisiert. Im Anschluß daran wird in Kapitel 5 nochmals zusammenfassend auf den Nutzen von Entwurfsmu- stern für die Entwicklung von ERP-Systemen eingegangen. Dazu werden die im Rahmen von Kapitel 3 vorgestellten Intentionen kritisch beleuchtet und außerdem betrachtet, ob die von Entwurfsmustern beschriebenen Lösungsansätze bereits in ERP-Systemen Anwendung finden. Abschließend wird dann in Kapitel 6 ein kurzer Ausblick vorgenommen. Hier werden Entwicklungen skizziert, die erforderlich sind, um die Verwendung von Entwurfsmustern im Bereich der Entwicklung von ERP-Systemen weiter zu etablieren.
Kapitel 2
Mit dem Begriff Enterprise Resource Planning (ERP) werden Softwaresysteme bezeichnet, welche zur Unterstützung von Geschäftsprozessen eines Unternehmens dienen. Grundlegendes Merkmal ist dabei die Integration der einzelnen Funktionsbereiche eines Unternehmens, d. h. ein ERP-System stellt z. B. Funktionen für Fertigung, Vertrieb, Beschaffung, Finanzbuchhaltung und Verwaltung innerhalb einer Anwendung zur Verfügung.1
Nicht Teil eines ERP-Systems sind die technischen Funktionsbereiche eines Unternehmens, wie z. B. Forschung und Entwicklung. Für diese Bereiche gibt es eine spezielle Kategorie von Software.2 Hierzu zählen beispielsweise Computer Aided Design (CAD) und Computer Aided Engineering (CAE).3 Auf derartige Software wird im Rahmen dieser Arbeit nicht näher eingegangen.
Ursächlich für die Entstehung von ERP-Systemen war vor allem die zunehmende Geschäftsprozess- orientierung der Unternehmen seit Beginn der 90er Jahre. Wurden die einzelnen Funktionsbereiche früher isoliert betrachtet, wird nun eine ganzheitliche Sicht auf das Unternehmen bevorzugt.4 Dieses Umdenken machte auch Veränderungen in der betrieblichen Informationsverarbeitung erfor- derlich. Wurden die Anwendungssysteme der einzelnen Funktionsbereiche zuvor noch weitestgehend isoliert betrieben, so war nun eine Integration der einzelnen Systeme erforderlich. Dies rückte die Idee für umfassende integrierte Informationssysteme, welche ein komplettes Unternehmen abbilden können, in den Mittelpunkt des Interesses.5
Die Gartner Group führte Mitte der 90er Jahre den Begriff ERP für derartig integrierte Informationssysteme ein.6 Laut Gartner Group ist die schnelle und effiziente Abwicklung von Geschäftsprozessen der maßgebliche Vorteil eines solchen Informationssystems.7
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Softwarekategorien
Eigene Darstellung in Anlehnung an Kirchmer, M. (1999), S. 17
Um sich dem Begriff ERP-System noch weiter zu nähern, wird in den folgenden Abschnitten eine Einordnung des Begriffes in unterschiedliche Software-Klassifikationen vorgenommen. Im Anschluss daran wird auf die Vor- und Nachteile der integrierten Sichtweise eines ERP-Systems eingegangen. Zum Schluss wird dann noch eine Abgrenzung von ERP-Systemen zu ähnlichen bzw. verwandten Begriffen erfolgen.
Es gibt unterschiedliche Möglichkeiten Software zu klassifizieren. Eine von Kirchmer vorgenomme- ne Klassifikation8 zeigt Abbildung 2.1. Demnach kann Software allgemein in Systemsoftware und Anwendungssoftware unterteilt werden. Dabei bildet die Systemsoftware zusammen mit der Hard- ware die Grundlage für den Betrieb eines Rechners. Sie steuert und überwacht die Ausführung der Anwendungssoftware. Zur Anwendungssoftware hingegen zählen alle Programme, welche zur Lösung fachlicher Probleme dienen.9 ERP-Systeme sind zur Kategorie der Anwendungssoftware zu zählen. Anwendungssoftware lässt sich wiederum in Individualentwicklungen und Standardsoftware untertei- len. Bei einer Individualentwicklung wird Software von einem Unternehmen selbst oder in seinem Auftrag entwickelt. Dabei wird die Software speziell auf die betriebsspezifischen Abläufe abgestimmt. Standardsoftware hingegen wird in unterschiedlichen Unternehmen eingesetzt. Es sind jedoch nicht alle Unternehmen identisch, deshalb sind bei Standardsoftware Möglichkeiten der Anpassung an ver- schiedene Organisationen unerlässlich.10 Auf solche Möglichkeiten der Anpassung wird in Abschnitt 2.3 ausführlich eingegangen.
Die Vor- und Nachteile von Individualentwicklung und Standardsoftware werden in der entsprechen- den Fachliteratur ausführlich gegenübergestellt.11 12 Auch wenn die Realisierung eines ERP-Systems in Individualentwicklung prinzipiell möglich wäre, ist ERP-Software heutzutage nahezu ausschließlich Standardsoftware.13 Begründen lässt sich dies vor allem durch den hohen Aufwand und das umfassende Know-how, welche für die Entwicklung eines solchen integrierten Systems erforderlich sind. Außerdem existiert mittlerweile für fast jede Branche eine große Auswahl an ERP-Standardsoftware.14 Standardsoftware lässt sich nochmals in mathematisch-technische und betriebswirtschaftlich-admini- strative Software unterteilen. Mathematisch-technische Software wird überwiegend in Naturwissen- schaft und Forschung eingesetzt. Sie führt komplexe Berechnungen mit nur wenigen Daten durch. Betriebswirtschaftlich-administrativer Software dient zur Unterstützung der Arbeitsprozesse in Unter- nehmen. Hier werden vergleichsweise einfache Operationen mit sehr großen Datenmengen vollzogen.15 ERP-Systeme zählen hier eindeutig zur Kategorie der betriebswirtschaftlichen Software. Fowler u. a. definieren neben der angesprochenen Verwaltung großer Datenmengen weitere Besonderheiten von betriebswirtschaftlicher Software gegenüber anderen Arten von Software. Zu nennen sind hier etwa die hohe Zahl der Benutzer, welche gleichzeitig auf die Daten zugreift, die Existenz zahlreicher Benut- zerschnittstellen zur Erfassung, Bearbeitung und Anzeige der Daten, sowie die komplexe und häufig wechselnde Geschäftslogik.16
Betriebswirtschaftlich-administrative Software lässt sich noch weiter in branchenneutrale und bran- chenspezifische Software unterteilen. ERP-Systeme existieren in beiden Kategorien. So bieten zahlrei- che Hersteller von ERP-Software neben einer branchenneutralen Lösung noch weitere Lösungen an, die jeweils speziell auf die Bedürfnisse einer bestimmten Branche abgestimmt sind.17 Auf die Gründe für die Existenz von branchenspezifischer ERP-Software wir in Abschnitt 2.3.3 näher eingegangen.
Im vorherigen Abschnitt wurden ERP-Systeme der Kategorie der betrieblichen Standardsoftware zu- geordnet. Die Einsatzbereiche solcher betrieblichen Standardsoftware lassen sich gemäß den Aufga- benbereichen eines Unternehmens noch weiter untergliedern. Je nach Branchenzugehörigkeit zählen zu diesen Aufgabenbereichen u. a. Beschaffung, Lagerhaltung, Fertigung, Vertrieb, Marketing, Finanz- buchhaltung, etc.18
Als weiteres Gliederungskriterium können die Typen der Aufgaben, welche in den genannten Aufgabenbereichen unterstützt werden, dienen. Mertens unterscheidet in diesem Zusammenhang nach Administrations-, Dispositions-, Planungs- und Kontrollsystemen.19
Administrationssysteme unterstützen bei der Massendatenverarbeitung, indem sie das Personal von Routineaufgaben entlasten und die Verarbeitungsprozesse beschleunigen.20
Hingegen sollen Dispositionssysteme menschliche Entscheidungen vorbereiten oder komplett ersetzen. Hier geht es entweder darum eine bessere Entscheidung als der Mensch oder eine Entscheidung gleicher Qualität schneller als der Mensch zu treffen.21
Während Dispositionssysteme eher zur Unterstützung von kurzfristigen Entscheidungen gedacht sind, unterstützen Planungssysteme mittel- bis langfristige Entscheidungen.22 Die mit Planungssystemen
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Kategorien betrieblicher Anwendungssysteme Eigene Darstellung in Anlehnung an Mertens, P. (1997), S. 6
herbeigeführten Entscheidungen sind außerdem weit weniger strukturiert und in höheren Mangerebe- nen angesiedelt, als solche Entscheidungen, welche mit einem Dispositionssystem herbeigeführt wer- den.23
Kontrollsysteme dienen wiederum dazu Planabweichungen zu erkennen und Hinweise darauf zu geben, dass korrigierende Maßnahmen eingeleitet werden müssen.24
Durch Kombination der einzelnen Gliederungskriterien erhält man das in Abbildung 2.2 dargestellte Schema. Wie bereits in Abschnitt 2.1.1 erwähnt, erstreckt sich ein ERP-System über sämtliche Auf- gabenbereiche eines Unternehmens. Es handelt sich gemäß Mertens also um ein horizontal integriertes System.25
Entsprechend des Aufgabentyps lässt sich ein ERP-System den Administrations- und Dispositionssy- stemen zuordnen. Denn neben der Verwaltung von Massendaten, wie Kunden, Artikeln oder Kunden- aufträgen, unterstützt ein ERP-System ebenfalls bei einigen Entscheidungen. So können anhand von Mindestbeständen, Wiederbeschaffungszeiten und Lagerbewegungen beispielsweise geeignete Mengen und Zeitpunkte zur Wiederbeschaffung von Artikeln und Materialien ermittelt werden.26 Möglichkeiten der Lösung unstrukturierter Entscheidungsprobleme und der Überwachung von Planer- füllungen gehören hingegen nicht zu den unterstützten Aufgabentypen eines ERP-Systems. Es ist somit weder zur Kategorie der Planungs- noch zu der Kategorie der Kontrollsysteme zu zählen.27 Fasst man die in diesem Abschnitt gemachten Ausführungen zusammen, kann man ein ERP-System als Administrations- und Dispositionssystem mit hoher horizontaler Integration klassifizieren.
Die zuvor bereits mehrmals angesprochene Integration der unterschiedlichen Funktionsbereiche in ei- nem ERP-System wird überwiegend durch Datenintegration erreicht. D. h. ein ERP-System besitzt eine zentrale Datenbank in welcher die benötigten Daten für alle Unternehmensbereiche gespeichert werden.28
Zusätzlich zur Datenintegration bedienen sich ERP-Systeme auch noch der Funktionsintegration. Ein ERP-System stellt also einen zentralen Fundus von Programmen zu Verfügung, auf den sämtliche Unternehmensbereiche zugreifen können. Dies ist insbesondere von Vorteil, wenn mehrere Unternehmensbereiche dieselben Funktionen benötigen. Solche Funktionalitäten müssen bei einem ERP-System nicht mehrfach implementiert werden.29
In Abschnitt 2.1.1 wurde bereits erwähnt, dass ERP-Systeme, aufgrund ihrer integrierten Sicht auf ein Unternehmen helfen, die Abwicklung von Geschäftsprozessen effizienter zu gestalten. Dass eine inte- grierte Informationsverarbeitung dem Informationsfluss eines Geschäftsprozesses besser entspricht, als die Verarbeitung der anfallenden Informationen mittels mehrerer isolierter Anwendungssysteme, wird an den durch Mertens erarbeiteten Vorteilen einer integrierten Informationsverarbeitung deutlich:30 Aufgrund der Datenintegration kann der manuelle Aufwand zur Erfassung von Daten deutlich re- duziert werden. So müssen bestimmte Daten, welche für mehrere Unternehmensbereiche erforderlich sind, nur noch einmal erfasst werden. Beispiel könnte hier eine Kundenadresse oder der Preis eines Artikels sein. Außerdem können die Ergebnisse einzelner Vorgänge wieder als Grundlage weiterer Be- rechnungen dienen. Die bei der Rechnungserstellung erzeugten Rechnungspositionen könnten etwa als Grundlage für die Erstellung einer Vertriebsstatistik dienen. Die Reduzierung der manuellen Eingaben spart nicht nur Zeit, sondern verringert auch die Gefahr von Fehlern bei der Dateneingabe.
Durch die Speicherung aller Daten an einer zentralen Stelle wird es erst möglich bestimmte Funk- tionen zu realisieren. So sind bereichsübergreifende Statistiken bei isolierten Anwendungssystemen nur schwer möglich. Die Vermeidung von Datenredundanzen, welche durch eine zentrale Datenbank erreicht wird, spart Speicherplatz und verhindert, dass Daten bei Änderungen an vielen verschiedenen Stellen angepasst werden müssen. Da die Daten an vielen Stellen eines ERP-Systems verwendet wer- den, ist die Wahrscheinlichkeit, dass fehlerhaft eingegeben Daten schnell bemerkt werden, recht groß. Da in einem ERP-System Aktionen inklusive aller erforderlichen Folgemaßnahmen fest implementiert sind, kann die Durchführung ganzer Prozessketten weitestgehend automatisiert werden. Auf diese Wei- se wird die Gefahr, dass bestimmte Routine-Maßnahmen vergessen werden, deutlich verringert. So ist es z. B. nicht mehr möglich, dass ein bestätigter Kundenauftrag nicht an die Fertigung gemeldet wird und somit bei der Bestimmung des zu produzierenden Primärbedarfes unberücksichtigt bleibt.
Ein weiterer Vorteil eines integrierten Systems ist die einheitliche Benutzeroberfläche. So müssen sich beispielsweise Mitarbeiter, die in eine andere Abteilung versetzt werden, nicht an eine komplett neue Software gewöhnen, sondern sind zumindest mit dem Bedienmodell der Software vertraut.31 Neben den vielen Vorteilen bringt ein integriertes Informationssystem jedoch auch einige Probleme mit sich. Wie beschrieben sind bei einem ERP-System alle Daten und Funktionen an zentraler Stelle abgelegt. Aus diesem Grund muss durch ein umfassendes Berechtigungssystem sichergestellt werden, dass ein Benutzer nur Zugriff auf solche Funktionen und Daten erhält, welche er tatsächlich verwenden darf. Wenn die einzelnen Abteilungen eines Unternehmens jeweils eigene Anwendungssysteme verwen- den würden, könnte eine solche Berechtigungsprüfung wesentlich simpler aussehen.32 Durch die redundanzfreie Speicherung der Daten werden diese schnell in einer großen Zahl von Pro- grammen verbreitet. Fehlerhaft eingegeben Daten können deshalb schnell zahlreiche Konsequenzen nach sich ziehen. Aus diesem Grund ist eine sorgfältige Prüfung der durch Benutzer eingegebenen Daten von hoher Wichtigkeit. Insbesondere vor dem Löschen von Daten ist eine Verwendungsprüfung durchzuführen, um sicherzustellen, dass keine Daten gelöscht werden, die an anderen Stellen im Sy- stem noch verwendet werden.33
Aufgrund der Vollständigkeit müssen in einem ERP-System auch solche Vorgänge abgebildet werden, deren Automation aufgrund der geringen Zahl oder des hohen Eingabeaufwandes normalerweise nicht wirtschaftlich wäre. Werden jedoch nicht alle möglichen Vorgänge im System nachgebildet, so kann es schnell zu Inkonsistenzen oder einem Datenbestand kommen, welcher nicht mehr der Realität ent- spricht.34
Nicht zuletzt ist die Entwicklung und Einführung eines ERP-Systems mit sehr hohem Aufwand verbunden und erfordert Mitarbeiter mit viel Erfahrung.35 Auf diesen Punkt wird in Abschnitt 2.4 noch näher eingegangen werden.
Im Zusammenhang mit ERP-Systemen finden sich in der Literatur noch zahlreiche andere Begriffe und Abkürzungen. Dieser Abschnitt soll dazu dienen diese Begriffe zu erläutern und vom Begriff ERP abzugrenzen.
Die Begriffe Enterprise Resource Management (ERM),36 Enterprise Management System (EMS)37 und Integriertes betriebliches Standardinformationssystem (IBSIS)38 stellen Synonyme zum Begriff ERP da. Sie haben sich allerdings alle nicht in dem Maße durchgesetzt, wie der durch die Gartner Group eingeführte Begriff ERP.
Material Requirements Planning (MRP) und Manufacturing Resource Planning (MRPII) sind Begrif- fe, welche häufig in Verbindung mit ERP genannt werden. Während sich das frühere MRP auf die Verwaltung der zur Produktion benötigten Materialien beschränkte, wurden mit MRPII auch andere für die Produktion benötigte Resourcen, wie Personal und Maschinenkapazitäten, in die Planung mit eingeschlossen.39
ERP ist gewissermaßen die Fortführung der Begriffe MRP und MRPII. Schließlich erweitert es die Sichtweise von MRPII, indem es sich nicht mehr nur auf die Produktion beschränkt, sondern auch Resourcen der anderen Unternehmensbereiche mit einbezieht.40
Neuerdings taucht auch immer öfter der Begriff ERPII auf. Dieses von der Gartner Group eingeführte Konzept erweitert den ERP-Gedanken nochmals. Es macht nicht mehr an den Grenzen eines Unternehmens halt, sondern bezieht Geschäftspartner aktiv mit ein. D. h. Lieferanten und Kunden erhalten direkten oder indirekten Zugriff auf das Informationssystem des Unternehmens.41
In vielen Quellen trifft man außerdem auf den Begriff Warenwirtschaftssystem (WWS). Ein WWS bezeichnet nur einen Ausschnitt des ERP-Konzeptes. Es beschränkt sich auf die Funktionsbereiche, welche von reinen Handelsunternehmen benötigt werden, die Fertigung bleibt hingegen unberücksich- tigt.42
Das andere Extrem bilden Systeme der Produktionsplanung und -steuerung (PPS). Sie beschränken sich nahezu ausschließlich auf Funktionen, die von der fertigenden Industrie benötigt werden. PPS- Systeme sind im Vergleich zu rein kaufmännischen Systemen wie WWS relativ anspruchsvoll. Dies begründet sich in den wesentlich komplexeren Datenstrukturen und Planungsproblemen im Bereich der Fertigung.43
Ein ERP-System kann hinsichtlich der unterstützten Funktionen als Kombination eines WWS und PPS bezeichnet werden. Dies erklärt auch, dass die Grenzen zwischen reinen PPS-Systemen und ERP-Systemen immer mehr verschwimmen.44
Heutige ERP-Systeme verwenden eine Client/Server-Architektur.45 Man versteht darunter, dass die Bearbeitung von Aufgaben auf mehrere übers Netzwerk verbundene Rechner aufgeteilt wird. Dabei bieten Server bestimmte Leistungen an, welche von den Clients angefordert und somit dem Endanwender zur Verfügung gestellt werden.46
Es gibt unterschiedliche Möglichkeiten der Konfiguration einer solchen Client/Server-Architektur. Entsprechend Abbildung 2.3 kann entweder ein Server seine Dienste mehreren Clients anbieten, oder ein Server stellt seine Dienste einem oder mehreren anderen Servern zur Verfügung, welche ihre Dienste dann wiederum den Clients anbieten.47
Je nach Anzahl der vertikalen Ebenen bezeichnet man die resultierende Client/Server-Architektur als Zwei-, Drei-, Vier- oder ganz allgemein als Mehr-Schicht-Architektur (Multi Tier Architecture). Am Weitesten verbreitet ist heutzutage eine Drei-Schicht-Architektur, welche die Aufgaben in Datenhal- tung, anwendungsbezogene Funktion und Repräsentation bzw. Benutzeroberfläche unterteilt.48 Wie Abbildung 2.3 zeigt, können trotz dieser Dreiteilung mehrere Schichten auf einem Rechner be- trieben werden. So kann es etwa bei kleinen Systemen sinnvoll sein Datenhaltungs- und Anwendungs- schicht auf einem zentralen Rechner zu betreiben und nur die Präsentation an Clients auszulagern. Bei größeren Systemen kann die Anwendungsschicht je nach erforderlicher Leistungsfähigkeit auf einen oder mehrere Anwendungsserver ausgelagert werden. Man spricht bei einer solchen Erhöhung der Lei- stungsfähigkeit durch hinzufügen neuer Ebenen auch von vertikaler Skalierbarkeit.49 Zusätzlich zur horizontalen Skalierbarkeit ist es ohne großen Aufwand möglich, neue Clients hinzu- zufügen, um weiteren Mitarbeitern den Zugriff auf das ERP-System zu ermöglichen. Diese Möglichkeit, weitere Arbeitsplätze in das System einzubinden, wird als horizontale Skalierbarkeit bezeichnet.50
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Unterschiedliche Client/Server-Konfigurationen Quelle: Appelrath, H.-J., Ritter, J. (2000), S. 17
Neben der gerade beschriebenen hohen Skalierbarkeit einer solchen mehrstufigen Architektur bietet sich die Möglichkeit, Systeme mit hoher Ausfallsicherheit einzurichten. So stehen beispielsweise in Variante 3 aus Abbildung 2.3 mehrere Anwendungsserver zur Verfügung. Fällt einer dieser Server aus Wartungs- oder Störungsgründen aus, kann mit den anderen Servern der Systembetrieb trotzdem aufrechterhalten werden.
Prinzipiell besteht durch die Mehr-Schicht-Architektur auch die Möglichkeit, das ERP-System nach den einzelnen Unternehmensbereichen zu gliedern. In diesem Falle würde jeder Unternehmensbereich seinen eigenen Anwendungsserver erhalten. Die Integration fände dann nur noch über den zentralen Datenbankserver statt. Auf diese Weise wäre z. B. gewährleistet, dass die in Abschnitt 2.1.5 angespro- chenen komplexen Berechnungen im Bereich der Fertigung die anderen Unternehmensbereiche nicht beeinträchtigen.51
Theoretisch erlaubt die Drei-Stufen-Architektur sogar die Einrichtung mehrerer Datenbankserver. Ei- ne solche Konfiguration ist jedoch in der Praxis nur sehr selten anzutreffen, da sie mit der in Abschnitt 2.1.4 erläuterten Datenintegration kollidieren würde.52
Nachdem im vorherigen Abschnitt der Aufbau eines ERP-Systems aus der technischen Sicht betrachtet wurde, soll dieser Abschnitt den Aufbau aus fachlicher Sicht beleuchten. Unter fachlichen Gesichtspunkten lässt sich ein ERP-System in so genannte Module unterteilen. Ein Modul entspricht dabei einem Baustein, welcher einen Teil der Funktionen des ERP-Systems beinhaltet. Diese einzelnen Bausteine lassen sich auf unterschiedliche Weise zu einem Gesamtsystem kombinieren.53 Thome sieht in den so entstehenden zahlreichen Kombinationsmöglichkeiten sogar einen Widerspruch zur Einordnung von ERP-Systemen als Standardsoftware.54
Die Modulaufteilung erfolgt entsprechend der einzelnen Aufgabenbereiche eines Unternehmens. So existieren beispielsweise unterschiedliche Module für Beschaffung, Vertrieb, Produktion, Lagerlogistik, etc. Jedes dieser Module beinhaltet alle benötigten Funktionen des entsprechenden Unternehmensbe- reiches.55
So beinhaltet ein typisches Vertriebs-Modul beispielsweise Funktionalitäten zur Abwicklung von Kundenaufträgen sowie die Verwaltung von Kundenstammdaten. Zusätzlich existieren meist ein oder zwei zusätzliche Module, welche die Basis-Funktionalität des Systems bereitstellen. Hierzu zählen u. a. Benutzer- und Berechtigungsverwaltungen, Dienste zur Systemüberwachung und bereichsübergreifende Stammdaten, wie Mengeneinheiten, Sprachen und Währungen.56
Bei der Entwicklung von ERP-Systemen bietet sich durch diesen modularen Aufbau der Vorteil, dass der Entwurf der einzelnen Module weitestgehend getrennt voneinander vorgenommen werden kann. Dies verringert die Komplexität der Entwürfe und macht sie somit überschaubar und handhabbar.57 Bei der Einführung eines ERP-Systems in eine Unternehmung können individuell die Module aus- gewählt werden, welche von dem jeweiligen Unternehmen benötigt werden. So kann sich in der oben beschriebenen Weise jedes Unternehmen ein individuelles Gesamtsystem zusammenstellen, welches nur die von ihm benötigten Funktionalitäten beinhaltet. Zudem macht die Unterteilung in Modu- le eine schrittweise Einführung des Systems möglich. So kann ein Unternehmen z. B. zunächst nur Beschaffung und Vertrieb mit einem ERP-System abbilden und nach und nach die anderen Unterneh- mensbereiche mit einbinden, indem die entsprechenden Module später hinzugeschaltet werden.58
Ein Kritikpunkt ist allerdings, dass der modulare Aufbau bislang nur innerhalb der Produkte eines Herstellers konsistent ist. D. h., das Produktionsmodul des einen Herstellers lässt sich nicht ohne größeren Aufwand mit dem Vertriebsmodul eines anderen Herstellers kombiniert betreiben. Die Möglichkeit, sich für jeden Bereich die beste Lösung zu suchen und diese dann zu kombinieren, bietet sich dem Anwender somit leider auch nicht durch den modularen Aufbau.59
In Abschnitt 2.1.2 wurde ausführlich erläutert, dass es sich bei ERP-Software um Standardsoftwa- re handelt. Dies bedeutet, die gleiche ERP-Software wird in mehreren Unternehmen eingesetzt. Da sich die Anforderungen der einzelnen Unternehmen an ein ERP-System jedoch vielfach unterscheiden, muss es Möglichkeiten zur Anpassung der ERP-Software an das jeweilige Unternehmen geben.60 Der Einsatz von ERP-Software in unterschiedlichen Unternehmen ist jedoch nicht der einzige Grund, warum ERP-Systeme flexibel gegenüber Veränderungen sein müssen. So verändern sich im Laufe der Zeit z. B. auch innerhalb eines Unternehmens die Anforderungen an ein ERP-System. Dies kann unterschiedliche Gründe haben. Zum einen können bestimmte Anforderungen anfänglich zu ungenau oder falsch definiert worden sein. Desweiteren kann es sein, dass im Laufe des Betriebes der ERP-Software neue Einsatzmöglichkeiten entdeckt werden und daraus neue Anforderungen entstehen, die ursprünglich nicht existierten.61
Flexibilität ist außerdem erforderlich, weil sich Änderungen an den Geschäftsprozessen eines Unter- nehmens ergeben können. Ursachen hierfür können beispielsweise Ausnahmeregelungen sein, welche Kunden in Verhandlungsprozessen gewährt werden oder auch die Erlassung von neuen Gesetzen durch den Staat.62
Es muss also Möglichkeiten geben auf Veränderungen innerhalb eines Unternehmens und seiner Um- welt reagieren zu können, denn nur Unternehmen, welche Ihr Informationssystem schnell an sich verändernde Umweltsituationen anpassen können, sind in der Lage sich dauerhaft im Wettbewerb zu behaupten.63
Grundsätzlich lässt sich die Anpassung von ERP-Systemen in zwei Bereiche unterteilen. Die Konzep- tion von Anpassungsmöglichkeiten und die Realisierung des Anpassungsprozesses. Die Konzeption von Anpassungsmöglichkeiten bedeutet, dass zum Zeitpunkt der Entwicklung einzelner Komponenten vorausgedacht werden muss. Nur so kann ein späteres Anpassungsvermögen gewährlei- stet werden. Ggf. müssen hier auch schon geeignete Werkzeuge zur späteren Anpassung bereitgestellt werden.64
Mit der Realisierung des Anpassungsprozesses ist gemeint, dass die bereitgestellten Anpassungsmöglichkeiten genutzt werden, um die einzelnen Komponenten eines ERP-Systems ans Unternehmen und im Laufe des Betriebes an auftretende Veränderungen anzupassen.65
In den folgenden Abschnitten werden unterschiedliche Möglichkeiten der Anpassung von ERP-Syste- men vorgestellt.
Eine Möglichkeit der Anpassung ist die bereits in Abschnitt 2.2.2 angesprochene Aufteilung in Module. Ein Unternehmen kann sich mit Hilfe der Module ein individuelles Gesamtsystem zusammenstellen. Die Flexibilität dieses Ansatzes ist jedoch nicht besonders hoch. Schließlich handelt es sich bei der Schaltung von Modulen lediglich um das Auswählen von benötigten Funktionsgruppen aus einer Men- ge möglicher Funktionsgruppen. Eine Einflussnahme auf den Ablauf einzelner Funktionen ist hingegen nicht möglich.66
Mehr Flexibilität bietet hier schon das so genannte Customizing. Der Begriff Customizing leitet sich vom englischen Ausdruck custom made ab. Dieser bedeutet übersetzt ins Deutsche maßgearbeitet.67 Im ERP-Umfeld bezeichnet der Begriff Customizing die Anpassung einer Standardsoftware über Parametereinstellungen.68
Es gibt anwendungsübergreifende und anwendungsspezifische Einstellungen im Customizing. Beispiele für anwendungsübergreifende Customizing-Einstellungen wären Sprachen, Währungen und Maßein- heiten. Anwendungsspezifisches Customizing bezieht sich immer auf ein bestimmtes Anwendungsge- biet des ERP-Systems. Hier wären z. B. Regeln zur Preisfindung und Verfügbarkeitsprüfung, Vorge- hensweise bei der Auftragsabwicklung oder aber Zugriffs- und Nutzungsberechtigungen zu nennen.69
Die Konfigurationsmöglichkeiten mittels Customizing-Einstellungen werden vielfach als entscheiden-der Schritt zur Flexibilisierung von ERP-Systemen betrachtet. Dies liegt u. a. daran, dass Einfluss auf das Verhalten der Software genommen werden kann, ohne Änderungen am Quellcode vornehmen zu müssen. Somit ist es prinzipiell auch dem Anwender selbst möglich das Verhalten der Software zu ändern.70
Heutige ERP-Software besitzt jedoch eine so hohe Zahl solcher Einstellungsmöglichkeiten, dass die Interdependenzen einzelner Einstellungen und die damit verbundenen Auswirkungen auf das System- verhalten für einen Laien nur schwer erkennbar sind. Aus diesem Grunde wird bei der Vornahme solcher Parametereinstellungen meist der Softwarehersteller oder ein speziell geschulter Berater hin- zugezogen.71
Um die Komplexität der zahlreichen Einstellungsmöglichkeiten zu reduzieren, bieten viele ERPAnbieter Checklisten und Werkzeuge an, welche beim Setzen und Dokumentieren solcher Einstellungen unterstützen sollen. Auf diese Weise wird versucht, mögliche Fehlerquellen zu reduzieren und den Customizingprozess effizienter zu gestalten. Ein Beispiel für solche Methoden ist ASAP (Accelerated SAP) der Firma SAP.72
Vorteil des Customizing ist die Flexibilität, ohne dabei die Releasesicherheit oder die Konsistenz des Systems zu gefährden. Da sich der Anwender mit den vorgenommenen Einstellungen im vorgedachten Lösungsraum des ERP-Systems bewegt, garantieren die meisten Anbieter dafür, dass die Anpassungen auch nach dem Einspielen eines Updates noch funktionieren.73
Ein weiterer Vorteil ist, dass die meisten Einstellungen auch im laufenden Betrieb an die eigenen Bedürfnisse angepasst werden können. Teilweise ist es sogar möglich, Zeitintervalle anzugeben, welche die Wirksamkeit der jeweiligen Einstellung zeitlich begrenzen.74
Die mittels Customizing-Einstellungen möglichen Anpassungen haben jedoch Grenzen. So sind bei- spielsweise keine umfangreichen Änderungen an der Datenstruktur und der gesamten Ablauflogik möglich. Hier bietet die in Abschnitt 2.3.4 vorgestellte Anpassungsprogrammierung deutlich mehr Flexibilität.75
Außerdem müssen die Hersteller von ERP-Systemen schon bei der Entwicklung die nötigen Voraus- setzungen für eine spätere Anpassung schaffen. D. h. sie müssen eventuelle Anpassungswünsche der Endanwender antizipieren sowie die erforderlichen Fallunterscheidungen und Einstellungsmöglichkei- ten mit in den Quellcode aufnehmen. Neben dem daraus resultierenden höheren Programmieraufwand macht eine große Zahl von Customizing-Einstellungen den Quellcode mitunter unübersichtlicher und schwerer wartbar.76
Ein weiterer Nachteil ist die schon angesprochene Komplexität der Parametereinstellungen. Je fle- xibler ein System gestaltet wird, desto mehr Einstellungen sind bei einem Einführungsprojekt auch vorzunehmen. Diese Tatsache hat erheblichen Einfluss auf Erfolg und Dauer der Einführungsphase.77
Im vorherigen Abschnitt wurde erläutert, dass mit zunehmender Zahl von Einstellungsmöglichkeiten die Komplexität und Dauer des Einführungsprozesses einer ERP-Software ansteigt. Gleichzeitig ist jedoch die Eignung eines ERP-Systems zur exakten Abbildung der Geschäftsprozesse der unterschied- lichen Branchen von großer Wichtigkeit. So gaben bei einer Studie unter 1200 deutschsprachigen Unternehmen 25 % der befragten Unternehmen an, keine ERP-Software einzusetzen. Als einer der Hauptgründe wurde die mangelnde Abdeckung von branchenspezifischen Funktionen und Prozessen genannt.78
Aus diesem Grund haben sich Branchen- bzw. Industrielösungen entwickelt. Eine Branchenlösung ist ein ERP-System, welches durch vordefinierte Parametereinstellungen bzw. entsprechender Erweiterungsprogrammierung an die Besonderheiten einer Branche angepasst ist. Auf diese Weise kann der Customizing-Aufwand reduziert und gleichzeitig eine adäquate Anpassung an die entsprechenden Branchen gewährleistet werden.79
Gerade die großen ERP-Anbieter haben für viele Branchen mittlerweile eigene Lösungen im Angebot. So existieren von dem ERP-System R/3 der Firma SAP u. a. spezielle Lösungen für Banken (IS-B), Krankenhäuser (IS-H), Mineralölindustrie (IS-OIL), Versicherungen (IS-IS), etc.80 Neben Branchenlösungen auf Basis von bestehenden ERP-Systemen existieren ebenfalls Produkte von Nischenanbietern, welche sich ausschließlich auf eine bestimmte Branche spezialisiert haben. Bei einem solchen Anbieter bietet sich der Vorteil, dass er genaustens mit den Besonderheiten und der Terminologie der jeweiligen Branche vertraut ist. Dies erleichtert vor allem die Kommunikation zwischen Endanwender und Hersteller des ERP-Systems.81
Eine weitere Art der Anpassung, welche noch mehr Flexibilität bietet als die bislang vorgestellten Möglichkeiten, ist die Anpassungsprogrammierung. So werden die marktführenden ERP-Systeme heute mit Entwicklungsumgebungen ausgeliefert. Diese erlauben es, die Programme gemäß der Anforderung des Anwenders zu verändern.82
Man unterscheidet bei einer Anpassung durch Programmierung nach Modifikation des Standardquellcode, der Verwendung von leeren Unterprogrammen bzw. User-Exits und der Programmierung von so genannten Add-Ons.83
Bei einer Modifikation des Standardquellcodes werden die originalen Programme eines ERP-Systems entsprechend den Anforderungen des Unternehmens überschrieben. Eine solche Modifikation wird auch als harte Codierung bezeichnet. Die Programmierung kann dabei vom Softwarehersteller, einem Dritten oder auch dem Unternehmen selbst vorgenommen werden.84
Diese Methode hat zwei wichtige Vorteile. Zum einen ist die Flexibilität nahezu grenzenlos, da das ursprüngliche System komplett verändert und somit genau an die Bedürfnisse des Unternehmens ange- passt werden kann.85 Der Softwarehersteller muss außerdem nicht voraussehen, in welchen Bereichen olche Konfiguration ist jedoch in der Praxis nur sehr selt
Abbildung 2.4: User-Exits und Modifikationen im Standardquellcode
seiner ERP-Software Anpassungsmöglichkeiten sinnvoll wären. Er muss lediglich den Quellcode und eine Dokumentation ausliefern, damit der Endanwender seine eigenen Erweiterungen programmieren kann.
Nachteilig ist allerdings, dass für derartige Anpassungen Programmier-Know-how und eine gute Kenntnis des jeweiligen ERP-Systems notwendig ist. Im Gegensatz zu den bereits vorgestellten CustomizingEinstellungen, sind die Änderungen außerdem nicht releasefähig. D. h. beim Einspielen eines Updates des Softwareherstellers kann es passieren, dass der geänderte Quellcode überschrieben wird. In einem solchen Fall müssen die eigenen Änderungen erneut vorgenommen werden.86
Moderne ERP-Systeme bieten zur Erleichterung dieses Vorgangs so genannte Modifikationsassistenten. Diese unterstützen den Anwender dabei, eigene Programmänderungen in neue Quellcode-Versionen des Softwareherstellers zu übertragen, in dem sie z. B. Hinweise darauf geben, an welchen Stellen geänderter Quellcode durch ein eingespieltes Update überschrieben worden ist. Die Übernahme der Anpassungen bleibt jedoch ein manueller Vorgang und kann bei umfangreichen Erweiterungen und häufigen Updates zu einem hohen Zeit- und Kostenfaktor werden.87
Als weiterer Nachteil ist die Verminderung von Gewährleistungsansprüchen zu nennen. Schließlich wird ein ERP-Hersteller keinen Support für solche Programme anbieten, in denen der Anwender den Quellcode geändert hat.88
Aufgrund der Nachteile einer Modifikation des Standardquellcodes haben ERP-Hersteller so genannte User-Exits eingeführt. Es handelt sich hierbei um spezielle Stellen im Quellcode, welche explizit für Erweiterungen vorgesehen sind. D. h. die ERP-Software ruft an bestimmten Stellen leere Unterprogramme auf. Diese können vom Endanwender mit eigenem Quellcode gefüllt werden.89 Zum besseren Verständnis soll anhand von Abbildung 2.4 nochmals der Unterschied zwischen UserExits und Modifikation des Standardquellcodes erläutert werden. Problemstellung ist die Erweiterung der Fakturierung eines Auftrages um einige eigene Berechnungen.
Bei einer Modifikation des Standardquellcodes müssten die entsprechenden Änderungen direkt in der Methode auftragFakturieren() der Klasse Fakturierung vorgenommen werden (einfach schraffierter Be- reich).
In diesem Beispiel wird aber jeweils zu Beginn und am Ende der Fakturierung eines Auftrages ein User-Exit angeboten (Methoden beginFaktura() und endFaktura()). Ist eine Ausführung der entsprechenden Erweiterungen am Beginn oder Ende der Faktura möglich, so kann die Anpassung durch Füllen einer dieser beiden Methoden gelöst werden (doppelt schraffierter Bereich). Der ursprüngliche Quellcode bleibt unangetastet.
Da der Hersteller eines ERP-Systems derartige User-Exits explizit für Erweiterungen vorgesehen hat, besteht nicht die Gefahr, dass die Änderungen bei Updates überschrieben werden könnten. User-Exits sind somit voll releasefähig.90
Allerdings ist die Flexibilität wesentlich geringer als bei einer Modifikation des Standardquellcodes, da solche leeren Unterprogramme nur an bestimmten vordefinierten Stellen im ERP-System vorhanden sind. D. h. der Hersteller muss schon bei der Entwicklung seiner Software vorausgedacht haben und die entsprechenden Erweiterungsmöglichkeiten vorgesehen haben. Außerdem kann nur Funktionalität hinzugefügt, jedoch keine bestehende Funktionalität entfernt oder gar geändert werden. Eine andere Möglichkeit der Erweiterung durch Programmierung besteht durch so genannte Ad-Ons. Ad-Ons sind Zusatzprogramme, die nicht den eigentlichen Kern des ERP-System verändern.91 Sie werden vielmehr unabhängig von den Programmen des ERP-Systems programmiert und dann über Schnittstellen mit diesem integriert. Auf diesem Wege können z. B. auch Altsysteme, deren Funktio- nalität noch weiterhin benötigt wird, mit in das ERP-System eingebunden werden. Als Schnittstelle kann z. B. eine so genannte API (Application Programmers Interface) dienen, welche es ermöglicht von außerhalb bestimmte Funktionalitäten des ERP-Systems aufzurufen.92
Vorteil ist neben der schon genannten Integrationsmöglichkeit von Altsystemen, dass die so erzeugten Erweiterungen nicht durch Updates von Seiten des Softwareherstellers überschrieben werden können, da es sich ja um komplett eigenständige Programme handelt. Allerdings werden für die Einbindung der Add-Ons in das ERP-System Schnittstellen benötigt, die entweder vom Softwarehersteller zur Verfügung gestellt oder vom Unternehmen selbst programmiert und gewartet werden müssen. Eigen- entwickelte Schnittstellen müssen dann nach Updates ebenfalls ständig auf ihre Funktionstüchtigkeit überprüft werden.93
In den bisherigen Abschnitten wurden ERP-Systeme eher unter allgemeinen Gesichtspunkten bzw. aus der Sicht von Anwenderunternehmen beschrieben. Mit diesem Abschnitt soll nun ein Perspektiven- wechsel vollzogen werden und eine Betrachtung von Seiten der ERP-Hersteller erfolgen. Hierzu wird im Folgenden vor allem auf Vorgehensweisen und Probleme bei der Entwicklung von ERP-Software eingegangen.
In der allgemeinen Literatur werden sowohl für die strukturierte94 als auch die objektorientierte Soft- wareentwicklung9596 eine Reihe von Vorgehensmodellen diskutiert. Alle dieser Vorgehensmodelle las- sen sich grob in Phasen der Analyse, des Entwurfs, der Realisierung und des Betriebs unterteilen. Die Analyse dient dazu den Anwendungsbereich zu beschreiben, welcher von der Software später un- terstützt werden soll. Hierzu werden zunächst die bisherigen Strukturen und Abläufe sowie ggf. die bislang verwendete Software betrachtet. Dabei wird versucht Schwachstellen zu identifizieren. Basie- rend darauf werden nun die Anforderungen an die zu entwickelnde Software definiert.
Während der Analyse wird also das Problem beschrieben, welches es mit der neuen Software zu lösen gilt. Im Laufe des Entwurfs wird nun versucht, eine Lösung für dieses Problem zu finden. Hierbei wer- den konkrete Entwürfe der zu programmierenden Software erstellt, sowie die erforderliche Hardware festgelegt.
Die Realisierung setzt nun die im Entwurf konzipierte Lösung in die Realität um. D. h. die Softwa- reentwürfe werden in Quellcode umgesetzt und die erforderliche Hardware wird beschafft. Beides wird nach erfolgreichen Tests beim Anwender installiert und entsprechend eingerichtet. Evtl. muss auch eine schrittweise Umstellung von der abzulösenden Software auf die neue Software vollzogen werden. Die Aufgaben enden in der Regel nicht mit der Einführung der Software beim Anwender. So muss die Software weiterhin gewartet werden, indem beispielsweise auftretende Fehler korrigiert werden.
Die hier angegebenen und auszugsweise erläuterten klassischen Vorgehensmodelle lassen sich prinzipiell auf die Entwicklung von ERP-Software übertragen. In der Praxis werden allerdings oft Varianten dieser Vorgehensmodelle verwendet. D. h. man orientiert sich an den hier beschriebenen Aufgaben von Analyse, Entwurf, Realisierung und Betrieb, lässt sich jedoch Freiheiten bezüglich der Reihenfolge und Ausführlichkeit der einzelnen Phasen. So werden bestimmte Aufgaben teilweise auf frühere Zeitpunkte verlagert oder es werden bestimmte Schritte übersprungen.97
Die Abweichungen von den klassischen Vorgehensmodellen lassen sich auf unterschiedliche Weise erklären. Eine Begründung ist das von Appelrath und Ritter beschriebenen Mehr-Kreislaufsystem, welches im Laufe der Zeit entstanden ist.98
Gemäß Appelrath und Ritter vollzieht sich der Entwicklungsprozess standardisierter Anwendungssoft- ware nämlich in unternehmensübergreifenden Kreisläufen. Einer dieser Entwicklungskreisläufe voll- zieht sich beim Hersteller des ERP-Systems. Die Software wird hier nicht in einem einzigen Ent- wicklungsprojekt erstellt sondern entsteht in einem evolutionären Entwicklungsprozess.99 D. h. die Standardsoftware wird sukzessive weiterentwickelt. Dabei spielen vor allem die Erfahrungen und An- forderungen aus Einführungsprojekten bei unterschiedlichen Anwenderunternehmen eine Rolle.
Diese Einführungsprojekte in den einzelnen anwendenden Unternehmen stellen die weiteren Ent- wicklungskreisläufe dar. Ein solches Unternehmen selbst plant die Einführung eines ERP-Systems. Auch hier werden Schwachstellen analysiert und Anforderungen definiert. Ggf. entstehen nach der Einführung der Software neue Ziele und Anforderungen, weil während der Verwendung des neuen Systems Einsatzmöglichkeiten entdeckt werden, an welche zuvor noch nicht gedacht wurde.
Die einzelnen Kreisläufe hängen eng zusammen, weil eine Standardsoftware nur dann Erfolg haben kann, wenn sie den Anforderungen der Anwender entspricht. Deshalb müssen die Hersteller von ERP- Software bestrebt sein, die Anforderungen der potentiellen Anwender zu erkennen und in ihre Software einzubeziehen. Außerdem müssen beim Anwender auftretende Fehler vom ERP-Hersteller korrigiert und durch Einspielung von Updates möglichst schnell beim Anwender behoben werden.100 Das Mehr-Kreislaufsystem bietet für Hersteller und Anwender gleichermaßen Vorteile. Der Hersteller kann die Funktionalität seiner Software mit Hilfe des Feed-back der Anwender ständig verbessern und weiter ausbauen. Die Anwender profitieren vom zunehmenden Funktionsumfang der Software und evtl. sogar von Ideen, welche aus anderen Anwenderunternehmen stammen.101 Nachteilig für Anwender und Softwarehersteller ist allerdings, dass die Software immer komplexer wird. Die Hersteller müssen während der Entwicklung an vielen Stellen flexible Parameter und Wahlmöglich- keiten vorsehen. Dies bedeutet höheren Entwicklungsaufwand und macht die Software schwerer wart- bar.102 Die Anwender benötigen evtl. nur einen Teil der gesamten Funktionalität, müssen jedoch evtl. eine große Zahl von Einstellungen vornehmen, um die restlichen Funktionen zu deaktivieren bzw. zu umgehen (s. Abschnitt 2.3.2).103
Ein weiteres Problem, welches durch die Aufteilung in Hersteller- und Anwenderunternehmen verschärft wird, ist die Kommunikation. So gibt es zwischen den beiden Unternehmen oft Verständigungsschwierigkeiten, weil die Anwender ihre anwendungsbezogenen Fachausdrücke benutzen, während die Hersteller eher technische Fachausdrücke verwenden.104 Böhm und Fuchs nennen dies auch das Transformationsproblem: Die Anforderungen des Anwenders werden vom Hersteller aufgrund des mangelnden Verständnis falsch in Softwareentwürfe transformiert.105
ERP-Hersteller sind deshalb bestrebt erfahrene Entwickler einzustellen, welche neben umfassendem technischem auch ein gutes betriebswirtschaftliches Wissen besitzen.106
Oft wird auch geschildert, dass im Laufe der Entwicklung zwischen Entwicklern und Anwender zu wenig kommuniziert wird. Auch dieses Kommunikationsproblem wird durch die Aufteilung des Entwicklungsprozesses auf mehrere Unternehmen noch verschlimmert.107
Die konkurrierenden fachlichen und softwaretechnischen Anforderungen stellen ebenfalls ein Problem dar. Während die Anwender vor allem wünschen, dass ihre fachlichen Anforderungen mit möglichst geringem zeitlichen und finanziellen Aufwand realisiert werden, sind die Hersteller auch bestrebt nicht- funktionale Anforderungen wie Wartbarkeit und Wiederverwendung zu berücksichtigen. Ein weiteres Problem hängt zwar nicht direkt mit dem Mehr-Kreislaufsystem zusammen, erklärt je- doch, warum die Hersteller gerade bei der Fehlerbehebung stark auf die anwendenden Unternehmen angewiesen sind. So sind Programmtests von ERP-Systemen meist sehr komplex. Da sie unter ei- ner Vielzahl verschiedener Parametereinstellungen und Datenkonstellationen vorgenommen werden müssen, ist eine komplette Fehlerfreiheit und wirtschaftlichen Gesichtspunkten nicht zu gewährlei- sten.108
Die einzelnen Komponenten einer ERP-Software lassen sich nach Appelrath und Ritter in funktionsbezogene, funktionsübergreifende und Systemkomponenten unterteilen.109
Funktionsbezogene Komponenten unterstützen direkt einzelne betriebswirtschaftliche Aufgaben eines Unternehmens. Beispiele für solche Komponenten sind Anwendungen zur Auftragsverwaltung oder der Buchung von Wareneingängen.
Funktionsübergreifende Komponenten dienen fachlichen Anforderungen, welche in allen Funktions- bereichen benötigt werden. Bespiele hierfür sind Anwendungen für Dokumenten- und Workflow- Management.
Systemkomponenten bilden die technische Grundlage zur Realisierung der funktionsbezogenen und funktionsübergreifenden Komponenten, erfüllen jedoch nicht direkt fachliche Aufgaben. Beispiele hierfür sind Komponenten zur Steuerung des Zugriffs auf die Datenbank oder zur Regelung der Feh- lerbehandlung.110
Entsprechend dieser unterschiedlichen Typen von erforderlichen Komponenten lässt sich auch die Entwicklung in zwei unterschiedliche Aufgabenbereiche mit unterschiedlichen Anforderungen an die Qualifikation der Entwickler unterteilen.
Die Systementwicklung legt mit den Systemkomponenten die technische Grundlage für die spätere Realisierung der fachlichen Funktionen. Da die entwickelten Komponenten vorwiegend technischer Natur sind, werden den Entwicklern in diesem Bereich vornehmlich technische Qualifikationen abver- langt.
Mit Hilfe der so entwickelten Systemkomponenten können dann im Rahmen der Anwendungsentwick- lung die eigentlichen fachlichen Anwendungen erstellt werden. Neben Kenntnissen über die geeigne- te Verwendung der Systemkomponenten ist hier natürlich das entsprechende betriebswirtschaftliche Wissen erforderlich. Wichtig ist auch entsprechende Erfahrung bei der Gestaltung von Benutzerober- flächen.
Bei Unternehmensanwendungen findet die System- und Anwendungsentwicklung heute häufig schon in unterschiedlichen Unternehmen statt. So werden die Anwendungen basierend auf so genannten Frameworks entwickelt, welche entweder frei zugänglich sind oder eingekauft werden. Diese Frameworks beinhalten bereits eine Vielzahl von Systemkomponenten für Datenzugriffe, Code-Generierung, etc. Diese Systemkomponenten können dann entweder direkt zur Anwendungsentwicklung genutzt oder zunächst noch weiterentwickelt werden.111 Ein Beispiel für einen solchen Framework ist die Java 2 Platform, Enterprise Edition (J2EE).112
Gerade bei größeren Anbietern von ERP-Systemen entsteht eine komplexe Hierarchie von abhängigen Softwaresystemen. Neben der ursprünglichen ERP-Software existieren meist mehrere darauf basierende Branchen- und Kundenlösungen. Um funktionale Erweiterungen nicht in jedem System wiederholt durchführen zu müssen, sind Mechanismen erforderlich, welche den Austausch von Erweiterungen zwischen den einzelnen Systemen ermöglichen.
Bei einem solchen Aktualisierungsprozess handelt es sich jedoch um ein komplexes Vorgehen, welcheszahlreiche Konflikte verursachen kann (s. Ausführungen zu Releasesicherheit in Abschnitt 2.3). Es ist somit eine strikte Organisation des Transportes von Software-Updates erforderlich, um unnötigen Konflikte zu vermeiden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5: Mögliche Softwaretransportwege Quelle: Will, L. (1998), S. 105
Eine bewährte Lösung zur Organisation des Softwaretransportes ist eine Unterteilung in Systeme unterschiedlicher Klassen. Man unterscheidet hierbei nach Entwicklungs-, Qualitätssicherungs- und Produktivsystemen.113
Nur in einem Entwicklungssystem können Änderungen am Quellcode des ERP-Systems vorgenommen werden. Üblicherweise finden in diesen Systemen auch die restlichen Anpassungen wie das Customi- zing statt.114
Einem Entwicklungssystem sollte immer ein Qualitätssicherungssystem nachgelagert werden. Ein sol- ches System dient dazu die vorgenommenen Anpassungen zu testen. Ein separates System zum Testen ist deshalb sinnvoll, da ein ausgiebiger Testbetrieb evtl. weiterführende Entwicklungen stören würde und ein direktes Einspielen in ein Produktivsystem aufgrund der möglichen Fehler zu risikoreich wäre.115
Das Produktivsystem ist das System, mit welchen die Anwender arbeiten, d. h. dieses System dient ausschließlich dazu die Anwender bei der Abwicklung der Geschäftsprozess zu unterstützen. Entwicklungen und Tests sind in diesem System nicht möglich. Es bildet somit immer den Endpunkt eines Softwaretransportes.116
In den vorangegangenen Ausführungen wurde bereits mehrfach angedeutet, dass eine Übertragungvon Software-Updates nur zwischen bestimmten Systemen möglich ist. Abbildung 2.5 zeigt dies nochmals. Demzufolge sollte der Transport von Updates aus einem Entwicklungssystem über ein Qualitätssicherungssystem in ein Produktivsystem erfolgen.117
Ein solcher dreistufiger Aufbau könnte bei einem ERP-Hersteller, welcher seine Kunden mit exakt derselben ERP-Software ausstattet, Anwendung finden. Von dem Qualitätssicherungssystem würden in diesem Fall die einzelnen Produktivsysteme der Kunden versorgt.
Komplizierter sieht es aus, wenn bei einem Hersteller gemäß den Ausführungen zu Beginn dieses Abschnittes noch Branchenlösungen und individuelle Kundenentwicklungen vorgenommen werden sollen. In diesem Fall müssen noch weitere Ebenen in die Systemlandschaft eingeführt werden. Abbildung 2.6 zeigt eine entsprechende Systemlandschaft.118
Eine derartig komplexe Systemlandschaft resultiert in einem entsprechend hohen Administrationsaufwand. Auch wenn es möglich ist, mehrere der Systeme auf einem Rechner zu betreiben, so müssen Aktualisierungen immer durch sämtliche Ebenen geschleust werden um ins Produktivsystem zu gelangen. Ein solcher Aufbau ist jedoch notwendig, um trotz branchenspezifischer bzw. kundenindividueller Entwicklungen die Möglichkeit des Software-Updates zu bewahren.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.6: Systemlandschaft eines großen ERP-Herstellers Eigene Darstellung in Anlehnung an Will, L. (1998), S. 106
Kapitel 3
Erfahrene Softwareentwickler suchen nicht für jedes Problem eine komplett neue Lösung. Vielmehr versuchen sie sich zu erinnern, ob sie ein ähnliches Problem bereits in der Vergangenheit gelöst haben. Ist dies der Fall, so probieren sie die damalige Lösung auf das aktuelle Problem zu übertragen.1 Dieses Denken in Problem-Lösungs-Paaren ist ein typisch menschliches Verhalten im Umgang mit Problemen. Eine derartige Lösungsfindung findet deshalb auch in unterschiedlichen Bereichen, wie z.
B. der Architektur, den Wirtschaftswissenschaften und der Softwaretechnik, Anwendung. Die Idee von Entwurfsmustern trägt dieser Tatsache Rechnung, indem jedes Entwurfsmuster zunächst ein Problem und dann eine Lösung für dieses Problem beschreibt.2
Gemäß Fowler gibt es keine allgemein akzeptierte Definition des Begriffes Entwurfsmuster (englisch: Design Pattern oder Pattern).3 Dennoch sind die in der Literatur anzutreffenden Definitionen von Entwurfsmustern weitestgehend Deckungsgleich.456
Alle oben angegebenen Definitionen umschreiben ein Entwurfsmuster als Beschreibung einer möglichen Lösung eines Problems, welches in einem bestimmten Kontext auftritt. Einige der Definitionen beinhalten zusätzlich die Aussage, dass es sich bei den zu lösenden Problemen um häufig wiederkehrende Probleme handelt.7 Andere Definitionen betonen, dass es sich um eine allgemeingültige und erprobte Lösung des Problems handelt.8
Fasst man die in allen oder vielen Definitionen genannten Eigenschaften zusammen, so erhält man die folgende Definition: Ein Entwurfsmuster beschreibt eine allgemeingültige und erprobte Lösung für ein Entwurfsproblem, welches in einem bestimmten Kontext häufig wiederkehrt. Wie bereits angedeutet ist eine Verwendung von Entwurfsmustern prinzipiell in mehreren Bereichen möglich. Diese Arbeit bezieht sich jedoch auf die Softwareentwicklung. Wenn im Folgenden also von Entwurfsmustern die Rede ist, so sind Entwurfsmuster aus dem Bereich der Softwareentwicklung ge- meint.
Das wohl bekannteste Entwurfsmuster aus dem Bereich der Softwareentwicklung ist das Model-View Controller-Muster (s. Abschnitt 4.3.3). Es löst ein Problem aus dem Bereich interaktiver Softwa- resysteme. Hier müssen die gleichen Funktionen oft über unterschiedliche und hoch konfigurierbare Benutzeroberflächen dargestellt werden. Die Lösung des Model-View-Controller-Musters ist, ein sol- ches System in voneinander unabhängige Komponenten der Benutzeroberfläche (View), Datenhaltung (Model) und Eingabekontrolle bzw. Ablauflogik (Controller) zu gliedern. Durch die Unabhängigkeit kann die Benutzeroberfläche einfach ausgetauscht werden ohne die Kernfunktionalität zu beeinflus- sen.9
Bei den durch Entwurfsmuster beschriebenen Lösungen handelt es sich keinesfalls um neue Ideen. Deshalb sind die von Entwurfsmustern beschriebenen Lösungswege erfahrenen Softwareentwicklern vielfach bereits bekannt.10
Es entspricht aber auch nicht dem hinter Entwurfsmustern stehenden Gedanken komplett neue Ideen zu entwickeln. Vielmehr stehen die Dokumentation und der Austausch von Erfahrungen im Mittel- punkt. Dieser Bereich bereitet Softwareentwicklern nach wie vor Probleme. Entwurfsmuster sollen hier Abhilfe schaffen, indem sie einen Ansatz zur Verfügung stellen, um Erfahrungen beim Softwareentwurf festzuhalten.11
Zur Dokumentation der Erfahrungen werden existierende Softwarelösungen untersucht, um in diesen elegante Lösungsansätze zu finden. Aufgrund dieser Vorgehensweise wird oft auch davon gesprochen, dass neue Entwurfsmuster gesucht und nicht erfunden werden (s. Abschnitt 3.4.2).12 Gesucht wird hierbei vor allem nach eleganten Entwurfsentscheidungen, welche nicht offensichtlich sind. Dies sind beispielsweise Lösungen, die bei der ersten Betrachtung den Anschein machen unnötigen zusätzlichen Aufwand zu verursachen. Bei genauerer Betrachtung wird der Zusatzaufwand jedoch durch eine flexible und wieder verwendbare Lösung belohnt.13
Ein wichtiger Grundsatz von Entwurfsmustern ist außerdem, dass sich die beschriebenen Lösungen in der Praxis bewährt haben müssen. D. h. die dargestellten Lösungen wurden bereits in mehreren verschiedenen Softwareprojekten erfolgreich eingesetzt.14
Entwurfsmuster sind somit ein Form der Dokumentation praktischer Erfahrungen im Bereich der Softwareentwicklung. Auf diese Weise soll das Entwurfswissen Einzelner der Allgemeinheit zur Verfügung gestellt werden.15
Auch wenn die von Enwurfsmustern beschriebenen Ideen nicht neu sind, so ist zumindest neu, dass die dargestellten Lösungswege durch Entwurfsmuster mit einem Namen versehen werden. Durch diese Benennung wird das Entwurfsvokabular erweitert. Somit können komplette Lösungswege in wenigen Worten beschrieben werden.16
Um die durch Entwurfsmuster beschriebenen Lösungen für eigene Entwicklungen verwenden zu können ist es wichtig zu verstehen, dass es sich dabei lediglich um Ausgangspunkte handelt. Ein Entwurfsmuster stellt also keine fertige Lösung dar, welche direkt in Quellcode überführt werden kann. Es beschreibt ein Schema für die Lösung ähnlicher Probleme.17
Dieses allgemeingehaltene Lösungsschema muss vor der Verwendung in einem konkreten Software- projekt zunächst noch konkretisiert werden. So muss es beispielsweise an die projektspezifischen Ge- gebenheiten angepasst werden. Erst nach einer solchen Weiterentwicklung kann das Entwurfsmuster verwendet werden. Aufgrund dieser Anpassungen kann die Lösung eines Problems in verschiedenen Software-Projekten komplett unterschiedlich sein, obwohl sie auf demselben Entwurfsmuster basiert.18 Genau in diesem Punkt lassen sich Entwurfsmustern auch von Frameworks abgrenzen. Im Gegensatz zu Entwurfsmustern lassen sich Frameworks direkt in Quellcode überführen. Ein Framework lässt sich somit ausführen und direkt in eigenen Projekten einsetzen. Entwurfsmuster hingegen können nur studiert werden. Um die Lösungsansätze zum Schreiben von eigener Software zu verwenden, müssen sie jedes Mal neu implementiert werden.19
Daraus lässt sich auch begründen, warum sich auf Entwurfsmustern basierende CASE-Tools (Computer Aided Software Engineering) nicht durchgesetzt haben. Die Angabe des Namens von einem Entwurfsmuster reicht wie oben beschrieben einfach nicht aus um für ein Softwareprojekt geeigneten Quellcode daraus zu generieren.20
Demzufolge sind Entwurfsmuster eher auf der gedanklichen Ebene des Softwareentwurfes anzusiedeln. Sie liefern Ideen bzw. Denkanstöße für die Konstruktion von Softwareentwürfen. Buschmann u. a.
stellen die Gesamtheit aller Entwurfsmuster deshalb treffend als mit deren Hilfe man Softwaresysteme entwickeln kann.“21
”einementaleWerkzeugkistedar,
In den vorangegangenen Abschnitten wurde erläutert, dass Entwurfmuster zur Konstruktion von Soft- wareentwürfen verwendet werden können. Dabei sind sie unabhängig von der Verwendung herkömm- licher Entwicklungsmethoden. Die herkömmlichen Methoden werden durch die Verwendung von Ent- wurfsmustern aber keinesfalls überflüssig. Die problemorientierten Entwurfsmuster schließen nur eine Lücke, welche von den problemunabhängigen Methoden bislang noch nicht abgedeckt wurde.22 Das Ausmaß der Verwendung von Entwurfsmustern kann vollkommen frei gewählt werden. Es ist unwichtig, ob in einem Softwareprojekt möglichst viele oder nur ein Problem mit Hilfe von einem Entwurfsmuster gelöst werden. Dies ist möglich, weil alle Entwurfsmuster grundsätzlich von einander unabhängig sind.
Trotz dieser prinzipiellen Unabhängigkeit werden einige Entwurfsmuster häufig gemeinsam verwendet. Ein Grund hierfür ist, dass Entwurfsmuster zwar gut dafür geeignet sind ein Problem elegant zu lösen, dafür aber teilweise ein anderes Problem verursachen. Zur Lösung dieses Problems können dann evtl. weitere Entwurfsmuster angewandt werden.23
[...]
1 Vgl. Kurbel, K. (2003), S. 322
2 Vgl. Mertens, P. (1997), S. 10f.
3 Vgl. Fowler, M., u. a. (2003), S. 24
1 Vgl. Ritter, B. (2000), S. 15 ; Mauterer, H. (2002), S. 7f.
2 Vgl. Mauterer, H. (2002), S. 8
3 Vgl. Schwarze, J. (2000), S. 265
4 Vgl. Kurbel, K. (2003), S. 322
5 Vgl. Kurbel, K. (2003), S. 322
6 Vgl. Gümbel, H. (2004), S. 4 ; Harrington, A. (2001)
7 Vgl. Gartner Inc. (2004), S. 143
8 Vgl. Kirchmer, M. (1999), S. 13-17
9 Vgl. Hansen, H. R. (1998), S. 170-171 ; Kirchmer, M. (1999), S. 14
10 Vgl. Mauterer, H. (2002), S. 9
11 Vgl. Mertens, P., u. a. (2000), S. 145-147 ; Barbitsch, C. E. (1996), S. 13-17
12 Vgl. Hansen, H. R. (1998) S. 172-174 ; Barthel, T., u. a. (1996), S. 28-29 ; Kirchmer, M. (1999), S. 14-16
13 Vgl. Raue, H. (1996), S. 3
14 Vgl. Kirchmer, M. (1999), S. 18
15 Vgl. Kirchmer, M. (1999), S. 16
16 Vgl. Fowler, M., u. a. (2003), S. 15-17
17 Vgl. Enzler, S. (2003), S. 2-6
18 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 5f.
19 Vgl. Mertens, P. (1997), S. 11-13
20 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 6
21 Vgl. Mertens, P. (1997), S. 11f.
22 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 6
23 Vgl. Mertens, P. (1997), S. 13
24 Vgl. Mertens, P. (1997), S. 13
25 Vgl. Mertens, P. (1997), S. 4
26 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 6
27 Vgl. Mertens, P. (1997), S. 12f.
28 Vgl. Kurbel, K. (2003), S. 323 ; Mauterer, H. (2002), S. 10
29 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 5 ; Barthel, T., u. a. (1996), S. 23-26
30 Vgl. Mertens, P. (1997), S. 9f.
31 Vgl. Barbitsch, C. E. (1996), S. 11
32 Vgl. Barthel, T., u. a. (1996), S. 20-23
33 Vgl. Mertens, P. (1997), S. 10 ; Barthel, T., u. a. (1996), S. 20-23
34 Vgl. Mertens, P. (1997), S. 10
35 Vgl. Mertens, P. (1997), S. 10f.
36 Vgl. Hufgard, A. (1994a), S. 4
37 Vgl. Mauterer, H. (2002), S. 7
38 Vgl. Barbitsch, C. E. (1996), S. 9-13 ; Mauterer, H. (2002), S. 7
39 Vgl. Gartner Inc. (2004), S. 246
40 Vgl. Kurbel, K. (2003), S. 322f.
41 Vgl. Gartner Inc. (2004), S. 143 ; Harrington, A. (2001) 8
42 Vgl. Alpar, P., u. a. (1998), S. 155 ; Schwarze, J. (2000), S. 296-303 ; Hansen, H. R. (1998), S. 74
43 Vgl. Alpar, P., u. a. (1998), S. 150f. ; Kurbel, K. (2003), S. 15-18
44 Vgl. Kurbel, K. (2003), S. 36
45 Vgl. Mauterer, H. (2002), S. 8
46 Vgl. Hansen, H. R. (1998), S. 64
47 Vgl. Buck-Emden, R., Galimow, J. (1996), S. 28f. ; Herth, B., u. a. (1996), S. 61-95
48 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 16 ; Hansen, H. R. (1998), S. 65
49 Vgl. Will, L. (1998), S. 20 ; Appelrath, H.-J., Ritter, J. (2000), S. 16f.
50 Vgl. Kurbel, K. (2003), S. 266
51 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 17
52 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 16f.
53 Vgl. Mauterer, H. (2002), S. 11
54 Vgl. Thome, R. (1998), S. 52f.
55 Vgl. Kirchmer, M. (1999), S. 18-20
56 Vgl. Rebstock, M., Hildebrand, K. (Hrsg.) (1998), S. 81-92
57 Vgl. Mauterer, H. (2002), S. 12
58 Vgl. Mauterer, H. (2002), S. 12
59 Vgl. Mauterer, H. (2002), S. 12
60 Vgl. Mauterer, H. (2002), S. 31
61 Vgl. Shalloway, A., Trott, J. R. (2003), S.25f.
62 Vgl. Fowler, M., u. a. (2003), S. 17f.
63 Vgl. Wolf, I. u. Wolf, R. (2003) ; Hufgard, A. (1994b), S. 2
64 Vgl. Hufgard, A. (1994b), S. 3
65 Vgl. Hufgard, A. (1994b), S. 3
66 Vgl. Vogelsang, E. (1998), S. 49
67 Vgl. Hufgard, A. (1994b), S. 1
68 Vgl. Hansen, H. R. (1998), S. 189
69 Vgl. Schwarze, J. (2000), S. 196f.
70 Vgl. Thome, R. (1998), S. 48f. ; Appelrath, H.-J., Ritter, J. (2000), S. 64-66
71 Vgl. Mauterer, H. (2002), S. 32 ; Hansen, H. R. (1998), S. 189
72 Vgl. Glauch, T. (2002); Glohr, C. (2001), S. 1-5
73 Vgl. Grigoleit, U., Stark, H. (1998), S. 423f. ; Vogelsang, E. (1998), S. 49
74 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 64f.
75 Vgl. Grigoleit, U., Stark, H. (1998), S. 423f.
76 Vgl. Thome, R. (1998), S. 48f. ; Buschmann, F., u. a. (1998), S. 387
77 Vgl. Mauterer, H. (2002), S. 33
78 Vgl. Emrich, C. (1998), S.22
79 Vgl. Grigoleit, U., Stark, H. (1998), S. 432-436
80 Vgl. Enzler, S. (2003), S. 2 ; Grigoleit, U., Stark, H. (1998), S. 37f.
81 Vgl. Thome, R. (1998), S. 48f.
82 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 67 ; Wettklo, M., Bremicker, H. (2003)
83 Vgl. Mauterer, H. (2002), S. 31 ; Appelrath, H.-J., Ritter, J. (2000), S. 67
84 Vgl. Mauterer, H. (2002), S. 31 ; Hansen, H. R. (1998), S. 190
85 Vgl. Mauterer, H. (2002), S. 32
86 Vgl. Wettklo, M., Bremicker, H. (2003) ; Mauterer, H. (2002), S. 32
87 Vgl. o. A. (2002), S. 12
88 Vgl. Grigoleit, U., Stark, H. (1998), S. 423
89 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 67 ; Kirchmer, M. (1999), S. 22f.
90 Vgl. Mauterer, H. (2002), S. 33
91 Vgl. o. A. (2002), S. 11 ; Mauterer, H. (2002), S. 33
92 Vgl. Mauterer, H. (2002), S. 33
93 Vgl. Mauterer, H. (2002), S. 33
94 Vgl. Mertens, P., u. a. (2000), S. 147-155 ; Böhm, R., Fuchs, E. (2002), S. 187-230
95 Vgl. Böhm, R., Fuchs, E. (2002), S. 281-323 ; Fowler, M., Scott, K. (2000), S. 11-33
96 Vgl. Seemann, J., von Gudenberg, J. W. (2000), S. 130-155 ; Erler, T. (2001), S. 29-31
97 Vgl. Mertens, P., u. a. (2000), S. 154f.
98 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 58-60
99 Vgl. Hansen, H. R. (1998), S. 140-142
100 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 59
101 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 59
102 Vgl. Mertens, P. (1997), S. 10 ; Raue, H. (1996), S. 3
103 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 59
104 Vgl. Mertens, P., u. a. (2000), S. 149
105 Vgl. Böhm, R., Fuchs, E. (2002), S. 170f.
106 Vgl. Mertens, P. (1997), S. 10f.
107 Vgl. Mertens, P. u. a. (2000), S. 154f.
108 Vgl. Mertens, P. (1997), S. 10
109 Vgl. Appelrath, H.-J., Ritter, J. (2000), S. 6f.
110 Vgl. Mertens, P., u. a. (2000), S. 151
111 Vgl. Gamma, E., u. a. (2001), S. 37-39 ; Fowler, M., u. a. (2003), S. 496
112 Vgl. Sun Microsystems, Inc (2004)
113 Vgl. Will, L. (1998), S. 104-106
114 Vgl. Mißbach, M., u. a. (2003), S. 145
115 Vgl. Will, L. (1998), S. 105
116 Vgl. Mißbach, M., u. a. (2003), S. 146f.
117 Vgl. Will, L. (1998), S. 105
118 Vgl. Will, L. (1998), S. 106
1 Vgl. Gamma, E., u. a. (2001), S. 1 ; Buschmann, F., u. a. (1998), S. 1
2 Vgl. Yacoub, S. M., Ammar, H. H. (2003), S. 10 ; Buschmann, F., u. a. (1998), S. 1f.
3 Vgl. Fowler, M., u. a. (2003), S. 24
4 Vgl. Gamma, E., u. a. (2001), S. 4 ; Buschmann, F., u. a. (1998), S. 5
5 Vgl. Shalloway, A., Trott, J. R. (2003), S. 86 ; Böhm, R., Fuchs, E. (2002), S. 315
6 Vgl. Yacoub, S. M., Ammar, H. H. (2003), S. 10
7 Vgl. Buschmann, F., u. a. (1998), S. 5 ; Yacoub, S. M., Ammar, H. H. (2003), S. 10
8 Vgl. Yacoub, S. M., Ammar, H. H. (2003), S. 10 ; Böhm, R., Fuchs, E. (2002), S. 315
9 Vgl. Fowler, M., u. a. (2003), S. 367-369
10 Vgl. Fowler, M., u. a. (2003), S. 24f.
11 Vgl. Gamma, E., u. a. (2001), S. 2
12 Vgl. Yacoub, S. M., Ammar, H. H. (2003), S. 11 ; Fowler, M., u. a. (2003), S. 24
13 Vgl. Gamma, E., u. a. (2001), S. XIII
14 Vgl. Gamma, E., u. a. (2001), S. 2
15 Vgl. Buschmann, F., u. a. (1998), S. 5f.
16 Vgl. Gamma, E., u. a. (2001), S. 2 ; Shalloway, A., Trott, J. R. (2003), S. 86
17 Vgl. Buschmann, F., u. a. (1998), S. 7
18 Vgl. Fowler, M., u. a. (2003), S. 24
19 Vgl. Gamma, E., u. a. (2001), S. 37-39
20 Vgl. Fowler, M., u. a. (2003), S. 24
21 Buschmann, F., u. a. (1998), S. 24
22 Vgl. Buschmann, F., u. a. (1998), S. 22-23
23 Vgl. Fowler, M., u. a. (2003), S. 24f.
