Ein Dashboard kann grün sein, während die Entscheidung dahinter falsch ist. Ein Finanzteam erhält womöglich einen vollständig wirkenden aufsichtsrechtlichen Bericht, obwohl ein Quellsystem einen Codewert geändert hat. Analysten vergleichen unter Umständen zwei Kundenkennzahlen, die unterschiedliche Definitionen verwenden. Ein Betriebsteam handelt vielleicht auf Basis der Daten von gestern, weil die Pipeline verspätet lieferte, ohne einen Alert auszulösen.

Solche Fehler sind schwer zu diskutieren, wenn jedes Team unter „Datenqualität“ etwas anderes versteht. Der eine meint Genauigkeit, die andere Aktualität, ein Dritter, ob die Tabelle verfügbar war, als ein Job lief. ISO/IEC 25012 gibt diesen Gesprächen ein gemeinsames Vokabular und liefert dann einen strukturierten Weg, Qualitätserwartungen mit messbaren Prüfungen zu verbinden.

Die nützliche Frage lautet nicht, ob ein Datensatz „gut“ ist. Sie lautet, ob der Datensatz für einen bestimmten Zweck geeignet ist und ob die Organisation diese Eignung über die Zeit nachweisen kann. Der Weg vom Modell zur Praxis führt über Definitionen, Prioritäten, Kontrollen, Scorecards, Ausnahmeprozesse und Auditnachweise.

Inhaltsverzeichnis

• Einleitung: Warum Datenqualität ein gemeinsames Modell braucht

  • Die versteckten Kosten unscharfer Qualitätssprache

  • Vom Vokabular zum operativen Nachweis

• Was ISO 25012 ist und warum es existiert

  • Betrachten Sie es als Bauordnung

  • Wobei das Modell Teams hilft

• Die 15 Datenqualitätsmerkmale einfach erklärt

  • Inhärente Qualität

  • Systemabhängige Qualität

• ISO 25012 für Unternehmensdatenprogramme auslegen

  • Von Merkmalen zu Anforderungen

  • Eine Scorecard braucht Kontext

• ISO 25012 auf Observability- und Validierungskontrollen abbilden

  • Eine praktische Kontrollmatrix

  • Datenfehler von Plattformfehlern trennen

• Branchenbeispiele, in denen ISO 25012 teure Fehler verhindert

  • Finanzdienstleistungen

  • Gesundheitswesen

  • Telekommunikation

  • Öffentlicher Sektor

• Umsetzungs-Checkliste und Grundlagen der Auditberichterstattung

Einleitung: Warum Datenqualität ein gemeinsames Modell braucht

Ein Data Engineer stellt fest, dass eine tägliche Kundentabelle erfolgreich geladen wurde. Der Pipeline-Status ist grün, die Zeilenzahlen wirken vertraut, und das BI-Dashboard hat sich fehlerfrei aktualisiert. Später entdeckt das Vertriebsteam, dass eine Quellanwendung begonnen hat, einen neuen Statuscode zu senden. Die Datensätze sind vorhanden, doch die Geschäftslogik interpretiert sie falsch.

Nichts an diesem Vorfall sieht zwingend nach einer fehlenden Datei oder einem gescheiterten Job aus. Die Daten können verfügbar, aber für die Entscheidung nicht genau sein. Sie können auf Satzebene vollständig, aber inkonsistent zu einem anderen System sein. Sie können in ihrer Herkunft glaubwürdig und dennoch nicht mehr aktuell genug für den konsumierenden Prozess sein.

Die versteckten Kosten unscharfer Qualitätssprache

Fehlt Teams ein gemeinsames Modell, entstehen häufig lokale Definitionen. Ein Finanzdatensatz hat vielleicht eine Vollständigkeitsregel, während ein Gesundheitsdatensatz eine andere Auslegung verwendet. Engineering überwacht womöglich die Lieferzeit, Analysten prüfen Werte manuell, und Governance fordert nach einem Vorfall Nachweise an. Jede Aktivität kann sinnvoll sein, doch die Organisation tut sich schwer, Ergebnisse zu vergleichen oder Verantwortung zuzuweisen.

