Hochschule Deggendorf für angewandte Wissenschaften -Fachhochschule Deggendorf-
Fakultä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 Dieses Werk bzw. Inhalt steht unter einer Creative Commons AM: 28. September 2012 Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Kurzfassung
Anhand des Start-Up-Unternehmens FENECON GmbH & Co. KG dokumentiert diese Bachelor- arbeit 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 Daten- migration 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 So- warealternativen wird das System anhand von betriebswirtschalichen und informationstech- nischen Parametern analysiert und die anschließende Implementierung von OpenERP beschrie- ben. Ein beispielhaer Ablauf „Vertriebsprozess eines LED-Projekts“ und ein abschließendes Resümee runden die Arbeit ab.
1vgl. Computerwoche (ERP-Migration fehlgeschlagen: Mit Blaulicht in die Insolvenz)
2 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 10 3.1. ERP-System ...... 10 3.2. Open-Source- und Closed-Source-Soware ...... 11 3.3. On-Premise-Installation und Soware-as-a-Service ...... 13 3.4. Abgrenzung von Start-Up-Unternehmen zu anderen Unternehmenstypen ... 14
4. Soware zur Steuerung eines Start-Up-Unternehmens 16 4.1. Anforderungskatalog an ein Sowaresystem ...... 16 4.1.1. Anforderungskatalog bei Unternehmensgründung ...... 17 4.1.2. Zukünige Anforderungen an die Unternehmenssoware der FENECON GmbH & Co. KG ...... 17 4.2. Sowarealternativen ...... 19 4.2.1. Office-Paket ...... 19 4.2.2. Kaufmännische Soware ür Kleinst- und Kleine Unternehmen .... 20 4.2.3. Mielstandssoware ...... 22 4.2.4. Open Source ERP-Systeme ...... 23
III. Evaluation von OpenERP 25
5. Funktionalität 26 5.1. Abdeckung unternehmerischer Funktionsbereiche ...... 26 5.2. Konkrete Anwendungsälle ...... 29 5.2.1. Im Vertrieb ...... 30 5.2.2. In der Buchhaltung ...... 31
3 5.2.3. In der Lagerverwaltung ...... 32 5.3. Anpassung von Geschäsprozessen ...... 33 5.4. Erweiterungen im „Enterprise App Store“ ...... 35 5.4.1. Reporting ...... 35 5.4.2. E-Business ...... 36 5.5. Referenzen ...... 36
6. Implementierungsunterstützung und Support 37 6.1. OpenERP s.a. in Belgien ...... 38 6.2. Dienstleistungspartner ...... 38 6.3. Online-Community ...... 39
7. Systemarchitektur 40 7.1. Sowarekonzeption ...... 40 7.1.1. Client-Server- und Drei-Schichten-Architektur ...... 41 7.1.2. Objektrelationaler Mapper ...... 42 7.1.3. Modularität ...... 42 7.1.4. Mehrbenutzerähigkeit ...... 43 7.1.4.1. Transaktionssicherheit ...... 43 7.1.4.2. Sperrverfahren ...... 44 7.1.4.3. Berechtigungssystem ...... 44 7.1.5. Schnistellen ...... 45 7.1.5.1. CSV ...... 45 7.1.5.2. XML-RPC ...... 45 7.1.5.3. Direkter Datenbank-Zugriff ...... 46 7.1.5.4. E-Mail-Gateway ...... 47 7.2. Basistechnologien ...... 47 7.2.1. Datenbank: PostgreSQL ...... 47 7.2.2. Programmiersprache: Python ...... 48 7.2.3. Auszeichnungssprache: XML ...... 48 7.3. Anpassungs- und Erweiterungstechnologien ...... 49 7.3.1. Personalisierung und Customizing ...... 50 7.3.2. Module ...... 50 7.3.3. Modifikation des ellcodes ...... 51
IV. Implementierung 52
8. Installation 53 8.1. Datenbank (PostgreSQL) ...... 53 8.2. Applikationsserver (OpenERP) ...... 54 8.3. Reporting (LibreOffice) ...... 56 8.4. Client-PCs ...... 57
4 9. Vorbereitung zur Inbetriebnahme 58 9.1. Anpassung des Reportings an das Corporate Design ...... 59 9.2. Anpassung der Nummernkreise ...... 60
10. Workflow: Vertriebsprozess für ein LED-Projekt 61 10.1. Angebot und Aurag ...... 62 10.2. Lieferung ...... 64 10.3. Rechnung ...... 64 10.4. Bezahlung ...... 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 84 D.1. Ausschnie des Report-Parsers (parser.py) ...... 84 D.2. LibreOffice-Vorlage ...... 84
E. Belege im Vertriebsprozess 87 E.1. Verkaufsaurag ...... 87 E.2. Lieferschein ...... 87 E.3. Rechnung ...... 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 busi- ness 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 perfor- mance, and the reduction of costs.“2
Aufgrund der komplexen Einührung und Wartung in Verbindung mit den erheblichen Kos- ten 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 da- her 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 Start- Up-Unternehmen eignen kann und propagiert die Idee, von Beginn an ein Open Source ERP- System als Unternehmenssoware ür Start-Up-Unternehmen einzusetzen.
2Schatz, Egri und Sauer (Open source ERP - Reasonable tools for manufacturing SMEs?, Seite 7) 3Schatz, Egri und Sauer (ebd., Seite 7)
6 Kapitel 1. 1Zielsetzung 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 Da- tenbasis 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 wach- sen 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 Un- ternehmenstypen 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 „Implemen- tierung“ 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 Entwick- lung von OpenERP.
4Hoppe (Soware ür den Überblick - Am offenen Herzen)
7 Kapitel 2. 2Die 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 versorgung“ auf den drei Säulen Energieerzeugung, -effizienz GmbH & Co. KG und -speicherung. Dabei steht „Energieerzeugung“ ür ei- ne dezentrale, erneuerbare und günstige Stromerzeugung durch Photovoltaik, „Energieeffizienz“ ür die Reduzierung der Stromnachfrage zu Nicht-Sonnenzeiten, vor allem durch LED-Beleuchtung, und „Energie- speicherung“ ü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 Market- place“ 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 Metho- den 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 darge- stellt werden.
Um den Rahmen der Bachelorarbeit nicht zu sprengen, ist es außerdem unabdingbar, eini- ge 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 Kapitel 3. 3Begriffsdefinition 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 Unterneh- men ablaufenden Geschäsprozesse. Entsprechend enthält es Module ür die Be- reiche Beschaffung, Produktion, Vertrieb, Anlagenwirtscha, Personalwesen, Finanz- und Rechnungswesen usw., die über eine (in Form einer relationalen Datenbank realisierte) gemeinsame Datenbasis miteinander verbunden sind. Durch die unter- nehmensweite Konsolidierung der Daten ist eine Unterstützung der Planung über sämtliche Unternehmensebenen hinweg (von der Konzernebene über verschiede- ne Werke, Sparten und Abteilungen bis hin zu einzelnen Lagerorten) möglich.“6
Ein ERP-System ist demnach also eine mehrbenutzerähige, an unternehmerischen Geschäs- prozessen ausgerichtete Anwendungssoware zur umfassenden, strukturierten Verwaltung der Ressourcen eines Unternehmens auf Basis einer gemeinsamen Datenbank. Diese wesentli- chen Punkte sind es auch, die ein ERP-System von den in Abschni 4.2 aufgezählten Soware- alternativen unterscheiden. 5Wikipedia contributors (Enterprise-Resource-Planning) 6Gabler 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än- gigen 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än- dert 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 So- ware, die aus verändertem ellcode entstanden ist, ausdrücklich erlauben. […]
Keine Diskriminierung von Personen oder Gruppen: Die Lizenz darf niemanden benach- teiligen.
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 überge- hen, 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 bestimm- ten Soware-Paketes ist. […]
7Free Soware Foundation (Kategorien freier und unfreier Soware) 8Der Ausdruck „Open-Source-Soware“ wird in dieser Arbeit bewusst synonym zum Begriff „Freie Soware“ im Sinne ihrer eigentlichen, gemeinsamen Bedeutung verwendet. 9Englische 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 We- sentliche gekürzt. Die vollständige Open Source Definition befindet sich in Anhang A.
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 zusam- men mit der lizenzierten Soware weitergegeben wird. […]
Bekannte Beispiele ür Freie Soware, die diese Bedingungen erüllen, sind der Browser „Mo- zilla Firefox“, die Bürosoware „LibreOffice“ bzw. „OpenOffice“ und die vielen weiteren An- wendungen, die das Rückgrat des Internets bilden, wie z. B. der Webserver „Apache“.
Obwohl aus den Kriterien nicht hervorgeht, dass Open-Source- Soware notwendigerweise kostenlos bereitgestellt werden muss, bleibt der bekannteste und offensichtlichste Vorteil ür die Nutzer quelloffener Soware in den meisten Fällen die Einspa- rung von Lizenzkosten. Doch die umfangreichen Rechte, die dem Nutzer von Open-Source-Soware zugesprochen werden, besit- zen 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 je- ce 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 collabo- rative Basar-Entwicklungsmodell als dem Kathedralen-Modell klassischer Sowarehersteller überlegen ansieht.
Da die klassischen Vertriebsmodelle im Open-Source-Umfeld kaum Erfolg versprechend wa- ren, 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 Bedeu- tung zunimmt, zeigt die Statistik in Abbildung 3.
10BBS Rechtsanwälte (Open-Source-Soware im Unternehmen: Verpflichtung ür beide Seiten) 11vgl. Reasoning LLC (How Open Source and Commercial Soware Compare, Seite 12) 12vgl. Coverity Inc. (Open Source Code ality On Par with Proprietary Code in 2011 Coverity Scan Report) 13Raymond (e Cathedral and the Bazaar: Musings On Linux And Open Source By An Accidental Revolutionary, Seite 41) 14vgl. Leiteritz (Open Source-Geschäsmodelle, Seite 139)
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 An- wendungen 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-a- Service (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
15Baun u. a. (Cloud Computing: Web-basierte dynamische IT-Services, Seite 1) 16vgl. Wikipedia contributors (Soware as a Service)
13 Transparente IT-Kosten da in der Regel nur ür die tatsächliche Nutzung der Soware be- zahlt 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 ge- lassen werden:
Abhängigkeit von Servicegebern und damit die Gefahr, dass das System aus einem be- stimmten Grund (z.B. Insolvenz, Ausfall der Internetanbindung) ausällt
Langsamere Datenübertragungsgeschwindigkeit als bei On-Premise-Lösungen im loka- len Netzwerk
Geringere Anpassungsmöglichkeiten durch hohen Standardisierungsgrad der SAAS-Lösung
Daten- und Transaktionssicherheit müssen geltenden Vorschrien und Gesetzen entspre- chen und durch angemessene Sicherheitsmaßnahmen geschützt werden
Das ERP-System OpenERP wird von diversen Dienstleistern, unter anderem der Hersteller- firma selbst, als Soware-as-a-Service angeboten. Für die in dieser Arbeit betrachtete Imple- mentierung wurde allerdings eine On-Premise-Installation auf einem lokalen Server vorgezo- gen, 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 Kom- mission der Europäischen Union17 sieht folgende Einteilung vor:
17EU-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 Beschäigte Jahresumsatz oder Unternehmensklasse Personen 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 zeitli- che Entwicklung außen vor. Damit eignet sie sich nicht ür die umfassende Charakterisierung eines Start-Up-Unternehmens, wie sich aus dem Blogeintrag des erfolgreichen Unternehmens- grü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-Up- Unternehmens substanziell von Existenzgründungen mit dem Ziel einer beruflichen Selbst- stä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 zu- kü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 Lite- ratur 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.
18Blank (What’s A Startup? First Principles.)
15 Kapitel 4. 4Soware 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 Start- Up-Unternehmen zu anderen Unternehmenstypen) diskutiert wurde, entscheidend. Soware- anbieter nutzen o die Einordnung in Unternehmensklassen, um ihre Produkte zielgruppen- gerecht zu bewerben. Dabei ist darauf zu achten, dass spezielle Soware ür Kleinstunterneh- men schon nach kurzer Zeit mit den Anforderungen eines Start-Up-Unternehmens überfordert sein kann, was einen kurzfristigen, aufwendigen Wechsel zu einem umfangreicheren Soware- system erfordern würde.
4.1. Anforderungskatalog an ein Sowaresystem
Bevor mit der Auswahl einer Soware begonnen werden kann, muss als eine der ersten Auf- gaben im Rahmen einer Anforderungsanalyse ein Soll-Konzept mit den fachlichen Anforde- rungen an Funktionen und Prozesse entwickelt werden. Ebenso sind systemtechnische An- forderungen und Restriktionen zu berücksichtigen und Schnistellen zu Nachbarsystemen und Fremdsoware zu definieren und zu analysieren.19 In Start-Up-Unternehmen ist es da- bei zweckmäßig, einen zweiteiligen Anforderungskatalog zu erstellen. Der erste Teil umfasst die grundlegenden betriebswirtschalichen Geschäsprozesse, die notwendigerweise schon
19vgl. 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 Unter- abschnie 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 Anfor- derungen zählen:
Zentrale, redundanzfreie Datenhaltung der Stammdaten von Kunden, Lieferanten und Pro- dukten
Abbildung eines einfachen Vertriebsprozesses mit der Funktionalität Angebote, Liefer- scheine und Rechnungen zu erstellen, Zahlungen zu registrieren, Lagerbestände zu kor- rigieren, usw.
Benutzerfreundlichkeit der Soware sowohl in der Anwendung als auch in der Adminis- tration
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 Unternehmens- soware 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 An- forderungen im Auswahlprozess beachtet werden, um Investitionssicherheit zu erreichen. Eine zukunsgerichtete Anforderungsanalyse der FENECON GmbH & Co. KG ergab folgende wich- tige Funktionalitäten:
Internationalisierung sowohl in Bezug auf die Benutzeroberfläche als auch die vollständi- ge Übersetzbarkeit der Standardbelege (Rechnung, Lieferschein,…), Produktbeschreibun- gen, 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 neu- er Bestellungen, bis hin zur vollständig integrierten Produkt-, Bestands- und Aurags- verwaltung, denkbar.
DATEV-Integration zum Austausch von Buchhaltungsdaten mit der Steuerkanzlei.
Flashlistenmanagement gehört zu den sehr spezifischen Anforderungen an eine Unterneh- menssoware in der Photovoltaikbranche. In sogenannten Flashlisten sind dem Kunden die eindeutigen Kennnummern sowie weitere Leistungsdaten der gelieferten Photovoltaik- module auszuhändigen.
Projekt- und Dokumentenmanagement ür die Abwicklung des LED-, Stromspeicher- und Photovoltaikvertriebs, da dieser häufig in Form von Projekten mit zahlreichen Planungs- und Angebotsschrien erfolgt.
Liquiditätsplanung um jederzeit Informationen über den aktuellen und zukünigen Zahlungs- fluss erhalten zu können.
Service, Wartung und Ersatzteilmanagement um den hohen Ansprüchen gerecht zu wer- den, die bei Produkten mit Garantielaufzeiten bis zu zehn Jahren bzw. einer Gesamt- einsatzdauer von 30 Jahren und mehr aureten.
Anpassungs- und Erweiterungsfähigkeit um Eigenentwicklungen in die Soware zu inte- grieren 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 Unter- abschni 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 Open- Office21, 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 Office- Paketes ür die Verwaltung von Stammdaten, das Schreiben von Angeboten, Rechnungen, usw. Der Einstieg ällt hier besonders leicht, weil entsprechende Soware meist sowieso vorhanden
20hp://office.microso.com 21hp://www.openoffice.org 22hp://www.libreoffice.org/ 23hp://www.corel.com/corel/product/index.jsp?pid=prod4720105
19 ist, da sie auch ür weitere Aufgabenbereiche benötigt wird, und ür gewöhnlich Vorerfahrun- gen 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 Abarbei- tung 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 unstruk- turiert 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 fehler- hae 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 Kleinunterneh- men der Sage Soware GmbH26 („GS-Office, „PC-Kaufmann“) und andere Programme wie „mi- crotech 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 So- ware bildet kaufmännische Soware ür Selbstständige, Freiberufler sowie ür Kleinst- und Kleine Unternehmen. Im Allgemeinen erüllen die Anwendungen aus dieser Kategorie unein- geschränkt die Punkte aus Unterabschni 4.1.1 (Anforderungskatalog bei Unternehmensgrün- dung), scheitern jedoch häufig an den zukünigen Anforderungen, die insbesondere in Start-
24hp://www.lexware.de 25hp://www.databecker.de 26hp://www.sage.de/sb 27hp://www.microtech.de/produkte/bueroPlus 28hp://www.ctosoware.de 29hp://www.monkey-office.de 30hp://mcrichter.macbay.de
20 Abb. 5.: Kaufmännische Soware: CTO Warenwirtscha Business
Up-Unternehmen aureten. Beispielsweise sind in dieser Sowareklasse die Integration eige- ner Individualprogrammierung zur Erweiterung der Grundfunktionalitäten, der direkte Zugriff auf die zugrunde liegende Datenbank mit den Geschäsdaten und Möglichkeiten zur Interna- tionalisierung 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, zei- gen. So war es ür Auslandsgeschäe im Senegal notwendig, französische Produktbeschreibun- gen vorzuhalten, Rechnungen in französischer Sprache zu erstellen und Steuersätze entspre- chend anzupassen. Ebenso wurde es mit zunehmender Anzahl an Mitarbeitern immer wichti- ger, 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 Sa- ge 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 Mielstands- offensiven der großen, traditionellen ERP-Systemhäuser SAP35 („Business One“), Oracle36 („JD Ed- wards EnterpriseOne“) und Microso37 („Dynamics NAV“). Als Investitionssumme ür Miel- standssoware sollten niedrige ünfstellige Beträge eingeplant werden, wobei sich die endgül- tigen 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 erwar- tende 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
31hp://www.sage.de/smb 32hp://www.datev.de 33hp://www.ifsworld.com 34hp://www.abas.de 35hp://www.sap.com/germany/sme 36hp://www.oracle.com/de/products/applications/jd-edwards-enterpriseone 37hp://www.microso.com/de-de/dynamics/erp-nav-ubersicht.aspx
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 wesent- lichen, auf den deutschen Raum angepassten Anwendungen. Die Pfeile (→) in der Tabelle sym- bolisieren jeweils einen Fork38.
Open Source ERP-Systeme bieten gerade ür Start-Up-Unternehmen einen interessanten Ge- genvorschlag zu den in den vorherigen Unterabschnien vorgestellten Sowarealternativen. Die aufgelisteten Systeme befinden sich in einem fortgeschrienen und bewährten Entwick- lungsstadium und sind grundsätzlich mit der Funktionstiefe von Mielstandssoware (Unter- abschni 4.2.3) vergleichbar. Ihr wesentlicher Vorteil im direkten Vergleich sind die sehr güns- tigen 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. Gera- de 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 Folge- projekte, 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 (Be- triebswirtschaliche Anwendungssoware auf Basis Freier Soware – eine Auswahl, Seite 6)
23 Programmier- ERP-System Hersteller Internet sprache Apache OFBiz Java oiz.apache.org Compiere Consona Corporation (USA) Java www.compiere.com → ADempiere Java www.adempiere.com → Openbravo Openbravo s.l. (Spanien) Java www.openbravo.com → OpenZ 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 → Tryton Python www.tryton.org SQL-Ledger DWS Systems Inc. (Kanada) Perl www.sql-ledger.com → Kivitendo LINET Services GmbH (Deutschland) Perl/ PHP www.kivitendo.de webERP PHP www.weberp.org
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 be- sonders gut geeignet. Nachdem nun im vorangegangenen Teil „eoretische Grundlagen“ ge- legt wurden und die möglichen Sowarealternativen in Hinblick auf aktuelle und zukünige Anforderungen des Unternehmens FENECON GmbH & Co. KG diskutiert wurden, folgt in die- sem Teil die konkrete „Evaluation von OpenERP“. Dazu werden in jeweils eigenen Kapiteln die „Funktionalität“, Varianten von „Implementierungsunterstützung und Support“ und die „Sys- temarchitektur“ der derzeit aktuellen Version 6.1 analysiert.
Abb. 8.: Startbildschirm von OpenERP
25 Kapitel 5. 5Funktionalität
Die möglichst vollständige und umfangreiche Abbildung und Unterstützung der Geschäspro- zesse eines Unternehmens ist das Ziel der Implementierung eines ERP-Systems. Um die Funk- tionalität einer Soware zu bewerten, ist deshalb sowohl die Breite des abgedeckten Funkti- onsportfolios, als auch die Funktionstiefe der einzelnen Module zu betrachten. Im Folgenden werden dazu die Funktionsbereiche von OpenERP kurz vorgestellt und anschließend beispiel- ha 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)
• 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 39OpenERP 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 Dyna- mics 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 un- gleich längeren Entwicklungszeit von SAP R/3, zum anderen verfolgt OpenERP in vielen Be- reichen 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 auf- wendiges 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 Lagerver- waltung aufgestellt und die Umsetzung durch OpenERP betrachtet werden.
40vgl. Delsart, Yves und Van Nieuwenhuysen, Christelle (OpenERP evaluation with SAP as reference, Seite 38) 41vgl. Partsch (Requirements-Engineering systematisch: Modellbildung ür sowaregestützte Systeme, Seite 19) 42vgl. Cockburn (Use Cases effektiv erstellen, Seite 15)
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 Verkaufs- management (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 Verkaufs- chance bzw. eine Rückmeldung aus Marketingaktivitäten oder um einen Kunden, der bereits
43Die 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 Unterneh- mens 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 angege- benen Fakturierungsregel wird dabei der Prozessablauf gesteuert. Der Prozess ür einen Ver- kauf 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 Zah- lungseingang registriert wurde. Der Menüpunkt „Kunden | Ausgangsrechnungen“ ermöglicht
31 in diesem Zusammenhang einen ständigen Überblick über den aktuellen Status der Ausgangs- rechnungen 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 Erstel- lung von Mahnungen aufgrund unbezahlter Rechnungen, bei denen das angegebene Zahlungs- ziel überschrien wurde.
5.2.3. In der Lagerverwaltung
Ein gut funktionierendes Lagermanagement kann die Kapitalbindung reduzieren und die Lie- ferquote 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 Lagerverwal- tung
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, physi- schen Lagern, wie „Hauptlager“ und „alitätskontrolle“, mit Konten ür Lager bei Kunden und Lieferanten und mit virtuellen Lagern, wie „Eigene Produktion“, „Lagerschwund“ und „Aus- schussware“.44
44vgl. 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 er- wartenden Wareneingänge auf, um sie an dieser Stelle zu überprüfen und zu bestätigen. Ana- log dazu erfolgt die Auslieferung der geplanten Warenausgänge inklusive der Erstellung eines Lieferscheines unter „Lagerbuchhaltung | Warenauslieferung“. Zur Überprüfung des Lagerbe- standes im Rahmen einer Stichtagsinventur steht der Punkt „Bestandsverwaltung | Inventur- auräge“ zur Verügung.
5.3. Anpassung von Geschäsprozessen
In 4.2.1 wurde bereits beschrieben, dass Office-Anwendungen ür komplexere Geschäspro- zesse ungeeignet sind, weil sie aufeinander folgende Arbeitsschrie nicht unterstützen. Ein ERP-System lebt davon, Aufgaben anhand von vordefinierten, mit Parametern gesteuerten Pro- zessen 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“ be- trachtet werden. Abbildung 17 zeigt beispielsweise in einem Verkaufsprozess den Weg des An- gebots 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 Prozess- schrien. Obwohl in ERP-Systemen grundsätzlich eine Reihe vordefinierter „best-practice Work- flows“ 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 betriebli- chen 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än- digen, 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 Ab- wicklung 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 Spe- zialisten 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üg- bar, wobei sowohl Umfang als auch alität der angebotenen Erweiterungen stark schwan- ken. 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 Auszeichnungs- sprache 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 über- fordert. 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 er- stellen. Im Gegensatz zum Original arbeitet es jedoch nicht als Konverter, sondern ver- wendet zum Ausdruck eine im Hintergrund laufende Office-Instanz. Für die Druckdoku- mente 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 HTML- Rendering-Engine Webkit, die unter anderem auch in Apple’s Browser Safari zum Einsatz
45vgl. Pansaers, Xavier (Vision & Update on Channel Strategy, Folie 13) 46hp://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 Berichts- Werkzeuge „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 spezia- lisierten 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 un- verhä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 umfang- reich die Funktionstiefe von OpenERP ist. Da es nicht möglich ist, die Abdeckung jedes ak- tuell 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 kriti- schen Bereich Finanzbuchhaltung, gelistet sind.
47hps://launchpad.net/magentoerpconnect 48OpenERP s.a. (Customers References) 49big-consulting GmbH (OpenERP Referenzen)
36 Kapitel 6. 6Implementierungsunterstützung und Support
Ein ERP-System ist ein komplexes Sowarepaket, das auf die Anforderungen jedes einzelnen Unternehmens individuell an- gepasst 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 An- passung vor Ort übernehmen. Darüber hinaus soll die Commu- nity, also auch jeder nicht-zahlende Benutzer der Soware, sich aktiv in den Entwicklungsprozess einbringen können und die Abb. 19.: Partnerstrategie des Herstellers OpenERP s.a. Soware dauerha als kostenlose Open-Source-Soware unter 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 anste- hende Releasewechsel.
37 Dieses Kapitel stellt die Protagonisten im Ökosystem um OpenERP dar, also das Zusammen- spiel 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 Open- Source-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 51Sobola, Sabine (Open Source: Wer haet, wenn es schief geht? - manager magazin - Unternehmen) 52Free Soware Foundation (GNU Affero General Public License (AGPL)) 53vgl. Bundesministerium ür Wirtscha und Technologie (Open-Source-Soware: Ein Leitfaden ür kleine und mi- lere Unternehmen, Kapitel 5. Rechtliche Fragen und Geschäsmodelle) 54vgl. OpenERP s.a. (e OpenERP Publisher Warranty) 55vgl. OpenERP s.a. (Partner Program)
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 ge- listet. Deren Araktivität als Supportdienstleister liegt darin, dass sie den deutschen Wirtschasraum mit den hier gelten- den rechtlichen Anforderungen an Unternehmenssoware sehr gut kennen, örtlich nahe am Kunden sind und nicht zu- letzt eine Kommunikation in deutscher Sprache möglich ist.
6.3. Online-Community
Auf verschiedenen Plaformen wie den öffentlichen Fo- ren auf openerp.com, der Entwicklungsplaform Launchpad, dem Hashtag #OpenERP auf Twier, dem Programmiererfo- rum 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üt- zung 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 herausge- stellt, dass ein hohes Maß an IT-Know-how und viel Geduld bei der Suche nach funktionieren- den 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
56hp://www.openerp.com/community 57In Kapitel 8 finden sich deshalb die ersten Schrie zu einer grundlegenden, zukunsähigen Installation. 58vgl. OpenUpgrade team (OpenUpgrade’s documentation)
39 Kapitel 7. 7Systemarchitektur
Für eine Soware, die weltweit von Tausenden Programmierern weiterentwickelt wird, die in ge- schäskritischen, sicherheitsrele- vanten Unternehmensbereichen eingesetzt wird und die sich fle- xibel an aktuelle und zuküni- ge Anforderungen, wie z. B. den Zugriff auf Unternehmensdaten über Smartphone und Tablet-PC, anpassen soll, ist eine moder- Abb. 21.: Client-Server-Architektur von OpenERP ne, skalierbare Systemarchitektur entscheidend.
Anhand der Kriterien Sowarekonzeption, verwendete Basistechnologien sowie Anpassungs- und 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 So- ware. Welche Programmierparadigmen im OpenERP-Framework zum Einsatz kommen, erläu- tern 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“), Anwendungs- schicht („OpenERP Server“) und Persistenzschicht („PostgreSQL-Datenbank“) konsequent auf eine Drei-Schichten-Architektur59. Neben der Übersichtlichkeit durch die klare Struktur erge- ben 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 Cli- ents, 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.
59vgl. 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 durch- gehend nach dem Paradigma der objektori- entierten Programmierung entwickelt. Um diese Objekte möglichst komfortabel in der zugrunde liegenden, relationalen Datenbank PostgreSQL abzulegen, ist ein sogenann- ter „objektrelationaler Mapper“ erforderlich. Dieser sorgt daür, dass mit wenig Aufwand persistente Geschäsobjekte erstellt, bear- beitet und verwaltet werden können und da- bei das relationale Datenmodell in den Hin- tergrund rückt. Abbildung 23 zeigt am Bei- spiel der Definition des Objektes „Partner“, dass das Beerben der Klasse „Object Service“ (osv.osv) ausreicht, um ein neues, persisten- tes Geschäsobjekt zu definieren. Mit wei- Abb. 23.: Definition des Objektes „Partner“ teren Anweisungen können darüber hinaus unter anderem Aribute und ihre Standard- werte definiert werden und Nebenbedingungen (Constraints) in der Datenbank angelegt wer- den.
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 ent- sprechenden Modulen zum ERP-System wird. Jede Funktionalität, egal ob komplexes Produktions- planungs- 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öglicherwei- se zur gleichen Zeit die gleichen Objekte bearbeiten oder deren Operationen sich gegensei- tig beeinflussen. In diesem Zusammenhang ist die Umsetzung der Transaktionssicherheit und des Sperrverfahrens ausschlaggebend. Darüber hinaus sind in einem Mehrbenutzersystem ver- schiedene 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 au- tomatisch 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ön- nen diese Sicherheitsvorkehrungen jedoch umgehen.
7.1.4.1. Transaktionssicherheit
Eine Transaktion bezeichnet „eine Folge von Programmschrien, die als eine logische Ein- heit 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 Daten- integritä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 ei- ner konsistenten Form sein, wenn er es bereits zu Beginn der Transaktion war.
Isolation (Isolation): Bei gleichzeitiger Ausührung mehrerer Transaktionen dürfen sich die- se nicht gegenseitig beeinflussen. (Siehe dazu auch 7.1.4.2 Sperrverfahren)
60Wikipedia contributors (Transaktion (Informatik)) 61Gabler Wirtschaslexikon (Definition: Transaktion) 62Wikipedia contributors (Transaktion (Informatik))
43 Dauerhaigkeit (Durability): Die Auswirkungen einer Transaktion müssen im Datenbe- stand dauerha bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht „mit der Zeit verblassen“ oder „aus Versehen verloren gehen“. Eine Verschachtelung von Trans- aktionen ist wegen dieser Eigenscha streng genommen nicht möglich, da ein Zurück- setzen (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 Anwendungs- schicht mithilfe eines Funktionsaufrufs (RPC)63 übergeben werden, zu Transaktionen. Dies be- tri sowohl alle Anfragen durch OpenERP-Clients als auch über externen Aufruf von Webser- vices.
7.1.4.2. Sperrverfahren
Falls mehrere Operationen auf dieselben Ressourcen zugreifen, sind Sperrverfahren notwendig, um gegenseitiges Überschreiben von Änderungen zu verhindern. OpenERP verwendet hier- zu 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 Post- greSQL65. 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 unterschiedli- che Lese- und Schreibrechte ür die unterschiedlichen Anwenderrollen erforderlich. Als Grund- voraussetzung ist dazu eine Anmeldung am System erforderlich, die die Benutzerauthentifizie- rung erledigt. Anhand der definierten individuellen und gruppenspezifischen Zugriffsrechte entscheidet das OpenERP-Framework über die ür den Benutzer geltenden Berechtigungen im System.
63vgl. OpenERP s.a. (OpenERP Coding Guidelines) 64vgl. Dony (Comment #3 : Bug #992525 : OpenERP Server) 65vgl. PostgreSQL Global Development Group (PostgreSQL: Documentation: 9.1: Transaction Isolation)
44 In OpenERP finden sich einige, nach typischen Anwendungsszenarien vordefinierte, Benutzer- rollen, 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 Hintergrund- wissen über den Auau von OpenERP erforderlich ist.66
7.1.5. Schnistellen
Eine komplexe Unternehmenssoware kann nicht sinnvoll vollkommen autark und unabhän- gig 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 Libre- Office erstellen und bieten somit eine einfache, benutzerfreund- Abb. 24.: Import- und Export- funktion liche Möglichkeit, die Daten aus dem ERP-System extern weiter- 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 Anwen- dungsschicht über definierte, netzwerktransparente Webservices kommunizieren. Externe An- wendungen können diese XML-RPC-Aufrufe auch direkt ansprechen und Geschäsobjekte in
66vgl. Modi und Collet (Security in OpenERP)
45 der gleichen Integrationstiefe wie der Client bearbeiten, wobei die oben genannten Funktio- nalitä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 „OpenERP- Rails 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 Massendatenver- arbeitung benutzt werden.
Abbildung 25 zeigt beispielha die Änderung des Status eines Produktes auf „Ende Produktle- benszyklus“ aus einer externen Python-Anwendung. Wie am Beispiel ersichtlich wird, erfor- dert XML-RPC ebenso wie der Web-Client eine Authentifizierung am Anwendungsserver mit Benutzername und Passwort und erlaubt anschließend die direkte Bearbeitung des Geschäs- objektes.
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 Sicherheitsvor- kehrungen 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 Con- nectivity“) direkt mit Datenbanken zu verbinden, besteht außerdem eine interessante und ein- fache Möglichkeit, Daten extern weiter zu bearbeiten.
67hps://github.com/lasarux/ooop 68hp://www.akretion.com/en/products-and-services/openerp-ooor-connector 69hp://kele.pentaho.com
46 7.1.5.4. E-Mail-Gateway
Da ein Großteil der Kommunikation in einem Unternehmen per E-Mail erfolgt, ist eine Integra- tion 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äti- gungen 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 Erwei- terungen ü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, kom- merzieller Anbieter wie Oracle oder Microso vorbehalten waren. Vom bekannteren Open- Source-Rivalen „MySQL“ unterscheidet es sich insbesondere durch den höheren Funktions- umfang und die weitgehende Konformität mit dem SQL-Standard ANSI-SQL 200871, während MySQL eher als benutzerfreundliche Datenbank ür Webentwickler gilt.72
70PostgreSQL Global Development Group (PostgreSQL: e world’s most advanced open source database) 71vgl. PostgreSQL Global Development Group (PostgreSQL: Documentation: 9.2: SQL Conformance) 72vgl. PostgreSQL Global Development Group (PostgreSQL: Frequently Asked estions, Q: How does PostgreSQL compare to MySQL?)
47 Aufgrund des objektrelationalen Mappers, über den das OpenERP-Framework jegliche Daten- bankzugriffe abwickelt, ist es grundsätzlich möglich, auch andere Datenbankmanagementsys- teme, 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 in- terpretierte 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“ Soware- entwicklungsprozess, der „mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen“74 auskommt. Die Sprache zeichnet sich unter anderem durch ih- re 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 ei- ne 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 ran- giert.
Mit Python 3.0 wurde vor einigen Jahren eine neue, nicht vollständig abwärtskompatible Ver- sion 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 (sie- he 7.1.1 Client-Server- und Drei-Schichten-Architektur). Die „Extensible Markup Language“
73vgl. Wikipedia contributors (Python (Programmiersprache)) 74Wikipedia contributors (Agile Sowareentwicklung) 75vgl. Python Soware Foundation (otes about Python) 76vgl. TIOBE Soware BV (TIOBE Programming Community Index for September 2012) 77vgl. O’Grady (e RedMonk Programming Language Rankings: September 2012)
48 gilt als sehr universelle Möglichkeit, hierarchische Daten strukturiert in Form von Elementen (siehe Abbildung 26, Zeile 4:
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 Programmie- rung ermöglicht OpenERP auch die Vererbung von Views mit der expliziten Möglichkeit, ein- zelne Felder zu ersetzen, zu entfernen oder neu hinzuzuügen79 – eine Funktionalität, die ins- besondere 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 abzubil- den. Dennoch unterscheiden sich die spezifischen Ausprägungen der Geschäsprozesse in ver- schiedenen 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.
78vgl. Wikipedia contributors (Extensible Markup Language) 79vgl. 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 Nummern- kreise (siehe 9.2) und die Verwaltung der Benutzer und des Berech- tigungskonzeptes 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 je- des Eingabeformular die Möglichkeit, ür Felder Standardwerte zu definieren. Auch der unter 5.3 „Anpassung von Geschäsprozes- sen“ vorgestellte Workflowdesigner zählt in diese Kategorie. Abb. 27.: Menüpunkt „Einstellungen“ Alle diese Änderungen können mithilfe des „Module recorder“ (base_module_record)81 aufgezeichnet und zu wiederverwendba- ren Modulen zusammengefasst werden.
7.3.2. Module
Tiefer gehende Eingriffe in die Funktionsweise des Systems und komplexe Individualprogram- mierungen 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 Ver- zeichnis mit den entsprechenden Python-Programmen, XML-Dateien und weiteren Ressour- cen geührt.
80vgl. OpenERP s.a. (OpenERP 6.1. Functional Demo, ab Minute 06:30) 81vgl. 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 Mo- difikation 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 Sowarever- sion manuell überprü und unter Umständen angepasst werden müssen. Die Installation von OpenERP mithilfe des Versionsverwaltungssystems Bazaar, wie unter Abschni 8.2 beschrie- ben, kann diesen Prozess deutlich erleichtern, da jegliche Änderungen automatisch mitproto- kolliert und dadurch nachvollziehbar werden.
51 Teil IV.
Implementierung
Die Evaluation im vorangegangenen Teil zeigt, dass die unter Kapitel 4.1 „Anforderungskata- log an ein Sowaresystem“ diskutierten Eigenschaen durch OpenERP erüllt werden. Teil IV dokumentiert daher nun die Implementierung von OpenERP im Start-Up-Unternehmen FENE- CON GmbH & Co. KG. Sie untergliedert sich in die Phasen „Installation“, „Vorbereitung zur Inbetriebnahme“ und den beispielhaen „Workflow: Vertriebsprozess ür ein LED-Projekt“.
52 Kapitel 8. 8Installation
Dieses Kapitel beschreibt die Einrichtung der Datenbank (PostgreSQL), des OpenERP-Applikations- servers, des Reportings (LibreOffice) und der Client-PCs. Die Anleitung setzt dabei ein beste- hendes, auf der Distribution Ubuntu 12.0482 basierendes Linux-Betriebssystem mit administra- tivem 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 fol- gende Kommando: sudo apt−get install postgresql
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 postgres −−no−createrole \
82hp://www.ubuntu.com 83hp://www.zentyal.org 84hp://h10010.www1.hp.com/wwpc/de/de/sm/WF06b/15351-15351-4237916-4237917-4237917-4248009- 5163346.html
53 −−no−s u p e r u s e r −−pwprompt openerp Enter password for new role: [OpenERP−Datenbankpasswort] Enter it again: [OpenERP−Datenbankpasswort] e x i t
8.2. Applikationsserver (OpenERP)
Um das Betriebssystem ür den OpenERP-Applikationsserver vorzubereiten, müssen erst eini- ge zusätzliche Programme installiert werden: sudo apt−get install bzr python−dateutil python−feedparser \ python−gdata python−l d a p python−libxslt1 python−lxml \ python−mako python−openid python−psycopg2 python−pybabel \ python−pychart python−pydot python−p y p a r s i n g \ python−reportlab python−simplejson python−t z \ python−vatnumber python−vobject python−webdav \ python−werkzeug python−xlwt 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 adduser −−system −−home=/opt/openerp −−group openerp
Mit einem weiteren Befehl kann man sich nun als „openerp“ einloggen: sudo su − openerp −s / bin / bash
Nun werden die ellcodes zur aktuellen Version 6.1 mithilfe des Versionskontrollsystems Ba- zaar (bzr) in das lokale Verzeichnis „/opt/openerp/version-control-6.1“ her- untergeladen. Dieses Verzeichnis dient in dieser Konfiguration von nun an als zentrale Ablage ür alle Downloads. mkdir version −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 bzr branch lp:openobject −server/6.1 openobject −s e r v e r bzr branch lp:openerp−web/6.1 openerp−web bzr branch lp:openobject −addons/6.1 openobject −addons
54 Die Dateien des OpenERP-Applikationsservers (openobject-server) werden nun mithilfe sym- bolischer 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/openobject −server/ server −6.1 cd s e r v e r −6.1/openerp/addons/ l n −s ~ / v e r s i o n −c o n t r o l −6.1/openobject −addons / * . l n −s ~ / v e r s i o n −c o n t r o l −6.1/openerp−web/addons/* . e x i t
Abschließend muss noch das Startskript aus Anhang B85 übernommen, die mitgelieferte OpenERP- Konfigurationsdatei kopiert und angepasst und die Protokollierung eingerichtet werden. cd /opt/openerp/server −6.1/install/ sudo nano /etc/init .d/openerp−s e r v e r [hier Inhalt einfügen] sudo chmod 755 /etc/init .d/openerp−s e r v e r sudo chown root: /etc/init .d/openerp−s e r v e r sudo update−rc.d openerp−server defaults sudo cp openerp−server.conf /etc/openerp−server .conf sudo chmod 640 /etc/openerp−server .conf sudo chown openerp: /etc/openerp−server .conf sudo nano /etc/openerp−server .conf db_password = [OpenERP−Datenbankpasswort] admin_passwd = [OpenERP−Administrationspasswort] logfile = /var/log/openerp/openerp−s e r v e r . l o g sudo mkdir /var/log/openerp/ sudo chown openerp:root /var/log/openerp/
Der OpenERP-Applikationsserver mit dem integrierten Webclient wird nun bei jedem System- start automatisch ausgeührt. Mit dem Befehl sudo service openerp−server start
85vgl. 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 Ab- läufe in der Protokolldatei können währenddessen mit diesem Befehl verfolgt werden: t a i l −f /var/log/openerp/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 apt−get install libreoffice −writer python−s e t u p t o o l s sudo nano /etc/init.d/libreoffice −h e a d l e s s sudo chmod 755 /etc/init.d/libreoffice −h e a d l e s s sudo chown root: /etc/init.d/libreoffice −h e a d l e s s sudo update−rc.d libreoffice −headless defaults
86vgl. Alistek Ltd. (Aeroo Reports Linux server)
56 Nun muss das Aeroo-Modul in die Installation integriert werden: sudo su − openerp −s / bin / bash 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:aeroolib aeroolib cd ~ / s e r v e r −6.1/openerp/addons/ l n −s ~ / v e r s i o n −c o n t r o l −6.1/aeroo/* . e x i t cd /opt/openerp/version −c o n t r o l −6.1/aeroolib/aeroolib/ sudo python ./setup.py install
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“ (re- port_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 Re- portings 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 ver- wendeten Webtechnologien können sie einfach per Webbrowser auf den OpenERP-Server zu- greifen: h t t p : / / [ IP−Adresse des Servers]:8069
57 Kapitel 9. 9Vorbereitung 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 deut- lich im Vergleich zur Einührung eines ERP-Systems in einem bestehenden kleinen oder mit- telständischen Unternehmen; insbesondere ist weder eine aufwendige Migration bestehender Daten erforderlich, noch müssen komplexe bestehende Workflows im System abgebildet wer- den.
Im Falle der FENECON GmbH & Co. KG konnten die, bis zur Einührung von OpenERP ange- fallenen, 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 vorde- finierten best-practice Prozesse ausreichend, sodass die Installation des Moduls „Verkaufsma- nagement“ (sale) ausreichte, um die im „Anforderungskatalog bei Unternehmensgründung“ (Unterabschni 4.1.1) geforderte „Abbildung eines einfachen Vertriebsprozesses“ zu ermögli- chen.
Die weiteren individuell notwendigen und gewünschten Anpassungen unterscheiden sich na- turgemäß je nach Firma sehr. Zwei der Customizing-Maßnahmen, die ür die FENECON erfor- derlich 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 Cor- porate Design des Unternehmens ist jedoch aufgrund der verwendeten Auszeichnungssprache RML sehr aufwendig. Aus diesem Grund wurden die Vorlagen ür Dokumente, die an den Kun- den 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 „Ein- stellungen | 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 Re- port ü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.
87hp://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 Rech- nung im Jahr 2012 oder „SO001“ ür den ersten Verkaufsaurag. Um diese Nummernkreise anzupassen, ist ein Eingriff in die „Sequenzen“ unter „Einstellungen | Konfiguration | Sequen- zen 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 Jah- reszahl 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 Kapitel 10. 10Workflow: 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 Kapi- tel einen einfachen Geschäsprozess zur Abwicklung des Vertriebs von LED-Leuchtmieln. Gleichzeitig dient es der Demonstration der Eingabe- und Ausgabeparadigmen im OpenERP- Webclient, 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 | Ver- kaufsaurä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 Stamm- daten 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 Fak- turierungsregel. In diesem Beispiel wird die Regel „Lieferung und Fakturierung nach Abru“ verwendet, die dem oben dargestellten Workflow entspricht. Dabei werden im Anschluss Rech- nung und Lieferschein nach Bedarf erstellt. Alternativ ist gerade im Onlinehandel o die Me- thode „Zahle vor Lieferung“ passend, die mit Bezahlung der Rechnung automatisch eine Wa- renauslieferung 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 Ein- trag 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 Pro- duktlieferung“ 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
Kapitel 11. 11Zusammenfassung
Ziel dieser Bachelorarbeit und des dahinterstehenden Projektes »Evaluation und Implementie- rung 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 Kapitel 12. 12Ausblick
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 Pincka- ers, 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 Fra- ge 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 Risi- ken 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.
88hp://www.salesforce.com 89hp://www.facebook.com 90OpenERP s.a. (OpenERP - Using 7.0. is as easy as 10 clicks)
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 bei- de 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 Co- verity Scan Report. : http : / / coverity . com / html / press / open - source - code-quality-on-par-with-proprietary-code-in-2011-coverity-scan- report.html (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.
69 EU-Kommission (Mai 2003). Empfehlung der Kommission vom 6. Mai 2003 betreffend die Definiti- on 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 - planning-system.html (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 : / / www . handelsblatt . com / unternehmen / mittelstand / software - fuer - den - ueberblick-am-offenen-herzen/2697732.html (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. ist.psu.edu/viewdoc/download?doi=10.1.1.83.6372&rep=rep1&type=pdf# page=153 (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: //www.theopensourcerer.com/2012/02/how-to-install-openerp-6-1-on- ubuntu-10-04-lts/ (besucht am 16. 09. 2012).
70 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- transaction (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-on- channel-strategy (besucht am 09. 09. 2012). Partsch, Helmuth (Juni 2010). Requirements-Engineering systematisch: Modellbildung ür so- waregestü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).
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& oldid=104297053 (besucht am 27. 06. 2012). — (Sep. 2012c). Extensible Markup Language. de. Page Version ID: 107429881. : http: //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) &oldid=108009097 (besucht am 13. 09. 2012). — (Juli 2012e). Soware as a Service. de. Page Version ID: 105704135. : http://de. wikipedia . org / w / index . php ? title = Software _ as _ a _ Service & oldid = 105704135 (besucht am 31. 08. 2012). — (Juli 2012). Transaktion (Informatik). de. Page Version ID: 106066896. : http:// de.wikipedia.org/w/index.php?title=Transaktion_(Informatik)&oldid= 106066896 (besucht am 11. 09. 2012).
72 Abbildungsverzeichnis
1. Logo der FENECON GmbH & Co. KG ...... 8
2. Logo der Open Source Initiative (hp://opensource.org/trademarks/opensource/print/opensource-rgb.ti) ...... 12 3. 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 & Soware- Based 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) ...... 21 6. Mielstandssoware: Sage New Classic (hp://www.sage.de/images/smb/screenshots/startseite-gross.jpg) ...... 22 7. 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)) ...... 37 20. OpenERP-Partner in Deutschland OpenStreetMap und Mitwirkende, CC BY-SA hp://www.openstreetmap.org und hp://creativecommons.org/licenses/by-sa/2.0 .... 39
21. Client-Server-Architektur von OpenERP (Stéphane Tteyssier (hp://blog.octo.com/en/first-steps-with-openerp)) ...... 40 22. Detaillierte Architektur von OpenERP (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 „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
74 Tabellenverzeichnis
1. Mitarbeiterzahlen und finanzielle Schwellenwerte zur Definition der Unternehmen- sklassen ...... 15
2. Übersicht über Open Source ERP-Systeme ...... 24
75 Teil VII.
Anhang
76 Anhang A. Die Definition quelloffener Soware A 91 („Open Source Soware“)
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 Soware- Paketes, das Programme unterschiedlichen Ursprungs enthält, zu verschenken oder zu verkau- fen. 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 ell- code 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,
91Ronneburg (Debian GNU/Linux Anwenderhandbuch, Version 1.9)
77 den ellcode zum Selbstkostenpreis zu bekommen, vorzugsweise als gebührenfreien Down- load aus dem Internet. Der ellcode soll die Form eines Programms sein, die ein Program- mierer 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 weitervertrie- ben 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, aus- drü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 ein- zusetzen. 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 er- halten, 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 Anhang B. BOpenERP Startskript (/etc/init.d/openerp-server)
#!/bin/sh
### BEGIN INIT INFO # Provides: openerp-server # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Should-Start: $network # Should-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Enterprise Resource Management software # Description: Open ERP is a complete ERP and CRM software. ### END INIT INFO
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 Anhang C. CLibreOffice Startskript (/etc/init.d/libreoffice-headless)
#!/bin/sh
### BEGIN INIT INFO # Provides: libreoffice-headless # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Should-Start: $network # Should-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: LibreOffice Headless Server # Description: LibreOffice Headless Server ### END INIT INFO
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 Anhang D. DRechnungserstellung 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
IDS[0].MOBILE_PHONE> < SET L ANG ( O . PARTNER _ ID . LANG OR ' DE _ D E ' ) > < CHOOSE > < WHEN TEST = " OBJECTS [ 0 ] . TYPE = = ' OUT _ INVOICE ' " > < CHOOSE > < WHEN TEST = " OBJECTS [ 0 ] . STATE = = ' OPEN ' OR OBJECTS [ 0 ] . STATE = = ' PAID ' " > < _ ( " R E CHNUNG " ) > < _ ( " N R . " ) > < OBJECTS [ 0 ] . NUMBER > < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . STATE = = ' PROFORMA 2 ' " > < _ ( " P ROFORMARECHNUNG " ) > < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . STATE = = ' DRAFT ' " > < _ ( " R ECHNUNG (ENTWURF)")> < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . STATE = = ' CANCEL ' " > < _ ( " R ECHNUNG (STORNIERT)")> < / WHEN > < / CHOOSE > < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . TYPE = = ' OUT _ REFUND ' " > < _ ( " G UTSCHRIFT " ) > < _ ( " N R . " ) > < OBJECTS [ 0 ] . NUMBER > < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . TYPE = = ' IN _ INVOICE ' " > < _ ( " E INGANGSRECHNUNG " ) > < _ ( " N R . " ) > < OBJECTS [ 0 ] . NUMBER > < / WHEN > < WHEN TEST = " OBJECTS [ 0 ] . TYPE = = ' IN _ REFUND ' " > < _ ( " E INGANGSGUTSCHRIFT " ) > < _ ( " N R . " ) > < OBJECTS [ 0 ] . NUMBER > < / WHEN > < / CHOOSE > <_("BEZEICHNUNG")> <_("ANZAHL <_("EINHEI <_("EINZELPR <_("GESAMTPRE ")> T")> EIS")> IS")> > % <_("ZWISCHENSUMME <_("GESAMTSUMME <_("ES GELTEN UNSERE ALLGEMEINEN GESCHÄFTSBEDINGUNGEN.")> <_("MIT FREUNDLICHEN GRÜSSEN")> - 2 - Anhang E. EBelege 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] Beleg-Nr.: VA0105 Datum: 25.09.2012 Bestellbestätigung Nr. VA0105 Sehr geehrter Herr Mustermann, hiermit bestätige ich Ihre Bestellung: Bezeichnung Anzahl Einheit Einzelpreis Gesamtpreis [1002090101] FENECON-E27-9W 1,000 Stück 20,16 € 20,16 € LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Zwischensumme (netto) 20,16 € zzgl. 19% USt 3,83 € Gesamtsumme (brutto) 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 Geschäftsführer: Franz-Josef Feilmeier Bank: Sparkasse Deggendorf Finanzamt Deggendorf Brunnwiesenstr. 4, 94469 Deggendorf Registergericht Deggendorf: HRA 2540 BLZ: 74150000 Ust-ID-Nr.: DE277646519 Tel.: +49 991 6488000 0 Persönlich haftende Gesellschafterin: Konto: 420151987 Steuernummer: 108/159/07006 Fax: +49 991 6488000 9 FENECON Verwaltungsgesellschaft mbH BIC: BYLADEM1DEG E-Mail: [email protected] Registergericht Deggendorf: HRB 3635 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 Einheit [1002090101] FENECON-E27-9W 1,000 Stück LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Lieferung erhalten: ______Ort, Datum Unterschrift FENECON GmbH & Co. KG Geschäftsführer: Franz-Josef Feilmeier Bank: Sparkasse Deggendorf Finanzamt Deggendorf Brunnwiesenstr. 4, 94469 Deggendorf Registergericht Deggendorf: HRA 2540 BLZ: 74150000 Ust-ID-Nr.: DE277646519 Tel.: +49 991 6488000 0 Persönlich haftende Gesellschafterin: Konto: 420151987 Steuernummer: 108/159/07006 Fax: +49 991 6488000 9 FENECON Verwaltungsgesellschaft mbH BIC: BYLADEM1DEG E-Mail: [email protected] Registergericht Deggendorf: HRB 3635 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.: RE12209 Referenz: VA0105 Datum: 25.09.2012 Rechnung Nr. RE12209 Sehr geehrter Herr Mustermann, hiermit stellen wir Ihnen folgende Artikel in Rechnung: Bezeichnung Anzahl Einheit Einzelpreis Gesamtpreis [1002090101] FENECON-E27-9W 1,000 Stück 20,16 € 20,16 € LED-Lampe als Ersatz für 60W Glühbirne mit großer Schraubfassung (E27) Zwischensumme (netto) 20,16 € zzgl. 19% USt 3,83 € Gesamtsumme (brutto) 23,99 € Zahlungsbedingungen: Vorkasse Es gelten unsere Allgemeinen Geschäftsbedingungen. Mit freundlichen Grüßen Stefan Feilmeier FENECON GmbH & Co. KG Geschäftsführer: Franz-Josef Feilmeier Bank: Sparkasse Deggendorf Finanzamt Deggendorf Brunnwiesenstr. 4, 94469 Deggendorf Registergericht Deggendorf: HRA 2540 BLZ: 74150000 Ust-ID-Nr.: DE277646519 Tel.: +49 991 6488000 0 Persönlich haftende Gesellschafterin: Konto: 420151987 Steuernummer: 108/159/07006 Fax: +49 991 6488000 9 FENECON Verwaltungsgesellschaft mbH BIC: BYLADEM1DEG E-Mail: [email protected] Registergericht Deggendorf: HRB 3635 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 28.09.2012 ______(Datum) (Unterschrift des Studenten) 2. 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)