Dateninfrastruktur - das Rückgrat des digitalen Unternehmens

Stammdatenmanagement

,

Data Intelligence

Dateninfrastruktur - das Rückgrat des digitalen Unternehmens

Martin Horvath | May 04, 2020

Industrie 4.0, Digital Enterprise, Digitale Transformation, Business Intelligence ... Das Repertoire an Buzzwords wächst täglich weiter und alle namhaften Unternehmen schreiben sich auf die Fahnen, ihre Digitalisierung zu starten, auszubauen oder zu verbessern.

Beratungshäuser erstellen innovative Konzepte und das Management freut sich auf Umsatzvorhersagen, neue Performance-Indikatoren und sich selbst umsetzende Optimierungen. In vielen Fällen bleiben die Konzepte und Ideen aber genau dies - Konzepte.

Die Gründe hierfür sind abhängig von der Unternehmensausrichtung und klarerweise von Faktoren wie verfügbarem Budget, dem Vorhandensein von klaren Anforderungen, dem Zugang zu Technologie, der Verfügbarkeit von schlicht und einfach “Zeit” das Thema voranzutreiben oder auch einfach von der Notwendigkeit der Digitalisierung.

Der Aspekt, den ich in diesem Blog aufzeigen möchte, setzt noch deutlich früher im Gesamtprozess an.

Die “Organizational Readiness”, oder auch das Vorhandensein von “Data Governance Frameworks”

Ähnlich wie das Fundament eines schönen Hauses kann man die Readiness oder das Data Governance Framework nicht sehen und es gibt kein schickes User Interface dafür. Aber - wie beim Hausbau - macht es einen großen Unterschied, ob das Fundament von guter Qualität ist und “durchdacht” wurde, oder ob einfach mal Beton auf Untergrund verteilt wurde. Kein Wolkenkratzer wird ohne bzw. auf einem schlechten Fundament erbaut werden und keine vernünftige Digitalisierung ist ohne ein Data Governance Framework möglich.

Was also ist Data Governance nun eigentlich? Das MDM Institut definiert es sehr treffend.

Data Governance is: “The formal orchestration of people, process, and technology to enable an organization to leverage data as an enterprise asset.”

Damit wird klar, was Data Governance zusammenfassend betrachtet bzw. inkludiert:

  • Prinzipien, auf denen die Organisation aufbaut - z.B. dass jeder Datentyp einen eindeutigen Besitzer haben muss.
  • Unternehmensrollen - z.B. Data Steward, Data Governance Office ...
  • Richtlinien - z.B. Datenstandards, Datenverantwortlichkeiten ...
  • Master Daten - also Daten, die für die gesamte Organisation von Interesse sind und nicht nur für einzelne Spezialisten bzw. Abteilungen



Dies führt ultimativ dazu, dass Daten als wertvolle Güter einer Organisation behandelt werden müssen. Daten sind allgegenwärtig und umfassen beispielsweise Kundenadressen, in der Organisation eingesetzte Maschinen, Produktpreise, Einkaufspreise, Bill of Materials, Unternehmensstandorte, finanzielle Transaktionen, Zeitbuchungen von Mitarbeitern, Serviceaufträge usw.

Es ist an der Zeit, dies mit einem vereinfachten Beispiel zu veranschaulichen: Internetanbieter-X beauftragt ein Bauunternehmen, mit Hilfe eines Parzellenplanes in einer fiktiven Parzelle-A99 eines Industriegebietes ein bestehendes Glasfaserkabel zu splitten und eine Weiche einzubauen. Die Arbeiten führen zu deutlichen Mehraufwänden und es muss deutlich mehr gegraben werden als geplant. Was war geschehen? Beim initialen Verlegen kam es zu Problemen und das Kabel wurde anders verlegt als planmäßig. Die nachfolgende Abbildung zeigt in rot das Glasfaserkabel lt. Bauplan, in blau lt. Umsetzung, und das X markiert die Stelle für den Split.

 

Das Problem hat einen Ursprung in der unzureichenden Reglementierung des Bauprozesses. Nach dem initialen Verlegen des Glasfaserkabels hätte eine Dokumentation der Änderung erstellt werden müssen, selbige im Bauplan vermerkt und alle bereits verteilten Baupläne hätten korrigiert werden müssen - digital und analog.

