Evaluierung der Open Source ERP und CRM Software Compiere

Inhaltsverzeichnis

1 Abstract

2 Einleitung
2.1 ERP
2.2 ERP und Open Source
2.3 Compiere - Eine Open Source ERP/CRM Software

3 Das Projekt Compiere

4 Architektur und verwendete Technologien
4.1 Prozess- und modellgetriebene Softwarearchitektur in Compiere
4.2 Benutzerinteraktion
4.2.1 Compiere Mobil
4.3 Application Service Provider
4.4 Das Service Center Konzept
4.5 Active Data Dictionary
4.6 Benutzeroberfläche
4.7 Informationsstruktur
4.7.1 Automatic Data Collection
4.7.2 Die Kombination von Informationen
4.8 Die Multies“ - Ansätze für internationale Unternehmen
4.9 Anwendungsintegration
4.9.1 Compiere Schnittstellen
4.9.2 Compiere Reporting
4.9.3 EDI - Electronic Data Interchange
4.9.4 E-Commerce über XML
4.10 Safe Fail
4.11 Sicherheitskonzept
4.12 Datenbank

5 CRM in Compiere
5.1 Voraussetzungen für eine CRM Lösung in Compiere
5.2 Operatives CRM
5.3 Analytisches CRM
5.4 Kollaboratives CRM
5.4.1 Self-Service in Compiere
5.5 Compiere im Vergleich zu anderen Systemen

6 Compiere im Einsatz
6.1 Die Installation
6.2 Start und Anmeldung
6.3 Initiale Konfiguration
6.4 Fachliche Konfiguration
6.5 Arbeit mit dem Webstore
6.6 Kostenlose Hilfe und Einflussnahme

7 Res ümee

8 Ausblick

9 Glossar
9.1 Terminologien in Compiere
9.2 Abkürzungen und Begriffe

1 Abstract

Der Einsatz von integrierter Unternehmenssoftware wird mit der fortschreitenden Technisierung auch für kleine und mittelständische Unternehmen immer wichti- ger. Jedoch schrecken viele Unternehmen vor hohen Lizenzkosten etablierter Soft- warehersteller zurück und für umfangreichere Individuallösungen ist meist kein ausreichendes Budget vorhanden. Mit Compiere existiert eine ERP/CRM Softwa- re, die als Open Source Projekt entwickelt und somit ohne Lizenzkosten genutzt werden kann. Compiere richtet sich an kleine und mittelständische Unternehmen in der Vertriebs- und Dienstleistungsbranche. Mit einer prozessorientierten Archi- tektur bietet Compiere eine sehr flexible Lösung, die jederzeit an Veränderungen angepasst werden kann. Diese Arbeit erörtert die Konzepte in Compiere und geht auf die Frage ein, ob einem Open Source Projekt überhaupt die Verantwortung für die Geschäftsprozesse eines Unternehmens übertragen werden kann. Ein besonde- res Augenmerk soll auf die versprochene CRM Komponente in Compiere gelegt werden. Diese ist zwar vollständig integriert, bietet aber längst nicht alle Funktio- nalitäten, die man von einer CRM-Lösung erwarten könnte.

Die Evaluierung von Compiere basiert in dieser Arbeit auf den Erfahrungen, welche bei der Realisierung eines Compiere-Systems in einem vordefinierten Szenario gemacht wurden.

Diese Erfahrung hat gezeigt, dass Compiere einen sehr guten Ansatz für ein ERP System darstellt, die CRM-Komponente allerdings noch sehr unterentwickelt ist. Die Architektur der Software aber bietet eine solide Grundlage für die Erweiterung des Funktionsumfangs der Software, so dass Compiere eine ernst zu nehmende Konkurrenz zu Business One von SAP, Oracle’s Small Business Suite oder Navision von Microsoft wird oder in einigen Bereichen schon ist.

Die rasanten Entwicklungen der Informationstechnologie haben innerhalb der letz- ten Jahre dazu geführt, dass heute kaum ein Unternehmen ohne den Einsatz von IT wettbewerbsfähig bleiben kann. Immer komplexere und schneller ablaufende Prozesse bedürfen spezieller Software. Hier gibt es unterschiedliche Ansätze. Zu Beginn des IT-Einsatzes gaben vornehmlich Großunternhemen Individuallösungen in Auftrag. Diese sehr teure Variante hat den Vorteil, dass die Software genau auf die Prozesse und Eigenheiten des Unternehmens abgestimmt werden konnte. Eine weitere Möglichkeit war die Nutzung unterschiedlichster Standardsoftwareproduk- te für den jeweiligen Anwendungszweck. Fehlende Schnittstellen und somit feh- lende Integration der einzelnen Softwareprodukte führen jedoch oft zu redundanter und inkonsistenter Datenhaltung oder zu Medienbrüchen.

