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.