Feuersbrünste und DQM

February 24, 2010 by · 2 Comments
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Wenn man sich mit dem Mittelalter beschäftigt, stößt man immer wieder auf riesige Brände, die ganze Städte vernichten. Ein Beispiel ist der “Große Brand von London”, eine Feuersbrunst, die vom 2. bis 5. September 1666 vier Fünftel der City of London, darunter die meisten mittelalterlichen Bauten, zerstörte und etwa 100.000 Einwohner obdachlos machte.


Quelle: Wikipedia, Great Fire London

Heute gibt es zahlreiche Vorschriften zum Brandschutz, so dass Feuer viel seltener als früher auftreten. Und im Fall eines Falles hat jede Stadt und jedes Dorf eine Berufs- oder freiwillige Feuerwehr, die im Notfall schnell eingreifen und weitreichende Schäden verhindern kann.

Diese Erkenntnis lässt sich auch auf das Datenqualitätsmanagement übertragen.

DQM Mittelalter

Immer wieder treten Probleme auf, die aus einer schlechten Datenqualität resultieren. Meist kommen diese Probleme bei wichtigen Projekten ans Tageslicht (z.B. bei Migrationen oder Prozessoptimierungen), bei Personalveränderungen oder bei Themen mit einer hohen Sichtbarkeit bei der Unternehmensführung. Um die Projektziele zu erreichen, muss sich dann um die DQ-Probleme gekümmert werden. Nachdem die unmittelbaren, drängenden Probleme gelöst und die naheliegenden Ziele erreicht sind, wird dann keine Notwendigkeit gesehen, ein regelmäßiges DQM einzuführen. Bis dann der nächste DQ-Notfalleinsatz ansteht …

Bei diesem “Ad-Hoc DQM” gibt es viele Probleme, einige Beispiele:

  • Bearbeitung von DQ-Themen durch verschiedene Abteilungen im Unternehmen
  • Kein einheitliches Vorgehen, keine einheitlichen Werkzeuge
  • Investitionen in DQ-Werkzeuge rechnen sich meist nicht für eine einzelne Maßnahme oder sind zu zeitaufwändig, können aber bei mehrfachem Einsatz sehr nützlich sein
  • Keine Planbarkeit von Budgets und Ressourcen, deswegen oft externe Unterstützung erforderlich
  • Nur die wichtigsten Symptome werden beseitigt, ohne die Ursachen auszuräumen
  • Keine präventiven Maßnahmen
  • Bei jedem Probleme wird “wieder von vorne angefangen”, dadurch hohe wiederkehrende Kosten

Modernes DQM

Es macht daher sehr viel Sinn, eine Einheit zu etablieren, die als primäre Aufgabe ein regelmäßiges, aktives Datenqualitätsmanagement durchführt. Zu den Aufgaben dieser Einheit ist die Festlegung von einheitliches Prozessen und die Etablierung einer technischen Plattform, um auf dieser Basis eine kontinuierliche Überwachung und Verbesserung der Datenqualität zu erreichen. Die zahlreichen dabei auftretenden Aspekte werden in folgenden Posts weiter diskutiert werden.

Preventing the “Great DQM Fire”

February 24, 2010 by · 3 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

When dealing with the Middle Ages, there are a lot massive fires that destroy entire cities. An example is the "Great Fire of London" (see Wikipedia article). It lasted four full days in September 1666 and destroyed four fifths of the City of London, including most of the medieval buildings, and resulted in about 100,000 homeless people.


Source: Wikipedia, Great Fire London
Today, there are numerous provisions for fire protection, so that fires occur much less frequently than before. And in the case of a fire, every town and every village has a professional or volunteer fire department that can respond quickly and prevent extensive damage.

This concept can also be applied to the data quality management.

Data Quality Middle Ages

Again and again, problems result from bad data quality. Typically, these issues occur in major projects (eg, data migration or process optimization), changes in personnel or when there is a high visibility to upper management. To achieve its objectives, the project must then take care of the problems in an ad-hoc fashion. After the immediate, pressing problems solved and the projects objectives are achieved, there is no need to introduce a regular DQM. Until the next DQ emergency occurs …

