Dieses Kapitel stellt ausgewählte Methoden und Werkzeuge für das unternehmensweite Datenqualitätsmanagement (DQM) vor, die im Rahmen der Konsortialforschung im Kompetenzzentrum Corporate Data Quality entwickelt worden sind. Jedes der drei vorgestellten Werkzeuge wurde gemeinsam mit Praxispartnern des CC CDQ konstruiert und mehrfach erfolgreich angewendet.

3.1 Methode zur Umsetzung der DQM-Strategie

Der erste Teil dieses Kapitels präsentiert eine Methode zur Strategieentwicklung und Wirtschaftlichkeitsanalyse für das unternehmensweite DQM vorFootnote 1. Die Methode umfasst insgesamt zehn Aktivitäten und 28 Techniken. Sie ist konfigurierbar, sodass je nach Ausgangslage und Anforderungen im anwendenden Unternehmen die passenden Aktivitäten und Techniken ausgewählt werden können. Zum Beispiel wird keine DQM-Reifegradanalyse benötigt, wenn die Stärken und Verbesserungspotenziale für das DQM schon definiert sind.

Die Methode richtet sich in der Praxis an mehrere Anspruchsgruppen im Unternehmen: Aus den Zielen der Geschäftsleitung und der Prozessverantwortlichen ergeben sich unternehmensweite DQM-Anforderungen. Die Methode garantiert für diese Anspruchsgruppen, dass die DQM-Strategie von ihren Zielen abgeleitet ist und ihre Anforderungen systematisch abgearbeitet werden. DQM-Verantwortliche erhalten mit der Methode eine „Roadmap“, mit deren Hilfe sie erprobte DQM-Maßnahmen unternehmensweit etablieren können.

Abbildung 3.1 zeigt am Beispiel von TelCo Inc. die unternehmensweiten DQM-Anforderungen der Unternehmensleitung und den Nutzen der Methode für den Konzern-Datensteward.

Abb. 3.1
figure 1

Nutzen der Methode am Beispiel der TelCo Inc. (Falge 2015, S. 5)

3.1.1 Aufbau der Methode

Die Methode besteht aus vier Phasen:

  1. 1.

    Analyse: Ziel ist die Definition der Reichweite, der Anspruchsgruppen und des Beitrags der DQM-Strategie zur Unternehmensstrategie sowie die Ableitung unternehmensinterner und -externer Anforderungen für das DQM.

  2. 2.

    Strategieentwicklung: In der Strategieentwicklung werden die strategischen DQM-Ziele, Prinzipien und Richtlinien definiert. Darauf aufbauend wird der Umsetzungsplan abgeleitet.

  3. 3.

    Wirtschaftlichkeitsanalyse: Phase III hat zum Ziel, den monetären Wert hoher Datenqualität zu quantifizieren und DQM-Investitionsentscheidungen ökonomisch zu rechtfertigen. Die Investitionsrechnung schafft die Voraussetzung für die anschließende Überwachung der DQM-Kosten und des realisierten Nutzens in Phase IV.

  4. 4.

    Umsetzung & Kontrolle: Phase IV führt den Umsetzungsplan aus. Dies geschieht zum einen mit Techniken des Programm- und Projektmanagements und zum anderen durch Verankerung der DQM-Ziele in den Funktions- und Geschäftsbereichsstrategien. Maßnahmen zum Veränderungsmanagement sichern den DQM-Programmerfolg ab. Ein Strategie-Controlling in Form einer spezifischen Balanced Scorecard dient als Instrument für die Überwachung und Erfolgsmessung der Maßnahmen des DQM.

Eine weitere Form der Kontrolle stellt das kontinuierliche Überwachen der Prämissen der gewählten Strategie dar. Ändern sich die Bedingungen im Umfeld des Unternehmens, so kann eine Anpassung der Strategie erforderlich werden. Die Prämissenkontrolle entspricht der strategischen Analyse in Phase I, wodurch klar wird, dass es sich beim strategischen Management für DQM um einen kontinuierlichen Prozess handelt.

Die Techniken in allen vier Phasen führen zu bestimmten Ergebnisdokumenten, die den Fortschritt der Methodenanwendung für das Projektteam dokumentieren und dazu dienen, die erzielten Ergebnisse unternehmensintern zu kommunizieren.

Abbildung 3.2 zeigt die Gesamtübersicht über die Aktivitäten, Techniken und Ergebnisdokumente jeder Phase.

Abb. 3.2
figure 2

Methode zur Strategieentwicklung und Wirtschaftlichkeitsanalyse für das DQM. (Falge 2015, S. 29)

Die Entwurfsergebnisse der Phasen bauen aufeinander auf, d. h. sie stehen in einer zeitlichen Reihenfolge. Dabei sind jedoch Rücksprünge und Iterationen möglich. Ein Beispiel dafür ist Phase III, da die Techniken der Wirtschaftlichkeitsanalyse auch dafür benutzt werden können, das Mandat für DQM im Unternehmen zu etablieren oder zu erweitern. In diesem Fall würde die Wirtschaftlichkeitsanalyse Aktivitäten der Phase I auslösen.

Das Vorgehensmodell in Abb. 3.3 zeigt die idealisierte zeitliche Reihenfolge der Aktivitäten in den einzelnen Phasen.

Abb. 3.3
figure 3

