Datenkompetenz im Unternehmen

Unternehmen haben mehr Daten als jemals zuvor. CRM, ERP, Warenwirtschaft, Buchhaltung, Marketingplattformen, Onlineshops und Fachanwendungen produzieren fortlaufend eine Flut an Informationen. Dazu kommen Excel-Dateien, lokale Datenbanken und jene erstaunlich langlebigen Übergangslösungen, die irgendwann für drei Monate gedacht waren und zehn Jahre später noch immer geschäftskritische Aufgaben erfüllen.

An Daten mangelt es nicht. Trotzdem fällt es vielen Unternehmen schwer, vergleichsweise einfache Fragen zuverlässig zu beantworten: Wie viele aktive Kunden haben wir eigentlich? Welche Produkte sind tatsächlich profitabel? Wie hoch war der Umsatz im vergangenen Monat? Und warum weist der Vertriebsbericht eine andere Zahl aus als die Buchhaltung?

Nicht die fehlenden Daten sind das Problem, sondern die Informationen zur Entstehung, ihrer Bedeutung und ihrer Nutzung. Entstehende Daten werden in unterschiedlichen Systemen erfasst, aber nicht synchronisiert, Begriffe werden von Abteilungen verschieden ausgelegt und Verantwortlichkeiten sind historisch gewachsen oder überhaupt nicht definiert. Technisch funktioniert vieles irgendwie. Ob die Ergebnisse fachlich stimmen und unternehmensweit dasselbe bedeuten, ist eine völlig andere Frage.

Wenn es mal jemandem auffällt und er oder sie sich traut es zu kommunizieren und dann auch noch erhört wird, was selten genug in einer Reihe klappt, folgt der reflexartige Ruf: "Das ist ein IT-Problem, das müssen die lösen!" Das ist nachvollziehbar, schließlich befinden sich dort Datenbanken, Schnittstellen und Anwendungen, aber es greift zu kurz. Die IT (sorry!) hat in der Regel keine Ahnung von Daten. Sie speichern alles gut ab, sorgen sich um Backups, Sicherheit, Verfügbarbeit und Performance. Aber was in den vielen Felden steht, was es fachlich bedeutet, ob Werte sinnvoll und plausibel sind, wie hoch die Datenqualität ist, das kann nur der Fachbereich bewerten. Und hier fehlt leider oft die Rückkopplung.

Gutes Datenmanagement entsteht deshalb erst im Zusammenspiel von Fachbereichen, IT und Management. Es ist keine rein technische Disziplin, sondern eine organisatorische Aufgabe mit technischen Komponenten.

Warum die IT das Datenproblem nicht allein lösen kann

Die IT schafft die technische Grundlage. Sie betreibt Systeme und Datenbanken, entwickelt Schnittstellen, verwaltet Zugriffsrechte und sorgt dafür, dass Informationen gespeichert, verarbeitet und geschützt werden können. Ohne diese Arbeit gäbe es kein funktionierendes Datenmanagement.

Die fachliche Bedeutung der Daten kann daraus jedoch nicht automatisch abgeleitet werden. Ob ein Kunde als aktiv gilt, wann ein Auftrag als abgeschlossen betrachtet wird oder welche Bestandteile in eine Umsatzkennzahl einfließen, sind zunächst betriebswirtschaftliche Entscheidungen.

Gerade scheinbar eindeutige Begriffe sorgen dabei regelmäßig für Überraschungen. Fragen Sie einmal Vertrieb, Marketing und Buchhaltung, was ein „Kunde“ ist. Der Vertrieb zählt möglicherweise bereits einen qualifizierten Interessenten dazu, während die Buchhaltung nur Unternehmen berücksichtigt, an die tatsächlich eine Rechnung gestellt wurde. Das Marketing wiederum arbeitet mit sämtlichen Kontakten im CRM.

Alle sprechen über Kunden, aber nicht zwingend über dieselbe Grundgesamtheit.

