Der Rat, den Sie bereits kennen, ist richtig. Benennen Sie einen Verantwortlichen. Fangen Sie klein an. Binden Sie es an ein Geschäftsproblem. Kaufen Sie Software, die passt.
Dort sterben Programme nicht. Sie sterben in den Mechaniken darunter: in dem spezifischen Moment, in dem ein Katalogeintrag fehlerhaft wird und niemand ihn behebt, in dem Treffen, in dem zwei Abteilungen entdecken, dass sie mit „Kunde" unterschiedliche Dinge meinen, in der Rechnung, die ankommt, wenn sich Ihr Datenvolumen verdreifacht. Dieser Artikel behandelt diese Momente, denn dort wird eine Data-Governance-Implementierung tatsächlich gewonnen oder verloren.
Die Vorhersage, die es wert ist, sorgfältig zu lesen
Gartner sagt voraus, dass bis 2027 80 % der Data- und Analytics-Governance-Initiativen scheitern. Das wird überall zitiert, meist ohne den Teil, der zählt. Es ist eine Prognose, keine gemessene Realität, und Gartner nennt einen spezifischen Grund: Die Programme scheitern, weil ihnen eine echte oder konstruierte Krise fehlt, um sie zu organisieren.
Verstehen Sie das als Diagnose. Governance, die aufgebaut wird, um eine Audit zu erfüllen, hat keine Krise dahinter, daher ergibt sie eine Politik, die niemand durchsetzt. Governance, die aufgebaut wird, um ein Problem zu stoppen, das gerade jemanden Geld kostet, wird genutzt, weil jemand aufpasst.
Die oft wiederholte Zahl, dass schlechte Daten eine Organisation 12,9 Millionen Dollar pro Jahr kosten, ist mit derselben Sorgfalt zu behandeln. Es ist eine Schätzung von 2020, wird aber noch als aktuell zitiert, ohne veröffentlichte Methodik hinter der runden Zahl. Nutzen Sie sie, um die Richtung zu setzen, nicht um ein Budget zu dimensionieren. Ihre eigene Duplikatquote und Rework-Stunden sind bessere Belege als ein fünf Jahre alter Durchschnitt, und sie zu sammeln ist das erste sinnvolle, das ein Programm tut.
Die Veraltungsschleife, die Kataloge tötet
Hier ist der Fehler, den ich beim letzten Mal in einer Zeile beschrieben habe, jetzt vollständig gezeigt, weil die Zeile das ganze Problem versteckt.
Ein Katalog ist ein Satz von Aussagen über Ihre Daten: was ein Feld bedeutet, woher es kommt, wer es besitzt. Diese Aussagen veralten in dem Moment, in dem sich ein Quellsystem ändert. Eine neue Spalte erscheint. Eine Definition verschiebt sich. Eine Pipeline wird umgeleitet. Um wahr zu bleiben, muss jede dieser Änderungen im Katalog widergespiegelt werden.
Wenn diese Widerspiegelung manuell erfolgt, muss jemand die Änderung bemerken, das Tool öffnen und den Eintrag bearbeiten. Diese Arbeit konkurriert mit allem anderen auf ihrer Platte, und sie hat keine Deadline. Also rutscht sie ab. Ein paar Einträge veralten. Menschen treffen auf einen falschen Eintrag, verlieren Vertrauen und hören auf, den Katalog zu überprüfen. Sobald sie aufhören zu überprüfen, bemerkt niemand den nächsten falschen Eintrag, und die Abweichung beschleunigt sich. Nach sechs Monaten beschreibt der Katalog ein System, das nicht mehr existiert.
Ein Katalog scheitert nicht auf einmal. Er scheitert einen Eintrag nach dem anderen, den niemand beachtet, und der erste falsche Eintrag, auf den ein Benutzer stößt, ist derjenige, der ihn lehrt, nicht mehr darauf zu vertrauen.
Die Lösung ist Automatisierung: Metadaten-Harvesting, Schema-Änderungserkennung, Einträge, die sich selbst aktualisieren, wenn die Quelle sich bewegt. Das kostet Geld. Geld braucht einen Sponsor. Und ein Sponsor erscheint nur, wenn das Programm an eine Krise gebunden ist, um die sich jemand kümmert. Deshalb sind die Gartner-Vorhersage und der veraltete Katalog dasselbe Problem mit zwei Gesichtern. Keine Krise, kein Sponsor. Kein Sponsor, keine Automatisierung. Keine Automatisierung, manuelle Wartung. Manuelle Wartung verfällt im ersten arbeitsreichen Quartal.
Kaufen Sie also keinen Katalog, den Sie von Hand warten werden. Kaufen Sie die Fähigkeit, ihn aktuell zu halten, oder beschränken Sie die Governance auf einen kleineren Umfang, den Sie tatsächlich wahr halten können.
Wenn zwei Abteilungen beide „Kunde" besitzen
Dieses Treffen entscheidet darüber, ob Governance real ist, und die meisten Rollouts planen nie dafür.
Sales bedeutet ein Konto, ein Unternehmen, das bei Ihnen kauft, während Finance eine juristische Person bedeutet, die Rechnungen bezahlt, was ein Mutterkonzern sein könnte, der drei von Sales' Konten abdeckt. Marketing bedeutet eine Person, einen benannten Kontakt, der eine E-Mail öffnete. Dasselbe Wort trägt drei Definitionen über drei Systeme hinweg, und jede ist in der Abteilung, die sie nutzt, richtig.
Der Konflikt taucht an dem Tag auf, an dem jemand einen Bericht über alle drei erstellt und die Kundenzahlen stimmen nicht überein. Oder ein Deduplizierungslauf führt zwei Datensätze zusammen, die nie dasselbe waren, weil die Regel eine Definition von „Kunde" annahm und die Daten drei hielten.
Ein Verantwortlicher löst das nicht, indem er einen Gewinner erklärt. Der Mechanismus ist enger und nützlicher. Der Verantwortliche zwingt die Definitionen ins Schriftliche, was allein schon die Hälfte der Verwirrung beendet, da die drei Teams normalerweise nicht wussten, dass sie nicht einig waren. Dann trifft der Verantwortliche eine strukturelle Entscheidung: Ist „Kunde" ein Konzept mit einem Typ-Attribut oder drei separate Entitäten, die durch Beziehungen verknüpft sind, ein Konto, das zu einer zahlenden Entität gehört und Kontakte enthält? Diese Modellierungsentscheidung ist die eigentliche Governance. Alles danach, wie Deduplizierung, Reporting und Zugriff, folgt daraus.
Governance ist nicht das Richtliniendokument. Governance ist es, eine Person mit der Autorität zu haben, um einen Streit zu beenden, der sonst jedes Quartal zurückkehren würde.
Der Grund, das vor dem Softwarekauf zu klären, ist, dass die Antwort formt, was Sie die Software tun lassen müssen. Drei verknüpfte Entitäten brauchen ein Tool mit einem flexiblen relationalen Datenmodell. Ein flaches Konzept braucht viel weniger. Kaufen Sie zuerst, und Sie könnten ein Tool kaufen, das die Struktur, auf der Ihr eigenes Geschäft läuft, nicht darstellen kann.
In der Arbeit, die wir bei Produkt- und Lieferantendaten gesehen haben, zeigt sich dasselbe Muster auf einer Ebene darunter: ein „Lieferant" in der Beschaffung ist ein „Vendor" in Finance und ein „Hersteller" im Produktdatensatz, und die drei wurden in separaten Tabellenkalkulationen gepflegt, die leise nicht übereinstimmten. Ihr Konsolidieren auf ein Datenmodell mit definierten Beziehungen ist weniger eine Softwareaufgabe als eine Entscheidung darüber, welche dieser drei Ansichten die Quelle der Wahrheit ist. Das Tool erzwingt die Entscheidung nur, sobald sie getroffen ist.
Lesen Sie das Preismodell, nicht die Feature-Liste
Feature-Listen konvergieren. Preismodelle sind, wo sich die langfristigen Kosten verstecken, und sie bestrafen Sie auf spezifische Weise: Fast jedes Modell besteuert das, was bedeutet, dass Ihr Programm funktioniert.
Governance erfolgt durch größere Datenabdeckung, mehr verbundene Systeme und mehr Beteiligung von Menschen. Schauen Sie, was jede Preisachse für diesen Erfolg tut.
- Pro Datensatz.
Als durchgearbeitetes Beispiel: Angenommen, ein Tool kostet einen Pauschalsatz pro 10.000 verwaltete Datensätze, und Sie starten mit 40.000 Produktdatensätzen. Die Rechnung ist klein. Governance funktioniert, also integrieren Sie Kundendaten und absorbieren den Katalog eines Unternehmens, und Sie sind jetzt bei 400.000 Datensätzen. Die Kosten sind zehnmal höher als das, wofür Sie sich angemeldet haben, und inzwischen sitzen Ihre Workflows und Integrationen auf dem Tool, daher ist das Verlassen teuer. - Pro Quelle oder Connector.
Sie fangen an, vier Systeme zu regeln. Erfolg bedeutet, Governance über den gesamten Bestand zu erweitern, und zwei Jahre später zahlen Sie für zwanzig Konnektoren. - Pro Platz.
Sieht billig aus, bis Sie daran denken, dass Governance nur funktioniert, wenn Stewards in jeder Abteilung handeln können. Je mehr das Programm sich ausbreitet, desto mehr Plätze kaufen Sie.
Jede Achse berechnet Ihnen mehr Geld, genau wenn Sie erfolgreich sind. Der Schachzug ist nicht, ein Modell ohne Kosten zu finden. Es ist, die Achse zu wählen, die Sie vorhersagen und kontrollieren können. Wenn Ihre Datensatzzahl volatil und Ihre Quellenliste stabil ist, ist Pro-Quelle-Preisgestaltung sicherer, und das Gegenteil gilt auch.
Zur Software selbst spaltet sich der Markt in zwei. Große Enterprise-Suites wie Collibra und Informatica verwalten breite Katalogisierung und Lineage über komplexe Bestände hinweg, mit Preisgestaltung und Personalausstattung, die dazu passen. Für Master Data wie Produkte, Lieferanten und Referenzdaten sind Open-Source-Plattformen ein leichterer Einstiegspunkt. AtroCore ist eine mit konfigurierbarem Datenmodell, rollenbasiertem Zugriff und Änderungsverlauf, die die Kern-Governance-Mechaniken ohne Enterprise-Vertrag abdeckt; sie sitzt neben Optionen wie Apache Atlas und OpenMetadata, jede stärker bei einer anderen Aufgabe. Shortlist zwei oder drei und führen Sie sie durch den unten stehenden Test, bevor Sie sich auf ein Preismodell festlegen.
Was ein Pilot offenbart, das eine Demo versteckt
Eine Vendor-Demo läuft auf den Vendor-Daten, und die Vendor-Daten sind sauber. Das ist der ganze Grund, warum die Demo makellos aussieht und Ihnen fast nichts sagt.
Führen Sie den Pilot stattdessen auf Ihren schlechtesten Datensätzen durch. Für Deduplizierung bedeutet das, Ihrem Tool Ihre echte Kunden- oder Lieferantenliste zu geben, die mit „Acme Inc", „Acme, Inc." und „ACME INCORPORATED" als drei Reihen, plus die Tippfehler, die fehlenden Ländercodes und das eine Unternehmen, das legitim unter zwei Namen handelt. Beschriften Sie dann ein paar hundert dieser Reihen selbst von Hand, damit Sie die richtige Antwort wissen, und messen Sie das Tool gegen sie.
Zwei Zahlen kommen heraus. Wie viele echte Duplikate es gefangen hat und wie viele unterschiedliche Datensätze es fälschlicherweise zusammengeführt hat. Eine falsche Zusammenführung ist die gefährliche, weil sie Daten zerstört, indem zwei Kunden kombiniert werden, die nie dasselbe waren, und eine saubere Demo wird das nie aufdecken. Diese zwei Zahlen sagen Ihnen, ob die Matching-Engine auf Ihren Daten funktioniert. Nichts, das der Vendor Ihnen zeigt, wird das tun.
Machen Sie das Gleiche für die Mechanik, die in Ihrem Fall am meisten wichtig ist: eine Schema-Änderung, die der Katalog erfassen muss, einen Genehmigungsworkflow unter realistischer Last, eine Zugangsregel mit einem echten Grenzfall. Pilot das, was brechen wird, nicht das, was Demo-freundlich ist.
Data-Governance-Implementierung kommt auf eine Handvoll dieser Mechaniken hinunter. Halten Sie den Katalog wahr, klären Sie die Definitionen vor der Modellierung, preisen Sie für das Wachstum, das Sie erwarten, und pilotieren Sie auf Ihren schmutzigsten Daten. Kriegen Sie das hin, und der generische Rat kümmert sich selbst.