Vorgehensmodell der Methode. (Falge 2015, S. 30)

3.1.2 Beispieltechniken der Methode

Im Folgenden werden ausgewählte Techniken kurz erläutert, um einen beispielhaften Durchlauf durch alle vier Phasen der Methode zu illustrieren.

Phase I, Aktivität I.1:Technik „Festlegen der strategischen Reichweite“

Das Festlegen der strategischen Reichweite der DQM-Strategie ist die Basis für alle weiteren Analyse-Tätigkeiten, für die Beschreibung der Ist- und Soll-Situation sowie in Phase II die Formulierung der DQM-Ziele. Die strategische Reichweite steckt den Rahmen ab, für den die DQM-Strategie entwickelt werden soll. Häufig ist die strategische Reichweite schon durch die Zuweisung des Mandats vom Auftraggeber bestimmt. Wenn nicht, ist es die Aufgabe des Konzern-Datenstewards, die einzubeziehenden Organisationseinheiten, Regionen, Datenklassen, Prozesse und Systeme zu definieren und mit dem Auftraggeber abzustimmen.

Die Ergebnisdokumentation sollte eine Aufstellung der einzubeziehenden Bereiche in der folgenden Form sein:

  • Organisationseinheiten (inkl. Größe und Entscheidungsträger; bildet Input für Stakeholder-Analyse)

  • Datenklassen

  • Regionen und Länder

  • DQM-relevante Kernprozesse

  • Verwendete Anwendungssysteme (optional)

  • Verweis auf die relevanten Unternehmensziele für die Organisationseinheit

Phase II, Aktivität II.2: Technik „Ableitung Maßnahmenkatalog“

Idealerweise leitet sich der DQM-Maßnahmenkatalog von den beschlossenen DQM-Zielen, Prinzipien und ausgewählten Optionen der Aktivität II.1 Strategieformulierung ab. Aus Zeitersparnisgründen erarbeiten einzelne Unternehmen einen Maßnahmenkatalog auch direkt basierend auf den Ergebnissen einer Reifegradanalyse (Aktivität I.1). In diesem Fall können neben zukünftigen Maßnahmen schon laufende oder projektierte Initiativen in die Liste aufgenommen werden, um zu verdeutlichen, dass für die betroffenen Reifegradkriterien zügig eine Verbesserung zu erwarten ist. Gelegentlich wird die Technik Ableitung Maßnahmenkatalog auch im Anschluss an eine Prozesskostenrechnung (Aktivität III.2) eingesetzt. So kann der Vergleich der Kosten einzelner DQM-Prozesse direkt dazu genutzt werden, Maßnahmen zur Verbesserung einzuleiten und diese zu priorisieren.

Unabhängig davon, ob die Maßnahmen von DQM-Zielen oder von Reifegradkriterien (mit hohem Handlungsbedarf) abgeleitet sind, ist die Herleitung klar zu dokumentieren. Das Beispiel in Abb. 3.4 zeigt die Ableitung von Maßnahmen, die in direktem Bezug zu Reifegradkriterien mit dringendem Handlungsbedarf (angedeutet durch die Zahlen in der Spalte Auswirkungen) stehen. Der erarbeitete Maßnahmenkatalog (abgeglichen mit den laufenden Maßnahmen) versteht sich als initialer Vorschlag des DQM-Teams und ist eine Ausgangsbasis, um weitere laufende, geplante oder vorzubereitende Maßnahmen in enger Zusammenarbeit mit den Fachbereichen zu ergänzen und zu priorisieren. Die priorisierten Maßnahmen müssen im Anschluss im Detail präzise geplant und umgesetzt werden. Um den Erfolg der umgesetzten Maßnahmen (Verbesserung des Reifegrades der Teilkriterien) messen zu können, empfiehlt es sich, die Reifegradmessung nach ein bis zwei Jahren zu wiederholen.

Abb. 3.4
figure 4

Beispiel Ableitung Maßnahmenkatalog (Auszug). (Falge 2015, S. 53)

Phase III, Aktivität III.2, Technik „Lebenszykluskostenrechnung (LCC)“

Lebenszykluskostenrechnung bzw. Life-Cycle-Costing (LCC) zielt darauf ab, alle Kosten einer Investition (und der damit verbundenen Aktivitäten und Prozesse) zu erfassen, die im Laufe ihres Lebenszyklus entstehen. Lebenszykluskosten sind definiert als „sum of all costs incurred during the life time of an item, i.e., the total of procurement and ownership costs“ (Dhillon 1989). Der Verein Deutscher Ingenieure beschreibt in seiner Richtlinie VDI 2884 ein LCC-Modell für die Beschaffung, den Betrieb und die Instandhaltung von Produktionsmitteln. Abbildung 3.5 zeigt das Modell im Überblick.

Abb. 3.5
figure 5

Lebenszykluskosten nach VDI-Richtlinie 2884. (VDI 2005, S. 5)

Das LCC-Modell gliedert den Lebenszyklus in drei Phasen, nämlich vor der Nutzung des Anlageguts, während der Nutzung und nach der Nutzung. Über die drei Phasen hinweg lassen sich fünf Kostenarten unterscheiden (VDI 2005):

  • Allgemeine Beschaffungskosten

  • Folgekosten der Beschaffung

  • Betriebs- und Hilfsstoffe

  • Instandhaltungskosten/Ersatzteile (inkl. Änderungskosten)

  • Außerbetriebnahmekosten

