Diese induktive Untersuchung evaluiert das Potenzial von Open Source ERP-Software anhand eines prototypisch modellierten Entscheidungsszenarios, bei dem die Anschaffung eines Neusystems aufgrund eines veralteten bestehenden Systems zur Debatte steht. Die technische Evaluierung erfolgt anhand praktischer Testung zweier ERP-Systeme, Microsoft Dynamics NAV und OpenERP. Neben der Grundkonfiguration wird auch die Abwicklung eines Geschäftsfalles anhand eines exemplarischen Beschaffungsprozesses simuliert und bewertet. Die wirtschaftliche Evaluierung basiert auf zwei Modellen, einem Prozesskostenmodell und einem Total Cost of Ownership-Szenariomodell. Das Prozesskostenmodell greift auf verfügbare Informationen zu Lizenzen und Kosten von Microsoft Dynamics NAV zurück. Das TCO-Szenariomodell betrachtet das Modell-Unternehmen als Ganzes und bezieht sich dabei auf empirische Kostenkennzahlen für die Einführung von ERP-Software.

Textprobe: Kapitel 3.5, Lizenzierung von Open Source ERP: ‘Ein besonders oft anzutreffendes Missverständnis ist die Annahme, dass Open Source Software frei von Lizenzbedingungen ist.’ (Fraunhofer, 2006, S. 19) Nach der österreichischen Rechtsvorschrift des Urheberrechtsgesetztes, Abschnitt III, §14-16, besitzt nur der Urheber von bspw. einer Software das Recht auf wirtschaftliche Verwertung, Vervielfältigung sowie Verbreitung der Software (ris.bka.gv.at, 2013). Im Falle von Open Source Software erklärt sich der Urheber dazu bereit, auf eben diese vom Urheberrechtsgesetz eingeräumten Rechte explizit zu verzichten. Um diesen Rechteverzicht zu deklarieren, bedienen sich Open Source Software Anbieter in der Regel einer der sogenannten Open Source Software Lizenzen, wobei ebenso die Möglichkeit besteht, eine eigene Open Source Lizenz zu verfassen. Die Gesamtheit aller verfügbaren Open Source Software Lizenzen ist schwer überschaubar, jedoch haben sich einige Lizenzmodelle etabliert. So führt etwa die Open Source Initiative einen sogenannten Lizenz-Bewertungsprozess durch und überprüft anhand der durch die OSI definierten Anforderungen an Open Source, ob eine Lizenz dem Open Source-Standard entspricht oder nicht. Die von der OSI geprüften und als populär deklarierten Open Source Lizenzen mit großer Verbreitung bzw. starken dahinterstehenden Communities sind folgende (OSI, 2006): - Apache License 2.0. - BSD 3-Clause ‘New’ or ‘Revised’ license. - BSD 2-Clause ‘Simplified’ or ‘FreeBSD’ license. - GNU General Public License (GPL). - GNU Library or ‘Lesser’ General Public License (LGPL). - MIT license (Massachusetts Institute of Technology). - Mozilla Public License 2.0. - Common Development and Distribution License. - Eclipse Public License. Ein wesentliches Unterscheidungskriterium von Open Source Lizenzen ist das sogenannte Copyleft. Bei der Weiterentwicklung von Software, die einer Open Source Lizenz mit Copyleft untersteht, ist eine Fortentwicklung dieser Software unmittelbar der jeweiligen ursprünglichen Lizenz unterstellt. (BITKOM, 2013, S. 11). 3.5.1, Die GNU General Public License (GPL): Die in Verbindung mit Open Source Software am häufigsten verwendete Lizenz ist zweifellos die General Public License (Fraunhofer, 2006, S. 20), welche von Richard Stallman als Grundlage für das im Jahre 1983 gegründete GNU Projekt entworfen wurde. Stallman arbeitete zuvor 13 Jahre für das Massachusetts Institute of Technology und trat aus diesem zeitgleich mit der Gründung des GNU-Projekts aus (Universität Klagenfurt, 2013). Speziell im Bereich der Open Source ERP-Software ist die GPL die am häufigsten vorzufindende Lizenzierungsvariante, wobei einige Hersteller wie bspw. AvERP oder Openbravo eigene Lizenzen einsetzen. Eine Kerneigenschaft der GPL ist, dass eine Veränderung an einer der GPL unterliegenden Software im Falle der Weiterverbreitung wiederum der GPL unterliegen müssen. Damit ist es nicht möglich, Teile von GPL Software in kommerzieller Software zu verwenden und entspricht somit einem Schutz vor Kommerzialisierung des geistigen Eigentums der Open Source Entwickler. (Fraunhofer, 2006, S. 20). 3.5.2, Die GNU Lesser General Public License (LGPL): Die LGPL ist eine von der GPL abgeschwächte Variante mit beschränktem Copyleft und stellt sich zwischen Lizenzen mit strengem Copyleft (bspw. GPL) und Lizenzen ohne jegliches Copyleft (bspw. BSD). Im Gegensatz zur GPL kennt die LGPL die Einschränkung nicht, dass abgeleitete Produkte wiederum derselben Lizenz unterliegen müssen, wenn diese in eigenen Dateien gebunden und unter proprietärer Lizenz verbreitet werden. (BITKOM, 2013, S. 11). Haupteinsatzgebiet der LGPL ist die Lizensierung von Programmbibliotheken, für welche sie speziell entwickelt wurde. Durch die LGPL ist es möglich, eine Programmbibliothek auch in kommerziellen Produkten nutzen zu können, was unter einer GPL-Lizensierung mit strengem Copyleft nicht möglich wäre. (BITKOM, 2013, S. 12). 3.5.3, Die GNU Affero General Public License (AGPL): Die GNU Affero General Public License unterscheidet sich von der GPL durch eine weitere Anforderung. Wird etwa ein Programm unter der GPL auf einem eigenen Server betrieben, auf den auch andere Nutzer Zugriff haben, so ist eine Offenlegung des Quellcodes nach den Anforderungen der GPL nicht erforderlich. Um diese Problematik handhaben zu können, bedient man sich der AGPL. Möchte man ein unter der AGPL lizenziertes Programm auf einem anderen Nutzern zugänglichen Server betreiben, so ist eine Offenlegung des Quellcodes für andere Nutzer zwingend. Ihnen muss die Möglichkeit zum Download des Programmcodes eingeräumt werden. (gnu.org, 2011). 3.5.4, Die Berkeley Software Distribution License (BSD): Die BSD-Lizenz ist im Gegensatz zur GPL eine im Open Source-Bereich eingesetzte Softwarelizenz ohne Copyleft. Der Urtyp der BSD-Lizenzen stammt von der University of California, Berkeley. Daher stammt auch das Akronym BSD, welches für Berkeley Software Distribution steht. Unter der BSD-Lizenz stehender Programmcode kann frei verändert, vervielfältig und verbreitet werden. Einzige Bedingung ist, dass der Copyright-Vermerk des ursprünglichen Programms nicht entfernt werden darf. Die BSD-Lizenz ermöglicht eine weitere Verwendung von Open Source-Programmcode in kommerzieller bzw. teilproprietärer Software. Die Charakteristik dieser Lizenz erfordert eine erneute Lizenzierung des Softwarederivats unter der BSD-Lizenz. Im Gegensatz zur GPL ist aufgrund des fehlenden Copylefts keine Veröffentlichung des Programmcodes erforderlich. (gnu.org, 2013). 3.6, Der Prozess: ‘Ein Prozess ist eine Serie von Handlungen, Tätigkeiten oder Verrichtungen mit einer messbaren Eingabe (Input), einer messbaren Verarbeitung und einer messbaren Ausgabe (Output) in einer sich wiederholenden Folge.’ (Pfitzinger, 2003, S. 9) ERP-Systeme sind wie bereits in Kapitel 3.1.1 beschrieben, modular aufgebaute Software-Lösungen, die eine prozessorientierte Sichtweise auf das Unternehmen und seine Geschäftspartner ermöglichen (Hinterhuber, 2005, S. 3). Das Verständnis für einen Prozess und die Kenntnis über dazugehörige Werkzeuge zur Modellierung und Analyse von Prozessen wird als fundamental für das Verständnis von ERP-Systemen erachtet. Engelhardt-Nowitzki beschreibt einen Prozess in Ergänzung zu Pfitzinger dahingehend, als dass dieser eine integrierte Gesamtheit von Tätigkeiten zur Hervorbringung eines Produktes oder einer Dienstleistung darstellt. Ferner fügt ein Prozess Wert hinzu und muss durch einen definierbaren Prozessbeginn und ein definierbares Prozessende abgegrenzt werden können. Die Verantwortung für einen Prozess liegt bei der Führungskraft. (Engelhardt-Nowitzki, 2013, S. 4). Das Prozessmanagement strebt danach, Prozesse möglichst zu standardisieren. Mit der Standardisierung werden verbindliche Vorgaben zu den von den Prozessen zu liefernden Ergebnissen und zur Vorgehensweise bei der Durchführung der Prozesse festgelegt. Die wesentlichen Vorteile standardisierter Prozesse ergeben sich in folgenden Bereichen (Wilhelm, 2007, S. 58f): - Transparenz zwischen internen Kunden und Lieferanten. - Prozessverständnis & Verantwortlichkeiten der Mitarbeiter. - Leichtere Einarbeitung bei neuen Mitarbeitern. - Sicherung des Prozess-Know-How durch Dokumentation. - Transparenz und Einheitlichkeit zu externen Kunden und Lieferanten. Aus betriebswirtschaftlicher Sicht erfolgt meist eine Kategorisierung nach Führungsprozessen, Leistungsprozessen und Unterstützungsprozessen. Wie der Name besagt, handelt es sich bei Leistungsprozessen um wertschöpfende Prozesse, welche Produkte oder Dienstleistungen für externe Empfänger (Kunden) generieren. Leistungsprozesse werden deshalb auch als Kern- oder Hauptprozesse bezeichnet. Unterstützungsprozesse oder auch Supportprozesse vollbringen interne Leistungen zur Unterstützung von Leistungsprozessen. Die Aufgabe von Führungsprozessen besteht in der Gestaltung, Lenkung und Entwicklung der Prozessarchitektur. (Koch, 2011, S. 8). Um Prozesse darstellen und analysieren zu können, bedient man sich der sogenannten Prozessmodellierung, einer Methode des Prozessmanagements. Prozessmodelle sind Abbildungen von internen oder externen Kunden-Lieferanten-Beziehungen. Detaillierungsgrad und Umfang eines Prozessmodells kann je nach Zielsetzung variieren. Modelle zur Prozessdarstellung nach Koch sind Wertschöpfungskettendiagramm, Flussdiagramm, erweiterte Ereignisgesteuerte Prozesskette (eEPK), Prozesstabellen und objektorientierte Methoden. (Koch, 2011) Jede dieser Methoden besitzt ihre eigene Charakteristik, aus welcher Vor- und Nachteile für die jeweilige Anwendung hervorgehen. Die Anwendung einer Prozessmodellierungsmethode erfordert entsprechende Kenntnisse über die Methode selbst, deren Zweck und Einsatzgebiet, als auch über die Stärken und Schwächen der Methode. Auf eine nähere Erläuterung dieser Methoden wird bewusst verzichtet, da dies nicht im Fokus dieser Fallstudie liegt. Im praktischen Teil dieses Buches kam die Methodik der ereignisgesteuerten Prozesskette (eEPK) zum Einsatz, da diese bereits vertraut war und die Eignung zur Definition von erforderlichen Prozessressourcen als gut befunden wurde. Zudem bestand die Verfügbarkeit der Prozessmodellierungssoftware ARIS Express zur Prozessmodellierung in der eEPK.

• Open Source ERP

• Enterprise Resource Planning

• Kostenstruktur

• Total Cost of Ownership

• Lizenzkosten

Markus Kontschieder, MSc, wurde 1988 in Lienz, Tirol, geboren. Sein Studium der Internationalen Wirtschaftsingenieurswissenschaften an der Fachhochschule Technikum Wien schloss der Autor im Jahre 2013 mit dem akademischen Grad des Master of Science in Engineering ab. Bereits während des Studiums sammelte der Autor umfassende praktische Erfahrungen in der metallverarbeitenden und chemischen Industrie. Sein immerwährendes Interesse an holistischen Betrachtungen und interdisziplinären Ansätzen motivierte den Autor, sich der Thematik des vorliegenden Buches zu widmen.