Ein gemeinsames Modell hilft Teams, verschiedene Fehlertypen zu trennen. Genauigkeitsfehler deuten auf falsche Werte hin. Konsistenzfehler zeigen Widersprüche an. Aktualitätsfehler betreffen veraltete Informationen, während Verfügbarkeitsfehler betreffen, ob autorisierte Konsumenten bei Bedarf auf Daten zugreifen können.

Praxisregel: Fragen Sie nie, ob Daten „von hoher Qualität“ sind, ohne Anwendungsfall, Merkmal und erwarteten Nachweis zu benennen.

Vom Vokabular zum operativen Nachweis

ISO/IEC 25012 ist deshalb relevant, weil es als Brücke zwischen fachlichen Erwartungen und technischer Observability dienen kann. Ein Governance-Verantwortlicher kann definieren, was „aktuell“ für einen Berichtsdatensatz bedeutet. Ein Engineer kann Liefermonitoring implementieren. Ein Analyst kann eine Scorecard prüfen, und ein Auditor kann die erfassten Ausnahmen und die Behebungshistorie einsehen.

Dieser Ablauf ist wertvoller als eine statische Checkliste. Das Modell liefert die Kategorien. Das Unternehmen entscheidet, welche Merkmale am wichtigsten sind, definiert Schwellenwerte, wählt Kontrollen und hält die Ergebnisse fest. In-Database-Monitoring kann diesen Prozess unterstützen, indem es Daten dort auswertet, wo sie bereits liegen, während Validierung und Anomalieerkennung Verstöße gegen Geschäftsregeln von unerwartetem Plattformverhalten unterscheiden.

Was ISO 25012 ist und warum es existiert

ISO/IEC 25012 ist ein allgemeines Datenqualitätsmodell für strukturierte Daten in Computersystemen. Es wurde im Dezember 2008 als Teil der ISO/IEC-SQuaRE-Familie veröffentlicht, und der ISO-Katalogeintrag zu ISO/IEC 25012 weist es als 13-seitige Internationale Norm aus.

Die Norm existiert, um drei zusammenhängende Aktivitäten zu unterstützen: Datenqualitätsanforderungen definieren, Datenqualität messen und bewerten, ob Daten für ihren vorgesehenen Zweck geeignet sind. Sie konzentriert sich auf strukturierte Daten, was sie für Datenbanken, Informationssysteme, Analyseumgebungen und Berichtsprozesse relevant macht.

Betrachten Sie es als Bauordnung

Eine Bauordnung schreibt nicht jedem Architekten vor, wie genau ein Krankenhaus, ein Lager oder ein Wohnhaus zu entwerfen ist. Sie benennt Sicherheitsfragen und Randbedingungen, die ein Entwurf adressieren muss. Das Projektteam entscheidet weiterhin, wie diese Anforderungen auf Zweck, Standort, Materialien und Risikoprofil des Gebäudes anzuwenden sind.

ISO/IEC 25012 funktioniert ähnlich. Es gibt Organisationen ein strukturiertes Vokabular von Datenqualitätsmerkmalen statt eines universellen Scores, den jeder Datensatz erreichen müsste. Eine Kundenadresse, ein klinischer Messwert und eine regulatorische Transaktion können unterschiedliche Prioritäten erfordern, selbst wenn sie in ähnlichen Datenbankstrukturen liegen.

Deshalb sollte das Modell nicht als schlüsselfertiger Umsetzungsleitfaden behandelt werden. Es liefert keinen einheitlichen Satz an Schwellenwerten, Gewichtungen, Überwachungsplänen oder Verantwortlichkeiten für jedes Unternehmen. Diese Entscheidungen liegen beim Bewertenden und beim fachlichen Kontext.

Wobei das Modell Teams hilft

Eine praktikable Einführungsreihenfolge sieht so aus:

1. Anforderung definieren. Legen Sie fest, was Qualität für einen Datensatz und seinen vorgesehenen Zweck bedeutet.

