Agile BI-Evolution bei Axel Springer SE

Transkript

1 Agile BI-Evolution bei Axel Springer SE Nicole Jänchen Axel Springer SE Dr. Jens Bleiholder OPITZ CONSULTING Deutschland GmbH Till Sander OPITZ CONSULTING Deutschland GmbH TDWI Konferenz München, Juni 2014

2 Sprint #1 ToDo In Progress Done Story #2 BI Strategie Story #3 Agile BI Story #4 Technologien Story #5 Fazit & Diskussion Story #1 Einleitung 2

3 Ich werde auf jeden Fall nicht müde werden, den Anspruch der Verleger auf Teilhabe an den bisherigen elektronischen Medien und noch mehr an allen neuen, auf uns zukommenden Informationssystemen zu vertreten. Axel Springer,

4 Mehr als 50% der Erlöse, mehr als 2/3 des EBITDA schon jetzt aus dem digitalen Geschäft Mit neuen Bezahlangeboten ohne die Reichweite zu opfern Mit vielen neuen operativen Systemen und verteilten Informationen Mit ganz neuen Informationsanforderungen Mit neuen Kennzahlen, um das digitale Geschäft zu verstehen, zu steuern und vorhersagen zu können Mit dem langfristigen Ziel, auch markenübergreifend den Kunden zu verstehen Und alles unter Berücksichtigung des Datenschutzes 4

5 Mit agilen Prinzipien das Risiko minimieren! AGILE und BI Wie passt das zusammen? DWH/BI Projekte - klassisch DWH/BI Projekte - agil Werden langwierig geplant Dauern zu lange Liefern am Ende doch nicht den nötigen Mehrwert Sind am Ende zu starr und zu unflexibel Kundenfeedback erfolgt erst nach langen Zyklen Werden nur von wenigen Personen genutzt Projekte sind lange intransparent Langwierige Planung entfällt Releasezyklen werden kürzer Ergebnisse entsprechen den Anforderung des Kunden Gehen direkt auf Kundenbedürfnisse ein Kundenfeedback erfolgt unmittelbar Werden vielfältiger und häufiger benutzt Projekte werden transparent

6 Scrum-Workflow im Überblick Product Backlog Daily Scrum PO Burndown Chart Sprint (1-4 Wochen) T Sprintziel PO T Sprint Backlog T SM Sprint Planning Meeting (Planning I, Planning II) SM Auslieferbares Inkrement Sprint Review PO T SM? T SM Sprint Retrospektive 6

7 Kurzübersicht Architektur Data Warehouse Standard + Ad-Hoc Reporting Data Marts Klassisch dimensional Core Data Vault Modellierung Stage Big Data Store Erweiterung möglich CSV SAP XML 7

8 Sprint #1 ToDo In Progress Done Story #3 Agile BI Story #4 Technologien Story #5 Fazit & Diskussion Story #2 BI Strategie Story #1 Einleitung 8

9 Neue Herausforderungen an Analysen und Kennzahlen durch die Digitalisierung Unstrukturierte Reportings >30 Reportings zu digitalen Themen, 15 Verteilerkreise, mehr als Empfänger Fehlende Automatisierung Analysen über Erlöse, Reichweite etc. werden manuell erstellt Bildung von Datensilos Keine Verknüpfung der verschiedenen Systeme möglich Datentiefe nicht ausgeschöpft Tracking Daten nicht auf Detailebene analysierbar Keine Einbeziehung externer Marktdaten Google, Wettbewerb 9

10 Das neue BI System soll die Geschäfte im Digitialen Bereich unterstützen Mehr Wissen über unsere digitalen Kunden sammeln Tracking und Auswertung des Kundenverhaltens Kosten und Erlöse transparent machen Vernetzung aller relevanten Datenquellen Automatisierung vorantreiben Individuelle Dashboards statt manuell erstellter Reportings Progressive Auswertungsmethoden aufbauen Predictive Analysis, Real-Time Decisions oder Behavioral Analytics ermöglichen Wettbewerbsvorteile durch präzise Geschäftssteuerung Neue Geschäftsfelder erschließen Leistungsfähige Business Intelligence kann Basis für datenbasierte Geschäftsmodelle sein Wir wollen die digitale Zukunft von Axel Springer gestalten. 10

