BI-Begriffe

Costcenter versus Profitcenter

Cost Center (Kostenstelle)

  • Hauptziel: Ein Cost Center ist eine Abteilung oder ein Bereich innerhalb eines Unternehmens, der keine direkten Umsätze erwirtschaftet. Sein Hauptziel ist es, die ihm zugewiesenen Aufgaben innerhalb eines vorgegebenen Budgets zu erfüllen und die Kosten zu kontrollieren und zu minimieren.
  • Verantwortung: Die Leitung eines Cost Centers ist für die Einhaltung des Budgets und die Effizienz der Kosten verantwortlich, nicht jedoch für die Erzielung von Gewinnen.
  • Messung des Erfolgs: Der Erfolg eines Cost Centers wird daran gemessen, wie gut es seine Kosten im Griff hat, sein Budget einhält und die geforderten Leistungen (oft interner Natur) in der gewünschten Qualität erbringt.
  • Beispiele: Typische Beispiele für Cost Center sind Abteilungen wie die Buchhaltung, die Personalabteilung, die IT-Abteilung, die Forschungs- und Entwicklungsabteilung oder der Kundendienst (obwohl dieser manchmal auch als Profit Center geführt werden kann). Diese Abteilungen verursachen Kosten, sind aber notwendig für den Gesamtbetrieb des Unternehmens.

Profit Center (Gewinnzentrum)

  • Hauptziel: Ein Profit Center ist eine Unternehmenseinheit, die sowohl für ihre Kosten als auch für ihre Erträge (Umsätze) verantwortlich ist. Das Hauptziel ist die Maximierung des Gewinns.
  • Verantwortung: Die Leitung eines Profit Centers hat eine weitergehende Verantwortung. Sie muss nicht nur die Kosten im Blick haben, sondern auch aktiv dafür sorgen, dass Umsätze generiert werden, die die Kosten übersteigen und somit einen Gewinn für das Unternehmen erwirtschaften. Profit Center agieren oft wie eigenständige kleine Unternehmen innerhalb des Gesamtunternehmens.
  • Messung des Erfolgs: Der Erfolg eines Profit Centers wird direkt an seinem Ergebnis gemessen, also am erzielten Gewinn oder Deckungsbeitrag.
  • Beispiele: Beispiele für Profit Center können Produktlinien, Geschäftsbereiche, einzelne Filialen oder Vertriebsregionen sein. Diese Einheiten haben oft direkten Marktzugang und können ihre Leistung direkt in Form von Verkaufszahlen und erwirtschafteten Gewinnen messen.

Zusammenfassend lässt sich sagen:

Merkmal Cost Center Profit Center
Hauptfokus Kostenkontrolle, Einhaltung des Budgets Gewinnmaximierung
Umsatzerzielung Nein (oder nur indirekt) Ja, direkte Umsatzerzielung
Verantwortung Kosten Kosten und Erträge (Gewinn)
Erfolgsmessung Einhaltung von Budgets, Kosteneffizienz Erzielter Gewinn, Deckungsbeitrag
Orientierung Intern auf unterstützende Funktionen Extern auf den Markt und Kunden

Die Entscheidung, ob eine Abteilung als Cost Center oder Profit Center geführt wird, hängt von der Strategie und der Struktur des Unternehmens ab. Beide Konzepte dienen dazu, die Verantwortlichkeiten klar zuzuordnen und die Leistung der einzelnen Bereiche besser steuern und bewerten zu können.

Datensilos: Was sind sie und wie geht man mit ihnen um?

Was sind Datensilos?

Ein Datensilo ist ein Quelle fester Daten, das unter der Kontrolle einer Abteilung bleibt und vom Rest des Unternehmens isoliert ist. Sie entstehen in der Regel, wenn ein Team eine Lösung erstellt, die einem einzigen Zweck oder einer Gruppe von Zwecken im Zusammenhang mit einem einzigen Thema dient.

Diese Lösung ist nicht mit anderen Teilen des Unternehmens verbunden und isoliert. Ein gutes Beispiel ist eine Datenbank mit Marketing-Leads, die nicht mit der zentralen Kundentabelle im Data Warehouse verknüpft ist.

Wozu können Datensilos führen?