2. Relevante Merkmale auswählen. Wählen Sie Dimensionen, die fachliches, regulatorisches, analytisches und operatives Risiko abbilden.

3. Nachweise festlegen. Entscheiden Sie, welche Messungen, Validierungsergebnisse, Lineage-Aufzeichnungen oder Systembeobachtungen die Konformität belegen.

4. Zwecktauglichkeit bewerten. Bestimmen Sie, ob der Datensatz den Prozess, den Bericht, das Modell oder die Entscheidung tragen kann.

Organisationen können das Modell als Grundlage für Datenqualitätsstandards und Governance-Praktiken nutzen, doch die Umsetzung erfordert weiterhin lokale Entscheidungen. Diese Unterscheidung verhindert einen häufigen Fehler: anzunehmen, ein Merkmal zu benennen sei dasselbe wie es zu kontrollieren.

Die 15 Datenqualitätsmerkmale einfach erklärt

ISO/IEC 25012 definiert 15 Datenqualitätsmerkmale. Eine neutrale Zusammenfassung nennt sie als Genauigkeit, Vollständigkeit, Konsistenz, Glaubwürdigkeit, Aktualität, Zugänglichkeit, Konformität, Vertraulichkeit, Effizienz, Präzision, Nachvollziehbarkeit, Verständlichkeit, Verfügbarkeit, Portabilität und Wiederherstellbarkeit. Dieselbe Liste findet sich im NPL-Good-Practice-Material zu Datenqualitätsmerkmalen.

Das Modell gruppiert die Merkmale um zwei Perspektiven. Inhärente Qualität betrifft die Daten selbst. Systemabhängige Qualität betrifft, wie das umgebende System Menschen und Anwendungen ermöglicht, diese Daten abzurufen, zu schützen, zu verarbeiten, zu bewegen und wiederherzustellen. Manche Merkmale können von beidem abhängen.

Inhärente Qualität

• Genauigkeit bedeutet, dass der Wert das reale Objekt, Ereignis oder den Zustand korrekt abbildet. Eine erfasste Kundenadresse sollte der tatsächlichen Adresse des Kunden entsprechen.

• Vollständigkeit bedeutet, dass die erwarteten Informationen für den vorgesehenen Zweck vorliegen. Ein Lieferantensatz ohne erforderliche Kennung kann unbrauchbar sein, selbst wenn jedes befüllte Feld gültig ist.

• Konsistenz bedeutet, dass die Daten sich nicht selbst widersprechen und nicht systemübergreifend kollidieren. Ein Kunde sollte in verbundenen Anwendungen ohne definierten Grund keine unvereinbaren Lebenszyklusstatus haben.

• Glaubwürdigkeit betrifft, ob Nutzer die Daten unter Berücksichtigung von Quelle und Erhebungsprozess vernünftigerweise als plausibel und verlässlich einstufen können.

• Aktualität bedeutet, dass die Daten den geforderten Zeithorizont abbilden. Ein Wert kann historisch genau, aber für einen Prozess, der den neuesten Stand benötigt, ungeeignet sein.

• Präzision beschreibt, ob die Daten den angemessenen Detailgrad aufweisen. Ein gerundeter Wert mag für eine Zusammenfassung taugen, aber für eine Berechnung mit feinerer Granularität versagen.

Systemabhängige Qualität

• Zugänglichkeit bedeutet, dass autorisierte Nutzer und Anwendungen die Daten abrufen und nutzen können.

• Konformität bedeutet, dass die Daten und ihre Handhabung geltenden Regeln, Standards, Verträgen und Richtlinien folgen.

• Vertraulichkeit schützt Daten vor unbefugtem Zugriff oder unbefugter Offenlegung.

• Effizienz betrifft die Ressourcen und das Verarbeitungsverhalten, die für eine wirksame Nutzung der Daten erforderlich sind.

• Nachvollziehbarkeit erlaubt Teams, Datenherkunft, Transformationen, Änderungen und verantwortliche Akteure zu verfolgen.

