Stammdatenqualität vor Automatisierung – warum schlechte Daten jeden Workflow bremsen

Automatisierung im Mittelstand klingt nach einer technischen Aufgabe. Ein System soll Bestellungen auslesen, eine Schnittstelle Daten ins ERP übertragen, eine KI E-Mails verstehen, ein Portal Kundenbestellungen direkt in Aufträge verwandeln.

In der Praxis scheitern solche Projekte selten an der Technologie. Sie scheitern an Daten. Eine Kundenartikelnummer lässt sich nicht eindeutig zuordnen. Ein Artikel hat drei Schreibweisen. Eine Verpackungseinheit fehlt. Ein Preis steht im Angebot anders als im ERP. Eine Lieferadresse ist doppelt angelegt.

Solange ein Mensch erfasst, fängt er das auf. Eine Sachbearbeiterin weiß, dass „Art. 4711 alt" der neue Artikel „4711-B" ist, und der Innendienst kennt die Sonderkondition, die nie sauber im ERP gepflegt wurde. Diese stillen Korrekturen passieren jeden Tag. Sie sind teuer, aber sie verhindern Fehler.

Automatisierung nimmt diese Zwischenschicht heraus. Das ist ihr Zweck. Und genau deshalb skaliert sie nicht nur Geschwindigkeit, sondern auch Datenprobleme.

Welche Daten müssen zuverlässig sein, damit ein Prozess automatisch entscheiden darf – und welche bremsen heute jeden Workflow, ohne dass es jemand misst?

Was Stammdatenqualität für Automatisierung wirklich heißt

Stammdaten sind die Daten, auf denen operative Prozesse immer wieder aufbauen: Kunden, Lieferanten, Artikel, Preise, Konditionen, Einheiten, Lieferadressen, Mappingtabellen, Sperrkennzeichen, Mindestbestellmengen. Sie sind keine einmaligen Transaktionsdaten. Sie sind die Grundlage, mit der das System entscheidet, was eine Bestellung bedeutet, welcher Artikel gemeint ist, welcher Preis gilt und ob ein Vorgang automatisch weiterlaufen darf.

Stammdatenqualität bedeutet für Automatisierung deshalb nicht, dass „die Daten irgendwie gepflegt sind". Sie bedeutet: Datensätze sind eindeutig, Pflichtinformationen vollständig, Werte aktuell, Formate konsistent, Beziehungen korrekt, Regeln maschinenlesbar abbildbar, Verantwortlichkeiten geklärt.

Wichtig dabei: Automatisierung braucht nicht perfekte Daten in jedem Bereich. Sie braucht ausreichend gute Daten für den konkreten Prozess. Bei automatisiertem Bestelleingang sind das andere Daten als bei automatisierter Rechnungsprüfung, Lagersteuerung oder Angebotskalkulation. Wer das verwechselt, baut sich ein zu großes Vorprojekt.

Sie merken das daran, dass die Automatisierung still ausweicht

Viele Unternehmen wissen, dass ihre Daten nicht perfekt sind. Sie unterschätzen aber, wie stark diese Datenfehler den operativen Prozess bremsen.

Ein starkes Warnsignal ist der Satz „Das machen wir schnell manuell, weil es im ERP nicht sauber hinterlegt ist." Genau diese Workarounds sind die Stellen, an denen ein Automatisierungsprojekt später stehen bleibt – nicht die exotischen Sonderfälle.

Warum schlechte Daten Automatisierung nicht nur bremsen, sondern riskanter machen

Manuelle Prozesse können schlechte Daten überdecken. Eine erfahrene Mitarbeiterin kennt die Schreibweisen, die Sonderkonditionen, den Standort des Kunden. Automatisierung nimmt diese Korrekturschicht heraus – und genau deshalb müssen Regeln, Daten und Prüfungen vorher sauber genug sein.

Schlechte Stammdaten erzeugen in automatisierten Prozessen typischerweise vier Effekte.

Die Automatisierung bleibt ständig hängen. Bei jeder zweiten Bestellung entsteht ein Prüffall. Das Ergebnis ist nicht Automatisierung, sondern ein neues Ticketsystem. Mitarbeitende prüfen weiter jeden Vorgang, nur jetzt in einem zusätzlichen Tool.