Um die Kosten für Individualsoftware zu senken, trotzdem aber die Vorteile ei- ner hohen Integration und Individualisierbarkeit zu nutzen begann man mit der Ent- wicklung von standardisierter aber flexibel konfigurierbarer Unternehmenssoftwa- re. Beispielsweise der Pionier und heutige Marktführer auf diesem Gebiet, SAP¹, bietet ein modularisiertes Softwaresystem, welches alle Bereiche eines Unterneh- mens unterstützt und durch die Integration der einzelnen Komponenten vernetzt. Eine solche Standardsoftware, welche die Kernfunktionalitäten eines Unterneh- mens abbildet, nennt man Enterprise Ressource Planning System (ERP)

2.1 ERP

”EnterpriseRessourcePlanning(ERP)entstandamAnfangder90 erJahre.Das neue Genre der Unternehemenssoftware optimierte Produktionsprozesse, in Deutsch- land zuvor bekannt als so genannte Produktionsplanungssysteme (PPS). ERP-Systeme f ügten zu diesem produktionszentrierten Ansatz eine Verbindung zum Finanz und Rechnungswesen hinzu. Damit waren sie stärker bezogen auf Warenumsatz, Kos- ten und Leistungsrechnung sowie auf Gewinnermittlung. Hinzu kamen weitere Unternehmenselemente wie Personalwesen und Logistik.“[3] Da nicht nur inter- ne, sondern auch unternehmensübergreifende Prozesse mit IT-Unterstützung abge- wickelt werden, spricht[3] von erweitertem ERP, das Funktionen wie Customer Relationship Management, Supply Chain Management oder Supplier Relationship Management integriert.

Eine große Herausforderung an ERP Systeme ist die Konfigurierbarkeit und Anpassbarkeit an die im Unternehmen herrschenden Bedingungen und Anforde- rungen. Zudem sollten allumfassende Systeme modularisiert, aber dennoch hoch integriert aufgebaut sein, was kein Widerspruch sein darf, sondern eine entschei- dende Herausforderung für die Entwickler von ERP Software. Obwohl die meis- ten Hersteller von ERP Systemen diesen Anforderungen Rechnung getragen ha- ben, schrecken gerade die kleinen und mittelständischen Unternehmen vor der An- schaffung eines solch komplexen Systems zurück. Große Unternehmen mit ent- sprechend hohem Umsatz können eine Amortisierung der Lizenz-, Customizing- Kosten und Supportkosten der Software wesentlich schneller erreichen.

2.2 ERP und Open Source

Laut einer ERP-Studie durch das Magazin Infoworld[4] würden 53 Prozent der hier Befragten eine Open Source ERP-Lösung in Erwägung ziehen, wenn sie da- durch den hohen Lizenzkosten entkommen könnten. Die Studie jedoch behauptet, dass kein Open Source ERP-System existiere. Eingehende Recherchen hätten je- doch zum Projekt Compiere geführt, welches über Source Forge² verfügbar ist.

Open Source Lösungen waren bisher weit verbreitet in den Bereichen der Be- triebssysteme (z.B. Linux), Server-Systeme (Apache-Projekt) oder Entwicklungs- umgebungen (Eclipse). Diese Bereiche liegen meist auch fachlich in der Kompe- tenz und im Interesse von Entwicklern, die ihre Arbeitsleistung freiwillig für ein Open Source Projekt zur Verfügung stellen. Zum Teil bietet die so entwickelte Soft- ware ggf. auch einen privaten Nutzen für den Entwickler. Handelt es sich aber um Unternehmenssoftware, so ist der Kreis derer, die sowohl die Fähigkeiten im Be- reich der Softwareentwicklung als auch den notwendigen betriebswirtschaftlichen Hintergrund haben und beides zudem kostenfrei zur Verfügung stellen, wesentlich kleiner[15] Erschwerend kommt hinzu, dass ein ERP-System gesetzlichen Be- stimmungen genügen muss, da es auch für bilanzrechtlich relevante Buchungen verwendet wird. Somit haben Fehlimplementationen wesentlich weiter reichende Auswirkungen als beispielsweise ein abgestürztes Betriebssystem. Zudem müssen im Gegensatz zu den oben genannten Software-Genres bei der Entwicklung von Unternehmenssoftware zahlreiche nationale Kriterien berücksichtigt werden, was sich ebenfalls negativ auf die Zahl der potentiellen Entwickler auswirkt.

