Geekly articles weekly

Warum E in der Abkürzung EHD über Geschäftsprozesse handelt

Data Warehouse ohne E.


In jedem Unternehmen, das mit großen und mittleren Unternehmen verbunden ist, ist die Verfügbarkeit eines Data Warehouse heute de facto ein Unternehmensstandard. Es spielt keine Rolle, in welcher Branche das Unternehmen tätig ist. Ohne Analyse der verfügbaren Daten zu Kunden, Lieferanten und Finanzen ist es unmöglich, einen Wettbewerbsvorteil zu erzielen. Mit der Entwicklung der Automatisierung und Optimierung auf jeder Ebene der Produktion eines Produkts oder einer Dienstleistung verwendet das Unternehmen immer mehr IT-Systeme, die Daten erstellen - Produktion, Buchhaltung, Planung, Personalmanagement und andere.

Wie man den Prozess der Erstellung eines Data Warehouse unter dem Gesichtspunkt der globalen Optimierung von Unternehmensressourcen, neuen und aktuellen Geschäftsanforderungen am effektivsten aufbaut und warum die Pflege von Metadaten wichtig ist.

Aufgaben zur Verwendung akkumulierter Daten werden am häufigsten für die folgenden Aufgabenklassen verwendet:

  • aufsichtsrechtliche Berichterstattung
  • Finanzbuchhaltung
  • Planung und Kontrolle
  • Budgetierung
  • Kundenbasisanalyse
  • Risikomanagement

Für die dringendsten Zwecke reicht es oft aus, eine Quelle zu verwenden - zum Beispiel, wenn es darum geht, dem Regulierer einige Details aus einem bestimmten System zur Verfügung zu stellen oder dem Kunden den gesamten Verlauf seiner Bestellungen mithilfe von CRM zu senden. Selbst wenn Informationssysteme geändert werden, gibt es normalerweise keine Schwierigkeiten, Berichte zu erhalten.

Methoden und Arten der Datenspeicherung


Wenn die Größe des Unternehmens jedoch groß genug wird oder Sie Ihren Wettbewerbsvorteil steigern möchten, reicht es nicht mehr aus, nur ein Produkt zu erstellen und auf den Markt zu bringen. Aktuelle Trends - in einer umfassenden Studie des Verbrauchers, um seine Loyalität zu erhöhen. Sie müssen das Geschäft aus verschiedenen Blickwinkeln analysieren und lernen, wie Sie die Kosten genauer bewerten können. Typische Aufgaben aus der Kategorie "Muss haben" sind:

  • Aufteilung der Ausgaben für Business Mining-Einheiten
  • Prognose der Nachfrage in Abhängigkeit von internen oder externen Faktoren
  • Risikomanagement in Finanz- und Versicherungsorganisationen
  • So erhöhen Sie den durchschnittlichen Scheck des Kunden (Targeting)

Jedes der obigen Beispiele erfordert die Verwendung von mehr als einer Datenquelle. Darüber hinaus ist es wichtig, dass die Methoden zum Vergleichen von Daten zwischen Quellen konsistent sind. Andernfalls entsteht unweigerlich eine Situation, in der die Organisation, beispielsweise der Strategiedirektor und der Vertriebsleiter, dem Generaldirektor dieselben Informationen mit unterschiedlichen Nummern zur Verfügung stellt. Und dann finden sie einen Monat lang heraus, wer „rechts“ war, indem sie fast die Hälfte des ihnen zur Verfügung stehenden Personals einsetzen.

Die primitivste Art, ein Data Warehouse zu organisieren, ist der sogenannte „Data Lake“ (oder Data Lake), bei dem wir einfach Daten aus verschiedenen Quellen entnehmen und stapeln. In diesem Fall verfügen wir über eine einzige technische Plattform für die Arbeit mit Daten und die Isolierung komplexer analytischer Abfragen von den Hauptaufgaben von Informationssystemen. Ein solches Data Warehouse kann ziemlich unzusammenhängend sein. In diesem Fall können Sie jedoch die komplexe Analyse vergessen und nur mit einfachen Abfragen arbeiten. Darüber hinaus sollten Personen, die mit Daten arbeiten, nicht nur über den Geschäftsbereich, sondern auch über die Datenmodelle der Quellsysteme informiert sein.