This "ad-hoc DQM" has many negatives, some examples:

  • No single approach, no standard tools
  • Only the main symptoms are eliminated, without resolving the root causes
  • No preventive measures
  • Investment in DQ tools cannot be justified for a single project (either too expensive or too time consuming)
  • DQ issues are handled by various people and departments
  • No predictability of budgets and resources, therefore external support is often needed
  • When new problems occur, everything has to start again from scratch, resulting in high recurrent costs

Modern Era Data Quality

It therefore makes a lot of sense to establish a unit with the main task of regular, active data quality management. The objectives of this unit are to establish a general process, organization and technical platform to continuously monitor and improve of data quality. The relevant aspects will be discussed in further posts.

Data Quality and Migration Projects – Friend or Foe?

February 15, 2010 by · Leave a Comment
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

The relationship between a data quality team and a migration project (such as from an in-house, host-based system to a standard ERP system such as SAP R/3) can be tricky. Often times, the project sees data quality as one more foe on their way to project success and tries to block access to the project. This blog post explores some ideas so that the two sides can become friends and the relationship can become mutually beneficial.

If migrations are often pursued ambitious targets for improving data quality. The project life is usually not much for them and after the migration has been then not only scrap grapple with the old data, but by migration have been added new problems. But it need not be: With an explicit monitoring of migration by DQM to data quality can actually be improved – to relieve the migration project and for the benefit of the company.

Deterioration of Data Quality in Migrations

When a new migration project is started, there are usually ambitious goals for improving data quality:

  • We can (finally!) get rid of all the junk in the old system.
  • Only good data can enter the new system.
  • Automatic checks in the new system will stop the data quality from deteriorating.

Unfortunately, reality is often different. In order to make a deadline constraints are relaxed and the new data is squeezed into the new system. This can lead to the “worst of both worlds”: The old junk data is still around, migration has created new issues and there is no one around who knows how to use the new system. In that case, the focus has to shift on “running the new system”, instead of being able to fix the issues that were inherited.

The following sections present ideas how this deterioration can be prevented by cooperation between the migration project and DQM.

DQM before migration

Even before the the actual migration DQM can play an important role in supporting the migration project:

  • Collect DQ problems
    There are a lot of DQ problems that are already known before the migration project or that are uncovered during the trial runs of the migration. The DQM team can help in tracking these issues.
  • Prioritization of the DQ problems
    In a second step, the accumulated problems prioritized in order to distinguish between important issues that must be handled before migration and those that are somewhat less urgent.
  • Resolve important DQ problems
    With increasing pressure to keep the deadline the project will focus on resolving the issues that are preventing the migration. This can be achieved using the standard DQ process and tools.
  • Tracking of DQ problems
    Identified DQ problems can be measured and tracked with the help of a DQ cockpit. A new cockpit can be implemented or an existing cockpit can be extended for the use of the migration project. The cockpits helps to track the progress towards acceptable error levels and makes sure that resolved issues do not flare up again.
  • Develop preventive measures in the new system
    When developing or customizing the new system, DQM can help to design preventive measures to help improve data quality in the new system. For example, if one of the problem areas in the old system has incorrect ZIP codes, a function for address validation can be integrated.

At the beginning of cooperation, there are often reservations in the project, which sees in DQM, a new "source of trouble." But as soon as the project realizes that DQM helps them solve problems, DQM can quickly take a supporting role to the benefit of both sides.

DQM during migration

There are always problems during the actual migration of data from the old system to the new system. Maybe there are some known problems that were not deemed as preventing migration. But as it is not possible to completely simulate the migration in tests, some new, unexpected problems occur. Only in very rare cases the migration is postponed, and the problems have to be fixed in the new system after the migration is complete. Again, DQM can help in collecting, prioritizing and tracking of issues.

Another supporting function DQM can take during the migration is by helping with DQ tools such as a dedicated analysis environment. For example, this environment could be used to compare the data before and after migration, making sure all records have been migrated or identifying records that have to be manually edited after the migration.

DQM after migration

After the migration event is over, the migration project usually ends pretty quickly, and a lot of resources are suddenly no longer available. Therefore, it is critical that the work of the DQ team is not over after the migration as there is a number of important tasks left:

  • Resolving open DQ problems
    Both the problems deferred to after the migration and the new problems that occurred during the migration have to be prioritized and resolved. Again, this can be done using the standard DQ process and tools.
  • Ongoing tracking of all DQ problems
    The DQ cockpit that has been filled before the migration has to be adapted to the new system and expanded as necessary. This enables an ongoing tracking of all DQ problems. Often this also results in preventive measures in the new system.