• Verständlichkeit macht Felder, Codes, Bezeichnungen und Bedeutungen für die vorgesehenen Nutzer klar.

• Verfügbarkeit bedeutet, dass die Daten und der zugehörige Dienst bei Bedarf nutzbar sind.

• Portabilität ermöglicht die Bewegung zwischen Systemen, ohne Bedeutung oder Qualität zu verlieren.

• Wiederherstellbarkeit betrifft die Wiederherstellung nach Verlust, Beschädigung, Ausfall oder Störung.

Eine nützliche Unterscheidung ist, dass Genauigkeit und Aktualität nicht austauschbar sind. Ein mit Zeitstempel versehener Wert kann bei der Erfassung genau gewesen, für die heutige Entscheidung aber veraltet sein. Ebenso sind Zugänglichkeit und Verfügbarkeit nicht identisch. Ein System kann laufen, während einem Nutzer der autorisierte Zugriff fehlt, oder eine Tabelle kann grundsätzlich zugänglich sein, während der Dienst während eines kritischen Workflows nicht verfügbar ist.

Für eine breitere Diskussion, wie diese Dimensionen zusammenwirken, siehe die Dimensionen der Datenqualität.

ISO 25012 für Unternehmensdatenprogramme auslegen

Ein Modell wird nützlich, wenn eine Organisation seine Merkmale in Entscheidungen übersetzt. Derselbe Datensatz kann für ein Audit starke Nachvollziehbarkeit, für die operative Disposition hohe Aktualität und für sensible Datensätze strikte Vertraulichkeit benötigen. Jedes Merkmal als gleich wichtig zu behandeln erzeugt Rauschen und lässt Teams Aufwand dort investieren, wo das Geschäftsrisiko geringer sein kann.

ISO/IEC 25012 überlässt Gewichtung, Schwellenwerte und kontextspezifische Priorisierung dem Bewertenden. Diese Flexibilität ist notwendig, erzeugt aber auch Umsetzungsarbeit. Ein Datenprogramm muss definieren, was jedes Merkmal für einen bestimmten Datensatz bedeutet, und die Definition dann mit einem messbaren Indikator und einem Owner verbinden.

Von Merkmalen zu Anforderungen

Beginnen Sie beim Anwendungsfall, nicht beim Monitoring-Werkzeug. Für einen aufsichtsrechtlichen Bericht könnte eine Anforderung Konformität, Nachvollziehbarkeit, Vollständigkeit und Konsistenz verbinden. Für eine nahezu echtzeitnahe operative Tabelle verdienen Aktualität, Verfügbarkeit und Wiederherstellbarkeit womöglich mehr Aufmerksamkeit.

Ein Datensatz kann insgesamt akzeptabel wirken und zugleich in einer geschäftskritischen Dimension versagen. Ein Durchschnittswert kann semantische Inkonsistenz, unvollständige Attribute oder Daten verbergen, die für den Prozess zu alt geworden sind. Eine Forschungsarbeit zur Anwendung von ISO/IEC 25012 hebt diese praktische Herausforderung hervor und die Notwendigkeit, konkrete Merkmale zu bewerten, statt sich nur auf einen Gesamteindruck zu verlassen.

Eine Scorecard braucht Kontext

Eine nützliche Scorecard sollte mehr zeigen als eine einzelne Note. Nehmen Sie Merkmal, Metrik, beobachtetes Ergebnis, Schwellenwert, fachlichen Owner, technischen Owner, Bewertungszeitraum und Ausnahmestatus auf. Halten Sie die zugrunde liegenden Nachweise verfügbar, damit ein Prüfer von der Zusammenfassung zu den fehlgeschlagenen Datensätzen, der Regelausführung, dem Lieferereignis oder der Schemaänderung gelangen kann.

ISO/IEC 25024:2015 liefert einen ergänzenden Ansatz für quantitative Messgrößen zu den in ISO/IEC 25012 definierten Merkmalen. Der ISO-Katalogeintrag zu ISO/IEC 25024 beschreibt seine Rolle bei der Definition von Maßen für Datenqualität. Er hilft Teams, von „Vollständigkeit überwachen“ zu einer definierten Messmethode zu kommen, während die Organisation weiterhin entscheidet, welches Ergebnis für ihren Anwendungsfall akzeptabel ist.