Solange solche Unterschiede nicht erkannt und geklärt werden, löst auch ein neues Dashboard das Problem nicht. Im schlimmsten Fall präsentiert es nur sehr viel eleganter die Widersprüche, die bereits vorher bestanden haben.

Fallbeispiel: Drei Umsatzzahlen und alle sind richtig

Ein mittelständisches Unternehmen führt eine neue Business-Intelligence-Lösung ein. Im Dashboard wird für Juni ein Umsatz von 1,84 Millionen Euro ausgewiesen. Der Vertriebsleiter widerspricht: Seine Auswertung zeigt 2,1 Millionen Euro. Die Buchhaltung meldet wiederum 1,72 Millionen Euro.

Was zunächst nach einem technischen Fehler aussieht, entpuppt sich bei näherer Betrachtung als Definitionsproblem. Der Vertrieb zählt Auftragseingänge, die Buchhaltung gebuchte Rechnungen und das Dashboard ausgelieferte Aufträge. Keine der drei Zahlen ist zwangsläufig falsch. Sie beantworten nur unterschiedliche Fragen unter einem unscharfen Begriff.

Das eigentliche Problem ist damit nicht die BI-Lösung, sondern die fehlende gemeinsame Definition. Die neue Technik hat den Konflikt nicht verursacht, sondern sichtbar gemacht.

Solche Situationen sind typisch. Unternehmen investieren erhebliche Summen in mächtige Tools, Reporting und Analyse, um dann festzustellen, dass die technische Qualität der Auswertung höher ist als die Klarheit der zugrunde liegenden Begriffe.

Gute Daten beginnen im Geschäftsprozess

Datenqualität entsteht nicht erst in einer Datenbank. Sie beginnt dort, wo Informationen erzeugt und erfasst werden: im Verkaufsgespräch, beim Anlegen eines Kunden, in der Produktion, bei einer Bestellung oder im Kundenservice.

Viele Fehler sind deshalb keine klassischen IT-Probleme, sondern das Ergebnis ungeeigneter Prozesse.

Ein einfaches Beispiel ist das Pflichtfeld. Wird festgestellt, dass eine wichtige Information häufig fehlt, liegt es nahe, die Eingabe technisch verpflichtend zu machen. Damit steigt tatsächlich die Vollständigkeit des Datensatzes, zumindest statistisch.

Kennt der Mitarbeiter die erforderliche Information jedoch nicht oder stehen keine passenden Auswahlmöglichkeiten zur Verfügung, entstehen Werte wie „Sonstiges“, „unbekannt“, ein Bindestrich oder irgendeine Auswahl, mit der sich die Eingabemaske endlich schließen lässt.

Die Datenbank meldet anschließend hundert Prozent vollständig ausgefüllte Datensätze. Fachlich ist dadurch noch nicht viel gewonnen.

Datenqualität lässt sich deshalb nicht ausschließlich anhand technischer Kriterien beurteilen. Entscheidend ist, ob Informationen für ihren jeweiligen Zweck korrekt, vollständig, konsistent, aktuell und nachvollziehbar genug sind. Dafür muss man verstehen, wie sie entstehen.

Prozesse verstehen, bevor Daten bereinigt werden

Viele Unternehmen beginnen ihre Datenqualitätsinitiative dort, wo das Problem sichtbar wird: bei den vorhandenen Daten. Dubletten werden zusammengeführt, Schreibweisen vereinheitlicht und fehlende Werte ergänzt. Das ist sinnvoll, reicht aber allein nicht aus.

Nehmen wir ein CRM-System, in dem 14.000 Kunden gespeichert sind, während die Buchhaltung lediglich 9.800 aktive Kunden führt. Eine Analyse zeigt zahlreiche Dubletten. Manche Kunden wurden mehrfach angelegt, andere existieren unter verschiedenen Firmierungen oder unterschiedlichen Schreibweisen. Eine Bereinigung kann diese Bestände zunächst korrigieren. Nachhaltig wird sie aber erst, wenn geklärt wird, warum die Dubletten entstehen.