Ferner folgt je nach Organisationsebene des Data Warehouse die Speicherung nach dem sogenannten Kimballs Klassifikation (Kimpball). Messungen aus verschiedenen Systemen werden vereinheitlicht, und auf diese Weise erhalten wir so etwas wie ein Netzwerk mit zwei Arten von Tabellen - Fakten und Messungen. Dies ist die primäre Bereicherung von Verzeichnissen, wenn wir mithilfe eines gemeinsamen natürlichen Schlüssels in denselben Tabellen verschiedener Quellen, z. B. TIN im Verzeichnis von Organisationen, eine einzige Referenz erhalten.

Das nächste in Bezug auf Komplexität und Zuverlässigkeit ist ein Data Warehouse mit einem einzigen Datenmodell, das die wichtigsten Objekte widerspiegelt, die die Aktivitäten der Organisation beschreiben. Die Zuverlässigkeit liegt in der Tatsache, dass die Daten, die in einer Form nahe der dritten Normalform mit einem korrekt zusammengestellten Modell dargestellt werden, ein universelles Mittel zur Beschreibung der Lebensdauer des gesamten Unternehmens darstellen. Daher kann das Datenmodell nicht nur für analytische und behördliche Berichte, sondern auch einfach angepasst werden und für den Betrieb einiger Unternehmenssysteme.

E - Eins


Wenn ich über die These dieses Artikels spreche, werde ich die Hauptprobleme auflisten, mit denen die Verantwortlichen für den Bau von Data Warehouses konfrontiert sind:

" Pferd im luftleeren Raum ." Das Repository wird erstellt, aber niemand verwendet es.

Die Black Box . Der Speicher ist aufgebaut, aber was sich darin befindet und wie es funktioniert, ist unverständlich. Aus diesem Grund treten ständig Fehler auf, und wenn auch ein Teil des Entwicklungsteams gekündigt hat, rollen wir als Ergebnis zu Punkt a.

" Rechner ". Der Speicher wird erstellt, erfüllt jedoch nur primitive Anforderungen. Das Geschäft ändert sich viel schneller als die Implementierung von Anforderungen. Neue Geschäftsanforderungen werden darin nicht berücksichtigt. Darüber hinaus sind einige Daten möglicherweise veraltet oder werden selten aktualisiert.

" Kristallvase ". Für die Speicherung sind viele manuelle Steuerungs-, Überprüfungs- und manuelle Steuerungsmaßnahmen erforderlich. Wenn einer der Support-Teilnehmer nicht arbeitet, besteht ein großes Risiko, dass ungültige oder gar keine Daten empfangen werden.

Wir werden alle vier Fälle genauer analysieren.

"Ein Pferd im luftleeren Raum." Wenn Sie dieses Ergebnis erhalten, geschieht dies aus einem von zwei Gründen:

  1. Weniger wahrscheinlich. Sie haben keine Anforderungen von Geschäftsbereichen gesammelt (oder, was auch immer, sie waren schlecht gestaltet). Eine solche scheinbar absurde Situation entsteht, wenn die Idee, ein Repository zu erstellen, nicht von einem Unternehmen stammt, sondern von einer IT-Abteilung, die lediglich über ein "zusätzliches" Budget verfügt, und das Repository wurde konzipiert, weil es jeder hat. Wir werden Kunden später finden (noch besser ist die Option "Sie werden mit ausgestreckten Händen rennen") - wenn wir alles dort ablegen. Die Verantwortlichen für die Zuweisung des Budgets halten dies für notwendig, sie lesen und hören in Büchern, es ist wie eine Modernisierung, und sie nicken zustimmend.
  2. Wahrscheinlicher. Die Kunden des Data Warehouse wurden identifiziert, zum Beispiel ist dies die Verkaufsabteilung, und hier kommt die gute Idee: „Lassen Sie uns das Delta etwas mehr anstrengen, die Finanzen, das Personal und etwas mehr in das Delta investieren und das gesamte Unternehmen wird den Speicher nutzen.“ Das Lagerhaus wurde gebaut, aber es wird nur von der Verkaufsabteilung genutzt, obwohl dort alles schön ist und ich nicht die Milchküsten nehmen möchte, aber nein, meine Kollegen haben keine Zeit für die Kusselbanken, sie müssen von morgens bis abends ein Datenstück graben. Immerhin ist dies ein Stück, das durch Schweiß und Blut gewonnen wurde (sprich: verbrachte Zeit).