Eine Open Source Lösung bietet aber auch große Vorteile, welche nach und nach in der ERP-Welt zu schätzen gelernt werden.

”Das Hauptargument für Open Source-Software ist das sehr flexible Customizing. Closed Source Software ist in aller Regel eine Black Box“[15] Somit ist der Anwender von den eingebauten Customizing Funktionalitäten abhängig oder muss in vielen Fällen auf eine An- passung vom Softwarehersteller selbst warten. Open Source Software hingegen ermöglicht es, Anpassungen direkt am Code vorzunehmen. Solche Änderungen aber sollten dokumentierbar sein und sich bei einem allgemeinen Update oder Re- leasewechsel der Software übernehmen lassen. Da die Open Source Welt jedoch vorsieht, ÄnderungenamCodeallenUsernzurVerfügungzustellen,wirdauf diese Weise die Software ständig erweitert und basiert auf den Erfahrungen un- terschiedlichster Unternehmen. Sofern jeweils die beste Lösung für ein Problem in die Software aufgenommen wird, kann dies letztlich zur Abbildung einer Practice-Lösung“ führen. [15]

Der Einsatz von Open Source im Bereich der Unternehmenssoftware ist al- so ein zweischneidiges Schwert. Eine Entscheidung für oder gegen eine solche L ösung liegt sehr individuell beim jeweiligen Unternehmen begründet. Auch der Vorteil der Lizenzkostenfreiheit relativiert sich sehr schnell, wenn die notwendigen Anpassungen zu umfangreich werden.

”DennOpenSourceistnureineandereArt zu zahlen, und bedeutet nicht, gar nicht zu bezahlen“[16]

2.3 Compiere - Eine Open Source ERP/CRM Software

Mit der Entwicklung von Compiere begann dessen Urheber, Jörg Janke[8] im Ja- nuar 1999. Er richtete sich mit dem Projekt an die Zielgruppe der kleinen und mittelständischen Unternehmen vor allem in den Bereichen Vertrieb und Dienst- leistung. Compiere soll diesen Unternehmen eine lizenzkostenfreie ERP-Software mit integriertem Customer Relationship Management bieten. Die Orientierung an Vertriebs- und Dienstleistungsunternehmen führt jedoch dazu, dass in Compiere die produktionszentrierten Bereiche fehlen, welche die Ursprünge von ERP aus- machen. Jedoch gibt es bereits weiterführende Projekt, die Compiere auch in die- se Richtung erweitern möchten (siehe Ausblick). Dies gilt auch für den Bereich der Personalverwaltung, welcher bis dato nur rudimentär von Compiere unterstützt wird.

Im Verlauf dieser Arbeit soll nun erläutert werden, welches Potenzial Com- piere als Alternative zu kommerziellen ERP-Lösungen wirklich bietet. Neben der Vorstellung der Architektur und der technischen Konzepte sowie der Analyse des Funktiosumfangs wird besonders der Installations- und Konfigurationsaufwand be- trachtet. Diese Analyse soll auf den Erfahrungen basieren, die bei der Realisie- rung von Compiere in einem virtuellen Unternehmen gemacht wurden. Grund- lage des Einsatzszenarios soll ein Wellness-Center sein, dessen Warenwirtschaft und Ressourcenplanung für Dienstleistungsangebote mittels Compiere verwaltet werden sollen. Zusätzlich soll ein Vertrieb vom Wellnessprodukten in das Center integriert sein. Somit kann Compiere anhand beider Adressaten, Dienstleistungs- und Vertriebsunternehmen, untersucht werden. Besonderes Augenmerk aber soll auf den Funktionsbereich ”CustomerRelationshipManagement“inCompierege- legt werden, um zu bewerten, ob diese Software den eigenen Ansprüchen an ein ”vollständigintegriertesCRM-System“[1]gerechtwird.

3 Das Projekt Compiere

Im Vorfeld der Analyse und Bewertung der Software sollen das Projekt und dessen Initiator vorgestellt werden. Das Projekt wurde von Jörg Janke ins Leben geru- fen. Er hat viele Jahre für Hersteller von Unternehmenssoftware gearbeitet[8]. Mit dem Vorsatz, einiges besser zu machen, hat er sich im Januar 1999 entschlossen ei- ne eigene Unternehmenssoftware zu entwickeln. Unterstützung dabei holte er sich von freiwilligen Entwicklern und machte Compiere somit zu einem Open Source Projekt.

