Praktische Evaluierung der aspektorientierten Programmierung zur Stärkung der Wandlungsfähigkeit eines ERP-Systems

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Struktur

2 Enterprise Resource Planning
2.1 Begri sklärung und Aufgabende nition
2.2 Entstehungsgeschichte
2.3 Enterprise Systeme
2.4 Aufbau eines ERP-Systems
2.5 Open-Source in unternehmensweiten Anwendungen . . .

3 Wandlungsfähigkeit
3.1 Begri sklärung
3.2 Wandlungsfähige ERP-Systeme
3.2.1 Kriterien der Wandlungsfähigkeit
3.2.2 Wandlungsfähige Architekturmodelle
3.2.3 Ermittlung der Wandlungsfähigkeit
3.2.4 Auswertung der Wandlungsfähigkeit
3.2.5 Bedeutung der Wandlungsfähigkeit für ERP-Systeme

4 Compiere
4.1 Funktionalitäten
4.1.1 Quote-to-Cash
4.1.2 Requisition-to-Pay
4.1.3 Customer-Relations-Management (CRM)
4.1.4 Partner-Relations-Management
4.1.5 Supply-Chain-Management (SCM)
4.1.6 Performanz Analyse
4.1.7 Web-Store
4.1.8 Work ows
4.1.9 Zusammenfassung
4.2 Aufbau und Struktur
4.2.1 Technische Anforderungen
4.2.2 Applikationsstruktur
4.2.3 Datenbankstruktur
4.2.4 Datenbankzugri
4.2.5 Gra sche Abbildung der Datenbank

5 Aspektorientierte Softwareentwicklung
5.1 Begri sklärung und allgemeine Übersicht
5.1.1 Problematik
5.1.2 Elemente der Aspektorientierung
5.1.3 Verwebung
5.1.4 Die Vor- und Nachteile der Aspektorientierung .
5.1.5 AOP-Implementierungen für Java
5.2 JBoss AOP
5.2.1 Das Pointcut-Modell
5.2.2 Verwebung und Deployment von Aspektklassen
5.3 Object Teams
5.3.1 Rollenbasierte Programmierung
5.3.2 Kollaborationen
5.3.3 Teams
5.3.4 Rollen
5.3.5 Modellierung aspektorientierter Anwendungen
5.3.6 Translations-Polymorphismus

6 Compiere Monitor
6.1 Aspektorientierung in Compiere
6.2 Zielsetzung
6.3 Funktionalitäten
6.4 Die Compiere-Aspektgeneratoren
6.4.1 Aspektklassen
6.4.2 Aspektkon guratoren
6.5 Verwendete Techniken
6.6 Datenbankmodell
6.7 Implementierung
6.7.1 Allgemeine Konzepte
6.7.2 Design Patterns
6.8 Zusammenfassung

7 Ergebnis und Zusammenfassung
7.1 Evaluierung der Wandlungsfähigkeit von Compiere.
7.1.1 Ermittlung der Ein üsse des Compiere Monitor
7.1.2 Ergebnisportfolio
7.2 Zusammenfassung und Ausblick Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Listings

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation

Das Aufkommen der globalen Marktwirtschaft in den 60'er Jahren des letzten Jahrhunderts erö nete den Unternehmen völlig neue Märkte und Möglichkeiten des Wachstums. Diese, noch immer anhaltende, Entwicklung führte zwangsläu g zu einer stärkeren Konzentration an Konkurrenzunternehmen, wobei diese den Druck auf ein Unternehmen erhöhen. Innovationen, Produktionskosten, Kontakt zum Kunden oder die geographische Nähe zu den Absatzmärkten sind heute wichtige Faktoren im ökonomischen Wettstreit der Unternehmen.

Seit den Anfängen der Globalisation werden Methodiken zur Planung oder Optimierung der Prozessketten verwendet, um in diesem Wettstreit konkurrenzfähig zu bleiben. Diese Entwicklung schreitet bis zum heuti-gen Tage voran. Die Einführung einer computergestützten Planung und Kommunikation führte zu einer weiteren E zienzsteigerung und stellte damit einen Wettbewerbsvorteil dar, der die Entwicklung der sogenann-ten Unternehmenssoftware förderte. Der Begri Unternehmenssoftware bezeichnet dabei eine Software, welche typischerweise verteilt lau ähig ist und eine oder mehrere betriebliche Bereiche abdeckt. Eine Gruppie-rung solcher Unternehmenssoftware bildet der Bereich zur Planung von Ressourcen, sei diese nun in menschlicher, materieller oder auch nan-zieller Form. Allgemein bezeichnet man diese als Enterprise Ressource Planning -Software.

Eine Software, welche in die betrieblichen Prozesse eingebunden ist, erfordert einen möglichst hohen Grad an Wandlungsfähigkeit, um sich schnell und e zient den dynamischen Prozessen anpassen zu können. Eine Erhöhung der Wandlungsfähigkeit von ERP-Systemen ist die Be-strebung zahlreicher Forschungsinstitute und ERP-System-Anbieter.

Dem gegenüber steht in der Softwareentwicklung der Wunsch nach mehr Flexibilität und Modularität. Eine Entwicklung die dieses Ziel ver-folgt, ist die der aspektorientierten Programmierung (AOSD - Aspect Oriented Software Development ). Diese Arbeit stellt den Versuch dar, die beiden genannten Elemente vorteilhaft zu verknüpfen. Dazu wird die Wandlungsfähigkeit eines Open-Source-ERP-Systems untersucht, um anschlieÿend die positiven Ein üsse bei der Verwendung von Aspektorientierung im Sinne der Wandlungsfähigkeit aufzuzeigen. Als Grundlage dient dabei das Java-basierende Open-Source-ERP-System Compiere. Unter Verwendung des aspektorientierten Programmiermodells ObjectTeams wird dieses im weiteren Verlauf dieser Arbeit mit Aspekten angereichert werden. Die Erweiterung zielt hierbei auf eine Stärkung einzelner Kriterien der Wandlungsfähigkeit ab, um dadurch eine Steigerung der Gesamtwandlungsfähigkeit zu erreichen.

1.2 Struktur

Die vorliegende Arbeit ist unterteilt in die Kapitel:

- Kapitel 2 - Enterprise Resource Planning Dieses Kapitel gibt einen Überblick über den Begri des Enterprise Resource Planning und erläutert dessen Aufbau und Bedeutung innerhalb eines Unternehmens.
- Kapitel 3 - Wandlungsfähigkeit Der Begri der Wandlungsfähigkeit im Kontext von ERP-Systemen wird in diesem Kapitel näher erläutert.
- Kapitel 4 - Compiere Das Kapitel 4 gibt einen Einblick in den Aufbau und der Funktionsweise des ERP-Systems Compiere. Ebenso werden hier die verwendeten Technologien von Compiere, wie dem Applikations-Server JBoss, kurz erläutert.
- Kapitel 5 - Aspektorientierte Softwareentwicklung Hier werden die Konzepte der Aspektorientierung allgemein und speziell die für diese Arbeit relevanten, aspektorientierten Programmiermodelle vorgestellt und näher erläutert.
- Kapitel 6 - Compiere Monitor Kapitel 6 behandelt die Implementierung des Compiere Monitor. Dieser nutzt verschiedene Techniken der vorhergehenden Kapitel zur Einbettung unterschiedlicher Funktionalitäten in Compiere über die Verwendung von Aspekten.
- Kapitel 7 - Ergebnis und Zusammenfassung

Abschlieÿend gibt Kapitel 7 eine Übersicht der erzielten Steigerung der Gesamtwandlungsfähigkeit des ERP-Systems Compiere und zeigt die dabei einwirkenden Vorteile der Verwendung von Aspektorientierung.

2 Enterprise Resource Planning

2.1 Begri sklärung und Aufgabende nition

Die Anforderungen heutiger Unternehmen an Bereiche wie Logistik, Buchhaltung oder Verkauf sind vielschichtig, wobei die Kernanforderun-gen bei allen in der Planung von Ressourcen, sei es in personeller, materi-eller oder nanzieller Form, liegt. Eine möglichst e ziente Verteilung der vorhandenen Ressourcen auf die Geschäftsprozesse wird somit zu einer wichtigen Aufgabe innerhalb eines Unternehmens, dem Enterprise Re-source Planning (ERP). Für den Begri ERP existieren in der einschlä-gigen Literatur verschiedenste De nitionen. Aus diesem Grund soll der Begri für die vorliegende Arbeit explizit festgelegt werden. Dazu wird im Folgenden die Klärung der Aufgaben und Funktionen vorgenommen.