Eine Scorecard ist nur dann glaubwürdig, wenn ein Prüfer ihren Status auf reproduzierbare Nachweise zurückführen kann.

Ein Unternehmensrahmen sollte daher Priorisierung mit Verantwortlichkeit verbinden. Leitlinien für ein Enterprise-Datenqualitäts-Framework können helfen, dieses Betriebsmodell zu strukturieren, doch die Umsetzung muss weiterhin Risiken, Architektur, Verträge und Serviceerwartungen der Organisation widerspiegeln.

ISO 25012 auf Observability- und Validierungskontrollen abbilden

Die Operationalisierung beginnt damit, jedes Merkmal in eine beobachtbare Frage zu übersetzen. Kann dem Wert vertraut werden? Ist die erwartete Ladung eingetroffen? Hat sich das Schema geändert? Kann das System die Daten wiederherstellen? Jede Frage verweist auf eine andere Kontrollfamilie, und kein einzelner Test deckt jede Dimension ab.

Nutzen Sie In-Database-Ausführung, wo die Kontrolle innerhalb der Datenbank des Kunden berechnet werden kann. Dieser Ansatz hält die Auswertung nah an den Daten und unterstützt Private-Cloud-, VPC-, On-Premises- und andere kontrollierte Bereitstellungsmuster. Das Kontrollergebnis sollte Datensatz, Bewertungszeitpunkt, verwendete Regel oder Detektor, Status, Owner und Verweise auf den zugehörigen Vorfall oder Behebungsdatensatz enthalten.

Eine praktische Kontrollmatrix

Diese Matrix ist ein Ausgangspunkt, kein Ersatz für ein Kontrolldesign. Eine Aktualitätsprüfung kann bei einer Tabelle die Ankunftszeit und bei einer anderen fachliche Gültigkeitsdaten betrachten. Eine Konsistenzprüfung kann zwei Systeme vergleichen oder Beziehungen innerhalb eines Datensatzes validieren.

Datenfehler von Plattformfehlern trennen

Ein nützlicher Vorfallsprozess klassifiziert den Fehler, bevor Schuld zugewiesen wird. Ein Wert außerhalb eines fachlich freigegebenen Bereichs ist etwas anderes als ein Query-Timeout. Ein fehlendes Feld, verursacht durch eine vorgelagerte Anwendung, ist etwas anderes als eine Tabelle, die durch einen Plattformausfall unzugänglich wurde.

digna bietet Module für Data Anomalies, Data Analytics, Timeliness, Data Validation und Schema Tracker, wobei Metrikberechnung und Analyse in-database erfolgen. Teams können diese Capability-Muster neben ihren bestehenden Warehouse-Tests, Orchestrierungs-Alerts, Katalogen, Zugriffskontrollen, Backup-Verfahren und Incident-Management-Systemen einsetzen. Der Überblick zur Data-Observability-Plattform liefert den passenden Produktkontext.

Die stärkste Umsetzung protokolliert sowohl die Erkennung als auch die Reaktion. Eine fehlgeschlagene Validierung sollte zeigen, welche Regel versagt hat, während ein Timeliness-Alert das erwartete Liefermuster und das beobachtete Ereignis zeigen sollte. Dieser Nachweis macht aus Monitoring statt einer Warnleuchte eine wiederholbare Governance-Kontrolle.

Branchenbeispiele, in denen ISO 25012 teure Fehler verhindert

Der Wert von ISO 25012 wird deutlicher, wenn dasselbe Modell auf unterschiedliche Betriebsumgebungen angewendet wird. Jede Branche betont andere Risiken, obwohl die zugrunde liegenden Merkmale wiedererkennbar bleiben.

Finanzdienstleistungen

