Magento ist, mit dem bisherigen Funktionsumfang, breit aufgestellt. Es beinhaltet Grundfunktionalitäten wie das Durchsuchen und Verwalten des Produktkataloges und den eigentlichen Bestellprozess mit mehreren Lieferadressen, diversen Zahlungsarten und der Sichtkontrolle. Zudem bietet Magento eine Reihe umfangreicher Marketing- und Promotion-Tools, Analysen und Reports sowie eine vollständige Bestellverwaltung mit einfacher Warenwirtschaft - also erst mal ideal um den E-Procurement-Prozess weiter zu unterstützen? ³

Zielsetzung

Die folgende Ausarbeitung soll zuerst einige Grundlagen zum E-Procurement schaffen und aus diesen Anforderungen an ein E-Commerce-Shop-System, in diesem Fall Magento, entwickeln. Ziel ist es zudem, zumindest zu einem Teil der Anforderungen, Lösungswege aufzuzeigen. Zielgruppe der Ausarbeitung sind Lieferanten, deren Kunden E-Procurement-Lösungen einsetzen wollen und diese Anforderungen an die Lieferanten herantragen. Aus Sicht des Lieferanten könnte somit auch von B2B-E-Commerce gesprochen werden.

Struktur dieser Arbeit

Im ersten Teil dieser Arbeit werden allgemeine Grundlagen zum Thema E-Procurement geschaffen. Aus dem Teil gehen Anforderungen an einen E-Commerce-Shop hervor die, im zweiten Teil der Arbeit, im Rahmen von Magento geprüft bzw. konzeptioniert werden. Der zweite Teil der Arbeit ist bedingt durch die wenige Magento-Literatur zu dem Thema in Teilen empirisch⁴ gewachsen.

E-Procurement

Grundlagen

E-Procurement Lösungen liegen im Moment weiterhin absolut im Trend. Aktuelle Zahlen zeigen, dass durch die Einführung eines E-Procurement-Systems die Transaktionskosten um 25% gesenkt werden können.⁵ Dazu einmal zwei Definitionen:

• E-Procurement hilft Unternehmen, Waren und Dienstleistungen zu den geringsten Gesamtkosten zu beschaffen, wobei der gesamte Einkaufsprozess von der Planung über die Beschaffung bis zur Bezahlung automatisiert wird.⁶
• E-Procurement unterstützt die Beziehungen und Prozesse eines Unternehmens zu seinen Lieferanten mit Hilfe von elektronischen Medien⁷

So überwiegen bei vielen Unternehmungen die administrativen Tätigkeiten innerhalb des Beschaffungswesens. Dazu gehört z.B. das Suchen des richtigen Bestellanforderungsformulares, Koordination mit Arbeitskollegen, Korrespondenz mittels Telefon, Fax oder E-Mail mit dem Lieferanten aber auch Berichtswesen. Diese Schritte können und sollen durch die Einführung eines E-Procurement-Systems deutlich reduziert werden.⁸

In der Praxis können zwei Gruppen von E-Procurement-Lösungen unterschieden werden. Auf der einen Seite stehen die Systeme zur Beschaffung von direkten Gütern.⁹ Hier kommen spezielle Anbindungen der ERP-Systeme mittels EDI zum Einsatz. Dies begründet sich dadurch, dass bei direkten Gütern in der Regel langfristige Kooperationen mit dem Lieferanten angestrebt werden - der Aufwand beide Systeme zu integrieren lohnt also. Auf der anderen Seite stehen Systeme zur Beschaffung von indirekten Gütern.¹⁰ Hier setzen die Unternehmen, um Aufwand bei der Integration zu sparen, in der Regel auf Desktop Purchasing Systeme (DPS). Das sind Systeme, die einen dezentralen Einkauf am Arbeitsplatz mittels Webbrowser ermöglichen.¹¹

