Derselbe Kunde existiert dreimal, und jedes System kennt eine andere Version.
Kunden-, Lieferanten- und Artikeldaten liegen parallel in drei Welten: im ERP, im CRM und in einer Handvoll Excel-Dateien, die niemand anfassen will. Keines der drei Systeme ist absichtlich falsch. Sie sind über die Jahre einfach auseinandergelaufen.
Änderungen kommen per Mail. Ein Lieferant meldet eine neue Bankverbindung, ein Kunde eine neue Rechnungsadresse, ein Ansprechpartner geht. Wer die Mail liest, pflegt sie in dem System nach, in dem er gerade arbeitet, und macht weiter. Die anderen beiden behalten den alten Wert. Ein halbes Jahr später kann niemand mehr sagen, welche Version stimmt.
Dubletten entstehen auf demselben Weg, weil eine Firma ein zweites Mal mit leicht anderer Schreibweise angelegt wird. Die Folgen bleiben nicht in den Daten: Mahnläufe gehen an Adressen, an denen niemand mehr sitzt, Lieferungen an ein stillgelegtes Lager, und jede Auswertung zählt eine Firma still als zwei.
Wir klären zuerst, wem welches Feld gehört, dann bauen wir die Software.
Stammdatenprojekte scheitern, wenn sie mit einer Synchronisation anfangen. Zwei Systeme, die aufeinander zeigen, ohne dass entschieden ist, wem welches Feld gehört, überschreiben sich abwechselnd. Und die Bedingungen des Teams werden zur Spezifikation: Bankverbindungen laufen nie automatisch, jeder Vorschlag zeigt seine Quelle, und die Regeln pflegt das Team selbst.
- Führendes System je Feld festlegen: Pro Datenart und pro Feld wird entschieden, welches System führt. Meist das ERP bei kaufmännischen Feldern wie Zahlungsziel und Steuernummer, das CRM bei Ansprechpartnern und Rollen. Felder ohne Verantwortlichen sind genau die, die auseinanderlaufen.
- Bewusst klein starten: Der erste Umfang ist eine Datenart und ein Systempaar, zum Beispiel Lieferanten zwischen ERP und CRM. Schmal genug, dass das Team in den ersten Wochen jeden Vorschlag prüfen kann.
- Bestand einmal aufräumen: Der KI-Mitarbeiter listet Dubletten mit beiden Datensätzen nebeneinander und Abweichungen Feld für Feld. Das Team arbeitet die Liste ab. Genau dabei werden die echten Regeln sichtbar.
- Go-live erst nach dem Okay vom Team: Danach beobachtet der KI-Mitarbeiter neue und geänderte Datensätze laufend. Live geht das System erst, wenn die Sachbearbeitung sagt: Die Vorschläge stimmen, und ich sehe, woher sie kommen.
80 Prozent macht der KI-Mitarbeiter. An zwei Stellen entscheidet der Mensch.
Zwei Dinge lösen den KI-Mitarbeiter aus. Das erste sind die Daten selbst: Er geht eine Datenart systemübergreifend durch, erkennt denselben Kunden oder Lieferanten über ein Bündel aus Signalen und meldet zwei Arten von Fund, nämlich Dubletten innerhalb eines Systems und Abweichungen zwischen Systemen. Das zweite ist der Posteingang: Mails und angehängte Dokumente werden auf gemeldete Änderungen gelesen und dem passenden Datensatz zugeordnet, bevor jemand etwas tippt.
Jeder Fund wird zu einem Vorschlag mit Quelle. Man sieht, welche Mail, welches Dokument und welches Feld in welchem System was gesagt hat. Die Sachbearbeitung gibt die Änderung frei und bestätigt den Dubletten-Merge. Erst danach schreibt der KI-Mitarbeiter zurück, und zwar in das System, dem das Feld gehört, mit einem Protokolleintrag, der die Quelle behält. Bankverbindungen gehen immer über vier Augen.
Ein Lieferant schreibt, dass die Firma nach einer Fusion umfirmiert wurde und Rechnungen ab dem Ersten des Folgemonats auf ein neues Konto gehen. Ein unterschriebenes Änderungsschreiben hängt als PDF an.
Ein Feld ist zur Prüfung markiert: Die Bankverbindung ist das Feld, auf das Zahlungsbetrug zielt. Zwei Personen prüfen sie gegen das Änderungsschreiben, bevor ein einziges Zeichen geschrieben wird.
Das war vorher, das ist heute.
So lief die Stammdatenpflege vorher, und so läuft sie heute mit dem KI-Mitarbeiter. Konservativ gerechnet spart das rund 80 Prozent des Pflegeaufwands pro Änderung.
| Vorher | Heute | |
|---|---|---|
| Gemeldete Änderung | In ein System getippt, von wem auch immer die Mail las | Ein belegter Vorschlag für jedes betroffene System |
| Dubletten | Zufällig gefunden, meist nach einem Fehler | Über ein Signalbündel erkannt, nach Bestätigung zusammengeführt |
| Abweichende Felder | Niemand weiß, welches System recht hat | Führendes System je Feld, Abweichungen sind gelistet |
| Bankverbindung ändern | Absprachesache, teils von einer Person allein | Nie automatisch, immer über vier Augen |
| Nachvollziehbarkeit | Keine Spur, wer was warum geändert hat | Jede Änderung mit Quelldokument protokolliert |
* Einsparung konservativ gerechnet: eine gemeldete Änderung vorher 10 bis 15 Minuten, weil mehrere Systeme geöffnet, gesucht und getippt werden, heute rund 1 Minute Freigabe auf einem fertigen Vorschlag. Gerechnet mit der unteren Grenze von 10 Minuten. Bei 400 bis 800 Änderungen im Jahr sind das 60 bis 120 Stunden, also zwei bis drei Arbeitswochen, und bei rund 40 Euro Vollkosten pro Sachbearbeitungsstunde ein mittlerer vierstelliger Betrag. Die Nacharbeit für fehlgeleitete Mahnungen und Lieferungen ist darin nicht enthalten, weil sie sich ehrlich nicht beziffern lässt.
Wie baut man so einen KI-Mitarbeiter technisch?
Das Wissen aus diesem Use Case zum Mitnehmen, egal ob ihr mit uns baut oder selbst:
Änderungen aus Mails und Dokumenten lesen
Gemeldete Änderungen kommen als Fließtext, als PDF-Anhang oder als Scan. Sprachmodelle wie GPT von OpenAI oder Claude von Anthropic lesen beides und ziehen die einzelnen Felder heraus: neuer Name, neue Adresse, neuer Ansprechpartner, neue Bankverbindung. Jedes Feld bekommt seine Fundstelle im Dokument, damit der Vorschlag später belegbar ist.
Dubletten über ein Signalbündel finden
Exakter Textabgleich findet in gewachsenen Daten fast nichts. Müller GmbH, Mueller G.m.b.H. und Müller Gesellschaft mbH sind drei Datensätze für eine Firma. Ein Fuzzy-Matching vergleicht deshalb ein Bündel: normalisierter Name, Adresse, USt-ID, Registernummer, Bankverbindung, Ansprechpartner, Bestellhistorie. Jedes Signal für sich ist schwach, zusammen tragen sie einen Merge-Vorschlag.
Regeln statt KI, wo es um Zuständigkeit geht
Welches System bei welchem Feld führt, ist eine Entscheidung, keine Wahrscheinlichkeit. Das gehört in eine feste Regel, nicht in ein Modell. Dasselbe gilt für die Frage, welche Felder automatisch geschrieben werden dürfen. Bankverbindungen stehen dort grundsätzlich nicht drin.
Anbindung: die bestehenden Systeme bleiben
Der KI-Mitarbeiter hängt über die Schnittstellen von SAP und Microsoft Dynamics am ERP, über die CRM-Schnittstelle am Vertrieb und über Microsoft Graph an Outlook und den Excel-Dateien. Es gibt keine neue Stammdatenplattform und keine Migration.
UX: die Oberfläche entscheidet über die Akzeptanz
Ein Prüf-Screen zeigt den Änderungsvorschlag und die Quelle Seite an Seite, also links die Mail oder das Dokument, rechts das Feld mit altem und neuem Wert. Kritische Felder haben eine eigene Vier-Augen-Freigabe. Und die Regeln haben eine eigene Ansicht, in der das Team sie selbst ändert. Genau diese drei Dinge haben aus Skepsis Zustimmung gemacht.
Was kostet das im Vergleich?
Superkind rechnet pro Use Case ab. Der Preis wächst mit dem Datenvolumen, nicht mit dem Personalbestand. Hier die ehrliche Gegenüberstellung:
| Manuelle Pflege | MDM-Software | Superkind KI-Mitarbeiter | |
|---|---|---|---|
| Kosten | 55.000 bis 75.000 € pro Jahr für eine Sachbearbeitung | Oft 50.000 € und mehr für die Einführung, dazu Lizenz und Datenpfleger | Preis pro Use Case, ein Bruchteil einer Vollzeitstelle |
| Was ist enthalten | Der komplette Abgleich, von Hand | Steuerung und Regelwerk, aber kein Lesen von Mails | Lesen, Abgleichen, Dubletten, Vorschlag mit Quelle, Rückschreiben |
| Skaliert mit | Mehr Personal | Lizenzstufen und Pflegeaufwand | Datenvolumen, ohne neue Stellen |
| Ausnahmen | Mensch macht alles | Bleiben liegen | Gehen markiert an einen Menschen |
| Einführung | Rekrutierung und Einarbeitung | Mehrmonatiges Projekt | 2 bis 3 Wochen bis zur ersten produktiven Version |
Der ehrliche Vergleich sind die vollen Kosten auseinanderlaufender Daten: die Pflege selbst, die Folgefehler in Mahnwesen und Logistik und die Auswertung, die eine Firma still als zwei zählt.
Was wir aus diesen Projekten gelernt haben.
Stammdaten sind der am meisten unterschätzte Baustein der ganzen KI-Diskussion. Unternehmen planen einen Rechnungs-Assistenten, einen Mahn-Assistenten und ein Reporting, und dann stolpern alle drei über dieselben doppelten Lieferanten. Für Datenpflege bekommt niemand Budget genehmigt, für den Use Case, der ohne sie scheitert, bekommt es jeder. Unser ehrlicher Rat: die langweilige Schicht zuerst.
Das Zweite: Die Angst dreht sich nie um Können, sondern um Schreibrechte. Niemand bezweifelt, dass ein Modell eine Dublette findet. Die Teams bezweifeln, dass sie in sechs Monaten noch wissen, was mit ihren Daten passiert ist. Deshalb ist die Quelle am Vorschlag kein Extra, sondern die Eintrittskarte.
Wofür es sich nicht eignet: Wenn alle Stammdaten in einem einzigen System liegen und eine Person sie diszipliniert pflegt, gibt es nichts abzugleichen. Wenn niemand entscheiden darf, welches System bei welchem Feld führt, entsteht nur eine längere Konfliktliste. Und ein Altsystem ohne Schnittstelle und ohne Export ist eine Wand, die vorher geklärt gehört.
