Business Intelligence in der Praxis: Herausforderung an Business und IT

Transkript

1 Business Intelligence in der Praxis: Herausforderung an Business und IT Dr. Stefan Paul Jahrgang : Berater bei IDS Scheer heute: Selbständiger IT- und Unternehmensberater Geschäftsführer der Citi GmbH, Zweibrücken - SAP Business Warehouse Berater der ersten Stunde (enge Zusammenarbeit mit der SAP) - IT-Projektleiter in zahlreichen BI-Großprojekten für ein DAX-Unternehmen der chemischen Industrie - Aufbau von globalen Reporting-Tools für Sales&Marketing, Supply-Chain, Lieferservice, etc. - Steuerung global verteilter Entwicklungsteams - Mitglied der IT Governance für BI Projekte Dolmetscher zwischen Business und IT Seite 1

2 Inhalt Business Intelligence: Einstieg und Begrifflichkeiten Herausforderungen in BI Projekten - Team - Fachliche Anforderungen - Tools - Prototyp - Go Live und was dann? Zusammenfassung Seite 2

3 Business Intelligence: Einstieg und Begrifflichkeiten Seite 3

4 Unter Business Intelligence versteht man die Analyse von Daten mit dem Ziel die Entscheidungsfindung zu unterstützen Präsentieren Sammeln Verwalten Der Begriff Business Intelligence* (deutsch etwa Geschäftsanalytik) bezeichnet Verfahren und Prozesse zur systematischen Analyse (Sammlung, Auswertung und Darstellung) von Daten in elektronischer Form. Ziel ist die Gewinnung von Erkenntnissen, die in Hinsicht auf die Unternehmensziele bessere operative oder strategische Entscheidungen ermöglichen. Wikipedia * Der englische Ausdruck intelligence bedeutet in diesem Kontext nicht Intelligenz, sondern die aus dem Sammeln und Aufbereiten erworbener Informationen gewonnenen Erkenntnisse. Seite 4

5 Business Intelligence stellt Entscheidungen auf die Basis von Fakten Unter Business Intelligence (BI) versteht man alle Strategien, Prozesse und Technologien, bei denen aus Daten Informationen und aus Informationen erfolgskritisches Wissen gewonnen wird, so dass Entscheidungen auf Basis von Fakten getroffen werden, die Aktionen zur Unternehmens- und Prozesssteuerung auslösen Dr. Wolfgang Martin, 2009 Seite 5

6 Business Intelligence erhöht den Informationsgrad Informationsgrad mit Informationssystem ohne Zeit Quelle: Marcus Reiser, Jan Holthuis Seite 6

7 Business Intelligence sorgt dafür, dass Entscheidungen besser getroffen werden Informationsgrad mit Informationssystem ohne Gewinn an Sicherheit Zeitpunkt der Entscheidung Zeit Quelle: Marcus Reiser, Jan Holthuis Seite 7

8 Business Intelligence sorgt dafür, dass Entscheidungen schneller getroffen werden Informationsgrad mit Informationssystem Für Entscheidung notwendiger Informationsgrad Gewinn an Zeit ohne Zeit Quelle: Marcus Reiser, Jan Holthuis Seite 8

9 Aufgaben von BI: Sammeln, Verwalten und Präsentieren von Daten Präsentieren Separate Datenhaltung (Data Warehouse) Entlastung der operativen Systeme von umfangreichen Abfragen für Abfragen optimierte Datenhaltung Zusammenführung von Daten aus mehreren Quellen Sammeln Online Analytical Processing (OLAP) Verwalten Online Transaction Processing (OLTP) Seite 9

10 Multidimensionale Analyse: Ein Würfel aus Merkmalen und Kennzahlen Typische Fragestellungen werden mit dem Drehen, Wenden und Durchschneiden ( Slice & Dice ) eines mehrdimensionalen Würfels assoziiert Merkmalen sind Kanten bzw. Dimensionen des Würfels Kennzahlen sind Zellen des Würfels Beispiel: Wie entwickeln sich bestimmte Kennzahlen (Absatz, Umsatz, etc.) bezüglich bestimmter Merkmale (Kunde, Produkt, Zeit etc.)? Produkt A380 Umsatz x Mio A350 A Zeit Qantas Singapore Airlines Lufthansa Seite 10