11 Zielgruppen des BI Systems sind über alle Ebenen des Konzern verteilt Vorstand / VGF Transparente Berichte Aggregierter Überblick über die Geschäftsentwicklung zur Unterstützung von High- Level-Entscheidungen Produktmanager KPI-Kontrollsystem für alle geschäftskritischen Prozesse zur täglichen Steuerung des Produkts Fachbereiche Themenbasierte Antworten auf konkrete Fragen der operativen Arbeit 11

12 Anforderungen werden pragmatisch in Workshops erarbeitet Workshops mit 9 Fachbereichen, ca. 50 Kollegen bei der WELT Fragen aufgenommen, die heute nicht oder mit sehr viel manuellem Aufwand beantwortet werden können Gruppiert in 28 Themenblöcken Strukturierung und Iteration mit den Stakeholdern statt Erstellung formschöner Anforderungsdokumentationen 12

13 Unser Projekt-Scope: Eine Plattform für intelligente Antworten 13

14 Visualisierung des Informationsbedarfs in Sternen am Beispiel der Abos 14

15 Mit User Stories von unterschiedlicher Tiefe wächst das BI Sytem kontinuierlich Data Warehouse Reporting Data Marts Core Stage Big Data Store CSV SAP XML Sprints 15

16 Die neue BI Lösung wird agil entwickelt 16

17 Das SCRUM Projekt in der Konzern Organisation 17

18 Sprint #1 ToDo In Progress Done Story #4 Technologien Story #5 Fazit & Diskussion Story #3 Agile BI Story #1 Einleitung Story #2 BI Strategie 18

19 Scrum-Workflow im Überblick Product Backlog Daily Scrum PO Burndown Chart Sprint (1-4 Wochen) T Sprintziel PO T Sprint Backlog T SM Sprint Planning Meeting (Planning I, Planning II) SM Auslieferbares Inkrement Sprint Review PO T SM? T SM Sprint Retrospektive 19

20 Evolution-Sprint 3 Wochen Di Mi Do Fr Mo Di Mi Do Fr Mo Di Mi Do Fr Mo P1 EM P2 Development S U S U S U S U S U S U S U S U S U S U S U S U S U S U EM Estimation P1 Story Planning P2 Task Breakdown SU Daily Standup RV Review RS Retrospective DI Sprint Dinner RV RS DI 20

21 Estimation & Planning Ablauf & Ziel: Vorstellung der priorisierten Stories (PO) Klärung von Anforderungen und Akzeptanzkriterien Schätzung der Komplexität Festlegung des Sprintziels Definition der einzelnen Tasks Maßnahmen für eine gute und realistische Planung: Frühzeitiges Schätz-Meeting als Vorbereitung für die eigentliche Planungs-Session Definition of Ready 21

22 Definition of Ready (DoR) Formaler Rahmen für den Reifegrad einer Story Gibt dem Team und dem PO die Sicherheit, dass die Story wertvoll klar definiert überprüfbar realisierbar... ist und somit einen Wert für das Unternehmen hat und im Sprint auch tatsächlich umgesetzt werden kann. 22

23 Definition of Done (DoD) Formaler Rahmen für den Abschluss einer Aufgabe Aufteilung der DoD nach Story und Task Checkliste für das Team, welche Schritte für den Abschluss einer Aufgabe auszuführen sind Akzeptanzkriterien erfüllt Dokumentation Test Deployment Preview 23

24 Entwicklerteams in klassischen Projekten Agile BI Fachwissen Architektur Testen Modellierung Analytics ETL PO + SM IT-Analyst Tester Architekt ETL-Enwickler BI-Entwickler 24

25 Entwicklerteams in Scrum-Projekten Agile BI Fachwissen Architektur Testen Modellierung Analytics ETL PO + SM IT-Analyst Tester Architekt ETL-Enwickler BI-Entwickler 25

26 Testen in agilen BI-Projekten 26