LCC-Modelle werden schon bei der Untersuchung von Anwendungssystemen genutzt. Darüber hinaus lassen sich die Konzepte des LCC-Ansatzes auf die Phasen des Datenlebenszyklus (Erstellung, Nutzung und Deaktivierung von Daten) übertragen (Otto 2012a).

Außerdem ist auf das Konzept der „Total Cost of Ownership“ (TCO) zu verweisen, das sich weitgehend mit dem der Lebenszyklusrechnungen für Ressourcen überschneidet (Geissdörfer et al. 2009). TCO-Modelle und LCC-Modelle unterscheiden sich im Wesentlichen in zwei Punkten: Die TCO-Modelle berücksichtigen im Gegensatz zu LCC-Modellen die Transaktionskosten. Umgekehrt ist die Betrachtung der sog. „Overall Equipment Efficiency“ in LCC-Modellen integriert und wird in TCO-Modellen nur eingeschränkt oder überhaupt nicht berücksichtigt.

Phase IV, Aktivität IV.1, „Techniken des Programm- und Projektmanagements“

In einem Programm werden mehrere, miteinander verwandte oder verbundene Projekte zusammengefasst. Das Programm-Management versucht, nicht nur die richtigen Projekte auszuwählen, sondern auch die Projekte effizient zu betreiben und Projektrisiken klein zu halten. Die Bewertungsgrundlagen zur Auswahl der Projekte liefern die Projektanträge. In einem standardisierten Projektantrag sind u. a. finanzielle Kennzahlen wie ROI, NPV oder IRR, projektspezifische Erfolgsfaktoren, Angaben zu Zielen, Risiken, Kosten und zur Zeitplanung enthalten. Außerdem prüft das Programm-Management die Abhängigkeiten zwischen den Projekten, die Einhaltung von Qualitätsstandards sowie die Verfügbarkeit von Mitarbeitern und anderen Ressourcen.

Im Rahmen der Ressourcenplanung für das DQM gilt es, folgende Fragen zu beantworten:

  • Welche DQM-Projekte können überhaupt mit den zur Verfügung stehenden Ressourcen realisiert werden?

  • Welche spezifischen Ressourcen werden den Projekten zugewiesen?

  • Welche projektkritischen Ressourcen und DQM-Kompetenzen müssen auf- oder ausgebaut werden bzw. welche müssen ggf. am externen Markt zugekauft werden?

Letztlich wird für jede DQM-Maßnahme der Planungsperiode ein Projektplan benötigt. Er bezeichnet nach DIN 69905 die „Gesamtheit aller im Projekt vorhandenen Pläne“ und kann u. a. folgende Unterlagen enthalten: Projektstrukturpläne, Meilensteinpläne, Gantt-Diagramme oder Netzpläne. Projektmanagement-Techniken sind problemneutral und müssen nicht für das DQM angepasst werden. Weitere Angaben können daher der Methode PROMET®-PM (IMG 1999) oder dem PMI PMBoK (Project Management Institute 2013) entnommen werden.

3.2 Reifegrad-Assessment und Benchmarking-Plattform für das Datenqualitätsmanagement

3.2.1 Ausgangssituation in Unternehmen

Um die Datenqualität im Unternehmen nicht nur einmalig, sondern dauerhaft zu verbessern, etablieren Unternehmen das Datenqualitätsmanagement als Unternehmensfunktion. Denn Datenqualitätsmanagement ist kein Projekt, sondern eine Aufgabe, die kontinuierlich wahrgenommen werden muss (Weber 2009; Weber et al. 2009; Batini und Scannapieco 2006). Dazu sind Fähigkeiten in strategischer, organisatorischer, technischer, aber auch kultureller Hinsicht erforderlich (Lee et al. 2002; Baskarada et al. 2006; Bitterer 2007; DataFlux 2007). Zwar ist die Bedeutung des Datenqualitätsmanagements als wichtige Unternehmensfunktion in vielen Fällen erkannt. Jedoch attestieren Unternehmen den eigenen Datenqualitätsmanagement-Fähigkeiten erst einen frühen Reifegrad (Pierce et al. 2008).

Beim Aufbau sowie bei der Weiterentwicklung dieser Fähigkeiten benötigen Unternehmen Unterstützung. Grundsätzlich sind zwei Fälle zu unterscheiden. Entweder bauen Unternehmen das Datenqualitätsmanagement erstmalig auf, oder es handelt sich um die Verbesserung eines bereits bestehenden Datenqualitätsmanagements. Die verantwortlichen Mitarbeiter sind mit Fragen konfrontiert, wie sie in Tab. 3.1 dargestellt sind.

Tab. 3.1 Typische Fragestellungen von DQM-Verantwortlichen

Verantwortliche für das Datenqualitätsmanagement und Führungskräfte benötigen ein praxisnahes und anwendbares Vorgehen zur Beantwortung dieser Fragestellungen. Zwei Werkzeuge unterstützen bei der Steuerung und Verbesserung des Datenqualitätsmanagements und des damit verbundenen Transformationsprozesses, nämlich ein Reifegradmodell und ein Benchmarking-Portal.

3.2.2 Reifegradmodelle und Benchmarking als Steuerungsinstrumente

