Warum ein KI-Projekt zur Datenbereinigung einen Projektleiter braucht

Kurzantwort: Ein KI-Projekt zur Datenbereinigung scheitert am häufigsten nicht, weil das Modell schwach ist, sondern weil niemand es so führt, wie man ein Team führen würde, das dieselbe Arbeit macht. Das bedeutet: klein genug anfangen, um Vertrauen aufzubauen, bevor skaliert wird, eine konkrete Person benennen, die für das Ergebnis verantwortlich ist, und von der Software dasselbe Reporting, dieselben Zeitpläne und denselben Ansprechpartner erwarten, die Sie auch von einem Team erwarten würden, das diese Arbeit für Sie erledigt.

Auf dieser Seite: Klein anfangen, bevor Sie skalieren · Die Software wie ein Team behandeln · Was Verantwortlichkeit von Software verlangt · Warum Pilotphasen und Validierung entscheidend waren · FAQ

Klein anfangen, bevor Sie skalieren

Aktuelle Branchenforschung liefert eine harte Zahl für ein Muster, das wir direkt in Kundenprojekten sehen: Über 80 Prozent der KI-Projekte liefern nicht das Erwartete, und die durchschnittliche Organisation hat 2025 fast die Hälfte ihrer KI-Proof-of-Concepts verworfen, bevor sie in Produktion gingen. Der wiederkehrende Grund ist nicht, dass die zugrunde liegenden Modelle nicht fähig genug sind. Es sind unklare Erfolgsdefinitionen, schwache Datenfundamente und kein Governance-Rahmen für den Rollout.

Ein FM-Kunde, mit dem wir kürzlich zusammengearbeitet haben, führte sein Datenbereinigungsprojekt durch Pilotphasen statt eines einzigen großen Rollouts über alle Standorte und Kategorien gleichzeitig. Das Projekt lief in seiner ersten Phase enger gefasst als der spätere Umfang, wurde gegen eine validierte Lieferantenliste getestet, bevor es erweitert wurde, und erst danach über den Rest des Unternehmens ausgerollt. Bei der Projektbewertung im Nachhinein waren es die Pilotphasen und die validierte Lieferantenliste, nicht die KI selbst, die der Kunde als Grund dafür identifizierte, dass das Projekt zusammenhielt. Ein Modell, das in einer kontrollierten ersten Phase gut funktioniert und dann sofort die Daten des gesamten Unternehmens erhält, hat keine Chance, seine Grenzfälle aufzudecken, bevor sie teuer werden.

Die Software wie ein Team behandeln

Wenn wir ein Team beauftragen, ein Stück Arbeit zu erledigen, übergeben wir nicht einfach das Briefing und verschwinden bis zur Deadline. Wir erwarten zu wissen, wer verantwortlich ist, wie die Arbeit voranschreitet und wo wir ein Bedenken ansprechen können. Irgendwo im Übergang zu KI-Tools verschwindet diese Erwartung leise, und ein Datenbereinigungsprojekt wird wie ein System behandelt, das man einmal konfiguriert, statt wie eine Arbeitsbeziehung, die man kontinuierlich führt.

Die Lösung ist nicht kompliziert, und sie erfordert keine neue KI-Fähigkeit. Sie erfordert, dieselben Erwartungen anzuwenden. Benennen Sie die Software, im praktischen Sinne, indem Sie dem Projekt einen klaren Verantwortlichen und einen klaren Ansprechpartner geben, so wie Sie die Leitung eines Teams benennen würden, das diese Arbeit macht. Definieren Sie explizit, wer für das verantwortlich ist, was das System produziert, denn „das hat die KI gemacht" ist keine Antwort, die man von einer Person akzeptiert, und sie sollte auch von einem System nicht akzeptiert werden. Das sind keine neuen Disziplinen, die für KI erfunden wurden. Es sind dieselben Disziplinen, an die jedes ausgelagerte oder interne Team bereits gehalten wird, angewandt auf eine andere Art von Mitarbeiter.

Was Verantwortlichkeit von Software verlangt