In beiden Fällen gibt es kein Element, die Verantwortung für den Top-Manager zu übernehmen und ihn in der Hierarchie zu senken. Es ist wie bei der Unternehmenskultur. Wenn das Gen. Wenn der Direktor des Unternehmens 2 Stellvertreter ist, kann nur das Gen selbst den Speicher auf Unternehmensebene nutzen. Ein Hirsch oder der Speicher wird für einen Teil des Unternehmens gebaut - derjenige, der vom Leiter der höchsten Position überwacht wird, der sich der Notwendigkeit bewusst ist, EDM einzuführen.

Um solche Situationen zu beseitigen, ist Folgendes erforderlich:

  1. Bestimmen Sie formell den Sponsor des Data-Warehouse-Projekts, der sowohl finanziell als auch geistig für das Ergebnis verantwortlich ist
  2. Genehmigen Sie den Projektumfang, möglicherweise schrittweise, und geben Sie ungefähre Daten an
  3. Koordinieren Sie mit allen Abteilungen - vorzugsweise mit dem Aufbau von Geschäftsprozessen wie sie sind und sein sollen

Erst danach können wir mit der Umsetzung des Projekts beginnen - Anforderungen sammeln, Architektur entwerfen usw.

Die Black Box . Sie behaupten also, dass Sie das Repository erstellt haben, dass alle Anforderungen berücksichtigt werden, aber niemand versteht, wie man es verwendet. Wenn einer der wichtigsten Entwickler gegangen ist, ist es fast unmöglich zu verstehen, was und wie getan wurde.

In diesem Fall wurde der Entwicklungsdokumentationsprozess offensichtlich nicht festgelegt. Das Prinzip der „ersten Dokumentation“, dann der Entwicklung sollte erhöht werden, wenn nicht zum Absoluten, dann zu einer ziemlich strengen Kontrolle. Und das nicht nur vom Team, das für die Entwicklung des Data Warehouse verantwortlich ist. Im Idealfall ist es erforderlich, dass zusätzliche Berichtsentwickler (analytische, behördliche), Eigentümer der internen Informationssysteme des Unternehmens und natürlich die Verbraucher selbst mit dem Prozess der kontinuierlichen und aktuellen Dokumentation verbunden sind.

Darüber hinaus sollte der Dokumentationsprozess die folgenden Grundsätze erfüllen:

  • Relevanz - Der aktuelle Status des Programmcodes wird vollständig durch die Zusammensetzung der Dokumentation bestimmt
  • Versionierung - Die Möglichkeit, die Dokumentation früherer Releases zu analysieren und Änderungen für zukünftige Releases zu planen
  • Trennung - Mehrere Personen können gleichzeitig an einem Dokument arbeiten
  • Anwendbarkeit Es heißt, dass es für jede Art von Speicherdokumentation wichtig ist, eine Struktur auszuwählen, die für die Zielbenutzer am besten verständlich ist: Beispielsweise wird die Tabellenstruktur am besten in tabellarischer Form beschrieben, Geschäftsprozesse in Form von Notationen, die Interaktion zwischen Informationssystemen in Form eines Diagramms, Geschäft - ein Wörterbuch in Form eines Wiki-Systems usw.

Jetzt gibt es Softwareprodukte, die das Leben ernsthaft vereinfachen, d. H. Design und Entwicklung zu verknüpfen, aber es gibt noch keine vollständige Lösung für Data Warehouses, aber diese sind:

  • ER-Diagramme
  • BPMN-Produkte
  • ETL-Lösungen

Ohne aktuelle Dokumentation wird die Komplexität der Entwicklung neuer Anforderungen zunehmen und mit kompetenter Dokumentation abnehmen.