Vielleicht dürfen mehrere Systeme unabhängig voneinander Kundendaten anlegen. Vielleicht fehlt eine eindeutige Identifikationsnummer. Vielleicht finden Mitarbeiter bestehende Datensätze nicht zuverlässig oder haben keine klare Regel, wann ein neuer Kunde angelegt werden darf.

Wer nur die Daten bereinigt, ohne den Prozess zu verändern, wird dieselbe Arbeit nach einiger Zeit erneut erledigen. Das ist dann zwar Datenpflege, aber noch kein wirksames Datenqualitätsmanagement.

Datenmodelle sind unsichtbar – bis sie schlecht sind

Datenmodelle gehören zu den Bereichen, die im normalen Unternehmensalltag kaum auffallen. Solange sie funktionieren, interessiert sich außerhalb der IT meist niemand sonderlich dafür. Ihre Schwächen werden mit aller Härte sichtbar, wenn Systeme erweitert, integriert oder ausgewertet werden sollen.

Ein sauberer Aufbau klärt beispielsweise, wie Kunden, Ansprechpartner, Standorte und Aufträge miteinander verbunden sind. Er definiert eindeutige Schlüssel, Beziehungen und Datentypen und legt fest, welches System für bestimmte Informationen führend ist.

Probleme entstehen dort, wo Anwendungen über viele Jahre schrittweise erweitert wurden. Für eine neue Anforderung wird zunächst ein weiteres Feld ergänzt. Dann kommt eine zusätzliche Excel-Liste hinzu, später vielleicht eine kleine Access-Anwendung oder ein Importskript. Jede einzelne Erweiterung mag zum Zeitpunkt ihrer Einführung sinnvoll gewesen sein. In ihrer Gesamtheit entsteht jedoch irgendwann eine Architektur, bei der niemand mehr genau sagen kann, welche Information eigentlich woher stammt und mit welchen sie noch in Verbindung steht.

Die berühmte „Übergangslösung“ besitzt dabei eine bemerkenswerte Lebenserwartung. Ich habe bisher noch keine Firma gesehen, die nicht irgendweche "Schattenlisten" oder inoffizielle "Staging-Datenbanken" versteckt hat.

Gute Datenarchitektur bedeutet deshalb nicht, möglichst komplexe Modelle zu entwickeln. Im Gegenteil: Sie soll Strukturen schaffen, die nachvollziehbar, erweiterbar und wartbar bleiben.

Gute Entwickler stellen unangenehme Fragen

Auch auf technischer Seite reicht es nicht, Anforderungen lediglich umzusetzen. Ein guter Entwickler muss verstehen, was fachlich hinter einer Anforderung steckt.

Der Wunsch „Wir brauchen noch ein Feld für den Kundenstatus“ klingt zunächst eindeutig. Bei genauerer Betrachtung ergeben sich jedoch sofort weitere Fragen: Welche Statuswerte gibt es? Wer darf sie ändern? Kann ein Kunde mehrere Status gleichzeitig besitzen? Was bedeutet „inaktiv“ konkret? Müssen frühere Statuswerte nachvollziehbar bleiben? Welche Berichte oder angebundenen Systeme verwenden diese Information?

Solche Rückfragen werden von Fachabteilungen nicht immer begeistert aufgenommen. Schließlich wollte man doch nur „mal eben ein Feld“. Genau diese Fragen verhindern jedoch, dass aus einer kleinen Erweiterung später ein größeres Datenproblem entsteht.

Technische Kompetenz im Datenmanagement bedeutet deshalb nicht nur Programmieren, Administrieren oder Modellieren. Sie umfasst auch die Fähigkeit, fachliche Anforderungen zu hinterfragen und ihre Auswirkungen auf andere Systeme und Prozesse zu verstehen.

Datenqualität ist mehr als Dubletten löschen

Bei Datenqualität denken viele Unternehmen zunächst an doppelte Datensätze. Tatsächlich reicht das Thema wesentlich weiter.