Beim DPS-System über den Webbrowser liegt der Fokus ebenfalls auf der Unterstützung und Automatisierung des Bestellprozesses. Sie basieren in der Regel auf elektronischen Produktkatalogen aus denen die benötigen Produkte ausgewählt werden. Die so entstandene Bestellung wird automatisch an das ERP-System des Lieferanten übertragen. Dabei sollte in der Regel der gesamte operative Prozess im Workflow, wie z.B. Verfügbarkeitsprüfung und Genehmigung abgedeckt werden. Im Wesentlichen gibt es für die Umsetzung von E-Ordering drei Möglichkeiten: Einkauf über eine externe Lösung auf Verkäuferseite (Sell-Side), Erstellung einer eigenen Lösung unternehmensintern (Buy-Side) und Einkauf auf einem katalogbasierten Marktplatz. Die Einteilung erfolgt also anhand der Katalogverantwortlichkeit.¹³ Dies verdeutlicht noch einmal Abbildung sell-buy-side.

Das bedeutet: Bei der Sell-Side-Lösung wird die Geschäftslogik bzw. der Bestellprozess vollständig vom System des Lieferanten abgebildet. Bei der Buy-Side-Lösung dagegen liegt die Logik im eigenen Unternehmen. Hier besteht die Herausforderung darin Katalogdaten und eventuelle Produktabhängigkeiten korrekt abzubilden.¹⁴

Für die aus der Einleitung bekannte Problemstellung (der Kunde eines Lieferanten möchte E-Procurement-Lösungen einführen) bleiben somit zwei Lösungswege: Zum einem stellt der Lieferant dem Kunden seinen Produktkatalog zur Verfügung, zum anderen bietet er seinen Kunden eine Sell-Side-Lösung an. Im Rahmen dieser Arbeit wird nun ausschließlich die Sell-Side-Lösung näher betrachtet.

Sell-Side-Lösung

Bei Sell-Side-Lösungen werden sowohl die Einkaufssoftware als auch der Katalog vom Lieferanten zur Verfügung gestellt. Diesen Ansatz verfolgt die grosse Zahl der
E-Shops, die heute im B2B-Geschäft zum Einsatz kommen. Bei diesen Lösungen muss sich ein Besteller bei jedem Lieferanten neu einloggen und sich mit den unterschiedlichen Designs und Navigationsstrukturen auseinandersetzen. Die Transaktionsdaten fallen beim Lieferanten an und es bedarf zusätzlicher Instrumente (Import-/Exportschnittstellen, manuelle Eingaben), um sie in den Systemen der beschaffenden Organisation verfügbar zu machen. Einige Lieferanten bieten heute auf ihren Sell-Side-Lösungen bereits umfangreiche Personalisierungsfunktionen an (z.B. Abbildung kundenindividueller Regeln für den Beschaffungsprozess), die einen Teil der Nachteile dieser Lösungen für den Kunden wettmachen sollen. Der Vorteil von Sell-Side-Lösungen liegt vor allem darin, dass der Lieferant seine Produkte optimal präsentieren und spezifische Funktionen (z.B. eine geführte Produktkonfiguration oder Kompatibilitätsprüfung) integrieren kann.¹⁵¹⁶

Die wesentliche Aufgabe von Sell-Side-Lösungen ist es also den Beschaffer beim Sourceing zu unterstützen. Prozesse des Unternehmens bleiben hier jedoch erst einmal außen vor. Viele Sell-Side-Lösungen bieten mittlerweile jedoch eine umfangreiche Anzahl an Personalisierungen, so dass Kunden Teile ihrer internen Prozesse im System abbilden können.¹⁷Vgl. (Kollmann, 2007, S. 76)

Sell-Side-Lösungen mit Magento

Im März 2007 begann Varien, der Hersteller hinter dem E-Commerce-System Magento, mit der Konzeption des Systems und veröffentlichte im August 2007 eine erste frühe Beta-Version. Drei Jahre später hat sich das System soweit im Markt durchgesetzt das das Suchvolumen zum Suchwort 'Magento' mittlerweile das Volumen nach 'E-Commerce' überholt hat.¹⁸ Meiner Meinung nach zeigt dies deutlich welches Potenzial in Magento steckt. Magento, welches zur Zeit in der Version 1.4.1.1 vorliegt, bringt eine Reihe von Basis-Features mit die für Sell-Side-Lösungen relevant sein können.¹⁹

Basisfunktionen

Produktkatalog