Fehler werden schneller und systematischer. Ein manueller Fehler betrifft einen Auftrag. Ein falsches Mapping, eine falsche Einheit oder eine nicht erkannte Dublette betrifft viele. Automatisierung skaliert Wiederholbarkeit – bei schlechten Daten skaliert sie Fehler. Ich habe das schon gesehen: einmal in einem ERP eingerichtet, fällt es Wochen später bei einer Mahnung auf, dass eine ganze Kundengruppe mit dem alten Listenpreis abgerechnet wurde.

Vertrauen geht verloren. Wenn die ersten automatisierten Vorgänge fehlerhaft sind, prüfen Mitarbeitende danach alles nach. Das System ist technisch live, fachlich aber nicht akzeptiert. Der Automatisierungsgrad bleibt niedrig, weil niemand dem Ergebnis traut.

Sonderlogik wächst unkontrolliert. Statt Stammdaten zu bereinigen, werden Workarounds gebaut: „Wenn Kunde A diese alte Nummer sendet, dann nimm Artikel B – außer die Menge ist größer als 100, dann prüfe manuell." Das löst kurzfristig ein Problem und macht die Lösung langfristig unwartbar.

Wenn das Projekt dann scheitert, lautet die Diagnose oft „Die Technologie funktioniert nicht." Tatsächlich war die Datengrundlage nicht reif – und das Unternehmen sucht ein neues Tool, obwohl zuerst Artikel-, Kunden- oder Mappingdaten geklärt werden müssten.

Welche Stammdaten den Bestelleingang am meisten blockieren

Nicht alle Stammdaten sind für jeden Automatisierungsprozess gleich kritisch. Wer den Bestelleingang automatisieren will, sollte sich zuerst auf die Daten konzentrieren, die direkt entscheiden, ob aus einer eingehenden Bestellung ein korrekter ERP-Auftrag werden kann.

Kunden

Kundenstammdaten sind die Grundlage für Zuordnung, Konditionen und Kommunikation. Kritisch sind Kundennummer, abweichende Firmennamen, Debitorenkonto, Rechnungs- und Lieferadressen, E-Mail-Domains, Kundengruppe, Zahlungs- und Lieferbedingungen, Sperrstatus, Sprache und der bevorzugte Bestellkanal.

Typisches Problem: Derselbe Kunde existiert mehrfach im ERP oder in angrenzenden Systemen. Eine Bestellung lässt sich nicht eindeutig zuordnen. Automatisierung braucht hier klare Regeln – welche Kundennummer ist führend, welche E-Mail-Domains gehören zu welchem Kunden, welche Lieferadresse darf automatisch gewählt werden, wann muss ein Auftrag in die Prüfung.

Artikel und Mapping

Im Bestelleingang muss jede Position eindeutig verstanden werden. Wichtige Felder sind interne Artikelnummer, EAN/GTIN, kundenspezifische Artikelnummern, Ersatzartikel, Status (aktiv, gesperrt, ausgelaufen), Mengeneinheit, Verpackungseinheit, Mindestbestellmenge und Lieferbarkeit.

Häufiger Engpass sind die Mappingtabellen, nicht die Stammdaten selbst: Kundenartikelnummer zu interner Artikelnummer, alte zu neuer Nummer, EDI-Partner-ID zu Kunde, E-Mail-Domain zu Kunde, externe zu interne Lieferadresse. Diese Daten liegen oft historisch in Excel, im Kopf einzelner Mitarbeitender oder in alten Schnittstellenregeln. Wie sich diese Übersetzungsschicht sauber aufbauen lässt, beschreibt der Artikel Kundenartikelnummern automatisch zuordnen.

Preise und Einheiten

Automatisierung wird riskant, wenn Preise nicht eindeutig sind: Listenpreise, kundenspezifische Preise, Staffeln, Aktionen, Rahmenverträge, Rabatte, Zuschläge, Währungen, Gültigkeitszeiträume, Mindestmengen. Wenn der Bestellpreis vom ERP-Preis abweicht, muss eine Regel entscheiden, ob der ERP-Preis gilt, der Bestellpreis akzeptiert wird oder ein Prüffall entsteht. Ohne Regel erzeugt jede Abweichung manuelle Arbeit.