Sind erforderliche Informationen vorhanden? Sind Werte plausibel und aktuell? Werden Einheiten und Schreibweisen einheitlich verwendet? Stimmen Zuordnungen? Gibt es Werte, die fachlich überhaupt nicht möglich sein dürften?

Interessant wird die Analyse vor allem dann, wenn sie nicht bei den Symptomen stehen bleibt.

Finden sich beispielsweise in einer Lieferantendatenbank fünf Varianten desselben Unternehmens – „Müller Maschinenbau GmbH“, „Müller Maschinenbau“, „Mueller Maschinenbau GmbH“, „Müller Masch.bau“ und „Müller Maschinenbau Hamburg“ –, lassen sich diese Datensätze technisch relativ leicht zusammenführen.

Die wichtigere Frage lautet, warum fünf Varianten entstehen konnten. Gab es ausschließlich freie Texteingaben? Fehlt eine eindeutige Lieferantennummer? Werden Stammdaten in mehreren Systemen parallel gepflegt? Oder ist schlicht nicht geregelt, wer für Lieferantendaten verantwortlich ist?

Erst wenn diese Ursache beseitigt wird, verbessert sich die Qualität dauerhaft.

Schlechte Daten werden durch KI nicht besser

Mit Business Intelligence, Machine Learning und künstlicher Intelligenz steigen die Anforderungen an Daten noch einmal deutlich. Denn je stärker Entscheidungen automatisiert oder datenbasiert getroffen werden, desto wichtiger wird die Verlässlichkeit der zugrunde liegenden Informationen.

Eine KI-basierte Prognose kann mathematisch hochentwickelt sein und dennoch ein schlechtes Ergebnis liefern, wenn historische Daten unvollständig sind, Definitionen im Laufe der Jahre mehrfach geändert wurden oder wesentliche Einflussgrößen fehlen.

Das Problem dabei: Komplexe Analysen wirken häufig besonders überzeugend. Eine Prognose von 7,43 Prozent Wachstum vermittelt erheblich mehr Präzision als die Aussage „wahrscheinlich ungefähr sieben Prozent“. Die beiden Nachkommastellen sagen jedoch nichts darüber aus, ob die Datenbasis diese Genauigkeit überhaupt erlaubt.

Unternehmen sollten deshalb vor der Frage „Was können wir mit KI machen?“ zunächst klären, ob sie den entscheidenden Daten ausreichend vertrauen können.

Das klingt weniger spektakulär als ein neues KI-Projekt, besitzt aber häufig den größeren wirtschaftlichen Hebel.

Sprache ist Teil der Datenarchitektur

Ein besonders unterschätzter Bereich des Datenmanagements ist die gemeinsame Sprache.

Unternehmen verwenden ständig Begriffe wie Kunde, Auftrag, Umsatz, Mitarbeiter, Standort, Produkt oder Reklamation. Da diese Begriffe vertraut erscheinen, wird häufig vorausgesetzt, dass alle Beteiligten dasselbe darunter verstehen. In der Praxis ist das erstaunlich selten der Fall.

Wann beginnt beispielsweise eine Reklamation? Bereits beim ersten Anruf eines unzufriedenen Kunden? Erst mit der Eröffnung eines Tickets? Oder nur dann, wenn tatsächlich ein Produkt- oder Leistungsfehler bestätigt wurde?

Je nach Definition kann sich die Reklamationsquote eines Unternehmens erheblich verändern, obwohl sich weder Produkte noch Kundenverhalten verändert haben.

Ein Business Glossary schafft hier Verbindlichkeit, indem wichtige Geschäftsbegriffe eindeutig beschrieben werden. Davon zu unterscheiden ist ein Data Dictionary, das die technische Ebene dokumentiert – etwa Tabellen, Datenfelder, Datentypen, Beziehungen und Wertebereiche.

Diese Arbeit wirkt auf den ersten Blick weniger aufregend als ein neues Analytics-Projekt. Sie verhindert aber sehr wirkungsvoll, dass Führungskräfte stundenlang über Zahlen diskutieren, obwohl sie eigentlich unterschiedliche Definitionen verwenden.