" Rechner ". Wenn wir davon ausgehen, dass wir kein „Pferd im luftleeren Raum“ erhalten haben, handelt es sich in dieser Situation um einen Zeitpunkt, an dem die Anforderungen scheinbar erfüllt sind, sie jedoch formal erfüllt werden. Sie wollten den Rest des Tages zählen - bitte. Möchten Sie sie nach Regionen der Gegenparteien erhalten - dies war nicht in den Anforderungen enthalten, müssen Sie hochladen, um Excel zu erstellen, und dann vom System X-Upload an Auftragnehmer mit einer Auswahl an Y-Feldern und dann VPR-ite senden.

Die aktuelle Situation weist auf einen Mangel an Erfahrung mit dem Team hin, ohne eine architektonische Sicht auf die spätere Entwicklung des Repositorys, ohne ein primitives Datenmodell. In der Regel werden solche Repositorys vorübergehend oder schnell vergessen. In guter Weise sollte der Laden die Kraft eines Schneeballs haben, der von einem Berg rollt. Wenn der Klumpen noch klein ist und loser Schnee vor Ihnen liegt, müssen Sie ihn zunächst kaum sammeln und schieben. Irgendwann wird sich der Ruhm über Ihr Produkt verbreiten und die Benutzer werden immer mehr in den Laden schauen.

Damit sich der Speicher nicht als Taschenrechner herausstellt, muss Folgendes sichergestellt werden:

  1. qualifiziertes Personal - Architekten, Analysten, EtL- und SQL-Entwickler
  2. Die Charta des Projekts, in der der Zweck der Lagerung nicht nur für die nächste Haushaltsperiode, sondern auch für die folgenden Jahre angegeben wird
  3. Quantitative und qualitative Kriterien für ein Data Warehouse. Wenn nicht genügend Personal vorhanden ist, wird empfohlen, Berater zu gewinnen
  4. Stellen Sie sich klar vor, was in Zukunft zur Optimierung des Data Warehouse beitragen wird - Personalkosten, Software, Beschleunigung der Berichtsentwicklung usw.


" Kristallvase ". Der Speicher ist so aufgebaut, dass er seine Aufgaben zu bewältigen scheint, aber es erfordert viel Aufwand, um ihn zu unterstützen: Verwalten manueller Verzeichnisse, ständiges Neuladen einiger Quellen, Fehler beim Laden, Duplizieren von Daten usw.

Diese Situation kann aus folgenden Gründen auftreten:

  1. Darüber wurde oben gesagt - der Mangel an qualifiziertem Personal;
  2. Unarchitektonisches Konzept - Wenn verschiedene Teile des Speichers von verschiedenen Personen oder Teams ohne ein gemeinsames genehmigtes Konzept erstellt werden, haben wir mehrere Möglichkeiten, Daten zu extrahieren, zu transformieren und zu laden.
  3. Eine sehr häufige Situation ist das „Outsourcing der Entwicklung“, die eigene Unterstützung, während die Akzeptanz der Arbeit schlecht erfolgt
  4. Irgendwann in der Entwicklung des Repositorys ist "das Budget vorbei". Und dann wird der Speicher nicht von dem Team, das ihn erstellt hat, fertiggestellt (unterstützt), sondern von denen, die Daten benötigen

Um diese Situationen zu vermeiden, werden die folgenden Maßnahmen empfohlen:

  1. Zu den oben genannten Punkten gehören qualifiziertes Personal, die Charta des Projekts, der langfristige Plan und das Budget sowie die interessierte Person des Top-Managers.
  2. Es ist nicht das Outsourcing, das den Prozess leitet, sondern ein interner Mitarbeiter (Chefanalyst oder Architekt), der das Outsourcing überwacht.
  3. Alle fehlgeschlagenen Situationen sollten den Besprechungen zur Prüfung durch den Lagerarchitekten vorgelegt werden. Wenn es mehrere Architekten gibt, dann das Architekturkomitee.
  4. Es wird empfohlen, eine Qualitätsmetrik für das Data Warehouse einzuführen. Sie können diese Metrik verwenden, um eine Bindung an den KPI-Befehl herzustellen.