Magento bildet die Produkte über verschiedene Produkttypen ab. Dazu zählen einfache Produkte, wie z.B. ein bestimmte DVD, genauso wie konfigurierbare Produkte wie z.B. ein T-Shirt, bei dem noch Farbe und Größe ausgewählt werden müssen. Die jeweiligen Produkttypen lassen sich sich durch sogenannte Attribute und Attributes-Sets einfach verwalten. Das hat den Vorteil, dass Sie bei unterschiedlichen Produkten verschiedene Darstellungsformen und tabellarische Informationen angeben können. Des weiteren bringt der Produktkatalog Basisfeatures wie Kategorisierung, verschiedene flexible Sortierungen, Themenwelten und eine rudimentäre Suche nach konfigurierbaren Inhalten mit.²⁰

Bestellvorgang

In Magento ist es sowohl möglich eine Bestellung bequem auf einer Seite mit allen notwendigen Informationen schnell und übersichtlich zu tätigen oder, alternativ, eine Bestellung auf mehrere Lieferadressen aufzuteilen.²¹

Der Bestellvorgang beginnt in Magento mit dem Schritt Produkte in den Warenkorb zu legen. Es folgt im Magento-Standard die Auswahl zwischen Registrierung, Anmeldung mit einem bestehenden Kundenkonto oder die Bestellung als Gast. Im E-Procurement Umfeld sollten jedoch alle Möglichkeiten bis auf Anmeldung mit einem bestehenden Kundenkonto deaktiviert werden. Danach können die Rechnungsinformation übernommen oder bearbeitet werden. Es ist möglich aus einer Reihe von vorher definierten Rechnungsinformation zu wählen. Im nächsten Schritt wird die Versandadresse hinterlegt. Auch hier kann wieder aus einer Auswahl von bestehenden Adressen gewählt werden. Als nächstes wird die Versandart bestimmt. Im E-Procurement Umfeld könnte z.B. zwischen Standard und Expressversand unterschieden werden. In wie weit der nächste Schritt, die Angabe von Zahlungsinformationen relevant ist, muss im Einzelfall genauer geprüft werden. Es wäre denkbar diesen Schritt vollständig zu deaktivieren oder den Mitarbeiter aus einer Reihe von für ihn relevanten Kostenstellen wählen zu lassen. Der letzte Schritt, die Bestellübersicht oder auch Sichtkontrolle, listet noch einmal alle Informationen übersichtlich auf. An dieser Stelle kann der Kunde die Bestellung endgültig übermitteln oder noch einmal verändern.²²

Zugriffsbeschränkungen

Je nachdem wie transparent sich der Lieferant, der seinen Katalog als Sell-Side-Lösung online stellt, im Web machen möchte benötigt es noch einige Einschränkungen im Katalog.

• Katalog für angemeldete Benutzer: Möchte sich der Lieferant möglichst nur Partnerunternehmen im Web mit seinem vollständigen Sortiment präsentieren macht es Sinn den Katalog nur nach Anmeldung zur Verfügung zu stellen. Dazu muss, sollte der Kunde nicht eingeloggt sein, jede Anfrage einer Produktauflistung oder eines Produktes zuerst zur Anmelde-Seite weitergeleitet werden. Des weiteren muss dafür gesorgt werden, dass Kunden sich nicht, wie sonst in Magento üblich, registrieren und dann selbst durch Bestätigung der eigenen E-Mailadresse freischalten. Hier ist es erforderlich das ein zuständiger Mitarbeiter neue Kunden prüft, eventuell Verträge aushandelt, und im folgenden erst die Kunden freischaltet. Für beide Anforderungen gibt es bereits freie Erweiterungen die über MagentoConnect²³ bezogen werden können: Die Erweiterung Login only catalog²⁴ sorgt dafür das ausschließlich angemeldete Kunden einen Blick in den Katalog werfen können. Die Freischaltung der Kunden dagegen wird mittels der Erweiterung Customer Activation²⁵ umgesetzt.
• Individueller Katalog: In der Praxis kommt oft die Anforderung auf, dass die Sortimente, die der Kunde über eine Sell-Side-Lösung beziehen kann, auf einige Kategorien eingeschränkt werden. Das hat für den Kunden den klaren Vorteil, dass seine Mitarbeiter ausschließlich vorher genehmigte und geprüfte Produkte beim Lieferanten einkaufen können - auf Seiten des Lieferanten vermeidet es Irritationen mit dem Einkaufsleiter des Kunden. Für diese Anforderung, die die Standard-Installation von Magento nicht beinhaltet, gibt es ebenfalls eine Erweiterung mit dem Namen Netzarbeiter GroupsCatalog²⁶. Sie ermöglicht es vollständige Kategorien oder alternativ einzelne Produkte für bestimmte Kundengruppen auszuschließen.