Wenn Datensilos nicht rechtzeitig aufgelöst werden, erhält man im besten Fall kein vollständiges Bild. Man erhält Daten, die nicht so wertvoll sind, wie sie sein könnten, weil sie für andere Teams nicht zugänglich und nicht mit anderen Daten oder Tools im Unternehmen integriert sind.

Wenn Sie beispielsweise die Daten Ihres Vertriebs- und Kundensupportteams zusammenführen, können Sie die Gründe für die Kundenabwanderung erfahren oder andere Kundenaktivitäten ermitteln, die Ihrem Unternehmen potenziell helfen können.

Eine geringere Datenintegrität (da Sie mit mehreren Kopien von Datenbanken arbeiten, die sich überschneiden), eine geringere Datensicherheit und eine geringere Produktivität der Entwickler.

Wie geht man mit Datensilos um?

Eine Antwort auf Datensilos könnte die Zentralisierung von Daten sein – ein Konzept, das lange Zeit als heiliger Gral für Datenteams galt. Eine zentralisierte Datenbank, die verschiedene Lösungen, Tools und Unternehmensebenen miteinander verbindet und an einem Ort gepflegt und verwaltet wird, klingt für viele Unternehmen sehr verlockend.

Heutzutage beginnen Experten jedoch, die Ziele und die Durchführbarkeit der Datenzentralisierung in Frage zu stellen und stellen fest, dass sie sich für die meisten Unternehmen als schwer realisierbar erwiesen hat, und betrachten sie sogar als einen ziemlich altmodischen Ansatz für die Datenverwaltung, denn:

Ein gut gepflegtes, zentralisiertes Data Warehouse ist sehr komplex und schwer zu realisieren,
es führt zu großen monolithischen Lösungen, die den Arbeitsablauf der Teams einschränken,
es kann zu einem überspezialisierten Silo führen.

Experten bezeichnen das Data Mesh als einen weitaus vorteilhafteren und praktischeren Ansatz für die Gestaltung und Entwicklung von Datenarchitekturen. Dieser Begriff umschreibt mehrere Data Warehouses in einem Unternehmen, die miteinander verbunden sind und zusammenarbeiten.

In diesem Artikel gehen wir näher darauf ein, was Datensilos sind, was sie verursacht und warum sie schlecht für Ihr Unternehmen sind. Wir erläutern auch die Vorteile von Data Meshes im Detail und zeigen, wie Apache Airflow in dieses Bild passt.

Was sind die Ursachen für Datensilos in einem Unternehmen?

Um das Problem der Datensilos zu lösen, müssen Sie zunächst verstehen, was sie verursacht. Hier haben wir die 4 häufigsten Gründe für Datensilos zusammengestellt:

1. Überlastetes zentralisiertes Datenteam

Damit etwas funktioniert, braucht es Zeit. Wenn Ihr zentrales Datenteam überlastet ist, hat es möglicherweise nicht die Zeit auf jede neue Datenanfrage zu reagieren.

Andere Teammitglieder haben vielleicht Daten, die sie für wertvoll halten und die bereinigt und rationalisiert werden müssen und sie wollen (oder können) nicht darauf warten, dass diese Daten zu den vorhandenen ETL- und Lagerverfahren hinzugefügt werden. Also fangen sie an, die Sache selbst in die Hand zu nehmen.

Da Sie wahrscheinlich hoch qualifizierte und talentierte Mitarbeiter an Bord haben, werden sie eine vernünftige Lösung finden. Dabei handelt es sich jedoch um eine Einzellösung, die nicht in die übrigen Tools und Datenbanken des Unternehmens integriert ist. Ohne eine breitere Perspektive und großes systemisches Denken enden Sie mit Datensilos.

2. Verschiedene, nicht miteinander verbundene Datenbanken

Verschiedene Datenbanken neigen dazu, unterschiedliche Standards zu verwenden, und die Daten, die sie gemeinsam haben, stimmen möglicherweise nicht genau überein. Die Integration all dieser Datenquellen kann ausufernd werden. Je mehr unverbundene Datenbanken Sie haben, desto schwieriger wird es, die Daten zu katalogisieren, sie auf dem neuesten Stand zu halten und schließlich den Überblick über die Wahrheit zu behalten.

3. Veraltete oder falsche Tools für die Sammlung und Analyse von Daten