11 Beispiel für Drill-Down, Slice & Dice alle Zahlen fiktiv Seite 11

12 Beispiel für Drill-Down, Slice & Dice alle Zahlen fiktiv Seite 12

13 Beispiel für Drill-Down, Slice & Dice alle Zahlen fiktiv Seite 13

14 Beispiel für Drill-Down, Slice & Dice alle Zahlen fiktiv Seite 14

15 Beispiel für Drill-Down, Slice & Dice alle Zahlen fiktiv Seite 15

16 Stammdaten Bewegungsdaten Informationen Informationen in BI-Systemen: z.b. SAP BW Informationen helfen, strategische und operative Entscheidungen zu treffen und Bewegungsdaten in Operativen Systemen z.b. SAP R/3 Stammdaten - Material - Kunde - Lieferant -... Seite 16

17 Stammdaten Bewegungsdaten Informationen Close the loop Informationen in BI-Systemen: z.b. SAP BW Informationen helfen, strategische und operative Entscheidungen zu treffen und Bewegungsdaten in Operativen Systemen z.b. SAP R/3 bei der Optimierung der Prozesse Stammdaten - Material - Kunde - Lieferant -... bei der Harmonisierung der Stammdaten Seite 17

18 BI scheint eine einfache Thematik zu sein trotzdem laufen viele BI Projekte schief BI scheint eine relativ einfache Thematik zu sein: Daten sammeln, verwalten und präsentieren That s it! Präsentieren Verwalten Sammeln Trotzdem laufen viele BI Projekte schief: Gartner says more than 50 percent of Data Warehouse projects will have limited acceptance or will be failures Gartner Press release 2005 Wo liegt das Problem? Seite 18

19 Wo liegen die Probleme bzw. Herausforderungen? Phasen eines typischen BI Projektes Projektstart - Ziele* - Sponsoren - Team Analyse der fachlichen Anforderungen Toolauswahl Prototyp Entwicklung Post Go-Live * welche "Entscheider" sollen bei der Verrichtung welcher betriebswirtschaftlichen Aufgabe unterstützt werden und welche Informationen benötigt man dazu? Einige Herausforderungen in BI Projekten werden näher betrachtet Seite 19

20 Herausforderungen in BI Projekten - Team - Fachliche Anforderungen - Tools - Prototyp - Go Live und was dann? Seite 20

21 Das Team: Facheinheit und IT - Rollenabgrenzung - gemeinsame Sprache - Kommunikation Seite 21

22 Die Rollen/Aufgaben müssen zwischen Facheinheit und IT klar abgegrenzt sein Wenn die Facheinheit Aufgaben der IT übernimmt und z.b. selbst programmiert oder über Tabellen-Logiken entscheidet -... werden die Anwendungen oft nicht in das Support-Konzept eingebunden wer kümmert sich um die Pflege, Korrektur und Erweiterung der Anwendung, um die Rückmeldung zu User-Anfragen, etc.? -... sind die Anwendungen oft auf einzelne Einheiten beschränkt, folgen also keinem zentralen Ansatz Synergien gehen verloren Wenn die IT Fach-Aufgaben übernimmt (z.b. Fachkonzept-Details festlegt) verstehen die Facheinheiten ev. die Details der Anwendung nicht die Anwendung findet keine Akzeptanz Seite 22

23 Die Rollen/Aufgaben müssen zwischen Facheinheit und IT klar abgegrenzt sein Konflikte in der Aufgabenverteilung zwischen Facheinheit und IT basieren oft auf betrieblichen Rahmenbedingungen wie z.b.: - Mitarbeiter sind überlastet jeder versucht Arbeit abzuschieben - Mitarbeiter sorgen sich um ihre Aufgaben und verbittet sich Eingriffe in seinen Kompetenz-Bereich Seite 23