27 Testen in agilen BI-Projekten Data Warehouse Reporting Data Marts Core Produktion Stage Big Data Store Integration Test CSV SAP XML Entwicklung 27

28 Dokumentation 28

29 Dokumentation Wiki-basierte Lösung für das kollaborative Arbeiten Zentral Kommunikationsplattform für das Projekt, u.a. für Konzepte Lösungsszenarien Dokumentation der Entwicklung 29

30 Review Ablauf: Der PO gibt eine Einleitung in den Sprint Das Team präsentiert die Ergebnisse des Sprints Der PO begutachtet die Ergebnisse und stellt anhand der Akzeptanzkriterien fest, ob die Stories abgenommen werden können Binäre Entscheidung, keine Kompromisse! Maßnahmen: Preview mit dem PO als Vorbereitung auf den Review in die DoD aufgenommen 30

31 Retrospektive Ablauf: Das Team reflektiert den letzten Sprint Scrum Master leitet durch die Retrospektive In der Regel ohne PO Ziel: Ableiten von Maßnahmen Stetige Verbesserung 31

32 Retrospektive Prime Directive Die Retrospektive wird im geschützten Raum durchgeführt. Vegas-Regel: Alles was in diesem Raum besprochen wird, bleibt auch in diesem Raum, es sei denn, es wird gemeinschaftlich anders entschieden. 32

33 Sprint Dinner 33

34 Wartung & Betrieb DevOps! Aufgrund der ständigen Weiterentwicklung ist es für externe Teams quasi nicht möglich, eine Wartung des Systems zu übernehmen. Ein gewisses Grundrauschen für Wartung & Betrieb sollte in den Sprints berücksichtigt werden, z.b. durch : Aufstocken des Teams Weniger Stories für Weiterentwicklung 34

35 Sprint #1 ToDo In Progress Done Story #5 Fazit & Diskussion Story #4 Technologien Story #1 Einleitung Story #2 BI Strategie Story #3 Agile BI 35

36 Übersicht Architektur Data Warehouse Standard + Ad-Hoc Reporting Data Marts Klassisch dimensional Core Data Vault Modellierung Stage Big Data Store Erweiterung möglich CSV SAP XML 36

37 Übersicht Technologien Data Warehouse Reporting Data Marts Core Oracle BI Foundation Suite Oracle TimesTen Oracle Data Integrator Oracle Exalytics Stage Big Data Store Oracle 12c CSV SAP XML Oracle Exadata 37

38 Sizing Architektur und Größe Abschätzung Datenvolumen Quellen, Staging, Core, DM Einbeziehung Komprimierung Verschiedene Vorhaltezeiträume Unterschiedliche Anforderungen der Marken Abschätzung Nutzungsverhalten Entscheidungsgrundlage für Hard- und Softwarekauf TB Gesamt Datenvolumen Jahr 1 Jahr 2 Jahr 3 Jahr 4 Jahr 5 38

39 Datenmodellierung in Evolution Data Warehouse Core Stage Reporting Data Marts Big Data Store Reporting Definition von Aggregaten Data Mart Dimensional Conformed Dimensions Abstimmung über Marken/Quellen hinweg Core Data Vault Staging Übernahme Datenmodell Quelle CSV SAP XML 39

40 Was ist Data Vault? Datenmodellierungsmethode 1990 von Dan Linstedt entwickelt Seit 2000 Public Domain und vermehrt im Einsatz Strikte Trennung von: Schlüsseln / Relationen / Informationen Stark standardisiert Daher gut automatisierbar 40

41 Warum Data Vault? Mehrere Quellen vereint in Data Warehouse Exakte und vollständige Historisierung Fokus auf Nachvollziehbarkeit Trennung von Historisierung und Business Logik Data Lineage und Auditing Gute Ergänzung zu agiler Vorgehensweise A single version of the facts 41

42 Drei Elemente der Data Vault Modellierung Hub Enthält die natürlichen Schlüssel einer Entität (Identität) Link Enthält die künstlichen / technischen Schlüssel der Hubs, deren Beziehung beschrieben werden soll Satellit Enthält die beschreibenden Attribute einer Entität (Eigenschaften) 42

