Evaluation und Implementierung des Open

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