Ein Reifegradmodell misst generell die Fähigkeit eines Unternehmens, seine Ressourcen zu einem bestimmten Zweck einzusetzen (Rosemann und De Bruin 2005). Ein Reifegradmodell für Datenqualitätsmanagement misst die Fähigkeit eines Unternehmens, Datenqualitätsmanagement zu betreiben (Ofner 2013; Ofner et al. 2013a). Typischerweise enthält ein Reifegradmodell mehrere Kriterien, mit deren Hilfe bewertet wird, inwiefern die Kriterien die Ziele der Reifegradstufen erreicht haben. Das Ergebnis einer Reifegradbewertung soll Unternehmen unterstützen, Verbesserungsbereiche zu identifizieren und zu priorisieren.

„Benchmarking“ bezeichnet allgemein einen Leistungsvergleich bestimmter eigener Kennzahlen (z. B. für Prozessleistungen oder Managementpraktiken) mit den Kennzahlen eines geeigneten Vergleichsobjekts. Eine Reifegradbewertung kann in Kombination mit Benchmarking erstens dazu genutzt werden, das eigene Reifegradergebnis in Relation zu einer ausgewählten Vergleichsgruppe zu setzen (z. B. Unternehmen der gleichen Industrie), um eigene Leistungsdefizite aufzudecken. Zweitens kann sie dazu dienen, sich an den Besten zu orientieren und realistische Zielwerte zu definieren, um daraufhin konkrete Maßnahmen für die Verbesserung des eigenen Reifegrads zu planen und umzusetzen.

Benchmarking wurde in den 1980er und frühen 1990er Jahren als Methode begründet, von anderen Unternehmen zu lernen und sogenannte Best Practices zu identifizieren (Camp 1989). Grundlage des Benchmarkings sind Kennzahlen, die in komprimierter Form quantitativ messbare Merkmale betrieblicher Sachverhalte beschreiben. Bei Kennzahlen kann zwischen Leistungs-, Treiber- und Analysegrößen unterschieden werden (Legner 1999; Abb. 3.6).

Abb. 3.6
figure 6

Klassifikation von Kennzahlen mit Beispielen für einen DQM-Leistungsvergleich. (nach Legner 1999, S. 112)

  • Leistungsgrößen sind finanzielle und Prozesskennzahlen, die sich an den wirtschaftlichen Zielen des Unternehmens orientieren.

  • Treibergrößen sind vor allem Mengengerüste, die die Rahmenbedingungen der Leistungsgrößen bestimmen und für die Vergleichbarkeit von Messergebnissen unterschiedlicher Organisationen berücksichtigt werden müssen.

  • Analysegrößen unterstützen die spätere Interpretation des Benchmarks im Rahmen der Ursachenanalyse für eine Leistungslücke.

Abbildung 3.6 zeigt das Zusammenspiel der Kennzahlentypen am Beispiel von Datenqualitätsmanagement in einem Kennzahlensystem. In diesem Zusammenhang ist der Reifegrad des Datenqualitätsmanagements eine Analysegröße, die für eine Ursachenanalyse herangezogen werden kann. Falls beispielsweise ein anderes Unternehmen in einer Leistungsgröße (z. B. Durchlaufzeit des Materialanlageprozesses) ein besseres Ergebnis erzielt, zeigt die Reifegradanalyse auf, in welchen Kriterien eine Lücke zu dem anderen Unternehmen und ein potentieller Handlungsbedarf bestehen. Durch die Identifikation der Best Practices, die Ursache für die Leistungsunterschiede sind, kann sich ein Unternehmen an bewährten Lösungsansätzen orientieren und deren Umsetzung beschleunigen. Treibergrößen wie beispielsweise die Anzahl der Datensätze oder die Unternehmensgröße sind wichtig bei der Auswahl geeigneter Benchmarking-Partner, um die Vergleichbarkeit und Aussagekraft eines Benchmarks zu erhöhen.

Reifegradmodelle und Benchmarking sind Steuerungsinstrumente für Verantwortliche des Datenqualitätsmanagements, um regelmäßig Verbesserungsbereiche zu identifizieren und zu priorisieren, Maßnahmen auf Grundlage von bewährten Lösungsansätzen zu planen und Zielwerte aufgrund von Benchmarks zu setzen.

3.2.3 EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement

Im Rahmen des Kompetenzzentrums Corporate Data Quality (CC CDQ) wurde ein standardisiertes Reifegrad- und Benchmarkingmodell entwickelt, das Fähigkeiten und Kennzahlen für das Datenqualitätsmanagement strukturiert und beschreibt, das „EFQM-Framework für das Stammdatenqualitätsmanagement“Footnote 2,Footnote 3(engl. „EFQM Framework for Corporate Data Quality Management“) (EFQM 2011). Das Modell deckt alle Bereiche des CDQ-Frameworks für Stammdatenqualitätsmanagement (vgl. Kap. 1.4) ab und basiert auf der Struktur des „Excellence Models“ der EFQM (European Foundation for Quality Management)Footnote 4.

Das Modell ist an die generischen Struktur des „Excellence Models“ der EFQM angelehnt und gewährleistet dadurch die Anschlussfähigkeit an bestehende EFQM-Bewertungs- und Analysetechniken. Die von der EFQM und ihren Partnern entwickelten Techniken werden seit über 20 Jahren eingesetzt und kontinuierlich weiterentwickelt, um das Qualitätsmanagement in Unternehmen zu bewerten.