24 Gemeinsame Sprache: Mitarbeiter der Facheinheit benötigen ein Grundverständnis zu IT-Themen Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der Datenmodellierung verstehen, wie z.b.: - Bewegungsdaten Beleg 4711 bestellt am Artikel 0815 Warenempfänger KG 20 Seite 24

25 Gemeinsame Sprache: Mitarbeiter der Facheinheit benötigen ein Grundverständnis zu IT-Themen Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der Datenmodellierung verstehen, wie z.b.: - Bewegungsdaten vs. Stammdaten Beleg 4711 bestellt am Artikel 0815 Warenempfänger KG 20 Name: Müller GmbH Ort: Bielefeld Land: Deutschland Branche: Automobile werden regelmäßig aktualisiert (täglich, wöchentlich) Seite 25

26 Gemeinsame Sprache: Mitarbeiter der Facheinheit benötigen ein Grundverständnis zu IT-Themen Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der Datenmodellierung verstehen, wie z.b.: - Nummern-Ergänzungen (Compounding) zur Vermeidung von Kollisionen Beleg 4711 bestellt am Artikel 0815 Warenempfänger 01/ KG 20 Name: Müller GmbH Ort: Bielefeld Beleg 4713 bestellt am Artikel 1111 Warenempfänger 02/ KG 20 bei einer hinzu gekauften Firma aus GB werden die identischen Kundennummern verwendet aber für andere Kunden Name: Smith Inc. Ort: London Seite 26

27 Gemeinsame Sprache: Mitarbeiter der Facheinheit benötigen ein Grundverständnis zu IT-Themen Zum Beispiel sollten Facheinheiten Mitarbeiter verstehen, - dass es Performance-Restriktionen gibt man kann nicht beliebig viele Daten beliebig schnell bereitstellen! viel schnell - dass es in der IT Arbeit Aufwandstreiber gibt Dinge, die relativ einfach klingen, können technisch sehr aufwändig sein! Seite 27

28 Gemeinsame Sprache: Mitarbeiter der IT benötigen ein Grundverständnis der Arbeit der Facheinheit Zum Beispiel sollten IT-Mitarbeiter ein Grundverständnis der Arbeit der Facheinheit haben zu Themen wie: - Prozess-Know-how: Wie sind Prozesse konzipiert bzw. implementiert, aus denen das BI Tool die Daten bezieht? - Was sind die wesentlichen Kennzahlen, die bereitgestellt werden sollen - und wofür werden sie verwendet? Seite 28

29 Gemeinsame Sprache: es geht um einen groben Überblick und nicht um die Details Es kommt zu Frustration und Missverständnissen - wenn die IT die Facheinheit mit IT-Ausdrücken überfordert - wenn die Facheinheit die IT Kollegen nicht zumindest in die Grundzüge der fachlichen Hintergründe der Anforderung einweiht Wo es nötig ist, muss jemand (Projektleitung, Berater, etc.) übersetzen! Business IT IT Business Seite 29

30 Gemeinsame Sprache: es geht um einen groben Überblick und nicht um die Details Facheinheit und IT müssen ihre Themen so weit veranschaulichen und vereinfachen, dass ein gemeinsames Gespräch und gemeinsame Entscheidungen möglich werden Wahrheit und Klarheit sind komplementär! 100% Klar 100% Wahr das Programm ist fehlerhaft ziemlich klar! im Function Module XY führt eine fehlende If-Anweisung dazu, dass in ca. 10% aller Fälle ein falscher Datums-Wert an das übergeordnete Programm übergeben wird... näher an der Wahrheit Seite 30

31 Offene Kommunikation & gegenseitiges Vertrauen sind essentiell für den Projekterfolg Es muss möglich sein, die Aussagen der jeweils anderen Einheit zu hinterfragen die Aussage das versteht Du eh nicht hilft hier nicht weiter! Gleichzeitig muss es in der Zusammenarbeit eine Vertrauensbasis geben (nicht jede Aussage, die unangenehm ist, sollte hinterfragt werden) Zwei Beispiele: - Wenn die IT zur Umsetzung einer Anforderung nur 2 technische Optionen sieht (mit Vor.- und Nachteilen), ist es nicht hilfreich, wenn die Facheinheit darauf drängt, dass nach einer Option 3 (ohne Nachteile) gesucht wird - Wenn die Facheinheit eine technisch schwierig zu ermittelnde Information zwingend für ihr Reporting benötigt, ist es nicht hilfreich, wenn die IT den betriebswirtschaftlichen Mehrwert dieser Information in Frage stellt Seite 31