Again, the project is often grateful to have a pre-defined recipient for issues that could not be resolved by the project. (Of course this does not mean that all problems should be declared to be DQ issues.)

In many cases, an ongoing DQ practice can be built and established during a migration project.

DQM und Migrationen

February 15, 2010 by · 1 Comment
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Bei Migrationen werden oft ehrgeizige Ziele zur Verbesserung der Datenqualität verfolgt. Im Projektalltag bleibt davon meist nicht viel nach und nach der Migration hat man sich dann nicht nur mit dem alten Datenschrott herumzuschlagen, sondern in durch die Migration sind noch neue Probleme hinzugekommen. Das muss aber nicht sein: Mit einer expliziten Begleitung der Migration durch DQM kann die Datenqualität tatsächlich verbessert werden – zur Entlastung des Migrations-Projekts und zum Nutzen des Unternehmens.

Verschlimmerung der DQ-Probleme bei Migrationen

Ein typischer Anknüpfungspunkt für Maßnahmen zur Verbesserung der Datenqualität sind Migrationen von einem alten System zu einem neuen, etwa von einem selbst-entwickeltem, Host-basiertem System zu einer Standardsoftware wie SAP R/3. Beim Start eines solchen Projekts gibt es meist ehrgeizige Ziele:

  • Man will (endlich!) den alten Datenschrott loswerden,
  • in das neue System kommen nur saubere Daten,
  • auf der neuen, guten Grundlage wird das Entstehen neuen Datenschrotts durch umfangreiche Maßnahmen verhindert.

Die Realität sieht dann leider meist anders aus: Unter dem zunehmenden Druck, einen Migrations-Termin zu halten, bleibt am Ende nur noch “Augen zu” und die Daten werden “so gut es halt geht” in das neue System “reingedrückt”. Wenn man Pech hat, produziert man damit “das Schlechteste aus beiden Welten”: Der alte Datenschrott wurde doch übernommen, durch die Migration sind neue Probleme entstanden und im neuen System ist man erst mal damit beschäftigt, den Betrieb am laufen zu halten, anstatt sich über Qualitäts-Maßnahmen Gedanken zu machen.

In den folgenden Abschnitten werden Ideen vorgestellt, wie diese Verschlimmerung verhindert werden kann und durch eine Zusammenarbeit von Migrations-Projekt und DQM tatsächlich sogar eine Verbesserung der Datenqualität erreicht werden kann – zum Vorteil beider Parteien.

DQM vor Migration

Bereits vor der tatsächlichen Migration kann DQM wichtige Aufgaben zur Unterstützung des Migrations-Projekts und zur Vorbereitung der Zeit nach der Migration:

  • DQ-Problemaufnahme
    Bereits bekannte oder im Laufe der Migration aufkommende oder festgestellte Datenqualitäts-Probleme (z.B. Datensätze, die nicht oder nur unvollständig migriert werden können; Warnungen beim Import in das neue System) werden aufgenommen.
  • Priorisierung der DQ-Probleme
    In einem zweiten Schritt werden die gesammelten Probleme priorisiert, um zwischen wichtigen Problemen zu unterscheiden, die vor der Migration bearbeitet werden müssen und solchen, die etwas weniger dringlich sind.
  • Bearbeitung der wichtigsten DQ-Probleme
    Mit zunehmenden Projektdruck wird man sich in der Bearbeitung auf die Probleme konzentrieren, die Migrations-verhindernd sind und diese im Rahmen dezidierter DQ-Maßnahmen nach dem Standard-DQ-Vorgehen (DQM Kreislauf) bearbeiten.
  • Verfolgung der DQ-Probleme
    Mit Hilfe eines DQM Cockpits, das im Migrations-Projekt implementiert oder durch neue Messgrößen erweitert wird, kann die Entwicklung der DQ-Probleme verfolgt werden. Somit kann sichergestellt werden, dass die Bearbeitung der Probleme Fortschritte macht, bereits bearbeitete Probleme nicht erneut aufflammen und die Anzahl der Problemfälle insgesamt in ein für die Migration akzeptables Maß gebracht werden kann.
  • Erarbeitung von Maßnahmen im neuen System zur Prävention neuer DQ-Probleme
    Beim Entwurf des neuen Systems können DQ-Aspekte durch DQM mit eingebracht werden oder präventive Maßnahmen umgesetzt werden. Wenn es im alten System z.B. regelmäßig Probleme mit falschen Postleitzahlen gegeben hat, kann eine Funktion zur postalischen Prüfung integriert werden.