Er wollte den Nutzern von integrierter Unternehmenssoftware die Möglichkeit geben, von den Vorteilen quelloffener Software zu profitieren. Dies sind beispiels- weise eine möglichst niedrige finanzielle Eintrittsschwelle in die Nutzung einer ERP-Software und eine größere Kontrolle über die Entwicklung (siehe 2.2 auf Sei- te 5). Durch die Verfügbarkeit des Quelltextes hat der Nutzer die Möglichkeit, die Software nach seinen Bedürfnissen anzupassen und zu erweitern. Somit erhält der Anwender den Vorteil der individuellen Anpassungsmöglichkeit von Individual- software, hat aber geringere Entwicklungskosten, da ein Basissystem bereits vor- handen ist und nur einzelne Komponenten individualisiert werden müssen. Weiter- hin kann man bereits auf die Integration der einzelnen Komponenten zurückgrei- fen.

Compiere wird seit 2001 über die Open Source Plattform Sourceforge verwal- tet. Dort zählt zu den Projekten mit der höchsten Entwickleraktivität und wurde im Februar 2004 zum ”ProjektdesMonats“gekürt³.

”ImGegensatzzuanderenOpensource-ProjektenwirddieEntwicklungvon Compiere jedoch zentral gesteuert“ [7]. Diese zentrale Steuerung geschieht aus Gründen der Qualitäts- und Stabilitätssicherung. So werden alle frei programmier- ten Erweiterungen zunächst von Janke und seinem Entwicklerteam kontrolliert, bevor sie in das ”Core“vonCompiereübernommenwerden.Einsolcheszentrales Qualitätsmanagement ist gerade für Unternehmenssoftware unerlässlich, da dieser Software die Verantwortung für die Unternehmensdaten übertragen wird. Ein Aus- fall der Unternehmenssoftware oder gravierende Fehler bei bilanzrechtlich relevan- ten Buchungen können ein Unternehmen ggf. innerhalb weniger Tage existentiell bedrohen.

Allgemein birgt die Nutzung von Open Source Software im Gegensatz zu kom- merziellen Produkten zudem die Gefahr für den Anwender, dass die Weiterent- wicklung zum einen jederzeit eingestellt werden kann und zum anderen, dass der Anwender unzureichende Unterstützung bei Problemen mit der Software erhält. Diesem Nachteil entgegnet der Compiere Initiator Jörg Janke mit einem umfang- reichen Supportangebot, dass von seinem Unternehmen Compiere Inc. ausgeht. Diese kostenpflichtigen Angebote unterstützen den Anwender in der Einführung, dem Betrieb und der Wartung eines Compiere Systems. Des Weiteren soll dieses Geschäftsmodell ein Garant dafür sein, dass die Entwicklung von Compiere voran- getrieben werden kann, da sich auf diese Weise eine Geldquelle für die Hauptent- wickler bietet. Um den Support und Service flächendeckend anbieten zu können, bemüht sich Compiere Inc. bereits, ein weltweites Partnernetzwerk aufzubauen⁴. Neben Support und Customizing bieten die Compiere Partner Schulungen an. Dies sind entweder Präsenzschulungen oder auch Webseminare bis hin zu individuell nutzbarer Schulungssoftware.

Der Einsatz von Compiere in einem realen Unternehmen begann mit der Ers- tinstallation bei Goodyear Deutschland. Auf der Website des Projektes[1] wird die Vision der Entwickler beschrieben. Compiere soll demnach kein ERP/CRM f ür einen Nischenmarkt sein, sondern eine primäre horizontale, also einen breiten Funktionsbereich abdeckende ERP und CRM Lösung für SMEs⁵ sein. Weiter- hin befindet sich Compiere beispielsweise bei dem französischen Textilhersteller ”PierredeLoyeetCie“imEinsatz.DortwurdeeinSystemvonNixdorfdurch Compiere ersetzt. Sogar in einem belgischen Krankenhauszentrum mit[1000] Mit- arbeitern und[120] Ärzten wird Compiere eingesetzt.[17] Wie im Verlauf der Arbeit beschrieben wird, hat Compiere eine sehr solide Ar- chitektur aber Schwächen im Funktionsumfang. Diesen Umstand nutzt das Soft- wareunternehmen Wilken mit seiner Lösung ”Openshop“aus,dieaufdieBasis von Compiere aufsetzt und zahlreiche Erweiterungen bietet. Ein Blick auf die Re- ferenzliste von Openshop⁶ zeigt, dass auch große Unternehmen wie Schlecker, Veltins oder Neckermann von der Compiere Entwicklung profitieren.