32 Das Team: Zusammenfassung Die Rollen/Aufgaben müssen zwischen Facheinheit und IT klar abgegrenzt sein Facheinheit-Mitarbeiter benötigen ein Grundverständnis zu IT-Themen und umgekehrt Die Kommunikation lebt davon, dass jeder einen groben Einblick in die Arbeit der anderen Einheit hat es geht nicht um die Details! Offene Kommunikation und gegenseitiges Vertrauen sind essentiell Man kann nur erfolgreich sein, wenn alle das gleiche Ziel verfolgen Seite 32

33 Die fachlichen Anforderungen - Unterschiedliche Sichten - Implizite Logik - Abgeleitete Merkmale - Was ist wesentlich? - Fehlerfrei und vollständig Seite 33

34 Anforderungen unterschiedliche Sichten Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht: Absatzzahlen pro Warengruppe pro Land pro Monat Seite 34

35 Anforderungen unterschiedliche Sichten Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht: Absatzzahlen pro Warengruppe pro Land pro Monat Hier müssen z.b. folgende Details geklärt werden: - Absatzzahlen: Alle Absätze oder nur die Absätze mit echten Kunden? - pro Warengruppe: welche Artikel gehören zu dieser Warengruppe und: ist die Gruppierung gemäß aktueller Sicht zu erstellen? - pro Land: Land der Vertriebseinheit oder Land des Kunden? - pro Monat: basierend auf welchem Datum? Seite 35

36 Anforderungen unterschiedliche Sichten Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht: Absatzzahlen pro Warengruppe pro Land pro Monat Dazu sagt der Vertriebschef - alle Absätze auch die Verkäufe an Händler, die zum Konzern gehören - auch historische Daten sollen so gezeigt werden, als wäre die aktuelle Waren-Gruppierung schon immer gültig gewesen - bezogen auf das Land des Kunden, der die Ware geliefert bekommt - basierend auf Auftragsanlagedatum Seite 36

37 Anforderungen unterschiedliche Sichten Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht: Absatzzahlen pro Warengruppe pro Land pro Monat Dazu sagt der Finanzchef - nur Absätze mit echten Kunden - historische Daten sollen so gezeigt werden bzw. in Warengruppen eingeordnet sein, wie sie zum Zeitpunkt der Belegerstellung gruppiert waren - bezogen auf das Land des Kunden, der die Ware bezahlt - basierend auf Rechnungsdatum Seite 37

38 Anforderungen unterschiedliche Sichten Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht: Absatzzahlen pro Warengruppe pro Land pro Monat jede Menge Klärungs- bzw. Detaillierungsbedarf unterschiedliche Antworten aus unterschiedlichen Abteilungen Seite 38

39 Anforderungen implizite Logik Beispiel 2: Die Facheinheit eines Industriebetriebes möchte folgenden Bericht: Lieferzuverlässigkeit pro Transportart pro Land pro Monat Auch hier müssen die Merkmale Transportart, Land, Monat detailliert werden Zusätzlich muss hier geklärt werden: - Basierend auf der Definition der Lieferzuverlässigkeit = Anzahl pünktliche Lieferungen / Anzahl alle Lieferungen was ist pünktlich, welche Verspätung ist noch OK? Im Verständnis der Facheinheit ist die Interpretation, ob eine Lieferung pünktlich ist oder nicht, abhängig von der Transportart: See: +/- 3 Tage Toleranz LKW: 0 Tage Toleranz Seite 39