43 Vergleich zu 3NF KUNDE PK KUNDE_ID UK KUNDENNR TITEL VORNAME NACHNAME ADRESSE FK KUNDENTYP_ID FK HÄNDLER_ID H_KUNDE PK H_KUNDE_ID UK KUNDENNR ZEITSTEMPEL QUELLE S_KUNDE PK H_KUNDE_ID PK ZEITSTEMPEL QUELLE TITEL VORNAME NACHNAME ADRESSE L_KUNDE_TYP PK L_KUNDE_TYP_ID UK H_KUNDE_ID UK H_KTYP_ID ZEITSTEMPEL QUELLE L_KUNDE_HÄNDLER PK L_KUNDE_HÄND_ID UK H_KUNDE_ID UK H_HÄNDLER_ID ZEITSTEMPEL QUELLE + Hubs für Kundentyp und Händler 43

44 Beladung des Data Vault Modells Reihenfolge Dimensionen und Fakten 1. Hubs (Erzeugung Schlüssel) 2. Links und Satelliten zu Hubs 3. Satelliten zu Links Satellites Satellites Links Beladung ist sehr gleichartig Templates Beladung kann massiv parallelisiert werden Hubs Staging 44

45 Erweiterung des Data Vault Modells Sprint 3 S_PRODUKT_DETAIL Sprint 2 S_TRANS_APPLE H_TRANS_APPLE L_SALE_APPLE S_DEVICE H_DEVICE Sprint 1 S_PRODUKT_STAMM H_PRODUKT L_SALE_GOOGLE S_TRANS_GOOGLE H_TRANS_GOOGLE 45

46 Gelebte Agilität mit Data Vault Data Warehouse Reporting Data Marts Sprint 1 Nur Anlage Hubs im Core Attribute am Core vorbei, da bereits dimensional Core Stage Big Data Store Sprint 2 Core ausmodelliert Um Objekte zu verbinden (quellübergreifend) CSV SAP XML 46

47 Mandantentrennung Aufgrund Anforderung Berechtigungssteuerung WELT-Nutzer dürfen keine BILD-Abonnenten sehen Fest ins Datenmodell eingebaut Verbindung Hub zu Mandantenhub, einfach mit Data Vault n:m Beziehung möglich S_ABO_MARKE S_ABONNENT H_ABONNENT L_ABO_MARKE H_MARKE 47

48 Erstellung von Dimensionen Business Logik auf dem Weg in die Dimensionen Was sind meine Produkte? Unterschiede in den Marken Regeln und Gruppierungen Automatisierbar, da Standard-Tabellen D_PRODUKT S_PRODUKT_ITUNES S_PRODUKT_GOOGLE H_PRODUKT S_PRODUKT_STAMM 48

49 Vorteile Schnelle Anpassung und Erweiterung möglich Starke Entkoppelung je Quelle ein eigener Satellit Kaum Lade-Abhängigkeiten durch Hubs/Links Einfache Struktur nur drei standardisierte Typen Hub / Link / Satellite Hohe Parallelisierbarkeit Automatisierbarkeit 49

50 Sprint #1 ToDo In Progress Done Story #5 Fazit & Diskussion Story #1 Einleitung Story #2 BI Strategie Story #3 Agile BI Story #4 Technologien 50

51 Fazit Der Axel Springer Verlag stellt sich den Herausforderungen durch die Digitalisierung Data Warehouse soll Markenübergreifend die Transparenz erhöhen Klassische Architektur kombiniert mit agiler Vorgehensweise Agiles BI funktioniert, ist aber nicht automatisch ein Garant für den Projekterfolg 51

52 Vielen Dank für Ihre Aufmerksamkeit! 52

53 Kontakt Nicole Jänchen Axel-Springer SE Axel-Springer-Straße Berlin Dr. Jens Bleiholder OPITZ CONSULTING Deutschland GmbH Tempelhofer Weg Berlin Tel. +49 (30) Till Sander OPITZ CONSULTING Deutschland GmbH Butendeichsweg Hamburg Tel. +49 (173) till.sander@opitz-consulting.com