<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=412841&amp;fmt=gif">

Wie Ihr BI-Projekt erfolgreich wird, wenn Sie einige Regeln beachten

30.01.2018  •  Business Intelligence & Cloud

Für die Realisierung größerer Datawarehouse Umgebungen wollen wir mit Hilfe dieses Blogeintrags eine kurze Handlungsempfehlung für ein BI-Projekt unter Berücksichtigung der bekannten Problemfelder wiedergegeben

Starten wir mit den üblichen Problemfelder einer Organisation ?

  • Anstieg von Kundenanforderungen sowie gesetzlichen Anforderungen
  • komplexere und größere Datenmengen aus verschiedene Systemen
  • Unternehmensdaten sind schwer kombinier- und auswertbar
  • hohe Investitions- und Betriebskosten
  • Bildung von Schatten – IT

Finden Sie sich hier wieder? Wir schon, diese Probleme treten in irgendeiner Form immer auf und fallen uns innerhalb der einzelnen Projektphasen des BI-Projekt immer wieder auf die Füße.

Auch wenn die hier vorgestellten Empfehlungen in der Regel allen Projektbeteiligten bekannt sind, werden diese in den Projekten leider nicht immer gelebt. Aus diesem Grund haben wir eine kurze Handlungsempfehlung erstellt, um sich im Vorfeld die richtigen Fragen zu stellen.

BI Projekt - AGILES Vorgehen vs. IT Architektur

  • Ein agiles Projektvorgehen muss auch in der zukünftigen Architektur berücksichtigt werden, d.h. Datenbereitstellung, Self Services Gedanke oder Modellierungsansätze etc. müssen für agile Anforderungen geeignet sein.
  • Eine starre bzw. systemgestützte Architekturvorgabe, die sicherlich Ihre Vorteile aufweist, kann in diesen Fällen kontraproduktiv sein und den agilen Gedanken behindern.
  • Ein weiter Aspekt ist der Umsetzungsumfang – die geplante Architektur kann zwar das große „Big Picture“ enthalten, jedoch sollte die Umsetzung nur kleine Teilbereiche beinhalten (also keine 800 Kennzahlen auf einmal umsetzen) und Zwischenergebnisse immer den Fachbereich zeitnah präsentieren – positive Konsequenz: die Fachbereiche fühlen sich von Anfang an ernst genommen und die Akzeptanz steigt deutlich

IT Maßnahmen – Einführung neuer Technologien

  • Eine von der IT getriebenen Architektur sollte nicht den Endkunden (Fachbereich) außer Acht lassen und diesen von Anfang mit einbinden – besser noch immer den „Top Down“ Ansatz wählen
  • den Blick über den Tellerrand wagen, d.h. Fachbereiche sind nicht immer bereit alle Informationen preis zu geben, diese sind aber für das Gesamtbild relevant. Fachbereiche sind in der Regel sehr kreativ, um Ihre Anforderungen umzusetzen. Es ist nicht ausreichend nur die Datenbereitstellung zu beachten. Fachbereiche veredeln Ihre Daten weiter und bilden damit eine parallele Schatten IT ab. (z.B. Berechnung neuer Kennzahlen in den Berichten, Aufbau neuer Logiken, Einbindung weiter Quellen etc.)
  • Verständigung von IT und Fachbereichen – sogenannte „Buzzwords“ (z.B. Big Data, Dimension, Realtime etc.) erschweren die Zusammenarbeit. Jeder interpretiert diese im Kontext anderes. Wichtig ist im Vorfeld eine einheitliche Sprachdefinition zu bestimmen, die übergreifend gültig ist. Damit werden von Anfang Verständnisprobleme aus dem Weg geräumt. Ggf. helfen hier auch geeignete Schulungsmaßnahmen