Eine Excel-Datei ist kein guter Ort, um Ihre Daten zu speichern und zu organisieren. Das mag offensichtlich erscheinen, ist aber ein häufigeres Problem, als Sie vielleicht denken. Außerdem verwenden einige Unternehmen möglicherweise ältere Tools, die nicht alle ihre Anforderungen erfüllen. Um Ihr Unternehmen skalierbar zu machen, müssen Sie in der Lage sein, Ihre Daten auf automatisierte, effiziente Weise zu verwalten und sich dabei auf moderne Tools für die Datenorchestrierung verlassen.

4. Ineffiziente Kommunikation und Unternehmenskultur

Um auf die Teams zurückzukommen, die an ihren eigenen Lösungen arbeiten… es ist nicht ihre Schuld. Wenn es an der Kommunikation zwischen den Führungskräften mangelt, wissen die Teammitglieder möglicherweise nicht einmal, dass es im Unternehmen zentralisierte Tools gibt, die sie nutzen sollten. Ein perfektes Beispiel dafür, dass ein Informationssilo ein Datensilo verursacht.

Warum Datensilos schlecht für Ihr Unternehmen sind

Wir alle wissen, dass Datensilos schlecht für das Geschäft sind, aber wissen Sie auch, wie genau sie Ihr Unternehmen beeinflussen? Natürlich können die negativen Auswirkungen von Datensilos von Unternehmen zu Unternehmen unterschiedlich sein, aber in diesem Artikel haben wir die häufigsten aufgeführt.

Geringere Datenintegrität

Datensilos führen dazu, dass Sie mehrere Kopien von Datenbanken haben, die sich überschneiden. Doppelte Daten führen zu verpassten Möglichkeiten, bessere und fundiertere Schlussfolgerungen zu ziehen. Mit anderen Worten: Es ist schwer, Ihren Daten zu vertrauen.

Kompromittierte Datensicherheit

Wenn Sie Ihre Daten in einer Excel-Datei aufbewahren oder sich auf unterschiedliche Datenquellen verlassen, können Sie nicht angemessen in verschiedene Sicherheitsebenen investieren. Unternehmen, die nicht in der Lage sind, eine umfassende Datensicherheit zu gewährleisten, haben es schwer, das Vertrauen ihrer Kunden aufrechtzuerhalten und auf dem wettbewerbsorientierten Markt zu bestehen.

Geringere Teamproduktivität

Datensilos führen zu Missverständnissen und einer schlechteren Zusammenarbeit zwischen Teams. Anstatt sich auf die Analyse von Daten zu konzentrieren, fundierte Schlussfolgerungen zu ziehen und das Unternehmen wachsen zu lassen, verschwenden Ihre Ingenieure ihre Zeit damit, herauszufinden, welche Daten wahr sind, wie sie eine gemeinsame Sprache finden können und warum ihnen bestimmte Informationen fehlen.

Datenzentralisierung oder Datennetz? Wie man Datensilos beseitigt

Bislang war die beliebteste Antwort auf die Beseitigung von Datensilos die Zentralisierung von Daten. Und es überrascht nicht, dass die Idee einer zentralen Datenbank, die verschiedene Lösungen, Tools und Ebenen des Unternehmens miteinander verbindet und an einem Ort gepflegt und verwaltet wird, sehr verlockend klingt und potenziell viele Vorteile mit sich bringen kann, z. B.:

  • Leichtere Handhabung für Entwickler
  • Leichtere und bessere Berichterstellung
  • Vereinheitlichung der Daten, die in verschiedenen Teams des Unternehmens verfügbar sind
  • Effizientere Datenverwaltung
  • Bessere Zusammenarbeit zwischen Teams
  • Mehr Sicherheit

Heutzutage befasst man sich jedoch eingehender mit der Datenzentralisierung und stellen fest, dass sie eine etwas altmodische Herangehensweise an die Datenverwaltung darstellt.

Monolithischen Lösungen – die zentrale Datenplattform

Und warum? Erstens ist ein gut verwaltetes, zentralisiertes Data Warehouse sehr komplex und schwer zu erreichen. Die Integration all dieser Daten in eine zentrale Datenbank dauert in der Regel Jahre.

Man verfolgt den Ansatz Daten an einem Ort zu zentralisieren, um nützlich und wertvoll zu sein. Das führt zu großen monolithischen Lösungen, die in der Praxis eher einem Datensumpf gleichen.