Einheiten klingen banal, sind aber eine der häufigsten Fehlerquellen: Kunde bestellt 10 Stück, ERP führt Kartons; Kunde bestellt 2 Paletten, ERP erwartet einzelne Einheiten; Excel-Bestellung enthält „VE", PDF enthält „Pack", ERP nutzt „Karton". Im manuellen Prozess fängt das jemand ab. Automatisch erzeugt ein falsches Einheitenmapping Fehlmengen, die im Lager auffallen – oder beim Kunden, der eine Palette statt zehn Stück bekommt.

Geschäftsregeln als Stammdaten

Nicht jede wichtige Information sieht wie ein klassischer Stammdatensatz aus. Auch Geschäftsregeln sind Stammdaten für Automatisierung: Welche Preisabweichung ist tolerierbar? Welche Kunden dürfen automatisch angelegt werden? Welche Artikel dürfen nicht automatisch ersetzt werden? Ab welchem Auftragswert ist eine Prüfung nötig?

Wenn solche Regeln nur informell existieren, kann der Prozess nicht sicher automatisiert werden. Sichtbar werden sie meist erst, wenn jemand sie aufschreiben muss.

Warum KI keine Stammdatenpflege ersetzt

KI kann viel im Bestelleingang verbessern: E-Mails klassifizieren, PDF-Bestellungen auslesen, Freitext interpretieren, Artikelbeschreibungen vergleichen, Mappings vorschlagen. Sie ersetzt aber keine Stammdatenqualität.

Wenn ein Artikel im ERP doppelt existiert, kann KI den wahrscheinlichsten Treffer vorschlagen. Sie kann nicht fachlich garantieren, welcher Datensatz führend sein soll. Wenn ein Preis nicht gepflegt ist, kann KI ihn nicht zuverlässig erfinden. Wenn ein Kunde alte Artikelnummern verwendet und keine Mappinghistorie existiert, liefert KI Vermutungen – und Vermutungen sollten nicht automatisch zu ERP-Aufträgen werden.

KI ist stark bei Unsicherheit. ERP-Prozesse brauchen an entscheidenden Stellen Verbindlichkeit. Der tragfähige Ansatz: KI für Erkennung, Klassifikation und Vorschläge. Stammdaten und Regeln für verbindliche Entscheidungen. Unsichere Fälle sichtbar in eine Prüfstrecke. Bestätigte Korrekturen zurück in Mapping und Stammdatenpflege. So entsteht ein Lernkreislauf, ohne dass das System unkontrolliert falsche Daten verarbeitet. Wann „dunkel" überhaupt das richtige Ziel ist, ist Thema des Artikels Dunkelverarbeitung im Bestelleingang.

Wie ein realistischer Datenqualitätscheck aussieht

Ein Datenqualitätscheck muss nicht groß starten. Für einen sinnvollen Einstieg reicht ein klar abgegrenzter Prozess und ein repräsentativer Datensatz: 30 echte PDF-Bestellungen, 20 Excel-Bestellungen, 10 EDI-Aufträge mit Fehlern, die 50 häufigsten Artikel eines Kundensegments, 10 Top-Kunden mit Sonderkonditionen, eine Auswahl manuell korrigierter Aufträge der letzten Wochen.

Das Ziel ist nicht, alle Stammdaten des Unternehmens zu bewerten. Das Ziel ist, die Datenprobleme zu finden, die genau diesen Prozess blockieren.

Schritt 1: Prozess auswählen. Nicht „Datenqualität allgemein". Konkrete Prozesse: Bestellungen aus E-Mail und PDF ins ERP übertragen. Kundenartikelnummern automatisch zuordnen. WooCommerce-Bestellungen ins ERP übernehmen. EDI-Aufträge validieren. Je klarer der Prozess, desto klarer die relevanten Daten.