Das Modell unterscheidet zwei Perspektiven (Abb. 3.7). Die Befähigungsperspektive bewertet, was konkret in einem Unternehmen getan wird. Die Ergebnisperspektive berücksichtigt, welche Ergebnisse damit erreicht werden sollen. Ein hoher Reifegrad in der Befähigungsperspektive ist demnach wertlos, wenn damit nicht die gesetzten Ergebnisse erreicht werden. Ziele der beiden Perspektiven müssen somit ausbalanciert werden. Das Reifegradmodell definiert insgesamt 35 Fähigkeiten und mehr als 70 Kennzahlen für das Stammdatenqualitätsmanagement (Stand 2015). Während die Fähigkeiten in einer Reifegradbewertung als Kriterien zur Feststellung des Reifegrads verwendet werden, können die Kennzahlen als Ausgangspunkt für den Aufbau eines Kennzahlensystems zur Steuerung des Datenqualitätsmanagements verwendet werden.

Da sich die Anforderungen an ein Datenqualitätsmanagement im Laufe der Zeit wandeln, wird das EFQM-Framework jährlich aktualisiert und veröffentlicht.

Abb. 3.7
figure 7

Das EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement. (EFQM 2011, S. 14)

3.2.4 Corporate Data Excellence: Steuerungswerkzeuge für Verantwortliche des Datenqualitätsmanagements

Corporate Data Excellence ist eine unternehmensübergreifende Initiative zum Austausch von Erfahrungen zwischen Unternehmen mit dem Ziel, erfolgreiche Stammdatenqualitätsmanagement-Konzepte zu verbreiten. Die Initiative stellt über ein Internetportal Werkzeuge zum Leistungsvergleich (Benchmarking) zur VerfügungFootnote 5. Es umfasst ein Steuerungscockpit, eine Benchmarking-Datenbank und eine Good Practice-Datenbank.

Steuerungscockpit

Das Steuerungscockpit ist die informationstechnische Umsetzung eines Kennzahlensystems für das Datenqualitätsmanagement. Standardisierte Kennzahlen können aus einem bestehenden Katalog ausgewählt und mit eigenen Kennzahlen ergänzt werden. Kennzahlen werden dann grafisch aufgearbeitet und dem Verantwortlichen in Form von interaktiven „Dashboards“ zur Verfügung gestellt (siehe Abb. 3.8). Zusätzlich unterstützt das Steuerungscockpit den gesamten Prozess einer Reifegradbewertung von der Datensammlung über die Datenaufbereitung bis zur Analyse. Analyse- und Ergebnisberichte werden automatisiert erstellt und sind für die Kommunikation gegenüber Entscheidungsträgern ausgelegt. Das Steuerungscockpit integriert die internen Steuerungsinformationen mit den Vergleichswerten der Benchmarking-Datenbank, um neben der internen auch die externe Sicht darzustellen.

Abb. 3.8
figure 8

Steuerungscockpit für den MDM-Verantwortlichen. (eigene Darstellung)

Benchmarking-Datenbank

Die Benchmarking-Datenbank enthält Vergleichswerte für das Datenqualitätsmanagement zwischen Unternehmen (u. a. Reifegrad, Kosten, Durchlaufzeiten, Mengengerüste). Diese Datenbank ist eine Grundlage für unternehmensindividuelle Benchmarking-Berichte (siehe Abb. 3.9). Bei den Vergleichswerten wird sichergestellt, dass der Rückschluss auf ein einzelnes Unternehmen nicht möglich ist. Regelmäßig durchgeführte Benchmarking-Studien und -projekte aktualisieren laufend die Vergleichswerte.

Abb. 3.9
figure 9

Vergleich mit anderen Unternehmen mit der Benchmarking-Datenbank. (eigene Darstellung)

Good Practice-Datenbank

Die Good Practice-Datenbank zeigt erfolgreiche Lösungsansätze von Unternehmen für die verschiedenen Aspekte des Datenqualitätsmanagements. Good Practices unterstützen im Fall einer identifizierten Leistungslücke bei der Maßnahmenplanung und geben konkrete Vorschläge zur Umsetzung von Verbesserungen (siehe Abb. 3.10).

Abb. 3.10
figure 10

Lernen von anderen Unternehmen mit der Good Practice-Datenbank. (eigene Darstellung)

Die Benchmarking-Initiative hilft den Verantwortlichen des Datenqualitätsmanagements, deren Mitarbeitern und den Unternehmen im Gesamten:

  • Geschwindigkeit und Aufwand: Innovative, aber andernorts bewährte Konzepte und Erfahrungen erleichtern das Stammdatenqualitätsmanagement.

  • Steuerbarkeit: Das Steuerungscockpit unterstützt die regelmäßige Bewertung der eigenen Effizienz, Effektivität und des Wertbeitrages des Datenqualitätsmanagements durch den Vergleich mit anderen Unternehmen. Es unterstützt den Verantwortlichen des Datenqualitätsmanagements bei der Steuerung und Überwachung sämtlicher Aktivitäten.

  • Befähigung: Mitarbeiter des Datenqualitätsmanagements werden befähigt, eigenverantwortlich standardisierte Reifegradbewertungen und ein Benchmarking durchzuführen. Der Zugriff auf die Benchmarking-Datenbank ermöglicht wiederholbare Benchmarks mit aktuellen Vergleichswerten.

  • Mitgestaltung und Nachhaltigkeit: Mitglieder der Benchmarking-Initiative sitzen im Change Advisory Board des EFQM-Frameworks und können aktiv die Inhalte des Reifegrad- und Benchmarkingmodells mitgestalten.

