Die Realtime Big Data OTTO

Transkript

1 Die Realtime Big Data OTTO Conny Dethloff Hamburg, 22. Mai 2014 Weg vom»denken in BI-Anwendungen«hin zum»denken in fachlichen Use Cases«.

2 Anliegen des heutigen Dialogs Über mich Inhalt des Dialogs Ziel des Dialogs Conny Dethloff Aufzeigen bestehender Die OTTO BI Architektur ist Otto GmbH & Co KG Handlungsmuster im aus fachlicher Sicht Abteilungsleiter OTTO BI Aufbau von BI bekannt. Projekt- und Architekturen. Die Gründe sind offen Datenmanagement Bewerten dieser gelegt, warum die OTTO BI 14 Jahre praktische Handlungsmuster im Architektur so gewählt Erfahrung im Thema Kontext Realtime und Big wurde. Business Intelligence Data. Vorstellen der OTTO BI Architektur. Seite 2 Begleiten Sie mich auf meiner Reise des Verstehens in wirtschaftliche und ökonomische Zusammenhänge:

3 Agenda Herausforderungen beim Aufbau einer BI Architektur Die OTTO BI Facharchitektur Vorgehensweise beim Aufbau der OTTO BI Facharchitektur Seite 3

4 Eine data-driven Company setzt eine neue Denkweise bei der Konzeption von BI Architekturen voraus. Klassische Denkweise Neue Denkweise Keine Gebäudearchitektur (Organisation) sondern Prozessstrecken (Daten, Prozesse und Ergebnisse) EVA-Prinzip E (Eingabe) V (Verarbeitung) A (Ausgabe) Feedback (Closed Loop) Seite 4

5 Der Quadrant der Datenbereitstellung Push (Quellengetrieben) Pull (Anforderungsgetrieben) systematisch Alle Fakten, auch historische Massenentwicklungen Vertrauenswürdigkeit vor Flexibilität Vorhersagbare, wiederholende und standardisierbare Hoher Grad an Automatisierung Hohe IT Orientierung Fokus auf Wahrheit, Interpretation und Kontext Stück-für-Stück Bereitstellung Flexibilität vor Vertrauenswürdigkeit Nutzerfreundlichkeit Relativ geringe IT Expertise Fachliche Domainexpertise ist essentiell opportunistisch Fachbereich und IT sind in getrennten Organisationen zu Hause Bereiche sind: Militär, Finanz & Controlling, Wartung & Betrieb Zentralisierte Bestrebungen und unternehmensweite Informationsbeschaffung Kontrollierte Entwicklungen unter Nutzung von IT Services, Prozessen und Produkten Fachbereich und IT sind in gemeinsamen Organisationen zu Hause Dezentralisierte Bestrebungen und bereichsspezifische Informationsbeschaffung Entwicklungen direkt in Produktion unter Nutzung von speziellen Produkten und Prozessen Quelle: Seite 5

6 Der Quadrant der Datenbereitstellung: Ziele Push (Quellengetrieben) Pull (Anforderungsgetrieben) systematisch Alle Fakten, auch historische Massenentwicklungen Vertrauenswürdigkeit vor Flexibilität Vorhersagbare, Reduzieren wiederholende von und standardisierbare Unsicherheit Hoher Grad an Automatisierung Hohe IT Orientierung Fokus auf Wahrheit, Interpretation und Kontext Stück-für-Stück Bereitstellung Flexibilität Reduzieren vor Vertrauenswürdigkeit von Nutzerfreundlichkeit Durchlaufzeit Relativ geringe IT Expertise Fachliche Domainexpertise ist essentiell opportunistisch Fachbereich und IT sind in getrennten Organisationen zu Hause Bereiche sind: Militär, Finanz & Controlling, Wartung & Betrieb Ankurbeln von Innovationen Zentralisierte Bestrebungen und unternehmensweite Informationsbeschaffung Kontrollierte Entwicklungen unter Nutzung von IT Services, Prozessen und Produkten Fachbereich und IT sind in gemeinsamen Organisationen zu Hause Dezentralisierte Bestrebungen und bereichsspezifische Informationsbeschaffung Gewolltes Chaos für Innovationen Entwicklungen direkt in Produktion unter Nutzung von speziellen Produkten und Prozessen Quelle: Seite 6

7 Datenbereitstellung vs. Reaktionszeit Datenbereitstellung Historische Daten Real-Time Daten Batch Use Cases (Capture later, act later) Near-Time Use Cases (Capture now, act later) Reaktionszeit Batch Real-Time Beispiele: ing, Kampagnen, Print Adhoc Use Cases (Capture later, act now) Beispiele: DMC auf statistischen Profilen (offsite, onsite, newsletter) Beispiele: Shoppingcart abandons, fraud detection, keyword bidding Real-Time Use Cases (Capture now, act now) Beispiele: Last Minute Defense (NBA), Product Recommendations (NBO), Dynamic Pricing, Retargeting Seite 7