Manche Erwartungen übertragen sich direkt. Ein Ansprechpartner, eine benannte Person, die eine Frage zur Arbeit beantworten kann, wird gebraucht, egal ob die Arbeit von einem Team oder einem System erledigt wird, und ein KI-Datenbereinigungsprojekt ohne einen solchen ist ein Projekt, bei dem niemand ein Problem eskalieren kann. Andere Erwartungen zeigen sich anders, gelten aber trotzdem. Hätte ein Teammitglied diese Arbeit für Sie erledigt, würden Sie erwarten, ohne Nachfragen über den Fortschritt informiert zu werden. Das Äquivalent für Software ist nicht eine Person, die sich mündlich meldet, sondern das System, das von sich aus zeigt, was passiert ist und wo Aufmerksamkeit nötig ist, nach einem Zeitplan, dem Sie nicht hinterherlaufen müssen.

Dieser Unterschied ist wichtig, weil der Fehlermodus ohne ihn in beiden Fällen derselbe ist: Niemand weiß, wo er hinsehen soll, bis etwas bereits schiefgelaufen ist. Statt dass ein Kunde wiederholt nachfragt, ohne zu wissen, wann er hinschauen soll, ist es weit einfacher, ein Projekt zu führen, das einem nach seinem eigenen Zeitplan mitteilt, was sich geändert hat und wo zuerst Aufmerksamkeit nötig ist. Ein System, das Ergebnisse ohne Einblick in die Konfidenz liefert, ohne Markierung dessen, was geprüft werden muss, und ohne Aufzeichnung dessen, was sich geändert hat, ist nicht leistungsfähiger, weil ihm das fehlt. Es ist schlicht ungeführt, und ungeführte Arbeit scheitert aus denselben Gründen, egal ob eine Person oder ein Modell sie produziert hat.

Warum Pilotphasen und Validierung entscheidend waren

Die konkrete Lehre aus diesem Projekt, verallgemeinert über den einen Kunden hinaus, ist, dass die zwei Dinge, die tatsächlich den Unterschied gemacht haben, strukturell waren, nicht technisch. Pilotphasen bedeuteten, dass Grenzfälle an einem kleinen, überschaubaren Datensatz auftauchten, wo ein falsches Ergebnis günstig zu erkennen und zu korrigieren war, statt am vollständigen Unternehmensdatensatz, wo dasselbe falsche Ergebnis in einen Vorstandsbericht eingeflossen wäre, bevor es jemand bemerkt hätte. Eine validierte Lieferantenliste bedeutete, dass die Klassifizierungsarbeit von einem bereits geprüften Fundament aus begann, statt Unsicherheit bei den Lieferantendaten mit Unsicherheit bei der Klassifizierung obendrauf zu häufen.

Keines dieser Dinge erforderte ein besseres Modell. Beide erforderten jemanden, der das Projekt mit derselben Disziplin führte, die er auch bei einem Team von Menschen anwenden würde: die Arbeit sequenzieren, das Fundament prüfen, bevor darauf aufgebaut wird, und eine benannte Person für das Ergebnis am Ende verantwortlich halten. Das ist das eigentliche Argument dafür, ein KI-Datenprojekt als geführtes Engagement zu behandeln statt als Tool-Deployment. Das Projekt gelingt oder scheitert an denselben strukturellen Entscheidungen, so oder so. Die KI ändert nur, wer oder was die Arbeit innerhalb dieser Struktur leistet.

Häufig gestellte Fragen

Warum scheitern die meisten KI-Datenbereinigungsprojekte?

Die wiederkehrenden Ursachen sind struktureller, nicht technischer Natur: unklare Erfolgsdefinitionen, ein schwaches Datenfundament als Ausgangspunkt und kein Governance-Rahmen für den Rollout. Über 80 Prozent der KI-Projekte liefern nach diesem Muster nicht das Erwartete, und das Scheitern lässt sich meist darauf zurückführen, wie das Projekt geführt wurde, nicht auf eine Grenze des zugrunde liegenden Modells.

Wie kann ich ein erfolgreiches KI-Datenbereinigungsprojekt führen?

