SOCOMA
  • Home
  • WWPlaner
  • DWH & BI
    • DWH & BI Vorbereitung
      • Projektmanagement
      • Vorgehensmodell
      • Quickcheck
      • Konzeption & Dokumente
      • DWH Architektur
      • BI Architektur
    • MIS
    • ORACLE BI EE 11g Praxis
      • Installation OBIEE 11g
      • Berechtigungen
      • Sitemap
      • Dialog Act as
      • Javascript
      • Custom Link
      • Schaltjahr
      • Active Directory
      • GUIDs
      • Custom Layout
  • Impressum
  • Datenschutzerklärung

Quickcheck

Details
Geschrieben von Steffen Thorn
Kategorie: DWH & BI
Veröffentlicht: 11. Juli 2018
Zugriffe: 139

Seriöse DWH/BI Dienstleister sollten ihren Kunden immer einen BI-Quickcheck anbieten und ich kann Firmen (Kunden) nur empfehlen dies anzunehmen und auch zu finanzieren.

Dieser Invest rechnet sich für beide Seiten!

 

Was ist der Quick Check?

Ein Quick Check ist ein strukturierter Workshop gemeinsam mit dem Kunden. In dem Workshop werden die Ziele und Strategien des Kunden beschrieben und auf Ihre Machbarkeit geprüft. Anhand der Ergebnisse werden qualitative und quantitative Maßnahmen beschrieben. Der Kunde erhält somit ein Lösungsprofil zur Planung der zeitlichen Umsetzung, des Budgets und der erforderlichen Komponenten. Die Ergebnisse werden in Form eines Grobkonzepts dokumentiert und dem Kunden präsentiert.


Quick Check - Topics


Kick Off Workshop: Evaluierung einer IT-Anforderung
Analyse der Geschäfts- und IT-Strategie
IST/SOLL–Analyse 
Lösungsbeschreibung
Ergebnis Workshop
Übergabe eines Grobkonzepts

 

Aufbau eines Quickcheck-Konzept

Im folgenden zeige ich eine grobe Struktur für ein Quickcheck-Konzept auf:

Einleitung

Ausgangssituation

Strategie & Zielsetzung des BI-Vorhabens

Relevante Geschäftsprozesse

Organisation

Abhängigkeiten Geschäftsprozesse und Organisation

Anforderungen

Berichtswesen

Kennzahlen

Dimensionen

Datenvolumen

Berechtigungsstruktur

Nicht fachliche Anforderungen

Präsentationstools

Export

Mehrsprachigkeit

Rahmenbedingungen

NO GOs und „Fettnäpfchen“

Ergebnisse

Architekturvorschlag

Projektplanung

Maßnahmenplanung

Kundennutzen

Geschätzte Dauer des Projektes

Zeitplanung

Ressourcenplanung

Budgetplanung

Projektorganisation

Konzepte/Dokumente

Details
Geschrieben von Steffen Thorn
Kategorie: DWH & BI
Veröffentlicht: 11. Juli 2018
Zugriffe: 133

Die Konzeption und Dokumentation ist ein wesentlicher Bestandteil eines IT Projektes und sollte nicht vernachlässigt werden. 
Folgende Konzepte/Dokumente müssen in einem DWH/BI Projekt erstellt werden:

Auftraggeber zu erstellen:

Pflichtenheft
Datenschutzkonzept


Auftragnehmer zu erstellen:

Anforungsdokument
Berechtigungskonzept
Prozess-Analyse
Detail-Design-Konzept
Schnittstellen-Konzept (Input)
Schnittstellen-Konzept (Output)
Projekthandbuch

 

Anforderungsdokument

In dem Anforderungsdokument wird die Anforderung aus Sicht der IT nochmals detailiert beschrieben und sollte vom Auftraggeber abgezeichnet werden.

Beispiel Agenda:

Allgemeines/Ziel
Ziel
Fachliche Anforderung
  Beschreibung der Anforderung
  Ist-/ Soll-Analyse
Realisierungsvorschlag
Beschreibung der Prozesse
Vereinbarungen/ Absprachen
  Lieferzeiten
  Mengenangaben
Abnahme

 

Prozess-Analyse

Bei Einführung einer neuen IT unterstützten Lösung macht es oft Sinn die existierenden Prozesse zu analysieren und in Verbindung mit dem neuen IT-Systems zu optimieren.