Am Anfang der Zusammenarbeit gibt es oft Vorbehalte durch das Projekt, das in DQM eine weitere “Problemquelle” sieht. Sobald es aber DQM gelingt, das Projekt bei der Abarbeitung von Probleme zu entlasten, kann DQM schnell eine das Projekt unterstützende Funktion wahr nehmen, aus der beide Seiten Nutzen ziehen.

DQM während Migration

Bei einer Migration treten immer Probleme auf. Dabei kann es sich um Probleme handeln, die im Vorwege schon bekannt waren, aber nicht als Migrations-verhindernd eingestuft worden. Nicht immer lässt sich das Migrations-Szenario im Vorwege zu 100% durchspielen, so dass auch neue, unerwartete Probleme auftreten. Nur in ganz extremen Fällen führen diese Probleme zum Abbruch der Migration, im Normalfall müssen sie im Nachgang beseitigt werden. Auch hier kann DQM bei der Problemaufnahme, -Priorisierung und -Verfolgung unterstützen.

Eine weitere Möglichkeit zur Unterstützung des Projekts durch DQM kann darin bestehen, DQM-Werkzeuge (wie eine dezidierte Analyse-Umgebung) zum Abgleich der Daten vor und nach der Migration zu nutzen und so bei der Abnahme der Migration beizutragen.

DQM nach Migration

Das Migrations-Projekt endet meist recht schnell nach der Migration, und viele Ressourcen stehen kurzfristig nicht mehr zur Verfügung. Es ist daher sehr wichtig, dass die Arbeit von DQM nach der Migration nicht beendet ist:

  • Bearbeitung noch offener DQ-Probleme
    Sowohl die vor der Migration schon bekannten, aber zurückgestellten Probleme als auch die neuen, in der Migration entstandenen Probleme sind zu bearbeiten. Auch hier kann wieder auf das Standard-DQ-Vorgehen zurück gegriffen werden.
  • Laufende Verfolgung aller DQ-Probleme
    Das bestehende DQM Cockpit ist – soweit sinnvoll -  auf das neue System anzupassen und entsprechend der neuen Probleme zu erweitern. Damit ist es möglich, eine laufende Verfolgung des Bearbeitungsfortschritts aller Probleme und DQ-Messgrößen zu verfolgen. Oft resultieren daraus auch präventive Maßnahmen im neuen System.

Auch hier ist das Projekt meist dankbar dafür, für bestimmte Problemfälle einen definierten Empfänger zu haben. (Dies darf natürlich nicht dazu führen, dass alle Probleme zu DQ-Problemen erklärt werden und DQM Aufgaben erhält, die nicht geleistet werden können.)

In vielen Fällen ist die Nachverfolgung der Themen aus der Migration und die Bearbeitung neuer Probleme der Einstieg in ein dauerhaftes, nachhaltiges Datenqualitäts-Management.

Specifying DQ Measurands: An Example

February 10, 2010 by · 1 Comment
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Artikels.

In the last blog post, the elements of a DQ Measurand specification were discussed. These elements will be illustrated with an example. 

1. Name

The following DQ Measurand will be detailed:

  • Measurand 1: Partners without a postal address

Some other, simple DQ Measurands could be the following:

  • Measurand 2: Potential partner duplicates
  • Measurand 3: Active home finance loans, where there is no property value for the real estate object used as collateral

2. DQ Rule

Business partners (records in the table BUT000) should be connected to an address (table ADRC) using the table BUT021_FS (using address kind BUT021_FS-ADRVERW = "Postal"). This measurand consists of partners without a link in the BUT021_FS or without a valid record in BUT021_FS (current date and between DATE_FROM and DATE_TO). This rule is only valid for partners that have taken out a loan. (For these partners, there is a record in the table VDGPO with SNUMOBJ = ‘VD’ and ROLETYP = "TR0100".)