Die vorgestellten Werkzeuge unterstützen Unternehmen, durch den kontinuierlichen Vergleich mit anderen Unternehmen Verbesserungsbereiche zu identifizieren und die eigenen Fähigkeiten im Umgang mit kritischen Stammdaten zu verbessern.

3.3 Die Corporate Data League: Ein Ansatz zur kooperativen Geschäftspartnerdatenpflege

3.3.1 Herausforderungen der Geschäftspartnerdatenpflege

Geschäftspartnerdaten repräsentieren Geschäftspartner in Informationssystemen. Unter Geschäftspartnern versteht man in diesem Kontext sowohl Kunden als auch Lieferanten. In seltenen Fällen werden auch Mitarbeiter als Geschäftspartner definiert; diese sind aber hier von der Betrachtung ausgeschlossen. Die Qualität von Geschäftspartnerdaten kann unternehmensintern nur begrenzt sichergestellt werden, da sie im Gegensatz z. B. zu Produktdaten Objekte außerhalb der Grenzen des eigenen Unternehmens beschreiben. Die Qualitätssicherung dieser Daten ist für ein einzelnes Unternehmen äußerst aufwändig, denn Änderungen müssen aktiv recherchiert und nachgepflegt werden. Wichtige Attribute eines Geschäftspartners, die sich häufig ändern, sind beispielsweise die Adressen eines Lieferanten oder Beteiligungsverhältnisse. Adressänderungen oder Fusionen sind Vorfälle, von denen ein anderes Unternehmen nicht zwangsläufig erfährt, sodass die Qualität dieser Daten sinkt.

In der Regel verwenden Unternehmen neben der eigenen manuellen Datenpflegetätigkeit auch Referenzdaten von externen Datenprovidern. Sehr häufig wird dabei auf den Service des Unternehmens Dun & Bradstreet zurückgegriffen. Es bietet als Franchise-Netzwerk seinen Kunden weltweit Daten und Bewertungen zu mehr als 200 Mio. Unternehmen an und hatte damit in den vergangenen Jahren ein De-facto-Monopol. Der zunehmende Bedarf insbesondere von Finanzdienstleistern an aktuellen Risikobewertungen und den dazu benötigten Informationen zu Beteiligungshierarchien von Unternehmen hat jedoch Konkurrenz durch weitere Anbieter geschaffen. Beispiele sind Avox, eine Ausgründung der Deutschen Börse AG, oder Dienstleistungen des Unternehmens Bureau von Dijk.

Neben den genannten Angeboten, die insbesondere Finanzdienstleister adressieren, gibt es verschiedene Dienstleistungen zur Unterstützung von Marketing und Vertrieb. Das prominenteste Angebot ist die Plattform data.com des Unternehmens salesforce.com, deren primäre Dienstleistung die Identifikation von Ansprechpartnern in Unternehmen verschiedener Branchen und Regionen ist. Ein ähnliches Angebot bietet OneSource, wobei data.com auf Crowdsourcing als Informationsquelle setzt und OneSource öffentliche und kommerziell verfügbare Daten konsolidiert.

Die Leistungen dieser Anbieter sind jedoch auf bestimmte Anwendungsgebiete zugeschnitten und liefern daher einerseits nicht alle benötigten Daten eines Geschäftspartners (z. B. Lieferadressen einzelner Produktionsstandorte), dafür andererseits „teuer“ recherchierte Daten, die nicht benötigt werden (z. B. Mitarbeiterzahlen oder Wirtschaftsdaten). Zudem ist es im Einzelfall schwierig zu entscheiden, ob eingekaufte Referenzdaten aktueller sind als die „eigenen“ Daten im System. Die fehlende Transparenz zu Informationsquellen und Datenpflegern der externen Anbieter schafft nur geringes Vertrauen in die Daten und führt dazu, dass Referenzdaten in den meisten Fällen nur unterstützend bei Bereinigungen und nicht als operative Datenbasis genutzt werden.

3.3.2 Der Lösungsansatz des kooperativen Datenmanagements

Um die beschränkten Möglichkeiten der unternehmensinternen Pflege von Geschäftspartnerdaten und die daraus resultierenden Probleme zu beseitigen, bietet sich alternativ auch ein kooperativer Ansatz für das Geschäftspartnerdatenmanagement an. Kooperatives Datenmanagement bedeutet, dass mehrere Unternehmen gemeinsam Daten pflegen, deren Qualität sichern und die Daten letztlich für die eigene Wertschöpfung nutzen.

Ein solcher Ansatz bietet sich hier besonders durch die multiple Nutzung von Geschäftspartnerdaten an. Geschäftspartnerdaten haben im Vergleich zu z. B. Produktdaten eine Besonderheit: In der Regel ist ein Unternehmen S nicht nur Geschäftspartner eines einzelnen Unternehmens, sondern vieler anderer Unternehmen (z. B. der Unternehmen A, B, C). Daraus folgt, dass viele Unternehmen Daten zu gleichen Geschäftspartnern pflegen, aus unternehmensübergreifender Sicht also redundante Tätigkeiten ausführen. Dieser Sachverhalt ist in Abb. 3.11 dargestellt.