Ein erfolgreiches Datenbereinigungsprojekt mit KI zu führen, hängt ironischerweise von den beteiligten Menschen ab. Bevor Sie mit einem Anbieter für KI-Datenbereinigung zusammenarbeiten, fragen Sie immer, wie dieser seine Projekte strukturiert und ob Sie einen dedizierten Success Manager erhalten. Ein menschlicher Ansprechpartner bedeutet, dass jemand die Qualität der Arbeit überwacht, was nötig ist, damit die Automatisierungen langfristig weiter liefern.

Was bedeutet es, KI-Software wie ein Team zu führen, das man managt?

Es bedeutet, dieselben grundlegenden Erwartungen anzuwenden, die Sie an ein Team von Menschen stellen würden, das dieselbe Arbeit macht: eine benannte Person, die für das Ergebnis verantwortlich ist, ein klarer Ansprechpartner, regelmäßige Sichtbarkeit des Fortschritts und ein definierter Prozess zur Eskalation eines Problems. Das sind Projektmanagement-Disziplinen, keine KI-Fähigkeiten, und sie auszulassen ist genau das, was ein fähiges Modell in ein ungeführtes Projekt verwandelt.

Warum waren Pilotphasen bei diesem Projekt wichtiger als das KI-Modell selbst?

Pilotphasen ließen Grenzfälle an einem kleinen, überschaubaren Datensatz auftauchen, wo ein falsches Ergebnis günstig zu erkennen ist, statt am vollständigen Unternehmensdatensatz, wo derselbe Fehler einen Bericht erreicht hätte, bevor es jemand bemerkt hätte. Diese Sequenzierungsentscheidung, nicht ein Unterschied in der Modellfähigkeit, war das, was der Kunde als Grund dafür identifizierte, dass das Projekt zusammenhielt.

Was ist eine validierte Lieferantenliste, und warum ist sie für ein Datenbereinigungsprojekt wichtig?

Eine validierte Lieferantenliste ist eine geprüfte, deduplizierte Referenz von Lieferantendatensätzen, deren Richtigkeit bestätigt ist, bevor die Klassifizierungsarbeit darauf aufbaut. Wenn die Klassifizierung von einer nicht validierten Lieferantenliste ausgeht, summieren sich zwei Unsicherheitsquellen, Lieferantenidentität und Kategoriezuordnung, statt dass eine gelöst wird, bevor man sich der anderen zuwendet.

Wie wendet Pearstop Projektmanagement-Disziplin auf KI-Datenprojekte an?

Pearstop führt Datenbereinigungs- und Klassifizierungsprojekte mit einem dedizierten Ansprechpartner durch, der für den Erfolg verantwortlich ist. Projekte durchlaufen Pilotphasen gegen eine validierte Lieferantenliste, bevor auf volles Volumen skaliert wird, und ein benannter Ansprechpartner ist für das Ergebnis verantwortlich, wobei Fortschritt und Konfidenz nach einem festen Zeitplan gemeldet werden, statt dass der Kunde hinterherlaufen muss. Der schrittweise Ansatz erlaubt es, gründlich zu prüfen, solange das Volumen noch klein ist, und nachzujustieren, bevor skaliert wird.

Ist es jemals sicher, ein KI-Datenbereinigungsprojekt auf einmal im gesamten Unternehmen auszurollen?

Das ist selten die richtige Sequenzierung, selbst wenn die zugrunde liegende Technologie das volle Volumen technisch bewältigen kann. Ein phasenweiser Rollout gegen einen kleineren, validierten Datensatz lässt Grenzfälle auftauchen, während sie noch günstig zu beheben sind, und die Kosten dieser Phasierung sind gering im Vergleich zu den Kosten einer falschen Klassifizierung, die aus einem nicht validierten, unternehmensweiten ersten Durchlauf in einen Vorstandsbericht gelangt.

Stephanie Wiechers

CEO & Co-founder, Pearstop

Stephanie leads Pearstop's go-to-market and strategic direction. She works directly with procurement and FM leaders across Europe to understand how data quality affects margins, contracts, and AI readiness.

LinkedIn →