40 Anforderungen implizite Logik pünktlich ist abhängig von der Transportart See: +/- 3 Tage Toleranz LKW: 0 Tage Toleranz Tage Zugesagter Eintreff-Termin + 3 Tage - 3 Tage Zugesagter Eintreff-Termin + 3 Tage Lieferzuverlässigkeit im See-Verkehr: Lieferzuverlässigkeit im LKW-Verkehr: 90 pünktliche Lieferungen 100 Lieferungen insgesamt = 90 % 80 pünktliche Lieferungen 100 Lieferungen insgesamt = 80 % Seite 40

41 Anforderungen implizite Logik: 3 Implementierungs-Optionen Abhängigkeit der Pünktlichkeit von der Transportart ist in Anwendung implementiert 30 See: +/- 3 Tage Toleranz 80 LKW: 0 Tage Toleranz Tage Zugesagter Eintreff-Termin + 3 Tage - 3 Tage Zugesagter Eintreff-Termin + 3 Tage Option 1: Die Anwendung berücksichtigt bei Berechnung der Lieferzuverlässigkeit automatisch die unterschiedlichen Toleranzen implizite Logik Zum Verständnis der Daten muss der User bedenken, dass diese Logik in die Berechnung eingebaut ist Seite 41

42 Anforderungen implizite Logik: 3 Implementierungs-Optionen Implementiert ist eine 0 Tage Toleranz für alle Transportarten Tage Zugesagter Eintreff-Termin + 3 Tage - 3 Tage Zugesagter Eintreff-Termin + 3 Tage Option 2: Toleranz wird für alle Transportarten auf 0 Tage gesetzt Zum Verständnis der Daten muss der User berücksichtigen, dass im See- Verkehr eine geringere Pünktlichkeit zu erwarten ist Seite 42

43 Anforderungen implizite Logik: 3 Implementierungs-Optionen Die Toleranz ist variabel (kann vom User individuell festgelegt werden) Tage Zugesagter Eintreff-Termin + 3 Tage - 3 Tage Zugesagter Eintreff-Termin + 3 Tage Option 3: der User kann die Toleranz selbst einstellen damit besteht z.b. die Möglichkeit, See-Transporte mit +/- 3 oder mit +/- 0 Tagen auszuwerten Seite 43

44 Anforderungen implizite Logik Implizite Logik (Option 1) hat Vorteile: - Einheitliche, standardisierte und vergleichbare Interpretation der Daten - User müssen sich um nichts kümmern Nachteile: - Verlust an Flexibilität - Mögliche Missverständnisse, wenn Regeln nicht bekannt sind Wieso wird ein 2 Tage verspäteter Transport manchmal als pünktlich bewertet und manchmal als unpünktlich? Implizite Logik kann sehr hilfreich sein funktionieren aber nur, wenn sie global anerkannt und verstanden ist Flexibilität darf nicht verloren gehen daher z.b. in globalen Standard-Berichten Logik einbauen, aber für Experten die Option erhalten, diese Regeln auch auszuschalten bzw. selbst festzulegen Seite 44

45 Anforderungen abgeleitete Merkmale Beispiel 3: Absatzmenge aller über ecommerce angelegten Aufträge Die Info Auftrag wurde über ecommerce-vertriebskanal angelegt ist nicht global einheitlich über ein Feld erkennbar Abgeleitetes Merkmale ecommerce-kennzeichen mit Definition - Quelle 1: Verkaufsbelegart = x1, x3 oder x7 - Quelle 2: Vorgängerbelegart des Auftrages = y1 Aufgabe von abgeleiteten Merkmalen 1. Verdichten bzw. vereinfachen: x1, x3, x7 = ecommerce 2. Harmonisieren: ecommerce ist in Quelle 1 anders definiert als in Quelle 2 Verkaufsbelegarten: x1, x2, x3, x4, x5 x6, x7, x8, x9, x10 ecommerce ja / nein Vorgängerbelegart: y1, y2,, y3, y4 Seite 45