Fallbeispiel: Die plötzlich explodierende Reklamationsquote

Ein Unternehmen stellt im monatlichen Managementbericht fest, dass sich die Reklamationsquote nahezu verdoppelt hat. Qualitätsmanagement, Vertrieb und Geschäftsführung suchen nach Ursachen. Lieferanten werden überprüft, Veränderungen in der Produktion diskutiert und neue Mitarbeiter als mögliche Fehlerquelle betrachtet.

Erst später fällt auf, dass mit der Einführung eines neuen Ticketsystems auch allgemeine Kundenanfragen als Reklamationen klassifiziert werden. Die Produktqualität hat sich überhaupt nicht verändert. Verändert wurde lediglich die Definition beziehungsweise technische Zuordnung der Kennzahl.

Das Beispiel zeigt, warum bei wichtigen KPIs nicht nur der aktuelle Wert dokumentiert werden sollte. Ebenso wichtig sind Definition, Datenquelle und Berechnungslogik.

Datenmanagement sollte nicht nur Fehler verwalten

Wer Datenmanagement ausschließlich mit Bereinigung, Dokumentation und Governance verbindet, greift ebenfalls zu kurz. Gute Daten sind nicht nur ein Mittel zur Risikoreduzierung. Sie können unmittelbar wirtschaftlichen Nutzen erzeugen.

Unternehmen sollten deshalb auch fragen, welche Prozesse durch bessere Daten automatisiert werden können, welche Informationen für bessere Planungen fehlen und welche Daten heute erhoben werden, ohne dass jemand sie tatsächlich nutzt.

Möglicherweise lassen sich Kundenbedarfe früher erkennen, Angebotsprozesse beschleunigen oder Bestände genauer planen. Vielleicht entstehen neue Dienstleistungen, wenn bisher voneinander getrennte Informationen zusammengeführt werden.

Dabei muss es keineswegs immer künstliche Intelligenz sein. In manchen Unternehmen bringt bereits eine saubere Artikel-, Lieferanten- oder Kundennummer erheblich mehr als das nächste innovative Pilotprojekt. Sie eignet sich nur deutlich schlechter für eine spektakuläre PowerPoint-Folie.

Warum Datenprojekte häufig an Kommunikation scheitern

Die für gutes Datenmanagement benötigten Kompetenzen sind in vielen Unternehmen grundsätzlich vorhanden. Das Wissen befindet sich allerdings an unterschiedlichen Stellen. Die IT kennt Systeme und Schnittstellen. Der Vertrieb versteht Kunden und Vertriebsprozesse. Die Buchhaltung kennt finanzielle Abläufe. Das Marketing arbeitet mit Zielgruppen und Kampagnen. Produktion und Logistik kennen operative Abhängigkeiten. Das Management wiederum benötigt verdichtete Informationen für Entscheidungen. Schwierig wird es, wenn diese Bereiche Datenfragen unabhängig voneinander behandeln.

Fachabteilungen formulieren dann Anforderungen als technische Bestellungen. Die IT setzt diese möglichst genau um und stellt einige Monate später gemeinsam mit dem Auftraggeber fest, dass zwar die Anforderung erfüllt wurde, aber nicht das eigentliche Problem. Das bekannte „Das haben wir aber anders gemeint“ ist deshalb nicht nur ein Kommunikationsproblem. Es ist häufig der Ausgangspunkt für schlechte Datenstrukturen.

Fallbeispiel: 800 Leads, von denen der Vertrieb nur 60 haben möchte

Marketing führt eine Kampagne durch und übergibt 800 Leads an den Vertrieb. Aus Sicht des Marketings ist die Kampagne ein Erfolg. Der Vertrieb sieht das deutlich zurückhaltender und hält lediglich 60 Kontakte für ernsthaft interessant.

Auch hier muss keine der beiden Seiten falsch liegen.