Ähnliche Probleme kennt vermutlich jeder aus dem Bereich Kundendatenverwaltung.

Nun in voller Tiefe Data Governance zu behandeln würde den Umfang dieses Blogs überschreiten, aber zur besseren Veranschaulichung können die genannten Eckpfeiler von Data Governance (Prinzipien, Richtlinien, Entitäten und Master Daten) auf das Parzellenbeispiel übertragen werden.

Die zugrunde liegenden Master Daten könnten in einer einfachen Tabellenstruktur dokumentiert werden:

Datensatz

Beschreibung

Besitzer

Prozess

Parzelle

Abgrenzung der nutzbaren Fläche

Extern

 

Bauplan

Bebauungsplan 

Projektmanager A

Bauplanupdateflow

Baudokumentation

IST-Bebauungsplan

Bauleiter B

Bauplanupdateflow

 

Eine solche - in der Realität deutlich komplexere - Master-Daten-Dokumentation führt zwangsläufig zu den nächsten beiden Eckpfeilern.

Richtlinien und Entitäten

Erste legen fest, in welchem Format ein Bauplan vorliegen muss, um eine automatische Verarbeitung zu ermöglichen. Ebenso fällt hierunter das erforderliche Metadatenprofil, damit beispielsweise ein Datenkatalog-System evaluieren kann, welche Baupläne womöglich nicht aktuell sind. Dazu zählen aber auch Anforderungen an die Datengenauigkeit oder an die Datensicherheit (z.B. Verschlüsselung). Auch standardisierte Prozesse sind hier vermerkt und umfassen zum Beispiel automatische Qualitätskontrollen, Katalogisierungen oder Informationsaussendungen, wenn ein neuer Bauplan elektronisch übermittelt wurde.

Die menschliche Komponente, hier genannt Entitäten, haben die Schirmherrschaft über Daten und Prozesse. So stellt zum Beispiel der “Besitzer” in obiger Tabelle sicher, dass jederzeit ein Ansprechpartner für einen Datensatz existiert und dieser auch die Verantwortung dafür trägt. Eine Ebene höher werden Prozesse definiert, die einem Besitzer das Leben leichter machen sollen, z.B. elektronische Verarbeitung, aber auch solche die notwendig sind um (rechtliche) Anforderungen einzuhalten. Hier das Rückspielen der Baudokumentation in den Bauplan und die Information aller “Bauplan-Nutzer”. Selbiges wird übrigens auch im Kontext der DSGVO genutzt bzw. sogar gefordert.

Letztlich werden all diese Rollen, Richtlinien und Daten sowie die Einhaltung der Prozesse mit Hilfe von verständlichen Organisationsprinzipien “zusammengehalten”. Beispielsweise “jeder Datensatz muss einen Verantwortlichen haben.” oder “Daten haben für uns einen monetären Wert und müssen auch so behandelt werden.”.

Technologie unterstützt Organisationen bei der Umsetzung eines Data Governance Frameworks und wie so oft führen viele Wege ans Ziel. Dabei geht es nicht immer darum, eine monströse und exorbitant teure Unternehmenslösung zu installieren und den Mitgliedern/Mitarbeitern vorzuwerfen. Am Ende des Tages muss eine Evaluation stattfinden, welche Lösung oder welches Mosaik an Lösungen den Anforderungen entspricht und nachhaltig eingesetzt werde kann. Das ganze am fiktiven Parzellenbeispiel angewandt soll als Denkanstoß dienen.

Eine zentrale Datenbank dient als Master Datenspeicher und bildet das digitale Rückgrat der Organisation. Dort sind sowohl die Daten selbst, als auch deren Masterdaten abgelegt und ein Versionierungskonzept umgesetzt. Jeder Schreibzugriff wird aus Gründen der Nachvollziehbarkeit protokolliert und die Zugriffsrechte so restriktiv wie möglich vergeben. Oracle ermöglicht hier etwa ein Spalten- und Zeilen-basiertes Sicherheitskonzept und schützt nicht nur die Tabelle sondern auch innerhalb dieser, die besonders sensiblen Inhalte.