46 Anforderungen abgeleitete Merkmale Problemfelder bei abgeleiteten Merkmalen - Neue Begrifflichkeiten müssen geschult und etabliert werden - Information lässt sich nicht 1:1 im ERP-Quellsystem überprüfen - Qualität der Information steht und fällt damit, dass Mapping-Tabellen aktuell gehalten werden - Wenn Zuordnungen geändert werden (z.b. weil alte Einträge fehlerhaft oder unvollständig waren) Umstellung der Historie-Daten notwendig Abgeleitete Merkmale können sehr hilfreich sein funktionieren aber nur, wenn sie global anerkannt und verstanden sind (man sollte die Anwender nicht mit unnötig vielen Objekten überfordern) Flexibilität darf nicht verloren gehen Experten unter den Usern sollten auch die Basis-Merkmale sehen können Seite 46

47 Anforderungen Beschränkung auf das Wesentliche Ich will ALLES haben!!! Wenn man Kollegen aus der Facheinheit die Frage stellt, welche Merkmale z.b. aus einem Auftragsdokument für das Reporting relevant sein könnten, bekommt man oft die Antwort ALLES könnte irgendwie irgendwann relevant sein Was sind die wesentlichen Informationen (Merkmale und Kennzahlen)? Besser 80% der Anforderungen mit einer Easy-to-use Anwendung abdecken als 99% der Anforderungen in einem Tool bereitstellen, das keiner nutzt, weil es zu komplex bzw. unübersichtlich ist Seite 47

48 Anforderungen Beschränkung auf das Wesentliche Seite 48

49 Anforderungen fehlerfrei und vollständig! das kann ein Widerspruch sein Beim Laden von Daten werden oft Fehlerprüfungen bzw. Plausibilitätschecks durchgeführt Belege im Reporting werden nicht angezeigt weil z.b.: - Kundennummern falsch ist - Datumsfelder unlogisch ist (Lieferungsdatum zeitlich vor Auftragsanlage) + Das BI-System findet Fehler und hilft, diese zukünftig im ERP zu vermeiden Die fehlerhaften Belege werden z.b. in einem Monats-Umsatz-Report vermisst (wo es z.b. dem Vertriebschefs völlig gleichgültig ist, ob es in den ERP- Belegen Datumsfelder gibt, die nicht plausibel sind) - Es muss abgewogen werden, was wichtiger ist: Fehler aufzudecken oder Daten vollständig (und analog zum ERP) anzuzeigen Seite 49

50 Exkurs zum Thema Datenqualität Exkurs Datenqualität ist nicht Alles bei leichten Fehlern kann die Datenvollständigkeit wichtiger sein Der korrekte Trend ist z.b. in Supply Chain Anwendungen oft wichtiger als die korrekten Absolut-Werte - Anwender ziehen ihre Schlüsse sehr oft über die Analyse des Trends - Bei Finance & Controlling Anwendungen sieht man das anders Beim Beheben von Fehlern sollte man an die eventuell zu diesen Daten getroffene Zielvereinbarungen denken und Korrekturen kommunizieren und dann nur jeweils zum Monats-, Quartal- oder Jahreswechsel einbauen Extrem hilfreich zur Verifizierung der Datenqualität einer Anwendung ist die Option, im Reporting-Umfeld auch die Einzelbelege anzeigen zu können Seite 50

51 Exkurs zum Thema Datenqualität Beispiel: Pünktlichkeit messen mit Fabrikkalender vs. 7 Tage-Kalender Exkurs Überwachung der Pünktlichkeit basierend auf einer 7 Tage Woche 4 Tage zu spät Di Mi Do Fr Sa So Mo Di Mi Versprochener Liefertermin Tatsächlicher Liefertermin t Alternativ: basierend auf 2 Fabrikkalendern (Ermittlung der Arbeitstage) 2 Arbeitstage zu spät 1 Arbeitstag zu spät Tu We Th Fr Sa So Mo Tu We Versprochener Liefertermin Tatsächlicher Liefertermin t Tu We Th Fr Sa So Mo Tu We Versprochener Liefertermin Feiertag Tatsächlicher Liefertermin t gibt es einen analytischen Mehrwert durch die Fabrikkalender-Information? Seite 51