Marketing bewertet möglicherweise bereits den Download eines Whitepapers oder die Teilnahme an einem Webinar als Interesse. Der Vertrieb erwartet dagegen einen konkreten Bedarf, ein realistisches Budget und einen identifizierten Ansprechpartner.

Was fehlt, ist eine gemeinsame Definition eines qualifizierten Leads und ein verbindlicher Übergabeprozess.

Auf den ersten Blick handelt es sich um einen Konflikt zwischen Marketing und Vertrieb. Aus Datenperspektive ist es vor allem ein Definitions- und Governance-Problem.

Der Einstieg: Erst verstehen, dann transformieren

Unternehmen müssen nicht sofort ein umfassendes „Enterprise Data Transformation Program“ aufsetzen. Gerade im Mittelstand ist ein pragmatischer Einstieg häufig erfolgreicher.

Am Anfang sollte eine Bestandsaufnahme stehen. Welche wesentlichen Datenquellen existieren? Welche Systeme speichern identische oder ähnliche Informationen? Wo haben sich Excel-Dateien als Nebenbuchhaltung oder Ersatzdatenbank etabliert? Welche Schnittstellen sind geschäftskritisch? Wer pflegt welche Daten? Und bei welchen Kennzahlen beginnt regelmäßig dieselbe Diskussion?

Dabei ist es nicht notwendig, sofort jede Tabelle und jedes Datenfeld zu katalogisieren. Zunächst sollte ein Unternehmen seine wichtigsten Datenflüsse verstehen: Wo entstehen Informationen, wo werden sie verändert, wo werden sie verwendet und wer trägt die fachliche Verantwortung?

Allein diese Fragen liefern häufig bereits ein erstaunlich aussagekräftiges Bild des tatsächlichen Reifegrades.

Konkrete Ziele statt Datenstrategie-Poesie

Auch eine Datenstrategie sollte möglichst eng mit den tatsächlichen Unternehmenszielen verbunden sein. „Wir wollen datengetriebener arbeiten“ klingt modern, beschreibt aber weder ein konkretes Problem noch einen messbaren Nutzen.

Deutlich hilfreicher wären Ziele wie:

• Die monatliche Umsatzplanung basiert künftig auf einer einheitlich definierten Datenbasis.

• Kundendaten werden nicht mehr unabhängig in mehreren Systemen gepflegt.

• Fehlerhafte Artikelstammdaten werden erkannt, bevor sie an den Onlineshop übertragen werden.

• Für geschäftskritische Kennzahlen sind Datenquelle und Berechnungslogik nachvollziehbar.

• Die Anzahl von Kundendubletten wird innerhalb eines Jahres deutlich reduziert.

Aus solchen Zielen lassen sich Maßnahmen, Verantwortlichkeiten und Qualitätskriterien ableiten. Gleichzeitig kann das Management später überprüfen, ob die Investition tatsächlich etwas verbessert hat.

Verantwortung muss dort liegen, wo die Daten verstanden werden

Ein wiederkehrendes Problem besteht darin, dass viele Menschen Daten nutzen, während sich niemand wirklich dafür verantwortlich fühlt. Deshalb sollte zwischen technischer und fachlicher Verantwortung unterschieden werden.

Die IT kann beispielsweise für den zuverlässigen Betrieb eines CRM-Systems zuständig sein. Die fachliche Verantwortung für Kundendaten sollte dagegen dort liegen, wo deren Bedeutung und Qualitätsanforderungen verstanden werden.

In größeren Unternehmen werden hierfür Rollen wie Data Owner oder Data Steward eingerichtet. Kleinere Organisationen müssen deswegen keine zusätzliche Hierarchieebene schaffen. Entscheidend ist weniger die Bezeichnung als die Klarheit der Aufgaben.

Wer entscheidet über Definitionen? Wer bewertet Qualitätsprobleme? Wer genehmigt Änderungen? Wer entscheidet bei widersprüchlichen Informationen zwischen verschiedenen Systemen?

