Zur PDF-Version

Berufsakademie Sachsen
Staatliche Studienakademie Dresden
Studienrichtung Medienproduktion
Wildsmile Studios
Rudolf-Leonhard-Straße 54
01097 Dresden
Machbarkeitsstudie zur Erweiterungsmöglichkeit des
E-Commerce-Systems Magento um die Steuerungsmöglichkeit
produktionsrelevanter Managementprozesse für den Druck
Diplomarbeit
zur Erlangung des Grades
Diplom-Informatiker (BA)
in der Studienrichtung Medienproduktion
eingereicht von:
Christoph Joschko
29. Januar 1984
1. Gutachter:
Herr Dipl.-Medienkünstler Andreas Ullrich
2. Gutachter:
Herr Dr.-Ing. Ulf Martin
Tag der Themenübergabe: 19. Mai 2010
Tag der Einreichung:
26. August 2010
1
AUFTRAGSBLATT E²
2
Autorenreferat
JOSCHKO, Christoph: Machbarkeitsstudie zur Erweiterungsmöglichkeit des E-CommerceSystems Magento um die Steuerungsmöglichkeit produktionsrelevanter Managementprozesse für den Druck, Berufsakademie Sachsen, Staatliche Studienakademie, Studiengang
Medienproduktion, Diplomarbet, 2009
E-Commerce ist für heutige Unternehmen kaum noch wegzudenken, Online-Shops sind
dadurch alltäglich geworden. Die Software Magento setzte als OpenSource-Lösung für
Online-Shops neue Maßstäbe. Auch stark individualisierbare Produkte wie Druckerzeugnisse können so mit einer benutzerfreundlichen Lösung online vertrieben werden. Die vorliegende Arbeit beschäftigt sich mit dem Szenario des Online-Vertriebs und anschließender Fertigung, einer Reihenfolge wie sie bei Druckportalen und anderen Fertigungen üblich ist. Magentos Erweiterungsmöglichkeiten werden hinsichtlich einer Einbindung der
Produktionsprozesse in die Auftragsverwaltung der E-Commerce Software untersucht. Am
Beispiel der Druckagentur stickma.de werden die aufgezeigten Lösungsansätze verglichen
und eine Verallgemeinerung auf andere Fertigungen vorgenommen. Abschließend werden
die Ergebnisse ausgewertet und die Machbarkeit der Verbindung von einem auf Magento
basierten Online-Shop mit einer Produktionssteuerung bewertet.
3
Inhaltsverzeichnis
1 Einleitung........................................................................................................................7
1.1 Motivation......................................................................................................................7
1.2 Ziel und Aufbau der Arbeit ............................................................................................8
1.3 Beschreibung der Software Magento............................................................................9
2 Aktueller Bestellablauf (Ist-Zustand)...........................................................................10
2.1 Auftragseingang...........................................................................................................11
2.2 Auftragsannahme.........................................................................................................11
2.3 Druckvorstufe..............................................................................................................12
2.3.1 Datencheck..............................................................................................................14
2.3.2 Datenaufbereitung....................................................................................................15
2.3.3 Bogensatz................................................................................................................15
2.4 Druck...........................................................................................................................17
2.5 Weiterverarbeitung......................................................................................................17
2.6 Qualitätskontrolle.........................................................................................................18
2.7 Verpackung und Versand............................................................................................18
2.8 Fakturierung................................................................................................................19
2.9 Besonderheiten...........................................................................................................19
3 Analyse des Bestellablaufs.........................................................................................20
3.1 Reihenfolgen und Abhängigkeiten...............................................................................20
3.2 Der Bestellablauf als Geschäftsprozess......................................................................21
3.3 Schwachstellen & Verbesserungsmöglichkeiten.........................................................23
3.3.1 Mangelnde Kenntnis über den Auftragsstatus..........................................................23
3.3.2 Uneinheitliche Datenhaltung.....................................................................................24
4
3.3.3 Unzureichende Automatisierung einzelner Aktivitäten..............................................24
3.3.4 Mangelnde Erfassung der Ereignisse.......................................................................25
4 Überlegungen zum Soll-Zustand................................................................................25
4.1 Zusammenfassung der Parameter für einen Druckauftrag..........................................26
4.2 Anwendungsfälle und Sichten.....................................................................................27
4.2.1 Datencheck..............................................................................................................28
4.2.2 Bogensatz................................................................................................................28
4.2.3 Druck........................................................................................................................29
4.2.4 Weiterverarbeitung...................................................................................................29
4.2.5 Qualitätskontrolle......................................................................................................29
4.2.6 Versand....................................................................................................................30
4.3 Entscheidung zum Erreichen des Soll-Zustandes.......................................................30
5 Schnittstelle zwischen Online-Shop und Produktionen...........................................31
5.1 Anpassung von Magento.............................................................................................32
5.1.1 Core-Änderung.........................................................................................................32
5.1.2 Module-Extension.....................................................................................................33
5.1.3 REST-Integration......................................................................................................35
5.1.4 Magento Core-API....................................................................................................37
5.2 Auswertung und Auswahl der Anpassungsmöglichkeiten............................................40
6 Lösung für den Agenturbetrieb....................................................................................41
6.1 Bessere Kenntnis über den Auftragsstatus.................................................................42
6.2 Vereinfachte Datenhaltung..........................................................................................43
5
6.3 Automatisierung von Arbeitsschritten..........................................................................43
7 Übertragbarkeit der Erkenntnisse...............................................................................44
8 Fazit...............................................................................................................................45
8.1 Machbarkeit.................................................................................................................45
8.2 Vor- und Nachteile von Magento für das Thema.........................................................46
8.3 Möglichkeiten & Ausblick.............................................................................................47
Quellenverzeichnis.............................................................................................................48
Tabellenverzeichnis............................................................................................................49
Abbildungsverzeichnis........................................................................................................50
Eidesstattliche Erklärung....................................................................................................51
6
1 Einleitung
1.1 Motivation
Das Unternehmen „Wildsmile Studios“ betreibt unter der Marke „stickma.de“ eine Druckagentur für individuell gestaltete Aufkleber. Die im Bogen-Offsetdruck gefertigten und optional durch Lackierung veredelten Produkte werden in der anschließenden Weiterverarbeitung je nach Kundenwunsch auf ein rechteckiges Format oder nach einer individuellen
Konturlinie geschnitten. Die eigentliche Produktion im Offsetdruck und die anschließende
Weiterverarbeitung erfolgt durch Geschäftspartner, mit denen ein enges Kooperationsverhältnis besteht. Das Aufgabenfeld der Agentur setzt sich aus den Schwerpunkten Vertrieb
und Druckvorstufe zusammen, sowie der Unterstützung der engagierten Druckereien bei
besonders wichtigen Produktionen. Für den Vertrieb wurde zunächst ein Online-Shop verwendet, welcher als Eigenlösung programmiert wurde. Der Online-Shop bedurfte aufgrund
des nicht mehr zeitgemäßen Standes der Software und damit steigender Wartungs- und
Kompatibilitätsprobleme einer dringenden Ablösung. Im Jahr 2009 wurde die E-Commerce-Software Magento eingeführt, welche im Jahr zuvor als OpenSource-Projekt von der
Varien Inc. veröffentlicht wurde. Die Eignung der Software Magento als Online-Shop für
eine Druck-Agentur wurde bereits dokumentiert sowie die Einführung des Systems angedeutet1.
Mit der nun abgeschlossenen Implementierung von Magento ergibt sich die Gelegenheit,
auch die Struktur des Agenturbetriebs neu zu überdenken und Möglichkeiten der Weiterentwicklung aufzudecken. Die bisherige Erfahrung mit der neuen Software zeigte, dass
zwar der Online-Vertrieb komfortabler wurde, jedoch die Organisation der Auftragsabwicklung außerhalb von Magento stattfindet. Sicher ist es kein Muss, dass ein Online-Shop neben der Kunden- und Auftragsverwaltung auch die Prozesse der Auftragsabwicklung erfasst, jedoch wäre so aus der Auftrags- und Kundenverwaltung ein unmittelbarer Zugriff
auf den Produktionsprozess möglich. Eine verbesserte Transparenz und effiziente Kommunikation mit den Kunden könnte die Folge einer solchen Arbeitsumgebung sein und
zum Mehrwert des Online-Shops beitragen2.
1
2
[METSCHKE 2009], Seite 59
[METSCHKE 2009], Seite 11
7
Nach Möglichkeit soll eine Vereinfachung der Auftragsabwicklung über die Unternehmensgrenzen hinweg erfolgen und gleichzeitig die Kooperation mit vorgenannten Partnern der
Druckproduktion optimieren.
Entscheidend ist, dass im hier untersuchten Szenario Produkte vertrieben werden, die erst
nach Auftragseingang gefertigt werden können. Magento deckt den Bereich E-Commerce
dahingehend ab, als dass Produkte ab Lager vertrieben werden können und die Produktion nicht Teil der Bestellabwicklung ist.
Ziel der vorliegenden Arbeit ist daher, die gegebene OpenSource-Lösung dahingehend zu
erweitern, dass sowohl von Seiten der Agentur als auch ihrer Partnerunternehmen eine
vereinfachte Verwaltung der laufenden Druckaufträge möglich wird und Informationen über
den Produktionsprozess in Magento verfügbar werden.
Über die gegebene Situation der Agentur hinaus soll auch Magentos Erweiterbarkeit und
Flexibilität dahingehend untersucht werden, inwiefern eine grundsätzliche Verknüpfung
von Online-Vertrieb und Produktion außerhalb der Druckbranche möglich ist.
1.2 Ziel und Aufbau der Arbeit
Die vorliegende Arbeit gliedert sich wie folgt:
Zunächst erfolgt im Rahmen des untersuchten Unternehmens eine Bestandsaufnahme der
aktuellen Bestellabwicklung. Dabei werden die nötigen Arbeitsschritte und daran beteiligten
Stationen
dargestellt
und
deren
Zugriff
auf
Auftragsdaten
festgehalten.
In der folgenden Analyse des Ist-Standes wird dargestellt, an welchen Stellen eine in
Magento integrierte Lösung Schwachstellen im Prozess umgehen oder den Prozess zumindest vereinfachen könnte.
8
Daraus soll anschließend ein System definiert werden, welches den Produktionsprozess
des Unternehmens stützen könnte, während Magento als Verkaufslösung dient. Dabei
werden die in der Bestandsaufnahme erfassten Arbeitsschritte einbezogen und daraus Anwendungsfälle ermittelt, welche das ergänzende System umfassen sollte.
Folgend soll untersucht werden, welche Möglichkeiten zur Erweiterung Magento bietet und
inwiefern diese ausreichen, um das zuvor modellierte System in die E-Commerce-Software zu integrieren. Dabei werden unter anderem die von Magento bereitgestellten Möglichkeiten der modularen Erweiterung betrachtet.
Danach wird versucht, die anhand des untersuchten Szenarios gewonnenen Erkenntnisse
im allgemeinen Rahmen anzuwenden. Dabei werden mit Blick auf Magento Besonderheiten bei der Lösungsfindung aufgezeigt, die bei der Prozessgestaltung mit einbezogen werden sollten.
Abschließend wird die Übertragbarkeit der Erkenntnisse ausgewertet und bilanziert, in welchem Verhältnis von Aufwand und Nutzen die gezeigte Lösung auf Basis von Magento zu
realisieren wäre. Ein Teil der Auswertung geht auf die generelle Eignung von Magento für
produzierende Unternehmen ein und stellt dahingehend Aspekte dar, die bei der weiteren
Entwicklung mit Magento relevant sein könnten.
1.3 Beschreibung der Software Magento
Magento wurde im März 2008 von der Varien Inc. veröffentlicht, die mittlerweile gleichnamig als Magento Inc. firmiert. Die Bezeichnung Magento bezieht sich folgend immer auf
die Software. Ist hingegen das gleichnamige Unternehmen gemeint, wird dies erwähnt
bzw. geht aus dem Kontext eindeutig hervor. Magento ist als reine Webanwendung konzipiert und nach dem Modell-View-Controller-Pattern (MVC) in der Skriptsprache PHP 5.2
programmiert. Dabei wurde auf das Zend-Framework der Zend Technologies Ltd. zurückgegriffen. Zur Datenhaltung wird eine MySQL-Datenbank verwendet, welche mithilfe des
Entity-Attribute-Value-Modells (EAV) organisiert ist. Dadurch erreicht das System ein hohes Maß an Skalierbarkeit, da beispielsweise Datenbestände hinzugefügt werden können,
ohne die Abfragelogik des Systems anpassen zu müssen. Gleichzeitig hat das EAV-Modell
9
jedoch zur Folge, dass die Datenbank eine gewisse Komplexität aufweist und Abfragen in
zahlreichen Teilabfragen realisiert werden. Daher arbeitet Magento mit Caches um die bei
Datenbankabfragen entstehenden Geschwindigkeitsdefizite zu kompensieren. Daraus entstehende, an den Browser ausgegebene HTML-Seiten werden ebenfalls in einem separaten Cache abgelegt.
Die Konfiguration sowohl der Oberflächen im Administrations- und im Shop-Bereich als
auch der für Abfragen verwendeten Schnittstellen (zum Model) werden in Form von XMLDateien hinterlegt.
Magento erlaubt den Betrieb mehrerer Domains, welche systemweit als „Sites“ bezeichnet
werden. Pro „Site“ können mehrere Online-Shops (Stores) angelegt werden, deren Ausgabe separat als „Store-View“ konfiguriert werden kann. So können beliebige Kombinationen
aus Site, Store und Store- View angelegt werden, wobei die Abwicklung der einzelnen
Käufe zentral über eine Administrationsoberfläche erfolgt.
2 Aktueller Bestellablauf (Ist-Zustand)
Nach einer Bestellung durchläuft ein Auftrag bei stickma.de mehrere Stationen, an denen
er bearbeitet wird. Solange der Auftrag nicht den tatsächlichen Produktionsschritt durchläuft, also noch kein physisches Druckerzeugnis vorliegt, kann er als eine Menge von Informationen angesehen werden. An den einzelnen Stationen der Verarbeitung werden Teilmengen dieser Informationen aufgerufen und gegebenenfalls mit zusätzlichen Daten ergänzt, die für die weitere Bearbeitung nötig sind. Dabei werden die Daten von unterschiedlichen Benutzern (Mitarbeitern) aufgerufen, die unterschiedliche Sichtweisen auf den Auftrag haben. So sind in der grafischen Bearbeitung das Druckmotiv und alle damit zusammenhängenden Informationen, wie das Format und ggf. das Material des Bedruckstoffes,
relevant. Informationen zur Fakturierung und Lieferung hingegen sind für die Auftragsannahme, Buchhaltung bzw. den Versand von Bedeutung. Die folgenden Abschnitte des Kapitels sollen darstellen, welche Stationen ein Auftrag im derzeitigen Bestellablauf durchläuft und wie die Mitarbeiter auf die zum Auftrag gehörende Informationsmenge zugreifen.
10
2.1 Auftragseingang
Druckaufträge werden über den auf Magento basierenden Online-Shop vom Kunden erstellt. Dabei steht eine vorgegebene Auswahl an Bedruckstoffen und Formaten zur Verfügung. Die für eine Auftragserteilung benötigten Daten kann der Kunde selbst eingeben.
Angaben zu
– Material des Bedruckstoffes
– Format des Druckerzeugnisses
– Auflage des Druckerzeugnisses
– Druckmotiv (optional)
– Datencheck (optional)
– Weiterverarbeitung
– Lieferadresse
– Rechnungsadresse
können im Laufe des Bestellvorgangs eingegeben werden. Die beim Bestellvorgang gesammelten Daten werden per E-Mail an eine vorgegebene E-Mail-Adresse des Unternehmens versendet, wo sie von einem Sachbearbeiter abgerufen und gelesen werden. Außerdem erfasst Magento die Daten in seiner Auftragsverwaltung. Das Druckmotiv kann optional vom Kunden als Datei im Browser übertragen werden, womit es auf einem Server der
Agentur gespeichert wird. Alternativ besteht die Möglichkeit, das Druckmotiv später per EMail zu senden. Alle anderen Angaben (s.o.) sind zwingend erforderlich, um den Bestellvorgang abschließen zu können. In jedem Fall erhält der Kunde eine Dateneingangsbestätigung per E-Mail, die automatisch vom Online-Shop erstellt und versendet wird.
2.2 Auftragsannahme
Die Auftragsannahme wird von einem dafür eingewiesenen Sachbearbeiter übernommen,
der somit Kenntnis über die eingehenden Druckaufträge besitzt. Dieser überprüft zunächst
alle bei der Bestellung angegebenen Daten auf Plausibilität und holt ggf. fehlende Informationen beim Kunden ein.
11
Widersprüchlichkeiten in den Bestelldaten können z.B. die Kombination aus Format und
Weiterverarbeitung sein, wenn das bestellte Format nicht für den Schnitt geeignet ist und
nur mittels einer Formstanzung hergestellt werden kann. Nicht überprüft werden hingegen
Fehler bei der Erstellung der Druckdaten, wie eine zu geringe Auflösung oder fehlender
Beschnitt. Dies ist Teil des Druckdatenchecks, der als kostenpflichtige Option bei der Bestellung angegeben werden kann. Kunden, die diese Option nicht bestellen, erhalten umgehend eine Auftragsbestätigung, unabhängig von der Richtigkeit der Druckdaten.
Wünscht ein Kunde die Überprüfung der Druckdaten, erfolgt die Auftragsbestätigung mit
einem entsprechenden Hinweis, dass die Druckbarkeit der gesendeten Daten überprüft
wird.
Neben der Überprüfung der bestehenden Auftragsdaten, werden bei der Auftragsannahme
weitere, für die Produktion relevante Parameter zu den Auftragsdaten hinzugefügt. So
kann an diese Stelle ein Produktionstermin, ggf. abhängig von vereinbarten Lieferzeiten,
festgelegt werden. Der einzelne Auftrag wird einem geplanten Produktionstermin zugeordnet, für den der Druck des gesamten Bogens vorgesehen ist. Die Zuordnung erfolgt über
die Speicherung der Druckdaten in einer vereinbarten Ordnerstruktur. Diese Struktur ist
wiederum unterteilt in die im Online-Shop angebotenen Bedruckstoffe, auf denen produziert werden kann.
Sobald die Druckdaten in der vorgesehenen Ordnerstruktur einsortiert wurden, sind Sie für
die folgenden Verarbeitungsstationen verfügbar. Anschließend wird die Rechnung für den
Auftrag angelegt. Je nach Zahlungsvereinbarung wird diese sofort an den Kunden versendet (Vorkasse), oder für der Versandabteilung hinterlegt. Außerdem wird dort ein Formular
mit den Lieferdaten und einer Kopie des Druckmotives hinterlegt.
2.3 Druckvorstufe
In der Druckvorstufe werden die zu einem Auftrag gehörenden Druckdaten betrachtet. Das
bei einer im Online-Shop ausgelösten Bestellung optional übertragene Druckmotiv muss
spätestens für die folgend beschriebenen Prozesse vorliegen. Die Druckvorstufe wird von
mehreren Bearbeitern durchgeführt, deren Aufgabenfeld hauptsächlich im graphischen Bereich liegt. Die vorliegenden Druckaufträge können im Rahmen der Druckvorstufe über12
prüft, verändert und für den Bogendruck einem zu produzierenden Druckbogen zugeordnet werden. Die Aufgabenteilung erfolgt in der Regel derart, dass (je nach Menge der Aufträge) mehrere Mitarbeiter die Druckdaten überprüfen, jedoch ein Einzelner für die Erstellung eines Druckbogens zuständig ist. Ähnlich wie bei der Auftragsannahme ist auch hier
nur ein Mitarbeiter in Kenntnis über den Bearbeitungsstand eines Druckbogens und somit
der darauf enthaltenen Aufträge. Um diesen Arbeitsschritt auch aus Sicht der Auftragsannahme, und somit der Kontaktstelle zum Kunden, nachvollziehbar zu machen, werden die
Dateien der Druckmotive entsprechend ihres Bearbeitungsstandes umbenannt oder entsprechend eines vereinbarten Systems an einen anderen Speicherort verschoben. Grafik
1 veranschaulicht dieses Kennzeichnungssystem, dass der internen Kommunikation des
Auftragsstatus dient.
Abbildung 1: Kennzeichnungssystem für Druckdaten bei stickma.de, Quelle: Wildsmile Studios, 2010
13
2.3.1 Datencheck
Das vom Kunden übermittelte Druckmotiv wird anhand verschiedener Parameter auf seine
Druckbarkeit hin überprüft. Dabei werden sowohl qualitätsrelevante Parameter, als auch
logische Zusammenhänge zwischen Druckmotiv und den weiteren Auftragsdaten überprüft. Tabelle 1 zeigt die Auflistung der zu überprüfenden Parameter und deren Zusammenhänge.
Kriterium
qualitätsrelevante
Auflösung
Beschnitt
Farbmodus
produktionsrelevante
Farbauftrag
Format
Anforderung
Zusammenhang mit
min. 300dpi
min. 2mm
CMYK
bestelltes Format
max. zulässiger Farbauftrag
min. Schnittgröße = 35mm
max. Bogenformat = 70x100cm
Bedruckstoff
Weiterverarbeitung
Bedruckstoff
Tabelle 1: Kriterien zur Überprüfung der Druckbarkeit (Datencheck)
2.3.2 Datenaufbereitung
Ergibt der Datencheck (vgl. Abschnitt 2.3.1 ), dass fehlerhafte Druckdaten vorliegen, oder
wünscht ein Kunde ausdrücklich eine Ergänzung oder Veränderung der Druckdaten, wird
diese im Rahmen des Druckdatenchecks vorgenommen. So können dabei erkannte Fehler gegebenenfalls korrigiert werden. Die Veränderung der Druckdaten bedarf der anschließenden Freigabe durch den Kunden. Dieser erhält dazu ein Freigabeformular mit
dem veränderten Druckmotiv und allen Auftragsdaten, dass er unterschrieben postalisch
oder per Fax zurücksendet.
Die Bearbeitung der Druckdaten wird von einem dafür zuständigen Mitarbeiter vorgenommen, meistens demjenigen, der auch die übrigen Druckdaten überprüft. Die für die Druckfreigabe zusätzlich benötigte Zeit, also für Zustellung, Überprüfung und Rücksendung des
Freigabeformulars, muss dabei mit eingeplant werden. Erst nach erfolgter Druckfreigabe
kann das Motiv druckfertig auf den Sammelbogen gesetzt werden kann. Die Kommunikation mit dem Kunden erfolgt in der Regel über die Station der Auftragsannahme. Der Mitar14
beiter der grafischen Bearbeitung sendet das erstellte Freigabeformular an den Mitarbeiter
der Auftragsannahme, der es an den Kunden weiterleitet und die Druckfreigabe anfordert.
2.3.3 Bogensatz
Die Zusammenstellung eines Sammelbogens für den Offset-Druck wird von einem speziell
dafür eingewiesenen Mitarbeiter vorgenommen. Dabei werden alle Druckmotive, die für
das gleiche Material (Bedruckstoff) vorgesehen sind, in auf einer Datei als Druckbogen gesetzt, solange dessen verfügbare Fläche ausreicht. Die möglichen Maße des Bogens sind
durch die Druckerei vorgeschrieben, welche später den Druck ausführt. Der Druckbogen
muss so gesetzt werden, dass dieser nach dem Druck wieder in die einzelnen Motive zerschnitten werden kann.
Eine besondere Rolle nehmen beim Bogensatz Formate bzw. Formen ein, welche nicht im
Stapelschneider, sondern nur mithilfe einer individuellen Stanzform oder eines Formplots
aus dem Bogen geschnitten werden. Dies ist erforderlich, wenn
– das Druckprodukt in seiner Form nicht rechteckig ist (Freiformen)
– mindestens eine Seitenlänge des Endformates das kleinste Schnittmaß des
Stapelschneiders unterschreitet
– der Kunde ein exaktes Format benötigt (z.B. Etiketten)
Die Stanzform, welche als Konturlinie (Pfad) vorliegen muss, kann in einer separaten Datei hinterlegt sein, so dass der Bogensetzer Kenntnis über den geplanten Zuschnitt des
Produktes haben muss. Ferner dürfen beim Bogensatz nur Motive für den Druck platziert
werden, bei welchen im vorhergehenden Datencheck keine Fehler festgestellt wurden.
Auch darüber muss der für den Bogensatz zuständige Mitarbeiter Kenntnis haben. Dazu
wird das am Anfang des Abschnittes 2.3 erwähnte Verfahren (Kennzeichnung via Dateinamen und Speicherort) verwendet.
15
Nach Abschluss des Bogensatzes wird der erstellte Druckbogen gespeichert und einem
weiteren Mitarbeiter mit ausreichender Fachkenntnis zur Überprüfung vorgelegt. Erfahrungen aus früheren Produktionen zeigen, dass dieser Schritt die Fehlerquote erheblich minimiert. Nach Überprüfung des gesetzten Druckbogens, und gegebenenfalls vorgenommener Korrekturen, wird dieser elektronisch auf einen Server der Druckerei übertragen. Ist
die Übertragung angeschlossen, wird die Produktionsleitung der Druckerei per E-Mail oder
telefonisch über den Dateneingang informiert. Eine zusätzliche Auftragserteilung entfällt
aufgrund bestehender Vereinbarungen mit der Druckerei (vgl. Abschnitt 2.9 ), so dass die
Übertragung des Druckbogens und die anschließende Benachrichtigung für die weitere
Produktion bereits verbindlich sind. Ein weiterer Eingriff in den Aufbau des Druckbogens
oder die darauf enthaltenen Motive ist ab diesem Zeitpunkt grundsätzlich nicht mehr möglich.
Im regulären Bestellablauf ist ein optionaler Andruck (Proof) derzeit nicht vorgesehen und
wird im Online-Shop deswegen nicht angeboten.
2.4 Druck
Der Druck selbst findet außerhalb des Einflussbereiches der Druckagentur statt. Für den
Kunden und die Agentur befindet sich der Auftrag in Bearbeitung, ohne dass darauf Einfluss genommen werden kann.
In diesem Produktionsabschnitt werden die Druckplatten hergestellt, die Druckmaschine
eingerichtet und der Druck vorgenommen. Anschließende Veredelungen wie eine UVSchutz-Lackierung oder vorbereitende Maßnahmen, wie eine weiße Grundierung der
Druckflächen auf transparenten Bedruckstoffen, sind Teil des Druckprozesses.
2.5 Weiterverarbeitung
Die Weiterverarbeitung umfasst hauptsächlich den Prozess des Schneidens. Wie in Abschnitt 2.3.3 angedeutet, wird dieser für alle rechteckigen Formate manuell vorgenommen, sofern keine Seitenlänge ein vorgegebenes Mindestmaß unterschreitet. Den Zu16
schnitt nimmt ein Mitarbeiter der Druckerei manuell am Stapelschneider vor. Die Motive,
welche im Bogensatz mit einer Konturlinie versehen wurden, werden gestanzt oder mittels
eines Formplots geschnitten.
2.6 Qualitätskontrolle
Nach Abschluss der Weiterverarbeitung wird das fertige Druckerzeugnis zunächst der
Agentur überstellt und dort einer Qualitätskontrolle unterzogen. Dabei werden die Qualität
des Druckbildes und der Weiterverarbeitung beurteilt, sowie eventuelle Abweichungen von
den Druckdaten überprüft. Die Qualitätskontrolle erfolgt von einem Mitarbeiter, welcher mit
den gesendeten Druckdaten vertraut ist. Die Druckdaten wurden vor der Produktion in der
Auftragsannahme, dem Datencheck und dem Bogensatz verarbeitet, so dass einer der jeweils zuständigen Mitarbeiter die Qualitätskontrolle durchführt.
Weißt das Druckerzeugnis keine Mängel auf, wird es für den Versand freigegeben.
Zeigt die Qualitätskontrolle Mängel am Produkt auf, wird entschieden, ob die Mängel innerhalb akzeptabler Toleranzen liegen, oder ein Nachdruck erforderlich ist. Ziel ist es, den
Kunden vor Erhalt der Ware über etwaige Mängel informieren zu können. Gegebenenfalls
kann so mithilfe von Preisnachlässen ein Nachdruck umgangen werden. Ist ein Nachdruck
zwingend nötig, wird auf Wunsch des Kunden ein Teil der mangelhaften Ware trotzdem
versendet. So kann dieser in der für den Nachdruck benötigten Zeit, die mangelhafte Ware
behelfsmäßig einsetzen.
Die Kundenkommunikation bezüglich der Qualitätskontrolle und etwaiger Reklamationen
sind Aufgabe des Mitarbeiters, der auch die Auftragsannahme betreut.
2.7 Verpackung und Versand
Dieser Schritt der Auftragsabwicklung erfolgt unregelmäßig und ist abhängig vom vorhergehenden Produktionstermin. Der Versand erfolgt unregelmäßig, jedoch mindestens nach
Fertigstellung eines Sammeldruckbogen. Die Versandabteilung wird deshalb von einem
auf Abruf verfügbaren Mitarbeiter besetzt, welcher den Versand abwickelt. Bei gleichzeiti17
ger Fertigstellung mehrerer Druckbogen, werden diese natürlich auch im Versand gesammelt verarbeitet.
Die bei Auftragsannahme hinterlegten Formulare (vgl. Abschnitt 2.2 ) werden mithilfe der
Druckmotive wieder einem Kunden und einer Lieferadresse zugeordnet und anschließend
verpackt. Die Lieferadresse liegt dabei in handschriftlicher Form auf dem erwähnten Formular vor. Die Adressierung der Sendung erfolgt wiederum über ein elektronisches Frankierungssystem des Versanddienstleisters. Ausnahmen
bilden Sendungen, welche per
Kurier oder Expresslieferung versendet werden oder deren Bezahlung per Nachnahme erfolgen soll. Diese müssen manuell adressiert werden, da die elektronische Frankierung
zum Zeitpunkt dieser Ist-Analyse hierfür nicht vorgesehen ist.
2.8 Fakturierung
Die Rechnungslegung wurde bereits in Abschnitt 2.2 erwähnt, um den Zusammenhang
von Auftragsannahme und Versand darzustellen, nicht jedoch die Erstellung der Rechnung
erläutert.
Die zum Auftrag gehörende Rechnung wird bei Auftragserteilung vom System Magento
automatisch angelegt. Bei der Auftragsannahme wird die Rechnung lediglich kopiert, im
Rechnungsarchiv gespeichert und, wie in Abschnitt 2.2 beschrieben, gegebenenfalls sofort an den Kunden versendet. Die Vergabe fortlaufender Rechnungsnummern erfolgt automatisch durch die Software.
2.9 Besonderheiten
Als Besonderheit ist die organisatorische und räumliche Distanz zu nennen, welche durch
die Auslagerung einzelner, zuvor beschriebener Prozesse besteht (Outsourcing):
So erfolgen Auftragsannahme, Druckvorstufe und Versand (Aufgaben der Agentur) getrennt vom zwischenzeitlich erfolgenden Druck und der Weiterverarbeitung (Aufgaben einer oder mehrerer Druckereien). Die Druckereien agieren dabei als eigene Organisatoren,
18
welche jeweils in einem eigenen Auftragsverhältnis mit der Agentur stehen. Dadurch ergeben sich Lieferzeiten zwischen den Bearbeitungsstationen, die im Rahmen der Auftragsabwicklung beachtet werden müssen. Je nach Auslastung der Produktionskapazität können
sogar Druck und Weiterverarbeitung nacheinander in zwei verschiedenen Druckereien erfolgen. Die Kommunikation der Druckaufträge zwischen den einzelnen Organisationen erfolgt vorwiegend auf elektronischem Weg per E-Mail und im Rahmen bestehender Kooperationsvereinbarungen.
3 Analyse des Bestellablaufs
Der Bestellablauf und die damit zusammenhängenden Bearbeitungsschritte wurden in Abschnitt 2 im Rahmen einer Bestandsaufnahme erläutert. Als Grundlage der Analyse soll
der aktuelle Bestellablauf zunächst als Geschäftsprozess erfasst werden und auf Modellebene untersucht werden. Anhand dessen soll überprüft werden, an welchen Stellen dieser
Prozess sinnvoll in das vorhandene E-Commerce-Systems Magento integriert werden
kann.
3.1 Reihenfolgen und Abhängigkeiten
Der Ablauf der einzelnen Bearbeitungsschritte ergibt sich bereits aus der in Abschnitt 2 verwendeten Reihenfolge. Abbildung Fehler: Referenz nicht gefunden veranschaulicht die
Reihenfolge nochmals. Die Reihenfolge ergibt sich aus der
kausale Abhängigkeit eines Schrittes zum jeweils vorhergehenden. So kann beispielsweise die Weiterverarbeitung eines
Druckproduktes selbstverständlich erst nach dem Druck desselben erfolgen. Entscheidend für eine zeitsparende Abwicklung eines Auftrages ist einerseits die Dauer der einzelnen
Bearbeitungsschritte, andererseits auch der reibungslose
Übergang zum nächsten Schritt.
Abbildung 2: zeitlicher Ablauf der
Auftragsbearbeitung, Quelle:
Wildsmile Studios 2010
19
3.2 Der Bestellablauf als Geschäftsprozess
Der aktuelle Bestellablauf (Ist-Stand) lässt sich als Geschäftsprozess dargestellt wesentlich exakter untersuchen, als lediglich auf Abhängigkeiten der einzelnen Arbeitsschritte.
Ein Geschäftsprozess wird als eine Folge von Aktivitäten betrachtet, welche eine betriebliche Leistungserstellung ermöglichen3. In der genaueren Analyse wird diese Darstellung
um Ereignisse ergänzt, die infolge von Aktivitäten im Prozess entstehen4. „Ein Ereignis hat
keine Kosten, keine Dauer und benötigt keine Ressourcen“5. Es dient somit hauptsächlich
der Definition des Fortschritts innerhalb des Prozesses. Da für das Fortschreiten eines
Prozesses zu einem Zeitpunkt oft mehrere Ereignisse eintreten müssen und diese wiederum mehrerer vorhergehender Aktivitäten bedürfen, werden in der Darstellung die logischen Operatoren AND, OR und XOR verwendet, um derartige Abhängigkeiten zu zeigen.
Mithilfe eines so dargestellten ereignisorientierten Prozessgraphen (EPG) lässt sich ein
Geschäftsprozesse für die spätere Umsetzung planen. Ebenso kann aber auch ein bestehender Geschäftsprozesse visualisiert und auf Modellebene analysiert werden. Die Darstellung der Auftragsbearbeitung im EPG (vgl. Abb. 3) ermöglicht so die Abstrahierung des
in Abschnitt 2 erfassten Ist-Standes zur weiteren Untersuchung. Zur Darstellung werden
die zuvor erläuterten Elemente, nämlich Aktivitäten (abgerundete Rechtecke), Ereignisse
(Sechsecke) und Informationsobjekte (Rechtecke) verwendet. Die Software Magento ist
an genau denjenigen Stellen als Informationsobjekt dargestellt, an welchen Daten des Bestellablaufs aus dem System gelesen bzw. neue Daten in das System geschrieben werden
können. Auf die Darstellung der einzelnen Organisationseinheiten, d.h. der in Abschnitt 2
erwähnten Mitarbeiter und Abteilungen, wurde zugunsten der Übersichtlichkeit verzichtet.
Die im EPG grau hinterlegten Aktivitäten und Ereignisse finden ohne einen Datenaustausch mit dem existierenden System Magento statt. Es ist erkennbar, dass die Integration
der Arbeitsabläufe in Magento unvollständig ist. So wird beispielsweise das Ereignis „Auftrag in Druckvorstufe“ nur teilweise von der Software erfasst.
3
4
5
[ROSE2002], Seite 3
Vgl. ebd., Seite 22
Vgl. ebd.
20
Abbildung 3: Ist-EPG eines Bestellablaufs, nach [ROSE2002], Seite 30
21
3.3 Schwachstellen & Verbesserungsmöglichkeiten
Schwachstellen im gegebenen Bearbeitungsprozess stellen, im Sinne der vorliegenden Arbeit, diejenigen Ereignisse und Aktivitäten dar, welche sinnvoll durch Erweiterungen der
Software Magento ergänzt, ausgeführt oder über die zumindest Informationen erfasst werden können.
Bei der Suche nach Verbesserungsmöglichkeiten muss gleichzeitig hinterfragt werden, an
welchen Stellen sich gegebene Prozess (Ist-Stand) durch eine automatisierte Softwarelösung vereinfachen lassen. Kriterien für eine Verbesserung könnten dabei sein:
– Des Arbeitsschritt muss durch die softwaregestützte Lösung in gleicher Qualität
ausgeführt werden können.
– Die softwaregestützte Bearbeitung darf keine höhere Fehleranfälligkeit aufweisen,
als die bisherige Bearbeitung.
– Die softwarebasierte Lösung sollte erweiterbar sein, um die Bearbeitung zukünftiger Produkte zu ermöglichen
Folgend sollen erkannte Schwachstellen des in Abschnitt 3.2 dargestellten Prozesses
erläutert werden:
3.3.1 Mangelnde Kenntnis über den Auftragsstatus
Die zuvor aufgezeigte Kausalität in der Bearbeitungskette erfordert einen reibungslosen
Übergang von einem Schritt in den nächsten. Oft hat der Übergang die Zuständigkeit einer
anderen Abteilungen zur Folge (z.B. von der Auftragsannahme zur grafischen Bearbeitung) oder, wie im gegebenen Beispiel, sogar eines anderen Unternehmens (z.B. Übergabe an die Druckerei). Im EPG (Abb. 3) werden unterschiedliche Informationsobjekte dargestellt, die Daten zum bearbeiteten Auftrag halten. Im Sinne dieser Arbeit sollten diese Informationsobjekte in die E-Commerce-Software Magento integriert werden, um zunächst den
22
Auftragsstatus zentral verfügbar zu halten. Weiterhin sollen Informationen zum Auftrag jedoch nicht nur erfasst, sondern auch ergänzt werden können, um folgende Arbeitsschritte
einzuleiten. Anschließend muss wieder eine Rückmeldung an das ursprüngliche System
erforderlich, um den Status zu aktualisieren.
3.3.2 Uneinheitliche Datenhaltung
Die Informationsobjekte nehmen die Auftragsdaten in unterschiedlichster Form auf und ermöglichen keinen einheitlichen Zugriff. So werden Informationen in Papierform, im Dateisystem oder in der von Magento verwalteten Datenbank hinterlegt. Ändert ein Kunde innerhalb seines Kundenkontos im Online-Shop z.B. die gewünschte Lieferadresse, muss
diese an anderen Stellen manuell aktualisiert werden, ansonsten droht ein inkonsistenter
Datenbestand.
3.3.3 Unzureichende Automatisierung einzelner Aktivitäten
Im untersuchten Prozess ergeben sich begrenzt Möglichkeiten, Aktivitäten zu automatisieren. So könnte beim Versand auf den Datenbestand von Magento zugegriffen werden, und
dieser zur Adressierung und Frankierung übernommen wird.
Ferner wird das Ereignis „Auftrag in Druckvorstufe“ erreicht, indem zuvor nötige Aktivitäten
teils von Magento ausgeführt werden, teils manuell erledigt werden müssen. Die Rechnungserstellung wird mit dem Auslösen der Bestellung automatisch vorgenommen. Die
Dauer bis zum Erreichen des benannten Ereignisses richtet sich hier einzig nach der Dauer der manuell zu erledigenden Arbeitsschritte. Durch eine automatische Sortierung der
Druckdaten sowie die spätere Bereitstellung der Versandinformationen durch Magento
könnte sowohl die Auftragsannahme als auch die Versandvorbereitung vereinfacht werden.
23
3.3.4 Mangelnde Erfassung der Ereignisse
Dieser Punkt ergibt sich infolge der zuvor beschriebenen uneinheitlichen Datenhaltung
und der mangelnden Kenntnis über den Auftragsstatus. Betrachtet man den „produzierenden“ (rechten) Zweig des Ist-EPG, so wird deutlich, dass ab der Rechnungserstellung kein
weiterer Zugriff auf das Bestellsystem Magento erfolgen muss. Lediglich im Falle einer Reklamation könnte der Vermerk über eine Gutschrift darauf hinweisen. Alle dazwischen
stattfindenden Aktivitäten und Ereignisse, z.B. die der Druckvorstufe und der Weiterverarbeitung, fehlen und lassen eine spätere Rekonstruktion des Auftrages nur aus anderen
Quellen zu.
4 Überlegungen zum Soll-Zustand
Es wurde dargestellt, inwiefern eine Integration des in Abschnitt 3 beschriebenen Prozesses in die von Magento bereitgestellte Auftragsverwaltung zu einer Verbesserung des gesamten Produktionsprozesses beitragen kann. Um diese zusätzliche Funktionalität bereitzustellen, muss Magento also um ein Teilsystem mit genau dieser Funktion erweitert werden, welches als Parameter diejenigen Auftragsdaten verarbeitet, die für die Erfüllung der
einzelnen Arbeitsschritte relevant sind. Für Folgeschritte relevante Informationen müssen
wiederum als Rückgabewerte von Magento akzeptiert und verarbeitet werden.
Betrachtet man diese Anforderung unabhängig von Magento, wird klar, dass es um eine
austauschbare Software mit einer beliebigen Funktion geht, die zur Unterstützung bestimmter Prozesse eine Menge von Parametern annimmt, verarbeitet und ausgibt. Entscheidend in diesem Fall ist also vielmehr die Schnittstelle zur Übergabe der in Magento
bekannten oder hinzuzufügender Parameter eines Auftrages.
24
4.1 Zusammenfassung der Parameter für einen Druckauftrag
Die für einen Auftrag nötigen Parameter, also alle Daten, welche einen Auftrag vollständig
beschreiben um ein konkretes Druckprodukt herzustellen und zu versenden, sind in Tabelle 2 aufgelistet. Dabei wurde unterschieden, welche Parameter bei einer Bestellung (im
Online-Shop) von Magento erfasst werden können und welche als Ergebnis von Arbeitsschritten der Auftragsbearbeitung manuell hinzugefügt werden.
Parameter
Von Magento erfasst
manuelle Ergänzung nötig
Bedruckstoff
ja
nein
Format
ja
nein
Auflage
ja
nein
Weiterverarbeitung
ja
nein
Datencheck (ja/nein)
ja
nein
Druckmotiv
optional
optional
Rückseitendruck
optional
optional
Produktionszeit
ja
nein
Druckbarkeit
nein
ja
Zuordnung Sammelbogen
nein
ja
Qualität (Kontrolle)
nein
ja
Versandadresse
ja
nein
Rechnungsadresse
ja
nein
Versandtyp (Standard/Express)
ja
nein
Tabelle 2: Parameter eines Druckauftrages bei stickma.de
Aus Tabelle 2 ist erkennbar, dass fast alle für die Produktion nötigen Informationen beim
Abschluss des Online-Kaufs erfasst werden. Das Druckmotiv wird nur bedingt von Magento erfasst, da dem Kunden die Möglichkeit gegeben wird das Motiv nach der Bestellung
per E-Mail zu senden. Diese Option soll erhalten bleiben, da Sie dem Kunden einen gewissen Komfort bietet, z.B. wenn er die Druckdaten nicht selbst angelegt hat, sondern Dritte damit beauftragt.
Die Parameter „Druckbarkeit“ und „Qualität“ (gemeint sind die Ergebnisse des Datenchecks, und der Qualitätskontrolle vor bzw. nach dem Druck) können nicht von Magento
erstellt werden. Dafür sprechen mehrere Grunde: Die Aussage zur Druckbarkeit kann nur
25
getroffen werden, wenn ein Druckmotiv vorliegt. Dieses wird im Bestellvorgang jedoch nur
optional übertragen. Ferner kann das Druckmotiv in zahlreichen Formaten vorliegen, so
dass für jedes (druckbare) Dateiformat ein Algorithmus zur Überprüfung des Motives implementiert werden müsste. Auch können individuelle Anforderungen, zum Beispiel der
Druck eines bestimmten Bildausschnittes des gesendeten Motives, nur umständlich automatisch bearbeitet werden.
Die Zuordnung zu einem Sammelbogen ergibt sich aus dem Bogensatz (Abschnitt 2.3.3 )
und kann beim Bestellvorgang nicht vorgenommen werden.
Damit existieren also Parameter, welche stets außerhalb von Magento entstehen und nicht
währen der Bestellung automatisch kalkuliert werden können. Sie entstehen in jenen Teilprozessen, welche nicht Teil des Online-Handels sind und spezielle Leistungen des betreffenden Unternehmens erfordern.
4.2 Anwendungsfälle und Sichten
Die in Abschnitt 2 beschriebenen Stationen eines Druckauftrages bei stickma.de sollen in
der geplanten Erweiterung Magentos erfasst werden. Da Magento als Online-Shop die Bestellannahme bereits abdeckt, werden hier nur diejenigen Schritte betrachtet, welche ab
der Druckvorstufe (Abschnitt 2.3 ) passieren. Wichtig sind dabei die Informationen, welche
im jeweiligen Arbeitsschritt relevant sind. Gerade die räumliche und organisatorische Trennung von Druck und Weiterverarbeitung erfordern einen begrenzten Zugriff z.B. auf Kundendaten. Ebenfalls ermöglicht die Reduktion auf nur zur Ausführung des Arbeitsschrittes
relevante Daten eine übersichtliche Aufbereitung dieser und somit eine effiziente Gestaltung der Benutzeroberfläche.
Im Rahmen der einzelnen Arbeitsschritte entstehen zusätzliche Parameter, welche für folgende Arbeitsschritte relevant sind. Diese Parameter müssen als Output in den Auftragsstatus einfließen und ebenfalls an Magento kommuniziert werden. Folgend werden die Parameter der in Abschnitt 2 erläuterten Arbeitsschritte aufgezeigt. Dabei wird unterschieden in Parameter, die zur Ausführung des Arbeitsschrittes nötig sind (Input) und solchen,
die nach Ausführung des Arbeitsschrittes für spätere Arbeitsschritte relevant sind.
26
In den folgenden Tabellen sind außerdem die Datentypen angegeben, in welchen die einzelnen Parameter vorliegen. Ferner sind optionale Output-Parameter kursiv angegeben.
Zum Beispiel ist die Beschreibung von Mängeln im Datencheck nur nötig, wenn solche tatsächlich vorliegen.
4.2.1 Datencheck
Input
Datentyp
original Druckmotiv
file
Format
string
Material
string
Weiterverarbeitung
string
Output
Druckbarkeit (ja/nein)
bool
Mängel
string
Tabelle 3: Sicht auf Auftragsdaten für den Datencheck bei stickma.de
4.2.2 Bogensatz
Input
Datentyp
druckbares Motiv
file
Auflage / Nutzen
int
Material
string
Weiterverarbeitung
string
Output
Status „Motiv gesetzt“
bool
Zuordnung Druckbogen
string
Druckbogen
file
Tabelle 4: Sicht auf Auftragsdaten für den Bogensatz bei stickma.de
27
4.2.3 Druck
Input
Datentyp
Druckbogen
file
Material
string
Output
Status Fertigstellung
String
Tabelle 5: Sicht auf Auftragsdaten für den Druck bei stickma.de
4.2.4 Weiterverarbeitung
Input
Datentyp
Schnittplan
file
Plotform
file
Output
Status Fertigstellung
String
Tabelle 6: Sicht auf Auftragsdaten für die Weiterverarbeitung
bei stickma.de
4.2.5 Qualitätskontrolle
Input
Datentyp
Druckmotiv
file
Format
string
Material
string
Weiterverarbeitung
string
Output
Qualität OK (ja/nein)
bool
Mängel
string
Tabelle 7: Sicht auf Auftragsdaten für die Qualitätskontrolle
bei stickma.de
28
4.2.6 Versand
Input
Datentyp
Auftragsnummer
int
Versandadresse
file
Rechnung
file
Output
Status Versand
bool
Tracking-ID
string
Tabelle 8: Sicht auf Auftragsdaten für den Versand bei stickma.de
4.3 Entscheidung zum Erreichen des Soll-Zustandes
Auf dem Markt existieren sowohl Warenwirtschaftssysteme, als auch Angebote für individuelle Programmierlösungen. Auch bei der Einführung von Magento als Online-Shop der
Agentur standen andere Systeme zur Auswahl. Die Eignung von Magento als Online-Shop
sowie die Machbarkeit der Umsetzung wurden in [METS2009] besprochen. Bereits dort
wurde die „größtmögliche Freiheit bei der Gestaltung“6 als wichtiger Vorteil einer eigens
angepassten OpenSource-Lösung dargestellt. Auch der hohe finanzielle Aufwand einer
Kauf- oder Mietlösung spricht gegen den Einsatz dieser Alternativen.
Als Folge der in [METS2009] durchgeführten Machbarkeitsstudie wurde Magento als Online-Shop für das Unternehmen eingeführt. Die nötigen Anpassungen wurden dabei in Eigenleistung vorgenommen, so dass eine intensive Auseinandersetzung mit der Software
Magento erfolgte. Die damalige Investition in Form von Arbeitszeit des dafür abgestellten
Personals schafft nun einen Vorteil durch die angereicherte Erfahrung in der praktischen
Entwicklung mit der Software und dem entstandenen Wissenszuwachs.
Es ist daher auch wirtschaftlich sinnvoll, die Arbeit mit Magento zu vertiefen und zumindest
für den mit Online-Verkäufen in Verbindung stehenden Agenturbetrieb so weit wie möglich
die Anknüpfung an vorhandene Kapazitäten von Magento zu untersuchen.
6
[METS2009], Seite 16
29
5 Schnittstelle zwischen Online-Shop und Produktionen
Ein Online-Shop bietet zunächst zahlreiche Möglichkeiten, den Online-Handel zu vereinfachen. Da beim Kauf alle relevanten Daten vom Kunden eingegeben werden können, liegen diese anschließend gesammelt und digital vor. Dabei handelt es sich im wesentlichen
um Informationen zum gewünschten Produkt selbst, die Rechnungs- und Lieferadresse
des Kunden, sowie Kontakt- und ggf. Firmeninformationen. Mit Ausnahme der Druckdaten
(file) liegen diese Informationen als Textinformationen (string) vor und können entsprechend leicht übertragen und verarbeitet werden. Hinzukommende Informationen auf Agenturseite beschränken sich auf Wahrheitswerte (bool), weitere Vermerke in Textform sowie
aktualisierte Druckdaten und Druckbögen (file). Mindestens diese drei Datentypen müssen
im Soll-Zustand also verarbeitet werden können. Ferner ergibt sich daraus die Anforderung, dass die Schnittstelle nicht nur reinen Lesezugriff auf den Datenbestand von Magento bereitstellen muss, sondern auch Schreibvorgänge (ggf. auch die Löschung von Daten)
ermöglichen sollte.
Die in Abschnitt 4.2 aufgezählten Anwendungsfälle stellen die Sichten auf den Auftrag
dar. Die nötige Trennung dieser Views macht es erforderlich, unterschiedliche Rechte zur
Nutzung der Schnittstelle vergeben zu können. Somit ist eine Benutzerverwaltung eine
sinnvolle Anforderung an eine geplante Schnittstelle.
In Abschnitt 4.1 wurden Prozesse genannt, welche neben dem Online-Verkauf die eigentliche Kernleistung des Unternehmens ausmachen. Für eine Druckagentur ist dies etwa der
Umgang mit den Druckdaten, die Anwendung Ihres Fachwissens und die Verwendung entsprechender Werkzeuge, wie der professionellen Bildbearbeitung. Die Gegebenheiten
können z.B. bei der Verwendung anderer Werkzeuge (Software) variieren. Eine Schnittstelle zwischen Online-Vertrieb und Produktion sollte möglichst universell einsetzbar sein
und die kommunizierten Daten in einer leicht verwendbaren und erweiterbaren Form liefern. Die vollständige Integration unternehmensspezifischer Aufgaben in Magento würde
dessen primäre Funktion als Online-Shop in Frage stellen. Oft existieren bereits spezielle
Lösungen zur Steuerung der Produktion selbst, so dass eine flexible Kommunikationsmöglichkeit zwischen Magento und beliebigen externen Systemen den Übergang vom Vertrieb
zur Produktion vereinfachen kann.
30
5.1 Anpassung von Magento
Magentos Architektur ist in Modell-, Präsentations- und Steuerungsschicht unterteilt (MVCPattern). Ebenfalls wurde gleichzeitig auf eine strikte Modularisierung geachtet. In der Entwicklerdokumentation von Magento heißt es: „In a typical PHP Model-View-Controller
(MVC) application, all the Controllers will be in one folder, all the Models in another, etc. In
Magento, files are grouped together based on functionality, which are called modules in
Magento„7. In [KIMS2008] werden Module als „the core of Magento“8 beschrieben.
In der Tat sind sämtliche Funktionen von Magento selbst in Modulen organisiert. Jede Anfrage an die Software wird von einem oder mehreren Modulen verarbeitet. Hintergrund
dieses Konzeptes ist die von Magento angestrebte Flexibilität, um eine universelle und
gleichzeitig individuell anpassbare Lösung für den E-Commerce bereitstellen zu können.
So ist es möglich, Erweiterungen anzulegen, die exakt dem Aufbau des eigentlichen Systems entsprechen und, bei entsprechender Konfiguration, von der Software eingebunden
werden.
5.1.1 Core-Änderung
Magento ist ein Open-Source Projekt, womit der Quellcode frei verfügbar ist. Da die Software größtenteils in PHP geschrieben wurde und der Quellcode daher nicht kompiliert
werden muss, liegt dieser zusammen mit der installierten Software vor und muss nicht separat bezogen werden. Außerdem sind dadurch Änderungen am Quellcode sofort wirksam, da Sie vom PHP-Interpreter bei der nächsten Ausführung bereits erfasst werden. Es
ist also durchaus möglich, die Software grundlegend zu verändern, ohne die vorgegebene
Struktur aus Modulen zu verwenden. Die Magento Inc. empfiehlt dazu die Verwendung einer Software zur Versionsverwaltung9, wie etwa das frei verfügbare10 Tool Subversion
(SVN). Subversion ermöglicht es dem Benutzer, veränderte Dateien nicht zu überschreiben, wenn Magento selbst durch ein Update aktualisiert wird. Jedoch warnt die Magento
7
8
9
10
[MKNOW2010]
[KIMS2008], Seite 27
[MAGE2009]
[SVN2008]
31
Inc. diesbezüglich: „(...) the changes from one version of Magento to another may be too
great for subversion to handle in one diff“11. So können beispielsweise Veränderungen der
Dateinamen im Rahmen eines Updates aufwändige Vergleiche nötig machen, welche der
Anwender manuell für alle betroffenen Dateien vornehmen muss.
5.1.2 Module-Extension
Wesentlich komfortabler als die Veränderung systemeigener Dateien von Magento erscheint die Erstellung eigener, sogenannter Module-Extensions (Module). Module als
grundlegender Baustein von Magento müssen einem definierten Aufbau entsprechen, damit sie in Magento eingebunden werden können. Zudem wird Magento als „configurationbased MVC-System“12 beschrieben. Gemeint ist die Eigenschaft, dass Module zunächst
an einer zentralen Konfiguration bekanntgeben (aktiviert) werden müssen, bevor Magento
das betreffende Modul und dessen eigene Konfiguration einliest13. Nicht aktive Module
werden bei der Bearbeitung von Anfragen ignoriert.
Eine Module-Extension verfügt zudem über eine eigene Konfiguration für das Überschreiben von Controller-Klassen, die Beeinflussung der Manipulation und persistenten Speicherung von Daten (Model) und für die Datenausgabe (View). Innerhalb eines Moduls können
Klassen von abstrakteren Klassen aus Magento abgeleitet werden. Daher ist nur die Konfiguration derjenigen Teile (Model, View oder Controller) nötig, die tatsächlich verändert
werden sollen. Für alle fehlenden Teile eines Moduls fällt Magento auf Klassen aus dem
eigenen Bestand zurück.
Um die in Abschnitt
5.1.1
beschriebene Vermischung von eigenem Quellcode und
Magentos eigenem Quellcode zu vermeiden, stellt Magento sogenannte Codepools mithilfe einer entsprechenden Ordnerstruktur bereit. Im Unterverzeichnis /app/code/core/ befinden sich alle originalen Modulen von Magento. Unter /app/code/local/ können eigene Module abgelegt werden, welche bei Updates von Magento nicht überschrieben werden.
11 [MAGE2009]
12 [MKNOW2010]
13 [KIMS2008], Seite 62
32
Die einzelnen Module organisiert Magento
wiederum in Namespaces, die über die Ordnerstruktur und die Modulkonfigurationen gebildet werden. Damit sollen Kollisionen bei
der Namensvergabe für Klassen vermieden
werden.
Betrachtet
man
den
Ordner
/app/code/core/ findet man dort einen Namespace „Mage“ (kurz für: Magento), der alle
originalen Module der Software enthält (vgl.
Abb. 4). Die Klassennamen eines Moduls leiten sich dabei aus der Ordnerhierarchie ab.
Entsprechend kann ein Pfad /app/code/local/
[ModulNamespace]/[ModulName]/
angelegt
werden, um darin ein neues Modul anzulegen. Die Platzhalter [ModulNameSpace] und
[ModulName] können dabei frei gewählt werden. Die Dokumentation empfiehlt bei der
Abbildung 4: Verzeichnisstruktur der Magento Core-Module
(Bildschirmfoto)
Namensvergabe einen Bezug zum eigenen
Unternehmen um Dopplungen zu vermeiden.
Um eine Module-Extension und darin enthaltene Klassen für Magento sichtbar zu machen,
muss in einem weiteren Verzeichnis /app/etc/modules/ ein XML-Dokument
[ModulNameSpace]_[ModulName].xml
angelegt werden, welches die Existenz des
Moduls, dessen Namespace und den Verweis auf den Codepool /local/ angibt und dieses aktiviert bzw. deaktiviert (vgl. Abb.6) .
Abbildung 5: XML zur Bekanntgabe eines eigenen Moduls für
Magento, (Bildschirmfoto)
33
Die Konfiguration des Moduls selbst erfolgt ähnlich innerhalb der Modulordner mithilfe eines weiteren XML-Dokumentes
/app/code/local/[ModulNamespace]/[ModulName]/etc/config.xml
Die genaue Struktur einer Modulkonfiguration richtet sich nach Art und Umfang des gewünschten Moduls und ist in der Dokumentation von Magento beschrieben14.
5.1.3 REST-Integration
Mithilfe der Module-Extensions besteht auch die Möglichkeit, eigene Schnittstellen zu
schaffen. Dabei ist es hilfreich, zunächst den Bearbeitungszyklus von Magento zu betrachten. Magento identifiziert eine Anfrage (z.B. durch den Webbrowser) über die aufgerufene
URL. Innerhalb der Anwendung werden zunächst alle Anfragen (URLs), mit Ausnahme
konkreter Aufrufe z.B. von Bilddaten, auf einen festen Einstiegspunkt geleitet.
Dort wird die vom Browser angefragte URL nach einem festgelegten Schema interpretiert,
welches die Zuordnung von Model und Controller, und optional einer bestimmten Methode
innerhalb des Controllers (einer sog. Action) ermöglicht15 (vgl. Abb. 6).
14 [MKNOW2010]
15 [KIMS2008], Seite 36
34
Abbildung 6: Zuordnung von Model, Controller und Controller-Methode (Action) zu URL, aus [KIMS2008], Seite 36
Am Beispiel der Website www.stickma.de wird die URL
http://www.stickma.de/catalog/category/view/?id=5
von Magento so verarbeitet, dass analog zu Abb. 6 das Modul Catalog und der CategoryController aufgerufen werden. Der Parameter id übergibt dem Controller die Kennung der
angefragten Produktkategorie.
Damit ist es nun möglich, einzelne Controller und darin enthaltene Methoden gezielt über
die URL anzusprechen. FIELDING beschreibt in [FIEL2000] den Architekturansatz Representational State Transfer (REST) für verteilte Systeme, wobei Informationen und Dienste
als Ressourcen angesprochen werden16. Angelehnt an das Prinzip des REST zeigt
[KIMS2008] in einem praktischen Beispiel die Nutzung einer Module-Extension zur Schaffung einer Schnittstelle zwischen Magento und einem weiteren System17. Der Controller
der Module-Extension wird genutzt, um einfache CRUD-Operationen bereitzustellen, welche die eingehenden Anfragen bearbeiten. Da die Module-Extension Zugriff auf Magentos
Model-Klassen hat, können über die geschaffene Schnittstelle auch Kunden- und Bestelldaten des Online-Shops gelesen und modifiziert werden. Zur Ausgabe von Daten wird ein
16 [FIEL2000], Seite 88
17 Vgl. [KIMS2008], Seite 135 ff
35
XML-Stream erstellt und zurück an den Client gesendet. Anstelle eines XML-Streams können die Daten natürlich auch an ein beliebiges Model übergeben werden um sie in einer
Datenbank zu hinterlegen oder weiter zu modifizieren. Um die Schnittstelle vor öffentlichem Zugriff zu schützen, verwendet KIMSAL den Authentisierungsmechanismus von
Magento, womit bei der Anfrage ein gültiger Benutzer aus der Benutzerverwaltung für
Magentos Administrationsoberfläche angegeben werden muss. Offen bleibt jedoch, ob Benutzer mit eingeschränkten Rechten verwendet werden können, um die Anfrage ausführen
zu dürfen. Magento sieht vor, das Benutzergruppen mit unterschiedlichen Rechten nur auf
jeweils erlaubte Bereiche der Administrationsoberfläche zugreifen dürfen, um nicht jedem
Mitarbeiter vollständige Administrationsrechte am Online-Shop verleihen zu müssen.
Auf Seiten des Clients ist es nun notwendig, zunächst die Benutzerauthentifizierung von
Magento aufzurufen und folgend auf die im Module-Controller verfügbaren Ressourcen zugreifen zu können. Die Kommunikation erfolgt über das Hypertext Transfer Protokoll
(HTTP). Dabei muss bei der Authentifizierung des Benutzers das von Magento bereitgestellte Session-Cookie gespeichert und für jede Anfrage bereitgehalten werden. Existierende Frameworks wie die Cognitfy HTTP Library für PHP bieten die entsprechende Grundfunktionalität, um einen Client für die beschriebene Schnittstelle zu implementieren.
5.1.4 Magento Core-API
Neben der Möglichkeit, Schnittstellen mithilfe von Module-Extensions zu schaffen, bietet
Magento eine umfangreiche Magento Core API an, die sowohl das Simple Object Access
Protocol (SOAP) als auch den Remote Procedure Call über XML (XML RPC) unterstützt.
Die Schnittstellenbeschreibung ist bei jeder Standardinstallation von Magento unter
http://[MagentoHost]/api/?wsdl
verfügbar. Die Schnittstellen können jeweils über
http://[MagentoHost]/api/soap/ und
http://[MagentoHost]/api/xmlrpc
36
aufgerufen werden. In der deutschen Übersetzung von Magento werden die Schnittstellen
als Web-Dienste bezeichnet. Zur Benutzung der Schnittstellen muss ein entsprechendes
Benutzerkonto eingerichtet werden. Die Benutzer für Web-Dienste werden in Magento separat verwaltet. Im Gegensatz zur Schnittstelle auf Basis einer Module-Extension (vgl. Abschnitt 5.1.2 ), muss hier kein Benutzerkonto eingerichtet werden, welches zusätzlich
auch den Zugriff auf den Administrationsbereich Magentos ermöglichen würde. Die Authentifizierung zur Benutzung der Magento Core API erfolgt über die Kombination aus Benutzernamen und einem API-Key. Letzterer muss beim Anlegen des Benutzers vergeben
werden (vgl. Abb. 7).
Abbildung 7: Einrichtung der Web-Dienste im Magento Admin-Panel (Administrationsoberfläche, Bildschirmfoto)
Die Magento Core API bietet derzeit Zugriff auf fünf Module18 aus dem Namespace Mage
(vgl. Abschnitt 5.1.2 ):
– Mage_Customer
lesen, verändern, erstellen und löschen von Kundendaten
– Mage_Directory
lesen von Ländernamen und zugehörigen Regionen für Versandziele
18 [MKNOW2010]
37
– Mage_Catalog
lesen, verändern, erstellen und löschen von Kategorien und Produkten
– Mage_Sales
lesen, erstellen und stornieren von Käufen im Online-Shop
– Mage_CatalogInventory
lesen und verändern von Produkteigenschaften (Attributen)
Darüber hinaus bietet Magento die Möglichkeit, eigene APIs zu erstellen. Nicht zu verwechseln mit der in Abschnitt
5.1.3
be-
schriebenen Methode, kann hierbei zunächst nur Magentos vorgegebene API genutzt werden. Dazu muss das gewünschte
Modul um eine entsprechende Konfiguration (vgl. Abb. 8) und natürlich einen Adapter
Abbildung 8: Aufbau der XML-Beschreibung einer APIErweiterung (Bildschirmfoto)
mit den gewünschten Methoden ergänzt
werden19.
Unter dem Knoten <resources> (vgl. Abb. 8) werden die neu erstellten Methoden einem
Magento-eigenem Modul zugewiesen. Der Knoten <acl> steht für Access Control List und
ermöglicht es, bestimmte (oder alle) dieser als Ressourcen definierten Methoden als nichtöffentlich zu definieren. Als Resultat verlangt Magento dann die Autorisierung eines Benutzers mit entsprechenden Rechten und zugehörigem API-Key, wie zuvor in diesem Abschnitt beschrieben wurde.
Die offizielle Dokumentation von Magento geht davon aus, dass nur die vorhandene
Magento Core API erweitert werden soll. Lediglich im Magento Wiki, einer von der Magento Inc. angebotenen Plattform zum Wissensaustausch unter Nutzern der Software, findet
sich ein Hinweis, dass die Magento Core API um eigene Funktionen ergänzt werden
kann20. Dabei wird wie in Abschnitt 5.1.2 eine Module-Extension erstellt und, analog zum
19 [MKNOW2010], Kapitel 3
20 [MWIK2010]
38
Vorgehen der Nutzung der Mage Core API, eine Konfiguration für die angebotenen Ressourcen der API hinterlegt. Etwas aufwändiger ist das Vorgehen dadurch, dass für die
neue Schnittstelle eine vollständige Beschreibung mit Hilfe der Web Services Description
Language (WSDL) hinterlegt werden muss.
Wie in der vorher beschriebenen Methode einer REST-Integration müssen auch bei Verwendung der Magento Core API die Rückgabewerte in das gewünschte Format gebracht
werden. Die Erstellung, beispielsweise eines XML-Streams, obliegt damit dem Entwickler,
was jedoch eine sehr hohe Flexibilität bei der Aufbereitung der Daten ermöglicht.
5.2 Auswertung und Auswahl der Anpassungsmöglichkeiten
Grundsätzlich bietet Magento eine gute Auswahl an Möglichkeiten zur Erweiterung der
Software, je nach Umfang und Komplexität der gewünschten Anpassung. Die Tatsache,
dass Magento ein quelloffenes System ist, kann genutzt werden um schnelle und einfache
Lösungen direkt im Code-Pool /core/ vorzunehmen. Dafür muss in Kauf genommen werden, dass mit zukünftigen Updates eine aufwändige Analyse des Systems vorgenommen
werden muss, um das weitere Funktionieren zu gewährleisten. In der Praxis muss der Betrieb des Online-Shops jedoch auch wirtschaftlich betrachtet werden. So kann eine kurzfristige Anpassung im Codepool /core/ eine Übergangslösung darstellen, bis eine ausführlichere Lösung bereitsteht. Die vorgeschlagene Benutzung einer Versionsverwaltung erlaubt in diesem Fall zudem die unkomplizierte Wiederherstellung der zuvor veränderten
Dateien (des Codepools /core/).
Die Module-Extension erscheint daher für langfristige Lösungen die sichere Herangehensweise zu sein. Jedoch erfordert dieser Ansatz ein tieferes Verständnis von Magentos modularen Aufbau. Die Konfiguration der Module-Extension kann nicht vollständig im Namespace des eigenen Moduls vorgenommen werden (vgl. Abschnitt 5.1.2 ), was etwa bei einer Portierung des Systems beachtet werden muss.
Soll eine Kommunikation der in Magento über Kunden oder getätigte Verkäufe erfassten
Daten erfolgen, sollte eine Schnittstelle in Betracht gezogen werden. Die dazu vorgestellten Ansätze könnten beide ausreichende Funktionalität bieten, um eine Schnittstelle zu ei39
nem Warenwirtschaftssystem oder einer Prozessteuerung zu schaffen. Die Anwendung
der REST-Architektur liefert dafür eine unkomplizierte Lösung. Für jede neue (über die
URL anzusprechende) Ressource muss lediglich im Controller des Moduls eine entsprechende Methode implementiert werden. Nachteilig erscheint jedoch die mangelnde Nutzerverwaltung für die Schnittstelle. Die Automatisierung der eigentlich für den Webbrowser
vorgesehenen Login-Prozedur könnte bei zukünftigen Versionen von Magento fehlschlagen. Gerade bei Webanwendungen ist es durchaus üblich, derartige Zugriffe aus Sicherheitsgründen zu unterbinden. In der derzeit aktuellen Version 1.4 von Magento ist das Login-Formular der Administrationsoberfläche bereits mit einer Prüfsumme versehen, die zunächst aus dem Quelltext des Formulars geparsed werden muss, um sie mit den Benutzerdaten und dem Session-Cookie zu übermitteln.
Die Magento Core API bietet eine gute Möglichkeit, Zugriff auf alle grundlegenden Daten
des Online-Shops zu erlangen. Die fünf in Abschnitt 5.1.4 genannten Module ermöglichen Lese- und Schreibzugriffe auf alle Bestell-, Kunden- und Produktdaten sowie zusätzliche Informationen, die beispielsweise für die Abwicklung des Versands oder die Pflege
des Produktsortiments wichtig sein könnten. Da Magento diese Schnittstelle von Haus aus
mitbringt, ist zu erwarten, dass zukünftige Versionen von Magento auch die Möglichkeiten
der Magento Core API verbessern und eine Abwärtskompatibilität gegeben sein wird.
Die Anwendung der Magento Core API in eigenen Modulen und den Überlegungen bezüglich zusätzlich implementierter Methoden führen zu einer Kombination der beiden vorgenannten Erweiterungsmöglichkeiten. Die Verwendung der REST-Architektur in Verbindung
mit der Magento Core API auf Basis einer Module-Extension schaffen eine sehr hohe Flexibilität unter Verwendung von bereits in Magento vorhandenen Features. Die von der
Magento Core API bereitgestellte Benutzerauthentifizierung lässt zudem zu eine einheitliche Benutzerverwaltung und die Anwendung vorhandener Sicherheitsstandards innerhalb
der Software zu.
Die Rückgabewerte der Magento Core API können in Form eines XML-Streams gesendet
werden. Dies ermöglicht die exakte Anpassung an externe Systeme, sofern diese XML
verarbeiten können. Da die Formatierung der Ausgabe dem Entwickler obliegt, sind andere Möglichkeiten denkbar und können je nach Bedarf implementiert werden.
40
6 Lösung für den Agenturbetrieb
Im konkreten Fall bei stickma.de bietet sich die Erarbeitung einer praktischen Lösung mithilfe passender Module-Extensions, sowie der Schaffung einer Schnittstelle zu externen
Systemen an. Dazu wird folgend das mögliche Vorgehen, bezogen auf den Agenturbetrieb
bei stickma.de, erläutert.
6.1 Bessere Kenntnis über den Auftragsstatus
Zunächst sollte die Möglichkeit geschaffen werden, die erforderlichen Zustände eines Auftrages zu erfassen (vgl. EPG in Abschnitt 3.2 ). Unter den verfügbaren Erweiterungen für
Magento existiert bereits das Modul „Order Status“, welche über die Funktion Magento
Connect installiert werden kann. In [METS2009] wird das Vorgehen zur Installation vorhandener Module-Extensions am Beispiel der Sprachpakete beschrieben21. Die Module-Extension Order Status wird von der Magento Inc. auf der Plattform Magento Connect bereitgestellt und kann mit dem Extension-Key magento-community/Order_Status installiert werden22. Anschließend ermöglicht die Auftragsverwaltung von Magento die Zuordnung neuer
Zustände zu einem Auftrag. Abb. 9 zeigt den Vergleich der Darstellung im Administrationsbereich vor und nach Installation der Module-Extension, im Zusammenhang mit dem Inhalt
der jeweiligen Modulkonfiguration in XML. Rechts ist die Konfiguration des Standard-Moduls aus /app/code/core/Sales zu sehen, rechts die Konfiguration der Erweiterung.
21 Vgl. [METS2009], Seite 27
22 Vgl. ebd.
41
Abbildung 9: Erfassung neuer Auftragszustände mithilfe der Module-Extension Order Status. Quelle: Wildsmile Studios,
Entwicklungsumgebung http://dev.stickma.de, 2010, (modifiziertes Bildschirmfoto)
In Abb. 9 ist zu erkennen, wie die zusätzlichen Knoten in der XML-Konfiguration des Auftragsstatus mit den verfügbaren Statusmeldungen korrelieren. Die abweichende Darstellung der Bezeichnung resultiert aus der in Magento integrierten Übersetzung. Auf der rechten Seite ist zu erkennen, dass für die neuen Zustände keine Übersetzung vorliegt. Die originalen Auftragszustände (Ausstehenddddddd, Verarbeitung, Versandt, Vollständig) sind
im Modul Sales in /app/code/core/Mage/Sales/etc/config.xml definiert. Diese Konfiguration
wird vom Modul Order Status in /app/code/community/Mage/Sales/Community/etc/config.xml lediglich überschrieben und erweitert. Dieser Ansatz kann weiter verfolgt werden,
und um für die Agentur stickma.de relevante Zustände (vgl. Abschnitt 3.2 ) ergänzt werden.
6.2 Vereinfachte Datenhaltung
Im Abschnitt 5.1.4 wurde gezeigt, wie Mithilfe der Magento Core API auf den Datenbestand von Magento zugegriffen werden kann. Das in Abschnitt 3.3.2 angesprochene Problem der manuellen Korrektur von inkonsistenten Daten, etwa der Lieferadresse, kann umgangen werden, indem solche Daten grundsätzlich über Schnittstellen abgefragt werden.
Somit erfolgt eine einmalige Speicherung zum Zeitpunkt der Datenentstehung, nämlich bei
der Bestellung. Anschließend sind diese Daten über die Magento Core API erreichbar und
sogar manipulierbar. Die fünf von der Schnittstelle abgedeckten Module (vgl. Abschnitt
42
5.1.4 ) ermöglichen die Kommunikation sämtlicher Auftragsdaten. Auch die Zustände eines bestimmten Auftrages können über die Ressource sales_order der Schnittstelle kommuniziert und werden. Die Benutzerverwaltung für die Webservices sollte aber verwendet
werden, da der Online-Shop zwangsläufig auf einem öffentlich erreichbaren Webserver
laufen muss.
6.3 Automatisierung von Arbeitsschritten
Die Automatisierung einzelner Arbeitsschritte ist stark von der Beschaffenheit selbiger abhängig. Eine Druckagentur verliert durch einen höheren Automatisierungsgrad gleichzeitig
die Fähigkeit, auf Sonderwünsche von Seiten ihrer Kunden individuell einzugehen. Wohl
aber können mit der Erweiterung von Magento die Übergänge zwischen Teilprozessen
komfortabler gestaltet werden. So können einzelne Druckaufträge anhand ihrer Eigenschaften bereits im Vorfeld passenden Sammeldruckbögen zugeordnet werden. Da das
Druckformat Teil der Auftragsdaten ist, ist auch eine Berechnung der verbleibenden Bogenfläche und damit eine Unterstützung der Produktionsplanung denkbar.
Da der Versand bereits von einer Frankierungssoftware des Versanddienstleisters unterstützt wird, kann hier eine Schnittstelle geschaffen werden, über welche sowohl die Frankierung anhand des Auftragsstatus automatisch auslöst, als auch der Auftragsstatus in
Magento aktualisiert werden kann.
7 Übertragbarkeit der Erkenntnisse
Nachdem die Verknüpfung vom Online-Vertrieb mit Magento und einer Produktion am Beispiel einer Druckagentur für Offset-Produktionen untersucht wurde, stellt sich die Frage,
ob dies auch für andere Fertigungen möglich ist. Für das vorliegende Beispiel wurde die
Produktion als ereignisorientierte Prozesskette dargestellt und die einzelnen Arbeitsschritte durch Ereignisse abgegrenzt. Jeder Arbeitsschritt verarbeitet eine gewisse Teilmenge
an Daten des Auftrages und gibt anschließend eine Rückmeldung, die weitere Arbeitsschritte beeinflusst. Für jeden Arbeitsschritt wurde eine eigene Sicht auf die Auftragsdaten
angenommen, da im vorliegenden Fall keine Kommunikation während der Ausführung ei43
nes Arbeitsschrittes nötig war, sondern ausschließlich nach Abschluss eines Arbeitsschrittes. Die Zerlegung in derartige Einheiten reduzierte die Problematik auf einzelne, unabhängige Schnittstellen und ist für Magento umsetzbar. Ob dies auch möglich ist, wenn von
mehreren Seiten über unterschiedliche Schnittstellen mit Magento kommuniziert werden
muss, sollte im Vorfeld überprüft werden. Die in der Produktion erfassten Zustände eines
Auftrages müssen für Magento definiert werden, sofern sie an das Bestellsystem kommuniziert werden sollen. Im untersuchten Fall wurde dazu auf eine vorhandene Module-Extension zurückgegriffen, die nach dahingehend angepasst werden kann. Dabei können
diejenigen Zustände definiert werden, die in Magento, und damit auch für den Kunden
sichtbar sein sollen.
Die Begrenzung der Automatisierung begründete sich aus den Anforderungen des Unternehmens, gilt aber nicht zwingend für andere Umgebungen. Dort wo Fertigungsschritte
vollautomatisch ablaufen, könnten auch die geschaffenen Schnittstellen zwischen Magento und dem Fertigungssystem automatisch bedient werden. Dennoch gibt es Grenzen, die
bei der Verwendung von Magento entstehen können. So muss stets bedacht werden, dass
Magento eine Webanwendung ist, die auf einem öffentlichen Server läuft. Ohne diese Gegebenheit wäre die Kernfunktion, der Online-Shop, nicht öffentlich nutzbar. Diesbezüglich
sollten Sicherheitsaspekte in die Planung mit einbezogen werden, und abgewogen werden, ob sich die Anbindung eines öffentlichen Servers an die Produktionssteuerung eignet.
Magento ist in seiner Flexibilität ein sehr komplexes System mit recht hohen Anforderungen an Hardware-Ressourcen23. Daher sollte bedacht werden, dass zusätzliche Schnittstellenanfragen das System weiter belasten können. Im untersuchten Beispiel wurden
mehrere Schnittstellen angenommen, die pro Auftrag aufgerufen werden. Zwar geschieht
dies zeitversetzt zur Bestellung selbst, trägt jedoch zur Belastung des Webservers bei. Je
nach Auslastung des Servers und Automatisierungsgrad der Schnittstellenbedienung kann
die Häufigkeit der zusätzlichen Anfragen an Magento zunehmen und eine höhere Serverlast ausüben. Daher muss bei der Anbindung einer Produktionssteuerung die Kapazität
der verfügbaren Hardware beachtet werden.
23 [METS2009], Seite 24f
44
8 Fazit
8.1 Machbarkeit
Im Rahmen dieser Arbeit wurde der auf Magento basierende Online-Shop einer Druckagentur auf die mögliche Verknüpfung mit produktionsrelevanter Prozesse untersucht. Die
verschiedenen Anpassungsmöglichkeiten von Magento lassen mehre Herangehensweisen
zu, mit denen eine Lösung erarbeitet werden kann.
Die kombinierte Verwendung der Module-Extensions und der Magento Core API erweist
sich als sinnvoller Ansatz, um eine individuelle Lösung zu erarbeiten. Die Flexibilität von
Magentos Schnittstelle ist ein Vorteil bei der Verknüpfung mehrerer Unternehmensteile
und über Unternehmensgrenzen hinaus. Die mögliche Einbeziehung von Geschäftspartnern in die geplante Erweiterung ermöglicht eine Lösung auch dann, wenn einzelne Arbeitsschritte vom verkaufenden Unternehmen ausgelagert werden.
Als OpenSource-System kann Magento zudem im seinen Kernfunktionen verändert werden, um eine vorübergehende Lösung zu schaffen. Somit ist die Machbarkeit auch dann
gegeben, wenn eine kurzfristige Lösung benötigt wird. Die kann auch zu Testzwecken
sinnvoll sein, um die dadurch entstehenden Veränderungen im Arbeitsablauf zu testen.
Langfristig sollte jedoch auf eine modulare Erweiterung zurückgegriffen werden, insbesondere dann, wenn andere Module-Extensions zum Einsatz kommen und die Kompatibilität
gewährleistet sein muss. Ferner macht das erstmalige Release von Magento im Jahr
2008 macht die Software immer noch zu einem jungen System, das auf weitere Updates
angewiesen sein wird.
Für beide Lösungsansätze, die kurzfristige Veränderung des Kernsystems und die Entwicklung einer eigenen Module-Extension, ist ein ausreichendes Verständnis der Architektur von Magento nötig. Unbedingt sollte ein unabhängiges Testsystem herangezogen werden, um die Erweiterungen ausführlich testen zu können, ohne Ausfälle im Shop-Betrieb
riskieren zu müssen. Insbesondere die Verbindung mit produktionsrelevanten Arbeitsprozessen verlangen ein zuverlässiges und stabiles Funktionieren einer Lösung.
45
8.2 Vor- und Nachteile von Magento für das Thema
Das Ziel der Software Magento war, der Anpassbarkeit an individuelle Geschäftsprozesse
keine Grenzen zu setzen24. Der von Grund modulare Aufbau der Software bestätigen diese Vorgabe auch in der Umsetzung. Durch die Möglichkeit, Erweiterungen (Module-Extensions) mit eigener Anwendungslogik zu versehen, setzt Magento kaum Grenzen in seiner
Erweiterbarkeit. Die standardmäßig vorhandene Schnittstelle (Magento Core API) schafft
eine solide Grundlage für die Anbindung weiterer Systeme und Datenquellen, welche, wiederum durch Ihre Erweiterbarkeit, ein hohes Maß an Flexibilität aufweist. Derzeit ist
Magento das umfangreichste quelloffene System für die Schaffung eines Online-Shops 25.
So besteht ein Vorteil von Magento auch darin, als dass wohl kaum ein anderes System
existiert, das bereits vorhandene Unternehmenslösungen derart umfangreich um die Möglichkeit des Online-Vertriebs ergänzt.
Als Nachteilig erweist sich die Komplexität in Verbindung mit der mangelnden, technischen
Dokumentation der Software26. Um die Zusammenhänge innerhalb des Systems Magento
zu verstehen, sind die sog. KnowledgeBase der Magento Inc. sowie das von Nutzern ergänzte Magento-Wiki unabdingbar. Die Literatur über die Entwicklung mit Magento ist
noch rar gesät, was auch mit der erst zweijährigen Verfügbarkeit der Software begründet
werden kann. So ist das Zusammenspiel der einzelnen Module nur schwer nachzuvollziehen, was bei der Findung richtiger Ansatzpunkte für eigene Erweiterungen hinderlich sein
kann.
24 Vgl. [MCOM2010]
25 Vgl. [METS2009], Seite 60
26 Vgl. [METS2009], Seite 61
46
8.3 Möglichkeiten & Ausblick
Wie bereits dargestellt ist Magento in seiner Komplexität nur mit größerem Aufwand zu erfassen. So ergeben sich im Laufe dieser Arbeit Möglichkeiten, deren weitere Untersuchung wünschenswert, jedoch nicht innerhalb des gegebenen Rahmens machbar gewesen wäre.
So kann mit den erläuterten Ansätzen je Anwendungsfall eine eigene Lösung geschaffen
werden, die jeweils entsprechende Kenntnis über Magento und die Umsetzung der Programmierung erfordern. Je nach Unternehmen kann dies Investitionen in zusätzliches
Personal erfordern, wenn im Haus keine entsprechenden oder nicht genügend Fachkräfte
verfügbar sind. Aus dieser Überlegung heraus könnte auch eine abstraktere Lösung gesucht werden, die es dem Benutzer erlaubt, die benötigten Schnittstellen dynamisch zu
konfigurieren. Im Idealfall könnte so ein Modul erstellt werden, welches vom Anwender die
Prozesse seines Unternehmens in einer Eingabemaske erfasst und auf Grundlage dessen
die benötigten weiteren Module und Schnittstellendefinitionen erstellt. Damit würde eine
benutzerfreundliche und wiederverwendbare Lösung angestrebt werden. Jedoch müssten
dazu gewisse Standards vereinbart werden, welche den Aufbau von Module-Extensions
und Schnittstellen in Magento allgemein beschreiben.
Zur ausführlicheren Bewertung der Machbarkeit hätte ferner eine Untersuchung der in Abschnitt 7 vermuteten zusätzlichen Hardwarebelastung beigetragen und eine ausführlichere Planbarkeit einer praktischen Umsetzung ermöglicht.
47
Quellenverzeichnis
[FIEL2000]
Architectural Styles and the Design of Network-based Software
Architectures (Dissertation), Roy Thomas Fielding, 2000
[KIMS2008]
php architect's Guide to Programming Magento,Mark Kimsal,
Marco Tabini & Associates Inc.,2008
[MAGE2009]
Changing and Customizing Magento Code,Luispic,Magento
Inc.,
http://www.magentocommerce.com/wiki/groups/174/changing_
and_customizing_magento_code am 30.07.2010
[MCOM2010]
About Us, Magento Inc.,
http://www.magentocommerce.com/company/ am 02.08.2010
[METS2009]
Machbarkeitsstudie zur Umsetzung eines bestehenden OnlineShops mit der E-Commerce Software Magento (Diplomarbeit),
Jana Metschke, 2009
[MKNOW2010]
Magento for Developers, Alan Storm, Magento Inc.,
http://www.magentocommerce.com/knowledgebase/entry/magento-for-dev-part-1-introduction-to-magento/
am 10.08.2010
[MWIK2010]
Overriding an existing api class with additional functionality,
http://www.magentocommerce.com/wiki/5__modules_and_development/web_services/overriding_an_exis
ting_api_class_with_additional_functionality am 10.08.2010
[ROSE2002]
Geschäftsprozesse: Modell- und computergestützte
Planung,Friedrich Rosenkranz, Springer-Verlag Berlin
Heidelberg New York, 2002
[SVN2008]
Versionskontrolle mit Subversion, Ben Collins-Sussman, Brian W.
Fitzpatrick, C. Michael Pilato, http://svnbook.redbean.com/nightly/de/svn-book.html#svn.intro.whatis am 17-08-2010
48
Tabellenverzeichnis
Tabelle 1: Kriterien zur Überprüfung der Druckbarkeit (Datencheck).................................14
Tabelle 2: Parameter eines Druckauftrages bei stickma.de................................................25
Tabelle 3: Sicht auf Auftragsdaten für den Datencheck bei stickma.de..............................27
Tabelle 4: Sicht auf Auftragsdaten für den Bogensatz bei stickma.de................................27
Tabelle 5: Sicht auf Auftragsdaten für den Druck bei stickma.de........................................28
Tabelle 6: Sicht auf Auftragsdaten für die Weiterverarbeitung bei stickma.de....................28
Tabelle 7: Sicht auf Auftragsdaten für die Qualitätskontrolle bei stickma.de......................28
Tabelle 8: Sicht auf Auftragsdaten für den Versand bei stickma.de...................................29
49
Abbildungsverzeichnis
Abbildung 1: Kennzeichnungssystem für Druckdaten bei stickma.de,
Quelle: Wildsmile Studios, 2010...............................................................13
Abbildung 2: zeitlicher Ablauf der Auftragsbearbeitung,
Quelle: Wildsmile Studios 2010................................................................19
Abbildung 3: Ist-EPG eines Bestellablaufs,
nach [ROSE2002], Seite 30......................................................................21
Abbildung 4: Verzeichnisstruktur der Magento Core-Module.............................................33
Abbildung 5: XML zur Bekanntgabe eines eigenen Moduls für Magento...........................33
Abbildung 6: Zuordnung von Model, Controller und Controller-Methode (Action) zu URL,
aus [KIMS2008], Seite 36.........................................................................35
Abbildung 7: Einrichtung der Web-Dienste im Magento Admin-Panel
(Administrationsoberfläche)......................................................................37
Abbildung 8: Aufbau der XML-Beschreibung einer API-Erweiterung..................................38
Abbildung 9: Erfassung neuer Auftragszustände mithilfe der Module-Extension Order
Status. Quelle: Wildsmile Studios, Entwicklungsumgebung
http://dev.stickma.de, 2010.......................................................................42
50
Eidesstattliche Erklärung
Ich, Christoph Joschko, erkläre an Eides statt, dass ich die vorliegende Arbeit selbstständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe.
Die Zustimmung der Firma zur Verwendung betrieblicher Unterlagen habe ich eingeholt.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form weder veröffentlicht noch einer anderen Prüfungsbehörde vorgelegt.
Dresden, 25. August 2010
51