Beispiel Agenda:

Hintergrund und Ziele
  Kontext und Hintergrund
  Ziel
  Geschäftsvorteile
  Risiken
  beteiligte Organisationseinheiten
  Anforderung
  Abgrenzung
Relevante Fakten und Annahmen
   Externe Faktoren
   Interne Faktoren
   Abhängigkeiten
Prozess: Ist-Analyse
    Überblick über die aktuelle Situation
Prozess: Zielanalyse
Nicht-funktionale Anforderungen
   Funktionalität
   Zuverlässigkeit
   Leistungsfähigkeit
   Wandelbarkeit
   Randbedingungen

 

Detail-Design-Konzept

Das DD-Konzept ist in der Regel das umfangsreichste Konzept. Hier wird die komplette technische Datenverarbeitung für ein DWH oder für das BI beschrieben. BI 

Beispiel Agenda für ein DWH:

Allgemeines
Bezugsdokumente
  Fachliche Dokumentation
  Schnittstellenbeschreibungen zu Quell- und Referenzdateien
Allgemeine Beschreibung der ETL-Prozesse
  Gesamtübersicht: Prozess
  Gesamtübersicht: Zeitlicher Ablauf
  Mengenangaben
  Startbedingungen und Abhängigkeiten
     Technische Startbedingungen
     Initial-Startbedingungen
     Abhängigkeiten
Datenverarbeitung
  Staging-Ebene
  Transformationen-Ebene
  Befüllung der Output-Tabelle oder DataMart
  Abschluss-Prozess
  Wiederaufsatzmechanismen
  Freigabe


Schnittstellen-Konzept (Input/Output)

Ein Schnittstellendokument ist eine bindende Vereinbarung zwischen Quell-System und Ziel-System.
Eine schriftliche Abnahme ist zu empfehlen.

Beispiel Agenda:

Gültigkeit
  Fachliche Dokumentation
  Schnittstellendateien
Beschreibung der Schnittstelle
  Inhalt
  Mengen
  Dateiformat
  Datentypen
  Schnittstellendatei
    Datensatzbeschreibung
Fehlerbehandlung
Lieferverfahren
Übergabemodalitäten
Wiederholungslieferungen
Ansprechpartner
Lieferzeitpunkt
Abschluss der Vereinbarung



DWH/BI Vorbereitung

Details
Geschrieben von Steffen Thorn
Kategorie: DWH & BI
Veröffentlicht: 11. Juli 2018
Zugriffe: 194

Data Warehouse (DWH) und Business Intelligence (BI) ist kein fertiges Produkt/Tool, sondern es beschreibt ein Verfahren/Prozess zur Speicherung/Auswertung von Informationen. Entsprechend müssen produktunabhängige Vorbereitungen durchgeführt werden, damit die Einführung von DWH/BI zum erfolgt wird.

Die Einführung von DWH/BI ist ein Projekt.

Das richtige Projektmanagement und das korrekte Vorgehensmodell sollten vorhanden sein. Ziele müssen beschrieben werden, d.h. Konzeption ist die Voraussetzung. Die DWH-Architektur und BI-Architektur sollte man kennen und mit seiner Infrastruktur abstimmen.

Sind alle obigen Vorausetzungen erfüllt wird das passende Produkt/Tool evaluiert.

DWH Architektur

Details
Geschrieben von Steffen Thorn
Kategorie: DWH & BI
Veröffentlicht: 11. Juli 2018
Zugriffe: 273

Ein Data Warehouse ist ein großer Datentopf, in dem alle geschäftsrelevante Daten aus beliebig unterschiedlichen operativen und auch dispositven Datenhaltungssysteme denormalisiert vorliegen. In operativen Datenbank-Systemen wird versucht Redundanz der Daten zu vermeiden, es wird normalisiert. Die Zielsetzung eines Data Warehouse verfolgt das Ziel Daten für das Reporting optimal zur Vefügung zu stellen, es wird denormalisiert.

Das folgende Diagramm zeigt eine klassische Data Warehouse Architektur.

 

Im Zusammenhang mit einem Data Warehouse wird oft über ETL oder ELT Verarbeitung gesprochen.

E - Extraktion

T - Transformation

L - Laden