Genehmigungshierachie

Ein gutes E-Procurement System benötigt, damit Mitarbeiter nicht endlos bestellen sondern strukturiert vorgehen, einige Strukturen zur endgültigen Genehmigung einer solchen Bestellung. In aktuellen Monographien zum Thema sind in der Regel folgende genannt:

• Vier-Augen-Prinzip: Beim Vier-Augen-Prinzip muss jede Bestellung eines Mitarbeiters durch einen anderen freigegeben werden. Bei C-Teilen macht dies in der Regel wenig Sinn. Hier sind die Kosten der Teile oftmals geringer als zwei Mitarbeiter die die Bestellungen gemeinsam durchführen.²⁷
• Wertegrenze: Es können Wertegrenzen festgelegt werden, innerhalb derer jeder Mitarbeiter seinen Bedarf ohne Genehmigung durch einen Vorgesetzten automatisch bestellen kann. Bei der Bestellung einer neuen Maus für den Computer [..] macht es wohl kaum einen Sinn, jedes Mal die Genehmigung des entsprechenden Vorgesetzten einzuholen. [..] Die Wertegrenzen können auf Kontoebene, Artikelebene, Artikelgruppenebene oder auf einem bestimmten Gesamtwert festgesetzt werden. Unterhalb der festgelegten Grenze kann der Anforderer seinen Bedarf selbst genehmigen. Wird diese Grenze überschritten, wird die Anforderung zu dem vorgesehenen Genehmiger weitergeleitet.²⁸Zur nachträglichen Genehmigung einer Bestellung sind zwei Verfahren vorstellbar. Im ersten ist jedem Mitarbeiter ein Vorgesetzter zugeordnet. Sobald eine Genehmigung, z.B. durch eine Überschreitung einer Wertgrenze erforderlich ist, wird der Vorgesetzte aktiv informiert das eine Bestellung zur Genehmigung vorliegt. Dieses Verfahren verhält sich rekursiv, was bedeutet, dass die Freigabe des Vorgesetzten mitunter eine Genehmigung seines Vorgesetzten mit sich bringt. Das zweite Verfahren ist nach meinem Verständnis eher für Unternehmen mit flexibleren Strukturen ausgelegt. Hierbei wird die Genehmigung anhand des Organigramms geregelt. Dadurch kann der Mitarbeiter, der eine Genehmigung benötigt, auswählen welcher höhere Mitarbeiter seine Bestellung genehmigen soll. Dies bietet gerade in einer Matrix-Organisation die benötigte Flexibilität in Projekten.²⁹

Das Vier-Augen-Prinzip benötigt nicht zwanghaft eine Implementierung in Magento. Dies könnte der Kunde des Lieferanten auch durch einfache Arbeitsanweisungen im Workflow realisieren. Das Genehmigungsverfahren Wertegrenze dagegen schon. Hier ist an erster Stelle abzuwägen wie komplex die Implementierung der Genehmigungsverfahren sein darf. Es benötigt, für den Fall das der Lieferant das System auch anderen Kunden anbieten möchte, eine generische Lösung. Bedenkt man, dass jede Organisation kleinere und größere Besonderheiten hat ist das Abbilden einer kompletten Organisation, mit allen ihren Besonderheiten, vermutlich deutlich zu aufwendig um wirtschaftlich zu bleiben. Es bleibt die Genehmigung über den direkten Vorgesetzten. Mit ist z.Z. kein Modul bekannt, das eine solche Anforderung annähernd abbildet. Vermutlich müsste dies noch implementiert werden. Dazu wäre es notwendig, je Kunde des Lieferanten, eine Kundengruppe mit dem Namen des Unternehmens zu erstellen. Alle Mitarbeiter des Kundens, die Zugriff auf den Katalog haben, befinden sich somit in der selben Kundengruppe. Zudem benötigt es ein weiteres Feld welches ermöglicht jedem Mitarbeiter einen Vorgesetzten zuzuteilen. Vorgesetzten sollte es möglich sein weitere Mitarbeiter anzulegen. Das Rechte-System ist hier ganz klar Top-Down. Das bedeutet, das ein Vorgesetzter weitere, ihm zugeteilte Mitarbeiter anlegen darf, Mitarbeiter dagegen ihre Vorgesetzten nicht selbst ändern dürfen. Vergleichbar verhält es sich mit den Wertegrenzen: Vorgesetzte können ihr Budget auf ihre Mitarbeiter aufteilen. Sie können ihr eigenes Budget aber nicht bearbeiten. Abbildung Genehmigung verdeutlicht das Verfahren der Genehmigung noch einmal. [caption id="attachment_1291" align="alignnone" width="437" caption="Vereinfachtes Zustandsdiagramm Genehmigungsverfahren"]