4 Architektur und verwendete Technologien

Dieser Abschnitt beschreibt die von Compiere verwendeten Konzepte aus technischer Sicht. Neben der Architektur wird besonderes Augenmerk auf die Datenspeicherung gelegt, da gerade die Entwicklungen im Bereich der Datenbankmanagementsysteme einen wichtigen Aspekt für einen potentiellen Compiere Nutzer darstellen dürfte. Grundlage des Kapitels sind die Ausführungen des technologischen ÜberblicksaufderWebseitevonCompiere[1].

Compiere wurde vollständig in der Programmiersprache Java entwickelt. Diese bietet den Vorteil der Plattformunabhängikeit und macht Compiere somit ohne wei- teres in heterogenen Systemlandschaften nutzbar. Als Server wird neben dem An- wendungsserver JBoss⁷ ein Tomcat-Webserver⁸ eingesetzt, der es erlaubt, mittels Java Server Pages (JSP)⁹ auch über einen Webbrowser auf Compiere zuzugrei- fen. Der Java-Client verbindet sich mit dem Server über JDBC¹⁰. Für die Spei- cherung der Daten ist eine Relationales Datenbankmanagementsystem (RDBMS) zuständig.

4.1 Prozess- und modellgetriebene Softwarearchitektur in Compiere

Im Gegensatz zu Software, die, abgestimmt auf den jeweiligen Funktionsbereich bzw. die Organisationsstruktur eines Unternehmens, modular aufgebaut ist, wird in Compiere eine Architektur angestrebt, die sich am Workflow eines Geschäftsprozesses orientiert. Somit wird eine Integration der Daten- und Anwendungsmodule entlang der Wertschöpfungskette geboten.

”DieinterneLogikiststrenganGeschäftsprozessenausgerichtet.Eskrempeltda- bei die traditionelle Logik und Begriffswelt modularer Business-Software um. Wer das System einsetzt, muss sich also unter Umständen auch vom gewohnten Organi- sationsmodell seines Unternehmens verabschieden.“ [10] Dies kann zum einen ein Nachteil sein, wenn die bisherige Organisationsstruktur des Unternehmens das Er- gebnis eines langen, durchdachten und vielleicht auch teuren Entwicklungsprozes- ses war. Jedoch könnte gerade eine Anpassung der Organisationsstruktur an eine Software zu einem eher positiven Ergebnis führen. Da mittelständische Unterneh- men häufig mehr mit dem Tagesgeschäft beschäftigt sind, als Ressourcen in organi- satorische Fragestellungen zu investieren, kann die Erfahrung, die im Rahmen der

”Entwicklunggeschichte“ineineUnternehmenssoftwaregeflossenist,demeinset- zenden Unternehmen zu Gute kommen.

Das obige Zitat steht unter der Überschrift

”EinprofessionellerAnsatz“und untermauert somit die Aussage der Compiere-Entwickler hinsichtlich der Fort- schrittlichkeit ihres Architekturansatzes. Die Ausrichtung auf Prozesse entspricht dem Gedanken daran, dass gerade in SMEs, also der Compiere-Zielgruppe, ein Mitarbeiter für einen gesamten Prozesszyklus verantwortlich ist. Dies wirkt sich auch als Vorteil auf die Pflege der Kundenbeziehung aus, da ein Mitarbeiter für alle Aspekte einer einzelnen Geschäftsbeziehung entlang der primären Aktivitäten der gesamten Wertschöpfungskette zuständig ist. So kann ein einzelner Mitarbei- ter einen Kunden von der Erstellung des Angebots bis hin zur Rechnungsstellung und daran anschließenden Serviceaktivitäten betreuen. Die Entscheidung für eine prozesszentrierte Architektur legt somit den Grundstein für ein CRM-Konzept.

Die Wertekette wird in Compiere in zwei Hauptprozesse, von der Angebotserstellung bis zum Zahlungseingang, und ”Quotetocash“,also ”RequisitiontoPay“, also vom Bedarf zur Bezahlung, aufgeteilt. ”Quotetocash“stehtalsdemKun- den entgegen gerichteter Prozess in engem Zusammenhang mit dem CRM Ansatz.

”RequisitiontoPay“hingegenstehtganzimZeichendesSupplyChainManage- ments.