In der Extraktionsphase werden Daten aus den Quell-Datenbanken in ein Data Warehouse geladen. Im nächsten Schritt erfolgt die Transformation der Daten, d.h. Konvertierungen, Berechnungen und Datenqualitätsprüfungen werden durchgeführt. Im letzten Schritt beim Laden werden Fakten und Dimensions-Tabellen aufgebaut und in ein Star-Schema gebracht.

 

Tipp:

Im Vorfeld sollte man sich über eine Nomenklatur für Tabellen, Spalten, Foreign-Keys einigen:

S_ - Staging-Tabellen, T_ - Transformationstabellen, R_ - Referenztabellen, H_-Hiestorisierungstabellen, D_- Dimensionstabellen und F_- Faktentabellen.

Tipp:

Es ist Sinnvoll für jede Tabelle zusätzliche Spalten wie Anlagedatum, Geändertdatum und Batchlauf-ID hinzuzufügen. Über eine Batchlauf ID die am Anfang eines Ladeprozesse vergeben wird, lassen sich Fehlersuchen und ein Rollback einfacher durchführen.

 

Datenquellen

Operative Datenquellen sind z.B. ERP-, CRM- oder BDE-Anwendungen. Dispositive Datenquellen ist z.B. Excel.

Die größte Herausfoderung beim Aufbau eines Data Warehouse ist es, die Quell-Systeme zu identifizieren und anzubinden, herauszufinden in welchen Tabellen sich die Daten befinden und in welcher Relation. Dieser Schritt nimmt erfahrungsgemäß die meiste Zeit in Anspruch.

 

Extraktion

In der Extraktions-Verarbeitung werden die Quelle-Datenhaltungssysteme angebunden und die Daten 1:1 in die Staging-Ebene geladen. Die Anbindung kann über Datei-Import, Datenbank-Links ODBC oder JDBC erfolgen. Oft wird der Flat-File Import aus Sicherheitsgründen bevorzugt.

Eine Validierung, z.B. Datentyp/Länge-Prüfung, der Daten sollte hier nicht stattfinden, d.h. die Spalten der Staging-Ebene sind alle vom Datentyp VARCHAR mit einer großen Länge.

 

Transformation

In der Transformations-Verarbeitung wird die Daten qualitativ für das Reporting aufbereitet. Dazu müssen folgende Schritte durchgeführt werden:

1) Datenqualitäts Prüfung

-> technische Prüfung: stimmt der Datentyp und die Länge

-> fachliche Prüfung: sind alle Daten und ihre Beziehungsdaten vorhanden, z.B. Stammdaten, Master-Detail-Beziehungen

2) Konvertierungen, z.B. Umwandlung des Datumsformat oder Währungsumrechnung

Des Weiteren werden oft Referenz-Tabellen benötigt, um z.B. Daten aus zwei Quellen in Beziehung zu setzen, wie beim Master Daten Management MDM oder um spezielle Gruppierungsebenen die das Reporting fordert hinzuzufügen.

3) Aggregation, Daten werden auf eine Auswertungsebene Ebene aggregiert. Dies reduziert die Datenmenge und fördert die Abfrageperformance.

 

Laden

Die letzte Verarbeitung ist das Laden. Beim Daten werden Dimensionstabellen und Faktentabellen gefüllt. Eine Dimension ist eine Auswertungsebene z.B. Zeit, Region, Produkt oder Kunde. Die Faktentabellen beinhalten die Kennzahlen, beschreibene Informationen und die Foreign-Keys zu den Dimensionstabellen.

Für die Dimensions- und Fakten-Tabellen sollte zusätzlich der "Natural-Key" gespeichert werden. Der Natural-Key ist der PK-Schlüssel aus dem Quell-System. Bei Aggregationstabellen ist das hinterlegen eines Natural-Key nicht immer möglich.

Oft werden für Fachbereiche eigene Fakten-Tabellen erstellt und in einem separaten Datenbereich gestellt, dies wird als Data-Mart bezeichnet. Mehrere Data-Marts nutzen in der Regel die gleichen Dimemsionen.

 

Historisierung

Eine Historisierung dient zum protokollieren von Datenzuständen. Ändert sich z.B. die Farbe eines Produktes, kann dies durch eine Historisierung nachvollzogen werden und es können auch die Auswertungen über einen älteren Zeitraum auf die damals gültige Farbe erstellt werden.