Wenn bei jeder dieser Fragen automatisch die IT genannt wird, ist die organisatorische Verantwortung wahrscheinlich noch nicht vollständig geklärt.

Governance muss zur Unternehmensgröße passen

Auch bei den organisatorischen Strukturen gilt: Nicht jedes Unternehmen braucht dieselbe Lösung. Ein internationaler Konzern kann ein formelles Data Governance Council mit definierten Rollen und Entscheidungsprozessen benötigen. In einem mittelständischen Unternehmen kann eine regelmäßige Abstimmungsrunde zwischen den entscheidenden Fachbereichen und der IT völlig ausreichen.

Wichtig ist, dass dort tatsächlich Entscheidungen getroffen werden: Welche Definition gilt? Wer trägt Verantwortung? Welche Qualitätsregeln werden eingeführt? Welche Probleme haben Priorität?

Und mindestens ebenso wichtig ist, dass diese Entscheidungen dokumentiert und anschließend umgesetzt werden. Andernfalls entsteht eine Form von Governance, bei der man sich regelmäßig trifft, um erfreut festzustellen, dass dieselben Probleme noch vorhanden sind.

Datenkompetenz bedeutet nicht, jeden zum Data Scientist auszubilden

Auch beim Thema Data Literacy schießen Unternehmen gelegentlich über das Ziel hinaus. Nicht jeder Mitarbeiter muss SQL beherrschen, Datenmodelle entwickeln oder statistische Verfahren erklären können. Entscheidend ist vielmehr, welche Datenkompetenz für die jeweilige Aufgabe benötigt wird.

Mitarbeiter, die Informationen erfassen und pflegen, sollten beispielsweise verstehen, warum eindeutige Identifikationsnummern wichtig sind, welche Folgen freie Texteingaben haben können oder warum fehlende Werte nicht beliebig durch null ersetzt werden dürfen.

Führungskräfte benötigen andere Kompetenzen. Sie sollten Kennzahlen kritisch hinterfragen können: Woher stammt eine Zahl? Wie wurde sie berechnet? Welche Annahmen liegen zugrunde? Ist die Datenbasis vollständig? Und lässt sich aus einer beobachteten Veränderung tatsächlich die behauptete Schlussfolgerung ziehen?

Das sind keine Fähigkeiten für Datenwissenschaftler, sondern zunehmend grundlegende Managementkompetenzen.

Software hilft – aber sie ersetzt keine Entscheidungen

Der Markt bietet inzwischen leistungsfähige Lösungen für Data Governance, Master Data Management, Datenqualität, Metadatenmanagement und Datenkataloge. Richtig eingesetzt können solche Systeme erheblichen Nutzen schaffen. Sie ersetzen jedoch keine fachlichen Entscheidungen.

Ein Business Glossary kann Definitionen verwalten, aber das Unternehmen muss sie zuvor festlegen. Ein Data Catalog kann Metadaten dokumentieren, aber irgendjemand muss diese Informationen pflegen. Ein Master-Data-Management-System kann Stammdaten zentralisieren, aber zuvor muss geklärt sein, wer für diese Stammdaten verantwortlich ist und welche Regeln gelten.

Vor einer Softwareauswahl sollte deshalb möglichst klar sein, welches konkrete Problem gelöst werden soll.

Die Reihenfolge „Problem verstehen, Verantwortung klären, Regeln definieren und anschließend Technik auswählen“ ist deutlich weniger spektakulär als eine groß angelegte Transformation. Sie verhindert allerdings recht zuverlässig, dass Unternehmen viel Geld für Software ausgeben, die anschließend organisatorische Probleme verwalten soll, die niemand zuvor lösen wollte.

Lieber eine wichtige Kennzahl vollständig verstehen

Für den Einstieg empfiehlt sich häufig ein überschaubares Pilotprojekt. Statt sofort sämtliche Unternehmensdaten zu katalogisieren, kann beispielsweise eine besonders wichtige Kennzahl vollständig untersucht werden: etwa Umsatz, Auftragseingang, Lieferfähigkeit oder Reklamationsquote.