Die Aufgaben und Eigenschaften des ERP können zusammenfassend beschrieben werden als [WK01]:

- eine Sammlung unternehmensweiter Programme zum Management von Ressourcen im Zyklus von Angebot und Nachfrage
- die Fähigkeit den Kunden und Anbieter in einer kompletten Lie- ferkette miteinander zu verbinden
- die Verwendung bewährter Unternehmensprozesse zur Entschei- dungs ndung zu unterstützen
- die Eigenschaft einen hohen Grad an Inter-funktioneller Integration zwischen den Bereichen Verkauf, Marketing, Herstellung, Betrieb, Logistik, Einkauf, Finanzen, Produktentwicklung und menschlicher Ressourcen zu bieten
- der Unterstützung des unternehmerischen Betriebs, speziell den Be- reichen Kundendienst und Produktivität, auf einem hohen Niveau bei gleichzeitig geringeren Kosten und nötigen Lagerkapazitäten
- der Bereitstellung der Basis eines e ektiven e-Commerce

In [Gro04] wird des Weiteren als Wesensmerkmal von ERP-Systemen die Integration verschiedener Funktionen, Aufgaben und Daten in ein gemeinsames Informationssystem genannt, wobei der wesentliche Vorteil in der Automatisierung von Abläufen und in einer Standardisierung von Prozessen liegt. Der Begri Integration umfasst in diesem Zusammen-hang zwei Dimensionen (Abb. 2.1). Zum einen gibt es die horizontale Integration. Sie beschreibt die abteilungs- bzw. funktionsübergreifenden Prozesse, wie z.B. einen gemeinsamen Prozess aus den Bereichen Vertrieb und Lagerhaltung. Senkrecht dazu entsteht die zweite Dimension, die der vertikalen Integration. Sie umfasst alle Ebenen der Aufgaben, welche auf einen Bereich angewandt werden können, so z.B. die Ebenen der Admi-nistration oder der Planung des gemeinsamen Wirkbereichs Vertrieb.

Der Umfang einer vollzogenen Integration wird von einem Integrati-onsgrad beschrieben. Dieser gibt an, wie viele betriebliche Funktionen in dem ERP-System vereinigt wurden. Typischerweise ist der Integrati-onsgrad abhängig von den betrachteten Bereichen, d.h. Bereiche wie die Logistik oder Produktion bilden Bereiche besonders hoher integrativer Möglichkeiten. Für diese Bereiche, in [Gro04] Integrationsinseln genannt, entstehen in Unternehmen oft eigenständige ERP-Systeme. Nur wenn alle diese Integrationsinseln in einem gemeinsamen ERP-System zusammen-gefasst sind, spricht man von einem voll integrierten ERP-System.

Die Einbettung von ERP innerhalb der von Unternehmen eingesetzten betrieblichen Informationssysteme zeigt Abbildung 2.2. Im Zentrum steht dabei die ERP-Komponente, wobei das Supply Chain Management (SCM) und das Customer Relationship Management (CRM) die Verbindung in die Bereiche ausserhalb des Unternehmens darstellen. Sie stellen die Verknüpfung vom innerbetrieblichen ERP-System zum ausserbetrieblichen Lieferanten bzw. Kunden dar. Diese beiden Begri ichkeiten werden im Folgenden nun kurz beschrieben werden.

Supply Chain Management

Nothing Entirely New...Just a Signi cant Evolution [Hug03]

Der Begri Supply Chain Management beschreibt eine Lieferkette, Versorgungskette oder auch eine unternehmensübergreifende Wertschöp-fungskette. Diese Kette erstreckt sich dabei typischerweise vom Liefe-ranten bis hinüber zum Kunden und kann auch Querverbindungen zu verschiedenen Organisationen beinhalten. Sie dient der unternehmens-übergreifenden Koordination der Material- und Informations üsse über Abbildung in dieser Leseprobe nicht enthalten den gesamten Wertschöpfungsprozess hinweg, d.h. von der Rohsto gewinnung über die einzelnen Veredelungsstufen bis hin zum Kunden. Ziel ist hierbei, den Gesamtprozess sowohl zeit- als auch kostenoptimal zu gestalten. [BD04][SRJ99]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Horizontale und vertikale Integration betrieblicher Anwendungssysteme (nach [Gro04])

Customer Relationship Management

Die Ausrichtung auf den Kunden wird zunehmend zu einem kritischen Erfolgsfaktor innerhalb eines Unternehmens. Durch eine geringe Loya-lität des Kunden gegenüber den Unternehmen sind diese aufgefordert, die Wünsche des Kunden zu erkennen und in ihrem Handeln zu berück-sichtigen. Das Customer Relationship Management, im Weiteren auch als CRM bezeichnet, soll bei dieser Aufgabe helfen. Es umfasst die ge-samte Interaktion eines Unternehmens mit bestehenden und zukünfti-gen Kunden während des gesamten Prozesses der Kaufentscheidung und des Besitzzeitraums. Das CRM beinhaltet damit die Planung, Durch-führung, Kontrolle und Anpassung aller Unternehmensaktivitäten, wie Marketing oder Service, mit dem Ziel die Kundenbeziehungen zu optimie-ren. Um die Isolierung der einzelnen Unternehmensbereiche zu lockern, wird durch CRM eine globale Kundendatenbank etabliert, welche jedem Abbildung in dieser Leseprobe nicht enthalten Bereich Zugri auf dieselben Kundendaten ermöglicht. Dies verringert die Informationsverluste bei seperaten Kundendaten für jeden Bereich und erhöht damit die E zienz des Kundenkontaktes. Typische Funk-tionalität eines CRM ist daneben unter anderem das Bereitstellen eines Helpdesk, Kundendienstes oder die Möglichkeit einer Kundenwertanaly-se. [Gro04][HS00]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Aufgabenverteilung innerhalb betrieblicher Informationssysteme

Letztendlich kann aber auch CRM allein keine Kundenfreundlichkeit gewährleisten, sondern dient nur zur Unterstützung derselbigen. Dieser Umstand wird in [Bre03] wie folgt dargelegt:

...spielt die Technik im Gesamtkontext des Customer Re-lationship Managements keineswegs die dominierende Rolle. Denn eines ist klar: Beziehungen werden nicht von Compu-tern aufgebaut und gep egt, sondern einzig und allein von Menschen... Allerdings hängt der Erfolg neben Mitarbeitern und Technik auch von der organisatorischen Gesamtausrich-tung eines Unternehmens ab. Kundenfeindlich strukturierte Geschäftsprozesse werden allein durch guten Willen und mo-derne Technik nicht zu kundenfreundlichen.

2.2 Entstehungsgeschichte

Das Bedürfniss nach besseren Methoden zur Material- und Komponentenbestellung führte um 1960 zur Entwicklung des Material Requirement Planning (MRP). Primär ging es dabei um die Erfüllung der grundlegenden Fragen bei der Herstellung eines Produkts [WK01]:

- Was möchte ich herstellen?
- Was benötige ich für die Herstellung?
- Was haben wir auf Lager?
- Was müssen wir bestellen?

Sumner lokalisiert die Einführung des MRP jedoch 10 Jahre später, d.h. um 1970 [Sum05]. Das Planungssystem in den 60'ern bezeichnet sie dabei als Reorder point system. Dabei legt sie den Schwerpunkt der Un-terscheidung auf den jeweiligen Fokus der beiden Systeme. Resultierend daraus stehen Marketing und eine höhere Integration der Produktions-planung bei MRP einem Kostenfokus auf Seiten des Reorder point system gegenüber.

Der E zienzvorteil durch MRP säte den Keim für den Erfolg von ERP. Auf dem Weg zu dem umfassenderen ERP machte MRP noch einige Evolutionsschritte durch. Der erste vollzog sich durch die Hinzunahme von Priorisierungen, dem priority planning, und Komponenten zur Einschätzung des zukünftigen Kapazitätsbedarfes, dem capacity planning, innerhalb des MRP. Aus diesen Verbesserungen ging das closed-loop MRP hervor. An der dritten Evolutionsstufe steht dann das Manufacturing Resource Planning (MRP), welches in [Sum05] um 1980 lokalisiert wird und zusätzlich folgende Elemente beinhaltete:

- Planung von Verkauf & Betrieb zur Anpassung der Produktion an die bestehende Nachfrage und einer besseren Kontrolle der damit verbundenen betrieblichen Aspekte
- Transformation von betrieblichen Einheiten, wie Anzahl oder Ge- wicht, in nanzielle, wie Euro oder Dollar
- Simulation von Aktionen zur Bestimmung der Auswirkungen und Seitene ekten

Besonders das Element zur Simulation war in der Stufe der Evolution noch unterentwickelt, sollte sich dann aber bis zur folgenden und aktuellen Stufe des ERP bzw. ERP weiter ausbauen. Gronau nennt an dieser Stelle in [Gro04] zusätzlich noch zwei weitere Funktionen die als Evolutionselemente von MRP zu MRP genannt werden:
- Bescha ung (Einkauf )
- Zeitwirtschaft als Erweiterung der mengenorientierten Material- wirtschaft

Als Erweiterung von MRP ist ERP, aufgekommen in den späten 90'ern, e zienter geworden und bietet neben einem erweiterten Anwen-dungsbereich auch eine verstärkte Ingeration der Geschäftsprozesse. ERP kann als unternehmensweite Ansammlung von Programmen zur Vorher-sage, Planung und Terminierung verstanden werden und bietet eine Viel-zahl von Vorteilen, welche in Kapitel 2.1 beschrieben wurden. Eine weite-re Stufe des ERP zeichnet sich mit ERP ab, bei welchem der Bedarf an o enen Schnittstellen zum Internet im Mittelpunkt steht. Einen kurzen Überblick über die Entwicklung der genannten Planungssysteme soll mit Abbildung 2.3 gegeben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Evolutionsschritte des ERP

Mit dem Aufkommen der ersten ERP-Systeme geht auch das Erschei-nen des heutigen Marktführers SAP¹ im Jahre 1972 einher. Ziel dieser 3-Mann-Firma aus Mannheim war anfangs die bessere Integration von Geschäftsprozessen und Verknüpfung von Daten zur E zienzsteigerung des Geschäftbetriebs. Der Erfolg von SAP gab der Idee von ERP Recht und war der Anfang einer Entwicklung, die bis in die heutigen Tage reicht. Von dem anfänglichen Schwerpunkt auf den Bereich gröÿerer, globaler Unternehmen bildeten sich im Folgenden ERP-Systeme heraus, welche für kleine- und mittelständische Unternehmen (KMUs) konzipiert sind. Ein Beispiel solch eines ERP-Systems ist Compiere, das in Kapitel 4 beschrieben wird und welches als Grundlage späterer Betrachtungen in dieser Arbeit dienen wird.

2.3 Enterprise Systeme

Die Realisierung einer e zienten Ressourcenplanung in einem Unterneh-men wird mit zunehmender Anzahl der zu planenden Ressourcen immer aufwendiger und damit kostenintensiver. Um dem entgegenzuwirken, ste-hen Tools zur Verfügung, welche die Aufgaben des ERP unterstützen kön-nen. Sie werden als Enterprise Software (ES) bezeichnet und in [Dav00] wie folgt beschrieben:

"...packages of computer applications that support many, even most, aspects of a company's information needs."

Jedoch dient lediglich eine Untermenge der vorhanden Enterprise Software zur Realisierung der Aufgaben der Ressourcenplanung (Abb. 2.4). Um eine maximale Abdeckung der von ES unterstützten ERP-Prozesse zu gewährleisten, bedarf es einer auf diese ERP-Prozesse spezialisierten Enterprise Software - der ERP-Software, oder im Folgenden auch als ERP-Lösung bezeichnet. [WK01]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: ERP-Prozesse in Enterprise Software

Das Ausrollen einer ERP-Lösung innerhalb eines Unternehmens bedeu-tet jedoch nicht zwingend einen sofortigen Vorteil gegenüber der Konkur-renz. Es kann sogar zu einem anfänglichen Nachteil durch entstehende Kosten und Ein uss auf die laufenden Prozesse kommen. Die Benutzung von ERP-Lösungen bietet im Gegenzug aber das Potential zur Verbesse-rung der Prozesse, Beschleunigung der Zyklen und der Informations üsse allgemein sowie zu einem besseren Finanzmanagement. [Dav00]

Das erst spät einsetzende Wirken der Vorteile bei der Nutzung von ERP-Lösungen, stellt einen Hemmfaktor bei der Entscheidung für ei-ne ERP-Lösung dar. Daneben spielen auch noch die Kosten/Nutzen-Faktoren für Unternehmen eine wichtige Rolle. Besonders die Software-und Consultingkosten bilden den Hauptanteil der Kosten eines ERP-Systems. So wird in [Sum05] davon ausgegangen, dass eine Kostener-sparniss durch die Einführung eines ERP-Systems erst ab dem Zeitpunkt einsetzt, an dem Mitarbeitertraining und Implementierung abgeschlos-sen sind. Dies sind Faktoren, aus welcher eine Lebensdauer der ERP-Lösungen von 10 Jahren und mehr resultiert.

Die dynamischen Anforderungen des Unternehmens während dieses Zeitraums werden somit zu einer ständigen Herausforderung für eine Lö-sung. Um dem gerecht zu werden, müssen die Spezi kationen der ERP-Lösung an den Grad der benötigten Flexibilität angepasst werden. Neben den funktionalen Eigenschaften treten somit technische Charakteristika in den Vordergrund der Entwicklung neuer ERP-Lösungen. Einige der technischen Merkmale treten hierbei besonders hervor. Dies sind zum Beispiel die Zukunftsaussichten der Produkte, auf welche die Lösung aufbaut, sowie der Grad der Anpass- und Erweiterbarkeit der Lösung selbst. Sie sind es, die im hohen Maÿe etwas über die Fähigkeiten einer Lösung aussagen können, . Eine solche Fähigkeiten ist zum Beispiel, sich an dynamische ERP-Prozesse anpassen zu können um so eine stetig ho-he Abdeckung der ERP-Prozesse, welche durch ES unterstützt werden können, gewährleisten. Die dafür nötigen Architekturen und Techniken werden Bestandteil späterer Kapitel sein.

2.4 Aufbau eines ERP-Systems

Unabhängig von den jeweiligen spezi schen Charakteristika eines ERP-Systems weisen alle ERP-Systeme einen mehrstu gen Aufbau auf. (Abb. 2.5)

Die Abstufung ndet dabei über 4 vertikale Schichten statt:

1. Datenhaltungsschicht
2. Applikationsschicht
3. Adaptionsschicht
4. Präsentationsschicht

Jede dieser Schichten wird im Folgenden kurz beschrieben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Aufbau eines ERP-Systems (nach [Gro04])

Datenhaltungsschicht Diese unterste Schicht bildet das Fundament auf das alle anderen Schichten aufbauen. Sie dient der Datenhaltung und besteht aus Datenbanken, die über ein Datenbankmanagementsys-tem (DBMS), wie Oracle Database oder MySQL, verwaltet und ange-sprochen werden. Sie ermöglicht einen transparenten Zugri höhererlie-gender Schichten auf diese Datenbanken. Zusätzlich kann diese Schicht auch Schnittstellen zu anderen Datenbanken, welche nicht zwingend zum eigenen Informationssystem gehören müssen, beinhalten.

Applikationsschicht Der funktionale Kern des gesamten ERP-Systems mitsamt der dazugehörigen Business-Logik be ndet sich in dieser Schicht. Aus diesem Grund gehört zu dieser Schicht auch typischerweise eine Pro-grammierumgebung, mit welcher Funktionalitäten bis zu einem spezi -schen Grad erweitert oder ergänzt werden können. Desweiteren existiert in dieser Schicht eine Trennung zwischen dem datenbankabhängigen und datenbankunabhängigen Teil. Dies erlaubt eine individuelle Ausrichtung des datenbankabhängigen Teils auf die spezi schen Merkmale der jewei-ligen Datenbank. Daneben ist es möglich über Remote Procedure Calls (RPC) andere Programme aufzurufen, um deren Funktionalitäten zu nut-zen. Die Möglichkeit der Integration von Programmbausteinen, die in anderen Programmiersprachen geschrieben sind, wird über sogenannte User Exits ermöglicht.