Eine Historisierung der Daten kann auf jeder Ebene durchgeführt werden. Hier entscheidet die Anforderung. Historisiert wird in der Regel über einen begrenzten Zeitraum z.B. 24 Monate. Eine Speicherplatzberechnung (Anzahl Daten * Bytes pro Datensatz) ist unbedingt notwendig, da sonst das existierende Storage schnell voll ist.

BI Architektur

Details
Geschrieben von Steffen Thorn
Kategorie: DWH & BI
Veröffentlicht: 11. Juli 2018
Zugriffe: 152

Eine Business Intelligence (BI) Software konzentriert sich darauf Daten so aufzubereiten, dass sie für den Benutzer (Consumer) in einfacher Weise abrufbar sind.

Welche Vorteile ergeben sich aus einem BI-Tool?

Optimierung Ihrer Performance

Frühzeitiges Erkennen von Marktveränderungen
Engere Beziehungen zu Kunden, Partnern und Lieferanten
Höhere Mitarbeiterproduktivität
Schneller Zugriff auf Informationen

Höherer Unternehmenswert

Ad hoc-Zugriff auf zeitkritische Infos
Identifikation neuer Umsatzpotenziale
Verbesserung der Kommunikation und der gemeinsamen Planung
Entscheidungen auf Grundlage von Wissen statt Vermutungen
Kostenreduktion für Reporting und
ständigen dezentralen Abgriff von Daten
Bessere Transparenz und höhere Effizienz von Prozessen

 

Bevor man anfängt eine BI Software zu installieren, ist es wichtig die BI-Architektur zu kennen und entsprechend auf sein Unternehmen abzustimmen.

Die folgende Abbildung zeigt eine klassische BI-Architektur:

Beginnend im Unternehmen stehen die Prozesse. Prozesse produzieren Informationen, diese werden in beliebigen Datentöpfen abgelegt. Es handelt sich dabei um externe Daten, operative Daten und dispositive Daten.

Für eine einheitliches Reporting bietet es sich an ein Data Warehouse aufzubauen. Hier werden dann alle Informationen aus unterschiedlichsten Datenquellen zeitversetzt gesammelt.

In der Informationsschicht und Präsentationschicht kommt nun die BI-Software (in der Regel eine Server Software) zum Einsatz.


 

Informationschicht

In der Informationschicht werden nun folgendene 3 Punkte erledigt:

1) Physikalische Anbindung der Datenquellen (Data Warehous oder operative Datenbanken für echtzeit Analysen)

2) Aufbau der Geschäftslogik (Dimension & Fakten, Cubes, Aggregationen, Berechnungen, Drill-Down-Logik)

3) Bereitstellung für die Präsentationschicht (Zugriffberechtigungen & Einteilung in Fachthemen, DataMarts)

Eine BI-Software dient nicht zur Datenhaltung! Alle in Punkt 1 bis 3 durchgeführten Arbeiten werden in Meta-Daten gespeichert.

Die obigen Punkte werden in der Regel von der IT-Abteilung aufgebaut und verwaltet.

 

Präsentationschicht

Die Präsentationschicht ist letztendlich die Interkation zwischen Benutzer und Meta-Daten.

Bei Ausführung eines Berichts erstellt das BI-Tool, basierend auf der Logik in den Meta-Daten, einen Datenbank-SELECT. Das Ergebniss wird dann an die GUI zurückgesendet und angezeigt.

BI-Tools stellen diverse leistungsfähige Werkzeuge zur Verfügung:

- schnelles und einfaches Erstellen von Berichten (AdHoc-Reporting)

- Ablegen der Berichte in ein Dashboard/Cockpit

- ereignisgesteuertes verteilen von Berichten

- Offline Reporting

- zahlreiche Export-Möglichkeiten

- MS Office Integration (Word, Excel, Powerpoint)

- Mobile Solution

- Lösungsunterstützung für spezielle Anforderungen, z.B. Balance Scorescard

 

Aus einem BI-Tool ergeben sich für das Unternehmen folgende technische Vorteile:

- Synchronisierter Abgriff von Daten
- Homogenisierung und Konsistenzsicherung
- Unternehmensweit standardisierte Informationsobjekte (einheitl. Benennung, …)
- Bereitstellung homogener und konsistenter Informationen (inkl. Berechtigung) 
- Breite Palette an verwendbaren Frontends und Devices
- Anreicherung operativer Systeme durch relevante Informationen
- Zentrale Steuerung

 

  1. Einleitung DWH & BI