[/caption] Die Verwaltung sollte, um Verwirrung zu vermeiden, vollständig im Magento Frontend stattfinden. Die Verwaltung der Mitarbeiter und Wertgrenzen findet somit im selben System statt wie die Abbildung des Katalogs und der Bestellvorgang. Bestellungen, die noch nicht freigegeben wurden, bleiben bis zur endgültigen Freigabe im Status "warte auf Freigabe". Abgelehnte Bestellungen werden, um das Reporting nicht zu verfälschen, storniert.³¹

Reporting

Der Vorgesetzte sollte die Möglichkeit haben mittels Reporting zu erfassen welche Mitarbeiter welche Produkte zu welchem Zeitpunkt und zu welchem Preis bestellt haben. Hier können leider nicht die Magento Statistiken direkt verwendet werden. Diese beziehen sich auf das komplette System und beinhalten somit auch Bestellungen von Mitarbeitern anderer Abteilungen. Eine an das Genehmigungsverfahren angepasste Statistik ist somit unumgänglich. In der Startphase sollten jedoch ausreichen wenn folgende Fragen klären zu können:

• Welcher Mitarbeiter hat wann wie viel bestellt? (Wertmäßig)
• Welche Produkte wurden (von Mitarbeiter x) zu welchem Preis in Zeitraum y bestellt?
• Wie verhält sich das aktuelle Budget der Mitarbeiter bzw. der Kostenstelle?
• Wie viele (und welche) Bestellungen mussten genehmigt werden und wie lange dauerte dies?
• Wie vielen Bestellungen wurde die Genehmigung verwehrt?

Alle Statistiken sollten im Account des Vorgesetzten direkt abrufbar sein.³²

Integration

Integration impliziert eine oder mehrere Applikationen, welche in einem gemeinsamen Rahmen zusammenwirken müssen. Dieser Integrationsrahmen sorgt für die gemeinsame Plattform, um Verbindungen zu erzeugen, gemeinsame Daten zu speichern, Meldungen von einem Punkt zum anderen zu senden, Sicherheit, Autorisierung und andere gemeinsame Funktionen zu gewährleisten.³³ Applikationen, welche in einem gemeinsamen Rahmen zusammenwirken müssen sin,d an dieser Stelle drei unterschiedliche Systeme:

• ERP-System des Lieferanten
• Magento E-Commerce System
• ERP-System des Kunden

Bestellungen, Kundendaten und der Produktkatalog sollten problemlos zwischen ERP-System des Lieferanten und Magento synchronisiert werden. Hier gilt es einige Probleme wie z.B. Datenkonflikte zu lösen. Details hierzu habe ich bereits in meiner zweiten Praxisarbeit zum Thema Integration eines Magento-Webshops in ein bestehendes ERP-System.³⁴ erläutert. Eine nicht unbedingt notwendige Integration findet zwischen Magento und dem ERP-System des Kunden statt. Hier wäre es denkbar in regelmäßigen Abständen EDI-Meldungen zu aktuell getätigten Bestellungen bzw. Bestellstati mittels Export zu liefern. Dies ermöglicht es dem Kunden die Warenannahme, Warenprüfung und Rechnungsprüfung weitgehend zu automatisieren.³⁵

GUI

Um den Anwendern die Arbeit deutlich zu erleichtern sollten Design und Navigationsstruktur vergleichbar zu üblichen Systemen am Markt sein. Wie in Abbildung gui zu sehen ist stellt das zentrale Element der Seite oftmals die Suche [1] dar. Die Kategorieauflistung [2] erweitert diese Darstellung. Beides ist in der Regel auf der linken Seite platziert wobei Einstellungen des Kundenkontos (=Profil) und Bestellstatus in der Regel in der Kopfnavigation [8-10] zu finden sind. Der Inhaltsbereich auf der Startseite setzt sich meist aus Topseller, Favoriten oder allgemeinen Informationen zusammen.³⁶ [caption id="attachment_1292" align="alignnone" width="650" caption="Aussehen eines Standard DPS, Nekolar, 2003, S. 36"]