Adaptionsschicht Eine Anpassung der Funktionalität und des Daten-modells des ERP-Systems an die jeweils abgebildeten betrieblichen Pro-zesse und Datenstrukturen ist Teil der Adaptionsschicht. Zusätzlich sind in dieser Schicht typischerweise Integrationselemente vertreten. Sie erlau-ben über Work ows eine Abbildung von Prozessketten, dessen einzelne Prozesse auch unterschiedliche Informationssysteme nutzen können.

Präsentationsschicht Als oberste Schicht bildet die Präsentationsschicht die Schnittstelle zum Benutzer. Sie kann die typischen Elemente, wie eine gra sche Benutzerober äche (GUI ) oder Internet-Browser, umfassen. Die von der Schnittstelle abgebildeten Funktionalitäten können dabei variieren. So bietet z.B. für gewöhnlich ein Internet-Browser weniger Funktionalität als eine gra sche Benutzerober äche.

2.5 Open-Source in unternehmensweiten Anwendungen

Der enorme Vormarsch von OpenSource-basierenden Projekten und An-wendungen in den vergangenen Jahren mag verschiedene Gründe haben. Für Unternehmen sind jedoch bei der Entscheidungs ndung zwischen kommerzieller, proprietärer und OpenSource-Lösungen bestimmte Krite-rien besonders entscheidend. Diese leiten sich im Falle von ERP-Lösungen direkt aus den, in Kapitel 2.3 genannten Anforderungen an eine ERP-Software ab. Insbesondere die Eigenschaft der Zukunftssicherheit einer ERP-Lösung spricht für eine Verwendung von Software auf Basis einer OpenSource-Lizenz

Problematisch ist das Auslaufen und letztendliche Versiegen der Pro-duktp ege seitens des Herstellers einer ERP-Lösung, sei es durch Fu-sionen, Konkurs oder anderer Ein üsse. Es führt nicht zwingend zu ei-nem Kon ikt bei Änderungen oder Evolutionen der eigenen Prozesse, stellt jedoch einen Risikofaktor dar, welcher die Entscheidung für eine OpenSource-Lösung bestärkt. Der o ene Quellcode und die weltweite Gruppierung der unterstützenden Programmierer bewirkt hier eine Ent-kopplung von Abhängigkeiten im Zuge von Produktevolutionen und Än-derungen. Bei einem Versiegen der Gruppierungen der freien Program-mierer bleibt einem Unternehmen hier weiterhin noch die Möglichkeit, den o enen Code durch nanzierte Programmierer erweitern und ändern zu lassen. Ein gänzliches Verschwinden der Erweiterungsmöglichkeiten ist bei solch einer Form der ERP-Lösung nicht möglich.

Im Folgenden sollen einige Kriterien zur Entscheidungs ndung bei der Auswahl von kommerzieller oder OpenSource-Software genannt werden [GW05]:

- Transparency: Die Beurteilung der Softwarequalität, ohne eine tiefere Analyse und Bewertung des zugrunde liegenden Programm- codes, bleibt auf die nach auÿen sichtbaren Komponenten der Soft- ware begrenzt. Typischerweise werden bei kommerzieller Unterneh- menssoftware Programmfehler auch nicht in den ö entlichen Raum, wie es z.B. Internetforen sind, getragen, um Hilfe zu ersuchen. Dies resultiert in einem begrenzten Wissenshorizont, was die Fehler und Schwächen des Programms betre en. Die Möglichkeiten zur Eva- luierung der Softwarequalität ist bei OpenSource-Software somit ungleich zahlreicher.
- The Sales Process: Zur Vermarktung kommerzieller Unterneh- menssoftware stehen überwiegend professionelle und vom Hersteller bezahlte Verkäufer zur Verfügung, welche auf Fragen bezüglich des Produktes Antworten geben können. Bei OpenSource-Software ist dies nicht der Fall - hier sind die Fragen an die Gemeinschaft der Programmierer bzw. Anwender zu richten. Eine Bewertung der ge- gebenen Antworten obliegt in beiden Fällen dem Fragesteller, d.h. einem Selbst. Einen Anspruch auf unbedingte Glaubwürdigkeit ha- ben beide Bezugsquellen der Antworten nicht.
- Flexibility: Individuelle Änderungswünsche, z.B. das Hinzufü- gen einer Funktionalität, sind bei kommerziellen Softwareproduk- ten an den Hersteller zu richten. Die Entscheidung, wann dieser die gewünschte Änderung vornimmt, obliegt ihm allein. Eine erhöhte Prioritätsstufe lässt sich hier oft nur durch eine gesteigerte Anfra- gezahl anderer Nutzer hinsichtlich derselben Änderung oder durch nanzielle Mittel erreichen. Die Zeitdauer bis eine Änderung vor-genommen wird, kann so mitunter Jahre in Anspruch nehmen. Bei OpenSource-Software gibt es diese Hindernisse nicht. Es bedarf nur dem Wissen, der Zeit und dem Aufwand um eine Änderung selbst-ständig durchzuführen bzw. durch die Gemeinde durchführen zu lassen.
- Risk of Quality: Die Entwicklung neuer Funktionalitäten inner- halb einer kommerziellen Software geschieht für den Benutzer bzw. dem Unternehmen im Verborgenen. Die Beurteilung der korrekten Funktionsweise der neuen Funktion beruht auf Vertrauen gegen-über dem Hersteller und wird nur mittels Trial & Fail, d.h. dem austesten der neuen Funktion, bestärkt. OpenSource-Software bie-tet hier den Vorteil der ö entlichen Diskussion über eventuelle Ne-bene ekte der neuen Funktion oder der korrekten Implementierung der Funktion selber. Das Risiko eines unentdeckten Nebene ektes oder Fehlers wird dadurch verringert.
- Risk of Productization: Ein Bereich, in welchem OpenSource gegenüber kommerzieller Software oft Schwächen aufzeigt, ist der des Produktrahmen. Damit sind Elemente gemeint sind, welche das Softwarepaket abrunden, wie z.B. ausführliche Dokumentationen, administrative Unterstützungstools oder Tools die das Installieren und Ausrollen der Software im Unternehmen erleichtern.
- Risk of Failure: Das Risiko des Scheiterns eines Softwareher- stellers besteht ebenso für OpenSource-Projekte, bei denen die Ge- meinde der Programmierer versiegt. Dieser Verlust wiegt bei jedoch kommerzieller Software schwerer, da hier nur bei vorher getätigtem Abschluss entsprechender Verträge die Herausgabe des Quellcode erwirkt werden kann. OpenSource-Projekte bieten diese Möglich- keit um ihrer Selbst willen und reduzieren damit das Risiko für die Unternehmen im Falle eines Scheiterns der Softwarehersteller.
- Risk of Takeover: Neben dem Risiko des Scheiterns des Soft- wareherstellers gibt es noch die Gefahr der Übernahme des Herstel- lers durch einen Konkurrenten, welcher ein vergleichbares Produkt anbietet. Au ösung des Supports des ursprünglichen Herstellers und erzwungene Migrationen zum Konkurrenzprodukt sind durch- aus übliche Szenarien und erhöhen das Risiko für das eigene Unter- nehmen. OpenSource-Projekte sind gegen diese Art von Übernah- men weitgehend geschützt.
- Support: Der Support der Unternehmenssoftware ist ein wich- tiges Entscheidungskriterium, welches durch kommerzielle Anbie- ter überwiegend durch spezialisierte Supportteams gewährleistet wird. Sie gewährleisten eine Unterstützung auf hohem Level, welche die jährlich anfallenden Gebühren für die Unternehmen rechtferti- gen. OpenSource-Projekte bieten im Gegensatz dazu gröÿtenteils nur Internet-Foren und andere Formen der schriftlichen Verö ent- lichung von Fragen. Die Qualität und Wartezeit der Antwort ist hier variabel, d.h. eine Instanz bei dringenden Fragen in Notsitua-tionen gibt es nicht. An diese Punkt setzen einige Firmen an, die ihr Wissen über die OpenSource-Software in Form eines Support-dienstes anbieten. Sie füllen die Lücke, welche OpenSource hin zu kommerzieller Software im Bereich des Supports aufweist.

