Datenqualität als Compliance-Faktor ist ein Thema, das in vielen Technischen Redaktionen aktuell ist. Worauf in der Praxis wirklich ankommt, jenseits von Marketing und Tool-Versprechen.
Es klingt unspektakulär: ein falsches Gewicht in einer Produktdatenbank. Ein paar Kilogramm daneben, irgendwo in einem System, das schon lange niemand mehr gründlich geprüft hat. Und dann kommt ein Millionenbußgeld. Nicht wegen einer groben Fahrlässigkeit, nicht wegen einer strategischen Entscheidung. Stattdessen wegen einer Datenpanne, die systematisch hätte verhindert werden können.
Ich habe auf mehreren Fachtagungen zu diesem Thema gesprochen, und jedes Mal ist die Reaktion im Saal dieselbe: zuerst ein leichtes Nicken — „ja, kenne ich“ — und dann eine merkwürdige Stille, in der die Zuhörenden offensichtlich anfangen zu rechnen, ob das bei ihnen auch passieren könnte.
Die Antwort ist in den meisten Fällen: ja.
Warum Datenqualität kein IT-Problem ist
Das erste Missverständnis, das ich regelmäßig antreffe, ist folgendes: Datenqualität wird als technisches Thema behandelt, das irgendwo in der IT oder im Qualitätsmanagement angesiedelt ist. Jemand ist zuständig, irgendein Tool läuft, irgendjemand führt ab und zu einen Datenexport durch und schaut sich die Zahlen an. Das Ergebnis dieser Zuständigkeitsdiffusion ist, dass de facto niemand zuständig ist.
Daten entstehen an Schnittstellen. Sie entstehen dort, wo Menschen Informationen erfassen — in der Konstruktion, in der Produktentwicklung, im Einkauf, im Vertrieb, in der Technischen Redaktion. Jede dieser Stationen hat ihre eigene Systematik, ihre eigenen Felder, ihre eigenen Gepflogenheiten beim Befüllen. Wenn diese Stellen nicht durch ein gemeinsames Governance-Modell verbunden sind, sammeln sich Fehler an. Nicht weil die Menschen schlecht arbeiten, sondern weil das System es zulässt.
Datenqualität ist deshalb keine technische Frage, sondern eine Führungsfrage. Wer entscheidet, welche Daten wie gepflegt werden? Wer ist verantwortlich, wenn ein Wert falsch ist? Wer prüft, ob ein Produkt wirklich das Gewicht hat, das im System steht? Wenn auf diese Fragen keine klare Antwort existiert, ist das Problem nicht die Software, sondern die Organisation.
Typische Fehlerbilder — und warum sie sich wiederholen
Ich sehe in der Praxis immer wieder dieselben Muster. Nicht bei einem bestimmten Unternehmenstyp, bei allen. Großunternehmen, Mittelständler, gut aufgestellte Betriebe mit ISO-Zertifizierung und alle.
Das häufigste Muster: Informationssilos. Produktdaten leben in der Konstruktionssoftware. Technische Daten für die Dokumentation leben im CCMS oder in einer Excel-Datei. Logistikdaten für den Versand leben im ERP. Marketingdaten für den Online-Shop leben im PIM-System. Wenn niemand dafür gesorgt hat, dass diese Systeme miteinander reden — oder dass zumindest ein Mensch die Konsistenz regelmäßig überprüft, dann sind Abweichungen unvermeidlich. Irgendwann wird ein Produktgewicht im ERP aktualisiert, weil ein Lieferant einen anderen Werkstoff verwendet hat. Aber im Online-Shop steht noch der alte Wert. Und wenn der Zoll oder eine Aufsichtsbehörde das überprüft, interessiert es niemanden, dass das ERP korrekt war.
Das zweite Muster: fehlende Validierung. Daten werden ohne automatisierte Prüfmechanismen freigegeben. Ein Redakteur oder Sachbearbeiter gibt eine Information frei, weil sie plausibel klingt, nicht weil sie verifiziert wurde. Das ist ein Vorwurf an den Prozess, nicht an die Person — der Prozess der keine Validierungsschleusen eingebaut hat.
Das dritte Muster: keine Governance-Struktur. Es gibt Daten, aber niemanden, der offiziell für ihre Richtigkeit verantwortlich ist. Wenn ein Fehler auftaucht, beginnt die Suche: Wer hat das eingetragen? Wer hätte es prüfen müssen? Was war die Quelle? In vielen Unternehmen ist diese Frage nicht innerhalb von fünf Minuten zu beantworten, was bei einem regulatorischen Audit fatal ist.
Was auf dem Spiel steht
Der konkrete Fall, auf den ich eingangs angespielt habe, ein Millionenbußgeld wegen fehlerhafter Gewichtsangaben — ist kein Einzelfall. Er ist symptomatisch. Die rechtliche Grundlage für solche Bußgelder ist je nach Branche unterschiedlich: Maschinenrichtlinie, CE-Kennzeichnungspflicht, Produktsicherheitsgesetz, Verpackungsverordnung, Datenschutzgrundverordnung, Lieferkettensorgfaltspflichtengesetz. Die Liste wird länger, nicht kürzer.
Und die Behörden prüfen zunehmend genauer. Nicht weil sie Unternehmen schikanieren wollen, sondern weil die Digitalisierung es ihnen leichter macht. Automatisierte Prüfroutinen, digitale Produktpässe, Marktüberwachung auf Basis von Datenbankabgleichen, das ist keine ferne Zukunft, das passiert bereits.
Wer also heute noch die Haltung hat, Datenqualität sei ein Nice-to-have, riskiert morgen eine Prüfung, die teuer wird. Und die Kosten eines Bußgeldes sind dabei noch das kleinste Problem. Rückrufe, Lieferstopps, Reputationsverlust, interne Aufräumarbeiten, das ist das eigentliche Schadenbild.
Was konkret hilft — und was nicht
Es gibt keine Abkürzung. Wer mir erzählt, er habe ein neues PIM-System eingeführt und damit sei das Datenqualitätsproblem gelöst, dem sage ich: Nein. Ein System kann schlechte Prozesse nicht reparieren. Es kann sie manchmal sichtbarer machen, was schon wertvoll ist —, aber es löst sie nicht.
Was hilft, ist eine Kombination aus drei Dingen:
Erstens Governance. Definieren Sie, wer für welche Daten verantwortlich ist. Nicht im Sinne von „wer trägt ein“, sondern im Sinne von: wer ist fachlich verantwortlich für die Richtigkeit? Wer muss freigeben, bevor eine Information in die Welt geht? Das muss in Prozessen und Stellenbeschreibungen verankert sein, nicht nur in Köpfen.
Zweitens Systemintegration. Wenn Produktdaten in vier verschiedenen Systemen leben, ist die Wahrscheinlichkeit von Inkonsistenzen hoch. Das bedeutet nicht, dass alle vier Systeme zu einem zusammengeschlossen werden müssen, das ist in den meisten Organisationen weder machbar noch sinnvoll. Aber es bedeutet, dass Schnittstellen definiert sein müssen: Welches System ist die führende Quelle für welche Art von Daten? Und wie stellen Sie sicher, dass nachgelagerte Systeme diese Quelle nutzen und nicht eigene Versionen entwickeln?
Drittens Qualitätssicherung im Prozess. Nicht als nachgelagerte Kontrolle, sondern als integrierter Bestandteil des Datenentstehungsprozesses. Automatisierte Validierungsregeln, die greifen, bevor ein Datensatz freigegeben wird. Pflichtfelder, Plausibilitätsprüfungen, Vieraugenprinzip bei kritischen Attributen. Das ist eine Investition, kein bloßer Aufwand: weil es den Aufwand der Fehlerbehebung dramatisch reduziert.
Ein persönlicher Tipp von mir: Fangen Sie nicht mit einer großen Datenbereinigungsaktion an. Die meisten solcher Projekte verlieren sich im Umfang und enden halbfertig. Fangen Sie stattdessen mit einer Frage an: Welche Daten könnten uns morgen ein Bußgeld einbringen oder einen Rückruf auslösen? Beginnen Sie dort mit Governance und Validierung. Der Rest folgt.
Für wen das gilt
Diese Erkenntnisse sind für nahezu jedes Unternehmen relevant, das physische Produkte herstellt oder in stark regulierten Branchen tätig ist. Maschinenbau, Medizintechnik, Automotive, Konsumgüter mit Sicherheitsrelevanz. Aber auch im B2B-Dienstleistungsbereich werden Daten zunehmend regulatorisch relevant: Datenschutz, Sorgfaltspflichten in der Lieferkette, Nachhaltigkeitsberichterstattung.
Es gibt Unternehmen, für die das weniger dringlich ist. Beratungen ohne Produktverantwortung, rein kreative Dienstleister. Aber auch dort ist die Qualität von Kundendaten oder internen Prozessdaten oft ein unterschätztes Risiko. Ich sage bewusst „weniger dringlich“, nicht „nicht relevant“.
Wenn Sie unsicher sind, ob bei Ihnen Handlungsbedarf besteht: In der Regel lohnt sich ein kritischer Blick auf drei Punkte. Erstens: Können Sie bei jedem relevanten Produktattribut sagen, welches System die autoritative Quelle ist? Zweitens: Haben Sie definierte Verantwortlichkeiten für kritische Datenkategorien? Drittens: Gibt es automatisierte Prüfmechanismen, bevor Daten publiziert oder an Behörden übermittelt werden?
Wenn die Antwort auf eine dieser Fragen „eigentlich nicht“ lautet, dann lautet die Empfehlung: Handeln Sie. Nicht weil es regulatorisch schön wäre. Sondern weil der nächste Prüfer vielleicht nur eine Datenbankabfrage weit entfernt ist.
Weiterführende Standards und Branchen-Information bei der tekom — Gesellschaft für Technische Kommunikation.
Mehr zu konkreten Praxisfällen finden Sie in unserer Beitragsreihe zu Künstlicher Intelligenz und Technischer Dokumentation.