Da Teams durch diese monolithischen Lösungen eingeschränkt werden, versuchen sie, sie in kleinere, integrierte Teile aufzuteilen, in der Regel um technische Modi (z. B. Ingest, Process, Serve). Auf diese Weise werden die Teams um die Aufgaben und nicht um Anwendungsfälle oder Funktionen herum zerlegt.

Das ist eine schlechte Nachricht, denn Anwendungsfälle und Funktionen lassen sich in der Regel nicht in solch übersichtlichen Kästchen unterteilen – meistens überschneiden sie sich.

Zweitens führen zentralisierte Datenplattformen und monolithische Systeme zu einem überspezialisierten Silo. Das kann passieren wenn ein Unternehmen über hochspezialisierte Datenteams verfügt das maßgeschneiderte Lösungen entwickelt, die es unzureichend teilt. In diesem Fall steht die Lösung im Raum zwischen den Leuten die sie erstellen und jenen Endnutzer, die die Lösung brauchen. Sozusagen Insellösungen, die auf keiner Karte verzeichnet sind und nach einem meist einmaligen Anwendungsfall in Vergessenheit geraten.

Data Mesh – das Datengeflecht

Ein weitaus realistischerer, modernerer und vorteilhafterer Ansatz ist ein sogenanntes Data Mesh, das eine neue Art der Gestaltung und Entwicklung von Datenarchitekturen beschreibt.

Der Schwerpunkt liegt dabei auf mehreren Data Warehouses in einem Unternehmen, die miteinander verbunden sind und zusammenarbeiten. Die Idee ist, dass Sie immer noch eine zentralisierte Governance und Standards haben, aber auch mehrere Zentren, die mit zentral verwalteten Datenflüssen (Pipelines) miteinander vernetzt sind.

Wie ETL-Orchestrierung helfen kann

Die Lösung ist ein Framework für die Datenorchestrierung, ein steuerbares Netzwerk miteinander verbundener Datenflüsse. Hierdurch können Sie die Integration mehrerer Plattformen, Tools, Anwendungen und Datenbanken aktiv steuern.

Wenn Sie mit Daten arbeiten, tun Sie das in der Regel auf asynchrone Weise und versuchen herauszufinden, was funktioniert und was nicht. Irgendwann muss man dies jedoch formalisieren, denn ein wiederholter, kontinuierlicher Umgang mit Daten ist von großem Nutzen.

Apache Airflow ist ein solcher Datenorchestrator, der es Ihnen ermöglicht, diese Formalisierung viel einfacher und schneller vorzunehmen.

Mit Airflow können Sie:

  • Migrieren, stabilisieren, operationalisieren und integrieren Sie alle Ihre Legacy-Workloads. Sie können eine Multi-Tenant-Umgebung von einer einheitlichen Steuerungsebene aus steuern.
  • Entwickeln Sie eine zentrale Datenplattform oder ein Datengeflecht, das Ihren Anforderungen entspricht – und führen Sie Daten, Governance-Regeln und Geschäftslogik zusammen, die zuvor über verschiedene Teile des Unternehmens verstreut waren.
  • Geben Sie Ihren Entwicklungsteams eine Standardmethode für die Interaktion mit Daten an die Hand, um den für die Unterstützung ihrer Umgebungen erforderlichen betrieblichen Aufwand zu verringern.

Data Warehouse (DWH)

In einer idealen Welt ist die Lücke zwischen Theorie und Praxis nicht groß oder zumindest nicht von großer Auswirkung auf den Lebenszyklus eines Projekts. In der realen Welt weiß man jedoch, dass das nicht stimmt, schon gar nicht bei der Arbeit mit Daten. Die Datenspeicherung (vor allem Langzeitspeicherung), kann unordentlich werden und zu unsauberen Datentabellen führen, die irgendwann verarbeitet und für eine bessere und effizientere Analyse in Ordnung gebracht werden müssen, daher die Notwendigkeit von ETL-Pipelines.