Die Verwendung eines OpenSource-Produktes bringt also verschiedene Vorteile für Unternehmen. Besonders die genannten Punkte The Sales Process, Risk of Failure/Takeover und Support bilden für Unternehmen häu g die stärksten Argumente bei der Entscheidungs ndung. Sie bilden die Kriterien, welche in hohem Maÿe eine reibunglose und dauerhafte Nutzung des Produkts sicherstellen. Trotz der aufgezeigten Vorteile von OpenSource-Produkten existieren parallel dazu auch Nachteile, die sich besonders im Bereich des Support negativ auswirken können. Nichts-destotrotz ist die Entscheidungs ndung nicht generell zu Gunsten von OpenSource-Lösungen zu tre en, sondern unterliegt immer auch den je-weiligen Anforderungen der Unternehmen.

3 Wandlungsfähigkeit

Im vorangegangenem Kapitel wurden die Kernaufgaben eines ERBSystems näher erläutert und spezi ziert. Sie unterstützen ein Unternehmen bei der Koordinierung und Verbesserung ihrer Arbeitsprozesse. Diese Arbeitsprozesse sind jedoch nicht statisch. Das Aufkommen der globalen Marktwirtschaft hat nicht zuletzt auch den Änderungsdruck auf Unternehmen und damit auch ihrer Arbeitsprozesse erhöht. Im Zuge dieser Veränderungen des Marktes entwickelten sich Trends, welche in [Wil06] unter anderem wie folgt benannt werden:

- Anhaltender Preis- und Wettbewerbsdruck
- Erhöhte Anforderung an Lieferzeiten und Termintreue
- Steigende Nachfrage kundenindividueller Produkte
- Sinkende Produktlebenszyklen und Time-to-Market-Zeiten
- Hoher Innovationsanspruch in der Produktentwicklung
- Wechsel zu System- und Modullieferanten sowie Globalisierung von Produkten und Bescha ung

Die Anpassung an diese Trends durch die sich ändernden Unternehmensbereiche, seien dies nun z.B. geänderte Geschäftsprozesse oder Zuliefererketten, wird damit zu einem wesentlichen Erfolgskriterium eines Unternehmen. In diesem Kapitel soll nun der Begri der Wandlungsfähigkeit näher erläutert werden und die daraus resultierende Bedeutung für ERP-Systeme betrachtet werden.

3.1 Begri sklärung

Der Begri der Wandlungsfähigkeit wird in vielen Quellen unterschiedlich de niert. Aus diesem Grund soll an dieser Stelle eine kurze Erläuterung der in dieser Arbeit verwendeten Begri sde nition, angelehnt an [AG05], folgen:

Als Wandlungsfähigkeit bezeichnet man die Fähigkeit, sich bzw. etwas zu verändern, um sich an Veränderungen anzu-passen. Im Kontext von IT-Systemen konkretisiert sich dies auf eine Veränderung mit dem Ziel, sich an wechselnde Umge-bungen oder Gegebenheiten anzupassen. Daraus resultiert die Anforderung an ein Systems, Änderungen idealerweise selbst zu erkennen, um sich anschlieÿend mittels passender Lösungs-alternativen an die Änderung anpassen zu können.

Der Umfang des nötigen Aufwands, um ein System wandlungsfähig zu gestalten, hängt damit von der Systemumgebung ab und ist so individuell für jeden Systemtyp. Im Folgenden soll nun ein Einblick in den betrachteten Systemtyp dieser Arbeit, d.h. der Thematik wandlungsfähiger ERP-Systeme, gegeben werden.

3.2 Wandlungsfähige ERP-Systeme

Am Anfang dieses Kapitels fanden Trends Erwähnung, welche heutige Unternehmen dazu drängen, ihre Systeme und hier im speziellen ihre IT-Systeme wandlungsfähig zu gestalten. Ziel ist ein unternehmenswei-tes IT-System, welches sich an Änderungen innerhalb seiner Umgebung, den sogenannten Umweltturbulenzen, anpassen kann. Umweltturbulen-zen, wie sich ändernde Geschäftsprozesse, nden häu g im laufenden Sys-tembetrieb statt. Die Anpassungsfähigkeit bestehender ERP-Systeme ist hier meist nur ungenügend, d.h. die veränderten Geschäftsprozesse las-sen sich nur unvollständig oder ine zient abbilden. Ziel der Entwicklung bzw. Verbesserung wandlungsfähiger ERP-Systeme ist eine eigenständi-ge, schnelle und e ziente Anpassung an veränderte Anforderungen.

3.2.1 Kriterien der Wandlungsfähigkeit

Für eine Evaluierung der Wandlungsfähigkeit von Informationssystemen werden geeignete Kriterien benötigt, welche in diesem Abschnitt vorge-stellt werden.

Die Kriterien der Wandlungsfähigkeit nden sich auf zwei Dimensionen wieder. Die Dimension der technischen Ausprägung de niert die Kriterien zur Bestimmung des Potentials eines Softwaresystems, sich wandlungsfä-hig zu verhalten. Dem gegenüber steht die Dimension der unternehmen- sindividuellen Ausprägung. Ihre Kriterien bestimmen wie wandlungsfähig eine unternehmensindividuelle Informationsarchitektur ist. Die Kriterien der Wandlungsfähigkeit werden im Folgenden genannt [GLA06][ALG06]:

- Skalierbarkeit

Die Skalierbarkeit eines Informationssystem bezeichnet die quanti-tative Kapazität eines Systems. Dieser Indikator fordert die e zien-te Anpassung der Kapazitätsmenge sowohl nach oben als auch nach unten. Die Techniken zur Erfüllung dieses Kriteriums können dabei sowohl Hardware- als auch Software-basierend sein. Eine Hardwa-relösung könnte hier z.B. das automatische Entfernen, Freigeben oder Hinzufügen von Ressourcen beinhalten, sobald der problem-lose Betrieb des Systems gefährdet ist. Eine skalierbare Software-lösung muss selbst den Anforderungen entsprechen und mit ihnen wachsen können. Dies kann z.B. die Bildung von weiteren System-gruppen bei steigender Anwenderzahl sein.

- Modularität

Als Modularität bezeichnet man die Aufteilung eines Gesamtsys-tems in kleine Subsysteme, den Modulen. Ein Modul wird dabei de-niert als ein Konstrukt aus einem Modulrumpf und einer Modul-schnittstelle. Der Modulrumpf implementiert dabei De nitionen, welche durch die Modulschnittstelle gegeben werden. Die Schnitt-stelle spezi ziert damit die Eigenschaften eines Moduls, welche für seine Modulumgebung von Bedeutung sind. Die Möglichkeit der damit ermöglichten Wiederverwendung und Kombination von Mo-dulen kann eine schnelle und e ziente Anpassung des Systems un-terstützen und damit zur Erhöhung der Wandlungsfähigkeit beitra-gen.

- Verfügbarkeit

Die Verfügbarkeit ist das Kriterium der uneingeschränkten zeitlichen und räumlichen Zugri smöglichkeit auf das System. Dies bedeutet, dass ein System von jedem Ort aus und zu jeder Zeit für jeden verfügbar sein muss.

- Unabhängigkeit

Ein als unabhängig de niertes System agiert von anderen Systemen getrennt. Der Ausfall des Systems darf des Weiteren auch keinen Ein uss auf andere Systeme haben. Dies bedeutet, dass ein Sys-tem unabhängig von der Umgebung, wie dem Betriebssystem oder der System-Hardware, agieren können muss. Daneben zählen dazu auch alle wichtigen Subsysteme. Sie müssen vor Ausfällen bewahrt werden, wie z.B. durch geeignete Backup- und Redundanzstrategi-en.

- Interoperabilität