Abb. 3.11
figure 11

Redundante Pflege von Geschäftspartnerdaten. (eigene Darstellung)

Einen Lösungsansatz für diese redundante Datenpflege bietet die Zusammenarbeit der Unternehmen A, B und C, welcher in Abb. 3.12 dargestellt ist. Wenn Unternehmen C die Pflege der Geschäftspartnerdaten zu Unternehmen S übernimmt und die Unternehmen A und B die qualitätsgesicherten Daten ebenfalls nutzen, reduziert diese Kooperation den Gesamtaufwand der Unternehmen. Für Unternehmen C bleibt der Aufwand in diesem Beispiel zwar gleich, es profitiert aber von diesem Modell, sobald Unternehmen A oder B die Pflege für einen weiteren gemeinsamen Geschäftspartner übernimmt. Neben der Reduzierung des Aufwands ist auch eine Verbesserung der Datenqualität im Vergleich zur Pflege in einem Einzelunternehmen zu erwarten. Mögliche Fehler werden aufgrund der höheren Nutzungsfrequenz (A, B und C nutzen denselben Datensatz aktiv) früher erkannt.

Abb. 3.12
figure 12

Gemeinschaftliche Pflege von Geschäftspartnerdaten. (eigene Darstellung)

Eine weitere Verbesserung hinsichtlich sowohl der Qualität als auch des Aufwands ist durch die in Abb. 3.13 gezeigte weitere alternative Kooperationsform zu erwarten: Hier pflegt das Unternehmen S, als Teil der Community, „seine“ Geschäftspartnerdaten selbst. Besonders hinsichtlich der Aktualität und der Richtigkeit der Daten ist dies vorteilhaft, denn im Vergleich zu den Unternehmen A, B und C kann davon ausgegangen werden, dass S z. B. stets die aktuellsten Adressen seiner Produktionsstätten kennt.

Abb. 3.13
figure 13

Geschäftspartnerdatenpflege durch einen realen Data Owner. (eigene Darstellung)

3.3.3 Die Corporate Data League

Eine solche Community von Unternehmen zur gemeinschaftlichen Geschäftspartnerdatenpflege stellt die Corporate Data League (CDL) darFootnote 6. Die CDL ist eine Lösung, die vom CC CDQ gemeinsam mit dem Business Engineering Institute St. Gallen und drei Praxispartnern (Syngenta, Nestlé und Bayer) im Rahmen eines von der Schweizerischen Eidgenossenschaft geförderten Forschungsprojekts entwickelt wurde. Unternehmen können bei Erfüllung bestimmter Voraussetzungen Teil dieser Community werden und zu einem gemeinsam gepflegten Geschäftspartnerdatenpool beitragen. Die Idee ist, dass Unternehmen, die sich zu einem gewissen Grad vertrauen, einen abgeschlossenen Klub (als besondere Ausprägung der Community) bilden, in welchem sie gemeinsam bei geringeren Total Costs of Ownership zu einem „Golden Set“ von Geschäftspartnerdaten beitragen. Der Gesamtpflegeaufwand eines einzelnen Unternehmens als Teil der CDL sowie die Datenqualität an sich hängen von der Schnittmenge an Geschäftspartnerdaten zwischen den Mitgliedern ab.

Unter technischen Gesichtspunkten ist die CDL als cloud-basierte Lösung realisiert, die verschiedene Webservices bereitstellt. Die Mitglieder der Community verwenden die Funktionalitäten der CDL über eine Webapplikation (siehe Abb. 3.14).

Abb. 3.14
figure 14

Screenshot der Webapplikation der Corporate Data League. (eigene Darstellung)

Datenmodell

Geschäftspartner werden durch zahlreiche Attribute in den Informationssystemen abgebildet. Natürlich eignen sich nicht alle dieser Attribute für die gemeinschaftliche Pflege. So sind z. B. im Fall von Lieferanten die Preis-, Liefer- und Zahlungskonditionen geschäftskritisch und im Regelfall unternehmensindividuell. Allerdings zeigte die Erfahrung verschiedener Unternehmen, dass bestimmte globale und gleichzeitig geschäftsunkritische Attribute einen Großteil des Datenpflegeaufwands ausmachen. Genau diese Daten sind im Fokus der CDL, da hier das größte Einsparpotenzial besteht und diese Daten zum anderen aufgrund ihrer freien Verfügbarkeit für die gemeinschaftliche Pflege geeignet sind. Im Speziellen sind es folgende Attribute:

  • Der rechtlich eingetragene Unternehmensname und die Unternehmensform (z. B. AG oder GmbH)

  • Adressen, hierbei insbesondere: Legal-, Liefer- und Rechnungsadressen

  • Steuer(identifikations)nummer

  • Hierarchien (legal, geographisch, organisatorisch)

  • Compliance-relevante Daten wie Blacklist-Informationen oder Briefköpfe

  • Zertifizierungen, z. B. SAS70 oder ISO 9000