Die theoretischen Faustregeln, die in diesem Beitrag erläutert werden, können in Verbindung mit kleineren (oder größeren) Anpassungen aufgrund von Dateninkonsistenzen zu sehr sauberen und nützlichen Data Warehouses (DWH) führen, die für ein Unternehmen von großem Wert sein können. Die Dateninkonsistenzen können recht umfangreich sein, da die meisten von ihnen auf menschliche Fehler zurückzuführen sind.

So kreativ die Menschen bei den von ihnen begangenen Fehlern auch sein mögen, die Arten von Problemen, mit denen man bei der Durchführung von ETL konfrontiert wird, sind recht häufig die gleichen.

Es gibt drei Hauptschritte, die jede ETL-Pipeline durchläuft:

  1. Datenanalyse
    eine gründliche Analyse des IST-Zustandes mit dem Ziel, zu verstehen, welche Transformationen durchgeführt werden müssen.
  2. Modelldefinition
    die Definition der Tabellen und der Beziehungen zwischen ihnen.
  3. ETL-Implementierung
    die eigentliche Implementierung des Datenmodells, das mit Daten aus verschiedenen Datenquellen gefüttert wird und das entworfene Datenmodell erzeugt.

Analyse der Daten

Die Bedeutung dieses Schrittes ist zweifach:

1. Geschäftsbedürfnisse

Verständnis der Informationen, die aus dem Meer der Datenquellen für das zu implementierende Data Warehouse gewonnen werden müssen, unter der Leitung der Geschäftseinheit.
Ein Data Warehouse kann auf vielen verschiedenen Datenquellen basieren, die zusammengefügt werden, oder auf nur einer Datenquelle, aber mit nur einer Teilmenge der darin enthaltenen Tabellen. Es kann zwei Szenarien für den Geschäftsbedarf geben:

  • eines, bei dem sie genau wissen, welche Art von Analyse sie anschließend mit dem Data Warehouse durchführen wollen,
  • und eines, bei dem sie keine konkrete/ spezifische Vorstellung haben.

So oder so besteht die Aufgabe in diesem Schritt darin, zu verstehen, welche Tabellen für den Entwurf des Datenmodells verwendet werden sollen, und genauer gesagt, welche Attribute dieser Tabellen nützlich sind.

Die goldene Regel ist, ein DWH zu entwerfen, das die Anforderungen erfüllt – sofern sie existieren – und dabei Raum für mögliche zukünftige Erweiterungen dieser Anforderungen zu lassen.

Falls keine spezifischen Anforderungen definiert sind, kann eine Lösung darin bestehen, die gängigsten Analyseszenarien für die betreffenden Daten zu identifizieren und dann die Daten für diese Szenarien vorzubereiten. Der letztere Fall ist allerdings eher selten, da ein Unternehmen kaum in etwas investiert, das keine kurz- oder mittelfristigen Einnahmen in Aussicht stellt.

2. Datenqualität

Verstehen und bewerten des aktuellen Zustands der Datenquellen, die verwendet werden sollen.
Sobald die gewünschten Tabellen identifiziert sind, ist es an der Zeit, in die Tiefe zu gehen: die Analyse dieser Tabellen und ihrer Attribute. In der Praxis bedeutet dies, dass für jede Tabelle die Attribute betrachtet werden müssen. Es könnte Tabellen mit über 200 Attributen geben, aber nicht alle davon sind nützlich und nicht alle sind mit Werten gefüllt.

Die erste Prüfung, die durchgeführt werden muss, ist die Suche nach fehlenden Werten und wie viele fehlende Daten es gibt. Ein Attribut, das, sagen wir, zu 90-95% NULL ist, kann kaum für die Analyse oder eine Berichtsvisualisierung verwendet werden, also kann es verworfen werden. Bei Datensammlungen über viele Jahre kann es zu Inkonsistenzen in der Grundgesamtheit der Tabelle kommen.

Eine weitere Quelle für Inkonsistenzen in den Daten kann entstehen, wenn dieselbe Tabelle aus mehr als einer Quelle gespeist wird. Für diese Art von Problemen ist es wichtig, die Logik hinter den Inkonsistenzen zu verstehen und zu sehen, ob sie behoben werden können.
Die Lösungen hängen von der Analyse ab:
alte Daten können für das DWH verworfen werden, wenn sie nicht mehr relevant sind, oder, wenn möglich, kann eine Transformation angewendet werden, um eine Vereinheitlichung der Daten zu erreichen.