[/caption]

Fazit

Mit Magento ist es durchaus möglich E-Procurement Anforderungen zu erfüllen. Das System enthält beinahe alle Features großer (und teurer) Enterprise E-Commerce-Systeme die mitunter auch zum E-Procurement eingesetzt werden. Die Basisanforderungen wie Artikelauswahl und Zusammenstellung im Warenkorb, sowieso Bestellanforderung und Bestellübermittelung, bringt das System von Haus aus mit. Limitkontrollen mit Genehmigungsverfahren müssen dagegen zusätzlich implementiert werden. Meiner Meinung nach ist es nur eine Frage der Zeit bis Module auf den Markt kommen die Magento kostengünstig um die benötigten Funktionalitäten erweitert - ein System mit Zukunft. Sie möchten eine solche Lösung in Ihrem Unternehmen einsetzen? Sprechen Sie uns an.

Quellen

Die Literaturangaben sind alphabetisch nach den Namen der Autoren sortiert. Bei mehreren Autoren wird nach dem ersten Autor sortiert. ALEXANDER STEIREIF, Rouven Alexander R. : Webshops mit Magento. 1. Auflage. 2009 KOLLMANN, Tobias: E-Business, Grundlagen elektronischer Geschäftsprozesse in der Net Economy. 1. Auflage. 2007 NEKOLAR, Alexander-Philip: e-Procurement, Euphorie und Realität. 1. Auflage. Springer, 2003 SCHUBERT, Petra: E-Procurement: Elektronische Unterstützung der Beschaffungsprozesse im Unternehmen.1. Auflage. 2002 STOLL, Patrick P.: Handbuch E-procurement: Grundlagen,standards und Situation amMarkt.1. Auflage. 2007

Fussnoten

1(Nekolar, 2003, Vorwort) 2Vgl. (Schubert, 2002, S. 1) 3Vgl. (Alexander Steireif, 2009, S. 23ff) 4auf Erfahrung beruhend; aus Erfahrung gewonnen 5Vgl. (Nekolar, 2003, S. 3) 6(Nekolar, 2003, S. 1) 7(Schubert, 2002, S. 2) 8Vgl. (Nekolar, 2003, S. 1) 9Handelsware oder Vorleistungen die direkt in die Eigenleistung einfließen 10Produkte und Leistungen die das Unternehmen für den eigenen Betrieb benötigt: Verbrauchsmaterial bzw. MRO-Produkte 11Vgl. (Schubert, 2002, S. 4) (Schubert, 2002, S. 5) 13(Stoll, 2007, S. 20) 14Vgl. (Schubert, 2002, S. 5) 15(Schubert, 2002, S. 5) 16Vgl. (Kollmann, 2007, S. 76)... können. 18Vgl. www:google-trends 19Vgl. (Alexander Steireif, 2009, S. 23ff) 20Vgl. (Alexander Steireif, 2009, S. 23ff) 21Vgl. (Alexander Steireif, 2009, S. 23ff) 22Vgl. (Alexander Steireif, 2009, S. 167ff) 23MagentoConnect ist die offizielle Plattform für Magento-Erweiterungen 24http://www.magentocommerce.com/magento-connect/vinai/extension/490/login-only-catalog 25http://www.magentocommerce.com/magento-connect/vinai-kung/extension/489/customer-activation 26http://www.magentocommerce.com/magento-connect/vinai/extension/635/netzarbeiter_groupscatalog 27Vgl. (Nekolar, 2003, S. 25f) 28(Nekolar, 2003, S. 25) 29Vgl. (Nekolar, 2003, S. 25f) eigene Darstellung 31Vgl. (Nekolar, 2003, S. 25f) 32Vgl. (Nekolar, 2003, S. 25f) 33(Nekolar, 2003, S. 131f) 34http://www.webguys.de/magento/integration-eines-magento-webshops-in-ein-bestehendes-erp-system/ 35Vgl. (Nekolar, 2003, S. 27) 36Vgl. (Nekolar, 2003, S. 36) (Nekolar, 2003, S. 36)