Ein Team für aufsichtsrechtliche Berichterstattung stimmt Transaktionen aus mehreren Systemen ab. Die Summen wirken plausibel, doch eine Transformation hat verändert, wie eine Produktkategorie dargestellt wird. Das unmittelbare Thema ist Konformität, doch die Behebung erfordert auch Nachvollziehbarkeit, Konsistenz und klare Validierungsnachweise.

Das Team kann die Lineage von der Quelle bis zum Bericht bewahren, freigegebene Codewerte validieren, verwandte Kennzahlen vergleichen und Ausnahmen an benannte Owner leiten. Das Modell hilft dem Team, den Fehler präzise zu beschreiben, statt den gesamten Bericht als „schlecht“ abzustempeln.

Gesundheitswesen

Eine klinische Analysegruppe erhält Patientendaten aus mehreren Erhebungsprozessen. Ein Feed enthält gültige Datensätze, lässt aber für eine Teilmenge der Behandlungsfälle ein wichtiges Feld aus. Ein anderer Feed verwendet eine inhaltlich abweichende Codeauslegung.

Hier zählen Vollständigkeit, Glaubwürdigkeit, Genauigkeit und Verständlichkeit gleichermaßen. Validierung auf Satzebene kann fehlende oder ungültige Werte identifizieren, während dokumentierte Definitionen und Quellhistorie Prüfern helfen festzustellen, ob eine Abweichung ein Erfassungs-, Mapping- oder Auslegungsproblem ist.

Telekommunikation

Ein Netzbetriebsteam hängt von Ereignisdaten in hohem Volumen ab. Eine Pipeline-Verzögerung lässt das Dashboard zugänglich, doch die Ansicht bildet den Betriebszustand, den Engineers brauchen, nicht mehr ab. Eine separate Schemaänderung führt dazu, dass nachgelagerte Logik ein neu eingeführtes Feld ignoriert.

Aktualität, Verfügbarkeit, Portabilität und Wiederherstellbarkeit ermöglichen dem Team eine vollständigere Diagnose. Timeliness-Monitoring kann Lieferverhalten melden, Schema-Tracking kann strukturelle Änderungen offenlegen, und Wiederherstellungsverfahren können die Folgen einer fehlgeschlagenen oder unvollständigen Ladung adressieren.

Öffentlicher Sektor

Ein staatliches Berichtsprogramm führt Informationen aus Ressorts mit unterschiedlichen Datenkonventionen zusammen. Datensätze mögen in jeder Quelle vorhanden sein, doch Kennungen und Statuswerte passen nicht zusammen. Während eines Audits muss die Organisation nicht nur das veröffentlichte Ergebnis erklären, sondern auch, wie es entstanden ist.

Konsistenz, Nachvollziehbarkeit, Konformität und Verständlichkeit rücken in den Mittelpunkt. Ein gemeinsames Modell gibt Richtlinienverantwortlichen, Engineers, Analysten und Auditoren eine gemeinsame Sprache, um das Kontrollziel zu beschreiben und die Nachweise zu prüfen.

Umsetzungs-Checkliste und Grundlagen der Auditberichterstattung

Die Umsetzung gelingt am besten, wenn Teams ISO/IEC 25012 als lebendes Kontrollmodell behandeln statt als Dokument zum Abheften. Beginnen Sie mit den Datensätzen, die wesentliche Entscheidungen, regulierte Berichterstattung, Kundenprozesse, klinische Arbeit oder operative Automatisierung tragen.

Nutzen Sie diese Checkliste:

• Kritische Daten abgrenzen: Identifizieren Sie Datensatz, Geschäftsprozess, Konsumenten, Quellsysteme und verantwortlichen Owner.

• Merkmale auswählen: Wählen Sie die Dimensionen, die zum Anwendungsfall passen, statt jede Kontrolle unterschiedslos anzuwenden.

• Messungen definieren: Nutzen Sie ISO/IEC 25024 als Referenz für quantitative Maße und dokumentieren Sie dann die lokale Metrikdefinition.