8 Gegenüberstellung der klassischen und der neuen Denkweise bzgl. der Konzeption von BI Architekturen. Klassische Denkweise Neue Denkweise Silos nach Kimball oder zu strenger Inmon Modernes logisches Layermodell Data Marts Große Informationsräume KPI Orientierung Use Case Orientierung Erdrückendes Reporting Mindset Mehrzweckverwendung von Daten Anwendungsnirvana Closed-Loop BI Beliebigkeit Design & Lifecycle Patterns Daily und Batch Near- & Real-Time NO-SQL Verwirrung Nahtlose NO-SQL Integration Heterogene Punkt-zu-Punkt Vebindungen BI Middleware Seite 8

9 Neue Denkweise Brechen mit einigen Paradigmen: Business Rules Klassische Denkweise DWH Business Rules Business Rules zu nah an Quellen impliziert einen hohen Änderungsaufwand Neue Denkweise Hard Business Rules Stage Raw Vault Soft Business Rules Business Vault Data Marts Integration Business Logik Seite 9

10 Agenda Herausforderungen beim Aufbau einer BI Architektur Die OTTO BI Facharchitektur Vorgehensweise beim Aufbau der OTTO BI Facharchitektur Seite 10

11 OTTO BI hat einen 360 Grad Anspruch: Die BI Services gliedern sich nach den folgenden Anwendungsdomänen. CAM Sortimentsanalysen Lieferantenmanagement CAM-Planung Pricing Analytics Bestandsmanagement Prognose (Beschaffung und Warenströme) Vertrieb Kundensegmentierung und Zielgruppenselektion Marketing Performance Management Vertriebsanalysen Kundenprozess- Monitoring E-commerce Analytics Contact Center Analytics SEM Performance Management Realtime Offer Management Controlling Profitabilitätsanalysen Geschäftscontrolling und Business Development Kredit Managemnt Kredit Management Analysen Logistik SLA Monitoring Logistik Prozesscontrolling Bestandsmonitoring Logistische Leistungsabrechnung Finanz/ ReWe Bilanz, GuV, Cash Flow Analysen Kostenstellen/ Profit Center Reporting Hauptbuch Analysen Warenbuchhaltung Analysen Seite 11

12 Was bedeutet data-driven? 1 Data-Driven beginnt im Kopf. Daten dürfen bei der Umsetzung fachlicher Anforderungen keine Begrenzung darstellen. 2 Grundsätzlich müssen stets alle Daten in die Überlegungen zu Umsetzungen mit ins Kalkül gezogen werden. Warum sollte man sich aus Sicht der Daten bereits vorher künstlich begrenzen ohne einen Beweis der Nutzbarkeit dieser angetreten zu haben. 3 Daten gehören grundsätzlich dem Unternehmen, nicht einzelnen Bereichen. Datensilos sind verboten. 4 Daten kennen keine Systemgrenzen, schon gar keine Bereichsgrenzen. 5 Datenintegration ist ein Muss. Damit erkauft man sich ganz bewusst und auch gewollt Abhängigkeiten auf Datenebene. Hier muss zwischen Abhängigkeit auf Daten- und Applikationsebene unterschieden werden. Seite 12

13 Die notwendigen Leistungsmerkmale der OTTO BI Facharchitektur sind Ermöglichung von flexiblen und agilen Weiterentwicklungsmöglichkeiten (Real-Time Use Cases sollten auch in Real-Time weiterentwickelt werden können). Integration von Real- sowie Neartime Fähigkeiten in Verbindung zu Batchprozessen sowie operativen Prozessen. Algorithmen müssen kanalübergreifend konzipiert und implementiert werden, um auf dieser Basis ganzheitlich und ergebnisorientiert steuern zu können. Algorithmen benötigen eine einheitliche Datenbasis bzgl. Testen und Ausführen, was impliziert das eine Trennung der Algorithmen in Backend und Frontend nicht sinnvoll. Algorithmen benötigen historische, kontextuelle und vorberechnete Daten, die auf einer Plattform, der BI Plattform, persistiert sein müssen. Alle steuerungs- und analytikrelevante Daten müssen an einem Ort verfügbar und für die Abbildung der Use Cases aufbereitet vorliegen. Seite 13