Schritt 2: Echte Fälle sammeln. Keine idealisierten Beispiele. Echte Bestellungen, echte Fehlerfälle, echte Nacharbeiten. Wertvoll sind die Fälle, die im Alltag Zeit kosten: häufige Rückfragen, fehlerhafte Aufträge, manuell korrigierte Positionen, fehlgeschlagene Importe, Lieferadressprobleme, Preisabweichungen, Artikelsuchen im Freitext.

Schritt 3: Datenfelder pro Prozessschritt identifizieren. Für jeden Schritt notieren, welche Daten gebraucht werden und welche Fehler auftreten:

Prozessschritt	Benötigte Daten	Typische Fehler
Kunde erkennen	Kundennummer, E-Mail-Domain, Firmenname	mehrere Treffer, abweichende Schreibweise
Artikel zuordnen	interne Nummer, Kundenartikelnummer, Beschreibung	kein Mapping, alte Nummer
Menge prüfen	Einheit, VE, Mindestmenge	Stück/Karton verwechselt
Preis prüfen	Kundenpreis, Staffel, Gültigkeit	abweichender Bestellpreis
Lieferadresse prüfen	freigegebene Lieferadressen	neue oder unvollständige Adresse
ERP-Auftrag erstellen	Auftragsart, Zahlungs- und Lieferbedingungen	Pflichtfeld fehlt

Diese Tabelle zeigt oft sofort, warum ein Prozess nicht stabil automatisiert werden kann.

Schritt 4: Datenqualität pro Feld bewerten. Nicht abstrakt, sondern in einfachen Kategorien: Grün – ausreichend für Automatisierung. Gelb – teilweise nutzbar, braucht Regel oder Prüfung. Rot – blockiert Automatisierung. So entsteht ein realistischeres Bild als bei der allgemeinen Frage „Sind unsere Stammdaten sauber?".

Schritt 5: Automatisierungszonen definieren. Nach dem Check werden Vorgänge eingeteilt: automatisch verarbeiten (Daten und Regeln eindeutig), automatisch vorbereiten und manuell freigeben (Risiko bleibt), manuell prüfen (Datenlage zu unsicher), nicht automatisieren (zu selten oder zu komplex). Diese Zonen verhindern, dass schlechte Daten entweder alles blockieren oder unkontrolliert durchlaufen.

Wie Sie Stammdaten verbessern, ohne das ERP neu aufzuräumen

Der größte Fehler bei Stammdatenqualität ist der Anspruch, sofort alles zu bereinigen. Das führt zu großen Projekten, vielen Diskussionen und wenig operativem Fortschritt.

Besser ist ein prozessbezogener Ansatz. Fragen Sie nicht „Welche Stammdaten sind schlecht?", sondern: Welche Stammdaten verhindern, dass dieser konkrete Prozess automatisch läuft?

Das reduziert den Umfang drastisch. Für den Bestelleingang können 50 Top-Artikel, 20 Top-Kunden und die häufigsten Bestellformate wichtiger sein als die vollständige Bereinigung des gesamten Artikelstamms. Priorisiert wird, wo Volumen und Wiederholung hoch sind: Top-Kunden nach Bestellvolumen, häufigste Artikel, wiederkehrende Artikel-Kunden-Kombinationen, Bestellkanäle mit vielen manuellen Schritten, Datenbereiche mit direkter Auswirkung auf Lieferfähigkeit oder Preis.

Datenqualität wird nicht durch eine einmalige Aktion stabil. Sie braucht klare Pflichtfelder, definierte Datenverantwortliche, Freigabeprozesse für kritische Änderungen, Dublettenprüfung, Änderungsprotokolle und die Rückführung von Prüffällen in die Stammdatenpflege. Datenpflege ist dabei keine reine IT-Aufgabe – Fachbereiche müssen definieren, was fachlich korrekt ist, IT stellt Strukturen, Validierung und Automatisierung bereit.

Schattenlisten sollten nicht ignoriert, sondern überführt werden: Import in eine zentrale Mappingtabelle, Abgleich gegen ERP-Stammdaten, Dublettenprüfung, Verantwortlichkeit pro Mapping, Versionierung, Gültigkeitsdatum. Damit wird informelles Wissen schrittweise maschinenlesbar.