3. Impact of Rule Violations

  • Partners without a valid address cannot be contacted via normal mail channels (e.g. for sales information, event invitations, etc.) – broken process.
  • When a partner without an address is to be dunned[?], the address must be manually – broken process, resulting in additional effort/cost.
  • Location is an important part of rating a customer. The risk analysis of a partner without an address is therefore inaccurate – skewed performance indicator.
  • In Germany (as probably in most countries), money transfers out of the country are highly regulated and must be reported to the authorities. Without a valid address this cannot be properly determined – violation of regulation.

4. Root Causes

The following causes have been identified:

  1. Addresses for a partner are entered in the SAP Business Partner (transactions BUP1 and BUP2). One address for a partner has to be assigned as a “postal address” on the "Addresses" tab. Sometimes, when entering a new partner, users forget to assign a “postal address”.
  2. In addition, the use of an address as a “postal address” is time dependent, i.e. you can enter a start and end date. When it is known that a partner will move in the near future (which is normal when a customer takes out a real estate loan), the “postal address” is assigned with an end date, but without entering the new address which is valid after the end date. When the end date is reached and no new postal address is assigned, the partner will not have a valid postal address.

5. Correction

Depending on the situation and causes as noted above, the following correction procedures shall be applied:

  1. When there is no postal address at all, then a user in Division shall use the SAP transaction BUP2 to assign the default address on the tab "Address list" of a partner as a postal address without a specific end date.
  2. If a postal address was entered but lost its validity, the user shall check whether a new default address has been entered. If that is the case this new default address shall be assigned as a postal address as well.
    If no new default address was entered, the customer shall be contacted to determine the new address and entered as described above. If necessary, the default address shall be changed as well.

DQ Messgröße – Steckbrief-Beispiel

February 8, 2010 by · 1 Comment
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Im letzen Blogpost wurden die Elemente eines Steckbriefs für DQ Messgrößen vorgestellt. Diese Elemente sollen mit Hilfe eines ausführlichen Beispiels verdeutlicht werden.

1. Bezeichnung

Grundlage der weiteren Diskussion ist folgende Regel:

  • Messgröße 1: Partner, die keine Postanschrift besitzen
    Diese Messgröße wird im folgenden genauer beschrieben.

Weitere, einfache Regeln:

  • Messgröße 2: Kunden, bei denen Anzeichen für eine Dublette vorliegen
  • Messgröße 3: Aktive Baufinanzierungs-Darlehen, bei denen für das Besicherungsobjekt kein Beleihungswert vorliegt.

2. Datenregel

Allen Partnern (Datensätze in der Tabelle BUT000) sind normalerweise Adressen (Tabelle ADRC) mit Hilfe der Tabelle BUT021_FS (Adressverwendung BUT021_FS–ADRVERW = “WAGA”) zugeordnet werden. Von der Messgröße werden Partner erfasst, bei denen keine Verknüpfung in der BUT021_FS vorkommt oder kein gültiger Satz in der BUT021_FS (aktuelles Datum zwischen DATE_FROM und DATE_TO) vorliegt.

Dabei sind nur solche Partner relevant, die Hauptdarlehenspartner eines Darlehens sind. (Für diese Partner gibt es einen Satz in der Tabelle VDGPO mit SNUMOBJ = ‘VD’ und ROLETYP=’TR0100’.)

3. Auswirkungen der Regelverletzungen

  • Bei Partnern ohne Adresse gibt es keine Möglichkeit, Schreiben (Informationen, Einladungen, etc.) zu versenden(Prozess kann nicht durchgeführt werden).
  • Wenn an einen Partner ohne Adresse eine Mahnung versendet werden soll, muss die Adresse erst aufwändig ermittelt werden (Prozess kann nur mit zusätzlichem Aufwand durchgeführt werden).
  • Bei Kunden ohne Anschrift ist die Bestimmung der Region nicht möglich, die ein wichtiges Kriterium bei der Ermittlung des Kundenratings darstellt. Die Risikobewertung des Kunden ist daher ungenau (ungenaue Kennzahl).
  • Kontobewegungen von Kunden aus dem Ausland müssen gemäß AWG/AWV gemeldet werden. Ohne deutsche Anschrift kann nicht ausgeschlossen werden, dass der Kunde im Ausland wohnt (Verletzung gesetzlicher Vorschriften).