52 Zusammenfassung: Bei der Definition der fachlichen Anforderungen muss man Details diskutieren und bei Interessenskonflikten Kompromisse finden Entscheidung treffen über den Einbau impliziter Logik & abgeleiteter Merkmale Die für das Reporting wesentlichen Informationen finden Eine Strategie zum Umgang mit Fehler bzw. Ungenauigkeiten finden Oft gibt es nicht die eine richtige Lösung, die für alle passt Was kann man tun? Optionen sind: - Kompromisse finden - Separate Anwendungen pro Anforderer bzw. Facheinheit bauen - Anwendungen bzw. Datenmodelle so flexible wie möglich bauen Wichtig ist dabei aber immer auch Keep it simple!!! Seite 52

53 Tools Seite 53

54 Wichtiger als schicke Frontend-Tools sind z.b. eine klare Anforderungs-Definition und ein schlüssiges IT Konzept Beim Start von BI Projekten wird oft über Frontend-Tools diskutiert - Facheinheit-Mitarbeiter haben sich z.b. auf Messen oder im Internet informiert und betrachten nun Tool und Anwendungs-Idee als Einheit - Solche Diskussionen sind viel interessanter und spaßiger als z.b. die Anforderungs-Detailanalyse Quelle: images/showcase/dashboard.jpg Organizations tend to throw technology at BI problems. You could have the right tool but it could be doomed to failure because of (e.g.) an absence of executive support Ian Bertram, Gartner global BI manager, 2009 Lenkt bisweilen von den eigentlichen Problemen ab Oft gibt es Rahmenbedingungen (IT-Strategie, Know-how im Unternehmen, etc.) und nur geringe Anzahl von Tools kommt überhaupt in Frage Seite 54

55 Frontend Tool Beispiel: QlikView alle Zahlen fiktiv Seite 55

56 Frontend Tool Beispiel: QlikView alle Zahlen fiktiv Seite 56

57 Der Prototyp Seite 57

58 Die zügige Erstellung eines ersten Prototypen erleichtert die Projektarbeit Sobald die Anforderungen und Konzepte grob geklärt sind, hilft die Erstellung eines ersten Prototypen in den Projektarbeit - Man sieht, worüber man spricht Missverständnisse werden ausgeräumt - Man kann falls nötig jetzt noch gegensteuern (ohne ganz viel Geld verloren zu haben) - Man ist weg von der grünen Wiese (für viele Kollegen ist es einfacher, etwas Bestehendes anzupassen) - Man bekommt ein Gefühl dafür, was technisch möglich ist - Man erreicht einen ersten Projekterfolg Motivation für Projektmitarbeiter, Anforderer und Sponsoren Deshalb gilt immer noch der Spruch: Think big, start small! Seite 58

59 Go Live und was dann... Seite 59

60 Nicht selten wird die Arbeit, die nach dem Go Live ansteht, unterschätzt Nach dem Go Live - stellt man vielleicht fest, dass die Welt nicht auf dieses Tool gewartet hat es wird weniger genutzt als erwartet (ein Weihnachtsgeschenk, das sich niemand gewünscht hat) -... bekommt man erstmals Feedback von den echten Anwendern und stellt dann vielleicht fest, dass man einiges überarbeiten muss Nach dem Go Live - braucht man einen starken Application Owner, der das Change Management organisiert Marketing für die neue Anwendung betreibt (Training organisiert, Vorträge hält, die Anwender informiert und überzeugt) - braucht man weiterhin zumindest einen Teil des Projektteams um eventuell erst jetzt erkennbare Fehler zu korrigieren dringende Änderungswünsche umzusetzen Seite 60

61 Zusammenfassung Seite 61

62 Business Intelligence Projekte in der Praxis: Herausforderungen an Business und IT Business Intelligence klingt einfach, ist es aber nicht! Herausforderungen in BI Projekten - Team muss sich multikulturell (Business und IT) zusammen finden und am gleichen Strick ziehen - Fachliche Anforderungen müssen im Detail diskutiert und verstanden werden und es müssen oft fachlich und IT-technisch Kompromisse gefunden werden - Tools alleine lösen noch keine Probleme - Prototyp ist immer noch der beste Start - Go Live und was dann? beginnt manchmal die Arbeit erst so richtig Seite 62