Und jeder Prüffall sollte eine Lernquelle sein. Warum wurde der Vorgang gestoppt? Welches Datenfeld war unklar? Welche Korrektur wurde vorgenommen, soll daraus ein neues Mapping entstehen, muss ein Stammdatensatz korrigiert werden? So verbessert jeder manuelle Eingriff die Automatisierung – statt nur den einzelnen Auftrag zu retten.

Welche Prüfregeln vor die ERP-Übergabe gehören

Gute Stammdaten allein reichen nicht. Automatisierung braucht Prüfregeln, die entscheiden, wann ein Vorgang sicher genug ist. Im Bestelleingang sind das im Wesentlichen sechs Prüfgruppen.

Kundenprüfung. Ist der Kunde eindeutig erkannt, aktiv, nicht gesperrt? Ist der E-Mail-Absender bekannt? Ist der Bestellkanal für diesen Kunden erlaubt? Ist die Lieferadresse bekannt oder neu?

Artikelprüfung. Ist der Artikel eindeutig erkannt, aktiv, für die Kundengruppe freigegeben? Liegt eine Kundenartikelnummer vor? Ist ein Ersatzartikel erlaubt? Ist die Mindestmenge eingehalten?

Mengen- und Einheitenprüfung. Ist die Einheit eindeutig, die Umrechnung bekannt, die Menge plausibel, die Verpackungseinheit erfüllt? Ist eine ungewöhnliche Menge erkannt?

Preisprüfung. Ist ein Preis im ERP vorhanden und gültig? Wenn der Bestellpreis abweicht, greift eine Toleranzregel? Sind Staffel oder Rabatt korrekt?

Lieferprüfung. Ist die Lieferadresse eindeutig, das Lieferland erlaubt, der Liefertermin plausibel, die Versandart bekannt?

Risikoprüfung. Sind die Pflichtfelder vollständig, ist die Auftragsart eindeutig, gibt es eine Kundensonderregel, liegt der Auftragswert unter dem definierten Schwellenwert?

Diese Regeln sollten nicht nur im Code versteckt sein, sondern fachlich dokumentiert und änderbar bleiben. Sonst kann niemand außer der ursprünglichen Implementierung erklären, warum eine Bestellung so verarbeitet wurde, wie sie verarbeitet wurde.

Architektur: Datenqualität als Teil des Workflows

Stammdatenqualität sollte nicht nur vor dem Projekt geprüft werden. Sie sollte Teil der Architektur sein – mit klar getrennten Schichten und einer Rückführung in die Daten.

In der Eingangsschicht kommen Daten aus E-Mail, PDF, Excel, CSV, XML, SFTP, EDI, Portal, Shop oder API an. Sie werden normalisiert, damit Vorgänge unabhängig vom Kanal vergleichbar sind. Wann CSV/SFTP gegenüber einer API der bessere Weg ist, beschreibt der Artikel CSV-, XML- und SFTP-Schnittstellen fürs ERP.

In der Erkennung werden Kunde, Bestellnummer, Positionen, Mengen, Einheiten, Preise, Lieferadresse, Liefertermin und Freitext extrahiert – regelbasiert, per Parser oder mit KI-Unterstützung.

Der Stammdatenabgleich prüft, ob die erkannten Daten zu den ERP-Stammdaten passen: Kunde eindeutig, Artikel eindeutig, Preis gültig, Einheit umrechenbar, Lieferadresse bekannt.

Die Regel- und Risikobewertung entscheidet, ob ein Vorgang automatisch ins ERP geht, in eine Prüfstrecke vorbereitet wird, blockiert wird oder ein neues Mapping vorschlägt.

Die ERP-Übergabe schreibt nicht nur Daten. Sie protokolliert nachvollziehbar, welche Daten übernommen wurden, welche Regeln geprüft wurden und welche Unsicherheiten es gab.

Der Prüffall-Workflow zeigt erkannte Daten, vorgeschlagene Zuordnung, Grund für den Prüffall, mögliche Korrektur und Auswirkung auf Stammdaten – nicht eine Fehlermeldung wie „Fehler Artikelnummer", sondern eine fachlich entscheidbare Aufgabe.