Dabei wird nachvollzogen, wo die zugrunde liegenden Daten entstehen, welche Systeme beteiligt sind, welche Definition verwendet wird, welche Berechnungen stattfinden und wer für die einzelnen Informationen verantwortlich ist.

Ein solcher Blick entlang der gesamten Datenkette fördert häufig mehr Erkenntnisse zutage als umfangreiche Strategiepräsentationen. Nicht selten entdeckt man dabei manuelle Zwischenschritte, ungeklärte Definitionen oder Excel-Dateien, deren Existenz für mehrere Beteiligte eine Überraschung darstellt.

Genau solche Erkenntnisse sind wertvoll, weil sie zeigen, wo organisatorische und technische Verbesserungen tatsächlich ansetzen müssen.

Woran sich Fortschritt erkennen lässt

Erfolgreiches Datenmanagement lässt sich nicht sinnvoll an der Zahl erstellter Richtlinien, Governance-Dokumente oder neu benannter Rollen messen. Ein umfangreiches Data-Governance-Handbuch kann hilfreich sein. Wenn es allerdings hauptsächlich auf SharePoint liegt und nach seiner Fertigstellung kaum noch geöffnet wird, verbessert es die Datenqualität des Unternehmens nur begrenzt.

Entscheidend ist vielmehr, ob sich Veränderungen im täglichen Arbeiten bemerkbar machen. Zentrale Kennzahlen sollten eindeutig definiert sein, Verantwortlichkeiten bekannt und wichtige Datenquellen nachvollziehbar dokumentiert werden. Werden Qualitätsprobleme entdeckt, sollte nicht nur der einzelne Datensatz korrigiert, sondern möglichst auch die Ursache des Fehlers beseitigt werden.

Ebenso sollte die parallele Pflege identischer Informationen in mehreren Systemen zurückgehen. Mitarbeiter sollten wissen, welches System für bestimmte Daten führend ist und wie Änderungen weitergegeben werden. Bei widersprüchlichen Zahlen sollte sich nachvollziehen lassen, woher die Unterschiede stammen.

Interessanterweise kann zu Beginn einer systematischen Datenqualitätsinitiative sogar die Zahl der bekannten Fehler steigen. Das ist kein Rückschritt. Die Fehler waren meist bereits vorhanden – sie werden lediglich erstmals systematisch sichtbar gemacht.

Langfristig zeigt sich der Fortschritt darin, dass Fehler seltener erneut auftreten, Abstimmungen schneller erfolgen und Entscheidungen auf einer Datenbasis getroffen werden können, deren Herkunft und Bedeutung bekannt sind.

Also: Gute Daten entstehen nicht in der IT allein

Datenmanagement lässt sich nicht an die IT delegieren und damit als erledigt betrachten. Die technische Infrastruktur ist unverzichtbar, aber sie entscheidet nicht über die fachliche Bedeutung der Daten.

Unternehmen benötigen Prozesswissen, vernünftige Datenstrukturen, technische Kompetenz, Qualitätsmanagement, analytische Fähigkeiten und gemeinsame Definitionen. Vor allem müssen diese Kompetenzen miteinander verbunden werden.

Für CEOs und Datenverantwortliche bedeutet das zunächst nicht, möglichst schnell eine neue Organisationseinheit oder Plattform einzuführen. Der sinnvollere Einstieg besteht darin, einige sehr einfache Fragen konsequent zu beantworten: Welche Daten sind für unser Geschäft wirklich wichtig? Wo entstehen sie? Wer nutzt sie? Nach welchen Regeln werden sie gepflegt? Und wer trägt die Verantwortung dafür, dass sie stimmen?

Wer diese Fragen beantworten kann, hat eine erstaunlich solide Grundlage geschaffen.

Und ist damit möglicherweise weiter als manches Unternehmen mit einem stattlichen Technologieetat, einem modernen Data Lake und zwölf Dashboards, die zwölf verschiedene Wahrheiten präsentieren.