Am Ende dieses Schrittes, also nach der Datenbereinigung und den Geschäftsanforderungen, hat man einen Pool, wenn man mit einem Meer von Daten begonnen hat.

Modelldefinition

Die Modelldefinition lässt sich auf die Aufteilung der Tabellen in Dimensionen und Faktentabellen sowie die Einrichtung der Beziehungen zwischen diesen Tabellen darlegen. Der Königsweg liegt hier zwischen den Anforderungen und datengestützter Möglichkeit, diese zu erfüllen. In der Praxis kommt es hier im Lauf der Zeit zu Anpassungen, so dass es sinnvoll ist, von Anfang an Möglichkeiten der Erweiterung zu berücksichtigen.

Dimensionen

Bei den Dimensionen (vergleichbar mit einer Spalte in Excel) ist zu beachten, ob es sich um eine „Slowly Changing Dimension“ (SCD) handelt und welcher Typ von SCD am besten zu Ihren Anforderungen passt. SCD vom Typ 2 ist der häufigste.
Beispielsweise können Filialleiter unterjährig wechseln, so dass für eine wirkliche Vergleichbarkeit der Daten diese Ausprägung berücksichtigt werden muss.

Fakten

Ein wichtiger Aspekt ist, dass die für die weitere Analyse und Definition von KPIs bereits das Datenmodell auf der niedrigsten Granularitätsebene implementiert wird so dass Raum für jede Art von Aggregation bleibt.
Visualisierungstools können die Möglichkeiten der Datentransformation einschränken oder sehr erschweren, so dass das Vorantreiben dieser Berechnung auf der Ebene der DWH-Implementierung eine große Erleichterung darstellt und auch die Implementierung zukünftiger visueller Analysen vereinfacht.

Beziehungen

Die Unterscheidung der beiden Kategorien Dimensionen und Fakten ist ziemlich einfach, aber was knifflig werden kann, ist das Einrichten der Beziehungen, wobei eines der Hauptprobleme auftritt, wenn mehrere Faktentabellen vorhanden sind, was recht häufig vorkommen kann, und diese Faktentabellen miteinander sowie Dimensionen sprechen müssen. Die Grundregel ist, dass Beziehungen zwischen zwei Faktentabellen zu vermeiden sind und man sich immer an das Sternschema halten sollte, was zu einem Data Warehouse mit mehr als einem Sternschema führen kann.

Namenskonventionen

Wählen Sie eine sprechende Namenskonvention und halten Sie sich daran. Ob Deutsch oder Englisch ist Geschmacksache.

Staging-Bereich / Temporärer Zwischenspeicher zum Datenabruf

Ziehen Sie eine Replikationsschicht für Ihre Quelldatentabellen in Betracht. Beispielsweise kann es sinnvoll sein eine Produktivdatenbank in einer zweiten Datenbank zu spiegeln, damit der Datenabruf nicht gegebenenfalls den Produktivbetrieb ausbremst.
Andererseits wissen ohne Replikationsschicht nach 5 Minuten ganze Abteilungen daß der Berater wieder im Haus ist, auch eine Facette die neue Möglichkeiten eröffnet. 

Indizierung und Partitionierung

Für eine bessere (d.h. schnellere) Effizienz der Abfragen, basierend auf der Größe der zu erstellenden Tabellen, kann eine Partitionierung (chunks)in Betracht gezogen und gegebenenfalls implementiert werden. Auch die Wahl der richtigen Indizierung kann einen großen Einfluss auf die Abfrageleistung haben. Grundsätzlich machen sie mit einem aufsteigenden Index nichts falsch.

Technische / Verwaltungs- Attribute

Obwohl das Hinzufügen und Pflegen dieser Attribute mühsam sein kann, kann es für die Zukunft hilfreich sein, Zusatzinformationen wie z. B.

  • Zeitstempel des Einfügens
  • Aktualisierens von Datensätzen
  • Ursache für die Aktualisierung
  • Funktion des Attributs

festzuhalten.

Aktualisierungshäufigkeit

Abhängig von der Notwendigkeit der Analyse kann die Planung der DWH-Aktualisierung periodisch täglich, einigen Tagen pro Woche, oder auch Triggergesteuert variieren. Die Zeit, die für eine Aktualisierung benötigt wird, kann einen Einfluss darauf haben und muss daher bei der Planung der Aktualisierungen berücksichtigt werden.