Die Prozessorientierung in Compiere spiegelt sich teilweise auch in der Menüstruk- tur wieder, die hierarchisch aufgebaut ist und auf deren oberster Stufe die genann- ten Hauptprozesse angeordnet sind. Allerdings ist die prozessorientierte Ausrich- tung der Menüstruktur nicht direkt nachvollziehbar. Während sich die Rechnungs- erstellung noch im ”Quotetocash“Menübefindet,suchtmanz.B.dieZahlungsein- gangskontrolle oder das Mahnwesen dort vergebens, diese finden sich in anderen Menüs wieder, obwohl sie eigentlich zum Prozess einer vollständigen Auftragsabwicklung dazu gehören sollten.

Um auf unterschiedliche Belange der Compiere-Nutzer reagieren zu können, gibt es die Möglichkeit, existierende Workflows zu editieren oder auch neue zu erstellen. Workflows geben dem Anwender Hilfestellung beim Ablauf eines be- stimmten Prozesses und führen ihn durch die einzelnen Schritte. Weiterhin gibt es automatisierte Prozesse, die manuell oder zeitgesteuert angestoßen werden.

Neben dem prozessorientierten Ansatz basiert Compiere auf einer Model Dri- ven Architecture (MDA). Diese beiden Architekturansätze schließen sich nicht aus, sondern ergänzen sich. Die Model Driven Architecture wird ebenfalls von der Object Management Group (OMG) vorangetrieben und forciert die Trennung der Business und Anwendungslogik von der darunter liegenden Plattformtechno- logie. Auf lange Sicht hin soll es mit der MDA möglich sein, Software vollständig aus Modellen zu generieren, was den Vorteil erhöhter Flexibilität und stark verein- fachter Wartbarkeit mit sich bringt. Vertiefende Informationen zum MDA-Konzept finden sich bei der OMG¹¹ Die Erkenntnis, dass Compiere auf einer MDA basiert, stammt aus einer Überblickspräsentation zu Compiere[12], die von Jörg Janke selbst erstellt wurde. Hier finden sich einige Abbildungen zur modellgetriebenen Entwicklung und der Hinweis, dass diese sich an den Vorgaben der bereits erwähn- ten Object Modelling Group orientieren.

Auch bei der Betrachtung der Prozesskonfiguration in Compiere können die MDA-Ansätze erkannt werden. Hier soll der Anwender ein Prozessmodell bzw. das Modell eines Workflows im Workfloweditor erstellen und den Prozess überneh- men, ohne selbst am Code zu arbeiten. Somit wird aus einem Modell ein ausführ- barer Anwendungsprozess.

Die Konfiguration von Workflows und automatisierten Prozessen bzw. deren Erstellung ist allerdings schwer zu durchschauen und benötigt viel Einarbeitungs- zeit. Ein reines Vorgehen nach der Trial-and-Error Methode ist jedoch wenig Erfolg versprechend, so dass der Anwender für solche Aufgaben beinahe gezwungen ist, sich um kostenpflichtige Hilfe zu bemühen oder eine Schulung zu besuchen. Denn auch die kommerzielle Anwenderdokumentation hilft in diesem Punkt nicht wei- ter.

Es bleibt also sehr zu hoffen, dass zukünftige Versionen der Dokumentation die Vorgehensweise zur Workflowerstellung anwenderfreundlich beschreiben und dass die Entwicklung von Compiere sich gerade diesem Bereich stärker widmet und dem Anwender im Idealfall einen grafischen Workflow-Editor zu Verfügung stellt. Denn nur auf diese Weise können die Vorteile der Prozesszentriertheit und die der Modellgetriebenheit wirklich ausgenutzt werden.

Ein großer Fortschritt in diesem Bereich ist die Aussage der Compiere-Entwickler sich laut[11] in Zukunft an die ”OMGWorkflowManagementfacility“¹² zuhal- ten. Dabei handelt es sich um ein Framework der Object Modelling Group (OMG), das die Workflowbeschreibungen vereinheitlichen soll, um diese zwischen unterschiedlichen Softwareprodukten austauschbar zu machen. Das Ganze geschieht unter der Regie der Workflow Management Group (WfMC).

Die Abbildung zeigt die Struktur des Workflowmanagements. Allerdings sind die beiden Input-Schnittstellen Scanner/Digital Sender und E-Mail voraussgegriffen. Vor allem eintreffende E-Mails können nicht von Compiere verarbeitet werden. Zwar kann ein Mail-Konto im Setup angegeben werden, aber der Import von Mails aus dem angegebenen IMAP-Konto wurde nicht durchgeführt. Somit ist es notwendig eine externe E-Mail Lösung zu verwenden, was gearde im Hinblick auf ein CRM-Konzept ein großes Defizit darstellt.

