ERP-Anwender freuen sich über günstige Preise von Open-Source-Software (OSS) - aber kann ERP tatsächlich auf Basis von quelloffener Software funktionieren? ZDNet gibt einen Überblick über Anbieter und Konzepte.
Das grundsätzliche Interesse an Open Source bei Anwendern ist enorm. Laut Gartner erwägen zwölf Prozent der Unternehmen, die sich mit Open-Source-Software (OSS) beschäftigen, auch deren Einsatz für Enterprise Resource Planning (ERP). Doch erwägen heißt noch lange nicht benutzen.
Allerdings gibt es bereits Open-Source-ERP-Projekte in Anwenderunternehmen. Laut Forrester handelt es sich dabei oft um kleine Unternehmen, denen der vorgefundene Funktionsumfang reicht und die vor allem wegen des günstigen Preises zur OSS greifen - genauer gesagt, weil sie kostenlos aus dem Netz geladen werden kann.
Bei größeren Unternehmen kann OSS mit seinen Preisen dagegen kaum punkten. Angesichts des Aufwands für den Auswahlprozess, Implementierung, Schulung und Wartung fallen die Anschaffungskosten kaum ins Gewicht. Insofern unterscheidet sich auch das Open-Souce-Geschäftsmodell wenig von denen der herkömmlichen Anbieter. Auch SAP erwirtschaftet rund 40 Prozent des Umsatzes mit Wartung.
Auf das größte Interesse stößt Open Source aber bei Unternehmen mit ausgeprägtem Programmier-Know-how im eigenen Hause. Das sind zum einen Dienstleister, die die ERP-Halbfertigware in ERP-Projekten für Kunden nutzen, um das Rad nicht immer neu erfinden zu müssen. Zum anderen sind es Anwenderunternehmen, die aufgrund ihrer Branche einen extrem hohen Anpassungsaufwand treiben. Bei Software, die im Sourcecode vorliegt, ist das für Dienstleister wie Anwenderunternehmen naturgemäß einfacher, als wenn man einen Hersteller bitten müsste, proprietären Code umzuschreiben. Das gilt insbesondere, wenn der Anwender ein kleiner Mittelständler und der Lieferant ein Weltkonzern wie SAP ist.
Allerdings nimmt die Notwendigkeit von Eigenentwicklungen in dem Maße ab, in dem modulare ERP-Konzepte wie SOA dafür sorgen, dass auch proprietäre Systeme leicht an unterschiedlichste Bedürfnisse anpassbar sind. Es ist eine Rechenaufgabe herauszufinden, ob eine geringfügige Erweiterung eines Standardpakets teurer oder günstiger kommt als die einfachere, aber umfänglichere Entwicklung von Open-Source-Funktionen.
Wer sich auf den Ausbau von halbfertiger Open-Software zu einem funktionsfähigen ERP-System einlässt, gewinnt an Flexibilität und Kontrolle über die eigene Anwendung. Er steht aber auch vor der Aufgabe, seine Änderungen in einer Weise zu dokumentieren, dass er sie etwa bei einem Release-Wechsel nachvollziehen kann. Wer das nicht tut, schafft sich über kurz oder lang einen nicht mehr wartbaren Code.
Zu den größten Hindernissen für OSS im ERP-Umfeld gehört, dass betriebswirtschaftliche Funktionen als so wichtig gelten, dass man nicht möchte, dass ein Mitbewerber sie kennt. Daher schrecken Anwenderunternehmen davor zurück, wie in die General Public License (GPL) gefordert, Änderungen am offenen Quellcode an die Open-Source-Gemeinde zurückzugeben. Deshalb werden die Anwender und ERP-Anbieter versuchen, die GPL zu umgehen und auf andere Open-Source-Lizenzregeln auszuweichen. Am klarsten zeigt sich die Haltung vieler Anbieter zu Open Source im Konzept des britischen ERP-Konzerns Sage. Dort wurde mit Bäurer Open Access (BOA) eine Integrationsplattform geschaffen, in die sich hauseigene Komponenten wie Bäurer Industry, Bäurer Trade oder Sage CRM einklinken lassen. Zudem ist vorgesehen, dass sich Drittanbieter in die Plattform einkaufen können, etwa Teccom, das einen Katalog für Autoteile eingebunden hat. Die nötigen Schnittstellen mögen auf Web-Services oder SOA-Konzepten beruhen, frei zugänglich sind sie deshalb noch lange nicht. Offen sind dagegen die Schnittstellen zur Infrastruktur. Auf diese Weise lassen sich Java-Clients und Webbrowser als Clients nutzen, Apache als Applikationsserver und My SQL als Datenbank. Einbinden lassen sind aber auch die proprietären Alternativen von Microsoft, IBM oder Oracle. Die BOA-Development-Tools beruhen auf dem Open-Source-Framework Eclipse, sind aber selbst proprietär.
Tatsächlich beschränkt sich das Open-Source-Konzept darauf, Eclipse-Kennern eine gewohnte, aber mitnichten quelloffene Entwicklungsumgebung für ein weitgehend proprietäres ERP-System zu verkaufen. Wo offene Standards genutzt werden, dienen sie entweder dazu, die Kosten des ERP-Anbieters für die Schnittstellen-Entwicklung zu Datenbank und Betriebssystem zu senken oder sich ein Geschäftsmodell für Web-Services von Drittanbietern zu erschließen.
Hinter dieser Art des Umgangs mit Open Source steckt die berechtigte Befürchtung, dass quelloffene Software die Lizenzumsätze gefährdet. Je größer das Unternehmen und je höher die Erwartungen der Börse, desto mehr wächst das Sicherheitsbedürfnis. Konzerne wie SAP oder Microsoft werden sich mit den daraus entstehenden proprietären Konzepten vermutlich durchsetzen können. Sie fühlen sich schon von offenen Standards bedroht, die wie SOA oder Java nichts mit Open Source zu tun haben, und betten sie daher in mehr oder weniger proprietäre Plattformen ein. Dieses Konzept mag bei Marktführern wie SAP aufgehen. Bei den aus vielen Aufkäufen zusammengewürfelten Konzernen für mittelständische Software wie Infor oder Sage sind Zweifel angebracht, ob sie eigene Standards setzen können. Mittelständische ERP-Häuser dagegen tun gut daran, Alternativen zu proprietären Konzepten zu entwickeln.
Ein gutes Beispiel bietet hier Godesys. Dessen eben angekündigte Entwicklungsplattform setzt sich nicht nur aus Open-Source-Komponenten zusammen, sondern wird auch im Quellcode kostenlos abgegeben. Die mit der Plattform entstehenden ERP-Komponenten oder Services lassen sich dann technisch leicht in die Godesys-Umgebungen einbinden. Ob die Integration auch betriebswirtschaftlicher Funktionen einigermaßen reibungslos gelingt, hängt stark von der Tauglichkeit der SOA-Standards und deren Umsetzung in den Unternehmen ab. Ziel von Godesys ist es, über Open-Source-Marketing und dem Versprechen einfacher Diensteintegration Entwickler und Anwender auf die Godesys-Plattform zu locken. Dabei nimmt das Unternehmen anders als etwa Sage oder SAP in Kauf, dass der Umsatz mit dem Verkauf eigener ERP-Komponenten zurückgeht, und hofft, dass der Anteil am Service-Geschäft steigt.
Godesys wird damit noch längst nicht zur Open-Source-Company. Firmengründer Godelef Kühl versteht sich nach wie vor als Anbieter betriebswirtschaftlicher Software, also von in Technik implementiertem (Geschäfts- und Branchen-)Know-how. So müssen die mit der neuen Open-Source-Plattform entwickelten ERP-Komponenten ihrerseits keineswegs quelloffen sein. Entsprechend soll es kostenlose Basis-Dienste im Open-Source-Modell geben, darüber hinausgehende Funktionalität aber wird herkömmlich angeboten und bepreist. Das könnte langfristig zur Folge haben, dass Godesys-Betriebswirtschaft in einer offenen und geschlossenen Variante angeboten wird, wie das etwa bei der My-SQL-Datenbank der Fall ist. Es könnte aber auch auf ein weit serviceorientierteres Konzept hinauslaufen. Schließlich spricht derzeit wieder alle Welt von "Software as a Service" (Saas) - einem unter dem Kürze ASP bereits einmal gescheiterten Konzept.
Kühl gibt sich abwartend und will sich beim Geschäftsmodell an den Marktentwicklungen orientieren. Generell geht er davon aus, dass sich ein gemischtes Verfahren etabliert - auch weil die Kunden Open Source in geschäftskritischen und konkurrenzwichtigen Bereichen nicht akzeptieren würden. Zudem sei die Haftung für Fehler in OSS nicht immer geklärt.
Auch wenn Godesys deutlich weiter geht als Sage, wird auch hier OSS vor allem aus Marketing- und Standardisierungsgründen geschätzt. Anders als SAP oder Microsoft sehen mittelständische Anbieter keine Chance, eigene Standards à la Netweaver oder Dotcom setzen zu können. Angesichts des anhaltenden Konzentrationsprozesses, sehen viele ihre Überlebenschance in der Nutzung offener Standards, mit denen sich Entwicklungskosten sparen lassen und die Kooperationen mit bisherigen Konkurrenten ermöglichen. SOA etwa eröffnet die Perspektive, als Dienste-Lieferant in Saas-Umgebungen zu reüssieren. Der Wettbewerb läuft dort - aber zum Teil schon jetzt - über betriebswirtschaftliches Know-how, Branchenkenntnisse, Servicequalität und generell über Kundenzufriedenheit.
Konkurrenz von reinen Open-Source-Anbietern brauchen angestammte ERP-Anbieter kaum zu fürchten - auch wenn es inzwischen Produkte wie Sugar CRM, Compière, Tiny ERP, Gnu Cash oder Openbravo im Einsatz sind. Doch die globale Open-Source-Entwicklergemeinde tut sich aus mehreren Gründen mit ERP-Projekten schwer.
Die Community hat sich bislang schwerpunktmäßig mit Betriebssystemen, Datenbanken und Entwicklungswerkzeugen befasst, so dass es schlicht an Programmierern fehlt, die über fundiertes betriebswirtschaftliches Know-how verfügen. Der Mangel verschärft sich dadurch, dass viele ERP-Funktionen sich wegen gesetzlicher Regeln von Land zu Land unterscheiden, so dass Entwickler aus dem Ausland keine Hilfe bieten können. Anders als bei Infrastruktursoftware ist zudem die Zahl der potenziellen Nutzer vergleichsweise gering. Sie beschränkt sich auf Unternehmenskunden, die zudem häufig schon auf Jahre an eine ERP-Software gebunden sind.
Schließlich hat jede Branche zu Branche ganz eigene Anforderungen. ERP-Entwicklung verlangt daher eine hohe Spezialisierungsbereitschaft und großes Durchhaltevermögen. So brauchen auch etablierte Anbieter in der Regel Jahrzehnte, bis sie ein komplettes Funktionspaket vorweisen können. Innovativen Open-Source-Entwicklern sagt man dagegen nach, dass sie gerne von einem Projekt auf ein neues wechseln, wenn es spannender erscheint. Zurückbleibt dann bestenfalls Halbfertigware.
Für Anwenderunternehmen bedeutet derartige Sprunghaftigkeit einen eklatanten Mangel an Investitionssicherheit. Zudem bestehen Unternehmenskunden in der Regel darauf, einen Lieferanten zu haben, den man für Fehler etwa in der Lohnbuchhaltungssoftware haftbar machen kann - möglichst über Jahrzehnte hinweg. Ein umfassendes, weltweit funktionierendes Open-Source-ERP-Paket ist daher auf absehbare Zeit nicht zu erwarten - außer, ein etablierter Softwarekonzern stellt sich dauerhaft hinter ein Projekt.
Einen langer Atem beim Hersteller verlangt zudem die Behebung des Hauptmangels offener ERP-Software bei Funktionsvielfalt und Funktionstiefe. Av ERP (von Synerpy) fehlt es laut Arno Schambach von Softselect an einer Finanzbuchhaltung, Tiny ERP hat noch keine Buchhaltung, und die ASP-Software Compiere ist nur auf Provider-Ebene Open Source - und selbst dort auf die lizenzpflichtige Oracle-Datenbank angewiesen. Außerdem mangelt es der schon 1999 entwickelten Software an Funktionen für den Fertigungsbereich.
Diese Argumentation geht allerdings von ERP in Form von Modulpaketen aus. Sollte sich das Konzept von serviceorientierten Architekturen (SOA) im ERP-Umfeld etablieren, entstünden weit feinkörnigere Funktionen, die sich als Service in offene Plattformen einbinden ließen. Die begrenzte Aufgabe der Entwicklung solcher Services könnte Open-Source-Entwickler durchaus locken. Außerdem lassen sich solche Services durchaus von ERP-Anbietern als Lockmittel nutzen, wie das Godesys vorhat. Insofern könnte sich SOA zur Triebfeder für zumindest teilweise offene ERP-Software entwickeln.
Insgesamt ergibt sich das Bild, dass der Markt für genuine Open-Source-ERP-Software sich auf die wenigen Unternehmen beschränkt, die großen Anpassungsaufwand machen müssen. Sieht man in Open Source vor allem einen Werkzeugkasten voller offener Standards, so lassen sich diese von ERP-Anbietern, Dienstleistern und Anwendern für mehr Flexibilität und Unabhängigkeit zu niedrigen Preisen nutzen. Zudem steckt in serviceorientierten Architekturen das Potenzial für neue Geschäfts- und Nutzungsmodelle wie Saas, mit den genannten Vorteilen für Anbieter und Kunden. Open Source hat damit aber nur insofern zu tun, als sie einen Teil der offenen Standards liefert, die man für solche Architekturen braucht. Außerdem spielt Open Source eine ähnlich wichtige Rolle beim Produktmarketing, wie die kostenlosen Dienste auf Webseiten. Sie locken den Interessenten zum Anbieter und führen schnurstracks zu kostenpflichtigen Angeboten, sobald etwas mehr als die Basisfunktion benötigt wird.