4. Fehler-Ursachen

Die Erfassung einer Postanschrift erfolgt im SAP Geschäftspartner (Transaktionen BUP1 und BUP2). Eine erfasste Anschrift muss zusätzlich über den Reiter “Adressübersicht” als “Postanschrift” dem Partner zugeordnet werden. Teilweise wird bei der Neuanlage eines Partners versäumt, diese Zuordnung vorzunehmen.

Diese Zuordnung ist zeitabhängig, d.h. sie kann mit einem Anfangs- und Endedatum versehen werden. Wenn bei der Erfassung bekannt ist, dass ein baldiger Umzug bevorsteht (z.B. wenn der Partner ein Immobilien-Darlehen aufnimmt), wird ein Beziehungsende erfasst, ohne die anschließend neu geltende Adresse zu erfassen. Wenn dies vor Ablauf der Gültigkeit der alten Adresse nicht nachgeholt wird, verliert die alte Adresse ihre Gültigkeit und der Partner besitzt keine gültige Postanschrift.

5. Vorgehen zur Korrektur der fehlerhaften Datensätze

  • Wenn zu einem Partner keine Postanschrift erfasst wurde, so ist durch einen Sachbearbeiter in Abteilung A in der SAP Transaktion BUP2 die Standardanschrift über den Reiter “Adressübersicht” dem Partner als Postanschrift ohne festes Enddatum zuzuordnen.
  • Wenn die Postanschrift erfasst wurde, diese aber ihre Gültigkeit verloren hat, ist zunächst zu prüfen, ob eine neue Standardanschrift zugeordnet wurde. Ist dies der Fall, ist diese wie oben beschreiben auch als Postanschrift zu übernehmen.
  • Ist auch keine neue Standardanschrift erfasst worden, so ist über die zuständige Filiale, die ggf. Kontakt mit dem Kunden aufnimmt, die korrekte Anschrift zu ermitteln und zu erfassen.

Describing Data Quality Measurands

February 5, 2010 by · 1 Comment
Filed under: English 

For German Readers: Es gibt eine deutsche Version dieses Artikels.

There is more than a good name when specifying a Data Quality Measurand. Five important elements are discussed in this blog post. In a subsequent entry the elements will be illustrated with an example.

1. Name of DQ Measurand

A meaningful, descriptive term simplifies the communication between all the parties involved. It should describe the measurand briefly but accurately as possible.

2. Description of the DQ Rule

The description of the data quality rule must be quite detailed, so that the exact tests are clear and and thus the DQ rule can be implemented with a SQL statement or a program. General terms used (e.g. ‘customer’) must be defined, for example, in a general section of the documentation or in a business glossary.

If possible, the rule is developed in collaboration between the IT and business departments, usually in an iterative fashion. Exceptions to the rule (ie situations where a violation of the rule is not a data quality issue) should also be documented.

3. Impact of Rule Violations

In order to prioritize between several DQ problems, it is important to understand the consequences of rule violations. Some general types:

  • Are there direct costs incurred by noncompliance?
  • Are regulations are being violated?
  • Will the DQ problems result in broken processes?
  • Does the DQ problem lead to incorrect or skewed performance indicators?

Qualitative and quantitative results should be described as accurately as possible. For this purpose, it is important to have a good overview of the processes and data of the company. It also requires discussion with the various departments entering and using the data.

In order to obtain management support for the elimination of DQ problems, it is essential to identify the consequences of non-action.

4. Root Causes

If you want to permanently fix the DQ problems, it is necessary to identify the root cause of the DQ problem. The system where the wrong information originates (or necessary entries have been omitted) has to be identified. This sounds simple, but typically you have to backtrack through a number of systems to get to the source of the problem. “Five whys” is a good strategy for this task.

The exact description of the error causes is a valuable aid when defining preventive measures and in case of a recurrence of the DQ problem.

5. Correction

Finally,there is a description of how defective records can be corrected:

  • If data is missing or even wrong, how can you determine the correct values? Can you retrieve these values from the Internet (e.g. wrong ZIP codes) or do you have to check the paper records? Or do you have to contact the customer and ask for the information?
  • Will there be a manual correction (e.g. a user entering data into an ERP system)? Which programs, menus, transactions etc. should be used?
  • Is there a program that “automagically” fixes the problems for large amounts of data?