14 Die OTTO BI Facharchitektur baut auf diesem Basisbild auf. Content- System (Bilder, Produktdaten) Steuerimpuls Action (NBA, NBO, ) Decision Engine Modellergebnisse BI Plattform Online Shop Parsing Kontextdaten Modellergebnisse Modellergebn. Modellaktualisierung Kanäle Quellen Print Dateninput Trackingdaten Operative Systeme (NOA, EKR, ) Dateneinkauf Dateninput Historische Daten Realtime Layer- Architektur Load Layer Base Layer Neartime & Batch Layer-Architektur Dateninput Business Layer BI Datenmanagement Dateninput Dateninput Dateninput Modell-/ Algorithmusentwicklung Modellverwaltung Modell-Management und Advanced Analytics Standard-Reporting Ad Hoc-Analytics Reporting und Business Analytics Seite 14

15 Agenda Herausforderungen beim Aufbau einer BI Architektur Die OTTO BI Facharchitektur Vorgehensweise beim Aufbau der OTTO BI Facharchitektur Seite 15

16 Vorbemerkungen bzgl. der Vorgehensweise zum Implementieren der OTTO BI Architektur. 1 Der Aufbau der Facharchitektur erfolgt evolutionär entlang der Use Cases. Das Ziel entsteht beim Gehen. 2 Die Facharchitektur ist die Klammer bei der Transformation. Im Rahmen der Transformation müssen stets stable states erzeugt werden. Diese Werden als Meilensteine in der Roadmap abgebildet. 3 Frühe BI Fachprojekte haben den Aufwand zu tragen, die BI Layerarchitektur aufzubauen. Spätere BI Fachprojekte partizipieren davon. 4 Die BI Facharchitektur ist das Bindeglied zwischen OTTO BI Weiterentwicklungen und Aktivitäten im Rahmen der Transformation. Seite 16

17 Der Geschlossene Testzyklus innerhalb der OTTO BI Architektur verlangt integrativ aufgesetzte Projekte. Geschlossener Testzyklus (auch als Closed Loop bekannt) Die Volatilität im e-commerce verlangt einen geschlossenen BI-Testzyklus. Entscheiden Entscheidungen, die über BI Services an die Kanäle ausgespielt werden, müssen auf Basis der Kundenaktionen und der vorher definierten Erwartungen gemessen werden. Auf Basis dieser Messergebnisse werden Erkenntnisse bzgl. der Güte der Modelle generiert, die ggf. dazu führen, dass Modelle angepasst werden. Kundenaktion Messen Adaptieren Lernen Diese angepassten Modelle führen dann zu anderen Entscheidungen, die an die Kanäle ausgespielt werden, die dann in der Regel zu anderen Kundenaktionen führen, die wiederum gemessen und gegen die Erwartungen gespiegelt werden. Usw. usf. Seite 17

18 Die OTTO BI Architektur muss fachlich getrieben und evolutionär umgesetzt werden. Schrittfolge pro Use Case Erkenntnisse Fachliche Anforderungen Anforderungen an Daten Anzubindende Quellen Anzubindende Datenquellen Reihenfolge der Abarbeitung der Use Cases Viabilität der Use Cases zum Implementierun gsstand BI Architektur Welche Use Cases stellen einen Quick Win dar? Use Case 1 Use Case 2 Use Case n 50% 30% 20% 70% 80% 20% 100% 100% 100% Kunde Artikel Bestellung Kunde Artikel Bestellung Kunde Artikel Bestellung Seite 18

19 Ein Beispiel für die Verortung von Use Cases auf die OTTO BI Architektur Session Typlogie Use Case basiert auf einer Hypothese Beschreibung des Datenflusses Die Motivation, die ein User/ Kunde für den Besuch unserer Kanäle hat (stöbern, Direktkauf, ) beeinflusst maßgeblich mögliche Angebote an den Kunden seitens OTTO, die dann zu mehr Umsatz mit dem Kunden führen. Schematischer Datenfluss Aus den Trackingdaten der Vergangenheit wird eine Tabelle der Klickpfade der User und Kunden bereit gestellt und im Neartime & Batchlayer persistiert. Im Rahmen eines Modells werden die Klickpfade zu Sessiontypen geclustert. Input dafür sind die vorher vereinbarten Konventionen über Sessiontypen (z.b. Welche Klickpfade zeichnen eine Stöbersession aus?) Output ist eine Tabelle der Sessiontypen. Diese Tabelle wird im Realtime sowie Neartime & Batch Layer persistiert. Wenn User und Kunden sich auf dem Onlineshop bewegen wird abhängig vom derzeitigen Sessiontyp (Abgleich Kontext mit der Sessiontabelle) dem Kunden/ User Content ausgespielt bzw. Aktionen angestoßen. Seite 19

20 Seite 20 Vielen Dank