Datenanforderung – und bereitstellung

  • Alle Datenanforderungen, egal auf welche der Arten (z.B. Vorstudien, Fachinterviews, Analyse von Berichten, Erstellung von Fachmodellen) die identifiziert wurden, sollten in einen allgemein gültigen Kennzahlenkatalog einfließen.
  • Fachbereiche sollten aufgefordert werden, eine genaue fachliche Definition der Kennzahlen und Merkmalen in diesem Katalog zu hinterlegen, diese kann später in den semantischen Layer (z.B. SAP BO Universen, SAP HANA Calculation View) zum besseren Verständnis hinterlegt werden.
  • wiederholte Kennzahlenberechnungen gehören nicht ins Berichtswesen – führen nur zur Mehraufwänden in der Berichtserstellung und –wartung
  • Dieser Katalog ist die wesentliche Dokumentation der Datenanforderungen und die wichtigste Grundlage für das fachliche Design.
  • Einbindung der Quellverantwortlichen – diese Personen müssen im Projekt berücksichtigt werden, da diese als „Know How“ - Träger die Datenforderungen der Endkunden erfüllen können.
  • Batchlaufzeiten, Sollstellungen etc. müssen berücksichtigt werden – Stichwort Realtime – ggf. sind die Datensätze an dispositive System noch nicht Übergabefähig, dies muss beim Einsatz von Realtime betrachtet werden

Was ist mein wirtschaftlicher relevanter Datenbestand?

Eine zukünftige Datawarehouse Umgebung abei auch ein Data Lake muss sich im Vorfeld mit bestimmten Kriterien befassen - wie z.B.

  • Zeitpunkt des Datenabzugs
  • Definition des wirtschaftlichen Bestandes

Die Frage ist damit weniger, mit Hilfe welcher Kennzahlen Bestand- und Bestandsbewegung beschrieben werden, sondern wie diese Kennzahlen ermittelt werden.

Bestandsbetrachtungen (Snapshot Gedanke) sind stichtagbezogen. Zu einem vorgegebenen Zeitpunkt wird der in einem System verwaltete Bestand analysiert und diese Analyse dokumentiert (z.B. in Form einer Datei). Bei dieser Analyse werden alle Datensätze zu einem Geschäftsvorgang, die sich auf eine bestimmte Art und Weise abgrenzen lassen, betrachtet. Einzelne Kennzahlen können dabei direkt aus den Quelldatensätze entnommen werden, andere werden auf Basis dieser Daten berechnet. Der Betrachtungszeitpunkt ergibt sich aus sowohl fachlichen als auch technischen Vorgaben. So wird in der Regel eine solche Bestandsbetrachtung nach einem Sollstellungstermin erfolgen.

Letztendlich hängt der Zeitpunkt aber von dem Start des entsprechenden Analyseprogramms ab. Bewegungsbetrachtungen sind Zeitraumsbetrachtungen.  Aus fachlicher Sicht wird typischerweise der Zeitraum zwischen zwei Sollstellungen betrachtet. Da die einer Bewegung zugrundeliegende Transaktion im Allgemeinen mit einem Zeitstempel versehen ist, kann dieser Zeitraum auch besser als bei der Stichtagsbetrachtung abgegrenzt werden.

Die Bewegungen bieten die Möglichkeit einer Kontrolle der Bestandsführung anhand der folgenden Formel:

(Bestand Ende Monat x + Bewegungen im Monat (x+1) = Bestand Ende Monat (x+1))

Die Rechnung kann aber nur dann aufgehen, wenn die beiden jeweiligen Zeitpunkte der Stichtagsbetrachtung genau den Bewegungszeitraum abgrenzen und die Analyse des Bestands dieselben Abgrenzungen verwendet wie die Analyse der Bestandsbewegung.

Wichtig für die Analyse der Bewegungen ist eine Einteilung dieser Bewegungen in Bewegungsarten. Dies passiert oft in mehreren Schritten. Innerhalb des Bestandsverwaltungssystems werden die einzelnen Transaktionen mit Hilfe mehrerer Parameter untersucht und dann daraus Bewegungsarten abgeleitet.

Die Frage die nun gestellt werden sollte, liefert das entsprechende Bestandsystem diese oben beschriebene Logik oder muss die Bestimmung der Bestandsbewegung in den zukünftigen Layern umgesetzt werden. Wenn nein, sollte ein entsprechender hoher Aufwand für die Umsetzung eingeplant werden.

30.01.18 Swen Göllner