Für unser Beispiel nehmen wir an, dass Baupläne mit AutoCAD erstellt und bearbeitet werden und die Parzellen in einem geographischen Informationssystem Verwaltet werden. Es wird also erhöhten Bedarf an Datenkonvertierung geben, da verschiedene CAD und GIS Systeme - und damit auch Datenformate - verwendet werden. Safe FME Server ist ein multifunktionelles ETL (Extract transform load) Werkzeug und kann als Ebene über der Datenbank positioniert werden. In unserem Beispiel implementieren wir sogenannte FME Workbenches, die GIS Daten (z.B. Parzellen) aus dem AutoCAD Format zu standardisierten Datenbank-Geometrien konvertieren - und umgekehrt:

Diese Workbench - ein frei definierbarer Prozess - führt in unserem Beispiel einen Bauplan-Upload durch, konvertiert die CAD Daten, prüft die Vollständigkeit und Richtigkeit dieser unter Berücksichtigung der Data Governance Policies und überträgt diese dann in die zentrale Datenbank. Im Falle von unvollständigen Metadaten (z.B. Projektnummer, Parzellennummer,...) oder fehlerhaften Daten - beispielsweise wenn das Glasfaserkabel nicht unterbrechungsfrei eingezeichnet wurde - wird der Einreicher sofort darüber informiert und die Aktualisierung abgebrochen. Das alles zusammengefasst führt - wieder stark vereinfacht - zu folgender Architektur:



Warum der ganze Aufwand und was hat die Organisation gewonnen?

Erinnern wir uns an das beispielhafte Problem das eingangs erwähnt wurde: Die Baufirma hat nach dem Glasfaserkabel am falschen Ort gegraben. Korrekte Daten hätten dies verhindert.

Korrekte Daten verhindern, dass Entscheidungen aufgrund falscher Tatsachen getroffen werden und dass Produkte mit mangelhafter Qualität an den Kunden verkauft werden. Korrekte Daten beugen Fehlinformationen vor und sind die Grundvoraussetzung für Unternehmenskennzahlen.

Die Frage, ob sich der Aufwand lohnt, stellt sich also gar nicht. Nur mit einem solchen Framework - ob das nun Data Governance oder Daten-Wahrheits-Maßnahme oder Organizational-Brain-Program heißt macht erstmal keinen Unterschied - kann überhaupt evaluiert werden ob Daten der Organisation korrekt sind. Und eine Organisation legt damit den Grundstein für eine nachhaltige digitale Transformation. Die Frage nach “Welche Daten müssen für den Umsatz-Optimierungsalgorithmus herangezogen werden und wo sind diese zu finden” werden dann nicht mit “Dafür müssen wir eine Analysephase einplanen und finanzieren” beantwortet, sondern mit “Das ist alles in unserem Data Governance Framework Handbuch dokumentiert”.

Take away


Digitale Transformation braucht Data Governance und ohne selbiges steht das Digitalisierungsvorhaben auf wackeligen Beinen. Data Governance umfasst Menschen, Prozesse und Technologie, um Daten als Assets zu behandeln und unter Umständen hat Data Governance bei Digitalisierungskandidaten einen anderen Namen. Wenn eine der folgenden Fragen mit nein beantwortet wird, dann lohnt es sich das Fundament der Organisation nochmals zu analysieren:

  1. Verfügt die Organisation über eine aktuelle Dokumentation was als Master- oder Kern-Daten behandelt wird?
  2. Verfügt die Organisation über eine aktuelle Dokumentation der Master-Daten hinsichtlich Verantwortlichkeiten, Inhaltlichen Anforderungen, Formaten, Prüfroutinen usw.?
  3. Hat die Organisation ein transparentes Regelwerk, das den Datenzugriff reglementiert?
  4. Verfügt die Organisation über ein standardisiertes Verfahren, um die Datenqualität kontinuierlich zu evaluieren?
  5. Hat die Organisation eine ETL (Extract-Transform-Load) Lösung im Einsatz?



Möchten Sie mehr über Dateninfrastruktur erfahren?

Wenn Sie ausführlicher über Dateninfrastrukturen reden möchten,  senden Sie uns eine Nachricht: Wir freuen uns auf ein Gespräch!

KONTAKTIEREN SIE UNS

Abonnieren!