• Entscheidungsregeln festlegen: Halten Sie Schwellenwerte, Bewertungsfenster, Schweregrad, Eskalation und Ausnahmebehandlung fest.

• Verantwortung zuweisen: Trennen Sie die Verantwortung für Geschäftsregeln von der Engineering-Verantwortung für Plattform- und Pipeline-Verhalten.

• In der richtigen Umgebung überwachen: Erwägen Sie In-Database-Ausführung innerhalb der VPC, Private Cloud, On-Premises-Umgebung oder des Rechenzentrums der Organisation.

• Nachweise bewahren: Behalten Sie Regelergebnisse, Anomaliekontext, Lieferhistorie, Schemaänderungen, Lineage, Zeitstempel und Behebungsentscheidungen.

• Adressatengerecht berichten: Geben Sie Engineers Vorfalldetails, Analysten Trendkontext und Governance-Verantwortlichen eine kompakte Kontrollsicht.

Ein auditfähiger Datenqualitätsansatz sollte jeden gemeldeten Status erklärbar machen. Prüfer müssen wissen, was geprüft wurde, gegen welche Anforderung, wann es lief, was fehlschlug, wer reagierte und ob das Problem nachgelagerte Entscheidungen beeinflusst hat.

digna bietet eine Enterprise-Plattform für Datenqualität und Observability, die Datenverhalten überwacht, Datensätze validiert, Timeliness verfolgt, Schemaänderungen erkennt und fachliches wie plattformseitiges Monitoring in der Umgebung des Kunden unterstützt. Besuchen Sie digna, um zu sehen, wie die In-Database-Monitoring-Muster helfen, ISO-25012-Merkmale in messbare Kontrollen und Auditnachweise zu überführen.

So verwandelt digna diese Merkmale in laufende Kontrollen: Datenqualitäts-Monitoring über Ihre Plattformen hinweg.

Häufig gestellte Fragen

Was ist ISO 25012?

ISO/IEC 25012 ist eine internationale Norm, die ein Datenqualitätsmodell für strukturiert gespeicherte Informationen definiert. Sie gibt Teams ein gemeinsames Vokabular aus 15 Merkmalen, damit „Datenqualität“ nicht länger für den einen Genauigkeit und für die andere Aktualität bedeutet.

Was sind die 15 Datenqualitätsmerkmale der ISO 25012?

Sie umfassen Genauigkeit, Vollständigkeit, Konsistenz, Glaubwürdigkeit und Aktualität sowie Zugänglichkeit, Konformität, Vertraulichkeit, Effizienz, Präzision, Nachvollziehbarkeit, Verständlichkeit, Verfügbarkeit, Portabilität und Wiederherstellbarkeit. Zusammen beschreiben sie sowohl die Daten selbst als auch das System, das sie bereitstellt.

Was unterscheidet inhärente von systemabhängiger Qualität?

Inhärente Merkmale gehören zu den Daten, unabhängig davon, wo sie liegen, etwa Genauigkeit und Vollständigkeit. Systemabhängige Merkmale hängen von der bereitstellenden Plattform ab, etwa Verfügbarkeit und Wiederherstellbarkeit. Die Trennung zeigt, ob ein Datenfehler oder ein Plattformfehler vorliegt.

Wie bildet man ISO 25012 auf echte Kontrollen ab?

Übersetzen Sie jedes relevante Merkmal in eine messbare Anforderung und binden Sie es an eine laufende Kontrolle: Aktualität wird zu einem Timeliness-Schwellenwert, Vollständigkeit zu Null-Raten-Monitoring, Konsistenz zu systemübergreifender Abstimmung. Ein Merkmal ohne Kontrolle dahinter ist Vokabular, keine Sicherheit.

Gibt es eine Zertifizierung nach ISO 25012?

Es handelt sich um ein Referenzmodell und nicht um eine zertifizierbare Norm, ein Auditsiegel gibt es also nicht. Ihr Wert im Audit liegt woanders: Sie liefert belastbare Sprache und eine Struktur, um zu zeigen, welche Merkmale Sie messen, wie, und mit welchen Nachweisen.