4.2 Benutzerinteraktion

Compiere bietet dem Endanwender zwei unterschiedliche Möglichkeiten auf das System zuzugreifen. Einerseits einen Java Client und andererseits den Zugriff über ein Web-GUI welches mit einem Webserver kommuniziert. Durch die direkte An-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Workflow in Compiere (Quelle:[1] )

bindung an Datenbank und Anwendungsserver bietet der Java Client eine bessere Performance als der HTML-Client mit Umweg über den Webserver. Abbildung 2 zeigt den Aufbau der Client Server Architektur.

F ür die Nutzung von Compiere über den Java-Client wird als Vorraussetzung eine Bandbreite von 128 kbit/s der Netzwerkverbindung als ausreichend ange- geben. Wie jedoch die Erfahrungen im Verlauf dieser Arbeit gezeigt haben, ist dies eher eine optimistische Schätzung. Um effizient mit dem System arbeiten zu k önnen, sollte für die Nutzung des Java-Client eine weitaus schnellere Verbindung verwendet werden. Wie in der Abbildung 2 auf der nächsten Seite zu sehen ist, wird über einen HTML Client und das Protokoll HTTPS auf das Compiere System zu- gegriffen. Dabei werden über den Einsatz von Java Server Pages und Java Servlets auf dem Tomcat Webserver Anfragen des Clients entgegengenommen und an den Anwendungsserver übermittelt. Der wiederum generiert die angeforderte Ansicht unter Berücksichtigung der Konfiguration des Active Data Dictionary und füllt sie

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Client Server Architektur (Quelle:[1] )

mit den angeforderten Daten aus der Datenbank. Diese Informationen werden vom Tomcat-Server zu einer HTML-Seite umgesetzt und an den HTML-Client zurück- gesendet.

Die Nutzung des HTML-Client erzeugt im Gegensatz zum Java-Client einen gewissen Overhead, was die Performance stark mindert. Seine Vorteile liegen aber im Bereich des Deployments der Software gegenüber Kunden und Geschäftspart- ner und dem damit verbundenen Sicherheitsbedürfnis. Der HTML-Client eignet sich somit hauptsächlich als Zugangsinstrument im Rahmen ”Customer(bzw.Sup- plier) Self Service“ Funktionalitäten. Dieser Aspekt wird im Zuge der CRM Eva- luierung nähere Betrachtung finden.

Ein Vorteil des HTML-Clients ist, wie bereits erwähnt, der erhöhte Sicherheits- aspekt, was ihn für den Einsatz über die Unternehmensgrenzen hinweg prädesti- niert. Zum einen wird zwischen Browser und Webserver eine SSL-verschlüsselte Verbindung aufgebaut, welches die Datenübertragung selbst absichert. Für die Da- tenübertragung bei der Verwendung des Java-Client jedoch müssen zusätzliche Si- cherungsmaßnahmen wie z.B. ein virtuelles privates Netzwerk (VPN) verwendet werden, da JDBC und JNP Anfragen von Hause aus unverschlüsselt sind. Zum anderen erfordert der HTML-Client nur die Sichtbarkeit des Web-Servers nach

außen hin, was Anwendungs- und Datenbankserver selbst vor unbefugtem Zugriff von außen schützt. Wird jedoch über den Java-Client eine Verbindung zum Compiere System aufgebaut, so muss die Möglichkeit des direkten Zugriffs auf Anwendungs- und Datenbankserver gegeben sein. Sollte also beispielsweise einem Außendienstmitarbeiter die Möglichkeit eingeräumt werden, außerhalb des Unternehmensnetztwerkes mittels Java Client auf Compiere zuzugreifen, sind weitgehende Sicherungsmaßnahmen zu ergreifen.

Da Compiere aber gerade für verteilte Standorte nutzbar sein soll, ist die Nutzung des HTML-Clients für die tägliche Arbeit keine Alternative zum Java-Client. Aufgrund der beschriebenen Nachteile bezüglich der Sicherheit ist eine sichere Vernetzung der Standorte sehr wichtig. Da aber gerade für mittelständische Unternehmen der Compiere-Zielgruppe der Kostenfaktor einer Vernetzung eine große Rolle spielt, besteht die Gefahr der voreiligen unsicheren Verbindung über günstige breitbandige Internetzugänge. Hier sollten auf jeden Fall gründliche Überlegungen zur Absicherung beispielsweise via VPN gemacht werden.