Als Interoperabilität bezeichnet man die Fähigkeit eines Systems mit anderen Systemen zu interagieren. Diese muss dabei unabhän-gig von der zugrundeliegenden Architektur, d.h. der Hardware, dem Betriebssystem, der Netzwerktopologie oder der Implementierung, sein. Durch diese Charakteristika lässt sich der Indikator dieses Kri-teriums auch als Maÿ der Systemkompatibilität verstehen. Die Ent-wicklung und Nutzung von Standards kann dabei helfen den Grad der erreichten Systeminteroperabilität zu erhöhen. Eine steigende Interoperabilität erhöht die Integrationsfähigkeit des Systems und unterstützt damit z.B. die Verteilung eines Geschäftsprozesses auf unterschiedliche Anwendungssysteme. Diese Eigenschaft der stei-genden Integrationsfähigkeit räumt diesem Kriterium eine zentrale Rolle unter den Kriterien der Wandlungsfähigkeit ein. Sie stärkt die Kommunikationsfähigkeit über System- und damit auch Unter-nehmensgrenzen hinweg und kann sich so auch auf Eigenschaften der Verfügbarkeit und Unabhängigkeit auswirken und diese positiv beein ussen.

- Selbstorganisation

Die Selbstorganisation von Systemen bezeichnet deren Fähigkeit ih-re Systemstruktur mittels selbstregulierender Mechanismen selbst zu ermitteln, um mit diesen Informationen den problemlosen Be-trieb zu gewährleisten. Dabei sammelt jedes der Subsysteme Infor-mationen über ihre Umwelt und ihrer eigenen Wechselwirkungen mit ihr. Diese Informationen werden genutzt, um ein Modell zu er-stellen, nachdem das Subsystem dann handeln kann. Umweltverän-derungen eines dieser Subsysteme führt zu einer Änderung dieses Modells und damit des Verhaltens dieses Subsystems selbst. Das Kriterium der Selbstorganisation von Informationssystemarchitek-turen verlangt vom System demnach die Fähigkeit, seine innere Struktur bzw. Architektur selbst ganz oder teilweise zu bestimmen.

- Selbstähnlichkeit

Als Selbstähnlichkeit wird die Eigenschaft eines Systems bezeich-net, auf unterschiedlichen Abstraktionsebenen immer wieder diesel-ben Muster vorzu nden. Diese Skaleninvarianz hilft bei der Kom- plexitätsreduzierung eines Systems und unterstützt damit auch die Selbstorganisation. Daneben bietet sie noch weitere Vorteile, wie die leichtere Erlernbarkeit. So ist z.B. ein selbstähnlicher Quellcode schneller zu analysieren als Code mit ständig wechselnden Patterns oder Stilen.

- Automatisierungsgrad: Neben dem Customizing durch eine Pa- rametrisierung ist hiermit auch die Anpassung des Systems durch Änderung seiner Implementierung gemeint. Dadurch wirkt sich die- ser Punkt insbesondere bei quello enen Systemen aus.
- Systemwissen: Änderungen an einem System erfordern Wissen über die jeweiligen Eigenheiten und Details dieses Systems. Je bes- ser das vorhandene und je geringer das nötige Wissen ist, desto e zienter ist die Umsetzung und daher auch die Wandlungsfähig- keit des Systems.

3.2.2 Wandlungsfähige Architekturmodelle

Im Zuge der Entwicklung der in diesem Kapitel genannten Kriterien der Wandlungsfähigkeit eines ERP-Systems, wurde ein Referenzmodell für wandlungsfähige Systemarchitekturen entwickelt (Abb. 3.1). Da die einzelnen Schichten dieses Modells den kontextuellen Rahmen für die Kritieren der technischen Ausprägung bildet, soll dieses Modell an dieser Stelle kurz vorgestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Architekturmodell für wandlungsfähige ERP-Systeme (nach [GLA06])

- Infrastrukturschicht

Die Infrastruktur bildet die unterste Schicht des Modells und beinhaltet Informationen über die Verteilung des Systems sowie der verwendeten Topologie

- Datenschicht

Das Datenbankmanagementsystem mitsamt den Datenbanken wird in der Datenschicht zusammengefasst.

- Applikationsschicht

Die Applikationsschicht hilft bei der Strukturierung der einzelnen Systemkomponenten. Es beinhaltet den sogenannten Servicelayer, welcher Ressourcen und Transaktionen verwaltet.

- Präsentationsschicht

Die Präsentationsschicht dient der Interaktion zwischen Benutzer und dem System. Es stellt damit das Benutzerinterface des Systems dar.

- Kontrollschicht

Diese Schicht dient der Modellierung von Geschäftsprozessen. Änderung an dem Modell werden von dieser Schicht an alle ihre Unterschichten kommuniziert und somit konsistent gehalten.

Durch alle diese Schichten zieht sich die vertikale Adaptionsschicht. Sie beinhaltet alle wandlungsfähigen Elemente der jeweiligen Schicht und bildet damit ein Maÿ zur Evaluierung des erreichten Grades der Wand-lungsfähigkeit aller Schichten, d.h. des gesamten ERP-Systems.

3.2.3 Ermittlung der Wandlungsfähigkeit

Mit Hilfe der im vorangegangenem Abschnitt vorgestellten Kriterien kann nun ein aussagekräftiger Wert für den Grad der Wandlungsfähigkeit er-mittelt werden. Das Vorgehensmodell hierfür beinhaltet ein stufenweises Vorgehen innerhalb einer Hierarchie von Bewertungen. Die Reihenfolge erfolgt dabei bottom-up, d.h. man beginnt bei der untersten Hierarchie-stufe und folgt ihr schrittweise nach oben bis zum Erreichen der Wurzel. Diese Hierarchie soll im Folgenden kurz erläutert werden. Auf oberster Stufe ndet in ihr zuallererst eine Aufteilung in zwei Typen der Wand-lungsfähigkeit statt. Die Typen und ihr weiterer hierarchischer Aufbau werden nun kurz erläutert werden.

1. Technische Wandlungsfähigkeit

Diese Art der Wandlungsfähigkeit hat als Fokus das eigentliche Anwendungssystem an sich. Es gliedert sich in jedes der Schich-ten des wandlungsfähigen Architekturmodells aus Abbildung 3.1 und betrachtet dabei pro Schicht jeweils die genannten Kriterien aus 3.2.1. Jedem dieser Kriterien ist dabei für die jeweilige Modell-schicht ein passender Fragenkatalog zugeordnet, mit welchem ein Punktwert für die Wandlungsfähigkeit in dieser Schicht und unter dem jeweiligen Kriterium ermittelt werden kann. Aus den Ergebnis-sen der Fragebögen der einzelnen Kriterien lässt sich anschlieÿend ein Wert zur Wandlungsfähigkeit für die Gesamtschicht ermitteln. Je höher der erreichte Wert eines Kriteriums oder einer Schicht ist, desto mehr Komponenten liegen innerhalb der vertikalen Adapti-onsschicht des Architekturmodells und umso wandlungsfähiger ist damit das Gesamtsystem.

2. Geschäftsspezi sche Wandlungsfähigkeit

Die zweite Ebene der Betrachtung ist die der unternehmensindi-viduellen Wandlungsfähigkeit, d.h. der Beurteilung, inwieweit das System Geschäftsprozesse zur Laufzeit des Systems umsetzen und ändern kann. Zu diesem Zweck gibt es einen Fragebogen, welcher sich auf die 4 Reorganisationsansätze von Gronau in [Gro06] be-zieht:

- Subsystembildung: Zuordnung oder Aufspaltung der Aufga- benbearbeitung zu einzelnen Untersystemen
- Prozessorientierung: Ausrichtung und Anpassung der Pro- zesse entlang der Wertschöpfungskette
- Kontinuierlicher Verbesserungsprozess: Kontinuierliche Betrachtung des Unternehmens über einen Zeitabschnitt hin- weg zur Bildung von Subsystemen und Ausrichtung der Pro- zesse an der Wertschöpfungskette
- Au ösung der Unternehmensgrenzen: Ausweitung der Wertschöpfungskette über die eigenen Systemgrenzen hinaus

Jedes dieser Reorganisationansätze beinhaltet jeweils eine Reihe von Teilprozessen. Sie werden in Form von Fragen formuliert und erlauben die Beantwortung über die beiden Kritieren Automati- sierungsgrad und Systemwissen. Diese werden mittels einer fünf- 1 stu gen Skala für den betrachteten Teilprozess bewertet. Alle Be- wertungen zusammen geben Aufschluss darüber, inwieweit der je-weilige Reorganisationsansatz im betrachteten System realisierbar ist und dienen so der Ermittlung der geschäftsspezi schen Wand-lungsfähigkeit.