Das Datenmodell der Corporate Data League ermöglicht es, genau diese Informationen zu teilen. Jeder Geschäftspartner erhält eine global eindeutige Kennung, die „CDL ID“. Das Ziel des Datenmodells ist es, einen Standard für die beschriebenen Geschäftspartnerdaten zu schaffen und dabei existierende Standards soweit wie möglich zu integrieren. Daher basiert das Adressdatenmodell auf der extensible Address Language (xAL). Diese ist Teil des OASIS Customer Information Quality Standards (CIQ)Footnote 7. Die xAL ermöglicht es, in einer standardisierten „Sprache“ Adressen aus jedem beliebigen Land der Welt abzubilden. Abbildung 3.15 zeigt die konzeptionelle Darstellung der wichtigsten Komponenten der xAL. Ein bekannter Anwender der xAL ist Google, welches Konzepte dieses Standards für die Repräsentation von Adressen in GoogleMaps nutzt.

Abb. 3.15
figure 15

Konzeptionelle Darstellung der extensible Address Language (xAL). (eigene Darstellung)

Data Governance-Konzept und Funktionalitäten

Der Zugriff auf die Funktionalitäten und die Kooperationsprozesse der Corporate Data League erfolgt über bereitgestellte Webservices oder alternativ über eine Webapplikation. Das Governance-Modell der CDL sieht dabei grundsätzlich zwei verschiedene Rollen vor:

  • Data Steward: Der Data Steward ist für einen oder mehrere Datensätze verantwortlich. D. h. er muss Änderungen an den ihm zugewiesenen Geschäftspartnerdaten autorisieren und selbst regelmäßige Prüfungen vornehmen. Der Spezialfall ist die Rolle des Data Owners: Ein Unternehmen, welches Mitglied der CDL ist, ist automatisch auch der Data Steward für die Geschäftspartnerdaten des eigenen Unternehmens.

  • Data Subscriber: Andere Unternehmen, die einen Datensatz verwenden, für diesen aber nicht verantwortlich sind, haben die Rolle des Data Subscriber für diesen Datensatz. Diese Rolle setzt voraus, dass ein bestimmter Datensatz von mindestens einem weiteren Unternehmen genutzt wird. Ein Subscriber kann Änderungsvorschläge für den verwendeten Datensatz machen. Diese müssen aber vom Data Steward freigegeben werden.

Eine Voraussetzung dieses Governance-Modells ist die Anonymität der Rollen. Das bedeutet, dass weder der Data Steward erkennen kann, welche anderen Unternehmen einen bestimmten Datensatz verwenden, noch dass ein Data Subscriber weiß, welches Unternehmen die Data Steward-Rolle einnimmt.

Neben den generellen Funktionalitäten zur Kooperationssteuerung bietet die CDL diverse Zusatzfunktionalitäten, welche Unternehmen bei der Sicherstellung der Datenqualität ihrer Geschäftspartnerdaten unterstützen. So wird die GoogleMaps API zur Validierung und grafischen Darstellung von Adressdaten verwendet. Durch die Verwendung des xAL Standards sowohl in der CDL als auch in der GoogleMaps API ergibt sich nur ein geringer Integrationsaufwand. Zusätzlich bietet die CDL eine Funktionalität zur Identifikation von Duplikaten im eigenen Geschäftspartnerdatenbestand. Technisch zu Grunde liegen dabei eine Implementierung von Apache Lucene zur Indexierung der Daten und die Verwendung verschiedener Vergleichsalgorithmen, die zur Optimierung konfiguriert werden können.

Business Vocabulary und semantisch annotierte Referenzdaten im CDL-Portal

Neben der Adressvalidierung und den manuellen Editiermöglichkeiten der CDL-Mitglieder umfasst die CDL auch ein frei zugängliches Referenzdaten-Repository. Diese Daten werden in einem semantischen Wiki, dem „Corporate Data League Portal“Footnote 8, gepflegt. Durch die semantische Annotation der Daten können diese problemlos in den CDL-Services oder auch in anderen Applikationen verwendet werden. So sind z. B. alle Ländercodes gemäß ISO3166 und sämtliche erlaubten Unternehmensformen je Land dokumentiert. Diese Informationen können z. B. von einem Data Steward in einem Unternehmen während der Erstellung oder der Pflege von Geschäftspartnerdaten abgerufen werden, sodass unerlaubte Kombinationen z. B. von Unternehmensform und Land vermieden werden können.

Zusätzlich nutzt das CDL-Portal die „Standard Semantics of Business Vocabulary and Rules“ (SBVR) der OMGFootnote 9. Basierend auf SBVR werden die verwendeten Begriffe und Konzepte in einer fachbereichs-verständlichen Sprache strukturiert beschrieben. Die Beschreibungen der einzelnen Attribute können dynamisch mittels Webservice oder direkt in der CDL-Webapplikation abgerufen werden. Die semantische Annotation ermöglicht auch hier die einfache Integration.

3.4 Weitere Methoden und Werkzeuge des CC CDQ

Neben den in den vorigen Kapiteln und Abschnitten vorgestellten Methoden und Werkzeugen sind seit dem Projektstart des CC CDQ im Jahr 2006 eine Bandbreite weiterer Werkzeuge entwickelt und erprobt worden, auf die Verantwortlichen für das unternehmensweite Datenqualitätsmanagement zurückgreifen können (Tab. 3.2).

Tab. 3.2 Weitere Methoden und Werkzeuge des CC CDQ

Eine vollständige Übersicht ist über die Internetpräsenz des CC CDQ verfügbar.