Erstellung eines E-Commerce-Systems im
Werbung
Erstellung eines E‐Commerce‐Systems im Zusammenspiel mit Microsoft SharePoint 2013 Anbindung eines Shop‐Systems an ein auf SharePoint 2013 basierendes PIM‐System Bachelorarbeit Vorgelegt von Heiko Angermann aus Kulmbach am 30. Januar 2014 an der Hochschule der Medien in Stuttgart Fakultät Druck und Medien Erstprüfer: Prof. Dr.‐Ing. Arno Hitzges Zweitprüfer: Dipl. Math. Arndt Kraft Lehrveranstaltung: Thesis EDV‐Nr.: 11555 Matrikel‐Nummer 24142 Ehrenwörtliche Erklärung Name, Vorname, Matrikel‐Nr.: Angermann, Heiko, 24142 Studiengang, akademischer Grad (angestrebt): Druck‐ und Medientechnik, Bachelor Hiermit versichere ich, Heiko, Angermann, an Eides statt, dass ich die vorliegende Bachelorarbeit (The‐ sis) mit dem Titel "Erstellung eines E‐Commerce‐Systems im Zusammenspiel mit Microsoft SharePoint 2013 – Anbindung eines Shop‐Systems an ein auf SharePoint 2013 basierendes PIM‐System" selbstän‐ dig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinne nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht. Die Arbeit ist noch nicht veröffentlicht oder in anderer Form als Prüfungsleistung vorgelegt worden. Ich habe die Bedeutung der eidesstattlichen Versicherung und prüfungsrechtlichen Folgen (§ 26 Abs. 2 Bachelor‐SPO Hochschule der Medien Stuttgart) sowie die strafrechtlichen Folgen (vgl. Auszug aus dem Strafgesetzbuch) einer unrichtigen oder unvollständigen eidesstattlichen Versicherung zur Kennt‐ nis genommen. Auszug aus dem Strafgesetzbuch (StGB) § 156 StGB Falsche Versicherung an Eides Statt Wer von einer zur Abnahme einer Versicherung an Eides Statt zuständigen Behörde eine solche Versi‐ cherung falsch abgibt oder unter Berufung auf eine solche Versicherung falsch aussagt wird mit Frei‐ heitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft. Stuttgart, 30.01.2014 Ort, Datum Signatur ii Kurzreferat Die vorliegende Studie versucht einen möglichst konkreten Lösungsansatz für die beidseitige Wech‐ selbeziehung zwischen Informationsmanagement‐ und E‐Commerce‐System zu geben. Von besonde‐ rem Interesse ist hierbei die Übernahme von Auszeichnungsmerkmalen (Folksonomie und Taxono‐ mie) der Artikel. Hintergrund ist die aktuelle Herausforderung ein anhaltend exponentiell steigendes Datenvolumen (Big Data), z. T. aus vielfältigen Datenquellen, zentral speichern und verarbeiten zu können. Aus erwähntem Anlass werden verschiedene Technologie‐Ansätze, im Kontext der Interakti‐ onsgüte, qualifiziert und mittels eines übertragbaren Rahmenkonzeptes diskutiert. Anhand eines Re‐ ferenzmodelles werden geschilderte Anwendungen und Funktionalitäten exemplarisch verdeutlicht. Schlagworte: E‐Commerce, SharePoint 2013, Web‐Shop, Produktinformationsmanage‐ ment, PIM, Contentmanagement, CMS, Structured Query Language, SQL, Business Data List Connector, BDLC, Business Connectivity Services, BCS iii Abstract This study attempts to give a concrete possible solution to the bilateral correlation between Infor‐ mationmanagement and E‐Commerce‐system. Of particular interest in this context, the acquisition of award features (folksonomy and taxonomy) of the articles. The background is the current challenge of a persistently exponentially increasing volume of data (Big Data), partly from a variety of data sources, to be stored and handled centrally. Off‐mentioned occasion, various technological approaches in the context of interaction quality, are qualified and by means of a transferable framework concept dis‐ cussed. A conlusive reference‐model illustrates the described applications and functionalities as exam‐ ples. Keywords: E‐Commerce, SharePoint 2013, Web‐Shop, Produktinformationsmanage‐ ment, PIM, Contentmanagement, CMS, Structured Query Language, SQL, Business Data List Connector, BDLC, Business Connectivity Services, BCS iv Vorwort Die vorliegende Arbeit entstand als Abschlussarbeit (Thesis) während meines Studiums der „Druck‐ und Medientechnik“ an der Hochschule der Medien, Fakultät „Druck und Medien“ in Stuttgart. Sie wurde von Herrn Prof. Dr.‐Ing. Arno Hitzges (Erstbetreuer) und Herrn Dipl.‐Math. Arndt Kraft (Zweit‐ betreuer) betreut. Herrn Prof. Dr.‐Ing. Arno Hitzges, Professor in den Lehrgebieten Datenbanken und Contentmanage‐ ment, Database‐ und Crossmediapublishing sowie IT‐Projektmanagement an der Hochschule der Me‐ dien, gilt mein besonderer Dank für seine stets kompetente, freundliche und fördernde Unterstützung dieser Abschlussarbeit. Herrn Dipl.‐Math. Arndt Kraft, Leiter der Abteilung ECM Development bei der Infoman AG in Stuttgart danke ich sehr für die Übernahme der Zweitkorrektur. Herrn B. Eng. Jens Gäbeler danke ich besonders für die Durchsicht der Arbeit und konstruktive Kritik. Ein bedeutender Dank gebührt auch meiner Familie. Meiner Mutter Elfriede Angermann, die mir stets den Rücken bei Erledigungen rund um das Studium frei hielt. Meinem Vater Joachim Angermann, ohne dessen Inspiration ich die Druck‐ und Medienbranche wohl nie kennen‐ und schätzen gelernt hätte. Meinem Bruder Markus Angermann, der mir in Sachen Engagement und Lerneifer stets ein positives Vorbild war. Stuttgart, im Januar 2014 Heiko Angermann v Inhaltsverzeichnis EHRENWÖRTLICHE ERKLÄRUNG ..............................................................................................................ii Auszug aus dem Strafgesetzbuch (StGB) ..................................................................................................ii KURZREFERAT ......................................................................................................................................... III ABSTRACT ............................................................................................................................................... IV VORWORT ............................................................................................................................................... V INHALTSVERZEICHNIS ............................................................................................................................. VI ABBILDUNGSVERZEICHNIS ..................................................................................................................... XI TABELLENVERZEICHNIS ........................................................................................................................ XIII VERZEICHNIS DER VERWENDETEN ABKÜRZUNGEN ............................................................................. XIV HINWEIS FÜR DIE LESERSCHAFT ........................................................................................................... XVI 1. ZIELSETZUNG UND VORGEHENSWEISE ..................................................................................... 1 1.1. Zielsetzung ........................................................................................................................... 1 1.2. Vorgehensweise ................................................................................................................... 2 2. WECHSELBEZIEHUNGEN ZWISCHEN EIN‐ UND AUSGABEMEDIEN ............................................. 3 2.1. Motivation und Einführung .................................................................................................. 3 2.1.1. Einführung in Systeme für die Produktdatenverwaltung .................................................... 3 2.1.2. Gegenwärtiger Standpunkt im E‐Commerce‐Handel .......................................................... 4 2.2. Steigende Datenmengen und crossmediale Nutzformen ...................................................... 5 2.2.1. Aktuelle Herausforderungen im Multi‐Channel‐Vertrieb ................................................... 6 2.2.2. Bedeutende Methoden für die Suchoptimierung ............................................................... 7 2.2.3. Technologien zur Auszeichnung von Daten ........................................................................ 7 2.3. Einführung in SharePoint Server 2013 und SmartStore.NET .................................................. 7 2.3.1. Wesentliche Neuerungen in SharePoint Server 2013 ......................................................... 8 2.3.2. Vorstellung des E‐Commerce‐Systems SmartStore.NET ..................................................... 8 3. 3.1. MARKTRELEVANTE E‐COMMERCE‐SYSTEME IM ÜBERBLICK ..................................................... 9 Einführung in die Marktstudie .............................................................................................. 9 3.2. Ergebnisse der Marktstudie ............................................................................................... 10 3.2.1. Intershop ........................................................................................................................... 10 vi 3.2.1.1. Allgemeine Informationen ............................................................................................ 10 3.2.1.2. Kernfunktionen im Überblick ........................................................................................ 10 3.2.2. Heiler und Demandware ................................................................................................... 10 3.2.2.1. Allgemeine Informationen ............................................................................................ 10 3.2.2.2. Kernfunktionen im Überblick ........................................................................................ 10 3.2.3. Hybris ................................................................................................................................. 11 3.2.3.1. Allgemeine Informationen ............................................................................................ 11 3.2.3.2. Kernfunktionen im Überblick ........................................................................................ 11 3.2.4. Magento ............................................................................................................................ 11 3.2.4.1. Allgemeine Informationen ............................................................................................ 11 3.2.4.2. Kernfunktionen im Überblick ........................................................................................ 11 3.2.5. Commerce Server .............................................................................................................. 12 3.2.5.1. Allgemeine Informationen ............................................................................................ 12 3.2.5.2. Kernfunktionen im Überblick ........................................................................................ 12 3.2.6. Strato ................................................................................................................................. 12 3.2.6.1. Allgemeine Informationen ............................................................................................ 12 3.2.6.2. Kernfunktionen im Überblick ........................................................................................ 12 3.2.7. Xt:Commerce ..................................................................................................................... 13 3.2.7.1. Allgemeine Informationen ............................................................................................ 13 3.2.7.2. Kernfunktionen im Überblick ........................................................................................ 13 3.2.8. Omeco ............................................................................................................................... 13 3.2.8.1. Allgemeine Informationen ............................................................................................ 13 3.2.8.2. Kernfunktionen im Überblick ........................................................................................ 13 3.2.9. WebSale ............................................................................................................................. 13 3.2.9.1. Allgemeine Informationen ............................................................................................ 13 3.2.9.2. Kernfunktionen im Überblick ........................................................................................ 14 3.2.10. SmartStore.NET ................................................................................................................. 14 3.2.10.1. Allgemeine Informationen ........................................................................................ 14 3.2.10.2. Kernfunktionen im Überblick .................................................................................... 14 4. AUSGANGSSITUATION UND BEKANNTE PROBLEME ............................................................... 15 4.1. Analyse der PIM‐Ansätze ................................................................................................... 15 4.1.1. XSL‐Transformation (XML‐Input) ....................................................................................... 15 4.1.2. Spread‐Sheet‐Import (CSV‐Input) ..................................................................................... 15 4.1.3. Data‐Connection (XML‐Input) ........................................................................................... 16 4.2. Untersuchung des bestehenden Produktkataloges ............................................................. 16 4.2.1. Produktmigration und Suche............................................................................................. 16 4.2.2. Veränderung der Datenkonsistenz .................................................................................... 16 4.2.3. Exportmöglichkeiten des Kataloges .................................................................................. 17 4.3. 5. 5.1. Übergreifend bekannte Probleme ...................................................................................... 17 KONZEPTMODELL FÜR DIE ENTWICKLUNG DER SYSTEM‐INTERAKTION .................................. 19 Bestandteile des Rahmenkonzeptes ................................................................................... 19 5.2. Akteure und Anwendungsfälle im Web‐Shop‐Umfeld ........................................................ 19 5.2.1. Berechtigungsstufen in SharePoint 2013 und SmartStore.NET ........................................ 20 vii 5.2.2. 5.2.3. 5.2.3.1. 5.2.3.2. User‐Stories und Best‐Practice der Akteure ...................................................................... 20 Use Cases inner‐ und außerhalb der E‐Commerce‐Plattform ........................................... 22 Entwicklung einer Use‐Case‐Schablone für die Detailbetrachtung .................................. 23 Definierte Use Cases und deren Abläufe ........................................................................... 24 5.3. Unterteilung der Integrations‐Komponenten ..................................................................... 25 5.3.1. Anforderung an die Technologie ....................................................................................... 26 5.3.2. Entwicklung von Güte‐Parametern zur Technologie‐Auswahl .......................................... 26 5.3.3. Übersicht relevanter Technologien ................................................................................... 26 5.3.3.1. Website‐Sammlung Produktkatalog .............................................................................. 27 5.3.3.2. Business Connectivity Services (BCS) ............................................................................ 27 5.3.3.3. Business Data List Connector (BDLC) ............................................................................. 27 5.3.4. Vergleich und Auswertung der Technologien ................................................................... 27 5.3.4.1. Datenkonsistenz Produktmanagement ......................................................................... 28 5.3.4.2. Datenkonsistenz Kundenaktionen ................................................................................. 28 5.3.4.3. Barrieren im Datenaustausch ........................................................................................ 28 5.3.4.4. Zeitbedarf verschiedener Funktionen ........................................................................... 28 5.3.4.5. Anbindungsfähigkeit an Drittsysteme ........................................................................... 28 5.3.4.6. Verwaltungsfähigkeit ..................................................................................................... 29 5.3.5. Technologie‐Entscheid und Begründung .......................................................................... 29 5.4. Integrations‐Komponente Kundenverwaltung .................................................................... 29 5.4.1. Findung von Produkten ..................................................................................................... 30 5.4.2. Bestellung von Produkten und Stammdaten‐Integration ................................................. 30 5.4.2.1. Transfer der Kunden‐Stammdaten von SmartStore.NET zu Active Directory ............... 31 5.4.2.2. Datenanbindung und CSV‐Export in Microsoft Excel .................................................... 31 5.4.2.3. Power‐Shell‐Import des CSV‐Files nach Active Directory .............................................. 32 5.4.2.4. Transfer der Kunden‐Stammdaten aus Active Directory zu SharePoint ....................... 32 5.4.2.5. Automatisierte Anpassung bei der SharePoint Installation .......................................... 32 5.4.3. Bewertung von Produkten ................................................................................................ 32 5.4.3.1. Transfer artikelbezogener Bewertungen von SmartStore.NET zu SharePoint .............. 33 5.4.3.2. Kombination verschiedener SQL‐Tabellen in SharePoint für erhaltene Bewertungen . 33 5.4.4. Weitere soziale Aktivitäten ............................................................................................... 33 5.4.4.1. Transfer artikelübergreifender Kundeneinträge von SmartStore.NET zu SharePoint .. 33 5.4.4.2. Verwaltung verschiedener Blog‐/Foren‐Themengebiete in SharePoint ....................... 34 5.5. Integrations‐Komponente Produktdaten‐ und Designmanagement .................................... 34 5.5.1. Produkte verwalten ........................................................................................................... 35 5.5.1.1. Inhalts‐ und Spaltentypen des Produktkataloges ......................................................... 35 5.5.1.2. Katalog‐Navigation mittels Term‐Store‐Integration ..................................................... 36 5.5.1.3. SQL‐Integration innerhalb des Produktkataloges ......................................................... 36 5.5.1.4. Hersteller‐, Kategorie‐ und Schlagwort‐Zuweisung mittels SQL ................................... 37 5.5.2. Produkte veröffentlichen/sperren .................................................................................... 37 5.5.2.1. Standard‐Workflow für Genehmigungsprozesse .......................................................... 37 5.5.2.2. Modifizierter Genehmigungs‐Workflow inklusive Publikationsprozess ....................... 38 5.5.3. Design verwalten ............................................................................................................... 38 5.5.3.1. Implementierung eines Design‐Editors in SharePoint .................................................. 38 5.5.3.2. Page‐Viewer WebPart für die Designintegration .......................................................... 38 5.5.3.3. SharePoint Color Palette Tool für Corporate Designs ................................................... 39 5.5.3.4. Verwaltung der migrierten Themes mittels definierter Workflows.............................. 41 viii 5.6. Integrations‐Komponente Nichtredaktionelle Ereignisse .................................................... 43 5.6.1. Änderungsmaßnahmen aufgrund erhaltener Artikelbewertungen .................................. 43 5.5.6.1. Ansätze zur Auswertung erhaltener Bewertungen ....................................................... 43 5.5.6.2. Automatisierte Mittelwertberechnung mit vorhandenen Spaltentypen ...................... 43 5.5.6.3. Automatisierter Anstoß des Verbesserungs‐Szenarios mittels Workflow .................... 44 5.6.2. Kampagnen steuern für erhöhte Absatzchancen .............................................................. 44 Lieferung verwalten für getätigte Kundenbestellungen ................................................... 45 5.6.3. 6. EINSATZERFAHRUNG UND BEWERTUNG DER VORGEHENSWEISE ........................................... 46 6.1. Beispielmigration eines neuen Produktes ........................................................................... 46 6.1.1. Migration des Artikels innerhalb des Produktkataloges ................................................... 46 6.1.2. Auszeichnung der Produkte durch Klassifikation und Schlagworte .................................. 47 6.1.3. Genehmigungsworkflow und Anstoß zur Publikation ....................................................... 47 6.2. Reaktion auf Bewertungen mittels Workflow ..................................................................... 48 6.2.1. Handlungsanstoß mittels Formelimplementierung .......................................................... 48 6.2.2. Rückschluss auf erhaltene Bewertungen .......................................................................... 49 6.3. Shop‐Umgebung aus Kundensicht ...................................................................................... 50 6.3.1. Sucherfahrung ................................................................................................................... 50 6.3.2. Look and Feel der Shop‐Oberfläche .................................................................................. 50 6.4. Vor‐ und Nachteile der Ansätze .......................................................................................... 51 6.4.1. Taxonomie‐ und Folksonomie‐Management .................................................................... 51 6.4.2. Business Data List Connector innerhalb des Produktkataloges ........................................ 51 6.4.3. Frontend‐Erfahrungen beim Gebrauch von SmartStore.NET ........................................... 52 7. ANREGUNGEN FÜR DIE WEITERENTWICKLUNG ...................................................................... 53 7.1. Kontinuierlicher Abgleich der Produktstruktur ................................................................... 53 7.2. Pflege personalisierter Kundenprofile ................................................................................ 53 7.3. Verbesserung der Sucherfahrung ....................................................................................... 54 7.4. Rückschlüsse aus Blog‐ und Foreneinträgen ....................................................................... 55 8. FAZIT ..................................................................................................................................... 56 9. LITERATUR ............................................................................................................................. 57 GLOSSAR ....................................................................................................................................... 59 ANHANG A ‐ VISUAL BASIC IMPLEMENTIERUNG ...................................................................... 61 ANHANG B ‐ SQL‐INTEGRATION UND LISTENERZEUGUNG ....................................................... 62 ix ANHANG C ‐ USE CASE SCHABLONEN ...................................................................................... 71 ANHANG D ‐ POWER SHELL SKRIPT .......................................................................................... 86 ANHANG E ‐ TABELLARISCHER VERGLEICH VERSCHIEDENER TECHNOLOGIEN .......................... 87 ANHANG F ‐ IMPORT UND EXPORTMÖGLICHKEITEN DER SYSTEME ......................................... 88 ANHANG G ‐ EINFÜHRUNG IN UML‐VERHALTENSDIAGRAMME ............................................... 95 ANHANG H ‐ BDC‐KOMPONENTEN INNERHALB DER ZENTRALADMINISTRATION ..................... 96 LEBENSLAUF .................................................................................................................................. 97 x Abbildungsverzeichnis Abb. 2‐1 PIM‐Komponenten der ECM‐Elemente (AIIM) 4 Abb. 2‐2 Exemplarische Big‐Data‐Interaktion 6 Abb. 2‐3 Exemplarischer Vergleich crossmedialer Datenströme (No‐Line, Multi‐Channel) 6 Abb. 3‐1 Übersicht studienrelevanter Shop‐Systeme 9 Abb. 4‐1 Verluste von Strukturen bei Produktkatalog‐Import 17 Abb. 5‐1 Anwendungsfälle für die Benutzergruppe "Kunden" (UC 01 bis 04) 22 Abb. 5‐2 Anwendungsfälle für die Benutzergruppe "Produktdatenmanagement" 23 (UC 05 bis 07) Abb. 5‐3 Anwendungsfälle für die Benutzergruppe "Nichtredaktionelle Abteilungen" 23 (UC 08 bis 10) Abb. 5‐4 Aktivitätsdiagramm für den Anwendungsfall "Produkte finden" (UC 01) 25 Abb. 5‐5 Exemplarischer Verbund von Relationen für Kundenstammdaten (Join) 31 Abb. 5‐6 Exemplarisches SQL‐Statement innerhalb der Excel‐Anwendung 31 Abb. 5‐7 Exemplarischer Verbund von Relationen für Blogeinträge (Join) 34 Abb. 5‐8 Exemplarische Metadaten‐Navigation mittels SP‐Term‐Store 36 Abb. 5‐9 Redundante Klassifizierungs‐Migration 37 (links: Term‐Store; rechts: Externe Liste) Abb. 5‐10 Implementierung eines Genehmigungsworkflows inklusive Publikationsanstoß 38 Abb. 5‐11 WebPart Page‐Viewer zur Design‐Vorschau 39 Abb. 5‐12 Exemplarische Design‐Migration per SharePoint Color Palette Tool 40 Abb. 5‐13 Verwaltung von Farb‐Themes innerhalb SharePoint 41 Abb. 5‐14 Implementierung individueller Formularfelder mittels InfoPath 42 Abb. 5‐15 Implementierung eines Design‐Genehmigungsworkflows 42 Abb. 5‐16 Formel‐Migration für den Spaltentyp „Calculated Data“ 44 Abb. 5‐17 Implementierung eines KVP‐Workflows 44 xi Abb. 6‐1 Konsolidierte Elementattribute für die Produktmigration 46 Abb. 6‐2 Kategorie‐Zuweisung für Produkte (Taxonomie) per ID‐Zuweisung 47 Abb. 6‐3 Exemplarische Auswirkung einer Kategorie‐Zuweisung für Produkte 47 Abb. 6‐4 Genehmigungsworkflow für den Publikationsvorgang 48 Abb. 6‐5 Exemplarische Auswirkung für genehmigte Listenelemente 48 Abb. 6‐6 Auswertung erhaltener Kundenbewertung (Rankings) 49 Abb. 6‐7 Auflistung erhaltener Kundenbewertung (Text) 49 Abb. 6‐8 Erweitertes Suchcenter des Shop‐Systems 50 Abb. 7‐1 Anwendungsfall für den Abgleich der Produktstruktur 53 Abb. 7‐2 Anwendungsfall für die Generierung personalisierter Kundenprofile 54 Abb. 7‐3 Aktivitätsdiagramm für Erweiterungsmöglichkeiten des Suchcenters 54 xii Tabellenverzeichnis Tab. 1‐1 Primär verwendete Peripherie 2 Tab. 2‐1 Bestandteile des SharePoint‐Wheel (Version 2013) 8 Tab. 5‐1 Übersicht der Akteure 20 Tab. 5‐2 Berechtigungskonzept für die Akteure 20 Tab. 5‐3 Übersicht der Anwendungsfälle 22 Tab. 5‐4 Bestandteile der Use Case‐Schablone 24 Tab. 5‐5 Exemplarische Übersicht ergänzender AD‐Attribute 32 Tab. 5‐6 Spaltentypen des Inhaltstyps "Product with Image" 36 Tab. 5‐7 Konsolidierung des Produktkataloges mit SQL‐Inhalten 37 Tab. 5‐8 Exemplarischer Vergleich verschiedener XML‐Strukturen 40 xiii Verzeichnis der verwendeten Abkürzungen AD Active Directory ADS Active Directory Service AG Aktiengesellschaft AIIM Association for Information and Image Management ASP.NET Active Server Pages.NET BCS Business Connectivity Services BDLC Business Data List Connector BDVW Bundesverband Digitale Wirtschaft CMS Content Management System CRM Customer Relationship Management CSS Cascading Style Sheets CSV Comma‐separated values DTD Dokumenttypdefinition E Electronic ECMS Enterprise‐Content‐Management‐System ERP Enterprise‐Resource‐Planning FSK Freiwillige Selbstkontrolle HTML Hypertext Markup Language ID Identifikationsnummer IM Information Management JPEG Joint Photographic Experts Group xiv KVP Kontinuierlicher Verbesserungsprozess ODBC Open Database Connectivity OleDB Object Linking and Embedding Database PDF Portable Document Format PHP Personal Home Page PIM Product‐Information‐Management SEO Search Engine Optimization SP SharePoint Server 2013 SQL Structured Query Language UC Use Case UML Unified Modeling Language URL Uniform Resource Locator VB Visual Basic WCMS Web Content Management System WYSIWYG What you see is what you get XML Extensible Markup Language XSL Extensible Stylesheet Language XSLT Extensible Stylesheet Language Transformations xv Hinweis für die Leserschaft Die vorliegende Studie verzichtet, aus Gründen der vereinfachten Lesbarkeit, auf eine geschlechts‐ neutrale Schreibweise. Stellvertretend für beide Geschlechtsformen wird nur die kürzere, männliche Schreibweise verwendet. xvi 1 Zielsetzung und Vorgehensweise 1. Zielsetzung und Vorgehensweise 1.1. Zielsetzung Der Autor bietet mit dieser Studie einen strukturierten Einblick in die Möglichkeit ein auf „Microsoft SharePoint Server 2013“ (SP) konfiguriertes Produktinformationsmanagementsystem (PIM) an die für den Endverbraucher sichtbare Web‐Shop‐Oberfläche anzubinden. Im ersten Teil der Studie findet sich eine kurze Einführung in die Thematik. Dabei wird anhand einer Literaturrecherche eine Übersicht der verwendeten Technologien in Bezug auf die Terminologie des beidseitigen Datentransfers eingegangen. Hierbei werden Motivation, verwandte Begriffe, Definitio‐ nen und allgegenwärtige Herausforderungen vorgestellt. Nach dem Exkurs zur technischen Funktions‐ weise und dem Verständnis des Zusammenspieles von Datenmechanismen (Big Data) wird dem Leser ein herstellerneutraler Überblick über den Markt an Web‐Shop‐Systemen und Vergleich dieser, in Be‐ zug auf die Anbindung an Zweitsysteme (Schnittstellen, Zahlungsabwicklung, Lieferabwicklung und Multipublishing) gegeben. Im zweiten Teil der Studie findet sich neben der Analyse der Ausgangssituation, wobei bereits unter‐ suchte PIM‐Ansätze qualitativ bewertet werden, ein Rahmenkonzept als theoretische Grundlage für eine integrierte PIM‐Shop‐Lösung, die den aktuellen Entwicklungsstand berücksichtigt (State of the Art). Primär stehen die Verwendung von Metadaten, Benutzerverwaltung sowie weitere wesentliche E‐Commerce Prozesse im Vordergrund. Konkret ist angestrebt, die im SP‐PIM erzeugten und angerei‐ cherten Produktdaten (Produktinformationen) möglichst effizient in das Shopsystem zu transferieren. Die prinzipielle Umsetzbarkeit des Rahmenkonzeptes sei abschließend anhand eines Prototyps nach‐ gewiesen. Abschließend werden Ideen und Anregungen für den weiteren Ausbau der Wechselbezie‐ hung beider Systeme geschildert. Für das Rahmenkonzept und die Machbarkeitssimulation wird die Publikation auf einem Ausgabeme‐ dium (E‐Shop) begrenzt. Die Datenhaltung erfolgt ebenfalls auf nur einem System (PIM). Es wird sich ferner auf die Wechselbeziehungen von Texten, Zahlen und Strukturinformationen beschränkt. Die Hinzunahme von Medien (z. B. Bildern) wird nicht im Detail berücksichtigt. 1 1 Zielsetzung und Vorgehensweise 1.2. Vorgehensweise In einer vorangegangenen Studie (Gäbeler, 2013) wurde die Möglichkeit untersucht, das Enterprise‐ Content‐Management‐System (ECMS) „Microsoft SharePoint Server 2013“ als PIM‐System zu nutzen. Es wurden vier verschiedene Ansätze analysiert, die aktuell gebräuchlichen Funktionalitäten von PIM‐ Systemen mit dem ECMS umzusetzen. Allerdings werden dabei lediglich die Aspekte Datenimport, Pro‐ dukte verwalten und hinzuzufügen sowie Datenexport betrachtet. Eine engere Kommunikation mit Ausgabekanälen wie zum Beispiel die Publikation als Printkatalog oder digitalisierter Katalog (E‐Shop) ist nicht beleuchtet. Zugleich liegt bereits ein umfangreicher Kriterienkatalog für Web‐Shop‐Systeme sowie darauf aufbau‐ ende Produktsteckbriefe, erfasst vom Autor der hier vorliegenden Studie, der am Markt relevantesten Systeme vor (Angermann, 2013a, 2013b). In diesem werden allgemeine Fragen zu den Herstellern und der aktuellen Version, Anbindung und Erweiterung, Sicherheit, Marketing und Kundenbindung sowie die Benutzerfreundlichkeit (Usability) für den Redakteur abgefragt. Die in Abschnitt 1.1 genannten Ziele resultieren somit aus im Kontext der Untersuchung darüber hin‐ aus ergebender Fragestellungen der drei genannten Studienergebnisse. Forschungsbegleitend wird sich befasst, welche Möglichkeiten ein in „SharePoint 2013“ angelegtes PIM‐System für eine Publika‐ tion der Produktinformationen in einem Web‐Shop‐System bietet. Tab. 1‐1: Primär verwendete Peripherie Funktion Verwendete Anwendung (Erscheinungsjahr) Content Management Microsoft SharePoint Server 2013 Enterprise (2013), fortlaufend als PIM‐System genutzt SharePoint‐Editor Microsoft Office SharePoint 2013 Designer (2013) Betriebssystem Microsoft Windows Server 2012 R2 (2012) Datenbankmanagement Microsoft SQL Server 2012 (2012) Betriebssystem‐Shell Microsoft Windows PowerShell 4.0 (2013) Tabellenkalkulation Microsoft Office Excel 2013 (2013) Web‐Browser Microsoft Internet Explorer 10 (2012) Web‐Entwicklung Microsoft ASP.NET Web Matrix 3 (2013) XML‐Editor Syncro Soft oXygen XML‐Editor 14.1 (2012) Erstellung Formulare Microsoft InfoPath 2013 (2013) 2 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien 2. Wechselbeziehungen zwischen Ein‐ und Ausgabemedien 2.1. Motivation und Einführung Information Management (IM) bzw. Product Information Management (PIM) ist nach „Gartner“ und der „Association for Information and Image Management“ (AIIM) eine Technologie, welche der Samm‐ lung, Aufbereitung und Zusammenfassung von Informationen über Produkte aus einer (Single Source) oder mehrerer (Multiple Source) Quellen dient. Erhaltene Investitionen werden darauf beruhend an eine breite Leserschaft (z. B. Redakteure), über mehrere Publikationskanäle hinweg, veröffentlicht. (“About AIIM,” n. a., “Gartner IT Glossary ‐ PIMS (production information management system),” n.d.) 2.1.1. Einführung in Systeme für die Produktdatenverwaltung PIM‐Systeme etablieren sich im Markt und spielen beim Multi‐Channel‐Publishing (Multikanal‐Publi‐ kation) in Unternehmen eine zentrale Rolle. Bei der Verwendung eines PIM‐Systems ergeben sich vier wesentliche Vorteile für die Unternehmung (Gäbeler, 2013, p. 13): Eine zentrale Datenhaltung als Depot aus den referenzierenden Informationsquellen, Zusatz an relevanter Informationen zu den zu verwaltenden Produkten, medienneutrale Datenhaltung über verschiedenste Formate hinweg, übergreifende Rollen‐ und Rechteverwaltung für Redakteure und Administratoren. In einem PIM‐System werden verschiedene Managementsysteme konsolidiert (Gäbeler, 2013). Die Ausprägungen in den verschiedensten Bereichen des Systems, innerhalb des durch die AIIM beschlos‐ senen ganzheitlichen ECM‐Systems (vgl. Abb. 2‐2), müssen für jeden Hersteller individuell betrachtet werden (vgl. Abschnitt 3.2.1 bis 3.2.10). 3 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien Abb. 2‐1: PIM‐Komponenten der ECM‐Elemente (AIIM) Die zu erfassenden Inhalte (Capture) können neben elektronischen Informationen auch in physischer Form, sowie weiter unterteilt in den unterschiedlichsten Kapazitäten (Text, dynamische Medien, Ge‐ scanntes etc.), daneben in den verschiedensten (Datei‐)Formaten (JPEG, TXT, XLS, DOCX, PDF, etc.), aus strukturell‐ (SQL, XML, etc.) und/oder formell unterschiedlichen Quellen (Folksonomie, Taxono‐ mie), vorliegen. (“What is Information Management?,” n. a.) Angestrebt ist unter dem genannten Standpunkt stets, die Datenkonsistenz in dessen Umfang nicht zu verschmälern, jedoch in eine für die zentrale, medienneutrale Datenhaltung beträchtliche, einheitliche Formation zu transferieren. Be‐ gründend hierfür ist die Information in den unterschiedlichsten Kanälen publizieren zu wollen.‐ 2.1.2. Gegenwärtiger Standpunkt im E‐Commerce‐Handel Der Online‐Handel für Waren ist von 2011 bis 2012 um 27,2 % auf 27,6 Mrd. € gewachsen (Digital Services mit etwa 10 Mrd. € exklusive). Der Umsatz stationärer Einzelhändler schrumpfte im identi‐ schen Zeitraum um real über 5 %. (Heinemann, 2014) Der durchschnittliche Bestellwert (33 % Anteil) beim Online‐Kauf beträgt zwischen 101 € und 500 €. (Black, 2013) „Neun von zehn Internet‐Nutzern kaufen im Internet ein. 40 Prozent von Ihnen sogar regelmäßig, d. h. mehr als zehn Mal innerhalb eines Jahres. Zudem ist das Online‐Shopping in allen Altersgruppen weit verbreitet. “ (Budde et al., 2013) Der Verzicht von E‐Shops bei der Kundenakquise wird somit zur Wachstumsbremse für rein stationäre Händler, da die dominierende Anbietergruppe der Versender Internet‐, Katalog‐ und Filialverkauf pa‐ rallel nutzt, um Kundenpotenziale optimal auszuschöpfen. (Axel Springer AG ‐ Marktanalyse, 2011) Eine aktuelle Studie des Harvard‐Business‐Managers (Januar 2014; Schwerpunkt „Modernes Marke‐ ting“) besagt, dass Marken, deren Verkaufsstrategie primär durch Online‐Auftritte realisiert wird, zu 4 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien einer höheren Begegnungsfrequenz Marke‐Kunde führen. Grund hierfür und Vorteil gegenüber tradi‐ tionellen Vertriebskanälen (Zeitung, TV, etc.) ist die geringere Entfernung zum Kunden. Potentielle Kunden sind nur wenige Klicks von den Produkten entfernt. (Macdonald et al., 2014) Für den möglichen Kunden (Endverbraucher) und Händler ergeben sich folgende Vorteile: Personalisierung des Produktportfolios und damit gesteigerte Marketingfunktionen durch Steigerung des Einkaufserlebnisses mittels „bewusstem“ Einkauf, geringere Suchkosten für homogene Produkte durch einen schnellen aber breiten Informati‐ onszugang und damit effizientere Produktdifferenzierung und Preisvergleich, bessere Kontrolle anhand statistischer Auswertungen von u. a. Kaufabbrüchen und Ladenhü‐ tern. (Vulkan, 2005) Aber auch mögliche Nachteile müssen berücksichtigt werden, welche jedoch z. B. durch eine Integra‐ tion von PIM‐Systemen und Anbindung weiterer Systeme schrittweise behoben werden können: Unvollkommene Information durch z. B. fehlende oder falsch platzierte Medien, Unterschiedliche Zugangschancen zu neuen Medien („Digitale Divide“) durch unterschiedliche Bevölkerungsschichten (‐segmente), Altersgruppen und technischer Affinität, Unsicherheit der Käuferschaft im Hinblick auf Zahlungsabwicklung und Datenschutz, Nicht ausgereifte Technologien für die freiwillige Selbstkontrolle (FSK). (Breidenbach, 2007) 2.2. Steigende Datenmengen und crossmediale Nutzformen In einer Ausgabe des “Harvard Businessmanager” (November 2012; Schwerpunkt: Big Data) wird die Bedeutsamkeit des exponentiell steigenden Datenwachstums (Big Data) einfach und prägnant ausge‐ drückt: Unternehmen haben so die Möglichkeit, wesentlich mehr zu messen und über deren Geschäft zu erfahren. Daraus resultieren bessere Entscheidungen und parallel hierzu bessere Ergebnisse. Grund‐ lage für diese Erkenntnis ist die gestiegene Kundentransparenz bei digitalen Ausgabekanälen. (Mcafee and Brynjolfsson, 2012) 5 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien Abb. 2‐2: Exemplarische Big‐Data‐Interaktion 2.2.1. Aktuelle Herausforderungen im Multi‐Channel‐Vertrieb Der Begriff Multi‐Channel (Mehrkanal) versteht die Publikation von Inhalten über mehrere Kanalstruk‐ turen hinweg (Wirtz, 2007). Mögliche Offline‐ und Online‐Kanäle sind die Informationen zu drucken, im Web, über soziale Plattformen, mittels Smartphone oder Tablet‐PC zu publizieren und somit einem breiten Publikum zukommen zu lassen. Nach Heinemann (Heinemann, 2013) können No‐Line‐Systems (Barrierefreie Systeme) als höchste Evo‐ lutionsstufe des Multi‐Channel‐Handels bezeichnet werden. Wesentlich ist nicht auf die Harmonisie‐ rung von Off‐ und Online‐Kanälen und das damit verbundene Channel‐Hopping („Hüpfen“ zwischen Kanälen) zu bauen, sondern eine maximale Vernetzung und Integration zwischen allen Absatzkanälen anzustreben (vgl. Abb. 2‐3). Demzufolge definiert sich No‐Line‐Handel als ein Information‐ und Kauf‐ prozess ohne Medienbrüche, demnach eine nahtlose Verzahnung aller Kanäle zu einem einheitlichen Unternehmensauftritt. Dienstleistungen und Produkte werden aktuell über eine stets steigende An‐ zahl an Touchpoints (Berührungspunkte) vertrieben. Gangbare Berührpunkte sind Chats, gedruckte Dokumente, Web‐Shops, Filiale, Mobil, Tablet, am Telefon und am Fernseher. Mögliche Vernetzungs‐ ansätze sind zum Beispiel als Plakat dargestellte Artikel mit dem Smartphone zu fotografieren und diese erst beim Bezahlvorgang zu erhalten. (Macdonald et al., 2014) Der modernste Ansatz ist hierbei, jedem Kunden personalisierte Preise, anhand seiner zuvor getätigten Einkäufe und Präferenzen, zu gewähren. Diese Strategie und der damit verbundene Datenstrom nutzt dem Vertreiber, der dadurch in Erfahrung bringt, welche Kundengruppe, welche Produkte, wann kauft. Ferner dem Kunden, der dort kaufen wird, wo das Angebot in höchstem Maße für ihn individualisiert angeboten wird. Abb. 2‐3: Exemplarischer Vergleich crossmedialer Datenströme (No‐Line, Multi‐Channel) 6 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien 2.2.2. Bedeutende Methoden für die Suchoptimierung Sebastian Erlhofer beschreibt in seinem Buch „Suchmaschinenoptimierung – Das umfassende Hand‐ buch“ (Erlhofer, 2011) Onpage und Offpage als zwei wesentliche Verfahren bei der Suchmaschinenop‐ timierung (kurz SEO). Ziel von SEO ist es, die Internetpräsenz in den Suchmaschinen‐Ergebnissen mög‐ lichst weit oben zu platzieren. Onpage‐Optimierung ist eine Maßnahme, welche der Betreiber einer Web‐Präsenz intern (auf der Seite) durchführen kann. Eine wichtige Rolle beim Ranking spielt die Auszeichnung mittels Tags und optimierte Texte. (Erlhofer, 2011) Offpage‐Optimierung ist eine aufwendigere und externe (außerhalb der Seite) Methode. Es werden gute und wertig eingehende Links auf ein Angebot gesetzt. Der direkte Verweis auf die eigene Website ist Bedingung, um auf die vordersten Plätze im Suchmaschinen‐Ranking zu gelangen. (Erlhofer, 2011) 2.2.3. Technologien zur Auszeichnung von Daten Taxonomie ist ein Verfahren, um Objekte nach bestimmten Kriterien zu klassifizieren. Dies bedeutet demzufolge die Einordnung in bestimmte Klassen oder Kategorien. Diese verwalteten Metadaten wer‐ den beispielsweise in SP zentral von bestimmten Anwendern festgelegt. (Straub, 2010) Als Resultat entsteht z. B. eine nach Artikelgruppen gegliederte Navigation. Folksonomien, welche auch als Schlüsselworte/Schlagworte oder Social Tagging (Soziale Schlagwort‐ Auszeichnung) bezeichnet werden, verfügen hingegen nicht über ein vorgeschriebenes Formular. In SP beispielweise können Anwender selbst Schlagworte definieren und somit deren eigene Interpretation einbringen. (Straub, 2010) Als Resultat entsteht z. B. eine Schlagwortwolke (Tag Cloud). 2.3. Einführung in SharePoint Server 2013 und SmartStore.NET In diesem Abschnitt wird dem Leser ein kurzer Überblick über die Grundfunktionalität der beiden, in dieser Studie ausschlaggebend verwendeten, Technologien gegeben. Diese sind das ECM‐System „Microsoft SharePoint 2013“, vereinfacht betrachtet zur Verwaltung der Produktdaten in einem Pro‐ duktkatalog sowie das Web‐Shop‐System „SmartStore.NET“ als Vertriebskanal (vgl. Tab. 1‐1). 7 2 Wechselbeziehungen zwischen Ein- und Ausgabemedien 2.3.1. Wesentliche Neuerungen in SharePoint Server 2013 Im Oktober 2012 wurde das ECM‐System „Microsoft SharePoint Server 2013“ veröffentlicht. Wesent‐ liche Neuerungen sind u. a. die Verwendung von Apps, eine verbesserte Office‐Integration, Entwick‐ lung von Cloud‐Diensten mittels „SkyDrivePro“, Ausbau der sozialen Kompetenzen durch Blogs, Follo‐ wer‐ und Newsfeed‐Funktionen sowie das Site‐Collection‐Template Produktkatalog. Letztgenanntes agiert als Erweiterung der Veröffentlichungsfeatures im Standard‐Repertoire. (Larisch, 2013) Die Funk‐ tionalitäten des Produktkataloges werden in den Abschnitten 4.2, 5.3 und im Glossar näher beleuchtet. Microsoft SP beschreibt das ECM‐Verständnis anhand des SP‐Wheels, für die aktuelle Version (2013), in sechs Feldern (Catrinescu, 2013): Tab. 2‐1: Bestandteile des SharePoint‐Wheel (Version 2013) 2.3.2. Wheel‐Bestandteil Wichtigste Funktionen/Bestandteile Sites (Seiten) Webseiten für Teams, Projekte, Kalender Composites (Verbund) Verwaltung von Aufgaben, Nachrichten, Apps Insights (Einblick) Funktionen zum internen Wissensmanagement Communities (Gemeinschaft) Integration von Yammer, Blogs, MySite Content (Inhalt) Inhaltsverwaltung in SkyDrive Pro und Bibliotheken Search (Suche) Verschiedene Suchcentren inkl. FAST‐Search Vorstellung des E‐Commerce‐Systems SmartStore.NET Im Juni 2013 wurde die Open‐Source E‐Commerce‐Lösung „SmartStore.NET 1.2.0“ auf Microsofts O‐ pen‐Source‐Projekt Hosting Seite „Codeplex“ veröffentlicht. Die in Dortmund beheimatete „Smart Store AG“ entwickelt seit 1999 Standard‐Software im Bereich E‐Commerce. Ziel der Entwicklung sind einfache und kostengünstige out‐of‐the‐box (aus der Box) E‐Commerce‐Softwares für kleine‐ und mit‐ telständische Unternehmungen. Die aktuelle Version 1.2.0 enthält die aktuellsten Microsoft Techno‐ logien wie MVC 4, ASP.NET, Entity Framework 5, Twitter Bootstrap und LESS CSS. (Angermann, 2013b) 8 3 Marktrelevante E-Commerce-Systeme im Überblick 3. Marktrelevante E‐Commerce‐Systeme im Überblick 3.1. Einführung in die Marktstudie In zwei früheren Studien (Angermann, 2013a, 2013b) wurden die neun am Markt relevantesten Sys‐ teme (vgl. Abb. 3‐1) sowie das Web‐Shop‐System „SmartStore.NET“, welches im Prototyp der vorlie‐ genden Studie zum Einsatz kommt anhand Produktsteckbriefen untersucht. Analysiert wurden Funkti‐ onalitäten, die derzeit dem aktuell erreichten Entwicklungszustand entsprechen. Die Marktstudie eva‐ luiert daher primär herstellerneutral die Bereiche: Allgemeine Informationen (Hersteller, Version), Sys‐ tem und Performance (Anbindung, Erweiterung, Sicherheit) sowie Marketing und Redaktion (Betrei‐ ber, Kunde). Abb. 3‐1: Übersicht studienrelevanter Shop‐Systeme 9 3 Marktrelevante E-Commerce-Systeme im Überblick 3.2. Ergebnisse der Marktstudie 3.2.1. Intershop 3.2.1.1. Allgemeine Informationen Die „Intershop Communications AG“ wurde 1992 gegründet und ist mit derzeit 21 % Marktverteilung das dominierende Web‐Shop‐System. Die aktuelle Version „Intershop 7“ wurde mittels Java imple‐ mentiert und ist ein Kaufprodukt. (Angermann, 2013a) 3.2.1.2. Kernfunktionen im Überblick Bereits integriert sind Schnittstellen zu SAP, Navision und Preisvergleichsportalen. Mittels des „Multi‐ Touch‐Point‐Moduls“ können Produkte an vielen verschiedenen Berührungspunkten wie etwa soziale Plattformen vertrieben werden. Die Anzahl der Produkte ist unbegrenzt. Meta‐Tagging ermöglicht dem Kunden personalisierten Inhalt zu präsentieren. Für den Redakteur stehen 90 vordefinierte Temp‐ lates zur Verfügung. Die Inhaltspflege erfolgt mittels eigenem CMS inklusive Drag & Drop‐Funktionali‐ tät (Ziehen und Ablegen). (Angermann, 2013a) 3.2.2. Heiler und Demandware 3.2.2.1. Allgemeine Informationen Die „Demandware GmbH“ wurde 2004 gegründet und ist mit derzeit 4 % Marktanteil in Deutschland vertreten. Die aktuelle Version wurde mittels Java implementiert und ist ein Mietprodukt. Besonder‐ heit ist die Integration des PIM‐Systems „Informatica PIM“ („Heiler Software AG“). (Angermann, 2013a) 3.2.2.2. Kernfunktionen im Überblick Vorgesehen ist die Datenintegration von ERP‐Systemen, XML‐ und CSV‐Datenformaten sowie SAP‐An‐ wendungen. Es können Aktualisierungseinstellungen für Produkte, Kategorien und Kataloge festgelegt werden. Zentrale Datenhaltung erfolgt mittels „Informatica PIM“. Das Channel‐Management ermög‐ licht, welche Attribute oder Promotion‐Aktionen auf den verschiedenen Publikationskanälen veröf‐ fentlicht werden. Dynamische Produktanordnung geschieht für jeden Kunden individuell. Ein Web‐In‐ terface dient der Inline‐Produktpflege. Mittels „Web‐Bearbeitungs‐Suite“ kann der Web‐Designer HTML‐ und CSS‐Assets editieren. (Angermann, 2013a) 10 3 Marktrelevante E-Commerce-Systeme im Überblick 3.2.3. Hybris 3.2.3.1. Allgemeine Informationen Die „Hybris AG“ wurde 1997 gegründet und ist mit derzeit 6 % Marktverteilung in Deutschland vertre‐ ten. Die aktuelle Version „Hybris Commerce Suite“ wurde mittels Java implementiert und ist ein Kauf‐ produkt. (Angermann, 2013a) 3.2.3.2. Kernfunktionen im Überblick Eine geschlossene Integration mit SAP ist bereits implementiert. Das „Payment Module“ sorgt für die Eingliederung verschiedenster Online‐Zahlungsverfahren. Chross‐Channel (Kreuzung von Kanälen) und Mobile‐Commerce werden out‐of‐the‐box unterstützt. Das „Advanced Personalization Module“ sorgt für individuelle Produktempfehlungen. Das „Web Content Management Module“ gewährleistet eine Trennung von Layout und Inhalt, vordefinierte Templates und Multi‐Channel‐Unterstützung. (Anger‐ mann, 2013a) 3.2.4. Magento 3.2.4.1. Allgemeine Informationen Die Open‐Source „Community Edition“ von „Magento“ („ebay Inc.“) ist mit derzeit 2 % am Markt ver‐ treten und wurde 2001 gegründet. (Angermann, 2013a) 3.2.4.2. Kernfunktionen im Überblick CSV‐ Im‐/Export für Produkte und Kundendaten ist in der „Community Edition“ möglich. Erweiterte Schnittstellen sind nur mittels zusätzlicher Module bzw. in den Kaufprodukten realisierbar. Die Migra‐ tion verschiedener Shops (z. B. verschiedene Marken‐Shops) sowie volle Unterstützung im Bereich des Mobile‐Commerce sind bei allen „Magento“‐Produkten enthalten. Up‐ und Cross‐Selling (Verkauf kos‐ tenintensiverer und ergänzender Produkte) Möglichkeiten werden anhand von Metainformationen zu den Produkten realisiert. Es können Designvorlagen kostenfrei und legal auf „Magento‐Connect“ be‐ zogen werden. (Angermann, 2013a) 11 3 Marktrelevante E-Commerce-Systeme im Überblick 3.2.5. Commerce Server 3.2.5.1. Allgemeine Informationen Das Kaufprodukt „Commerce Server 10.1“ des Softwareherstellers „Ascentium Corporation“ wurde ursprünglich von der „Microsoft Corporation“ vertrieben, welche diesen ab 2000 im „.NET‐Frame‐ work“ entwickelte. (Angermann, 2013a) 3.2.5.2. Kernfunktionen im Überblick Da es sich um ein ehemaliges Microsoft‐Produkt handelt, kann die Anbindung an SP und „Microsoft Dynamics CRM“ nahtlos erfolgen. Im „Multi‐Channel‐Framework“ werden Multi‐Shop und Multi‐Chan‐ nel inkl. Mobile‐Commerce unterstützt. Die Funktion „Targeted Merchandising“ ermöglicht die Darstel‐ lung von personalisierten Inhalten. Die Benutzerfreundlichkeit ist, durch eine vertraute Benutzerober‐ fläche, welche dem Microsoft Windows Desktop‐Aussehen und Metapher entspricht, als sehr hoch einzustufen. (Angermann, 2013a) 3.2.6. Strato 3.2.6.1. Allgemeine Informationen Das Mietprodukt „Webshop Basic“ der „Strato AG“, welche 1997 gegründet wurde ist mit derzeit 13 % Marktverteilung, das nach „Intershop“ am zweitstärksten genutzte E‐Commerce‐System in Deutschland. (Angermann, 2013a) 3.2.6.2. Kernfunktionen im Überblick Die Basisversion bietet keinerlei Schnittstellen zu Preisportalen, ERP‐, CRM‐ oder PIM‐Systemen. Auch Möglichkeiten für multimediales Publizieren sowie der Aufbau eines Multishops sind nicht möglich. Als ebenso kritisch sind die nur einstellbaren 100 Produkte zu betrachten. Kunden können in Gruppen, die Produkte in zehn Produkttypen eingeteilt werden. Da keine Schlagwort‐Auszeichnung vorgesehen ist kann keine Personalisierung für Kundeninhalte stattfinden. Mittels Drag & Drop und WYSIWYG‐Editor wird eine einfache Pflege der Inhalte ermöglicht. Es werden vordefinierte Templates angeboten, die allerdings nur geringfügige Individualität bei der Gestaltung zulassen. (Angermann, 2013a) 12 3 Marktrelevante E-Commerce-Systeme im Überblick 3.2.7. Xt:Commerce 3.2.7.1. Allgemeine Informationen Die Open‐Source „xt:Commerce Start!“‐Version der „xt:Commerce GmbH“ ist mit derzeit 1 % am Markt vertreten und wurde 2003 gegründet. Die Technologie kann, im Gegensatz zu den meisten anderen hier aufgeführten Technologien, nur über ein Linux‐Betriebssystem betrieben werden. (Angermann, 2013a) 3.2.7.2. Kernfunktionen im Überblick Anbindungen an ERP‐, CRM‐ oder PIM‐Systeme sowie Multi‐Shopping wird nicht unterstützt, können jedoch gegen Aufpreis realisiert werden. Dem Personalisierungsgrad sind durch Metatags und die Pflege verschiedenster Kundengruppen keine Grenzen gesetzt. Drag & Drop ist für die Inhaltspflege nicht vorgesehen. Die Gestaltungsvorlagen sind editierbar, jedoch werden für die Bearbeitung zwin‐ gend CSS‐Kenntnisse benötigt. Im System ist ein HTML‐Editor integriert. (Angermann, 2013a) 3.2.8. Omeco 3.2.8.1. Allgemeine Informationen Die „Omeco GmbH“ wurde 1998 gegründet und ist mit derzeit 1 % Marktanteil in Deutschland vertre‐ ten. Die aktuelle Version „Shopware 4 Enterprise Basic“ wurde mittels PHP implementiert und ist ein Kaufprodukt. (Angermann, 2013a) 3.2.8.2. Kernfunktionen im Überblick Bereits installiert sind die Anbindungen an Warenwirtschaftssysteme und Preisportale. Ebenso attrak‐ tiv ist die Fähigkeit, aus bestehenden Web‐Shop‐Systemen (z. B. „Strato“, „Magento“), Inhalte impor‐ tieren zu können. Personalisierte Inhalte werden durch die Migration verschiedener Kundengruppen erreicht. Bei der Installation sind zehn verschiedene Designvorlagen enthalten. Diese können individu‐ ell durch Stylesheets angepasst werden. (Angermann, 2013a) 3.2.9. WebSale 3.2.9.1. Allgemeine Informationen Die „WebSale AG“ wurde 1996 gegründet und ist mit derzeit 1 % Marktverteilung in Deutschland ver‐ treten. Die aktuelle Version „WebSale Suite“ ist ein Kaufprodukt. (Angermann, 2013a) 13 3 Marktrelevante E-Commerce-Systeme im Überblick 3.2.9.2. Kernfunktionen im Überblick Nur optional vorgesehen ist die Anbindung an ERP‐, CRM‐ und PIM‐Systeme. Im Bereich Multi‐Channel ist lediglich Mobile‐Commerce vorgesehen. Tagging ist optional möglich. Eine interne Bearbeitungs‐ möglichkeit von Bildern wird, wie ein integrierter HTML‐Editor, merklich vermisst. (Angermann, 2013a) 3.2.10. SmartStore.NET 3.2.10.1. Allgemeine Informationen Die „SmartStore AG“ wurde 1999 gegründet und bietet derzeit ihre aktuellste Web‐Shop‐Version „SmartStore.NET 1.2.0“ an. Diese ist als Open‐Source‐Produkt frei erhältlich, unterstützt als Betriebs‐ system jedoch nur den „Microsoft Windows Server 2008“ (oder höher). (Angermann, 2013b) 3.2.10.2. Kernfunktionen im Überblick Bei Installation kann zwischen einer eingebetteten Datenbank, „Microsoft SQL Server Compact“, oder einer externen SQL‐Datenbank gewählt werden. Es wird keine Standard‐Schnittstelle zu CRM‐, ERP‐ und PIM‐Systemen angeboten, da das Web‐Shop‐System selbst über eigene CRM‐ und CMS‐Funktio‐ nalitäten verfügt. Multi‐Shop und Multi‐Channel (ausgenommen Mobile‐Commerce) sowie die Anbin‐ dung an soziale Plattformen sind nicht möglich. Taxonomie‐ und Folksonomie‐Funktionalitäten wer‐ den ausreichend unterstützt. In Punkto Design steht nur die Standard‐Vorlage zur Auswahl. Die kom‐ plette Inhaltspflege kann mittels Browseroberfläche vorgenommen werden. (Angermann, 2013b) 14 4 Ausgangssituation und bekannte Probleme 4. Ausgangssituation und bekannte Probleme 4.1. Analyse der PIM‐Ansätze In einer vorangegangen Studie (Gäbeler, 2013) wurde die Möglichkeit untersucht, SP als PIM‐System zu nutzen. Betrachtet wurden vier Szenarien. Es standen hierbei XML und CSV als Importdaten zur Auswahl. Gäbeler beleuchtete, dass mittels des Site‐Collection‐Templates „Produktkatalog“ die meis‐ ten wesentlichen Funktionalitäten mit geringstem Aufwand gegeben sind. Der Produktkatalog kann somit als Best‐Practice‐Szenario betrachtet werden und wird deshalb als Grundlage für die Anbindung an ein E‐Commerce‐System gewählt. Aus erläutertem Anlass werden deshalb die drei divergenten An‐ sätze nur kurz im Kapitel 4.1.1 bis 4.1.3 erläutert, der Ansatz „Produktkatalog“ im Abschnitt 4.2 hinge‐ gen ausführlicher. Alle untersuchten Szenarien verwendeten das BMEcat‐Format als Importgrundlage. 4.1.1. XSL‐Transformation (XML‐Input) An dieser Stelle wurde untersucht, das zur Verfügung stehende XML‐File mittels einer XSL‐Transfor‐ mation (XSLT) in das SP‐Frontend, unter Verwendung des „XML‐Viewer‐Webparts“, zu transferieren. Mittels genannten Webparts ist die Anzeigefunktion ohne Einschränkungen möglich. Probleme hinge‐ gen waren neben der nötigen XSL‐Transformation die damit verbundenen erweiterten Rechte, auf dem Server, für den Redakteur. DTD‐Dateien werden nicht unterstützt. 4.1.2. Spread‐Sheet‐Import (CSV‐Input) Hierbei wurde der in SP verfügbare Datenimport von „Excel“‐Datenblättern untersucht. Besonderes Feature, der out‐of‐the‐box Technologie, ist die Möglichkeit, nur ausgewählte Produkte importieren zu können. Auffällig ist die fehlende Flexibilität der CSV‐Struktur, wodurch manuelle Anpassungen nötig sind. Analog der XSLT sind erweiterte Rechte nötig. Das gravierendste Defizit stellt die Importfähigkeit von nur sieben Unterelementen für den „Term‐Store“ dar. Insgesamt werden nach der XSL‐Transfor‐ mation drei CSV‐Dateien benötigt. Jeweils eine Datei für die Metainformation, die Struktur und tat‐ sächlichen Produkte. 15 4 Ausgangssituation und bekannte Probleme 4.1.3. Data‐Connection (XML‐Input) Die XML‐Datei wird als sogenannte neue „Datenverbindung“, mittels „„SP‐Designer““, eingebunden. Die Visualisierung außerhalb einer Liste ist nur mittels HTML‐Formular möglich. Eine Export‐Schnitt‐ stelle für Bilder wird nicht unterstützt, diese müssen, wie auch bei den anderen Ansätzen manuell heruntergeladen werden. Dieser Ansatz bietet die meiste Konsistenz, in Bezug auf Datenerhalt. Hinge‐ gen den zuvor genannten Varianten findet die Pflege direkt im XML statt. Dies bedeutet, dass die Daten nicht redundant gepflegt werden. 4.2. Untersuchung des bestehenden Produktkataloges Nachfolgend erhält der Leser einen Überblick über die Funktionen, Probleme und Handbarkeit des in einer vorangegangenen Studie implementierten Produktkataloges. 4.2.1. Produktmigration und Suche Der Produktkatalog ist in Funktion der konventionellen SP‐Listen editierbar. Es können unterschied‐ lichste Ansichten erstellt werden, die ein rasches Bearbeiten der Elemente („Data‐Sheet‐View“) oder den Aufruf eines Formulars („Standard‐View“) ermöglichen. Die Produktpflege entspricht daher den aktuellen PIM‐Standards. Die Fehlertoleranz ist mäßig ausgeprägt. Wortsilben werden nicht gefunden. 4.2.2. Veränderung der Datenkonsistenz Für den Import der Produkte stand ursprünglich ein XML‐File (BMEcat) zur Verfügung, welches dessen Information in Header und Katalog gliedert (vgl. Abb. 4‐1). Bei Übernahme in den Produktkatalog ge‐ hen die Daten des Headers vollständig verloren, könnten jedoch in einer separaten Liste gepflegt wer‐ den. Elemente des eigentlichen XML‐Kataloges werden weniger strukturiert in den SP‐Katalog transfe‐ riert (vgl. Abb. 4‐1). Der nun importierte Katalog enthält zwei Ebenen, Kategorie und Inhalte. 16 4 Ausgangssituation und bekannte Probleme Abb. 4‐1: Verluste von Strukturen bei Produktkatalog‐Import 4.2.3. Exportmöglichkeiten des Kataloges Der Inhalt des Produktkataloges lässt sich nach „Excel“ exportieren. Die Struktur des „Term‐Stores“ wird jedoch auf eine Ebene und aufgrund der fehlenden Datentyp‐Unterstützung als String reduziert. Demzufolge bedeutet dies, dass Taxonomie‐Strukturen nicht konsistent bleiben. Selbiges trifft auch für hinterlegte Bildinformationen zu. Beim Export kann die Auswahl zwischen HTML‐Image‐Tag oder SP‐Link getroffen werden. Die Images können, z. B für eine Druckpublikation nicht platziert werden (z. B. „InBetween“ Layoutgenerator). Alle textlichen und nummerischen Inhalte bleiben konsistent. 4.3. Übergreifend bekannte Probleme Als primär fehlerhaft stellt sich heraus, dass die Publishingsite nicht über einen anonymen Zugriff ver‐ fügt. Des Weiteren sind auch nicht genehmigte Artikel, d. h. Produkte die den Approval‐Workflow (Ge‐ nehmigungs‐Ablauf) noch nicht positiv bestanden haben, veröffentlicht. 17 4 Ausgangssituation und bekannte Probleme Mögliche Erweiterungsschritte sind in den Bereichen Suchoptimierung, Schnittstellen und Mehrspra‐ chigkeit zu erwähnen. An dieser Stelle hätten die Funktionen multilingualer „Term‐Stores“ oder die Verwendung von „Language‐Tags“ näher beleuchtet werden können. Die Produkte werden manuell oder gefiltert selektiert. Verschiedene Preise für unterschiedliche Aus‐ gabemedien (z. B. Druckkatalog) wurden nicht bedacht. Differente Preiswerte hätten beispielsweise durch die Migration erweiternder Spalten realisiert werden können. Für nicht alle Produkte sind Bilder hinterlegt. Die Daten sind somit als unvollständig zu betrachten. 18 5 Konzeptmodell für die Entwicklung der System-Interaktion 5. Konzeptmodell für die Entwicklung der System‐Interaktion 5.1. Bestandteile des Rahmenkonzeptes Das in der vorliegenden Studie verfasste Rahmenkonzept befasst sich primär mit der beidseitigen In‐ teraktion von Shop‐ und PIM‐System. Genauer bedeutet dies den Austausch von mehr oder minder strukturierten Daten. Hierfür werden Berechtigungsmodelle genannt, Anwendungsfälle aufgezeigt und erläutert sowie Workflows die im Rahmen von Inhaltsgenehmigung und Hinweisgewinnung hilf‐ reich sind beschrieben. Zur Verfügung stehende Technologien werden erläutert und hinsichtlich der Anwendungsfälle analysiert. a) Berechtigung: Akteure verfügen über verschiedene Rechtezuordnungen, die durch den An‐ wender selbst jedoch nicht änderbar sind. Diese legen fest, welche Operationen dieser anle‐ gen, bearbeiten und lesen darf. b) Datenaustausch: Durch die Vernetzung der beiden Systeme können einmal erfasste Daten ge‐ meinsam genutzt bzw. mehrfach verwendet werden. Für den Datenaustausch kommen u. a. Produktbeschreibungen, Informationsauszeichnungen (Folksonomie, Taxonomie), Analyseda‐ ten für Marketing‐ und Produktionsprozesse sowie Referenzprodukte in Betracht. c) Workflows: Definierte Arbeitsabläufe können im Rahmen des Datentransfers beispielsweise bei Genehmigungsprozessen eingesetzt werden, welche die finale Publikation nach einer Kon‐ trolle durch den Vorgesetzten auslösen. d) Technologien für die Interaktion: Ein halbautomatisierter Datenaustausch kann mittels Zwi‐ schenablagen sowie Import‐ und Exportfiltern realisiert werden. Vollautomatisierung ist bei‐ spielsweise mittels Datenbankanbindung möglich. 5.2. Akteure und Anwendungsfälle im Web‐Shop‐Umfeld Eine Anwendergruppe (User‐Group) zeichnet sich dadurch aus, dass deren Akteure die gleichen Inte‐ ressen innerhalb der Umgebung haben und dadurch i. d. R. das identische Software‐Produkt verwen‐ den. Die User‐Gruppen für die E‐Commerce‐Plattform, sind wie folgt gegliedert: 19 5 Konzeptmodell für die Entwicklung der System-Interaktion Tab. 5‐1: Übersicht der Akteure User‐Group Akteure (Mensch) Akteur (System) Hauptmerkmale Kunden Interessent Shop‐System Finden, Kaufen Produktdaten‐ management Neukunde Bewerten, Stammkunde Soziale Aktivitäten Produktdatenmanager Fremdabteilungen PIM‐System Abteilungsleiter Nachverfolgung, Designer Publizieren Marketingverantwortlicher PIM‐System Kampagnen, Analyse Bestellungen Produktionsverantwortlicher 5.2.1. Migration, Berechtigungsstufen in SharePoint 2013 und SmartStore.NET SP‐Benutzergruppen ermöglichen dem Betreiber der Anwendung, unterschiedliche Benutzerberechti‐ gungen auf Seiten‐, Listen‐ und Elementebene zu vergeben. (Büttner et al., 2013) Die Zugriffsrechte für Kunden erfolgen automatisiert in der Shop‐Umgebung. Für die ernannten SP‐Akteure (vgl. Tab. 5‐ 1) kommen folgende Berechtigungsstufen auf Listenebene in Frage (vgl. Tab. 5‐2): Tab. 5‐2: Berechtigungskonzept für die Akteure Akteure (Mensch) Berechtigungs‐ stufe System Beschreibung Kenntnisse Administrator Vollzugriff SP Verfügt über Vollzugriff Experte Produktdatenmanager Entwerfen SP Kann anzeigen, hinzufügen, ak‐ tualisieren, löschen, genehmi‐ gen und anpassen Fort‐ geschritten Abteilungsleiter Genehmigen SP Kann Seiten, Listenelemente und Dokumente bearbeiten und genehmigen Grundlagen Designer Mitwirken SP Grundlagen Marketingverantwortlicher Mitwirken SP Können Listenelemente und Do‐ kumente anzeigen, hinzufügen, aktualisieren und löschen Produktionsverantwortlicher Mitwirken SP Interessent Lesen Shop Kann Artikel betrachten n. v. B. Neukunde Lesen, Bestellen Shop Kann User‐Profil anlegen n. v. B. Stammkunde Bestellen, Einträge Shop Kann sich einloggen n. v. B. 5.2.2. Grundlagen Grundlagen User‐Stories und Best‐Practice der Akteure User‐Stories sind in Alltagssprache formulierte Anforderungen an das zu entwickelnde Softwaresys‐ tem. Diese werden zu Beginn eines Softwareprojekts definiert (Wirdemann, 2009). 20 5 Konzeptmodell für die Entwicklung der System-Interaktion a) Kunde wählt Produkte: „Als Kunde möchte ich Produkte finden. Hierfür möchte ich ein erwei‐ tertes Suchcenter für eine bessere Sucherfahrung nutzen können.“ b) Kunde bestellt Produkte: „Als Kunde möchte ich Produkte bestellen. Parallel möchte ich meine Stammdaten hinterlegen. Als Benutzerverwaltungssystem möchte ich die hinterlegten Stammdaten erhalten, um diese für weitere Umgebungen nutzen zu können.“ c) Kunde bewertet Produkte: „Als Kunde möchte ich Produkte bewerten, um meine Erfahrung über Artikel zu teilen. Dafür möchte ich mich anhand meines Profils einloggen können. Als PIM‐System möchte ich die Bewertungen analysieren können.“ d) Kunde generiert Foren‐ und Blogeinträge: „Als Kunde möchte ich Foren‐/Blogeinträge gene‐ rieren, um meine Erfahrung zum Dienstleister auch mit anderen Kunden zu diskutieren. Hierfür möchte ich mich anhand meines Profils einloggen. Als PIM‐System möchte ich das gewonnene Feedback erhalten.“ e) Produktdatenmanager migriert Produkte: „Als Produktdatenmanager möchte ich Informati‐ onen migrieren, um diese für den Kunden sichtbar zu machen. Für die Migration möchte ich Technologien zur Verwaltung von Taxonomie und Folksonomie anwenden, um meine Pro‐ dukte rekursiv verwalten zu können.“ f) Abteilungsleiter genehmigt Produktdaten: „Als Abteilungsleiter möchte ich durch den Pro‐ duktdatenmanager getätigte Informationsinhalte genehmigen. Den Prozess möchte ich mit‐ tels Workflow mit verschiedenen Status abhandeln, um ggf. Änderungsbedarf zu erläutern.“ g) Designer editiert das Web‐Design: „Als Designer möchte ich das Theme (Leitmotiv) anhand verschiedener Variablen pflegen. Ich möchte keine CSS‐Kenntnisse anwenden müssen.“ h) Marketingverantwortlicher reagiert auf Produktbewertungen: „Als Marketingverantwortli‐ cher möchte ich schlechte Bewertungen auslesen können, um ggf. Änderungsszenarien anzu‐ stoßen. Der Hinweis an mich sollte intuitiv und automatisiert erfolgen.“ i) Marketingverantwortlicher steigert Absatzchancen: „Als Marketingverantwortlicher möchte ich Kampagnen, wie etwa Discounts, welche über verschiedenste Variablen verfügen, pflegen können. Diese möchte ich auswerten, um die Kundenakzeptanz zu analysieren.“ j) Produktionsverantwortlicher versendet Bestellungen: „Als Produktionsverantwortlicher möchte ich die Stückzahlen und Bestellungen verwalten, um auf Bestandsengpässe umgehend reagieren zu können. Ebenso möchte ich den Bestellstatus pflegen können. 21 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.2.3. Use Cases inner‐ und außerhalb der E‐Commerce‐Plattform Ein Anwendungsfall beschreibt das Verhalten eines Systems unter verschiedenen Bedingungen, wäh‐ rend es auf den Primärakteur, welcher eine Interaktion auslöst, reagiert. Durch unterschiedliche An‐ fragen und Bedingungen können sich verschiedene Abläufe entfalten. Ein Use Case (Anwendungsfall) fasst all diese vielfältigen Szenarien zusammen. Ergebnis ist ein Erfolg, Fehlschlag oder Abbruch. Für die Shop‐PIM‐Interaktion ergeben sich die in Tab. 5‐3 gezeigten Anwendungsfälle für die verschie‐ denen Benutzergruppen, welche anhand von UC‐Diagrammen modelliert sind (vgl. Abb. 5‐1 bis 5‐3). Tab. 5‐3: Übersicht der Anwendungsfälle Bezug zu Bereich Use Case ID Use Case Name Untergeordneter Use Case Kundenverwaltung UC 01 Produkte finden Nein UC 02 Produkte bestellen Nein UC 03 Produkte bewerten Nein UC 04 Weitere soziale Aktivitäten Nein UC 05 Produkte verwalten UC 05.1 Produktdaten verwalten Produktverwaltung UC 05.2 Produktstruktur verwalten UC 06 Produktdaten genehmigen Nein UC 07 Design verwalten Nein Nichtredaktionelle UC 08 Artikelspezifische Änderun‐ Nein Ereignisse UC 09 Kampagnen steuern UC 09.1 Discounts realisieren UC 09.2 Discounts auswerten UC 10 Lieferung verwalten UC 10.1 Lager verwalten UC 10.2 Bestellung verwalten Abb. 5‐1: Anwendungsfälle für die Benutzergruppe "Kunden" (UC 01 bis 04) 22 5 Konzeptmodell für die Entwicklung der System-Interaktion Abb. 5‐2: Anwendungsfälle für die Benutzergruppe "Produktdatenmanagement" (UC 05 bis 07) Abb. 5‐3: Anwendungsfälle für die Benutzergruppe "Nichtredaktionelle Abteilungen" (UC 08 bis 10) 5.2.3.1. Entwicklung einer Use‐Case‐Schablone für die Detailbetrachtung Einzelne Use Cases lassen sich anhand einer Use Case‐Schablone (Entwurfsraster) definieren und hin‐ sichtlich Vollständigkeit prüfen. Die Use Case‐Schablone (vgl. Tab. 5‐4) entspricht in Anlehnung der Definition nach Alistair Cockburn (Cockburn, 2003). Einzelne Charaktere („NEU“) wurden ergänzt. 23 5 Konzeptmodell für die Entwicklung der System-Interaktion Tab. 5‐4: Bestandteile der Use Case‐Schablone Charaktere Studie Nach Cockburn Bedeutung Name Use Case‐Titel Name des Anwendungsfalldiagramms Beschreibung NEU Kurze Beschreibung über Use Case Primäre Akteure Primärakteur Mittelbar beteiligte Menschen/ Systeme Beteiligte Akteure Stakeholder Unmittelbar beteiligte Menschen/Systeme Verwendete UC‘s NEU Verweis auf andere Anwendungsfälle Auslöser NEU Fachlicher Grund den UC anzustoßen Vorbedingung Vorbedingung Alle Bedingungen um UC auszuführen Ergebnis Nachbedingungen Zustand nach erfolgreichem Durchlauf Standardablauf Schritte im Szenario An seinem Ende steht Zielerreichung des Primärakteurs. Ablaufschritte werden nummeriert und in strukturierter Sprache beschrieben Alternative Ablaufschritte Schritte im Szenario Ereignete Szenarien außerhalb der Zielerreichung des UC; Ende ist Misserfolg, Zielerreichung oder Rückkehr zum Standardablauf Hinweise NEU Kurze Erklärungen zum besseren Verständnis Weitere Systeme NEU Mögliche Anbindung an MIS, ERP, CRM (vgl. Abschnitt 7) Status Status Hinweis über den Fertigstellungsgrad 5.2.3.2. Definierte Use Cases und deren Abläufe Aktionen, genauer deren Standard‐ und alternative Abläufe (vgl. Tab. 5‐4) können mittels UML Aktivi‐ tätsdiagrammen beschrieben werden. Diese dienen zum Beschreiben von aller Art Abläufen, sehr aus‐ drucksmächtig und universell einsetzbar. (Störrlse, 2005) Beispielhaft für die geschilderte Möglichkeit, wird Use Case 01 dargestellt (vgl. Abb. 5‐4). Für die hier vorliegende Studie wurde die Beschreibung mittels Use Case‐Schablonen gewählt. Die rest‐ lichen Aktivitäts‐Szenarien können rein der Beschreibung des Standardablaufes bzw. alternativer Ab‐ laufschritte entnommen werden. Parallel‐Aktivitäten, Verzweigungen und Gabelungen sind im Raster berücksichtigt (Legende in Anhang C). (vgl. Anhang C UC 01 bis 14). UML‐Diagramme lassen sich ferner in Struktur‐ und Verhaltensdiagramme unterteilen (Kecher, 2006). Ein Ausblick zu weiteren Verhaltensdiagrammen welche im Rahmen der UML‐Notation gültig sind fin‐ det sich, inklusive Hierarchie und Beschreibung, in Anhang G. 24 5 Konzeptmodell für die Entwicklung der System-Interaktion Abb. 5‐4: Aktivitätsdiagramm für den Anwendungsfall "Produkte finden" (UC 01) 5.3. Unterteilung der Integrations‐Komponenten Für die Interaktion zwischen Informationsverwaltungssystem (PIM) und Ausgabekanal (E‐Shop) sind drei wesentliche Thematiken von Bedeutung: Kundenverwaltung, Produktverwaltung und nichtredak‐ tionelle Ereignisse. Durch die Spiegelung der drei wesentlichen Komponenten in die PIM‐Umgebung, dient der Shop lediglich als Web‐Oberfläche (Frontend) für den Kunden. Es müssen keine Aktivitäten durch den Betreiber im Shop‐Backend ausgeführt werden. Kundenverwaltung: Die gewonnenen Kundendaten (Stammdaten) sollen in ein Benutzer‐Ver‐ waltungstool transferiert werden (z. B. Active Directory). Die gewonnenen Stammdaten sollen parallel in die PIM‐Umgebung gespiegelt werden, da auf diese bei Bestellaktionen und die da‐ rin enthaltene Lieferinformation zurückgegriffen werden muss. Produkt‐ und Designverwaltung: Die Produkte werden allein innerhalb des PIM‐Systems ver‐ waltet. Einzelne Artikel, Waren‐ und Kundengruppen werden durch Taxonomien und Folkso‐ nomien ausgezeichnet. Die Editierung des Designs soll im PIM‐System stattfinden. Hierfür wird ein integrierter Editor inklusive einer Vorschaufunktion benötigt. Dem Web‐Designer soll es möglich sein, alle Änderungen ohne CSS‐Kenntnisse vornehmen zu können. Nichtredaktionelle Ereignisse: Dem Marketing soll es ermöglicht werden auf erhaltene Pro‐ duktbewertungen, Blog‐ und Foreneinträge zu reagieren. Die Produktion erhält bei Kundenbe‐ stellung den nötigen Impuls, inkl. der IDs der bestellten Produkte und Kundenadresse. 25 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.3.1. Anforderung an die Technologie Primär zeichnet sich die Güte der Technologie im Kontext der Wechselbeziehung zwischen PIM‐ und Shop‐System durch eine möglichst hohe Anzahl zu verwaltender Shop‐Attribute (Produktdetails, Ver‐ waltung von Taxonomie und Folksonomie) aus. Somit ist qualitätsentscheidend, welche Daten für die Rückkopplung in das PIM‐System konsistent bleiben. Weiterhin, welche Informationen im Shop, durch die Verwaltung jener im PIM‐System, fortbestehen. 5.3.2. Entwicklung von Güte‐Parametern zur Technologie‐Auswahl Die Parameter um die Güte von Technologien für die Integrationsfähigkeit festlegen zu können sind: Datenkonsistenz Produktmanagement: Meint Details des Produktes, z. B. Text, Zuordnung zu Warengruppen, Integration von erhaltenen Produktbewertungen, erhalten zu können. Datenkonsistenz Kundenaktion: Erörtert Details über die Kundengeschehnisse, wie etwa so‐ ziale Aktivitäten, Gewinnung von Kundenstammdaten und Ablage im Benutzerverwaltungs‐ dienst (z. B. AD), Analyse negativer Sucherfahrungen und erweitere Suchmöglichkeiten. Bedarf Shop‐Backend Barriere: Bedeutet den möglichen, nicht gewollten Bedarf, das Shop‐ Backend (Administrationsbereich) für die Bereiche: Design‐, Kunden‐, Bestell‐ und Marketing‐ verwaltung betreten zu müssen. Zeitbedarf verschiedener Funktionen: Meint die Unterschiede hinsichtlich benötigter quanti‐ tativer Zeitintervalle für die Migration neuer Produkte inkl. Auszeichnungsmethoden. Anbindungsfähigkeit an Drittsysteme: Bedeutet die qualitative Bewertung der möglichen An‐ bindung innerhalb der PIM‐Umgebung an Dritt‐Systeme (z. B. ERP‐System für die Lagerverwal‐ tung, Printkatalog zum Erstellen physischer Druckapplikationen). Ferner wird der Automatisie‐ rungsgrad für die Interaktion zwischen Zweit‐ und Drittsystem qualitativ bewertet. Verwaltungsfähigkeit: Meint die Möglichkeit Workflows, Mail‐Benachrichtigungen (Alerts) weiteres Customizing (z. B. Migration neuer Spalten) in bestehenden Listen vorzunehmen. 5.3.3. Übersicht relevanter Technologien Für die Interaktion (PIM‐/Shop‐System) stehen drei Technologien zur Verfügung: Das neue Veröffent‐ lichungsfeature Produktkatalog, „Business Connectivity Service“ bei denen mittels „SP‐Designer“ ex‐ terne Inhaltstypen implementiert werden können sowie der „Business Data List Connector“, bei dem die Integration direkt in SP erfasst wird. 26 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.3.3.1. Website‐Sammlung Produktkatalog Diese SP, out‐of‐the‐box integrierte Site‐Collection (Webseit‐Sammlung) ist eine Neuerung im Rahmen der Veröffentlichungsfeatures des SP Servers 2013. (Büttemeier, n. a.) Diese verfügt über Inhaltstypen die bei einer Katalogverwaltung benötigt werden, „Product with Image“ (Produkt mit Bild) oder „Pro‐ duct“. Durch diese Inhaltstypen können Spalten in die Katalog‐Liste eingebracht werden, z. B. „Mana‐ ged Metadata“ (Verwaltete Metadaten), welches die Taxonomie‐Verwaltung des „Term‐Store“ be‐ rücksichtigt oder „Rollup Image“ (Vorschaubild), welches Medien aus Bildbibliotheken („Asset‐“ oder „Picture‐Library“) innerhalb der Produktliste visualisiert. Durch die Einbindung des „Term‐Stores“ in die Katalogelemente kann die Katalogstruktur als Metadaten‐Navigation genutzt werden. 5.3.3.2. Business Connectivity Services (BCS) Mittels des BCS können Inhalte externer Datenquellen (z. B. SQL‐Tabelleninhalte) in externe Listen o‐ der aber auch in konventionelle Listen als externe Inhaltstypen eingebunden werden. (Larisch, 2013) Für die Implementierung ist es erforderlich den externen Inhaltstyp anhand Server, Datenbankname und die zu interagierenden Tabellen im „SP‐Designer“ zu verifizieren. Letztgenannte können anhand vordefinierter Aktionen, z. B. „Lesen“, hinsichtlich Bearbeitungs‐ und Berechtigungsstufe spezifiziert werden. Die BCS‐Verbindung wird nach erfolgreicher Implementierung im „SP‐Designer“ in der Zent‐ raladministration angezeigt und kann dort in Bezug auf berechtigte User modifiziert werden (vgl. An‐ hang H). 5.3.3.3. Business Data List Connector (BDLC) Mittels „BDCL“ (Hersteller: „Layer2 GmbH“ aus Hamburg) können bestehende SP‐Listen durch Auswahl einer der verschiedenen Datenbankschnittstellen (z. B. ODBC), Verbindungsstring und SQL‐Abfrage durch die Inhalte und Spalten aus externen Datenquellen ergänzt werden. Wesentlicher Vorteil ist die Berücksichtigung und Modifikationsmöglichkeit von Inhaltstypen, genauer deren Spalten sowie die Re‐ alisierbarkeit von Workflows, Rückschreibe‐ und Updatefunktionalität. SP‐Diskussionslisten und –Blog‐ listen werden nicht unterstützt. 5.3.4. Vergleich und Auswertung der Technologien Jene in Abschnitt 5.3.4 genannten Technologien sind nachfolgend anhand deren Qualifikation darge‐ stellt. Eine detailliertere Auflistung in Tabellenform befindet sich in Anhang E. 27 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.3.4.1. Datenkonsistenz Produktmanagement Alle Technologien sind hinsichtlich Produkttexten und Schlagwort‐Auszeichnung konsistent. Werden Listenelemente aus dem Produktkatalog in das „Excel“‐Format exportiert, bleibt nur die letzte Taxo‐ nomie‐Ebene als String erhalten. Listenelemente des Produktkataloges und BDLC können auf bereits im System vorhandene Bilddaten verweisen. Letzteres jedoch nicht automatisiert zu den Identifikatio‐ nen. Der Produktkatalog sieht keine Bewertungsspalte vor. Ebenso bedarf es bei Letztgenanntem eines manuellen Im‐ und Exportvorgangs, um die Produktdaten in das Shop‐System transferieren zu können. 5.3.4.2. Datenkonsistenz Kundenaktionen Mittels der Implementierung von SQL‐Sichten (bei BDLC und BCS), Verwendung der JOIN‐Klausel, kön‐ nen Kundenstammdaten direkt den einzelnen Benutzern, zur Visualisierung im PIM‐System, hinzuge‐ fügt werden. In SP (Produktkatalog) kann ein erweitertes Suchcenter eingerichtet werden, welches auf negative Suchanfragen analysiert werden kann. BDC und BDLC erlauben out‐of‐the‐box keine Suchaus‐ wertung. Barrieren sind analog dem Produktmanagement. 5.3.4.3. Barrieren im Datenaustausch Zu keiner Attributs‐Ansteuerung muss bei der Verwendung der Technologien BDC und BDLC das Shop‐ Backend betreten werden. Probleme jedoch bei dem Bedarf, komplett neue Bilder, d. h. noch nicht im Shop integriert, verwenden zu wollen. Bei Verwendung des Produktkataloges muss der administrative Bereich des Shops für die Ex‐ und Importvorgänge betreten werden (vgl. 5.3.5.1 und 5.3.5.2), welches in Folge dessen den Bedarf einer redundanten Rollen‐ und Rechtevergabe bewirkt. 5.3.4.4. Zeitbedarf verschiedener Funktionen Erheblicher Zeitbedarf bei der Erst‐Implementierung von BCS und BDLC. Bei Neu‐Implementierung sind erweiterte Fähigkeiten hinsichtlich SQL‐Statements und SQL‐Verbindungsdialog, sowie Kenntnisse über Datenbankschnittstellen (z. B. OLEDB) von immenser Bedeutung. 5.3.4.5. Anbindungsfähigkeit an Drittsysteme Da BDC und BDLC wie erwähnt SQL‐Tabellen integrieren, bestehen bei Informationsmanagementsys‐ temen, welche ebenfalls SQL‐Statements integrieren können (SQL‐Konnektoren), keine Probleme. Der Produktkatalog ist in alle gängigen Microsoft‐Produkte, z. B. Visualisierung in „Excel“ oder „Microsoft Access“ durch Aufbau einer Datenverbindung vorgesehen. Die Anbindung von externen Inhaltstypen ist kongruent zu BDC oder BDLC nicht ohne Experten‐Knowhow realisierbar. 28 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.3.4.6. Verwaltungsfähigkeit In externen Listen, welche auf BCS beruhen, können keine weiteren Spalten hinzugefügt werden. Ebenso können keine Workflows verwendet werden. Der Produktkatalog verfügt über alle Funktionen hinsichtlich Mail‐Benachrichtigung, Anbindung/Implementierung von Workflows oder Berücksichti‐ gung neuer Inhaltstypen. Bei Verwendung der BDLC‐Technologie, können alle Funktionalitäten, analog des Produktkataloges verwendet werden. 5.3.5. Technologie‐Entscheid und Begründung Der Produktkatalog verfügt über vielfältige Möglichkeiten Produktdaten zu verwalten. Ebenso funkti‐ oniert die Integration von in der SP‐Umgebung vorhandenen Listen (z. B. „Media Asset“) oder dem „Term‐Store‐Manager“ intakt. Eine mögliche Bestellverwaltung und eine daraus resultierende Mög‐ lichkeit Zahlungsverfahren vorzunehmen sind nicht geboten. Der alleinige Einsatz des Produktkatalo‐ ges im Rahmen einer Shop‐Präsenz ist somit nicht funktionsfähig. Mittels des externen Inhaltstyps (BCS) können alle im SQL Server verfügbaren Tabellen/Sichten in die SP‐Umgebung integriert werden. Workflows und ergänzende Inhaltstypen werden nicht unterstützt. Der „Business Data List Connector“ schließt die Lücke zwischen beiden zuvor genannten und wird des‐ halb vorrangig im Fortlauf der Studie verwendet. Mit Hilfe des Connectors (Anschluss) können alle SQL Tabellen und Listen in das PIM‐System gespiegelt werden. Ferner können alle Funktionen, wie diese auch im Produktkatalog verfügbar sind, z. B. Workflows und Inhaltstypen, implementiert werden. Eine Metadaten‐Navigation im Bereich der lokalen Navigation, welche anhand des „Term‐Stores“ agiert, ist ebenfalls möglich. 5.4. Integrations‐Komponente Kundenverwaltung Unter Kundenverwaltung wird in der vorliegenden Studie die Rückkopplung der im Shop, durch den Kunden hinterlegten Stammdaten (Kontaktanschrift, Name, User‐Account, etc.) in ein Benutzerverwal‐ tungssystem (z. B. AD) sowie generierte Kundeneinträge im Shop (Blog, Bewertung, etc.) in das PIM‐ System verstanden. Bei der Integration der angesprochenen Rückkopplung der Kundendaten (Stammdaten, Einträge) in der eigenen PIM‐Umgebung ist es deshalb von ausschlaggebender Bedeutung alle zur Verfügung ge‐ stellten Attribute ansteuern zu können. Die Güte der Kunden‐Integration kann somit an dem Erfül‐ lungsgrad des Attribut‐Transfers gemessen werden. 29 5 Konzeptmodell für die Entwicklung der System-Interaktion Innerhalb der Kundenverwaltung sind folgende vier Akteure aktiv: Kunden, welche eigene Profile anlegen und im Web‐Shop‐System sozial‐medial agieren, ein Web‐Shop‐System, welche die Oberfläche für den Kunden darstellt, ein PIM‐System, in welchem generierte Kundeneinträge gesammelt werden, ein Benutzerverwaltungssystem, in welchem Stammdaten zu Kunden gesammelt werden. 5.4.1. Findung von Produkten Das Auffinden von Produkten beschreibt die finale Barriere zwischen „Betreten“ der Webseite und die Auslösung des möglichen Bestellimpulses. Genannte Hürde wird durch den Interessenten, i. d. R. mit‐ tels einer Volltextsuche, die anhand Metadaten‐Filterung erweiterbar ist, oder anhand des direkten Navigierens zu Produkten mithilfe von Steuerelementen/Überschriften, überwunden. Der Sucherfolg wird durch den Artikeln beigefügten Schlagworte oder im Text enthaltene Wörter (vgl. 2.2.2) beeinflusst. Bei einer erfolglosen Suche können zwei Gründe vorliegen: Falsche Wortphrasen/‐silben bei der Worteingabe, oder fehlende Auszeichnung durch Schlagworte. Das Auffinden von Produkten findet komplett in der Shop‐Oberfläche statt, weshalb keine Implemen‐ tierung nötig ist. 5.4.2. Bestellung von Produkten und Stammdaten‐Integration Die Produktbestellung stellt den unmittelbaren, scheinbar erfolgreichen Übergang zwischen Produkt‐ suche und Kaufabwicklung dar und wird i. d. R. als Warenkorb/Wunschliste/Merkliste‐Transfer be‐ zeichnet. Bis zur finalen Einleitung des Abwicklungsprozesses findet eine dauerhafte sowie parallele Präsenz der Produktfindung, zum Ziel dem Kunden Artikel zu suggerieren, statt. Für den Dienstleister können aufgrund von Kundendaten, die aus Stammdaten (Anschrift, Alter, Kontaktdaten) und Infor‐ mationen über dessen Kaufverhalten bestehen, Rückschlüsse für weitere Marketingmaßnahmen ge‐ schlossen werden. Das Bestellen von Produkten findet komplett in der Shop‐Oberfläche statt, weshalb keine Implemen‐ tierung nötig ist. Eine Implementierung ist jedoch bei der Gewinnung der Kunden‐Stammdaten und deren Verweis an das Benutzerverwaltungs‐System nötig, welche nachfolgend beschrieben wird. 30 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.4.2.1. Transfer der Kunden‐Stammdaten von SmartStore.NET zu Active Directory Für den Export der Stammdaten aus dem Shop‐System stehen drei Lösungen zur Verfügung: Direkter Excel‐Export aus dem Shop Direkter XML‐Export aus dem Shop Einbindung der SQL‐Tabellen in ein ausgelagertes Excel‐File Alle drei Varianten generieren eine Syntax, welche nicht ohne Anpassungen in das AD importiert wer‐ den kann. Daher muss zwingend eine Manipulation der Datenstruktur (z. B. mittels Excel‐Makro oder XSL‐T) vorgenommen werden. Erstgenannte Varianten exportieren nicht alle Stammdaten, so wird z. B. die Lieferadresse nicht berücksichtigt. Diese Varianten werden daher nicht näher betrachtet. 5.4.2.2. Datenanbindung und CSV‐Export in Microsoft Excel „Microsoft Excel“ bietet die Möglichkeit Tabellen aus einer SQL‐Datenbank direkt in das Kalkulations‐ blatt einzubinden. Der Verbindungsassistent alleine, d. h. Visualisierung des gesamten SQL‐Tabellen‐ Inhalts ist nicht sinnvoll, da beispielsweise nicht jeder Kunde eine Adresse hinterlegt hat. Des Weiteren sind die Stammdaten des Kunden auf verschiedenste SQL‐Tabellen verteilt, welche mittels IDs (Identi‐ fikation) auf andere SQL‐Tabellen referenzieren (vgl. Abb. 5‐5). Abb. 5‐5: Exemplarischer Verbund von Relationen für Kundenstammdaten (Join) Die SQL‐Verbindung kann deshalb um komplexe SQL‐Abfragen ergänzt werden (vgl. Abb. 5‐6). Abb. 5‐6: Exemplarisches SQL‐Statement innerhalb der Excel‐Anwendung Die gezeigte Abfrage generiert Inhalte innerhalb eines „Excel“‐Blattes, welches alle Variablen zur Kun‐ denstammdaten‐Verwaltung aus den abgefragten Tabellen, inklusive der korrekten Zuordnung, an‐ hand IDs gesteuert, enthält. Die generierte Tabelle ist jedoch noch nicht in Form der, für den AD CSV‐ Import benötigten (vgl. Anhang D), Validität geordnet. Die automatisierte Ordnung sowie der finale CSV‐Export aus „Excel“ müssen deshalb mittels eines „Visual‐Basic“ Skriptes (oder XSLT) erfolgen. 31 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.4.2.3. Power‐Shell‐Import des CSV‐Files nach Active Directory “Csvde.exe” ist ein Dienstprogramm, mit dessen Hilfe Kontakte und Benutzerkonten nach AD, via „Po‐ werShell“ importiert, werden können. „Csvde.exe“ kann beispielsweise mittels des AD‐Modul für „Windows Power Shell“, welches zur Ansteuerung von Skripten verwendet wird (vgl. Anhang D), aus‐ geführt werden. Header und Inhalt können durch weitere Inhalte erweitert werden (vgl. Tab. 5‐5). Tab. 5‐5: Exemplarische Übersicht ergänzender AD‐Attribute CSV‐Attribut SQL‐Variable Bedeutung telephoneNumber Phone Number Telefonnummer streetAddress Adress1 Anschrift I City Stadt postalCode ZIPPostalCode Postleitzahl 5.4.2.4. Transfer der Kunden‐Stammdaten aus Active Directory zu SharePoint SP bietet die Möglichkeit mittels des „Active Directory Services“ (ADS) Daten aus AD zu importieren. Der Vorteil einer Integration in die AD‐Umgebung liegt darin, die Kunden‐Stammdaten auch für später anzudenkende Anbindungen an ERP‐ oder CRM‐Systeme zu realisieren. Die Benutzer inklusive Kunden sind somit zentral abgelegt. Des Weiteren besteht der Vorteil durch die ADS, Authentifizierungs‐Infor‐ mationen (z. B. Password, Username) automatisiert in SP nutzen zu können. So wird es beispielsweise auch möglich, jedem Benutzer (Kunden) eine eigene „MySite“ zu generieren, welches bei SQL zu SQL nicht möglich wäre. 5.4.2.5. Automatisierte Anpassung bei der SharePoint Installation Bei der Installation von SP wird automatisiert eine Verbindung zu dem auf dem gleichen Server befind‐ lichen Dienstverzeichnis hergestellt. Alternativ können andere Standorte des Verzeichnisdienstes hin‐ terlegt werden. Die Konfiguration der Zuordnung zur Dienstanwendung „Business Data Connectivity‐ Service“ kann in der Zentraladministration unter „User Profile Administration“ betrachtet und an die‐ ser Stelle nochmals detailliert konfiguriert, z. B. „Users Only“ (Nur Benutzer) oder „Users and Groups“ (Benutzer und Gruppen) für die Konfiguration der Synchronisations‐Entitäten, angepasst werden. 5.4.3. Bewertung von Produkten Die Produktbewertung erfolgt direkt für einzelne Artikel. Die Beurteilungen werden durch den Kunden anhand von Text und Ranking (0‐5) generiert. Aufgrund getätigter Rezensionen können sich potentielle Interessenten somit direkt bei Konsumenten über die Produktgüte informieren. 32 5 Konzeptmodell für die Entwicklung der System-Interaktion Die Bewertung von Produkten findet komplett in der Shop‐Oberfläche statt, weshalb keine Implemen‐ tierung nötig ist. Eine Implementierung ist jedoch bei der Gewinnung der Bewertungen und deren Ver‐ weis an das PIM‐System nötig, welche nachfolgend beschrieben wird. 5.4.3.1. Transfer artikelbezogener Bewertungen von SmartStore.NET zu SharePoint Für den Transfer erhaltener Artikelbewertungen von der Shop‐Oberfläche in das PIM‐System kann die Implementierung von „External Data Sources“ (Externe Datenquellen) mittels der BDLC‐Solution ver‐ wendet werden. Mittels genannter Funktion lassen sich Inhalte aus SQL‐Tabellen direkt in die SP‐Um‐ gebung, genauer in deren Listen, einbetten und stehen dort zur Visualisierung/Editierung bereit. 5.4.3.2. Kombination verschiedener SQL‐Tabellen in SharePoint für erhaltene Bewertungen „Externe Inhaltstypen“, hier die erhaltenen Bewertungen, können als eigene Liste, „Externe Liste“, o‐ der direkt in bestehenden SP ‐Listen, als Spalte, welchen externen Inhalt umfasst, gepflegt werden. So ist es möglich Inhalte aus verschiedenen SQL‐Tabellen, welche anhand einer SQL‐Sicht miteinander verknüpft werden, in einer einzigen SP‐Liste aufzuführen. Die direkte Verknüpfung verschiedener SQL‐ Tabellen (Join‐Statement) in SP wird nicht unterstützt. 5.4.4. Weitere soziale Aktivitäten Die Blog‐/Foreneinträge sind in einzelne Themengebiete (Lieferung, Rabatt‐Coupon, etc.) unterteilt. Diese erfolgen demnach artikelunspezifisch können jedoch Rückschluss auf die Qualität einzelner Ab‐ teilungsbereiche (z. B. Versandabteilung) liefern. Das verwendete Web‐Shop‐System bietet beide Technologien (Blog und Forum). Diese können in ver‐ schiedene Themenbereiche, durch den Administrator generiert, gegliedert werden. Funktion und Rückschlüsse für die Unternehmung sind bei beiden identisch. Die Aktionen für den Kunden und PIM‐ Transfer sind marginal unterschiedlich, weshalb beide nachstehend übergreifend beschrieben werden. Die Generierung von Blog‐/Foreneinträgen findet komplett in der Shop‐Oberfläche statt, weshalb keine Implementierung nötig ist. Eine Implementierung ist jedoch bei der Gewinnung der Einträge und deren Verweis an das PIM‐System von Bedarf, welche folglich beschrieben wird. 5.4.4.1. Transfer artikelübergreifender Kundeneinträge von SmartStore.NET zu SharePoint Der Datentransfer erfolgt prinzipiell analog zu artikelspezifischen Kundeneinträgen (vgl. Abschnitt 5.4.3.1) inklusive der Migration einer SQL‐Liste (vgl. Anhang B). 33 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.4.4.2. Verwaltung verschiedener Blog‐/Foren‐Themengebiete in SharePoint Das Shop‐System berücksichtigt die Möglichkeit der Pflege verschiedener Blog‐Kategorien bzw. ver‐ schiedener Titel der Blogs. Für die Verwaltung der verschiedenen Themengebiete stehen in SP zwei Varianten zur Verfügung: a) Verschiedene Themengebiete in einer Liste zusammengefasst (vgl. Abb. 5‐7) b) Für die Verwaltung jedes Themengebietes eine einzelne Liste Abb. 5‐7: Exemplarischer Verbund von Relationen für Blogeinträge (Join) Für die Migration neuer Themen sollte es dem Redakteur, ohne den Bedarf neue SP‐Listen migrieren zu müssen, möglich sein neue Themen pflegen zu können. Deshalb wird Variante a) gewählt. Neue Ereignisse können folglich als neues „Item“ in der SP‐Liste migriert und aufgrund der Aktions‐ Definition „Enable Write‐Back“ (erlaube Rückschreiben in die SQL‐Tabelle) transferiert werden. Ange‐ sichts der SQL‐Integration werden neue Themengebiete umgehend für den Shop‐Besucher sichtbar. 5.5. Integrations‐Komponente Produktdaten‐ und Designmanagement Unter Produktverwaltung wird in der vorliegenden Studie die Migration/Editierung von neuen/beste‐ henden Produkten verstanden. Hierbei werden die Produkte in Warengruppen, realisiert durch die „Term‐Store“‐Technologie (Spalte: Managed Metadata) in SP, zugeteilt und die Artikel mit Schlagwor‐ ten, verwirklicht durch „Enterprise‐Keywords“ in SP, versehen. Migrierte Produkte werden abschließend durch einen Vorgesetzten, welcher mittels Approval‐Work‐ flow auf die anstehende Genehmigung hingewiesen wird, ermöglicht durch SP‐Tasks und darin enthal‐ tenem Formular (SP: Forms), bewertet (genehmigt oder abgelehnt). Nach der Genehmigung erfolgt der automatisierte Publikationsprozess. 34 5 Konzeptmodell für die Entwicklung der System-Interaktion Die Designverwaltung enthält viele wesentliche Variablen im Frontend‐Umfeld, um bei einem mögli‐ chen Käufer die Dauer des Verweilens im E‐Shop positiv zu beeinflussen. Bei der Integration der ange‐ sprochenen Verwaltung analog eines WCMS in der eigenen PIM‐Umgebung ist es deshalb von aus‐ schlaggebender Bedeutung alle zur Verfügung gestellten Attribute ansteuern zu können. Die Güte der Design‐Integration kann somit an dem Erfüllungsgrad des Attribut‐Transfers gemessen werden. Innerhalb des Produktdatenmanagements sind folgende vier Akteure aktiv: Ein Produktdatenmanager, welcher Daten migriert und deren Struktur verwaltet, ein Abteilungsleiter, welcher den Genehmigungsprozess abschließt, ein Designer, welcher die nötigen Konfigurationen innerhalb des PIM‐Systems vornimmt, ein PIM‐System, in welchem generierte Änderungen/Einträge gesammelt werden. 5.5.1. Produkte verwalten Unter „Produkte verwalten“ ist neben der rein textuellen Pflege von Produktinformation die Verwal‐ tung der verwirklichten Folksonomie und Taxonomie zu verstehen. Es erfolgt die Pflege neuer Pro‐ dukte, aber auch die Inline‐Bearbeitung bestehender. Für die Verwaltung der Produkte stellt SP 2013 das Template des „Produktkataloges“ bereit, dessen rudimentäre Import‐Möglichkeiten in einer Studie von Jens Gäbeler (Gäbeler, 2013) untersucht wurden (vgl. Abschnitt 4.1, 4.2, 4.2.1 bis 4.2.3). Der Produktkatalog bedient sich bei der Verwaltung der Produkte mittels spezifischer Inhaltstypen („Product“ oder „Product with Image“) (vgl. 5.5.1.1). 5.5.1.1. Inhalts‐ und Spaltentypen des Produktkataloges Der Inhaltstyp „Product with Image“ bringt neben reinen Textspalten (z. B „Single line of text“ für den Titel) auch die Spalte „Item Category“ (Element Kategorie) mit sich, welche vom Typ „Managed Meta‐ data“ ist und sich durch Elemente des „Term‐Stores“, welcher der Taxonomie‐Verwaltung innerhalb SP dient, in das Element einbinden lässt (vgl. Tab. 5‐6). Weiteres Feature ist die Spalte „Rollup Image“. Anhand der Bildervorschau können den Produktelementen Medien beigefügt werden, die beispiels‐ weise innerhalb einer SP‐Asset‐Liste gepflegt sind. 35 5 Konzeptmodell für die Entwicklung der System-Interaktion Tab. 5‐6: Spaltentypen des Inhaltstyps "Product with Image" Spaltenname Bedeutung SP‐Datentyp Eigenschaft Title Titel Single line of text Erforderlich Item Number Element‐Nummer Single line of text Optional Group Number Gruppen‐Nummer Single line of text Optional Language Tag Sprach‐Auszeichnung Choice Optional Rollup Image Vorschau‐Bild Image with formating and con‐ Optional straints for publishing Item Category_0 Zuordnung der Kategorie Multiple lines of text Ausgeblendet Taxonomy Catch All Column Zuordnung Term‐Stores Lookup Ausgeblendet Taxonomy Catch All Column1 Zuordnung Term‐Stores Lookup Ausgeblendet Item Category Element‐Kategorie Managed Metadata Optional 5.5.1.2. Katalog‐Navigation mittels Term‐Store‐Integration Wesentlicher Vorteil des „Term‐Stores“, neben der Möglichkeit einer hierarchischen Struktur für die SP‐Elemente, ist die Möglichkeit, die Taxonomie‐Migration für Navigationszwecke zu verwenden (vgl. Abb. 5‐8, grüner Rahmen). Grund ist die bereits implementierte Navigation des Typs „Managed Navi‐ gation“, die sich in Bezug auf deren Inhalte und Struktur an den angesprochenen „Term‐Set“ orientiert. Selbst Produkt‐ definierte vorschau Navigation in SP Navigation SP‐ mittels Frontend Term‐Store (Auszug) Abb. 5‐8: Exemplarische Metadaten‐Navigation mittels SP‐Term‐Store 5.5.1.3. SQL‐Integration innerhalb des Produktkataloges Mittels der „Business Data List Connection“‐Technologie kann die SQL‐Tabelle “dbo.Products”, welche alle artikelrelevanten Spalten (ausgenommen Schlagwort‐Auszeichnung, Kategorie und Bild, jedoch Meta‐Migration) enthält, in den Produktkatalog transferiert werden (vgl. Anhang B und Tab. 5‐7). Nach erfolgreichem Verbindungsaufbau erhält man so eine Liste, welche aus Spaltentypen des ursprüngli‐ chen Produktkataloges sowie den SQL‐Spalten besteht. Dies bedeutet die Taxonomie‐Verwaltung mit‐ tels „Term‐Store“, Genehmigungs‐Workflow des Produktkataloges, Nachverfolgbarkeit durch Anzeige 36 5 Konzeptmodell für die Entwicklung der System-Interaktion des Bearbeitungsdatums und ‐person sowie die barrierefreie SQL‐Integration. Alle Strukturinformati‐ onen bleiben somit konsistent. Tab. 5‐7: Konsolidierung des Produktkataloges mit SQL‐Inhalten Herkunft/Technologie Spalten Produktkatalog (SP) Rollup Image, Genehmigungs‐Workflow, Kategorie, Modified By, Created By, Title, Enterprise Keywords BDLC (SQL – OleDB) Id, Name, ShortDescription, FullDescription, AdminComment, ProductTemplateId, ShowOnHomePage, MetaKeywords, MetaDescription, MetaTitle, AllowCustom‐ erReviews, ApprovedRatingSum, NotApprovedRatingSum, ApprovedTotalReviews, NotApprovedTotalReviews, SubjectToAcl, LimitedToStores, Published, Deleted, CreatedOnUtc, UpdatedOnUtc 5.5.1.4. Hersteller‐, Kategorie‐ und Schlagwort‐Zuweisung mittels SQL Die Migration weiterer Produktdetails mit unmittelbarem Einfluss auf das Shop‐System ist in anderen SQL‐Tabellen gespeichert. Die Zuweisung der migrierten Elemente (z. B. Kategorie) erfolgt über eine separate SQL‐Liste. Somit kann neben dem „Term‐Store“, welcher innerhalb SP Verwendung findet, die SQL‐Kategorie‐Zuweisung innerhalb einer externen Liste gepflegt werden (vgl. Abb. 5‐9). Abb. 5‐9: Redundante Klassifizierungs‐Migration (links: Term‐Store; rechts: Externe Liste) Hersteller‐ und Tag‐Zuweisung erfolgen analog des Kategorie‐Mapping weshalb diese nicht näher be‐ schrieben sind. 5.5.2. Produkte veröffentlichen/sperren Bei der Veröffentlichung von Produktdaten werden die Produktinformationen final publiziert. Voraus‐ setzung ist die Befugnis, abgehandelt mittels eines Workflows, durch den direkten Vorgesetzten. 5.5.2.1. Standard‐Workflow für Genehmigungsprozesse Der Produktkatalog verfügt standardmäßig über einen Genehmigungs‐Workflow. Mittels dessen kön‐ nen Produktdatenmanager die Erlaubnis zum Publizieren erfragen. Ein Anstoß kann manuell oder au‐ tomatisiert, bei Neumigration oder Modifikationen von Listenelementen erfolgen. 37 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.5.2.2. Modifizierter Genehmigungs‐Workflow inklusive Publikationsprozess Mittels „SP‐Designer“ können neue Workflows migriert oder Bestehende modifiziert werden. Die Spalte „Published“ (Publiziert, Standardwert: No) (vgl. Tab. 5‐7), hat unmittelbaren Einfluss auf die Veröffentlichung im Shop. Der modifizierte Workflow beinhaltet somit eine If‐Abfrage (Ob‐Abfrage), welche bei erfolgreichem Genehmigungsprozess den Wert der Spalte „Published“, für das genehmigte Listenelement, automatisiert auf „Yes“ setzt. Abb. 5‐10: Implementierung eines Genehmigungsworkflow inklusive Publikationsanstoß 5.5.3. Design verwalten Für die Designverwaltung stehen die Aspekte Corporate Design und Integration eines Editors im Vor‐ dergrund. Von Bedeutung ist die Steuerung möglichst aller CSS‐Merkmale für den Shop, innerhalb des PIM‐Systems. Ferner ist von Relevanz das Design beider Systeme möglichst einheitlich gestalten zu können, für ein gemeinsames „Look and Feel“ (Aussehen und Handhabung). Alle Konfigurationen bzgl. Design‐Themes sollten ohne Wissen der verwendeten CSS‐ und HTML‐Technologien möglich sein. 5.5.3.1. Implementierung eines Design‐Editors in SharePoint Für die nachfolgend beschriebenen Implementierungsschritte können u. a. die Web‐Parts „Page‐Vie‐ wer“ und „Script‐Editor“ zur Realisierung eines integrierten Editors, inkl. Vorschau, verwendet werden. 5.5.3.2. Page‐Viewer WebPart für die Designintegration Im Web‐Shop‐Backend des E‐Commerce‐Systems „SmartStore.NET“ ist bereits ein kleines WCMS inte‐ griert. Hierüber können sämtliche Farb‐, Schrift‐, Bilder‐ und Positionierungs‐Variablen individuell edi‐ tiert werden. Dem Designer wird es durch Einbettung des Shop‐WCMS in die PIM‐Umgebung möglich alle wesentlichen Änderungen, inklusive einer Vorschau‐Funktion, in SP zu realisieren. Das Web‐Part „Page Viewer“ dient der Visualisierung von externen Webseiten, d. h. Webseiten die außerhalb der SP‐Umgebung liegen. Mit Hilfe des genannten Web‐Parts lässt sich so das Web‐Shop‐ Backend in die PIM‐Oberfläche einbinden. Durch verschiedene Anordnungsvarianten und hinterlegte URLs lässt sich so ein externer Editor integrieren: 38 5 Konzeptmodell für die Entwicklung der System-Interaktion Bearbeitungs‐Ansicht: Variablen werden, inkl. Farb‐Picker und ggf. Drop‐Down‐Menü, gezeigt. Vorschau‐Ansicht: Eine aktuelle Vorschau wird gezeigt, welche mittels eines HTML‐Snippets (Schnipsel) manuell neu geladen werden kann. Mit Hilfe dessen kann die Auswirkung, der in der Bearbeitungs‐Ansicht vorgenommenen Theme‐Konfigurationen, beinahe parallel betrach‐ tet werden (vgl. Abb. 5‐11). SP‐ Frontend Vorschau des Shops innerhalb SP Abb. 5‐11: WebPart Page‐Viewer zur Design‐Vorschau 5.5.3.3. SharePoint Color Palette Tool für Corporate Designs „Microsoft“ stellt einen kostenfreien, externen Editor für SP‐Designs zur Verfügung („SharePoint Color Palette Tool“). Mit diesem können die in SP verwendeten Farb‐Themes editiert und Neue angelegt werden (Dateiformat: spcolor). Der Editor verfügt über eine Live‐Vorschau (WYSIWYG) und einer Auflistung aller in einer SP‐Webseite hinterlegten Farb‐Attribute (vgl. Abb. 5‐12). Die einzelnen Farbwerte können als Hexadezimalwert in ein Textfeld eingeben oder mittels eines Farb‐Pickers ausgewählt werden. Bei Letztgenanntem wird automatisiert in den Hexadezimalwert umgerechnet. 39 5 Konzeptmodell für die Entwicklung der System-Interaktion Abb. 5‐12: Exemplarische Design‐Migration per SharePoint Color Palette Tool Bestehende Designs lassen sich wie gewohnt speichern. Neue Designs werden wie oben geschildert im Dateiformat .spcolor exportiert. Ein wesentlicher Nachteil des .spcolor‐Dateiformates (nicht‐originäres XML) ist, dass die Struktur zwar eines originären XML‐Formates entspricht (wohlgeformt), jedoch andere Elemente verwendet werden (nicht valide). Die aus SP oder dem Color Palette Tool exportierten Daten müssen demnach zwingend in eine für den Shop lesbare Ordnung manipuliert werden. Tab. 5‐8: Exemplarischer Vergleich verschiedener XML‐Strukturen Bereich XML Shop XML SharePoint (spcolor) Header <ThemeVars for="Alpha"> <s:colorPalette isInverted="false" … (Auszug) xmlns:s="http://schemas.microsoft.com/share‐ Content <s:color name="TopBarBackground" <s:color name="EmphasisBackground" (Auszug) value="C6EFEFEF" /> value="0072C6" /> Für die Herstellung der Validität bietet sich z. B die XSL‐Transformation oder „Microsoft‐Excel“ an, mit welchem Makros aufgezeichnet werden können. Der Makro‐Ablauf kann in vier Teilbereichen be‐ schrieben werden: 1. Import einer aus dem Shop exportierten Theme‐Konfiguration (originäres XML). 2. Import einer aus dem Palette‐Tool oder aus SP exportierten Theme‐Konfiguration (nicht origi‐ näres XML). 3. Transformation relevanter Farb‐Werte (aus 2.) in die für den Shop lesbare Ordnung (aus 1.). 4. Export einer originären XML‐Datei. 40 5 Konzeptmodell für die Entwicklung der System-Interaktion Analog der Farb‐Paletten‐Transformation können auch in SP hinterlegte Schriften in die Shop‐Umge‐ bung eingebunden werden. In SP werden alle Farbpaletten in einem Theme‐Katalog, einer SP ‐Liste gespeichert. Neue Themes kön‐ nen hierüber eingebunden werden. Unter „Composed Looks“ (vgl. Abb. 5‐13) sind komplette Design‐ Varianten zu verstehen. So können bestehende Varianten mittels neu generierten Farb‐Themes geän‐ dert oder ein neuer composed Look (Zusammengesetztes Aussehen), der auf das neue Design verweist, angelegt werden. Werden Looks mittels bereits bestehenden Farbpaletten modifiziert, muss kein neues Design angelegt werden. Im Menü „Change the Look“, welches ebenfalls in SP zur Verfügung steht, können alle vorhandenen Looks visualisiert sowie bestehende Farbpaletten und Schriften einge‐ bunden werden. Abb. 5‐13: Verwaltung von Farb‐Themes innerhalb SharePoint Alternativ zur SP‐Oberfläche bietet sich die direkte Einbindung des Themes mittels „SP‐Designer“ an. 5.5.3.4. Verwaltung der migrierten Themes mittels definierter Workflows Für die administrative Steuerung von Freigabe‐Workflows und Verwaltung generierter Designfiles können u. a. Dokument‐Bibliotheken, Aufgabenlisten und vordefinierte Workflows verwendet werden. Letztgenannte müssen jedoch zwingend mittels „SP‐Designer“ oder mit gestiegener Individualität in Info‐Path angepasst werden. Die nachfolgende Beschreibung widmet sich deshalb der Entwicklung ei‐ gener Workflows. Für die Entwicklung eines Genehmigungs‐Workflow kann als Basis der in SP out‐of‐the‐box befindliche Approval‐Workflow verwendet werden. Grund für eine nötige Anpassung ist in erster Linie das Nicht‐ Vorhandensein von gegliederten Kommentaren innerhalb der Initiierung‐Sicht. Die Individualisierung dieser ist mittels des SP‐Designers (vgl. Abb. 5‐14 und 5‐15) oder der Anwendung Info‐Path möglich. Bei Letztgenanntem steht eine größere Auswahl an Funktionen sowie die Möglichkeit einer Vorschau bereit. Die Theme‐Konfiguration kann im Web‐Shop Backend grob in die Menüpunkte „Allgemein“, „Typogra‐ fie“, „Layout“, „Buttons“ und „Header“ unterteilt werden. Um eine Integration genannter Elemente 41 5 Konzeptmodell für die Entwicklung der System-Interaktion und den Transfer von Initiierung‐Sicht und Genehmigungs‐Sicht zu gewährleisten, ist eine Implemen‐ tierung der unten gezeigten Zeilen, welche als Kommentar agieren, notwendig. Stets muss die soge‐ nannte Bindung, d. h. Textfeld zu einer definierten Variablen erfolgen, da sonst der gepflegte Text, wie oben angesprochen, nicht transferiert werden kann. Abb. 5‐14: Implementierung individueller Formularfelder mittels InfoPath Für die Entwicklung eines Archiv‐Workflows können out‐of‐the‐box keine vorhandenen Workflows als Grundlage dienen. Ziel des neu zu implementierenden Workflows ist der Transfer von Elementen (engl. Items) zwischen zwei Listen. Grund ist eine anzudenkende Verlagerung bereits realisierter Designs für eine möglicher‐ weise notwendige Rückverfolgbarkeit. Final wird das Element aus der ursprünglichen Liste gelöscht, um dem Designer eine Auflistung der nur aktuellen Designdateien zu gewährleisten. Abb. 5‐15: Implementierung eines Design‐Genehmigungsworkflows SP bietet neben den angesprochenen Individualisierungsmöglichkeiten von Workflows ergänzend die Möglichkeit eigene Steuerelemente, sogenannte „Quick Steps“ (schneller Zugriff) zu entwickeln. Diese können in der Menüleiste oder mittels des Item‐Editierung Buttons angesprochen werden. Wesentli‐ cher Vorteil ist, dass sich der Designer nicht in die für einen Workflowanstoß nötigen Untermenüs ein‐ wählen muss. 42 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.6. Integrations‐Komponente Nichtredaktionelle Ereignisse Unter nichtredaktionellen Ereignissen wird in der vorliegenden Studie die Möglichkeit verstanden, eine kontinuierliche Artikel‐ und Absatzverbesserung sowie einen zügigen Bestellprozess abhandeln zu kön‐ nen. Der Anstoß zur Artikelverbesserung erfolgt unmittelbar durch den Erhalt negativer Kundenbewer‐ tungen, UC 03 „Produkte bewerten“ (Abschnitt 5.4.3) (vgl. Anhang C). Der Marketingverantwortliche wird auf den Handlungsbedarf mittels eines explizit für diesen Prozess entworfenen SP‐Workflows hin‐ gewiesen. Eine Steigerung der Absatzchancen von Gütern oder Dienstleistungen kann u.a. mittels eines Discounts realisiert werden. Um verwirklichte Discounts in den Aspekten Absatzsteigerung und erhöhter Umsatz analysieren zu können, sollte es dem Marketing möglich sein, realisierte Kampagnen auszuwerten. Die Verwaltung von Lieferungen berücksichtigt durch den Kunden angestoßene Artikelbestellungen. Durch den Versand von Artikeln muss die Anzahl der noch vorhandenen Güter fortlaufend angepasst sowie der aktuelle Bestellstatus dem Käufer mitgeteilt werden. Innerhalb der nichtredaktionellen Abteilungen sind drei Akteure aktiv: Ein Marketingverantwortlicher, welcher Kampagnen verwaltet und Bewertungen analysiert, ein Produktionsverantwortlicher, welcher auf getätigte Bestellungen reagiert, ein PIM‐System, in welchem generierte Änderungen/Einträge gesammelt werden. 5.6.1. Änderungsmaßnahmen aufgrund erhaltener Artikelbewertungen Der Erhalt von Rückmeldungen aus Kundenbewertungen ist die Grundlage für einen kontinuierlichen Verbesserungsprozess (KVP), im Rahmen der Artikelgüte und Absatzchance. Änderungsszenarien kön‐ nen sein: Artikelbeschreibung oder Fertigungsdetails. 5.5.6.1. Ansätze zur Auswertung erhaltener Bewertungen Die erhaltenen Kundenbewertungen für die spezifischen Artikel können Rückschluss auf die Zufrieden‐ heit der Kunden mit dem Artikel liefern. Hieraus können Informationen für das Marketing, beispiels‐ weise Produktsperre, bei durchschnittlich schlechter Bewertung von Handelswaren oder für die Pro‐ duktion bei Produktfehlern, geschlossen werden. 5.5.6.2. Automatisierte Mittelwertberechnung mit vorhandenen Spaltentypen Durch das hinterlegte Rating (0 bis 5), welches neben der textuellen Bewertung erfolgt, kann ein Durch‐ schnittswert ermittelt werden. Für genanntes Szenario bietet SP die Möglichkeit, den Spaltentyp („Cal‐ culated Data“) zu definieren, welcher das Ergebnis aus einer Formel verschiedener Spalten berechnet. 43 5 Konzeptmodell für die Entwicklung der System-Interaktion Abb. 5‐16: Formel‐Migration für den Spaltentyp „Calculated Data“ 5.5.6.3. Automatisierter Anstoß des Verbesserungs‐Szenarios mittels Workflow Anhand des Rankingmittelwertes kann, durch die Realisierung eines eigenen Workflows, ein Hinweis auf Handlungsbedarf (Verb: „Handeln“), erfolgen. Beispielsweise kann dieser bei einem Durchschnitts‐ ranking kleiner 3 automatisiert initiiert werden (vgl. Abb. 5‐17). Abb. 5‐17: Implementierung eines KVP‐Workflows 5.6.2. Kampagnen steuern für erhöhte Absatzchancen Der Anstoß von Kampagnen wird genutzt, um die Absatzchancen zu steigern. Eine mögliche Kampagne ist die Migration eines Discounts, bei dem ausgewählte Kunden einen Code erhalten, z. B. via E‐Mail oder Facebook. Dieser kann dann bei einer Bestellung hinterlegt werden und führt zu Preisnachlass. Berücksichtigt werden muss, einen Mindestbestellwert hinterlegen zu können. Um eine Aussagekraft über getätigte Kampagnen (z. B. Discounts) zu erhalten, sollte z. B. die quantita‐ tive Verwendung einer Discountaktion, in einem definierten Zeitraum, betrachtet werden. Die Implementierung erfolgt erneut anhand BDLC und wird deshalb nicht näher erläutert. 44 5 Konzeptmodell für die Entwicklung der System-Interaktion 5.6.3. Lieferung verwalten für getätigte Kundenbestellungen Unter „Bestellung verwalten“ ist die Auflistung der getätigten Kundenbestellungen zu verstehen. Ent‐ sprechend resultiert folglich die finale Auslieferung der Produkte. Diese beinhaltet demzufolge die Be‐ stellnummer, Adresse des Kunden, Produktname sowie Bestellmenge verschiedener Produkte. Von signifikanter Bedeutung ist deshalb parallel zum Bestellvorgang die Sicherung der Kundenstammdaten, neben der geschilderten AD‐Integration, als SQL‐Inhalte. Die Implementierung erfolgt erneut anhand BDLC und wird deshalb ebenfalls nicht näher erläutert. 45 6 Einsatzerfahrung und Bewertung der Vorgehensweise 6. Einsatzerfahrung und Bewertung der Vorgehensweise 6.1. Beispielmigration eines neuen Produktes Im Wesentlichen wird unter Migration neuer Produkte die Generierung neuer Elemente im SP‐Pro‐ duktkatalog, die Auszeichnung jener mittels Schlagworten und Klassifizierung sowie der finale Publi‐ kationsprozess, abgehandelt mittels Genehmigungs‐Workflow, verstanden. 6.1.1. Migration des Artikels innerhalb des Produktkataloges Dem Produktdatenmanager steht bei Einwahl in die Liste des Produktkataloges das Quick‐Step „New Item“ (Neues Element) zur Verfügung. Bei Anwahl erscheint das hinterlegte Formular, mit dem die Element‐Attribute hinterlegt werden können. Die gezeigte Form (Abb. 6‐1) besteht wie gefordert aus Elementen der direkten SQL‐Verbindung sowie Attributen, welche zur besseren Verwaltung innerhalb des SP‐Produktkataloges dienen. So sind neben der Eingabe von Strings zur Pflege von Beschreibungs‐ texten, Integers (Datentyp für ganzzahlige Werte) für die Migration von IDs und booleschen (logischer Operator) Werten für beispielsweise die Angabe zur Publikation (Yes oder No) auch Spaltentypen die der Taxonomie‐, Spalte „Kategorie Term‐Store“ und Folksonomie‐Steuerung, Spalte „Enterprise Keywords“, SP‐intern dienen, realisiert. Abb. 6‐1: Konsolidierte Elementattribute für die Produktmigration 46 6 Einsatzerfahrung und Bewertung der Vorgehensweise 6.1.2. Auszeichnung der Produkte durch Klassifikation und Schlagworte Die im Produktkatalog migrierten Produkte verfügen wie dargestellt über eine Identifikationsnummer. Anhand derer können Produkte einer Warengruppe zugeteilt werden. Der Verweis erfolgt mittels An‐ gabe der Kategorie‐ID, welche auf die SQL‐Liste zur Kategorie‐ Verwaltung referenziert. Im Beispiel dargestellt bedeutet dies: Produkt 3 „Benz Sektpackung“ ist Bestandteil der Kategorie 1 „Sekt“. Abb. 6‐2: Kategorie‐Zuweisung für Produkte (Taxonomie) per ID‐Zuweisung Wie in Abb. 6‐3 ersichtlich, so wird durch die SQL‐Verbindung das Produkt auch im Shop‐Frontend korrekt der Kategorie zugeteilt und die Hierarchie mittels Navigation richtig zugeordnet. Abb. 6‐3: Exemplarische Auswirkung einer Kategorie‐Zuweisung für Produkte Durch die Angabe von Eltern‐Kategorien (Spalte: ParentCategoryID) können so auch mehrstufige Ka‐ tegorie‐Hierarchien realisiert werden. Element „Rot‐ und Weißwein“ (Id 7) ist beispielsweise Kind‐Ele‐ ment des Eltern‐Elements „Geschenkpaket“ (Id 3) (vgl. Abb. 5‐9). Die Migration und Produkt‐Verknüpfung von Schlagworten erfolgt analog zur Verwaltung der Waren‐ gruppen, weshalb diese nachfolgend nicht näher erläutert wird. 6.1.3. Genehmigungsworkflow und Anstoß zur Publikation Die Unter 6.1.1 migrierten Elemente müssen vor der Publikation einen Genehmigungsprozess durch‐ laufen. Wie dargestellt kann der Produktdatenmanager den Workflow für das Element starten. 47 6 Einsatzerfahrung und Bewertung der Vorgehensweise Dem Vorgesetzten (Approver) erscheint die Aufgabe automatisiert in dessen Task‐Liste, wonach dieser den Genehmigungsprozess abschließen (genehmigen oder verwerfen) kann. Es können darüber hinaus Kommentare, welche beispielsweise Gründe der Nicht‐Genehmigung enthalten, hinterlegt werden. Abb. 6‐4: Genehmigungsworkflow für den Publikationsvorgang Das genehmigte Produkt erhält bei Genehmigung den Status „Genehmigt“. Durch den erweiterten Workflow wird bei Genehmigung die Spalte „Published“ automatisiert auf den Wert „Yes“ gesetzt, was eine unmittelbare Publikation im Shop‐Frontend zur Auswirkung hat (vgl. Abb. 6‐3). Abb. 6‐5: Exemplarische Auswirkung für genehmigte Listenelemente 6.2. Reaktion auf Bewertungen mittels Workflow Das arithmetische Mittel aus Bewertungssumme und Anzahl Bewertungen gibt Aussage betreffend der Artikelzufriedenheit über mehrere Bewertungen hinweg und harmonisiert mögliche Ausreißer. 6.2.1. Handlungsanstoß mittels Formelimplementierung Der BDLC bietet die Möglichkeit einzelne Spalten der SQL‐Tabelle „Products“ anstatt der gesamten Tabelleninhalte zu transferieren. Die Spalte „Handlungsbedarf“ trägt eine Formel, deren Werte sich als 48 6 Einsatzerfahrung und Bewertung der Vorgehensweise Quotient aus dem Dividendem „ApprovedRatingSum“ (Summe aller Rankings) und dem Divisor „Ap‐ provedTotalReviews“ (Anzahl getätigter Rankings“) ergibt. Sinkt dieser unter 3.00 so ist das Produkt zu verbessern („Handeln!“). Abb. 6‐6: Auswertung erhaltener Kundenbewertung (Rankings) 6.2.2. Rückschluss auf erhaltene Bewertungen Die arithmetische Auswertung der Produktbewertungen beinhaltet noch nicht die vom Kunden hinter‐ legten Texte. Für den Marketingverantwortlichen sind jedoch elementar, die Gründe die ggf. zu einer schlechten Bewertung führten, zu kennen, um durch deren Erhalt Verbesserungs‐Szenarien zu initiie‐ ren. Mittels Vererbung zwischen unterschiedlichen SQL‐Tabellen (Join) kann die Bewertungsliste an‐ hand Produkt und Kundentext analysiert werden. Abb. 6‐7: Auflistung erhaltener Kundenbewertung (Text) 49 6 Einsatzerfahrung und Bewertung der Vorgehensweise 6.3. Shop‐Umgebung aus Kundensicht 6.3.1. Sucherfahrung Das Auffinden von Produkten inklusive erweiterter Suchkriterien findet eigenständig über die Shop‐ Oberfläche statt. Neben dem Basis‐Suchcenter, welches mittels eines Suchschlitzes agiert (vgl. Abb. 6‐8) wird der Kunde bei der Suchanfrage auf das Enterprise‐Suchcenter weitergeleitet. In der Enterprise‐Suche stehen folgende erweiterte Suchkriterien, mittels Metadaten‐Filterung reali‐ siert, zur Verfügung: Kategorie, welches die Eingrenzung von Warengruppen bedeutet, Hersteller, welches die Filterung nach bestimmten Marken bedeutet, Preisgruppe, bei der eine Preisspanne (von n bis nn) definiert werden kann, Auswahl, zur Suche in Unterkategorien, wodurch Warengruppen der Ebene zwei (Unter‐Wa‐ rengruppen) durchsucht werden, Auswahl, zur Suche in Produktbeschreibung, welches eine On‐Page Suche bedeutet. Abb. 6‐8: Erweitertes Suchcenter des Shop‐Systems 6.3.2. Look and Feel der Shop‐Oberfläche Den Kunden stehen neben einer lokalen und globalen Navigationsleiste die Artikelauswahl mittels Hersteller oder Tags zur Verfügung. Gewünschte Artikel können vergleichen, in die Wunschliste oder direkt in den Warenkorb transferiert werden. Neben den sozialen Funktionen Blog und Bewertungen 50 6 Einsatzerfahrung und Bewertung der Vorgehensweise können auch Umfragen durchgeführt werden. Standardmäßig befindet sich im oberen Bereich ein Content‐Slider (Inhaltsschieber) (vgl. Abb. 5‐11, grüner Rahmen). 6.4. Vor‐ und Nachteile der Ansätze 6.4.1. Taxonomie‐ und Folksonomie‐Management Das Auffinden von Produkten inklusive erweiterter Suchkriterien findet eigenständig über die Shop‐ Oberfläche statt. Durch die Implementierung des Inhaltstyps „Produkt with Image“ des Produktkataloges können die Produkte in Kategorien innerhalb der SP‐Umgebung zugeteilt werden. Diese wiederum ermöglicht eine durch Metadaten strukturierte lokale Navigationsleiste, die dem Redakteur einen schnellen Produkt‐ einstieg ermöglicht. Der Spaltentyp „Enterprise Keywords“ ermöglicht ein rasches hinzufügen von Schlagworten zu den Artikeln, welcher eine bessere SP‐interne Sucherfahrung liefert. Der in SP gepflegte „Term‐Store“ lässt sich nur in das CSV‐Dateiformat exportieren. Eine Verbindung von „Term‐Store“ zum Shop‐System ist deshalb nicht möglich. Für die Realisierung von Warengruppen sowie Schlagworten muss demzufolge zwingend eine externe SQL‐Liste redundant gepflegt werden. 6.4.2. Business Data List Connector innerhalb des Produktkataloges Der BDLC von „Layer2“ stellt eine effizientere Lösung als die von SP out‐of‐the‐box angebotene Integra‐ tion mittels externer Inhaltstyp dar. Die Implementierung Letztgenannter mittels „SP‐Designer“ ist sehr zeitaufwändig und größeres SP‐Know‐How ist notwendig. Die Integration mittels BDLC erfolgt an‐ hand üblicher SQL‐Statements. Das Rückschreiben in die SQL‐Tabellen ist ebenfalls möglich. Neben der in dieser Studie untersuchten OleDb‐Connection wird eine Vielzahl von möglichen weiteren Verbin‐ dungen angeboten (z. B. XML). Als wesentlicher Nachteil ist zu erwähnen, dass nicht alle Listentypen integrationsfähig sind. So können beispielsweise SP Blog‐ und Diskussionslisten nicht verbunden werden. Demzufolge ist somit ebenfalls eine redundante Datenpflege nötig. Ferner sollte die Verbindung stets bei Neuentwicklung einer Liste gepflegt werden, da der Konnektor bei Erst‐Update bereits getätigte Einträge überschreibt. Ein Rück‐ schreiben auf SQL‐Sichten oder Listen, welche auf mehrere SQL‐Tabellen referenzieren, ist nicht mög‐ lich. 51 6 Einsatzerfahrung und Bewertung der Vorgehensweise 6.4.3. Frontend‐Erfahrungen beim Gebrauch von SmartStore.NET Das Auffinden von Produkten inklusive erweiterter Suchkriterien findet eigenständig über die Shop‐ Oberfläche statt. Das Shop‐System entspricht dem aktuellen Stand der Technik. Durch die Ablage der Informationen in SQL‐Datenbanken kann eine barrierefreie Integration in alle relevanten Microsoft‐Systeme (z. B. „Excel“, „Access“, „SharePoint“) erfolgen. Funktionen für die Produktverwaltung, Migration von Kam‐ pagnen, strukturierte Kundenverwaltung und verschiedene Zahl‐ und Bestellverfahren werden berück‐ sichtigt. Das gebotene Suchcenter ist erweiterbar, mögliche Fehlertoleranzen werden jedoch nicht berücksich‐ tigt. Als Standardschnittstellen werden die Formate XML und „Excel“ angeboten. Ein Export/Import ist jedoch nur für wenige Listen vorgesehen. 52 7 Anregungen für die Weiterentwicklung 7. Anregungen für die Weiterentwicklung 7.1. Kontinuierlicher Abgleich der Produktstruktur Mit Hilfe der bestellten Waren können Rückschlüsse auf die Aktualität und Akzeptanz der ursprünglich ergänzenden Produkte geschlossen werden (z. B. Buch A „XML in der Praxis“ in Kategorie „XML“; Buch B „NoSQL Heute“ in Kategorie „SQL“ wird aktuell mehrfach zusammen gekauft). Es wird ersichtlich, dass die Produktstruktur nicht aktuell ist. Dienstleister und Kunde unterscheiden sich in Produktver‐ ständnis (ergänzende Produkte) einzelner Produkte. Ergo wird ein Änderungsszenario seitens PIM an‐ gestoßen. Das Marketing wird auf die Änderungsszenarien hingewiesen. Ergebnis ist ein Abgleich der Produktstruktur, die dem Kundenverständnis entspricht (vgl. Anhang C – UC 11). Abb. 7‐1: Anwendungsfall für den Abgleich der Produktstruktur 7.2. Pflege personalisierter Kundenprofile Ein Kundenprofil, welches über die Verwaltung der Stammdaten hinausgeht, ermöglicht eine persona‐ lisierte Akquise. Anhand des Profils können dem Kunden personalisierte Inhalte gezeigt werden. Das Kundenprofil wächst und wird präziser, je mehr Einkäufe getätigt werden. Ergebnis ist eine Ergänzung des Kundenprofils (Stammdaten), welches in Bezug auf möglicherweise kundenspezifisch interessante Artikel ergänzt wird sowie resultierend die Übernahme für die übergeordnete Kundengruppe. Die Vorteile eines Kundenprofiles gehen über die Personalisierung hinaus. Durch die persönlichen In‐ formationen (z. B. Alter, Beruf) können somit des Weiteren Marketingaktionen für Kundengruppen generiert werden (z. B. Rückschlüsse auf Verhalten bestimmter Altersgruppen) (vgl. Anhang C – UC 12). 53 7 Anregungen für die Weiterentwicklung Abb. 7‐2: Anwendungsfall für die Generierung personalisierter Kundenprofile 7.3. Verbesserung der Sucherfahrung Die Verwaltung des Suchcenters stellt eines der Kernelemente der Produktverwaltung in Bezug auf die verwirklichte Schlüsselwort‐Struktur dar. Moderne Suchverwaltung/Suchoptimierung gliedert sich in die sog. On‐ und Off‐Page‐Optimierung. Genauer wird u. a. die Fehlertoleranz für die Volltextsuche und die Auffindbarkeit von Artikeln anhand richtiger Schlagworte realisiert. Änderungsanstöße erfolgen direkt durch den Kunden aufgrund von Misserfolgen bei der Suche. Auslöser sind beispielsweise inkorrekte Wort‐Konstrukte bei der Eingabe in den Suchschlitz oder Schlagworte die nicht hinterlegt wurden. Ergebnis ist eine kontinuierliche Ver‐ besserung der Suchtoleranz und Abgleich des Kundenverständnisses in Bezug auf Schlagworte reali‐ siert durch einen Trigger‐Anstoß bei Misserfolg (vgl. Anhang C – UC 13). Abb. 7‐3: Aktivitätsdiagramm für Erweiterungsmöglichkeiten des Suchcenters Der Use Case wird aufgrund oben genannter Szenarien („Worst‐Case“) aufgerufen und folglich durch den Kunden initiiert. Die Änderungsanstöße durch den Kunden zum Produktdatenmanager stellen eine 54 7 Anregungen für die Weiterentwicklung kontinuierliche Verbesserung der Strukturierungsqualität dar. Wie oben geschildert wird von einer be‐ stehenden Struktur ausgegangen. 7.4. Rückschlüsse aus Blog‐ und Foreneinträgen Der Erhalt von Rückmeldungen aus Blog und Forum ist die Grundlage für eine kontinuierliche Verbes‐ serung innerhalb von Abteilungen. Der Blog und das Forum sind in Themengebiete unterteilt (z. B. Lieferung). Die erhaltenen Einträge sind anhand Titeln gelistet. Mögliche Titel könnten als Abteilungssensoren agieren, um Verbesserungsszenarien anzustoßen. Beispielsweise könnte der Kommentar anhand Schlagworten ausgelesen werden und so bei einschlägigen Werten an die jeweilige Abteilung weiter‐ geleitet werden. Das Use Case Diagramm ist nur marginal unterschiedlich zu UC 08, weshalb dieses nicht explizit aufgeführt wird. Spätestens ab der Verwirklichung von Verbesserungs‐Anstößen mittels intuitiver Workflows (z. B. Hin‐ weis per Mail an Verantwortlichen), liegt eine weitere Schnittstelle zu einem ERP‐System, bei dem Akteure, welche nicht oder nicht primär innerhalb der PIM‐Umgebung agieren, nahe. 55 8 Fazit 8. Fazit „Microsoft SharePoint Server 2013“ liefert gute, aber keinesfalls vollkommene Möglichkeiten der Integrationsfähigkeit externer Publikationskanäle. Die Datenintegration mittels untersuchter Funkti‐ onalität „Externer Inhaltstyp“ verbietet die Anbindung von Workflows an Listen oder die Modifika‐ tion Letztgenannter. Demnach entfällt eine Vielzahl der am Markt bewährten SharePoint‐Features im Bereich Business Intelligence (BI). Ferner ist bei der Erstimplementierung, im Hinblick auf Berechti‐ gung und Verknüpfung innerhalb des SharePoint Designers, ein nicht zu vernachlässigender Zeit‐ und Wissensaufwand von Nöten. Der „Business Data List Connector“ hingegen, der jedoch nicht ouf‐of‐the‐box integriert ist, berück‐ sichtigt neben der geforderten Datenintegration in SharePoint, zuvor genannte Features im BI‐Ge‐ biet. Die Erstimplementierung gestaltet sich für SQL‐Routiniers als zügig und selbsterklärend. Eine Unterstützung von Listen im Bereich der sozialmedialen Kommunikationsformen (z. B. Blog), die im Rahmen der Neuerungen von SharePoint 2013 beachtlich im Hinblick auf Struktur und Gestaltung modifiziert wurden, wird merklich vermisst. Das Shop‐System „SmartStore.NET“ stellt eine befriedigende Softwarelösung für kleine‐ und mittel‐ ständische Unternehmungen dar. Genannte Technologie verspricht dem Betreiber eine möglichst einfache Bedienoberfläche und hohen Erfüllungsgrad derzeit marktrelevanter Funktionalitäten. Letzt‐ genanntes bewirkt indes, dass die Anbindungsfähigkeit an weitere Informationsquellen (z. B. PIM) bedeutend gering ausgeprägt ist. Die unausweichliche Mehrung vorhandener Information und die damit verbundene steigende Anzahl möglicher Datenquellen führen zu neuen Herausforderungen in den Bereichen Datenablage und Suchoptimierung. Derzeit relevante, mehr und minder strukturierte Auszeichnungsmerkmale (Taxo‐ nomie, Folksonomie), liefern eine maßgebliche Grundlage für die auch inhaltliche Informationsge‐ winnung des angesprochenen Datenaufkommens. Aufgabe und Gelegenheit hieraus resultierend wird sein, eine noch engere und akutere Bindung zwischen Anwendern und Benutzern zu schaffen. 56 9 Literatur 9. Literatur About AIIM [WWW Document], n. a. AIIM The Global Community of Information Professionals. URL http://www.aiim.org/about (accessed 10.24.13). Angermann, H., 2013a. Web‐Shop‐Systeme 2013 in Deutschland. Hochschule der Medien Stuttgart, Stuttgart. Angermann, H., 2013b. Web‐Shop‐System smartstore.net. Hochschule der Medien Stuttgart, Stuttgart. Black, S., 2013. E‐Commerce‐Benchmark Report für Onlinehändler (Marktanalyse). Frankfurt am Main. Breidenbach, P., 2007. E‐Commerce bei Multi‐Channel‐Unternehmen, Geographie der Kommunika‐ tion. LIT Verlag, Berlin. Budde, L., Hampe, K., Puppe, M., Shahd, M., 2013. Trends im E‐Commerce ‐ Konsumverhalten beim Online‐Shopping (Studie). BITKOM, Berlin. Büttemeier, C., n. a. Der neue Produktkatalog von SharePoint 2013 [WWW Document]. Merentisblog. URL http://www.merentisblog.com/Seiten/SharePoint/Der‐neue‐Produktkatalog‐von‐Share‐ Point‐2013.aspx (accessed 11.7.13). Büttner, J., Erdag, C., Grasekamp, D., Greenhill, S., Kawollek, M., Kihn, T., Kaller, M., Quiring, A., Reinke, H., Schäfer, N., Schäfer, S., Schumacher, O., Schwarz, R., Straub, B., Unverhau, S., 2013. Share‐ Point 2013 für Anwender. Microsoft Press. Catrinescu, V., 2013. Microsoft Doubles SharePoint Advertising with new site [WWW Document]. Ab‐ solute SharePoint Blog. URL http://absolute‐sharepoint.com/2013/07/microsoft‐doubles‐ sharepoint‐advertising‐efforts‐and‐they‐do‐a‐good‐job‐2.html (accessed 11.9.13). Cockburn, A., 2003. Use Cases effektiv erstellen, [das Fundament für gute Software‐Entwicklung; Ge‐ schäftsprozesse mit Use Cases modellieren; die Regeln für Use Cases sicher beherrschen]. mitp‐Verl., Bonn. Erlhofer, S., 2011. Suchmaschinenoptimierung ‐ Das umfassende Handbuch. Galileo Computing, Bonn. Gäbeler, J., 2013. Möglichkeiten von Microsoft SharePoint 2013 als Produktinformationsmanagement‐ System. Gartner IT Glossary ‐ PIMS (production information management system) [WWW Document], n.d. IT Glossary. URL http://www.gartner.com/it‐glossary/pims‐production‐information‐manage‐ ment‐system (accessed 11.1.13). Heinemann, G., 2013. No‐Line‐Handel ‐ Höchste Evolutionsstufe im Multi‐Channeling. Springer Gabler, Wiesbaden. Heinemann, G., 2014. Der neue Online‐Handel ‐ Geschäftsmodelle und Kanalexzellenz im E‐Commerce, 5th ed. Springer Gabler, Wiesbaden. 57 9 Literatur Kecher, C., 2006. UML 2.0 Das umfassende Handbuch. Galileo Computing, Bonn. Larisch, D., 2013. Microsoft SharePoint 2013 ‐ Über 300 Lösungen für Anwender & Administratoren, über 300 Lösungen für Anwender & Administratoren. Hanser Verlag, München. Macdonald, E., Wilson, H., Konus, U., 2014. Modernes Marketing ‐ Neue Medien nutzen, Werbung richtig gestalten Harvard‐Business‐Manager: das Wissen der Besten, 70. Mcafee, A., Brynjolfsson, E., 2012. So beherrschen sie BIG DATA Harvard‐Business‐Manager: das Wis‐ sen der Besten, 96. Störrlse, H., 2005. UML 2 erfolgreich einsetzen. Addison‐Wesley, München. Straub, B., 2010. SharePoint 2010 – Taxonomie, Tagging, Metadaten, Bewertungen (I) « MindBusiness Tech‐Blog [WWW Document]. MindBusiness. URL http://blog.mindbusi‐ ness.de/blog/2010/08/06/sharepoint‐2010‐taxonomie‐tagging‐metadaten‐bewertungen‐i/ (accessed 1.24.14). TrendTopic ‐ E‐Commerce (Marktanalyse), 2011. . Axel Springer AG, Berlin. Vulkan, N., 2005. Elektronische Märkte, Strategien, Funktionsweisen und Erfolgsprinzipien. Mitp‐Verl., Bonn. What is Information Management? [WWW Document], n. a. AIIM The Global Community of Infor‐ mation Professionals. URL http://www.aiim.org/What‐is‐Information‐Management (accessed 11.1.13). Wirdemann, R., 2009. Scrum mit User Stories. Hanser, München. Wirtz, B., 2007. Handbuch Multi‐Channel‐Marketing. Gabler, Speyer. 58 Glossar Glossar BCS Verbindungsservice, welcher als Standard‐Schnittstelle zwischen SharePoint und externen Datenquellen dient. Implementierung findet mittels „SP‐Designer“ o‐ der innerhalb der Zentraladministration statt. BDLC Verbindungsservice, welcher als erweiternde Schnittstelle zwischen SharePoint und externen Datenquellen dient. Implementierung findet innerhalb der List‐ Settings statt. E‐Commerce Vertrieb von Produkten und Dienstleistungen über digitale Kanäle. Folksonomie Auszeichnungsverfahren um Objekte mittels Schlagworten zu klassifizieren. Die Objekte werden nicht über ein vorgeschriebenes Formular zugeteilt. Weitere Bezeichnungen: (Social)‐Tagging, Keywords, Schlüsselworte. OleDb Microsoft‐Programmierschnittstelle auf verschiede Datenressourcen, z. B. SQL‐ Datenbanken. PIM Informationsmanagementsystem, mit dessen Einsatz Produktinformationen zentral verwaltet werden können. SP‐Produktkatalog Veröffentlichungsfeature (ab Version 2013), welches erlaubt Inhalte mittels Lis‐ ten und Metadaten zu verwalten, um Artikeldetails zu verwalten und ggf. mit‐ tels Vorlagen (z. B. Publishingseite) zu publizieren. SQL Datenbanksprache in relationalen Datenbanken. Diese enthält u. a. die Katego‐ rie DML (Datenmanipulation), welche Lese‐, Änderungs‐, Einfüge und Löschbe‐ fehle definiert. 59 Glossar Taxonomie Auszeichnungsverfahren, um Objekte nach bestimmten Kriterien zu klassifizie‐ ren. Die Objekte werden vordefinierten Kategorien zugeteilt. Term‐Store Metadaten‐Funktion in Microsoft SharePoint (ab Version 2010). Bietet Unterstützung für die Umsetzung formaler Taxonomien. 60 Anhang A - Visual Basic Implementierung Anhang A ‐ Visual Basic Implementierung Ordnung der SQL‐ in die für CSVDE lesbare Struktur Abb. A‐1: Inhalte aus verschiedenen Quellen in Excel konsolidiert Abb. A‐2: Tabellenblatt zu Ordnung der CSV‐Struktur Abb. A‐3: Exportfähige Struktur per Excel‐Makro Erzeugtes CSV‐File Das erzeugte CSV‐File verwendet Semikolon statt Komma als Trennzeichen sowie drei Anführungszei‐ chen vor und nach dem distinguishedName‐String statt einem. Diese Änderungen sind noch nicht be‐ rücksichtigt und müssen vor dem CSVDE‐Import manuell mittels Editor ersetzt werden. Abb. A‐4: Exemplarischer CSV‐Export (fehlerhaft) 61 Anhang B - SQL-Integration und Listenerzeugung Anhang B ‐ SQL‐Integration und Listenerzeugung Entwicklung von SQL‐Sichten Hinweis: Die Transformation der Tabellen/Sichten in Normalformen ist nicht Teil dieser Studie. Bestellung von Produkten SELECT dbo.[Order].Id, dbo.[Order].CustomerId, dbo.OrderProductVariant.OrderId, dbo.Customer.Email, dbo.ProductVariant.ProductId, dbo.Product.Name FROM dbo.Customer INNER JOIN dbo.[Order] ON dbo.Customer.Id = dbo.[Order].CustomerId INNER JOIN dbo.OrderProductVariant ON dbo.[Order].Id = dbo.OrderProductVariant.OrderId INNER JOIN dbo.ProductVariant ON dbo.OrderProductVariant.ProductVariantId = dbo.ProductVariant.Id INNER JOIN dbo.Product ON dbo.ProductVariant.ProductId = dbo.Product.Id Kundenstammdaten SELECT dbo.Address.FirstName, MIN(DISTINCT dbo.Address.LastName) AS Expr1, dbo.Address.Email, dbo.Address.Company, dbo.Country.Name, dbo.StateProvince.Name AS Land, dbo.Address.Address1 AS Straße, dbo.Address.ZipPostalCode, dbo.Address.Id FROM dbo.Address INNER JOIN dbo.Country ON dbo.Address.CountryId = dbo.Country.Id INNER JOIN dbo.StateProvince ON dbo.Address.StateProvinceId = dbo.StateProvince.Id AND dbo.Country.Id = dbo.StateProvince.CountryId GROUP BY dbo.Address.Id, dbo.StateProvince.Id, dbo.Country.Id, dbo.Address.FirstName, dbo.Address.Email, dbo.Address.Company, dbo.Country.Name, dbo.StateProvince.Name, dbo.Address.Address1, dbo.Address.ZipPostalCode 62 Anhang B - SQL-Integration und Listenerzeugung Produkt Kategorie Mapping SELECT dbo.Category.Id AS Kategoriename, dbo.Category.Name, dbo.Product_Category_Mapping.Catego‐ ryId, dbo.Product.Name AS Produktname, dbo.Product_Category_Mapping.ProductId FROM dbo.Product_Category_Mapping INNER JOIN dbo.Category ON dbo.Product_Category_Mapping.CategoryId = dbo.Category.Id INNER JOIN dbo.Product ON dbo.Product_Category_Mapping.ProductId = dbo.Product.Id Produkt Tag Mapping SELECT dbo.Product_ProductTag_Mapping.Product_Id, dbo.Product_ProductTag_Mapping.ProductTag_Id, dbo.ProductTag.Name, dbo.ProductTag.Id, dbo.Product.Name AS Expr2 FROM dbo.Product_ProductTag_Mapping INNER JOIN dbo.ProductTag ON dbo.Product_ProductTag_Mapping.ProductTag_Id = dbo.ProductTag.Id INNER JOIN dbo.Product ON dbo.Product_ProductTag_Mapping.Product_Id = dbo.Product.Id Bestellstatus SELECT dbo.[Order].Id, dbo.[Order].OrderNumber, dbo.[Order].CustomerId, dbo.[Order].OrderStatusId, dbo.OrderNote.Note, dbo.Customer.Username, dbo.OrderProductVariant.Id AS UserID, dbo.OrderProductVariant.OrderId, dbo.OrderProductVari‐ ant.ProductVariantId, dbo.Product.Name FROM dbo.[Order] INNER JOIN dbo.OrderNote ON dbo.[Order].Id = dbo.OrderNote.OrderId INNER JOIN dbo.Customer ON dbo.[Order].CustomerId = dbo.Customer.Id INNER JOIN dbo.OrderProductVariant ON dbo.[Order].Id = dbo.OrderProductVariant.OrderId INNER JOIN dbo.Product ON dbo.[Order].Id = dbo.Product.Id Lagerverwaltung SELECT dbo.ProductVariant.ProductId, dbo.Product.ShortDescription, dbo.ProductVariant.StockQuantity FROM dbo.ProductVariant INNER JOIN dbo.Product ON dbo.ProductVariant.ProductId = dbo.Product.IdGROUP BY dbo.Address.Id, dbo.StateProvince.Id, dbo.Country.Id, dbo.Address.FirstName, dbo.Address.Email, dbo.Ad‐ dress.Company, dbo.Country.Name, 63 Anhang B - SQL-Integration und Listenerzeugung dbo.StateProvince.Name, dbo.Address.Address1, dbo.Address.ZipPostalCode Discount auswerten SELECT dbo.Discount.Name, dbo.[Order].CustomerId, dbo.Customer.Username FROM dbo.DiscountUsageHistory INNER JOIN dbo.Discount ON dbo.DiscountUsageHistory.DiscountId = dbo.Discount.Id INNER JOIN dbo.[Order] ON dbo.DiscountUsageHistory.OrderId = dbo.[Order].Id INNER JOIN dbo.Customer ON dbo.[Order].CustomerId = dbo.Customer.Id Blog Mapping SELECT dbo.BlogPost.Title, dbo.BlogComment.CommentText, dbo.BlogComment.Id FROM dbo.BlogPost INNER JOIN dbo.BlogComment ON dbo.BlogPost.Id = dbo.BlogComment.BlogPostId Produktbewertungen SELECT dbo.ProductReview.ProductId, dbo.ProductReview.Title, dbo.ProductReview.ReviewText, dbo.Produc‐ tReview.Rating, dbo.Product.Name FROM dbo.Product INNER JOIN dbo.ProductReview ON dbo.Product.Id = dbo.ProductReview.ProductId OleDB Connection‐String Server=141.62.68.159; Database=WebShopping; Provider=SQLOLEDB; Integrated Security=SSPI; pro‐ viderName=System.Data.SqlClient; User ID=BAHA\Administrator; Password=Ke2wbG23; SQL‐Queries innerhalb BDLC für die Erzeugung von SP‐Listen Kundenstammdaten: Select * From Kundenstammdaten 64 Anhang B - SQL-Integration und Listenerzeugung Abb. B‐1: Liste für Kundenstammdaten Bewertung von Produkten Ratinganalyse: Select Id, Name, ApprovedRatingSum, ApprovedTotalReviews From Product Where ApprovedTotalRe‐ views is not NULL Abb. B‐2: Liste für Bewertungsranking Bewertung von Produkten Sichten: Select * From ReviewIDMapping Abb. B‐3: Liste für Bewertungen mit Artikelverweis 65 Anhang B - SQL-Integration und Listenerzeugung Migration von Blogeinträgen Select * From BlogPost Abb. B‐4: Liste für die Realisierung von Blogthemen Produktverwaltung Select * From Product Abb. B‐5: Liste für die Migration von Produkten Taxonomie‐Verwaltung (Kategorien): Select * From Category Abb. B‐6: Liste für die Migration von Kategorien 66 Anhang B - SQL-Integration und Listenerzeugung Taxonomie‐Verwaltung (Hersteller): Select * From Manufacturer Abb. B‐7: Liste für die Migration von Herstellern Mapping der Produkte zu Kategorien: Select * From Product_Category_Mapping Abb. B‐8: Liste für die Migration der Klassifikationszuweisung Migration von Schlagworten: Select * From ProductTag 67 Anhang B - SQL-Integration und Listenerzeugung Abb. B‐9: Liste für die Migration von Schlagworten Mapping von Schlagworten zu Produkten Select * From Product_ProductTag_Mapping Abb. B‐10: Liste für die Zuweisung von Schlagworten Verwaltung der Bestellstatus: Select * From BestellungStatus 68 Anhang B - SQL-Integration und Listenerzeugung Abb. B‐11: Liste für die Übersicht der aktuellen Bestellungen Lagerverwaltung: SELECT TOP 1000 [ProductId], [ShortDescription], [StockQuantity] FROM [WebShopping].[dbo].[Lagerverwaltung] Abb. B‐12: Liste für die Pflege der Lagerverwaltung Discounts auswerten: SELECT TOP 1000 [Name] ,[CustomerId] ,[Username] FROM [WebShopping].[dbo].[DiscountAuswerten] Abb. B‐13: Liste für die Analyse getätigter Kampagnen 69 Anhang B - SQL-Integration und Listenerzeugung Übersicht der verfügbaren Datenbank‐Tabellen Prefix dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo Name AclRecord ActivityLog ActivityLogType Address Affiliate BackInStockSubscription BlogComment BlogPost Campaign Category CategoryTemplate CheckoutAttribute CheckoutAttributeValue Country CrossSellProduct Currency Customer Customer CustomerRole Mapping CustomerAddresses CustomerContent CustomerRole DeliveryTime Discount Discount AppliedToCategories Discount AppliedToProductVariants DiscountRequirement DiscountUsageHistory Download EmailAccount ExternalAuthenticationRecord Forums Forum Forums Group Forums Post Forums PrivateMessage Forums Subscription Forums Topic GenericAttribute GiftCard GiftCardUsageHistory GoogleProduct Language LocaleStringResource LocalizedProperty Log Manufacturer ManufacturerTemplate MeasureDimension MeasureWeight MessageTemplate News dbo NewsComment Prefix dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo dbo Name NewsLetterSubscription Order OrderNote OrderProductVariant PermissionRecord PermissionRecord Role Mapping Picture Poll PollAnswer PollVotingRecord Product Product Category Mapping Product Manufacturer Mapping Product Picture Mapping Product ProductTag Mapping Product SpecificationAttribute Mapping ProductAttribute ProductReview ProductReviewHelpfulness ProductTag ProductTemplate ProductVariant ProductVariant ProductAttribute Mapping ProductVariantAttributeCombination ProductVariantAttributeValue QueuedEmail RecurringPayment RecurringPaymentHistory RelatedProduct ReturnRequest RewardPointsHistory ScheduleTask Setting Shipment Shipment OrderProductVariant ShippingByTotal ShippingByWeight ShippingMethod ShippingMethodRestrictions ShoppingCartItem SpecificationAttribute SpecificationAttributeOption StateProvince Store StoreMapping TaxCategory TaxRate ThemeVariable TierPrice Topic UrlRecord Tab. B‐1: Übersicht der SQL‐Datenbank 70 Anhang C - Use Case Schablonen Anhang C ‐ Use Case Schablonen Legende Aktion‐Art Single Parallel Entscheidung Entscheidung Ablauf Standard Standard Standard Alternativ Struktur (Beispiel) 1 2a 3 3 Inhalt und Beispiel Text Text 2b Bedingung Text Bedingung Text Text Entwurfsraster (Beginnend ab Seite 72) 71 Anhang C - Use Case Schablonen UC 01 Beschreibung Primärer Akteur Beteiligte Akteure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingungen Standardablauf Alternative Ablauf‐ schritte Hinweise Weitere Systeme Status Use Case „Produkte finden“ Das Auffinden von Produkten beschreibt die Barriere zwischen digitalem Betreten der Webseite und dem möglichem Bestellimpuls. Genannte Barriere wird i. d. R. mittels einer Volltextsuche, die üblicherweise erweiterbar ist (Metadaten‐Filter) oder das Na‐ vigieren anhand Steuerelementen/Überschriften durch den Besucher/Kunden über‐ wunden. Interessent, Neukunde, Stammkunde Shop‐System (Frontend) keine Der Kunde besucht die Web‐Shop‐Präsenz und navigiert zum Suchcenter/‐schlitz. Anonymer Seitenzugriff; a) Produkte werden anhand von Off‐ und Onpage‐SEO gefunden b) Taxonomie und Folksonomie entsprechen der Kundeninterpretation Start 1 Betreten der Webseite 2 Erwägen eines Suchwunsches 3 Suchcen‐ Eingabe der Suche in den Suchschlitz ter 4 Positiv Erhalt Ergebnisliste und die funktionelle Wahl zur erweiterten Suche 5 Erweitert Betätigung erweiterter Suchfilter 6 Erhalt einer gefilterten Ergebnisliste Ende 3 Else Kunde wählt Produkte anhand globaler/lokaler Navigationsleiste Alternatives Ende 4 Else Erhalt einer Ergebnisliste ohne Inhalt 5 Produktdatenmanager erhält Information über die erfolglose Suche [Aufgrund fehlender Fehlertoleranz oder falscher Schlagworte] Alternatives Ende (Aufruf UC 13 „Suchcenter verwalten“) 5 Else Alternatives Ende Unter einer erweiterten Suche wird üblicherweise jene Volltextsuche verstanden, die anhand verschiedener Filter, welche anhand Metadaten realisiert werden, z. B. Wa‐ rengruppe, Preis, Farbe, Hersteller, eingegrenzt werden kann. Der Sucherfolg wird durch dem Artikel beigefügten Schlagworte (engl. Keywords) beeinflusst. Bei einer er‐ folglosen Suche können zwei Gründe vorliegen: Fehlende Buchstaben oder falsche Buchstaben bei der Worteingabe sowie nicht korrekt hinterlegte Schlagworte. Keine Behandelt 72 Anhang C - Use Case Schablonen UC 02 Beschreibung Primärer Akteur Beteiligte Akteure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingungen Standardablauf Alternative Ablaufschritte Hinweise Weitere Systeme Status Use Case „Produkte bestellen“ Die Produktbestellung stellt den erfolgreichen Übergang zwischen Produktsuche und Kaufabwicklung dar und wird i. d. R. als Warenkorb‐/Wunschliste/Merkliste‐Transfer bezeichnet. Bis zur finalen Einleitung des Abwicklungsprozesses findet eine dauer‐ hafte Präsenz der Produktfindung, zum Ziel dem Kunden Artikel zu suggerieren, statt. Für den Dienstleister können aufgrund von Kundendaten, die aus Stammdaten (An‐ schrift, Alter, Kontaktdaten) und Informationen über dessen Kaufverhalten bestehen, Rückschlüsse für weitere Marketingmaßnahmen geschlossen werden. Neukunde, Stammkunde Shop‐System (Frontend) UC 01 „Produkte finden“ Der Kunde entscheidet sich für die Bestellung von einem oder mehreren Artikeln. Findung von Produkten und Interessensverweis (Warenkorb); Authentifizierter Seitenzugriff; a) Produktbestellung wurde erfolgreich getätigt b) Kundenstammdaten wurden migriert Start 1 Kunde wählt Produkt an 2 Transfer des Produktes in Warenkorb 3 Kunde „geht“ zur Kasse 4 Neu Verweis auf Registrierungsseite 5a Eingabe Stammdaten 6 Eingabe optionale Rechnungsanschrift 7 Bestätigung des Kaufvorgangs Ende 4 Else Einwahl mittels Kundenprofil 5 Stammdaten werden aus Kundenstammdatensystem importiert Alternatives Ende Der manuelle Transfer erfolgt anhand der Zwischenspeicherung in einem Tabellenkal‐ kulationsprogramm (Staging‐Umgebung), welche vor dem Export (CSV‐Export) mittels eines VB‐Skript in eine lesbare Ordnung gebracht werden. Abschließend CSV‐Import mittels Power‐Shell‐Skript. Die entstehenden Kundenstammdaten werden sowohl direkt im Shop‐Backend aber auch im Kundenverwaltungstool gespeichert (Informationsintegration). Hintergrund ist die später mögliche Anbindung an weitere Informationsmanagementsysteme (z. B CRM, ERP). Das Szenario endet nach Eingabe der Anschrift. Die Kaufabwicklung wird rein über den Shop gesteuert und somit nicht Bestandteil des Integrations‐Konzeptes. Theore‐ tisch wäre eine nicht endliche Wiederholung des Produktauswahlprozesses vorstell‐ bar, ist jedoch für das Konzept inkl. Demonstrator nicht von Bedeutung. CRM (SQL/AD‐Source) Behandelt 73 Anhang C - Use Case Schablonen UC 03 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Produkte bewerten“ Die Produktbewertung erfolgt für einen spezifischen Artikel. Die Bewertungen werden alleinig durch Kunden anhand Text und Ranking (0‐5) generiert. Aufgrund getätigter Kundenbewertungen können sich potentielle Interessenten somit direkt bei Konsumen‐ ten über die Produktgüte informieren. Neukunde, Stammkunde Shop‐System (Frontend) UC 01 „Produkte finden“ UC 02 „Produkte bestellen“ Der Kunde möchte seine Erfahrung für einzelne Produkte mit anderen Kunden teilen. Existenz eines Bewertungsportales; a) Kunde hat Produkt textuell bewertet b) Kunde hat Produkt anhand eines Rankings bewertet Start 1 Kunde wählt die Produktbewertung für einen Artikel aus 2 Kunde gibt seine textuelle Produktbewertung und ein Ranking ab 3a Kunde speichert seine Bewertung 3b PIM‐System erhält Bewertungsmerk‐ male 4 Gut Ende Ende 4 Else Anstoß Workflow „Artikel ändern“ Alternatives Ende (Aufruf UC 08 „Artikelspezifische Änderungen durchführen“) Die Produktbewertung kann für alle erhaltenen Produkte erfolgen, erfolgt aber für je‐ den analog, deshalb nur einmalig beschrieben. CRM (SQL‐Source) Behandelt 74 Anhang C - Use Case Schablonen UC 04 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Weitere soziale Aktivitäten“ Unter weiteren sozialen Aktivitäten ist neben dem Bewertungsportal ein Blog und Fo‐ rum zu verstehen, in deren sich Kunden untereinander oder aber auch mit dem Shop‐ Betreiber austauschen können. Die Blog‐/Foreneinträge sind in einzelne Themenge‐ biete (Lieferung, Rabatt‐Coupon, etc.) unterteilt. Diese erfolgen demnach artikelunspe‐ zifisch und können Rückschluss auf die Qualität einzelner Abteilungsbereiche (z. B. Ver‐ sandabteilung) und die Wirksamkeit von Promo‐Aktionen liefern. Neukunde; Stammkunde Shop‐System (Frontend) keine Der Kunde möchte seine Erfahrung über den Dienstleister diskutieren. Existenz eines Blogs/Forums mit vordefinierten Themenbereichen. a) Soziale Kommunikation wurde durch den Kunden betrieben b) Produktmanager erhält die Ergebnisliste Start 1 2 3a 4 4 Ende keine Kunde begibt sich in eines der Themenbereiche Kunde pflegt seine Beschreibung ein Kunde speichert seinen Eintrag 3b PIM‐System erhält Eintrag Eintrag wird anhand Schlagworten ausgelesen Gut Ende Das verwendete Web‐Shop‐System bietet beide Technologien: Blog und Forum. Diese können beide in verschiedene Themenbereiche, durch den Administrator generiert werden. Funktion und Rückschlüsse für die Unternehmung sind bei beiden identisch. Die Aktionen für den Kunden sind marginal unterschiedlich, weshalb beide wie oben ge‐ schildert, anhand eines Use Cases beschrieben werden. CRM (SQL‐Source) Behandelt 75 Anhang C - Use Case Schablonen UC 05 UC 05.1 UC 05.2 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Produkte verwalten“ Use Case „Produktdaten verwalten“ Use Case „Produktstruktur verwalten“ Unter „Produkte verwalten“ ist neben der rein textuellen Pflege von Produktinforma‐ tion die Verwaltung der verwirklichten Metadaten‐, genauer Taxonomie und Schlüs‐ selwort‐Struktur (Folksonomie) zu verstehen. Letztgenannte stellen das Kernelement der Produktverwaltung dar, da folglich die Meta‐Hierarchie, Taxonomie‐Konzept und Attribut‐Pflege verwirklicht wird. Es erfolgt die Pflege neuer Produkte, aber auch die Inline‐Bearbeitung bestehender. Produktdatenmanager; PIM‐System; keine Es liegen neue Produkte vor und/oder Bestehende müssen geändert werden. PIM‐Zugriff mit entsprechender Rollendefinition; a) Produkte werden textuell gepflegt b) Produkte werden anhand Folsonomie und Taxonomie gepflegt Start 1 Produktdatenmanager erwägt Migration von Produkten 2 Produktdatenmanager wählt sich in Produktkatalog ein 3 Neue Neues Element wird geöffnet („Create New Item“) 4 Produkt wird anhand Beschreibung und textueller Attribute gepflegt 5 Alt Taxonomie‐Verwaltung wird aufgerufen und für Produkt gepflegt 6 Alt Folksonomie‐Verwaltung wird aufgerufen und für Produkt gepflegt Ende 3 Else Bestehendes Element wird geöffnet („Edit Item“) 5 Else Migration neues Taxonomie‐Element und Produktverweis 6 Else Migration neues Schlagwort und Produktverweis Neben dem beschriebenen Szenario ist eine weitere Detailierung zwischen textueller und designspezifischem Produktdatenmanagement möglich, z. B. Redakteur und De‐ signer. In diesem Konzept wird deren Unterschied jedoch nicht tiefgründiger betrach‐ tet (vgl. Abschnitt 5.5.3). Keine Behandelt 76 Anhang C - Use Case Schablonen UC 06 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Produktdaten genehmigen“ Bei der Veröffentlichung von Produktdaten werden die Produktinformationen, beru‐ hend auf verschiedenen Datenformaten (Texte, Bilder, Hierarchie, Warengruppe) für das Web‐Shop‐Frontend freigeschaltet (publiziert). Voraussetzung ist die Genehmi‐ gung, abgehandelt mittels eines Workflows durch den direkten Vorgesetzten. Abteilungsleiter PIM‐System; Produktdatenmanager keine Neue Produkte wurden gepflegt und/oder Bestehende geändert. PIM‐Zugriff mit entsprechender Rollendefinition; Implementierung eines Genehmigungs‐Workflows mit entsprechendem Formular; a) Produkte werden veröffentlicht oder b) Produkte werden abgelehnt Start 1 Workflow‐Anstoß durch Produktmanager 2 Weiterleitung des Workflow‐Formulars an Abteilungsleiter 3 Ap‐ Produkt wird für den Web‐Shop freigeschaltet („Approved“) pro‐ ved 4 Produkt erhält Spalten‐Attribut „Approved“ Ende 3 Else Produkt wird abgelehnt 4 Produkt erhält Spalten‐Attribut „Reject“ (Abgelehnt) Ende Der Genehmigungsprozess innerhalb der Produktmanager‐Abteilung kann über beide Organigrammstufen hinweg initiiert (Sperrung durch Abteilungsleiter, Anstoß durch Produktmanager), jedoch nur von der obersten Stufe genehmigt werden (Abteilungs‐ leiter). Ferner können neben den beiden Status Kommentare im Formular hinterlegt werden. keine Behandelt 77 Anhang C - Use Case Schablonen UC 07 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Design verwalten“ Die Designverwaltung enthält viele wesentlichen Variablen im Frontend‐Umfeld, um bei einem möglichen Käufer die Dauer des Verweilens im E‐Shop positiv zu beeinflus‐ sen. Designer PIM‐System; keine Bedarf eines neuen Designs, z. B. Corporate Design. PIM‐Zugriff mit entsprechender Rollendefinition; a) Neues Stylesheet wurde gepflegt b) Stylesheet wird in die Shop‐Umgebung eingebunden Start 1 Designer erhält Anweisung 2 Designer wählt sich in die Designverwaltung ein 3 Editierung relevanter Attribute Ende keine Der geschilderte Standardablauf berücksichtigt keinen Freigabeprozess. keine Behandelt 78 Anhang C - Use Case Schablonen UC 08 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Artikelspezifische Änderungen durchführen“ Der Erhalt von Rückmeldungen aus Kundenbewertungen ist die Grundlage für eine kon‐ tinuierliche Verbesserung (KVP) der Artikelgüte und Absatzchance. Änderungsszenarien können sein: Artikelbeschreibung oder Fertigungsdetails. Beispielszenario: ‐ Fünf schlechte Bewertungen erfordern Änderungen an Artikel Marketingverantwortlicher PIM‐System UC 03 „Produkte bewerten“ Artikel erhält des Öfteren negative Bewertungen. Bewertungen werden in PIM‐System zu den Artikeln gespeichert. PIM‐Zugriff mit entsprechender Rollendefinition; a) Anstoß die angesprochenen Artikel nachhaltig zu verbessern b) Steigerung der Absatzchance oder Sperrung von Ladenhütern Start 1 PIM‐System informiert Marketingverantwortlichen 2 Entscheidung Änderung (neue Version) oder Sperrung 3 Änderung Auslösung von Arbeitsanweisungen (z. B. an Redakteur) 4 Anstoß Änderungsszenario 5 Änderungsdetails in PIM migriert (neue Artikelversion) 6 Produkt veröffentlicht Alte Version gesperrt Ende 3 Else Sperrung des Artikels Ende Keine keine Behandelt 79 Anhang C - Use Case Schablonen UC 09 UC 09.1 UC 09.2 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Kampagnen steuern” Use Case “Discounts realisieren” Use Case “Discounts auswerten” Der Anstoß von Kampagnen wird genutzt, um die Absatzchancen zu steigern. Eine mög‐ liche Kampagne ist die Migration eines Discounts, bei dem ausgewählte Kunden einen Code erhalten, z. B. via E‐Mail oder Facebook innerhalb eines Newsletters. Dieser kann dann bei einer Bestellung hinterlegt werden und führt zu unmittelbarem Preisnachlass. Berücksichtigt werden sollte einen Mindestbestellwert hinterlegen zu können. Um eine Aussagekraft über getätigte Kampagnen (z. B. Discounts) zu erhalten, sollte z. B. die quantitative Verwendung einer Discountaktion in einem definierten Zeitraum be‐ trachtet werden. Marketingverantwortlicher PIM‐System keine Absatzschwächen Discountvariable ist in Bestellprozess integriert. PIM‐Zugriff mit entsprechender Rollendefinition; a) Discounts werden anhand Zeitraum und Codewort sowie Wert migriert b) Discounts werden anhand Verwendung durch Kunden analysiert Start 1 Marketingverantwortlicher sichtet Absatz 2 Entscheid und Migration neuer Discount 3 Hinterlegung von Attributen (Wert, Gültigkeitszeitraum, Mindestbestellwert) Ende keine Keine keine Behandelt 80 Anhang C - Use Case Schablonen UC 10 UC 10.1 UC 10.2 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Lieferungen verwalten“ Use Case „Lager verwalten“ Use Case „Bestellung verwalten“ Unter „Bestellung verwalten“ ist die Auflistung der getätigten Kunden‐Bestellungen zu verstehen. Ergo resultiert folglich die finale Auslieferung der Produkte. Diese beinhal‐ tet demzufolge die Bestellnummer, Adresse des Kunden, Produktname sowie Bestell‐ menge verschiedener Produkte. Von signifikanter Bedeutung ist deshalb, parallel zum Bestellvorgang, die Sicherung der Kundenstammdaten. Produktionsverantwortlicher PIM‐System; UC 02 „Produkte bestellen“ Kunden bestellen Produkte PIM‐Zugriff mit entsprechender Rollendefinition; a) Bestellungen werden gelistet verwaltet b) Status des Liefervorgangs entspricht dem aktuellem Vorgang Start 1 2 3 4 Ende keine Anstoß durch automatisiert generiertes Listenelement Bearbeitung der Bestellung Berücksichtigen des Bestell‐ bzw. Lieferstatus Pflege des Bestellstatus in Liste Die Lagerverwaltung wird nur rudimentär berücksichtigt (prinzipielle Machbarkeit), da diese überwiegend direkt in einem ERP‐System stattfindet. Die Kundenstammdaten könnten ebenso in einem CPM‐System verwaltet werden. Keine Behandelt 81 Anhang C - Use Case Schablonen UC 11 Beschreibung Use Case „Produktstruktur abgleichen“ Jedem Produkt werden ergänzende Produkte angezeigt (z. B. Buch A „XML in der Praxis; Buch B „XML Einstieg“). Mit Hilfe der bestellten Waren können Rück‐ schlüsse auf die Aktualität und Akzeptanz der ursprünglich ergänzenden Produkte geschlossen werden (z. B. Buch A „XML in der Praxis; Buch B „XML Heute“ wird mehrfach zusammen gekauft). Es wird ersichtlich, dass die Produktstruktur nicht aktuell ist. Infolgedessen wird ein Änderungsszenario seitens PIM angestoßen. Das Marketing wird auf die Änderungsszenarien hingewiesen. Produktdatenmanager PIM‐System; Kunde (Vorläufer) UC 02 „Produkte bestellen“ Primärer Akteur Beteiligte Akteure Beinhaltende Use Cases Auslöser Vorbedingungen Ergänzte Produkte entsprechen nicht dem Kundenverständnis Es wurden Waren bestellt; Dienstleister und Kunde unterscheiden sich in Produkt‐ verständnis (ergänzende Produkte) einzelner Produkte; a) Ergänzende Produkte wurden dem Kundenverständnis angeglichen b) Übernahme auch für Produkte ähnlicher Schlagwort‐Auszeichnung Start 1 Definierte Obergrenze ist erreicht (Not‐Fitting Products) 2 Produktdatenmanager wird mittels Workflow auf Problematik hingewiesen 3 Auswertung referenzierender Produkte 3a Manuelles Änderungsszenario 4 Freigabe und Benachrichtigung an Abteilungsleiter 4 Veröffentlichung Ende keine Ergebnis/ Nachbedingungen Standardablauf Alternative Ablauf‐ schritte Hinweise Weitere Systeme Status Vorerst keine Keine Ausstehend 82 Anhang C - Use Case Schablonen UC 12 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Datenfluss Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Kundenprofil generieren“ (aufgrund Kundenstammdaten) Ein Kundenprofil, welches über die Verwaltung der Stammdaten hinausgeht, ermöglicht eine personalisierte Akquise. Anhand des Profils können dem Kunden personalisierte Inhalte gezeigt werden. Das Kundenprofil wächst und wird präziser, je mehr Einkäufe getätigt werden. PIM‐System Shop‐System; UC 02 „Produkte bestellen“ SEQUENZDIAGRAMM Der Kunde hat Produkte bestellt. Verwaltung der Kundenbestellungen im Shop inkl. Persönlicher Informationen a) Das Kundenprofil wird in Bezug auf möglicherweise interessante Artikel er‐ gänzt b) Prüfung für Kunden innerhalb der identischen Kundengruppe Start 1 Erhalt Information aufgrund bestellter Waren 2 Kundenprofil erhält Schlagworte anhand Artikel 3 Schlagworte werden den Kundengruppen zugeordnet Ende keine Die Vorteile eines Kundenprofiles gehen über die Personalisierung hinaus. Durch die persönlichen Informationen (z. B. Alter, Beruf) können somit des Weiteren Marketing‐ aktionen für Kundengruppen generiert werden (z. B. Rückschlüsse auf Verhalten be‐ stimmter Altersgruppen) Mögliche Anbindung an ein CRM‐System Ausstehend 83 Anhang C - Use Case Schablonen UC 13 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Suchcenter verwalten“ Die Verwaltung des Suchcenters stellt eines der Kernelemente der Produktverwaltung in Bezug auf die verwirklichte Schlüsselwort‐Struktur dar. Moderne Suchverwal‐ tung/Suchoptimierung gliedert sich in die sog. On‐ und Off‐Page‐Optimierung. Genauer wird u. a. die Fehlertoleranz für die Volltextsuche und die Auffindbarkeit von Artikeln anhand richtiger Schlagworte realisiert. Änderungsanstöße erfolgen direkt durch den Kunden aufgrund von Misserfolgen bei der Suche. Auslöser sind beispiels‐ weise inkorrekte Wort‐Konstrukte bei der Eingabe in den Suchschlitz oder Schlagworte, die nicht hinterlegt wurden. Produktdatenmanager Shop‐System; PIM‐System; UC 01 „Produkte finden“ Der Produktdatenmanager erhält Information über eine erfolglose Produktsuche des Kunden. Existenz einer Metadaten‐ und Attribute‐Struktur; a) Kontinuierliche Verbesserung der Suchtoleranz b) Kontinuierliche Verbesserung der Schlagwortstruktur des Kundenverständnis‐ ses Start 1 Erhalt von Information aufgrund negativer Suche 2 Konzeptentwicklung für neue Schlagwort‐Struktur, Texte und Slug 3 Konzepthinterlegung der Strategien im PIM‐System 4 Änderungsrelevante Artikel mittels Workflow abgeglichen 5 Finale Kontrolle im Web‐Shop‐System 6 Gut Veröffentlichung neuer Struktur Ende 6 Else Zurück zu 2 Der Use Case wird aufgrund oben genannter Szenarien (Worst‐Case) aufgerufen und folglich durch den Kunden initiiert. Die Änderungsanstöße durch den Kunden zum Pro‐ duktdatenmanager stellen eine kontinuierliche Verbesserung der Strukturierungsquali‐ tät dar. Wie oben geschildert wird von einer bestehenden Struktur ausgegangen. Keine Ausstehend 84 Anhang C - Use Case Schablonen UC 14 Beschreibung Primärer Akteur Beteiligte Ak‐ teure Beinhaltende Use Cases Auslöser Vorbedingungen Ergebnis/ Nachbedingun‐ gen Standardablauf Alternative Ab‐ laufschritte Hinweise Weitere Systeme Status Use Case „Abteilungsspezifische Änderungen“ Der Erhalt von Rückmeldungen aus Blog und Forum ist die Grundlage für eine kontinu‐ ierliche Verbesserung innerhalb von Abteilungen. Der Blog und das Forum sind in The‐ mengebiete unterteilt (z. B. Lieferung). Beispielszenarien: ‐ Thema: Lieferung; Eintrag: Lieferung nicht gut; Anstoß Änderungsszenario Infolgedessen KVP z. B. Verbesserung der Liefergüte (indirekte Wertschöpfungskette). Marketingverantwortlicher PIM‐System UC 04 „Weitere soziale Aktivitäten“ Themengebiet erhält des Öfteren negative Bewertungen. Bewertungen werden in PIM‐System zu den Artikeln gespeichert. a) Verbesserung nicht artikelspezifischer Details (z. B. Umverpackung) b) Ursächlichkeit von Verbesserungspotential innerhalb verschiedenster Abtei‐ lungen Start 1 PIM‐System informiert spezifizierte Abteilung (Anhand Themengebiet) 3 Entscheidung Änderungsszenarien 4 Änderung Auslösung von Änderungsanweisungen 5 Anstoß Änderungsszenario 6 Blog‐/Foreneintrag des Administrators (Veröffentlichung Verbesserung) Ende 4 Else Ignorieren von Beschwerden (z. B. baldige Auslagerung der Abtei‐ lung) Ende Eine automatisierte Auslesung wird noch nicht berücksichtigt! Die Sichtung von Einträ‐ gen erfolgt anfänglich manuell! Mögliche Anbindung an ein ERP‐System Ausstehend 85 Anhang D - Power-Shell Skript Anhang D ‐ Power‐Shell Skript Benötigte CSV‐Struktur objectClass,sAMAccountName,dn user,Petergr," CN=Peter Gross,CN=Users,DC=baha,DC=local" PowerShell Skript für AD‐Import mittels CSV‐Datei csvde ‐i ‐f Pfad PowerShell Skript Beispiel csvde ‐i ‐f C:\Users\Administrator\Desktop\456.csv Demonstration erfolgreicher AD‐Import: Abb. D‐1: Exemplarischer PowerShell‐Import 86 Anhang E - Tabellarischer Vergleich verschiedener Technologien Anhang E ‐ Tabellarischer Vergleich verschiedener Technologien Abb. E‐1: Tabellarischer Vergleich verschiedener (Interaktions‐)Technologien 87 Anhang F - Import und Exportmöglichkeiten der Systeme Anhang F ‐ Import und Exportmöglichkeiten der Systeme Shop‐System Produkte mittels XML Abb. F‐1: Produkt‐Export (XML) aus dem Shop‐System 88 Anhang F - Import und Exportmöglichkeiten der Systeme Kategorien mittels XML Abb. F‐2: Kategorie‐Export (XML) aus dem Shop‐System 89 Anhang F - Import und Exportmöglichkeiten der Systeme Hersteller mittels XML Abb. F‐3: Hersteller‐Export (XML) aus dem Shop‐System 90 Anhang F - Import und Exportmöglichkeiten der Systeme Design mittels XML Abb. F‐4: Design‐Export (XML) aus dem Shop‐System Detaillierte Übersicht Struktur‐ und Inhaltsrelevanter Bereiche sowie Im‐/Export Tab. F‐1: Metadaten sowie Im‐Export‐Möglichkeiten des Shop‐Systems Bereich Menü Export Import Metadaten Kunden Kunden Excel, XML Nein Nein Aktionen Newsletter‐Abonnenten CSV CSV Nein Produkt‐Attribute Katalog/Attribute Nein Nein Nein Spezifikations‐Attribute Katalog/Attribute Nein Nein Nein Produktverwaltung Katalog/Produkte Excel, XML Excel Ja Varianten Katalog/Produkte Nein Nein Nein Produkt‐ Katalog/Produkte Nein Nein Nein Hersteller Katalog/Produkte XML Nein Nein Tags Katalog/Produkte Nein Nein Nein Listenansicht Übersicht/Warengruppe Nein Nein Ja Baumansicht Übersicht/Warengruppe Nein Nein Ja 91 Anhang F - Import und Exportmöglichkeiten der Systeme PIM‐System Produkte Abb. F‐5: Produkt‐Export (Excel) aus dem Produktkatalog 92 Anhang F - Import und Exportmöglichkeiten der Systeme Design mittels XML (spcolor) [Auszug] <?xml version="1.0" encoding="utf‐8"?> <s:colorPalette isInverted="false" previewSlot1="BackgroundOverlay" pre‐ viewSlot2="BodyText" previewSlot3="AccentText" xmlns:s="http://schemas.mi‐ crosoft.com/sharepoint/"> <s:color name="BodyText" value="444444" /> <s:color name="SubtleBodyText" value="777777" /> <s:color name="StrongBodyText" value="262626" /> <s:color name="DisabledText" value="B1B1B1" /> </s:colorPalette> 93 Anhang F - Import und Exportmöglichkeiten der Systeme SQL‐Server CSV‐Export für Produkte Abb. F‐6: Produkt‐Export (CSV) aus dem SQL‐Management‐Studio 94 Anhang G - Einführung in UML-Verhaltensdiagramme Anhang G ‐ Einführung in UML‐Verhaltensdiagramme Verhaltensdiagramme Modellieren dynamische Aspekte, das Verhalten des Systems und seiner Komponenten Anwendungsfall ‐diagramm Aktivitäts‐ diagramm siehe 1.1 Zustands‐ diagramm siehe 1.2 Interaktions‐ diagramm siehe 1.3 Sequenz‐ diagramm siehe 1.4.1 siehe 1.4 Kommunikations‐ diagramm Timing‐ diagramm siehe 1.4.3 Interaktionsübersichts‐ diagramm siehe 1.4.2 siehe 1.4.4 Abb. H‐1: Übersicht der UML‐Verhaltensdiagramme Nr. Diagrammart (Verwendet) Beschreibung 1.1 Anwendungsdiagramm Zeigt Beziehung zwischen Akteuren und Anwendungsfällen (Menge (Nein) von Aktionen, die Akteur während Interaktion mit System abruft) Aktivitätsdiagramm (Ja) Beschreiben Verhalten einer Klasse oder Komponente, anhand Kon‐ 1.2 troll‐ und Datenflussmodells 1.3 1.4 Zustandsdiagramm Mögliche Zustände, Zustandsübergänge, Ereignisse und Aktionen im (Nein) „Leben“ eines Systems Interaktionsdiagramm (Nein) Beschreibt die zeitliche Ordnung von Ereignisauftritten 1.4.1 Sequenzdiagramm (Nein) Definieren Interaktionen zwischen Objekten, Fokus auf Nachrichten‐ fluss; Zeitlicher Ablauf der Nachrichten ohne Beziehungsinformation; 1.4.2 Kommunikationsdiagramm (Nein) tionsbeziehungen der Objekte während Interaktion; 1.4.3 Timingdiagramm (Nein) Zeigen Zustandswechsel von Objekten innerhalb Zeitspanne 1.4.4 Interaktionsübersichts‐ Beschreibt Kontrollfluss zwischen Interaktionen mit Hilfe der Notati‐ Diagramm (Nein) Definieren Interaktionen zwischen Objekten, Fokus auf Kommunika‐ onselemente von Aktivitätsdiagrammen; 95 Anhang H - BDC-Komponenten innerhalb der Zentraladministration Anhang H ‐ BDC‐Komponenten innerhalb der Zentraladministration Abb. H‐2: Übersicht implementierter BDC‐Verbindungen Abb. H‐3: Modifikation von Berechtigungsstufen für BDC‐Verbindungen 96 Lebenslauf Lebenslauf Persönliches Heiko Angermann Geboren 16.05.1985 in Kulmbach 1992 – 2002 Grundschule Kulmbach Gymnasium Kulmbach Realschule Kulmbach, Mittlere Reife Juni 2002 2002 – 2005 Ausbildung zum Flachdrucker Kulmbach 2005 – 2006 Druckergeselle in Kulmbach 2006 – 2008 Fachschule Nürnberg Staatlich geprüfter Drucktechniker, Fachhochschulreife 2008 – 2010 Produktdatenmanager in Bern 2010 – 2011 Kaufmännischer Angestellter in Berlin 2011 – 2014 Hochschule der Medien Stuttgart Studium der Druck‐ und Medientechnik Schwerpunkt Print & IT, Vertiefung in Contentmanagementsysteme Bachelorarbeit „Erstellung eines E‐Commerce‐Systems im Zusammenspiel mit Microsoft SharePoint 2013“ bei Prof. Dr‐Ing. A. Hitzges „Das Glück besteht nicht darin, daß du tun kannst, was du willst, sondern darin, daß du immer willst, was du tust.“ Leo N. Tolstoi (1828‐1910), russ. Schriftsteller 97