Eine solche Absicherung ist auch dann notwenig, wenn User an unterschiedlichen Standorten nicht auf das zentrale System zugreifen, sondern auf eine lokal vorge- haltene Compiere Instanz. Diese muss jedoch in definierten Zeitabständen mit dem Hauptsystem synchronisiert werden. Dazu bietet Compiere eine Replikationsfunk- tionalität an, für die aber auch eine sichere Netzwerkverbindung notwendig ist.

4.2.1 Compiere Mobil

Nachdem Compiere bereits einen plattformunabhängigen Zugang anbietet, liegt der Gedanke nahe, ob auch ein mobiler Einsatz von Compiere möglich ist. Denn gerade Dienstleistungs- und Vertriebsunternehmen setzen häufig Außendienstmitarbeiter ein, die vor Ort beim Kunden oder auch Lieferanten die Möglichkeit haben sollten, auf Unternehmensdaten zuzugreifen.

Bei der Betrachtung beider Zugriffsmöglichkeiten, sollte sich beim Einsatz ei- nes Notebooks im Hinblick auf die GUIs kein Problem ergeben. Der Java-Client m üsste wohl für Endgeräte wie PDAs oder Smartphones stark angepasst werden und sein Ressourcenbedarf könnte schnell die Grenzen dieser Devices sprengen. Der HTML Client könnte jedoch recht gut nutzbar sein.

Das Hauptproblem jedoch liegt darin, dass es nur schwer möglich ist, einen Offline Client zu nutzen. Dies würde die redundante Installation des zentralen Compiere Systems inkl. Datenbank auf dem Client erfordern. Ein Datenabgleich kann zwar mit der genannten Replikationsfunktionalität geschehen, doch können die Daten jeweils nur auf Tabellenebene selektiert werden. Es ist nicht möglich, beispielsweise einzelne für den Außendienstmitarbeiter relevante Kunden oder Pro- dukte zu synchronisieren. Auf einem Notebook ist das Vorhalten eines vollständi- gen Systems mit Anwendungs- und Datenbankserver noch möglich, aber auf End- geräten wie PDAs scheidet eine Offline-Datenverarbeitung aus. PDAs oder Smart- phones müssen also eine direkte Verbindung via GPRS oder besser UMTS zum zentralen System aufnehmen. Die Einbindung mobiler Endgeräte als Inhouse-Lösung, z.B. via Wireless-LAN in Bereichen wie der Lagerverwaltung oder im Produkti- onsumfeld, könnte eine einfach zu realisierende Lösung darstellen. Wie auf[1]beschrieben, ist die Einbindung für mobile Nutzer bereits geplant. In welchem Um- fang dies geschieht und ob damit auch Offline-Clients möglich sind, bleibt leider ungewiss.

4.3 Application Service Provider

ASPs können Compiere zentral als Anwendung für mehrere Unternehmen über das Internet zur Verfügung stellen. Eine Compiere Instanz kann mehrer Clients verwalten, die sich Anwendungs- und Datenbank Server teilen. Die Daten und Konfigurationen aber bleiben voneinander unabhängig. Diese Fähigkeit von Compiere erlaubt es, den Systembetrieb als Outsourcing-Projekt zu betreiben. Dies ist gerade f ür Unternehmen, deren Kernkompetenz nicht in der Informationstechnik liegt ein Vorteil. Sie können die Konfiguration, Wartung und Pflege ihrer Unternehemenssoftware somit an einen Dienstleister übergeben.

Auf diese Weise muss der Anwender sich nicht selbst um Bugfixes, Updates oder Backupstrategien kümmern.

[...]

¹ SAP - größter Hersteller von ERP-Software (http://www.sap.de)

² Source Forge ist eines der größten Open Source Entwicklungsportale mit einem sehr umfangreichen Open Source Code Repository und frei verfügbaren Anwendungen (http://www.sourceforge.net)

³ https://sourceforge.net/potm/potm-2004-02.php

⁴ siehe http://www.compiere.org/aboutus/index.html

⁵ SME - Small an Medium Sized Enterprises

⁶ http://www.openshop.de/impressionen/referenzen.html

⁷ siehe 9.2 auf Seite 67

⁸ siehe 9.2 auf Seite 66

⁹ siehe 9.2 auf Seite 67

¹⁰ siehe 9.2 auf Seite 68

¹¹ http://www.omg.org

¹² http://www.omg.org/docs/formal/00-05-02.pdf