Erweiterbarkeit

Machen Sie das Modell leicht erweiterbar, anpassbar an Veränderungen, das ist die Praxis. Immer.

Die ETL-Implementierung

Das letzte Puzzlestück: die eigentliche Implementierung der Einzelkomponenten und Befüllung des Modells mit Daten. Gerne gesagt: Jetzt kommt Fleisch an die Knochen.

Wenn sie die beiden vorangegangenen Schritte gründlich durchgeführt wurden, fällt dieser Schritt recht leicht und Sie werden trotzdem mit kleinen Überraschungen konfrontiert, die Sie in den vorangegangenen Analyseschritten vielleicht übersehen haben.

Das Werkzeug, das für die ETL-Implementierung verwendet wird, hat den größten Einfluss auf die Menschenkinder, die das entworfene Modell umsetzen und pflegen, weniger auf das Endprodukt.
Heutzutage gibt es eine Vielzahl von Tools, die diese Aufgabe erfüllen, aber die Wahl der ETL-Implementierungssoftware hängt stark von verschiedenen Faktoren ab, wie z. B. von anderer Software (Schnittstellen), Plattformen (Softwarebündel) und Programmiersprachen, die das Unternehmen verwendet, dem vorhandenen Budget für das Projekt und weiterer Faktoren.

Unabhängig von dem Tool, das zum Aufbau der Pipeline verwendet wird, ist der wichtigste Schritt das Testen auf technische und inhaltliche Korrektheit. Wenn alles implementiert wurde, wird die Korrektheit des gesamten Prozesses durch die Durchführung von Tests überprüft. Jede Tabelle muss geprüft werden und es muss auf alle Attribute jeder Tabelle geachtet werden, damit das Endergebnis korrekt ist und mit den ursprünglichen Anforderungen übereinstimmt.
Die Erstellung eines Schemas mit erschöpfenden Testfällen (Einfügen, Aktualisieren oder Löschen von Datensätzen sind die grundlegenden) kann entmutigend erscheinen, aber es ist der beste Weg, um die Gültigkeit Ihres Modells sicherzustellen. Das intensive Testen durch den zukünftigen Endnutzer ist auch ein praxistauglicher Weg, kann je nach Grad der Einbindung allerdings die Akzeptanz erhöhen, oder die Skepsis ausbauen.

Zu guter letzt

Das Design und die Entwicklung eines Data Warehouse ist genau genommen ein ziemlich mechanischer Prozess. Die Beteiligung der Endnutzer (in verschiedene kaufmännische Aspekte) ist es, die die Analyse vorantreibt und die Analyse ist es, die den Rest des Prozesses vorantreibt.
Das Design und die Implementierung des Modells sind eine Ansammlung von Anforderungen, die evaluiert und bei Bedarf implementiert werden müssen. Ein gut entworfenes Modell kann die zukünftige Datenanalyse und die Entwicklung von Dashboards zu einer sehr einfachen und dankbaren Aufgabe machen.

Year-to-Date (YTD)

Definition

Der Englische Ausdruck Year-to-Date (kurz: YTD) bezeichnet den Zeitraum vom (Geschäfts-)Jahresanfang bis zum gewählten Datum des gleichen Jahres, also den Jahresverlauf. Dieser konstante Zeitraum wird häufig verwendet, um den Geschäftsverlauf mit einer Vorperiode (gleicher Jahresschnitt) vergleichen zu können.

Beispiel mit Kalenderjahr

Schreibweise: 2019-07_YTD
Bedeutung: Monate 2019-01 bis 2019-07 –> [2019-01,2019-07]

Vergleichszeitraum Vorjahr (VJ): 2018-07_YTD

Beispiel mit abweichendem Geschäftsjahr

Geschäftsjahr (GJ): September bis August Folgejahr
Schreibweise: GJ_2019-07_YTD

Bedeutung:

Anfang/Basis: GJ_2019-01 == 2019-09 (oder z.b. auch KJ_2019-09)

Ende Periodenbetrachtung: GJ_2019-07 == 2020-03 (oder z.b. auch KJ_2020-03)

–> GJ_2019-07_YTD = 2019-09 bis 2020-03

Nach oben scrollen