Datenqualität für KI – gut genug statt perfekt

Datenqualität entscheidet bei jedem KI-Vorhaben mit, das auf Unternehmensdaten aufsetzt: bei Auswertungen und Prognosen ebenso wie bei automatisierter Angebotserstellung oder Assistenten mit Systemzugriff. Die Datenbasis dafür ist in den meisten Unternehmen über Jahre gewachsen, über mehrere Systeme verstreut und nie für maschinelle Verarbeitung angelegt worden. Diese Lesson zeigt, wie du sie mit vertretbarem Aufwand gut genug machst und hältst. Eine Abgrenzung vorab: Scheitert ein Pilot, liegt die Ursache häufig im Projektzuschnitt und nicht in den Daten; diesen Fall behandelt Pilotprojekte, die ankommen.

Es geht hier um strukturierte Daten: Stammdaten, Aufträge, Artikel, Maschinendaten, alles was in Systemen mit Zeilen und Spalten lebt. Wie du unstrukturiertes Wissen wie Handbücher und Ablagen KI-tauglich machst, behandelt Content ist nicht Context. Und wie du eine einzelne Tabelle auswertest, zeigt Datenanalyse mit KI. Diese Lesson setzt eine Ebene darüber an: bei der Frage, wie die Daten in deinen Systemen dauerhaft gut genug werden, damit KI-Vorhaben darauf bauen können.

Der Aufbau dieser Lesson

Datenqualität lässt sich in vier Dimensionen zerlegen: Vollständigkeit, Korrektheit, Konsistenz und Aktualität. Jede davon ist pro Feld und pro System einzeln prüfbar. Diese Zerlegung ist die Grundlage für alle folgenden Schritte: Erst wenn benannt ist, welche Dimension in welchem Feld schwächelt, lässt sich gezielt etwas beheben.

Warum KI diese Schwächen verstärkt

Ein Mensch überbrückt solche Lücken unbewusst: Wer die drei Zilvenda-Schreibweisen sieht, weiß, dass es ein Kunde ist. Ein KI-System weiß das nicht und behandelt sie als drei Kunden. Damit ist die Umsatzauswertung falsch, die automatische Angebotserstellung zieht die falsche Historie, und der Chatbot gibt je nach Schreibweise andere Auskünfte. Dieselbe Schwäche, die im Tagesgeschäft nur lästig war, wird in automatisierten Abläufen zum Ergebnisfehler.

Für die Reihenfolge von Datenbereinigung und KI-Einsatz gibt es zwei Ansätze: erst alle Daten unternehmensweit in Ordnung bringen und dann starten, oder erst ein konkretes Vorhaben festlegen und nur dessen Daten bereinigen. Der erste Ansatz bindet über Monate Kapazität in Bestandsaufnahme und Abstimmung, ohne dass ein einziges Feld besser wird. Und ohne Use Case fehlt das Kriterium, welche der tausenden Felder überhaupt zählen.

Use-Case-first heißt deshalb: erst das Vorhaben, dann die Daten. Ein konkretes Vorhaben (automatisierte Angebotserstellung, Wartungsprognose, Auswertung der Reklamationen) braucht fast nie das ganze System. Es braucht einen kleinen Ausschnitt: typischerweise 10 bis 20 Prozent der Felder. Nur diese werden bereinigt, und zwar in den vier Dimensionen aus Schritt 1. Das ist dieselbe Logik, mit der Pilotprojekte, die ankommen den Projektzuschnitt behandelt, angewendet auf Daten.

Den Use Case finden

Use-Case-Kandidaten musst du selten erfinden. Sie stecken an drei Stellen im Arbeitsalltag:

• Wiederkehrende Handarbeit an Daten: Berichte, die jeden Monat von Hand zusammengestellt werden, und Zahlen, die zwischen Systemen kopiert werden.
• Wiederkehrende Anfragen: Fragen, deren Antwort in den Systemen steckt, aber jedes Mal jemand heraussuchen muss (Bestellstatus, Preishistorie, Liefertermin).
• Entscheidungen aus dem Bauch: Prognosen zu Absatz, Wartung oder Personaleinsatz, für die Daten vorhanden wären, aber nicht genutzt werden.

Ein Kandidat wird zum tragfähigen Use Case, wenn er vier Bedingungen erfüllt:

Das Vorgehen in vier Zügen

1. Use Case festlegen: aus den Kandidaten den mit dem klarsten Nutzen und dem kleinsten Datenausschnitt wählen. In einem Satz festhalten: Wer bekommt welches Ergebnis auf Basis welcher Daten.
2. Kritische Felder identifizieren: den Ablauf einmal von Hand durchspielen, etwa ein Angebot Schritt für Schritt erstellen, und jedes Feld notieren, das dabei gelesen oder gebraucht wird. Diese Liste ist der kritische Ausschnitt, meist 10 bis 30 Felder, nicht 300.
3. Diese Felder bereinigen: in den vier Dimensionen aus Schritt 1, mit den Methoden aus Schritt 5. Für einen typischen Mittelstands-Use-Case sind das zwei bis vier Wochen, oft durch eine Person in Teilzeit, nicht Monate.
4. Nutzen messen und dann erst skalieren: Erst wenn der Use Case läuft und der Nutzen belegt ist, wird der nächste Datenausschnitt angefasst.

Use-Case-first funktioniert nur, wenn du weißt, wo die Daten für einen Use Case überhaupt liegen. Genau daran scheitert es oft: Die Auftragsdaten leben im ERP, die Kundenhistorie im CRM, die Maschinenstunden in einer Access-Datenbank von 2014, und die wirklich aktuelle Preisliste pflegt der Vertrieb in einer Excel-Datei. Niemand hat den Überblick, also beginnt jedes Vorhaben mit Suchen.

Das Gegenmittel ist bewusst unspektakulär: ein Data Inventory. Eine Tabelle, die pro Datenbestand fünf Angaben festhält. Kein Tool, kein Projekt, ein halber Tag konzentrierte Arbeit mit den Leuten, die die Systeme täglich nutzen.

Was du mit dem Inventory machst

Das Inventory ist ein Nachschlagewerk, kein Umbauplan. Es bedeutet weder, alle Systeme an eine KI anzubinden, noch die Daten in eine zentrale Ablage zusammenzuführen. Für den nächsten Use Case liest du daraus ab, in welchen Systemen die kritischen Felder liegen, wen du ansprechen musst und wo die Qualitäts-Baustellen sitzen. Die Daten selbst holst du dir dann als Export der relevanten Felder aus dem jeweils führenden System (dazu Schritt 4). Ob KI-Systeme später direkt auf Systeme zugreifen sollen, ist eine Architekturfrage, die erst mit einem konkreten Vorhaben ansteht; die Grundlagen dazu behandelt Warum RAG keine Architektur ist.

Über Branchen hinweg wiederholen sich in gewachsenen Systemen dieselben vier Fehlerbilder. Für jedes gibt es ein Gegenmittel, das an der Quelle wirkt, also dort, wo Daten entstehen. Das unterscheidet diesen Schritt von der Bereinigung in Datenanalyse mit KI: Dort wird pro Auswertung bereinigt, hier wird verhindert, dass dieselben Fehler jeden Monat neu entstehen.

Was die Gegenmittel kosten

Keines dieser Gegenmittel braucht neue Software. Dropdowns, Pflichtfelder und Validierungsregeln sind in jedem ERP und CRM Bordmittel, sie wurden nur nie konfiguriert. Verbindliche Schreibweisen sind eine Entscheidung plus eine Seite Dokumentation. Das führende System festzulegen ist eine Managemententscheidung, keine Migration. Der Aufwand liegt fast vollständig in der Abstimmung: sich auf Schreibweisen, Pflichtfelder und Zuständigkeiten zu einigen, kostet Gespräche, keine Lizenzen.

