Evaluation und Implementierung des Open
Werbung
Hochschule Deggendorf für angewandte Wissenschaften -Fachhochschule DeggendorfFakultät Betriebswirtschaft und Wirtschaftsinformatik (Bachelor-Studiengang Wirtschaftsinformatik) Evaluation und Implementierung des Open Source ERP-Systems „OpenERP“ in einem Start-Up-Unternehmen Evaluation and implementation of the open source ERP system „OpenERP“ in a startup company Bachelorarbeit zur Erlangung des akademischen Grades: Bachelor of Science an der Hochschule Deggendorf VORGELEGT VON: PRÜFER: Stefan Feilmeier Prof. Dr. Josef Schneeberger geboren am 8. Juni 1986 Donaulände 19, 94544 Hofkirchen AM: 28. September 2012 Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Kurzfassung Anhand des Start-Up-Unternehmens FENECON GmbH & Co. KG dokumentiert diese Bachelorarbeit die Evaluation und anschließende Implementierung des Open Source ERP-Systems OpenERP. Traditionell waren hochintegrierte Sowaresysteme, sogenannte ERP-Systeme, aufgrund ihrer Komplexität und der hohen Kosten nur Mielständlern und Großunternehmen vorbehalten. Das heißt, dass in diesen Unternehmen mindestens einmal – sobald sie die kritische Größe ür ein ERP-System erreicht haen – eine aufwendige ERP-Sowareimplementierung mit Datenmigration erforderlich war. Diese Projekte bergen neben enormen Kosten auch ein nicht zu verachtendes betriebswirtschaliches Risiko, wie die Insolvenz des Unternehmens American LaFrance1 zeigt. Die Open-Source-Soware „OpenERP“ stellt diesbezüglich eine interessante Alternative dar. Das freie Lizenzmodell ermöglicht es, in einem neu gegründeten Unternehmen mit geringem Budget schon von Beginn an grundlegende Geschäsvorälle in einem ERP-System abzubilden, welches im Laufe der Zeit modular mit dem Unternehmen wachsen kann. Nach einer gründlichen Begriffsdefinition und -abgrenzung sowie einer Abwägung der Sowarealternativen wird das System anhand von betriebswirtschalichen und informationstechnischen Parametern analysiert und die anschließende Implementierung von OpenERP beschrieben. Ein beispielhaer Ablauf „Vertriebsprozess eines LED-Projekts“ und ein abschließendes Resümee runden die Arbeit ab. 1 2 vgl. Computerwoche (ERP-Migration fehlgeschlagen: Mit Blaulicht in die Insolvenz) Inhaltsverzeichnis I. Einleitung 6 1. Zielsetzung und thematischer Aufbau der Arbeit 7 2. Die Firma FENECON GmbH & Co. KG 8 II. Theoretische Grundlagen 9 3. Begriffsdefinition und -abgrenzung 3.1. ERP-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Open-Source- und Closed-Source-Soware . . . . . . . . . . . . . . . . . 3.3. On-Premise-Installation und Soware-as-a-Service . . . . . . . . . . . . 3.4. Abgrenzung von Start-Up-Unternehmen zu anderen Unternehmenstypen 4. Soware zur Steuerung eines Start-Up-Unternehmens 4.1. Anforderungskatalog an ein Sowaresystem . . . . . . . . . . . . . . . 4.1.1. Anforderungskatalog bei Unternehmensgründung . . . . . . . 4.1.2. Zukünige Anforderungen an die Unternehmenssoware der FENECON GmbH & Co. KG . . . . . . . . . . . . . . . . . . . . 4.2. Sowarealternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Office-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Kaufmännische Soware ür Kleinst- und Kleine Unternehmen 4.2.3. Mielstandssoware . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4. Open Source ERP-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 11 13 14 . . . . . . . . 16 16 17 . . . . . . 17 19 19 20 22 23 . . . . . . . . . . . . . . . . . . . . . . . . . . III. Evaluation von OpenERP 5. Funktionalität 5.1. Abdeckung unternehmerischer Funktionsbereiche 5.2. Konkrete Anwendungsälle . . . . . . . . . . . . . 5.2.1. Im Vertrieb . . . . . . . . . . . . . . . . . 5.2.2. In der Buchhaltung . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 29 30 31 3 5.2.3. In der Lagerverwaltung . . . . . 5.3. Anpassung von Geschäsprozessen . . . 5.4. Erweiterungen im „Enterprise App Store“ 5.4.1. Reporting . . . . . . . . . . . . . 5.4.2. E-Business . . . . . . . . . . . . . 5.5. Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 33 35 35 36 36 6. Implementierungsunterstützung und Support 6.1. OpenERP s.a. in Belgien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Dienstleistungspartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Online-Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 38 38 39 7. Systemarchitektur 7.1. Sowarekonzeption . . . . . . . . . . . . . . . . . . . . 7.1.1. Client-Server- und Drei-Schichten-Architektur 7.1.2. Objektrelationaler Mapper . . . . . . . . . . . . 7.1.3. Modularität . . . . . . . . . . . . . . . . . . . . 7.1.4. Mehrbenutzerähigkeit . . . . . . . . . . . . . . 7.1.4.1. Transaktionssicherheit . . . . . . . . 7.1.4.2. Sperrverfahren . . . . . . . . . . . . 7.1.4.3. Berechtigungssystem . . . . . . . . . 7.1.5. Schnistellen . . . . . . . . . . . . . . . . . . . 7.1.5.1. CSV . . . . . . . . . . . . . . . . . . . 7.1.5.2. XML-RPC . . . . . . . . . . . . . . . 7.1.5.3. Direkter Datenbank-Zugriff . . . . . 7.1.5.4. E-Mail-Gateway . . . . . . . . . . . . 7.2. Basistechnologien . . . . . . . . . . . . . . . . . . . . . 7.2.1. Datenbank: PostgreSQL . . . . . . . . . . . . . 7.2.2. Programmiersprache: Python . . . . . . . . . . 7.2.3. Auszeichnungssprache: XML . . . . . . . . . . 7.3. Anpassungs- und Erweiterungstechnologien . . . . . . 7.3.1. Personalisierung und Customizing . . . . . . . 7.3.2. Module . . . . . . . . . . . . . . . . . . . . . . 7.3.3. Modifikation des ellcodes . . . . . . . . . . . 40 40 41 42 42 43 43 44 44 45 45 45 46 47 47 47 48 48 49 50 50 51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV. Implementierung 8. Installation 8.1. Datenbank (PostgreSQL) . . . 8.2. Applikationsserver (OpenERP) 8.3. Reporting (LibreOffice) . . . . 8.4. Client-PCs . . . . . . . . . . . 4 52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 53 54 56 57 9. Vorbereitung zur Inbetriebnahme 9.1. Anpassung des Reportings an das Corporate Design . . . . . . . . . . . . . . . 9.2. Anpassung der Nummernkreise . . . . . . . . . . . . . . . . . . . . . . . . . . 58 59 60 10. Workflow: Vertriebsprozess für ein LED-Projekt 10.1. Angebot und Aurag . . . . . . . . . . . . . . . 10.2. Lieferung . . . . . . . . . . . . . . . . . . . . . . 10.3. Rechnung . . . . . . . . . . . . . . . . . . . . . 10.4. Bezahlung . . . . . . . . . . . . . . . . . . . . . 61 62 64 64 65 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V. Resümee 66 11. Zusammenfassung 66 12. Ausblick 67 VI. Verzeichnisse 68 Literaturverzeichnis 69 Abbildungsverzeichnis 73 Tabellenverzeichnis 75 VII. Anhang 76 A. Die Definition quelloffener Soware („Open Source Soware“) 77 B. OpenERP Startskript (/etc/init.d/openerp-server) 80 C. LibreOffice Startskript (/etc/init.d/libreoffice-headless) 82 D. Rechnungserstellung mit Aeroo Reports D.1. Ausschnie des Report-Parsers (parser.py) . . . . . . . . . . . . . . . . . . . . D.2. LibreOffice-Vorlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 84 84 E. Belege im Vertriebsprozess E.1. Verkaufsaurag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2. Lieferschein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.3. Rechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 87 87 87 5 Teil I. Einleitung Integrierte Sowaresysteme können ein entscheidender Baustein ür langfristig erfolgreiches unternehmerisches Handeln sein. Richtig eingesetzt erhöhen Sie die Effizienz und verringern die Fehleranälligkeit betriebswirtschalicher Prozesse. Das Fraunhofer PMI schreibt dazu in einer Studie: „Nowadays, information technology is unavoidable in every part of life and business management is also not an exception. One of the most widespread solutions is the use of enterprise resource planning (ERP) systems that has proved to support the integration and automation of the processes, the improvement of the performance, and the reduction of costs.“2 Aufgrund der komplexen Einührung und Wartung in Verbindung mit den erheblichen Kosten waren sie aber traditionell nur den großen Konzernen vorbehalten. Seit einigen Jahren versuchen die großen Sowareanbieter neue Absatzmärkte zu erschließen und sprechen daher zunehmend auch mielständische Unternehmen an. Für Unternehmensgründer stellt sich trotzdem weiterhin die Frage, mit welchem System der Geschäsbetrieb gestartet werden soll. Die Studie ergänzt: „Yet, several mostly small and medium enterprises (SME) cannot afford the time, the uncertainty and the resources that are required by the implementation of an ERP system.“3 Diese Arbeit beschäigt sich daher mit der Frage, inwieweit sich ein ERP-System ür StartUp-Unternehmen eignen kann und propagiert die Idee, von Beginn an ein Open Source ERPSystem als Unternehmenssoware ür Start-Up-Unternehmen einzusetzen. 2 3 6 Schatz, Egri und Sauer (Open source ERP - Reasonable tools for manufacturing SMEs?, Seite 7) Schatz, Egri und Sauer (ebd., Seite 7) 1 Kapitel 1. Zielsetzung und thematischer Aufbau der Arbeit Ziel ist, dem neu gegründeten Unternehmen FENECON GmbH & Co. KG von Beginn an die Basisfunktionalitäten einer integrierten Soware zur Verügung zu stellen. Zu den erhoen Vorteilen zählt zum einen, dass bereits ab dem Zeitpunkt der Gründung eine einheitliche Datenbasis zur Verügung steht, mit der Auräge, Kunden- und Artikeldaten, Lagerbestände usw. zentral verwaltet werden können. Darüber hinaus soll das System mit dem Unternehmen wachsen können, um somit eine später notwendige, aufwendige „Operation am offenen Herzen“4 vermeiden zu können. Die Struktur der Arbeit teilt sich konzeptionell in die Abschnie „eoretische Grundlagen“, „Evaluation von OpenERP“ und „Implementierung“. Im Teil „eoretische Grundlagen“ wird das große Feld kaufmännischer Soware, möglicher Lizenzmodelle und unterschiedlicher Unternehmenstypen so weit auf den vorliegenden Fall abgegrenzt und eingeschränkt, dass eine sinnvolle, anforderungsnahe Evaluation ermöglicht wird. Auf dieser Basis werden neben der betriebswirtschalichen Funktionalität im Teil „Evaluation von OpenERP“ auch die externen Supportmöglichkeiten und die Architektur der Soware analysiert. Der Abschni „Implementierung“ stellt schließlich die notwendigen Schrie zur Installation und Inbetriebnahme dar und zeigt beispielha die Abbildung eines Vertriebsprozesses im System. Das „Resümee“ am Ende der Arbeit bietet eine Zusammenfassung und einen Ausblick auf die zukünige Entwicklung von OpenERP. 4 Hoppe (Soware ür den Überblick - Am offenen Herzen) 7 2 Kapitel 2. Die Firma FENECON GmbH & Co. KG Das Start-Up-Unternehmen FENECON GmbH & Co. KG mit Sitz im niederbayerischen Deggendorf wurde vor dem Hintergrund einer politisch und gesellschalich geforderten Energiewende nach den Reaktorunällen in Japan im März 2011 gegründet. Das kleine Team verfolgt die Vision einer „dezentralen Selbst- Abb. 1.: Logo der FENECON GmbH & Co. KG versorgung“ auf den drei Säulen Energieerzeugung, -effizienz und -speicherung. Dabei steht „Energieerzeugung“ ür eine dezentrale, erneuerbare und günstige Stromerzeugung durch Photovoltaik, „Energieeffizienz“ ür die Reduzierung der Stromnachfrage zu Nicht-Sonnenzeiten, vor allem durch LED-Beleuchtung, und „Energiespeicherung“ ür die kurzfristige (Tag/ Nacht) und langfristige (Jahreszeiten) Verteilung von Stromlasten durch Stromspeichersysteme. Für dieses ganzheitliche Konzept, mit dem der Wandel zu einer erneuerbaren und dezentralen Energieversorgung unterstützt werden soll, wurde das Unternehmen im Jahr 2012 mit dem Niederbayerischen Gründerpreis ausgezeichnet. Die Firma FENECON vertreibt ihre Produkte über Mitarbeiter im Außendienst, den eigenen Onlineshop unter www.leds-go-home.de und über die Verkaufsplaform „Amazon Marketplace“ und tri dabei sowohl als Einzel- als auch als Großhändler auf. Außerdem bestehen intensive internationale Geschäsbeziehungen nach China, Bulgarien und in den Senegal. 8 Teil II. Theoretische Grundlagen Im Teil „eoretische Grundlagen“ werden die Hauptbegriffe, die in dieser Arbeit Verwendung finden, definiert und insofern eingeschränkt und abgegrenzt, als dass im darauf folgenden Teil eine sinnvolle und anforderungsnahe Evaluation ermöglicht wird. Eine Abgrenzung ist deshalb erforderlich, weil neben ERP-Systemen verschiedenste Methoden zur IT gestützten Unternehmenssteuerung existieren, die sich bezüglich ihrer Komplexität und Spezialisierung enorm unterscheiden. Einige ausgewählte Alternativen zum ERP-System werden kurz mit ihren jeweiligen Stärken und Schwächen vorgestellt. Darüber hinaus sollen kurz die wesentlichen Eigenschaen, Vor- und Nachteile von Open-Source-Soware dargestellt werden. Um den Rahmen der Bachelorarbeit nicht zu sprengen, ist es außerdem unabdingbar, einige Einschränkungen vorzunehmen. So wird hier davon ausgegangen, dass eine Installation „On-Premise“, also auf einem eigenen Server des Unternehmens, erfolgt, und nicht auf die Dienstleistungen eines Soware-as-a-Service-Anbieters zurückgegriffen wird. Ebenso ist die Arbeit klar auf „Start-Up-Unternehmen“ ausgerichtet, die sich in ihren Anforderungen an ein Sowaresystem deutlich von anderen Unternehmenstypen unterscheiden. 9 3 Kapitel 3. Begriffsdefinition und -abgrenzung 3.1. ERP-System „Ein ERP-System ist eine komplexe Anwendungssoware zur Unterstützung der Ressourcenplanung eines gesamten Unternehmens.“5 So kurz und verständlich erscheint die Definition des Begriffs „ERP-System“ in Wikipedia. Deutlich detaillierter definiert Gablers Wirtschaslexikon: „Ein Enterprise Resource Planning-System oder kurz ERP-System dient der funktionsbereichsübergreifenden Unterstützung sämtlicher in einem Unternehmen ablaufenden Geschäsprozesse. Entsprechend enthält es Module ür die Bereiche Beschaffung, Produktion, Vertrieb, Anlagenwirtscha, Personalwesen, Finanzund Rechnungswesen usw., die über eine (in Form einer relationalen Datenbank realisierte) gemeinsame Datenbasis miteinander verbunden sind. Durch die unternehmensweite Konsolidierung der Daten ist eine Unterstützung der Planung über sämtliche Unternehmensebenen hinweg (von der Konzernebene über verschiedene Werke, Sparten und Abteilungen bis hin zu einzelnen Lagerorten) möglich.“6 Ein ERP-System ist demnach also eine mehrbenutzerähige, an unternehmerischen Geschäsprozessen ausgerichtete Anwendungssoware zur umfassenden, strukturierten Verwaltung der Ressourcen eines Unternehmens auf Basis einer gemeinsamen Datenbank. Diese wesentlichen Punkte sind es auch, die ein ERP-System von den in Abschni 4.2 aufgezählten Sowarealternativen unterscheiden. 5 6 Wikipedia contributors (Enterprise-Resource-Planning) Gabler Wirtschaslexikon (Definition: Enterprise Resource Planning-System) 10 3.2. Open-Source- und Closed-Source-Soware Im Gegensatz zu sogenannter Closed-Source- oder Proprietärer Soware, dazu zählen die gängigen Programme wie z. B. „Microso Office“, deren Nutzung, Neuvertrieb oder Modifizierung untersagt oder stark eingeschränkt ist, bezeichnet „Freie Soware […] Soware, die jedem die Berechtigung gewährt, sie zu nutzen, zu kopieren und/ oder zu verbreiten, entweder unverändert oder mit Modifizierungen, gratis oder gegen ein Entgelt. Im Besonderen bedeutet das, dass der ellcode verügbar sein muss.“7 Die Open Source Initiative (OSI) hat dazu einige Kritierien als verbindliche Merkmale von Open-Souce-Soware8 (OSS) festgelegt.9 Freie Weitergabe: Die Lizenz darf niemanden in seinem Recht einschränken, die Soware als Teil eines Soware-Paketes, das Programme unterschiedlichen Ursprungs enthält, zu verschenken oder zu verkaufen. […] ellcode: Das Programm muss den ellcode beinhalten. […] Abgeleitete Soware: Die Lizenz muss Veränderungen und Derivate zulassen. […] Unversehrtheit des ellcodes des Autors: […] Die Lizenz muss die Weitergabe von Soware, die aus verändertem ellcode entstanden ist, ausdrücklich erlauben. […] Keine Diskriminierung von Personen oder Gruppen: Die Lizenz darf niemanden benachteiligen. Keine Einschränkungen bezüglich des Einsatzfeldes: Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Bereich einzusetzen. […] Weitergabe der Lizenz: Die Rechte an einem Programm müssen auf alle Personen übergehen, die diese Soware erhalten. […] Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein: Die Rechte an dem Programm dürfen nicht davon abhängig sein, ob das Programm Teil eines bestimmten Soware-Paketes ist. […] 7 Free Soware Foundation (Kategorien freier und unfreier Soware) Der Ausdruck „Open-Source-Soware“ wird in dieser Arbeit bewusst synonym zum Begriff „Freie Soware“ im Sinne ihrer eigentlichen, gemeinsamen Bedeutung verwendet. 9 Englische Originalfassung der Open Source Initiative (e Open Source Definition) bzw. deutsche Übersetzung von Ronneburg (Debian GNU/Linux Anwenderhandbuch); Die Beschreibungen sind an dieser Stelle auf das Wesentliche gekürzt. Die vollständige Open Source Definition befindet sich in Anhang A. 8 11 Die Lizenz darf die Weitergabe zusammen mit anderer Soware nicht einschränken: Die Lizenz darf keine Einschränkungen enthalten bezüglich anderer Soware, die zusammen mit der lizenzierten Soware weitergegeben wird. […] Bekannte Beispiele ür Freie Soware, die diese Bedingungen erüllen, sind der Browser „Mozilla Firefox“, die Bürosoware „LibreOffice“ bzw. „OpenOffice“ und die vielen weiteren Anwendungen, die das Rückgrat des Internets bilden, wie z. B. der Webserver „Apache“. Obwohl aus den Kriterien nicht hervorgeht, dass Open-SourceSoware notwendigerweise kostenlos bereitgestellt werden muss, bleibt der bekannteste und offensichtlichste Vorteil ür die Nutzer quelloffener Soware in den meisten Fällen die Einsparung von Lizenzkosten. Doch die umfangreichen Rechte, die dem Nutzer von Open-Source-Soware zugesprochen werden, besitzen nicht nur unmielbare positive Wirkung, sondern bringen auch eine Reihe von mielbaren Vorteilen mit sich. Ist nämlich Abb. 2.: Logo der Open Sour„der ellcode vorhanden und die Weiterentwicklung durch jece Initiative den hinreichend versierten Drien möglich, verliert die Insolvenz eines Sowareherstellers oder Wartungsdienstleisters viel von ihrem Schrecken.“10 Studien von Reasoning11 und Coverity12 bescheinigen Freier Soware außerdem eine hohe Codequalität. In ihrer Begründung „given enough eyeballs, all bugs are shallow“13 folgen Sie der Argumentation aus Eric S. Raymond’s Standardwerk „e Cathedral and the Bazaar“, in der dieser das collaborative Basar-Entwicklungsmodell als dem Kathedralen-Modell klassischer Sowarehersteller überlegen ansieht. Da die klassischen Vertriebsmodelle im Open-Source-Umfeld kaum Erfolg versprechend waren, haben sich im Laufe der Zeit einige innovative, alternative Geschäsmodelle entwickelt. Raphael Leiteritz listet in seinem Beitrag zum Open Source Jahrbuch 200414 unter anderem das Geschäsmodell der OSS-Applikationsanbieter, wie z. B. Apache (ehemals SUN bzw. Oracle) mit OpenOffice oder der OSS-Dienstleister, wie z. B. OpenERP s.a. mit dem hier thematisierten ERP-System. Dass die wirtschaliche Relevanz quelloffener Soware immer mehr an Bedeutung zunimmt, zeigt die Statistik in Abbildung 3. 10 BBS Rechtsanwälte (Open-Source-Soware im Unternehmen: Verpflichtung ür beide Seiten) vgl. Reasoning LLC (How Open Source and Commercial Soware Compare, Seite 12) 12 vgl. Coverity Inc. (Open Source Code ality On Par with Proprietary Code in 2011 Coverity Scan Report) 13 Raymond (e Cathedral and the Bazaar: Musings On Linux And Open Source By An Accidental Revolutionary, Seite 41) 14 vgl. Leiteritz (Open Source-Geschäsmodelle, Seite 139) 11 12 Abb. 3.: Prognostizierter Umsatz mit Open Source Soware in Europa in den Jahren 2008 bis 2020 3.3. On-Premise-Installation und Soware-as-a-Service Ein Trend, der in den vergangenen Jahren entstanden ist, ist das sogenannte Cloud Computing. Es „erlaubt die Bereitstellung und Nutzung von IT Infrastruktur, von Plaformen und von Anwendungen aller Art als im Web elektronisch verügbare Dienste. Der Begriff Cloud soll dabei andeuten, dass die Dienste von einem Provider im Internet (bzw. im Intranet eines größeren Unternehmens) erbracht werden.“15 Ein Teilbereich des Cloud Computing ist Soware-as-aService (SAAS), bei dem eine spezifische Sowareanwendung als Dienst vom Provider zur Verügung gestellt wird. Da das Angebot an hochwertiger, als SAAS bereitgestellter Unternehmenssoware ständig wächst, ist es sinnvoll, über eine Auslagerung von Diensten in die Cloud nachzudenken. Dabei müssen jedoch die Vor- und Nachteile16 sorgältig gegeneinander abgewogen werden. Zu den Vorteilen von Soware-as-a-Service zählen: Geringes Investitionsrisiko da ür die Sowareeinührung keinerlei IT-Hardware benötigt wird und ausschließlich die Einührungsberatung berechnet wird 15 16 Baun u. a. (Cloud Computing: Web-basierte dynamische IT-Services, Seite 1) vgl. Wikipedia contributors (Soware as a Service) 13 Transparente IT-Kosten da in der Regel nur ür die tatsächliche Nutzung der Soware bezahlt wird Beschleunigte Implementierung durch die Standardisierung der SAAS-Lösung Verringerung der IT-Prozesskomplexität indem Wartungsarbeiten, Updates und weitere IT-Aufgaben durch den Servicegeber übernommen werden Mobilität durch zeit- und ortsunabhängigen Zugriff über das Internet Konzentration auf das Kerngeschä durch die Abtretung „lästiger IT-Aufgaben“ Die Nachteile dürfen aber gerade bei geschäskritischen Anwendungen nicht außer Acht gelassen werden: Abhängigkeit von Servicegebern und damit die Gefahr, dass das System aus einem bestimmten Grund (z.B. Insolvenz, Ausfall der Internetanbindung) ausällt Langsamere Datenübertragungsgeschwindigkeit als bei On-Premise-Lösungen im lokalen Netzwerk Geringere Anpassungsmöglichkeiten durch hohen Standardisierungsgrad der SAAS-Lösung Daten- und Transaktionssicherheit müssen geltenden Vorschrien und Gesetzen entsprechen und durch angemessene Sicherheitsmaßnahmen geschützt werden Das ERP-System OpenERP wird von diversen Dienstleistern, unter anderem der Herstellerfirma selbst, als Soware-as-a-Service angeboten. Für die in dieser Arbeit betrachtete Implementierung wurde allerdings eine On-Premise-Installation auf einem lokalen Server vorgezogen, um eine intensivere Evaluation des Systems zu ermöglichen. 3.4. Abgrenzung von Start-Up-Unternehmen zu anderen Unternehmenstypen Üblicherweise werden Unternehmen anhand der Anzahl der beschäigten Personen, ihres Jahresumsatzes und ihrer Jahresbilanzsumme in Unternehmensklassen eingeordnet. Die Kommission der Europäischen Union17 sieht folgende Einteilung vor: 17 EU-Kommission (Empfehlung der Kommission vom 6. Mai 2003 betreffend die Definition der Kleinstunternehmen sowie der kleinen und mileren Unternehmen. (2003/361/EG)), Artikel 2 des Anhangs 14 Unternehmensklasse Beschäigte Personen Jahresumsatz oder Jahresbilanzsumme Kleinstunternehmen < 10 < 2 Mio € Kleine Unternehmen < 50 < 10 Mio € Milere Unternehmen < 250 < 50 bzw. < 43 Mio € Tab. 1.: Mitarbeiterzahlen und finanzielle Schwellenwerte zur Definition der Unternehmensklassen Diese Einordnung bezieht sich jedoch nur auf den aktuellen Zeitpunkt und lässt eine zeitliche Entwicklung außen vor. Damit eignet sie sich nicht ür die umfassende Charakterisierung eines Start-Up-Unternehmens, wie sich aus dem Blogeintrag des erfolgreichen Unternehmensgründers Steve Blank aus dem Silicon Valley ableiten lässt: „A startup is an organization formed to search for a repeatable and scalable business model.“18 Dieses „skalierbare Geschäsmodell“ impliziert ein schnelles Wachstum des Unternehmens sowohl finanziell als auch personell. Damit unterscheidet sich die Gründung eines Start-UpUnternehmens substanziell von Existenzgründungen mit dem Ziel einer beruflichen Selbstständigkeit, wie sie z. B. typischerweise im Handwerk aureten, obwohl beide in die Klasse der Kleinstunternehmen eingeordnet werden. Gerade bei Investitionen in die unternehmerische Infrastruktur ist es wichtig, die erwartete zukünige Entwicklung der Firma mit in den Entscheidungsprozess einfließen zu lassen, um das Unternehmen auf eine adäquate Basis zu stellen und um die Investitionssicherheit zu erhöhen. Diese Arbeit beschränkt sich auf die Betrachtung von Start-Up-Unternehmen mit ihrem im Vergleich zu anderen Kleinstunternehmen abweichenden Anforderungsprofil. Da in der Literatur keine eindeutigen, quantitativen Kriterien ür Start-Up-Unternehmen existieren, ist es dem Unternehmensgründer selbst überlassen, seine Firma einzuordnen. In der Praxis könnte z. B. ein geplanter Personalbestand von mehr als 10 Beschäigten innerhalb der ersten beiden Jahre nach Gründung ein Indikator ür die Existenz eines Start-Up-Unternehmens sein. 18 Blank (What’s A Startup? First Principles.) 15 4 Kapitel 4. Soware zur Steuerung eines Start-Up-Unternehmens Insbesondere ür die betriebliche Soware ist die Abgrenzung von Start-Up-Unternehmen zu anderen Kleinstunternehmen, die im vorangegangenen Abschni (3.4 Abgrenzung von StartUp-Unternehmen zu anderen Unternehmenstypen) diskutiert wurde, entscheidend. Sowareanbieter nutzen o die Einordnung in Unternehmensklassen, um ihre Produkte zielgruppengerecht zu bewerben. Dabei ist darauf zu achten, dass spezielle Soware ür Kleinstunternehmen schon nach kurzer Zeit mit den Anforderungen eines Start-Up-Unternehmens überfordert sein kann, was einen kurzfristigen, aufwendigen Wechsel zu einem umfangreicheren Sowaresystem erfordern würde. 4.1. Anforderungskatalog an ein Sowaresystem Bevor mit der Auswahl einer Soware begonnen werden kann, muss als eine der ersten Aufgaben im Rahmen einer Anforderungsanalyse ein Soll-Konzept mit den fachlichen Anforderungen an Funktionen und Prozesse entwickelt werden. Ebenso sind systemtechnische Anforderungen und Restriktionen zu berücksichtigen und Schnistellen zu Nachbarsystemen und Fremdsoware zu definieren und zu analysieren.19 In Start-Up-Unternehmen ist es dabei zweckmäßig, einen zweiteiligen Anforderungskatalog zu erstellen. Der erste Teil umfasst die grundlegenden betriebswirtschalichen Geschäsprozesse, die notwendigerweise schon 19 vgl. Jungebluth (Das ERP-Pflichtenhe, Seite 82) 16 zum Zeitpunkt der Aufnahme des Geschäsbetriebes verügbar sein müssen. Im zweiten Teil können die absehbaren zukünige Anforderungen aufgelistet werden. Die folgenden Unterabschnie beschreiben die wesentlichen Punkte, die dabei durch eine betriebliche Soware erüllt werden müssen. 4.1.1. Anforderungskatalog bei Unternehmensgründung Es gilt der Grundsatz, dass zum Zeitpunkt der Unternehmensgründung nur die grundsätzlichen Geschäsprozesse im System abgebildet werden sollen, um dadurch die Kosten ür Einührung und Anpassung der Soware zu begrenzen. Zu den daraus resultierenden wesentlichen Anforderungen zählen: Zentrale, redundanzfreie Datenhaltung der Stammdaten von Kunden, Lieferanten und Produkten Abbildung eines einfachen Vertriebsprozesses mit der Funktionalität Angebote, Lieferscheine und Rechnungen zu erstellen, Zahlungen zu registrieren, Lagerbestände zu korrigieren, usw. Benutzerfreundlichkeit der Soware sowohl in der Anwendung als auch in der Administration Hilfe und Support bei Eingabe- und Programmfehlern sowie bei Fragen zu Bedienung und Verhalten der Soware Überschaubare Investitionssumme um das junge Unternehmen nicht zu überfordern und das geringe zur Verügung stehende Kapital in den Kernprozessen verwenden zu können Ziel in dieser Phase ist es nicht, das Unternehmen als Ganzes miels einer Unternehmenssoware abzubilden, sondern lediglich vorwiegend die kundenorientierten Kernprozesse zu unterstützen. 4.1.2. Zukünige Anforderungen an die Unternehmenssoware der FENECON GmbH & Co. KG Die Liste der Anforderungen bei Unternehmensgründung zählt ür gewöhnlich auch bereits zum Leistungsumfang einfacherer, auf Kleinstunternehmen ausgerichteter Sowarealternativen. 17 Wie oben angedeutet sollten jedoch insbesondere auch die erst zukünig zu erwartenden Anforderungen im Auswahlprozess beachtet werden, um Investitionssicherheit zu erreichen. Eine zukunsgerichtete Anforderungsanalyse der FENECON GmbH & Co. KG ergab folgende wichtige Funktionalitäten: Internationalisierung sowohl in Bezug auf die Benutzeroberfläche als auch die vollständige Übersetzbarkeit der Standardbelege (Rechnung, Lieferschein,…), Produktbeschreibungen, usw. Integration mit E-Commerce-Anwendungen wie dem „Amazon Marketplace“ und dem eigenen, auf der Open-Source-E-Commerce-Plaform Magento basierenden, Webshop. Dabei sind unterschiedliche Stufen der Integration, von der einfachen Übernahme neuer Bestellungen, bis hin zur vollständig integrierten Produkt-, Bestands- und Auragsverwaltung, denkbar. DATEV-Integration zum Austausch von Buchhaltungsdaten mit der Steuerkanzlei. Flashlistenmanagement gehört zu den sehr spezifischen Anforderungen an eine Unternehmenssoware in der Photovoltaikbranche. In sogenannten Flashlisten sind dem Kunden die eindeutigen Kennnummern sowie weitere Leistungsdaten der gelieferten Photovoltaikmodule auszuhändigen. Projekt- und Dokumentenmanagement ür die Abwicklung des LED-, Stromspeicher- und Photovoltaikvertriebs, da dieser häufig in Form von Projekten mit zahlreichen Planungsund Angebotsschrien erfolgt. Liquiditätsplanung um jederzeit Informationen über den aktuellen und zukünigen Zahlungsfluss erhalten zu können. Service, Wartung und Ersatzteilmanagement um den hohen Ansprüchen gerecht zu werden, die bei Produkten mit Garantielaufzeiten bis zu zehn Jahren bzw. einer Gesamteinsatzdauer von 30 Jahren und mehr aureten. Anpassungs- und Erweiterungsfähigkeit um Eigenentwicklungen in die Soware zu integrieren und nicht abgedeckte Funktionalitäten zu ergänzen. Umfangreiches Berechtigungskonzept zur Absicherung von Unternehmenskennzahlen vor unberechtigten Zugriffen 18 4.2. Sowarealternativen Nachdem der Anforderungskatalog ür die betriebliche Soware definiert wurde, kann eine Marktanalyse durchgeührt werden. Dieser Abschni stellt die verschiedenen Kategorien der am Markt verügbaren Soware vor und analysiert Chancen und Schwachstellen der jeweiligen Lösungen in Bezug auf den Anforderungskatalog bei Unternehmensgründung (siehe Unterabschni 4.1.1) und ihre Zukunsähigkeit. Die aufgelisteten Anwendungsprogramme und Sowarepakete verstehen sich als beispielha ür die jeweilige Kategorie und erheben keinen Anspruch auf Vollständigkeit. 4.2.1. Office-Paket Zur Kategorie der Office-Pakete zählen Anwendungen wie Microso Office20 , Apache OpenOffice21 , LibreOffice22 (e Document Foundation) und Corel WordPerfect Office23 . Für die Soware ist ein finanzieller Aufwand von 0 € bis maximal ungeähr 300 € einzuplanen. Abb. 4.: Office-Paket: Microso Word Eine naheliegende Option ür jeden Unternehmensgründer ist die Verwendung eines OfficePaketes ür die Verwaltung von Stammdaten, das Schreiben von Angeboten, Rechnungen, usw. Der Einstieg ällt hier besonders leicht, weil entsprechende Soware meist sowieso vorhanden 20 hp://office.microso.com hp://www.openoffice.org 22 hp://www.libreoffice.org/ 23 hp://www.corel.com/corel/product/index.jsp?pid=prod4720105 21 19 ist, da sie auch ür weitere Aufgabenbereiche benötigt wird, und ür gewöhnlich Vorerfahrungen im Umgang mit der Soware existieren. Somit können ohne zusätzliche Investitionen und mit nur geringem Lernaufwand gute Erfolge erzielt werden. So sind Office-Anwendungen nicht auf die Bewältigung von „Workflows“, also die Abarbeitung von festen Arbeitsschrien in einem komplexen Arbeitsprozess, ausgerichtet. Durch die vielen manuellen Tätigkeiten, die deshalb notwendig werden, wie etwa das Korrigieren des Lagerbestandes, nachdem eine Lieferung durchgeührt wurde, können schnell Fehler in der Datenintegrität aureten. Da die Daten nicht formalisiert und strukturiert, sondern unstrukturiert abgelegt werden, ist außerdem eine spätere, automatisierte Migration in eine Datenbank wenn überhaupt nur mit sehr hohem Aufwand möglich. Bei den wenigen „handgeschriebenen“ Rechnungen, die im Rahmen der Implementierung von OpenERP bei FENECON zu migrieren waren, traten z. B. mit regelmäßiger Häufigkeit fehlerhae Berechnungen, uneinheitliche Layouts, falsche Lagerbestände, usw. auf. 4.2.2. Kaufmännische Soware für Kleinst- und Kleine Unternehmen In diesen Bereich fallen unter anderem die Produkte der Haufe-Lexware GmbH & Co. KG24 („Warenwirtscha pro“, „Büro easy“, „Handwerk plus“), der DATA BECKER GmbH & Co. KG25 („finance to date“, „Aurag & Rechnung“, Handwerker PRO“), die Lösungen ür Kleinunternehmen der Sage Soware GmbH26 („GS-Office, „PC-Kaufmann“) und andere Programme wie „microtech büro+“27 , „CTO Warenwirtscha Business“28 , „MonKey Office“29 und „Win-HaBu“30 . Das Sowarespektrum reicht von kostenloser Freeware bis hin zu Sowarepaketen ür ca. 2.000 €. Den Einstieg in den Bereich integrierter, auf betriebliche Geschäsvorälle ausgerichteter Soware bildet kaufmännische Soware ür Selbstständige, Freiberufler sowie ür Kleinst- und Kleine Unternehmen. Im Allgemeinen erüllen die Anwendungen aus dieser Kategorie uneingeschränkt die Punkte aus Unterabschni 4.1.1 (Anforderungskatalog bei Unternehmensgründung), scheitern jedoch häufig an den zukünigen Anforderungen, die insbesondere in Start24 hp://www.lexware.de hp://www.databecker.de 26 hp://www.sage.de/sb 27 hp://www.microtech.de/produkte/bueroPlus 28 hp://www.ctosoware.de 29 hp://www.monkey-office.de 30 hp://mcrichter.macbay.de 25 20 Abb. 5.: Kaufmännische Soware: CTO Warenwirtscha Business Up-Unternehmen aureten. Beispielsweise sind in dieser Sowareklasse die Integration eigener Individualprogrammierung zur Erweiterung der Grundfunktionalitäten, der direkte Zugriff auf die zugrunde liegende Datenbank mit den Geschäsdaten und Möglichkeiten zur Internationalisierung keine Selbstverständlichkeit. Demzufolge können diese Programme im unternehmerischen Alltag schnell an ihre Grenzen stoßen, wie einige Beispiele, die in der Firma FENECON schon nach kurzer Zeit auraten, zeigen. So war es ür Auslandsgeschäe im Senegal notwendig, französische Produktbeschreibungen vorzuhalten, Rechnungen in französischer Sprache zu erstellen und Steuersätze entsprechend anzupassen. Ebenso wurde es mit zunehmender Anzahl an Mitarbeitern immer wichtiger, den Zugriff auf sensible Daten nur ür bestimmte Mitarbeitergruppen freizugeben, was nur durch ein in die Soware integriertes Authentifizierungs- und Berechtigungssystem möglich war. 21 4.2.3. Mielstandssoware Die bekannten, auf branchenorientierte Mielstandssoware ausgerichteten, Anbieter wie Sage Soware GmbH31 („Office Line Evolution“, „New Classic“, „ERP b7“, „ERP X3“), DATEV eG32 („Mielstand classic pro“, „Unternehmen online“), IFS33 („Applications“) und ABAS Soware AG34 („abas-ERP“) bekommen in den letzten Jahren vermehrt Konkurrenz durch die Mielstandsoffensiven der großen, traditionellen ERP-Systemhäuser SAP35 („Business One“), Oracle36 („JD Edwards EnterpriseOne“) und Microso37 („Dynamics NAV“). Als Investitionssumme ür Mielstandssoware sollten niedrige ünfstellige Beträge eingeplant werden, wobei sich die endgültigen Kosten stark projektbezogen unterscheiden können. Abb. 6.: Mielstandssoware: Sage New Classic In Bezug auf Branchenorientierung und -optimierung, Funktionalität, Benutzerfreundlichkeit und Anpassungsähigkeit sind die Sowarepakete aus dieser Kategorie das Maß der Dinge. Ausschlusskriterium ür den Einsatz in einem Start-Up-Unternehmen ist jedoch die zu erwartende Investitionshöhe, die den finanziellen Rahmen dieser Unternehmensklasse übersteigt. Mit Produkten wie „Sage New Classic“ finden sich in dieser Kategorie auch Anwendungen, die ür Start-Up-Unternehmen geeignet sein können. Über den Ansatz, eine Basissoware erst 31 hp://www.sage.de/smb hp://www.datev.de 33 hp://www.ifsworld.com 34 hp://www.abas.de 35 hp://www.sap.com/germany/sme 36 hp://www.oracle.com/de/products/applications/jd-edwards-enterpriseone 37 hp://www.microso.com/de-de/dynamics/erp-nav-ubersicht.aspx 32 22 bei Bedarf über Module individuell und flexibel an neue Anforderungen anzupassen, lassen sich hohe Initialkosten zeitlich entzerren. Als Einstiegslösung ür ein Start-Up-Unternehmen stellen sie aber weiterhin eine enorme Investition dar. 4.2.4. Open Source ERP-Systeme Abb. 7.: Open Source ERP-Systeme: OpenZ Im Markt der Warenwirtschassysteme unter Open-Source-Lizenz existieren viele Projekte mit unterschiedlichsten Ausrichtungen und Hintergründen. Tabelle 2 listet daraus die wesentlichen, auf den deutschen Raum angepassten Anwendungen. Die Pfeile (→) in der Tabelle symbolisieren jeweils einen Fork38 . Open Source ERP-Systeme bieten gerade ür Start-Up-Unternehmen einen interessanten Gegenvorschlag zu den in den vorherigen Unterabschnien vorgestellten Sowarealternativen. Die aufgelisteten Systeme befinden sich in einem fortgeschrienen und bewährten Entwicklungsstadium und sind grundsätzlich mit der Funktionstiefe von Mielstandssoware (Unterabschni 4.2.3) vergleichbar. Ihr wesentlicher Vorteil im direkten Vergleich sind die sehr günstigen Anfangsinvestitionskosten, da ür die Freie Soware keine Lizenzgebühren anfallen. Dennoch darf nicht übersehen werden, dass hinter den meisten Open Source ERP-Systemen Unternehmen stehen, ür die die Veröffentlichung des ellcodes Teil der Geschässtrategie ist und die ihre Umsätze meist mit Komplementärprodukten und -dienstleistungen erzielen. Gerade bei ERP-System stellen die im Laufe der Zeit älligen Kosten ür Anpassung und Erweiterung 38 „Ein Fork bezeichnet in der Sowareentwicklung die Aufspaltung eines Projektes in zwei oder mehrere Folgeprojekte, wobei Teile des ellcodes kopiert werden und dann unabhängig von dem ursprünglichen Projekt weiterentwickelt werden. Gründe ür einen Fork können verschiedene Ziele ür das Projekt, Uneinigkeiten in der technischen Ausührung oder persönliche Unstimmigkeiten zwischen den Entwicklern sein.“ Neubert (Betriebswirtschaliche Anwendungssoware auf Basis Freier Soware – eine Auswahl, Seite 6) 23 ERP-System Hersteller Programmiersprache Internet Java oiz.apache.org Java www.compiere.com Java www.adempiere.com Openbravo s.l. (Spanien) Java www.openbravo.com Zimmermann-Soware (Deutschland) Java www.openz.de conceptERP mm-concept GbR (Deutschland) PHP www.concepterp.de ERP5 Nexedi s.a. (Frankreich) Python www.erp5.com IntarS IntarS GmbH (Deutschland) Objective-C www.intars.de Nuclos Novabit GmbH (Deutschland) Java www.nuclos.de OpenERP OpenERP s.a. (Belgien) Python www.openerp.com Python www.tryton.org Apache OFBiz Compiere Consona Corporation (USA) → ADempiere → Openbravo → OpenZ → Tryton SQL-Ledger DWS Systems Inc. (Kanada) Perl www.sql-ledger.com → Kivitendo LINET Services GmbH (Deutschland) Perl/ PHP www.kivitendo.de PHP www.weberp.org webERP Tab. 2.: Übersicht über Open Source ERP-Systeme des Funktionsumfangs, sowie notwendige Schulungen einen hohen Anteil der Gesamtkosten dar. Es ist also unrealistisch anzunehmen, die Einührung einer Open-Source-Lösung könne vollständig kostenfrei durchgeührt werden – trotzdem sind die „Total Cost of Ownership“ häufig deutlich geringer als bei vergleichbaren Alternativlösungen. 24 Teil III. Evaluation von OpenERP Grundlage dieser Bachelorarbeit ist die Idee, in einem Start-Up-Unternehmen ab der Gründung mit einem vollwertigen, erweiterbaren ERP-System zu arbeiten. Zu diesem Zweck erscheint Open-Source-Soware aufgrund der günstigen Anschaffungs- und Inbetriebnahmekosten besonders gut geeignet. Nachdem nun im vorangegangenen Teil „eoretische Grundlagen“ gelegt wurden und die möglichen Sowarealternativen in Hinblick auf aktuelle und zukünige Anforderungen des Unternehmens FENECON GmbH & Co. KG diskutiert wurden, folgt in diesem Teil die konkrete „Evaluation von OpenERP“. Dazu werden in jeweils eigenen Kapiteln die „Funktionalität“, Varianten von „Implementierungsunterstützung und Support“ und die „Systemarchitektur“ der derzeit aktuellen Version 6.1 analysiert. Abb. 8.: Startbildschirm von OpenERP 25 5 Kapitel 5. Funktionalität Die möglichst vollständige und umfangreiche Abbildung und Unterstützung der Geschäsprozesse eines Unternehmens ist das Ziel der Implementierung eines ERP-Systems. Um die Funktionalität einer Soware zu bewerten, ist deshalb sowohl die Breite des abgedeckten Funktionsportfolios, als auch die Funktionstiefe der einzelnen Module zu betrachten. Im Folgenden werden dazu die Funktionsbereiche von OpenERP kurz vorgestellt und anschließend beispielha die Abbildung einiger konkreter Anwendungsälle im System nachvollzogen. 5.1. Abdeckung unternehmerischer Funktionsbereiche OpenERP wirbt auf der eigenen Internetpräsenz mit der Abdeckung folgender betrieblicher Funktionsbereiche:39 CRM (Customer Relationship Management) • • • • • • • 39 Durchührung von Marketingkampagnen Unterstützung der Kundenakquise Planung von Besprechungen und Telefonanrufen Management von Kundenkontakten und Verkaufschancen Angebots- und Auragsverwaltung Echtzeit-Auswertungen Anbindung an Microso Outlook und Mozilla underbird OpenERP s.a. (OpenERP - Open Source Business Applications) 26 Buchhaltung und Finanzen • Eingabeoptimierte Benutzeroberfläche • Integriertes, analytisches Rechnungswesen • Automatischer und manueller Zahlungsabgleich mit Online Banking Schnistelle • Multiwährungsähigkeit • Mehrfirmenähigkeit • Rechnungsverfolgung • Automatisches Mahnwesen • Angepasste Lokalisierung an viele Staaten • Definierbare Dashboards und Leistungskennzahlen Kassenterminal • Basierend auf Webtechnologie • Bedienerfreundlich • Leistungsähige Artikelsuchmaschine mit Unterstützung ür Barcode-Scanner • Offlineähig • Parallele Warenkörbe • Leistungsähiges Back-End (Öffnen und Schließen von Registrierkassen, Mehrbenutzerähigkeit, verschiedene Zahlungsarten,…) Projektmanagement • Integrierte Kollaborationswerkzeuge (Texteditor, Chat, E-Mail) • Einsatzplanung der Mitarbeiter • Auswerungen und Analysen (z. B. Gan-Diagramme) • Issue-Tracking-System Lagerverwaltung • Abbildung komplexer Warenströme • Doppelte Lagerbuchührung • Wareneingangs-, -ausgangs- und -wertanalyse • Integration mit Bestellwesen (Mindest- und Meldebestände) 27 Personalwesen • Zentrale Mitarbeiterdatenbank • Anwesenheits- und Arbeitszeiterfassung • Urlaubsplanung • Personalbeschaffungsmanagement • Aufstellung von Mitarbeiterentwicklungsplänen Einkauf • Wareneingangsverfolgung • alitätsmanagement • Lieferantenbewertung Produktion, Planung und Steuerung • Optimierte automatische und manuelle Ablaufplanung • Ablaufverfolgung mit Barcode-Unterstützung • Ressourcenplanung ür Personal und Material • Unterstützung ür komplexe Stücklisten und Produktionsprozesse Marketing • Durchührung von Kampagnen per E-Mail und Post • Test-Modus • Integration mit CRM ür Nachfassaktionen usw. Fakturierung • Einfache, benuterfreundliche Erstellung von Rechnungen • Detaillierte Auswertungen Gehaltsabrechnung • Noch nicht auf den deutschen Markt angepasst 28 Abb. 9.: Screenshot: www.evaluation-matrix.com OpenERP s.a. versucht mit der Internetseite www.evaluation-matrix.com (Abbildung 9) einen objektiven, detaillierten Vergleich mit den Konkurrenten Open Bravo, Sage, Microso Dynamics NAV und SAP R/3 auf funktionaler Ebene. Leider befindet sich die Seite noch im Auau und ist aufgrund der starken Ausrichtung auf OpenERP auch nur bedingt aussagekräig. Dabei ist ein direkter Vergleich beispielsweise zwischen OpenERP und SAP R/3 eigentlich nicht sinnvoll. Dies liegt zum einen an der grundsätzlich unterschiedlichen Zielgruppe und der ungleich längeren Entwicklungszeit von SAP R/3, zum anderen verfolgt OpenERP in vielen Bereichen einen vollkommen anderen Ansatz. So zeigt das Buch „OpenERP evaluation with SAP as reference“40 anschaulich (Abbildung 10), wie sich die Grundphilosophie zur Anpassung der Soware an den Bedarf des Kunden in den beiden Systemen unterscheidet. Während SAP im Regelfall die Anforderungen der Unternehmen deutlich übersteigt und ür den Einsatz ein aufwendiges Customizing erforderlich ist, verfolgt OpenERP die Idee, nur die Basisfunktionalität anzubieten, die ür die jeweiligen Ansprüche individuell erweitert wird. 5.2. Konkrete Anwendungsfälle Ein bewährtes Miel zur Analyse und Bewertung der Funktionalität von IT-Systemen ist das „Requirements Engineering“41 . Mithilfe konkreter „Use Cases“42 werden dabei aus der Sicht des Anwenders Aufgaben definiert, die durch das System abzubilden sind. Im Folgenden sollen jeweils beispielhae Anwendungsälle in den Bereichen Vertrieb, Buchhaltung und Lagerverwaltung aufgestellt und die Umsetzung durch OpenERP betrachtet werden. 40 vgl. Delsart, Yves und Van Nieuwenhuysen, Christelle (OpenERP evaluation with SAP as reference, Seite 38) vgl. Partsch (Requirements-Engineering systematisch: Modellbildung ür sowaregestützte Systeme, Seite 19) 42 vgl. Cockburn (Use Cases effektiv erstellen, Seite 15) 41 29 Abb. 10.: Grundphilosophie zur Anpassung der Soware an den Bedarf des Kunden: SAP im Vergleich zu OpenERP 5.2.1. Im Vertrieb Im Vertrieb steht die Interaktion mit den Kunden im Vordergrund. Aus den dabei anfallenden Aufgaben resultiert eine Reihe von Anwendungsällen, die sich ür den Vertriebsmitarbeiter im System ergeben: Kontaktdaten verwalten Kundenbesuch planen Angebot erstellen Kontakt nachfassen Vertriebsmitarbeiter Auftrag verwalten Abb. 11.: Anwendungsälle im Vertrieb Abb. 12.: Menüpunkt „Verkau“ OpenERP bildet die geforderte Funktionalität mithilfe der Module CRM (crm)43 und Verkaufsmanagement (sale) im zentralen Menüpunkt „Verkau“ ab. Zur Kontaktdatenverwaltung stehen die Menüunterpunkte „Verkauf | Verkaufskontakte“ und „Partnerverzeichnis | Kunden“ zur Verügung – je nachdem ob es sich nur um eine Verkaufschance bzw. eine Rückmeldung aus Marketingaktivitäten oder um einen Kunden, der bereits 43 Die interne Bezeichnung des Moduls ist jeweils in Klammern dahinter angegeben. 30 in der Kundendatenbank abgelegt wurde, handelt. Kundenbesuche und Nachfassaktionen, wie z. B. Telefonanrufe, können ebenfalls in der Kundenverwaltung oder unter „Kundenanrufe | Geplante Anrufe“ geplant werden. Angebote und Auräge werden über den Punkt „Verkauf | Verkaufsauräge“ erfasst. 5.2.2. In der Buchhaltung Die Buchhaltung bearbeitet die im Rahmen der finanziellen Geschäsvorälle eines Unternehmens auretenden Tätigkeiten. Mögliche Use-Cases in Bezug auf das ERP-System sind: Rechnung erstellen Zahlungsfluss registrieren Warenauslieferung freigeben Gutschrift erstellen Buchhalter Mahnung schreiben Abb. 13.: Anwendungsälle in der Buchhaltung Abb. 14.: Menüpunkt „Finanzen“ Die entsprechenden Funktionalitäten befinden sich bei OpenERP sowohl unter dem bereits bekannten Menüpunkt „Verkau“ als auch unter dem Überbegriff „Finanzen“, der durch die Module „eInvoicing“ (account), „eInvoicing & Payments“ (account_voucher) und „Buchhaltung und Finanzen“ (account_accountant) abgedeckt wird. Der Standardprozess zur Erstellung einer Rechnung und zur Freigabe der Warenauslieferung wird angestoßen, indem ein bestehender Verkaufsaurag bestätigt wird. Miels der angegebenen Fakturierungsregel wird dabei der Prozessablauf gesteuert. Der Prozess ür einen Verkauf auf Vorkasse wird mit der Option „Zahle vor Lieferung“ angestoßen. Dabei wird direkt eine Rechnung erstellt, die Auslieferung der Waren jedoch erst freigegeben, nachdem der Zahlungseingang registriert wurde. Der Menüpunkt „Kunden | Ausgangsrechnungen“ ermöglicht 31 in diesem Zusammenhang einen ständigen Überblick über den aktuellen Status der Ausgangsrechnungen und bietet auch den Einstiegspunkt zur Erfassung eines Zahlungseingangs und zur Erstellung einer Gutschri im Falle einer Rücksendung. Die Funktion „Periodische Buchungen | Zahlungserinnerungen | Sende Zahlungserinnerung“ aus dem Modul „Followup Management“ (account_followup) unterstützt den Buchhalter darüber hinaus bei der automatisierten Erstellung von Mahnungen aufgrund unbezahlter Rechnungen, bei denen das angegebene Zahlungsziel überschrien wurde. 5.2.3. In der Lagerverwaltung Ein gut funktionierendes Lagermanagement kann die Kapitalbindung reduzieren und die Lieferquote erhöhen. Das Bereitstellen der daür notwendigen, gesicherten Informationen über den aktuellen und zukünigen Lagerbestand ist die zentrale Aufgabe der Lagerverwaltung. Wareneingang registrieren Ware ausgeben Lagerverwalter Bestand verwalten Abb. 15.: Anwendungsälle in der Lagerverwaltung Abb. 16.: Menüpunkt „Lager“ OpenERP setzt intern auf eine Methode, die sich an die doppelte Buchührung anlehnt und die einzelnen Lagerorte wie Konten in der Buchhaltung ührt. Eine Warenlieferung entspricht dabei einem Buchungssatz mit Soll- und Habenkonto, sodass zu jeder Warenlieferung immer auch eine Buchung auf einem Gegenkonto erfolgt. Das System arbeit dazu mit echten, physischen Lagern, wie „Hauptlager“ und „alitätskontrolle“, mit Konten ür Lager bei Kunden und Lieferanten und mit virtuellen Lagern, wie „Eigene Produktion“, „Lagerschwund“ und „Ausschussware“.44 44 vgl. Pinckaers und Van Vossel (Integrate Your Logistic Processes with Openerp, Seiten 103) 32 Die entsprechenden Eingabeoberflächen ür Anwendungsälle der Lagerverwaltung sind der Kategorie „Lager“ zugeordnet, das mit dem Modul „Lager & Logistik“ (stock) mitgeliefert wird. „Lagerbuchhaltung | Wareneingang“ listet die, durch Beschaffungsauräge ausgelösten, zu erwartenden Wareneingänge auf, um sie an dieser Stelle zu überprüfen und zu bestätigen. Analog dazu erfolgt die Auslieferung der geplanten Warenausgänge inklusive der Erstellung eines Lieferscheines unter „Lagerbuchhaltung | Warenauslieferung“. Zur Überprüfung des Lagerbestandes im Rahmen einer Stichtagsinventur steht der Punkt „Bestandsverwaltung | Inventurauräge“ zur Verügung. 5.3. Anpassung von Geschäsprozessen In 4.2.1 wurde bereits beschrieben, dass Office-Anwendungen ür komplexere Geschäsprozesse ungeeignet sind, weil sie aufeinander folgende Arbeitsschrie nicht unterstützen. Ein ERP-System lebt davon, Aufgaben anhand von vordefinierten, mit Parametern gesteuerten Prozessen abzuarbeiten, wie das Beispiel eines Verkaufs auf Vorkasse (Unterabschni 5.2.2) kurz angedeutet hat. OpenERP kennt zwei verschiedene Perspektiven auf Geschäsprozesse. Mithilfe der Ansicht „User Process“ kann der aktuelle Status eines konkreten Dokuments in einem „Workflow“ betrachtet werden. Abbildung 17 zeigt beispielsweise in einem Verkaufsprozess den Weg des Angebots VA0102, aus dem ein Verkaufsaurag mit zugehöriger Rechnung (RE12172) und eine Warenauslieferung wurde. Abb. 17.: User Process 33 Als „Workflow“ bezeichnet OpenERP die technische Definition zur Abarbeitung von Prozessschrien. Obwohl in ERP-Systemen grundsätzlich eine Reihe vordefinierter „best-practice Workflows“ existieren, ist es häufig notwendig, Anpassungen vorzunehmen oder vollständig neue Arbeitsprozesse zu entwerfen. Somit lässt sich die ERP-Soware vollständig an die betrieblichen Abläufe des Unternehmens anpassen. Im Menüpunkt „Einstellungen | Personalisierung | Workflowdesign | Workflowdesign“ steht dazu ein leistungsähiger, grafischer Editor zur Verügung. Abbildung 18 zeigt den Verkaufsprozess erneut, jedoch diesmal in der formal vollständigen, technischen Darstellung als Zustandsdiagramm. In dieser Ansicht werden die möglichen Zustände und die jeweiligen Transitionen deutlich. Dabei stellen die grauen Ellipsen Start- und Endzustände dar; das Rechteck um „invoice“ deutet auf einen eigenen Subworkflow zur Abwicklung der Rechnungsstellung hin. Abb. 18.: Workflowdesigner 34 5.4. Erweiterungen im „Enterprise App Store“ OpenERP s.a. verfolgt den Ansatz, ein stabiles, hochwertiges ERP-System zur Abdeckung der Basisfunktionalitäten zu entwickeln und zu pflegen.45 Nach dem Vorbild der App-Stores ür Android- und Apple-Smartphones, soll das Grundsystem mit Apps erweitert werden, die durch externe Partner erstellt werden. Vorteil dieser Strategie ist die Nutzung der Open-Source-Community als Entwickler von Erweiterungen sowie eine Stärkung der OpenERP-Partner, die sich als Spezialisten positionieren können. Ein wesentlicher Nachteil ist, dass o sehr viel Zeit zwischen dem Erscheinen neuer OpenERP-Versionen und der Verügbarkeit der Apps ür diese Version verstreicht. Derzeit sind im „Enterprise App Store“ auf hp://apps.openerp.com ca. 2500 Module verügbar, wobei sowohl Umfang als auch alität der angebotenen Erweiterungen stark schwanken. Hinter dem großen Angebot verbergen sich eine Vielzahl sehr brauchbarer und wichtiger Werkzeuge, wie die verschiedenen „Reporting-Engines“ zur Erstellung von Auswertungen und Ausdrucken und die Konnektoren ür E-Business-Anwendungen. 5.4.1. Reporting OpenERP setzt auf das gut integrierte „ReportLab PDF Toolkit“46 , das auf der Auszeichnungssprache RML (Report Markup Language) basiert, die jedoch sehr tief ansetzt und relativ schwer anzupassen ist. Obwohl mit dem „OpenOffice Report Designer“ ein Konverter existiert, der Office-Dokumente in RML übersetzt, ist dieser mit komplexeren Aufgabenstellungen o überfordert. Von Partnern wurden deshalb einige gute Alternativen entwickelt: Aeroo Reports (report_aeroo) setzt ähnlich wie der „OpenOffice Report Designer“ auf die Funktionalität von OpenOffice bzw. LibreOffice um die Vorlagen ür Dokumente zu erstellen. Im Gegensatz zum Original arbeitet es jedoch nicht als Konverter, sondern verwendet zum Ausdruck eine im Hintergrund laufende Office-Instanz. Für die Druckdokumente der FENECON GmbH & Co. KG kommt Aeroo Reports zum Einsatz; siehe dazu auch die Beschreibung der Installation des Reportings in Abschni 8.3. Webkit Report Engine (report_webkit) verwendet zur Erstellung seiner Ausdrucke die HTMLRendering-Engine Webkit, die unter anderem auch in Apple’s Browser Safari zum Einsatz 45 46 vgl. Pansaers, Xavier (Vision & Update on Channel Strategy, Folie 13) hp://www.reportlab.com/soware/opensource/rl-toolkit 35 kommt. Nachteil der Auszeichnungssprache HTML zur Erstellung von PDF-Dokumenten ist, dass eine exakte Positionierung und Seitenumbrüche nur schwer zu realisieren sind. Darüber hinaus existieren unter anderem noch Anbindungen an die spezialisierten BerichtsWerkzeuge „JasperReports“ und „Pentaho Business Analytics“. 5.4.2. E-Business Unter dem Projektnamen „Magento OpenERP Connector“47 entwickeln einige OpenERP-Partner gemeinsam eine offene und flexible Schnistelle zur Anbindung von E-Business-Plaformen wie „Magento“, „Amazon Marketplace“ und „eBay“. Leider sind diese Module in den derzeit frei verügbaren Versionen noch nicht tauglich ür einen Produktivbetrieb. Eine Integration der verschiedenen Shop-Systeme ist deshalb momentan nur in Verbindung mit darauf spezialisierten OpenERP-Partnern sinnvoll. Im Projekt FENECON wird deshalb die automatisierte Anbindung an die eigenen Online-Shops Magento und Amazon so lange ausgesetzt, bis die manuelle Bearbeitung der Bestellungen unverhältnismäßig wird. 5.5. Referenzen Die oben dargestellten, abgedeckten unternehmerischen Funktionsbereiche, die beispielhaen Anwendungsälle und verügbare Erweiterungen geben einen Hinweis darauf, wie umfangreich die Funktionstiefe von OpenERP ist. Da es nicht möglich ist, die Abdeckung jedes aktuell und zukünig notwendigen Betriebsprozesses zu analysieren, lohnt sich darüber hinaus ein Blick auf die Unternehmen und Branchen, in denen die Soware bereits im Einsatz ist. OpenERP s.a. listet in seinen Referenzen48 über 100 Unternehmen aus den Bereichen Handel, Bau, Fertigung, Dienstleistung usw. auf und zählt auch einige namhae Firmen wie „Danone“ und „Canonical“, den Sponsor der Linux-Distribution „Ubuntu“, zu seinen Kunden. Wichtig ür einen Einsatz in Deutschland ist außerdem, dass die Soware auch den hiesigen Anforderungen genügt. Dazu sei auf die Referenzen49 der „big-consulting GmbH“ aus Cloppenburg verwiesen, in denen zahlreiche Implementierungen in Deutschland, insbesondere auch im rechtlich kritischen Bereich Finanzbuchhaltung, gelistet sind. 47 hps://launchpad.net/magentoerpconnect OpenERP s.a. (Customers References) 49 big-consulting GmbH (OpenERP Referenzen) 48 36 6 Kapitel 6. Implementierungsunterstützung und Support Ein ERP-System ist ein komplexes Sowarepaket, das auf die Anforderungen jedes einzelnen Unternehmens individuell angepasst werden muss und das sich in jeder Implementierung etwas unterscheidet. OpenERP ist milerweile verhältnismäßig einfach zu installieren und eine interne Inbetriebnahme ist, wie in dieser Arbeit dargestellt, gerade bei Start-Up-Unternehmen durchaus sinnvoll. Das Geschäsmodell hinter dem Open Source ERP-System sieht vor, dass sich mit OpenERP s.a. der Hersteller der Soware um die Weiterentwicklung des Frameworks und der grundlegenden ERP-Funktionalität, sowie um den Langzeitsupport kümmert, während Dienstleistungspartner die Implementierung und Anpassung vor Ort übernehmen. Darüber hinaus soll die Community, also auch jeder nicht-zahlende Benutzer der Soware, sich aktiv in den Entwicklungsprozess einbringen können und die Abb. 19.: Partnerstrategie des Herstellers Soware dauerha als kostenlose Open-Source-Soware unter OpenERP s.a. der AGPL-Lizenz zur Verügung gestellt werden. Dabei behält sich OpenERP s.a. die Vorgabe der strategischen Ausrichtung der Soware vor und bestimmt quasi im Alleingang die grundlegende Ausrichtung, Anpassungen im Framework und anstehende Releasewechsel. 37 Dieses Kapitel stellt die Protagonisten im Ökosystem um OpenERP dar, also das Zusammenspiel zwischen OpenERP s.a., den Dienstleistungspartnern und der Online-Community. 6.1. OpenERP s.a. in Belgien Ein wesentlicher, im Unternehmensumfeld vielleicht entscheidender, Unterschied zu anderen Open Source ERP-Systemen wie „Apache OfBiz“ oder dem OpenERP-Ableger „Tryton“, ist die Tatsache, dass im Falle von OpenERP ein gut etabliertes Unternehmen hinter der Soware steht. Das belgische Unternehmen „OpenERP s.a.“50 wurde im Jahr 2005 von Fabien Pinckaers mit der Vision gegründet, mit einer Open-Source-Soware der Markt der ERP-Systeme zu verändern. Die milerweile mehr als 180 Mitarbeiter in den Standorten Belgien und Indien zeigen, dass das Geschäsmodell aufgegangen ist. Bei Open-Source-Soware im Unternehmenseinsatz drängt sich immer die Frage auf: „Wer haet, wenn es schief geht?“51 In der AGPL-Lizenz etwa, nach der OpenERP lizenziert ist, steht unter Paragraf 15: „THERE IS NO WARRANTY FOR THE PROGRAM“52 . Auch wenn dieser Haungsausschluss in Deutschland gesetzlich umstrien ist53 – ein Unternehmen, das OpenSource-Soware in kritischen Bereichen einsetzt, benötigt eine kompetente Anlaufstelle ür Unterstützung und Support. Mit dem Supportmodell „OpenERP Enterprise“54 bietet OpenERP s.a. Unterstützung und Produktgarantie durch den Hersteller sowie kostenlose Migrationen auf die neueste Version bei einem Releasewechsel. Die Kosten ür diesen Servicevertrag belaufen sich auf 1.950 € im Jahr bei bis zu zehn Benutzern. Zu beachten gilt es dabei, dass der Support durch den Hersteller nur in französischer und englischer Sprache verügbar ist. 6.2. Dienstleistungspartner Mit über 400 Partnern in mehr als 70 Ländern existiert außerdem ein weltweites Netzwerk aus „Gold-“, „Silver-“ und „Ready-Partnern“55 . Diese regionalen und fachlichen Spezialisten pflegen 50 „s.a.“ steht ür „société anonyme“, eine belgische Rechtsform ür Aktiengesellschaen Sobola, Sabine (Open Source: Wer haet, wenn es schief geht? - manager magazin - Unternehmen) 52 Free Soware Foundation (GNU Affero General Public License (AGPL)) 53 vgl. Bundesministerium ür Wirtscha und Technologie (Open-Source-Soware: Ein Leitfaden ür kleine und milere Unternehmen, Kapitel 5. Rechtliche Fragen und Geschäsmodelle) 54 vgl. OpenERP s.a. (e OpenERP Publisher Warranty) 55 vgl. OpenERP s.a. (Partner Program) 51 38 den persönlichen Kontakt zum Kunden im Rahmen von Produktpräsentationen, Projektdurchührungen, Mitarbeitertrainings, Wartung und laufender Betreuung und passen die Soware an regionale Erfordernisse, wie z. B. geltende Gesetze, und die Anforderungen des Kunden an. Für den Raum Deutschland sind derzeit 13 lokale Partner gelistet. Deren Araktivität als Supportdienstleister liegt darin, dass sie den deutschen Wirtschasraum mit den hier geltenden rechtlichen Anforderungen an Unternehmenssoware sehr gut kennen, örtlich nahe am Kunden sind und nicht zuletzt eine Kommunikation in deutscher Sprache möglich ist. 6.3. Online-Community Auf verschiedenen Plaformen wie den öffentlichen Foren auf openerp.com, der Entwicklungsplaform Launchpad, dem Hashtag #OpenERP auf Twier, dem Programmiererforum stackoverflow.com, privaten Blogs und dem sozialen Netzwerk Facebook, existiert eine weitläufige, unübersicht- Abb. 20.: OpenERP-Partner in Deutschland liche Community. Auch wenn dadurch Informationen nicht immer einfach zu finden sind, findet sich doch eine große Vielfalt an Wissen und Unterstützung zu OpenERP. Eine erste Anlaufstelle bietet die Communityseite56 von OpenERP s.a. Für die hier diskutierte Einührung in einem Start-Up-Unternehmen wurde der Weg mithilfe der Online-Community anstelle eines Dienstleistungspartners gewählt. Auch wenn eines der erklärten Ziele von OpenERP eine möglichst einfache Installation ist, hat sich doch herausgestellt, dass ein hohes Maß an IT-Know-how und viel Geduld bei der Suche nach funktionierenden Lösungen eine Voraussetzung ür diese Variante der Implementierung ist.57 Wie oben bereits erwähnt, sind Migrationen und die schnelle Korrektur von Programmfehlern durch den Hersteller nur durch einen „OpenERP Enterprise“-Vertrag abgedeckt. Wer darauf verzichten kann, findet in der Community häufig ebenfalls gute, kostenlose Lösungen, wie etwa das Projekt OpenUpgrade, mit dem Migrationen von einem Release zum nächsten möglich werden.58 56 hp://www.openerp.com/community In Kapitel 8 finden sich deshalb die ersten Schrie zu einer grundlegenden, zukunsähigen Installation. 58 vgl. OpenUpgrade team (OpenUpgrade’s documentation) 57 39 7 Kapitel 7. Systemarchitektur Für eine Soware, die weltweit von Tausenden Programmierern weiterentwickelt wird, die in geschäskritischen, sicherheitsrelevanten Unternehmensbereichen eingesetzt wird und die sich flexibel an aktuelle und zukünige Anforderungen, wie z. B. den Zugriff auf Unternehmensdaten über Smartphone und Tablet-PC, Abb. 21.: Client-Server-Architektur von OpenERP anpassen soll, ist eine moderne, skalierbare Systemarchitektur entscheidend. Anhand der Kriterien Sowarekonzeption, verwendete Basistechnologien sowie Anpassungsund Erweiterungstechnologien erfolgt in diesem Kapitel eine eingehende, technische Analyse von OpenERP. 7.1. Sowarekonzeption Die Sowarekonzeption beschäigt sich mit den Fragen zum grundsätzlichen Auau der Soware. Welche Programmierparadigmen im OpenERP-Framework zum Einsatz kommen, erläutern die folgenden Unterabschnie. 40 Abb. 22.: Detaillierte Architektur von OpenERP 7.1.1. Client-Server- und Drei-Schichten-Architektur Die Abbildungen 21 und 22 zeigen in unterschiedlichen Detailstufen die Architektur von OpenERP. Diese setzt mit der Trennung von Präsentationsschicht („OpenERP Client“), Anwendungsschicht („OpenERP Server“) und Persistenzschicht („PostgreSQL-Datenbank“) konsequent auf eine Drei-Schichten-Architektur59 . Neben der Übersichtlichkeit durch die klare Struktur ergeben sich aus den klar definierten Schnistellen zwischen den Schichten einige Vorteile: Die Präsentationsschicht ist ür die Darstellung der Informationen auf dem Endgerät und damit ür ein einheitliches, benutzerfreundliches Bedienkonzept innerhalb der gesamten Anwendung zuständig. Sie verwendet dazu in der Auszeichnungssprache XML definierte Benutzeroberflächen mit Diagrammen, Eingabeformularen, usw. Der Standardclient in aktuellen Versionen ist der „OpenERP Web-Client“, der mithilfe eines Internetbrowsers bedient wird. Er wird zwar neben dem Applikationsserver installiert, technisch gesehen bildet er trotzdem als unabhängige Einheit eine eigene Schicht. Daneben existieren noch der GTK-Client, der sich wie eine Desktopanwendung bedienen lässt, und weitere Clients, die als Apps ür Android und iPhone bzw. iPad umgesetzt sind. Die Anwendungsschicht realisiert die eigentliche Applikationslogik der Anwendung durch ihre Geschäsobjekte („Business Objects“) und Geschäsprozesse („Workflow Engine“). In den in der Programmiersprache Python verfassten Modulen im „OpenERP Server“ finden die Berechnungen und Auswertungen sta, deren Ergebnis an die übergeordnete Präsentationsschicht über Schnistellen weitergeleitet wird. 59 vgl. Dunkel und Holitschke (Sowarearchitektur Für Die Praxis, Seite 18) 41 Die Persistenzschicht sorgt mit ihrem integrierten objektrelationalen Mapper daür, dass die in Python definierten Geschäsobjekte dauerha in der Datenbank abgelegt werden. 7.1.2. Objektrelationaler Mapper OpenERP wurde von Grund auf und durchgehend nach dem Paradigma der objektorientierten Programmierung entwickelt. Um diese Objekte möglichst komfortabel in der zugrunde liegenden, relationalen Datenbank PostgreSQL abzulegen, ist ein sogenannter „objektrelationaler Mapper“ erforderlich. Dieser sorgt daür, dass mit wenig Aufwand persistente Geschäsobjekte erstellt, bearbeitet und verwaltet werden können und dabei das relationale Datenmodell in den Hintergrund rückt. Abbildung 23 zeigt am Beispiel der Definition des Objektes „Partner“, dass das Beerben der Klasse „Object Service“ (osv.osv) ausreicht, um ein neues, persistenAbb. 23.: Definition des Objektes „Partner“ tes Geschäsobjekt zu definieren. Mit weiteren Anweisungen können darüber hinaus unter anderem Aribute und ihre Standard- werte definiert werden und Nebenbedingungen (Constraints) in der Datenbank angelegt werden. 7.1.3. Modularität Im Gegensatz zu vielen klassischen ERP-Systemen, die als monolithische Strukturen aufgebaut sind, besteht OpenERP nur aus einem allgemeinen Applikationsframework, das mit den entsprechenden Modulen zum ERP-System wird. Jede Funktionalität, egal ob komplexes Produktionsplanungs- und -steuerungssystem oder die einfache Erweiterung eines Geschäsobjektes um ein Eingabefeld, ist zu einem Baustein gekapselt. Diese Module können voneinander abhängen, sich gegenseitig flexibel erweitern und Eigenschaen und Methoden erben und vererben. 42 Weitere Informationen zur Modularität befinden sich im entsprechenden Unterabschni 7.3.2 auf Seite 50 unter den Anpassungs- und Erweiterungstechnologien. 7.1.4. Mehrbenutzerfähigkeit Ein ERP-System kann von vielen Benutzern gleichzeitig verwendet werden, die möglicherweise zur gleichen Zeit die gleichen Objekte bearbeiten oder deren Operationen sich gegenseitig beeinflussen. In diesem Zusammenhang ist die Umsetzung der Transaktionssicherheit und des Sperrverfahrens ausschlaggebend. Darüber hinaus sind in einem Mehrbenutzersystem verschiedene Benutzerrollen mit unterschiedlichen Zugriffsrechten notwendig. Mit der durchgängigen Drei-Schichten-Architektur und dem objektrelationalen Mapper sind in OpenERP die Grundlagen ür eine übergreifende Mehrbenutzerähigkeit gegeben, die automatisch bei allen Modulen Anwendung findet. Programme, die an diesen Schichten vorbei operieren, wie etwa durch einen direkten Zugriff auf die Datenbank per SQL-Anweisung, können diese Sicherheitsvorkehrungen jedoch umgehen. 7.1.4.1. Transaktionssicherheit Eine Transaktion bezeichnet „eine Folge von Programmschrien, die als eine logische Einheit betrachtet werden.“60 Sie ist „ein abgeschlossener Vorgang, der die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand überührt“61 und somit die Datenintegrität gewährleistet. Das Transaktionssystem stellt dabei die Einhaltung der sogenannten ACID-Eigenschaen62 sicher: Atomarität (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgeührt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, ist das System unverändert. Konsistenz (Consistency): Nach Ausührung der Transaktion muss der Datenbestand in einer konsistenten Form sein, wenn er es bereits zu Beginn der Transaktion war. Isolation (Isolation): Bei gleichzeitiger Ausührung mehrerer Transaktionen dürfen sich diese nicht gegenseitig beeinflussen. (Siehe dazu auch 7.1.4.2 Sperrverfahren) 60 Wikipedia contributors (Transaktion (Informatik)) Gabler Wirtschaslexikon (Definition: Transaktion) 62 Wikipedia contributors (Transaktion (Informatik)) 61 43 Dauerhaigkeit (Durability): Die Auswirkungen einer Transaktion müssen im Datenbestand dauerha bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht „mit der Zeit verblassen“ oder „aus Versehen verloren gehen“. Eine Verschachtelung von Transaktionen ist wegen dieser Eigenscha streng genommen nicht möglich, da ein Zurücksetzen (Rollback) einer äußeren die Dauerhaigkeit einer inneren, bereits ausgeührten Transaktion verletzen würde. Das OpenERP-Framework bündelt automatisch alle Anweisungen, die an die Anwendungsschicht mithilfe eines Funktionsaufrufs (RPC)63 übergeben werden, zu Transaktionen. Dies betri sowohl alle Anfragen durch OpenERP-Clients als auch über externen Aufruf von Webservices. 7.1.4.2. Sperrverfahren Falls mehrere Operationen auf dieselben Ressourcen zugreifen, sind Sperrverfahren notwendig, um gegenseitiges Überschreiben von Änderungen zu verhindern. OpenERP verwendet hierzu die Strategie der „Optimistischen Sperren“64 . Im Gegensatz zum „Pessimistischen Locking“ werden dabei gleichzeitige Zugriffe nicht grundsätzlich blockiert, sondern Transaktionen nur bei tatsächlichen Konflikten zurückgesetzt. Um inkonsistente Daten zu erkennen, bedient sich das OpenERP-Framework der „Snapshot Isolation“ der zugrunde liegenden Datenbank PostgreSQL65 . Diese vergleicht die Daten in der Datenbank zu Beginn der Transaktion mit den Daten zu deren Ende und überprü, ob von parallelen Transaktionen gleichzeitig dieselben Daten verändert wurden. 7.1.4.3. Berechtigungssystem In einem Mehrbenutzersystem, das sensible Unternehmensdaten verwaltet, sind unterschiedliche Lese- und Schreibrechte ür die unterschiedlichen Anwenderrollen erforderlich. Als Grundvoraussetzung ist dazu eine Anmeldung am System erforderlich, die die Benutzerauthentifizierung erledigt. Anhand der definierten individuellen und gruppenspezifischen Zugriffsrechte entscheidet das OpenERP-Framework über die ür den Benutzer geltenden Berechtigungen im System. 63 vgl. OpenERP s.a. (OpenERP Coding Guidelines) vgl. Dony (Comment #3 : Bug #992525 : OpenERP Server) 65 vgl. PostgreSQL Global Development Group (PostgreSQL: Documentation: 9.1: Transaction Isolation) 64 44 In OpenERP finden sich einige, nach typischen Anwendungsszenarien vordefinierte, Benutzerrollen, wie „Verantwortlicher Mitarbeiter im Bereich Finanzen & Controlling“ oder „Einfacher Mitarbeiter im Personalwesen“, die den Benutzern über das Menü „Einstellungen | Benutzer | Benutzer“ im Reiter „Zugriffsrechte“ zugewiesen werden können. In der Detaildefinition unter „Einstellungen | Sicherheit | Rechte ür Daten“ bzw. „Rechte ür Anwendungen“ können diese Rechte sehr exakt näher spezifiziert werden, wobei daür einiges an technischem Hintergrundwissen über den Auau von OpenERP erforderlich ist.66 7.1.5. Schnistellen Eine komplexe Unternehmenssoware kann nicht sinnvoll vollkommen autark und unabhängig von anderen IT-Systemen arbeiten. OpenERP bietet aufgrund seiner Architektur und der Tatsache, dass es Freie Soware ist, eine Vielzahl an Integrationsmöglichkeiten. Diese reichen vom einfachen, manuellen Import von CSV-Dateien bis hin zum automatisierten Zugriff auf die Anwendungsschicht per XML-RPC oder die Datenbank. Darüber hinaus ist die Einbindung über ein E-Mail-Gateway Kernbestandteil des Systems. 7.1.5.1. CSV Im Web-Client findet sich überall dort, wo Daten dargestellt werden die Möglichkeit, diese als „comma-separated values“Datei zu exportieren oder externe Daten zu importieren. Diese CSV-Dateien lassen sich leicht mit Microso Excel oder LibreOffice erstellen und bieten somit eine einfache, benutzerfreund- Abb. 24.: Import- und Exportliche Möglichkeit, die Daten aus dem ERP-System extern weiter- funktion zubearbeiten oder neue und geänderte Daten halb automatisiert in die Datenbank einzuügen. 7.1.5.2. XML-RPC Das Drei-Schichten-Modell von OpenERP sieht vor, dass die Präsentations- und die Anwendungsschicht über definierte, netzwerktransparente Webservices kommunizieren. Externe Anwendungen können diese XML-RPC-Aufrufe auch direkt ansprechen und Geschäsobjekte in 66 vgl. Modi und Collet (Security in OpenERP) 45 der gleichen Integrationstiefe wie der Client bearbeiten, wobei die oben genannten Funktionalitäten der Mehrbenutzerähigkeit und der objektrelationale Mapper ohne Einschränkungen genutzt werden. Für Programmierer stehen Bibliotheken wie „OpenObject on Python“ (OOOP)67 und der „OpenERPRails connector“ (OOOR)68 zur Verügung, die die einfache Verwendung des XML-RPC-Protokoll in Drianwendungen ermöglichen. Miels der Erweiterung „TerminatOOOR“ kann auch die spezielle ETL-Anwendung (Extraktion, Transformation, Laden) Kele69 zur Massendatenverarbeitung benutzt werden. Abbildung 25 zeigt beispielha die Änderung des Status eines Produktes auf „Ende Produktlebenszyklus“ aus einer externen Python-Anwendung. Wie am Beispiel ersichtlich wird, erfordert XML-RPC ebenso wie der Web-Client eine Authentifizierung am Anwendungsserver mit Benutzername und Passwort und erlaubt anschließend die direkte Bearbeitung des Geschäsobjektes. Abb. 25.: Die Bibliothek OOOP 7.1.5.3. Direkter Datenbank-Zugriff Nicht empfohlen, aber aufgrund der offenen Architektur möglich, ist der direkte Zugriff auf die Datenbank des ERP-Systems. Zu bedenken gilt, dass auf diesem Weg sämtliche Sicherheitsvorkehrungen und Konsistenzprüfungen umgangen werden und berechnete Felder nicht zur Verügung stehen. Trotzdem kann der lesende Zugriff auf die Datenbank manchmal sinnvoll sein, da damit komplexe Anfragen, ohne den Umweg über den „Flaschenhals“ Anwendungsserver, direkt ausgeührt werden können. Über die Funktionalität Office-Anwendungen per ODBC-Schnistelle („Open Database Connectivity“) direkt mit Datenbanken zu verbinden, besteht außerdem eine interessante und einfache Möglichkeit, Daten extern weiter zu bearbeiten. 67 hps://github.com/lasarux/ooop hp://www.akretion.com/en/products-and-services/openerp-ooor-connector 69 hp://kele.pentaho.com 68 46 7.1.5.4. E-Mail-Gateway Da ein Großteil der Kommunikation in einem Unternehmen per E-Mail erfolgt, ist eine Integration in das ERP-System sinnvoll. OpenERP verügt über eine leistungsähige E-Mail-Schnistelle, die aus eingehenden E-Mails automatisch Datensätze erstellen und E-Mails versenden kann. Ein möglicher Anwendungsbereich dieser Funktionalität ist die automatische Erstellung von Verkaufschancen im Customer Relationship Management aus E-Mails an die Adresse „[email protected]“ oder die Verwaltung von Stellenbewerbungen an „[email protected]“ über das Modul „Human Ressources Recruitment Process“ (hr_recruitment). Ebenso können Liefer- und Bestellbestätigungen bei hinterlegter E-Mail-Adresse des Kunden direkt aus dem System an ihn versendet werden. Für weitergehende Integration der E-Mail-Kommunikation mit dem ERP-System stehen Erweiterungen ür Microso Outlook und Mozilla underbird zur Verügung. 7.2. Basistechnologien Ausschlaggebende Kriterien ür die Zukunsähigkeit und Skalierbarkeit einer Soware sind nicht nur die sinnvolle Sowarearchitektur, sondern auch die Eigenschaen der verwendeten Basistechnologien. Deren Vor- und Nachteile sollen in diesem Abschni diskutiert werden. 7.2.1. Datenbank: PostgreSQL PostgreSQL bezeichnet sich selbst als „the world’s most advanced open source database“70 . Mit diesem Selbstverständnis verügt das freie, objektrelationale Datenbankmanagementsystem über zahlreiche fortgeschriene Funktionen, die traditionell nur den Produkten großer, kommerzieller Anbieter wie Oracle oder Microso vorbehalten waren. Vom bekannteren OpenSource-Rivalen „MySQL“ unterscheidet es sich insbesondere durch den höheren Funktionsumfang und die weitgehende Konformität mit dem SQL-Standard ANSI-SQL 200871 , während MySQL eher als benutzerfreundliche Datenbank ür Webentwickler gilt.72 70 PostgreSQL Global Development Group (PostgreSQL: e world’s most advanced open source database) vgl. PostgreSQL Global Development Group (PostgreSQL: Documentation: 9.2: SQL Conformance) 72 vgl. PostgreSQL Global Development Group (PostgreSQL: Frequently Asked estions, Q: How does PostgreSQL compare to MySQL?) 71 47 Aufgrund des objektrelationalen Mappers, über den das OpenERP-Framework jegliche Datenbankzugriffe abwickelt, ist es grundsätzlich möglich, auch andere Datenbankmanagementsysteme, insbesondere MySQL, einzusetzen – wobei offiziell nur PostgreSQL unterstützt wird. 7.2.2. Programmiersprache: Python Als Programmiersprache, sowohl ür das OpenERP-Framework als auch ür die Module, wird Python verwendet. Die, erst in den 1990er Jahren entwickelte, dynamisch typisierte und interpretierte Sprache wurde mit dem Ziel entworfen, möglichst einfach und benutzerfreundlich zu sein.73 Sie eignet sich daher besonders ür den in OpenERP angestrebten „agilen“ Sowareentwicklungsprozess, der „mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen“74 auskommt. Die Sprache zeichnet sich unter anderem durch ihre Plaformunabhängigkeit, die vollständige Umsetzung objektorientierter Paradigmen und einen enormen Fundus an verügbaren Bibliotheken aus. Ihr sichtbarstes Merkmal ist, dass Code-Blöcke durch ihre Einrückung und nicht, wie in anderen Sprachen, durch Klammern oder Schlüsselwörter begrenzt werden, wie das Beispiel in Abbildung 23 auf Seite 42 zeigt. Python findet in den letzten Jahren mit Unternehmen wie Canonical, Google und YouTube75 eine immer professionellere Nutzerscha und taucht auch in den Programmiersprachen-Rankings seit Jahren auf den vordersten Rängen auf. So sieht TIOBE76 die Sprache derzeit auf Platz acht, während sie bei RedMonk77 sogar auf Platz vier der beliebtesten Programmiersprachen rangiert. Mit Python 3.0 wurde vor einigen Jahren eine neue, nicht vollständig abwärtskompatible Version eingeührt. Die Anpassung des Codes von OpenERP auf die neue Version steht noch aus. 7.2.3. Auszeichnungssprache: XML Die Auszeichnungssprache XML wird in OpenERP zur Vorgabe von Konfigurationsdaten und vor allem zur Definition der Benutzeroberflächen in der Präsentationsschicht verwendet (siehe 7.1.1 Client-Server- und Drei-Schichten-Architektur). Die „Extensible Markup Language“ 73 vgl. Wikipedia contributors (Python (Programmiersprache)) Wikipedia contributors (Agile Sowareentwicklung) 75 vgl. Python Soware Foundation (otes about Python) 76 vgl. TIOBE Soware BV (TIOBE Programming Community Index for September 2012) 77 vgl. O’Grady (e RedMonk Programming Language Rankings: September 2012) 74 48 gilt als sehr universelle Möglichkeit, hierarchische Daten strukturiert in Form von Elementen (siehe Abbildung 26, Zeile 4: <field[…]>res.partner</field>) und Aributen (name="model") abzulegen. Sie wird milerweile ür unterschiedlichste Zwecke, wie z. B. Internetseiten (XHTML), Vektorgrafiken (SVG) und Textdokumente (OpenDocument und Microso Office mit OOXML), eingesetzt.78 Abb. 26.: Erweiterung des Views „Partner“ durch das CRM-Modul Da sich der Auau von Benutzeroberflächen sehr gut als Hierarchie beschreiben lässt, ist XML insbesondere ür diesen Zweck geeignet. In Anlehnung an die objektorientierte Programmierung ermöglicht OpenERP auch die Vererbung von Views mit der expliziten Möglichkeit, einzelne Felder zu ersetzen, zu entfernen oder neu hinzuzuügen79 – eine Funktionalität, die insbesondere in der Erweiterung von Stammdatenoberflächen durch Module Verwendung findet. So ügt beispielsweise das „Customer Relationship Management“-Modul den Reiter „Historie“ in die Oberfläche „Partner“ ein. 7.3. Anpassungs- und Erweiterungstechnologien ERP-Systeme sind ein Ansatz, unternehmerische Prozesse in einer Standardsoware abzubilden. Dennoch unterscheiden sich die spezifischen Ausprägungen der Geschäsprozesse in verschiedenen Unternehmen teilweise deutlich und stellen o gerade die entscheidenden Vorteile gegenüber der Konkurrenz dar. Aus diesem Grund müssen ERP-Systeme Möglichkeiten bieten, um sie an die jeweilige Unternehmung anzupassen. Die folgenden Unterabschnie stellen Anpassungs- und Erweiterungstechnologien vor, die OpenERP zu diesem Zweck vorsieht. 78 79 vgl. Wikipedia contributors (Extensible Markup Language) vgl. Open Object Press (Technical Memento v0.6.5, Seite 9) 49 7.3.1. Personalisierung und Customizing Im Allgemeinen erfolgt das Customizing über den zentralen Menüpunkt „Einstellungen“, der z. B. die Konfiguration der Nummernkreise (siehe 9.2) und die Verwaltung der Benutzer und des Berechtigungskonzeptes ermöglicht. Weitere weniger komplexe Anpassungen werden ebenfalls direkt im Client über die entsprechenden Menüpunkte durchgeührt; so können etwa Eingabefelder direkt über den „Entwicklermodus“ hinzugeügt oder ausgeblendet werden.80 Darüber hinaus bietet jedes Eingabeformular die Möglichkeit, ür Felder Standardwerte zu definieren. Auch der unter 5.3 „Anpassung von GeschäsprozesAbb. 27.: Menüpunkt „Einstellungen“ sen“ vorgestellte Workflowdesigner zählt in diese Kategorie. Alle diese Änderungen können mithilfe des „Module recorder“ (base_module_record)81 aufgezeichnet und zu wiederverwendbaren Modulen zusammengefasst werden. 7.3.2. Module Tiefer gehende Eingriffe in die Funktionsweise des Systems und komplexe Individualprogrammierungen werden über Module in das System integriert. Die umfangreiche Unterstützung objektorientierter Programmierparadigmen wie Vererbung und Delegation ermöglicht dabei umfassende Anpassungen, ohne dass der vorhandene ellcode angetastet werden muss. Um den Austausch von Erweiterungen in der Community zu ördern, stellt OpenERP den in Kapitel 5.4 vorgestellten „Enterprise App Store“ zur Verügung. Jedes Modul wird innerhalb der OpenERP-Installation im Ordner „addons“ als eigenes Verzeichnis mit den entsprechenden Python-Programmen, XML-Dateien und weiteren Ressourcen geührt. 80 81 vgl. OpenERP s.a. (OpenERP 6.1. Functional Demo, ab Minute 06:30) vgl. Open Object Press (Technical Memento v0.6.5, Seite 16) 50 7.3.3. Modifikation des ellcodes Falls die oben genannten Eingriffsmöglichkeiten nicht ausreichen, um die Funktionsweise von OpenERP hinreichend zu beeinflussen, steht als letzte Möglichkeit immer noch die direkte Modifikation des ellcodes zur Verügung. Zu beachten ist, dass in diesem Fall die Upgradeähigkeit der Soware eingeschränkt wird, da diese Änderungen bei jeder neuen Sowareversion manuell überprü und unter Umständen angepasst werden müssen. Die Installation von OpenERP mithilfe des Versionsverwaltungssystems Bazaar, wie unter Abschni 8.2 beschrieben, kann diesen Prozess deutlich erleichtern, da jegliche Änderungen automatisch mitprotokolliert und dadurch nachvollziehbar werden. 51 Teil IV. Implementierung Die Evaluation im vorangegangenen Teil zeigt, dass die unter Kapitel 4.1 „Anforderungskatalog an ein Sowaresystem“ diskutierten Eigenschaen durch OpenERP erüllt werden. Teil IV dokumentiert daher nun die Implementierung von OpenERP im Start-Up-Unternehmen FENECON GmbH & Co. KG. Sie untergliedert sich in die Phasen „Installation“, „Vorbereitung zur Inbetriebnahme“ und den beispielhaen „Workflow: Vertriebsprozess ür ein LED-Projekt“. 52 8 Kapitel 8. Installation Dieses Kapitel beschreibt die Einrichtung der Datenbank (PostgreSQL), des OpenERP-Applikationsservers, des Reportings (LibreOffice) und der Client-PCs. Die Anleitung setzt dabei ein bestehendes, auf der Distribution Ubuntu 12.0482 basierendes Linux-Betriebssystem mit administrativem Zugriff auf die Konsole voraus. Im konkreten Fall wird der „Zentyal Linux Small Business Server“83 in Version 3.0 auf einem „HP ProLiant N40L Microserver“84 verwendet, da sich diese Kombination gut als Basis ür die Infrastruktur eignet, um eine gemeinsame Datenablage und zentrale Benutzerauthentifizierung in einem kleinen Unternehmensnetzwerk zu realisieren. 8.1. Datenbank (PostgreSQL) Das Installieren des Datenbankservers und der notwendigen Abhängigkeiten erledigt das folgende Kommando: sudo a p t −g e t i n s t a l l p o s t g r e s q l Im Anschluss müssen noch der Benutzer und die Datenbank ür OpenERP angelegt werden: sudo su − p o s t g r e s c r e a t e u s e r −−c r e a t e d b −−username p o s t g r e s −−no−c r e a t e r o l e \ 82 hp://www.ubuntu.com hp://www.zentyal.org 84 hp://h10010.www1.hp.com/wwpc/de/de/sm/WF06b/15351-15351-4237916-4237917-4237917-42480095163346.html 83 53 −−no−s u p e r u s e r −−pwprompt o p e n e r p E n t e r p a s s w o r d f o r new r o l e : [ OpenERP−D a t e n b a n k p a s s w o r t ] E n t e r i t a g a i n : [ OpenERP−D a t e n b a n k p a s s w o r t ] exit 8.2. Applikationsserver (OpenERP) Um das Betriebssystem ür den OpenERP-Applikationsserver vorzubereiten, müssen erst einige zusätzliche Programme installiert werden: sudo a p t −g e t i n s t a l l b z r python−d a t e u t i l python−f e e d p a r s e r \ python−g d a t a python−l d a p python− l i b x s l t 1 python−l x m l \ python−mako python−o p e n i d python−p s y c o p g 2 python−p y b a b e l \ python−p y c h a r t python−p y d o t python−p y p a r s i n g \ python−r e p o r t l a b python−s i m p l e j s o n python−t z \ python−vatnumber python−v o b j e c t python−webdav \ python−werkzeug python−x l w t python−yaml python−z s i Nun wird ein Benutzer „openerp“ angelegt, mit dessen Privilegen und in dessen Home-Verzeichnis der OpenERP-Applikationsserver später ausgeührt wird: sudo a d d u s e r −−s y s t e m −−home = / o p t / o p e n e r p −−group o p e n e r p Mit einem weiteren Befehl kann man sich nun als „openerp“ einloggen: sudo su − o p e n e r p −s / b i n / b a s h Nun werden die ellcodes zur aktuellen Version 6.1 mithilfe des Versionskontrollsystems Bazaar (bzr) in das lokale Verzeichnis „/opt/openerp/version-control-6.1“ heruntergeladen. Dieses Verzeichnis dient in dieser Konfiguration von nun an als zentrale Ablage ür alle Downloads. mkdir v e r s i o n −c o n t r o l −6.1 cd v e r s i o n −c o n t r o l −6.1 b z r b r a n c h l p : o p e n o b j e c t −s e r v e r / 6 . 1 o p e n o b j e c t −s e r v e r b z r b r a n c h l p : openerp −web / 6 . 1 openerp −web b z r b r a n c h l p : o p e n o b j e c t −ad dons / 6 . 1 o p e n o b j e c t −addons 54 Die Dateien des OpenERP-Applikationsservers (openobject-server) werden nun mithilfe symbolischer Links unter dem Namen „/opt/openerp/server-6.1“ zusammengeügt, da dieser die Erweiterungsmodule (z. B. diejenigen aus openobject-addons und openerp-web) im Unterordner „./openerp/addons“ erwartet. cd . . l n −s v e r s i o n −c o n t r o l − 6 . 1 / o p e n o b j e c t −s e r v e r / s e r v e r −6.1 cd s e r v e r − 6 . 1 / o p e n e r p / ad dons / l n −s ~ / v e r s i o n −c o n t r o l − 6 . 1 / o p e n o b j e c t −ad dons / * . l n −s ~ / v e r s i o n −c o n t r o l − 6 . 1 / openerp −web / addons / * . exit Abschließend muss noch das Startskript aus Anhang B85 übernommen, die mitgelieferte OpenERPKonfigurationsdatei kopiert und angepasst und die Protokollierung eingerichtet werden. cd / o p t / o p e n e r p / s e r v e r − 6 . 1 / i n s t a l l / sudo nano / e t c / i n i t . d / openerp −s e r v e r [ hier Inhalt einfügen ] sudo chmod 7 5 5 / e t c / i n i t . d / openerp −s e r v e r sudo chown r o o t : / e t c / i n i t . d / openerp −s e r v e r sudo u p d a t e −r c . d openerp −s e r v e r d e f a u l t s sudo cp openerp −s e r v e r . c o n f / e t c / openerp −s e r v e r . c o n f sudo chmod 6 4 0 / e t c / openerp −s e r v e r . c o n f sudo chown o p e n e r p : / e t c / openerp −s e r v e r . c o n f sudo nano / e t c / openerp −s e r v e r . c o n f d b _ p a s s w o r d = [ OpenERP−D a t e n b a n k p a s s w o r t ] admin_passwd = [ OpenERP−A d m i n i s t r a t i o n s p a s s w o r t ] l o g f i l e = / v a r / l o g / o p e n e r p / openerp −s e r v e r . l o g sudo mkdir / v a r / l o g / o p e n e r p / sudo chown o p e n e r p : r o o t / v a r / l o g / o p e n e r p / Der OpenERP-Applikationsserver mit dem integrierten Webclient wird nun bei jedem Systemstart automatisch ausgeührt. Mit dem Befehl sudo s e r v i c e openerp −s e r v e r s t a r t 85 vgl. Open Sourcerer, e (How to install OpenERP 6.1 on Ubuntu 10.04 LTS) 55 steht er auch ohne Neustart des Systems unter der Adresse »hp://[IP-Adresse des Servers]:8069« zur Verügung. Über den Link „Manage Databases“ kann dort eine neue Datenbank angelegt werden: Abb. 28.: Erstellen einer OpenERP-Datenbank Darauin steht eine leere aber vollwertige OpenERP-Instanz zur Verügung. Die internen Abläufe in der Protokolldatei können währenddessen mit diesem Befehl verfolgt werden: t a i l −f / v a r / l o g / o p e n e r p / openerp −s e r v e r . l o g 8.3. Reporting (LibreOffice) Als Reporting-Engine (vgl. 5.4.1 Reporting auf Seite 35) wird das Aeroo-Modul verwendet. Es erfordert ein im „Headless“-Modus laufendes OpenOffice oder LibreOffice, deshalb ist dessen Installation und die Einrichtung des Startskriptes (C) erforderlich.86 sudo a p t −g e t i n s t a l l l i b r e o f f i c e −w r i t e r python−s e t u p t o o l s sudo nano / e t c / i n i t . d / l i b r e o f f i c e −h e a d l e s s sudo chmod 7 5 5 / e t c / i n i t . d / l i b r e o f f i c e −h e a d l e s s sudo chown r o o t : / e t c / i n i t . d / l i b r e o f f i c e −h e a d l e s s sudo u p d a t e −r c . d l i b r e o f f i c e −h e a d l e s s d e f a u l t s 86 vgl. Alistek Ltd. (Aeroo Reports Linux server) 56 Nun muss das Aeroo-Modul in die Installation integriert werden: sudo su − o p e n e r p −s / b i n / b a s h cd v e r s i o n −c o n t r o l − 6 . 1 / bzr branch lp : aeroo / openerp6 . 1 . x aeroo bzr branch lp : a e r o o l i b a e r o o l i b cd ~ / s e r v e r − 6 . 1 / o p e n e r p / ad don s / l n −s ~ / v e r s i o n −c o n t r o l − 6 . 1 / a e r o o / * . exit cd / o p t / o p e n e r p / v e r s i o n −c o n t r o l − 6 . 1 / a e r o o l i b / a e r o o l i b / sudo python . / s e t u p . py i n s t a l l Anschließend kann das Reporting-Modul über den OpenERP-Webclient installiert werden. Nach der Aktivierung der erweiterten Schnistelle in den persönlichen Einstellungen („Zahnrad“ am oberen rechten Bildrand) wird der Menüpunkt „Einstellungen | Übersicht Module | Update der Module“ verügbar, mit dem die Liste der im Addons-Verzeichnis vorhandenen Module neu geladen werden kann. Im Fenster „Einstellungen | Übersicht Module“ können nun die Module „Aeroo Reports“ (report_aeroo) und „Aeroo Reports - OpenOffice Helper Addon“ (report_aeroo_ooo) installiert und eine Verbindung zum LibreOffice-Dienst hergestellt werden. Zur Erstellung der Angebots- und Rechnungsvorlagen ür Aeroo wird an dieser Stelle auf Abschni 9.1 „Anpassung des Reportings an das Corporate Design“ weiter unten verwiesen. 8.4. Client-PCs Abb. 29.: Aufruf des OpenERP-Webclients Aufseiten der Client-PCs sind ür gewöhnlich keine Anpassungen erforderlich. Dank der verwendeten Webtechnologien können sie einfach per Webbrowser auf den OpenERP-Server zugreifen: h t t p : / / [ IP−A d r e s s e d e s S e r v e r s ] : 8 0 6 9 57 9 Kapitel 9. Vorbereitung zur Inbetriebnahme Nachdem die Installation von OpenERP im vorangegangenen Kapitel durchgeührt wurde, steht nun das Customizing, also die Anpassung des ERP-Systems an das Unternehmen, an. Wichtig ist auch hier wieder, wie in der gesamten Bachelorarbeit, die Einschränkung auf den Einsatz in einem Start-Up-Unternehmen. Dies reduziert den Umfang der Inbetriebnahme deutlich im Vergleich zur Einührung eines ERP-Systems in einem bestehenden kleinen oder mittelständischen Unternehmen; insbesondere ist weder eine aufwendige Migration bestehender Daten erforderlich, noch müssen komplexe bestehende Workflows im System abgebildet werden. Im Falle der FENECON GmbH & Co. KG konnten die, bis zur Einührung von OpenERP angefallenen, Geschäsvorälle mit vertretbarem Aufwand manuell im System nacherfasst werden. Für den Import größerer Datenmengen stellt OpenERP eine Reihe von Technologien bereit, die im Unterabschni 7.1.5 „Schnistellen“ näher betrachtet werden. Außerdem waren die vordefinierten best-practice Prozesse ausreichend, sodass die Installation des Moduls „Verkaufsmanagement“ (sale) ausreichte, um die im „Anforderungskatalog bei Unternehmensgründung“ (Unterabschni 4.1.1) geforderte „Abbildung eines einfachen Vertriebsprozesses“ zu ermöglichen. Die weiteren individuell notwendigen und gewünschten Anpassungen unterscheiden sich naturgemäß je nach Firma sehr. Zwei der Customizing-Maßnahmen, die ür die FENECON erforderlich waren, werden im Folgenden kurz vorgestellt. 58 9.1. Anpassung des Reportings an das Corporate Design Die in OpenERP vordefinierten Reports sind zwar zweckmäßig, eine Anpassung an das Corporate Design des Unternehmens ist jedoch aufgrund der verwendeten Auszeichnungssprache RML sehr aufwendig. Aus diesem Grund wurden die Vorlagen ür Dokumente, die an den Kunden gerichtet sind, wie etwa Angebote, Rechnungen und Lieferscheine, miels Aeroo Reports neu erstellt. Andere Berichte, die nur intern verwendet werden, wie z. B. die Bestandsvorschau der Produkte, wurden im Original belassen. Abb. 30.: Definition einer Dokumentenvorlage mit Aeroo Reports Um eine neue Dokumentenvorlage mit Aeroo Reports anzulegen, wird im Menüpunkt „Einstellungen | Personalisierung | Aeroo Reports | Reports“ mit „Anlegen“ ein neuer Datensatz mit den Angaben aus Abbildung 30 erstellt. Der bestehende RML-Report ür Rechnungen wird dabei durch die Namensgleichheit im Feld „Dienst Name“ ersetzt. Im „Template path“ muss der Pfad zu einer Vorlagendatei angegeben werden; ein Beispiel dazu findet sich in Anhang D.2. Mithilfe eines Parsers, der im entsprechenden Reiter angegeben wird, können dem Report über eigene Programmierung weitere Umgebungsvariablen und Hilfsfunktionen zur Verügung gestellt werden. Der hier verwendete ellcode befindet sich in Anhang D.1 und im Modul „fenecon_aeroo_reports“ in der Bazaar-Versionsverwaltung auf Launchpad87 . 87 hp://bazaar.launchpad.net/∼sfeilmeier/coreser-addons/trunk/files/head:/fenecon_aeroo_reports 59 9.2. Anpassung der Nummernkreise Im Standard vergibt OpenERP eindeutige Nummern wie „VK/2012/0001“ ür die erste Rechnung im Jahr 2012 oder „SO001“ ür den ersten Verkaufsaurag. Um diese Nummernkreise anzupassen, ist ein Eingriff in die „Sequenzen“ unter „Einstellungen | Konfiguration | Sequenzen und Identifizierungsmerkmale“ erforderlich. Die Vorgaben ür Rechnungen und Auräge befinden sich in den Journalen „Verkau“ und „Sales Order“. Um etwa das Format ür Rechnungsnummern als „RE“ gefolgt von einer zweistelligen Jahreszahl und einer fortlaufenden, dreistelligen Nummer vorzugeben, sind die Angaben wie in Abbildung 31 geeignet. Das Ergebnis ist eine eindeutige Nummer der Form „RE12001“ ür die nächste erstellte Rechnung. Abb. 31.: Defintion eines Nummernkreises 60 10 Kapitel 10. Workflow: Vertriebsprozess für ein LED-Projekt Abb. 32.: Vereinfachtes BPMN-Diagramm eines Vertriebsprozesses Als Teil der Schulung ür die Mitarbeiter der FENECON GmbH & Co. KG zeigt dieses Kapitel einen einfachen Geschäsprozess zur Abwicklung des Vertriebs von LED-Leuchtmieln. Gleichzeitig dient es der Demonstration der Eingabe- und Ausgabeparadigmen im OpenERPWebclient, wie z. B. der Möglichkeiten zum Anlegen neuer Datensätze. Abbildung 32 stellt einen Teil des Vertriebsprozesses als BPMN-Diagramm (Business Process Model and Notation) so dar, wie er in OpenERP abgebildet wird. 61 10.1. Angebot und Aurag Angebote und Auräge verwaltet OpenERP unter dem Menüpunkt „Verkauf | Verkauf | Verkaufsauräge“ (siehe Abbildung 12 auf Seite 30). Abbildung 33 zeigt den Anzeigemodus „Liste“ zur Übersicht über den Status der aktuellen Verkaufsauräge. Er bietet die Möglichkeit einen neuen Datensatz anzulegen (①) oder bestehende zu bearbeiten (②). Abb. 33.: Liste der Verkaufsauräge Ein Klick auf den Buon „Anlegen“ (①) erzeugt einen neues Angebot in der „Formular“-Ansicht. OpenERP vergibt automatisch eine eindeutige Nummer (①) und trägt das aktuelle Datum (②) ein. Im Feld „Kunde“ wird der Name des Geschäspartners eingetragen, der, sollte er noch nicht im System erfasst sein, auch direkt aus dem Angebot heraus angelegt (③) werden kann. In diesem Fall öffnet sich ein Fenster zur Erfassung eines neuen Kunden. Aus dessen Stammdaten werden im Anschluss unter anderem die Felder Rechnungsadresse, Lieferadresse und Preisliste, aber auch die Sprache des Druckdokumentes, Steuerschlüssel, Zahlungsziele, usw. vorbelegt. Mit dem Buon „Verkaufsauragpositionen Anlegen“ (④) öffnet sich das Fenster aus Abbildung 36 zur Erfassung der einzelnen Artikel. Entscheidend ür den weiteren Verlauf des Geschäsprozesses ist die Konfiguration der Fakturierungsregel. In diesem Beispiel wird die Regel „Lieferung und Fakturierung nach Abru“ verwendet, die dem oben dargestellten Workflow entspricht. Dabei werden im Anschluss Rechnung und Lieferschein nach Bedarf erstellt. Alternativ ist gerade im Onlinehandel o die Methode „Zahle vor Lieferung“ passend, die mit Bezahlung der Rechnung automatisch eine Warenauslieferung einplant. Sobald alle Daten erfasst wurden, kann das Angebot als PDF-Datei exportiert und gedruckt (⑤) werden. Nach einer positiven Rückmeldung durch den Kunden wird es im Anschluss per „Bestätige Aurag“ (⑥) in einen Aurag (Anhang E.1) umgewandelt. Die Statusmeldungen (Abbildung 37) geben Auskun darüber, welche Schrie durch den Prozess ausgelöst wurden. 62 Abb. 34.: Neuer Verkaufsaurag Abb. 35.: Neuer Verkaufsaurag: Andere Informationen Abb. 36.: Neue Verkaufsauragposition Abb. 37.: Statusmeldung: Verkaufsaurag bestätigt 63 10.2. Lieferung Mit einem Klick auf „Lieferaurag … ist geplant ür …“ oder über den entsprechenden Eintrag im Reiter „Historie“ des Aurags, kann nun die Warenauslieferung bestätigt werden. Sie dient dazu, die physische Entnahme aus dem Lager zu buchen und so z. B. den Lagerbestand zu aktualisieren. Nach den Schrien „Prüfe Verügbarkeit“ (⑧), „Bestätigen“ und „Validiere Produktlieferung“ verbucht OpenERP den Warenausgang. Der Buon „Lieferaurag“ erstellt bei Bedarf einen Lieferschein wie in Anhang E.2. Abb. 38.: Warenauslieferung bestätigen 10.3. Rechnung Auf Basis des Verkaufsaurags wird mit dem Buon „Erstelle Schlussrechnung“ (⑨) eine neue Rechnung als Entwurf erstellt. Sofern sich seit dem Verkaufsaurag keine Änderungen ergeben haben, kann diese nun validiert (⑩) und als Rechnung (⑪, Anhang E.3) an den Kunden versandt werden. Abb. 39.: „Erstelle Schlussrechnung“ aus einem Verkaufsaurag 64 Abb. 40.: Kundenrechnung im Status „Entwur“ 10.4. Bezahlung Um nun den Vertriebsprozess abzuschließen, wird über den Buon „Zahlung“ (⑫) der Ausgleich des offenen Postens verbucht. Dazu wird eine Einzahlung des Kunden erstellt, die nach ihrer Bestätigung die Rechnung in der Buchhaltung ausgleicht. Abb. 41.: Rechnung drucken und Bezahlung einleiten 65 Teil V. Resümee 11 Kapitel 11. Zusammenfassung Ziel dieser Bachelorarbeit und des dahinterstehenden Projektes »Evaluation und Implementierung des Open Source ERP-Systems „OpenERP“ in einem Start-Up-Unternehmen« war, die neu gegründete Firma FENECON GmbH & Co. KG auf eine solide, zukunsähige Sowarebasis zu stellen. Außerdem sollte der Beweis angetreten werden, dass Open-Source-Soware ür den Einsatz in unternehmerischen Kernbereichen geeignet ist. Beide Ansprüche können durchaus als erüllt betrachtet werden. Zwar ist OpenERP noch lange nicht das leicht zu installierende, „Out of the box“ System, als das es die Marketingabteilung von OpenERP s.a. gerne darstellt. Trotzdem ist die Installation und Einrichtung mit guten IT-Kenntnissen, etwas Geduld und den richtigen Anleitungen sehr wohl möglich. Wer den Aufwand nicht scheut, wird mit einem System belohnt, das über beachtliche Funktionalität, Integration und Flexibilität verügt und eine gute Basis ür Unternehmenswachstum und zukünige Anforderungen an die Soware darstellt. 66 12 Kapitel 12. Ausblick Die vorliegende Arbeit beschäigt sich mit Version 6.1 von OpenERP. Auf dem „OpenERP Community, Customers and Partners Summit“ in Brüssel im April 2012 verriet Fabien Pinckaers, Gründer und Geschäsührer der OpenERP s.a., mit welcher strategischen Ausrichtung das Unternehmen in die Zukun geht. Als auälligste Änderung in der kommenden Version 7.0, die ür das vierte artal 2012 geplant ist, stellte er die intuitivere Benutzeroberfläche des Webclient vor, der in Anlehnung an Plaformen wie salesforce88 und facebook89 stark auf Web 2.0 Technologie setzt. Durch die Konzentration auf benutzerfreundliche, anwenderorientierte Bedienung sollte sich die Soware zukünig noch besser ür Start-Up-Unternehmen eignen. Ein Ziel des Herstellers lautet: „With OpenERP 7.0, new users should be productive in no time“90 Für das Unternehmen FENECON wird sich mit dem Erscheinen der neuen Version die Frage stellen, wann und ob ein Upgrade notwendig und sinnvoll erscheint. Die Antwort darauf kann nur eine Evaluation der Änderungen in Version 7.0 ergeben, sobald diese freigegeben ist. Gegen eine sofortige Aktualisierung des Systems spricht jedoch neben den üblichen Risiken bei Hauptversionen mit vielen Neuerungen, dass auch einige Module aus dem Enterprise App Store verwendet werden, die erst von den jeweiligen Programmierern migriert werden müssen. Es ist aber nicht davon auszugehen, dass ein Upgrade auf Version 7.0 - entweder mit „OpenERP-Enterprise“-Vertrag oder mit dem freien OpenUpgrade - in einigen Monaten eine große Herausforderung darstellen wird. 88 hp://www.salesforce.com hp://www.facebook.com 90 OpenERP s.a. (OpenERP - Using 7.0. is as easy as 10 clicks) 89 67 Teil VI. Verzeichnisse 68 Literaturverzeichnis Alistek Ltd. Aeroo Reports Linux server. : http://www.alistek.com/wiki/index.php/ Aeroo_Reports_Linux_server (besucht am 17. 09. 2012). Baun, Christian u. a. (Okt. 2009). Cloud Computing: Web-basierte dynamische IT-Services. de. Springer DE. : 9783642015939. BBS Rechtsanwälte (Feb. 2011). Open-Source-Soware im Unternehmen: Verpflichtung ür beide Seiten. : http : / / bbs - law . de / 2011 / 02 / open - source - software - im unternehmen-verpflichtung-fuer-beide-seiten/ (besucht am 31. 08. 2012). big-consulting GmbH. OpenERP Referenzen. : http : / / www . openbig . org / openerp referenzen (besucht am 09. 09. 2012). Blank, Steve (Jan. 2010). What’s A Startup? First Principles. : http://steveblank.com/ 2010/01/25/whats-a-startup-first-principles/ (besucht am 28. 06. 2012). Bundesministerium ür Wirtscha und Technologie, Hrsg. (März 2001). Open-Source-Soware: Ein Leitfaden ür kleine und milere Unternehmen. : http://oss- broschuere. berlios.de/broschuere/broschuere-de.html (besucht am 10. 09. 2012). Cockburn, Alistair (Feb. 2008). Use Cases effektiv erstellen. de. Hüthig Jehle Rehm. : 9783826617966. Computerwoche (Jan. 2008). ERP-Migration fehlgeschlagen: Mit Blaulicht in die Insolvenz. : http : / / www . computerwoche . de / software / erp / 1854252/ (besucht am 29. 08. 2012). Coverity Inc. (Feb. 2012). Open Source Code ality On Par with Proprietary Code in 2011 Coverity Scan Report. : http : / / coverity . com / html / press / open - source code-quality-on-par-with-proprietary-code-in-2011-coverity-scan- (besucht am 31. 08. 2012). Delsart, Yves und Van Nieuwenhuysen, Christelle (Dez. 2011). OpenERP evaluation with SAP as reference. : 978-2-960-08764-2. Dony, Olivier. Comment #3 : Bug #992525 : OpenERP Server. : https://bugs.launchpad. net/openobject-server/+bug/992525/comments/3 (besucht am 12. 09. 2012). Dunkel, Jürgen und Andreas Holitschke (2003). Sowarearchitektur Für Die Praxis. de. Springer DE. : 9783540002215. report.html 69 EU-Kommission (Mai 2003). Empfehlung der Kommission vom 6. Mai 2003 betreffend die Definition der Kleinstunternehmen sowie der kleinen und mileren Unternehmen. (2003/361/EG). : http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L: 2003:124:0036:0041:DE:PDF (besucht am 01. 09. 2012). Free Soware Foundation. Kategorien freier und unfreier Soware. : http : / / www . gnu . org/philosophy/categories.de.html (besucht am 31. 08. 2012). — (2007). GNU Affero General Public License (AGPL). : http : / / www . gnu . org / licenses/agpl-3.0.de.html (besucht am 10. 09. 2012). Gabler Wirtschaslexikon. Definition: Enterprise Resource Planning-System. : http : / / wirtschaftslexikon . gabler . de / Definition / enterprise - resource - (besucht am 30. 08. 2012). — Definition: Transaktion. : http : / / wirtschaftslexikon . gabler . de / Definition/transaktion.html (besucht am 11. 09. 2012). Hoppe, Till (Aug. 2006). Soware ür den Überblick - Am offenen Herzen. : http : / / planning-system.html www . handelsblatt . com / unternehmen / mittelstand / software - fuer - den - (besucht am 01. 09. 2012). Jungebluth, Volker (2008). Das ERP-Pflichtenhe. 4., überarb. Aufl. Heidelberg: mitp, REDLINE. : 978-3-8266-5962-1. Leiteritz, Raphael (2004). Open Source-Geschäsmodelle. Bd. 2004. : http://citeseerx. ueberblick-am-offenen-herzen/2697732.html ist.psu.edu/viewdoc/download?doi=10.1.1.83.6372&rep=rep1&type=pdf# (besucht am 31. 08. 2012). Modi, Harshad und Raphael Collet (Apr. 2012). Security in OpenERP. : http : / / de . slideshare . net / openobject / openerp - security - in - openerp (besucht am 12. 09. 2012). Neubert, Falk (Sep. 2011). Betriebswirtschaliche Anwendungssoware auf Basis Freier Soware – eine Auswahl. : http://www.wt- os.de/fileadmin/user_upload/alle/ reco/erp/Broschüre_ERP_web.pdf (besucht am 05. 09. 2012). O’Grady, Stephen. e RedMonk Programming Language Rankings: September 2012. : http: //redmonk.com/sogrady/2012/09/12/language-rankings-9-12/ (besucht am 16. 09. 2012). Open Object Press (Jan. 2011). Technical Memento v0.6.5. : http://doc.openerp.com/ memento/OpenERP_Technical_Memento_v0.6.5_A4_draft.pdf. Open Source Initiative. e Open Source Definition. : http://opensource.org/docs/osd (besucht am 10. 08. 2012). Open Sourcerer, e (Feb. 2012). How to install OpenERP 6.1 on Ubuntu 10.04 LTS. : http: page=153 //www.theopensourcerer.com/2012/02/how-to-install-openerp-6-1-onubuntu-10-04-lts/ 70 (besucht am 16. 09. 2012). OpenERP s.a. Customers References. : http : / / www . openerp . com / products / new references (besucht am 09. 09. 2012). — OpenERP - Open Source Business Applications. : http : / / www . openerp . com / products/ (besucht am 05. 09. 2012). — OpenERP Coding Guidelines. : http://doc.openerp.com/v6.0/contribute/ 15_guidelines/coding_guidelines_framework.html#never- commit- the- (besucht am 11. 09. 2012). — Partner Program. : http://www.openerp.com/partners/partner- program (besucht am 10. 09. 2012). — e OpenERP Publisher Warranty. : http://www.openerp.com/catalog/146 (besucht am 10. 09. 2012). — (Sep. 2012a). OpenERP - Using 7.0. is as easy as 10 clicks. : http://www.openerp. com/node/1225 (besucht am 25. 09. 2012). — (März 2012b). OpenERP 6.1. Functional Demo. : http : / / www . youtube . com / watch ? v = ElussgP7OcQ & feature = youtube _ gdata _ player (besucht am 16. 09. 2012). OpenUpgrade team. OpenUpgrade’s documentation. : http : / / openupgrade - server . readthedocs.org/en/latest/index.html (besucht am 10. 09. 2012). Pansaers, Xavier (Apr. 2012). Vision & Update on Channel Strategy. Business & Management. : http://de.slideshare.net/openobject/openerp-vision-update-onchannel-strategy (besucht am 09. 09. 2012). Partsch, Helmuth (Juni 2010). Requirements-Engineering systematisch: Modellbildung ür sowaregestützte Systeme. de. Springer DE. : 9783642053573. Pinckaers, Fabien und Els Van Vossel (Juli 2011). Integrate Your Logistic Processes with Openerp. Tiny Sprl. : 2960087623. PostgreSQL Global Development Group. PostgreSQL: Documentation: 9.2: SQL Conformance. : http : / / www . postgresql . org / docs / current / static / features . html (besucht am 13. 09. 2012). — PostgreSQL: Frequently Asked estions. : http://www.postgresql.org/about/ press/faq (besucht am 13. 09. 2012). — PostgreSQL: e world’s most advanced open source database. : http : / / www . postgresql.org/ (besucht am 13. 09. 2012). — (2012). PostgreSQL: Documentation: 9.1: Transaction Isolation. : http : / / www . postgresql . org / docs / 9 . 1 / static / transaction - iso . html (besucht am 12. 09. 2012). Python Soware Foundation. otes about Python. : http://www.python.org/about/ quotes/ (besucht am 13. 09. 2012). transaction 71 Raymond, Eric S. (Feb. 2001). e Cathedral and the Bazaar: Musings On Linux And Open Source By An Accidental Revolutionary. O’Reilly Media. : 0596001088. : http://www. catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html. Reasoning LLC (Feb. 2003). How Open Source and Commercial Soware Compare. : http: //www.reasoning.com/pdf/Open_Source_White_Paper_v1.1.pdf (besucht am 20. 08. 2012). Ronneburg, Frank. Debian GNU/Linux Anwenderhandbuch. : http : / / debiananwenderhandbuch . de / freiesoftware . html # osid (besucht am 10. 08. 2012). Schatz, Anja, Péter Egri und Marcus Sauer. Open source ERP - Reasonable tools for manufacturing SMEs? : http://www.ipa.fraunhofer.de/fileadmin/www.ipa.fhg.de/ pdf/Studien/OpenSource-ERP_Study_2011.pdf. Sobola, Sabine. Open Source: Wer haet, wenn es schief geht? - manager magazin - Unternehmen. : http://www.manager-magazin.de/unternehmen/it/0,2828,322293,00. html (besucht am 10. 09. 2012). TIOBE Soware BV. TIOBE Programming Community Index for September 2012. : http : //www.tiobe.com/index.php/content/paperinfo/tpci/index.html (besucht am 16. 09. 2012). Wikipedia contributors (Sep. 2012a). Agile Sowareentwicklung. de. Page Version ID: 107404032. : http : / / de . wikipedia . org / w / index . php ? title = Agile _ Softwareentwicklung&oldid=107404032 (besucht am 13. 09. 2012). — (Juni 2012b). Enterprise-Resource-Planning. de. Page Version ID: 104297053. : http: //de.wikipedia.org/w/index.php?title=Enterprise-Resource-Planning& (besucht am 27. 06. 2012). (Sep. 2012c). Extensible Markup Language. de. Page Version ID: 107429881. : http: oldid=104297053 — //de.wikipedia.org/w/index.php?title=Extensible_Markup_Language& — oldid=107429881 (besucht am 16. 09. 2012). (Sep. 2012d). Python (Programmiersprache). de. Page Version ID: 108009097. : http: //de.wikipedia.org/w/index.php?title=Python_(Programmiersprache) (besucht am 13. 09. 2012). (Juli 2012e). Soware as a Service. de. Page Version ID: 105704135. : http://de. &oldid=108009097 — wikipedia . org / w / index . php ? title = Software _ as _ a _ Service & oldid = (besucht am 31. 08. 2012). (Juli 2012). Transaktion (Informatik). de. Page Version ID: 106066896. : http:// 105704135 — de.wikipedia.org/w/index.php?title=Transaktion_(Informatik)&oldid= 106066896 72 (besucht am 11. 09. 2012). Abbildungsverzeichnis 1. Logo der FENECON GmbH & Co. KG . . . . . . . . . . . . . . . . . . . . . . . 2. Logo der Open Source Initiative (hp://opensource.org/trademarks/opensource/print/opensource-rgb.ti) . . . . . . . . . 3. 8 12 Prognostizierter Umsatz mit Open Source Soware in Europa in den Jahren 2008 bis 2020 (PAC, ”D3 – Baseline Scenario for 2020: Economic and Social Impact of Soware & SowareBased Services” (2010)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Office-Paket: Microso Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Kaufmännische Soware: CTO Warenwirtscha Business (hp://www.ctosoware.de/images/phocagallery/Produkte/eho/thumbs// phoca_thumb_l_ScreenshotWAWI4.jpg) 6. . . . . . . . . . . . . . . . . . . . . . . . . Mielstandssoware: Sage New Classic (hp://www.sage.de/images/smb/screenshots/startseite-gross.jpg) . . . . . . . . . . . . 7. 21 22 Open Source ERP-Systeme: OpenZ (hp://www.heise.de/soware/screenshots/g104473.jpg) . . . . . . . . . . . . . . . . . 23 8. Startbildschirm von OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Screenshot: www.evaluation-matrix.com . . . . . . . . . . . . . . . . . . . . . 29 10. Grundphilosophie zur Anpassung der Soware an den Bedarf des Kunden: SAP im Vergleich zu OpenERP (Delsart, Yves und Van Nieuwenhuysen, Christelle (OpenERP evaluation with SAP as reference, Seite 38)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Anwendungsälle im Vertrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Menüpunkt „Verkau“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Anwendungsälle in der Buchhaltung . . . . . . . . . . . . . . . . . . . . . . . 31 14. Menüpunkt „Finanzen“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Anwendungsälle in der Lagerverwaltung . . . . . . . . . . . . . . . . . . . . 32 73 16. Menüpunkt „Lager“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 17. User Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 18. Workflowdesigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 19. Partnerstrategie des OpenERP-Herstellers OpenERP s.a. (Pansaers, Xavier (Vision & Update on Channel Strategy, Folie 18)) . . . . . . . . . . 20. 37 OpenERP-Partner in Deutschland OpenStreetMap und Mitwirkende, CC BY-SA hp://www.openstreetmap.org und hp://creativecommons.org/licenses/by-sa/2.0 . . . . 21. Client-Server-Architektur von OpenERP . . . . . . . . . 40 (Nicos Interests (hp://en.wikipedia.org/wiki/OpenERP)) . . . . . . . . . . . . . . . . 41 23. Definition des Objektes „Partner“ . . . . . . . . . . . . . . . . . . . . . . . . . 42 24. Import- und Exportfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 25. Die Bibliothek OOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 26. Erweiterung des Views „Partner“ durch das CRM-Modul . . . . . . . . . . . . 49 27. Menüpunkt (Stéphane Tteyssier (hp://blog.octo.com/en/first-steps-with-openerp)) 22. 74 39 Detaillierte Architektur von OpenERP „Einstellungen“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 28. Erstellen einer OpenERP-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . 56 29. Aufruf des OpenERP-Webclients . . . . . . . . . . . . . . . . . . . . . . . . . . 57 30. Definition einer Dokumentenvorlage mit Aeroo Reports . . . . . . . . . . . . 59 31. Defintion eines Nummernkreises . . . . . . . . . . . . . . . . . . . . . . . . . . 60 32. Vereinfachtes BPMN-Diagramm eines Vertriebsprozesses . . . . . . . . . . . . 61 33. Liste der Verkaufsauräge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 34. Neuer Verkaufsaurag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 35. Neuer Verkaufsaurag: Andere Informationen . . . . . . . . . . . . . . . . . . 63 36. Neue Verkaufsauragposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 37. Statusmeldung: Verkaufsaurag bestätigt . . . . . . . . . . . . . . . . . . . . . 63 38. Warenauslieferung bestätigen . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 39. „Erstelle Schlussrechnung“ aus einem Verkaufsaurag . . . . . . . . . . . . . . 64 40. Kundenrechnung im Status „Entwur“ . . . . . . . . . . . . . . . . . . . . . . . 65 41. Rechnung drucken und Bezahlung einleiten . . . . . . . . . . . . . . . . . . . 65 Tabellenverzeichnis 1. 2. Mitarbeiterzahlen und finanzielle Schwellenwerte zur Definition der Unternehmensklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Übersicht über Open Source ERP-Systeme . . . . . . . . . . . . . . . . . . . . 24 75 Teil VII. Anhang 76 A Anhang A. Die Definition quelloffener Soware („Open Source Soware“)91 Einführung „elloffen“ („Open Source“) bedeutet nicht nur freien Zugang zum ellcode. Bei quelloffener Soware müssen die Lizenzbestimmungen in Bezug auf die Weitergabe der Soware folgenden Kriterien entsprechen: 1. Freie Weitergabe Die Lizenz darf niemanden in seinem Recht einschränken, die Soware als Teil eines SowarePaketes, das Programme unterschiedlichen Ursprungs enthält, zu verschenken oder zu verkaufen. Die Lizenz darf ür den Fall eines solchen Verkaufs keine Lizenz- oder sonstigen Gebühren festschreiben. 2. ellcode Das Programm muss den ellcode beinhalten. Die Weitergabe muss sowohl ür den ellcode als auch ür die kompilierte Form zulässig sein. Wenn das Programm in irgendeiner Form ohne ellcode weitergegeben wird, so muss es eine allgemein bekannte Möglichkeit geben, 91 Ronneburg (Debian GNU/Linux Anwenderhandbuch, Version 1.9) 77 den ellcode zum Selbstkostenpreis zu bekommen, vorzugsweise als gebührenfreien Download aus dem Internet. Der ellcode soll die Form eines Programms sein, die ein Programmierer vorzugsweise bearbeitet. Absichtlich unverständlich geschriebener ellcode ist daher nicht zulässig. Zwischenformen des Codes, so wie sie etwa ein Präprozessor oder ein Konverter („Translator“) erzeugt, sind unzulässig. 3. Abgeleitete Soware Die Lizenz muss Veränderungen und Derivate zulassen. Außerdem muss sie es zulassen, dass die solcherart entstandenen Programme unter denselben Lizenzbestimmungen weitervertrieben werden können wie die Ausgangssoware. 4. Unversehrtheit des ellcodes des Autors Die Lizenz darf die Möglichkeit, den ellcode in veränderter Form weiterzugeben, nur dann einschränken, wenn sie vorsieht, dass zusammen mit dem ellcode so genannte „Patch files“ weitergegeben werden dürfen, die den Programmcode bei der Kompilierung verändern. Die Lizenz muss die Weitergabe von Soware, die aus verändertem ellcode entstanden ist, ausdrücklich erlauben. Die Lizenz kann verlangen, dass die abgeleiteten Programme einen anderen Namen oder eine andere Versionsnummer als die Ausgangssoware tragen. 5. Keine Diskriminierung von Personen oder Gruppen Die Lizenz darf niemanden benachteiligen. 6. Keine Einschränkungen bezüglich des Einsatzfeldes Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Bereich einzusetzen. Beispielsweise darf sie den Einsatz des Programms in einem Geschä oder in der Genforschung nicht ausschließen. 78 7. Weitergabe der Lizenz Die Rechte an einem Programm müssen auf alle Personen übergehen, die diese Soware erhalten, ohne dass ür diese die Notwendigkeit bestünde, eine eigene, zusätzliche Lizenz zu erwerben. 8. Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein Die Rechte an dem Programm dürfen nicht davon abhängig sein, ob das Programm Teil eines bestimmten Soware-Paketes ist. Wenn das Programm aus dem Paket herausgenommen und im Rahmen der zu diesem Programm gehörenden Lizenz benutzt oder weitergegeben wird, so sollen alle Personen, die dieses Programm dann erhalten, alle Rechte daran haben, die auch in Verbindung mit dem ursprünglichen Soware-Paket gewährt wurden. 9. Die Lizenz darf die Weitergabe zusammen mit anderer Soware nicht einschränken Die Lizenz darf keine Einschränkungen enthalten bezüglich anderer Soware, die zusammen mit der lizenzierten Soware weitergegeben wird. So darf die Lizenz z. B. nicht verlangen, dass alle anderen Programme, die auf dem gleichen Medium weitergegeben werden, auch quelloffen sein müssen. 79 B Anhang B. OpenERP Startskript (/etc/init.d/openerp-server) #!/bin/sh ### BEGIN INIT INFO # Provides: # Required-Start: # Required-Stop: # Should-Start: # Should-Stop: # Default-Start: # Default-Stop: # Short-Description: # Description: ### END INIT INFO openerp-server $remote_fs $syslog $remote_fs $syslog $network $network 2 3 4 5 0 1 6 Enterprise Resource Management software Open ERP is a complete ERP and CRM software. PATH=/bin:/sbin:/usr/bin DAEMON=/opt/openerp/server-6.1/openerp-server NAME=openerp-server DESC=openerp-server # Specify the user name (Default: openerp). USER=openerp # Specify an alternate config file (Default: /etc/openerp-server.conf). CONFIGFILE="/etc/openerp-server.conf" # pidfile PIDFILE=/var/run/$NAME.pid # Additional options that are passed to the Daemon. DAEMON_OPTS="-c $CONFIGFILE" 80 [ -x $DAEMON ] || exit 0 [ -f $CONFIGFILE ] || exit 0 case "${1}" in start) echo -n "Starting ${DESC}: " start-stop-daemon --start --quiet --pidfile ${PIDFILE} \ --chuid ${USER} --background --make-pidfile \ --exec ${DAEMON} -- ${DAEMON_OPTS} echo "${NAME}." ;; stop) echo -n "Stopping ${DESC}: " start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \ --oknodo echo "${NAME}." ;; restart|force-reload) echo -n "Restarting ${DESC}: " start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \ --oknodo sleep 1 start-stop-daemon --start --quiet --pidfile ${PIDFILE} \ --chuid ${USER} --background --make-pidfile \ --exec ${DAEMON} -- ${DAEMON_OPTS} echo "${NAME}." ;; *) N=/etc/init.d/${NAME} echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2 exit 1 ;; esac exit 0 81 C Anhang C. LibreOffice Startskript (/etc/init.d/libreoffice-headless) #!/bin/sh ### BEGIN INIT INFO # Provides: # Required-Start: # Required-Stop: # Should-Start: # Should-Stop: # Default-Start: # Default-Stop: # Short-Description: # Description: ### END INIT INFO libreoffice-headless $remote_fs $syslog $remote_fs $syslog $network $network 2 3 4 5 0 1 6 LibreOffice Headless Server LibreOffice Headless Server PATH=/bin:/sbin:/usr/bin DAEMON=/usr/bin/loffice NAME=libreoffice-headless DESC=libreoffice-headless # Specify the user name (Default: openerp). USER=openerp # pidfile PIDFILE=/var/run/$NAME.pid [ -x $DAEMON ] || exit 0 82 case "${1}" in start) echo -n "Starting ${DESC}: " start-stop-daemon --chuid ${USER} --start --name soffice.bin \ --background --startas /usr/bin/soffice \ -- -headless -nologo -nofirststartwizard -norestore \ -accept='socket,host=localhost,port=8100;urp' echo "${NAME}." ;; stop) echo -n "Stopping ${DESC}: " start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \ --oknodo echo "${NAME}." ;; restart|force-reload) echo -n "Restarting ${DESC}: " start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \ --oknodo sleep 1 start-stop-daemon --chuid ${USER} --start --name soffice.bin \ --background --startas /usr/bin/soffice \ -- -headless -nologo -nofirststartwizard -norestore \ -accept='socket,host=localhost,port=8100;urp' echo "${NAME}." ;; *) N=/etc/init.d/${NAME} echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2 exit 1 ;; esac exit 0 83 D Anhang D. Rechnungserstellung mit Aeroo Reports D.1. Ausschnie des Report-Parsers (parser.py) from report import report_sxw from report.report_sxw import rml_parse from osv.orm import browse_null class Parser(report_sxw.rml_parse): def __init__(self, cr, uid, name, context): super(Parser, self).__init__(cr, uid, name, context) objekt = self.pool.get(name).browse(cr,uid,context["active_id"],context) ## Bank: Ermittelt die für die Rechnung gültigen Kontodaten # [...] ## Kontext: Erstellt den gültigen Kontext für die Reporting-Engine self.localcontext.update({ 'get_formatted_address': self.get_formatted_address, 'get_gender': self.get_gender, 'get_person_name': self.get_person_name, 'bank': self.bank, }) # Gibt den Namen der Person zurück def get_person_name(self, address): # [...] # Gibt eine formatierte Adresse zurück def get_formatted_address(self, address): # [...] D.2. LibreOffice-Vorlage 84 <OBJECTS[0].COMPANY_ID.PARTNER_ID.NAME> <OBJECTS[0].COMPANY_ID.PARTNER_ID.TITLE.NAME> • <A["NAME"]>< <FOR EACH="A IN GET_FORMATTED_ADDRESS(OBJECTS[0].ADDRESS_INVOICE_ID)"> TEST="A.NAME2"> IF <A["NAME2"]></ > <A["STREET"]>< =" . <A["STREET2"]></ > IF <_("IHR ANSPRECHPARTNER:")> A STREET2"> IF TEST <OBJECTS[0].USER_ID.EMPLOYEE_IDS[0].NA ME> IF <_("TEL.")>: <OBJECTS[0].USER_ID.EMPLOYEE_ IDS[0].WORK_PHONE><IF <A["CITY"]> <A["COUNTRY"]></ TEST="OBJECTS[0].USER_ID.EMPLOYEE_IDS[0].MOBILE_PHONE"> FOR> <_("MOBIL")>: <OBJECTS[0].USER_ID.EMPLOYEE_ IDS[0].MOBILE_PHONE></IF> <_("FAX")>: <OBJECTS[0].COMPANY_ID.FAX> <_("E-MAIL")>: <OBJECTS[0].USER_ID.EMPLOYEE_ < S E T L A N G ( O . P A T E S T = " O B J E C T S [ 0 ] . T Y P E T E S T = " O B J E C T S [ 0 ] . S T A T R T N E R _ I . D L A N = = G ' = = E O R O U T _ ' O P E ' D E _ D E ' ) > I N V O N ' O I C R < ' " > < E O B J E C C C T H H S O O O O S S [ 0 ] . > < E > < E S T A W W T H H E E N N = = E ' P A I <_("RE ' " > D ")> <_("NR.")> <OBJECTS[0].NUMBER> <_("PROFORMARECHNUNG")> <_("RECHNUNG (ENTWURF)")> <_("RECHNUNG (STORNIERT)")> <_("GUTSCHRIFT")> <_("NR.")> <OBJECTS[0].NUMBER> <_("EINGANGSRECHNUNG" )> <_("NR.")> <OBJECTS[0].NUMBER> <_("EINGANGSGUTSCHRIFT ")> <_("NR.")> <OBJECTS[0].NUMBER> C H N U N G < / ' P R O F O R M A T E S T = " O B J W H E > < N W H E N T E S = " T E C T [ 0 ] . S E N T E S T = " O S T A T = = E ' W D H R E A F T E S T = " O B J E C T B S E C > < N J E C T S [ 0 ] . T Y P = = E ' W O [ 0 ] . T Y P E = = ' I N _ I N V T W H E N H E N T E S = " T O B J E C T T A T E > < / C U _ T R E F U N D [ 0 ] . S W O I C E H E N S E S T = " O B J E C T S [ 0 ] . T Y P E = = ' I N _ R E F > < S T A T W H E N = = E U N D = = H O O S W H E E N > < ' E C A N > < / C E L ' " > W H E N > < ' " > W H E > < N N ' " > < / T [ 0 ] . S ' " > < / T J < / < / H B 2 ' " > < / W O W H W H E N ' " > < / W H E N > < / C H O O S E > <_("SEHR GEEHRTER HERR")> <GET_PERSON_NAME(OBJECTS[0].ADDRESS_INVOICE_ID)>,</ >< =" _ ( [0]. _ _ ) == 'F '"><_("SEHR GEEHRTE FRAU")> <GET_PERSON_NAME(OBJECTS[0].ADDRESS_INVOICE_ID)>,</ >< ><_("SEHR GEEHRTE DAMEN UND HERREN,")></ ></ > <CHOOSE><WHEN TEST="GET_GENDER(OBJECTS[0].ADDRESS_INVOICE_ID) == 'HERR'"> WHEN WHEN TEST WHEN OTHERWISE GET GENDER OBJECTS ADDRESS INVOICE ID RAU OTHERWISE <_("HIERMIT STELLEN WIR IHNEN FOLGENDE ARTIKEL IN RECHNUNG:")></ '"><_("HIERMIT BESTÄTIGEN WIR DIE FOLGENDE GUTSCHRIFT:")></ ></ > <CHOOSE><WHEN TEST="OBJECTS[0].TYPE == 'OUT_INVOICE'"> 'OUT_REFUND WHEN><WHEN TEST="OBJECTS[0].TYPE WHEN <_("BEZEICHNUNG")> CHOOSE == CHOOSE <_("ANZAHL <_("EINHEI <_("EINZELPR <_("GESAMTPRE ")> T")> EIS")> IS")> <FOR EACH="LINE IN OBJECTS[0].INVOICE_LINE"> [<LINE.PRODUCT_ID.DEFAULT_CODE>] </ ><LINE.PRODUCT_ID.NAME>< =" . "> <IF TEST="LINE.PRODUCT_ID.DEFAULT_CODE"> IF IF TEST <LINE.NOTE></ > IF <OBJECTS[0].COMPANY_ID.PARTNER_ID.NAME> <OBJECTS[0].COMPANY_ID.PARTNER_ID.TITLE.NAM E> <OBJECTS[0].COMPANY_ID.STREET>, <OBJECTS[0].COMPANY_ID.ZIP> LINE NOTE <FORMATLANG <LINE.UOS_I (LINE.QUANTIT D.NAME> Y, DIGITS=3)> <OBJECTS[0].COMPANY_ID.CITY> _ID.EMAIL> <_("TEL.")>: <OBJECTS[0].COMPANY _ID.PHONE> <_("FAX")>:<OBJECTS[0].COMPANY_ID.FAX> <_("E-MAIL")>: <OBJECTS[0].COMPANY <IF TEST="LINE.PRICE_UNIT ! <IF TEST="LINE.PRICE_SUBTOTAL != <FORMATL 0"><FORMATLANG ANG(LINE.PRIC (LINE.PRICE_SUBT E_UNIT)> <OB OTAL)> <OBJECTS = 0"> <_("GESCHÄFTSFÜHRER")>: Franz-Josef Feilmeier <_("REGISTERGERICHT DEGGENDORF")>: HRA 2540 <_("PERSÖNLICH HAFTENDE GESELLSCHAFTERIN")>: <OBJECTS[0].COMPANY_ID.PARTNER_ID.NAME> <OBJECTS[0].COMPANY_ID.PARTNER_ID.TITLE.NAME> • <OBJECTS[0].COMPANY_ID.STREET> • <OBJECTS[0].COMPANY_ID.ZIP> <OBJECTS[0].COMPANY_ID.CITY> <IF TEST="GETLANG() != 'DE_DE'"><_("DEUTSCHLAND")></WHEN> <IF TEST="LINE.DISCOUNT"> </IF> <_("RABATT")> : <STR('%.0F' % (LINE.DISCOUNT)) > %</ ></ > IF IF </FOR> <_("ZWISCHENSUMME (NETTO)")> <FORMATLANG(OBJECTS[0].AMO UNT_UNTAXED)> <OBJECTS[0].C URRENCY_ID.SYMBOL> <FOR EACH="LINE IN OBJECTS[0].TAX_LINE"> <_("ZZGL.")> <OBJECTS[0].I NVOICE_LINE[ 0].INVOICE_LI NE_TAX_ID[0] .DESCRIPTION> <FORMATLANG(LINE.AMOUNT)> <OBJECTS[0].CURRENCY_ID.SYMBO L> </FOR> <_("GESAMTSUMME (BRUTTO)")> <FORMATLANG(OBJECTS[0].AMO UNT_TOTAL)> <OBJECTS[0].CURR ENCY_ID.SYMBOL> <IF TEST="OBJECTS[0].PAYMENT_TERM.NAME"><_("ZAHLUNGSBEDINGUNGEN")>: <CHOOSE><WHEN TEST="OBJECTS[0].PAYMENT_TERM.NOTE != ''"><OBJECTS[0].PAYMENT_TERM.NOTE></WHEN><OTHERWISE><OBJEC TS[0].PAYMENT_TERM.NAME></OTHERWISE></CHOOSE><IF TEST="OBJECTS[0].PAYMENT_TERM.NAME == 'BILLPAY'"> <_("VERWENDUNGSZWECK")>: <OBJECTS[0].REFERENCE></IF></IF> <IF TEST="OBJECTS[0].COMMENT"> <OBJECTS[0].COMMENT></ > IF <_("ES GELTEN UNSERE ALLGEMEINEN GESCHÄFTSBEDINGUNGEN.")> <_("MIT FREUNDLICHEN GRÜSSEN")> <OBJECTS[0].USER_ID.EMPLOYEE_IDS[0].NAME> -2- E Anhang E. Belege im Vertriebsprozess E.1. Verkaufsaurag E.2. Lieferschein E.3. Rechnung 87 FENECON GmbH & Co. KG • Brunnwiesenstr. 4 • 94469 Deggendorf Musterfirma AG Herr Mustermann Musterstraße 1 Ihr Ansprechpartner: Stefan Feilmeier 12345 Musterort Tel.: +49 991 6488000 5 Fax: +49 991 6488000 9 E-Mail: [email protected] Bestellbestätigung Beleg-Nr.: VA0105 Datum: 25.09.2012 Nr. VA0105 Sehr geehrter Herr Mustermann, hiermit bestätige ich Ihre Bestellung: Bezeichnung Anzahl [1002090101] FENECON-E27-9W Einheit 1,000 LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Stück Zwischensumme (netto) zzgl. 19% USt Gesamtsumme (brutto) Einzelpreis Gesamtpreis 20,16 € 20,16 € 20,16 € 3,83 € 23,99 € Lieferung: Musterfirma AG, Herr Mustermann Musterstraße 1, 12345 Musterort Es gelten unsere Allgemeinen Geschäftsbedingungen. Mit freundlichen Grüßen Stefan Feilmeier FENECON GmbH & Co. KG Brunnwiesenstr. 4, 94469 Deggendorf Tel.: +49 991 6488000 0 Fax: +49 991 6488000 9 E-Mail: [email protected] Geschäftsführer: Franz-Josef Feilmeier Registergericht Deggendorf: HRA 2540 Persönlich haftende Gesellschafterin: FENECON Verwaltungsgesellschaft mbH Registergericht Deggendorf: HRB 3635 Bank: Sparkasse Deggendorf Finanzamt Deggendorf BLZ: 74150000 Ust-ID-Nr.: DE277646519 Konto: 420151987 Steuernummer: 108/159/07006 BIC: BYLADEM1DEG IBAN: DE83 7415 0000 0420 1519 87 www.fenecon.de FENECON GmbH & Co. KG • Brunnwiesenstr. 4 • 94469 Deggendorf Musterfirma AG Herr Mustermann Musterstraße 1 Ihr Ansprechpartner: Stefan Feilmeier 12345 Musterort Tel.: +49 991 6488000 5 Fax: +49 991 6488000 9 E-Mail: [email protected] Beleg-Nr.: OUT/00081 Lieferschein Sehr geehrter Herr Mustermann, vielen Dank für Ihre Bestellung. Hiermit bestätigen wir die folgende Lieferung: Bezeichnung Anzahl [1002090101] FENECON-E27-9W 1,000 LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Lieferung erhalten: Einheit Stück _____________________________ _____________________________ Ort, Datum Unterschrift FENECON GmbH & Co. KG Brunnwiesenstr. 4, 94469 Deggendorf Tel.: +49 991 6488000 0 Fax: +49 991 6488000 9 E-Mail: [email protected] Geschäftsführer: Franz-Josef Feilmeier Registergericht Deggendorf: HRA 2540 Persönlich haftende Gesellschafterin: FENECON Verwaltungsgesellschaft mbH Registergericht Deggendorf: HRB 3635 Bank: Sparkasse Deggendorf Finanzamt Deggendorf BLZ: 74150000 Ust-ID-Nr.: DE277646519 Konto: 420151987 Steuernummer: 108/159/07006 BIC: BYLADEM1DEG IBAN: DE83 7415 0000 0420 1519 87 www.fenecon.de FENECON GmbH & Co. KG • Brunnwiesenstr. 4 • 94469 Deggendorf Musterfirma AG Herr Mustermann Musterstraße 1 Ihr Ansprechpartner: Stefan Feilmeier 12345 Musterort Tel.: +49 991 6488000 5 Fax: +49 991 6488000 9 E-Mail: [email protected] Beleg-Nr.: Referenz: Datum: RE12209 VA0105 25.09.2012 Rechnung Nr. RE12209 Sehr geehrter Herr Mustermann, hiermit stellen wir Ihnen folgende Artikel in Rechnung: Bezeichnung Anzahl [1002090101] FENECON-E27-9W Einheit 1,000 LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Stück Zwischensumme (netto) zzgl. 19% USt Gesamtsumme (brutto) Einzelpreis Gesamtpreis 20,16 € 20,16 € 20,16 € 3,83 € 23,99 € Zahlungsbedingungen: Vorkasse Es gelten unsere Allgemeinen Geschäftsbedingungen. Mit freundlichen Grüßen Stefan Feilmeier FENECON GmbH & Co. KG Brunnwiesenstr. 4, 94469 Deggendorf Tel.: +49 991 6488000 0 Fax: +49 991 6488000 9 E-Mail: [email protected] Geschäftsführer: Franz-Josef Feilmeier Registergericht Deggendorf: HRA 2540 Persönlich haftende Gesellschafterin: FENECON Verwaltungsgesellschaft mbH Registergericht Deggendorf: HRB 3635 Bank: Sparkasse Deggendorf Finanzamt Deggendorf BLZ: 74150000 Ust-ID-Nr.: DE277646519 Konto: 420151987 Steuernummer: 108/159/07006 BIC: BYLADEM1DEG IBAN: DE83 7415 0000 0420 1519 87 www.fenecon.de Erklärung Name des Studenten: ............ Stefan Feilmeier Name des Betreuers: ............. Prof. Dr. Josef Schneeberger Thema der Bachelorarbeit: Einführung eines ERP-Systems in einem Start-Up-Unternehmen: Evaluation und Implementierung von OpenERP 1. Ich erkläre hiermit, dass ich die Bachelorarbeit gemäß § 35 Abs. 7 RaPO (Rahmenprüfungsordnung für die Fachhochschulen in Bayern, BayRS 2210-4-1-4-1-WFK) selbständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe. Deggendorf, den 2. 28.09.2012 (Datum) ____________________________________ (Unterschrift des Studenten) Ich bin damit einverstanden, dass die von mir angefertigte Bachelorarbeit über die Bibliothek der Hochschule einer breiteren Öffentlichkeit zugänglich gemacht wird. Nein Ja, nach Abschluss des Prüfungsverfahrens Ja, nach Ablauf einer Sperrfrist von _____ Jahren Ich erkläre und stehe dafür ein, dass ich alleiniger Inhaber aller Rechte an der Bachelorarbeit einschließlich des Verfügungsrechts über Vorlagen an beigefügten Abbildungen, Plänen o.ä., bin und durch deren öffentliche Zugänglichmachung weder Rechte und Ansprüche Dritter noch gesetzliche Bestimmungen verletzt werden. Deggendorf, den 28.09.2012 (Datum) ____________________________________ (Unterschrift des Studenten) Bei Einverständnis des Verfassers mit einer Zugänglichmachung der Bachelorarbeit vom Betreuer auszufüllen: Eine Aufnahme eines Exemplars der Bachelorarbeit in den Bestand der Bibliothek und die Ausleihe des Exemplars wird befürwortet nicht befürwortet Deggendorf, den ____.____._______ (Datum) ____________________________________ (Unterschrift des Betreuers)