This information enables a quick response when new records for a known DQ problem show up.

DQ Messgröße – 5 Steckbrief-Elemente

February 1, 2010 by · 2 Comments
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Dass eine DQ Messgröße einen aussagekräftigen Namen erhalten muss, ist wohl klar. Was sonst noch dazu gehört, wird in diesem Artikel genauer betrachtet. In einem folgenden Eintrag werden die Elemente an einem Beispiel weiter diskutiert.

1. Bezeichnung der DQ Messgröße

Eine aussagekräftige, einheitliche Bezeichnung erleichtet die Kommunikation zwischen den Beteiligten. Sie sollte die Messgröße knapp, aber möglichst genau beschreiben.

2. Beschreibung der Datenregel

Die Beschreibung der einzuhaltenden Datenregel muss so detailliert sein, dass die genaue Umsetzung der Prüfung abgeleitet werden kann und somit die DQ Messgröße mit Hilfe eines SQL Statements oder eines Programms umgesetzt werden kann. Dabei verwendete allgemeine Begriffe (z.B. ‘Kunde’) sind zu definieren, z.B. in einem allgemeinen Abschnitt der Dokumentation oder in einem Business-Glossar.

Nach Möglichkeit ist diese Regel zusammen mit dem betroffenen Fachbereich zu erarbeiten und meist in einem iterativen Prozess zu schärfen. Die dabei ermittelten Ausnahmen (d.h. Konstellationen bei denen eine Verletzung der Regel keinen Fehler darstellt) sind ebenfalls festzuhalten.

3. Auswirkungen der Regelverletzungen

Für eine Priorisierung bei mehreren DQ-Problemen ist es wichtig, die Folgen von Regelverletzungen zu kennen. Erste Ansatzpunkte:

  • Entstehen direkte Folgekosten durch die Regelverletzungen?
  • Werden gesetzliche Vorschriften verletzt?
  • Können Prozesse nicht oder nur mit zusätzlichem Aufwand oder Kosten durchgeführt werden?
  • Können Kennzahlen nicht bestimmt werden oder werden durch Regelverletzungen ungenau oder unzuverlässig?

Nach Möglichkeit sind qualitative und quantitative Folgen so genau wie möglich anzugeben. Hierfür ist es wichtig, einen guten Überblick über die Prozesse und Datenbewirtschaftung des Unternehmens zu haben und mit den verschiedenen Fachbereichen die Auswirkungen von Regelverletzungen zu erarbeiten. Um Management-Unterstützung für die Beseitigung von DQ-Problemen zu erhalten, ist es unerlässlich, die Folgen des Nicht-Handelns aufzuzeigen.

4. Fehler-Ursachen

Um einen Ansatz zur Korrektur und zur dauerhaften Beseitigung des DQ-Problems zu haben, ist es wichtig zu ermitteln, wo das DQ-Problem entsteht. In welchem System sind fehlerhafte Eingaben erfolgt oder benötigte Angaben unterblieben? U.U. muss man dabei mehrere Schritte in der Datenbewirtschaftungskette zurückgehen, um zur eigentlichen Fehler-Ursache zu kommen.

Die genaue Beschreibung der Fehler-Ursachen stellt eine wertvolle Hilfe bei der Definition von Präventionsmaßnahmen dar, mit denen nach einer Korrektur das erneute Auftreten des DQ-Problems verhindert werden soll.

5. Vorgehen zur Korrektur der fehlerhaften Datensätze

Den Abschluss bildet eine Beschreibung, wie fehlerhafte Datensätze korrigiert werden können:

  • Wenn Angaben fehlen oder falsch sind, wie können die korrekten Werte bestimmt werden? Können die Werte aus dem Internet (z.B. fehlerhafte Postleitzahlen) oder der Kundenakte entnommen werden? Muss gar der Kunde direkt angesprochen werden?
  • Werden diese Angaben von einem Benutzer erfasst werden? Welche Programme, Menüpunkte, Transaktionen etc. können dazu verwendet werden?
  • Gibt es ein Korrektur-Programm, mit dem eine maschinelle Korrektur bei großen Datenmengen erfolgen kann?

Mit diesen Informationen kann bei Auftreten von Fehlern schnell reagiert werden.