Manuelle Bereinigung skaliert schlecht: 8.000 Kundendatensätze sieht niemand von Hand durch. Sprachmodelle übernehmen genau die Aufgaben, an denen es bisher scheiterte: Ähnlichkeiten erkennen, Freitext einordnen, Widersprüche markieren. Damit wird die Bereinigung größerer Bestände mit vertretbarem Aufwand machbar.

Drei Bereinigungsaufgaben mit Prompts

Alle drei Prompts enden mit derselben Anweisung in Varianten: vorschlagen, nicht entscheiden. Das ist kein Misstrauensritual, sondern Arbeitsteilung. Ob "Zilvenda GmbH" und "Zilvenda GmbH & Co. KG" wirklich derselbe Kunde sind oder eine Ausgründung, steht in keinem Datensatz. Das weiß der Vertrieb. Die KI reduziert 8.000 Datensätze auf 40 Entscheidungsfälle, und diese 40 entscheidet ein Mensch.

Ein bereinigter Datenbestand verfällt ohne Pflege in Monaten: Neue Kollegen kennen die Schreibregeln nicht, unter Zeitdruck kehren alte Gewohnheiten zurück, und jede Systemumstellung bringt neue Varianten mit. Eine einmalige Bereinigung liefert deshalb nur eine Momentaufnahme. Dauerhaft wird Qualität durch eine Schleife aus drei Elementen, die bewusst klein gehalten sind.

1. Eine Kennzahl pro Use Case: messbar und verständlich formuliert, etwa "95 % der aktiven Artikel haben eine vollständige Beschreibung" oder "unter 1 % Dubletten-Kandidaten in der Kundenliste".
2. Ein fester Rhythmus: Die Kennzahl wird monatlich gemessen, idealerweise automatisch als kleiner Report oder als Anzeige im vorhandenen BI-Werkzeug. Sinkt sie, wird nachgesteuert, solange das Problem klein ist.
3. Eine verantwortliche Person: jemand im Fachbereich, der den Datenbestand verantwortet, meist als Teilzeitrolle neben der eigentlichen Aufgabe. Kein neues Team, keine neue Stelle, aber ein Name aus der Verantwortlich-Spalte deines Inventory.

Fachthema, nicht IT-Thema

Der häufigste Konstruktionsfehler ist, die Schleife in der IT aufzuhängen. Die IT sieht Tabellen und Feldtypen, aber sie kann nicht beurteilen, ob eine Materialbeschreibung fachlich vollständig ist oder ob zwei Kunden wirklich einer sind. Diese Urteile liegen im Fachbereich, also gehört die Verantwortung dorthin. Die IT stellt die Werkzeuge: Validierungsregeln, Reports, Exporte.

Gut genug ist ein Zustand, kein Kompromiss

Perfekte Daten sind unerreichbar, und kein KI-Vorhaben braucht sie. Was ein Vorhaben braucht, ist ein sauberer, dokumentierter, verantworteter Ausschnitt, und einen Mechanismus, der ihn sauber hält. Das ist mit den Mitteln dieser Lesson erreichbar: ohne neues System, ohne neue Stelle, ohne Großprojekt. Die Reihenfolge macht den Unterschied: Use Case, Ausschnitt, Bereinigung, Schleife.

Wie diese Lesson im Curriculum hängt

Die Auswertung eines einzelnen Exports, inklusive Bereinigung pro Analyse, zeigt Datenanalyse mit KI. Die Aufbereitung unstrukturierten Wissens für KI-Zugriff behandelt Content ist nicht Context, dessen strukturelle Tiefe Warum RAG keine Architektur ist. Und wenn die Frage nicht mehr ist, ob die Daten stimmen, sondern ob dein KI-Workflow gute Ergebnisse liefert, übernimmt Messen statt raten.