Die einzelnen Elemente dieser Hierarchie können einen verschieden grossen Ein uss auf die reale Wandlungsfähigkeit ausüben. Diesem wird man gerecht, in dem jedes Element zusätzlich eine Gewichtung bekommt. Sie bestimmt bei der späteren Berechnung, wie stark der ermittelte Wert zur Wandlungsfähigkeit eines Elements, z.B. eines Kriteriums oder einer Schicht, auf das Endergebnis Ein uss nimmt. Die Gewichtung wird hier-bei mit dem Analytical Hierarchy Process von Saaty [SV00] ermittelt. Auf eine tiefergehende Betrachtung des mathematischen Modells zur Be-rechnung der Wandlungsfähigkeit wird an dieser Stelle aber verzichtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Hierarchie zur Ermittlung der Wandlungsfähigkeit eines ERP-Systems

Die Fragenkataloge jedes Kriteriums sowie das gesamte Vorgebensmo-dell wurden innerhalb des Forschungsprojektes CHANGE² am Lehrstuhl für Wirtschaftsinformatik und Electronic Government der Universität Potsdam³ entwickelt. Sie nden innerhalb eines Werkzeuges zur Evalu-ierung der Wandlungsfähigkeit eines ERP-Systems Anwendung - dem Adaptability Analyzer . Diese Java-Applikation wurde im Rahmen ei- ner Diplomarbeit am genannten Lehrstuhl entwickelt und unterstützt den Benutzer bei der Beantwortung aller Fragen jedes Kriteriums. Aus den Antworten wird daraufhin das, im Anschluss näher beschriebene Be-wertungsportfolio erstellt. Das Ergebnis der Bewertung des Adaptabili- ty Analyzer dient als Qualitätsmerkmal eines ERP-Systems und wird in Form einer Zerti zierung durch das Center for Enterprise Research käu ich vertrieben. Aus diesem Grund ist der Fragenkatalog nicht ö ent-lich einzusehen und wird in den abschlieÿenden Bewertungen (Siehe 7.1) nur Auszugsweise genannt werden. Des Weiteren dient der Adaptability Analyzer in späteren Kapiteln lediglich der Bewertung der Wandlungs-fähigkeit von Compiere und bedarf damit an dieser Stelle selbst keiner detaillierteren Betrachtung.

3.2.4 Auswertung der Wandlungsfähigkeit