Wie zu sehen ist, müssen in all diesen Fällen trotz der Tatsache, dass die Erstellung eines Data Warehouse eine Projektaktivität ist, die Erstellungsprozesse selbst reguliert werden, um ein qualitativ hochwertiges Ergebnis zu erzielen.

Übergang von einem Data Warehouse zu einem einzelnen


Wie oben erwähnt, wird der Erfolg des Projekts zur Erstellung eines Data Warehouse durch eine Vielzahl von Eingabedaten (Budget, Sponsor, Team, Ziele, Kunden) bestimmt. Wir haben jedoch praktisch keine Geschäftsprozesse angesprochen, die darauf abzielen, die CD selbst zu entwickeln und zu warten. Im Folgenden werde ich versuchen, die wichtigsten Geschäftsprozesse zu formulieren, mit denen die Prozesse der Arbeit mit Daten im Unternehmen wirklich vereinheitlicht werden sollen:

  1. Verfahren zur Aktualisierung der technischen Dokumentation und der Benutzerdokumentation
  2. Prozesse zur Aktualisierung des Geschäftswörterbuchs (Glossars) von Daten
  3. Datenqualitätskontrollprozesse
  4. Prozesse zur Erfassung und Verwaltung von Anforderungen an CD und Berichtssystem
  5. Verwaltungsprozesse für die Speicherinfrastruktur
  6. Prozesse zur Optimierung der Speicherung und Datenerfassung

Im modernen Paradigma bilden diese Geschäftsprozesse die Grundlage des Konzepts der Data Governance.

Sehr oft wird beim Versuch, diese Prozesse durch die Bemühungen des CD-Erstellungs- und Berichterstellungsteams zu implementieren, aktiver Widerstand geleistet oder die Prozesse ignoriert. Es ist verständlich, weil es im lokalen Sinne eine Erweiterung der Entwicklung ist.

Daher ist es hilfreich, die folgenden Maßnahmen zu ergreifen:

  • Einführung einer horizontalen Verantwortungsstruktur (jeder Teilnehmer kann für einen kleinen Bereich verantwortlich sein)
  • Grafische Darstellung aller möglichen Workflows für alle Mitarbeiter (Formalisierung des Prozesses)
  • Implementierung des Prozentsatzes und der Qualität der Verantwortung im KPI-System

Trotz der Tatsache, dass der Übergangsprozess im lokalen Sinne erheblich "bürokratisch" und schwer zu sein scheint, bietet er im globalen Sinne erhebliche Vorteile und spart Zeit. Da der Hauptzeitverlust - bei der Erfindung von Grund auf bereits vorhandene Lösungen aufgrund der Unmöglichkeit oder des Mangels an Wunsch, den vorhandenen Mechanismus zu verstehen.

Ein wenig über die architektonische Ziellösung


Trotz der Tatsache, dass die Architektur des EDS auf einem separaten großen Artikel oder sogar einem Buch basiert, werde ich auch die wichtigsten technischen Anforderungen für ein ausgereiftes Data Warehouse angeben:

  1. Das Data-Lake-Paradigma ersetzt keine Data Warehouses von Unternehmen, sondern existiert gleichzeitig damit
  2. Das EDS sollte über verschiedene Datenpräsentationsschnittstellen verfügen: Bi-Tools, die Möglichkeit, Ad-hoc-SQL-Abfragen auszuführen, Standarddatenbereitstellung in JSON, XML usw.
  3. Ein Datenzugriffsrollenmodell sollte implementiert werden.
  4. Antwortgeschwindigkeit beim Zugriff auf Daten: 90% der typischen Abfragen - weniger als 1 Sekunde, 99% der Abfragen - weniger als 10 Sekunden. Es sollte eine ziemlich gute Versorgung mit Ressourcen geben
  5. Das Vorhandensein einer einzelnen und verbundenen zentralen HD-Schicht (vorzugsweise - Inmon-Methode)

Infolgedessen wird das Data Warehouse nicht durch die Verfügbarkeit von Quellen, sondern durch die Verfügbarkeit von Datenkonsumenten als einheitlich bezeichnet. Dies ist viel komplizierter als das Schreiben einer universellen ETL und das Anpassen der Petabyte an Speicher.

Source: https://habr.com/ru/post/de418361/

More articles:


All Articles