Und die Rückführung in Datenqualität ist die Schleife, die vielen Architekturen fehlt. Wenn eine Mitarbeiterin eine Kundenartikelnummer zuordnet, entsteht daraus ein neues geprüftes Mapping. Wenn eine Lieferadresse bestätigt wird, wird sie in den Stammdaten ergänzt. Wenn eine Preisabweichung regelmäßig akzeptiert wird, muss die Konditionslogik geprüft werden. Genau diese Rückführung entscheidet, ob die Quote über die Zeit steigt oder konstant bleibt.

Welche Kennzahlen sichtbar machen, ob die Datenqualität besser wird

Datenqualität sollte messbar sein, aber prozessnah. Eine reine Automatisierungsquote reicht nicht – sie kann auch dann hoch sein, wenn das System zu großzügig durchwinkt.

Eine sinnvolle Kombination:

Kennzahl	Frage	Was sie zeigt
Automatisierungsquote	Wie viele Vorgänge laufen ohne Eingriff durch?	Entlastungspotenzial
Prüffallquote nach Ursache	Warum landet ein Vorgang in der Prüfung?	Wo Datenqualität konkret blockiert
Ersttrefferquote Artikelzuordnung	Wie oft wird ein Artikel sofort eindeutig erkannt?	Reife des Mappings
Mapping-Abdeckung Top-Kunden	Wie viele wiederkehrenden Kombinationen sind gemappt?	Hebel für die nächsten Quotenpunkte
Preisabweichungsquote	Wie oft weicht der Bestellpreis vom ERP-Preis ab?	Pflegezustand der Konditionsdaten
Nacharbeitszeit pro Vorgang	Wie viel Zeit kostet die Korrektur?	Tatsächliche Entlastung
Wiederholrate Prüffallgründe	Kommt derselbe Fall mehrfach?	Ob Prüffälle in Datenqualität zurückgeführt werden

Eine 55-%-Quote mit fast keinen nachträglichen Korrekturen ist besser als 85 % mit hoher Korrekturquote. Das Ziel ist nicht maximale Automatisierung um jeden Preis, sondern maximale Entlastung bei kontrolliertem Risiko.

Ein realistischer Pilot in 30 bis 60 Tagen

Ein guter Pilot zur Stammdatenqualität ist klein genug, um schnell zu starten, und real genug, um echte Erkenntnisse zu liefern.

Sie merken das daran, dass die Diskussion im Pilot von „Welches Tool brauchen wir?" zu „Welche Bestellung darf wie laufen, mit welchen Daten?" wandert. Genau dann beginnt Datenqualität, ein operativer Hebel zu werden statt eines abstrakten MDM-Themas.

Typische Fehler bei Stammdaten und Automatisierung

Die wirtschaftliche Frage lautet selten „Wie hoch wird unsere Datenqualität?". Sie lautet: Welche Daten sind heute gut genug, welche blockieren den Prozess, und welche Korrekturen aus dem Tagesgeschäft fließen wirklich zurück in Stammdaten und Mapping?

Fazit

Automatisierung ist kein Ersatz für Stammdatenqualität. Sie macht gute Daten wertvoller – und schlechte Daten sichtbarer.

Wer Bestelleingang, ERP-Schnittstellen, B2B-Portale oder KI-Workflows automatisieren will, sollte deshalb nicht zuerst fragen, welche Technologie gebraucht wird. Sondern: welche Daten zuverlässig sein müssen, damit der Prozess automatisch entscheiden darf.

Der pragmatische Weg ist immer derselbe. Einen konkreten Prozess auswählen, echte Vorgänge analysieren, kritische Stammdaten identifizieren, Datenqualität pro Schritt bewerten, sichere Fälle automatisieren, unsichere Fälle in eine Prüfstrecke geben und Prüffälle in Datenverbesserung zurückführen.

So entsteht Automatisierung, die wirklich entlastet. Nicht, weil alle Daten perfekt sind. Sondern weil klar ist, welche Daten gut genug sind, welche Regeln gelten und welche Fälle nicht blind verarbeitet werden dürfen.

FAQ zur Stammdatenqualität vor Automatisierung