Im Verlaufe dieses Kapitels wurde das Vorgehen zur Evaluierung der Wandlungsfähigkeit von ERP-Systemen erläutert. Durch die Auswertung der Antworten auf die Fragen der einzelnen Hierarchieebenenen kann ein Wert sowohl für die technische- als auch die geschäftliche Wandlungsfä-higkeit ermittelt werden. Diese beiden Werte dienen der Einordnung des Systems in ein Portfolio, in welchem sich die technische- und geschäftss-pezi sche Wandlungsfähigkeit gegenüberstehen (Abb. 3.3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Ergebnisportfolio für ERP-Systeme bezüglich Wandlungsf higkeit (nach [ALG06])

Dieses Portfolio ordnet die untersuchten Systeme in 4 Quadranten ein, wobei jedes der Quadranten unterschiedliche Aussagen zulässt. Der Qua-drant Durchschnittlich beinhaltet Systeme, welche sowohl in der tech-nischen als auch in der geschäftsspezi schen Wandlungsfähigkeit eher geringer Ausprägung sind. Als Technisch fortgeschritten wird der Qua-drant betitelt, welcher die Systeme umfasst, die technisch sehr wand-lungsfähig sind, jedoch nur eine mangelhafte Unterstützung von sich än-dernden Geschäftsprozessen bieten. Ein weiterer Quadrant ist Prozess fortgeschritten . Ein System, welches in diesem Quadranten liegt, erlaubt eine sehr gute Abbildung von Geschäftsprozessen im System, ohne jedoch Abbildung in dieser Leseprobe nicht enthalten über eine vergleichbare technische Wandlungsfähigkeit zu verfügen. Dies tri t oft bei der Betrachtung von spezialisierten oder standardisierten Geschäftsprozessen zu, auf die ein System zugeschnitten sein kann. Als Ausgezeichnet ist der Quadrant bezeichnet, der eine hohe Ausprägung auf beiden Ebenen der Wandlungsfähigkeit bietet. Er ist der Bereich, in dem ein System im Sinne der Wandlungsfähigkeit idealerweise liegen soll.

Die Gegenüberstellung der beiden Ebenen der Wandlungsfähigkeit er-laubt eine Beurteilung des betrachteten Systems und auch einen objek-tiven Vergleich mit anderen Systemen. Die durch diese Auswertung ge-wonnenen Resultate können sowohl den Entwicklern als auch den Kunden dienen. Aus Entwicklersicht dienen sie dem Erkennen von Schwachstellen im System und dem Finden neuer Entwicklungsansätze. Der Kunde hat mit ihnen ebenfalls die Möglichkeit, Schwächen eines Systems zu erken-nen. Er nutzt sie jedoch zur frühzeitigen Beurteilung eines Systems und die damit verbundene Entscheidungshilfe.

3.2.5 Bedeutung der Wandlungsfähigkeit für ERP-Systeme

Allgemein benötigt man für eine aussagekräftige Gegenüberstellung von Dingen ein Bewertungsmass, welches für alle Vergleichselemente diesel-ben Metriken und Methoden beinhaltet. Auf die Frage nach einer Be-wertung der Wandlungsfähigkeit eines ERP-Systems haben dessen Ent-wickler in der Vergangenheit häu g subjektiv entschieden und damit die Nutzung einer Vergleichsmatrix erschwert [AKS05]. In diesem Kapitel wurde nun eine einheitliche Methodik zur Bewertung der Wandlungsfä-higkeit eines ERP-Systems vorgestellt. Sie erlaubt anhand ihrer Ergeb-nise und deren Einordnung in das vorgestellte Portfolio eine Gegenüber-stellung verschiedener ERP-Systeme. Mit ihr lassen sich für jedes der ERP-Systeme Schwachstellen bezüglich der Wandlungsfähigkeit lokali-sieren.

Eine gesteigerte Wandlungsfähigkeit dient dabei zuallererst dem Kun-den. Diesem wird durch ein wandlungsfähiges System erlaubt, seine Geschäftsprozesse zur Laufzeit des Systems anzupassen und im Ideal-fall das System selbst nach den eigenen Wünschen zu gestalten. Zum Grossteil wirkt dies jedoch entgegen den Interessen der Systementwick-ler. Wartungsverträge und der Verkauf von Erweiterungsmodulen bilden einen Hauptpfeiler des Tagesgeschäfts vieler Anbieter. Ein System mit stark ausgeprägter Wandlungsfähigkeit würde diese Geschäftsbereiche einschränken. Nichtsdestotrotz kommt dem Thema Wandlungsfähigkeit auch von Entwicklerseite ein reges Interesse zu. So bewerten bereits vie-le Entwickler die Flexibilität des ERP-Systems als entscheidenden Punkt für zukünftige Weiterentwicklungen [AKS05]. Nicht zuletzt, weil das Prä-dikat der hohen Wandlungsfähigkeit die Attraktivität eines ERP-System für den Kunden steigert. Wie so oft wird sich hier aber ein Konsens der Interessen bilden und die Wandlungsfähigkeit auch in Zukunft ein Im-pulsgeber für die Weiterentwicklung von ERP-Systemen bleiben.

4 Compiere

compiere [kompjere] ital. für erreichen, erfüllen, abliefern

Das seit 1999 entwickelte OpenSource-Projekt Compiere ®1 stellt eine ERP-Lösung mit dem Schwerpunkt auf kleine und mittelständische Un-ternehmen dar. Der Name Compiere ist ein registriertes Markenzeichen der ComPiere Inc., wird im weiteren Verlauf dieser Arbeit aber nicht wei-terführend als solches gekennzeichnet. Als Produkt mit dem funktionalen Kern im Bereich der Ressourcenplanung tritt Compiere in Konkurrenz zu kommerziellen Produkten von Microsoft, SAP und anderen. Die in 2.5 genannten Vorteile von OpenSource ermöglichten dem Produkt, sich auf dem Markt zu behaupten. Wirtschaftlich trägt sich dieses Projekt, welches zum Zeitpunkt der Ausarbeitung über 55 Mitarbeiter in der Ent-wicklung beschäftigt, durch die Ausrichtung des Geschäftmodells rund um das Produkt. So bilden Support in Form von Wartungsverträgen, Training und das Bereitstellen von Dokumentationen das Kerngeschäft der Compiere Inc.

Das in diesem Kapitel Betrachtung ndende Compiere entspricht dem Release 2.5.3a.

4.1 Funktionalitäten

Anders als bei einigen anderen Entwicklungen, liegt die funktionale Hauptausrichtung im Design von Compiere in der Abbildung von Ge-schäftsprozessen. Eine zentrale Aufgabe kommt dabei dem Ressource-Management zu. Dieser verknüpft die abgebildeten Geschäftsprozesse mit den Ressourcen, wie Material, Kapital oder Personal und erlaubt damit die Integration verschiedenster Ressourceneigenschaften in die ab-gebildeten Geschäftsprozesse. Ein vorstellbares Anwendungsbeispiel wäre hier die Anpassung des Geschäftprozesses Verkauf an die vorhandenen Ressourcen. Das Unterbreiten eines Angebotes ist nur sinnvoll, wenn die nötigen Ressourcen vorhanden bzw. lieferbar sind. In Abbildung 4.1 sind diese Relationen zwischen den Geschäftprozessen und den Ressourcen abgebildet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1: Basisfunktionalitäten von Compiere (Nach [Com])

Im Folgenden soll nun noch eingehender auf die von Compiere implementierten Funktionalitäten und abgebildeten Geschäftsprozesse eingegangen werden. [Com]

4.1.1 Quote-to-Cash

Quote-to-Cash bezeichnet den Geschäftsprozess Verkauf und beinhaltet die folgenden Elemente:

- Angebot

Erstellung und Druck eines Angebotes für potentielle bzw. reale Kunden. Dieses basiert auf allgemeinen oder kundenbezogenen Preislisten und kann bindend wirken, d.h. Ressourcen werden für dieses Angebot reserviert. Angebote können jederzeit geändert und zu Aufträgen konvertiert werden.

- Auftrag

Das Management der getätigten Bestellungen umfasst die Ausliefe-rung und die Erstellung von Rechnungen. Ein Auftrag kann dabei verschiedene Aktionen implizieren, welche über den Auftragtypus geregelt werden. Hierbei werden die folgenden Aufträge unterschie-den:

- Standard: Erstellung eines Auftrages mit anschlieÿender Reservierung der benötigten Ressourcen. Die Rechnung wird sofort oder nach erfolgter Lieferung erstellt.
- POS-Auftrag: Sofortiges Einleiten aller Auftragselemente, d.h. Erstellen des Auftrages, Auslieferung, Drucken der Rechnung und Empfang der Bezahlung.
- Kredit-Auftrag: Erstellung des Auftrages mit sofort erfolgen-der Lieferung und Rechnungsstellung, aber mit optionaler Be-zahlung. Diese kann hier zu einem späteren Zeitpunkt erfolgen.
- Warenhaus-Auftrag: Sofortige Erstellung und Lieferung des Auftrages. Das Ausstellen der Rechnung und die Bezahlung können zu einem späteren Zeitpunkt erfolgen.
- Vorkassen-Auftrag: Nach Erstellen des Auftrages und der Rechnung wird auf die eingehende Bezahlung gewartet, bevor die Lieferung eingeleitet wird.
- Reklamation (RMA): Umfasst das Empfangen von schon gesandten Artikeln im Zuge einer Reklamation.

- Lieferung

Basierend auf dem Auftrag werden eine oder mehrere Lieferungen eingeleitet, welche sofort oder automatisch bei Vorhandensein der benötigten Ressourcen getätigt werden können.

- Rechnung

Rechnungen werden entweder sofort nach der Auftragsgenerierung oder nach erfolgter Lieferung erstellt. Dabei können auch Verzögerungen erzwungen werden, wie sie zum Beispiel bei monatlichen Sammelrechnungen nötig sind.

- Bezahlung & Quittungen

Die automatische Generierung von Quittungen wird über sogenann-te Payment-rules gewährleistet, wobei diese eine Bezahlung über verschiedene Arten, wie Kreditkarte oder Scheck, erlauben.

Die genannten Elemente bilden den gesamten Prozess des Verkaufes ab und sind stark in das Supply-Chain-Management (Abschnitt 4.1.5) und dem Customer-Relationship-Management (Abschnitt 4.1.3) integriert. Dies erhöht die Anpassbarkeit der Angebote an die verfügbaren Res-sourcen und einen genaueren Zuschnitt an den jeweiligen Kunden.

4.1.2 Requisition-to-Pay

Die Befriedigung der Anforderungen an vorhandene Ressourcen zum lau-fenden Betrieb ist ein essentieller Bestandteil eines ERP-Systems. Der Geschäftsprozess Requisition-to-Pay dient der Akquirierung von Ressourcen als Unterstützung zur Erfüllung dieser Anforderungen. Er deckt den Ablauf von der Requirierung bis zu dessen Bezahlung ab. Dabei wird basierend auf der Anforderung eine Einkaufsbestellung generiert, welcher eine dazugehörige Rechnung und Bezahlung folgt. Aufgrund der Verknüpfung zur Lieferantenkette und dem Lieferanten als Kunden, ndet in diesem Prozess eine starke Integration des Supply-Chain-Management und des Customer-Realtionship-Management statt.

Auf die Elemente dieses Geschäftsprozesses soll an dieser Stelle nicht näher eingegangen werden, da diese analog zu dem Prozess Quote-to-Cash stehen.

4.1.3 Customer-Relations-Management (CRM)

Das in Kapitel 2.1 erläuterte Konzept des Customer-Relations-Management dient der Verbesserung des Kundenkontaktes durch die Bereitstellung eine möglichst hohen Vielzahl an Kundeninformationen. Anders als die typischen ERP-Systeme ist das CRM nicht als geson-dertes Modul in Compiere implementiert, sondern ist selbst integraler Bestandteil der Business Prozesse. Der Grund dafür liegt wohl auch in dem Umstand, dass das CRM in Compiere sehr rudimentär ausgebildet ist und ein gesondertes Modul über üssig werden lässt.

So bietet Compiere beispielsweise keine Kundenservice-Center Funk-tionalitäten oder eine Kundenwertanalyse wie sie in Abschnitt 2.1 darge-legt wurden. Nichtsdestotrotz gereicht der Integrationsumfang zur Ver-besserung des Kundenkontaktes und erreicht damit ein wesentliches Ziel des CRM.

4.1.4 Partner-Relations-Management

Eine Erweiterung der CRM-Funktionalitäten bildet das sogenannte Partner-Relations-Management von Compiere. Es erlaubt die Nutzung von CRM-Funktionalitäten über die Grenzen von Compiereklienten und - rmen hinweg. Es verbindet verschiedene Systeme und erlaubt dane-ben den Zugri über Webschnittstellen für Partner, welche nicht dem Verbund angehören. Die Funktionen sind wie folgt zusammenzufassen:

- Server-übergreifendes Relationship-Management

Für nichtverbundene Partner bietet das Partner-Relations-Management eine Webschnittstelle zum Informationszugri an. Systeme, welche dem Verbund angehören, kommunizieren unterein-ander mittels Anfragen, den Requests. Neben der Verbesserung der

[...]

---

¹ Mit einem mehr als klaren Marktanteil von 54,8% Im Jahre 1999 ist SAP auch zum heutigen Tage Marktführer unter den ERP-System-Anbietern. [tusT]

² Beispiel einer, an wirtschaftliche Interessen angepassten, OpenSource-Lizenz ist die Mozilla Public Licence [Moz00]

¹ = Keine Anpassung möglich, 1 = Anpassung durch Add-Ons, 2 = Anpassung durch Modi kationen, 3 = Anpassung durch Parametrisierung, 4 = autom. Selbstkonfiguration

² http://www.change-projekt.de

³ http://wi.uni-potsdam.de

⁴ http://wi.uni-potsdam.de/projekte/ceronline.nsf ?Open&ID=AEC3CD875292223AC125710000798BF3

⁵ http://www.erp-research.de

¹ http://www.compiere.org - ComPiere Inc., Portland, USA